Aprendendo uma coisa nova todos os dias
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
O Open Group criou o ArchiMate como uma linguagem de modelagem aberta e independente para a arquitetura empresarial (EA). A norma fornece uma notação que permite aos arquitetos de empresas descrever, analisar e visualizar as relações entre os domínios de negócios de forma inequívoca. ArchiMate permite a criação de modelos totalmente integrados da EA da organização, a motivação para ela, e os programas, projetos e caminhos de migração para implementá-la.
Continue reading
O INVEST como um lembrete das características de um Produto de boa qualidade Item de Backlog (PBI) (ou histórias de usuários) comumente escrito em formato de história de usuário. Mas quais são as características de uma boa história de usuário? A sigla “INVEST” pode lembrá-lo de que boas histórias devem ser
Continue reading
Se você já tentou criar o Visio Flowchart® da MS, você sabe como é difícil. Você pode começar com algumas ferramentas básicas, se precisar mudar alguma coisa – mover formas, apagar formas ou adicionar novas formas – é muito difícil! Você sabe o que quero dizer. O Visual Paradigm Online automatiza todas as suas tarefas complexas com apenas alguns cliques.
Continue reading