Mitos del software

Ahora en la actualidad, la mayoría de profesionales de la ingeniería de software reconocen los mitos como lo que son: actitudes equivocadas que han ocasionado serios problemas a los administradores y a los trabajadores por igual. sin embargo, las actitudes y hábitos antiguos son dificíles de modificar, y persisten algunos remanentes de los mitos del software.

A continuación voy a listar los mitos más comunes del Software:

• Mitos de la administración. Los gerentes que tienen responsabilidades en el area del software, como también otras disciplinas, con frecuencia se hallan bajo presión para cumplir el presupuesto.

• Mito: Tenemos un libro lleno de estándares y procedimientos para elaborar software. ¿no le dará a mi personal todo lo que necesita saber?

• Realidad: Tal vez exista el libro de estándares, pero ¿se utiliza? ¿saben de su existencia los trabajadores del software? ¿refleja la práctica moderna de la ingeniería de software? ¿es completo? ¿es adaptable? en muchos casos las respuestas a estas preguntas es: no.

1. Mito: Si nos atrasamos, podemos agregar más programadores  y ponernos al corriente.

• Realidad: El desarrollo del software no es un proceso mecánico similar a la manufactura. en palabras de Brooks: "agragar personal a un proyecto de software atrasado lo atrasará más". a inicio, esta afirmación parece ir contra la intuición. sin embargo, a medida que se agregan personas, las que ya se encontraban trabajando deben dedicar tiempo enseñando a los recién llegados.

• Mito: Si decido subcontratar el proyecto de software a un tercero, puedo descansar y dejar que esa compañia lo elabore.

• Realidad: Si una organización no comprende cómo administrar y controlar proyectos de software internamente, de manera invariable tendrá dificultades cuando subcontrate proyectos de software.

• Mitos del cliente. El cliente que requiere software de computadora puede ser la persona en el escritorio de al lado, un grupo técnico en el piso inferior, el departamento de mercadotecnia por ejemplo. En muchos casos, el cliente sostiene mitos sobre el software porque los gerentes o prefesionales de éste hacen poco para corregir la mala información. Los mitos generan falsas espectativas (por parte del cliente) y, en la última instancia, la insatisfacción con el desarrollador.

• Mito: para comenzar a escribir programas, es suficiente el enunciado general de los objetivos.

• Realidad: Aunque no es posible tener el enunciado axhaustivo y estable de los requerimientos, un "planteamiento de objetivos" ambiguo es una receta para el desastre. Los requerimientos no son ambiguos (por que por lo general se obtienen de forma iterativa) se desarrollan sólo por medio de una comunicación eficaz y continuan entre el cliente y el desarrollador.

• Mito: Los requerimientos del software cambian continuamente, pero el cambio se asimila con facilidad debido a que el software es flexible.

• Realidad: Es verdad que los requerimientos del software cambian, pero el efecto que los cambios tienen varían según la época en la que se introducen. cuando se solicitan al principio cambios en los requerimientos (antes de que haya comenzado el diseño o elaboración de código), el efecto sobre el costo es relativamente pequeño. Sin embargo, conforme pasa el tiempo, el costo aumenta con rapidez: los recursos ya se han comprometido, se ha establecido la estructura del diseño y el cambio ocasiona perturbaciones que exigen recursos adicionales y modificaciones importantes en el diseño.

Tomado de: Mitos del software

Tipos de Outsourcing de TI

Tomado de: Tipos de Outsourcing de TI

Se han definido distintos tipos de outsourcing de TI, la mayoría de las categorías y tipos distintos tiene peculiaridades propias y configuran un tipo de servicio único. En el proceso de contratación (o revisión) deberán tenerse en cuenta las diferentes posibilidades para configurar nuesro porpio menú de servicios y modelos de relación. A continuación listamos algunos de estos tipos de outsourcing.

 

• Outsourcing Informático Tadicional

Presenta un enfoque más táctico que estratégico. Supone la transferencia de la gestión a un proveedor externo que podría llegar a asumir activos físicos de la compañía, e incluso, a parte de los empleados de la misma. Se centra en actividades y activos gestionados por el proveedor. Los servicios típicos en este esquema son: gestión micro-informática, de redes, de aplicaciones o de seguridad entre otros.

• Outsourcing de Procesos de Negocio

También conocido como outsourcing transformacional o Business Process Outsourcing (BPO) dado que pretende transformar la organización de una forma sustancial. Representa la delegación de uno o más procesos de negocio a un proveedor externo que administra y gestiona estos procesos. En este caso los activos, personas y actividades realizadas pasan a un segundo plano pasando a ser mucho más relevantes los aspectos del proceso. Por ejemplo, si disponemos de un sistema que genera la nómina podemos establecer un contrato de outsourcing para que las nóminas sean gestionadas conforme a unos determinados parámetros del servicio. Las áreas típicas en esta modaldiad son la gestión de procesos de áreas como la de recursos humanos, administración, finanzas, relación con clientes o bien la logística o procesos completos de TI.

 

• Outsourcing Total

El proveedor gestiona todos los servicios informáticos de la organización. Normalmente permite (dadas las economías de escala) obtener tarifas más competitivas a cambio de incrementar el riesgo de tener ligado todos los servicios a un solo agente.

 

• Outsourcing Parcial

El proveedor gestiona algunos de los servicios y sistemas informáticos de la organización. Limita el riesgo de que el proveedor no sea competente o exitoso introduciendo competencia entre proveedores. Sin embargo aumenta los costos del servicio y los de transacción y puede generar problemas de gestión y conflictos entre los distintos actores.

 

• Proveedor único

Estrategia mixta entre el outsourcing total y el parcial donde para ciertos procesos, áreas, sistemas se dispone de un solo proveedor pero se dispone de otros diferentes que permiten compensar la exposición al riesgo en otras áreas o funciones.

 

