miércoles, 16 de julio de 2014

Especificacion de requirimientos

La especificación de requisitos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.
Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.
Link


Rodrigo Gonzalez

domingo, 11 de mayo de 2014

Tarea Nº6 - Frameworks


Los Frameworks son todos muy diferentes y tienen la particularidad de que han sido creadas por diferentes razones y para alcanzar diferentes objetivos. El elegir un framework entonces, obviamente depende del tipo de proyecto que lo requiera, lo cual hace muy difícil su elección. Como hay muchas características que pueden influir en la decisión, se presentan 3 distintos Framework de acuerdo a diferentes características. Los 3 framework serán Spring, JSF y Struts.

Link: Aqui 

---
Rodrigo Gonzalez
Alejandro Barra

viernes, 18 de abril de 2014

Tarea Nº5 - Estadísticas de Proyectos de Software

En muchos artículos, reportajes, e incluso trabajos orientados a la Ingeniería de Software aparecen estadísticas de los proyectos llevados a cabo. Estas estadísticas nos entregan mucha información: el éxito, fracaso o estancamiento de un proyecto, así como sus causas habituales. 
Ahora, la pregunta es ¿Que tienen de especial estas estadísticas?. Bueno, los números que generalmente aparecen son atroces (con respecto a otras ingenierías), aunque han ido mejorando con el tiempo a través de los métodos ágiles para el desarrollo de software, precisamente por estas mismas estadísticas que se presentan a continuación.
Los datos sacados son de "Chaos Manifesto 2013", que es un informe de "Chaos Report", una de las estadísticas mas usadas actualmente. Se realiza cada dos años desde 2004 hasta la fecha. El reporte Chaos clasifica a los proyectos como exitosos, fracasos, o estancados, y en el "Chaos Manifesto 2013" incluye una estadística de los proyectos entre 2004 - 2012 y que usan metodologías ágiles o en cascada. A continuación, los aspectos mas importantes de dicha estadística:
  • Datos Generales de Proyectos de Software desde 2004 a 2012

Estos son los datos generales de los proyectos desde 2004 hasta 2012, en donde, por ejemplo los datos del 2012 arrojan que un 39% de los proyectos fueron exitosos, 43% se entregó pero fuera de plazo o con un costo mas elevado del originalmente presupuestado, y un 18% finalmente se canceló.
  • Datos Generales de Proyectos de Software de 2012 de pequeños proyectos, versus grandes proyectos.


The Chaos Manifesto clasifica a "pequeños proyectos" los que cuentan con un presupuesto de menos de un millón de dolares, mientras que clasifica como "grandes proyectos" a los que tuvieron un presupuesto mayor a 10 millones de dolares.
El  informe deja establecido ciertos factores comunes dentro del éxito en los proyectos que se llevaron a cabo. El primero es la calidad del Personal Ejecutivo de Apoyo. Según el informe, un buen personal debe tener ciertas cualidades que se refleja el informe:
- Visión Simple
- Compromiso
- Decisiones
- Velocidad
- Enseñanza
- Mediciones
- Negociaciones
- Plan
- Kill Switch
- Felicitaciones
Estos 10 puntos que toma el manifiesto y que los explica a fondo en el informe, son parte de lo que ha llevado a ser exitosos a los proyectos pequeños. Los proyectos que siguieron esta "metodología" obtuvieron los siguientes resultados, en donde un 78% de los proyectos se llevaron a cabo, un 20% tuvo problemas en su entrega, y solamente un 2% se cancelo definitivamente:


El segundo punto que toma como factor de éxito es la Participación de los Usuarios. Solo la activa participación de los usuarios podrá darle un mayor porcentaje de éxito a los proyectos, aunque este puede ser un trabajo mas dificultoso que cualquier otro. A continuación los números de la dificultad que tuvieron los desarrolladores en colaboración con los usuarios:


El tercer punto es la Optimización. Se refieren con optimización a la capacidad de separar proyectos grandes en muchos proyectos pequeños. Esto con la finalidad de tener un mayor enfoque dentro de los recursos asignados a cada equipo. Esto se traduce en un valor, en donde los proyectos pequeños son mayormente valorados por su optimización.
El cuarto punto es la Especialización de recursos, que significa tener a la gente adecuada haciendo las cosas correctamente en el momento adecuado. La elección de personal competente para realizar determinadas tareas es otro factor importante en la hora del éxito del proyecto.


El quinto factor es la Experiencia del Project Manajer. La experiencia y el talento de la persona a cargo del proyecto es enormemente importante. De hecho una persona con una basta experiencia en proyectos grandes puedes fácilmente manejar múltiples proyectos pequeños. El siguiente gráfico muestra el procentaje de certificación de los PM desde 2008 a 2009

El sexto factor son los Procesos Ágiles. Las metodologías (que funcionan mejor en los proyectos pequeños, que en los proyectos grandes) logran una gran diferencia. En los últimos años la utilización de metodologías ágiles a mejorado considerablemente la producción de proyectos. El siguiente es un gráfico de los proyectos que utilizaron metodología en cascadas y procesos ágiles.



