Skip to content

Time: TEDD

Jump to bottom
Daniel La Rubia edited this page Jul 12, 2018 · 60 revisions

TEDD

Desenvolvendo sempre bito a bito

Sobre o Projeto inicial:

Formado por alunos da turma de Fundamentos de Engenharia de Software da Universidade Federal do Rio de Janeiro (UFRJ), o TEDD é um time estruturado para prática e desenvolvimento das capacidades individuais e coletivas em torno dos métodos ágeis. No período de 2018-1, realizaremos um trabalho com o software i-Educar, que é uma ferramenta livre e com código disponibilizado online com fins de tornar mais prática e fácil a gestão de processos das escolas, reunindo dados dos alunos e dando suporte aos profissionais que trabalham com as redes de ensino. Você pode saber mais do projeto i-Educar clicando neste link 🔗.

Fomos colocados diante de um cenário real que consiste basicamente em um problema constante à empresa que realiza a administração do software no momento: Os clientes precisam na maioria das vezes realizar alguma alteração nos relatórios que são gerados pelo programa, entretando pela forma que o mesmo foi desenvolvido essa alteração é muito "trabalhosa" e, por não fornecer a opção de customização para o próprio cliente, a empresa está sempre recebendo pedidos para customização individual.

Nosso objetivo principal é a busca pelo conhecimento nos métodos ágeis e sua aplicação para desenvolver um componente externo (um Plugin ou API) que permitirá ao cliente customizar os relatórios de acordo com suas necessidades. Todo o desenvolvimento será feito em Java com o auxílio da ferramenta Trello (personalizado para funcionar como Canvas para a equipe). Todo o processo de desenvolvimento estará documentado nesta Wiki, tais como os códigos e ideias que venham a surgir.

-Daniel

Sobre o Projeto Merendinha:

Supondo que você não leu acerca do projeto inicial (texto acima), o TEDD é um time formado por alunos da turma de Fundamentos de Engenharia de Software da Universidade Federal do Rio de Janeiro (UFRJ). Nosso objetivo é estudar a metodologia ágil e aplicá-la de forma concreta em um projeto real, dando segurança a cada um dos alunos para que, futuramente, sejamos capazes de confiar e aplicar essa metodologia de desenvolvimento. Tínhamos como projeto inicial o desenvolvimento de um plugin complementar ao i-Educar, para permitir ao usuário leigo a possibilidade de personalizar relatórios de acordo com suas necessidades.

Por diversos problemas encontrados na ideia e planejamento do projeto anterior, o time preferiu por mudar de ramo, partindo para área de merenda escolar, seguindo a solução proposta pelo professor. O Projeto Merendinha (nome escolhido pelo time) consiste em um ambiente que fornece às escolas um ambiente prático para adicionar informações sobre o sistema de alimentação - quantidade de refeições consumidas diariamente, total de alunos presentes, alimentos que são mais consumidos - e, simultaneamente, fornece à prefeitura um ambiente integrado que reune as informações fornecidas por cada escola e permite uma visualização clara sobre o que é consumido, o quanto é consumido e quando será necessário repor o estoque!

Basicamente, nosso projeto surge em meio a uma necessidade de substituir a atual forma de gerenciamento, que se utiliza de uma planilha online compartilhada para realizar o levantamento de informações sobre as escolas e sobre os alimentos necessários. Esperamos em breve poder melhorar essa descrição, tanto quanto queremos melhorar a forma como que se organiza a Prefeitura de Caxias para realizar a compra mensal de alimentos.

-Daniel

Membros do Time

Acompanhadores

  • Professor Eber Assis Schmitz
  • Professor Luis Felipe Coimbra Costa

Lista de Tarefas

Mapa Mental - Primeiro modelo

Conforme requisitado, desenvolvemos um mapa mental para facilitar a visualização e reunião das informações que temos no momento. (Lucas)

Mapa Mental - Versão Final

Alterações para o projeto de merenda e suas respectivas visualizações em forma de mapa mental (Dennison)

Project Model Canvas - Primeiro modelo [v0.1]


Reações

 Semanalmente serão publicadas resenhas relacionadas ao que estamos desenvolvendo como um time e em relação às aulas.

OBSERVAÇÃO: Todas as reações serão disponibilizadas, a partir de hoje, 09/07, na pasta Deliverables do repositório do time TEDD.


Semana 1 - 26/03, 28/03

Como foi visto na última aula e debatido com o estimado Cesar Brod, o Scrum é uma metodologia derivada dos Métodos Ágeis que consiste numa série de passos que tem como objetivo tornar o processo de desenvolvimento de software mais eficiente, diminuindo o tempo necessário para entrega do produto final e acrescentando um maior valor de negócio. O nome de método ágil é uma expressão referente a um conjunto de métodos e boas práticas para o desenvolvimento de software. Ela surgiu para resolver os paradigmas que o desenvolvimento tradicional traziam, que eram: consumo de tempo superando o cronograma previsto, funcionalidades que não resolviam os problemas dos usuários, cancelamento do projeto por inviabilidade, dentre outros.

