Conteúdo P1 ES

Prévia do material em texto

Paradigmas de ES são modelos de processo que possibilitam: 
• Ao gerente: Controlar o processo de desenvolvimento de software
 • Ao desenvolvedor: Obter a base para produzir, de maneira eficiente, software que satisfaça os requisitos estabelecidos
• Os paradigmas servem principalmente para diminuir os problemas encontrados no processo de desenvolvimento de software. 
• O paradigma é escolhido de acordo com o tipo de projeto, métodos, prazo, custo, esforço e ferramentas disponíveis.
Paradigmas a serem conhecidos em ES: Clássico (Ciclo de vida clássico); Evolutivo; Espiral
Clássico (Modelo Cascata) 
Características: Sistemático e Sequencial ; o resultado de uma fase é entrada para outra (ordem linear) ; cada fase é estruturada como um conjunto de fases e podem ser executadas por pessoas diferentes, simultaneamente.
Aplicação do Modelo: A opção pelo paradigma clássico depende da COMPLEXIDADE da aplicação que será desenvolvida. Ele é preferível para aplicações muito simples, com poucas funcionalidades e requisitos bem claros, demandam MENOS formalidade. 
As fases do Cascata: Elas também aparecem em outros paradigmas, a diferença está no modo em que as atividades são conduzidas de acordo com o paradigma adotado. Em outras palavras: Todo projeto tem uma fase de análise, mas as formalidades e o jeito que a disciplina é conduzida, fazem diferença de um modelo para outro.
Análise e Especificação de Requisito: São identificados, através de consultas aos usuários do sistema, OS SERVIÇOS (Requisitos em forma de funções) e as metas a ser atingidas. 
• O Analista: Descobre O QUE deve ser feito e especifica os requisitos por meio de documentos, mas não os detalhes técnicos de implementação.. Um documento muito conhecido nesta fase é o Documento de Visão de Projeto. 
• Nesta fase se obtém o ACEITE do Cliente sobre os requisitos especificados. Dessa forma o documento deve ser de fácil entendimento por todos os envolvidos no projeto que utilizarão esses documentos (cliente, desenvolvedor, testador, gerente etc) Análise e Especificação de Requisitos
 • Os requisitos especificados preciosamente neste fase, são classificados:
- Requisitos Funcionais (São entendidos como funcionalidades - o que o software deve fazer) 
- Requisitos Não Funcionais (Em geral, não são solicitados pelos clientes, mas o software muitas vezes deve atender: Segurança, Integridade dos Dados, Alta disponibilidade) 
- Requisitos de desenvolvimento e manutenção: Incluem os procedimentos de controle de qualidade. Procedimentos de TESTES do sistema e descrição do que poderá ser alterado no futuro.
 – Requisitos de Aceitação: O que é entendido como satisfatório para o Cliente
Projeto : Esta fase também é conhecida como ARQUITETURA do Sistema. Ela é a responsável em transformar os requisitos em soluções de arquitetura (pré codificação).
 • Nesta fase são construídos os modelos de dados (MER) e Diagramas de Arquitetura de Projeto
 • Além disso, o gerente estabelece um plano de PROJETO, com as datas de entregas, correções, cronogramas e definição de marcos. 
Implementação e Teste Unitário: É a fase da CRIAÇÃO, em que os requisitos se tornam funcionalidades reais do sistema. Nela são feitos: Interfaces (layout das telas); Programas (códigos) ; Testes de cada unidade programada
 Teste Unitário : Ao fazê-los cuidadosamente diminui trabalho consequentes de não tê-los feito bem. Dessa forma,T tudo deve ser testado para garantir um mínimo de funcionamento.
Fase de Verificação : Nela são realizados testes sistêmicos e integração. Os testes se tornam mais robustos, garantindo que as partes estão integradas e sem defeitos. E cada parte já deveria ser testada em separado pelo teste unitário.
 Operação e Manutenção 
