Resumo do conteúdo para P2 de Engenharia de Software - PUCC

Prévia do material em texto

Scrum
Ele não é :método; é fácil; é a Bala de Prata e muito menos a novidade que veio salvar sua empresa;é fábrica de papel. Também não diz como fazer e não estabelece um processo; ou define documentos e etapas.
Ele é um framework (conjunto de princípios); Um modelo de trabalho; Enxuto; Iterativo e Incremental; com Times que se auto gerenciam; Trabalha com Visão de Produto e Valor; possui Regras claras e diretas; Ferramentas de medição diretas e simples.precisa de COMPROMETIMENTO.
 Ser ágil não é: Pular Etapas; Entregar mais rápido sem testar; Deixar de fazer aquilo que é de valor para o cliente; Cortar recursos e contratar mão de obra barata.
 Ser ágil é: Entregar o que gera valor ao meu cliente(o que o cliente mais necessita); Trabalhar em tarefas que têm resultado ligado ao valor; Ter liberdade e ser time de fato; Igualdade, respeito, responsabilidade e compromisso;
Pilares do Scrum: 
1-Transparência: garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser equivalente à definição de pronto utilizada.
 2-Inspeção: Inspecionar de uma forma contínua tanto o trabalho bem como o processo pelo qual o time resolveu adotar. 
3-Adaptação: Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.
4- Framework Scrum: consiste em um conjunto formado por Times Scrum e seus papéis associados, Eventos com Duração Fixa (Time-Boxes), Artefatos e Regras.
5-Times Scrum são projetados para otimizar flexibilidade e produtividade. Para esse fim, eles são autoorganizáveis, interdisciplinares e trabalham em iterações. Cada Time Scrum possui três papéis: 
 A) o ScrumMaster, que é responsável por: garantir que o processo seja entendido e seguido e o uso do Scrum; impedimentos do time; Protege o time de interferências externas.
 B) o Product Owner, que é responsável por maximizar o valor do trabalho que o Time Scrum faz; ; Responsável por garantir o ROI; Responsável por conhecer as necessidades do cliente; Proxy em ambientes de mais de um cliente; 
 C) o Time executa o trabalho propriamente dito. Sendo Multi-disciplinar; Auto-organizado; Desenvolve produto com qualidade e valor para o cliente (transformar os requisitos do Product Owner em um pedaço potencialmente entregável do produto ao final da Sprint).