O desenvolvimento tradicional é trabalhado no conceito de Desenvolvimento em Cascata, onde somente poderia passar para a próxima parte do projeto quando a anterior fosse terminada, o que causa um “trânsito” e fazia com que o projeto ficasse parado enquanto não solucionado algum problema, se existente. Com o estudo do método tradicional com o intuito de diminuir riscos e maximizar o sucesso da produção do software, adotou-se princípios do manifesto ágil que são:

  • Mais indivíduos e interação entre eles do que processos e ferramentas
  • Software em funcionamento mais que documentação abrangente
  • Colaboração com o cliente mais que negociação de contratos
  • Responder a mudanças mais que seguir um plano

Com o método ágil, novas ideias são sempre discutidas para um melhor desempenho. Os trabalhadores estão sempre aprendendo com as necessidades do cliente, possibilitando alterações antes da entrega final.

Basicamente o processo consiste em dois backlogs, o primeiro são as funcionalidades pedidas pelo Product Owner e, o segundo, as funcionalidades que as equipes são capazes de implementar. É feito um planejamento da Sprint (que é realizada num período curto de tempo, entre uma semana a um mês) e, diariamente, além das “dailys” é feita uma inspeção pelo Scrum Master para garantir o bom andamento do projeto. Ao fim do Sprint, analisam-se as funcionalidades que até o momento estão prontas e verifica se precisam passar por mais um ciclo. Nessa metodologia o Scrum Master é responsável por fazer a ponte entre o Product Owner e a equipe de desenvolvimento e garantir que o andamento do projeto vai funcionar perfeitamente, sem interferências externas e removendo possíveis obstáculos que possam surgir. O Product Owner é aquele que cria o Backlog de funcionalidades que se deseja no produto, verifica se aceita ou rejeita o que foi desenvolvido e também cuida da parte de rentabilidade.

Concluindo, enxergamos o Scrum como mais uma forma de aprimorar o processo de desenvolvimento de software, tornando os factíveis problemas grandes em problemas menores, o que além de facilitar o trabalho melhora as relações entre desenvolvedores, times e clientes.

-Daniel e Dennison.

Semana 2 - 02/04, 04/04

Nesta segunda semana, tivemos um conhecimento maior sobre a ferramenta Trello que foi apresentada pelo professor Luis Felipe. Além de tirar dúvidas sobre como utilizar e suas funcionalidades, foi apresentado a estrutura na ferramenta Trello de um projeto real que o professor trabalhou. Com esta conexão feita, o aprendizado e a aplicação sobre tal ferramenta elevou-se completamente, motivando a todos do meu time a utilizar a mesma. Na apresentação do projeto foi mostrado o conceito de boards, cards, backlog, sprints e a organização que segue o conceito de Kanban(“Backlog”, “Fazendo”, “Feito”).

Além disso, foi feita uma motivação para atualizarmos constantemente a página Wiki do nosso repositório. Foi explicado como fazer essas atualizações junto com todos da turma. Por fim, tivemos a entrega do nosso Canvas. Nosso time teve destaque em Justification e tivemos a tarefa de com base no que foi explicado nas aulas, fazer alterações em campos onde o professor julgou que poderia melhorar, podendo consultar o canvas dos outros times, visto que o proposto não era uma competição, mas sim uma troca de conhecimentos para que todos possam aprimorar seus trabalhos.

-Dennison.

Semana 3 - 09/04, 11/04

Nesta semana tivemos o primeiro contato com a nossa "cliente", a Sandra, que é a principal pessoa na aplicação do iEducar nas escolas de Caxias.
Ela expôs algumas das dificuldades das escolas de Caxias em usar o sistema em tudo, dentre esses problemas existe a dificuldade de algumas escolas terem computadores conectados à rede, para que acessem e possam inserir os dados no banco centralizado.
A Sandra também explicou como funciona a aderência dos usuários (escolas) ao sistema. Antes do iEducar todos os formulários eram feitos em um trabalho extensivo, a fim de coletar todos os dados e colocá-los de uma forma organizada, e a maior proposta do sistema vem nesse ponto, simplificar os cálculos e exposição de relatórios. Ela falou também sobre os principais documentos que as escolas usam, o Livro de Matrículas e a Ata de Resultados.
Já na segunda aula tivemos a oportunidade de configurar as workstations, conhecer o laboratório, tirar as dúvidas relacionadas a isso.

-Dennison.

Semana 4 - 16/04, 18/04

Essa semana houve uma reunião completamente diferente, junto à Sandra veio Poliane, também da equipe de desenvolvimento da prefeitura de Caxias, junto delas encaramos o problema mais a fundo. Vimos a aplicação de produção e as dificuldades entre a aplicação, o banco e o gerador de relatórios iReport. Como o o controle e contato com o banco traz várias complicações para a equipe de desenvolvimento, e também como os relatórios se relacionam com o iReport e o sistema do iEducar.
Na segunda aula houve uma discussão sobre que rumo pegar em questão de que problemas atacar, e depois da discussão sobre dever ou não atacar o problema dos relatórios, nossa equipe chegou à conclusão de que o melhor caminho a ser tomado será resolver o problema das merendas.

-Elvis.

Semana 4 - Sobre a Sprint #0

Sprint #0