• Normalmente esta é a fase mais longa do ciclo de vida. 
• Porém a manutenção é classificada em diversos tipos: Corretivas ; Adaptativas ; Evolutivas
Modelo Espiral
Características Principais: 
• “O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos específicos.”
• Isto significa que podemos encaixar nele as principais características dos modelos clássicos, adaptando-os a necessidades específicas de desenvolvedores ou às particularidades do software a ser desenvolvido. Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, além das principais atividades do modelo cascata.
A característica marcante – Riscos: Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste metamodelo com base em análise de riscos e planejamento que é realizado durante toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto.
Exemplos de Riscos: Profissionais deixarem a equipe; Quebra de contrato; Impedimentos tecnológicos (exemplo: o sistema não funcionará na versão nova do Windows).
Tudo isso tem um significado central: O compromisso de entregar o produto que o cliente pagou para ter (o que ele deseja). Porém, qualquer projeto está sujeito a isto. Os riscos precisam ser reduzidos.
Estágio 1: devem ser determinados: objetivos, soluções alternativas e restrições. 
Estágio 2: devem ser analisados os riscos das decisões do estágio anterior. Durante este estágio podem ser construídos protótipos ou simulações do software. Recomenda-se, protótipos descartáveis nesta fase (o cliente não sabe o que deseja).
 Estágio 3: consiste nas atividades da fase de desenvolvimento, incluindo design, especificação, codificação e verificação. A principal característica é que a cada especificação que vai surgindo a cada ciclo - especificação de requisitos, do software, da arquitetura, da interface de usuário e dos algoritmos e dados - deve ser feita a verificação apropriadamente. 
Estágio 4: compreende a revisão das etapas anteriores e o planejamento da próxima fase. • Neste planejamento, dependendo dos resultados obtidos nos estágios anteriores - decisões, análise de riscos e verificação, pode-se optar por seguir o desenvolvimento num modelo Cascata (linear), Evolutivo ou Transformação. Por exemplo, se já no primeiro ciclo, os requisitos forem completamente especificados e validados pode-se optar por seguir o modelo Cascata. Caso contrário, pode-se optar pela construção de novos protótipos, incrementando-o, avaliando novos riscos e replanejando o processo.
Scrum
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.
Ser ágil é: Entregar o que gera valor ao meu cliente; 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. Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Isto é, quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser equivalente à definição de pronto utilizada.
 Inspeção: Inspecionar de uma forma contínua tanto o trabalho bem como o processo pelo qual o time resolveu adotar. 
2-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.
3- 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.
4-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, que executa o trabalho propriamente dito. O Time consiste em desenvolvedores com todas as habilidades necessárias para transformar os requisitos do Product Owner em um pedaço potencialmente entregável do produto ao final da Sprint. Sendo Multi-disciplinar; Auto-organizado; Desenvolve produto com qualidade e valor para o cliente.
5- Sprint: Scrum emprega os eventos com duração fixa (timeboxes) 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. • O coração do Scrum é a Sprint, que é 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.
6- 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 Backlog do Produto restante ao longo do tempo de um plano de entrega.
D) Um Burndown de Sprint mede os itens do Backlog da Sprint restantes ao longo do tempo de uma Sprint.
7- 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. Durante a reunião, cada membro explica: o que ele realizou desde a última reunião diária; o que ele vai fazer antes da próxima reunião diária; 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: Sugere-se 8 horas de duração para um Sprint de 1 mês, dividida em duas partes. Nas primeiras 4 horas definir “O QUE” será feito na Sprint (Selected Product Backlog) e uma “META” - visão pela qual a sprint será orientada. Nas 4 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. 
Selected Product Backlog possui a Meta: Novo registro eletrônico de chamadas (diário de classe);
Estimativa: Cada tarefa deve ser estimada pelo time quanto tempo / pontos custará. Se o time optar por usar “points” é uma medida heurística em uma certa escala que pode ser definida pelo time: 1 a 10 points por exemplo.
Daily Meeting:
Durante a Sprint, todos os dias uma reunião de 15 minutos na qual cada membro do time deve responder: o que fez desde a última reunião; O que pretende fazer até a próxima; e se teve (está tendo) algum impedimento.
Finalização da Sprint: Ao final da Sprint, é realizada a Sprint Review. Essa é uma reunião de 4 horas para sprints de um mês. 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). A Sprint Review serve de INPUT para as próximas Sprint Plannings. 
Sprint Retrospective: Reunião com duração sugerida para 3 horas, cuja finalidade é 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.