Como Utilizar O Processo De Testes Como Guia Para Elicitação De Requisitos De Sistemas Em Produção?

Como utilizar o processo de testes como guia para elicitação de

Requisitos de sistemas em produção?

1. Introdução

Uma das grandes dificuldades encontradas dentro das empresas é garantir que o software entregue cumpra o que foi solicitado pelo cliente interno ou externo. Esta dificuldade aplica-se tanto ao desenvolvimento de um novo software quanto às manutenções corretivas ou evolutivas. Uma vez que o sistema tenha sido instalado e seja usado regularmente, inevitavelmente surgirão novas necessidades de alterações, ajustes, correções ou evoluções que demandarão novos requisitos de software. Segundo Sommerville (2011), quando os usuários finais tiverem a experiência de um sistema, descobrirão novas necessidades e novas prioridades. Existem muitos recursos ferramentais, técnicas e abordagens que ajudam a contribuir e mitigar tais dificuldades, contudo, conforme observado na experiência profissional dos autores do presente artigo, a atual especificação de requisitos é suficiente para recuperar, rastrear, compartilhar e garantir o entendimento das funcionalidades do software.

Os testes contribuem diretamente com a qualidade do software que está sendo entregue. Contudo, o nível de qualidade dos testes depende do planejamento da atividade, elaboração dos casos de testes e execução do plano de testes.

Os casos de testes são municiados pela análise prévia dos requisitos, de onde são extraídas as regras, restrições, comportamentos, formas de interação, tipos de comunicação para o desenvolvimento do sistema. Tema bastante desafiador na indústria de software, pois nessa fase a comunicação entre as equipes de desenvolvimento e o cliente é essencial para almejar um produto final com qualidade. A gestão do conhecimento se torna o alicerce para a construção de todas as futuras funcionalidades que o sistema proverá ao usuário final, com base na análise dos requisitos é possível desenvolver um framework de conhecimento contemplando casos de testes, casos de uso, planos de testes, assim, temos uma evolução colaborativa no desenvolvimento de software, sendo possível a reutilização do conhecimento já adquirido.

Ao contrário do que acontecia no passado, quando as empresas guardavam seus conhecimentos às sete chaves, com a gestão do conhecimento, toda informação deve ser transformada em conhecimento e distribuída a todos os interessados e envolvidos. O segredo, quanto ao conhecimento, está em armazená-lo organizadamente e divulgá-lo para toda a organização, ao invés de detê-lo.

O conhecimento passa a ser ativo da empresa. Portanto, motivar, recompensar e reter as pessoas que têm conhecimento é um foco das empresas bem-sucedidas, assim como transportar esse conhecimento para os sistemas corporativos, principalmente na sua elaboração, transformando conhecimento em requisitos de sistema (MACHADO, 2011).

Conhecimento é uma realidade no mundo dos negócios. O conhecimento numa empresa não a torna mais competitiva, mas o seu gerenciamento faz a diferença. Esse conhecimento tem de ser encapsulado nas especificações de uma aplicação de software, pois sem ele não conseguimos realizar uma aplicação que agregue valor à organização. (MACHADO, 2011). Os conhecimentos classificam-se em dois tipos, sendo conhecimento tácito e conhecimento explícito. O conhecimento explícito é o que pode ser articulado na linguagem formal, inclusive em afirmações gramaticais, expressões matemáticas, especificações e manuais. Ele pode ser facilmente transmitido, sistematizado e comunicado. Este é o conhecimento que é trabalhado em entrevistas e brainstorming durante a realização do levantamento de requisitos. O conhecimento tácito é difícil de ser articulado na linguagem formal, porém é um tipo de conhecimento muito importante no processo de levantamento de requisitos. É o conhecimento pessoal incorporado à experiência individual e envolve fatores intangíveis, como por exemplo, crenças pessoais, perspectivas, sistema de valor, insights, intuições, emoções e habilidades. Em contrapartida é o conhecimento considerado como fonte importante de competitividade entre as organizações e só pode ser avaliado por meio de ação. Todo o conhecimento tácito necessita passar a ser explicito em um software (NONAKA e TAKEUCHI, 1995).

Assim, a presente pesquisa aborda a seguinte questão:

Em uma empresa de porte pequeno, com sistemas em produção, sem a devida especificação de requisitos documentada e sem uma equipe independente de testes, seria possível utilizar o processo de testes para instaurar também um processo de gestão de conhecimento? Tal processo faria uso de uma ferramenta de gestão de testes e teria como principal objetivo reduzir a dependência de recursos experientes na execução de testes.

O presente artigo faz uso de uma funcionalidade, denominada Apostilamento, dentro de um Sistema de Recursos Humanos desenvolvido pelo grupo setorial de tecnologia da informação de um órgão público do estado de São Paulo. Para um maior esclarecimento, define-se por Apostilamento, o registro de mudança de nome, dados do RG e/ou CPF, cuja pré-condição é a publicação no diário oficial da união.

Ao analisar o processo de manutenção (corretivas ou evolutivas) de quaisquer funcionalidades foi identificado que não há equipe independente de testes que possa garantir com que as manutenções sejam entregues com qualidade para seus solicitantes e que os requisitos do sistema não estão devidamente formalizados. Sendo assim, essa atividade sempre é atribuída ao recurso com maior senioridade, gerando dependência constante, bem como uma superalocação de recurso. Não é possível identificar o tempo total gasto nos últimos três meses com manutenções específicas da funcionalidade de Apostilamento pela falta de registros, entretanto, o tempo total gasto nos últimos três meses com manutenções de todo o sistema de RH é de aproximadamente 2 horas/dia.

Como o processo de levantamento de requisitos e de execução de testes não estão devidamente oficializados pela empresa, não há padronização que garanta o levantamento de requisitos assim como o plano de testes. Dessa forma, torna-se morosa ou até mesmo inexistente a possibilidade de utilizar casos de testes como uma ferramenta estratégica para a geração de indicadores que auxiliassem de forma quantitativa e/ou qualitativa a tomada de decisões de desenvolvimento e manutenção de software baseada em evidência.

Não obstante a esse fator, é impossível determinar a qualidade do produto final, pois como não há métricas indicando qualitativamente o desempenho

...