domingo, 10 de junio de 2012

Mejores Prácticas y algo más ..


Definitivamente la industria de desarrollo de software es de las industrias que más ha crecido en los últimos años y se ha introducido en la economía de una manera muy rápida, hemos visto como países como India, Chile e inclusive México han ido adoptando esta industria como factor de crecimiento, también, hemos visto también la creciente demanda de desarrollar software con distintas características; que sea de calidad, seguro, eficaz eficiente, y que dada la experiencia de todos los desarrollos, el desarrollo de software sea más una metodología que el tener varias personas con habilidades técnicas tirando líneas y líneas de código según la experiencia personal de cada programador, es tener una estrategia formal que la industria la ha denominada Mejores Practicas.
Hoy en día, las Mejores Practicas se encuentran en todo el mundo y para todos tipos, están divididas por continente, por tamaño de la empresa, para empresa privada o para el gobierno.
Bajo ese contexto las mejores prácticas que expongo en este blog y para la comunidad Mexicana especialista en desarrollo de software expongo las siguiente Mejores Prácticas que actualmente se pueden utilizar para las empresas mexicanas, en cada punto contempla una breve introducción y su objetivo:

MoProSoft
Modelo de Procesos para la Industria del Software en la industria del software. Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría de Economía para obtener una norma mexicana que resulte apropiada a las características de tamaño de la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de software. MoProSoft  es el nombre del modelo en la comunidad universitaria y profesional, y la norma técnica a la que da contenido es la NMX-059/01-NYCE-2005 que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicación de su declaratoria en el Diario de la Federación.

MAGTIC
Si bien MGATIC es considerado como “mejor practica” no es propiamente un estándar, de hecho es considerado un Manual General utilizado por el Gobierno Federal para lo que se refiere a Tecnologías de la Información y más recientemente adaptado para seguridad e información.
El Manual a que se refiere las reglas, acciones y procesos que en materia de tecnologías de la información y comunicaciones deberán observar de manera obligatoria, las dependencias y entidades de la Administración Pública Federal
El Manual hacer referencia al ámbito a las Tecnologías de la Información e incluso integra distintos estándares, como el caso de ITIL.

Para los que deseen descargar su última versión les anexo la liga o bien los aspectos generales los podrán descargar de la página de la Normateca

ITIL
Actualmente en su versión 3,  la Biblioteca de Infraestructura de Tecnologías de Información, frecuentemente abreviada, es un conjunto de conceptos y prácticas para la gestión de servicios de tecnologías de la información, el desarrollo de tecnologías de la información y las operaciones relacionadas con la misma en general. ITIL da descripciones detalladas de un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura, desarrollo y operaciones de Tecnologías de Ia Información, página oficial.

CMMI
El CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.

Niveles CMMI
Los niveles CMMI son 5:

  • Inicial o Nivel 1 CMMI. Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, los empleados si tienen que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no se sabe que pasara con él.
  • Nivel 2 CMMI. Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.
    • Los procesos que hay que implantar para alcanzar este nivel son:
      • Gestión de requisitos
      • Planificación de proyectos
      • Seguimiento y control de proyectos
      • Gestión de proveedores
      • Aseguramiento de la calidad
      • Gestión de la configuración
  • Nivel 3 CMMI. alcanzar este nivel significa que la forma de desarrollar proyectos (gestión e ingeniería) está definida, por definida quiere decir que está establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.
    • Los procesos que hay que implantar para alcanzar este nivel son:
      • Desarrollo de requisitos
      • Solución Técnica
      • Integración del producto
      • Verificación
      • Validación
      • Desarrollo y mejora de los procesos de la organización
      • Definición de los procesos de la organización
      • Planificación de la formación
      • Gestión de riesgos
      • Análisis y resolución de toma de decisiones
    • La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades.
  • Nivel 4 CMMI. Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.
    • Los procesos que hay que implantar para alcanzar este nivel son:
      • Gestión cuantitativa de proyectos
      • Mejora de los procesos de la organización
  • Nivel 5 CMMI. Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica.
    • Los procesos que hay que implantar para alcanzar este nivel son:
      • Innovación organizacional
      • Análisis y resolución de las causas

