Subscribe

Bookmark and Share

lunes, agosto 31, 2009

Venezuela podría prohibir videojuegos violentos...

Patria para todos (PPT), el partido en el poder en Venezuela, impulsa la aprobación de una ley que prohíba la venta, arriendo y compra de videojuegos violentos, dio a conocer el diario local El Universal.

La Asamblea Nacional local, lo que equivaldría en México al Congreso de la Unión, aprobó el primer debate del proyecto de ley que, de aprobarse, perseguiría la comercialización de videojuegos e incluso de juguetes que sean clasificados como ‘violentos’ por su contenido bélico.

Según el PPT, la ley conocida como ‘Prohibición de Videojuegos y Juguetes Bélicos’ tendría como fin evitar la propagación de la violencia entre los niños y los jóvenes.

El debate que llevaron a cabo representantes populares venezolanos no fue solo de palabras, sino que fueron presentadas imágenes y escenas de títulos como Grand Theft Auto y Resident Evil para demostrar que el uso de armas de destrucción utilizadas para la guerra están presentes, según el diario venezolano.

Según representantes del PPT, el proyecto de ley prevé que quien venda o alquile este tipo de juegos podría hacerse acreedor a multas por 500 o 5,000 unidades tributarias.

Diversos estudios han estudiado el impacto real de los videojuegos violentos, pero hasta ahora ninguno ha ofrecido argumentos contundentes para provocar su prohibición definitiva.

La publicación Journal of Pediatrics ha difundido estudios aplicados a niños y adolescentes de Estados Unidos, Japón y China para conocer la relación entre la violencia en los videojuegos y el comportamiento agresivo en los niños y adolescentes, algunos de los cuales tanto han descartado la relación, como la han confirmado en otros casos.

Fuente: http://www.netmedia.info/

jueves, agosto 27, 2009

Dar ordenes e insturcciones en Ingles, Giving commands and orders with the Imperative form (LECCION 7)

martes, agosto 25, 2009

Modelo de Plan de Negocio

Estructura de un Business Plan
1. Resumen ejecutivo
El objetivo de un resumen ejecutivo es captar el interés de los potenciales inversores, por ello debe contener un breve resumen de los aspectos más importantes del Plan de Negocio.

Los principales elementos a contener son:



  • La idea del negocio: su exclusividad respecto a productos/servicios existentes.

  • Público objetivo: principales características y su encaje con el perfil de usuarios de Internet.

  • Valor del producto/servicio para ese público objetivo.

  • Tamaño de mercado y crecimiento esperado.

  • Entorno competitivo.

  • Fase actual de desarrollo del producto, especificando las necesidades de desarrollo adicionales a realizar.

  • Inversión necesaria.

  • Hitos fundamentales durante el funcionamiento del negocio

  • Objetivos a medio/largo plazo.

2. Descripción del producto y valor distintivo

Este capítulo debe contener una explicación detallada del concepto básico y de las características del producto o servicio a ofrecer.

Descripción general del producto


  • Funcionalidades básicas

  • Soporte tecnológico

  • Origen de la idea de negocio
Valor distintivo para el consumidor:

  • Público objetivo al que va dirigido y necesidades que satisface.

  • Especificación del valor único y distintivo del nuevo producto o servicio a lanzar desde la óptica del cliente, explicando la diferenciación con la oferta actual de productos del resto de competidores del mercado.

3. Mercado potencial

  • Descripción del mercado.

  • Tamaño de mercado (volumen de ventas, rentabilidad, etc.)

  • Grado de consolidación del sector.

  • Factores clave de éxito de este mercado.

  • Barreras de entrada y salida.

  • Evolución y crecimiento.

  • Ritmo de crecimiento histórico y futuro.

  • Tendencias
Público objetivo

  • Segmentación de clientes en base a criterios bjetivos.

  • Tamaño de mercado para cada segmento de consumidores.

  • Principales factores de crecimiento en cada segmento.

  • Porcentaje de número de clientes a captar respecto al volumen del mercado.

  • Volumen de ventas por segmento.

  • Rentabilidad esperada de cada segmento de mercado.

  • Segmento de mercado más atractivo.

  • Factores clave de compra para los consumidores.
