Neste capítulo, será detalhado o planeamento das tarefas que serão executadas ao longo do estágio. É também possível encontrar o tempo gasto na elaboração de cada tarefa de modo a possibilitar a comparação entre as estimativas e o tempo real.
De forma a simplificar esse planeamento, será feita uma divisão da duração do estágio em duas partes, o primeiro e segundo semestre.
Posteriormente, será descrita a metodologia utilizado no projeto, passando pela descrição da metodologia, todos os papéis envolvidos na mesma, e por fim as adaptações feitas para a sua utilização.
4.1 Planeamento
De modo a desenvolver um produto funcional e bem estruturado, foi feito um planeamento detalhado para cada um dos dois semestres com o objetivo de cumprir todos os requisitos ”Must have” enumerados em 5.1.
4.1.1 Primeiro Semestre
A primeira fase do projeto consiste no levantamento do estado da arte e na decisão de quais as ferramentas e tecnologias a serem utilizadas no desenvolvimento do projeto. Para esta primeira fase, foi previsto o desenvolvimento do protótipo para ser apresentado na defesa intermédia no início do segundo semestre. Este protótipo tinha como objeti-vos possibilitar o carregamento de ficheiros para todos os tipos de dados suportados pela plataforma, editar e apagar os dados armazenados na base de dados. Posto isto, era ne-cessário fazer as devidas configurações na conta Amazon Web Services (AWS), criar todas as tabelas necessárias, S3 Bucket e criar a Ledger Database para armazenar o histórico automóvel.
Na figura 4.1 está representado o diagrama de Gantt com as previsões das tarefas para o primeiro semestre. Nele é possível visualizar todas as tarefas previstas para serem reali-zadas no primeiro semestre e a estimativa de tempo necessário para a realização de cada uma delas.
Capítulo 4
Figura 4.1: Diagrama de Gantt com estimativas para o 1o Semestre.
De modo a perceber a diferença entre as estimativas do tempo necessário para a realização de todas as tarefas descritas na figura 4.1 e o tempo que realmente demoraram a ser elaboradas, foi desenhado um novo diagrama com o tempo utilizado em cada uma das tarefas anteriormente descritas.
Figura 4.2: Diagrama de Gantt com o tempo real para o 1o Semestre.
Na figura 4.2 está representado um diagrama de Gantt com as tarefas realizadas no 1o
semestres e o respetivo tempo de execução. Ao comparar a figura 4.2 com a figura 4.1 é possível observar a ausência de três tarefas. A falta destas tarefas devem-se à não realização do histórico de automóveis dada a sua complexidade e ao curto espaço de tempo para a realização do protótipo. É também possível observar um ligeiro atraso na realização do relatório, fazendo com que o inicio do protótipo também tenha sido atrasado, diminuindo assim o tempo disponível para a sua realização.
Descrição do processo
4.1.2 Segundo Semestre
Para a segunda fase do estágio, foi inicialmente previsto o desenvolvimento de uma versão do sistema com, pelo menos, todos os requisitos ”Must have” apresentados na secção 5.1 implementados. O facto da prioridade dos requisitos ter mudado no início desta fase, levou à alteração do diagrama de Gantt desenhado no início do projeto.
De modo geral, esta fase foi dedicada ao desenvolvimento da plataforma web, desde o sistema de autenticação, visualização da previsão do preço e de dados estatísticos, e tam-bém ao desenvolvimento dos modelos de aprendizagem computacional responsáveis pelas previsões do preço de um determinado automóvel.
Devido ao não desenvolvimento do histórico automóvel na primeira fase do projeto, como referido anteriormente, as tarefas relativas a este requisito foram adicionadas aos objetivos a cumprir nesta fase.
Ao mesmo tempo que essa versão é desenvolvida, devem ser reportadas todas as informações relevantes e o processo de desenvolvimento neste mesmo documento.
Por fim, foi prevista a realização de todos os testes necessários de forma a validar o bom funcionamento do sistema e de modo a avaliar o desempenho dos modelos desenvolvidos.
Figura 4.3: Diagrama de Gantt com estimativas para 2o Semestre.
Na figura 4.3 está representado o diagrama de Gantt com as estimativas das tarefas para o segundo semestre. Nele é possível visualizar todas as tarefas reportadas anteriormente com mais detalhe juntamente com a estimativa do tempo necessário para a sua realização. Ao analisar a figura é possível observar que as tarefas relativas ao relatório e aos modelos de aprendizagem computacional são as que mais tempo despendem.
Semelhante ao que foi feito para a primeira fase do projeto, também nesta fase foi dese-nhando um novo diagrama com o tempo dispêndio na realização de cada tarefa.
Capítulo 4
Figura 4.4: Diagrama de Gantt com o tempo real para 2o Semestre.
Na figura 4.4 é possível visualizar o tempo despendido na realização de todas as tarefas prevista para a segunda fase do projeto. Diferente do que aconteceu na fase anterior, todas as tarefas definidas foram cumpridas, porém, é notável um atraso de quase dois meses na sua realização. Parte desse atraso deve-se aos resultados obtidos com o primeiro dataset utilizado para o treino dos modelos de aprendizagem computacional, que obrigou à realização da escolha de um novo dataset. Este processo resultou na execução de diversas tarefas repetidas vezes.
Ao comparar a figura 4.4 com a figura 4.3 é possível visualizar que a estimativa mais distante do valor real é relativa aos testes realizados aos modelos de aprendizagem computacional. De modo geral, o tempo estimado para a realização de uma dada tarefa não foi suficiente para a sua execução.
4.2 Metodologia
Este projeto será baseado na metodologia Scrum de modo a ter um desenvolvimento ágil, porém com diversas diferenças que serão descritas na secção 4.2.4.
Com o objetivo de entender melhor essa metodologia, nesta secção irá ser abordada a metodologia Scrum, de modo a entender o seu funcionamento e as vantagens e desvantagens do seu uso.
4.2.1 Scrum
O Scrum [44] é baseado no princípio da transparência para todas as partes interessadas, juntamente com inspeções e adaptações contínuas ao longo do desenvolvimento. Isso re-sulta numa metodologia que abrange mudanças e promove um ambiente no qual todos os membros da equipa do projeto compartilham a mesma importância em relação à maneira como a aplicação agrega valor aos utilizadores.
Inclui os mesmos tipos de atividades que a metodologia em cascata (Definição de requi-sitos, Design, Desenvolvimento, Garantia da Qualidade e Manutenção), mas, em vez de implementá-las como fases sequenciais, elas são encapsuladas em várias sprints.
Descrição do processo Sprints são ciclos de desenvolvimento que duram de uma a quatro semanas. O comprimento do sprint é fixo ao longo da vida do projeto e é escolhido pela equipa. É atribuído um número fixo de tarefas por membro da equipa a cada sprint, porém, isso não quer dizer que não possam ser adicionadas ao sprint novas tarefas, a menos que isso exceda a capacidade
da equipa de criar e testar as tarefas até ao final do sprint. Geralmente, as equipas
subestimam o número de tarefas que podem ser concluídas e precisam adicionar tarefas para preencher o restante do sprint.
4.2.2 Papéis do Scrum
No Scrum existem três principais papéis, entre eles o dono do produto, o Scrum Master, e a equipa [45].
O Dono do Produto é responsável por identificar os requisitos do produto, convertendo-os em uma lista priorizada, decidindo qual deve estar no topo da lista para o próximo Sprint e atualizar a lista continuamente.
O Scrum Master atua como uma ponte entre o Dono do Produto e a equipa. O Scrum Master não gere a equipa, trabalha para remover quaisquer impedimentos que estejam a obstruir a equipa de alcançar os seus objetivos do sprint. Isso ajuda a equipa a permanecer criativa e produtiva, garantindo que seus sucessos sejam visíveis ao Dono do produto. A Equipa é responsável pela sua auto-organização de forma a concluir os seus objetivos. Uma equipa de desenvolvimento de Scrum contém cerca de sete membros, idealmente numa sala da equipa, protegida contra distrações externas. Para projetos de software, uma equipa típica inclui uma mistura de engenheiros de software, arquitetos, programadores, analistas, especialistas em controlo de qualidade, testers e designers. A cada sprint, a equipa é responsável por determinar como realizará as tarefas, tendo a autonomia e responsabilidade para cumprir os objetivos do sprint.
4.2.3 Artefatos do Scrum
Na metodologia Scrum existem três tipos de artefactos, Product backlog, Sprint backlog e o incremento [45].
Product backlog é o documento mais importante que descreve todos os requisitos de um sistema, projeto ou produto. Pode ser vista como uma lista de tarefas a fazer e é responsabilidade do dono do produto.
Sprint backlog consiste numa lista específica de tarefas selecionada a partir do product backlog baseada na prioridade do dono do produto que devem ser concluídas num sprint. Incremento é a soma de todos os itens do product backlog que foram concluídos desde a última versão do software. Embora seja responsabilidade do dono do produto decidir quando um incremento é disponibilizado, é responsabilidade da equipa garantir que tudo o que está incluído num incremento está pronto para ser disponibilizado.
4.2.4 Alterações ao Scrum
Como já referido anteriormente, a metodologia utilizada neste projeto é baseado em scrum, porém, difere em alguns pontos.
Capítulo 4
A diferença mais notável é em relação à equipa, em que neste projeto é constituída por um único elemento, e não cerca de sete elementos, como referido anteriormente. O motivo de ser uma equipa tão pequena deve-se ao facto de ser um projeto individual.
Posto isso, a equipa é formada unicamente pelo autor deste documento e o dono do produto é o orientador da empresa.
Por fim, foi definido para as Sprints uma duração de duas semanas, com reuniões diárias.