Por mais que para a maioria dos grupos a questão do projeto já estivesse definido, isso ainda era considerado um 'embate' interno dentro da nossa equipe. A questão de estar desenvolvendo algo similar ao que já existe e já é bom (iReport), na forma de 'curativo' para problemas de desenvolvimento do i-Educar (que está sendo reescrito e não pode ser modificado) foi um tanto quanto desistimulante. Levantamos também a questão de viabilidade, visto que o prazo é curto e o nível de construção desse projeto é relevante; também questionamos se o plugin seria externo ao iReport ou se seria uma modificação no próprio código fonte do programa a fim de modelá-lo à maneira que precisávamos na situação. Em resumo, não havia ânimo e boas ideias para desenvolver esse componente para o i-Educar e a discussão que foi levantada em aula, aliada à possibilidade de um novo projeto, foi agradável e ajudou a compreender a partir dalí como seria a forma correta de se trabalhar em Scrum.

Mais sobre a discussão acalorada que tivemos na aula, os times avaliaram em conjunto qual era a viabilidade e os pontos que cada um consideravam relevantes para sustentar suas respectivas opiniões, que variaram desde a complexidade que seria desenvolver esse tipo de projeto desde um simples "é possível". Os Scrum Masters tiveram uma breve fala pra representar o time e explicar o que cada um estava achando do projeto, foi muito falado sobre a péssima modelagem e os erros presentes no banco de dados, levantando a questão de que isso também pode ser um dos motivos das dificuldades que são enfrentadas no processo de geração de relatórios personalizados. Um dos times apresentou um projeto em estágio avançado em relação aos outros, já mostrando qual seria a ideia que tiveram para interface e um breve levantamento de informações que fizeram com uma olhada no banco.

Aos grupos que estavam desmotivados com o plugin para os relatórios do i-Educar, o professor propôs que se dispusessem a desenvolver um projeto voltado ao gerenciamento da merenda escolar no município de Caxias. Explicando a situação: atualmente o gerenciamento da quantidade de refeições diárias, do tipo de alimento consumido e todas as informações adicionais são gerenciadas por uma planilha online (Google Docs). Embora isso seja uma solução que permite um gerenciamento das informações, deve-se concordar que não é feito da melhor maneira. Não há um sistema decente de permissões, não é interessante entregar uma planilha a uma grande quantidade de pessoas para que gerenciem juntas, assim como também não é prático que poucas pessoas tenham acesso a essas planilhas e as escolas enviem separadamente a quantidade de alimento consumido, pois coloca na mão do 'gerente' a responsabilidade de computar as informações de todas as escolas. Nosso plano de projeto é desenvolver um ambiente integrado que irá permitir que todas as escolas tenham autonomia para inserir suas próprias informações no banco de dados, entretanto não podem visualizar e nem alterar informações referentes a outras escolas. Os responsáveis da prefeitura por visualizar essas informações e gerenciar a 'lista de compras' terão todas as informações reunidas de forma clara e detalhada, podendo consultar informações das escolas individualmente tanto quanto as informações gerais. Também estamos planejando permitir ao software um bom detalhamento de dados, permitindo levantar informações e gráficos acerca da quantidade de alimento consumida mensalmente, qual é a média de demanda, média de alunos se alimentando diariamente, semanalmente, mensalmente e quem sabe anualmente. Escrevemos com base nisso todas as nossas histórias.

Em tese, a mudança de projeto nos permitiu enxergar de forma mais clara o que queremos e iremos fazer, tanto quanto nos motivou a pensar nas variadas formas de construir isso utilizando a metodologia ágil. Acreditamos que a partir daqui já temos a motivação necessária para iniciar o desenvolvimento rumo a Sprint #1.

-Daniel.

Semana 5 - 23/04, 25/04

Âncora: "Os objetos que estão ao nosso redor têm uma finalidade utilitária. Entretanto, certos objetos incorporam outra perspectiva, seu significado simbólico. Assim, a âncora é muito mais do que uma simples peça de metal destinada a fixar uma embarcação no fundo do mar. Deve-se destacar que um barco sem âncora flui de maneira inevitável e esta circunstância é tão evidente que a âncora serve como metáfora para expressar qualquer tipo de ideia."

Nosso time não é um barco sem âncora, na verdade ele possui uma âncora bastante pesada. Embora tenhamos conseguido escrever as histórias que guiariam o nosso projeto, nada além disso foi feito. O fato de ter um rumo a seguir, não significa que o mesmo será seguido e muito menos que todos os ventos que virão serão favoráveis.

Nessa primeira semana enfrentamos um obstáculo conhecido como falta de comprometimento, que gerou desconforto e, consequentimente, improdutividade. A partir do bom senso e das conversas que tivemos, esperamos que esse não seja um problema que ocorra novamente. Foi sugerido por um dos membros do time a utilização da Framework Spring e iremos analisar a possibilidade para a Sprint #2. Nada foi entregue.

-Daniel.

Semana 6 - 02/05

Novamente, nossa âncora permanece fincada ao solo dos problemas. Embora tenha tido um breve momento em que navegamos, dessa vez a falta de comprometimento não foi o maior dos nossos desafios internos; esbarramos numa semana de provas complicadas, em que todos os membros do grupo possuem exames para fazer na quarta e quinta feira, que impossibilitou com que focássemos no nosso projeto.

Embora tenhamos commitado a base do nosso projeto em Spring, não desenvolvemos nenhuma interface e nenhuma linha de código próprio, conjunto a isso não trouxemos nada que pode ser considerado entregável para a aula. Aqui, hoje, utilizamos o tempo para tentar tirar um pouco do atraso passado, acrescentando alguns textos que estavam pendentes e montando nosso Sailboat. Nosso planejamento para a Sprint #3 é conseguir alcançar os grupos mais adiantados e tentar, no mínimo, compensar de alguma forma todo o nosso atraso nos Deliverables, concluindo algumas de nossas histórias e subindo nosso banco de dados.

