Escrever casos de uso parece coisa simples, mas ao não se concentrar nos princípios fundamentais que orientam a elaboração de um bom caso de uso, acaba-se cometendo erros. Conheça os sete erros mais comuns:

1. Escrever requisitos funcionais em vez de cenários de utilização

Os casos de uso são escritos em termos sobre o que o sistema deve fazer. Cenários de uso descrevem ações dos usuários e as respostas obtidas do sistema.
É importante que o texto do caso de uso permita claramente identificar como o sistema realizará um determinado comportamento. Deve-se manter uma clara distinção entre as descrições das ações (voz ativa) e os requisitos funcionais (voz passiva)
Exemplos:

Caso de uso: Editar conteúdo do carrinho de compras
(incorreto) – Fluxo Básico – Se o cliente modificar a quantidade de um item no carrinho de compras, e pressionar o botão de atualização, o sistema irá armazenar a nova quantidade, e exibir a novo custo para o item selecionado.
(correto) – Fluxo Básico – Na página do carrinho de compras, o cliente modifica a quantidade de um item e então pressiona o botão atualizar. O sistema armazena a nova quantidade e exibe o novo custo para o item selecionado.

2. Descrever atributos e métodos em vez de cenários de uso

Os casos de uso não devem conter muitos detalhes de telas e também estar livres de detalhes de campos de telas. Se você, por exemplo, estiver escrevendo um caso de uso e estiver relacionando vários campos da tela no texto de caso de uso, pare! O objetivo aqui é descrever o que o sistema deverá fazer, e não como será feito.
Exemplos:

Caso de uso: Processar Pedido

(incorreto) O operador do estoque certifica-se que os itens  relacionados no pedido conferem com o itens físicos. O operador passa o código de barras na leitora da estação. O sistema executa o método mudança de estado do pedido, para mudar o pedido para o estado de atendido, e então chama o método alterar quantidade em estoque, para cada um dos itens do pedido
(correto) O operador do estoque certifica-se que os itens relacionados no pedido conferem com o itens físicos. O operador passa o código de barras na leitora da estação. O sistema muda o estado do pedido, para atendido, e então atualiza a  quantidade em estoque, para cada um dos itens do pedido

   3. Escrever casos de uso de forma muito resumida

O objetivo de um caso de uso é descrever todos os detalhes da ação do usuário e da resposta do sistema. É melhor que o texto seja o mais completo possível, do que ser um texto muito resumido que omite esses detalhes
Deve-se lembrar também que os casos de uso servirão para a elaboração do manual do usuário. Assim é melhor pecar por excesso do que por falta de detalhes no manual do usuário.
Exemplos:

Caso de uso: Criar conta do cliente

(incorreto) O cliente entra com a informação solicitada. O sistema valida as informações e cria uma nova conta para o usuário
(correto) O cliente entra com o seu nome, e-mail, e a senha (duas vezes) e então pressiona o botão criar conta. O sistema certifica que o cliente forneceu dados válidos e então cria uma nova conta usando esses dados. O sistema conduz o cliente à página principal do sistema.

  4. Desconectar-se completamente da interface do usuário

Um dos fundamentos da notação de casos de uso, é que os desenvolvedores concordem em desenhar o sistema sob o ponto de vista dos usuários. Não é possível praticar isso, sem ser especifico as quais ações serão realizadas pelos usuários nas respectivas telas.

Entretanto não é necessário entrar em detalhes de campos ou detalhes cosméticos sobre a tela (trabalho do protótipo). O importante é citar pontos da interface que permite ao usuário dizer para o sistema fazer algo.

Exemplos:

Caso de uso: Procurar item

(incorreto) O cliente digita o nome do animal e então submete uma requisição de pesquisa. O sistema recupera detalhes importantes sobre cada animal e então exibe uma lista de animais.
(correto) O cliente digita o nome do animal na página de pesquisa e então pressiona o botão procurar. O sistema recupera detalhes importantes sobre cada animal, então o sistema exibe uma lista de animais em página de resultados da pesquisa.

  5. Evitar explicitar o nome dos objetos de fronteira

