Documento de Arquitetura
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 25/08/2017 | 0.1 | Criação do documento | Leonardo Dos Santos |
| 26/08/2017 | 0.2 | Descrição de casos de uso : Manter Usuário | Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira |
| 26/08/2017 | 0.3 | Descrição de casos de uso : Listar Projetos | Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira |
| 26/08/2017 | 0.4 | Descrição de casos de uso : Ver Problemas | Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira |
| 27/08/2017 | 0.5 | Introdução : Finalidade | Adrianne Alves |
| 28/08/2017 | 0.6 | Introdução : Escopo | Adrianne Alves |
| 28/08/2017 | 0.7 | Visão de casos de uso: Atores | Mateus de Oliveira |
| 28/08/2017 | 0.8 | Descrição de casos de uso: Adicionando novos casos | Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira |
| 28/08/2017 | 0.9 | Descrição de casos de uso: Finalizando últimos casos | Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira |
| 28/08/2017 | 0.10 | Representação da Arquitetura | Adrianne Alves, Pedro Kelvin, Daniel Oda, Vinícius Cantuária |
| 28/08/2017 | 0.11 | Restrições e Metas Arquiteturais | Matheus Roberto, Pedro Kelvin, Vinícius Cantuária |
| 28/08/2017 | 0.12 | Restrições e Metas Arquiteturais: Adicionando mais conteúdo | Matheus Roberto, Pedro Kelvin, Vinícius Cantuária |
| 28/08/2017 | 0.13 | Desempenho | Adrianne Alves, Mateus de Oliveira |
| 28/08/2017 | 0.14 | Qualidade | Mateus de Oliveira |
| 28/08/2017 | 0.15 | Diagrama de Caso de Uso | Adrianne Alves,Matheus Roberto, Pedro Kelvin, Vinícius Cantuária |
| 31/08/2017 | 0.16 | Visão Lógica | Adrianne Alves,Matheus Roberto, Vinícius Cantuária |
| 31/08/2017 | 1.0 | Revisão Geral | Pedro Kelvin |
| 02/09/2017 | 1.1 | Modificando Casos de Uso | Pedro Kelvin |
| 12/09/2017 | 1.2 | Excluindo Caso de Uso: Ver Problemas | Pedro Kelvin |
| 15/09/2017 | 1.3 | Editando índices | Pedro Kelvin e Matheus Roberto |
| 19/09/2017 | 1.4 | Descrição caso de uso Login | Matheus Roberto |
| 19/09/2017 | 1.5 | Atualização do diagrama UC | Leonardo Dos Santos |
| 28/09/2017 | 2.0 | Revisão Geral | Adrianne Alves |
| 04/10/2017 | 2.1 | Correção da descrição do banco de dados e do tópico 5.2.1 | Matheus Roberto |
- Introdução
- Representação da Arquitetura
- Restrições e Metas Arquiteturais
- Visão de Casos de Uso
- Visão Lógica
- Desempenho
- Qualidade
Objetiva-se por meio deste documento exibir, de maneira detalhada, a arquitetura a ser empregada na plataforma Falko. Isso porque, procura-se alcançar uma compreensão recíproca a todos os membros da equipe de desenvolvedores do projeto, a fim de que haja o entendimento da estrutura da aplicação, em termos de tecnologias utilizadas. Além disso, espera-se que os desenvolvedores e demais interessados sejam capazes de visualizar as consequências advindas da arquitetura escolhida.
Falko é uma plataforma desenvolvida para facilitar o processo de acompanhamento e gerência de projetos de desenvolvimento de software, que utilizam a metodologia ágil. Em termos técnicos, este documento abordará a arquitetura que será utilizada para a produção da aplicação, para que seja possível potencializar a assertividade do processo de desenvolvimento. Dessa forma, será exposta aqui toda a lógica de construção da plataforma, abordando os casos de uso, diagramas de classe, de pacote, informações técnicas a respeito do banco de dados, desempenho e qualidade.
A arquitetura aqui exposta abrange dois diferentes ambientes a serem desenvolvidos para a plataforma Falko, isto é, o ambiente de controle de dados e negócios que é denominado API e o ambiente para interação com o usuário, caracterizado como frontend da aplicação.
Em relação à API será utilizado o framework Rails , que se baseia no modelo ou padrão arquitetural MVC, ele consiste em 3 camadas: Model, View e Controller (fig 1). A função principal da API será resguardar as informações mais relevantes e suas devidas regras de negócio, dessa forma, ao receber alguma requisição de dados por parte de aplicações exteriores, nesse caso a View, ela irá repassar os dados.
Em termos de frontend será utilizado o framework em javascript Vue, uma ferramenta eficiente para o desenvolvimento de Single-Page Applications. Nesse sentido, vue Js proporciona o desenvolvimento de componentes reativos, ou seja, pedaços de códigos reaproveitáveis formados por marcação, estilo e comportamento. Dessa forma, obtém-se maior facilidade para conectar elementos, como por exemplo, de html e javascript, na aplicação falko desempenhará o papel de unir a view à model, conforme apresentado na fig.2.
Fig 1
Fig 2
Para um melhor entendimento as camadas do MVC estão explicitadas a seguir:
A partir de informações abstraídas do mundo real, a model é responsável pela representação e validação dos dados.
Interface responsável pela interação com o usuário, renderizando páginas, gráficos, informações, entre outros. Não possui o processamento lógico de dados.
Será a responsável por receber as requisições e interpretá-las, controlando a comunicação e os dados que serão fornecidos pela model para a view.
A aplicação Falko terá como base de sua arquitetura a utilização do framework Rails, que é baseado na linguagem de programação Ruby. Tal framework proporciona uma melhor manipulação e organização do projeto em termos de arquitetura de software. O banco de dados utilizado será o PostgreeSQL, para o armazenamento de dados dos usuários e demais informações a serem utilizada pelo Falko, o que faz o acesso à internet obrigatório para o uso da aplicação.
A utilização do modelo MVC que o framework Rails utiliza proporciona muitos benefícios. Isso por que mantém a integração entre os arquivos do projeto e facilita a manutenção no código, como por exemplo a inclusão de novas funções, mantendo a padronização da estrutura do projeto.
Esse ator tem acesso à todas funcionalidades do sistema, sem restrições de dados.
Tem como objetivo fazer com que o cliente se identifique para o sistema, para que o sistema possa fornecer as informações corretamente a cada cliente.
Essa funcionalidade será responsável pela realização do cadastro do usuário, assim como a edição do seu perfil na plataforma, permitindo que ele visualize ou exclua os dados salvos no banco de dados. Dessa maneira, o mesmo poderá manter informações sobre os projetos com os quais está ou esteve envolvido e informações pessoais como nome, formação, telefone para contato e empresa a qual pertence.
O usuário irá, por meio desta, visualizar todos os projetos que estão em andamento ou já foram concluídos. Entretanto, as informações e métricas expostas serão compactas, a fim de que demonstre uma visão geral do estado das suas aplicações.
Permite ao usuário selecionar quais são as métricas mais importantes a serem acompanhadas em seus projetos, de maneira que elas sejam apresentadas na dashboard. Dessa forma, não será necessário que o gerente aponte para um documento específico para visualizá-las.
A partir desta função o gerente poderá realizar a pesquisa de projetos específicos, dentre os cadastrados, facilitando e agilizando o processo de acompanhamento de produtividade.
Responsável por adicionar um projeto à aplicação, informando as informações necessárias para o gerenciamento. Além disso, o usuário poderá ter uma visão prévia dos que estão disponíveis e acessá-los para obter mais detalhes. O gerente poderá ainda, em caso de cancelamento de um projeto, excluí-lo da plataforma.
Irá permitir ao usuário a obtenção de dados dos repositórios do GitHub que se deseja acompanhar.
Através desta função, o usuário poderá visualizar todos os membros de determinado projeto e informações sobre seu desempenho e produtividade como commits e issues resolvidas.
Permite ao usuário verificar todas as métricas de determinado projeto, tais como: Issues, Burndown, Velocity, EVP e GPA. Entretanto, as métricas fornecidas dependerão do seu vínculo com a aplicação, condicionadas à integração ou não com o GitHub.
Ao acessar a funcionalidade de exposição das releases o gerente de projetos terá acesso às informações relativas ao que deveria ser apresentado, à data da entrega e aos resultados obtidos em cada uma.
Tem como objetivo iniciar uma nova sprint, adicionando-a ao sistema, com informações sobre o tempo de execução, objetivos a serem alcançados e comentários. O gerente poderá editar informações relacionadas ao tempo de duração, comentários e objetivos da Sprint. Além disso, o usuário poderá cancelar a sprint, através de uma justificativa. Entretanto, essa não poderá ser excluída pelo gerente, pois é necessária para o acompanhamento do desempenho e produtividade da equipe. Por meio desta funcionalidade o gerente terá à disposição todas as sprints criadas, a fim de observar o comportamento da equipe frente a determinada forma de condução expressa pelos objetivos e comentários de cada uma delas.
O gerente terá acesso, por meio dessa função, às métricas referentes à sprint selecionada, como Burndown e Velocity, de acordo às características do seu projeto, no quesito de integração com o GitHub.
O usuário terá à sua disposição a possibilidade de revisar uma sprint, visualizando informações sobre o seu desempenho, a fim de detectar possíveis problemas e comportamentos que tenham sido produtivos para a equipe.
O gerente poderá acessar uma retrospectiva de sprints, por meio da qual irá acompanhar a evolução, observando os pontos bons, ruins e o que é possível aprimorar para os próximos ciclos.
A funcionalidade tem como objetivo apresentar para o usuário como foi feito o planejamento de determinada sprint e as características do mesmo.
Funcionalidade por meio da qual o gerente terá acesso às informações a respeito de todas as issues, estando elas abertas ou fechadas.
Possibilitará ao gerente demandar a um indivíduo a solução de determinada issue.
Utilizando-se desta funcionalidade o usuário poderá atribuir valores às issues de acordo a critérios próprios.
Utilizando Data Science, a função avisa o usuário caso a história do projeto esteja sem alterações por um determinado período de tempo.
O aplicativo utiliza Data Science para realizar alguns planejamentos com base no passado do projeto, aprendendo assim com o mesmo.
Essa funcionalidade dará ao gerente um feedback das issues requisitadas, mostrando aquelas que já foram finalizadas e as que estão em andamento.
O diagrama de pacotes do projeto utiliza a arquitetura MVC(Model-View-Controller), sendo assim, ele é dividido da seguinte forma:
A descrição das pastas expostas se dão da seguinte forma:
App : A pasta nomeada App engloba os principais diretórios do sistema, como por exemplo, os documentos referentes ao MVC - Model, View e Controller.
DB: Abrange os arquivos de configuração do banco de dados, o que inclui a representação das tabelas através das migrations.
Config: Todas as configurações do programa ficarão nesse pasta. Nela ficará a descrição de como o programa irá se comportar.
Test: Haverá três divisões de validação do projeto: da model, view e da controller. Esses testes de validação ficarão nesta pasta.
A importância desse pacote advém da sua relação direta com o usuário do sistema, isso porque inclui toda a parte visual do mesmo. Em termos de arquitetura, o sistema utilizará o vue que utiliza arquivos com extensão .js, responsáveis por definir a forma como os dados serão expostos.
A pasta denominada modelo trará o conceito de abstração à situação apresentada no mundo real, identificando as entidades a serem utilizadas na aplicação. Ao se tratar da Falko, uma situação em que isso ocorre está na identificação da classe gerente que deverá fornecer nome e Rg como dados de identificação obrigatórios, por exemplo. Além disso, a modelo deverá garantir a comunicação com o banco de dados.
A controladora será responsável por gerenciar os dados e os comportamentos da aplicação. Ela fará a ligação do modelo com a visão.
Neste pacote haverá as configurações e o estado do banco de dados. Nela estará o responsável por manter, em tabelas, e fazer as alterações dos dados quando necessário.
A aplicação de testes durante a implementação de uma aplicação é de extrema importância, por esse motivo, haverá no projeto uma pasta teste a fim de englobar os arquivos desenvolvidos para tal atividade. Isso garantirá, por exemplo, que o gerente não armazene dados incorretos de login, ou que o mesmo não deixe de cadastrar informações relevantes.
O sistema, quando integrado com o github, irá coletar um grande volume de dados a serem analisados, dessa forma, a aplicação deve ser capaz de suportá-los e processá-los simultaneamente, estando sujeito à adição de novos dados. O desempenho também dependerá da velocidade da internet do usuário, assim como da capacidade de processamento do aparelho que estará utilizando o sistema através do navegador.
O software descrito deve ser compatível com os principais sistemas operacionais, e sua interface de usuário deve ser projetada de maneira que seja autoexplicativa, sendo assim desnecessário treinamento para utilização do sistema.
- Folha de Estilo
- Esquema de Cores
- Como Usar o Docker
- O Padrão Adapter
- Links e Comandos Úteis
- O Padrão Observer
- Product Backlog
- Quadro Kanban
- Priorização das Histórias
- Sistema de Pontuação
- EVM Agile
- Roadmap
- Post Mortem - Release II
- Termo de Abertura do Projeto
- Plano de Gerenciamento do Projeto
- Plano de Gerenciamento do Escopo
- Plano de Gerenciamento de Requisitos
- Plano de Gerenciamento de Tempo
- Plano de Gerenciamento das Partes Interessadas
- Plano de Gerenciamento de Comunicação
- Plano de Gerenciamento das Aquisições
- Plano de Gerenciamento de Recursos Humanos
- Plano de Gerenciamento dos Riscos
- Plano de Gerenciamento de Configuração de Software
- Plano de Gerenciamento da Qualidade
- Plano de Gerenciamento dos Custos