Em relação ao conteúdo dado, essa semana por conta do feriado no dia 01/05 (terça-feira), tivemos um ponto facultativo na segunda. Isso fez com que nossa única atividade na semana fosse o laboratório, onde essa reação foi escrita.

-Daniel.

Semana 7 - 07/05, 09/05

Essa semana começamos os estudos referentes a Testes de Software, explicados pelo professor Éber (que a partir de agora nos dará aula durante todas as segundas-feiras).

Os conceitos explicados basicamente nos garantem a qualidade do software que está sendo desenvolvido e será entregue. De forma análoga, é como os brinquedos e outros produtos criados pelas empresas que precisam passar pelos testes do Inmetro para receber o selo de qualidade. Esse processo é feito idealmente durante as etapas de desenvolvimento, nos certificando que tudo está funcionando conforme é esperado. Foi falado das características gerais, que tratam das diferentes técnicas para verificação de funcionamento, os atores (time responsável apenas por realizar testes) e também os variados tipos de testes em si.

Não foi possível falar sobre tudo durante essa aula por questões de tempo, então o professor informou que o assunto viria a ser concluído na semana seguinte.

-Daniel.

Semana 8 - 14/05, 16/05

Essa semana o professor Eber "concluiu" o que havia ficado em aberto na próxima semana e nos apresentou tipos importantes de testes que são muito utilizados nas empresas e na área de desenvolvimento de software em si. Quanto aos conceitos levantados, falamos sobre Verificação e Validação, o quanto é importante manter a qualidade e GARANTIR a integridade do produto que está sendo desenvolvido, estratégias para realização dos testes e outros pontos mais.

Na sequência, seguimos e vimos casos e procedimentos de teste, Oráculo de Teste (um nome curioso que inclusive causa certa estranheza por ser incomum, ao menos para mim que nunca ouvia escutado essa palavra na computação. Por definição, "Oráculo de Teste" contempla a "fonte utilizada para determinar os resultados esperados e compará-los com os resultados reais produzidos pelo software que está sendo testado", definição encontrada aqui), os casos de teste Positivo e Negativo etc.

Nos slides estão contidos os detalhes referentes a cada conceito, embora eu tenha achado um pouco complicado de utilizar somente aquele material para compreensão de tais conceitos.

Alguns testes relevantes:

  • TDD - Test Driven Development (Calma, não é TellelvisDanielDennison): Em tradução literal, significa Desenvolvimento guiado por testes, que é uma técnica de desenvolvimento de software que se relaciona com o conceito de verificação e validação. Baseia-se em escrever um caso de teste que é automatizado, definindo uma melhoria desejada ou funcionalidade. É produzido um código que possa ser validado pelo teste e posteriormente esse código é refatorado para um código sob padrões aceitaveis. (Definição: Wikipedia)

  • Teste de Unidade: Tipo de teste que realiza uma verificação de uma unidade única do sistema, testando de maneira isolada e fazendo a simulação das prováveis dependências que essa unidade possui. Trazendo para um desenvolvimento orientado a objetos, é comum que a unidade que irá ser testada seja uma classe, portanto todos os testes realizados se limitarão a essa classe, ignorando as interações que possam existir com outras classes. (Definição: Caelum)

  • Teste de Integração: Responsável por verificar a integração entre duas ou mais partes do sistema. Um exemplo simples é caso seu código comece em uma classe e vá até algum serviço externo, como um banco de dados, serviços web etc. Esse teste me certifica que existe uma integração fidedigna na aplicação.

  • Testes Alfa e Beta: Principalmente os usuários que estão acostumados a jogar jogos online já estão acostumados com esse termo. Os testes Alfa e Beta são levemente similares, sendo um a sequência do outro. O primeiro é realizado no início, antes que esteja concluído o desenvolvimento do software. Esses testes são realizados em "laboratório", onde geralmente usuários internos simulam usuários reais na busca de problemas que possam existir durante o funcionamento da aplicação. Isso permite que problemas mais críticos sejam solucionados rapidamente pelos responsáveis pelo desenvolvimento. O Teste Beta vem logo na sequência, onde o software é liberado para o público geral utilizar e, em troca, pedem um feedback caso encontrem problemas ou bugs. Geralmente um número limitado de usuários é autorizado a participar desse teste, é o que chamamos de beta fechado. Quando é liberado para QUALQUER usuário, chamamos de beta aberto, muito comum em games como já dito.

  • Teste de Sistema: Inclui no teste todos os componentes responsáveis pelo funcionamento do software, desde o código até o hardware e sistema operacional onde a aplicação está sendo executada. Esse teste me garante o funcionamento do sistema de forma completa, podendo-se incluir testes de stress, desempenho, entre outros.

-Daniel

Semana 9 - 21/05, 23/05

Na aula expositiva da segunda-feira, o professor Eber fez uma comparação entre os testes de Regressão e Fumaça, explicando que o primeiro é bastante demorado e computacionalmente tem um custo elevado, enquanto o outro pode ser feito a cada dia, checando e certificando de que tudo que foi feito no dia de trabalho anterior continua funcionando normalmente.

