Qualidade de Software Ltda

Neste artigo irei abordar as práticas e técnicas utilizadas para a elaboração do modelo de domínio para o desenvolvimento de software

Quando você está criando seu modelo de domínio, uma boa fonte de classes de domínio inclui a descrição de requisitos em alto nível, aqueles que são geralmente (mas nem sempre) escrito na forma "O sistema deve fazer isso, o sistema não deve fazer isso. " É útil verificar esses requisitos, extraindo os substantivos e frases substantivas. Você pode refiná-las para criar o modelo de domínio inicial. Com isso em mente, vamos percorrer os requisitos de alto nível para para o desenvolvimento de um software para uma Livraria Virtual, e e extrair as classes de domínio possíveis.

Leia mais …

O software é o combustível utilizado pelos negócios modernos, construir e manter software de qualidade, de forma repetitível e previsível é difícil hoje e se tornará cada vez mais difícil. São sintomas típicos de problemas no desenvolvimento de software: falha no entendimento das necessidades dos usuários; inabilidade de tratar mudança de requisitos; descobrimento tardio de demandas importantes do projeto; falta de um processo definido para o desenvolvimento de software

Geralmente os projetos de desenvolvimento de software falham devido às seguintes causas: gerência “por demanda” dos requisitos; comunicação ambígua e imprecisa; arquitetura fracamente definida; complexidade sub-estimada; inconsistências não identificadas nos requisitos, projeto e no código e testes insuficientes. Ao tratar essas causas, através de uma metodologia de desenvolvimento de software, os sintomas serão eliminados e será mais fácil desenvolver e manter um software de qualidade de forma previsível e que possa ser repetida.

Segundo o dicionário Aurélio metodologia é o estudo dos métodos; caminho pelo qual se atinge um objetivo. Modo de proceder, maneira de agir.

As principais características de uma metodologia de desenvolvimento são Leia mais …

Para determinados tipos de sistemas a preparação de massa de dados é uma das etapas que mais pode consumir esforços e recursos e certamente define a qualidade dos testes funcionais.
Se você é o responsável por esta importante etapa dos testes, veja as dicas abaixo:
Leia mais …

Ao longo dos anos tenho estudado e praticado a modelagem de software com UML. Participei de vários foruns de discussão, li vários artigos acadêmicos, artigos do Gartner Group, medotologias como o RUP e livros. Muitos livros.

E como acredito que a teoria na prática é diferente, pratiquei muito do que estudei sobre modelagem seja no desenvolvimento de novos sistemas ou na manutenção de sistemas existentes. Os resultados? Nem sempre animadores…

Geralmente chegava ao final da modelagem com pressão sobre o prazo de entrega do projeto, e a pergunta que sempre ouvia era: quanto do código já está pronto? Eu ainda não tinha código pronto, “apenas” os modelos. E dá-lhe pressão de prazos…

Leia mais …

Um dos grandes desafios do desenvolvimento de um bom software, certamente está em se ter um processo consistente para se capturar as necessidades do cliente, traduzí-las em requisitos e a partir daí definir os casos de uso. A partir deste ponto, como chegar ao início da codificação?

Elaborei um mapa conceitual do que entendo ser uma abordagem prática de análise e projeto de software, contemplando os seguintes artefatos:

• Documento de Visão
• Modelo de Caso de Uso
• Protótipo de Telas e Especificação de Interface Visual
• Diagrama de Classes de Análise e de Projeto
• Documento de Arquitetura do Software
• Diagramas de seqüência
• Modelo de Dados

Com essa abordagem creio que se obtém um modelo de análise e projeto consistente para o início da codificação. Veja o mapa conceitual dessa abordagem na figura abaixo. O que você acha a respeito dessa abordagem?

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

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?

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!