segunda-feira, abril 24

O que a Engenharia de Requisitos tem a ver com a qualidade do software

Bem... O que é qualidade em software?

A qualidade de um software está relacionada com a precisão a qual as necessidades de seus usuários são atendidas.

Como essa qualidade pode ser avaliada?

A única forma de se avaliar a qualidade de um software é testá-lo, de preferência, exaustivamente!

Estou afirmando que a única disciplina que poderá aferir a qualidade em software é a disciplina de testes e para testar é necessário que exista uma documentação atualizada, clara e fiel às necessidades dos usuários desse software. Por isso, existe uma dependência clara entre essas duas disciplinas (requisitos e testes).

Existem representantes de organizações que declaram que a disciplina de teste não faz parte do Controle de Gestão de Qualidade (CGQ) de software, estão profundamente enganados. Sem um teste minucioso que se inicia com a análise e revisão cuidadosa da documentação e prossegue com a análise cuidadosa das funcionalidades em contraposição com as necessidades não serão alcançadas as metas de qualidade em software que se desejam. Desenvolver aplicativos úteis, esse deve ser o objetivos das boas fábricas de software - o produto deve ser a meta. A remuneração econômica 'deveria' ser conseqüência dos produtos de qualidade. Mas esta última colocação é apenas uma reflexão íntima.

Um bom padrão de desenvolvimento ajuda em muito tanto a disciplina de requisitos quanto todas as outras disciplinas envolvidas no processo de desenvolvimento de sistemas. Porém os padrões devem ser flexíveis o suficiente para não engessar o processo e rígidos o suficiente para não serem diluídos - esse equilíbrio é díficil de ser alcançado sem traumas. Um problema é que, normalmente, o 'burocrata' que impõe o padrão não o utiliza no seu dia-dia. Por isso, proponho que os padrões surjam do amadurecimento natural dos processos com a avaliação dos profissionais envolvidos e que, definitivamente, (esses padrões) não sejam impostos por 'burocratas' insensíveis ao meio de produção.

segunda-feira, abril 3

Sobre 'Especificações de Caso de Uso'

Na minha modesta opinião esse artefato é de fundamental importância ao bom desenvolvimento do software.

Após extrairmos, dos stakeholders (usuários) as necessidades do software, determinaremos quais serão as funcionalidades que comporão o aplicativo que estamos concebendo. Em seguida, organizaremos essas funcionalidades em seus cenários comuns, os quais denominamos, casos de uso. Isto feito, e após concebermos a inter-relação entre os diversos casos de uso que compõem o nosso sistema, iniciaremos a construção do artefato que representará a navegabilidade do sistema, do ponto de vista do usuário. Bem como, as regras que regulam o funcionamento do negócio.
Esse artefato se compõe basicamente de fluxos de navegação e regras de negócio específicas para o caso de uso em questão; além de algumas informações complementares que informam sobre as características específicas das informações contidas nesse caso de uso. Os elementos fundamentais da Especificação de caso de uso, são os seguintes:

  1. Fluxo Básico - representa o fluxo fundamental (caminho feliz) do caso de uso. Ele define, inicialmente, o que determina o início do processo operacional do caso de uso em seu passo inicial e encerra o processo em seu último passo;
  2. Subfluxo - representa uma seqüência de passos que se repetem durante o caso de uso. A característica fundamental dos subfluxos é que quando invocados de qualquer ponto do caso de uso, executa os seus passos seqüencialmente e, após, a conclusão da execução devolve, ao passo seguinte ao que o invocou, a sua execução. Esse tipo de elemento é fundamental para indicar o reuso de uma instrução;
  3. Fluxo Alternativo - esse elemento representa toda a navegação que é alternativa àquilo que está proposto no passo ou fluxo antecedente. Quando invocamos um fluxo alternativo, estamos determinando um caminho opcional ao que está proposto antecedentemente;
  4. Fluxo de Exceção - esse elemento tem alguma similaridade com o fluxo alternativo. Porém, trata de uma execução alternativa em função da violação de uma Regra de Negócio. Quando temos a vinculação de uma regra de negócio ao um passo, obrigatoriamente, deveremos tratar a exceção correspondente. Obviamente, existirão outras exceções que não serão tratadas em nosso aplicativo. O elemento, em questão, dispõe sobre aquelas exceções que conseguimos prever, a priori;
  5. Regras de Negócio Específicas - esses elementos são fundamentais para a especificação de caso de uso, são através da determinação desses fatores que delimitamos operacionalmente o sistema que estamos a construir.

É bom lembrar, que esse artefato deve conter, ainda, a descrição precisa - do ponto de vista do negócio - das interfaces que compõem o caso de uso. Quando ressalto do 'ponto de vista do negócio', quero argumentar que somente aquelas definições de interface que advêm das necessidades do negócio é que devem ser documentadas. Neste momento, não deveremos focar conteúdo sobre os padrões de interfaces da corporação para qual estamos especificando, esse assunto deve ser tratado no artefato 'Documento Geral de Interfaces de Software'.

Os passos dos fluxos devem ser referenciados de forma clara e objetiva (recomenda-se que se utilize o tempo verbal presente do indicativo). É condenável passo de fluxo que contenha informação típica de regras de negócio. Essas informações devem estar contidas na própria regra de negócio que estará referenciada nos fluxos onde acontece. Essas regras devem ter redação clara e de fácil entendimento - mesmo por pessoas não afeitas ao negócio. Deve-se evitar que as regras de negócio contenham texto que conduzam a dupla interpretação ou a conclusões equivocadas. Quando necessário para aclarar a informações devemos apelar para diagramas, tabelas entre outros recursos. Assim como, devemos evitar termos específicos (jargões) que não estejam claramente explicados no artefato 'Glossário'.

Basicamente, a especificação é dividida em duas categorias:
Especificação comum - essa categoria é adequada para a descrição de casos de uso isolados, sejam autônomos ou que se mantenham relacionados a outros como 'include’, 'extends' ou ‘generalização’;
Especificação CRUD - Essa categoria refere-se aos agrupamentos de casos de uso com objetos comuns, ou seja, que contemplem as seguintes transações: consultar, excluir, incluir e alterar. Essas transações são estruturadas na forma de subfluxo, sendo que o fluxo básico do 'CRUD', normalmente, refere-se a seleção de uma dessas opções num menu.