Em seguida, falamos um pouco sobre os tipos de Teste de Caixa Branca, englobando principalmente o Caminho básico e Cobertura de Comandos. O Eber explicou que a cobertura de comandos não é uma boa escolha porque só verifica se o comando foi executado uma única vez. O Teste de Caminho básico insere alguns conceitos como 'Caminho Independente', Grafo de Controle etc.

Na quarta-feira, como de costume, tivemos o laboratório onde fizemos o Sprint Review e as cerimônias padrão.

-Daniel.

Semana 10 - 28/05, 30/05 (Greve dos Caminhoneiros)

HackComb - HACKEANDO O COMBUSTÍVEL

  • Organização das tarefas: Leitura de issues e Pesquisa sobre Pull Request : https://www.atlassian.com/git/tutorials/making-a-pull-request
    Através de uma visão geral das issues propostas para o HackComb traz-se um plano para o trabalho do dia, uma noção da figura do trabalho. Depois, sobre o PullRequest fez-se uma pesquisa sobre a possibilidade de uso desta ferramenta para o trabalho do dia.
    Como foi usado desde o início um modelo onde os alunos tem acesso completo ao serviço do github, não faz sentido partir para PullRequest, já que essa estratégia define fluxos de trabalho separados entre a comunidade. Mas é importante ler as páginas de tutorial do Atlassian, exemplificadas pela página acima.
  • Usar a Wiki para documentar as tarefas: A Wiki serve como ferramenta de documentação e organização das tarefas, logo será usada para registrar o backlog do dia, também servindo como um meio de passagem das tarefas para leituras posteriores.
  • Preparar prioridades para o time: Como é de suma importância o login no sistema, para o time presente a tarefa decidida foi terminar a história relacionada a este ponto.
    Então a separação fica: "Fazer a segurança do login", "Definir a página de login".
  • Executar tarefas (issues): Foi iniciada a pesquisa relacionada a como o security funciona, para descobrir onde estava o problema.
  • Hangouts: Foram feitos hangouts para reunir os times sobre o que foi feito à distancia e o que foi feito na HE:labs, geralmente descrevendo o que foi feito em cada pomodoro (intervalo de 30min)
  • Executar Backlog: À tarde, depois do almoço foi descoberto o problema. Com este resolvido, foi decidido que era mais importante conversar sobre teste com os outros times que estavam na sala, e assim foi feito até o fim do dia.
  • Hangout Entre Times - Assunto Livre: Neste hangout em específico foi feita uma apresentação com demonstração em tela, por mais rápido que tiver sido, de exemplos de testes automatizados em spring e também algo de JUnit.
  • Elvis.

Semana 11 - 04/06, 06/06

Passada a crise que assolou o país devido a Greve dos Caminhoneiros, retornamos para aula após um breve recesso e com isso o professor Eber fez uma revisão geral em casos de teste.

Dentre os tópicos abordados, os mais relevantes são o método da Caixa Branca (continuação do que já havia explicado na última aula que havíamos tido pré-recesso) e o Teste da Caixa Preta, que ainda não havia sido formalmente explicado. A grosso modo, a diferença entre os dois é que o Teste de Caixa Branca é feito em cima do código fonte, enquanto o outro é de acordo com as especificações.

Em certo momento da aula, o professor nos questionou acerca de como poderíamos especificar um software, e pontuou algumas questões relevantes a serem utilizadas nesse momento, sendo elas:

  • Nomes dos métodos, parâmetros e saída

  • Utilização da ferramenta OCL (Object Constraint Language, que significa Linguagem para Especificação de Restrições em Objetos). Por definição do Wikipedia, é uma linguagem declarativa para descrever as regras que se aplicam aos modelos UML. Aparentemente, a grande vantagem é que o "OCL, por fornecer expressões livres das ambiguidades das linguagens naturais e menos difíceis que os métodos formais tradicionais, complementa os modelos UML".

Observação: Embora tenha recomendado a OCL, também pode ser feito escrito em português convencional.

No que poderíamos chamar de segunda parte da aula, falamos sobre os casos de uso, que funciona como um roteiro. São os passos para que o usuário (ou algum determinado autor) siga para realizar determinada ação no software. No relatório que foi mostrado em sala, temos as seguintes seções:

  • Caso de Utilização: O que o usuário realiza no software seguindo os passos listados

  • Pré - Condição: Condições iniciais para que o sistema atenda e execute a função desejada

  • Pós - Condição: Qual é o resultado esperado ao final da execução/procedimento

  • Fluxo de sucesso: O que deve ocorrer caso tenhamos uma situação de sucesso, sem saltos no código

  • Fluxo alternativo: Condições e repetições caso hajam as condicionais

Nessa aula, o professor pediu para que fizéssemos alguns casos de uso passa nosso software, e também questionou sobre ter sido um dos primeiros procedimentos a realizarmos assim que começamos o desenvolvimento do projeto. Os casos de uso feitos em sala e posteriormente já estão disponíveis na pasta Deliverables do nosso repositório.

-Daniel.

Semana 12 - 11/06, 13/06

GREVE DOS RODOVIÁRIOS: NÃO CONSEGUI CHEGAR NA FACULDADE PARA AULA DO EBER, SEGUNDA-FEIRA

Na quarta-feira, o professor Luis fez uma reunião entre pessoas de grupos distintos para discutirem acerca de problemas que lhes estavam ocorrendo.