Objetos de fronteira são objetos que os atores irão interagir. Exemplos – janelas, caixa de diálogos, menus, etc. Na diretriz de detalhar a navegação do usuário, é necessário dar nomes aos objetos de fronteira no texto do caso de uso

Os nomes desses objetos serão posteriormente úteis nas próximas fases do desenho do sistema

Exemplos:

Caso de uso: Acompanhar pedidos recentes

(incorreto) O sistema recupera e exibe os pedidos que o cliente solicitou nos últimos 30 dias. O cliente solicita detalhamento de um pedido. O sistema recupera e exibe o conteúdo do pedido, apenas no modo de leitura. O cliente retorna para a lista de pedidos, quando ele finalizou a leitura dos detalhes do seu pedido.
(correto) O sistema recupera e exibe os pedidos que o cliente solicitou nos últimos 30 dias, e exibe esses pedidos na página de acompanhamento de pedidos. Cada registro possui um numero de pedido (em forma de link) O cliente seleciona um link. O sistema recupera e exibe o conteúdo do pedido, apenas no modo de leitura na página de detalhamento do pedido. O cliente pressiona OK e retorna para a página de acompanhamento de pedido.

  6. Descrever apenas as interações do usuário e esquecer as respostas do sistema

A narrativa de um caso de uso deve ser orientada por respostas a eventos, ou seja, “O sistema faz isto quando o usuário faz aquilo” O caso de uso deve capturar o que ocorre em decorrência a ação do ator: criação de registros em tabelas, validação de entrada de dados do usuário, mensagens de erros, etc.

O texto do caso de uso deve descrever os dois lados do diálogo entre o ator e o sistema, e todo o comportamento que se está buscando descobrir, ocorre do lado do sistema neste diálogo. Deixar a resposta do sistema de fora, significa ignorar o comportamento do sistema

Exemplos:

Caso de uso: Editar conteúdo do carrinho de compras

(incorreto) Na página do carrinho de compras, o cliente modifica a quantidade de um item do carrinho de compras, e então pressiona o botão de atualização. Então o cliente pressiona o botão de continuar comprando

(correto) Na página do carrinho de compras, o cliente modifica a quantidade de um item do carrinho de compras, e então pressiona o botão de atualização. O sistema armazena a nova quantidade, calcula e exibe o novo custo para tal item. Então o cliente pressiona o botão de continuar comprando.

  7.Omitir texto para os fluxos alternativos

Apesar dos fluxos básico serem mais fáceis de se identificar, não significa que se deva deixar de fora os fluxos alternativos. Geralmente os fluxos alternativos importantes só são descobertos na fase de codificação e depuração.

Nesta ocasião, o programador tende a encontrar uma solução que lhe seja mais conveniente, o que não é saudável para o projeto

Exemplos:

Caso de uso: efetuar logon

(incorreto) O cliente entra com a sua identificação e senha, e então o cliente pressiona o botão de log-in. O sistema conduz o cliente para a página inicial.
(correto) O cliente entra com a sua identificação e senha, e então o cliente pressiona o botão de log-in. O sistema valida as informações contra os dados da conta do usuário e então conduz o cliente para a página inicial

  A comunidade de software livre tem ao longo dos anos influenciado a indústria de software tradicional, no sentido de forçá-la a oferecer alguma versão dos seus produtos para uso sem custo. Empresas grandes como a IBM já adotaram essa abordagem de ofertar uma versão livre de alguns de seus softwares pagos.
Para a modelagem de software utilizando UML tenho usado para fins acadêmicos o Visual Paradigm Community Edition, que é uma versão sem custo e com algumas limitações em relação à versão paga, como por exemplo, só poder criar um diagrama UML de cada tipo sem que apareça a marca d’água da empresa nos diagramas. Uma outra restrição é a de não ter uma funcionalidade que permita o desenho da interface gráfica (elaboração de protótipos de telas)