• Pseudo-Outsourcing

Estrategia desarrollada por grupos empresariales, y que consiste en crear empresas dedicadas específicamente a gestionar la informática de todas las empresas del grupo. Es desarrollada principalmente por grandes grupos empresariales y salvo que la transición sea tomada con la suficiente independencia y audacia, muchas de las ventajas del outsourcing desaparecerán dado que la transformación será mucho menor que si se utiliza un tercero.

 

• Outsourcing de Transición

Solución a un problema temporal, como la transición a un nuevo sistema. El proveedor gestiona el sistema antiguo mientras que el personal informático del comprador implementa un nuevo sistema (o viceversa). Esto permite liberar recursos sobre proyectos o productos "maduros" a terceras partes para concentrarse en acciones de un mayor valor añadido o estratégico. Es un enfoque más táctico que estratégico pero que puede extenderse si la situación es ventajosa para ambas partes y terminar siendo una relación más duradera.

 

• Outsourcing Extraterritorial (Offshore)

Estrategia que contrata a profesionales en otros países, sacando ventaja de aspectos económicos, tecnológicos, etc. Son conocidos los grandes contratos de outsourcing de las grandes multinacionales en La India, China, Brasil o Argentina. Los reducidos costes de estos recursos humanos y el gran avance y abaratamiento de las telecomunicaciones y tecnologías de virtualización permiten disponer de centros de cómputo, fábricas de software o gestión de proyectos a varios usos horarios de las sedes de las compañías. Las principales dificultades de este modelo son las diferencias culturales (costumbres, regulaciones) de comunicación y coordinación entre los diferentes centros productivos.

 

• Participación del Capital

Usado frecuentemente a la hora de crear nuevas empresas o uniones temporales de empresas para un fin determinado. Pueden resultar de gran utilidad como alianzas de empresas, Joint-ventures o asociaciones que permitan obtener sinergias en las dos partes. Normalmente el proveedor ofrecerá los recursos humanos, el conocimiento experto y la posición de mercado mientras que el cliente ofrecerá el músculo financiero suficiente y calidad crediticia suficiente para poder llevar los proyectos adelante. Adicionalmente, el cliente podrá ofrecer otros servicios generales o específicos en los que tenga ventajas (servicios jurídicos, limpieza, inmuebles, etc.).

 

• Multiaprovisionamiento

Comprende la contratación de varios proveedores de servicio en una o diferentes áreas para disponer de mayor flexibilidad e independencia del proveedor especiamente en servicios que sean menos maduros y probados en el contexto de la organización. El riesgo de esta estrategia resulta en problemas de coordinación, comunicación, falta de homogeneidad entre otros, al convivir distintos incentivos, intereses y prácticas operativas en la gestión de las TI.

 

• Outsourcing Estratégico

También denominado Business Process Management y tiene un enfoque totalmente estratégico dado que no sólo pretende externalizarse el proceso de negocio sino que también se comparten con el proveedor estructuras de capital, financiación y sobre todo el éxito o fracaso de la empresa. En este modelo el cliente, financiación y sobre todo el éxito o fracaso de la empresa. En este modelo el cliente potencia el desarrollo del proveedor y en cierta forma "invierte" en el proveedor promoviendo el crecimiento y los beneficios de este. Este fortalecimiento del proveedor se persigue para conseguir una mejora continua y reingeniería de procesos que redundarán, a la postre, en ventajas operativas y eficiencias económica.

El cambio sobre los procesos es continuo, todo lo asociado al proceso es susceptible de ser modificado a fin de obtener la mayor eficiencia. Las funciones del proveedor se integran dentro de la empresa para obtener el mayor alineamiento posible. Este tipo de outsourcing no está libre de riesgos por el fuerte acoplamiento con los proveedores y la exposición al riesgo de los mismos.

 

• Ejemplo comercial: E-Business on demand de IBM

Basado en los siguientes principios:

• Integradora de los proceso de negocio de una empresa, de los socios, proveedores y clientes claves.
• Elemento flexible y rápido para dar respuesta a las necesidades de los clientes, oportunidades del mercado o amenazas externas.
• Elemento autogestionado, que permite a las empresas concentrarse en sus objetivos de negocio.

Las organizaciones deben entender que el outsourcing es una opción que incorpora una estrategia financiera y de competitividad a largo plazo. No considerarlo así puede crear falsas expectativas y limitar los beneficios que se pueden derivar de un acuerdo de este tipo. Combinar las características de distintos tipos de outsouring puede ser la mejor estrategia en cada caso a fin de poder encontrar la mejor estrategia para nuestra organización.

El Proceso Unificado en el Software

inShare1

Buen día chicos espero se encuentren muy bien, el dia de hoy estaremos hablando del Proceso Unificado en el Software. En la actualidad, la tendencia en el software es hacia sistemas mas grandes y complejos. Eso de debe en parte al hecho de que año tras año las computadoras son más poderosas, lo que hace que los usuarios esperen más de ellas. te invitamos que te quedes con nosotros y continues leyendo.

Fases del proceso Unificado

Fase de Concepción del PU (Proceso Unificado) agrupa tanto actividades tanto de comunicación con el cliente como de planeación. Al colaborar con los participantes, se indentifican los requerimientos del negocio, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental (vistos en articulos anteriores) del proyecto en cuestión. estos requerimientos detallan las características y funciones que desea cada clase principal de usuarios.

Fase de Elaboración incluye las actividades de comunicación y de modelado del modelo general del proceso. la elaboración mejora y amplía los casos de uso preliminares desarrollados como parte de la fase de la concepción y aumenta la representación de la arquitectura para incluir 5 puntos de vista distintos del software: los modelos de casos de uso, de requerimientos, de diseño, de la implementación y del despliegue.