Eu conversei com o time Celta 80Km/h, onde inicialmente conversamos bastante sobre os problemas relacionados aos testes que estava sendo um problema para eles (não me recordo com quem conversei, se não me engano se chama Vitor) e eu expliquei a situação do meu grupo, que estava desmotivado muito atrasado em questão de desenvolvimento. Em seguida os outros membros do Celta chegaram, me mostraram como estava a interface do programa deles até então e falaram sobre um problema que estava ocorrendo ao tentar realizar login. Indiquei que procurassem sobre Hash e se possível implementassem, porque acredito que além de facilitar, naquela situação, é uma questão voltada a segurança da informação.

O fato de armazenarmos senhas em texto plano num banco de dados é um risco gravíssimo a segurança dos usuários do sistema, visto que, caso ocorra algum tipo de invasão ou roubo de dados, o responsável pelo ataque possuirá acesso de todos os usuários que estão cadastrados no sistema. Aliado a isso, sabemos que é muito comum que os usuários reutilizem suas senhas em diferentes serviços, então isso poderia gerar um estrago ainda maior caso viesse a acontecer tal incidente.

Em breve explicação, o hash é um algoritmo matemático de dispersão consegue trabalhar com uma enorme quantidade de dados e limitar a um tamanho específico. Existem vários tipos de hash, mas o grande porquê do mesmo ser utilizado é que ele é unidirecional. Uma vez que você converteu a senha do usuário em um Hash, você não consegue realizar o processo inverso. Claro que existem técnicas (como brute force) para buscar encontrar senhas comuns geradas por colisões, entretanto dificulta em milhares de vezes o trabalho dos atacantes ao tentar utilizar os dados roubados e fornece ao usuário uma camada a mais de proteção.

-Daniel.

Semana 13 - 18/06, 20/06

Nessa semana, o professor Eber iniciou a aula recordando sobre os casos de teste, mas principalmente em como uma boa especificação em relação ao software ajuda na escrita dos processos de teste propriamente ditos. Durante a semana me questionei um pouco sobre a diferença entre os "Casos de Uso" e "Casos de Teste", porque me gerou certa confusão. Acredito que principalmente por ter enxergado muita similaridade entre ambos. Numa reação de outrora, especifiquei sobre os casos de uso e como é o escopo de um relatório dos mesmos. Aqui, me limitando aos casos de teste, basicamente temos três partes, onde:

  • Entrada e saída: Aquilo que devemos testar como entrada, esperando determinada saída como resposta a isso

  • Pré - memória: Nos casos de uso nós termos as pré-condições, que são similares. Aqui nós verificamos que, após as pré-condições dos casos de uso houverem sido obedecidas, existem outros casos que eu posso ter

  • Pós - memória: Similar ao que foi explicado acima, entretanto é feita a comparação com as pós-condições dos casos de uso

Por fim, na quarta tivemos a aula no laboratório onde os times se reuniram e fizeram o Planing e Review, bem como fizeram o acompanhamento em relação ao andamento dos projetos com o professor Luis.

-Daniel.

Semana 14 - 25/06, 27/06

Acredito que, pessoalmente, essa aula tenha sido uma das melhores na segunda-feira. Tivemos uma discussão inicial em que conversamos sobre como estavam o andamento dos projetos e fiquei um pouco aliviado de ver que não fui apenas eu quem tive dificuldade na aplicação do Scrum no dia a dia. Os outros grupos citaram algumas das dificuldades que estavam encontrando e prosseguimos para a aula com base no seguinte ponto:

"Mais vale arquitetar e projetar o software ou construir e derrubar consecutivas vezes?"

Analogamente, o professor exemplificou utilizando situações representativas como na Engenharia Civil, em que os projetos possuem um custo altíssimo para que, quando se iniciarem as construções, não hajam dúvidas de que tudo que foi planejado foi friamente calculado e não haverá riscos de erros nesse sentido.

O professor mais uma vez falou bastante sobre os custos, que é algo que eu admito ainda não compreender muito bem e ter noção de como que é realizado tal tipo de cálculo (acredito que seja baseado na qualidade da empresa que presta o serviço e, a mesma, cobre de acordo com os valores dos salários dos funcionários que ela contrata). Nesse caso, disse que embora seja custoso fazer um bom planejamento de projeto, isso garante que haverá um custo menor para manutenção e menos riscos de problemas estruturais.

Na aula também foram mostrados alguns tipos de diagramas comuns, como o Diagrama de Classes, Sequência e Transição. Aproveito para deixar o questionamento que ainda não respondi a mim mesmo:

"A utilização de driagramas posteriores ao início de desenvolvimento do software se encaixam na metodologia ágil?"

"Existe sentido em fazer uma modelagem no banco de dados posterior a necessidade de uso do mesmo?"

Para exemplificar o último caso, situando como background o meu projeto: se eu possuo apenas uma página de cadastro de usuários pronta, eu preciso já ter o banco modelado para receber as páginas de cadastro de alimentos e escolas ou devo fazê-las apenas quando realmente estiver desenvolvendo-as? Caso a resposta seja o que foi dito por último, realmente me parece claro a falta de necessidade de uma modelagem do banco de dados anteriormente, utilizando os diagramas que foram mostrados.

