Un sistema software
provee dos valores: el comportamiento y la estructura.
Comportamiento
El comportamiento hace
referencia a las funcionalidades del sistema, es el QUÉ debe hacer. Muchos
programadores, y no programadores, creen que el trabajo consiste en desarrollar
esas funcionalidades y arreglar los bugs que van surgiendo. Esto no es verdad.
Estructura
La estructura hace
referencia al CÓMO está implementado el comportamiento. El CÓMO estará formado
por una serie de componentes y su interacción entre ellos. A esta estructura se
le denomina arquitectura del sistema.
Cuando hay que
desarrollar una nueva funcionalidad, esta se suele desarrollar y dar como
resultado una implementación concreta. Si la arquitectura es dependiente de
implementaciones concretas, cada vez será más complicado el añadir componentes
y que estos interactúen entre ellos. Por esta razón, las arquitectura deberían
ser «agnósticas» en cuanto a implementaciones concretas.
¿Qué es más importante?
El valor de un sistema
viene determinado por la utilidad del mismo:
- Si el
sistema tiene el comportamiento esperado pero una mala arquitectura a la
larga se incrementará la dificultad de añadir nuevos comportamientos hasta
el punto de que los costes serán tan altos que harán inútil el sistema.
- Si un
sistema no tiene el comportamiento esperado pero tiene una buena
arquitectura no será difícil añadir el nuevo comportamiento por lo que el
sistema continuará siendo útil.
La matriz de Eisenhower
«I have two kinds of
problems, the urgent and the important. The urgent are not important, and
the important are never urgent.»
Matriz de Eisenhower
|
Importante
Urgente
|
Importante
No urgente
|
|
No importante
Urgente
|
No importante
No urgente
|
La matriz establece que
los problemas que son urgentes son raramente importantes mientras que las cosas
importantes son raramente urgentes.
Estos cuatro casos se
pueden ordenar con prioridad siendo esta:
- Importante
y urgente.
- Importante
pero no urgente.
- Urgente
pero no importante.
- Ni
urgente ni importante.
Con esta tipología de
problemas podemos concretar que:
- El
comportamiento es algo urgente pero no es particularmente importante.
- La
arquitectura del sistema es algo importante pero no es algo
particularmente urgente.
Según la lista de
prioridades, la arquitectura de un sistema ocupa los puestos 1 y 2 mientras que
la funcionalidad ocupa los puestos 1 y 3.
La evaluación de las
tareas dependen de la capacidad del administrador para evaluar las mismas y si
este es consciente de la importancia de la arquitectura. Incluso aún teniendo
el criterio suficiente, la presión por parte de factores externos que quieren
ver el comportamiento hacen que el administrador tome tareas urgentes pero no
importantes pasan a ser importantes y urgentes.
La responsabilidad del
equipo de desarrollo es la de afirmar la importancia de la arquitectura sobre la
urgencia de las funcionalidades. Esta es la razón por la que no deben ceder a
presiones externas de manera que que el sistema que se cree sea fácil de
mantener a la par de implementar nuevas funcionalidades.
No hay comentarios:
Publicar un comentario