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.
- Análise de viabilidade
- Determinación 1
- Obxectivos 1Estableceranse os obxectivos da fase de análise de viabilidade do proxecto.
- Alternativas 1Estableceranse posibles alternativas a eses obxectivos, aplicables no caso de que estes non se poidan cumprir.
- Restriccións 1Estableceranse restriccións aplicables a ditos obxectivos.
- Avaliación de alternativas e resolución de riscos 1
- Análise de riscos 1Determinaranse os riscos que comportan as distintas alternativas e as súas posibles solucións.
- Prototipo 1Realizarase un primeiro prototipo que nos permita intuir cómo será o producto final.
- Desenvolvemento e validación do seguinte nivel do producto 1
- Concepto de operaciónTrata 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.
- Planificación da seguinte fase ou ciclo 1
- Planificación de requisitosEstableceranse as tarefas da seguinte fase da planificación do proxecto, a análise de requisitos.
- Planificación do ciclo de vidaEstablecerase o ciclo de vida a empregar, xustificando o seu uso.
- Análise de requisitos
- Determinación 2
- Obxectivos 2Estableceranse os obxectivos da fase de análise de requisitos do proxecto.
- Alternativas 2Estableceranse posibles alternativas a eses obxectivos, aplicables no caso de que estes non se poidan cumprir.
- Restriccións 2Estableceranse restriccións aplicables a ditos obxectivos.
- Avaliación de alternativas e resolución de riscos 2
- Análise de riscos 2Determinaranse os riscos que comportan as distintas alternativas e as súas posibles solucións.
- Prototipo 2Realizarase un segundo prototipo que nos permita obter de maneira sinxela os requisitos do producto.
- Desenvolvemento e validación do seguinte nivel do producto 2
- Simulacións, modelos e programas de proba 2Estableceranse unha serie de probas a realizar sobre o prototipo anterior unha vez obtidos os requisitos.
- Requisitos hardware, software e económicos
- Extracción de requisitos propiaEstableceranse os requisitos do producto por parte do proxectando.
- Extracción de requisitos por parte de expertosEstableceranse os requisitos do producto por parte de expertos preseleccionados.
- Extracción de requisitos a través dos usuariosEstableceranse os requisitos do producto por parte de usuarios aleatorios.
- Validación de requisitosCruzaranse 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.
- Planificación da próxima fase ou ciclo 2
- Planificación do deseñoEstableceranse as tarefas da seguinte fase da planificación do proxecto, o deseño.
- Deseño
- Determinación 3
- Obxectivos 3Estableceranse os obxectivos da fase de deseño do proxecto.
- Alternativas 3Estableceranse posibles alternativas a eses obxectivos, aplicables no caso de que estes non se poidan cumprir.
- Restriccións 3Estableceranse restriccións aplicables a ditos obxectivos.
- Avaliación de alternativas e resolución de riscos 3
- Análise de riscos 3Determinaranse os riscos que comportan as distintas alternativas e as súas posibles solucións.
- Prototipo 3
- Prototipo hardware 3Realizarase un prototipo hardware mediante ferramentas software.
- Prototipo software 3Realizarase un terceiro prototipo, baseado no prototipo da fase anterior integrando tódolos cambios precisos para pasar a validación de requisitos.
- Desenvolvemento e validación do seguinte nivel do producto 3
- Simulacións, modelos e programas de proba 3Estableceranse unha serie de probas a realizar sobre o prototipo anterior, co fin de determinar se o deseño posterior é correcto.
- Deseño do producto hardware e software
- Deseño do producto hardwareBaseándose no prototipo hardware anterior, realizarase un deseño formal do producto hardware.
- Deseño do producto softwareBaseándose no prototipo software anterior, realizarase un deseño formal do producto software.
- Verificación e validación do deseñoVerificarase que o deseño se fixo correctamente (que se axusta ás especificacións) e que é correcto (fai o que se lle pide).
- Planificación da próxima fase ou ciclo 3
- Planificación do desenvolvementoEstableceranse as tarefas da seguinte fase da planificación do proxecto, o desenvolvemento.
- Desenvolvemento
- Determinación 4
- Obxectivos 4Estableceranse os obxectivos da fase de desenvolvemento do proxecto.
- Alternativas 4Estableceranse posibles alternativas a eses obxectivos, aplicables no caso de que estes non se poidan cumprir.
- Restriccións 4Estableceranse restriccións aplicables a ditos obxectivos.
- Avaliación de alternativas e resolución de riscos 4
- Análise de riscos 4Determinaranse os riscos que comportan as distintas alternativas e as súas posibles solucións.
- Prototipado operacional
- Prototipo hardware 4
- Integración do hardwareSeguindo o prototipo hardware realizado por software da fase anterior e o posterior deseño hardware, realizarase unha versión física do mesmo.
- Encapsulamento do hardwareUnha vez integrado o hardware será preciso encapsulalo de forma que sexa sinxelo interactuar con el.
- Prototipo software 4
- Desenvolvemento do prototipo
- Elaboración dun prototipo software completo (incluindo a parte do controlador hardware).
- Gravación dos samplesElaboración, partindo de cero, dunha fonte de sons de calidade para empregar co producto.
- Desenvolvemento e validación do seguinte nivel do producto 4
- Simulacións, modelos e programas de proba 4Estableceranse unha serie de probas a realizar sobre o prototipo anterior, co fin de determinar se o deseño posterior é correcto.
- Deseño detallado
- Deseño hardwareAmpliación do deseño hardware da fase anterior.
- Deseño softwareAmpliación do deseño software da fase anterior.
- Ensamblado e codificación
- EnsambladoIntegración do hardware e do encapsulamento.
- CodificaciónDesenvolvemento completo software.
- Probas de unidadeTesteo das distintas partes do producto facendo uso das probas definidas previamente.
- Integración e probasFusión de tódalas partes do producto nunha única e posterior testeo facendo uso das probas definidas previamente.
- Probas de aceptaciónVerificación e validación do producto por parte de expertos.
- Implantación
- 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.