No laboratório, quarta-feira, tivemos um excelente bate-papo com o Luis a respeito de algumas discussões que havíamos tido em aula com o Eber. Pontuamos o andamento dos nossos projetos e tomamos algumas decisões a respeito de entregas e a data da nossa prova/teste. A seguir, uma pequena lista do que foi conversado e acordado:

  • Desenvolver pelo menos fazer o básico de testes para entregar
  • Fazer no mínimo 1 caso de uso, recomendavelmente 3
  • Apresentação do projeto dia 11/07
  • Sobre a apresentação:
    • Apresentar algo visualmente bonito porque agrega valor
    • Falar sobre como é feita a utilização do software
    • Explicar parte da documentação, como foram realizados os testes e mostrar alguns prints da Wiki
    • Verificar a possibilidade de explicar alguns dos conceitos aprendidos
  • Possibilidade de vinda da mídia para registrar a apresentação dos trabalhos, visto que os projetos possuem um caráter social, já que fornecemos software para a prefeitura de Caxias
  • Teste será dia 02/07 (como dito pelo Éber) ou talvez dia 09/07, ainda será decidido
  • A segunda chamada, caso o teste seja dia 09/07, ocorrerá no dia das apresentações (11/07). Os grupos que contiverem pessoas que não fizeram o teste apresentarão primeiro para que os membros que precisem realizar o teste possam fazê-lo durante a apresentação

-Daniel.

Semana 15 - 02/07, 04/07

NÃO HOUVE AULA NA SEGUNDA DEVIDO AO JOGO DA SELEÇÃO BRASILEIRA NA COPA DA RÚSSIA.

Embora infelizmente eu tenha me atrasado e não tenha tido a oportunidade de sentar e fazer o Sprint Planing e Review com meu time, sentei com a galera do XtremeGoHorse e batemos um papo bem interessante sobre como estava o andamento do projeto deles e as dificuldades que estavam enfrentando. Em resumo essa foi nossa última semana, onde nos preparamos para o teste que ocorrerá no dia 09/07 e apresentação do projeto no dia 11/07.

O professor Luis escreveu no quarto alguns detalhes e recomendações sobre a entrega do Book do projeto, contendo fotos, links, design e outros anexos. Bem como deu dicas para a apresentação na próxima semana. Segue:

  • Apresentação:

    • Rodar o software
    • Mostrar o repositório
    • Conclusão: Como foi o curso de Fundamentos da Engenharia de Software

  • Book do projeto:

    • Quem é o time?
    • Os 5 porquês
    • Processo de construção de software
    • Reações
    • Conclusões
    • Anexos (gráficos, imagens, casos de teste e uso etc)

-Daniel.

Semana 16 - 09/07, 11/07

  • [09/07] - Teste com 11 questões relacionados a metodologia ágil e processos de desenvolvimento de software ✅

  • [11/07] - Apresentação dos Projetos e conclusão do curso de Fundamentos de Engenharia de Software


Sail Boat: ventos em falta, água a baixos níveis; como lidar com a frustração e barreiras enfrentadas


Burndown Chart

Primeiramente havia feito o gráfico abaixo, acreditando ser uma saída fácil para visualizar de forma básica e clara como havia sido a evolução do time em relação as tarefas que estavam no Backlog. Entretanto, após uma conversa com o Victor, do time XtremeGoHorse, vi que não era a solução ideal e muito menos a correta. Portanto o gráfico abaixo permanecerá na Wiki, mas faremos de conta que sua função é explicar para uma criança o quantas coisas os coleguinhas fizeram durante a semana!

Agora falando com os adultos, vamos aos gráficos que detalham melhor como foi a pontuação individual de cada membro, bem como a pontuação como time, fazendo um comparativo com o que era esperado e o que foi concluído.

Serão mostrados gráficos com a mesma amostragem, apenas divididos para gerar certa clareza. Como dividimos nossa Sprint em duas para que pudéssemos mostrar o andamento do nosso progresso (visto que não haverá oportunidade no dia da apresentação), serão mantidos os gráficos das duas semanas que a compuseram.

Sprint 7.1

1º - Burndown Chart Completo:

Burndown Completo

2º - Burndown Chart com a pontuação do time por Sprint:

Burndown Time

3º - Burndown Chart com a pontuação dos membros por Sprint:

Burndown Membros

Sprint 7.2

1º - Burndown Chart Completo:

Burndown Completo

2º - Burndown Chart com a pontuação do time por Sprint:

Burndown Time

3º - Burndown Chart com a pontuação dos membros por Sprint:

Burndown Membros

Os gráficos, bem como as pontuações formadoras dos mesmos, podem ser visualizados clicando neste link


Opinião: Como foi utilizar a metologia Scrum no ambiente universitário

Passados pouco mais de três meses de estudos na disciplina de Fundamentos de Engenharia de Software e um pouco menos que isso desenvolvendo o projeto próprio da disciplina, descrevo aqui uma análise e uma opinião inteiramente pessoal sobre como foi, para mim, aplicar a metodologia ágil (mais especificamente o Scrum) para desenvolver esse projeto como universitário.