Fase de la Construcción del PU es idéntica a la actividad de construcción definida por el proceso de general del software. la fase de construcción desarrolla o adquiere los componentes del software que harán que cada caso de uso sea operativo para los usuarios finales. para lograrlo, se completan los modelos de requerimientos y diseño que se comenzaron durante la fase de la elaboración. Después se implementan en en código fuente todas las características y funciones necesarias para el incremento de software.

Fase de Transición del Proceso Unificado incluye las últimas etapas de la actividad general de construcción y la primera parte de la actividad de despliegue general (entrega y retroalimentación). se da el software a los usuarios finales para las pruebas beta, quienes reportan tanto los defectos como los cambios necesarios.

Fase de Producción en esta fase se vigila el uso que se le da al software, se brinda apoyo para el ambientede operación (infraestructura)  y se reportan los defectos y solicitudes de cambio para su evaluación.

Tomado de:El Proceso Unificado en el Software

Los niveles de capacidad de CMMI

inShare3

Un nivel de capacidad consiste en una meta genérica y sus prácticas genéricas relacionadas en la medida que se relacionan con un área de proceso, las cuales pueden mejorar los procesos de la organización asociados con esa área de proceso. En la medida que se satisface la meta genérica y sus prácticas genéricas en cada nivel de capacidad, se obtienen los beneficios de mejora de procesos para esa área de proceso.

Los seis niveles de capacidad, especificados por los números 0 hasta 5, son los siguientes:

0. Incompleto
1. Realizado
2. Gestionado
3. Definido
4. Gestionado cuantitativamente
5. En optimización

El hecho de que los niveles de capacidad 2 a 5 utilicen los mismos términos que las metas genéricas 2 a 5 es intencionado, por que cada una de estas metas genéricas y prácticas genéricas reflejan el significado de los niveles de capacidad en términos de metas y práctica que se pueden implementar. Los niveles de capacidad son los siguientes:

Nivel de capacidad 0: Incompleto

Un "proceso incompleto" es un proceso que, o bien no se ejecuta, o se ejecuta parcialmente. Al menos una de las metas específicas del área del proceso no se satisface y no existe metas genéricas para ese nivel, ya que no hay ninguna razón para institucionalizar un proceso ejecutado parcialmente.

Nivel de capacidad 1: Realizado

Un proceso de nivel de capacidad 1 se caracteriza como un "proceso realizado". Un proceso realizado es un proceso que satisface las metas específicas del área de proceso. Soporta y permite el trabajo necesario para producir los productos del trabajo.

Aunque el nivel de capacidad 1 da como resultado mejoras importantes, esas mejoras pueden perderse en el tiempo si no se institucionalizan. La aplicación de la institucionalización (las prácticas genéricas de CMMI en los niveles de capacidad 2 a 5) ayudan a asegurar que las mejoras se mantendrán.

Nivel de capacidad 2: Gestionado

Un proceso de nivel de capacidad 2 se caracteriza como un "proceso gestionado". Un proceso gestionado es un proceso realizado (nivel de capacidad 1) que tiene la infraestructura básica dispuesta para soportar el proceso. Se planifica y ejecuta de acuerdo a políticas; emplea personal con habilidades; tiene los recursos adecuados para producir resultados controlados; involucra a las partes interesadas relevantes; se monitoriza, controla y revisa; y se evalúa la adherencia a su descripción del proceso. La disciplina de proceso reflejada por el nivel de capacidad 2 ayuda a asegurar que las prácticas existentes se mantienen durante tiempo de estrés.

Nivel de capacidad 3: Definido

Un proceso de nivel de capacidad 3 se caracteriza como un "proceso definido". Un proceso definido es un proceso gestionado (nivel de capacidad 2) que se adapta a partir de un conjunto de procesos estándar de la organización, de acuerdo a las guías de adaptación de la organización, y contribuye a los activos de proceso d ela organización con productos del trabajo, medidas e información adicional de mejora de procesos.

Una distinción crítica entre los niveles de capacidad 2 y 3 es el alcance de los estándares, descripciones de proceso y procedimientos. En el nivel de capacidad 2, los estándares, descripciones de proceso y procedimientos pueden ser bastante diferentes en cada instancia específica del proceso. En el nivel de capacidad 3, los estándares, descripciones de proceso y procedimientos para un proyecto se adaptan a partir del conjunto de procesos estándar de la organización, para ajustarse a un proyecto o unidad organizativa particular, y son, por tanto, más consistentes, excepto para las diferencias permitidas por las guías de adaptación.

Otra distinción crítica es que en el nivel de capacidad 3, los procesos se describen normalmente de forma más rigurosa que en el nivel de capacidad 2. Un proceso definido establece claramente el propósito, las entradas, criterios de entrada, actividades, roles, medidas, etapas de verificación, salidas y criterios de salida. En el nivel de capacidad 3, los procesos se gestionan de forma más proactiva utilizando una comprensión de las interralaciones de las actividades dle proceso y de las medidas detalladas del proceso, de sus productos del trabajo y de sus servicios.

Nivel de capacidad 4: Gestionado cuantitativamente

Un proceso de nivel de capacidad 4 se caracteriza como un "proceso gestionado cuantitativamente". Un proceso gestionado cuantitativamente es un proceso definido (nivel de capacidad 3) que se controla utilizando técnicas estadísticas y otras técnicas cuantitativas. Se establecen los objetivos cuantitativos de calidad y de ejecución del proceso, y se utilizan como criterios para gestionar el proceso. Se comprende la calidad y el rendimiento del proceso en términos estadísticos y se gestionan a lo largo de la vida del proceso.

Nivel de capacidad 5: En optimización

Un proceso de nivel de capacidad 5 se caracteriza como un "proceso en optimización". Un proceso en optimización es un proceso gestionado cuantitativamente (nivel de capacidad 4) que se mejora en base a una comprensión de las causas comunes de variación inherentes al proceso. El enfoque de un proceso en optimización es mejorar continuamente el rango de la ejecución del proceso mediante mejoras, tanto incrementales como innovadoras.

