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 |
- 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 os dois ambientes que serão 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, ou seja, frontend da aplicação. O framework Rails, que será usado na implementação da API, se baseia no modelo arquitetural MVC, que consiste em 3 camadas: Model, View e Controller. Essa API será responsável por resguardar as informações mais relevantes e suas devidas regras de negócio, e ao receber alguma requisição de dados por parte de aplicações exteriores(View), ela repassa esses dados. Já para o frontend será utilizado o framework em javascript Vue, que se mostra uma ferramenta muito eficiente para o desenvolvimento de Single-Page Applications.
Para um melhor entendimento as camadas 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, etc. 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 MySQL, para o armazenamento de dados dos usuários e demais informações para o Falko, o que faz o acesso a internet obrigatório para o uso da aplicação.
A utilização do modelo MVC que o framework Rails proporciona muitos benefícios. Além de manter integração entre os arquivos do projeto, facilitar 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 a todas funcionalidades do sistema, sem restrições de dados.
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.
Tem como objetivo fornecer ao usuário dados relativos aos problemas que estão ocorrendo em cada projeto específico, destacando as métricas mais agravantes, a fim de tornar o processo de acompanhamento mais eficiente. Assim, por meio de apelos visuais chamativos para as métricas em mau estado o gerente poderá decidir mais facilmente qual projeto analisar no momento.
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 no 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 rails que utiliza arquivos com extensão .html.derb, 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, não sendo assim necessário nenhum 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