Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Os melhores documentos à venda: Trabalhos de alunos formados
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Comunidade
Peça ajuda à comunidade e tire suas dúvidas relacionadas ao estudo
Descubra as melhores universidades em seu país de acordo com os usuários da Docsity
Guias grátis
Baixe gratuitamente nossos guias de estudo, métodos para diminuir a ansiedade, dicas de TCC preparadas pelos professores da Docsity
Tem como objetivo desenvolver todas as competências durante a jornada do conhecimento.
Tipologia: Manuais, Projetos, Pesquisas
1 / 45
Esta página não é visível na pré-visualização
Não perca as partes importantes!
DESAFIO
ATIVIDADE
Material Teórico
Material Complementar
Situação-Problema 1
Situação-Problema 2
Situação-Problema 3
Problema em Foco
Atividade de Entrega
Olá, estudante!
Vamos iniciar a disciplina abordando os conceitos necessários para que você possa realizar a atividade através de cada situação-problema mais à frente.
A ideia do desenvolvimento deste conteúdo didático é fazer com que você possa se recordar do que você já aprendeu de forma a mantê-lo(a) focado no desafio e ter praticamente tudo do precisa para desenvolvê-lo num lugar só.
Você também encontrará leituras e material complementares que, sinceramente te alerto, serão essenciais no aprofundamento e desenvolvimento desse desafio. Muitas pessoas e discentes
1 / 8
Sem nenhuma das seções mencionadas, os requisitos começam a perder valor e sentido. Muitas vezes, quando sou chamado para dar consultoria, vejo times ágeis e especificações de sistemas como um “punhado de gente bem-intencionada que não consegue escrever ou muitas vezes ler o livro que ganharam”. Daí fica realmente difícil construir algo se nem entendemos o português que está escrito, não é mesmo?! Cada seção de análise traz muito para a mesa e muitas vezes são julgadas como uma "perda de tempo", porém, quando vamos codificar, fazem toda a diferença.
Olhe só:
Histórias de Usuários
Indica todos os cenários dos usuários envolvidos. O padrão mundial disso é:
Como ALGUM PAPEL, EU QUERO FAZER ALGUMA COISA, PARA QUE POSSA OBTER ALGUNS BENEFÍCIOS.
Ou seja,
Histórias de usuários;
Testes de Aceitação do Usuário;
Fluxo de Trabalho;
Detalhes dos Requisitos;
Wireframes.
Como GERENTE DE CONTAS A RECEBER, EU QUERO ter uma relação de
devedores por safra (meses vencidos 0d, 60, 90d, 180, 360d), PARA QUE
POSSA encaminhar às empresas de cobrança por seguimento e especialidade
delas.
Por exemplo,
Entendeu o que esperamos de você. Dezenas de cartões de história do usuário completos, claros, concisos, especificando a ação e o que se espera, incluindo para que serve.
Por favor, pense como um profissional, e você vai pensar, “mas sou aluno”, sim todos nós somos alunos, incluindo o autor desse material, mas atitude é tudo e é isso que queremos de você. Atitude positiva e construtiva!
As histórias de usuários são essenciais para definir exatamente quem fará o quê e por quais razões.
Fluxo de Trabalho
Isso deve incluir uma imagem das telas envolvidas (você fará isso na IHC e no protótipo das telas; riqueza de detalhes é fundamental). Os estados de erro (incluindo as telas de mensagem de erros) e as alterações de visualização com base na função devem ser documentados. Aqui, uma imagem vale mais que mil palavras, pois os detalhes do fluxo através do recurso podem ser bastante complexos, e é difícil explicar os detalhes na próxima seção (aqui, visão é tudo, me desculpem os sinestésicos e auditivos).
Segue uma lista de alguns para você usar na construção de sua aplicação. Eles ajudarão a explicar o sistema através de fluxos e vão apoiar no desenvolvimento. Suas versões demo vão permitir que você utilize pelo tempo desse desafio, tranquilamente, portanto, não “durma no ponto”. São todos amigáveis e não precisam de curso para usar. Use e abuse:
Mas afinal, que nível de detalhes você realmente precisa?
Minha experiência é que você precisa de artefatos de requisitos que sejam bons o suficiente para lhe dar esse entendimento e nada mais, portanto, pense simples, porém direto.
Veja esse exemplo de um caso de uso geral:
Nome do caso de uso geral (macro): Inscrever-se numa Disciplina
Curso Básico de Ação (trata-se de um caso de uso normal):
suficientes para que você se sinta confortável com os conceitos de domínio primário. (coloquei literatura de referência na sessão de Material Complementar e deve ser mandatoriamente lida, por gentileza);
Modelo de interface do usuário: para projetos intensivos de interface de usuário, você deve considerar o desenvolvimento de alguns esboços de tela, ou até mesmo um protótipo de interface de usuário. (conforme coloquei no tópico Wireframe desse material).
1 Aluno digita seu nome e número de aluno;
O sistema verifica se o aluno está qualificado para se inscrever no curso. Se não for elegível, o aluno será informado e o caso de uso será encerrado;
2
3 O sistema exibe uma lista de disciplinas do curso disponíveis (naquele mês);
4 O aluno escolhe uma disciplina ou decide não se inscrever;
O sistema valida se o aluno está qualificado para se inscrever naquela disciplina (pode haver disciplinas anteriores como pré-requisito). Se não for elegível, o aluno é convidado a escolher outra disciplina;
5
A descrição acima contém informações suficientes para você entender o que o caso de uso escrito faz e, na verdade, pode conter informações demais para este ponto do ciclo de vida, já que apenas o nome do caso de uso pode ser suficiente para que o time de desenvolvimento ou outra parte interessada entenda os fundamentos do que se pede.
Porém, podemos detalhar isso, num caso de uso mais aprofundado, a que chamaremos de caso de uso expandido.
Nome: Inscrever-se numa Disciplina
Identificador : #C 49
Descrição: Inscrever um aluno existente em uma disciplina existente desde que ele seja elegível.
Pré-condições: O aluno precisa estar regularmente matriculado e pagando pontualmente a Universidade.
6 O sistema valida se a disciplina se encaixa na trilha de aprendizagem do aluno;
7 O sistema calcula e exibe as taxas para que o aluno pague por aquela disciplina;
8 O aluno verifica o custo e indica que deseja se inscrever ou não;
9 O sistema inscreve o aluno na disciplina e cobra por ela;
O sistema imprime o comprovante de inscrição na disciplina quando o departamento de contas a receber der baixa no crédito.
10
Curso alternativo Alfa: O aluno não é elegível para se inscrever na disciplina.
Alfa3: O algoritmo determina que o aluno não está qualificado para se inscrever na disciplina.
Alfa4: O algoritmo informa ao aluno que ele não pode se inscrever.
Alfa5: O caso de uso termina.
Curso alternativo Beta: O aluno decide não se inscrever em uma disciplina disponível.
Beta5: O aluno visualiza a lista de disciplinas e não encontrou aquela em que ele deseja se inscrever.
11 O aluno indica que deseja se inscrever na disciplina;
12 O sistema inscreve o aluno na disciplina;
O sistema informa ao aluno que a inscrição foi bem-sucedida por meio da TELA68 - Resumo da Matrícula da Disciplina;
13
O sistema emite a fatura/boleto para o aluno pagar pela disciplina, de acordo com a regra de negócios RN71 - Faturar o aluno pela disciplina;
14
O sistema pergunta ao aluno se ele deseja um extrato impresso da matrícula que será disponibilizado após confirmação do pagamento;
15
16 O aluno indica que deseja uma declaração impressa;
O sistema imprime um pdf da declaração de inscrição TELA39 - Relatório de resumo de inscrição (acessível somente após confirmação do pagamento);
17
18 O caso de uso termina quando o aluno pega a declaração impressa.
Beta6: O caso de uso termina.
Curso alternativo Delta: O aluno não possui os pré-requisitos para alguma disciplina.
Delta6: O algoritmo determina que o aluno não é elegível para se inscrever na disciplina que ele escolheu.
Delta7: O algoritmo informa ao aluno que ele não possui os pré-requisitos.
Delta8: O algoritmo informa ao aluno sobre os pré-requisitos de que ele precisa para se tornar elegível para aquela disciplina.
Delta9: O caso de uso continua, e é desviado para a linha 4 do curso básico de ação deste mesmo caso de uso.
Bem, você percebeu como é importante ser analítico, crítico e lógico nessa nossa profissão. A clareza e declaração sem ambiguidade são fundamentais quando estamos elicitando requisitos e/ou desenvolvendo casos de uso.
Temos aqui a descrição do mesmo caso de uso totalmente documentado. Este é um exemplo maravilhoso de um caso de uso bem construído, mas apresenta muito mais detalhes do que você possivelmente precisa no primeiro momento.
Se você realmente precisa desse nível de detalhe e, na prática, raramente o faz, pode capturá-lo quando realmente precisar.
Comunicação é tudo e, nesse caso, é preciso feedback com a equipe, porque quanto mais tempo você passar sem pedir feedback para o cliente/usuário, maior será o perigo de se modelarem coisas que não refletem o que as partes interessadas realmente precisam.
Figura 1 – Diagrama de Caso de Uso macro de uma pizzaria
Recomendo que você crie, inicialmente, todos os diagramas de caso de uso, como o demonstrado acima, para os cartões de história do usuário como requisitos e verifique se não falta nada, se há lógica e complementaridade e principalmente se o “bicho tem cabeça tronco e membros”.
Tome cuidado porque há desafios no processo de levantar requisitos e convertê-los em artefatos. Abaixo listo alguns, mas dê muita atenção a todos eles para não cometer essas faltas.
Acesso limitado às partes interessadas do projeto (clientes e usuários);
Partes interessadas do projeto geograficamente dispersas (estão distantes em outras cidades, países ou regiões de difícil acesso. Nesse caso use reuniões remotas síncronas ou documentos como questionários);
As partes interessadas do projeto não sabem o que querem (mais comum do que parece, nesse caso, seja um guia ou “terapeuta”);
As partes interessadas do projeto mudam de ideia (negocie, eles fazem isso por causa do item anterior, eles vão descobrindo conforme pensam no próprio negócio, coisa que a rotina não deixa);
Prioridades conflitantes (saiba negociar com o sponsor , usuário ou product owner );
Muitos participantes do projeto desejam ter voz;
As partes interessadas do projeto prescrevem soluções de tecnologia (faça-os aterem- se à área de domínio deles, ou seja, negócios);
As partes interessadas do projeto são incapazes de ver além da situação atual (em tecnologia, chamamos a isso de paralisia de paradigma, crença limitante ou a popular);
As partes interessadas do projeto têm medo de ser fixadas (é uma questão cultural, às vezes, é necessário tempo e confiança, afinal, as partes interessadas devem ter responsabilidades pelo bom andamento do projeto);
As partes interessadas do projeto não entendem os artefatos de modelagem. (conte uma história, pessoas se encantam com histórias, a técnica de story telling veio para ficar);
Os desenvolvedores não entendem o domínio do problema (é importante os desenvolvedores estudarem o negócio em profundidade, não existe mais desenvolvedor “trancado numa sala”; eles precisam ter contato com a operação para amadurecerem e melhorarem seu entendimento sobre o negócio e sobre o mundo);
as dependências circulares entre pacotes são o problema pior e resultam em testes mais difíceis e um tempo de construção mais longo.
Modelos de domínio como diagramas de classe ou ER (entidade-relacionamento) / diagramas: Um Modelo de Domínio descreve a taxonomia de conceito do espaço do problema no qual o aplicativo funciona. No nível de comunicação humana, o vocabulário desse modelo de domínio deve se tornar a “linguagem ubíqua” usada em toda a comunidade de partes interessadas, incluindo usuários, especialistas de domínio, analistas de negócios, testadores e desenvolvedores. No nível de programação, o Modelo de Domínio também é essencial para selecionar nomes de construções de programação, como classes, dados, métodos e outras convenções. Uma grande parte da taxonomia conceitual (frequentemente chamada de “entidades”) é mapeada em uma estrutura de dados persistente no banco de dados e geralmente tem uma vida útil mais longa do que o próprio aplicativo. Normalmente, o modelo de domínio (ou entidades) reside no pacote “M” na arquitetura lógica se você escolher uma arquitetura “MVC” para sua aplicação. Um diagrama ER é mais adequado para expressar um modelo de domínio porque está vinculado mais diretamente a bancos de dados relacionais. Observe também que esse modelo de domínio cresce com o tempo. Como o domínio está no cerne da compreensão e comunicação do problema, manter os modelos de domínio em crescimento na equipe (ou mais amplo, na comunidade) é muito importante. ”
Figura 2 – Exemplo de Classes levantadas e ao lado Diagrama de Classes Completo
Backlog de Produto
Para recordarmos, um backlog de produto é uma lista priorizada de entregas e isso inclui novos recursos, que devem ser implementados como parte de um projeto ou desenvolvimento de produto de software. É um artefato de tomada de decisão que ajuda a estimar, refinar e priorizar tudo o que você pode querer concluir no futuro.
Isso ajuda a garantir que a equipe esteja trabalhando nos recursos mais importantes e valiosos, corrigindo os bugs mais importantes ou fazendo outro trabalho importante e crítico para o desenvolvimento do produto.
O backlog , portanto, é extremamente útil em situações em que você não consegue fazer tudo o que está sendo solicitado, ou em contextos em que mesmo uma pequena quantidade de planejamento ajudará muito. Muitos pensam nesta “lista” como uma lista de tarefas pendentes e a definem exatamente dessa forma, como uma lista de coisas que você deve fazer para entregar seu produto
Sprint Backlog
É o conjunto de itens que uma equipe multifuncional de produtos seleciona de seu product backlog para trabalhar durante o próximo sprint.
Normalmente, a equipe concorda com esses itens durante a sessão de planejamento do sprint. Na verdade, o backlog do sprint representa a principal saída do planejamento desse.
Se a equipe não for capaz de completar, ou mesmo começar certos itens do sprint backlog até o final do sprint , a equipe pode escolher adicionar esses trabalhos inacabados ao próximo sprint backlog , caso eles ainda forem considerados de alta prioridade, ou para o backlog do produto.
De acordo com a estrutura do scrum , toda a equipe ágil, incluindo o scrum master, o product owner e o time de desenvolvimento, compartilhará a propriedade do sprint backlog. Isso ocorre porque todos os membros da equipe trarão conhecimentos e percepções exclusivas para o projeto no início de cada sprint.
Sprint backlogs são geralmente planilhas embutidas, mas também podem ser desenvolvidas e mantidas em ferramentas de software projetadas para gerenciamento ágil de projetos. Como essas listas incluem apenas trabalhos que podem ser concluídos em um curto espaço de tempo, a que chamamos de SPRINT , que dura de 2 a 4 semanas, os backlogs de sprint costumam ser muito simples.
Diagrama de Atividades
Usamos Diagramas de Atividades para ilustrar o fluxo de controle em um sistema e fazer referência às etapas envolvidas na execução de um caso de uso. Modelamos atividades sequenciais e concorrentes usando diagramas de atividades. Portanto, basicamente representamos os fluxos de trabalho visualmente usando um diagrama de atividades. Um diagrama de atividades enfoca a condição do fluxo e a sequência em que ele acontece. Descrevemos ou representamos o que causa um determinado evento usando um diagrama de atividades.
Um diagrama de atividades é usado por desenvolvedores para entender o fluxo de programas em alto nível. Também permite que eles descubram restrições e condições que causam eventos específicos. Geralmente usamos o diagrama e a documentação textual para tornar a descrição do nosso sistema o mais clara possível.
TDD E Testes
Testes de Aceitação do Usuário: Eles devem incluir todos os cenários descritos nas histórias de usuário. Eles não devem ser muito detalhados (eles não precisam mencionar telas específicas ou uma lista completa de ações para executar as etapas). Devem ler:
DADA essa condição 1 e condição 2…. QUANDO eu faço a etapa 1 e a etapa 2… ENTÃO, resultado desejado 1, resultado desejado 2….
Eles definem um conjunto de cenários reais que um testador pode percorrer para garantir que o recurso está completo.
Esses não são scripts de teste detalhados, pois o objetivo deles é transmitir um conjunto de testes que todos os envolvidos podem percorrer para entender como o recurso funcionará.
Vamos conhecer um pouco de TDD – Desenvolvimento Orientado a Testes. É uma abordagem evolutiva do desenvolvimento que requer disciplina e habilidades significativas e, claro, boas ferramentas.
A primeira etapa é adicionar rapidamente um teste, ou seja, um código básico o suficiente para falhar.
Em seguida, você executa seus testes, frequentemente, o conjunto de testes completo, ainda que, por uma questão de velocidade, você possa decidir executar apenas um subconjunto, para garantir que o novo teste de fato falhe.
