miércoles, 30 de noviembre de 2011

Financiación: Alternativas de financiamiento

Alternativas de financiación de empresas de base tecnológica



FONARSEC | EMPRETECNO

SEPYME | PACC

FONTAR | ANR Bio-Nano-TICs 2011




BANCO NACION | Programa para el Desarrollo Regional y Sectorial (PRODER)

Crédito Banco de Inversión y Comercio Exterior (BICE)-Agencia Nacional de Promoción Cientícica y Tecnológica |
CAE-AGENCIA-BICE

Agencia Nacional de Promoción Científica y Tecnológica
| FONTAR
ANR Patentes
Artículo 2º  Créditos Proy. de Modernización

Agencia Nacional de Promoción Científica y Tecnológica | FONSOFT
Créditos Exporta | ANR Capacitación

SEPYME | Programa de acceso al Crédito y a la Competitividad (PACC) |






ANR FONSOFT 2011

UVITEC informa que se encuentra abierta la convocatoria ANR FONSOFT 2011, dependiente de la Agencia Nacional de Promoción Científica y Tecnológica.

Los objetivos del llamado son: posibilitar la Certificación de Calidad; desarrollo de nuevos productos y procesos de software; e investigación y desarrollo precompetitivo de productos y procesos de software. Los beneficiarios serán aquellas empresas constituidas como tales al momento de la presentación de la solicitud y radicadas en el territorio nacional, productoras de bienes y/o servicios que satisfagan la condición PYMES dedicadas a la producción de software.

Tipo de Financiamiento:
I. Certificación de Calidad: Aporte no reembolsable por un monto de hasta PESOS CIENTO OCHENTA MIL ($180.000).
II. Desarrollo de nuevos productos y procesos de software: Aporte no reembolsable por un monto de hasta PESOS SEISCIENTOS MIL ($600.000).
III. Investigación y desarrollo precompetitivo de productos y procesos de software: Aporte no reembolsable por un monto de hasta PESOS OCHOCIENTOS MIL ($800.000).

En ningún caso estas subvenciones podrán superar el 50% del costo total del proyecto, debiendo la empresa beneficiaria aporta el resto.

La fecha límite de presentación de los proyectos será hasta el 19 de Diciembre de 2011 a las 12 hs.

Estos últimos podrán ser presentados en la Subdirección de Gestión de Proyectos del Ministerio de Ciencia y Tecnología de Córdoba, Álvarez de Arenales 230, hasta el día y hora señalados.

Bases y formularios
en:
http://www.agencia.gov.ar/spip.php?page=convocatorias_articulo&mostrar=1514





martes, 29 de noviembre de 2011

Mercado de software: La nube de Google

Google apuesta a la nube para seducir a las empresas

Es a través de sus aplicaciones de uso cotidiano por los usuarios pero a nivel corporativo; la Chromebook, como herramienta de trabajo unificadora


El anfiteatro de Google, recibió la conferencia para 350 empresarios del mundo.

"Google Atmosphere", una mirada de la nube.

La conferencia duró dos días con importantes oradores del sector.

Amith Singh, una de las máximas autoridades de Google Enterprise, presenta el evento.

Vint Cerf, considerado uno de los padres de Internet, presente en la conferencia.

Durante los tiempos libres, empresarios y público presente, testeaba las Chromebooks.

Rajen Sheth, director de producto de las Chromebooks, presenta las nuevas funcionalidades.

A medida de que se desarrollaba cada charla, un miembro del equipo de comunicación registraba en pizarras las ideas principales.

Jonathan Rochelle, realizó una demostración en vivo de la importancia de las herramientas que brinda Google.

La conferencia estaba rodeada por el trabajo diario de los que allí llevan adelante su labor; con el color característico de la empresa.

Astro Teller, brindó una de las charlas más interesantes sobre cómo construir lo imposible.

Bradley Horowitz, la cara visible de Google +. explicó las características de la nueva red social de la empresa estadounidense.



SAN FRANCISCO.- "El cambio es constante, por eso no hay que temer a lo nuevo". Con esas palabras, Vint Cerf , vicepresidente de Google y una de las voces más autorizadas para hablar sobre Internet, le explicó a más 350 CEO´s de todo el mundo que Internet está en constante innovación y transformación.
¿Y a qué se refería Cerf con el cambio? Básicamente a la necesidad de adaptarse a las nuevas tecnologías que colaboran y enriquecen el trabajo corporativo y empresarial. Ese fue el eje de la reciente conferencia " Google Atmosphere 2011 " realizada en el anfiteatro principal de la empresa estadounidense, donde se explicó de qué manera la nube (" cloud ", como se conoce la palabra en inglés) revolucionó el concepto de productividad.
Es simple: ¿por qué almacenar todos nuestros archivos en un sólo lugar si se puede hacer en miles y acceder a ellos desde cualquier parte del mundo? La nube es un concepto que a nivel usuario es utilizado diariamente: subir fotos en un álbum de Picasa, un video en YouTube o trabajar en un documento de forma online, son algunos de los ejemplos que se lleva a cabo cotidianamente. Pero, ¿qué pasa cuando se quiere realizar el mismo proceso a nivel empresarial? Ahí es cuando comienzan las dudas y preguntas de los que llevan adelante las empresas de cualquier rubro.

5 PREGUNTAS Y RESPUESTAS SOBRE LA NUBE

