| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 27/08/2018 | 1.0 | Criação do documento com template inicial | Guilherme Augusto |
| 28/08/2018 | 1.1 | Construção inicial dos tópicos 1, 2 | Guilherme Augusto |
| 01/09/2018 | 1.2 | Construção inicial do tópico 3, 4 e 5 | Guilherme Augusto |
| 03/09/2018 | 1.3 | Modificação de tópicos pela mudança do escopo | Guilherme Augusto e Ícaro Oliveira |
| 03/09/2018 | 1.4 | Melhoras nos tópicos com atualização do novo escopo | Ícaro Oliveira |
| 04/09/2018 | 1.5 | Melhoras no tópico 4 | Guilherme Augusto |
| 04/09/2018 | 1.6 | Construção inicial do tópico 8.2 | Guilherme Augusto |
| 07/09/2018 | 1.7 | Construção do tópico 8.1 | Guilherme Augusto |
| 07/09/2018 | 1.8 | Construção do tópico 6 | Ícaro Oliveira |
| 08/09/2018 | 1.9 | Construção do tópico 7 | Ícaro Oliveira |
| 08/09/2018 | 2.0 | Finalização do documento com os tópicos 9 e 10 | Guilherme Augusto |
| 24/11/2018 | 2.1 | Refatoração da escrita de alguns tópicos | Letícia de Souza |
O documento tem como objetivo informar os propósitos, objetivos e requisitos de alto nível, além de especificações de planejamento do projeto do Bot Lino, companheiro e ajudante da comunidade FGA.
O Lino é um bot disponibilizado nos mensageiros Telegram e Messenger, que visa orientar, alertar e tirar dúvidas a respeito de alguns assuntos relaciondaos à Universidade de Brasília - Campus FGA.
A comunidade FGA possui uma certa dificuldade em acessar, de forma rápida e prática, algumas informações. O Lino surge para suprir a carência de um mecanismo fácil e informal de acessar algumas informações, surgindo com o propósito de disponibilizar algumas funcionalidades, como por exemplo: disponibilizar o cardápio do RU, explicar sobre o passo a passo para obter documentos acadêmicos e, também, enviar o calendário de matrícula. Além disso, o Lino também é capaz de possibilitar com que o usuário opte por receber notificações sobre algumas dessas informações.
O objetivo do Lino é poder facilitar informações pontuais para o usuário. Informações essas que, sem o Lino, são disponibilizadas de forma mais burocrática e sem muita interação com o usuário. Com o acesso mais facilitado às informações que o Lino dispõe, a comunidade economiza tempo e esforço ao interagir com o bot, ao invés de ter que baixar alguma aplicativo para obrter informações sobre o cardápio, ou acessar um site para poder baixar um PDF e conferir informações sobre matrículas e trancamentos.
Estão entre os requisitos e alto nível:
- Interação através de linguagem natural para uma melhor usabilidade;
- Fluxos de conversas objetivos e práticos;
- Construir personalidade do Bot
- A captura de informações contidas em websites para incrementar a capacidade do Bot
Na estimativa de riscos deste projeto, opta-se por estipular um padrão para a avaliação de probabilidade e impacto, servindo, também, para a priorização de riscos. Sendo assim, seguem-se as tabelas:
| Probabilidade (P) | Peso |
|---|---|
| Raro (< 10%) | 1 |
| Improvável (10% - 25%) | 2 |
| Moderado (25% - 50%) | 3 |
| Provável (50% - 75%) | 4 |
| Quase Certo (> 75%) | 5 |
| Impacto (I) | Descrição | Peso |
|---|---|---|
| Insignificante | Quase que imperceptível ao projeto | 1 |
| Baixo | Pouca influência no desenvolvimento do projeto | 2 |
| Moderado | Notável ao projeto, mas sem grandes consequências | 3 |
| Alto | Dificulta o desenvolvimento do projeto | 4 |
| Catastrófico | Impossibilita o prosseguimento do projeto 5 | 5 |
A fórmula para o cálculo do Score (S) de cada risco é calculada: S = P x I e o Score de cada Sprint é dado pela soma dos Scores dos riscos identificados nesta.
Ao início de cada Sprint, cada risco é calculado com base nas tabelas apresentadas. Ou seja, a cada nova iteração, um risco conhecido e bem mitigado nas sprints anteriores tende sempre a diminuir. Levando isso em conta, riscos identificados ao decorrer do projeto tendem a ter impacto elevado e necessitam de medidas preventivas rápidas e precisas.
A seguir, a tabela para os riscos identificados:
| Risco | Resposta ao risco |
|---|---|
| Integração do time | Realizar feedbacks constantes para facilitar a comunicação e o acompanhamento constante dos membros; Realização de dailys presenciais e remotas |
| Configuração de ambiente | Auxiliar a equipe de desenvolvimento na configuração de suas máquinas; Utilização do Docker |
| Integração entre os serviços | Treinamento sobre as tecnologias utilizadas; Auxílio técnico da equipe de EPS |
| Greve na Universidade | Continuar o desenvolvimento; Replanejar o cronograma |
| Indisponibilidade temporária de integrantes (doença, viagem) | Manter cronograma atualizado com as viagens anunciadas com antecedência; Replanejar pareamento e/ou atividades do(s) membro(s) indisponíveis |
| Grade Horária | Manter comunicação entre os membros para manter-se atualizado da agenda destes; Planejar pareamento entre pessoas que tiverem grade horária parecida |
| Falta de planejamento por parte de EPS | Manter feedback e transparência constante entre os membros; Dividir atividades para não sobrecarregar ninguém; Pedir auxílio para a professora e/ou monitores |
| Descomprometimento da equipe | Auxiliar equipe a manter-se comprometida; Aumentar o senso de integração entre os membros; Tratar individualmente com o membro; Comunicar a professora em casos extremos |
| Mudança de escopo | Feedback constante com o cliente, por meio de reuniões; Buscar novas alternativas para elicitação de requisitos |
| Mudança de arquitetura | Preparar uma arquitetura adaptável, que permita mudanças sem grandes prejuízos |
| Indefinição do escopo | Feedback com o cliente; Utilização de ferramentas para visualizá-lo melhor, como mapas mentais, Canvas etc |
| Desistência da disciplina | Comunicação entre os integrantes para integrar o time; Transparência com os membros da equipe; Replanejamento de escopo para adequação à capacidade de produtividade restante |
| Atrasos nas reuniões | Comunicação constante entre os membros; Marcar reuniões antecipadamente para evitar chocar horário com compromissos de outros membros; Conversa individual; Comunicar à professora |
| Atrasos nas entregas (dívida técnica) | Auxílio técnico de EPS; Organizar pareamento para transferência de conhecimento; Evitar que as entregas atrasem pois os membros não tinham conhecimento suficiente para realizá-las |
| Entrega contínua | Definir pipeline; Treinamento dos membros com as ferramentas de CD |
| Integração contínua | Definir pipeline; Treinamento dos membros com as ferramentas de CI |
| Performance do produto | Monitorar a atividade do bot através do ElasticSearch e Kibana; Refatoração constante; Utilização de padrões de desenvolvimento para evitar o aumento de complexidade e lentidão no sistema |
| Qualidade da interação do bot | Monitorar a atividade do bot através do ElasticSearch e Kibana; Atentar para feedback dos usuários; Remodelar os fluxos de conversa que estejam causando gatilhos de confusão |
| Adicionar dificuldade técnica no decorrer do projeto | Treinamento da equipe; Comunicação constante; Escolher ferramentas que possuem boa documentação e rápida curva de aprendizado |
| MDS depender muito de EPS para realizar atividades propostas | Permitir a rápida comunicação entre os membros; Disponibilização de material e treinamento suficiente para MDS conseguir trabalhar sem o auxílio constante de EPS |
| EPS não disponibilizar condições necessárias para MDS trabalhar | Dividir o trabalho entre os membros de EPS para; Comunicação constante entre os membros; Identificação e correção de gargalos na disponibilização de ambiente, conhecimento e treinamento dos membros de MDS |
| Falta de métodos tradicionais para garantir qualidade (testes) | Coleta de dados e utilização de painéis para acompanhamento em uso para fornecer insights sobre a qualidade do bot (Kibana e ElasticSearch) |
O cálculo de custos leva em conta três fatores: aquisição, pessoal e ferramentas. Desta forma é levado em conta os custos reais de mercado: desde o custo com energia e aluguel de sala, até as ferramentas utilizadas pelos membros.
O cálculo de custos leva em conta três fatores: aquisição, pessoal e ferramentas. Assim, é levado em conta os custos reais de mercado: desde o custo com energia e aluguel de sala, até as ferramentas utilizadas pelos membros.
Nesse fator, são considerados os seguintes tópicos: custos de equipamentos e aluguel de uma sala em um coworking na cidade de Brasília - DF.
| Equipamento | Quantidade | Finalidade | Valor unitário | Preço |
|---|---|---|---|---|
| Notebooks | 10 unidades | Desenvolvimento e planejamento | R$ 3.000 | R$ 30.000 |
| Aluguel de espaço físico em um coworking* | 5 dias úteis | Alocação de pessoal | R$150** | R$ 24.000*** |
| Transporte e alimentação | 4 passagens diárias + R$10 alimentação | Transporte e alimentaçao | R$ 20/dia | R$ 16.000*** |
*resultado com base no preço médio de um Coworking em Brasília, em set/2018. Internet, água e luz inclusas. **por semana, individual. ***valor resultante para 10 membros, durante 16 sprints com duração de uma semana.
Nesse caso, foram levados em conta o valor médio por hora de um desenvolvedor Python Júnior, para a equipe de MDS e do valor médio entre desenvolvedores Plenos, Scrum Master e Analista de BI Júnior para a equipe de EPS.
| Cargo | Quantidade | Salário/mês (160h total) | Salário/hora | Total |
|---|---|---|---|---|
| Deselvolvedor Python Jr | 5 | R$ 3.000 | R$18,75 | R$ 15.000* |
| Analista BI, Arquiteto, DevOps, Scrum Master e PO** | 5 | R$ 6.000 | R$ 37,50 | R$ 60.000* |
*preço resultante para 5 membros, trabalhando 10h por semana, durante 16 sprints com duração de uma semana. **uma vez que a equipe de EPS não possui apenas um único papel, foi calculado um preço médio de cada profissional da área
| Ferramenta | Finalidade | Preço total |
|---|---|---|
| Google Drive | Compartilhamento de arquivos | R$ 0 |
| Editor de Texto | Elaboração de documentos e código | R$ 0 |
| GitHub | Versionamento de arquivos | R$ 0 |
| Telegram | Comunicação entre os membros | R$ 0 |
| Python, Rasa, API Telegram, ElasticSearch, Kibana, MongoDB | Tecnologias utilizadas para desenvolvimento | R$ 0 |
| Custo | Valor total |
|---|---|
| Aquisição | R$ 43.000 |
| Pessoal | R$ 75.000 |
| Ferramentas | R$ 0 |
O valor total estimado dos custos informados é de R$118.000. Levando em conta 10% de risco, o valor final para a estimativa de custo é de R$129.800.
- Discentes
- Doscentes
- Servidores
| Nome | Papel | Github |
|---|---|---|
| Bruna Pinos de Oliveira | Gerente de Projeto | @brunapinos |
| Guilherme Augusto Nunes Silva | Gerente de Projeto | @guiaugusto |
| Guilherme Guimarães Lacerda | Gerente de Projeto | @guilacerda |
| Ícaro Pereira de Oliveira | Gerente de Projeto | @icarooliv |
| Letícia de Souza Santos | Gerente de Projeto | @leticiadesouza |
| Gabriel Braga Mendes | Desenvolvedor | @braga9 |
| Gabriel Filipe Manso Araújo | Desenvolvedor | @gabrielfilipe7unb |
| Guilherme Marques Rosa | Desenvolvedor | @guilhesme23 |
| Matheus Salles Blanco | Desenvolvedor | @MatheusBlanco |
| Pedro Rodrigues Pereira | Desenvolvedor | @pedro-prp |
Para o projeto ser aprovado, ele deve atingir as seguintes metas:
- Ter a possibilidade de ser acessado pelos mensageiros Telegram e Facebook Messenger.
- Ter implementado as funcionalidades definidas pelo escopo do projeto.
- Atender as especificações dos requisitos levantados.
ROBERTO, Elmar; DIB, Cecília; CLÍMACO, Gabriel; CAROLINA, Maria; XAVIER, Júlio. Trezentos - Termo de Abertura de Projeto. Disponível em: https://fga-eps-mds.github.io/2018.1-Dulce_Docs/abertura/tap.html.
FRANÇA, Diego; SCONETTO, João; MENDES, Mariana; ARNAUD, Victor. Dr. Down - Termo de Abertura de Projeto. Disponível em: https://fga-eps-mds.github.io/2018.1-Dr-Down/eps/TAP/
EGEWARTH, Eliseu; EGEWARTH, João; GAMA, Gabriela; ALVES, Isaque. Dulce - Termo de Abertura de Projeto. Disponível em: https://github.com/fga-eps-mds/2017.1-Trezentos/wiki/Termo-de-Abertura-do-Projeto
LOVEMONDAYS. Salários para programadores e equipe de analista, arquiteto, scrum master, DevOps e PO. Disponível em: https://www.lovemondays.com.br/.
COWORKING BRASIL. Espaços para Coworking no Distrito Federal. Disponível em: https://coworkingbrasil.org/df/.