Segundo Estudo de Caso

Nesse segundo estudo de caso (sistema de remanejamento de servidores de uma ins- tituição de ensino público federal), o participante P03 ofereceu a possibilidade de testes com um dos sistemas abarcados em sua equipe de trabalho. Assim, foi solicitado, formal- mente à instituição, o acesso ao sistema de remanejamento para o estudo. Esse sistema foi escolhido por não ser um dos sistemas mantido por P03, e haver a possibilidade de imple- mentar facilmente leis e regras de outras instituições no sistema. O sistema em questão é um módulo do sistema de gestão de processos da administração. Como a linguagem de desenvolvimento, as ferramentas, políticas de rastreabilidade, plano de conguração e de controle são institucionalizados, e existem documentações e integração entre os sistemas, não houve nenhuma diculdade técnica para P03 com essa escolha.

Com a permissão de observação do ambiente real de desenvolvimento, código fonte, base de dados e das ferramentas institucionalizadas, como, as que são usadas para controle de versão do código fonte, e para gerenciamento de requisitos e de tarefas, a abordagem proposta pode ser testada nesse sistema em produção na instituição. Dessa forma, foi possível compreender a política organizacional e a cultura social relacionada com as ativi- dades do ciclo do software em questão. Isso possibilitou maior compreensão da dinâmica

da equipe e de suas atividades e necessidades dentro de um contexto organizacional real. Autores, como Sharp et al. (2016) e Sommerville (1993), dizem que a etnograa per- mite um foco nos detalhes e a complementação de outras abordagens adotadas, além de permitir mais do que um simples relato de experiência.

P03 é um prossional experiente em desenvolvimento de software, atua no mercado como analista de tecnologia da informação, pós-graduado em desenvolvimento de sistemas e mestrando em Sistemas e Computação, na linha de Engenharia de Requisitos. P03 também possui conhecimentos práticos em elicitação, rastreabilidade, gerenciamento de requisitos; e intermediários conhecimentos em testes, qualidade, denição de processos de software. A temática de requisitos legais para P03 não é novidade, visto que P03 trabalha há algum tempo em órgãos públicos. Além disso, P03 é interessado na temática em si, estando habituado na leitura da legislação e na elicitação de requisitos oriundos das leis.

4.3.3.1 Análise dos Resultados do Segundo Estudo de Caso

Esse estudo possibilitou uma reexão sobre o fenômeno estudado e a abordagem pro- posta em diferentes vertentes: conceitual (bibliográco) e prática; bem como a observação do comportamento de um participante, em seu próprio ambiente, frente a abordagem proposta. O participante P03 apresentou boa desenvoltura nas etapas iniciais de plane- jamento da rastreabilidade e seleção dos requisitos legais. Possivelmente, esse fato esteja associado a familiaridade com o ambiente e a sua prática com esse requisito. P03 preferiu utilizar o quadro Kanban ao sistema utilizado por sua instituição ao longo do estudo. Ao ser questionado sobre isso, foi percebido um certo desconforto com a possibilidade do acompanhamento do desenvolvimento das atividades por toda a equipe, que o sistema de gerenciamento de requisitos (SGR), seria permitido.

O sistema de remanejamento da instituição de P03 precisa ser adaptado frequente- mente; sempre que acontece alguma alteração na lei de remanejamento dos servidores. Para observar o comportamento do participante frente às alterações nas leis que podem causar conitos em requisitos já implementados no sistema foi oferecido um edital para remanejamento de outra instituição. Esse edital não apresentava a mesma estrutura das leis estabelecidas pela instituição de P03. Assim, houve um estranhamento inicial no mo- mento da denição dos elos de rastreabilidade. Este fato é uma das constatações de alguns autores no que diz respeito à falta de padronização do formato de publicação das leis. Por outro lado, a falta de prática com o quadro Kanban de P03 também pode ter atrapa-

lhado a identicação dos tipos de elos criados entre os requisitos, as informações relevantes e as tarefas.

O participante fez anotações do identicador no post-it, que originou o requisito ou possuía alguma relação, mas não conseguiu classicar os tipos de elos (de dependência, de direito ou de dever) existentes entre as informações relevantes e as tarefas com o requisito. P03 precisou também recorrer a algumas portarias da instituição de ensino e outras leis do governo citadas no edital. Consequentemente, foram criados links para essas portarias e leis. Outra diculdade foi a priorização dos requisitos, pois essa atividade, normalmente, é executada pelo gerente de P03. Assim, o participante preferiu fazer a priorização com base na ordem de elicitação dos requisitos.