1- ¿De qué hablamos cuando hacemos referencia a " cloud computing "? Básicamente a trabajar de forma virtual sin depender de ningún tipo de infraestructura o servidores para interactuar con Internet. Archivos de texto, planillas de cálculo, fotos, videos, todo lo que se necesita para llevar adelante una labor, almacenada de forma virtual, en la Web.
2- ¿Cuáles son los principales ejes? Al menos Google lo presenta como una plataforma móvil y social. Esto es que no solo está disponible para trabajar en un notebook o PC de escritorio, sino también a través de las aplicaciones de un celular. Y a la vez, recientemente se añadió la función social a través de Google +, donde se apunta a las virtudes de la red social de la empresa norteamericana para que el contenido y la información que se maneja pueda compartirse con una idea distinta.
3- ¿Cuál es el beneficio de utilizar la nube? Entre los más relevantes se pueden mencionar al ahorro en infraestructura y en inversión. Lo primero es obvio: al trabajar con los archivos de forma virtual no se requieren servidores y lugares especiales montados por una empresa para mantener los mismos. El segundo viene en correlato con lo explicado recientemente: las empresas ahorran dinero ya que no deben mantener los servidores ni pagar cifras elevadas por las licencias de uso de cada usuario.
4- ¿Existen problemas de seguridad? Es una de las inquietudes más comunes de las empresas que se suman a la nube. Jorge Mieres, analista de Mal-ware de Kaspersky Lab,explicó recientemente a LA NACION que "las medidas de seguridad siempre se deben adoptar en el nivel más alto posible para minimizar las posibilidades de éxito de un ataque. Para lograrlo, es necesario estudiar en profundidad las capacidades de seguridad que ofrece el proveedor en cada una de sus capas en función del modelo de cloud computing empleado".
5- ¿Se pueden perder los datos que allí se almacenan? Una de las ventajas de trabajar con la nube radica en que la información que está almacenada de forma virtual no está en un sólo lugar, sino que está fragmentada en los diferentes servidores que tiene la empresa prestataria del servicio en el mundo. Por lo que, si uno de los lugares donde esta la información en ese momento falla, automáticamente se obtienen los datos solicitados de los otros.

EMPRESAS QUE SE ANIMARON AL CAMBIO

Cambiar en Internet, como decía Cerf, requiere de una decisión de los directivos de la empresa que consideren que la transformación será positiva. No siempre la vanguardia es bien recibida por los consejos directivos que prefieren mantener tradicionales esquemas antes de innovar en nuevos procesos.
Gustavo Aguirre, es CIO de OSDE, y estuvo presente en "Google Atmosphere 2011". La empresa prestataria de servicios de salud en el país recientemente migró 6.500 usuarios a la nube. "Hay que asumir riesgos", le dijo a LA NACION al tiempo que señaló: "En nuestro caso el cambio de mentalidad que propusimos con trasladarnos a la nube también fue empujado por la gente de la empresa que nos pedía formar parte del proceso de innovación".
"El eje central de lo que ven las empresas de la nube es la productividad del equipo: se puede trabajar todo el tiempo que se desee desde cualquier lugar", aseguró un directivo de Google a este medio. "Para nosotros significa mayor colaboración en todas las áreas. El límite no es de las personas, sino de la tecnología", acotó Aguirre.

CHROMEBOOKS: OTRA MANERA DE CONCEBIR UNA LAPTOP

Una de las herramientas más consultadas y testeadas durante la conferencia fueron las Chromebooks, las laptop que Google diseño especialmente para trabajar con Internet. Lo diferente de las notebooks que se conocen es que este aparato tiene se prende y en instantes se encuentra, siempre que exista una conexión, en la Web.
Para Rajen Sheth, director de producto de Google en el área de las Chromebooks, estas herramientas que fueron presentadas a mitad de 2011 son una verdad revolución. "Aquí esta todo lo necesario para trabajar en la nube. Están diseñadas para trabajar alrededor de los navegadores de Internet", explicó.
Sheth puso en relieve la importancia de algunas de las bondades de las Chromebooks: la duración de la batería que puede llegar a las 10 horas, la multiplicidad de aplicaciones que se pueden descargar y la rapidez de conexión a la Web, entre otras.



lunes, 28 de noviembre de 2011

Polos tecnológicos: MIT crea un ambiente para el desarrollo tecnológico

Dentro de un ecosistema de innovación
Historia, proximidad y hallazgos fortuitos hacen del Kendall Square un terreno fértil para la próxima gran idea.



El lunes, a las afueras del campus del MIT, los representantes de MIT y Pfizer Inc., junto con los funcionarios electos, participaron en una ceremonia en torno a lo que se convertirá en un centro de investigación de 180.000 pies cuadrados para la Unidad de Investigación de Neurociencia de Pfizer y su cardiovasculares, metabólicos, endocrinos y Unidad de Investigación de Enfermedades. Después de la ceremonia, que incluyó comentarios de gobernador de Massachusetts, Deval Patrick, Cambridge alcalde David Maher y el presidente del MIT, Susan Hockfield, los participantes recorrieron la cuadra de una recepción en el atrio de McGovern del MIT y los institutos de Picower.

La fiesta no sólo celebra esta nueva inyección de talento y trabajo en Kendall Square, sino también el ecosistema de innovación que el barrio de Cambridge ha creado. Todas las etapas de la innovación - desde la idea germina en un aula a un producto que se empujó en el mercado - se puede encontrar en Kendall Square: Según la Asociación de Kendall Square, una organización no lucrativa centrada en la mejora y la promoción de la comunidad local, el área contiene del mundo más denso milla cuadrada de la tecnología y la investigación en biotecnología.

"Hay lugares en todo el mundo en el que una gran investigación que sucede", dice Geoff Mamlet, director general del Centro de Innovación de Cambridge, una empresa que ofrece espacio de oficina y los recursos para las compañías de lanzamiento, la mitad de los cuales tienen conexiones de MIT. "Lo que hace única esta área y así es la comercialización: tomar una idea [y] encontrar la manera de poner juntos con todas las cosas necesarias para conducir al mundo."

