Últimas entradas

IPCorp en Misión Comercial Multisectorial a México

El Polo IT Corrientes participará de la Misión Comercial Multisectorial (MCM) que, en el marco de la Visita de la Sra. Presidenta de la Nación, se realizará al Distrito Federal de México entre los días 13 y 15 de abril de 2011; no solo por la potencialidad reconocida de ese mercado en materia de Software y Servicios Informáticos, sino también para completar el último módulo del Proyecto de Desarrollo Comercial e Internacionalización del Grupo Asociativo que viene ejecutando desde el año pasado, en el marco de la Promoción de Clusters y Redes Productivas con Impacto en el Desarrollo Regional SEPyME-PNUD ARG/05/024.

La Misión Comercial Multisectorial programada, que cuenta con la organización de la Cancillería Argentina y la Fundación Exportar, constituye un marco muy propicio para presentar a las Empresas del POLO IT CORRIENTES en dicho mercado mexicano; las cuales viajan con la intención de concretar ventas directas, obtener representación comercial, agente de distribución o eventualmente un joint-venture con otras Empresas de ese país. 

Para ello, cada Empresa asociada ha confeccionado una Ficha de Inscripción, conteniendo información institucional y de productos, que será utilizada por los organizadores para la búsqueda de las contrapartes en México. En las fichas se informa sobre: sector al que pertenece la empresa; posición arancelaria del los productos que desea exportar; descripción detallada del producto y/ o principales usos; objetivos como participante de la rueda de negocios; perfil de la contraparte que desea contactar; etc. La delegación correntina estará integrada por las empresas que conforman el Polo IT Corrientes: Desarrollos NEA S.R.L., 3TX S.R.L., Daniel Filigoi & Asociados, IPCorp S.R.L., Aliare S.R.L., Coninfo.Net S.A., Soluciones Palm S.A., Comytel S.A. y E-Jaguareté S.R.L.

El Programa Tentativo de actividades de la Misión Multisectorial prevé el arribo a la Ciudad de México D.F. el martes 12 de Abril. El miércoles 13 se llevará a cabo un Desayuno de Trabajo seguido de un Seminario Empresarial y Rondas de Negocios. El jueves 14 de Abril, se desarrollarán las Rondas de Negocios durante todo el día y el viernes 15, se realizará un Seminario de trabajo sobre “Oportunidades de Negocios, Comercio e Inversiones entre Argentina y México” con la presencia de la Sra. Presidenta de la Nación; Encuentro con Líderes de las principales empresas del sector privado mexicano (CEO´s); firma del Acuerdo de Creación del Consejo Empresario Argentino – Mexicano; previéndose el regreso a Buenos Aires el mismo día por la tarde. 

En tal sentido, los trabajos de inteligencia comercial llevados a cabo por la Cancillería indican que los productos de software y servicios informáticos ofrecen buenas perspectivas para su comercialización en el referido mercado. Ello es así porque la región latinoamericana es una consumidora de software por efectos de la globalización y productora limitada, aunque creciente, a través de iniciativas internacionales de tercerización y, en menor medida, por la venta de productos desarrollados para mercados regionales.

En esa dirección y en el marco del Proyecto de Desarrollo Comercial e Internacionalización citado en el primer párrafo, durante el mes de Diciembre de 2010 el POLO IT CORRIENTES realizó una Misión Comercial a CHILE, con el objetivo de difundir la capacidad exportadora y hacer una primera experiencia piloto en el exterior como Grupo Asociativo. Ya se ha tomado contacto con CORRIENTES EXPORTA quien está facilitando la coordinación con la Subsecretaría de Comercio Internacional del Ministerio de Relaciones Exteriores, Comercio Internacional y Culto de la Nación. En particular se realizará una charla de orientación en temas comerciales y de protocolo, el día miércoles 23 del corriente a las 15 hs.

Haml: alternativa a ERb

Si hay algo de bueno que tiene rails, es como podemos cambiar sus componentes. Por ejemplo,
podríamos instalar SimpleStored a nuestro proyecto y reemplazar ActiveRecord para poder
trabajar con CouchDb, con Jquery-Rails podemos cambiar las librerías de prototype
por las de jquery. Otra cosa interesante es poder cambiar el motor de las
plantillas HTML, de esto vamos a hablar en este post.
Por defecto rails trae ERb (Embedded Ruby), como su nombre lo dice son archivos html con
condigo ruby embebido, son los archivos que todos los programadores de rails conocen, los rhtml.
Aquí la filosofía es muy simple, es escribir en html y para poner nuestro código
basta con utilizar <% %> y <%= %>.
Por ejemplo un listado de elementos sería así:

<table>
  <tr>
    <th>Raza</th>
    <th>Nombre</th>
    <th></th>
    <th></th>
    <th></th>
  </tr>
 
<% @perros.each do |perro| %>
  <tr>
    <td><%= perro.raza.descripcion %></td>
    <td><%= vaca.nombre %></td>
    <td><%= link_to 'Show', perro %></td>
    <td><%= link_to 'Edit', edit_perro_path(perro) %></td>
    <td><%= link_to 'Destroy',perro,:confirm=>'Are you sure?',:method=>:delete%></td>
  </tr>
<% end %>
</table>

Este código no es difícil de entender. Se empieza a poner un poco más
complicado cuando tenemos un código mas largo y con más código embebido,
por más ordenados que seamos cuesta entenderlo.
Para esto está Haml, en su página nos dice que “convierte nuestras horrorosas
plantillas en un verdadero haiku”. ¿Será cierta esta afirmación?, veamos como
queda nuestro listado:

%table
  %tr
    %th Raza
    %th Nombre
    %th
    %th
    %th
- @perros.each do |perro|
    %tr
      %td=perro.raza.descripcion
      %td=perro.nombre
      %td=link_to 'Show', perro
      %td=link_to 'Edit', edit_perro_path(perro)
      %td=link_to 'Destroy', perro, :confirm => 'Are you sure?', :method => :delete

Es un código mucho más limpio y ordenado, y sin dudas escribimos mucho menos

Según el sitio oficial de Haml , está basado en la idea de que el código de
descripción de páginas debe ser hermoso. Pensando en la simplicidad de Ruby y la
elegancia de Rails,recordando el axioma de que “la perfección se alcanza, no cuando ya
no queda nada más por agregar, sino cuando no queda nada más por eliminar”.
Como lenguaje de propósito específico está completamente diseñado para documentos XML,
y no tiene ninguna característica fuera de este ámbito.

Para instalar Haml en nuestra aplicación de rails 3, basta simplemente con editar el Gemfile
y agregar

gem 'haml'

luego en la consola ejecutamos

bundle install

y ya tenemos Haml en nuestra aplicación.
A partir de ahora los nombres de archivos html serán de la siguiente
manera index.html.haml.
La forma básica de un elemento html, sería así

%tagname{:attr1 => 'value1', :attr2 => 'value2'} Contents

Un párrafo nos quedaría así:

%p{:datatype => 'lupita'} Esto es un parrafo
 
#nos devuelve
<p datatype="lupita"> Esto es un parrafo </p>