A atividade de renamento dos requisitos legais transformando-os em requisitos tes- táveis do sistema foi bem satisfatório e iterativo. P03 cou surpreso com a necessidade de detalhamento de um requisito do sistema que já estava implementado, mas não era legível sua descrição depois de algum tempo decorrido de sua implementação. Como pode ser observado no trecho a seguir, extraído da entrevista realizada após a execução do estudo de caso.

A aplicação da abordagem permitiu uma melhor visualização / entendimento dos relacionamentos existentes entre as leis e os outros artefatos do sistema?

Resposta: "Sim. Inclusive durante o procedimento de levantamento de requisitos, com a abordagem, eu descobri um novo requisito para o sistema que não tinha observado antes."

A criação de tarefas e a distribuição dessas foram realizadas por P03 na ordem pro- posta pelo roteiro. No momento seguinte, o participante preferiu questionar a ordem das atividades subsequentes. Alternativamente, utilizou o quadro para a criação dos artefatos sugeridos de saída e de prova sugeridos, e seus respectivos elos de rastreabilidade. Foi, no- vamente, observada a diculdade do participante em realizar atividades que pudessem ser monitoradas por sua equipe nas ferramentas de desenvolvimento institucionalizadas. P03 mostrou-se contrário a criação de casos de testes e a qualquer outra atividade relacionada aos testes de software por julgar desnecessários, e de atribuição de outro membro de sua equipe. Para sua equipe, a inspeção do código fonte é feita pelo gerente de desenvolvimento ou pelo membro mais experiente da equipe, e a vericação utilizando testes de software é realizada utilizando um processo automático de execução realizado imediatamente a após a submissão do código fonte ao sistema de controle de versão.

tations ou marcações do tipo comentários. O participante alertou que a submissão do código fonte no sistema de controle de versão também poderia auxiliar na rastreabilidade entre o código fonte, a tarefa e os requisitos. Com essa nalidade, cada submissão deveria estar associada a uma lei, por exemplo. P03 defendeu que o código fonte bastaria como artefato de prova da implementação e auditabilidade de um requisito legal. Segundo o participante, a política de rastreabilidade adotada por sua equipe deveria ser alterada nos pontos de captação dos elos de rastreabilidade, uma vez que a política atual não trata requisitos legais de forma adequada.

O participante informou que a validação dos requisitos legais do sistema com os clientes é realizada através de um ambiente de homologação. Não existe um procedimento denido formalmente para validação dos requisitos, e também não é uma prática da equipe denir um plano de ações corretivas do projeto para os problemas encontrados.

De maneira geral, P03 achou que teria muito trabalho a ser feito quando foi convidado a participar do estudo. A dinâmica proposta segundo avaliação do participante foi simples e prática. Por outro lado, P03 disse que a exibilidade da abordagem seria quase que mandatória para adequar-se aos diferentes portes de sistemas. A exibilidade permitiria a exclusão de algumas etapas ou artefatos, para que o custo da adoção compensasse os benefícios, como facilidade de manutenção e auditabilidade do sistema. Mesmo assim, ao ser questionado sobre a possibilidade de usar a abordagem, P03 exclamou Para matar cachorro grande eu usaria. Como pode ser observado no trecho da entrevista a seguir.

Você usaria essa abordagem em seus projetos de software? Por quê?

Resposta: "Para matar cachorro grande eu usaria... Para softwares gran- des utilizaria essa abordagem, mas para softwares pequenos, não usaria. Acho que qualquer abordagem que seja mais que um bloco de notas e conversas com o usuário deve ser adaptado à realidade do usuário."

As experiências vividas por P03 mostraram-lhe que os auditores não inspecionam o código fonte ou os requisitos elicitados. Normalmente, os auditores fazem a conferência apenas a partir dos relatórios gerados. Por outro lado, armou que, se a auditoria fosse mais detalhada, a abordagem iria ajudar muito. Como no momento, que realizou a aplica- ção da abordagem no sistema institucional em produção, e foi lhe permitido uma melhor visualização e entendimento dos relacionamentos existentes entre as leis e os outros arte- fatos do sistema. Inclusive durante o procedimento de levantamento de requisitos, com a abordagem, eu descobri um novo requisito para o sistema que não tinha observado antes disse P03. O participante nalizou dizendo: Para mim isso aqui (a abordagem) é o que há de mais moderno.