Mamlet dice que la disposición física Kendall Square ayuda a impulsar la innovación: las empresas biotecnológicas grandes y pequeñas lindan MIT laboratorios de investigación, proporcionando oportunidades convenientes para la colaboración. Una reciente ola de tiendas y restaurantes se ha incrementado la posibilidad de establecer asociaciones casuales.

"Realmente creo que de Kendall Square como el semillero ... para todo el ecosistema de la innovación de Massachusetts," Mamlet dice. De hecho, un informe de 2009 realizado por investigadores de la Escuela del MIT Sloan de Administración determinó que Kendall Square basado en ciencias de la vida las empresas representaron dos tercios de todos los gastos en investigación y desarrollo de empresas de biotecnología de Massachusetts.

Apertura

Hoy en día, Kendall Square es un ecosistema dinámico, rico en recursos para apoyar la innovación. Pero para entender realmente lo que hace que este trabajo ecosistema, Mamlet sugiere mirar hacia atrás en su historia.

Las raíces comerciales de la zona comienzan en la década de 1940 y 50. Durante este período, la Corporación Interamericana de Investigación y Desarrollo, una firma de capital de riesgo de ese momento, se instaló en la zona como una asociación entre Georges Doriot, considerado el "padre del capitalismo de riesgo", y Karl Compton, entonces presidente del MIT. A finales de 1950, la empresa hizo lo que se ve hoy como el primer gran éxito en el capitalismo de riesgo, la inversión en Digital Equipment Corporation (DEC), una empresa de informática creada por dos ingenieros del MIT que buscaban para la comercialización de una nueva idea: la computación interactiva.

El diciembre se sentaron las bases para otras compañías para construir en Kendall Square, finalmente, el área fue apodada "AI Alley" para el número de empresas de software explorando la inteligencia artificial. Sin embargo, a pesar de la llegada de la industria, Kendall Square se mantuvo relativamente mediocre como destino la innovación.

"Había un ambiente comercial que fue prácticamente moribundo", dice Travis McCready, director ejecutivo de la Asociación de Kendall Square. "No había mucho de atractivo sexual a la dirección, de trabajar y estar en cualquier lugar cerca de Kendall Square, excepto por el hecho de que el MIT ha estado aquí."

Un gran punto de inflexión se produjo en la década de 1970, cuando Boston Properties y el MIT compró la tierra que fue arrasada originalmente en la década de 1960 para una planeada instalación de la NASA. La agencia espacial de revisión - el traslado de su Centro de naves espaciales tripuladas en Houston - y gran parte de los 43 acres de tierra había permanecido vacante durante años.

La compra puesto en marcha un plan de renovación urbana que con el tiempo empezar la construcción de centros de investigación como el Instituto Whitehead para Investigación Biomédica y el Instituto Broad.

Por la misma época, la ciudad de Cambridge se encontraba en medio de un intenso debate sobre la investigación del ADN. La genética era un territorio desconocido, y la ciudad celebró prolongadas deliberaciones sobre si y cómo participar en este tipo de investigación.

En última instancia, en 1976, Cambridge se convirtió en la primera ciudad del mundo para establecer una ordenanza local que regula la investigación con ADN recombinante. La ordenanza establece pautas claras para la investigación genética, que le abrió las puertas de la ciudad a la biotecnología, proporcionando acuerdo entre las autoridades municipales y los científicos sobre cómo practicar la investigación genética. Las compañías de biotecnología podría trasladarse a Cambridge a sabiendas de que, mientras ellos siguieron estas reglas, su trabajo contó con el apoyo municipal.

"Los resultados ... son extraordinarias", dice McCready. "Ahora las empresas como Pfizer se están moviendo en, ya tan sólo 35 años, la gente estaba volviendo loco sobre la investigación del ADN".

Dar vida a las ciencias

Mientras que Cambridge consolidó su posición en el ADN recombinante, el MIT se estaba expandiendo a muchos de sus departamentos académicos para incorporar las ciencias de la vida.

Martin Schmidt, rector asociado del MIT y profesor de ingeniería eléctrica, según algunos departamentos han tenido una larga historia en el campo de ciencias de la vida. Por ejemplo, su propio departamento de ingeniería eléctrica y ciencias informáticas, llevado a cabo las primeras investigaciones sobre el habla y la audición. Asimismo, el departamento de ingeniería mecánica trabajó en la mecánica de la prótesis.

En los últimos 20 años, dice Schmidt, el Instituto ha hecho un esfuerzo concertado en rama en ciencias de la vida: la ampliación de los departamentos existentes, la creación de un nuevo departamento de bioingeniería y erigir las instalaciones biomédicas.

"Así que usted tiene esta línea de tiempo de más de 15 o 20 años de la reubicación en este espacio del Instituto", dice Schmidt. "Ahora, probablemente no es de extrañar, que tenemos todas estas grandes empresas que quieren venir aquí, porque ven que como un talento y un motor de idea."

De hecho, el talento de Cambridge fue probablemente lo que inspiró al gigante farmacéutico Novartis con sede en Suiza a localizarse en Kendall Square en 2002, dice Schmidt.

"Ellos encontraron que cuando se publicó puestos de trabajo para los científicos PhD, que se vuelve mucho más para el puesto cuando estaba en Cambridge, en comparación con cuando el cargo fue en Basilea", dice Schmidt. "Conociendo la importancia de que el capital humano para el éxito de su empresa, que era una especie de obviedad."

Bernhardt Trout, un profesor de ingeniería química en el MIT, ha tenido una relación particularmente fructífera con Novartis. Trout recuerda reunión con representantes de la empresa poco después de que su sede Institutos Novartis de Investigación Biomédica en Kendall Square. Las conversaciones continuaron a través de los años, y en el año 2006, Novartis y Trout comenzaron a discutir continuo de fabricación - la manera de aumentar la eficiencia en la fabricación de fármacos de prescripción. La relación floreció rápidamente, y en 2007, los dos partidos formaron el Centro de Novartis-MIT para la fabricación continua, de los que la Trout es el director ejecutivo. Mirando hacia atrás, dice, que a Novartis como un vecino ayudó a sentar las bases para el centro.