Para cuando queremos utilizar un div, por ser este un elemento muy común no
necesita que pongamos %div. simplemente tenemos que poner el nombre del id (#) o
de la clase (.).

#show Esto es un div
 
//nos devuelve
<div id="show">Esto es un div</div>

De la misma manera si queremos agregar un id o una clase a cualqier tag, sería de esta
forma

%tagname#id.class

En Haml no se cierran los tags, esto se hace automáticamente, gracias a que es muy estricto
con la identación. Genera todo el html siguiendo la estructura de nuestro código

%ul
  %li Perro
  %li Gato
 
#nos devuelve
<ul>
  <li>Perro</li>
  <li>Gato</li>
</ul>

Y lo que más nos interesa. Si queremos embeber código ruby tenemos dos símbolos.
Si queremos mostrar algo usamos el igual (=), si no queremos que se vea usamos el guión medio(-).

%h1= @perro.nombre
- if @perro.agresividad > 5
  %p Es muy agresivo

Bueno, esto es una pequeña introducción a todo lo que podemos llegar a hacer con
haml. Y lo lindo que nos va a quedar nuestro código escrito de esta forma. Y es una muy
buena manera de aprender a indentar también. Para tener información un poco
más completa, tenemos su página oficial y su api
Espero que les guste y hasta la próxima.

Cursos de Verano 2011 Fa.C.E.N.A.

Al igual que en el 2010, este año se realizan los cursos de verano en la Facultad de Ciencias Exactas y Naturales y Agrimensura desde el 21/02/2011 hasta el 12/03/2011. Los cursos tienen como objetivo ofrecer a los profesionales y técnicos de la disciplina informática, la oportunidad de capacitación y actualización en herramientas orientadas al desarrollo de software. En esta oportunidad, IPCorp esta presente en el dictado de dos cursos. El primer curso es “Gestión de datos con PostgreSQL”, dictado por el Lic. Marcelo R. Diaz los días lunes, miércoles y viernes de 17 a 20 hs. y por otro lado, “Desarrollo Web Agil con Ruby on Rails”, desarrollado por el Lic. Carlos E. Barbiero, los martes y jueves de 18 a 22 hs.

Las inscripciones se realizan del 14 al 18 de febrero en el laboratorio de informática de 14 a 21 hs, o bien por correo electrónico a cursosveranofacena@gmail.com

Para más información de los contenidos de cada curso: http://exa.unne.edu.ar/docs/Informatica-Cursosdeverano2011-contenidos.pdf

Si querés obtener más información sobre los cursos dictados por el staff de IPCorp, podés enviar un email a contacto@ipcorp.com.ar, detallándonos tus consultas.

Listar todas las asociaciones de un modelo con Reflections

En rails, hacer relaciones entre tablas es muy fácil, basta con agregar en el modelo un :has_many:belongs_to, :has_and_belongs_to_many entre otros. Se pueden hacer todos los tipos de relaciones, pero no voy a profundizar este tema, todo lo que se necesita saber está en el API de Rails.

El otro día necesitaba eliminar un registro de una tabla, pero si este registro tenia algún registro asociado en otra tabla este no podía ser eliminado. La forma más fácil era hacer un NombreDeModelo.find() en todas las tablas asociadas y ver si existen registros. El problema es si esa tabla tiene asociadas muchas tablas y cada una de estas muchos registros, tomaría su tiempo.
La solución que se me ocurrió fué saber cuales son las tablas asociadas e ir haciendo los NombreDeModelo.find() de a uno y si alguno encuentra algo que tire un mensaje.
Rails tiene un método muy interesante que nos resuelve esto, se llama reflections.
Lo que hace es devolvernos un hash con todas las relaciones definidas en el modelo, veamos un poco de código:

Departamento.reflections
 
=> { :designaciones=>#<ActiveRecord::Reflection::AssociationReflection:0x46c04fc1 @name=:designaciones, 
                                  @active_record=Departamento(id: integer, descripcion:string), 
                                  @options={:class_name=>"Designacion"}, 
                                  @macro=:has_many>, 
       :localidades=>#<ActiveRecord::Reflection::AssociationReflection:0x261c2628 
                              @name=:localidades, 
                              @active_record=Departamento(id: integer, descripcion: string), 
                              @options={}, 
                              @macro=:has_many>}

Como vemos nos devuelve un hash, donde el key esta dado por el nombre que le dimos en el modelo a la relación y el value
es un objeto de la clase Reflection. Este objeto contiene 4 atributos:
@name: Nombre de la relación
@active_record: Este no entendí mucho, ya que no lo usé, si alguien me explica estaría bueno para agregarlo.
@options : las opciones que definimos en las relaciones, como el :class_name, foreign_key, :through, etc.
@macro: El tipo de relación

Con esto ya tenemos casi terminado el problema antes descripto, hacemos uso de un bloque y nos queda así:

Departamento.reflections.each do |ref|   
      if ref[1].macro.to_s == 'has_many' 
        registro = eval('@departamento.' + ref[1].name.to_s + '.first')     
      end
      unless registro.blank?
        existe_registro = 1
        break
      end
    end

Lo que hacemos es recorrer el hash hasta que encontramos un registro. Cuando encontramos uno cortamos la ejecución del bloque para que no siga buscando en la base de datos y problema resuelto.

Estoy seguro que debe haber miles de formas de hacer esto y quiza mucho más fácil, estaría bueno que comenten sus experiencias, siempre es bueno escuchar otra campana.

Conferencia “Tecnologías OLAP,Diseño de Soluciones de Business Intelligence”

El dia 26 de Noviembre del corriente año se desarrollará la conferencia “Tecnologías OLAP, Diseño de Soluciones de Business Intelligence“, a cargo del consultor informático Jorge Luis Valdez Socio Gerente de la empresa T&T Solutions distribuidor exclusivo de IDEASOFT en Argentina; la misma tendra lugar en el Aula Magna de FaCENA,  sita en 9 de julio 1449 en el horario de 19:00 a 20:30 hs. La entrada es gratuita y se emitirán certificados de asistencia.

La conferencia está destinada a profesionales, docentes y alumnos de informática y en particular a directivos y personal de las empresas de software de la región. El objetivo de la misma es conocer sobre las tecnologías OLAP,  su diferencia con la tecnología OLTP basadas en el modelo relacional y cómo implementar soluciones Business Intelligence mediante el diseño de modelos multidimensionales con la plataforma O3-PS (Performance Suite).

Contenido de la Conferencia

Título: “Tecnologías OLAP,Diseño de Soluciones de Business Intelligence”

• Evolución de las Tecnologías de la Información.
• OLTP verus OLAP.
• ¿Qué es un DatawareHouse, Datamarts y Dataming?.
• ¿Qué es un Cuadro Mando Integral , Tablero de Comando o Tablero de Control?.
• Presentación de la plataforma tecnológica O3-Performance Suite de IdeaSoft (O3-Designer, O3-Builder, O3-Browser, O3-Report, O3-Scorecard, O3-Gis).-
• Preguntas del público al orador.
• Cierre del evento.

CV del Disertante:

Jorge Luis Valdez nació en Corrientes y es egresado de la carrera de Licenciatura en Sistemas con el Título de Programador Universitario de Aplicaciones. Su experiencia laboral está enteramente relacionada al mundo de la informática, comenzando esta actividad como personal becado especial en el Centro de Cómputos de Corrientes, para luego pasar a la Contaduría General de la Provincia y formar parte del proyecto SIIF( Sistema de Administración Financiera) del cual surgió el proyecto SISPER donde se desempeñó como Project Leader. Luego se especializó en consultoría y desarrollos de soluciones ERP para el sector público , formando parte de varios proyectos entre los cuales se destacan: SIAP (Gobierno de Misiones), SISER (Gobierno Ciudad Autónoma de Bs.As), SIAFyC-SIARH (Gobierno de Formosa), proyectos en los cuales implementó soluciones del segmento BI con O3 de IdeaSoft.

Convenio de Cooperación entre FACENA e IPCorp S.R.L

El día martes 16 de noviembre, en el Campus de la UNNE, se procedió a la firma de un Convenio de Cooperación entre la Facultad de Ciencias Exactas, Naturales y Agrimensura de la Universidad Nacional del Nordeste, representada por su Decano Ing. Eduardo del Valle y la empresa IPCorp S.R.L, representada por su Gerente Lic. César Gerardo Kobluk en el marco de las iniciativas de los gobiernos y las universidades para el desarrollo de la industria del software en el país y en particular en la región.

Con la firma del Convenio ambas instituciones acuerdan contribuir a la mejora de la calidad del software mediante la transferencia de resultados de I+D, favoreciendo la competitividad de las empresas Pymes de la región, a través de la realización de actividades conjuntas enmarcadas en el proyecto F008-2009 “Modelos y métricas para la evaluación de la calidad del software” acreditado por la Secretaría de Ciencia y Técnica de la UNNE.

Cabe mencionar que el Convenio tiene como finalidad específica lograr la:

• realización de actividades recíprocas en materia de investigación, extensión, divulgación, capacitación y cooperación en áreas de interés común,
• generación de herramientas de software y metodologías que contribuyan a la mejora del producto y del proceso de desarrollo del mismo,
• formación y perfeccionamiento de RRHH en investigación, y
• difusión y divulgación de nuevas técnicas, herramientas y metodologías del campo de la Ingeniería de Software y de emprendedorismo tecnológico.

Los Coordinadores responsables de la planificación, coordinación y supervisión de las tareas necesarias para el logro de los objetivos propuestos son Mgter. Gladys Dapozo (FACENA-UNNE) y Lic. Carlos Enrique Barbiero (IPCorp S.R.L).

Jornada de Charlas de la Facultad de Ciencias Exactas de la UNNE

Jornada de Charlas de la Facultad de Ciencias Exactas – Universidad Nacional del Nordeste.

Fecha : 02 de Octubre de 2010

Lugar : Edificio 9 de julio . 9 de Julio 1449  - Corrientes -Cap-

Dirigido a estudiantes de la carrera de sistemas y pùblico en general. Las acreditaciones se realizan el mismo dìa, se entregaran certificados.

Cronograma de charlas

Charla “Diseño de Interfaces de usuario en Aplicaciones Web” en Jornadas de la FACENA – UNNE

En el marco de la  Jornadas  de  la Facultad de Ciencias Exactas, Naturales y Agrimensura de la UNNE, el Lic. Carlos Barbiero de IPCorp S.R.L brindará la Charla “Diseño de Interfaces de usuario en Aplicaciones Web” el día Sabado 2 de octubre de 11:00 a 13:00 hs, Lugar Edificio “9 de Julio”  calle 9 de Julio 1449 entre las calles San Lorenzo y Catamarca (Corrientes – Capital).

El Lic. Carlos Barbiero se graduó en la Universidad Nacional del Nordeste como Licenciado en Sistemas. Es especialista en Arquitecturas de Software, Desarrollador  Ruby on Rails.

La charla incluira los siguientes topicos:

1) Introducción, ¿que es una interfaz de usuario?
- Definiciones
- Pequeña referencia histórica
- Arquitectura de la información

