[quote=Alexandro.Almeida][quote=MarceloAraujo]
Qual a vantagem de se representar fluxo de informação de forma textual?
Criar uma história simples e rabiscar um protótipo não seria mais direto e de fácil entendimento?
[/quote]
Porque alguns clientes pedem que os casos de uso sejam entregues como parte da documentação do sistema*, e muitos deles não iram aceitar este “rascunhos”.
Quando o caso de uso tem a finalidade de ser apenas uma ferramenta durante o desenvolvimento do sistema, os rascunhos em papel e os diagramas (em papel ou em alguma ferramenta) talvez sejam mais uteis.
*Este é um ponto iteressante, caso de uso é documentação do sistema ou apenas uma ferramenta usada na construção do sistema?
[/quote]
Entendo esse ponto de vista, já passei por projetos exatamente assim, onde a área de TI do cliente obrigava a entrega de determinados documentos. Mas a questão que quero levantar é relativa a benefício. O que faz uma pessoa, seja cliente ou desenvolvedor, preferir representar fluxo de informação de forma textual em casos de uso formais? Não seria falta de conhecimento sobre técnicas mais ágeis para o mesmo objetivo? Ou então aquela falsa sensação de segurança que um documento mais formal acaba passando pra gerentes acostumados com desenvolvimento em cascata?
Mas de qualquer forma, acredito que os casos de uso com seu fluxo de informação de forma textual seja mais util nos casos em que não temos a oportunidade de termos o cliente ou um bom PO dentro do projeto.
Shoes, eu não afirmei que equipes ágeis não aplicam esta análise, para clarificar, estou falando sobre as literaturas e não como aplicamos no mercado. O fato é que essa análise de negócio não é escopo de XP e Scrum que são as práticas ágeis mais utilizadas (elas personificam essas práticas em papéis). O Kent Beck fala sobre isso no XP? O Ken Schwaber fala sobre isso no Scrum? É muito superficial certo? Quando usamos essas metodologias sem um bom Product Owner e sem cliente presente geralmente temos que adaptar muita coisa pra metodologia funcionar.
Geralmente vejo analise do negócio como estabelecer o problema, os objetivos de ROI, escopo high-level. IMHO não vejo que fazer isso com o barco andando é uma boa idéia. Isso é a visão. Acho uma boa prática documentar isso nem que seja 3 parágrafos. Nos meus projetos reais mesmo com cliente presente eu estabeleço a visão no papel.
Caso de uso não modela telas. Isso é um erro muito comum. Extend e Include são práticas para reutilizar comportamentos. Não fui muito radical não… geralmente quando vejo um include e um extend num diagrama a chance é de 99% de estar errado. O Martin Fowler diz “esqueça include e extend”, eu só concordo com ele.
Este caso de uso reserva um quarto para um cliente aprovado. Deve-se levar em consideração se o quarto está disponível para o período da reserva. Clientes não aprovados não podem reservar. Quando a reserva é efetivada um e-mail é enviado ao cliente.
Mais uma vez… casos de uso não precisam ser formais, não precisam constar em diagramas, não precisam ser descritos na forma de fluxos, podem até estar em Index Cards pra ficar mais na moda. 8)
[quote=rodrigoy][quote=Alexandro.Almeida]
Onde eu aplico os extends e includes são em telas do tipo “Painel de controle” onde a partir de uma unica tela eu tenho à disposição muitas funcionalidades distintas. Seria muito complicado neste caso colocar tudo em um unico caso de uso.
PS: Você não foi muito radical com o “Esqueça inclusão e extensão”? Ou você estava se referindo apenas nos casos em que eles são usados com a finalidade de decomposição funcional?
[/quote]
Caso de uso não modela telas. Isso é um erro muito comum. Extend e Include são práticas para reutilizar comportamentos. Não fui muito radical não… geralmente quando vejo um include e um extend num diagrama a chance é de 99% de estar errado. O Martin Fowler diz “esqueça include e extend”, eu só concordo com ele.
[/quote]
Entendo … talvez seja este erro recorrente de modelar baseado em tela que gere estes includes e extends mesmo. Vou ter que pensar mais um pouco no assunto.
Mas e neste cenário, de um caso de uso com 85% das funcionalidade do sistema, como dividi-lo em entregaveis? Por cenário? Não ficaria dificil de gerenciar? Ou não divido, entrego “85%” das funcionalidades sistema de uma única vez e depois os outros 15%?
A primeira etapa de uma jornada é saber onde vc quer chegar. Mas quem diz isso?
Não sou nenhum estudioso do assunto, mas já ouvi falar de um “cartão de visão”, que tem como característica ser sucinto, mas que tem o objetivo de fornecer uma visão conceitual do sistema para ambas as partes, cliente e desenvolvedor.
A grande diferença entre o documento de visão tipo (UP, RUP e semelhantes), é que o cartão é escrito pelo cliente e ele tem o direito de não ter que conceituar todo o sistema desde o início.
Mas se vc faz isso pelo cliente não está deixando de ser ágil, é verdade, mas está mas distante da visão dele, o especialista.
[quote=rodrigoy][quote=MarceloAraujo]
Qual a vantagem de se representar fluxo de informação de forma textual?
Criar uma história simples e rabiscar um protótipo não seria mais direto e de fácil entendimento?
[/quote]
Nada impediria você fazer o seguinte:
Caso de Uso: Reservar Quartos
Ator: Atendente
Este caso de uso reserva um quarto para um cliente aprovado. Deve-se levar em consideração se o quarto está disponível para o período da reserva. Clientes não aprovados não podem reservar. Quando a reserva é efetivada um e-mail é enviado ao cliente.
Mais uma vez… casos de uso não precisam ser formais, não precisam constar em diagramas, não precisam ser descritos na forma de fluxos, podem até estar em Index Cards pra ficar mais na moda. 8)
(sim… isso foi uma provocação gratuita) [/quote]
Mas desta forma não são mais casos de uso, seria melhor chama-lo de história e pronto!
Histórias e caso de uso tem objetivos em comum mas não são iguais.
Concordo, nesse caso ele funciona mas como um manual de consulta para visualizar algo, do que um mecanismo de projeção semântico-lógico-conceitual (Ou coisa parecida :D).
[quote=rodrigoy][quote=MarceloAraujo]
Qual a vantagem de se representar fluxo de informação de forma textual?
Criar uma história simples e rabiscar um protótipo não seria mais direto e de fácil entendimento?
[/quote]
Nada impediria você fazer o seguinte:
Caso de Uso: Reservar Quartos
Ator: Atendente
Este caso de uso reserva um quarto para um cliente aprovado. Deve-se levar em consideração se o quarto está disponível para o período da reserva. Clientes não aprovados não podem reservar. Quando a reserva é efetivada um e-mail é enviado ao cliente.
Mais uma vez… casos de uso não precisam ser formais, não precisam constar em diagramas, não precisam ser descritos na forma de fluxos, podem até estar em Index Cards pra ficar mais na moda. 8)
(sim… isso foi uma provocação gratuita) [/quote]
Pois é. Caso de uso não precisa disso, não precisa daquilo. Eles são quase tão customizáveis quanto o RUP
Minha dúvida então fica sendo com o caso de uso feito em um modelo mais formal, cheio de fluxos, idas e vindas. Que é o modelo mais comum de ser usado no mercado, descrito em artigos de revista e em cursos on-line por aí 8)
Faça o meu curso on-line grátis no site da Aspercom: www.aspercom.com.br
(basta se cadastrar no site)
Sim… quebra por cenário e ficará praticamente igual a Stories. No RUP é assim. No MSF é assim. No EssUP é assim. No OpenUP é assim.
Me diga a literatura que diz que casos de uso DEVEM ser descritos na forma de fluxos. Pelo que me lembro Jacobson, Cockburn e Larman dizem que eles podem ser descritos de forma sucinta.
Casos de uso com fluxos definidos só te ajudam quando você quer fazer o desenho da iteração com diagramas de sequência a lá RUP.
[quote=rodrigoy][quote=sergiotaborda]
i.e. em lado algum vi escrito que Agile /Stories significa ignorar a fase de levantamento. Como se relacionam estas duas coisas: levantamento de requisitos e stories ?
[/quote]
Nos métodos ágeis é muito comum que o analista de negócio, o cliente ou Product Owner direcione a equipe através de Stories. Isso é, uma grande diferença entre Scrum, XP e RUP. Os dois primeiros não são tão focados em análise do negócio e de requisitos: as coisas iniciam com Stories a serem construídas. Isso funciona perfeitamente com um cliente interessado, presente, bem resolvido e capaz de controlar escopo, mas você perde em documentação do negócio (não há FIT, RSpec, TDD que documente o negócio, alguém discorda? dá pra escrever um documento de visão em JUnit).
O RUP é mais completo nesse aspecto. Abrange Análise de Negócio, se aprofunda em requisitos e possui um conjunto de práticas e modelo de artefatos pra isso.
Não é que stories ignoram levantamento de requisitos, basicamente muito dessa responsabilidade é repassada para o Prod. Owner, Cliente Presente ou um Analista de Negócios da equipe.[/quote]
Bom, se entendi o que escreveu :
Independentemente da fonte e da metodologia usada existe a necessidade de um levantamento de requisitos.
Se esse levantamento é documentado ou não, e se sim, como é uma escolha à parte. O ponto é que a lista de requisitos existe, nem que seja na cabeça de alguém (memória volatil).
Stories são uma ferramenta da equipe de desenvolvimento ( que exclui o analista, o gerente e o cliente) e não uma forma de linguagem comum embora possa ser utilizada pelo analista para se fazer entender pela equipe. Aqui dá-me a impressão que Stories são artificios de contole de desenvolvimento e não de controle de projeto ( que algo mais lato porque inclui custos, tempos etc…)
Sim ?
Estou imaginando o analista aparecer com uma lista de requisitos e isso virar uma lista de stories não necessáriamente 1 para 1. Ou seja, fazer o breakdown dos requisitos em algo que se possa programar. Os testes unitários atuaram sobre as stories sendo que são a unidade mínima possível de programar e por conseqüência espera-se que os requisitos estão implementados corretamente. Ou seja
1 Requitiso -> N Stories -> T testes por Storie = NT testes por requisito.
Se todos os NT testes passarem isso signfiicaria ( se os testes forem bem feitos etc) que o requisito está implementado corretamente.
E isso ?
É que se for , então Casos de Uso são coisas que nada têm a ver com Stories, já que têm um proposito completamente diferente e na prática, se quiser documentar as coisas “no minimo detalhes” teria que fazer ambos no projeto. Só que o casos são feitos pelo analista enquanto stories pela equipe de desenvolvimento ( que não inclui o analista). É por ai ?
Por outro lado, se eu precisar orçar o projeto Stories não me adiantam já que eu preciso conhcer o escopo “todo” e portanto preciso da lista de requisitos. Por outro lado, o esforço vai ser ditado pela velocidade da implementação das stories. Como encaixam estes outras coisas : stories, casos de uso, lista de requisitos e orçamento ?
Fiz hoje mesmo e gostei, parabéns pelo trabalho.
Sua explicação de extends e includes foi aplicável em muitos casos onde eu já os usava, em outros realmete estam sendo usados de forma incorreta. Estou pensando em uma revisão dos conceitos usados aqui para o uso de extends e includes
[quote=rodrigoy]
Me diga a literatura que diz que casos de uso DEVEM ser descritos na forma de fluxos. Pelo que me lembro Jacobson, Cockburn e Larman dizem que eles podem ser descritos de forma sucinta.
Casos de uso com fluxos definidos só te ajudam quando você quer fazer o desenho da iteração com diagramas de sequência a lá RUP.[/quote]
Rodrigo, o caso não é a literatura que fala assim e a que fala assado, é a forma como o “mercado” entende como caso de uso.
Concordo que para que o caso de uso atinja o objetivo de auxiliar o desenvolvimento do software, ou mesmo documenta-lo de alguma forma, ele não precisa ser tão formal. Pode ser como uma história, acrescento uns diagramas, rascunhos e o que mais for útil.
Mas desta maneira ele não é visto como caso de uso por 90% das pessoas por ai. O fato é que eu tenho que fazer um CdU da maneira formal, e já que tenho que faze-lo assim, quero faze-lo de uma forma que seja util para o desenvolvimento e seja aceito pelo cliente. Acho que o seu curso online da uma grande ajuda neste trabalho de conciliar estes dois mundo.
Stories sao escritas preferencialmente pelo cliente (ou quem estiver fazendo o seu papel). Desenvolvedores podem participar (eu acho que devem) porque muitas vezes lidamos com analistas que nao sao muito especialistas no negocio e neste caso sobra para os desenvolvedores a tarefa nao de escrever a estoria mas guiar a discussao para falar em termos de negocio e nao fluxos de tela. Acho que essa e a questao , tentar resolver o problema dos requisitos na forma de CRUD com aperta o botao aqui e entao mostra na tabela ali.
Na UML muita gente tem dúvida como e quando usar composição e agregação (Losango aberto ou fechado?).
Está me parecendo o mesmo em relação aos Use Cases (UC) e User Stories (US). Em um ambiente ágil um caso de uso não deve ser escrito pelo desenvolvedor e sim pelo cliente. Mas ele não sabe com escrever, então a descrição textual vai ter um aspecto semelhante a uma user story, nisso os dois são iguais US e UC. Mas para por aí, por que depois do primeiro texto para esse caso de uso escrito pelo cliente (Reservar Apartamento, por exemplo) ele vai naturalmente “quebrar em outras coisas conceituais”, aí é que entram as diferenças de técnicas.
Então, Devo agrupar ou dispersar?
Esse é básicamente o “Q” da questão, levando em consideração que o cliente escreve os requisitos. UC e US são veículos de requisitos, ou seja, são iguais nesse aspecto, mas a natureza e conceitos envolvidos em cada um levam a pesamentos diferentes.
Uma user story é a menor quantidade de informações (uma etapa) necessárias para que o cliente defina um caminho através de um sistema. Um caso de uso é uma descrição completa (textual, de simples texto a formalidades) de uma seqüência de interações; ele não é normalmente um passo ou atividade individual em um processo. Por exemplo: Imprimir Recibo não é um caso de uso em si, mas uma subseqüência dentro do caso de uso Comprar Produto.
Um caso de uso agrupa todas as seqüências específicas de ações e interações entre atores e o sistema em forma de cenários, regras de negócio, requisito de interface, requisitos de desempenho, etc (seja sob referências ou não). Ele agrupa coisas, e um cliente não agrupa isso, um cliente pede. Quem agrupa, organiza, molda, etc é o desenvolvedor. Se vc quiser pode separar um documento para regras de negócio, outro para isso e aquilo, mas o cliente não faz isso, o cliente pede, requisita. Dentre essas requisições pode até pedir documentação de software, mas esse pedido não vai sair na escrita de um caso de uso vai?
Em resumo, o enfoque ao utilizar-se de casos de uso e seus relacionamentos é identificar os objetivos do usuário, em vez de funções do sistema. O caso de uso é sim uma visão externa do sistema mas uma visa externa de um objetivo maior. O usuário pode escrever a descrição de um caso de uso da forma que puder (grau de formalidade), mas a organização de cenários (Na forma que conhecemos) ele jamais fará, a não ser que seja treinado para isso. Já um diagrama de caso de uso, que representa os objetivos do sistema ele gostaria de ver. Note que são coisas diferentes diagramas e descrições do caso de uso.
Ao passo que um User Story também se concentra no comportamento externo do sistema, mas ela é uma unidade informação menor, menos arbitrária e “É escrita pelo cliente” ou pelo menos, uma transcrição tão fiel quanto possível de uma história dele. A descoberta de user stories é feita constantemente, dede um conjunto inicial, criado no início do projeto, que seria na forma de “levantamento de requisitos” do sistema, até o fim do projeto. É um processo constante, derivativo e refinador, onde à medida que novas expectativas de funcionalidades existentes são descobertas novas user stories são criadas para refinar tais descobertas.
Portanto pode sim usar as duas, mas vc escolhe como. Eu uso uma mistura onde utilizo user stories para incrementar e de fato desenvolver e vou documentando o sistema com os casos de uso, simples descritivos, faço isso porque tem um agrupamento de funcionalidades que me ajudam na rastreabilidade das mesmas. Quando implemento um ou mais objetivos me comunico com o cliente de forma gráfica (diagramas de caso de usos e atividades e até classes) e obtenho seu feedback em forma de Use Stories.
Minha realidade:trabalho desenvolvendo internamente soluções para uma empresa de negócios financeiros, ou melhor, para um cliente fixo. Por isso estou sempre contando com o cliente :roll:
É isso, essa é apenas uma resposta a pergunta do tópico. :lol:
[quote=MarceloAraujo]
Pois é. Caso de uso não precisa disso, não precisa daquilo. Eles são quase tão customizáveis quanto o RUP
Minha dúvida então fica sendo com o caso de uso feito em um modelo mais formal, cheio de fluxos, idas e vindas. Que é o modelo mais comum de ser usado no mercado, descrito em artigos de revista e em cursos on-line por aí 8) [/quote]
Marcelo… você me superou em provocação gratuita. :x
Toda abordagem tem usa essência, sua invariante… o importante é entender o conceito, o retorno. E escolher a abordagem em função do retorno que você precisa.
Fluxos do UC ajuda levantar os dados/conceitos da interação ator/sistema. Ajuda também na organização dos cenários no UC, pois permite referenciar/relacionar fluxos alternativos.
[quote=rodrigoy][quote=MarceloAraujo]
Pois é. Caso de uso não precisa disso, não precisa daquilo. Eles são quase tão customizáveis quanto o RUP
Minha dúvida então fica sendo com o caso de uso feito em um modelo mais formal, cheio de fluxos, idas e vindas. Que é o modelo mais comum de ser usado no mercado, descrito em artigos de revista e em cursos on-line por aí 8) [/quote]
Marcelo… você me superou em provocação gratuita. :x [/quote]
ok ok… pago uma rodada caso você faça um Agile Beer Drinking aqui no Rio