"Incluso en los días de la Internet y Skype, no hay sustituto para estar en la proximidad y la implicación directa de las nuevas tecnologías", dice Trout.

Mañana: centro de tecnología atrae a jugadores grandes y pequeñas para apoyar la innovación.


MIT





jueves, 24 de noviembre de 2011

Gestión de proyectos de software

Gestión de proyectos


"La gestión de proyectos es la disciplina de organizar y gestionar los recursos de tal manera que estos recursos ofrecen todo el trabajo necesario para completar un proyecto dentro del alcance, tiempo y limitaciones de costo definidas". [Wikipedia]
Un director de proyecto rara vez toma parte en las actividades que producen el resultado final, lo que hace más bien es esforzarse por reducir el riesgo general de fracaso.

Los 5 principios de selección de personal
·         Elegir los mejores talentos
·         Coincidencia de trabajo (Job Matching)
·         Progresión de carrera
·         Equilibrio de equipo  
·         Eliminación del personal que no se adapte

¿Qué características muestra un buen equipo?
·         Compartir visión/objetivo
·         Identidad de equipo
·         Estructura guiada por resultados
·         Miembros competentes
·         Compromiso con el equipo
·         Confianza mutua
·         Interdependencia
·         Comunicación efectiva
·         Autonomía
·         Delegación de autoridad (Empowerment)
·         Tamaño de equipo pequeño

Gestión de Proyectos orientada a objetivos[1]
Fijar objetivos claros, con fechas de entrega claros, con la menor presencia de ambigüedades es el principio de un proyecto de software. Esa misma claridad ayuda a resolver muchos más problemas de los que se supone.

La gestión de la naturaleza humana
Si todos hicieran lo que debían hacer, no tendríamos necesidad de los administradores de proyectos o jefes de equipo. Si los programadores siempre escribieran código libre de errores, no tendríamos necesidad de equipos de prueba de software. Sin embargo, la realidad de nuestra industria es que los equipos necesitan líderes y gerentes, y el código necesita de pruebas. Como jefe de proyecto, usted se encontrará la tentación de culpar a los miembros del equipo cuando se escribe el código con errores o no cumplir con los compromisos del proyecto, que es una reacción natural, pero una errónea. Si el equipo fuese perfecto, no tendría que estar allí. Su papel, en gran medida, es ayudar al equipo a superar su propia naturaleza humana. Aquí están algunas de las expresiones del equipo de software, convirtiéndose en protagonista condición humana que se puede esperar: Los desarrolladores de software a escribir el código que está lejos de ser perfecto, con diseños que sean más convenientes que estratégicos. Los miembros del equipo participarán en disputas tristes, sin sentido, e infantiles sobre las cosas más triviales. El trabajo se ampliaría para dar cabida a el tiempo asignado para su realización (y más), y los proyectos se ejecutarán tarde. El equipo va a hacer todas estas cosas, no porque son malos, estropeados o infantiles, sino simplemente porque son humanos.

Haz que se sientan apreciados. La gente lucha entre sí a menudo porque están preocupados por su propio sentido de logro y la percepción sobre su trabajo. Cuando los empleados sienten que sus contribuciones son limitadas o están siendo percibidas de esa manera, es común que su frustración se dirija a sus compañeros de trabajo (y su jefe). Los psicólogos llaman a esta "proyección". Haga cumplidos periódicamente… son gratis.

El estado del proyecto hace girar al mundo. Es triste pero cierto. Cuando usted pide una actualización sobre el estado de los entregables del proyecto, los empleados se sienten obligados a entregar un buen mensaje. Recoger con regularidad informes sobre la situación mantiene a los miembros del equipo constantemente interesado en la producción de mensajes de buenas noticias para su gestión. El estado es una entidad que tipo Zen que exige el equilibrio. El personal subalterno y de bajo rendimiento puede tolerar más porque lo necesitan. El personal superior y las superestrellas que requieren menos molesta y más. Uso de informes de estado como un dispositivo para mantener a las personas en el camino y se centró, pero la demanda con cuidado con un ojo avizor sobre quién lo está pidiendo y cómo ello lo percibirán.

Ofrecer una salida para salvar la cara. A veces es necesario señalar a las personas que hicieron una macana o se fueron de ruta. Tienen que cambiar su forma o solucionar un problema. Como un jefe de proyecto y personal, no puede escapar a eso. Dicho esto, desea que la persona que recibe el mensaje de que abandone la sala motivados para cambiar y seguir trabajando con entusiasmo. Si alguien se deja sentir abatido, deprimido, o a la defensiva, las cosas pudiera derivar en resultados cada vez peores. Para evitar esto, asegúrese de que todas las conversaciones duras proporcionen al destinatario una salida para salvar la cara, una manera de salir de la sala con una sonrisa. No es tan difícil de hacer. Conceder algunos puntos, o puntos parciales, sobre las causas últimas por lo general se desinfla mucha de la tensión. En segundo lugar, a pesar de los problemas que se encuentran en proceso, permiten ser optimistas para el futuro si las cosas pueden dar la vuelta.