Tomado de: Articulo Original

La guía definitiva para optimizar imágenes

Optimizar imágenes JPG/GIF/PNG y consejos técnicos sobre cómo reducir el tamaño de nuestra web o blog para que cargue más rápido.

Si acostumbramos a escribir en un blog o crear sitios web, obviamente, utilizaremos imágenes para decorar o complementar nuestros textos de una forma gráfica y atractiva. Las imágenes son un recurso necesario e imprescindible para conseguir mantener la atención del público y evitar aburrirlos.

Sin embargo, no siempre las utilizamos correctamente, bien por desconocimiento, por descuido (y falta de tiempo) o por no tener la base de conocimiento necesaria para utilizarlas correctamente.
En este artículo veremos una guía para optimizar imágenes en nuestro sitio web, de una forma efectiva, con un buen equilibrio entre calidad de imagen y tamaño de imagen.

Imágenes pesadas = sitio web lento

Una página web contiene varias imágenes. Desde los pequeños iconos que incorpora hasta las grandes imágenes que ilustran las entradas o artículos. Para el usuario, cargar cada imagen es un pequeño retardo en la carga del sitio web.
Esto es algo bastante importante. Una web lenta es sinónimo de pérdida de usuarios (abandonan o buscan otras webs, cansados por la lentitud de carga), pero además ahora sabemos que Google le da importancia a la velocidad de carga de una web, por lo que será algo que influye a la hora de posicionarse en Google.

 

La suma de todas las imágenes utilizadas en un sitio puede ser considerable.

Cada página de nuestra web, contiene varias imágenes en diferentes formatos (y muchas veces, poco apropiados) que habrá que descargar al acceder a ella. Es por esta razón, que lo ideal sería disminuir lo máximo posible el tamaño de cada una de ellas, para que ocupen menos y se descarguen antes, incluso en usuarios con conexiones lentas.

En el artículo Optimizar el rendimiento web, hago un repaso más detallado y técnico de los aspectos que pueden retrasar la carga de una web: número de peticiones, tipo de servidores, sistemas de caché, descargas paralelas, sistema lazy load, etc...

La decisión: ¿JPG, PNG o GIF?

La primera pregunta que nos podemos plantear es: ¿Qué formato de imagen debo utilizar? Existen multitud de formatos de imagen, algunos nuevos, otros más desconocidos (como por ejemplo: WEBP, JPEG2000, JPEG-XR...). Lo más importante es conocer la diferencia entre los formatos con pérdidas y los formatos sin pérdidas. Puedes saber más en la siguiente guía de formatos de imágenes.
Nosotros nos basaremos en los tres más utilizados: JPG, PNG y GIF. A grandes rasgos, el método más sencillo para saber que formato utilizar, es el siguiente:

 

 

• Formato JPG: Fotografías. Muchas texturas. Detalles complejos. No nos importa perder parte de calidad de la imagen original.
  Ejemplo: Una bonita fotografía de Mordor y el ojo de Sauron.
• Formato PNG: Capturas de pantalla. Dibujos. Bocetos. Imágenes en las que hay amplias zonas «lisas» con el mismo color.
  Ejemplo: Ilustración del artículo shooters de los 90, con dibujos y zonas de color uniforme.
• Formato GIF: Similar a PNG, pero actualmente utilizado sólo para imágenes animadas.
  Ejemplo: Una imagen animada de Larry Leisure Suit leyendo el periódico.

¿JPG o PNG? Artefactos de compresión

Es posible que llegado a este punto, no estés seguro si utilizar JPG o PNG para tus imágenes. No hay problema. Vamos a aclararlo.
Ambos formatos son comprimidos internamente para conseguir ocupar menos espacio en disco:

• Imágenes JPG: Con un valor entre 1 y 100 (más alto, menor compresión y mayor tamaño)
• Imágenes PNG: Con un valor entre 0 y 9 (más alto, mayor compresión y menor tamaño)

Antes de continuar, seguro que conoces un desagradable efecto producido en los archivos JPEG (con alto grado de compresión): unas feas marcas alrededor de ciertos objetos en imágenes:

Una imagen PNG y una imagen JPG del mismo tamaño (19KB).

Estas marcas se denominan artefactos de compresión, y se producen debido a que las imágenes JPG son un formato de imagen con pérdidas: para conseguir que ocupen menos, reducimos la calidad de la imagen (perdiendo nitidez).
En contraposición, las imágenes PNG son un formato de imagen sin pérdidas: para conseguir que ocupen menos, se utilizan algoritmos de compresión «reversibles», que no reducen tanto el tamaño, pero consiguen no introducir artefactos.

Obviamente, cada formato es útil para cada caso concreto. Simplificando, la norma general suele ser; utilizar imágenes JPG para fotografías y utilizar imágenes PNG para imágenes que contengan zonas de color uniformes.

Optimizar imágenes con RIOT

Para optimizar las imágenes de forma sencilla y cómoda, existe un programa gratuito ideal: RIOT: Radical Image Optimization Tool, que incluso puede utilizarse a modo de plugin si utilizas algún programa como IrfanView, GIMP o XnView.

Este programa permite optimizar imágenes mediante un panel donde podemos ver la diferencia de tamaño de la imagen original y optimizada, la calidad de la imagen, un selector del tipo de formato gráfico que queremos utilizar, así como algunas opciones comunes: rotar, invertir, redimensionar y comprimir imagen a un tamaño en KB concreto.
Para cada formato distinto (JPG, GIF o PNG) tendremos un panel diferente en la parte baja, donde elegir el tipo de compresión, así como ajustes de imagen (brillo, contraste, etc...).