El séptimo factor son los Objetivos Claros de Negocio. Hay que eliminar la ambigüedad dentro del proyecto y tener claro los objetivos, metas, métodos de llegar a esas metas, y definiciones para evitar malos entendidos entre las partes. 
El octavo factor es la Madurez Emocional. Esto significa tener la suficiente consciencia, autogestión, compromiso y control frente al proyecto. Estas habilidades están fuertemente ligadas no solo al líder del proyecto, sino también a los diferentes participantes. Solo con la suficiente madurez se podrá enfrentar conscientemente el proyecto y sus complicaciones y contratiempos.
El noveno factor es la Ejecución. La ejecución es el acto de tomar un proyecto hasta su finalización en base a un plan. En general, es más fácil llevar un pequeño proyecto hasta su finalización que una grande. Es incluso más fácil cuando se combinan pequeños proyectos con la gestión financiera y de una metodología formal.

El décimo factor son las Herramientas e Infraestructura. Herramientas indicadas en un entorno propicio ayudan a que el éxito del proyecto sea concluyente. Sin las herramientas o tecnologías necesarias, el proyecto puede salir de presupuesto o quedar fuera de plazo.

Todos estos puntos son solamente referencias para la estadística del reporte Chaos, sin embargo proporcionan un buen pie para enfrentar los proyectos venideros.
Para mayor información pueden consultar directamente el manifesto Chaos en el siguiente enlace.
--------------------------
Rodrigo González







Tarea Nº4 - ¿Requisito o Requerimiento?

Después de leer el artículo ¿Requisitos o Requerimientos? el autor llega a una conclusión final y al parecer bastante decidora: Se debe hablar como Ingeniería de Requerimientos y no de Ingeniería de Requisitos. Pero lamentablemente el artículo se basa demasiado en el sentido o significado que uno quiera darle a las palabras. 
Se habla demasiado de como se nombra la palabra en otros idiomas, los errores quizás de traducción, e incluso lo que dice la RAE acerca de las palabras, cuando lo que de verdad importa es lo que dice una entidad importante dentro de la materia de computación y electrónica como lo es le IEEE, en donde claramente se refiere a los requerimientos como las necesidades de los clientes, es decir, la ingeniería de requerimientos se ocupa de llevar a cabo las necesidades de los clientes.
Es decir, ¿el artículo está equivocado? No del todo. Es obvio que existen ambigüedades y tal como se menciona, el tema seguirá en el aire durante mucho tiempo. Las materias lingüísticas y comunicacionales mencionan que las palabras no son ni siquiera sinónimos, pero todo va de la mano en el sentido que uno quiera darle a las palabras. Si yo tomo las necesidades de mi cliente y las llevo a cabo, ¿Es necesario hacer una discusión por si tomamos requerimientos o requisitos? La verdad poco importa, ya que ni el cliente, ni las personas que participaron en el proyecto llegarán a una confusión. Asimilarán el concepto inmediatamente y por ende, no existirá ningún problema de comunicación. Al contrario, la comunicación será mas clara entre las partes que formar una discusión si se tomaron requerimientos o requisitos.
En resumen, en todos lados hay autoridades que deben respetarse. La de Computación es la IEEE y dice claramente, que los requisitos son las necesidades de los clientes. Lo demás es buscar discusión.

-----
Rodrigo González





Tarea Nº3 - The App Date


El día 01 de Abril de 2014 se celebró el primer "The App Date" en la ciudad de Santiago. Por si no lo conocen, el The App Date es el evento mas grande del mundo en materia de aplicaciones, realizado en muchos países y por fin se presentó en Chile para quedarse. 
El evento organizado por la Universidad de las Américas (con la ayuda de Microsoft, Ibex Technologies y Mediastream) reunió una cantidad importante de gente de muchas áreas de la computación (tanto en el desarrollo de aplicaciones, como en el diseño; comerciantes, estudiantes, etc.), dejando prácticamente completa la sala Zócalo de la UDLA.
El evento comenzó con prácticamente cuarenta minutos de retraso (como para seguir la línea de que los programadores no sabemos cumplir plazos, quizás). Esto al final complicó el evento, ya que los expositores tuvieron menos tiempo del presupuestado para su presentación, y quizás con algo mas de tiempo (al menos un minuto por persona) se hubiera podido realizar algo mas completo.

