Aprendendo uma coisa nova todos os dias
Uma tabela de decisão é uma excelente ferramenta a ser usada tanto em testes quanto no gerenciamento de requisitos. Essencialmente, é um exercício estruturado para formular requisitos quando se trata de regras comerciais complexas. Em uma tabela de decisão, a lógica empresarial está bem dividida em condições, ações (decisões) e regras para representar os vários componentes que formam a lógica empresarial.
Continue reading
Sempre nos deparamos com estes termos no desenvolvimento de software. Às vezes, as pessoas têm um recurso de software – caso de necessidade/uso, itens de backlog …. Qual é a convenção das pessoas do software para usar isso ou qual?
Continue reading
No desenvolvimento de software, a “estimativa” usual inclui uma avaliação quantitativa do trabalho necessário para realizar uma determinada tarefa de desenvolvimento; isto é normalmente expresso em termos de duração (hora / dia) ou unidade estimada (ponto da história). O objetivo é consolidar algumas dessas estimativas individuais a fim de obter uma indicação da duração total, trabalho ou custo do projeto de software.
Continue reading
Um diagrama de caso de uso UML é a principal forma de requisitos de sistema/software para um novo programa de software em desenvolvimento. Os casos de uso especificam o comportamento esperado (o quê) de um sistema, e não o método exato de fazê-lo acontecer (como). Um conjunto completo de casos de uso especifica todas as diferentes maneiras de usar o sistema e, portanto, define todo o comportamento exigido do sistema, delimitando o escopo do sistema.
Continue reading
Um caso de uso é uma descrição escrita de como um usuário executa uma tarefa em seu sistema. Ele delineia o comportamento do sistema da perspectiva do usuário ao responder a uma solicitação. Cada caso de uso é representado como uma seqüência de passos simples, começando com o objetivo do usuário e terminando quando o objetivo é alcançado.
Continue reading
Usar o Case 2.0 é uma abordagem escalável e ágil que usa casos de uso para capturar os requisitos e impulsionar o desenvolvimento incremental de um sistema para cumpri-los. Ele ajuda a entender como o sistema será usado e o conduz através do desenvolvimento de um sistema apropriado para dar suporte aos usuários.
Continue reading
Um diagrama de caso de uso modela diferentes tipos de usuários interagem com o sistema para resolver um problema. Como tal, ele descreve os objetivos dos usuários, as interações entre os usuários e o sistema e o comportamento necessário do sistema para satisfazer esses objetivos. Os casos de uso definem as interações entre os atores externos e o sistema para atingir determinados objetivos. Um diagrama de caso de uso contém quatro componentes principais
Continue reading
No verão de 2011, Ken Schwaber e Jeff Sutherland revisaram seu Guia Scrum. Nele, eles removeram um comportamento há muito estabelecido conhecido pela Scrum, que é o compromisso da equipe com o proprietário do produto e com os clientes. O compromisso foi substituído pela previsão. Eles dizem que as equipes podem prever seu trabalho, mas não se comprometem com ele.
Continue reading
A definição de Done (DoD) é uma lista de requisitos que uma história de usuário deve cumprir para que a equipe a chame de completa. Enquanto os Critérios de Aceitação de uma História de Usuário consistem em um conjunto de Cenários de Teste que devem ser cumpridos para confirmar que o software está funcionando como esperado.
Continue reading
Cada sprint termina com uma reunião de revisão de sprint em duas partes. Tal reunião começa com uma revisão e demonstração do cliente e termina com a retrospectiva da equipe. Ambos os componentes ocorrem no último dia do sprint. A Revisão do Sprint concentra-se na “inspeção” e “adaptação” do incremento (Potencialmente expedível), enquanto a Retrospectiva do Sprint dá mais foco na “inspeção” e “adaptação” do processo do sprint.
Continue reading