tag:blogger.com,1999:blog-1642327209032825052024-03-04T20:36:35.062-08:00Construir Software<br>Desarrollando fábricasAnwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-164232720903282505.post-81820438790199123942014-01-09T23:27:00.002-08:002016-08-07T22:33:15.807-07:00El entorno y sus partesLa vez pasada estaba recordando un experimento sencillo que se suele explicar en las escuelas sobre ondas y la velocidad de la luz. El experimento consistía en observar la deformación aparente que se produce a una cuchara cuando se introduce un vaso lleno de agua hasta la mitad, algo relacionado con la ley de snell si no estoy mal, luego otro día estaba leyendo sobre como se alimentan algunas células (y el ciclo de krebs creo) y por alguna extraña razón identifiqué en ambos casos una relación que podría ser interesante a la hora de modelar ciertos problemas computacionales.<br />
<br />
Las relaciones se dan entre un elemento y su entorno, tenia entonces esta idea en la cabeza de que los valores en las propiedades de algunos elementos varían según los valores en las propiedades de su entorno, de esta manera en el primer caso la velocidad de un rayo de luz varia según el indice de refracción del material (o ambiente) en el cual se propaga, no es igual en el vacío que en el aire o en el agua. Por otro lado cuando desarrollamos software utilizando OOP definimos clases que encapsulan los datos de sus propiedades, si por ejemplo yo quisiera modelar el primer caso, tendría una clase llamada RayoDeLuz que tendría un atributo velocidad, uno podría modelar el atributo velocidad como un método ObtenerVelocidad(..) que recibe como parámetro el material sobre el que se propaga el rayo de luz y así hacer el calculo pertinente para devolver la velocidad. Una vez que se ha definido una clase para representar un material, es difícil encontrar una forma de alterar el método ObtenerVelocidad para que funcione con otros materiales cuya influencia en los valores de velocidad están afectados por otro tipo de propiedades diferentes a las previamente establecidas, toca cambiar una interfaz, toca cambiar el método, toca establecer casos específicos para cada tipo de ambiente. <br />
<br />
Ahora consideremos que los datos son similares al rayo de luz, la representación de la información estaría dada por el medio en el cual se propaga dicha información, si por ejemplo los datos viajan por la red su representación sería diferente a su representación en la capa de aplicación o la de presentación, entonces, ¿Podríamos lograr que la información "mutara" en cada cambio de medio de propagación? Sera interesante codificar espacios reutilizables que pudieran albergar datos de diferentes tipos y adaptar la información entre si, por ejemplo, si tengo un objecto OBJ inmerso en un medio o espacio llamado MODELO y quiero enviar la información del objeto por la red, solo tendría que mover OBJ de MODELO a RED serializando automáticamente y agregando la información que haga falta. Los ORM se convertirían en un caso particular de este paradigma donde el espacio de origen es un modelo de datos y el de destino una base de datos relacional. Podríamos tener ambientes de ejecución especiales para diagnosticar problemas haciendo que la ejecución misma de un algoritmo dependa del ambiente en el que se desenvuelve. Si existieran ambientes heredados podríamos agregar aspectos nuevos al codigo existente, pero bueno la verdad se me acabó el tiempo y no terminé la idea, espero seguir otro día desarrollandola.Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-11952275002708012022013-12-30T21:30:00.001-08:002016-08-07T22:29:28.226-07:00ALGUNAS PREGUNTAS SOBRE LA GESTIÓN DE REQUERIMIENTOSSe suele decir que un buen código tiene en el fondo un buen diseño, sin embargo, un buen diseño solamente se puede verificar teniendo claros los objetivos del producto cuyo desarrollo ha sido emprendido. ¿Quiere decir esto que las únicas características susceptibles de ser medidas están asociadas directamente al dominio de los problemas que dicho desarrollo soluciona? De no ser así, ¿existe un mínimo de características de naturaleza subyacente que emerge de manera implícita en cada uno de los requerimientos del desarrollo? <br />
<br />
Para ponerlo en términos mas simples, cuando decidimos construir software por ejemplo un editor de texto un requisito puede estas asociado a la capacidad del sistema para escribir contenidos por parte de un usuario. Sin embargo, un requerimiento funcional de este tipo no puede estar completo de ninguna manera sin tener en cuenta el numero de palabras que deben ser escritas en un tiempo de referencia. Es decir. No nos sirve que se puedan escribir palabras si cada letra se demora un minuto en procesarse, seria en la practica un sistema completamente inútil.<br />
<br />
Si acordamos entonces que existen requerimientos subyacentes a este primero nuestra especificación crecería notablemente y nada sería capaz de garantizarnos que nuevos requerimientos no presenten la misma situación recurrentemente y hasta el infinito. ¿Cuál seria entonces la granularidad de los requerimientos de manera tal que sea viable establecer con exactitud las caracteristicas funcionales del producto y todos los requerimientos hijos relevantes? Pareciera que la respuesta se encuentra en las bases mismas del lenguaje. Nada que sea lo suficientemente claro de manera general debe ser reformulado con el fin de esclarecer detalles redundantes. Los requerimientos técnicos comunes deben plantearse de manera no redundante para poder alcanzar la completitud y la sencillez de manera sensata en nestras definiciones.<br />
<br />
Si vieramos una especificacion de un sistema como un arbol donde los nodos de dicho arbol son requerimientos . ¿podriamos construir un algoritmo para construir dicho arbol minimizando el numero de niveles y maximizando la descripcion del problema? ¿Podríamos realizar una clasificación automática sobre los conjuntos de tipos de requisitos técnicos generales que son comunes a un subconjunto de requerimientos? Probablemente basados en la experiencia previa algunos algoritmos existentes de clasificación y optimización podrían afinar con precisión cada vez mayor en el tiempo las predicciones de asociaciones o relaciones entre requisitos funcionales y técnicos, logrando una mayor robustez en las definiciones y los objetivos de nuestros desarrollos. <br />
<br />
Otra pregunta que podríamos hacernos sería, ¿Existe alguna forma de poder detectar en un esquema evolutivo de los requerimientos aquellas tareas que al final del ciclo de vida del desarrollo no habrán generado valor alguno en el producto final? Resolver este tipo de interrogantes pueden representar mejoras significativas en la productividad de los equipos, sin embargo, algunas parecen estar asociadas con la visión estratégica de la gestión de los proyectos y otras parecen estar relacionadas con la forma en la que crecen las expectativas a medida que avanzamos en la construcción de los conceptos fundamentales del sistema en cuestión. <br />
<br />
Seria interesante poder armar un modelo sencillo con las premisas esperadas con el fin de poder determinar si este tipo de interrogantes sobre la gestión de los requisitos puede abordarse de manera general o si estamos destinados a lidiar sin ninguna generalización clara con las dependencias aparentemente aleatorias entre los criterios que determinarán la calidad del software entregado. Espero que esto se analice en una entrada posterior.<br />
<br />
<br />
<br />Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-83510248995951284552013-12-05T00:23:00.000-08:002013-12-05T00:23:07.359-08:00Profiling de aplicaciones<h3>
<a href="" name="_Toc368185170">Profiling de
aplicaciones</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
El profiling de aplicaciones es
un estilo de análisis dinámico de software en el cual una herramienta llamada
comunmente <b>profiler</b> recolecta
información sobre el tiempo utilizado durante la ejecución de un programa por
parte de los componentes a evaluar con el ánimo de identificar demoras o
situaciones que puedan representar problemas de rendimiento de la aplicación.
De manera general lo que se busca con este tipo de pruebas es identificar los
tiempos o el uso de los componentes que conforman nuestra aplicación. </div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
El análisis realizado al utilizar
la información recolectada durante la ejecución de la aplicación en cuestión
estará relacionado directamente con el método utilizado para obtener los datos,
por lo que el tipo de herramienta utilizada se vuelve de vital importancia para
tener una buena idea de la calidad o resolución de los datos obtenidos. Como regla podríamos decir que a medida que
obtengamos mayor exactitud en los datos recolectados, mayor será el impacto en
el rendimiento de la aplicación monitoreada. A continuación se describen los
tipos más comunes de profilers según la forma utilizada para monitorear la
ejecución y se presentan adicionalmente algunas ventajas y desventajas de los
mismos.</div>
<h4>
Basados en eventos<o:p></o:p></h4>
<div class="MsoNormal" style="text-align: justify;">
Este tipo de herramientas
permiten la verificación de la mayoría de los tipos de evento presentados
durante la ejecución de la aplicación objetivo, por ejemplo, el inicio de un
llamado a una función o la carga de una biblioteca dinamica. Dado que la información se relaciona
directamente los eventos producidos, este tipo de aplicaciones puede impactar
el performance de la aplicación de manera general, por lo que es usual que se
utilice en ambientes de desarrollo y pruebas de investigación pero no en
escenarios donde afectar el rendimiento del sistema pueda representar un riesgo
como en el ambiente de producción. La
resolución de este tipo de herramientas es por lo general mejor que la de otro
tipo de profilers por la cantidad de datos recolectados pues no tienen pérdidas
significativas de información relacionada con los eventos interceptados.</div>
<h4>
Profilers estadísticos<o:p></o:p></h4>
<div class="MsoNormal" style="text-align: justify;">
Los profilers estadísticos por
otra parte funcionan recolectando muestras periódicas, es decir, interrumpiendo
la ejecución de la aplicación analizada y verificando la tarea realizada en el
momento de la interrupción. Típicamente
este tipo de profilers utilizan llamados a funciones del sistema operativo para
suspender los procesos y obtener el valor del program counter o puntero a
instrucción (EIP, RIP) periodicamente y realizar un recorrido llamado <b>stackwalk</b> en el que se identifican las
funciones en la pila de llamados a partir de la navegación entre cada uno de
los frames en la pila del hilo en ejecución.
Numéricamente los valores obtenidos con este tipo de herramientas son de
una precisión inferior a los obtenidos con los profilers basados en eventos y
esto se debe a que la información analizada corresponde únicamente a la
obtenida para los puntos de ejecución muestreados, sin embargo, una cualidad de
este tipo de herramientas radica en su bajo impacto en el rendimiento de la
aplicación, logrando que el programa objetivo funcione más cerca de su
velocidad real.</div>
<h4>
Profilers de instrumentación<o:p></o:p></h4>
<div class="MsoNormal" style="text-align: justify;">
Otro tipo de herramientas abordan
el problema de obtención de datos modificando la aplicación que se desea
analizar, al código agregado se le denomina <b>instrumentación</b> y dependiendo de los puntos instrumentados (por
ejemplo si decidiéramos instrumentar todo el código) dentro de la aplicación
puede suponer un gran impacto en el rendimiento de la aplicación medida. Para que las pruebas sean efectivas y
correctas este tipo de herramientas dependen en gran medida de lo específica
que sea la instrumentación realizada y no brindan gran flexibilidad sobre el
impacto en la aplicación.
Desafortunadamente para la identificación de problemas suele requerir
que se tenga una idea de los componentes implicados en la situación para poder
instrumentarlos, hecho que no siempre es evidente.</div>
<h4>
Salida de profilers<o:p></o:p></h4>
<br />
<div class="MsoNormal" style="text-align: justify;">
Según el tipo de salida generada
los profiler peden clasificarse en dos categorías, la primera corresponde a
aquellas herramientas que únicamente calculan el tiempo promedio por llamado
sin preocuparse de diferenciar entre el tiempo propio del método o función
involucrada y el tiempo consumido por los llamados a otros métodos por parte de
dicha función, a este tipo de herramientas se les conoce como profilers planos
o <b>flat profilers</b>. La segunda categoría está asociada con las
herramientas cuya salida contemplan en su análisis las diferentes rutas del
código y el contexto de la ejecución y pueden diferenciar entre el tiempo
própio consumido por una función del tiempo consumido por cada uno de sus
llamados, a estas herramientas se les conoce como profilers de gráfos de
llamadas y son más detallados y elaborados que los profilers planos.</div>
Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-41415882645526433912013-12-04T23:58:00.000-08:002016-08-07T22:31:10.148-07:00No olvides la escalabilidad<h2 style="margin-left: 13.6pt;">
<a href="https://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185051">¿Qué es escalabilidad?</a> <o:p></o:p></h2>
<div class="MsoNormal" style="text-align: justify;">
La escalabilidad se puede definir
informalmente como la posibilidad que posee un sistema para incrementar su
capacidad de atención a medida que el número de solicitudes o usuarios se
incrementa. Es en otras palabras la
forma en la cual un sistema puede adaptarse a los cambios potenciales en la
demanda sin perder calidad en el servicio prestado. De esta
manera, se debe considerar la escalabilidad al momento de adquirir y producir
aplicaciones informáticas, por ejemplo, suponga que usted administra una
universidad y para efectos administrativos se necesita un sitio web donde se
puedan publicar las notas de cada uno de los estudiantes, inicialmente la
institución educativa tendrá 1000 estudiantes y se adquiere un software capaz de manejar 500
usuarios por minuto, como todos los estudiantes no entran al mismo tiempo a
consultar sus notas, es probable que el sistema adquirido cumpla con la
capacidad, sin embargo a medida que la institución adquiere prestigio en su
entorno, el número de estudiantes se incrementa digamos que a unos 5000, es muy
probable que durante periodos de entregas de notas estos nuevos estudiantes
logren superar la capacidad permitida por la aplicación usada para la
administración. Una primera solución es encontrar otra aplicación que supla la
necesidad, sin embargo, si la tendencia en crecimiento se mantiene para el
siguiente año se tendrá nuevamente el mismo problema. Este sencillo ejemplo nos sugiere que las
aplicaciones deberían poder adaptarse a
los cambios en la demanda de los servicios prestados por las mismas, y este
tipo de situaciones son las que hacen necesario que las empresas productoras de
software deban evaluar lo que se define
como <b>escalabilidad</b> para cada una de
las aplicaciones que se producen de tal manera que siempre exista un mecanismo
claro que pueda ser utilizado para
aumentar su capacidad y conservar la calidad y los niveles de servicios adecuados para las operaciones realizadas. </div>
<div class="MsoNormal" style="text-align: justify;">
En la mayoría de las ocasiones
dicho mecanismo estará relacionado con agregar nuevo hardware a la
infraestructura de operación, por ejemplo agregando mas máquinas o mejor
hardware. Teniendo en cuenta que ambas
opciones pueden generar un incremento de la capacidad, la escalabilidad de
aplicaciones puede clasificarse a partir de las siguientes categorías.</div>
<h3>
<a href="https://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185052">Escalabilidad
Vertical</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
La escalabilidad vertical es la
manera de conseguir mayores niveles de atención incrementando las capacidades
de los recursos específicos consumidos por las aplicaciones, por ejemplo,
aumentando el tamaño de la memoria principal, el número de CPUs de una máquina,
el espacio en disco o agregando tarjetas
de red más potentes.</div>
<div class="MsoNormal" style="text-align: justify;">
Aunque es cierto que en primera
instancia esta puede ser una forma sencilla de aumentar la capacidad de los
servicios prestados por nuestras aplicaciones, el sentido común nos indica que
existe un límite asociado con el hardware que podemos actualizar, es decir, si
nuestras tendencias de crecimiento están acordes con la <b>ley de Moore</b>, no debería haber ningún problema, pues todos los años
contaríamos con componentes de hardware superiores a los del año anterior, pero ¿que ocurre si estamos creciendo por encima de la velocidad a la cual crece la capacidad
del nuevo hardware? Esta es una pregunta
que puede llegar a ser un poco molesta, porque plantea aspectos del diseño de
las aplicaciones que debieron ser considerados mucho antes de poder identificar
que este tipo de problemas se podrían presentar, dependeremos entonces de la
posibilidad de que nuestra aplicación pueda escalar horizontalmente.</div>
<h3>
<a href="https://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185053">Escalabilidad
Horizontal</a><o:p></o:p></h3>
<br />
<div class="MsoNormal" style="text-align: justify;">
Como se mencionó anteriormente la
escalabilidad vertical tiene un límite, y este se produce cuando ya no existe
el hardware que necesitamos para proveer con la misma calidad a nuestro
creciente número de usuarios dentro de la operación. Si pensamos en la escalabilidad vertical como
el hecho de aumentar el tamaño de un tanque de agua utilizado para suministrar
un fluido a una población, podríamos visualizar la escalabilidad horizontal
como el incremento del fluido suministrado agregando cada vez mas tanques de
manera tal que la escalabilidad horizontal nos proporcionará un mecanismo
repetible <b>indefinidamente</b> a medida
que el número de usuarios se incremente, logrando que la capacidad del sistema
se adapte cada vez a la nueva demanda.</div>
Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-6199094152125983312013-12-04T23:38:00.000-08:002013-12-04T23:46:22.663-08:00Metricas y valores esperados<h2 style="margin-left: 13.6pt;">
<a href="" name="_Toc368185045">Métricas y valores esperados</a><o:p></o:p></h2>
<h3>
<a href="" name="_Toc368185046">Qué es una
métrica y para qué sirve?</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
De manera sencilla una métrica se
puede definir como una medida o un conjunto de medidas que determinan una
característica de un sistema. Por
ejemplo, en un sistema de aprendizaje una métrica podría estar dada por el
número de estudiantes reprobados en un curso, este valor nos dará una idea de
una característica de nuestro sistema escolar por ejemplo para la metodología de los
docentes. Las métricas al igual que en
el resto de disciplinas, se utiliza en el software para cuantificar aspectos de
interés de modo que nos permita tener una visión clara y objetiva de lo que
estamos midiendo y establecer mecanismos para mejorar dicha
característica. En esta entrada nos
centraremos en las métricas de rendimiento de las aplicaciones, que como se espera
nos ayudarán identificar problemas de rendimiento y poder tomar acciones sobre
los mismos. Dentro de los beneficios de
proporciona la utilización de métricas en cualquier área del conocimiento y
consecuentemente en el software tenemos:<span style="font-size: 7pt; text-indent: -18pt;"> </span></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l5 level1 lfo1; text-align: justify; text-indent: -18.0pt;">
</div>
<ul>
<li><b style="text-indent: -18pt;">Análisis:</b><span style="text-indent: -18pt;">
Podremos analizar y comprender las capacidades del sistema en cuestión de
manera objetiva.</span></li>
</ul>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l5 level1 lfo1; text-align: justify; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Control:</b><span style="text-indent: -18pt;">
Se pretende poder realizar ajustes utilizando la información de dichas métricas
para mantener las características en los estados deseados.</span></li>
</ul>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l5 level1 lfo1; text-align: justify; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Predicción:</b><span style="text-indent: -18pt;">
Una vez se ha iniciado un estudio con el uso de métricas sobre una
característica de un sistema se hace más fácil predecir situaciones que de otra
manera serían imposibles de entender.</span></li>
</ul>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l5 level1 lfo1; text-align: justify; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Mejora:</b><span style="text-indent: -18pt;">
Las métricas nos proporcionan herramientas para mejorar las características que
cuantificamos. Si se manejan objetivamente,
mejorar una métrica en la mayoría de los casos es equivalente a mejorar
la característica en cuestión.</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto;">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto; text-align: justify;">
Es importante tener en cuenta que solamente aquellas
características que son susceptibles de ser medidas podrán manejarse utilizando
métricas, por suerte, en la evaluación del performance de las aplicaciones casi
todas las características se pueden medir. Aunque parezca extraña esta aclaración,
existen aspectos de la vida que no se pueden medir, como la moral , la
felicidad y muchos otros aspectos relacionados con cuestiones humanas, en
términos generales lo medible está asociado a unidades físicas, como tiempo,
espacio, memoria, etc. Las métricas están basadas
en <b>conceptos medibles</b> que son
relaciones abstractas entre las características de las entidades medidas.</div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto;">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto; text-align: justify;">
En la evaluación del software existen algunos objetos o
entidades de interés particular en el estudio del comportamiento de las
aplicaciones. A continuación presentamos
algunas:</div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto; text-align: justify;">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l4 level1 lfo2; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><span style="text-indent: -18pt;">Servicios</span></li>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><span style="text-indent: -18pt;">Productos</span></li>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><span style="text-indent: -18pt;">Procesos</span></li>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><span style="text-indent: -18pt;">Recursos</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto;">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto; text-align: justify;">
Las características o atributos según su cercanía con los
usuarios pueden ser internos o externos, dependiendo de si los usuarios son
conscientes de la existencia de la característica. Dentro de las características que nos
interesan medir para el performance de aplicaciones encontramos dos que suelen ser importantes.</div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto;">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l1 level1 lfo3; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><span style="text-indent: -18pt;">Comportamiento en el tiempo</span></li>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><span style="text-indent: -18pt;">Utilización de recursos</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto;">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto; text-align: justify;">
Usualmente el comportamiento en el tiempo es afectado por
la utilización de los recursos y los recursos son retenidos por problemas de
lógica con un rendimiento pobre. Por
ejemplo si una aplicación web utiliza una base de datos y la aplicación tiene
problemas de desempeño, dicha aplicación podría provocar bloqueos en los
recursos de la base de datos, de la misma manera si los recursos no fueran
suficientes en el servidor de bases de datos se podrían presentar pérdidas de
rendimiento en la aplicación web que la usa.
Casi todas las métricas de performance están asociadas a cuantificar
aspectos que se relacionan con el tiempo o con los recursos. </div>
<div class="MsoListParagraphCxSpMiddle" style="margin-left: 0cm; mso-add-space: auto;">
<br /></div>
<div class="MsoListParagraphCxSpLast" style="margin-left: 0cm; mso-add-space: auto; text-align: justify;">
Una métrica consta de un método de medición por ejemplo una
formula y una escala para los valores obtenidos a partir de dicho método. Las métricas pueden ser <b>directas</b> si solo dependen de la característica o atributo que se
está midiendo o <b>indirectas</b> si
dependen adicionalmente de otras métricas y se formalizan a partir de una
función de medición.</div>
<div class="MsoListParagraphCxSpLast" style="margin-left: 0cm; mso-add-space: auto; text-align: justify;">
<br /></div>
<div class="MsoNormal" style="text-align: justify;">
Las métricas de rendimiento por lo general son
independientes de los escenarios, de las plataformas, del hardware y de la
lógica de negocio que se esté probando.</div>
<h3>
<a href="" name="_Toc368185047">Categorización
de métricas</a><o:p></o:p></h3>
<h4>
Según la cercanía con el usuario<o:p></o:p></h4>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l2 level1 lfo7; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Internas:</b><span style="text-indent: -18pt;">
La característica que evalúa la métrica depende únicamente de factores internos
del diseño y los usuarios no tienen consciencia de su existencia.</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle">
<br /></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l2 level1 lfo7; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Externas:</b><span style="text-indent: -18pt;">
Los Usuarios son conscientes o tienen un contacto directo con la
característica que evalúa la métrica en cuestión y sus valores pueden depender
de aspectos específicos de la lógica de negocio de la aplicación.</span></li>
</ul>
<!--[if !supportLists]--><br />
<h4>
Según sus valores deseables<o:p></o:p></h4>
<div class="MsoNormal">
Las métricas de performance según los valores deseados se
pueden categorizar en tres tipos:<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l6 level1 lfo4; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Deseablemente
decrecientes: </b><span style="text-indent: -18pt;">Este tipo de métricas son aquellas en las cuales esperamos
que un mejor comportamiento de la característica que pretende medir en el sistema
esté asociado con la disminución del valor de dicha métrica, es decir, mientras
menor sea el valor será mejor. Un
ejemplo de esta categoría es el tiempo de respuesta de una aplicación, se
espera que mejoras en el rendimiento se reflejen en la disminución de los
valores de dicha métrica.</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l6 level1 lfo4; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Deseablemente
crecientes:</b><span style="text-indent: -18pt;"> A diferencia de la categoría
anterior, a este conjunto de métricas pertenecen aquellas en las que un
incremento de los valores obtenidos se asocia con una mejora en el rendimiento
de la aplicación. Como ejemplo podemos
ver el throughput o la productividad del sistema mientras mayor sea su valor
mayor mejor será el rendimiento del sistema.</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle">
<br /></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l6 level1 lfo4; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Valores
nominales deseables:</b><span style="text-indent: -18pt;"> En ocasiones existen características de nuestras
aplicaciones cuyos indicadores o métricas asociadas no convienen que sean
demasiado bajas o demasiado altas sino que se encuentren en lo que llamamos un
valor nominal, el cual es el valor óptimo o deseado para la característica
analizada. Un ejemplo de este tipo de
métricas es la utilización de la CPU, si el valor es muy bajo para un gran volumen
de transacciones, puede deberse a problemas de rendimiento de la aplicación en
cuestión desperdiciando el recurso específico y si el uso de CPU es muy alto, la aplicación podría estar impactando
otros aspectos del servidor como la estabilidad del propio sistema operativo
haciendo que todo fluya de manera más lenta y riesgosa. Podríamos decidir de manera arbitraria que el
valor nominal fuera un 50%.</span></li>
</ul>
<!--[if !supportLists]--><br />
<h4>
Según el marco de referencia<o:p></o:p></h4>
<div class="MsoNormal">
Dependiendo de si una característica se evalúa en un solo
contexto o si existen valores de referencia con los cuales se contrastan las
mediciones, las métricas se pueden clasificar en las siguientes categorías:</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo5; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Absolutas:</b><span style="text-indent: -18pt;">
Son aquellas métricas que dependen únicamente de mediciones realizadas en la
aplicación que se está midiendo, por lo cual únicamente reflejan el comportamiento
de la característica evaluada de manera individual o aislada. Un ejemplo de
este tipo de métricas sería el tiempo de respuesta de un método en una clase.</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle">
<br /></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l0 level1 lfo5; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">Relativas:</b><span style="text-indent: -18pt;">
Las métricas pertenecientes a este grupo definen el comportamiento de la
característica evaluada en relación a un comportamiento </span><b style="text-indent: -18pt;">base</b><span style="text-indent: -18pt;"> que en muchos casos corresponde a una segunda aplicación de
referencia, por ejemplo, la diferencia entre los tiempos de respuesta de dos
aplicaciones. Las métricas pueden ser
relativas a otras métricas o a valores nominales.</span></li>
</ul>
<!--[if !supportLists]--><br />
<h4>
Según la naturaleza de la medición<o:p></o:p></h4>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l3 level1 lfo6; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">De recursos:</b><span style="text-indent: -18pt;">
La característica medida se relacionada con recursos del sistema, por ejemplo,
el número de escrituras en disco debido a un evento dado.</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l3 level1 lfo6; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">De tiempo:</b><span style="text-indent: -18pt;">
La característica evaluada es una duración o un valora asociado al tiempo como
el periodo o la frecuencia de un evento.</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle">
<br /></div>
<div class="MsoListParagraphCxSpMiddle" style="mso-list: l3 level1 lfo6; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">De
complejidad:</b><span style="text-indent: -18pt;"> Este tipo de métricas pretende cuantificar la complejidad
computacional del sistema, por ejemplo, para el número de ciclos en el código para
una operación particular. Aunque puede
que estas no midan directamente temas de desempeño, puede que perdidas en el
desempeño estén relacionadas directas o indirectamente con los aspectos medidos
por las mismas.</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoListParagraphCxSpMiddle">
<br /></div>
<br />
<div class="MsoListParagraphCxSpLast" style="mso-list: l3 level1 lfo6; text-indent: -18.0pt;">
</div>
<ul>
<li><span style="font-family: Symbol; text-indent: -18pt;"><span style="font-family: 'Times New Roman'; font-size: 7pt;"> </span></span><b style="text-indent: -18pt;">De
calidad:</b><span style="text-indent: -18pt;"> Encontramos en algunas ocasiones métricas que no miden ni
recursos, ni tiempos, ni temas de complejidad, sin embargo, el mejoramiento de
las mismas puede representar un mejoramiento en el rendimiento del sistema. Un
ejemplo podría ser la tendencia en un comportamiento de la aplicación como la
estabilidad o cualquier aspecto del diseño.</span></li>
</ul>
<!--[if !supportLists]-->Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-74170505917866880792013-11-30T21:13:00.001-08:002013-11-30T21:16:01.438-08:00Pruebas de performance<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185153">¿Qué son las
pruebas de rendimiento?</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
De manera sencilla podemos
definir las pruebas de rendimiento como un conjunto de pruebas que son
realizadas a una aplicación para determinar el comportamiento del performance
de la misma, identificar puntos potenciales de mejora o garantizar los niveles
de servicios esperados por los clientes del sistema. Actualmente este tipo de pruebas son
realizadas en la mayoría de los proyectos de tecnología únicamente a aquellas
aplicaciones de ejecución crítica que puedan afectar la operación del negocio,
aunque cada vez más se evidencia la necesidad de realizar este tipo de pruebas para
los diferentes aspectos del código producido y consecuentemente los proyectos
de tecnología hacen cada vez un mayor uso de pruebas de stress y de carga en un
mayor número de compontes de sus sistemas.
</div>
<div class="MsoNormal" style="text-align: justify;">
Cabe recordar que las pruebas de
rendimiento pueden realizarse en diferentes niveles del desarrollo, pueden
planearse y ejecutarse mucho antes de que se haya finalizado el desarrollo en
su totalidad, por ejemplo, podríamos realizar pruebas de rendimiento a cada uno
de los componentes que integran el desarrollo en conjunto con las pruebas
unitarias de los mismos y a medida que se vayan integrando podríamos realizar
otras pruebas de integración entre componentes que aseguren que no existan
problemas de rendimiento en la forma en la cual interactúan a partir del diseño
del sistema. Realizar pruebas de
rendimiento de manera temprana es una buena forma de establecer garantías
parciales en el mediano plazo que nos permitan avanzar hacia los objetivos de
performance definidos con una incertidumbre menor.</div>
<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185154">¿Por qué son
necesarias?</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
<span style="background: white; color: #6b7074; font-family: "Arial","sans-serif"; line-height: 115%; mso-bidi-font-size: 10.0pt;">Podría pensarse que las pruebas de rendimiento pueden ser
ejecutadas de manera posterior al despliegue de nuestras aplicaciones, sin
embargo, debemos tener claro que las pruebas de rendimiento tienen como
objetivo fundamental anticipar los problemas de performance que puedan ocurrir
una vez la aplicación esté en producción. Una vez que se haya llevado a cabo la entrega
de un desarrollo, será mucho más difícil encontrar formas de sobrellevar
problemas de desempeño detectados en la operación ya que en esta etapa
contaremos con un menor control sobre las características que podremos cambiar
para cumplir los nuevos objetivos.<o:p></o:p></span></div>
<div class="MsoNormal" style="text-align: justify;">
Las pruebas de rendimiento
adicionalmente nos ayudan a visualizar tiempos muertos de las aplicaciones que
de otra manera no hubieran podido detectarse, redundando en un mayor
conocimiento las tareas que consumen mayor tiempo, de los límites del código
producido y adicionalmente en la identificación de los puntos más frágiles de
la aplicación. Cada uno de estos
aspectos es de vital importancia si deseamos descubrir mejores formas de
realizar las operaciones pertinentes. <span style="background: white; color: #6b7074; font-family: "Arial","sans-serif"; line-height: 115%; mso-bidi-font-size: 10.0pt;"><o:p></o:p></span></div>
<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185155"><span style="background: white; mso-ansi-language: ES-CO;">¿Cómo pueden ayudarnos?</span></a><span style="background: white; mso-ansi-language: ES-CO;"><o:p></o:p></span></h3>
<div class="MsoNormal" style="text-align: justify;">
Las pruebas de rendimiento pueden
hacernos la vida más fácil o más difícil dependiendo de la forma en la que se
gestione la ejecución de dichas pruebas, si no se tienen claros temas del
proyecto relacionados con costos, tiempos de entrega y parámetros específicos
de las pruebas realizadas podemos entrar en un ciclo infinito de pruebas
rechazadas. </div>
<div class="MsoNormal" style="text-align: justify;">
Es importante entender los
conceptos o las características que se están midiendo y como se alinearán
dichas mediciones con los objetivos del proyecto antes de iniciar un plan de
pruebas que probablemente arrojen resultados de poco valor que no nos permitan
mejorar nuestros productos. </div>
<div class="MsoNormal" style="text-align: justify;">
Otra forma en la que las pruebas
de performance pueden ayudarnos está relacionada con la capacidad de predecir
comportamientos a partir de los volúmenes de datos u operaciones de manera tal
que podamos ser capaces de entregar guidelines o documentación clara sobre el
rendimiento que debe ser esperado por parte de los usuarios del sistema, por
ejemplo, si hemos construido una aplicación para construir pantallas de captura
de datos en la web y entregamos una documentación que establezca que el tiempo
promedio de procesamiento para un control en una página tiene un tiempo
promedio de 1 ms bajo ciertas condiciones, con seguridad podremos establecer
los requisitos de hardware mínimos para que dicha premisa se cumpla y
adicionalmente podremos evitar mediante políticas de desarrollo que los
usuarios del sistema intenten construir páginas con 3000 controles que
demorarían en promedio 3 segundos en cargar lo que podría ocasionar otro tipo
de problemas en el desempeño general de la aplicación.</div>
<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185156">Etapas
generales de una prueba</a> <o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
Una prueba de rendimiento por lo
general se encuentra divida en tres fases.
A continuación se presenta una breve descripción de cada una de ellas.</div>
<div class="MsoNormal" style="text-align: justify;">
<b>Construcción:</b> En esta etapa de la prueba se identifican los casos
que serán susceptibles de ser probados, se define la manera en la cual se
realizará la prueba y se construyen scripts o artefactos que permitirán su
ejecución. </div>
<div class="MsoNormal" style="text-align: justify;">
<b>Ejecución:</b> El objetivo en
esta fase es el de utilizar los artefactos construidos para la ejecución de la
prueba con el fin de obtener información sobre las métricas, los casos y/o
características definidas durante la construcción.</div>
<div class="MsoNormal" style="text-align: justify;">
<b>Análisis:</b> Una vez que se haya recolectado la información que se ha
obtenido durante las ejecuciones de las pruebas de rendimiento se deberá
proceder a analizar la información según para poder tomar acciones los
resultados encontrados.</div>
<div class="MsoNormal" style="text-align: justify;">
A pesar de que puede parecer
sencillo, la obtención de los datos de una prueba con un nivel de confianza
relativamente bueno puede suponer algunos retos a la hora de poner en marcha el
plan. Temas como el aislamiento de los
ambientes, el estados de los recursos, temas de configuración de la aplicación
y los errores humanos pueden repercutir en la invalidez de las pruebas
realizadas, derivando en la necesidad de repetir la prueba una y otra vez hasta
que se logue la confianza suficiente en los datos y los procedimientos
utilizados.</div>
<span style="color: #595959; font-family: "Segoe UI","sans-serif"; font-size: 10.0pt; line-height: 115%; mso-ansi-language: ES-CO; mso-bidi-font-family: "Times New Roman"; mso-bidi-font-size: 11.0pt; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin;"><br clear="all" style="mso-special-character: line-break; page-break-before: always;" />
</span>
<br />
<div class="MsoNormal">
<br /></div>
<h2 style="margin-left: 13.6pt;">
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185157">Validez de pruebas</a><o:p></o:p></h2>
<div class="MsoNormal" style="text-align: justify;">
Como se mencionó anteriormente
las pruebas pueden invalidarse por un gran número de razones de diferente
naturaleza, por esta razón sería una buena idea tener claros los escenarios más
comunes que puedan presentarse para que una prueba pierda su validez. En esta sección presentaremos algunos de
estos escenarios e intentaremos detallar ejemplos asociados con los mismos. </div>
<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185158">Aislamiento
del ambiente de pruebas</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
Un caso común en las áreas de
tecnología de las empresas hoy en día corresponde al reúso de recursos para los
ambientes de IT, ser reutiliza la infraestructura con el objetivo de reducir
costos, por esta razón, encontramos ambientes virtualizados que comparten
hardware entre sí con el fin de optimizar las operaciones, estas situaciones
pueden representar un riesgo al momento de realizar pruebas de rendimiento, ya
que si el ambiente que ha sido destinado para pruebas también se utiliza en
otro tipo de tareas como por ejemplo como ambiente de desarrollo, los
resultados de nuestras pruebas podrían no ser del todo confiables. </div>
<div class="MsoNormal" style="text-align: justify;">
Teniendo como base el
planteamiento anterior podemos inferir que para que la validez de nuestras
pruebas no se vean afectadas por operaciones sobre el ambiente externas a los
escenarios probados es fundamental que el ambiente de pruebas esté físicamente
aislado de otros ambientes. Esto no
quiere decir que el ambiente deba estar totalmente desconectado, por ejemplo,
de la red de nuestra compañía o que deba ser privado de cualquier servicio de
comunicación con otros elementos de la infraestructura, lo que realmente nos
dice es que los recursos destinados para pruebas deben estar lo suficientemente
disponibles para garantizar que la aplicación probada no presentará pérdidas de
rendimiento debido a elementos externos a la misma prueba y a las condiciones
naturales de la plataforma sobre la que opera.
</div>
<h3>
<o:p> </o:p></h3>
<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185159">Disponibilidad
de recursos suficientes</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
Aún cuando el ambiente se
encuentre físicamente aislado durante la realización de las pruebas de
rendimiento, es posible que existan elementos locales dentro de las máquinas
utilizadas, por ejemplo, componentes ajenos a la prueba que puedan consumir
intensivamente recursos computacionales como podrían ser instalaciones
imprevistas de aplicativos, ejecución de análisis de antivirus o condiciones
específicas del sistema operativo pueden provocar una disminución en los
tiempos obtenidos en la prueba de manera, hecho que podría confundirse con
mejoras o disminución del rendimiento al ser comparados con pruebas que hayan
sido realizadas en ausencia de la ejecución de dichos componentes. Entonces podemos decir que se debe verificar
que los recursos locales no están siendo afectados de manera intensiva por
aplicaciones externas a la prueba. De
igual manera otras tareas en ejecución como la descarga de grandes volúmenes de
información de internet durante el tiempo de la prueba puede afectar recursos utilizados por la aplicación probada
como el acceso a la red.</div>
<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185160">Invariabilidad
del hardware y software</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
Una vez que se ha garantizado que
las condiciones físicas y locales del ambiente de pruebas se perciben como
estables podemos comenzar a realizar nuestras pruebas, pero en caso de utilizar
diferentes ambientes para realizar las mismas debemos garantizar que las
mediciones de tiempos se realicen utilizando recursos de hardware equivalentes,
es decir, asegurar que a pesar de que las pruebas se hayan realizado en
diferentes máquinas, las especificaciones del hardware utilizado sean
exactamente iguales o muy similares, en caso de ser diferentes las pruebas son incomparables a
menos que los resultados de las pruebas se evalúen en términos relativos, como
porcentaje del tiempo consumido. </div>
<div class="MsoNormal" style="text-align: justify;">
Si una aplicación se prueba dos
veces en ambientes con especificaciones de software diferentes, como por
ejemplo, máquinas con sistemas operativos diferentes o con diferencias en
parches instalados del sistema, es posible que las operaciones realizadas en
ambas pruebas no se realicen de la misma manera, por lo cual nuevamente las
pruebas no son comparables entre sí. Lo más
cómodo en términos generales al momento de ejecutar un conjunto de pruebas es
seleccionar un único ambiente, aislado y controlado para ejecutar todas las
pruebas pertinentes, de esta manera no deberemos preocuparnos por las
diferencias de hardware o software pues el ambiente será igual para todas las
muestras recolectadas haciendo que los resultados entre pruebas puedan se
comparables entre si y tengamos una mayor confianza en los datos obtenidos.</div>
<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185161">Representatividad
del tamaño de muestras</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
Aún cuando el ambiente esté
aislado, las condiciones locales del sistema sean uniformes y no existan
diferencias de hardware o software entre las pruebas realizadas, debemos
entender que el estado de las máquinas en la que se hospedan nuestras
aplicaciones está sujeto a variaciones no predecibles, como por ejemplo el uso
de la memoria virtual, caídas repentinas de la disponibilidad de ciertos
servicios como la red o tecnologías asociadas con la reducción del consumo
energético de los equipos y procesadores.
</div>
<div class="MsoNormal" style="text-align: justify;">
Por el motivo anteriormente
expresado, es necesario tener un tamaño de muestreo representativo, con el fin
de descartar los casos atípicos y poder establecer un comportamiento promedio o
general de las características que deseamos cuantificar. Mientras mayor sea el número de muestras
recolectadas tendremos una visión más completa del comportamiento medido. Determinar el número de pruebas a realizar
para obtener un nivel de confianza aceptable puede llevarnos a un análisis más
formal y estadístico, aunque usualmente este tipo de métodos no son utilizados
con frecuencia por lo que se trata de realizar las pruebas con el mayor número
posible de iteraciones o usuarios, por ejemplo por encima del número promedio
real. Tener un número muy bajo de
pruebas puede invalidar los resultados obtenidos a partir de las mismas.</div>
<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185162">Repetitividad
o repetibilidad de Casos</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
Otro factor que suele ser
determinante para identificar la validez de una prueba puede estar relacionado
con la capacidad que tiene la prueba de ser "repetible", para exponer
la importancia de este concepto, plantearemos un escenario en el cual una
aplicaciones realiza un conjunto de tareas diferentes de manera aleatoria, si
realizamos las pruebas de dicha aplicación ¿cómo podemos asegurar que todas las
pruebas miden los mismos aspectos?, de hecho, no lo hacen, por lo que se
evidencia la necesidad de que los casos probados sean perfectamente
reproducibles de modo que podamos establecer comparaciones sobre los resultados
obtenidos. En algunas ocasiones la
repetibilidad puede estar asociada a los diferentes caminos lógicos que una
aplicación puede tomar durante su ejecución y en otras ocasiones dichos cambios
dependerán de los datos suministrados como entrada de los algoritmos
implementados. </div>
<div class="MsoNormal" style="text-align: justify;">
Algunas veces es casi imposible
lograr que el número de llamados a todas las funciones sean exactamente igual
entre pruebas, sobre todo si lo que intentamos comparar está relacionado con mejoras
debido a modificaciones sobre los algoritmos codificados. En estos casos es posible realizar las
comparaciones normalizando los datos, por ejemplo si una aplicación ejecutó diez veces el
método A() en la prueba 1 y 30 veces el mismo método en la prueba 2 podremos
comparar los resultados dividiendo el tiempo T1(A) entre 10 lo que nos dará el
tiempo promedio de A durante la prueba 1 y podemos hacer lo mismo para la
prueba número 2 obteniendo el tiempo promedio de A durante la prueba 2 al
restar T2(A) - T1(A) podremos establecer la diferencia entre los tiempos promedio
aún cuando las dos pruebas no coincidan en el número de llamados. </div>
<div class="MsoNormal" style="text-align: justify;">
Analizar tiempos de
funcionalidades entre pruebas con diferente número de llamados y sin normalizar
los tiempos puede ser un factor para invalidar las conclusiones obtenidas en
las pruebas realizadas.</div>
<h3>
<a href="http://www.blogger.com/blogger.g?blogID=164232720903282505" name="_Toc368185163">Confiabilidad
de herramientas y mediciones</a><o:p></o:p></h3>
<br />
<div class="MsoNormal" style="text-align: justify;">
Bueno, como último aspecto a
considerar para evitar que nuestra prueba sea confiable tenemos la
confiabilidad de las herramientas que son utilizadas para realizar las
mediciones de las características que deseamos evaluar. Obtener datos a partir de herramientas que puedan
retrasar en demasía los tiempos de la aplicación a probar puede llevarnos a
conclusiones erróneas sobre el comportamiento de la misma. En los posible las herramientas utilizadas
deben estar certificadas o ser reconocidas como herramientas que arrojan
resultados confiables y que tienen el menor efecto posible en la prueba.</div>
Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-60614004936474470302013-11-30T20:57:00.000-08:002013-11-30T20:57:12.314-08:00Performance de Aplicaciones<h2 style="margin-left: 13.6pt;">
<a href="" name="_Toc368185024">Generalidades del performance</a><o:p></o:p></h2>
<div class="MsoNormal" style="text-align: justify;">
Día a día se escuchan en las
áreas de tecnología de las grandes empresas frases que asociamos con el
rendimiento de las aplicaciones, en algunos casos por ejemplo escuchamos que el
performance de cierta característica de nuestra aplicación es bueno o malo, de
igual manera relacionamos términos como "cuellos de botella" ,
"contención" y "throughput" con temas de rendimiento de
aplicaciones, sin embargo, cuando nos detenemos a pensar sobre lo que significa
el performance de aplicaciones solemos
no tener una idea clara sobre lo que realmente significa y esta será la
pregunta que nos ocupará durante la lectura de este capítulo.</div>
<h3>
<a href="" name="_Toc368185025">¿Qué es el
performance de aplicaciones?</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
En primera instancia podemos
definir el performance desde el punto de vista del usuario como la capacidad
que tiene una aplicación de realizar las operaciones que le competen cumpliendo
a cabalidad con las expectativas de procesamiento de los usuarios. Teniendo en cuenta esta primera aproximación se
evidencia que el buen o mal rendimiento por parte de una aplicación será una
categorización subjetiva dependiendo de los requerimientos técnicos esperados
por parte de los usuarios, llevándonos a concluir que lo que para un usuario es
un rendimiento aceptable para un sitio web para otro puede no serlo,
normalmente la percepción del rendimiento está asociada al volumen de operaciones
y datos que dicho usuario opera y dicha percepción irá cambiando a medida que
los volúmenes de información y cálculos se van incrementando en el tiempo. </div>
<div class="MsoNormal" style="text-align: justify;">
De lo anterior se puede intuir
que nuestras expectativas a la hora de diseñar y construir una aplicación
determinan en cierta medida el resultado que se obtendrá en términos de
desempeño, sin embargo, podemos observar que el hecho de que los volúmenes de
información manejados por dos aplicaciones distintas sean similares no quiere
decir que el rendimiento de ambas aplicaciones sea igual, aunque al usuario
pueda percibirlas por igual en producción, aún mas, que el performance de una
aplicación se perciba como bueno no implica que la manera en la que dicho
software realiza sus operaciones sea la óptima.
Teniendo en cuenta este segundo punto tendremos que buscar definir el
rendimiento de una manera más objetiva de modo tal que frente a dos
aplicaciones se pueda establecer cual cuenta con el mejor rendimiento. </div>
<h3>
<a href="" name="_Toc368185026">Subjetividad
y objetividad de los datos</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
La manera más sensata de
conseguir una aproximación objetiva podría ser establecer métricas que se
encuentren directamente relacionadas con las expectativas de un único usuario
de referencia, por ejemplo, para un usuario gerente de un banco y para una
aplicación web de su intranet una buena métrica podría ser el número de
créditos que pueden ser ingresados al sistema durante una hora, para un usuario
en una planta de producción una buena métrica podría estar relacionada con el
número de piezas revisadas por minuto.
Estas métricas que se han definido podrían diferenciar claramente las características
de rendimiento entre dos aplicaciones de funcionalidades similares, sin embargo
para poder establecer un criterio de evaluación realmente objetivo que nos
permita determinar las características y límites de performance de las aplicaciones,
dicho criterio deberá abstraerse de las condiciones y las expectativas del
negocio, llevándonos a clasificar las métricas para la evaluación del desempeño
en dos categorías, la primera de ellas serían las métricas de negocio y las segunda
categoría estaría dada por las métricas de técnicas ambas relacionadas con el
performance. </div>
<div class="MsoNormal" style="text-align: justify;">
Una combinación efectiva de ambos
tipos de métricas nos ayudarán a evaluar las condiciones de rendimiento de
manera objetiva sin alejarnos de los objetivos de negocio que perseguimos con
la implantación de nuestra solución en la organización. </div>
<div class="MsoNormal" style="text-align: justify;">
Todo esto está muy bien, pero ¿Qué
tipo de métricas técnicas nos permiten evaluar el desempeño de nuestras
aplicaciones de manera objetiva? bueno, las métricas indicadas estarán
relacionadas con las operaciones (computacionalmente hablando) que realice la
aplicación en cuestión. Para una
aplicación web es muy probable que el número de solicitudes procesadas por
segundo sea una buena medida de cuanto es capaz de hacer dicha aplicación. </div>
<div class="MsoNormal" style="text-align: justify;">
En términos generales podríamos
decir que el rendimiento general de una aplicación será mejor mientras más operaciones
por unidad de tiempo realice, sin embargo, aunque pareciera que esta métrica
únicamente dependiera de el número de operaciones procesadas por nuestro
software y del tiempo, la realidad es
que otros aspectos como el la cantidad de recursos que son consumidos por el
sistema pueden hacer que el número de operaciones por segundo disminuya
sustancialmente razón por la cual nos interesará establecer métricas
relacionadas con el consumo de recursos como memoria, cpu, red.</div>
<div class="MsoNormal" style="text-align: justify;">
El performance de las aplicaciones
por tanto puede concebirse como el
conjunto de valores asociados con métricas claramente definidas que determinan
la capacidad de procesamiento del sistema computacional en cuestión así como su
calidad y el análisis de performance podría verse como el conjunto de las
técnicas y herramientas orientadas al estudio del mejoramiento de los valores
para cada una de dichas métricas.</div>
<h2 style="margin-left: 13.6pt;">
<a href="" name="_Toc368185027">Importancia del performance</a><o:p></o:p></h2>
<div class="MsoNormal" style="text-align: justify;">
Como se ha mencionado en el
capitulo anterior, el performance de las aplicaciones que construimos es una
parte importante dentro de los objetivos de negocio de una organización, temas
como la ejecución de las operaciones críticas de una empresa pueden estar
siendo afectadas por pérdidas en el
rendimiento de los sistemas de información utilizados para gestionar dichas
operaciones y estos temas de negocio son en general los que deben motivarnos a
realizar planes para el mejoramiento del desempeño. La importancia de obtener aplicaciones con un
buen performance se visualiza de manera más evidente cuando se contemplan los
riesgos asociados, es decir, los problemas potenciales que pueden provocarse
por no tener en cuenta el desempeño de los sistemas construidos. A continuación se presentan algunos de los
riesgos que pueden generar este tipo de problemas.</div>
<h3>
<a href="" name="_Toc368185028">Daños en las
relaciones con los clientes</a> <o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
La manera más obvia en la que nos
afecta un bajo desempeño del software está ligada con la disminución en la capacidad
que posee una organización para proveer sus productos o servicios a los
clientes, una disminución en los niveles de servicio, tiempos de entrega o
productos fabricados puede afectar la imagen de la organización de manera tal
que los consumidores asocien una empresa con un mal manejo de la actividad
comercial a la que se dedica, los daños en la imagen pueden tomar mucho tiempo
en repararse y comúnmente reparar las causas de los daños no mejora
inmediatamente la percepción de los consumidores. Para el caso específico del
software como producto, una aplicación que ha sido identificada como de bajo
rendimiento hará que los usuarios antiguos dejen de utilizarla y probablemente
desviará el mercado potencial hacia otras alternativas equivalentes, es decir, nuestra competencia.</div>
<h3>
<a href="" name="_Toc368185029">Efectos en la
comunicación</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
En el mundo de las arquitecturas
empresariales de hoy, las aplicaciones suelen estar conectadas entre sí
ejecutando sus tareas de manera colaborativa y coordinada, de esta manera la
velocidad del sistema general puede comenzar a presentar una disminución en las
operaciones realizadas debido al bajo rendimiento de una de muchas aplicaciones
dentro del ecosistema. Este tipo de
situaciones, por lo general terminarán afectando los tiempos de respuesta de
algunos servicios de la organización y a todas sus dependencias, haciendo más difícil
el cálculo de la pérdida y multiplicando la misma.</div>
<h3>
<a href="" name="_Toc368185030">Pérdidas de
dinero</a> <o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
Los problemas relacionados con la
capacidad en la operación de una organización no solamente afectan la imagen y
la confianza de nuestros consumidores en la calidad de los productos, en
ocasiones, los retrasos producidos en las entregas o transacciones en general
pueden desencadenar pérdidas significativas de dinero para las empresas ya sea
por el pago de multas, clausulas de incumplimiento, por reprocesamiento
innecesario de trámites o por términos pactados con anterioridad en las
contrataciones relacionados con los niveles de servicio. A veces, los ingresos de la organización puede
estar relacionado de manera directa con el volumen de información que es capaz
de procesar un sistema de información específico.</div>
<h3>
<a href="" name="_Toc368185031">Perdida de la
competitividad</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
Sumado a los problemas anteriormente
descritos, es probable que se comience a tener problemas de velocidad respecto
a nuestros competidores y a la oferta de los productos o servicios en el
mercado.</div>
<span style="color: #595959; font-family: "Segoe UI","sans-serif"; font-size: 10.0pt; line-height: 115%; mso-ansi-language: ES-CO; mso-bidi-font-family: "Times New Roman"; mso-bidi-font-size: 11.0pt; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin;"><br clear="all" style="mso-special-character: line-break; page-break-before: always;" />
</span>
<br />
<div class="MsoNormal">
<br /></div>
<h2 style="margin-left: 13.6pt;">
<a href="" name="_Toc368185032">Performance como estrategia de mercadeo</a><o:p></o:p></h2>
<div class="MsoNormal" style="text-align: justify;">
Cualquier producto o servicio que
se esté presente en el mercado es susceptible de tener competencia y como es
algo natural los productos y servicios relacionados con el software no son la
excepción. Aún cuando nuestros productos
sean lo suficientemente innovadores y novedosos como para que no exista competidor
alguno, la posibilidad de competencia siempre está presente cada vez que se
abre un nuevo nicho en el mercado y si queremos conservar nuestra ventaja
competitiva tendremos que mejorar permanentemente las características de dichos
productos de manera que satisfagan las necesidades de nuestros
consumidores. El rendimiento de nuestras
aplicaciones no está exento de esta problemática de manera tal que en ocasiones
las evaluaciones de desempeño nos proporcionan herramientas para presentar a
nuestros consumidores la eficiencia con la que nuestro software realiza las
operaciones esperadas. </div>
<div class="MsoNormal" style="text-align: justify;">
Debemos tener en cuenta que los
usuarios de las aplicaciones persiguen un objetivo claro y es el de poder hacer
más en el menor tiempo posible y el hacer más estará directamente relacionado
con dos características principales del producto. En primera instancia tenemos la cantidad de
operaciones de negocio que podemos procesar, la cual se relaciona directamente
con el rendimiento de las aplicaciones, el segundo aspecto en el cual pueden
estar interesados nuestros clientes, está relacionado con la capacidad que
brinde nuestros sistemas para poder crecer el volumen de las operaciones a
medida que los negocios crecen, este aspecto claramente se relaciona con la
escalabilidad del sistema. En esta
sección se discutirán algunos temas sobre como exponer a nuestros usuarios las
ventajas de rendimiento y escalabilidad de nuestras aplicaciones.</div>
<h3>
<a href="" name="_Toc368185033">Hablar un
mismo idioma</a><o:p></o:p></h3>
<div class="MsoNormal" style="text-align: justify;">
Cuando intentamos presentar la
eficiencia de nuestros productos, como ya hemos dicho anteriormente debemos
tener en cuenta que a los consumidores de nuestras aplicaciones no les interesa
saber cuántos bytes por segundo, accesos a bases de datos o transacciones pueden
realizar nuestros programas de computadora,
se debe tratar de expresar las características de performance en
términos de beneficios para la operación del negocio si realmente deseamos
diferenciarnos, por ejemplo, si nuestra aplicación web puede procesar un
promedio de 100 solicitudes por segundo podremos presentar esta información en
términos de el número de aprobaciones para créditos que se pueden realizar al
día en nuestro sistema de información, de esta manera tendrá más valor para el
usuario saber que en un día laboral podrá procesar 2'880.000 de créditos que
saber el número de consultas a la base de datos. De esta manera se debe hablar en el idioma
del negocio y no en términos técnicos que puedan confundir o ahuyentar a
quienes serán los usuarios del sistema ofertado.</div>
<h3>
<a href="" name="_Toc368185034">Performance como
factor diferenciador</a><o:p></o:p></h3>
<br />
<div class="MsoNormal" style="text-align: justify;">
Algunas veces las empresas
productoras de software liberan distintas versiones de sus productos con el
objetivo de generar popularidad o recordación entre los usuarios potenciales,
de esta manera, encontramos versiones de evaluación y algunas con limitaciones
respecto a sus funcionalidades. Nuevamente
trabajar en el performance y en la escalabilidad de nuestras aplicaciones nos
dará herramientas para convencer y conectarnos con aquellos usuarios que han
estado atentos a las versiones limitadas y que están buscando poder obtener el
mayor rendimiento posible para su operación, es una forma de plantear que si
está contento con las limitantes, ¿podría imaginar lo que haría funcionando al
máximo de capacidad? Este concepto
utiliza el performance como un factor diferenciador entre lo que ofrecemos como
muestra y lo que ofrecemos como producto.
Algunas veces las diferencias están asociadas a limitaciones en el uso,
por ejemplo, un sistema cuya versión gratuita se distribuye con una limitante
en el número de usuarios que pueden operar en ella, atrayendo a usuarios con
mayores necesidades a utilizar la versión paga con un número de usuarios
indefinidos en producción.</div>
Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-34025222688185207742013-03-03T00:05:00.000-08:002013-11-27T22:35:55.537-08:00Let the context decide<br />
<div class="MsoNormal" style="margin: 0cm 0cm 5.25pt;">
<br /></div>
<h2>
Introduction </h2>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">All developers in some
moment in their lives have faced (or will be facing) the need of create a
graphic editor, an ER model editor, a flowchart editor, whatever... but a
common problem is that every time we start a project like these, we start
without a common way to implement that, there are patterns like MVC, MVP, MVVM
and others M-something. These patterns are useful but in the most of cases we
find a slight line in implementation where every looks like the same,
separating responsibilities is sometimes quite tricky and the more user
interaction is added, the more complicated is to support these changes in
developments, usually because we must to modify many components in the
implementation. Well in this article we discuss a way (maybe not the
best) to solve the user interaction problems. In general is not only
useful for graphic editors but these are good examples for this article.
I hope you like it. <o:p></o:p></span></div>
<h2>
<span lang="EN-US">Background </span></h2>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">Let's suppose that we must
to create a shapes editor, then we start creating a class model but the user
interaction behavior for every shape is different, however, the device actions
set performed by users are the same for every shape. A user can click,
move, release its mouse, and is the same for other devices, the device actions
are finite, but ¿why is so difficult to understand the device inputs and give a
meaning to these actions? Well the answer is that the meaning for some action
depends on the 'context' it is raised. Let see an example.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">A user press a mouse
button, if there is no shape in the mouse position a selection task must start,
but if there is a shape in that position we could think that user wants to
select or drag that shape, we can code this in an lazy way, but, what if this
action produces different meanings depending on the shape functionality for
example, if we have a box with an expand-button? or maybe a shape with an
internal “draggable” element? We must to manage all these conditions in
the editor but without a well-structured way to do that all becomes a
mess. <o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">What I propose in the title
of this article is not to manage the context for those actions directly, but
let the context itself decide which must be the consequences for a specific
action. Working in that way, every time a new meaning is needed or
appears for a specific context is easier to maintain the code, every
time a new context appears in the development is easier to create and connect
with the existing development. The class diagram shown bellow
display a general idea about the code posted for this article and it is
organized to read from left to right and from top to bottom. <o:p></o:p></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirlDjH4muvREO2h5KC0yorP8G5ihPLwaG22zTmbe-rdvx-J2UeIsgJQHrGApd30ELIFqj4_mi7dtYVZgoZsR_RnG1bO9hjYccQ7pg5qFNfxvuFCFjiDcoNmOEdtUeafTaWJhgt_NKCm_I/s1600/CompleteShapesModel.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirlDjH4muvREO2h5KC0yorP8G5ihPLwaG22zTmbe-rdvx-J2UeIsgJQHrGApd30ELIFqj4_mi7dtYVZgoZsR_RnG1bO9hjYccQ7pg5qFNfxvuFCFjiDcoNmOEdtUeafTaWJhgt_NKCm_I/s1600/CompleteShapesModel.png" /></a></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<br /></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">The first class we see is
the <b>DashboardBase</b> class
which is a user control and its responsibility is to catch the
control inputs for all devices (mouse, keyboard, pencil, whatever). This
class uses a <b>Renderizer</b> to
print the view state in the control's client area Graphics. Additionally the
dashboard references an <b>InteractionManager</b> which
processes all <b>InteractionEvent</b> instances built
by the dashboard control depending on the event raised. The <b>InteractionManager</b> class uses the <b>View</b> class and
its responsibilities are:<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">1. Manage the context for
the view.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">2. Adapt the diagram
information (for example managing coordinates spaces) to the control depending
on some properties like zoom, offset.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;"><br /></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">The <b>Selection </b>class
is only a property used by the view to store the selected shapes and it is not
important in order to show the idea. The Diagram class is the model
we are creating or editing, this class contains for this example Layers and
Shapes. To keep it simple we only define a <b>BoxShape</b> and a <b>LineShape</b>. When
the view detects that an action have been performed, it analyzes whether exists
a shape capable to solve the context, if a shape is found that shape must solve
the context depending on its features. In that way, if the shape is
a BoxShape it can define the context depending on a drag area, a
rotation glyph or a re-size corner, all these with different
consequences. OK now we have the context, so, how it is used?
That's the wonderful part, every context share a common
interface called IInteractionContext. This
interface contains basically three methods. <o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">Begin: When the context is
activated a transaction is started. <o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">ProcessEvent; This method
filters all the user interactions that this context can manage, including
events available to commit or rollback the transaction modifying the view for
the specified event. <o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">Commit: This method defines
in every context, the way all data must be applied to the diagram model or how
must be modified the view (in the Selection case for example). <o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">As you can see, we define
in the top classes implementing the IInteractionContext. These classes
decide for every context which is the meaning for all the interaction events
available for the context. We can observe the following
contexts: <o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<b><span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;"><br /></span></b></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<b><span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">ShapeResizeContext</span></b><span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">: Context used to re-size a BoxShape. <o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<b><span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">SelectionMoveContext</span></b><span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">: Context used to move a shape in the Diagram. <o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<b><span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">MoveLineVertexContext</span></b><span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">: Context used to move the start point and end point for a
line. <o:p></o:p></span></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<b><span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">SelectRectangleContext</span></b><span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">: Context used to select all shapes in a rectangle. <o:p></o:p></span></div>
<h2>
<span lang="EN-US" style="line-height: 150%; mso-ansi-language: EN-US; mso-bidi-font-size: 10.5pt;">Results</span></h2>
<div>
<br /></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span lang="EN-US" style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;">A single image about the
code execution result at <a href="https://drive.google.com/file/d/0B02IYieAFGvcbUdtWl9EUXYzQkk/edit?usp=sharing">Shapes Test</a><o:p></o:p></span><br />
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjylcSOntp4dWOYbuq9VEDTVNGyDfKePN5KYK3CbDBb7kw6DLBbSwu4b-IK4xqnqbf2wM_H1117Svp2rAJUOh4tpcKRf-FW13Oc9sX1HX2WiNGGOU72LsTc1-1GFLj59RehuaNHAbWop-0/s1600/Result.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjylcSOntp4dWOYbuq9VEDTVNGyDfKePN5KYK3CbDBb7kw6DLBbSwu4b-IK4xqnqbf2wM_H1117Svp2rAJUOh4tpcKRf-FW13Oc9sX1HX2WiNGGOU72LsTc1-1GFLj59RehuaNHAbWop-0/s1600/Result.png" /></a></div>
<div class="MsoNormal" style="margin-right: 0cm;">
<span style="color: #111111; font-family: "Segoe UI","sans-serif"; font-size: 10.5pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES-CO;"> </span></div>
Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-12292203627303964702012-10-13T21:14:00.001-07:002013-08-27T23:06:29.813-07:00CUANDO LOS ERRORES NO ESTAN EN EL CÓDIGO<br />
La mayoría de las veces estamos buscando los orígenes de los problemas en nuestro código fuente y puede que encontremos muchos o pocos, quien sabe, pero en otras ocasiones el código fuente solamente es el reflejo de otros aspectos de las organizaciones. A este tipo de situaciones es a la que nos vamos a referir en esta ocasión. <br />
<br />
Una aspecto fundamental que hay que entender es que los desarrolladores son seres humanos aunque aveces no lo parezcan, la consecuencia lógica es que sus acciones afecten los resultados y el ambiente de trabajo, a continuación presento una serie de conductas y efectos producidos por las mismas dentro del código. Como es de esperarse solamente se presentan aspectos negativos ya que los positivos no generan problemas, adicionalmente pueden establecerse combinaciones y de hecho considero que cada uno tiene un poco de todos por lo que se deben analizar los comportamientos presentados desde una óptica de extremos para ser comprendidos.<br />
<br />
<strong>El paranoico laboral.</strong><br />
<br />
Este es personaje que pocos identifican y que mantiene oculto sus pensamientos reales, se concentra permanentemente en la idea de que lo pueden despedir en cualquier momento, hace chistes en casi cualquier situación relacionados con el despido, se siente inseguro sobre su trabajo y actúa de acuerdo a su paranoia. Es el tipo de persona que nunca revela información sobre lo que hace porque su inseguridad es tan grande que piensa que si los compañeros entienden como funcionan sus desarrollos ya no será necesario para la organización o podrá ser sustituido. Esta persona suele escribir un código prácticamente cifrado e incomprensible para garantizar su subsistencia, como consecuencia le hace miserable la vida a todo el equipo de trabajo y sacrifica su propia tranquilidad con tal de mantener custodiado esos algoritmos que después de un tiempo ni el mismo entiende. La productividad general se ve afectada en gran medida si este individuo trabaja los aspectos principales de los productos.<br />
<br />
<strong>El inmediatista</strong><br />
<br />
Otro tipo de desarrolladores que a menudo nos encontramos son aquellos que nunca se preocupan por entender las dimensiones de lo que hacen. Esto es, frente a un bug o nuevo desarrollo solo visualizan el resultado inmediato de lo que están tratando y pierden el punto de vista general. El inmediatista por lo general toma decisiones de la forma 'Si x vale 2 entonces funciona...como x vale 1 cuando no funciona entonces le sumo uno', todo esto sin preocuparse que se supone que representa x, donde se usa, en que parte del código está parado... es el que coloca la mayoría de los try..catch sin sentido, es una persona que simplemente hace lo que se le pide, no va mas allá, solo piensa en que no se le acumule el trabajo. La consecuencia lógica de esta conducta es que por cada cosa que este personaje arregle daña 5 creando una inestabilidad en el código producto de una codificación al azar.<br />
<br />
<strong>El revolucionario</strong><br />
<br />
Este personaje siempre se encuentra en desacuerdo con la forma en la que se realizan las actividades de trabajo, anda en una búsqueda permanente de una solución mágica que hace que todos los problemas desaparezcan, la raíz de todos los males, el código que nos va a sacar del hueco. Este tipo de desarrolladores se siente a cada momento entre la espada y la pared, porque sus desarrollos nunca han funcionado y nunca es su culpa, está aburrido de que cada nueva solución traiga mas problemas y siempre busca nuevas tecnologías que solucionarán todo. Estos desarrolladores por lo general no viven alineados con los objetivos y dificultan la comunicación que es vital en este tipo de trabajo y hace que fluya todo en la dirección correcta.<br />
<br />
<strong>El hombre código</strong><br />
<br />
Es admirado por su capacidad analítica y por ser capaz de enfrentarse a situaciones desconocidas, sabe de todo y no se especializa en nada, pero por encima de estas características es admirado por su gran capacidad de producir toneladas y toneladas de código, a veces no tan bueno, pero, a quien le importa, ES MUCHO CÓDIGO!!!. Es tan bueno programando que no necesita diseñar nada, sus diseños (cuando le toca diseñar) son extremadamente complejos. Para este individuo todos los problemas se arreglan depurando el código y los conceptos pasan a un segundo plano, lo importante es el código y piensa en forma algorítmica hasta en su vida cotidiana. Como este personaje abarca gran parte de la "producción" es uno de los elementos que mas bugs inyecta en los fuentes, crea esquemas incomprensibles para el resto de los mortales dentro del equipo.<br />
<br />
<strong>El evasor de trabajo</strong><br />
<br />
De estos hay muchos, es ese tipo de persona que nunca se hace responsable de lo que hace siempre anda pensando que todos quieren ponerle mas trabajo a el, no es consiente de que el resto de las personas trabajan igual o quizás mas duro que el. Esta situación hace que siempre esté postergando sus tareas, y cuando se le pregunta sobre algo que desarrolló, siempre depende de otra cosa que el no hizo y por eso "NO SABE". Cuando el problema es generalizado dentro del equipo de desarrollo los tiempos de entrega se ven afectados por un carrusel del que es casi imposible salir, preguntando aquí y allá para saber quien conoce el estado actual del tema.<br />
<br />
<strong>El "buena gente"</strong><br />
<br />
Esta persona no le dice que NO a nada, es amable con todos y siempre anda colgado con el trabajo, pero sigue aceptando mas trabajo, consecuentemente acapara gran parte de las funcionalidades y hace que todo tenga que ver con el. Sus compañeros evasores se aprovechan de esta situación para transferir su carga laboral a esta persona que en ultimas no termina siendo mas que una víctima de sus propias acciones.<br />
<br />
<strong>El personalizado</strong><br />
<br />
Este ser se lo toma todo de manera personal, su código no puede ser cuestionado porque eso representa una ofensa a su intelecto, los problemas para este individuo nunca son académicos, siempre están relacionados con la manera de ser de los demás miembros del equipo y consecuentemente dificulta la comunicación creando fricciones innecesarias. Por lo general es una persona que trabaja muy bien solo y muy mal en equipo.<br />
<br />
<strong>El superproductivo</strong><br />
<br />
Esta persona siempre hace mas cosas de las necesarias, si le piden que haga un informe desarrolla un sistema de información para la generación automática de informes, por lo general entrega lo que se le pide, sin embargo, terminará dando mas soporte a todas las cosas que se inventó y que no tenia que hacer. La consecuencia de esta conducta es que se desperdicia el tiempo realizando las tareas innecesarias, tiempo que podría reducir los plazos de entregas de características o desarrollos de mayor valor.<br />
<br />
<strong>Super-EGO</strong><br />
<br />
Esta persona es difícil de tratar, siempre esta proyectando una imagen de saberlo todo, de ser incuestionable, nadie sabe mas que el en ningún tema. Sus actitudes crean malestar en los demás miembros del equipo y maximiza sus logros y minimiza los de los demás. Este tipo de personas no trabajan bien en equipo y vuelven lento los procesos de diseño y construcción.<br />
<br />
<strong>Otros factores</strong><br />
<br />
Otro tipo de situaciones que pueden afectar los procesos de desarrollo de nuestros productos está dado por el uso apropiado de las habilidades de los miembros del equipo. Si no conocemos dichas habilidades es muy probable que estemos distribuyendo el trabajo de una manera poco inteligente, de esta forma, las características y las habilidades pueden terminar cruzándose de maneras catastróficas. En otras ocasiones problemas como la extrema presión de tiempo, la presión por los costos de proyectos o la presión por la competencias hace que la calidad con la que se liberan las características no sea la esperada, estos son otros tipos de problemas que afectan el código sin estar inmerso en el, de los cuales hablaremos en otra ocasión.<br />
<br />
Una vez visto a grandes rasgos ejemplos de formas en las que las conductas humanas pueden influir en la calidad de los desarrollos, deberíamos ser mas autocríticos con nuestras acciones y detectar las oportunidades de mejora sobre las mismas, teniendo en cuenta que en muchas ocasiones aspectos relacionados con el desorden y los intereses personales también pueden afectar los resultados. Espero les haya gustado el articulo y también espero sus comentarios.Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-30426416303771664292012-10-13T21:12:00.002-07:002013-08-27T23:14:30.411-07:00MODELOS DE OBJETOS<br />
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Los lenguajes orientados a objetos trajeron consigo un número de ventajas relativas a conceptos significativos de la programación, sin embargo, en muchos aspectos la disponibilidad de las ventajas no implica su comprensión y aplicación, de esta manera, se puede tener un arma muy poderosa para el desarrollo de la cual solo se utilizan las partes básicas.<span style="mso-spacerun: yes;"> </span>Teniendo en cuenta lo anterior, los miembros de un equipo de trabajo no solamente deben tener conocimientos específicos de los lenguajes de programación y de las herramientas, deben además, desarrollar en sí mismos una capacidad analítica que les permita identificar de manera clara y objetiva cuales son los elementos de un problema que brindan soluciones particulares a otros problemas.<span style="mso-spacerun: yes;"> </span>De esta forma, un pensamiento lo suficientemente analítico le permitirá a los miembros del equipo de desarrollo trabajar en términos de funcionalidades, responsabilidades, reutilización y composición de soluciones.<span style="mso-spacerun: yes;"> </span>Una forma sencilla de combatir estos problemas es utilizar diagramas que nos permitan visualizar y desacoplar la lógica de los diferentes<span style="mso-spacerun: yes;"> </span>modelos que componen la solución de la lógica de otro tipo de tareas comunes como lo son la presentación y la interacción con el usuario. <o:p></o:p></span></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Los modelos nos permiten identificar soluciones parciales a problemas específicos y genericos que en conjunto crean una capacidad de solución a los problemas objetivo, esto simplifica el entendimiento del problema y define los límites de funcionalidades en la implementación, de otra manera se puede implementar aspectos que no serán utilizados al final del desarrollo.<span style="mso-spacerun: yes;"> </span>Los modelos de objetos suelen brindar un conjunto de soluciones que se encuentran cerradas en un grupo de componentes que usualmente son determinados por los espacios de nombres en la programación orientada a objetos.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Se puede construir un conjunto de objetos que implementen muchas funcionalidades y no ser un modelo de objetos coherente, hay que tener mucho cuidado si no se termina implementando soluciones poco claras y difíciles de comprender desde el punto de vista del desarrollador. Al momento de diseñar un modelo de objetos tenga en cuenta los siguientes aspectos:<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">Generalidad: </span></b><span style="mso-ansi-language: ES-CO;">El diseño debe contar con un nivel de generalidad suficiente para resolver el o los subproblemas y al mismo tiempo estar preparado para el cambio, esto debe ocurrir en cada grupo de objetos que componen el modelo que da solución al problema planteado.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">Capacidad de crecimiento:</span></b><span style="mso-ansi-language: ES-CO;"> El modelo debe poder crecer en el tiempo y este crecimiento debe poder realizarse de manera incremental conservando el origen del diseño.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">Agrupamiento de Componentes:</span></b><span style="mso-ansi-language: ES-CO;"> Agrupar los tipos de objetos suele tener ventajas al momento de mantener la solución, se debe tratar de agrupar las funcionalidades comunes. <o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">Independencia:</span></b><span style="mso-ansi-language: ES-CO;"> En casi todos los casos los problemas suelen tener conceptos relacionados y teniendo en cuenta que estos conceptos se traducen en tipos de datos se deben identificar previamente las dependencias entre ellos para eliminar o reducir el impacto frente a los posibles cambios futuros.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">Composición:</span></b><span style="mso-ansi-language: ES-CO;"> La solución de un problema suele estar compuesta de soluciones específicas que usualmente son más pequeñas y que no necesariamente están dentro del mismo grupo que los tipos de datos de la solución total.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">Unidades de datos:</span></b><span style="mso-ansi-language: ES-CO;"> Se espera que los datos estén relacionados entre sí, de esta manera no se deberían tratar los datos de manera independiente sino como una entidad o unidad que encapsula la información, que debe corresponder a un concepto claramente identificado dentro del dominio del problema. Quien no ha vivido la tortura de mantener código en el cual todos los datos estan dispersos y en aumento?<span style="mso-spacerun: yes;"> </span>Analizar la información desde esta perspectiva nos da la posibilidad de crecer en la información de cada entidad o unidad de datos sin tener que alterar el comportamiento de la aplicación.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Tener en cuenta estos pequeños ítems puede complicarnos un poco el diseño, pero posteriormente puede evitarnos muchos problemas por lo vale la pena pensar en ellos.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237713007"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">Importancia del Reúso</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Si los elementos de nuestro modelo tienen responsabilidades específicas y tienen una buena definición sobre sus dependencias se logra un buen balance en términos del reúso.<span style="mso-spacerun: yes;"> </span>Es posible que si un modelo de objetos se diseña sin tener en cuenta las características anteriormente mencionadas, se encuentre incompleto, es decir que frente a nuevas situaciones no se cuenten con funcionalidades previamente implementadas para resolver los nuevos problemas.<span style="mso-spacerun: yes;"> </span>Es por esto que debemos tener un grado de confianza frente a las funcionalidades existentes, preferiblemente inventariadas, de esta manera podremos saber con exactitud que funcionalidades se encuentran lo suficientemente completas para ser reutilizadas, de otra manera, se inicia el desastre ya que al no estar completo o acotado el modelo reutilizado puede sufrir modificaciones en el futuro y consecuentemente impactar las soluciones que dependen de dicho modelo.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">El reúso es más que sólo utilizar componentes ya existentes en nuevas soluciones, se debe diseñar pensando en el reúso para poder crear las oportunidades a futuro, la idea aquí es muy clara, si se construyen soluciones específicas para un problema sin determinar las tareas comunes entre los diferentes problemas que lo componen, es probable que nunca podamos reutilizar un componente más allá de la simple casualidad.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Para incrementar el reúso en las aplicaciones se podría sacar partido de las jerarquías de objetos basadas en la herencia ya que estas nos permiten visualizar instancias de diferentes formas y de manera adicional proporcionan niveles de abstracción para la extensibilidad o el crecimiento. Como siempre todo en exceso es malo y estas jerarquías no son la excepción, pueden desencadenar problemas de rendimiento o si están definidas a la ligera se termina con muchas implementaciones vacías o con clases abstractas que lo resuelven todo por si solas y son difíciles de mantener. El reuso descontextualizado, aquel que se hace porque en alguna otra parte tambien se hace lo mismo, aquel que no define límites sobre las responsabilidades de los componentes suele terminar una desestabilidación continua de nuestros desarrollos en los que se corrige una funcionalidad y se dañan otras.</span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-size: medium;"><span style="color: #4f81bd;"><span style="font-family: Cambria;">Concentrando responsabilidades<o:p></o:p></span></span></span></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Es importante que existan en nuestras soluciones entes u objetos especializados en el procesamiento de cada tipo de información esto hace más fácil el mantenimiento de las aplicaciones ya que crea puntos específicos para la actualización de las características.<span style="mso-spacerun: yes;"> </span>Se debe evitar tener múltiples objetos que efectúan operaciones de la misma naturaleza, por ejemplo tener varias clases de acceso a datos <span style="mso-spacerun: yes;"> </span>tiene como consecuencia que frente<span style="mso-spacerun: yes;"> </span>a un requerimiento de un cambio específico en la forma de acceder a los datos abarcará múltiples elementos de la aplicación, creando la necesidad de modificar el desarrollo en varios puntos aumentando la posibilidad de agregar errores adicionales.<o:p></o:p></span></span></div>
Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-88699817556772162082012-10-13T21:07:00.001-07:002013-08-27T23:19:43.970-07:00TEMAS DE PRESENTACIÓN<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Diseñar la forma en la que una aplicación se verá es una tarea más compleja de lo que a primera vista podría apreciarse.<span style="mso-spacerun: yes;"> </span>Esta actividad se puede realizar de diversas maneras, algunas fábricas utilizan criterios puramente estéticos y aunque el aspecto es algo fundamental para que una aplicación sea<span style="mso-spacerun: yes;"> </span>atractiva a los usuarios y comercialmente atractiva es solo una parte del diseño.<span style="mso-spacerun: yes;"> En esta página no se pretende realizar un análisis exhaustivo ni académico sobre la usabilidad de las aplicaciones pero si pretende exponer algunos temas que algunas veces pasamos por alto en el diseño y desarrollo de nuestras aplicaciones.</span></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Muchas veces vemos aplicaciones que se ven muy bien y consecuente nos resultan impactantes en principio, sin embargo, al comenzar a<span style="mso-spacerun: yes;"> </span>utilizar el software encontramos aspectos confusos debido a lo heterogéneo de la presentación.<span style="mso-spacerun: yes;"> </span>Muchas veces encontramos aplicaciones con sofisticadas gráficas y animaciones que crean una barrera al momento de utilizarlas de manera intuitiva.<span style="mso-spacerun: yes;"> </span>También existen aplicaciones con elementos de presentación que suelen ser muy sencillos pero que tienen una fuerte simbología que nos permite identificar las tareas disponibles de una manera rápida.<span style="mso-spacerun: yes;"> </span>En esta sección se presentarán aspectos importantes relacionados con la presentación que usualmente pasamos por alto.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712992"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">Trabajando con Imágenes</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Como se suele decir, una imagen vale más que mil palabras y esto en la construcción de aplicaciones sí que es cierto.<span style="mso-spacerun: yes;"> </span>Las imágenes en las aplicaciones están por doquier y hay una justificación en ello, una imagen puede identificar un concepto relacionado con la aplicación y elimina el esfuerzo de tener que leer por ejemplo una descripción de dicho concepto.<span style="mso-spacerun: yes;"> </span>Las imágenes suelen utilizarse para aprovechar el conocimiento previo que un usuario pueda tener del software que está utilizando, simplemente el usuario experimentado visualiza la imagen, identifica el concepto relacionado y usa dicho concepto, no tiene que leer de que se trata cada vez que lo va a utilizar.<span style="mso-spacerun: yes;"> </span>A pesar de brindar ventajas en este sentido, una aplicación debe tener en cuenta que no todos los usuarios son experimentados y que algunos se enfrentan a la herramienta simplemente utilizando su intuición.<span style="mso-spacerun: yes;"> </span>Teniendo en cuenta esto último, podríamos concluir que una aplicación bien definida debe proporcionar las dos opciones, las imágenes para los experimentados y algún mecanismo de orientación en caso de que no se tenga un conocimiento previo de las funcionalidades, entre estos mecanismos encontramos por ejemplo las barras de estado y los mensajes emergentes y muchos otros.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Las imágenes al igual que cualquiera de los elementos del producto deben ser diseñadas, usualmente por un diseñador gráfico, no debería ser trabajo del desarrollador crear o seleccionar las imágenes de una aplicación.<span style="mso-spacerun: yes;"> </span>Dicho diseño debe garantizar que existe una coherencia y uniformidad en la simbología utilizada y una clara diferenciación en los elementos visuales y su semántica <span style="mso-spacerun: yes;"> </span>Como mínimo se podría esperar que las imágenes de un mismo grupo visual tengan el mismo tamaño, muchas veces las imágenes se construyen con un tamaño diferente al utilizado en la aplicación y luego al ser escaladas se producen distorsiones en las mismas y suelen crear diferencias sutiles que le restan profesionalismo a la construcción.<span style="mso-spacerun: yes;"> </span>Es necesario considerar que los usuarios no están pensando en imágenes cuando utilizan las aplicaciones, por el contrario su mente que identifica los conceptos de la aplicación espera que dichos elementos<span style="mso-spacerun: yes;"> </span>estén integrados con la aplicación y esto nos lleva a concluir que las imágenes con colores de fondo no deberían utilizarse en formularios de la aplicación, aunque en algunos casos podrían ser útiles como decoración para elementos emergentes.<span style="mso-spacerun: yes;"> </span>El color suele ser otro factor importante al momento de diseñar las imágenes ya que colores muy claros tienden a cansar la vista del usuario, en algunas ocasiones pueden relacionarse colores con aspectos como la peligrosidad de una acción, o acciones específicas sobre diversos elementos.<span style="mso-spacerun: yes;"> </span>Se debe tener en cuenta durante el diseño que si las imágenes utilizadas son muy parecidas el usuario deberá realizar un esfuerzo adicional al identificar la operación que requiere realizar, de manera similar no deberían existir dos elementos iguales con diferentes significados ni un mismo significado con diferentes imágenes ya que esto desorienta al usuario</span><a href="http://www.blogger.com/null" name="_Toc237712993"><span style="font-family: Calibri;">.<br clear="all" style="mso-special-character: line-break; page-break-before: always;" /><o:p></o:p></span></a></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<span style="font-size: medium;"><span style="color: #4f81bd;"><span style="font-family: Cambria;"><span style="mso-bookmark: _Toc237712993;"><span style="mso-ansi-language: ES-CO;">Trabajando con Mensajes y descripciones</span></span><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></span></span></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Una parte importante de la presentación de una aplicación involucra una definición clara de los títulos, etiquetas y descripciones de los elementos de interacción presentados.<span style="mso-spacerun: yes;"> </span>Títulos poco precisos o ambiguos suelen confundir al usuario respecto a la ubicación u operaciones que desea realizar.<span style="mso-spacerun: yes;"> </span>Es importante que se examinen los títulos teniendo en cuenta algunos criterios sencillos:<o:p></o:p></span></span></div>
<br />
<h3 style="margin: 10pt 0cm 0pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-size: small;"><span style="color: #4f81bd;"><span style="font-family: Cambria;">Minimalidad y Simplicidad<o:p></o:p></span></span></span></span></h3>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Los mensajes presentados deben decir de la manera más simple lo que desean expresar,<span style="mso-spacerun: yes;"> </span>de igual manera se espera que un mensaje comunique de manera directa su contenido, esto es, las palabras mínimas requeridas para expresarlo.<span style="mso-spacerun: yes;"> </span>Mensajes muy largos o con más de una idea pueden confundir al Usuario novato y aburrir al usuario experimentado hasta el punto de obviar la advertencia realizada.<span style="mso-spacerun: yes;"> </span>Respecto a este punto un mensaje similar al presentado a continuación<o:p></o:p></span></span></div>
<br />
<div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">“Confirma que desea eliminar permanentemente estos elementos?”,<o:p></o:p></span></span></b></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Es preferible a otro como el siguiente:<o:p></o:p></span></span></div>
<br />
<div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">“La lista de los elementos seleccionados en la aplicación será removida indefinidamente como consecuencia de la ejecución de de la operación en curso.<span style="mso-spacerun: yes;"> </span>Está seguro que desea realizar la operación solicitada?”.<o:p></o:p></span></span></b></div>
<br />
<h3 style="margin: 10pt 0cm 0pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-size: small;"><span style="color: #4f81bd;"><span style="font-family: Cambria;">Coherencia del lenguaje<o:p></o:p></span></span></span></span></h3>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Se debe tener en cuenta que un usuario normalmente utiliza software como herramienta para realizar de una manera más fácil y rápida un oficio que muy probablemente pertenezca o otra área del conocimiento distinta a los sistemas de información.<span style="mso-spacerun: yes;"> </span>Por este motivo, los mensajes y las advertencias deben estar en el lenguaje de área de conocimiento del usuario, para ilustrar un poco esto consideremos los siguientes mensajes utilizados para describir la misma situación y evalúe cual se encuentra en el lenguaje apropiado para un cajero de una pequeña tienda o almacén.<o:p></o:p></span></span></div>
<br />
<div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">“Se ha detectado una inconsistencia de accesibilidad entre los elementos seleccionados para procesar la transacción solicitada. La cardinalidad entre los productos suministrados y sus descripciones debe ser equivalente (Uno a uno)”<o:p></o:p></span></span></b></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 36pt;">
<b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">“Tenga en cuenta que cada producto debe tener una y solo una descripción”<o:p></o:p></span></span></b></div>
<br />
<h3 style="margin: 10pt 0cm 0pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-size: small;"><span style="color: #4f81bd;"><span style="font-family: Cambria;">Contextualización<o:p></o:p></span></span></span></span></h3>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Los mensajes deben estar en contexto con las tareas realizadas por el usuario aunque deben ser lo suficientemente explicitos (dentro del contexto)<span style="mso-spacerun: yes;"> </span>para entender la situación.<span style="mso-spacerun: yes;"> </span>Evalúe los siguientes mensajes e identifique cual está en el contexto indicado para un usuario que se encuentra guardando un archivo.<o:p></o:p></span></span></div>
<br />
<div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt 36pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">“Seleccione la ubicación para guardar el archivo”<o:p></o:p></span></span></b></div>
<br />
<div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt 36pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">“Guardar”<o:p></o:p></span></span></b></div>
<br />
<h3 style="margin: 10pt 0cm 0pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-size: small;"><span style="color: #4f81bd;"><span style="font-family: Cambria;">Claridad<o:p></o:p></span></span></span></span></h3>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Por último los mensajes claros son claves para que el usuario se sienta cómodo utilizando nuestra aplicación, un problema en la claridad de un mensaje puede ser una consecuencia de una falla en los conceptos anteriormente descritos ya que un mensaje se puede hacer tan complicado o elaborado como se quiera. Por ejemplo:<o:p></o:p></span></span></div>
<br />
<div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">“El protocolo de transferencia de archivos ha arrojado una excepción en tiempo de ejecución (0x12345) debido a un desbordamiento de la pila. Si los archivos no se han transferido, entonces se enviarán la próxima ocasión que el mecanismo de conexión se restablezca. En caso de que los dispositivos de red se encuentren disponibles”<o:p></o:p></span></span></b></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><o:p><span style="font-family: Calibri;"> </span></o:p></span></div>
<br />
<div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: center;">
<b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">“No se pudo establecer la comunicación para enviar los datos, se intentará reenviarlos cuando la comunicación se restablezca.”<o:p></o:p></span></span></b></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<span style="mso-ansi-language: ES-CO;"><o:p><span style="color: #4f81bd; font-family: Cambria; font-size: medium;"> </span></o:p></span></h2>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<span style="font-size: medium;"><span style="color: #4f81bd;"><span style="font-family: Cambria;"><span style="mso-bookmark: _Toc237712994;"><span style="mso-ansi-language: ES-CO;">Trabajando con opciones</span></span><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></span></span></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Se pueden definir diferentes estrategias en la presentación de opciones al usuario, por un lado podemos optar por presentar las opciones de manera contextual, es decir en este modelo el usuario descubre las opciones dependiendo de las funciones, el área de trabajo o el contexto en el que se desenvuelve, aunque esta estrategia suele ser muy cómoda para el usuario representa un esfuerzo adicional en la construcción y un exceso de contextualización puede confundir al usuario sobre la localización de las opciones.<span style="mso-spacerun: yes;"> </span>Por otro lado se pueden agrupar según los tipos de características ofrecidas y visualizar los grupos de manera estática,<span style="mso-spacerun: yes;"> </span>por ejemplo, podemos colocar todo lo relacionado con la configuración en un grupo de “Opciones” y todo lo relacionado con el manejo de archivos en “Archivo”.<span style="mso-spacerun: yes;"> </span>Pueden mezclarse los métodos mencionados anteriormente para lograr una eficiencia en la presentación de opciones, esto debe hacerse con cuidado para no saturar al usuario con la redundancia introducida y consecuentemente las opciones definidas en las diferentes formas deben ser representadas visualmente de manera única para evitar confusiones.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712995"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">Diseñando la usabilidad</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Diseñar la usabilidad de una aplicación puede ser todo un reto, a<span style="mso-spacerun: yes;"> </span>pesar de no tener un impacto en los resultados de la construcción, la usabilidad brinda confort a los usuarios.<span style="mso-spacerun: yes;"> </span>A medida que simplificamos más los elementos de interfaz de usuario, es decir a medida que hacemos más sencillas de usar a nuestras aplicaciones, la complejidad interna puede aumentar para soportar estos aspectos.<span style="mso-spacerun: yes;"> </span>Algunas características son claves para incrementar la usabilidad de una aplicación, por ejemplo el número de clics que un usuario debe efectuar para realizar una tarea específica es clave para la usabilidad.<span style="mso-spacerun: yes;"> </span>Por otro lado hacer que nuestra aplicación tenga la mayor cantidad de información disponible para su uso suele ser otro factor determinante para la comodidad de los usuarios sin incurrir en excesos.<span style="mso-spacerun: yes;"> </span>La distribución del espacio, la distancia entre los elementos visuales y su agrupación también aportan un gran valor al momento de operar un sistema de información.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712996"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">Importancia de la Usabilidad</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">En muchos casos la usabilidad de una aplicación se ve reflejada y dirigida en el rendimiento operativo de los usuarios y es por esto que las características de usabilidad pueden impactar en gran medida la productividad del sistema de información.<span style="mso-spacerun: yes;"> </span>Para entender un poco más de que hablamos podríamos considerar como ejemplo un centro de atención telefónica que cumple con las siguientes condiciones:<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpFirst" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Los clientes se contactan con asesores<span style="mso-spacerun: yes;"> </span>por ejemplo para efectuar un proceso de actualización de datos.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Los clientes suelen ser impacientes y es muy probable que éstos tengan un umbral o límite en el tiempo de espera que asumen es necesario para procesar su solicitud, si esperan demasiado, se aburren y simplemente declinan la operación.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Considere entonces que un asesor puede recibir muchas llamadas y que utiliza una aplicación para registrar los datos proporcionados por el cliente, mientras más se demore en procesar los datos de un cliente menos clientes podrá atender en un tiempo determinado por ejemplo de una hora.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Asuma que de manera adicional la compañía de asistencia telefónica realiza su facturación dependiendo del número de clientes satisfechos atendidos o del número de registros actualizados.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Probablemente la empresa no se haya dado cuenta, pero existe un problema de usabilidad de la aplicación utilizada para ingresar la información en la base de datos. <o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpLast" style="margin: 0cm 0cm 10pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">El problema consiste en que el usuario debe realizar un clic sobre cada campo cada vez que desea ingresar información para dicho campo y no dispone de una forma directa para llenar la información y continuar con el siguiente.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Teniendo en cuenta las condiciones mencionadas anteriormente podríamos efectuar la siguiente reflexión sobre el funcionamiento de la empresa: <o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Si para llenar cada valor el usuario gasta un segundo (1) adicional al tiempo de escritura para abandonar el teclado, tomar el ratón y regresar al teclado, y los datos del usuario son por ejemplo veinte campos, el usuario perderá 20 segundos por cada actualización,<span style="mso-spacerun: yes;"> </span>si la actualización de los datos se estima en promedio en un minuto (60s) el usuario estaría perdiendo la tercera parte del tiempo.<span style="mso-spacerun: yes;"> </span>Esto nos indica que realizar una simple corrección en la usabilidad de la aplicación nos permitiría triplicar el volumen de clientes atendidos en un minuto.<span style="mso-spacerun: yes;"> </span>Si la empresa pierde este tiempo en un asesor pasaría inadvertido, sin embargo si el centro de soporte cuenta con un equipo de 40 personas y todas tienen el mismo comportamiento en el uso ya que todos los individuos operan la misma aplicación, la empresa podría estar perdiendo una suma significativa de dinero al momento de realizar la facturación.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">En algunos casos la usabilidad puede impactar en el confort de los usuarios y aun así no tener un impacto de esta magnitud, sin embargo un usuario que encuentra difícil de utilizar un producto eventualmente lo abandonará para adquirir otro que le haga las cosas más fáciles.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-size: medium;"><span style="color: #4f81bd;"><span style="font-family: Cambria;">Definiendo parámetros de usabilidad<o:p></o:p></span></span></span></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Teniendo claro los factores mencionados anteriormente, se debe tener una clara expectativa en términos de usabilidad. Se deben definir al menos los siguientes aspectos respecto a la funcionalidad construida:<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">¿La productividad del negocio se puede ver directamente asociada con la facilidad de uso de nuestra aplicación? </span></b><span style="mso-ansi-language: ES-CO;"><span style="mso-spacerun: yes;"> </span>Aunque en muchos casos esta situación puede presentarse, en muchos otros casos la productividad puede estar acotada por los tiempos del proceso del negocio y consecuentemente pasar a un segundo plano, de todas maneras es muy importante que se tenga claro el impacto de la usabilidad de un sistema de información en las operaciones del negocio.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">¿Se han identificado las tareas más comunes a realizar por los usuarios?</span></b><span style="mso-ansi-language: ES-CO;"> De una aplicación suele esperarse que las tareas más comunes se realicen con mayor rapidez que aquellas que se producen de manera eventual.<span style="mso-spacerun: yes;"> </span>Si no se han identificado cuales son las operaciones más comunes la construcción de la aplicación puede terminar siendo muy usable en las cosas que no se utilizan con frecuencia por lo que los usuarios tendrán las mismas dificultades que si no se hubiera diseñado el uso.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">¿Las funciones más utilizadas están disponibles en localizaciones cercanas al área de trabajo relacionada? </span></b><span style="mso-ansi-language: ES-CO;"><span style="mso-spacerun: yes;"> </span>La cercanía de las operaciones ayuda al usuario a concentrarse en el trabajo y no a buscar donde se encuentra la función que desea utilizar.<span style="mso-spacerun: yes;"> </span>Un ejemplo clásico de esto es un editor de texto en el que no se puede obtener un menú de opciones comunes mientras se encuentra ubicado en el área de edición.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">¿Existe un comportamiento común para la funcionalidad implementada en otras aplicaciones?</span></b><span style="mso-ansi-language: ES-CO;"> En algunos casos los usuarios perciben dificultades al momento de utilizar cierta característica debido a que poseen costumbres asociadas a otras aplicaciones, por ejemplo, un editor de texto en el que no se pueda copiar texto seleccionado realizando clic derecho o presionando CTRL-C, es probable que un usuario lo encuentre difícil de utilizar ya que casi todos brindan esta característica.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">¿Se han identificado las preferencias de dispositivos de interacción?</span></b><span style="mso-ansi-language: ES-CO;">Al momento de diseñar la usabilidad de nuestra aplicación debe tenerse en cuenta que no todos los usuarios tienen las mismas preferencias sobre los periféricos de entrada,<span style="mso-spacerun: yes;"> </span>algunos utilizan en exceso el ratón otros prefieren realizar la mayoría de las operaciones con el teclado, otros lo harán por smartphones o tablets.<span style="mso-spacerun: yes;"> </span>Tenga en cuenta que abarcar la mayoría de opciones no solamente le ayudará a la aplicación a adaptarse a las costumbres del usuario sino que también brindará opciones importantes al momento de faltar uno de ellos en caso por ejemplo de que se haya dañado el ratón a media noche y se tenga que entregar un informe a la mañana siguiente.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">¿Los elementos de interacción con el usuario que se han seleccionado permitirán un mínimo de esfuerzo para su utilización?</span></b><span style="mso-ansi-language: ES-CO;"> Muchas veces encontramos aplicaciones que presentan opciones de maneras equivocadas, por ejemplo una lista desplegable que solo tiene dos opciones, si y no lo único que logra además de la reducción del espacio es agregarle trabajo adicional a un usuario de descubrir cuáles son los elementos de la lista, mientras que sería más apropiado tener una casilla de chequeo que presente una sola opción activada o desactivada.<span style="mso-spacerun: yes;"> </span>Si los valores pueden ser escogidos de una lista, entonces poner a escribir la información al usuario únicamente le agrega más trabajo y si la lista es estática y no supera el número de 5 items entonces es mejor presentar las cinco opciones con una selección excluyente así al usuario no le toca realizar un clic adicional para descubrir el contenido de la lista.<span style="mso-spacerun: yes;"> </span>Existen muchas<span style="mso-spacerun: yes;"> </span>formas de equivocarse en la selección de los elementos, y en muchas ocasiones estos ocurren debido a la facilidad de integración de algunos componentes que es atractiva para reducir tiempos en la construcción por parte de los desarrolladores, sin embargo lo que es bueno para los desarrolladores no necesariamente es bueno para los usuarios.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">¿Se han considerado los distintos tipos de usuario y sus límites en el diseño? </span></b><span style="mso-ansi-language: ES-CO;"><span style="mso-spacerun: yes;"> </span>El diseño de la usabilidad de una aplicación podría estar afectado por las expectativas de productividad para distintos grupos de usuarios, por ejemplo se puede definir que el 40% de los usuarios nuevos deben poder instalar el producto en menos de 15 minutos sin ayuda alguna, o puede definirse que el 80% de los usuarios experimentados deben ser capaces de construir un documento pequeño completo en menos de 10 minutos.<span style="mso-spacerun: yes;"> </span>Este tipo de consideraciones nos permiten direccionar el rendimiento de la aplicación hacia el tipo de usuarios que son más importantes para nosotros.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: Calibri;"><b style="mso-bidi-font-weight: normal;"><span style="mso-ansi-language: ES-CO;">¿Se han involucrado en el diseño de usabilidad a los usuarios finales de manera previa a la construcción?</span></b><span style="mso-ansi-language: ES-CO;"> No hay nada peor que el esfuerzo y el trabajo perdido, y en algunas ocasiones los diseñadores y desarrolladores definen formas de interacción con el usuario que no han sido consultadas ni aprobadas por los mismos, esto redunda en un esfuerzo en vano y un rechazo frente a una funcionalidad esperada de cierta manera por los usuarios de la aplicación.<span style="mso-spacerun: yes;"> </span>Es importante que una vez se haya diseñado la forma en la que los usuarios interactuarán con la aplicación se someta a la aprobación por parte de los mismos para evitar construir algo que no obedezca a las expectativas de uso de quienes finalmente utilizarán la aplicación.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712997"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">Construyendo Interfaces intuitivas</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Un aspecto fundamental en el diseño de la usabilidad de una aplicación es la capacidad que brinda el software construido para<span style="mso-spacerun: yes;"> </span>ser comprendido y aprendido por el usuario en una manera eficiente, se espera que un usuario pueda intuir el funcionamiento básico de una aplicación sin un conocimiento previo de los elementos visuales, de igual manera se espera que un usuario experimentado pueda identificar de manera eficaz las acciones a realizar.<span style="mso-spacerun: yes;"> </span>Para lograr esto de manera eficaz se requiere que se diseñen opciones de presentación de mensajes que le permitan a un usuario novato consultar las funcionalidades,<span style="mso-spacerun: yes;"> </span>una forma muy común de lograrlo es utilizar mensajes emergentes (tooltips) que se presenten al posicionarse en los elementos visuales, en algunas ocasiones también se pueden presentar descripciones sobre las opciones de la aplicación en barras de estado o con menús emergentes con opciones como“Que es esto?” aunque esta opción personalmente no me gusta mucho.<span style="mso-spacerun: yes;"> </span>Los mensajes deben ser lo suficientemente descriptivos para que el<span style="mso-spacerun: yes;"> </span>usuario novato comprenda de qué se trata la opción adecuada.<span style="mso-spacerun: yes;"> </span>De la misma manera, las acciones que puedan comprometer datos o tener consecuencias irrecuperables deberían presentar mensajes de confirmación que le permitan al usuario nuevo entender las consecuencias de la acción que está por efectuar.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Es importante que una aplicación le permita al usuario comprender el estado y el contexto en el que se encuentra trabajando para que de esta forma pueda tomar las decisiones pertinentes, por ejemplo si un usuario está efectuando una tarea que implica un largo tiempo de procesamiento debe presentarse algún indicador sobre el progreso de la operación, de otra manera el usuario no comprenderá lo que está sucediendo y eventualmente buscará la manera de deshacerse del programa en ejecución lo que para algunos procesos pueden resultar en consecuencias desastrosas.<span style="mso-spacerun: yes;"> </span>Se pueden presentar barras de progresión o imágenes y mensajes que indiquen que existe una operación en proceso.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Hay que tener en cuenta que a veces es conveniente que las pantallas tengan un comportamiento dinámico, esto debe realizarse con moderación ya que una presentación muy cambiante puede despistar y confundir al usuario sobre la ubicación de las funcionalidades, al momento de dinamizar el comportamiento de una pantalla de captura por ejemplo prefiera presentar componentes inactivos en vez de ocultarlos, si están inactivos el usuario sabrá que no se encuentran disponibles pero tendrán una idea clara de la ubicación de dicha funcionalidad mientras que si se ocultan la mente del usuario no relacionará la funcionalidad oculta con su localización dentro de la aplicación lo cual logrará que en futuros usos tarde mas en identificar donde se encontraba.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<span style="font-size: medium;"><span style="color: #4f81bd;"><span style="font-family: Cambria;"><span style="mso-bookmark: _Toc237712998;"><span style="mso-ansi-language: ES-CO;">Captura de Datos</span></span><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></span></span></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Algunos desarrollos presentan problemas en la captura de datos, en algunos casos debido al exceso de ventanas modales anidadas durante el proceso de captura de datos específicos de una aplicación.<span style="mso-spacerun: yes;"> </span>Hay algo que es necesario entender sobre las ventanas modales, estas sirven como instrumento para sincronizar la entrada de la información y evitar estados inconsistentes debido a ingresos paralelos, sin embargo, para capturas de datos jerárquicas esto suele incluir algunos problemas de usabilidad, entre dichos problemas podemos encontrar la pérdida de la visión global de los datos de entrada dentro de la jerarquía.<span style="mso-spacerun: yes;"> </span>Para entender esto pensemos en el siguiente ejemplo, imagine una ventana modal que tiene<span style="mso-spacerun: yes;"> </span>dos botones, cada botón presenta una nueva ventana modal<span style="mso-spacerun: yes;"> </span>que nos impide ver la información en la ventana anterior, en este caso el usuario incurre en un sobre esfuerzo ya que<span style="mso-spacerun: yes;"> </span>es probable que para tomar una decisión deba consultar un dato de la ventana padre, para esto deberá mover la ventana para visualizar dicha información.<span style="mso-spacerun: yes;"> </span>Ahora supongamos que esta segunda ventana tiene una tercera anidada o ventaja hija,<span style="mso-spacerun: yes;"> </span>teniendo en cuenta que cada ventana bloquea las acciones de la anterior, el usuario podrá mover la tercera ventana para visualizar los datos de la segunda, sin embargo, si deseara visualizar información en la ventana principal, el usuario deberá cerrar la tercera ventana y mover la segunda.<span style="mso-spacerun: yes;"> </span>A medida que se agregan más cuadros de dialogo anidados se hace más difícil utilizar la aplicación.<span style="mso-spacerun: yes;"> </span>Una solución a este problema es utilizar un modelo coherente de los datos que se están solicitando y diseñar una única forma que permita administrar la jerarquía, por ejemplo con un árbol que presente la jerarquía y una ventana de propiedades cambiante según la posición dentro del árbol, de esta manera si un usuario se encuentra ubicado en a tres niveles y desea saber la información en el nivel superior con un solo click se puede trasladar hasta el nodo principal, en la mayoría de los casos puede presentarse toda la información en la misma ventana sin que se sature mucho la interfaz de usuario.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">La captura de los datos suele requerir validaciones para garantizar que los datos solicitados tengan cierto nivel de consistencia.<span style="mso-spacerun: yes;"> </span>La presentación de errores debería nuevamente minimizar la presentación de cuadros de mensajes en los que no se toma ninguna decisión, esto suele ser incomodo para un usuario ya que debe realizar un clic adicional cada vez que se equivoca debido a la presentación del cuadro de mensaje.<span style="mso-spacerun: yes;"> </span>Una estrategia que simplifica este tipo de problemas es agregar una etiqueta o lista dentro de la misma ventana que presente todos los errores dentro de los datos ingresados.<span style="mso-spacerun: yes;"> </span>No utilice mensajes genéricos como el “campo es inválido” el usuario poco experimentado necesitará información adicional para resolver el problema, a cambio de esto puede complementar el mensaje por ejemplo diciendo “El valor del campo XXX debe ser un número válido”.</span></span></div>
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;"><o:p>Espero que las sugerencias plasmadas en este documento por muy sencillas que parezcan sean tenidas en cuenta para poder cada dia mas disfrutar de una mayor comodidad en nuestros quehaceres informáticos. Adicionalmente agradezco su participación en el desarrollo de estos contenidos y espero sus comentarios.</o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><o:p><span style="font-family: Calibri;"> </span></o:p></span></div>
Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0tag:blogger.com,1999:blog-164232720903282505.post-52240113474485914442012-10-08T19:58:00.002-07:002013-08-27T23:09:33.917-07:00SOBRE EL SOFTWARE Y OTROS PROBLEMASAntes que nada, gracias a todos los lectores con paciencia para revisar los conceptos expuestos en las entradas expuestas. Espero que las mismas sean de utilidad para mis lectores.<br />
<br />
<span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">SOBRE EL SOFTWARE Y OTROS PROBLEMAS</span></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Una situación muy
común en el desarrollo de software que vemos por montones en empresas de
tecnología es la ausencia de los propósitos específicos en la construcción,
muchas empresas esperan obtener buenos resultados en su construcción, sin
embargo sienten que por más esfuerzo que se invierta en el desarrollo, el
software resultante carece de calidad o produce errores no previstos, sienten
que soportar las funcionalidades existentes es una pesadilla y al mismo tiempo
quieren que su software crezca a medida que avanzan las exigencias de los
usuarios.<span style="mso-spacerun: yes;"> </span>Este tipo de situaciones lo
que evidencian es una clara falta de estructura y desconocimiento sobre lo que
hacemos, a continuación se presentan algunas preguntas que suelen ser claves en
la adquisición de este conocimiento y que pueden representar la diferencia
entre alcanzar el resultado que deseamos y fracasar en el intento.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712957"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">¿Qué es
nuestro producto?</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Toda empresa debe
saber de manera clara a que se dedica, si no sabemos lo que queremos no debe
extrañarnos que no obtengamos lo que deseamos.<span style="mso-spacerun: yes;">
</span>Esto lo entienden personas sin educación especializada que administra un
negocio familiar, si se le pregunta, probablemente su respuesta sea “fabrico
zapatos” o “fabrico trajes”.<span style="mso-spacerun: yes;"> </span>Aunque el
software es un tanto más difícil de definir ya que el concepto toma diferentes
significados dependiendo de las soluciones que este brinde a los clientes, el
caso de la producción de software no es la excepción, si pensamos que el
resultado de nuestras operaciones es un conjunto de líneas de código que
implementan diversas funcionalidades, probablemente no hemos definido
apropiadamente nuestro producto.<span style="mso-spacerun: yes;"> </span>El
código fuente de una aplicación es sólo una parte de nuestra fábrica, una parte
muy importante ya que nuestro trabajo se ve reflejado de manera directa en su
funcionamiento, sin embargo, un código fuente que requiere ser modificado
permanentemente<span style="mso-spacerun: yes;"> </span>incrementa los costos al
momento de hacerlo crecer,<span style="mso-spacerun: yes;"> </span>un código
fuente que ha sido el resultado de solucionar situaciones particulares de
negocio probablemente no tenga la generalidad necesaria para ser extensible a
mediano plazo.<span style="mso-spacerun: yes;"> </span>Un código fuente que se
ha creado de manera tal que no se puedan sacarse conclusiones sobre la forma en
la que ejecutamos nuestras tareas es un artículo que únicamente ha generado
valor a los usuarios finales y nos ha impedido adquirir un nuevo conocimiento
sobre la manera en la que hacemos las cosas. Un código fuente cuya calidad no
es susceptible de cuantificarse suele representar un problema frente a futuros
cambios.<span style="mso-spacerun: yes;"> </span>Un código fuente carente de
documentación crea problemas potenciales de dependencias de recursos humanos,
mala comunicación y rendimiento frente a cambios imprevistos de personal.<span style="mso-spacerun: yes;"> </span>Todos estos aspectos tienen sus consecuencias
en los costos de implementación del mismo.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Por las razones
mencionadas anteriormente y muchas otras es necesario que tengamos una visión
clara de lo que esperamos producir que en el caso de software, evidentemente es
algo más que simples líneas de código en un sistema de administración de
versiones.<span style="mso-spacerun: yes;"> </span>Para definir sin ambigüedades
lo que espera que sea su producto tenga en cuenta los siguientes puntos:<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpFirst" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Qué
problema general del mundo real se resuelve con la aplicación del producto
realizado?<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Cuál es el
público objetivo beneficiado de la utilización del producto?<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpLast" style="margin: 0cm 0cm 10pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Que
características agregan mayor valor al producto?<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712958"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">¿Con que
contamos?</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Algo importante para
alcanzar el producto definido previamente es tener una idea realista de los
recursos con los cuales contamos, muchas pequeñas empresas establecen sus
expectativas al nivel de otras empresas que llevan mucho tiempo, años de
experiencia en el desarrollo de software y mucho más personal estructurado y
trabajando en equipo de manera coordinada.<span style="mso-spacerun: yes;">
</span>Esta situación inevitablemente nos llevará a un sobre esfuerzo
(posiblemente inhumano) o a un resultado fallido en nuestro proceso de
construcción.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Con lo anterior no
queremos decir que deba redefinir su producto por uno con un menor alcance, lo
que se pretende es mostrar que existe un conjunto de limitaciones sobre cuanto
podemos producir.<span style="mso-spacerun: yes;"> </span>Aunque no cuente con
los recursos necesarios para asistir a todos los aspectos relacionados con su
producto, Usted siempre tendrá la opción de hacer lo mínimo (siempre que se
haga bien) y postergar las oportunidades de mejora sobre el producto.<span style="mso-spacerun: yes;"> </span>Tenga en cuenta que postergar significa en
este contexto que deberá idear un plan y fijarse unas metas para poder alcanzar
el objetivo, significa que se ha cambiado la prioridad a estas oportunidades y
no que se hayan descartado.<span style="mso-spacerun: yes;"> </span>A medida que
pase el tiempo debemos tratar de darle una prioridad cada vez mayor de otra
manera nunca realizaremos estos trabajos postergados.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Si se le pregunta a un
fabricante de zapatos cuantas suelas tiene, cuántos trabajadores tiene, cuanto
cuero le queda, si tiene martillo o no, probablemente éste le contestará de
manera inmediata y esto se debe a que para la elaboración de sus productos se
tiene inventariada la materia prima, las herramientas, y mucho mas, esto nos
permite estimar cuantos zapatos es capaz de producir dicha fábrica.<span style="mso-spacerun: yes;"> </span>De igual manera en la construcción de
software es conveniente contar con un inventario que nos ayude a inferir la
cantidad y la calidad de lo que podemos producir en un momento dado.<span style="mso-spacerun: yes;"> </span>Para poder realizar esto de manera efectiva,
tenga en cuenta que la materia prima de un equipo de desarrollo de software son
el conocimiento, las habilidades y el talento humano de los miembros del equipo,
hecho por lo cual deberíamos conocer los aspectos mencionados anteriormente en
detalle.<span style="mso-spacerun: yes;"> </span>Tenga en cuenta que la cantidad
y la calidad de las características generadas no son necesariamente
proporcionales al número de miembros del equipo de trabajo, esto se puede
explicar por el desconocimiento de las habilidades que redundan en malas
asignaciones en la construcción o simplemente por los errores introducidos por
la interacción y la mala comunicación entre los miembros del equipo de trabajo.<span style="mso-spacerun: yes;"> </span>Existen proyectos, por ejemplo, con
funcionarios extremadamente calificados que realizan sus asignaciones o tareas
de trabajo en tiempo record y al momento de integrar todo en una misma solución
el proyecto se alarga de manera estrepitosa,<span style="mso-spacerun: yes;">
</span>esto suele ocurrir debido a una distribución inapropiada o a la poca
claridad de las responsabilidades individuales teniendo en cuenta su función
dentro del desarrollo colectivo.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">De una manera bien
estructurada, la fabricación de productos de software puede crecer a medida que
se incrementa la mano de obra, de otra forma simplemente se incurre en
sobrecostos y se extienden las fechas de entrega.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Pero no solo
necesitamos personas y una estructura organizacional, también necesitamos las
herramientas, si ya contamos con herramientas especializadas no hay problema,
sino, deberemos definir si contamos con recursos económicos para adquirirlas o
si podemos hacer uso de herramientas gratuitas disponibles en internet.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712959"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">¿Cómo lo
hacemos?</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Definir la forma en la
que vamos a realizar nuestras operaciones suele ser inicialmente una tarea
ardua y compleja, sin embargo, en el tiempo se mejoraran los procedimientos a
medida que se vayan identificando las necesidades de nuestro equipo de
desarrollo.<span style="mso-spacerun: yes;"> </span>Defina un plan de
mejoramiento continuo sobre sus procesos, esto estará allí recordándole que
existen oportunidades de mejora sobre dichos procedimientos.<span style="mso-spacerun: yes;"> </span>Cada vez que finalice una construcción
identifique aquellas cosas que fueron muy útiles<span style="mso-spacerun: yes;"> </span>en el proceso y las que causaron problemas,
intente darle un orden viendo las actividades como un todo.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712960"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">¿Qué
aprendemos de lo que hacemos?</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Pareciera que muchas
empresas de tecnología trabajan arduamente y obtienen los resultados esperados
en algunas ocasiones, sin embargo, notamos que muchas veces se comienzan a producir
errores en los procedimientos que han ocurrido anteriormente.<span style="mso-spacerun: yes;"> </span>En algunas situaciones no se cuenta con el
tiempo o los recursos suficientes para tomar medidas al respecto, algunas veces
es simplemente falta diligencia en la toma de decisiones.<span style="mso-spacerun: yes;"> </span>Todos estos temas pueden estudiarse con una
simple pregunta <b style="mso-bidi-font-weight: normal;">¿Qué aprendemos de lo
que hacemos?</b><span style="mso-spacerun: yes;"> </span>Esta parece una
pregunta sencilla pero que puede ser muy difícil de responder si no tenemos la disposición
suficiente para autoevaluarnos.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Aprender de lo que
hacemos puede ayudarnos<span style="mso-spacerun: yes;"> </span>en los
siguientes aspectos:<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpFirst" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Nos brinda
posibilidades para mejorar nuestros procedimientos y encausarlos por una
dirección que esté alineada con los objetivos de la construcción.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Nos ayuda
a aprender a detectar donde están las fallas de dichos procedimientos para
poder establecer planes para corregirlas.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Nos
permite agrupar las experiencias y de esta manera identificar áreas de interés
común.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Nos
permite establecer procedimientos claros frente a situaciones particulares para
poder invertir nuestros esfuerzos en aspectos importantes del negocio.<o:p></o:p></span></span></div>
<br />
<div class="MsoListParagraphCxSpLast" style="margin: 0cm 0cm 10pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;">
<span style="font-family: Symbol; mso-ansi-language: ES-CO; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";">
</span></span></span><span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Nos lleva
a cuestionarnos sobre otros aspectos en los procedimientos que anteriormente no
hubiéramos tenido en cuenta.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Esta pregunta puede
dividirse en muchas otras dependiendo de la naturaleza del negocio.<span style="mso-spacerun: yes;"> </span>Por ejemplo, podríamos preguntarnos ¿Qué
hemos aprendido de nuestro manejo con los clientes?<span style="mso-spacerun: yes;"> </span>Esto nos ayudará a mejorar nuestra relación
con los mismos y consecuentemente se reflejará finalmente en su satisfacción y
lealtad.<span style="mso-spacerun: yes;"> </span>Muchas compañías invierten
cantidades significativas de su presupuesto en sistemas de información para la
administración de las relaciones con los clientes y aún así fracasan en sus
estrategias, esto se debe a que no basta con tener los datos,<span style="mso-spacerun: yes;"> </span>no basta con tener la infraestructura sino
que adicionalmente toca comprender de manera objetiva la información.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Otra pregunta que
podríamos hacernos es ¿Qué hemos aprendido de nuestros costos?<span style="mso-spacerun: yes;"> </span>Muchos proyectos de tecnología podrían verse
como “agujeros negros de capital” ya que se invierte en personal calificado, se
invierte en recursos, se invierte en tecnología y aun así los tiempos de
construcción se alargan hasta el infinito lo que finalmente se refleja en los
costos de la construcción.<span style="mso-spacerun: yes;"> </span>Este tipo de
proyectos suelen consumir todos los recursos invertidos y perderlos sin ningún
resultado, esto puede ser consecuencia de un riesgo asumido durante las
negociaciones previas a la construcción o a ideas mal definidas o poco claras
sobre lo que se espera de dicha construcción.<span style="mso-spacerun: yes;">
</span>Una mala o excesiva gestión de los requerimientos podría también
impactar significativamente en los tiempos de implementación.<span style="mso-spacerun: yes;"> </span>Una fábrica podría operar de esta forma en
los desarrollos iniciales, sin embargo si esto se vuelve recurrente
probablemente no estamos aprendiendo nada de lo que hacemos con nuestras
inversiones.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">¿Qué hemos aprendido del
trabajo en equipo?<span style="mso-spacerun: yes;"> </span>El trabajo en equipo
suele adoptar diferentes formas en una organización, esto se debe a factores
externos tales como las relaciones interpersonales,<span style="mso-spacerun: yes;"> </span>aspectos culturales colectivos e
individuales.<span style="mso-spacerun: yes;"> </span>Identificar puntos de
falla y buenas prácticas en nuestro trabajo de equipo nos ayudará a ser más
productivos, a reestructurar ciertas áreas y a visualizar algunas que antes no
se tenían previstas. De manera adicional aprender de nuestro trabajo en equipo
nos ayudará a identificar habilidades dentro de nuestros grupos de trabajo y de
esta manera tener una base experimental a partir de la cual se puedan asignar
de una manera coherente las responsabilidades dentro de los miembros de la
organización, de otra forma termina Albert Einstein siendo un secretario de la
recepción y personas menos capacitadas o menos interesadas en la administración
dirigiendo aspectos fundamentales sin ningún rumbo.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">¿Qué hemos aprendido
de las negociaciones?<span style="mso-spacerun: yes;"> </span>Aparentemente cada
negociación es única y depende de muchos factores en la mayoría
circunstanciales por lo que es difícil tratar de predecir como resultarán, sin
embargo, es necesario que se adopten políticas dependiendo del aprendizaje
previo, de no verse de esta forma se corre el riesgo de tener negociaciones que
redunden en pérdidas para la fabrica.<span style="mso-spacerun: yes;">
</span>Resolver esta pregunta es vital para tener una base sobre el
comportamiento de nuestras negociaciones y poder tomar acciones correctivas y
definir estrategias<span style="mso-spacerun: yes;"> </span>que nos ayuden a
crecer en estos aspectos.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712961"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">¿Podemos medir
nuestros productos?</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Como podría un
zapatero tener utilidades numerosas si no sabe cuánto material gasta en la
construcción de un articulo?<span style="mso-spacerun: yes;"> </span>¿Cómo
podría el mismo saber cuánto puede producir si no conoce su inventario? ¿Cómo
puede establecer el precio del artículo si no conoce las diferencias en calidad
y esfuerzo invertido para cada uno de sus modelos?<span style="mso-spacerun: yes;"> </span>Estas preguntas nos llevan a entender que
mientas más información tengamos de nuestros productos y nuestros procesos
podremos darle el valor.<span style="mso-spacerun: yes;"> </span>En el caso de
la construcción de software una fábrica que no conoce la arquitectura ni el
estado de su código fuente, que no puede medir la producción o que no puede
cuantificar la calidad de sus desarrollos es una fábrica que trabaja a ciegas,
con una incertidumbre muy alta y esperando siempre resultados fantásticos.<span style="mso-spacerun: yes;"> </span>Para tener una visión apropiada al respecto,
debemos pensar primero en nuestras métricas, saber que deseamos medir y<span style="mso-spacerun: yes;"> </span>como repercuten las mejoras a dichas métricas
en el objetivo final de nuestra fábrica.<span style="mso-spacerun: yes;">
</span><o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712962"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">¿Podemos
medir nuestros procedimientos?</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">En nuestra fábrica
podemos medir el tiempo para realizar todas las tareas requeridas para la
producción del software?<span style="mso-spacerun: yes;"> </span>Probablemente
el zapatero si lo sabe. En muchas ocasiones los gerentes de proyectos de
tecnología no conciben la idea de no poder estimar cuanto tomará en tiempo por
ejemplo la definición de los requerimientos de determinada aplicación, o cuanto
tomará en recursos la construcción de un módulo o una funcionalidad.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712963"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">¿Podemos
predecir los impactos? ¿En cuántos Niveles?</span></span></a><span style="mso-ansi-language: ES-CO;"><o:p></o:p></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Predecir el impacto
que pueda producir un cambio sobre una solución no es una tarea fácil si no se
tiene una idea general suficientemente clara de la estructura de nuestros
desarrollos, existen relaciones y reglas conceptuales o implícitas entre las
componentes de nuestro producto que no se reflejan de manera directa en la
programación y mientras menos información se tenga sobre las dependencias de
cada uno de los componentes que conforman la solución o conjunto de soluciones,
será más difícil estimar dicho impacto.<span style="mso-spacerun: yes;">
</span>El diseño dirigido por modelos arquitectónicamente bien construidos
suele ser una aproximación interesante y poderosa al momento de asignar e
identificar claramente dependencias entre componentes con distintas responsabilidades.<span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Como usualmente
ocurre, una solución por software a un problema general estará compuesta de un
subconjunto de problemas particulares e independientes que de manera conjunta
interactúan para dar una solución completa a un caso de negocio específico.<span style="mso-spacerun: yes;"> </span>De esta manera algunos estructuran el
software en capas, otros en anillos, otros por funcionalidad, sin embargo,
parece que no importa de qué manera delimitemos las componentes de nuestro
desarrollo, siempre debería ser posible cuantificar cuantos niveles se
afectarían por los cambios realizados.<span style="mso-spacerun: yes;">
</span>Si ya tenemos el conocimiento sobre el número de dependencias sobre los
componentes de la solución, entonces debemos dar el siguiente paso, y este
consiste en diagnosticar los segmentos de código que podrían presentar efectos
indeseados.<span style="mso-spacerun: yes;"> </span>Posteriormente se presentan
algunas estrategias para combatir este tipo de problemas.<o:p></o:p></span></span></div>
<br />
<h2 style="margin: 10pt 0cm 0pt;">
<a href="http://www.blogger.com/null" name="_Toc237712964"><span style="mso-ansi-language: ES-CO;"><span style="color: #4f81bd; font-family: Cambria; font-size: medium;">¿Tenemos
problemas heredados del pasado?</span></span></a><span style="mso-ansi-language: ES-CO;"><span style="font-size: medium;"><span style="color: #4f81bd;"><span style="font-family: Cambria;">
¿Cómo los combatimos?<o:p></o:p></span></span></span></span></h2>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="mso-ansi-language: ES-CO;"><span style="font-family: Calibri;">Los problemas
heredados del pasado suelen ser una de las causas más relevantes de resistencia
a cambios al momento de revaluar la arquitectura de un producto.<span style="mso-spacerun: yes;"> </span>Si se plantea reestructurar una solución de
software, pensamos inmediatamente en problemas de arquitectura que se presentan
actualmente debido a correcciones del pasado que aún se soportan.<span style="mso-spacerun: yes;"> </span>Como combatimos estas circunstancias?<span style="mso-spacerun: yes;"> </span>Una forma es separar la implementación comercial
de la implementación reestructurada. <span style="mso-spacerun: yes;"> </span><o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
</div>
Anwar Ibáñez O'Kamelhttp://www.blogger.com/profile/03354594486919170632noreply@blogger.com0