lunes, 9 de mayo de 2016

Este xoves gravamos para a TVG!

Este xoves pola tarde estaremos gravando unha entrevista para a TVG nas dependencias do Grupo de Tecnoloxía Electrónica e Comunicacións (GTEC) da Universidade da Coruña (UDC) na que falaremos brevemente do Proxecto Puding.

Quedades convidados. Agardámosvos!

miércoles, 15 de agosto de 2012

Planificación do proxecto

Aplicando o exposto na entrada anterior sobre o ciclo de vida, tocaba facer a planificación do proxecto. E para iso había que adaptar o esquema xeral ó mesmo. Déixovos a continuación o resultado final da adaptación, con explicación das tarefas incluida.
  1. Análise de viabilidade
    1. Determinación 1
      1. Obxectivos 1
          Estableceranse os obxectivos da fase de análise de viabilidade do proxecto.
      2. Alternativas 1
          Estableceranse posibles alternativas a eses obxectivos, aplicables no caso de que estes non se poidan cumprir.
      3. Restriccións 1
          Estableceranse restriccións aplicables a ditos obxectivos.
    2. Avaliación de alternativas e resolución de riscos 1
      1. Análise de riscos 1
          Determinaranse os riscos que comportan as distintas alternativas e as súas posibles solucións.
      2. Prototipo 1
          Realizarase un primeiro prototipo que nos permita intuir cómo será o producto final.
    3. Desenvolvemento e validación do seguinte nivel do producto 1
      1. Concepto de operación
          Trata de definir de maneira conceptual cómo se operará co producto, aclarando que é o que se pretende conseguir máis exactamente, de xeito que sexa máis sinxelo obter os requisitos nunha fase posterior.
    4. Planificación da seguinte fase ou ciclo 1
      1. Planificación de requisitos
          Estableceranse as tarefas da seguinte fase da planificación do proxecto, a análise de requisitos.
      2. Planificación do ciclo de vida
          Establecerase o ciclo de vida a empregar, xustificando o seu uso.
  2. Análise de requisitos
    1. Determinación 2
      1. Obxectivos 2
          Estableceranse os obxectivos da fase de análise de requisitos do proxecto.
      2. Alternativas 2
          Estableceranse posibles alternativas a eses obxectivos, aplicables no caso de que estes non se poidan cumprir.
      3. Restriccións 2
          Estableceranse restriccións aplicables a ditos obxectivos.
    2. Avaliación de alternativas e resolución de riscos 2
      1. Análise de riscos 2
          Determinaranse os riscos que comportan as distintas alternativas e as súas posibles solucións.
      2. Prototipo 2
          Realizarase un segundo prototipo que nos permita obter de maneira sinxela os requisitos do producto.
    3. Desenvolvemento e validación do seguinte nivel do producto 2
      1. Simulacións, modelos e programas de proba 2
          Estableceranse unha serie de probas a realizar sobre o prototipo anterior unha vez obtidos os requisitos.
      2. Requisitos hardware, software e económicos
        1. Extracción de requisitos propia
            Estableceranse os requisitos do producto por parte do proxectando.
        2. Extracción de requisitos por parte de expertos
            Estableceranse os requisitos do producto por parte de expertos preseleccionados.
        3. Extracción de requisitos a través dos usuarios
            Estableceranse os requisitos do producto por parte de usuarios aleatorios.
      3. Validación de requisitos
          Cruzaranse tódolos datos obtidos durante a obtención de requisitos e validarase por parte do proxectando e dos expertos que o producto é correcto (fai o que se lle pide), empregando as probas definidas anteriormente.
    4. Planificación da próxima fase ou ciclo 2
      1. Planificación do deseño
          Estableceranse as tarefas da seguinte fase da planificación do proxecto, o deseño.
  3. Deseño
    1. Determinación 3
      1. Obxectivos 3
          Estableceranse os obxectivos da fase de deseño do proxecto.
      2. Alternativas 3
          Estableceranse posibles alternativas a eses obxectivos, aplicables no caso de que estes non se poidan cumprir.
      3. Restriccións 3
          Estableceranse restriccións aplicables a ditos obxectivos.
    2. Avaliación de alternativas e resolución de riscos 3
      1. Análise de riscos 3
          Determinaranse os riscos que comportan as distintas alternativas e as súas posibles solucións.
      2. Prototipo 3
        1. Prototipo hardware 3
            Realizarase un prototipo hardware mediante ferramentas software.
        2. Prototipo software 3
            Realizarase un terceiro prototipo, baseado no prototipo da fase anterior integrando tódolos cambios precisos para pasar a validación de requisitos.
    3. Desenvolvemento e validación do seguinte nivel do producto 3
      1. Simulacións, modelos e programas de proba 3
          Estableceranse unha serie de probas a realizar sobre o prototipo anterior, co fin de determinar se o deseño posterior é correcto.
      2. Deseño do producto hardware e software
        1. Deseño do producto hardware
            Baseándose no prototipo hardware anterior, realizarase un deseño formal do producto hardware.
        2. Deseño do producto software
            Baseándose no prototipo software anterior, realizarase un deseño formal do producto software.
      3. Verificación e validación do deseño
          Verificarase que o deseño se fixo correctamente (que se axusta ás especificacións) e que é correcto (fai o que se lle pide).
    4. Planificación da próxima fase ou ciclo 3
      1. Planificación do desenvolvemento
          Estableceranse as tarefas da seguinte fase da planificación do proxecto, o desenvolvemento.
  4. Desenvolvemento
    1. Determinación 4
      1. Obxectivos 4
          Estableceranse os obxectivos da fase de desenvolvemento do proxecto.
      2. Alternativas 4
          Estableceranse posibles alternativas a eses obxectivos, aplicables no caso de que estes non se poidan cumprir.
      3. Restriccións 4
          Estableceranse restriccións aplicables a ditos obxectivos.
    2. Avaliación de alternativas e resolución de riscos 4
      1. Análise de riscos 4
          Determinaranse os riscos que comportan as distintas alternativas e as súas posibles solucións.
      2. Prototipado operacional
        1. Prototipo hardware 4
          1. Integración do hardware
              Seguindo o prototipo hardware realizado por software da fase anterior e o posterior deseño hardware, realizarase unha versión física do mesmo.
          2. Encapsulamento do hardware
              Unha vez integrado o hardware será preciso encapsulalo de forma que sexa sinxelo interactuar con el.
        2. Prototipo software 4
          1. Desenvolvemento do prototipo
            1. Elaboración dun prototipo software completo (incluindo a parte do controlador hardware).
          2. Gravación dos samples
              Elaboración, partindo de cero, dunha fonte de sons de calidade para empregar co producto.
    3. Desenvolvemento e validación do seguinte nivel do producto 4
        1. Simulacións, modelos e programas de proba 4
          Estableceranse unha serie de probas a realizar sobre o prototipo anterior, co fin de determinar se o deseño posterior é correcto.
        2. Deseño detallado
          1. Deseño hardware
              Ampliación do deseño hardware da fase anterior.
          2. Deseño software
              Ampliación do deseño software da fase anterior.
        3. Ensamblado e codificación
          1. Ensamblado
              Integración do hardware e do encapsulamento.
          2. Codificación
              Desenvolvemento completo software.
        4. Probas de unidade
            Testeo das distintas partes do producto facendo uso das probas definidas previamente.
        5. Integración e probas
            Fusión de tódalas partes do producto nunha única e posterior testeo facendo uso das probas definidas previamente.
        6. Probas de aceptación
            Verificación e validación do producto por parte de expertos.
        7. Implantación
          1. Simulación da implantación do producto nun sistema limpo e preparado para o mesmo. Por exemplo, unha máquina virtual creada expresamente para a defensa do proxecto.