RIOT también incorpora un plugin RAW-HDR (colocar en carpeta plugins) para permitir abrir archivos HDR como EXR o HDR, o archivos RAW de cámaras digitales como NEF, RAW, RAF, CRW, CR2, entre muchos otros.

Algoritmos de redimensionado

Ya en la guía de productividad con Irfan View (punto 5) hable de los algoritmos de redimensionado. De la misma forma, RIOT permite ampliar o reducir las imágenes utilizando un algoritmo concreto de la siguiente lista:

Si esta forma se te queda grande, prueba con Cómo reducir una imagen.

Cada uno de ellos proporciona un resultado distinto, lo que lo hace ideal para diferentes situaciones. Por ejemplo, el algoritmo Box es ideal para ampliaciones de imágenes de 8 bits (conservando bordes definidos), mientras que Lanczos3 es ideal para ampliar fotografías (interpolación de imágenes).

Optimizando PNG (obsesivamente)

Uno de los trucos para optimizar imágenes PNG es la de «contabilizar los colores» que utiliza una imagen. Como hacerlo a mano sería muy tedioso y una tarea bastante repetitiva, podemos hacer uso de IrfanView, accediendo a la opción Image / Information, o pulsando la tecla I.
Veremos que en la linea Number of unique colors nos indicará el número de colores (únicos) que utiliza la imagen.

House y Wilson, a 8 bits.

Otra forma sencilla de contabilizar los colores, es utilizando ImageMagick, escribiendo en una terminal de Windows o Linux la línea identify -format "%k" imagen.png.

Debemos saber que los archivos PNG se suelen categorizar en varios tipos (PNG8 es un concepto introducido por Adobe):

• PNG24: También llamado PNG (True color). Se trata de la imagen a alta calidad. Es equivalente en calidad (o incluso superior) a una imagen JPG con 100 de nivel de compresión, pero también es considerablemente más grande en tamaño.
• PNG8: Se trata del mismo formato PNG pero con una paleta de colores indexada. Esto significa que, en imágenes que utilicen pocos colores (alrededor de 256 colores, o menos) podemos optimizarla para que ocupe un tamaño menor. Opción muy útil.

Reduciendo colores

Teniendo en cuenta lo anterior, podemos utilizar RIOT para ajustar el número de colores de una imagen PNG (y así su tamaño). En la zona inferior izquierda, ponemos seleccionar entre True color y Optimal 256 Colors Palette (o inferiores) para ir limitando el número de colores de la imagen.
También podemos hacerlo de forma manual, estableciendo el número de colores en la barra de desplazamiento inferior (Reduce colors to) y observando los cambios en la imagen de la derecha (Optimized image).

Marcando la casilla Best compression (slow), conseguiremos una mejor compresión a un precio muy bajo (lentitud al comprimir la imagen), por lo que es recomendable mantenerla activa.

Más a la derecha, nos encontraremos con un panel denominado Color quantization algorithm. En el caso de haber elegido realizar una optimización de una imagen PNG con paleta indexada (256 colores o menos) debemos elegir un algoritmo de cuantificación.
Este algoritmo se encargará de reducir los colores de la imagen (en el caso de tener más de 256) y elegir colores similares alternativos para convertirlos a un único color. Disponemos de dos algoritmos:

• Xiaolin Wu color: El método por defecto y recomendado (ya que es el más rápido de los dos).
• NeuQuant neutral-net: Otro método alternativo, basado en redes neuronales de Kohonen. Es más lento, pero puede ser útil en algunas ocasiones para reducir el efecto de «círculos concéntricos» generado en algunos gradientes.

PNG Entrelazado (Carga progresiva)

Si nos fijamos bien, en la zona inferior izquierda, hay una casilla denominada Interlaced. Esta casilla permite crear una imagen PNG entrelazada.
Estableciendo nuestra imagen como un PNG entrelazado, la imagen podrá ser cargada mediante el Algoritmo Adam7 (en el enlace se ve claramente como realiza la carga), mostrando una versión de baja resolución que se irá volviendo nítida de forma progresiva, en 7 pasadas.

Esto consigue una sensación de carga más rápida, sin embargo, todo tiene un precio: el tamaño de la imagen se eleva un pequeño porcentaje al activar esta característica.

Optimizadores externos

Finalmente, en el panel External optimizers se pueden configurar aplicaciones externas para optimizar (aún más) nuestra imagen. Por defecto se incorporan tres optimizadores (al pulsar sobre ellos, se descargan automáticamente): AdvPNG, OptiPNG y PNGout.

Sin embargo, podemos añadir nuestros propios optimizadores, ampliando la lista (pulsando en el símbolo de suma en fondo verde) y haciendo nuestras propias pruebas. A continuación, una lista de optimizadores externos que podemos utilizar:

Tool Name	Tool Path	Parameters
AdvPNG Insane (fast)	advpng.exe	-4 {IMAGE_FILE}
OptiPNG o3	optipng.exe	-o3 {IMAGE_FILE}
PNGout Xtreme (very slow)	pngout.exe	/s0 {IMAGE_FILE}
ImageMagick PNG8	convert.exe	{IMAGE_FILE} -type Palette {IMAGE_FILE}
PNGcrush (brute force)	pngcrush.exe	-reduce -brute {IMAGE_FILE} {IMAGE_FILE}
PNGquant PNG8	pngquant.exe	--force --verbose 256 {IMAGE_FILE}
DeflOpt	DeflOpt.exe	{IMAGE_FILE}
pngnq-s9	pngnq.exe	{IMAGE_FILE}
PNGrewrite PNG8	pngrewrite.exe	{IMAGE_FILE} {IMAGE_FILE}
PngOptimizerCL	PngOptimizerCL.exe	-file:"{IMAGE_FILE}"

 