2) Fenómeno Web 2.0
- Definiciones y conceptos
- Tecnologías influyentes
- Patrones de diseño

3) HTML, Javascript y CSS
- Introducción
- Frameworks JS
# Prototype
# Mootools
# Scriptaculous
# Jquery

- Jquery y Jquery UI
- Ejemplos, plugins y código

4) Ejemplos y Tips de diseño
- Sitios y aplicaciones de ejemplo
- Tips de diseño en aplicaciones Web

La razón de BDD. (Behaviour Driven Development) Parte 1

En estos últimos 6 años, la forma de programar y encarar proyectos de software ha ido evolucionando. Cuando uno comienza a trabajar, siempre elige una manera (sobre todo si se siente cómodo con ella) y la va adaptando según el proyecto en el que se esté realizando.
Muchos de estos cambios se producen por los requerimientos, magnitudes y alcances de los proyectos, y también con el tipo de clientes con el que se esté tratando. En los tiempos actuales, los clientes se han vuelto mucho más exigentes a la hora de solicitar un producto, generalmente van cambiando sus ideas y no solo eso, sinó que muchas veces (la mayoría) lo que el cliente pide no es lo que más necesita.
Esto también obliga a cambios a la hora de desarrollo de productos. Si queremos crecer (como empresa o freelance) obligadamente tenemos que adaptarnos a estos cambios.
BDD (Behaviour Drive Development) es una técnica de desarrollo de software ágil que fomenta la colaboración entre desarrolladores, QA (garantía de calidad) y participantes no técnicos o de negocios en un proyecto de software. Para más info sobre BDD Aquí (en inglés)