4.4 Discussão

Com a análise dos dados dos estudos de casos foi possível identicar algumas desvan- tagens e algumas vantagens na adoção da abordagem. Compreendeu-se, primeiramente, que a existência de uma abordagem não pode garantir, por si só, a conformidade legal do sistema. Para isso, é necessário que os membros da equipe do projeto tenham sido trei- nados e estejam cientes dos planos, modelos e políticas que visam a rastreabilidade das informações, consideradas importantes para a vericação dessa conformidade. A equipe precisa ser sensibilizada sobre a importância de cada passo, para que ao nal seja possível efetivamente obter um sistema que está de acordo com as leis. Além disso, os stakehol- ders, precisam conhecer algumas preocupações inerentes à implementação de sistemas, que possuem requisitos legais. Esses requisitos, normalmente, têm uma prioridade maior do que requisitos de usuário, por exemplo, não podem ser negociados, mas podem ser atendidos de diferentes formas, principalmente, quando considerado um conjunto maior de leis e as interrelações dessas leis nos diferentes contextos. Não atender um requisito legal pode signicar sofrer sanções, prejuízos institucionais, nanceiros, e sociais.

A exibilidade da abordagem pode facilitar a adaptação às metodologias e atividades utilizadas por cada equipe de desenvolvimento. Ao mesmo tempo que pode criar aberturas e, indiretamente, favorecendo a não rastreabilidade de artefatos importante à abordagem. Então, a prática simplicada pela abordagem deve ser considerada e adaptada com cui- dado pelas equipes.

Para os participantes dos estudos preliminares, o uso da abordagem torna visível os indícios de melhoramento da: i) implementação dos requisitos legais, por permitir que artefatos, como o trecho da lei e criação de elos de rastreabilidade do requisito até o resultados dos testes, sejam associados e facilmente resgatados; ii) rastreabilidade dos requisitos legais do sistema, por conta da preocupação com a criação de rastros e elos de rastreabilidade com os artefatos; iii) vericação e auditabilidade da conformidade le- gal como consequência de um esforço inicial para rastrear e manter as relações entre os artefatos, independente de sua natureza.

Foi observada que a fase de negociação, quando estão envolvidos requisitos legais, é comprometida negativamente. Essa diculdade pode ser atribuída a isonomia da legisla- ção, e a falta de compreensão desse fato pela maioria dos stakeholders. Características, como volatilidade e criticidade, desses requisitos tornam também sobrecarregado o ciclo de vida dos sistemas. O emprego da abordagem revelou sinais de redução dessa sobrecarga.

O segundo estudo suscitou dúvidas quanto a real possibilidade de aplicar a aborda- gem em qualquer projeto de sistema, sem considerar o seu porte. Todavia, há armações feitas pelos participantes de ambos os estudos que assinalam a possibilidade. Existe um investimento maior de energia para as equipes que não são dotadas de processos já padro- nizados pela Engenharia de Software. O investimento diz a respeito a denição de planos, políticas, ferramentas e treinamento de pessoal. Esse custo inicial é retornado rapida- mente a serem considerados benefícios como a facilidade de entendimento dos artefatos produzidos, comunicação da equipe, manutenção e expansão dos sistemas, por exemplo.

O foco da pesquisa foram os sistemas com requisitos legais. Por outro lado, nada impede que não havendo requisitos legais a abordagem seja utilizada, pois a rastreabilidade dos requisitos favorece a correção e o crescimento dos sistemas. Além disso, possibilita mais facilmente a adaptabilidade dos sistemas em havendo regras de negócio ou institucionais que precisam ser atendidas, e por certo essas regras também podem ser modicadas a qualquer momento. Esta situação foi percebida pelos participantes dos estudos.

O capítulo em pauta expôs os passos percorridos para renamento e avaliação da abordagem. Foram relacionados os instrumentos utilizados e detalhada a metodologia considerada para conduzir a pesquisa. No próximo capítulo, são apresentadas as conside- rações nais dessa dissertação de mestrado.