Si conoces más optimizadores de archivos PNG que no estén en la lista, puedes compartirlos con nosotros en los comentarios del artículo. Por otra parte, si buscas más aplicaciones para optimizar imágenes (con interfaz gráfico o incluso alternativas online) puedes consultar esta lista de 12 aplicaciones para optimizar imágenes, tanto para imágenes PNG, como imágenes JPG o GIF.

Tomado de: Articulo

Iseries Db2 A Mysql con Migration Toolkit

Una de las tareas recurrentes a la que nos enfrentamos quienes estamos dedicados al desarrollo de sistemas o a la administración de bases de datos es la migración de información entre difrentes o iguales SGBD.  Actualmente, cada motor de base de datos ofrece en mayor o menor medida, herramientas que facilitan estas tareas. En este artículo trataré el caso de Mysql que incluye  en su paquete de instalación un programa destinado a migrar datos desde cualquier motor que proporcione una interfaz de conexión JBDC.
Que necesitaremos?
Bueno, antes de iniciar con el proceso será necesario que tengas instalado en tu equipo lo siguiente:

• Mysql Gui Tools.  Esto lo puedes descargar desde la página de mysql en http://www.mysql.com/
• Mysql Migration Toolkit. Este programa está incluido en las Gui Tools y lo podrás encontrar en el menú Inicio / Programas / Mysql
• IBM Iseries Access for Windows.  Esto lo puedes descargar de la página de IBM
• También tendrás que tener instalado el JDK de java pues la comunicación será a través de JBDC

Para el artículo quiero suponer que ya  sabes como instalar las herramientas de conexión por lo que me enfocaré al proceso de migración.
 Lo primero que tendremos que hacer es copiar los .jar  de IBM que nos permitirán comunicarnos con Iseries. Para ello, dependiendo de tu sistema operativo, iremos a la carpeta de instalación del client access que en mi caso es:  C:\Program Files\IBM\Client Access  Luego buscaremos la ruta jt400 y entraremos a lib.  La ruta de acceso completa es: C:\Program Files\IBM\Client Access\jt400\lib. Una vez que hemos llegado a este directorio vamos a seleccionar los siguientes archivos de extensión Jar:

• jt400.jar
• jt400Servlet.jar
• jui400.jar
• uitools.jar
• util400.jar
• x4j400.jar

y los copiaremos al directorio Java / Lib del directorio de instalación de las Gui Tools de Mysql. En mi caso este directorio es: C:\Program Files\MySQL\MySQL Tools for 5.0\java\lib.  Muy bien, hecho lo anterior, hemos incluido el soporte para comunicarnos a Iseries Db2.
Ahora. ejecutaremos el programa “Mysql Migration ToolKit” que está en Inicio / Programas / Mysql  la pantalla inicial que veremos es la siguiente:
 


  Esta pantalla es muy importante  pues nos permite saber si el programa cuenta con los requerimientos mínimos para ejecutarse. Como podemos observar en la imagen a la izquierda, tanto el Java Loader como el entorno de ejecución deben encontrarse inicializados.
Hecho esto presionamos el botón “Next” para continuar a la pantalla “configuration type”



Aquí nos aparecerán dos opciones. Para el caso que nos ocupa seleccionaremos “Direct Migration”


Después presionaremos “Next” para continuar con el proceso.  El programa nos mostrará la pantalla “Source Database”. Es en esta pantalla donde estableceremos la configuración del origen de datos.  


Al dar click en Database System,  veremos que el programa soporta la migración por default de orígenes tan diversos como SqlServer, Oracle, Sybase, Etc. Para casos como el de DB2 que no está contemplado por defecto, tendremos que seleccionar “Generic Jdbc”.  Seleccionado esto nos aparecerá en la parte inferior de la ventana , el cuadro de configuración de la conexión.

La información que deberemos capturar es la siguiente:

• Class Name: Es el nombre de la clase java a usar para conectarnos a Iseries. El valor a capturar es: com.ibm.as400.access.AS400JDBCDriver
• Connection String: La cadena de conexión que se compone de jdbc:<clase>://<dsn o ip del servidor iseries>>/<instancia>;libraries:<Base de datos o schema>;socket timeout=3000000;thread used=false Quedando en mi caso de la siguiente manera: jdbc:as400://DNSNOMBSERVIDOR/NOMBLIB;libraries=MIDATABASE;socket timeout=3000000;thread used=false
• Username: Nombre de usuario
• Password: Password de acceso.

Como ejemplo:

• Class Name: com.ibm.as400.access.AS400JDBCDriver
• Connection String: jdbc: as400://192.168.200.5/SEGURI;libraries=SEGURI;socket timeout=3000000;thread used=false
• User Name: Usuario
• Password: Password

Ya que hemos capturado la información de conexión presionaremos “Next” para dirigirnos a la siguiente pantalla donde configuraremos la conexión al servidor de base de datos destino.

 Ya que la base de datos destino es el propio mysql, la configuración nos va a resultar familiar pues solo deberemos indicar ip del servidor, nombre de usuario y contraseña.  Presionamos ”Next” para continuar a la siguiente pantalla, donde, si hemos configurado correctamente nuestras conexiones nos mostrará la siguiente información.

 Hasta este punto solo hemos configurado la conexión entre mysql y Db2 por lo que al presionar el botón “Next” comenzaremos a configurar tanto el origen como el destino de los datos a migrar. La pantalla  que nos aparece “Source schemadata selection” nos muestra los schemas del servidor de base de datos y nos pide seleccionemos del cuál queremos migrar datos.

Seleccionamos el schema del que deseamos migrar información y presionamos siguiente.
La pantalla inicia el proceso de ingeniería inversa para obtener la información de objetos en el schema seleccionado.  Una vez que ha finalizado el análisis presionamos “Next”


En esta pantalla el programa nos muestra el total de objetos que ha encontrado en el schema seleccionado.

Si el objetivo es migrar el total de tablas encontradas da click en “Next” para continuar con el siguiente paso. De otra manera tendrás que dar click en “Detailed selection” para elegir la o tablas a migrar.