4. Competencia y Barreras de entrada

  • Competidores existentes.

  • Comparación de estos en base a los siguientes parámetros: volumen de ventas, precios, crecimiento, cuota de mercado, posicionamiento, líneas de producto, segmentación de clientes, canales de distribución, servicio de clientes.

  • Estrategias de los competidores: público objetivo, estrategias de marketing.

  • Descripción de sus fortalezas y debilidades.

  • Ventaja competitiva respecto a los competidores.

  • Potencial reacción de tus competidores ante el lanzamiento del nuevo negocio.

5. Modelo de negocio y plan financiero
No sólo es necesario que el valor distintivo del producto sea capaz de generar una base suficiente de clientes, sino que deberá explicarse cómo se les extraerá valor.
Detalle de todas las líneas de ingresos. En su caso especificar cuáles han sido ya probadas.

Plan financiero

Requisitos fundamentales de una planificación financiera son:

  • Cuenta de resultados: especificando las partidas de engresos y costes con sus hipótesis implícitas (Es muy importante justificar las hipótesis de crecimiento de ingresos y gastos realizadas; un buen indicador es la comparación y justificación de esos mismos parámetros conforme al crecimiento del mercado.

  • Proyecciones de cash flow, especificando cuando se alcanzará el breakeven (después de la generación de cash flow positivo).

  • Balance.

  • Previsiones de 3 a 5 años; al menos un año posterior al breakeven.

  • Valoración de la compañía.

  • Necesidades de financiación.
El Plan financiero debe estar detallado para los primeros dos años (mensual o trimestral), y posteriormente anual. Todas las cifras deben estar basadas en hipótesis razonables: sólo las principales deben estar razonadas en el Plan de Negocio.
6. Equipo directivo y organización
Equipo directivo

Esta sección es la segunda en la que se suelen fijar los inversores, después del resumen ejecutivo, quieren saber si el equipo directivo es capar de llevar a cabo el negocio: "I invest in people, not ideas".
Un equipo directivo potente ha de tener una visión común y capacidades complementarias.

Este capítulo debe contener:

  • Miembros del equipo directivo con su perfil: educación, experiencia profesional, éxitos en el mundo laboral.

  • Experiencia o habilidades del equipo directivo necesarias para llevar a cabo el proyecto: qué capacidades/experiencias tienen los miembros del equipo que hagan posible la puesta en marcha y gestión del nuevo negocio. Cómo encaja su perfil con las nuevas necesidades del negocio.

  • Capacidades que faltan: detallando cómo se piensan cubrir y por quién.

  • Misión/objetivos que persigue el equipo directivo al montar el negocio: cuál es su verdadera motivación.
Qué buscan los inversores

  • ¿Ha trabajado el equipo directivo juntos con anterioridad?

  • ¿Tienen experiencia laboral significativa previa?¿Son los fundadores conscientes de sus debilidades y van a ser capaces de hacerlas frente?

  • ¿Tienen los fundadores claro sus futuros roles? ¿Están claros los % de capital?

  • ¿Estarán a tiempo completo en el futuro proyecto?

  • ¿Tienen todos los miembros un objetivo común, o existen discrepancias?
Organigrama

  • Descripción de las funciones principales, personas, responsabilidades... Es necesario asignar cuáles son las responsabilidades de cada miembro del equipo y cual es el sistema de delegación que se establece.

  • El diseño organizativo ha de permitir la flexibilidad de la organización, adaptable a nuevas circunstancias y a crecimientos elevados.

7. Estado de desarrollo y plan de implantación
Estado de desarrollo del producto/servicio
Todo inversor querrá minimizar su riesgo, por tanto hay que darle una explicación detallada del estado de avance de la idea de negocio.
Desarrollo tecnológico: fase en la que se encuentra (desarrollado, en fase de desarrollo...).
Si existe un prototipo desarrollado se debe presentar, o si se ha podido testar el producto ante algún consumidor piloto, se deben presentar los resultados.
Plan de implantación Es necesario realizar un plan de todas las actividades necesarias para poner en marcha la empresa, así como para identificar las necesidades de financiación reales.

  • Calendario de implantación: principales actividades y responsables.

  • Principales hitos: momento de alcanzarlos, e interconexiones con el resto de actividades.

  • Principales interconexiones entre los distintos grupos de trabajo (marketing, operaciones...)


8. Alianzas estratégicas

Cuántas, con quién, grado de desarrollo de las mismas, condiciones, etc.

9. Estrategia de marketing y ventas
Este apartado debe contener dos apartados básicamente: el posicionamiento/diferenciación del producto y la estrategia de marketing a seguir para alcanzar los objetivos de tráfico y de facturación fijados.
Posicionamiento

  • Tipo de posicionamiento: descripción de las características distintivas del producto respecto a la competencia: percepción distintiva o única del cliente.

  • Diferenciación: como se espera mantener en el tiempo dicho posicionamiento.
Estrategia de marketing
En este apartado se debe especificar cuál va a ser la estrategia a seguir para captar el volumen de usuarios deseados y cuál va a ser su coste de adquisición.

En la estrategia de marketing se debe detallar:

  • Principales medios utilizados para la comunicación, entre online y offline.

  • Interlocultores o proveedores de servicio con los que se pretende trabajar: empresas de publicidad, empresas de venta de banners.

  • Coste de adquisición y fidelización por usuario.
Si se trata de un nuevo negocio, es preciso detallar cómo se pretende realizar la campaña de lanzamiento, detallando los medios que se van a utilizar.
Una vez explicada ésta, es necesario describir los programas definidos para continuar con la adquisición de clientes y fidelización de los ya existentes.
Es muy importante en el mercado de Internet tener programas de adquisición y fidelización muy potentes que permitan continuar con el crecimiento esperado.
Objetivos de métricas En este apartado se debe dar un resumen de las ambiciones del negocio en cuanto a las principales magnitudes operativas y volúmenes de facturación en un futuro.

  • Objetivos de tráfico a corto y medio plazo.

  • Usuarios únicos (reach sobre el mercado que implica).

  • Usuarios registrados.

  • Páginas vistas.

10. Principales riesgos y estrategias de salida
Riesgos, Podríamos diferenciar dos tipos de riesgos: los propios del mercado y los intrínsecos del proyecto en sí.
Riesgos básicos que afectan al mercado:

  • Crecimiento menor del esperado.

  • Incertidumbre propia del sector de la alta tecnología, que puede dar lugar a discontinuidades considerables en períodos cortos de tiempo.

  • Coste mayores a los previstos.

  • Riesgos del negocio en sí.

  • Entrada inesperada de un competidor.

  • Falta de encaje entre el producto y las necesidades que cubra del público objetivo.
En la evaluación de los riesgos que pueden afectar al negocio, es necesario incluir medidas concretas para hacer frente a dichos riesgos y una valoración alternativa de la compañía si se variasen algunos de los parámetros clave del modelo; como por ejemplo, tasa de crecimiento de usuarios, etc.
Estrategias de contingencia
En todo Plan de Negocio es necesario incluir un capítulo en el que se incluyan posibles estrategias de contingencia en caso de que el negocio no alcance los objetivos revistos.

Algunas de las estrategias de contingencia más comunes pueden ser:


  • Alianza con alguno de los principales líderes globales en el entorno de Internet o con un consorcio de ellos.




  • Venta total o parcial de la compañía a una empresa del sector más potente, que pueda impulsar el crecimiento de la compañía.




  • Venta o explotación de la tecnología y su patentes.




  • Venta de la base de clientes.




  • Autor: Redacción de Baquía
    Web: http://www.baquia.com


    viernes, agosto 21, 2009

    Gmail continúa creciendo y podría rebasar a Hotmail este año

    Gmail ocupa el tercer lugar entre los servicios de correo electrónico en línea más populares del mundo. Yahoo lidera, y el segundo lugar, ocupado por Hotmail, se ve amenazado por Google.

    En julio, Gmail superó a AOL, pasando así a ocupar el tercer lugar entre los servicios más populares de e-mail. La nueva posición de Gmail no se debe a una caída en el número de usuarios de AOL, sino a su propio crecimiento.

    En términos porcentuales, Gmail es el sistema que anota el crecimiento más rápido de todos. Entre julio de 2008 y julio de 2009, el número de usuarios únicos aumentó en 46%, de 25 millones a 37 millones de usuarios.

    En caso de mantenerse tal índice de crecimiento, Gmail podría rebasar a Microsoft Windows Live Hotmail dentro de los próximos meses. Según Comscore, el servicio de Microsoft tiene 47 millones de usuarios únicos, aunque el crecimiento anotado durante el último año ha sido de solo 3%.

    El primer lugar indiscutido continúa en manos de Yahoo Mail, con 106 millones de usuarios, y un crecimiento de 22% en un año.

    Fuente DiarioTi.com

    miércoles, agosto 19, 2009

    Campaña inglesa contra el envío de mensajes al ir conduciendo


    Los ingleses promueven una campaña para evitar que los jóvenes envíen mensajes de texto mientras conducen, por medio de un impactante cortometraje de 4 minutos. Vale la pena verlo.


    lunes, agosto 03, 2009

    Arquitectura de capas

    Introducción

    La metodología RPM presentada por C. Larman presupone una estructura de tres capas que es típica de los Sistemas de Información. Estas tres capas son:

    La capa de la Presentación. Esta capa reúne todos los aspectos del software que tiene que ver con las interfaces y la interacción con los diferentes tipos de usuarios humanos Estos aspectos típicamente incluyen el manejo y aspecto de las ventanas, el formato de los reportes, menúes, gráficos y elementos multimedia en general.

    La capa del Dominio de la Aplicación. Esta capa reúne todos los aspectos del software que tienen que automatizan o apoyan los procesos de negocio que llevan a cabo los usuarios. Estos aspectos típicamente incluyen las tareas que forman parte de los procesos, las reglas y restricciones que aplican. Esta capa también recibe el nombre de la capa de la Lógica de la Aplicación.

    La capa del Repositorio. Esta capa reúne todos los aspectos del software que tienen que ver con el manejo de los datos persistentes, por lo que también se le denomina la capa de las Bases de Datos).

    RPM toca muy superficialmente los problemas asociados al desarrollo de una capa de Presentación. Menciona que es conveniente usar un enfoque de prototipaje y que pueden ser útiles los casos reales de uso; sin embargo no proporciona métodos, principios o lineamientos metodológicos que apoyen el desarrollo de una metáfora de diseño para la interfaz, el diseño lógico de la presentación o su diseño físico.

    RPM tampoco proporciona muchas luces sobre el desarrollo de la capa del Repositorio y tiende a subestimar su complejidad.

    Una vez elaborado el Modelo de Uso, RPM recomiendo seguir con actividades de análisis de requerimientos. Para ello se elabora un Modelo Conceptual, en el cual se busca identificar los conceptos importantes del dominio de la aplicación, abstrayendo todo lo que puedan ser mecanismos o conceptos propios de un diseño o de una implementación. Así, en el ejemplo de un Sistema de Punto de Venta, nos interesan los conceptos como Venta, Recibo, Efectivo, Cheque, Impuesto que tienen que ver con los procesos de negocio que se están apoyando y no nos interesan conceptos como Menú, Ventana, Tabla relacional, Consulta a Base de Datos que tienen que ver con cómo mejor implementar los conceptos del negocio. La mayoría de estos elementos de un Modelo Conceptual terminan agrupándose naturalmente en la capa del Dominio de la Aplicación.

    Este enfoque de RPM termina por sesgar la metodología hacia el desarrollo de la capa del Dominio de la Aplicación, y en la práctica, tiende a hacer presuponer que el desarrollo de las otras capas se puede ajustar al diseño de la capa del Dominio de Aplicación, lo cual no es siempre el caso, incluso dentro del ámbito de los Sistemas de Información.

    Antes de estudiar el Modelo Conceptual, nos conviene aclarar qué es una arquitectura de capas, su importancia e implicaciones, para tener mayor claridad en los riesgos que corremos al adoptar una metodología como RPM.

    Arquitectura de Capas

    Preguntar qué conocen por arquitectura de capas (en Sistemas de Operación, Redes de Computadores...).

    Nos limitaremos a manejar la noción de arquitectura como una forma de estructurar los elementos de un software.
    En toda arquitectura de capa los elementos agrupados en una misma capa pueden comunicarse entre si; pero existen variantes en cuanto a las comunicaciones permitidas entre elementos de capas diferentes:

    1. Arquitectura top-down de capas: Los elementos de una capa i+1 pueden enviar solicitudes de servicio a elementos de la capa inferior i. Típicamente se produce una cascada de solicitudes, es decir para satisfacer una solicitud a una capa i+2, ésta requiere enviar varias solicitudes a la capa i+1; cada una de estas solicitudes a la capa i+1 genera a su vez un conjunto de solicitudes a la capa i y así sucesivamente. Una arquitectura top-down es laxa (o no estricta) si los elementos de una capa i+1 pueden enviar solicitudes de servicio directamente a un elemento de cualquiera de las i capas inferiores.
    2. Arquitectura bottom-up de capas: Cada elemento de una capa i puede notificar a elementos de la capa superior i+1 de que ha ocurrido algún evento de interés (ej. manejadores de dispositivos). La capa i+1 puede juntar varios eventos antes de notificar a su vez al elemento de la capa i+2. Una arquitectura bottom-up también puede ser no estricta si el elemento de la capa i puede notificar a cualquier elemento de cualquier capa superior a la capa i.
    3. Arquitectura bidireccional de capas En su forma más común involucra dos pilas de N capas que se comunican entre si. El ejemplo más conocido es el de los protocolos en Redes de Computadores.

    Al implementar una arquitectura top-down de capas, se deben tomar en cuenta los siguientes factores:

    1. ¿Cuál es el criterio de abstracción para agrupar servicios/clases en una capa? Mencionar el criterio Presentación-Dominio de Aplicación-Repositorio de Sistemas de Información.
    2. Determinar el número de capas En términos simplistas, a más capas más flexibilidad pero menor desempeño. [Discutir]
    3. Típicamente las capas más internas ofrecen menos servicios. Esto ayuda la reutilización de capas ("pirámide invertida de reuso").
    4. El grado de encapsulamiento de las capas. A mayor encapsulamiento, menor dependencia externa sobre la estructura de una capa.
    5. Estructura interna de cada capa.
    6. ¿Cuánta información pasar de una capa a otra? Tomemos el caso de la arquitectura top-down. Es muy posible que, de acuerdo con el tipo de servicio solicitado, la capa inferior requiera una cantidad de información variable. En un modelo puro "empujado" (push), la capa superior está obligada a enviarle toda la información que pueda llegar a hacerle falta a la capa inferior en la solicitud.Esto no siempre es posible (piense por ejemplo en una solicitud de servicio a una base de datos que no logra completarse por estar fuera de línea. ¿Qué se hace: reintentar, abandonar, usar una fuente alterna?).En el modelo contrario, "halado" (pull o por demanda), la capa inferior solicita mayor información sólo si le hace falta --¿pero de quién la pida? El modelo de solicitudes top-down presupone un invocador anónimo y un invocado conocido.La solución la proporciona el patrón Editorial-Suscriptor (Publish-Subscribe) que encapsula la idea del callback. Este patrón de diseño lo estudiaremos más adelante.
    7. Diseñe la estrategia de manejo de errores. Este es un aspecto que es frecuentemente obviado, aunque tiene impacto fuerte tanto en el tiempo de procesamiento como en el esfuerzo de programación. Típicamente se recomienda manejar el error en el nivel que lo descubrió, si esto no es posible, dejar que lo resuelva la capa más arriba, pero generalmente abstrayendo el tipo de error para que sea comprensible en término de los servicios de la capa superior.

    Todo patrón tiene ventajas y desventajas: en el caso de la arquitectura de capas ya las hemos mencionado [dejar que los estudiantes las resuman]:

    • Ventajas
    • Reutilización de capas;
    • Facilita la estandarización
    • Dependencias se limitan a
      intra-capa
    • Contención de cambios a una o pocas capas
    • Desventajas
  • A veces no se logra la contención del
    cambio y se requiere una cascada de cambios en varias capas;
  • Pérdida de eficiencia;
  • Trabajo innecesario por parte de capas más internas o redundante entre varias capas;
  • Dificultad de diseñar correctamente la granularidad de las capas.
  • Arquitectura de capas en Sistemas de Información

    Existen tres propuestas de arquitecturas de capas para Sistemas de Información, donde las capas a veces reciben el nombre de niveles (en Inglés tiers):

    Arquitectura de dos capas;

    Arquitectura de tres capas;

    Arquitectura de cuatro capas.

    Las diferencias entre estas arquitecturas las pospondremos hasta que nos corresponda estudiar el proceso de diseño de un software. Por los momentos, seguiremos RPM en presuponer que apuntamos a una arquitectura de tres capas.