• Nenhum resultado encontrado

3 Abordagem Proposta

3.6 ETAPA 4: VERIFICAR E VALIDAR A CONFOR MIDADE LEGAL

Os processos de vericação e de validação asseguram que o software atende às especi- cações e às necessidades para as quais ele foi desenvolvido Sommerville e Sawyer (1997). Logo, no contexto deste trabalho, a vericação e a validação da implementação dos re- quisitos legais têm como objetivo principal não somente o atendimento das especicações e das necessidades dos stakeholders, mas também o atendimento das normas vigentes e aplicáveis ao domínio do sistema.

Semelhante à etapa de validação, apresentada no processo de engenharia de requisitos de Sommerville e Kotonya (1998), esta etapa também pode ser descrita como um processo relativamente demorado, uma vez que as atividades, que a compõem, exige que uma aná- lise cuidadosa dos relatórios, diagramas e outros artefatos, seja realizada pelo engenheiro de requisitos e, se possível, por um prossional especializado na legislação relacionada. Técnicas tradicionais de vericação também podem ser utilizadas em conjunto, como a inspeção de software, uso de checklist, análise estática do código fonte, entre outras.

Assim, as atividades associadas a essa etapa podem permitir, consequentemente, ao gestor do projeto efetuar um conjunto de ações corretivas para garantir a qualidade do software. Essas atividades são: i) analisar requisitos legais com artefatos de prova; e ii) validar os resultados da análise da conformidade legal junto aos stakeholders. Atividades

que são representadas nos elementos de cor verde da Figura 17, e descritas detalhadamente nas subseções seguintes.

Figura 17: Visão detalhada da quarta etapa da abordagem

3.6.1 Atividade 4.1 - Analisar Requisitos Legais e Seus Artefatos

de Prova

Esta atividade consiste em vericar se os requisitos legais foram devidamente im- plementados no sistema. A análise dos requisitos legais e a identicação dos artefatos produzidos durante a sua modelagem tem um papel fundamental neste sentido. Nesta atividade o gerente do projeto irá utilizar-se dos elos de rastreabilidade estabelecidos nas etapas anteriores e deverá, a partir da vericação da lista de requisitos legais, analisar se os artefatos gerados, durante a implementação dos requisitos, são sucientes para garantir a conformidade legal do sistema.

Ao nal desta atividade, a Lista de requisitos legais do sistema e a Lista de artefatos de prova devem ser vericadas. Os artefatos que devem compor a lista podem ser de diversos tipos, desde logs de execução do sistema e diagramas do projeto até documentos de requisitos, onde podem ser encontradas evidências de esforços para implementação de funcionalidades em conformidade com a legislação. Os testes de software continuam sendo uma das técnicas de vericação e validação mais comumente utilizadas para determinar se as necessidades do cliente foram atendidas (CALISAYA; LEITE, 2013).

Na abordagem proposta, os testes também são considerados artefatos de prova, com- plementando as atividades desenvolvidas na Etapa 3, onde os testes de software foram planejados e executados. Esta atividade também deve possibilitar que o gerente de pro- jetos faça uma análise do relatório de testes com foco nas funcionalidades relativas aos requisitos legais.

Assim, outro artefato de saída, possível para esta atividade é um documento con- tendo a Análise do relatório da análise dos testes. O gestor deve analisar os pontos de não conformidade do sistema, identicados a partir do relatório de testes dos requisitos legais, disponibilizado na Etapa 3 e propor ações corretivas que visem a retomada da conformidade do sistema.

Os requisitos identicados como sendo de alta prioridade e criticidade podem ser monitorados mais profundamente através do uso de técnicas de auditoria de análise de código como a inspeção, por exemplo. A partir da política de rastreabilidade denida, trechos de código fonte, que implementam funcionalidades que atendem aos requisitos legais, podem ser facilmente identicados e recuperados.

O entendimento do requisito legal e a identicação do respectivo código fonte da aplicação que o implementa, precisam estar acessíveis ao gestor do projeto nesta etapa do processo. A realização desta atividade deve permitir, por exemplo, a visualização, se possível de forma gráca, do rastro e do provável impacto causado por uma alteração nos requisitos legais do sistema. Esta atividade poderá ser viabilizada com o auxílio de uma ferramenta que possibilite o registro, e a visualização posterior, de links de rastrea- bilidade a partir das interações do programador com o ambiente de desenvolvimento do software (IDE), as tarefas e os documentos de requisitos utilizados na implementação da funcionalidade. Técnicas de inspeção do código fonte também podem ser utilizadas.

O artefato resultante é um Diagrama de rastreabilidade dos requisitos legais. Este diagrama deverá ser produzido a partir das informações de rastreabilidade disponíveis no sistema de gerenciamento de requisitos ou registradas por uma ferramenta especíca, como dito no parágrafo anterior.

A Figura 18 ilustra os elementos que devem fazer parte do diagrama de rastreabilidade dos requisitos legais e a forma como eles se relacionam.

Ao nal desta atividade uma política de rastreabilidade atualizada poderá ser gerada, dependendo das necessidades constatadas pelo gerente do projeto durante a realização das ações desta fase da abordagem.

Figura 18: Rastreabilidade da lei ao código

3.6.2 Atividade 4.2 - Validar Requisitos Legais

Os resultados da análise de conformidade legal do sistema devem ser comunicados aos stakeholders. Negociações sobre os riscos de não conformidade do sistema devem estar claros nessa fase do projeto. Algumas boas práticas de negociação propostas por Pohl (2010) também podem ser consideradas pelos stakeholders nesta atividade. São elas: i) identicar os conitos, seus motivos e classicá-los; ii) analisá-los; iii) propor resoluções baseadas em estratégias de resolução de conito, como acordo, compromisso, matriz de decisão; e iv) documentar, de forma rastreável, a efetiva resolução implementada para os conitos identicados visando não enfrentar os mesmos conitos e mapear resoluções inapropriadas.

Os requisitos legais do sistema devem ser monitorados, analisados e validados pela equipe em intervalos planejados para assegurar a continuidade da sua pertinência e e- cácia. As análises devem incluir a análise da legislação concernente, a avaliação de opor- tunidades de melhoria e também a necessidade de alterações no sistema considerando alterações na política, objetivos e metas da empresa.

São dois os artefatos de saída que resultam da execução desta atividade, A Lista de requisitos legais validados e o Plano de ações corretivas. A Lista de requisitos legais validados atesta a conformidade legal das funções executadas pelo sistema, que derivaram dos requisitos legais monitorados através da abordagem. Esta lista de requisitos validados deve estar disponível para os stakeholders através da ferramenta de gerenciamento de requisitos adotada no projeto. Já o Plano de ações corretivas deve apresentar um conjunto de medidas que devem ser tomadas pela equipe de desenvolvimento do software para correção das inconformidades constatadas.