Haciendo uso de los estudiantes
Los estudiantes son mano de obra barata, a menudo muy productiva, y un gran forma de bajo riesgo para identificar el talento de estrellas. Incluso mejor, por lo general están felices y dispuestos de hacer todo el trabajo duro que sus bien pagados empleados superestrellas no quieren. Siempre me he sentido fuertemente que los estudiantes de prácticas a los estudiantes la cooperación triunfo para el valor debido a la complejidad de las posiciones de software en general significa que los primeros meses en el software trabajo es aprendizaje puro.
Para la mayoría de las posiciones de cooperación, el trabajo dura sólo unos meses, por lo que el tiempo efectivo que usted puede salir de los estudiantes es bastante escaso y, en algunos casos, los estudiantes de cooperación drenan más recursos que los que proveen. Los estudiantes de prácticas se suelen colocar por 8-16 meses, y se puede obtener un valor importante de ellos durante ese tiempo. Es un proceso de bajo riesgo para la identificación de talentos.
Piense en las prácticas de estudiantes como de su oportunidad de "probar y comprar." Si los estudiantes son superestrellas, usted descubrirá rápidamente a través del curso de su trabajo de duración. Si los estudiantes salen grandes o no, la experiencia de trabajo de duración dará una comprensión mucho más profunda de sus capacidades de una breve entrevista o prueba de aptitud podría hacerlo. Si un estudiante es un fiasco, no hay mucho daño, y no tiene la obligación de contratarlo de nuevo una vez que el estudiante termine su plazo. Los estudiantes son una fantástica manera de reclutar a los mejores y más brillantes, con poco riesgo, mientras que les asigna algunas de las tareas bajas en las que no quieres gastar sus programadores de alto costo y altamente experimentados.

El valor de medir el valor
Una de las cosas más difíciles para un equipo de desarrollo, y también uno de los más poderosos, es medir el valor del software que se crea. Es sensacional cómo medir el valor crea valor en sí mismo. Una de las grandes cosas acerca de la medición es que se presta a la imágenes. Se puede ilustrar un número en la forma de un gráfico de líneas, un gráfico de barras u otra forma. Considere un par de ejemplos de mi propia experiencia en IBM.

De ratones, hombres, y los planes de proyecto
Los planes de proyectos de software siempre tienen componentes de negocio (quien es nuestra audiencia, cuáles son las ventajas y beneficios que esperamos traer a ellos, cómo vamos a llevar nuestra tecnología al mercado, cómo va a ser monetizado), los de ingeniería (definiciones de características y especificaciones, el diseño, código, pruebas unitarias, pruebas de función, integración y pruebas de aceptación y pruebas del sistema), y los proyectos asociados a la gestión (análisis de dependencia, de personal y cronograma de desarrollo). En un sector tan dinámico como el nuestro, es virtualmente imposible planificar todos los aspectos de un proyecto desde el principio y ejecutar sin necesidad de variar el plan.

"No hay plan de batalla que sobreviva al contacto con el enemigo." De hecho, sólo los encuentros iniciales de una batalla pueden ser realmente previstas (y sólo si usted está planeando el primer ataque). Si hay un lugar común de la planificación de proyectos de software, es que el plan con el que se termina no puede ser el plan con el que se comenzó. Si es así, uno de los siguientes ha ocurrido:

·         Usted es un adivino y ha predicho el futuro con facilidad.
·         Usted está trabajando en un proyecto muy simple, y es probable que no necesitaba nada lo suficientemente sofisticados como para llamarse plan.
·         No han reaccionado a los cambios del entorno que te rodea, y que está a punto de entregar un proyecto de software que se ha incumplido gravemente sus objetivos.

Los planes de proyecto cambian, ya que, en cualquier proyecto con complejidad moderada, ciertos parámetros no se pueden conocer desde el principio. Desde el momento en que comienza hasta el momento en que el proyecto se completa, las piezas en movimiento, tales como una mejor comprensión de las necesidades, las partidas que se ejecutan antes de lo previsto (unas pocas) y otros que desbordan (varias), competidores introducen saltos en tecnología que fuerzan a modificar su estrategia, y la gente que mover, cambiar o desaparecer. Las estrategias de desarrollo iterativas han ayudado a hacer que la adaptación sea más natural, pero el cambio de un plan de negocios nunca es fácil.

La evaluación de la madurez de su desarrollo
El punto más importante acerca de metodologías de desarrollo de software es contar con una metodología y asegúrese de que el equipo lo está utilizando. Si usted está poniendo hacia fuera código sin un proceso establecido para ello, se va a quemar más tiempo y generar más errores en la parte final. El resultado neto será excesos de programación y presupuesto, de menor calidad y los requisitos probablemente no alcanzados. Las metodologías principales ampliamente en uso hoy en día incluyen los métodos ágiles de desarrollo, proceso en cascada de desarrollo de software, y la creación rápida de prototipos. Vale la pena conocer lo que cada uno de estos es en realidad.

Desarrollo iterativo
Qué es: Una metodología para el desarrollo de software que hace hincapié en la creación de software en las ondas de función. Cada ola debe ser totalmente funcional antes de proceder a la siguiente. Los equipos normalmente evolucionan a partir de un proceso en cascada de un proceso iterativo y luego a procesos más ágiles.
Ventajas: Esta metodología tiende hacia un entorno de desarrollo más estable debido a las características siguientes se construyen sobre una base estable. Generar las primeras etapas de aprendizaje para mejorar la siguiente. Los problemas son descubiertos antes. Características desarrolladas en algunas de las primeras iteraciones de obtener una mayor exposición a las pruebas y análisis de usabilidad.
Desventajas: las características finales del ciclo presionan en tiempo, poniendo un alto riesgo de baja calidad o falta de entrega. Los equipos maduros cortarán funciones para mantener la calidad y el horario características de alto riesgo temprano y de bajo riesgo (o de baja importancia) hacia el final, reduciendo al mínimo este peligro.