Opinión personal

Como podrán observar en las  líneas superiores, más que una descripción completa de lo que es cada una de las mejores prácticas, solo  he plasmado un pequeño esbozo de lo que son y su objetivo general.

Más allá de descripciones especificas creo que es muy importante considerar que debemos incorporar las mejores practicas internacionales de la que podamos sacar mejor provecho que redunde en generar productos de calidad, que nuestra organización se base en mejores practicas garantiza en mayor medida convertirla en una empresa competitiva.

Nosotros como profesionales de TI es nuestra responsabilidad adoptar las mejores prácticas del mercado e incluso contribuir para generar ejemplos de éxito como MoProSoft.

Trabajo Aplicación Turística




Proceso
Nombre
Desarrollo de APP
Descripción
Guía a seguir para el desarrollo de Software (aplicaciones Móviles)
Propósito
Determinar el ciclo de desarrollo de software
Objetivos
·         O1. Utilizar mejores practicas
·         O2. Estandarización del desarrollo de Software
·         O3. Determinar el nivel de calidad del software
Indicadores
·         I1. Auditorias de ISO
·         I2. Contar con documentación de los sistemas
·         I3. Pruebas IRM
Metas Cuantitativas
·         M1. Aprobada o No Aprobada
·         M2. Num de documentos aprobados /num de documentos requeridos
·         M1. Satisfactoria o No Satisfactoria
Responsabilidad
Director TI
Subprocesos
·         S1. Concepción del Proyecto
·         S2. Planificación
·         S3. Análisis
·         S4. Diseño
·         S5. Construcción
·         S6. Pruebas
·         S7. Implantación
Procesos Relacionados
·         Procesos Finanzas
·         Proceso de RH
·         Proceso de Publicidad / estudios de mercado
Entrada
Solicitud de aplicación Móvil para Guía turística Nacional e Internacional
Productos Internos
·         S1. Concepción del Proyecto. Obtención de proyecto de acuerdo a la demanda del cliente y realización de carta del proyecto
·         S2. Planificación. Planeación de actividades y fecha de liberación de la aplicación.
·         S3. Análisis. Obtención de requerimientos detallados.
·         S4. Diseño. Diseño de aplicación mediante aprobación de prototipo
·         S5. Construcción. Codificación de aplicación
·         S6. Pruebas. Pruebas unitarias e integrales para validación de aplicación.
·         S7. Implantación. Liberación de la aplicación
Salida
Aplicación de Guía Turística con iOS

Esta aplicaci+on es parte del trabajo que se realizó en equipo.

Saludos


domingo, 20 de mayo de 2012

Arquitectura Orientada a Servicios SOA


Encontré mucha definiciones sobre lo que es la Arquitectura Orientada a Servicios SOA, desde mi punto de vista, y después de haber leído varios autores,  básicamente podemos decir que es un paradigma, orientado a la forma que debemos ver a una empresa del giro que sea e independiente de los fines que persiga, él como la información interactúa en todos los aspectos de la empresa y como se debe utilizar.

SOA  es una Arquitectura orientada a Servicios, se basa en la independencia de plataformas de hardware, de sistemas operativos y de lenguajes de programación, fortalece la reutilización de los sistemas actuales que se construyeron y se venido utilizando y crea un ambiente en el que los negocios y la tecnología de la información pueden interactuar entre sí.

SOA se fundamenta en:

• Ejecutar rápido, adaptarse al mercado, ganar ante la competencia.
• Reutilizar los componentes de los procesos de negocios.
• Medir los resultados y tomar acción sobre ellos.
• Garantizar resultados que sean repetibles y predecibles.
• Empezar donde sea necesario (área de negocios - área de tecnología).

  

Un ejemplito …   Para entenderle un poco más