Voltando ao início, é possível relembrar o quanto foi animador. O fato de estarmos sendo inseridos de uma forma bem bacana no meio de um projeto real, que acrescentaria bastante no desenvolvimento individual e coletivo de todos os alunos que estavam cursando a disciplina, foi um dos grandes motivadores primários. A forma com que o Luis conduzia as aulas e incentivava a interação entre os grupos foi algo incomum comparado ao que estou habituado na faculdade e foi um dos grandes pontos positivos da disciplina. Geralmente há certo receio por parte dos professores quanto a 'cola', mas o voto de confiança do Luis e incentivo ao trabalho coletivo indo além dos membros do próprio grupo foi a chave para que, independente dos problemas com os projetos até aqui, a disciplina tenha sido um sucesso para os que souberam aproveitá-la.

Quando começamos a nossa primeira tentativa de desenvolvimento, batemos nossas cabeças por não enxergar uma maneira muito clara de como seria criar um componente externo para o iEducar. Parecia que estávamos fazendo um curativo para um problema na geração de relatórios que não é nem por 'culpa' do iReport, e víamos como inviável construir um software com nível próximo do mesmo. Tivemos uma conversa acalorada em uma aula de laboratório, onde a turma levantou os pontos positivos ou negativos que encontraram, além de comentarem sobre o que estavam achando em relação a ideia do projeto. Lá foi levantada uma nova possibilidade pelo professor, que seria a criação de um software para funcionar como solução à utilização de planilhas no Google Docs para gerência de merenda escolar no município de Caxias. Alguns grupos preferiram permanecer com o iEducar, outros gostaram da nova ideia e mudaram de projeto, como o meu caso.

Partindo daí, o meu grupo iniciou motivado a entregar O software. Víamos não como uma tarefa simples, mas enxergávamo-nos como completamente capazes de desenvolver algo de ótima qualidade, mas a partir da segunda/terceira semana as coisas começaram a mudar. A motivação inicial deu lugar a desinteresse, falta de comunicação, falta de compromisso e dificuldade contínua de retomar o desenvolvimento do projeto. Não conseguíamos realizar reuniões diárias, quiçá semanais. O único momento que tínhamos juntos eram nas aulas de segunda ou quarta-feira e, ainda assim, nem sempre estavam todos presentes. Por que será que, após um início tão animado, as coisas desandaram de tal forma?

Comecei a olhar pelo meu lado, inicialmente, e percebi que a preocupação com as outras disciplinas acabava me fazendo atrasar as resenhas semanais. Essas que fiz apenas até a sexta semana, se não me engano. A preocupação com provas e listas de exercícios que precisava entregar para disciplinas mais "rígidas" me fez relaxar a cobrança sobre mim mesmo quanto a manter o ritmo de escrita. Hoje, 25 de Junho, na início da aula do Éber, conversávamos quanto ao andamento dos projetos e foi possível notar que um dos problemas que mais atrapalharam foi, também, a comunicação. Fiquei um pouco mais tranquilo em ver que esse problema não era exclusividade do meu grupo, mas confirmou um pensamento que eu já havia tendo há alguns dias: é relativamente complicado aplicar o scrum de forma tão eficaz quando um grupo possui uma rotina tão diferente.

Tomando como exemplo o meu grupo, que é o que eu conheço, temos rotinas que divergem em todos os sentidos: metade está livre durante o fim de semana, outra metade não. Um está livre todas as tardes, outros não. Alguns estão livres durante a noite, os outros estão trabalhando. Não é simples manter o ritmo de desenvolvimento diário do projeto tendo tantas atribuições (seja lá outras disciplinas ou estágio, por exemplo), então uma reunião diária como seria o ideal não é eficaz e, antes mesmo disso, não é fácil de ser realizada (presencialmente é praticamente impossível). Tenho a percepção de que a utilização do Scrum dentro de um ambiente profissional de trabalho, onde uma equipe entra e sai, todos no mesmo horário, focados no projeto, é uma experiência absolutamente superior ao que é possível de se experimentar estando na faculdade com as dificuldades citadas.

Concluindo, para não me estender excessivamente, no início do período eu comecei a leitura de um livro em que o autor explicava até mesmo como aplicar a metodologia de Scrum para realizar um casamento e me convenceu de que era eficaz. Entretanto, pelas dificuldades enfrentadas no decorrer do período, me questiono não quanto a efetividade do método, mas o quão bom é aplicá-lo ao pé da letra nas condições de um grupo de estudantes universitários com rotinas divergentes e, ao mesmo tempo, se fui eu, como Scrum Master, incapaz de aplicar o método da maneira correta e, assim, torná-lo inefetivo em tais condições.

Daniel.


Escopo das Telas

Tela de Login

Home

Cadastros

Relatórios

Consultas

Perfil

Desconectar


Tutorial de Instalação

Como nossa aplicação é Web, não temos necessariamente uma instalação. O processo que ocorre é subir os arquivos no servidor juntamente com o banco de dados, tornando acessível localmente. Aqui estará sendo explicado o processo para rodar a aplicação LOCALMENTE:

-Tabela com as instruções

Passo Instrução
1 Baixar a aplicação no repositório do projeto (link)
2 Rodar a aplicação no Terminal do Linux utilizando o comando ./mvwn spring-boot:run (É necessário possuir o Maven)
3 Subir o Docker-Compose para deixar o banco de dados acessível
4 Aguardando o elvis disponibilizar o compose!!
. . .

Book do Projeto

Conforme requisitado pelo professor, organizamos as informações contidas na Wiki e fizemos algumas adições para criar o Book do nosso projeto. Lá estão contidas todas as reações, bem como gráficos, opiniões e afins. Para fazer o download, basta clicar neste link.

Clone this wiki locally