Blog de Andres Urena

Un excelente post sobre como se debiese realizar una estimación de tiempo/esfuerzo de un proyecto de software.

[PM] Estimaciones y Scheduling Avanzado - Lucas Ontivero

El día 22 de febrero tuvimos el agrado de compartir un desayudo/presentación del grupo arquitectum.org en la ciudad de Córdoba. Pudimos ver que en muchas de las definiciones sobre el rol que cumple el arquitecto de software en una empresa estaban bien concebidas dentro del perfil que se está desarrollando en Harriague & Asociados. Entre los temas que se discutieron entra la forma recomendada por Microsoft del organigrama del área de Arquitectura, además, cuales son las responsabilidades del arquitecto en cada una de sus "facetas" por decirlo así, comencemos por el principio.

Definición del área de arquitectura (el qué, cómo y con qué)

Si bien el rol del arquitecto de software viene circulando desde hace mas de 10 años por los laboratorios de sistemas y las áreas de ingeniería de software, no se ha estandarizado una definición exacta de que es un arquitecto de software, es en este sentido que se busca en diferentes fuentes bibliográficas definiciones más claras de que es o como este debiera ser tanto como rol unipersonal como de un área que se dedique a la arquitectura de software, la siguiente definición.

“Arquitectura de software es la suma de los módulos complejos, procesos y los datos del sistema, su estructura y exactas relaciones entre sí, cómo puede ser y se espera que sea, sus extensiones y qué tecnologías participan, deducir las capacidades exactas y flexibilidad del sistema desde el cual se puede formar un plan para la implementación o modificación del sistema.” (Hohmann, 2003)

Con seguridad esta definición no abarca todos los aspectos de un arquitecto de software pero, toca las esenciales. Cabe mencionar que dentro de la gran gama de definiciones de diferentes autores se puede considerar que la arquitectura es diseño, si bien una de las tareas del arquitecto es “diseñar” una solución, el término diseño está siendo mal empleado y causa confusión al momento de la delegación de responsabilidades.

Si bien al momento de la creación de una solución de software para un cliente participan muchos roles y con responsabilidades muy claras sería bueno definir el objetivo (en términos no técnicos) que es lo que un arquitecto y el resto de su equipo debe hacer.

¿Qué?

El “Que” del desarrollo de una solución es el resultado de la unión de los requerimientos de un cliente que llegan a un arquitecto y este al tener una visión clara del entorno en el que se encuentra el cliente, las necesidades del mismo y las expectativas de crecimiento de este como resultado del uso de la solución que vamos a proveer, definen el propósito u objetivo de la aplicación de la mano de un modelado de negocios que es realizado en forma conjunta con los analistas que forman parte del equipo. Considérese que el arquitecto es el director de una orquesta sinfónica se encarga de coordinar a cada uno de los músicos para que la pieza que interpretan salga de acuerdo a la partitura.

¿Cómo?

Una vez con el modelado de negocios en mano y con un equipo de analistas funcionales, se confecciona la documentación técnica del proyecto, esto consiste en el análisis, modelado y diseño de la solución a los requerimientos del cliente. El arquitecto cumple el rol de organizador y facilitador de definiciones y como un validador de la evidencia del modelado.

¿Con qué?

Esta tarea es orquestada ( de nuevo por el arquitecto) y esta vez cambia el equipo de trabajo, ahora seguirá su trabajo junto con un metodólogo y un líder técnico con un framework de trabajo bien consolidado para definir cada una de las partes de la solución, esta vez si se toma muy en detalle a la solución, las decisiones deberán ser tomadas de acuerdo a la tecnología que vaya ser utilizada por el equipo de desarrollo, presupuesto y cronograma del proyecto (a esta altura ya debiera estar bien definido el equipo de trabajo del proyecto).

Organigrama propuesto

Esta más que claro que cada compañía tiene sus propios organigramas y definiciones de puestos de trabajo, y no es intención de nadie tratar de cambiar esto, lo que se intenta es dar una guía de cómo se pudiese que un área de desarrollo de soluciones se organice.