Essa versão suporta todos os diagramas da UML 2.1, permite a descrição detalhada de requisitos, análise textual dos requisitos para identificação de classes, análise através de cartões CRC e diversas outras funcionalidades relacionadas à etapa de projeto de software.

O Visual Paradigm Community Edition pode ser obtido a partir do endereço http://www.visual-paradigm.com/product/vpuml/communityedition.jsp

Se é de uma ferramenta para modelagem UML que você procura, vale a pena instalar essa versão e testar suas funcionalidades, antes mesmo se for o caso, de partir para a compra de uma versão paga

Nos últimos anos tenho trabalhado bastante com a utilização da técnica de caso de uso tanto para validação das funcionalidades com o usuário, quanto para apoiar a etapa de análise e projeto do software visando um desenvolvimento orientado a casos de uso e que resulte num conjunto de especificações do software que possa ser construído por um programador.

A questão que trago aqui é a que muitos autores recomendam que a descrição do caso de uso deva ser genérica, independente de tecnologia ocultando assim detalhes de implementação e no extremo da abstração, a descrição fica até desassociada da interface gráfica.

Tenho visto que quando se adota essa abordagem, a descrição do caso de uso acaba tendo pouca utilidade, só servindo muitas vezes para validar as funcionalidades de software com o usuário, e mesmo assim com algumas limitações. Para a etapa de análise onde se deseja identificar as classes, suas propriedades e comportamentos, a descrição do caso de uso se torna abstrata, ambígua e incompleta. Daí decorre um problema: ela não ajuda na análise, não é atualizada e daí em diante a análise e o projeto seguem sem as descrições dos casos de uso. Perde-se portanto um importante instrumento para dirigir a analise o projeto e os testes do software.

Penso que ao decidir orientar o desenvolvimento por casos de uso, e isso é muito forte, as descrições de caso de uso devam sim ser detalhadas, escritas na voz ativa, de forma clara e sem ambigüidades. Deve-se escrever os casos de uso mão só pensando no cliente, mas também como eles irão ser úteis na fase de análise de projeto do software. Não esquecer também que um caso de uso fica bem mais preciso quando escrito a partir de alguns esboços da interface gráfica.

Veja esses dois exemplos para um caso de uso RESERVAR VEÍCULO (para um sistema de locadora de veículos). Qual descrição lhe parece mais adequada tanto para a validação pelo cliente, quanto para orientar a análise, o projeto e o teste do software?

No desenvolvimento de software das grandes empresas as fábricas de software vem desempenhando cada vez mais um papel central. O modelo que se busca e o de delegar a programação para a fábrica e manter o foco das áreas de desenvolvimento na análise do negócio, na especificação do que será construído nos testes e implantação.

Para que um programador possa implementar um código ele necessita de uma boa solicitação, e como ela deve ser ?

Seria apenas um formulário de requisição para a fábrica onde as informações contidas nele não formam uma documentação do software, ou a requisição deve ser a própria documentação de requisito análise e projeto do sistema?

Haverá sempre a tentação de se preencher um formulário rápido e enviá-lo para a fábrica de software, pois elaborar uma documentação adequada de requisitos, análise e projeto dão um bocado de trabalho. Entretanto penso que o melhor seria elaborar uma documentação completa de requisitos e análise e projeto e essa mesma documentação passa a servir a dois propósitos: documentação do software e para envio à fábrica de software

Essa documentação deve certamente conter uma página que oriente claramente o programador sobre o que deverá ser feito para que ele não precise ler todos os documentos de requisitos análise e projeto do início ao fim. Essa página serviria como um índice rápido para que o programador pudesse localizar o tipo de informação que ele necessita na documentação existente.

Penso que esse tipo de abordagem além de atender a dois propósitos contribui ainda para a produção de um código de melhor qualidade. O você, o que pensa sobre esse assunto?