A continuación comparto con ustedes una serie de artículos escritos por David Chelimsky del por qué cambiar:

La mayoría del software que escribimos nunca se utilizará. No es nada personal,
es sólo que es una industria en la que no somos muy buenos dándole a la gente lo que
que quieren. La razón subyacente de esto es que los métodos tradicionales de software están diseñados para fallar -trabajan realmente en contra nosotros-. Individuos heroicos ofrecen software a pesar de su proceso de desarrollo y no a causa de él. Veremos cómo y por qué los proyectos fallan, y enfocaremos la atención en algunos de los desafíos que enfrenta el Desarrollo Ágil de Software.

Cómo fallan los procedimientos tradicionales
Los proyectos tradicionales fallan por muchas razones. Una buena manera de identificar los diferentes modos de fallo es preguntarle a tu jefe de proyecto lo que hace por la noche. (Es bueno hacerlo de vez en cuando, ayuda a su autoestima.) Es probable que nuestro jefe de proyecto se planteará una lista de temores similares a los nuestros:

Entrega tardía según el presupuesto

Estimamos, planificamos, tenemos todas las contingencias hasta la enésima potencia y luego, sucede la verdadera decepción de la vida real. Cuando nos deslizamos de la primera fecha, a nadie le importa demasiado. Es decir, sólo será un par de semanas. Si esto sigue sucediendo semanalmente, y así mensualmente, el suficiente número de personas, se han ido y se han unido a que podamos finalmente, poner el proyecto fuera de su miseria. Dieciocho meses a dos años suele ser suficiente. Este es software que no tiene importancia.

Entregando la cosa incorrecta