Si bien este organigrama toma en cuenta todas las áreas que se puedan involucrar en el mantenimiento y medianamente el desarrollo de aplicaciones, no cuenta con un área específica de ingeniería de software esta es esencial para toda aquella empresa que desee brindar servicios de software factory.

Calidad del servicio de arquitectura

Así como el término es aun algo poco definido, el servicio de arquitectura es aun más desconocido, la pregunta es, ¿Necesito un arquitecto para el proyecto? La respuesta a esa pregunta (si uno hace las cosas bien) va a ser siempre SI. Un arquitecto es aquel individuo que posee la visión más clara del negocio donde va a implementar una solución, y es capaz de hablar varios idiomas, por esto entiéndase, que es capaz de hablar con el cliente acerca de cómo encarar la solución en el mismo lenguaje que usa el cliente (lenguaje de negocios) y por otra parte es capaz de bajar a tierra todos esos conceptos en la forma más clara y técnica posible para poder comunicarse con los desarrolladores.

Características

A grandes rasgos se considera que un arquitecto de software debiese tener algunas (sino todas) de las siguientes características:

• Visionario (ver el bosque y no solo los árboles)
• Referente para su equipo de trabajo – consultor
• Guardián de las estrategias y definiciones
• Evangelizador de frameworks sin estar atado con la tecnología
• Diseñador con criterio corporativo

Conclusiones

Está claro que el rol de un arquitecto, de forma estándar, no está definida del todo, sobretodo en nuestro entorno latinoamericano de trabajo, y depende de las buenas definiciones y trabajo arduo que tenemos por delante el definir a cabalidad el rol, sus responsabilidades y habilidades.

Bibliografía

Albin, S. T. (2003). The Art of Software Architecture—Design Methods and Techniques. Indianapolis, Indiana: Wiley Publishing, Inc.

Hohmann, L. (2003). Beyon Software Architecture: Creating and Sustanining winning Solutions. Boston Ma: THE ADDISON-WESLEY .

Día y hora: Lunes 26 de Noviembre de 2007, 18.00 hs.

ADO.Net Entity Framework
El nuevo ADO.Net Entity Framework permite manipular datos usando un modelo de objetos.
Aprenda sobre esta nueva tecnología de Microsoft que cambia la forma en que se piensa acerca de los datos. Algunos de los temas que veremos son:
Introducción a los ORM
Arquitectura de ADO.Net Entity Framework
Modelado con Entity Framework
Consulta de datos con Entity SQL
Consulta de datos con Linq To Entities
Entity Data Model Tools
Actualizacion de datos
Linq versus Entity Framework
Arquitectura de las nuevas aplicaciones
Duración: 180 minutos.

Oradores:
Eugenio Serrano - Microsoft MVP - Solid Quality Mentors
Ing. Marcos Mellibosky - ARSoft

Lugar: Universidad Tecnológica Nacional (UTN) - Aula Magna
Maestro M. López esq. Cruz Roja Argentina
Ciudad Universitaria
Cordoba, Argentina.

Para registrarse a este evento, haga click aqui.

En pro de la divulgación de la información sobre tecnología se ha iniciado un ciclo de conferencias sobre Desarrollo de software en la UTN de San Francisco.

Entre los panelistas se encuentran varios profesionales que prestan sus servicios en Harriague & Asociados

El programa de charlas está disponible en:

http://www.frsfco.utn.edu.ar/jornada-sistemas-2007.asp

Éxitos a estos brillantes profesionales.

http://www.microsoft.com/latam/technet/articulos/tn/2007/ago-16.mspx

Aunque a muchos les parezca que esto no tiene sentido alguno, es necesario comprender que el desarrollo no solo es un proceso artesanal, sino que hasta podría considerarlo artístico. Sé que esto puede malinterpretarse pero en las siguientes líneas tratare de explicarme tan claro como el lenguaje escrito me lo permita.