Scrum
Qué es: Una estrategia para organizar a la gente en un equipo de desarrollo para el trabajo de alta eficiencia y colaboración. Un scrum es un grupo de personas trabajando en un proyecto, cada uno con funciones específicas, como propietario de producto y un scrum master. Los scrums se reúnen regularmente (a diario) a tiempo fijo (por ejemplo, 15 minutos) y se organizan en torno a períodos "sprints", de tiempo de un par de semanas con los objetivos específicos definidos por el scrum. El scrum también hace hincapié en demos y la retroalimentación de los primeros usuarios. Además de las reuniones diarias, programan reuniones para ayudar a planificar los sprints y revisar las pruebas de sprints.
Ventajas: Este método es efectivo para forzar/fomentar la colaboración, el logro de respuesta temprana, y mantener el ritmo. El Scrum es un lugar sencillo, ideal para empezar como una incursión en los métodos ágiles. La metodología scrum/ágil se extiende a la planificación y gestión en todo el ciclo de desarrollo en orden de prioridad.
Desventajas: Aunque las reuniones diarias de scrum fomentar la colaboración y el progreso, algunas personas pueden empezar a tratar a presionar implacable en las actualizaciones y en el status de desarrollo. En segundo lugar, el scrum no es un proceso de desarrollo completo, es mejor aplicada como parte de un proceso iterativo/ágil. No cubre la tecnología/desarrollo de las prácticas, ni tampoco trata de iniciar un proyecto o la puesta en producción.

·         Al iniciar cada iteración, el equipo revisa el trabajo pendiente del proyecto y selecciona la parte que terminará como un incremento de funcionalidad incorporado al software al terminar la iteración.
·         Al final de la iteración el equipo presenta el incremento de funcionalidad a las partes implicadas en el proyecto.
El equipo revisa los requisitos, considera la tecnología disponible, evalúa sus conocimientos, y de forma colectiva determina cómo implementar la funcionalidad.

Roles
Scrum tiene una estructura muy simple. Todas las responsabilidades del proyecto se reparten en 3 roles:
·         Propietario del producto
·         Equipo
·         Gestor de Scrum (Scrum manager o Scrum Master)

Características
·         Scrum es un método adaptativo de gestión de proyectos que se basa en los principios ágiles:
·         Colaboración estrecha con el cliente.
·         Predisposición y respuesta al cambio
·         Prefiere el conocimiento tácito de las personas al explícito de los procesos
·         Desarrollo incremental con entregas funcionales frecuentes
·         Comunicación verbal directa entre los implicados en el proyecto
·         Motivación y responsabilidad de los equipos por la auto-gestión, auto-organización y compromiso.
·         Simplicidad. Supresión de artefactos innecesarios en la gestión del proyecto.


Proceso de desarrollo ágil
Qué es: También conocido como el Proceso de entrega ágil disciplinado, esto es una expansión del modelo de desarrollo iterativo en una metodología de software en toda regla de desarrollo. Se añade de scrum diario, equipos multidisciplinarios (desarrollo, pruebas de usabilidad, beta y envasado, comercialización, y así sucesivamente), y los ciclos de prueba totalmente completos para cada iteración. El desarrollo ágil hace hincapié en la adaptación a los conocimientos adquiridos en cada iteración.
Ventajas: El desarrollo ágil añade mejoras significativas en la calidad sobre la base iterativa modelo de desarrollo a través de más pruebas exhaustivas de cada iteración. Los scrums diarios mantienen a todo el equipo coordinado, y los equipos multidisciplinarios para que el trabajo es más que un festival de codificación. El desarrollo ágil captura el valor de negocio deseado (con especial énfasis en las historias de usuario para dar cuerpo a las definiciones tradicionales de problema) y busca una retroalimentación constante que los objetivos se están abordando.
Desventajas: Agotamiento. El desarrollo ágil es increíblemente eficaz, pero mantiene una intensa presión sobre los equipos de medida que pasan de iteración a iteración. La intensidad es mucho mayor que el desarrollo iterativo solo porque la metodología incluye varios aspectos adicionales del proceso de desarrollo, aparte de diseño y código.
En segundo lugar, como con cualquier modelo iterativo, las características finales del ciclo consiguen exprimir todo el tiempo.
En tercer lugar, la voluntad de adaptar los planes de producto basado en una nueva comprensión de cada iteración significa que los miembros del equipo (y empresarios) no puede saber con certeza lo que va a ser entregada hasta muy tarde. Un punto importante obstáculo se produce cuando los equipos de liderazgo tratan de aplicar los métodos ágiles para entregar proyectos de alcance fijo en una línea de tiempo fijo. Lo ágil se presta a sí mismo a la adaptación y la voluntad de compromiso en el contenido o en el cronograma a medida que las iteraciones perfeccionan la comprensión del equipo de las necesidades y prioridades.
En cuarto lugar, a diferencia de la metodología de cascada, que durante años ha abogado que el código sea probado por gente que no es su autor, el desarrollo ágil promueve las pruebas basada en autor como un método para acelerar el ciclo de prueba. Esto se suma a las pruebas de eficiencia, pero también presenta un riesgo considerable, ya que cualquier mala interpretación de los requisitos del proyecto que el programador tenía durante la edición del código probablemente se extenderá en el esfuerzo de la prueba.

XP: Programación Extrema

Qué es: Esta variación del desarrollo ágil pone gran énfasis en la programación por parejas (ver foto abajo), el desarrollo basado en pruebas (TDD), en el lugar las necesidades del cliente, la refactorización del diseño, y las revisiones de código intensa.
Ventajas: XP lleva los beneficios de las mejores características de ingeniería de software a un extremo. Se impone la idea de que dos cabezas piensan mejor que uno en cualquier trabajo de diseño y codificación, y el énfasis en las revisiones de código lleva a la calidad del código notablemente más altas que las revisiones de código siguen siendo la industria el método más eficaz para la detección de defectos y eliminación.
Desventajas: Los extremos rara vez son saludables en todos los aspectos de la vida, y por lo general este modelo no escala a los equipos grandes. A través de TDD, casos de prueba se escriben antes que el código del producto, que define la función prevista del producto aún está por escribirse. Debido a que los casos de prueba son en sí mismos el código, los defensores de XP escribir código que define el código (en lugar de escribir una especificación del lenguaje natural), un enfoque que algunos han argumentado que es incómodo y desalienta a recursos eficaces requisito.