Para pasar isto a algo manexable, seguindo a filosofía do proxecto, había que empregar software libre. Facendo un pouco de investigación e preguntando entre coñecidos con experiencia no tema, preseleccionei varios dos moitos existentes, para o seu posterior estudio:
 Nunha primeira avaliación por enriba, Planner e GanttProject parecéronme demasiado básicos, e LibrePlan todo o contrario, ademáis ser bastante máis lento.

Foi nesta primeira avaliación onde me decidín por OpenProj, lixeiro, completo e moi similar (por non dicir un clon) ó MS Project, que xa manexaba (co cal a curva de aprendizaxe e o tempo perdido sería menor).

Decidido entón por OpenProj, metín a antedita planificación nel. Todo ía ben, ata que aleatoriamente un día fallou. ¿Que cal foi o fallo? Poñámonos en situación.

Por motivos de dispoñibilidade de tempo (estudos, traballo e outras afeccións), decidín empregar un calendario de media xornada para o proxecto (si, 4 horas diarias durante a semana para o proxecto seguen sendo moitas horas, pero o que algo quere, algo lle custa).

Pois resulta que OpenProj, na versión que agora mesmo hai liberada, ten un problema cos calendarios se non son o estándar (xornada completa).

Concretamente, o que me fixo a min á hora de fallar foi que ó abrir o proxecto un día aleatorio, pasou de empregar un calendario de media xornada a un de xornada completa composto por dous de media xornada. É dicir, o que fixo foi meterme nun mesmo día dúas medias xornadas e, polo tanto, reducir a duración estimada do proxecto á metade. A partires desa data, aínda sen ter salvado o proxecto, facía sempre o mesmo.