Eu em conjunto com a pró-reitoria de graduação e extensão da Universidade Camilo Castelo Branco, realizaremos o curso acima no mês de agosto de 2009.

O mercado de desenvolvimento de software tem cada vez mais especializado os papéis dos profissionais, separando as etapas de análise das necessidades de negócios, análise e projeto de sistemas, construção do software e testes. Dado a complexidade dos softwares atuais, não se admite mais  que um profissional possa desempenhar todas as etapas do desenvolvimento de um software.

Esse curso dá ao participante uma visão teórica consistente e associada a prática, do processo de especificação de um software utilizando técnicas de orientação a objetos abrangendo as etapas de elicitação de requisitos, análise e projeto do software, capacitando-o a elaborar uma especificação completa de software a ser construído por um programador ou por uma Fábrica de Software.

Conteúdo:
1-Visão Geral da Análise e Projeto de Sistemas com UML
2-Metodologia de Desenvolvimento de Sistemas
3-Mecanismos Gerais da UML
4-Modelagem de casos de uso
5-Modelagem de Classes de Análise
6-Modelagem das Interações
7- Arquitetura do Software
8- Projeto de Interface Gráfica
9 – Mapeamento dos objetos para o modelo relacional

Dados sobre o curso:

INSCRIÇÕES: até 14/08/2009 –
LOCAL: Processo Seletivo – Campus II – Itaquera – São Paulo
INÍCIO DO CURSO: 15/08/2009 – TÉRMINO: 03/10/2009
HORÁRIO: 8h às12h aos sábados
CARGA HORÁRIA: 32 horas – FREQÜÊNCIA: 75%
INVESTIMENTO: R$ 200,00
Mais informações: coord.cstinformatica.sp@unicastelo.br

É sabido que programas de certificação como o CMMI e o seu primo brasileiro MPS.BR tem colocado os olofotes sobre os processos de desenvolvimento. Muitas empresas denvolvedoras de software fizeram o seu trabalho de casa no que tange a definir, documentar, e divulgar seu processo de desenvolvimento. Feito isso o próximo passo e obter um nível de certificação. Obtida a certificação (nível 2, ou nível 3 ou…) aí e só alegria! Almoços de comemoração e muita publicidade, afinal de contas deu um bocado dc trabalho para conseguir a certificação. Mas e a qualidade do produto de software?

Bem, este é o ponto. Certificação do processo, não significa certificação do produto! É aí que mora o perigo! Deitado em berço esplêndido de uma certificação muitas empresas se esquecem da qualidade do produto.

Para garantir que um processo certificado produza um produto de software de qualidade será necessário uma boa equipe de qualidade assegurada, que não só execute checklists, mas faça inspeções em cada etapa do processo de desenvolvimento para se verificar a conformidade entre o que foi especificado e o que foi construído. Um produto de software pode ser produzido e até funcionar e mesmo assim não estar em conformidade com a especificação. Por exemplo, a especificação descreve uma arquitetura lógica de três camadas e o programador implementa em uma camada única. A especificacao descreve um determinado método de acesso e o programador implementa um método diferente, e assim vai sendo comprometida a qualidade do produto mesmo de uma empresa certificada.

E você o que pensa sobre a qualidade do produto de empresas certificadas? Dá para confiar cegamente?

Você conhece algum desenvolvedor de software que gosta de metodologia para desenvolvimento?  Desenvolvedor gosta de exercer sua criatividade, gosta de imprimir seu estilo de codificar, gosta de liberdade e geralmente não gosta de regras!

E do ponto de vista da empresa? Adotar uma metodologia rígida, uma metodologia flexível ou nenhuma metodologia ?

Independentemente do tamanho da empresa e do seguimento de sua atuação toda empresa precisa de alguma metodologia para o desenvolvimemto de software, pois os funcionários tiram férias, ficam doentes e pedem as contas e nesses casos haverá alguma documentação do software que permitirá uma manutenção emergencial ou mesmo evolutiva sem sobressaltos.