Como podemos ver en la pantalla previa, se nos muestra el contenido del schema seleccionado donde podemos elegir la tabla o tablas a migrar. Presionamos “Next” para continuar.
En esta nueva pantalla tendremos que establecer las opciones de migración tanto para el origen como para el destino. Si no tienes mucha experiencia con los Engines de mysql así como el collation te recomiendo que intentes la migración con los valores por default.




Presionamos “Next” para continuar. y el programa comenzará a generar el bloque de sentencias DDL para la migración de datos. Una vez que haya finalizado presionamos ”Next” 





Si todo es correcto, nos dará un mensaje indicándonos que el mapeo se ha realizado correctamente. Presionamos siguiente.




En esta parte del asistente podemos elegir entre crear los objetos al vuelo o, si queremos verificar la definición de nuestros campos generar el script con todo el bloque de sentencias DDL para la migración. Seleccionamos la creación OnLine y presionamos “Next”




En este momento se comenzarán a crear los objetos seleccionados para su migración. Al finalizar el proceso podremos ver el resultado. Presionamos “Next” al ver que todo va bien en este punto.

 

El programa nos confirma que todo va bien. Aquí es importante mencionar que de ocurrir algún error en la creación de los objetos, se nos mostrará los problemas al seleccionar el filtro: “Show create problems”. Presionaremos “Next”




Una vez creadas las tablas que migraremos, procederemos a definir la manera en que el contenido será transferido a mysql. Podemos, como en el caso del metadata hacerlo al vuelo u online, o generar el script de migración para su análisis y revisión. En este caso hemos elegido OnLine. Presionamos Next




Hecho lo anterior, el programa comenzará el proceso de transferencia de datos desde Iseries Db2 hasta Mysql. De ser satisfactoria la transferencia, el programa nos lo indicará con un mensaje de éxito.

Y ahora prácticamente hemos terminado con el proceso de migración desde Db2 Iseries a Mysql.  El sistema en la pantalla que le sigue a la anterior nos mostrará un resumen del proceso de migración donde además de conocer el número y tipo de objetos migrados, también podremos ver el resultado de cualquier error ocurrido durante el proceso. Aquí la pantalla de resumen y la vista de la tabla migrada a Mysql:

 





Como pueden ver, migrar información a Mysql desde DB2, Oracle, Access, Ms Sql o cualquier motor que soporte conectividad JDBC es muy sencillo.

Tomado de: Articulo original

Regla dorada del diseño de la interfaz del usuario y Diseño de Componentes

Es decir, esta regla dorada constituyen la base de un conjunto de principios de diseño de la interfaz de usuario que guían este aspecto tan importarte de diseño del software.


Dejar el control al usuario:

Durante una sesión para recabar los requerimientos de un nuevo y gran sistema de información se preguntó a un usuario clace acerca de los atributos de la interfaz gráfica basada en ventanas.

"Lo que realmente me gustaría", respondió con solemnidad, "es un sistema que lea mi mente. que sepa lo que quiero hacer antes de que necesite hacerlo y que sea fácil para mí obtener eso que quiero, Eso es todo lo que quiero, sólo eso."

Mi primera reacción fue afirmar con la cabeza y sonreír, per me detuve unos instantes. Pues no habia nada raro en esa solicitud. pues él usuario queria un sistema que reaccionara a sus necesidades y la ayudara para que las cosas se hicieran. deseaba controlar la computadora, y no que la computadora la controlara a ella.

La mayor parte de las limitaciones y restricciones las impone un diseñador pretenden simplificar el modo de iteración. pero ¿para quién?

Como diseñador tal vez se sienta tentado a introducir restricciones y limitantes que simplifiquen la implementación de la interfaz. El resultado puede ser una interfaz fácil de construir, pero que sea frustrante de utilizar.
A continuación algunos principios de diseño que permiten que el usuario tenga el control:
Definir modos de iteracción de manera que se obligue al usuario a realizar acciones necesarias o no deseadas.Dar una interacción flexible.
Permitir que la iteracción del usuario sea interrumpible y también reversible.
Facilitar la iteracción a medida que aumenta la habilidad y permitir que aquellá se personalice.
Ocultar los tecnisismos internos al usuario ocasional.
Diseñar la interacción directa con objetos que aparezcan en la pantalla.

Diseños de componentes basados en clase


Bien ahora veremos los principios básicos del diseño
Hay cuatro principios básicos que son aplicables en el nivel de componentes y que han sido ampliamente aceptados para la aplicación de la ingeniería en software Orientada a objetos.

Principio Abierto-Cerrado (PAC) "Un módulo debe ser abierto para la extensión pero cerrado para la modificación" Este enunciado parece ser una contradicción, pero representa una de las características más importantes de un buen diseño en el nivel de componentes. es decir, debe especificarse el componente en forma tal que permita extenderlo (dentro del dominio funcional al que esta dirigido) sin necesidad de hacerle modificaciones internas (en el nivel de código o de lógica). para lograr esto se crean abstracciones que sirven como búfer entra la funcionalidad que sea probable extender y la clase de diseño en sí.




Principio de sustitución de Liskov (PSL) "Las subclases deben ser sustituibles por sus clases de base". Este principio de diseño, originalmente propuesto por Barbara Liskow sugiere que un componente que use una clase debe funcionar bien si una clase derivada de la clase base pasa al componente. así, el PSL demanda que cualquier clase derivada de la clase base debe respetar cualquier contrato implícito entre la clase base y los componentes que lo usan.

Principio de la Inversión de la Dependencia (PID) "Dependencia de las abstracciones. No dependa de las concreciones" Como se vio en el estudio PAC, las abstracciones son el lugar en el que es posible ampliar un diseño sin muchas dificultades. Entra más dependa un componente de otros componentes concretos (y no de abstracciones tales como una interfaz), más difícil será amplio.