Si analizamos bien las tareas de negocios e identificamos aquellas que podemos repetir, esas tareas las podríamos definir como “Servicios”. Verificar un crédito, abrir una cuenta, comprobar existencias, son tareas de negocio repetibles que podemos denominar servicios. Siendo así, cualquier negocio, independientemente de su industria, posee servicios.
Ahora bien, supongamos que cada uno de esos servicios son “bloques  y veamos cada uno de ellos como un “servicio”, que a su vez, es una tarea de negocios. En teoría con SOA podríamos tomar cada uno de esos bloques y unirlos de la manera que quisiéramos, pues todos encajan. Podemos ensamblarlos y volver a ensamblarlos de manera dinámica, a medida que cambian las necesidades de la empresa.


Cada bloque de equivale a una tarea de negocios dentro de una empresa. Un Gerente de X área  podría tomar algunos bloques y el gerente de otra X área otros, y construir algo diferente utilizando los mismos componentes (o Servicios).

La Arquitectura Orientada a Servicios (SOA) consiste en la forma en que unimos esos bloques (Servicios). 

Un poco de historia … Esto si quieren no lo lean. 


La arquitectura orientada a los servicios no es nueva, pero es un modelo alternativo con respecto a los modelos orientados a los objetos estrechamente acoplados de una manera más tradicional que han emergido en las últimas décadas. Al tiempo que los sistemas basados en SOA no excluyen el hecho de que se puedan construir servicios individuales con diseños orientados a los objetos, el diseño total está orientado a los servicios. Dado que permite objetos dentro del sistema, SOA está basado en objetos, pero no está, en su totalidad, orientado a los objetos. La diferencia está  en las interfaces propiamente dichas. Un ejemplo clásico de un sistema proto-SOA que ha estado alrededor por un tiempo es Common Object Request Broker Architecture (CORBA), que define conceptos similares a SOA.
  
Los servicios de Web no son la única forma de implementar SOA. Tal como se explicó anteriormente, CORBA es otra forma y también sistemas Message-Oriented Middleware

De donde salió…

SOA surge de la necesidad de hacer que los sistemas de negocios de IT sean más ágiles con respecto a los cambios en la empresa. Al permitir relaciones fuertemente definidas, si bien implementaciones específicas flexibles, los sistemas de IT pueden obtener las ventajas de los sistemas existentes y, no obstante, estar lista para cambios futuros en sus interacciones.

Que tecnologías los componen

En sí mismo SOA es un concepto abstracto sobre cómo se debe unir el software, como lo mencione en un principio, considero es un paradigma y nace de las ideas y tecnologías implementadas en XML y en servicios de Web para existir en la forma de software. Asimismo, para funcionar con efectividad, también requiere soporte de seguridad, administración de políticas, un messaging confiable y sistemas contables.
  
Esto sí es importante que lo lean

Para establecer un control apropiado de todo ese messaging, así como también para aplicar las necesidades de seguridad, política, confiabilidad y contabilidad, hay un nuevo objeto de software que entra en la escena de SOA. Es el Enterprise Service Bus (ESB), que es responsable del control y del flujo apropiado, y tal vez también de las conversiones de todos los mensajes entre los servicios, usando cualquier cantidad de protocolos de messaging posibles. No se requiere absolutamente el ESB, pero es un componente vital para administrar apropiadamente sus procesos de negocios en SOA. El ESB propiamente dicho puede ser un único motor o aun un sistema distribuido.

Con respecto al desarrollador, las herramientas que usa necesitan conocer las capacidades de SOA y permitirle trabajar efectivamente con objetos de SOA. Esto incluye el proceso de diseñar el modelo de SOA, desarrollando servicios y objetos de servicio, y probar la aplicación de SOA en su totalidad. De este modo, las herramientas del desarrollador deberán estar listas para Service-Oriented Application Design and Development (SOAD).

Tecnologías SOA

SOA puede interactuar con una cantidad de otras tecnologías, pero con respecto a esto el encapsulado y el agregado de componentes tienen un rol significativo. Tal como se indicó anteriormente, un servicio de SOA puede ser un objeto simple, un objeto complejo, una colección de objetos, un proceso que contiene otros procesos, y asimismo una colección entera de aplicaciones que dan un único resultado.
  