Duas abordagens que eu não acredito são:

1- Metodologia rígida -São boas para desenvolvimento de software de missão critica (principalmente aqueles que podem fazer com que haja perda de vidas) Fora desse domínio a metodologia rígida vira favas contadas, peça de museu, piada em “happy hour”

2 – Bom senso – Deixe por conta do bom senso dos desenvolvedores que eles produzirão um com junto mínimo de documentos, além do próprio código do software.

Então qual abordagem adotar?

Pense em uma metodologia flexível, adaptativa adequada a natureza de cada projeto. Estabeleça processos de entregas, por exemplo, um para novos desenvolvimentos, outro para manutenção evolutiva. Cada processo de entrega define uma raia que orienta o desenvolvedor nas suas atividades.

Não delegue o cumprimento dos processos de entrega para o bom senso. Estabeleça um indicador de conformidade ao processo e defina uma meta a ser atingida a cada nova entrega.

Esse indicador pode ser baseado em artefatos e cada artefato pode ter um peso diferente, por exemplo, um documento de visão do sistema, pode ter um peso maior para um processo de entrega de novo desenvolvimento do que numa manutenção corretiva.

E para garantir que o processo de entrega seja realmente adotado pela organização e necessário o patrocínio da alta gerência, o que irá demonstrar o comprometimento da organização com a metodologia proposta.

Penso que metodologia flexível seja melhor do que nenhuma metodologia. E você o que acha?

5: Afastar o cliente do processo de desenvolvimento – o desenvolvimento de software é de competência exclusiva de analistas e programadores, assim uma vez que já se obteve uma descrição funcional do software a ser desenvolvimento não se faz mais necessário a participação do cliente no processo de desenvolvimento. Com o afastamento do cliente a equipe de desenvolvimento se mantém mais focada, o software tem mais chances de ser entregue no prazo e de acordo com as necessidades do cliente.

4º: Não utilizar uma equipe de teste independente - As atividades de testes são onerosas em termos de custos e prazos, assim não se faz necessário a utilização de uma equipe independente de testes. Na maioria das vezes os testes realizados pelo próprio programador garantem um software de boa qualidade, entregue no prazo e com custos controlados.

3º: Utilizar o programador cowboy: aquele que faz todo o desenvolvimento do software sozinho – A divisão de papéis na equipe de desenvolvimento, como analista de negócios, analista de requisitos, arquiteto, programador e testador só burocratiza o processo de desenvolvimento sem trazer benefícios relevantes para a qualidade do software. Assim utilizar apenas um profissional desempenhado todos esses papéis resulta sempre em melhores resultados.

2º: Codificar antes de especificar – Iniciar a codificação do software o mais rápido possível, ainda que os requisitos não tenham sido claramente definidos torna o processo de desenvolvimento mais ágil, permite ao cliente ter uma melhor noção do que ele precisa, além de garantir entregas mais rápidas e de melhor qualidade.

1º: Estabelecer cronograma irreal – Atualmente em função das demandas de mercado, os cronogramas de desenvolvimento de software devem ser agressivos, ainda que pareçam irreais. Sempre é possível aumentar a equipe de desenvolvimento, reduzir prazos com atividades de arquitetura e testes, e em último caso renegociar o prazo com o cliente.

Essas práticas realmente são muito ruins! Mantenha-se afastado delas, por uma qualidade de software melhor!

É muito comum encontrar literatura sobre as melhores práticas para o desenvolvimento de software. Mas vou dedicar alguns posts para elencar em ordem decrescente as dez piores práticas para o desenvolvimento de software. Espero que você não se identifique com essas práticas!

Neste post vou elencar do 10º ao 6º lugar:

10 º : Não estabelecer métricas para o desenvolvimento de software – cada software é desenvolvido de uma forma particular, em função das suas características, e também cada desenvolvedor tem um estilo próprio de codificação. Assim não é possível nem necessário estabelecer métricas como produtividade por linha de código, quantidade de erros por pontos de função detectados em ambiente de produção, cumprimento dos prazos de desenvolvimento, etc. A equipe, mesmo sem métricas tende a melhorar organicamente.

9 º : Não prever capacitação dos usuários para utilização do software – Atualmente as interfaces gráficas são muito intuitivas e de fácil utilização. As crianças já utilizam computadores desde a tenra idade e crescem em contato com esse ambiente. Como hoje os prazos de desenvolvimento são apertados não se faz necessário gastar tempo com a capacitação dos usuários para a utilização do software. Havendo dúvidas de utilização, o usuário sempre pode ligar para o help-desk.

8º : Não utilizar um processo definido para relato de defeitos – durante o processo de desenvolvimento e as diversas etapas de testes, à medida que os defeitos vão sendo encontrados, eles vão sendo priorizados e corrigidos segundo a própria experiência dos programadores. Não há necessidade de um software para gestão de defeitos, o que iria só burocratizar a agilidade da correção dos mesmos. Raramente ocorre de um software ir para a produção com defeitos já conhecidos, que foram esquecidos de serem consertados pelos programadores.

7º : Não utilizar um software de controle de versão – os códigos fontes são mantidos nas máquinas dos programadores envolvidos em cada projeto de desenvolvimento, de forma a dar maior liberdade e velocidade ao programador. O que importa é a experiência e o controle efetuado pelo programador na hora de colocar o software em produção. Um software de controle de versão é caro e burocrático.

6º : Definir a arquitetura do software à medida que o código vai ficando pronto – Pensar e desenhar a arquitetura do software antes do código estar pelo menos 60 a 80 % pronto não é produtivo, e acaba sendo uma atividade de abstração que quase sempre se demonstra inútil. O programador de acordo com a necessidade do código vai definindo a arquitetura necessária e assim o resultado é sempre um software com boa funcionalidade, usabilidade e performance.

Se você conseguiu ler essas cinco piores práticas, é sinal que tem o coração forte. Aguarde as cinco primeiras e faça o teste definitivo do seu coração!

Uma das boas práticas para o desenvolvimento de sistemas é a de testar o código o mais cedo possível. Nesta linha a revisão estática de código é uma técnica que se adotada continuamente contribui para a melhoria da qualidade de código produzido. Ela pode ser feita manualmente utilizando a programação em pares, ou de forma automatizada, com o uso de uma ferramenta de software que apresenta as seguintes vantagens:

1. Utilização de uma base padrão de regras para a revisão de código

2. Execução da revisão de código de forma automatizada durante a geração do "build" do software

3. Estabelece uma cultura voltada às boas práticas de codificação, evitando a geração de códigos ruins.

A revisão de código permite a otimização do código associado à internacionalização; performance; portabilidade; facilidade de uso; lógica; API do Windows e banco de dados.

Uma boa estratégia de implantação é garantir que todos os desenvolvedores tenham acesso a uma ferramenta de revisão de código e a uma base corporativa, com os padrões customizados para as necessidades das equipes de desenvolvimento.

Os desenvolvedores devem garantir que o seu código esteja em conformidade com a base corporativa, antes de liberá-lo para o ambiente de produção. Visando certificar a conformidade do código colocado em produção, deve-se ainda executar de forma automatizada a revisão de código em tempo de geração de build e publicação em produção. Detectando-se alguma inconformidade, pode-se decidir se o código deve ou não ser implantado em produção, informando o desenvolvedor sobre o tipo de ocorrência detectada.

Segue abaixo dois links para acesso a ferramentas de uso gratuito para os ambientes de desenvolvimento .NET e Java:

Fxcop – Plataforma .NET: http://code.msdn.microsoft.com/codeanalysis/Release/ProjectReleases.aspx?ReleaseId=553

Jupiter – plugin para o Eclipse (Java) : http://code.google.com/p/jupiter-eclipse-plugin/