Histórico de Revisões
Histórico de Revisões
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 20/03/2018 | 0.1.0 | Introdução | Lorrany Azevedo |
| 20/03/2018 | 0.1.1 | Objetivo | Lorrany Azevedo |
| 20/03/2018 | 0.1.2 | Escopo | Lorrany Azevedo |
| 20/03/2018 | 0.1.3 | Referências | Lorrany Azevedo |
| 20/03/2018 | 0.1.4 | Visão Geral | Lorrany Azevedo |
| 20/03/2018 | 0.2.0 | Posicionamento | Mateus Augusto |
| 20/03/2018 | 0.2.0 | Posicionamento | Mateus Augusto |
| 20/03/2018 | 0.2.1 | Oportunidade de Negócio | Mateus Augusto |
| 20/03/2018 | 0.2.2 | Descrição do problema | Mateus Augusto |
| 21/03/2018 | 0.2.3 | Descrição da posição do produto | Mateus Augusto |
| 21/03/2018 | 0.3.0 | Descrição dos Envolvidos | Mateus Augusto |
| 21/03/2018 | 0.3.1 | Resumo das partes associadas | Mateus Augusto |
| 21/03/2018 | 0.3.2 | Resumo dos usuários | Mateus Augusto |
| 21/03/2018 | 0.3.3 | Ambiente de usuários | Mateus Augusto |
| 22/03/2018 | 0.3.4 | Perfis das partes associadas | Mateus Augusto |
| 23/03/2018 | 0.3.5 | Perfis dos usuários | Mateus Augusto |
| 22/03/2018 | 0.3.6 | Necessidades principais dos usuários | Mateus Augusto |
| 22/03/2018 | 0.3.7 | Alternativas e Concorrência | Mateus Augusto |
| 22/03/2018 | 0.4.0 | Visão Geral do produto | Gustavo Duarte Moreira |
| 22/03/2018 | 0.4.1 | Perspectiva do produto | Gustavo Duarte Moreira |
| 22/03/2018 | 0.5.0 | Recursos do produto | Gustavo Duarte Moreira |
| 22/03/2018 | 0.7.0 | Outros requisitos do produto | Lorrany Azevedo |
| 22/03/2018 | 0.7.1 | Requisitos de usuabilidade | Lorrany Azevedo |
| 22/03/2018 | 0.7.2 | Requisitos do sistema | Lorrany Azevedo |
| 22/03/2018 | 0.7.3 | Requisitos de desempenho | Lorrany Azevedo |
| 22/03/2018 | 0.8.0 | Referências Bibliográficas | Lorrany Azevedo |
| 23/03/2018 | 0.9.0 | Restrições | Matheus Gomes |
| 26/03/2018 | 0.10.0 | Outras restrições de produto | Matheus Gomes |
| 26/03/2018 | 1.0.0 | Finalização do documento | Matheus Gomes |
Sumário
-
1.1. Objetivo
1.2. Escopo
1.3. Referências
1.4. Visão Geral -
2.1. Oportunidade de Negócio
2.2. Descrição do problema
2.3. Descrição da posição do produto -
3.1. Resumo das partes associadas
3.2. Resumo dos usuários
3.3. Ambiente de usuário
3.4. Perfis das partes associadas
3.5. Perfis dos usuários
3.6. Necessidades principais dos usuários
3.7. Alternativas e Concorrência -
4.1. Perspectiva do produto
4.2. Resumo de recursos -
6.1. Restrições de Implementação
6.2. Restrições de Tempo
6.3. Restrições de Escopo -
7.1. Requisitos de usuabilidade
7.2. Requisitos do sistema
7.3. Requisitos de desempenho
7.4. Requisitos de confiabilidade
1. Introdução
1.1. Objetivo
O propósito deste documento é aprensetar a plataforma Cardinals e determinar suas ultilidades e funcionalidades, com isso serão relatadas de forma detalhada e objetiva, todas as inovações e vantagens oferecidas pela aplicação, através de tópicos que irão relatar a descrição do problema, oportunidade de negócios, descrição dos envolvidos, restrições do projeto, entre outros. Tudo isso será feito de forma à facilitar o entendimentoda plataforma para os usuários e investidores que irão utilizá-la.
1.2. Escopo
A plataforma Cardinals foi pensada com o objetivo de ajudar membros de equipes que utilizam a metodologia ágil, em particular os gestores, que querem acompanhar o trabalho das pessoas em um nível indidual, em um nível de repósitorio e a nível de boas práticas de engenharia de software em projetos quesão gerenciados pela plataforma GitHub. Isso se dá com o intuito de melhorar a produtividade das equipes e a qualidade dos projetos, sendo assim os gestores e as equipes poderão fazer uma análise baseada em dados do GitHub e outras ferramentas associadas, para otimizar os processos e gerenciamento dos mesmos.
1.3. Referências
IBM Knowledge Center - Documento de Visão: A estrutura de tópicos do documento de visão. Disponível em: https://www.ibm.com/support/knowledgecenter/pt-br/SSWMEQ_3.0.1/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.htm. Acesso em: .20 mar. 2018;
Wikipédia - Documento de Visão.
Disponível em:
https://pt.wikipedia.org/wiki/Documento_de_vis%C3%A3o. Acesso em: .20 mar. 2018;
1.4. Visão Geral
Este documento irá facilitar que o leitor tenha um bom entendimento e uma boa absorção das informações que serão mostradas, de forma bem estruturada e de fácil visualização. Sendo assim o documento irá aprensentar as finalidades e a motivação, que inspiraram a proposta oferecida para a implementação da plataforma. Em segundo plano, serão apresentadas as funções do produto, as problemáticas, os envolvidos no projeto, sendo eles a equipe responsável pela gestão e a responsável pelo desenvolvimento do software.
2. Posicionamento
2.1. Oportunidade de Negócio
A Metodologia Ágil aplicada na Engenharia de Software tem como objetivo tornar os processos de desenvolvimento mais rápidos e eficientes, estabelecer métricas, automatizar de tarefas e fazer uma boa da gestão da equipe.
A plataforma Cardinals tem o objetivo de dar um auxílio às equipes de desenvolvimento de software em relação a gestão de projetos e gestão da equipe. E também tem o objetivo de ser um ambiente para monitoramento e acompanhamento de todo o processo produtivo de software de um indivíduo e/ou equipe.
2.2. Descrição do problema
| ---------- | ------------- |
|---|---|
| O problema é | gerenciar e monitorar as equipes os projetos de software |
| Cujo impacto é | queda da eficiência das equipes |
| Uma boa solução seria | uma plataforma web de código aberto e gratuito capaz de fornecer métricas e indicadores, gerenciar e monitorar as equipes e projetos. |
2.3. Descrição da posição do produto
| --------- | ------------- |
|---|---|
| Para | os gestores de projetos que utilizam a metodologia ágil |
| Que | desejam tornar a gerência de projetos mais eficaz |
| Cardinals | é uma aplicação web de código aberto e gratuita |
| Que | torna mais eficiente a o acompanhamento de projetos e organização das equipes |
| Diferente | de outras aplicações web como GitHub e GitLab |
| Nosso produto | oferecerá mais recursos para incadores e métricas de forma mais automatizada. |
3. Descrição dos Envolvidos
3.1. Resumo das partes associadas
| Nome | Descrição | Responsabilidades |
|---|---|---|
| Equipe de Desenvolvimento | Estudantes da disciplina de Métodos de Desenvolvimento de Software da Universidade de Brasília | Participar ativamente no processo de desenvolvimento do software estabelecido como proposta de solução. |
| Equipe de gestão de projeto | Estudantes da disciplina de Engenharia de Produto de Software | Gerenciar a equipe de desenvolvimento. |
| Equipe de avaliação e suporte | Professor e Coaches das disciplinas MDS e EPS | Avaliar e auxiliar as equipes de gestão e desenvolvimento |
| Clientes | Coaches | Prover as informações para o levantamento de requisitos. |
3.2. Resumo dos usuários
| Nome | Descrição |
|---|---|
| Gestor de projeto | Indivíduo que deseja monitorar e acompanhar o desenvolvimento de equipes e projetos. |
| Equipe de desenvolvimento | Pessoal que deseja um ambiente para organizar e gerir a equipe e o desenvolvimento do projeto |
3.3. Ambiente de usuário
O software poderá ser utilizado por meio de navegadores como:
- Google Chrome;
- Mozilla Firefox;
3.4 Perfis das partes associadas
3.4.1 Equipe de Desenvolvimento
| ---------- | ------------- |
|---|---|
| Representantes | Lorrany Azevedo, Gustavo Duarte, Mateus Augusto, Matheus Gomes, João Pedro |
| Descrição | Desenvolvedores |
| Tipo | Grupo de Estudadntes da Faculdade do Gama (FGA), matriculados na disciplina de Métodos de Desenvolvimento de Software |
| Responsabilidades | Elaborar documentação base sobre o contexto do projeto.Desenvolver o projeto. |
| Critérios de Sucesso | Aplicar metodologias ágeis ao longo do processo e obter um produto que satisfaça a necessidade do cliente. |
| Envolvimento | Alto |
3.4.2 Equipe de Gestão de Projetos
| ---------- | ------------- |
|---|---|
| Representantes | Amanda Bezerra, Lucas Costa, Miguel Nery, Marlon Mendes, Guilherme da Luz |
| Descrição | Gerentes de Projeto |
| Tipo | Grupo de Estudadntes da Faculdade do Gama (FGA), matriculados na disciplina de ENgenharia de Produto de Software |
| Responsabilidades | Gerenciar, supervisionar e manter a equipe de desenvolvimento a fim de que as metodologias ágeis sejam aplicadas e o produto seja entregue ao cliente no final. |
| Critérios de Sucesso | Aplicar metodologias ágeis ao longo do processo e obter um produto que satisfaça a necessidade do cliente. |
| Envolvimento | Alto |
3.4.3 Coaches
| ---------- | ------------- |
|---|---|
| Representantes | João Guilherme, Sabryna |
| Descrição | Clientes |
| Tipo | Estudadntes da Faculdade do Gama (FGA) |
| Responsabilidades | Fazer o papel do cliente que demanda o produto. |
| Critérios de Sucesso | Transmitir informações e requisitos necessários para a equipe de desenvolvimento e a equipe de gestão. |
| Envolvimento | Alto |
3.5. Perfis dos usuário
3.5.1 Gestores de Projetos
| ---------- | ------------- |
|---|---|
| Representantes | Pessoas que realizam gestão de projetos ágeis |
| Descrição | Gestores que desejam uma forma mais eficiente e automatizada de gerir projetos e equipes de desenvolvimento |
| Responsabilidades | Dar feedback sobre a solução final em relação às funcionalidades de gestão na aplicação |
| Envolvimento | Médio |
3.5.2 Equipe de desenvolvimento
| ---------- | ------------- |
|---|---|
| Representantes | Pessoas que desenvolvem projetos ágeis |
| Descrição | Desenvolvedores que desejam um ambiante que os auxilie no processo de desenvolvimento de software |
| Responsabilidades | Dar feedback sobre a solução final em relação às funcionalidades que auxiliam no processo de desenvolvimento |
| Envolvimento | Médio |
3.6. Necessidades principais dos usuários
| Necessidade | Prioridade | Preocupações | Soluções Propostas |
|---|---|---|---|
| Mapear tempo de issues | Alta | Mapear tempo em que as issues ficam abertas | Criar uma funcionalidade que mapeie o tempo em que uma issue fica aberta e apresentar essa informação ao usuário |
| Mapear Pareamento | Alta | Mapear comtribuições que foram feitas ao longo do projeto de forma pareada | Criar uma funcionalidade que mapeie os pareamentos e mostre essa informação para o usuário |
| Gerenciar alterações e manipulações nas branchs | Alta | Verificar se durante o projeto a equipe seguiu a política de branchs | Criar uma funcionalidade que gerencia as alterações nas branchs verificando se há um segmento da política de branch defeinida |
| Gerenciar pull requests | Alta | Gerenciar se há um segmento da política de pull request | Criar uma funcionalidade que gerencie se a equipe está seguindo a política de pull request definida |
| Indicadores de práticas ágeis | Alta | Mapear se há indicadores que identificam o segmento do projeto segundo as práticas ágeis | Criar uma funcionalidade que mapeie o projeto e defina indicadores que sirva para verificar se o projeto está se desenvolvendo de acordo com as práticas ágeis |
| Mapear se exixtem ferramentas de automatização no projeto | Alta | Mapear se existem ferramentas que automatizem tarefas no projeto em relação a teste, integração contínua, qualidade de código, ambiente de desenvolvimento etc | Criar uma funcionalidade que mapeie se existem essas ferramentas de automatização |
3.7. Alternativas e Concorrência
3.7.1. Jira
O Jira é um software utilizado para avaliação e planejamento de projetos que utilizam metodologia ágil. Essa aplicação proporciona planejamento de sprints, distribuição de tarefas, discussão do trabalho, visualização em tempo real do desempenho, entre outros. Além disso, é um software vastamente utilizado por grandes empresas no cenário mundial. Entretanto, para se adquirir esta aplicação, é pago um valor mensal, proporcional ao tamanho da equipe a utilizá-lo.
3.7.2 Active Collab
É um software baseado no Jira, com o design e funcionalidades quase idênticas a ele. É uma versão mais simplificada, trazendo como principal crítica ao Jira a parte burocrática para utilização prática em projetos(muitas funcionalidades, o que deixa o usuário do produto “perdido”). Também é uma ferramenta paga.
3.7.3 ZenHub
É uma ferramenta que visa melhorar o planejamento e desempenho de equipes que utilizam metodologias ágeis. Uma de suas vantagens é que é um software gratuito e se integra diretamente ao GitHub, de maneira simples. Entretanto, o software não possui uma disposição limpa de resultados para que o gerente do projeto possa avaliar o andamento.
4. Visão geral do produto
4.1. Perspectiva do produto
A plataforma irá fornecer informações em tempo real para gestores e clientes, auxiliando na analíse de desempenho da equipe e do andamento do desenvolvimento dos projetos. Ela irá oferecer um painel de indicadores que centralizará as informações necessárias para o acompanhamento de projetos desenvolvidos com metodologia ágil.
4.2. Resumo de recursos
5. Recursos do produto
- Vizualização do andamento dos projetos;
- Consolidação de dados do github;
- Notificação de usuários;
- Painel de Controle customizável;
- Fornecer relatórios de desempenho;
- Gerenciamento de política de branchs e pull requests;
- Relatórios de issues e pareamento;
- Fornecer indicadores de práticas ágeis.
6. Restrições
6.1 Restrições de Implementação
O sistema deverá possuir uma API para consumir os dados referente à projetos do GitHub. O sistema deve seguir a utilização de microserviços.
6.2 Restrições de Tempo
*O sistema deve estar com uma versão estavel ate a Release 1(19/04), e deve estar pronto até a Release 2
6.3 Restrição do Escopo
*O sistema deve atender à principio apenas à projetos escritos em Django, Python.
7. Outros requisitos do produto
7.1. Requisitos de usuabilidade
- O sistema poderá ser utilizado por qualquer pessoa que tenha intimidade com navegadores web, já que ele podera ser executado pro qualquer web browser, sua interface deve ser de fácil entendimento e auto explicativa, facilitando assim o seu uso por quem quiser utiliza-lá.
7.2. Requisitos do sistema
*O sistema poderá ser acessado por qualquer computador que possua um browser e acesso à internet, compatível com os sistemas operacionais Linux, Windows ou Mac.
7.3. Requisitos de desempenho
*O sistema deve responder rapidamente a requisição do usuário, e deve estar sempre disponível.
7.4. Requisitos de confiabilidade
*O sistema deve se comprometer em não alterar os dados oferecidos pelo GitHub.
8. Referências Bibliográficas
- FUNPAR.UFPR.com. Artefato: Documento de Visão. Disponível em: http://www.funpar.ufpr.br:8080/rup/webtmpl/templates/req/rup_vision_sp.htm. Acesso em 22 de Março de 2018. +FUNPAR.UFPR.com. Artefato: Documento de Visão. Disponível em: http://www.funpar.ufpr.br:8080/rup/examples/csports/ex_vision.htm#Constraints .Acesso em 23 de Março de 2018.
-
Wikipédia - Documento de Visão. Disponível em:
https://pt.wikipedia.org/wiki/Documento_de_vis%C3%A3o. Acesso em: .20 mar. 2018; -
TechNet - Requisitos de desempenho : Estimar requisitos de desempenho e capacidade para ambientes de colaboração de portal. Disponível em: https://technet.microsoft.com/pt-br/library/cc263100(v=office.12).aspx. Acesso em: .22 mar. 2018;