Los servicios se pueden implementar en cualquier lenguaje de programación siempre y cuando pueda generar e interactuar con WSDL. SOAP en sí mismo no es un requisito absoluto, pero es un sistema de messaging común. De este modo, los servicios miembros en SOA pueden ser implementados en casi cualquier variedad de lenguaje de programación y plataforma que dé soporte a WSDL.
  
Los servicios de SOA y de Web son independientes de lenguaje de programación, pero el lenguaje Java está entre los principales lenguajes de desarrollo (por eso vemos Java en el propedéutico de Computación, supongo). La disponibilidad de interfaces de Java bien definidas, así como también las abundantes implementaciones de Java de los varios protocolos, le dan a los desarrolladores de Java una ventaja cuando se construye en este modelo.

Salu2



domingo, 22 de abril de 2012

Entropia y el modelo de la información ....


Originalmente nacida en la termodinámica como lo muestra el libro The Information y bajo las propuestas de Maxwell enfocadas a la termodinámica mismas que fueron postulados y en donde se mezcla varias “teorías” para sus demostraciones como la estadística, la probabilidad, la información y trata de dar una explicación del origen de la entropía en el ámbito de la termodinámica y haciendo una comparación directa en la teoría de la información.

En el texto The Mathematical Theory of Communication desde mi punto de vista para poder estar en condiciones de entender el capitulo 7 es necesario ahondar en mas apartados del libro, ya que trata de “aterrizar” si se le puede llamar de alguna manera, a la teoría de la información y comprobar la entropía por medio de métodos “lógicos” (logaritmo basado en la probabilidad) haciendo coincidir la teoría inicialmente de la termodinámica en la teoría de la información

Básicamente el video y las lecturas nos dan un panorama de donde nace y como se llega a la entropía, como es que se articula la teoría de la información y como el papel que juega la entropía, nos muestra su conformación y lo importante que es en la teoría de la información y lo importante del modelo de Shannon.




FUENTE DE INFORMACION: Selecciona el mensajedeseado de un conjunto de mensajes posibles.
TRANSMISOR: Transforma o codifica estainformación en una forma apropiada al canal.
SEÑAL: Mensaje codificado por el transmisor.
CANAL: Medio a través del cual las señales son transmitidas al punto de recepción.
FUENTE DE RUIDO: Conjunto de distorsiones o adiciones no deseadas por la fuente de información que afectan a la señal. Pueden consistir en distorsiones del sonido (radio, teléfono), distorsiones de la imagen (T.V.), errores de transmisión (telégrafo), etc.
RECEPTOR: Decodifica o vuelve a transformar la señal transmitida en el mensaje original o en una aproximación de este haciéndolo llegar a su destino.


Entropía e información


Creo que los postulados que podemos extraer son:
  • Medición de la información
  • Este establece que mientras más probable sea un mensaje menos información proporcionará
  • La probabilidad que tiene un mensaje de ser enviado y no su contenido, lo que determina su valor informativo
  • La información es tratada como magnitud física, caracterizando la información de una secuencia de símbolos utilizando la Entropía
  • De acuerdo a la teoría de la información, el nivel de información de una fuente se puede medir según la Entropía de la misma.

Para codificar los mensajes de una fuente intentaremos pues utilizar menor cantidad de bits para los mensajes más probables y mayor cantidad de bits para los mensajes menos probables de forma tal que el promedio de bits utilizados para codificar los mensajes sea menor a la cantidad de bits promedio de los mensajes originales. Siendo la base de la compresión de datos.

Salu2



jueves, 19 de abril de 2012

Bienvenida a tod@s a este nuevo Blog

Hola, mi nombre es Eduardo Muñoz y curso la Maestría en Tecnologías de Información y Administración en el ITAM, actualmente comparto con ustedes este nuevo Blog que servirá como ventana para expresar algunas opiniones propias en relación a las Tecnologías de la Información.

Salu2