El primer expositor de la cita fue Nicolás Palacios, uno de los fundadores de la empresa E-Pig Games. Durante aproximadamente 20 minutos nos contó su experiencia acerca de como logró que su producto fuera el Nº1 durante varias semanas en las distintas "store" de aplicaciones en diferentes sistemas. Nos mostró también como la mayor parte del éxito de su trabajo fue a través de la impresión visual que producían, que lo primero en que se fija una persona es en lo visual y que ese fue el enfoque.
Una de las partes mas interesantes de su charla, fue cuando explicó la forma en la que reclutaron gente para poder trabajar en su proyecto. A través de redes sociales y entrevistas masivas pudieron encontrar a la persona idónea para el cargo, algo que en la practica puede ser complicado lo hicieron bastante simple y rápido.
En resumen, una charla rápida, envolvente aunque con lamentablemente una gran cantidad de material audiovisual, en donde se perdieron mas de 5 minutos. Interesante propuesta, pero con mas charla y mas respuestas de las preguntas de los asistentes hubiera sido mejor.
Posterior a eso de la nada apareció algo entretenido para los asistentes del evento. Debiamos votar a traves de Twitter con el hashtag del The App Date y la aplicación que nos gustaba de los expositores que se presentarían en unos minutos con la siguiente dinámica:

  • Se presentan 4 expositores con sus respectivas aplicaciones.
  • Cada expositor tiene 2 minutos para lograr mostrar su aplicación para todos, y convencer que su aplicación es la mejor
  • La aplicación ganadora se lleva un premio de Microsoft (apoyo para su desarrollo) y la persona que haya votado a traves de Twitter por dicha aplicación podría participar en un sorteo para también un premio de Microsoft.

Las aplicaciones participantes fueron las siguientes:

  • Plantsss: App que nos ayuda a identificar que plantas se encuentran en el lugar que estas, que plantas cultivar, utilizando toda la tecnología de geolocalización que brindan los smartphones.
  • WOF: Red Social para los amantes de los perros. La gracia de esta aplicación y su aspecto mas rescatable, es la posibilidad de ayudar a perros heridos en la calle, mostrando su localización.
  • Beender: Una red social distinta. Simplemente se comparte todo lo que se te venga a la mente, agregando lugares, frases, fotos, etc.
  • Stories: Aplicación muy parecida quizás a Tenia que decirlo, pero con un valor mas artístico que cómico.
La votación se realiza desde la exposición de la última app, a través de Twitter, e inmediatamente parte la última exposición: la app de loharia.com

A través de una exposición rápida y a veces desubicada, Uri Martinich presentó su proyecto loharia.com. Digo rápida porque la exposición fue de una velocidad mas acelerada de lo que se requería para poder entender no solamente su postura como desarrollador o creador de un producto, si no que su proyecto tiene también un trasfondo y una complejidad mayor al trabajar directamente con dineros, reputaciones, etc. Y También digo desubicado por la falta de tino a veces para la elección de sus palabras, y el excesivo sarcasmo en su manera de hablar, que desvió a veces el verdadero propósito de su exposición: hablar de su proyecto y no de su comicidad.
En fin, ahondando en su materia, nos cuenta como fijo un objetivo bastante claro en la propuesta de su proyecto: ser el mercado libre de servicios. Y hasta el momento lo ha logrado, con plataformas en distintos países.
Un aspecto importante de su charla, fueron los problemas que se le presentaron al pasar loharia.com a móvil:

  • Si bien en Chile existen cantidades de smatphones y velocidades relativamente rápidas, en el resto de América eso no sucede.
  • Al comenzar a desarrollar en una plataforma potente como lo es la web, pasar toda esa potencia a un dispositivo móvil fue bastante complicado. Nos recomendó primero hacer algo bastante liviano para luego en web incorporarles mas funcionalidades.
  • Si bien no fue un problema aplicado solamente a tecnología móvil, el hecho de lidiar con SII y Sernac fue un tema bastante complicado de resolver. Su solución obviamente fue asesorarse por abogados que lo ayudaron a lidiar con este vacío en su propuesta de negocio.
Posteriormente se dio comienzo a una tanda de preguntas, en las que la mayoría preguntó sobre como imaginó estas propuestas de negocio y de como llegaron a la mente sus ideas. Buenas respuestas, para buenas preguntas, en donde el mensaje mas claro que envió Uri fue el de aprender algo que no sepas, y si no lo quieres aprender, asesórate de alguien que si lo sepa.

Luego de eso comenzó el "Networking" en donde los asistentes al evento compartimos nuestras experiencias y contactos con personas de diferentes áreas de la computación. También hubieron stands de Microsoft ofreciendo apoyo para desarrolladores con propuestas definidas y que necesitaran ayuda monetaria.
En medio del Networking se sorteó la ayuda de Microsoft a las aplicaciones que participaron en el App Date. Al final ganó la aplicación que peor se expuso y que obviamente causó menos impacto: Beender. Felicitaciones igualmente al ganador de aplicación y al ganador de Twitter.

Luego de eso concluyó el evento, con una muy buena impresión entre los asistentes, y con la esperanza que los pequeños detalles mejoren en el próximo encuentro de Mayo. Y obviamente, que Universidad Central apoye a que el mes de Junio sea en nuestras sedes. Gracias al profesor Fischer por la invitación a una muy buena experiencia a un mundo en que nos adentramos cada vez mas.

------
Rodrigo Gonzalez