6- Sprint: é uma iteração de um mês ou menos, de duração consistente com o esforço de desenvolvimento. Todas as Sprints utilizam o mesmo modelo de Scrum e todas as Sprints têm como resultado um incremento do produto final que é potencialmente entregável. Cada Sprint começa imediatamente após a anterior. Scrum emprega os eventos com duração fixa para criar regularidade. Entre os elementos do Scrum que têm duração fixa, temos a reunião de Planejamento da Versão para Entrega, a Sprint, a Reunião Diária, a Revisão da Sprint e a Retrospectiva da Sprint. 
7- Artefatos: Scrum utiliza quatro artefatos principais:
A) O Backlog do Produto é uma lista priorizada de tudo que pode ser necessário no produto.; realizado pelo P.O. considerando: conteúdo, disponibidade e priorização. O Scrum Master deve ajudar o P.O. a realiza-lo.
B)O Backlog da Sprint é uma lista de tarefas para transformar o Backlog do Produto, por uma Sprint, em um incremento do produto potencialmente entregável;
C)Um Burndown - medida do backlog restante pelo tempo- de Versão para Entrega mede o quanto falta fazer do Backlog do Produto que esteja dentro do prazo definido pelo plano de entrega.
D) Um Burndown de Sprint mede os itens do Backlog da Sprint restantes ao longo do tempo de uma Sprint.
8- Reunião Diária: É o encontro diário com cada time para uma reunião de 15 minutos. Ela é sempre feita no mesmo horário e no mesmo local durante as Sprints, na qual cada membro explica: o que fez desde a última reunião; o que pretende fazer até a próxima; e quais obstáculos estão em seu caminho. Elas melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto.
Fluxo do Scrum
VISÃO Antes de “rodar” o fluxo pela primeira vez, é necessário, ao P.O. estabelecer a Visão de Produto
Sprint Planning Meeting: Nas primeiras horas definir “O QUE” será feito na Sprint (Selected Product Backlog) e uma “META” - visão pela qual a sprint será orientada. Nas horas seguintes o time decide “COMO” construirá o sprint backlog em um incremento do produto durante a Sprint. Participantes: P.O., Scrum Master e Time. 
Estimativa: Cada tarefa deve ser estimada pelo time quanto tempo / pontos custará.
Finalização da Sprint: Ao final da Sprint, é realizada a Sprint Review. Nela o P.O. identifica: o que foi feito e o que não foi feito. O time discute o que foi bem e os problemas que tiveram, e demonstra o trabalho realizado (apresenta o software funcionando). 
Sprint Retrospective: tem a finalidade de responder as perguntas: Como ocorreu o último Sprint, o que se pode melhorar (método de trabalho, ferramentas, membros do time, comunicação, definição de pronto). No final dessa reunião espera-se uma lista de coisas a serem implementadas para a próxima Sprint.
JUnit é um framework open-source simples para escrever testes repetitivos, com suporte à criação de testes automatizados na linguagem de programação Java. Ele facilita a criação de código para a automação de testes com apresentação dos resultados. Com ele, pode ser verificado se cada método de uma classe funciona da forma esperada, exibindo possíveis erros ou falhas podendo ser utilizado tanto para a execução de baterias de testes como para extensão. Com JUnit, o programador tem a possibilidade de usar esta ferramenta para criar um modelo padrão de testes, muitas vezes de forma automatizada. O teste de unidade testa o menor dos componentes de um sistema de maneira isolada. Cada uma dessas unidades define um conjunto de estímulos (chamada de métodos), e de dados de entrada e saída associados a cada estímulo. As entradas são parâmetros e as saídas são o valor de retorno, exceções ou o estado do objeto. Tipicamente um teste unitário executa um método individualmente e compara uma saída conhecida após o processamento da mesma. Algumas vantagens de se utilizar JUnit: Permite a criação rápida de código de teste enquanto possibilita um aumento na qualidade do sistema sendo desenvolvido e testado; Não é necessário escrever o próprio framework; Amplamente utilizado pelos desenvolvedores da comunidade código-aberto, possuindo um grande número de exemplos; Uma vez escritos, os testes são executados rapidamente sem que, para isso, seja interrompido o processo de desenvolvimento; JUnit checa os resultados dos testes e fornece uma resposta imediata; Pode-se criar uma hierarquia de testes que permitirá testar apenas uma parte do sistema ou todo ele; Escrever testes com JUnit permite que o programador perca menos tempo depurando seu código.
Selenium: é usado para automação de testes. ou seja , é uma uma ferramenta de teste (GUI de Ferramenta de automação ). Nele é possível construir repositório de objetos utilizando XPath ou CSS, relatórios de configuração para a execução do teste . O conhecimento de JAVA Core é necessária para testar as funcionalidades . Usando DOM Inspector, reconhecem-se os objetos na página web. Executam-se os testes como Test Testing. Os relatórios pode ser feito usando a classe Reporter TestNG .
GitHub é um Serviço de Web Hosting Compartilhado para projetos que usam o controle de versionamento Git. Este site possui funcionalidades de uma rede social como feeds, followers, wiki e um gráfico que mostra como os desenvolvedores trabalhamas versões de seus repositórios. Pode ser considerada uma tecnologia de controle de versão, vulgo software de GCM, pois garante que as mudanças não se percam.
cd -->Criando um repositório local: 
git add --> Adicionando arquivos novos ou modificados no Stage:
mkdir -- criar diretorio
Removendo arquivos não versionados do Stage:
git rm --cached arquivo.txt
git clean -fd 
Jira: é um rastreador de problemas flexível e escalável para as equipes de software. Faz um acompanhamento de questões e a integração de código para planejar , colaborar e enviar grandes produtos. Um lugar para a sua equipe para compartilhar, encontrar , colaborar e fazer mais trabalho bem feito. Ajuda em : planejamento (Priorizar e agir sobre o que é importante , e manter-se atualizado com fazer tudo da sua equipe); trilha(Criar metas, definir datas de vencimento , e atribuir tarefas a seus companheiros de equipe ), envio (JIRA Hub lau dá-lhe up- to-date informações para mitigar os riscos de lançamento) e o relatório (Melhorar o desempenho com base em dados históricos, equipe acionáveis ​​).
Requisitos de software nada mais são do que um conjunto de atividades que o software deve desempenhar, com suas limitações e restrições, além de características não ligadas diretamente às funções desempenhadas pelo software (SOMMERVILLE, 2003). Possuem 3 tipos: Funcionais(descrevem a funcionalidade ou serviço que se espera que o sistema forneça), Não-funcionais ( Dizem respeito às restrições sobre os serviços- tempo ou processo de desenvolvimento- ou funções do sistema. usabilidade, confiabilidade, suporte,etc), Domínio( refletição das características deste domínio da aplicação do sistema).
UCP é usada para prever o tamanho do software para projetos de desenvolvimento de software, qunado a (UML) e (RUP) metodologias estão sendo utilizados para o design e desenvolvimento de software. Ele baseia-se nos requisitos para o sistema que está sendo escrito usando casos de uso , que faz parte do conjunto de técnicas de modelagem UML. O tamanho do software (UCP) é calculado com base em elementos dos casos de uso do sistema com factoring para contabilizar considerações técnicas e ambientais. A UCP para um projecto pode então ser usado para calcular o esforço estimado para um projecto.
Vantagens e Desvantagens:
Forma de escrita de casos de uso entre mais de um analista pode influenciar nas estimativas do projeto; Valor-hora por UCP é um parâmetro a ser refinado de acordo com a tecnologia em uso, equipe,requisitos, etc; A vantagem de UCP é que, em tese, requisitos representados por casos de uso tendem a ser menos modificáveis ou, ao menos, mais fáceis para uma rápida reestimativa de casos de uso; Permite chegar a um resultado de estimativa mais assertiva ainda na etapa de planejamento, minimizando problemas de estimativa que ocorrem na fase de desenvolvimento; Em alguns casos, casos de uso podem ocultar a real complexidade de um processo de software, especialmente quando ocorre algum esforço técnico acima do normal (exemplo: integrações entre sistemas).