Dito problema é non salvable polo usuario de ningunha maneira, polo que é preciso corrixilo no código. Polo que lin investigando pola rede, o erro está corrixido na seguinte versión, pero dita versión non é libre e non ten visos de selo en moito tempo (lembremos que tamén ten unha versión comercial).

Por dito motivo, e moi ó meu pesar, tiven que tirar con todo e volver comezar. Do que quedaba na lista, vistas as recomendacións, decidinme por Planner.

Planner é un xestor bastante sinxelo e rápido. Perdía algo de funcionalidade con respecto ó OpenProj, pero dado o atraso que levaba, e que os pequenos problemas que lle vía eran mitigables, tirei para adiante.

E alá fun. Meter todo de novo outra vez, pois os formatos non eran compatibles (alomenos o formato de Planner era un XML facilmente editable) e a xestión da información era totalmente diferente.

Todo perfecto. Ata que tocou asignar recursos materiais ás tarefas. Collo a primeira tarefa, que xa tiña asignado un recurso humano. Asígnolle un recurso material e a duración da tarefa redúcese á metade... espera un momento. Redúcese á metade. REDÚCESE Á METADE! É dicir, os recursos materiais consomen esforzo. CONSOMEN ESFORZO! É dicir, OS RECURSOS MATERIAIS TRABALLAN! Por favor, é que é de rir por non chorar. Para que nos entendamos, se nunha tarefa emprego, por exemplo, un paquete de folios, ese paquete traballa (si, si, con pico e pala, señores). Inadmisible.

Rapidamente notifiquei este e outros erros ós desenvolvedores, que prodeceron a marcarmos TODOS coma duplicados, cando moitos deles non eran tal e o resto tiñan un encabezamento máis descriptivo que os que xa había (por algo non os atopara), xuntándoos todos nun único "erro lixo" que logo será inmanexable, pero alá eles. Por este último motivo (e logo de que máis coñecidos lles insistiran e non obtiveramos resposta), desbotei tamén o Planner.

Chegados a este punto xa estaba canso, desanimado... de todo un pouco. ¿É que non pode haber un xestor de planificacións libre que non teña erros de bulto? Logo quéixanse de que a xente usa MS Project (que tamén ten erros de bulto -incluso peores- que o fan inusable por tódolos lados) e blah, blah, blah. En fin.

Desbotado o Planner, só quedaban o GanttProject e o LibrePlan. Empregar o último dábame respeto, así que decidín probar o GanttProject. Para daquelas tiña problemas coa máquina virtual de Java (linguaxe na que está desenvolvido) e entre iso e que me parecía extremadamente sinxelo (por non dicir incompleto) decidín desbotalo sen darlle sequera unha oportunidade.

Chegados a este punto, só me quedaba LibrePlan: servidor web, base de datos, interface web, multitude de opcións "a priori" complicadas, xestión da información totalmente distinta a canto tiña visto antes, alta curva de aprendizaxe e un longo etcétera. Para min, matar moscas a canonazos, vamos. Pero calquera cousa antes ca empergar MS Project. Así tivese que facelo totalmente a man.

E comecei a meter a planificación en LibrePlan. Ardua tarefa. A interface é lenta coma o cabalo do malo coxo, o que fixo da introducción dos datos unha lenta agonía. Levoume días. Tamén detectei algún erro leve (que se corrixiu en versións posteriores) e outro que parecía grave é ó final non era tal, senón un descoñecemento pola miña parte dun campo moi específico que LibrePlan xera automaticamente e que me daba problemas (graciñas a Javier Morán pola axuda prestada).

Pero pouco a pouco fun metendo todo. E por fin conseguín rematar. Moito tempo despois do previsto, pero mellor pouco e ben que moito e mal. E con todo, cheguei ó final, a planificación inicial, cun total de 688 horas de traballo planificadas. Déixovola a continuación.


