Incrementos executáveis no RUP ( Rational Unified Process ) e validação de clientes

Pergunta surgida na lista RUP Brasil:

Na fase de construção do RUP ( Rational Unified Process ), cada iteração produz uma versão executável do sistema que adiciona funcionalidades ou melhora as funcionalidades disponibilizadas em uma iteração anterior? Ao fim da iteração, a versão executável do sistema é entregue ao cliente (para que ele possa fazer uso do sistema o mais rápido possível, bem como validar o produto e fornecer feedback sobre o sistema para iterações posteriores) ou o usuário só recebe o produto na fase de transição?Caso as duas abordagens sejam possíveis (entregar os incrementos já na fase de construção ou esperar pela fase de transição e entregar tudo), qual delas é a mais recomendável? E o que costuma ser feito na prática?

Minha resposta:

Cada iteração do RUP ( Rational Unified Process ) em princípio deve produzir algum software. Mesmo as iterações da fase de iniciação podem produzir protótipos de interface gráfica e/ou protótipos arquiteturais.

O software que é produzido a cada iteração pode ou não ser entregue. Se ele for entregue a cada iteração significa que você está adptando o RUP para um modelo chamado "Entrega Incremental". Vide um artigo de meu blog que mostra alguns possíveis Managing Iterative Software Development Projects de Bittner e Spence.

Caso de uso: Dicas para uma modelagem de casos de uso eficaz

Aí vão algumas dicas para a realização da modelagem de casos de uso. Lembrando que a técnica de caso de uso é utilizada extensamente hoje no Brasil para organizar e documentar requisitos de software.

Dicas:

- Lembre-se que o RUP é um processo iterativo. Portanto você não especifica todos os casos de uso no começo de um projeto de forma detalhada. Os casos de uso possuem um ciclo de vida e podem estar em diferentes estágios de maturidade. O ciclo de vida de um caso de uso é: descoberto, brevemente descrito, esboçado, completamente descrito.

- Quando identificar atores foque nos papéis que indivíduos podem realizar no sistema. Não pense somente em cargos ou funções da empresa.

- Para nomear um caso de uso tente usar a forma ativa. Lembre-se sempre de colocar um nome que demonstre os objetivos de negócio e o resultado final do caso de uso. Coloque o nome na forma verbo mais objeto. Exemplo: Saca Dinheiro, Emite Apólice de Seguro.

- Tome extremo cuidado com a decomposição funcional. A técnica de modelagem de casos de uso é diferente de um DFD! Os casos de uso focam nos resultados finais que geram valor para os atores. Não crie casos de uso que se referem apenas a passos granulares.

- Evite usar as seguintes palavras nas especificações de caso de uso: clicar, abrir, botão, pop-up, campo, janela, banco de dados. Essas palavras evocam definição da solução e da interface gráfica e o caso de uso deve ficar livre desses detalhes. Use palavras como: inicia, submete, formulário, informa, escolhe, especifica, seleciona, mostra.

- E a última e mais importante dica: haja o que houver (a não ser que você seja muito experiente com modelagem de casos de uso) evite usar include, extend e generalização de atores e casos de uso logo no início da modelagem de caso de uso. Esses elementos devem ser usados com parcimônia e com muito critério, pois senão podem levar o analista a cometer o pecado da decomposição funcional.