La idea de un sistema, programa, herramienta de software o como quiera denominarse a una pieza de código compilado que cumple una función especifica es la de solucionar un problema o una situación dada para el manejo de información y/o cumplimiento de un proceso que puede o no ser administrado por una persona/s.

Esto puede llegar a ser una explicación muy simple en lo que a la cantidad de cosas que una pieza de código puede hacer, para alguno, para otros la explicación calza bastante bien; pero la idea de estas líneas no es la de tirar una verdad absoluta o de intentar conquistar los cerebros de los desarrolladores, sino, la de establecer una forma de entendimiento al momento de encarar el análisis de un proyecto de esta índole.

Es conocido por todos que el ser humano es el único ser de la creación que no es capaz de llevarse bien con su entorno, al plantear esta idea saltan a mi mente todos los conflictos bélicos y demás cosas que no son parte de este articulo, salvo que, hablemos de la forma en la que entablamos las negociaciones. Que tiene que ver esto con el desarrollo? bueno al momento de analizar una situación en la que es necesario implementar una pieza de cogido, es 100% seguro que deberemos entrar en negociaciones no solo con la persona que está encargando esta pieza, sino con el mismo equipo con el que se trabaja. Tenemos dos tipos de equipos de trabajo los cuales se dividen a su vez en más partes, definamos las primeras dos clases:

Grupos pequeños

Los grupos pequeños tienen a ser muy agiles, claro está, si es que este equipo se conoce bien, a fondo, conocen sus fortalezas y sus debilidades. En este punto quiero hacer hincapié.

Un equipo que conoce sus debilidades puede usarlas para fortalecerse a sí mismo al trabajar sobre ellas.

Un equipo pequeño que no tenga conciencia de sus debilidades es por lo general un equipo susceptible al conflicto, cada uno de los integrantes de este ve en su compañero de trabajo no a una persona que trabaja a su lado sino a una persona que le puede quitar su trabajo. Suena duro, pero así se presentan las cosas. Es sobre este tipo de equipo que me explayare y analizare cuales son los factures que debiesen tomar en cuenta sus integrantes para comenzar a fortalecerse.

Cada uno de los integrantes del equipo debiese conocer a todos sus compañeros, no solo en el ámbito laboral, sino como persona, esto podría parecer que no tiene relevancia y ahora explico porque si la tiene.

Al encarar una negociación muchas veces no logramos exactamente lo que queremos hacer, es en este momento que la personalidad de cada uno manifiesta su estado de ánimo de diferente manera. Algunos entablan una negociación en la que tanto uno como el resto salgan ganando, esta es la negociación ideal, así todos quedan contentos y el trabajo se aliviana tremendamente. Pero qué pasa si un miembro del equipo no está conforme con lo que se le asigno, o como termino la negociación, este miembro del equipo no ha ganado, es mas siente que ha perdido, he aquí el inicio de un problema muy grave.

El hecho que evite que no nos sintamos orgullosos del trabajo realizado comprende un fracaso tanto en lo personal como en lo profesional

Muchas veces me he encontrado en la situación en que uno de los miembros de mi equipo se siente frustrado por la forma en la que la negociación ha concluido, y es necesario que esa frustración sea:

Comunicada (de la mejor forma posible)

Tratada (entablar una negociación)

Solucionada (no puede quedar así)

Si estos pasos no son ejecutados tenemos una bomba de tiempo dentro del equipo, no porque aquella persona que no está "feliz" con el trabajo sea la bomba, sino por la situación en la que esta se encuentra, es necesario que el equipo se mantenga como tal.

Como comunicar frustraciones:

Al sentir que estamos perdiendo cada quien demuestra su sentir de diferente manera, depende de muchos factores, estado de ánimo, carácter, entorno, retribuciones, etc. la única forma de transmitir este sentimiento de frustración es hablando francamente con el equipo, mejor aun si se lo hace antes de cerrar la negociación (ideal) pero de no poderse tratar este asunto en una mesa redonda, el equipo de trabajo es como una familia, ya que durante un tiempo (tiempo de vida del proyecto) tendrán que compartir sus experiencias y verse las caras a diario.

(Continuará...)