A modo de conclusión, unha pequena reflexión. Ás veces merece a pena perder algo de tempo probando algo que sabes que será de calidade (aínda que teñas que matar moscas a canonazos) ca empregar algo máis rápido pero con alta probabilidade de fallo.

Ciclo de vida do proxecto

O ciclo de vida a empregar durante a duración do proxecto será o Ciclo de Vida en Espiral [1], por ser o que mellor lle acae debido ás súas características e vantaxes.

Dito ciclo de vida conta coas seguintes características:
  • Permite combinar a natureza interactiva de construcción de prototipos cos aspectos controlados e sistemáticos do modelo en Cascada.
  • Pon especial énfase na análise dos riscos.
  • O software desenvólvese nunha serie de versións incrementais:
    • Durante as primeiras iteracións, a versión incremental será un modelo en papel ou un prototipo.
    • Durante as últimas iteracións, prodúcense versións cada vez máis completas do sistema.
    • A idea básica é que cada fase (volta na espiral) establece os seguintes pasos:
      • Determinación de obxectivos, alternativas e restriccións.
      • Avaliación de alternativas (considerando análise de riscos).
      • Desenvolvemento do seguinte nivel de producto.
      • Planificación da seguinte fase (ciclo en espiral).
    • Cada ciclo (volta) na espiral representa unha fase do proceso de desenvolvemento.
      • Por ilo, o ciclo máis interno correspóndese coa viabilidade do sistema.
      • O seguinte, coa análise de requisitos e así sucesivamente.
    • Non hai fases fixas no modelo. O modelo adáptase ás necesidades que xordan en cada proxecto.
    • Os bloques de deseño, codificación e probas execútanse de forma secuencial para a entrega dunha características iniciais operativas.
    • Despois dilo, vólvese revisar o producto e cómo mellorar/ampliar as súas características operativas. O producto actualízase, obtendo un prototipo operativo “posto ó día” que serve de demostración e validación.
    • O sistema pasa por un proceso actualizado de desenvolvemento en cascada que finalmente obtén unha nova versión do producto.
Esquema básico dun ciclo de vida en espiral de 4 ciclos ou fases.


    • Esquema básico (espiral de 4 pasos):
      • 1º ciclo:
        • Determinación de:
          • Obxectivos
          • Alternativas
          • Restriccións
        • Avaliación de alternativas e resolución de riscos:
          • Análise de riscos
          • Prototipo 1
        • Desenvolvemento e validación do seguinte nivel de producto:
          • Concepto de operación
        • Planificación da próxima fase (ciclo):
          • Planificación de requisitos
          • Planificación do ciclo de vida
      • 2º ciclo:
        • Determinación de:
          • Obxectivos
          • Alternativas
          • Restriccións
        • Avaliación de alternativas e resolución de riscos:
          • Análise de riscos
          • Prototipo 2
        • Desenvolvemento e validación do seguinte nivel de producto:
          • Simulacións, modelos e programas de proba
          • Requisitos do software
          • Validación de requisitos
        • Planificación da próxima fase (ciclo):
            • Planificación do deseño
      • 3º ciclo:
        • Determinación de:
          • Obxectivos
          • Alternativas
          • Restriccións
        • Avaliación de alternativas e resolución de riscos:
          • Análise de riscos
          • Prototipo 3
        • Desenvolvemento e validación do seguinte nivel de producto:
          • Simulacións, modelos e programas de proba
          • Deseño do producto software
          • Verificación e validación do deseño
        • Planificación da próxima fase (ciclo):
          • Planificación do desenvolvemento
      • 4º ciclo:
        • Determinación de:
          • Obxectivos
          • Alternativas
          • Restriccións
        • Avaliación de alternativas e resolución de riscos:
          • Análise de riscos
          • Prototipado operacional
        • Desenvolvemento e validación do seguinte nivel de producto:
          • Simulacións, modelos e programas de proba
          • Deseño detallado
          • Codificación
          • Probas de unidade
          • Integración e probas
          • Probas de aceptación
          • Implantación

As vantaxes que presenta este ciclo de vida son as seguintes:
  • Permite adaptar o proceso de desenvolvemento ás necesidades cambiantes do proxecto e ó coñecemento que se vai adquirindo.
  • Permite o manexo de prototipos, ligándoos coa análise de riscos.
  • Xestiona explícitamente os riscos.