La mayoría de nosotros usamos un software que se entregó con retraso y más presupuesto en nuestros escritorios, en nuestros teléfonos móviles, en nuestras oficinas y hogares. De hecho nos hemos acostumbrado a los sistemas que se actualizan con correcciones de errores y nuevas características en forma de service packs y actualizaciones del sistema, o sitios web que ofrecen nuevas características con el tiempo. Pero ninguno de nosotros utiliza el software que no resuelve el problema que tenemos.
Es sorprendente cuánto esfuerzo de gestión de proyectos se dedica a cuidar el calendario o el presupuesto cuando el software persigue fines infinitamente más útiles que los mencionados.
Entonces, ¿cómo sucede esto? Tal vez los requisitos cambian después de que estuvimos de acuerdo con ellos, porque el negocio siguió adelante. Tal vez no fueron lo suficientemente claros en primer lugar. Puede ser que entregamos lo que la empresa pidió en vez de que lo que necesitaban. En cualquier caso ponemos una carga de esfuerzo en entregar el proyecto, dentro del presupuesto y a tiempo, pero resulta que nadie conseguirá realmente ningún beneficio de ello. Este es software que no tiene importancia.

Inestable en producción

¡Hurra! El proyecto llegó a tiempo y dentro del presupuesto, los usuarios lo miraron y decidieron que les gustó, por lo que lo ponemos producción. El problema es que el software falla dos veces al día. Creemos que es algo de memoria, o algo de la configuración, o algo de clustering, o de infraestructura, o …, pero ¿a quién estamos engañando? Nosotros no sabemos realmente lo que está causando la excepción, lo que es
más bien embarazoso y nos está costando mucho dinero. Si tan solo hubiéramos pasado más tiempo en probarlo!. La gente lo utilizará esta vez y se dará por vencido cuando se cae “constantemente”. Este es software que no tiene importancia.

Costoso de mantener
Hay una serie de cosas que no necesitamos considerar si estamos escribiendo software disponible. Mantenibilidad es uno de ellas. Sin embargo, si esperamos seguir con la Versión 1, Versión 2, Versión 3, o incluso una versión 2010 Professional Super Vaca Power Edition entonces fácilmente nos podemos pintar en una esquina, por no considerarnos desarrolladores río abajo.
Para empezar es probable que no participamos en la puesta en producción anticipada (early release) y no estamos al tanto de las decisiones y conversaciones que condujeron al diseño actual. Si el código no es obvio, los desarrolladores tendrán que luchar para entenderlo. Del mismo modo si el diseño no es obvio, si hay un montón de acoplamiento o redundancia innecesaria, si un montón de trozos fueron copiados y pegados y éste cambió ligeramente, entonces tendrán que luchar para resolver las implicaciones de los cambios que se hacen, lo cual es un éxito seguro a la hora de introducir defectos de regresión.
Con el tiempo el ritmo al que se pueden introducir nuevas características disminuirá hasta que los desarrolladores terminarán gastando más de su tiempo rastreando regresiones inesperadas y desarmando el “código spaguetti”. En algún momento, costará más mejorar el software que los ingresos que puede generar. Este es software que no tiene importancia.

Seguir leyendo la segunda parte

Traducido al castellano de “The Rspec Book, BDD with Rspec, Cucumber and Friends” Chapter 7 de David Chelimsky http://www.pragprog.com/titles/achbd/the-rspec-book ISBN: 978-1-93435-637-1

La razón de BDD. (Behaviour Driven Development) Parte 2

Por qué proyectos tradicionales fallan

La mayoría de estos modos de fallo ocurre con personas inteligentes tratando de hacer un buen trabajo. Para la mayor parte del software, las personas son diligentes y bien intencionadas. También es poco probable que los
errores en los proyectos son el resultado de la incompetencia o la incapacidad. Debe haber otra razón.
Tal vez este tipo de fracaso es un resultado inevitable del enfoque que hemos estado tomando (el método tradicional o cascada de entrega de software). No importa cuán inteligentes o bien intencionadas sean las personas, las cosas se pueden crear para el fracaso, y es sólo por los esfuerzos sobrehumanos que el software se entrega totalmente terminado.

Cómo funcionan los proyectos tradicionales

La mayoría de los proyectos de software se basan en la secuencia familiar de Planificación, Análisis, Diseño, Código, pruebas, implementación. Su proceso puede tener diferentes nombres, pero las actividades básicas en cada fase será bastante consistente. (Estamos asumiendo una especie de justificación de negocio que ya ha ocurrido, aunque incluso, no es siempre el caso)