Desarrollo lean
Qué es: Esta metodología de gestión de proyectos está estrechamente relacionado con el desarrollo iterativo. Favorece las decisiones de ciclo tardías, donde más conocimiento y entendimiento se dispone: “Comprométete a lo más tarde posible." Se hace hincapié en la reducción de residuos y la sobrecarga de proceso, se trata de reducir la burocracia. El desarrollo Lean también hace hincapié en la entrega de productos al mercado lo más rápido posible. El mantra del desarrollo magra dice mucho de su filosofía: "Piensa en grande, actúa pequeño, falla rápido, aprende rápido".
Ventajas: Este método mejora la eficiencia de la organización mediante la eliminación de residuos. La metodología Lean hace hincapié en la evaluación continua, idealmente a través de la medición, para eliminar los residuos. Esto explica por qué las obras de desarrollo ágil, proporcionando las filosofías fundamentales detrás de él. Requisitos y código que no contribuyen al valor de los clientes se dejan de lado. Los planes de producto no son considerados compromisos hasta tan tarde en el programa como sea posible.
Desventajas: el desarrollo Lean es más sobre los principios que de procesos. Es la metodología para los líderes para ayudarlos a implementar el desarrollo ágil de manera eficiente e integrar el proceso de desarrollo ágil con el pensamiento de negocios. El desarrollo Lean es alto en ideales, pero un poco menos específico acerca de las medidas preceptivas para su ejecución. De hecho, es más conceptual, y se necesita un mayor esfuerzo de aplicar que, por ejemplo, meter el scrum. Los programadores junior a menudo pierden el valor.

Lean Startup
“Lean Startup" es un término acuñado por Eric Ries, su método aboga por la creación de prototipos rápidos diseñados para poner a prueba hipótesis sobre el mercado, y utilizar la retroalimentación de los clientes para evolucionar mucho más rápido que a través de las prácticas más tradicionales de desarrollo de productos, tales como el modelo de cascada. No es raro ver a Lean Startups liberar el código nuevo a los tiempos de producción de muchas veces al día, a menudo usando una práctica conocida como la implementación continua.
Según el New York Times, "El término ‘lean startup" fue acuñado por el Sr. Ries, de 31 años, ingeniero, empresario y blogger. Su inspiración, dice, fue el proceso de manufactura lean, afinado en las fábricas japonesas hace décadas y centrada en la eliminación de cualquier obra o inversión que no produzca valor para los clientes. "
Lean startup es a veces descrito como Lean Thinking aplicada al proceso empresarial. Un principio central del pensamiento Lean es reducir los residuos. Los procesos lean startup reducen los residuos mediante el aumento de la frecuencia de contacto con clientes reales, por lo tanto, de las pruebas y evitan suposiciones incorrectas del mercado tan pronto como sea posible [5]. Este enfoque trata de mejorar las tácticas empresariales históricas, reduciendo el trabajo necesario para evaluar los supuestos sobre el mercado, y disminuyendo el tiempo que toma una empresa para encontrar la tracción del mercado. Esto se conoce como producto viable mínimo (MVP).

En The Entrepreneur's Guide to Customer Development, Brant Cooper y Patrick Vlaskovits añaden un cuarto elemento, y que es el uso de potentes herramientas de análisis y de bajo costo y fácil de usar. Si bien algunas características de los lean startups se ​​han practicado durante años, la confluencia de estas tendencias es un reciente fenómeno que aumenta la velocidad de iteración o el "número de ciclos de aprendizaje por dólar", como el foco de negocios que ajustan productos a mercados. [6]

Principios del Lean Startup
·         Entrepreneurs are Everywhere
o   En Estados Unidos… pero acá también "Think big. Start small. Scale Fast."

·         Entrepreneurship is Management
o   Un emprendimiento es una institución, no sólo un producto por eso requiere un tipo de gestión enfocado en un ambiente de extrema incertidumbre.
·         Validated Learning
o   Los emprendimientos existen para aprender cómo construir una empresa sostenible. Este aprendizaje puede ser validado científicamente realizando experimentos frecuentes que le permiten al emprendedor evaluar cada elemento de su visión.
·         Innovation Accounting
o   Hay que medir progresos, establecer puntos de referencia y priorización de tareas. Eso requiere un tipo de contabilidad diseñada para emprendimientos.
·         Build-Measure-Learn
o   Todos los emprendimientos convierten ideas en productos, miden como responden los clientes y aprender si pivotear o perseverar. Todos los emprendimientos deben acelerar este bucle.

Proceso de Desarrollo de Cascada
Qué es: Este es el modelo clásico de desarrollo de software, donde el desarrollo progresa en una secuencia lineal desde los requisitos hasta la especificación, luego el diseño, código, unidad, prueba de verificación funcional, prueba de integración, de aceptación/beta, prueba del sistema de verificación, y el producto listo para despachar.
Ventajas: Los desarrolladores de software saben lo que tienen que hacer por adelantado. Los planificadores de negocios, marketing, y todos los equipos de ventas comprender el contenido del producto y fecha de lanzamiento desde el principio. Bajo riesgo para desarrollos bien conocidos y tecnología familiar.
Desventajas: comprenden plenamente las necesidades y complejidad de producir una solución que va a entregar en 9-18 meses es por lo general casi imposible de hacer por adelantado. El proceso de cascada casi garantiza una necesidad de un cambio de plan a mitad de ciclo, pero no está bien diseñado para darle cabida. En segundo lugar, un ámbito fijo y horario aprieta calidad cuando aumenta la presión programar en la parte final del ciclo, donde todas las pruebas y corrección de defectos se producen. Por adelantado los planes son frágiles y se rompen con facilidad. Mercados, necesidades del cliente, adquisiciones, competencia, y consideraciones similares cambiantes continuamente rompen el plan.