Pero tamén ten os seus inconvintes:
  • Require dunha considerable habilidade para a consideración do risco.
  • O modelo é relativamente novo e non se manexou tanto coma os anteriores.
[1] Temario da asignatura Enxeñería do Software da Facultade de Informática da Universidade da Coruña.

sábado, 7 de abril de 2012

Estudio de viabilidade

Imaxe cortesía de Lis Latas
Co fin de facer un estudio de viabilidade do proxecto, veño de elaborar unha enquisa en Google Docs* para avaliala.

Esta enquisa esta orientada a recoller os requisitos desexables dunha gaita MIDI e a estudiar o perfil do tipo de gaiteiro interesado nela.

A enquisa é totalmente anónima, a excepción dos datos xeográficos e de idade, precisos para a elaboración do perfil. Tódolos datos recabados serán empregados exclusivamente para a fin anteriormente exposta.

Os únicos requisitos desexables para cubrir a enquisa son:

1) Ser gaiteiro.
2) Responder o máis completa e correctamente á mesma. Os datos incorrectos, incongruentes ou incompletos son contraproducentes para o estudio, polo que serán excluidos dos resultados.

En caso de non cumprir estes requisitos, sempre podes axudar a difundila (a través da ligazón a esta nova, de RTs en identi.ca e Twitter, ou ben directamente á través da propia ligazón da enquisa).

A ligazón á mesma é a seguinte: http://enquisa.proxecto-puding.org

¡Graciñas a todos de antemán!

(*) Moi interesante esta función de Google Docs. Alomenos eu non a coñecía. Graciñas a Tiago pola recomendación.

miércoles, 4 de abril de 2012

Actualización de redireccións

Veño de actualizar as redireccións do dominio. Volverán estar dispoñibles en canto se actualicen os DNS. Desculpade as molestias.

miércoles, 29 de febrero de 2012

Novas seccións na páxina web

A partir de agora, na marxe dereita da bitácora tedes dispoñible unha sección na que aparecen reflexados os enderezos dos servizos do proxecto: forxa, rolda de correo e contas de promoción (posteriormente agregarei algún servizo máis).

Desta maneira non se perderán no limbo ó publicar novas entradas.

Tedes tamén dispoñible unha sección coas últimas novas da conta de Twitter, que lle dá algo máis de dinamismo á páxina e vos informa de novas que poden non estar publicadas na bitácora.

Ademáis, no fondo da páxina dispoñedes dunha subscrición RSS ás entradas publicadas (para min a maneira máis cómoda de seguir as publicacións da bitácora).

Agardo que sexa do voso agrado.

martes, 28 de febrero de 2012

Creación da forxa

Logo de avaliar unha gran cantidade das forxas de proxectos libres máis coñecidas (GitHub, Gitorious, SourceForge, ...), decidín aloxar o proxecto en Google Code por varias razóns:
  • Soporta xestores de versións distribuidos (coma Git ou Mercurial). Isto supuña unha razón de peso (e excluínte) para o proxecto, pois cara o futuro, precisarei telo replicado en varios servidores por diversos motivos que agora non veñen a conto.
  • O aloxamento é gratuito e sen restriccións funcionais. A única restricción é que o proxecto esté baixo unha licencia libre (dá varias opcións a escoller). Son un estudiante con ínfimos ingresos, polo que isto é importante tamén para min.
  • A interface é moi limpa, clara e sinxela e está libre de publicidade. Cando estás a traballar nun proxecto grande e serio, é importante que a interacción cos servizos que emprega sexa o máis agradable posible.
  • Ten multitude de servizos complementarios integrados dentro da forxa: descargas, wiki, incidencias, xestión de usuarios e perfís, etiquetas, informes, ligazóns a páxinas externas do proxecto, etc. Todos estes servizos son de grande utilidade á hora de xestionar un proxecto.
  • Intrégrase co resto de servizos de Google: Google Analytics para a análise do tráfico, Google Groups para a rolda de correo, etc. Son servizos facilmente integrables na forxa e indispensables á hora de xestionar debidamente un proxecto.
Moitas destas características estaban soportadas polo resto de forxas, pero ningunha era, ó meu parecer, tan completa. De aí a miña decisión. Poida que a moitos lles pareza cuestionable; pero ó empregar un sistema de xestión distribuido, sempre se pode chegar a mudar sen maior problema se for o caso.

Xa para ir rematando, déixovos por aquí o enderezo da forxa, por se a algún lle interesa botarlle unha ollada ó código ou ó servizo en si.