Empezamos con la Fase de planificación: ¿cuánta gente, cuánto tiempo, qué recursos se necesitan, básicamente, ¿cual es el costo de entregar este proyecto y qué tan pronto vamos a ver algo funcionando?
Luego nos adentramos en una fase de análisis. Aquí es donde se articula en detalle el problema que estamos tratando de resolver, lo ideal sería sin prescribir cómo debe ser resuelto, aunque esto casi nunca es así.

Entonces tenemos una fase de diseño. Aquí es donde pensamos en cómo podemos utilizar un sistema informático para resolver el problema que tenemos articulado en análisis. Durante esta fase que pensamos sobre el diseño y la arquitectura, las decisiones técnicas a gran y pequeña escala, las diversas normas en torno a la organización, y poco a poco se descompone el problema en fragmentos manejables para que podemos producir especificaciones funcionales.

Ahora pasamos a la fase de codificación, donde escribimos el software que va a resolver el problema, de acuerdo a las especificaciones que salieron de la fase de diseño. Una suposición común es que en esta etapa, todo es coser y cantar, porque todo el pensamiento duro ya se hizo. Esto no es tan malo como parece, lo que estamos diciendo es que ahora se deben realizar las actividades de programación y pruebas (testing) a un riesgo relativamente bajo debido a que ya hicimos la planificación por adelantado (el análisis y diseño).

Ahora ya somos adultos responsables que tienen una fase de testing en la que probar el software para asegurarse de que hace lo que tenía que hacer. Esta fase incluye actividades con nombres como Testing de aceptación por los usuarios o Performance testing para destacar que nos estamos acercando a la entrega final.

Finalmente llegamos a la fase de implementación en la que desplegamos la aplicación en producción. Con un nivel adecuado de fanfarronería, se desliza nuevo software en producción y comenzamos a ganar dinero!

Todas estas fases son necesarias. No se puede comenzar a resolver un problema que no se ha articulado, no se puede iniciar la aplicación de una solución que no se han descrito, no se puede probar software que no existe y no se puede (o al menos no se debería) implementar software que no ha sido probado.
Por supuesto, en realidad, se pueden hacer cualquiera de estas cosas pero por lo general termina en lágrimas.

¿Cómo funcionan realmente los proyectos tradicionales

Hemos entregado proyectos en más o menos de esta manera desde que empezamos a escribir los sistemas informáticos. Ha habido varios intentos de mejorar el proceso y hacerlo más eficiente y menos propenso a errores, utilizando los documentos para formalizar la mano de fuerza, la creación de plantillas para los documentos, montaje de comités de revisión de las plantillas de los documentos, el establecimiento de normas y la acreditación formal para los comités de examen. . . . Por supuesto que podemos ver cuando el esfuerzo se ha ido.

La razón de toda esta ceremonia alrededor del hands-offs, opiniones, y cosas semejantes es más tarde en el ciclo de vida de entrega de software, detectar un defecto -o introducir un cambio- es más caro que ir por el camino correcto. Y no sólo un poco más – de hecho, la evidencia empírica en los últimos años ha demostrado que es exponencialmente más caro cuanto más tarde se averigua.

Con esto en mente, tiene sentido de adelantar el proceso. Queremos asegurarnos de que hemos reflexionado sobre los posibles resultados y cubierto todos los ángulos de manera temprana para que no nos sorprendamos por “desconocidos desconocidos” al final del día.

Están también, por supuesto, las cuestiones de la rendición de cuentas y responsabilidad cuando las cosas van mal inevitablemente. En una organización con una cultura de culpa tradicional cada grupo tiene que ser capaz de demostrar que no era culpa de ellos: los analistas, los arquitectos, los programadores, testers, el equipo de operaciones y en última instancia, el director del proyecto. Esto hace que, al reunir a un grupo de personas para firmar una declaración de que un artefacto -un plan de proyecto, un documento de requerimientos, especificación funcional, código – cumple con el nivel adecuado de fiabilidad. Si algo va mal ahora, debe ser debido a un error humano (es decir, la incompetencia, y más importante incompetencia de otra persona ) más adelante en el proceso.

Pero esto no es toda la historia. Sin embargo somos diligentes en cada una de las fases de desarrollo, cualquiera que haya entregado el software de manera tradicional hará constar la cantidad de trabajo que ocurre “debajo del radar”. El equipo de programación firma el plan del proyecto, resplandeciente en su detalle, las dependencias, los modelos de recursos, y gráficos de Gantt. Entonces los analistas comienzan a recibir a los apretones el detalle del problema y decir cosas como: “Hmm, esto parece estar más complicado de lo que pensábamos. Nos gustaría mejorar el plan, esta va a ser algo grande. ”