Figura 1. Modelo de Cascada



Prototipado rápido
Qué es: Esta es la idea de que cualquier software de diseño complejo debe ser un prototipo antes una prueba de concepto, para entender sus fortalezas y debilidades antes de ejecutarlo. Este modelo se utiliza a menudo como una fase temprana del modelo de desarrollo cascada.
Ventajas: El prototipado rápido saca mucho del riesgo del proceso de desarrollo de cascada. Los primeros prototipos ayudan a explorar los límites de un diseño propuesto al inicio del ciclo.
Desventajas: el código del prototipo suele ser bastante desordenado y limitado. Después de un prototipo exitoso, el código de prototipo debe ser desechado, y el equipo debe continuar el enriquecimiento del proyecto utilizando la metodología de cascada clásica. Sin embargo, los equipos han encontrado por doquier que es casi imposible resistirse a usar el código de prototipo como el punto de partida para el desarrollo de productos. El resultado neto es un producto final integrado en su núcleo en la parte superior de la baja calidad del código no fiable.

Figura 2. Historia del uso de los modelos de ciclo del software


Procesos de desarrollo de software actualmente
Las organizaciones modernas de desarrollo tienden cada vez más hacia los métodos ágiles (ver el lado izquierdo de la figura), pero los métodos ágiles también tienen sus problemas. Ya sea que elija una estrategia ágil o un modelo más clásico, puede aplicar estos métodos para gestionar una organización de software de primera clase y desarrollar software de alta calidad.



Prueba de Madurez

PREGUNTA SI? PUNTOS
1.       ¿Su equipo históricamente entrega los proyectos con las características de mayor prioridad, con una calidad excelente, y en 20% antes de la fecha de entrega prevista originalmente?  (10 puntos)
2.       ¿Su equipo utiliza un sistema de seguimiento de defectos? (10 puntos)
3.       ¿Su equipo utiliza un sistema de control de código fuente? (10 puntos)
4.       ¿Está claro para cada arquitecto, programador y tester el proceso que se debe utilizar para los requerimientos, especificación, el seguimiento de la gestión de código, pruebas y defectos? (10 puntos)
5.       ¿Su equipos crea y revisa planes de prueba que definen las pruebas que pretenden llevar a cabo? (10 puntos)
6.       ¿Su equipo de gestión de proyecto rastrea la tasa de defectos de las nuevas tasas de arribo y del tamaño nuevos retrasos?
7.       ¿Todas las personas que trabajan en el producto tiene una definición clara y unánime para la palabra "hecho?" (5 puntos)
8.       ¿Llevas a cabo pruebas de campo (programas alfa y beta) y/o estudios de usabilidad para obtener retroalimentación temprana? (5 puntos)
9.       ¿Sus desarrolladores entiendan claramente los objetivos de negocio a corto plazo para el producto que están trabajando, como la claridad en lo que los segmentos principales del mercado que son para el producto? (5 puntos)
10.   ¿Su equipo de pruebas interno puede escalar con el tamaño y la intensidad de su mayor número de usuarios esperado? (5 puntos)
11.   ¿Tiene la organización de desarrollo una mayor claridad tanto en la fecha de finalización del proyecto y una serie de hitos intermedios? (5 puntos)
12.   ¿Su equipo crea y revisa completamente las especificaciones del producto antes de que esté más del 30% terminado con la fase de codificación? (5 puntos)
13.   ¿Tiene su equipo descripción por escrito de los requisitos del proyecto, en la forma de una especificación, enunciados de los problemas, o los escenarios de usuario? (5 puntos)
14.   ¿Están por lo menos el 80% de los casos de prueba automatizados y se realizan de forma periódica? (5 puntos)
15.   Total (puntuación máxima: 100)
Si su puntaje es inferior a 70 en esta prueba, tienes un serio problema con la madurez de su organización de software. 
Si su puntaje es mayor de 90, felicitaciones, en mi opinión, está trabajando en un grupo que está en el percentil más alto de madurez en desarrollo de software.

Defectos de software y costos y eficiencias
Siempre es bueno captar los defectos del software en las etapas iniciales de cualquier ciclo de desarrollo de software. Si éstos salen a la luz en los estadios finales, resulta en altos costos y riesgos para todo el proyecto.
·         Más costos de soporte significan menos dinero para un nuevo desarrollo.
·         Desarrolladores de software gruñones significa un equipo de desarrollo menos motivado y eficiente.
·         Defectos a finales del ciclo en gran medida afectan la capacidad del equipo para concluir el proyecto, dando lugar a excesos de horario.
·         Menor calidad en el producto enviado conduce a menor satisfacción del cliente y reduce el éxito del producto. La baja calidad se traduce rápidamente a reducción de los ingresos.



Con el entendimiento de que los esfuerzos de calidad en las partes finales del ciclo cuestan dramáticamente más y produce menos, ¿cómo un aspirante a gerente de proyectos evitará los escollos y atolladeros de la detección tardía en el ciclo?
·         Revisiones de diseño, especificación, y código siguen siendo el método más eficaz para la detección de defectos tempranos.
·         Use una metodología de desarrollo iterativa para que las pruebas se lleven a cabo en las olas durante todo el ciclo de desarrollo, no como una masa de fondo del proceso.
·     Construya en la capacidad de prueba mediante la adición de numerosos puntos de seguimiento, afirmaciones y ganchos de programación que puede obligar a las condiciones de prueba (por ejemplo, la simulación de una restricción de memoria o falla en el dispositivo cuando no existe).


[1] Ligthstone, Sam “Making It Big in Software”. Prentice Hall, capítulo 15

Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Best Hostgator Coupon Code