Principio de segregación de la interfaz (PSI) "Es mejor tener muchas interfaces específicas del cliente que una sola de propósito general" Hay muchas instancias en las que múltiples componentes del cliente usan las operaciones que proveee una clase servidor. El PSI sugiere que debe crearse una interfaz especializada que atienda a cada categoría principal de clientes.En la interfaz de ese cliente, sólo deben de especificarse aquellas operaciones que sean relevantes para una categoría particular de clientes.

Principio de equivalencia de la liberación de la liberación de la neutralización (PER) Cuando las clases o componentes se diseñan para ser reutilizables, existe un contrato implicíto que se establece entre el desarrollo de la entidad reutilizable y las personas que la emplearán.

Tomado de: Componentes
                 Usabilidad

Algunos Trucos para Generacion de SMARTDRIVES

Revisar las siguientes paginas:

Tres trucos sobre ejecucion de SD

Recomendaciones

Instalar otro Emulador poco mas agil

Ejemplo de Presentacion

Mi Primera Aplicacion SMARTDEVICES

Genexus de España

Los 10 mitos de la Planificación de Proyectos de Software

Estudiando las areas de proceso del Nivel 2 de CMMI-Dev v1.3, llegue a encontrar estos mitos que comparto con Ustedes:

Mito # 10

Un plan de proyecto es una lista de hitos.

Realidad: La planificación de proyectos de software contiene varios componentes que definen el trabajo y cómo se hará.

Mito # 09

Planificación lleva demasiado tiempo. El tiempo estaría mejor invertirlo en codificación y pruebas.

Realidad: Tratar de ahorrar tiempo al no planificar se traduce en retrasos, reproceso, y los aumentos de costos.

Mito # 08

No puedo elaborar un plan de proyecto, ya que no entendemos todo lo que hay que saber acerca del proyecto.

Realidad: Un plan es un documento vivo. La precisión se incrementará con el tiempo y los detalles adicionales.

Mito # 07

El desarrollo de software no se puede planificar porque es “diferente” al de otras disciplinas de ingeniería.

Realidad: Los expertos en software dicen lo contrario. Tenemos que identificar y asignar recursos. Nadie va a pagar por un trabajo indefinido con objetivos poco claros!.

Mito # 06

Las estimaciones de software siempre cambian la respuesta “correcta” de la gestión.

Realidad: Las estimaciones basadas en datos proporcionan apalancamiento. La planificación ayuda a identificar el alcance completo. La gestión ajusta la planificación de proyectos de software.

Mito # 05

Esto se aplica a todos los demás, pero mi proyecto es “diferente”. Realidad: El plan del proyecto es flexible. Usted identifica el modelo de proceso, tareas, riesgos, y los recursos necesarios, los objetivos y las prioridades para gestionar, están indicadas.

Mito # 04

La planificación no se aplica a mí, porque yo no desarrollo software. (Mejora de procesos, administración de redes, …)

Realidad: Estas actividades suelen afectar otros ingenieros de software. Es aún más importante para planificar los proyectos “difusos”.

Mito # 03

No hay buenas herramientas disponibles para rastrear fácilmente las tareas y el calendario.

Realidad: Microsoft Project y otras herramientas están disponibles. Las nuevas herramientas y técnicas pueden ser adquiridas y aprendidas cuando sea necesario.

Mito # 02

No soy bueno en planificar. Es una tarea administrativa que la debe hacer un administrador.

Realidad: La planificación es una competencia clave para todos los ingenieros de software. “La planificación es un proceso natural. Es mucho más divertido hacer algo planificado. Y lo bueno de no planificar, es que el fracaso viene como una total sorpresa, que suele estar precedida por un período de preocupación y depresión”.

Mito # 01

La planificación de Proyectos es la última “moda” de procesos de software.

Realidad: La planificación es un área de proceso clave del CMM Nivel 2. La planificación es básica y obligatoria.

 

Tomado de: Articulo

Sistema de Gestión de Contenidos (CMS)

Alguna vez es un curso de social media escuchaba mucho sobre CMS y como se ejecutaba, bueno en ese momento no sabía todo al respecto, pero luego investigué y entendí sobre ello; yo se que muchos de nuestros lectores conocerán ese término, pero de seguro que otros no, la idea es compartir esos conocimientos con toda nuestra comunidad para que todos puedan aprender más del Social Media.

Para empezar ¿qué es el CMS?, según Wikipedia: Del inglés Content Management System o Sistema de Gestión de Contenidos, es un programa que permite crear una estructura de soporte (framework) para la creación y administración de contenidos, principalmente en páginas web, por parte de los administradores, editores, participantes y demás roles.

Este sistema informático nos permite crear, gestionar, editar y publicar nuestro contenido en la web en diversos formatos, el CMS permite generar páginas dinámicas y amigables al usuario, permitiendo una mejor usabilidad, esta aplicación web, siempre funciona funciona en el servidor web en el que esté alojado el portal. El acceso al gestor se realiza generalmente a través del navegador web, y se puede requerir el uso de FTP (protocolo de transferencia de ficheros, software cliente/servidor que permite a usuarios transferir ficheros entre ordenadores en una red TCP/IP) para subir contenido.

En la web existen ciertos gestores que contienen muchas plantillas disponibles permitiendo un sentido estético a esta plataforma que el usuario puede ejecutar sin saber de diseño. Entre los CMS más conocidos tenemos a WordPress, Joomla, y Drupal, gestores sobre los que hay una gran comunidad de extensiones (módulos, complementos, plugins y plantillas, entre otros).

A continuación les compartiremos una agradable infografía que le permitirá de forma simple y concreta conocer más acerca de los CMS. Esperamos que sea de su utilidad. Enjoy!

Tomado de: Articulo Original