A continuación, los arquitectos empiezan a trabajar sobre sus características funcionales, que descubren una serie de preguntas y ambigüedades sobre los requisitos. ¿Cómo estos datos se refieren a esa pantalla? ¿Qué pasa si este mensaje no es recibido por ese otro sistema? A veces los analistas de inmediato pueden responder a la pregunta, pero más a menudo que significa que necesitamos más tiempo de análisis y por lo tanto más de los analistas. Mejor actualización de dicho plan. Y conseguir que fuera firmado. Y firmar el nuevo documento, mayores exigencias.

Usted puede ver cómo este costo de coordinación puede montar rápidamente para arriba. Por supuesto que realmente se inicia durante la fase de prueba. Cuando el probador plantea un defecto, el programador pone sus manos en el aire y dice que hizo lo que había en la especificación funcional, el arquitecto culpa al analista de negocios, y así, sobre derechos de copia de seguridad de la cadena. Es fácil ver donde este coste exponencial viene.

En este ir y venir se convierte más en una carga, nos volvemos con más miedo de hacer cambios, lo que significa que la gente hace el trabajo fuera del proceso y los documentos fuera de sincronización entre sí y con el propio software. Las Pruebas se comprimen, la gente trabaja tarde en la de noche, ya la liberación del software se caracteriza generalmente por llanto y el crujir de los dientes, los ojos inyectados en sangre, y varios intentos fallidos de descifrado las instrucciones de las notas de publicación.

Esto se ve agravado por el hecho de que las personas suelen trabajar en una fase de un proyecto y luego seguir adelante, así que para cuando el probador está señalando los defectos que el analista de negocios hace tiempo que se unió a un proyecto diferente y ya no está disponible.

Una profecía autocumplida

En resumen, los proyectos se vuelven exponencialmente más caros al cambior cuanto más nos adentramos en ellos, debido al efecto acumulativo de mantenimiento de todos los artefactos de proyecto en sincronía, por lo que adelantar el proceso con una gran cantidad de planificación para mitigar los riesgos, actividades de análisis y diseño para reducir la posibilidad de reelaboración.

Ahora, ¿cuántos de estos artefactos (el plan del proyecto, la especificación de requisitos, la alta y documentos de diseño de bajo nivel, el software en sí) existían antes de que comenzó el proyecto? Eso es, exactamente ninguno! Así que todo ese esfuerzo -que crece exponencialmente- se debe a que ejecutamos los proyectos de la manera en que hacemos! Así que ahora tenemos una situación de gallina y el huevo o un bucle de refuerzo en la Terminología del Pensamiento Sistémático.

La ironía del enfoque tradicional de los proyectos es que el propio proceso hace el coste exponencial de cambio! Cuando les preguntamos a nuestros jefes de proyecto la forma en que planifican este coste exponencial de los cambios que nos dicen es “a través de la experiencia.”
Han visto suficiente de proyectos en situaciones bastante pasar por el mismo dolor.

La respuesta de nuestra industria ha de ser reforzar el bucle en lugar de intentar algo que podría romper el ciclo completo. Sin embargo el desarrollo de software es todavía una industria muy joven, así que ¿de dónde viene esta curva de costes, en primer lugar?

Yendo más profundo, resulta que la curva se origina en la ingeniería civil. Tiene sentido que es posible que se desee pasar mucho tiempo en las fases de diseño de un puente o una embarcación. Una vez que los pilares de hormigón estén armados, si se hunden y la infraestructura de hierro fundido está en su lugar, las cosas se vuelven muy caras de corregir!

Sin embargo, estas normas sólo se aplican al desarrollo de software, porque se lo permitimos! El software es, así, suave. Se supone que es la parte que es fácil de cambiar, y con el enfoque correcto y algunas herramientas decentes puede ser muy maleables. Así que utilizando la metáfora de la ingeniería civil e igualando software con acero y concreto, nos hemos hecho a nosotros mismos un flaco favor.

Seguir leyendo la tercera parte

Traducido al castellano de “The Rspec Book, BDD with Rspec, Cucumber and Friends” Chapter 7 de David Chelimsky http://www.pragprog.com/titles/achbd/the-rspec-book ISBN: 978-1-93435-637-1