A adoção de práticas ágeis está se tornando cada vez mais realidade nas empresas, e diferente como alguns pensam, não somente as pequenas e médias empresas de tecnologia estão adotando o método. Muitas instituições financeiras, indústrias e empresas de grande porte estão em processo de implantação. Mas para essas grandes instituições não temos como escapar de algumas exigências obrigatórias que impactam o desenvolvimento de software podendo torna-lo improdutivo ou burocrático. Essas exigências na maioria das vezes estão relacionadas ao atendimento de requisitos regulatórios, como por exemplo Sarbanes Oxley (SOX) ou Basileia.

Vamos focar este artigo nos principais itens regulatórios de instituições financeiras onde apresentaremos um breve resumo que poderá ajudar desenvolvedores a entenderem de forma simples quais os principais requisitos a serem obrigatoriamente seguidos e como não tornar o processo de desenvolvimento ágil burocrático e não produtivo.

Sarbanes-Oxley, Seção 404: Avaliação de controles internosv (a parte mais importante para TI)

A Lei Sarbanes-Oxley (em inglês, Sarbanes-Oxley Act) é uma lei assinada em 30 de julho de 2002. Motivada por escândalos financeiros corporativos (dentre eles, o da Enron, que acabou por afetar drasticamente a empresa de auditoria Arthur Andersen), essa lei foi redigida com o objetivo de evitar o esvaziamento dos investimentos financeiros e a fuga dos investidores causada pela aparente insegurança a respeito da governança adequada das empresas.

A lei Sarbanes-Oxley, apelidada de Sarbox ou ainda de SOX, visa garantir a criação de mecanismos de auditoria e segurança confiáveis nas empresas, incluindo ainda regras para a criação de comitês encarregados de supervisionar suas atividades e operações, de modo a mitigar riscos aos negócios, evitar a ocorrência de fraudes ou assegurar que haja meios de identificá-las quando ocorrem, garantindo a transparência na gestão das empresas.

O que meu desenvolvimento tem a ver com isso?

Apesar do SOX não abordar diretamente a informática, as implicações para TI são enormes, uma vez que a maioria dos dados financeiros da organização flui através dos sistemas de informação e do código que você escreve. Logo, podemos dizer que qualquer manipulação incorreta no código fonte dos sistemas de TI poderá causar danos e/ou prejuízos financeiros para a instituição.

Podemos então dizer que, o principal requisito da SOX é controlar a criação, edição e versionamento de ativos que podem estar associados à seção 404 (seção que determina uma avaliação anual dos controles e procedimentos internos para emissão de relatórios financeiros), ou seja, qualquer alteração dos softwares desenvolvidos deverá ser devidamente documentada e controlada, gerando evidências que a empresa está tomando os cuidados necessários com os dados críticos e informações sensíveis.

A seção 302 da Lei exige que os CEO e CFO façam declarações periódicas incluindo auditoria externas para evidenciar que os controles estão adequados para as informações financeiras da organização.

Acordo Basiléia II

O acordo de Capital de Basiléia II, também conhecido como Basiléia II, trata-se de um framework estabelecido pelo Comitê de Basiléia, um consórcio de Bancos Centrais de Governo de vários países. O objetivo de Basiléia II é a revisão das normas internacionais existentes usadas para medir a exequibilidade ou simplesmente qualidade do capital de um banco. O acordo Basiléia anterior é considerado ultrapassado, pois não se adequa à nova realidade e modernizações do sistema financeiro.

O que meu desenvolvimento tem a ver com isso?

Grande parte do conteúdo do acordo Basiléia II foi redigido por profissionais do setor financeiro, de tal forma que pode ser aplicado em uma variedade de sistemas bancários do mundo. Os requisitos são vagos na perspectiva de TI, no entanto há uma série de medidas de mitigação de riscos para serviços financeiros.

Portanto, podemos dizer que no ponto de vista de desenvolvimento, a grande questão está relacionada à gestão de riscos operacionais que visam à criação de políticas de gerenciamento de riscos para garantir segurança e confidencialidade das aplicações de TI que manipulam dados de clientes.

De forma não exaustiva, segue um resumo de alguns requisitos que apoiam no cumprimento da Basiléia II para tratamento de possíveis riscos operacionais:

• Construção de sistemas de alta confidencialidade garantindo a criptrografia de dados confidenciais e evitando vulnerabilidade no código desenvolvido;
• Disponibilidade do serviço, evitando interrupções devido a falhas de hardware ou software;
• Controle de alterações no software indevidos, não registrados e/ou autorizados;
• Controle de transações não autorizadas seja inserido no código dos sistemas.

Um bom processo de Gerência de Mudanças e Configuração pode ajudar bastante na redução dos riscos operacionais que podem ser gerados nas aplicações de TI.

Desafios no Desenvolvimento Ágil

Apesar de muitos dizerem que ágil é sinônimo de liberdade e bagunça, não é bem verdade. Eu diria exatamente o contrário, agile é um método muito mais organizado e disciplinado do que muitos desenvolvimentos tradicionais que tenho visto nas empresas.

A conformidade com essas regulamentações exige relatórios financeiros precisos dos custos de desenvolvimento dos projetos e uma extensa documentação do processo. De fato, quanto maior o projeto, time ou quantidade de áreas envolvidas, maior será a exigência por controles formais e documentação.

O principal paradigma quebrado na adoção do desenvolvimento ágil, é que o foco passa a ser do produto gerado, ou seja, a medida primária de gestão é teste ou software funcionando, diferente dos desenvolvimentos tradicionais onde boa parte do controle do progresso está associado à geração de documentos e reportes formais. Podemos perceber que muitas vezes passamos boa parte do tempo produzindo documentos de solução de problemas que nem sequer existem.

O grande desafio aqui é encontrar o “ponto doce”, ou seja, não devemos implementar controles excessivos ou produzir muito para nada. A prática de captura de requisitos, por exemplo, não é o ato de construção de um documento de especificação funcional, mas sim a negociação contínua da definição de um escopo.

Seguem listados aqui alguns dos principais objetivos exigidos pelas normas de auditoria e como podemos endereçá-los para o desenvolvimento ágil:

Objetivo: Processo de desenvolvimento definido
Realização: Estabelecer práticas padronizadas e um processo a ser seguido pelo time. Exemplo de práticas: desenvolvimento orientado a User Stories, visão geral de requisitos, planejamento de release, visão compartilhada, gerência de riscos orientada a valor, etc..

Objetivo: Processo de planejamento de release definido
Realização: Adotar a prática de planejamento de release integrada ao planejamento e revisões das iterações/sprints

Objetivo: Prevenção de manipulação
Realização: Controlar os acesso a dados críticos de sistemas e implantação de user stories de aplicação para criptografia de dados

Objetivo: Execução de testes
Realização: Evidenciar testes automatizados, definições de testes e arquivar os relatórios com segurança. A adoção da prática de build e teste contínuos também é recomendada.

Objetivo: Documentação de usuários
Realização: Descrever as user stories adicionalmente os critérios de aceite, definição de pronto, metas de iterações/sprints ou até casos de uso (opcional) complementam a documentação exigida

Objetivo: Arquivamento
Realização: Implantar um sistema de gerência de configuração e versionamento com seus elementos rastreados às user stories implementadas. Necessidade de arquivamento de pelo menos 10 (dez) anos.

Objetivo: Impedir alterações não autorizadas de software
Realização: Implantar um sistema de gerência de configuração e versionamento integrado aos itens de trabalho registrados (ex. defeitos, tarefas, user stories) evidenciam que a empresa está tomando cuidados necessários para evitar a injeção de rotinas que permitam transações fraudulentas no seu código.

Objetivo: Autenticação segura
Realização: Implantar users stories de aplicação de criação de mecanismos seguros de autenticação nos sistemas utilizando senhas fortes e armazenamento de senhas seguro.

 

Ambiente colaborativo é essencial

Diferente das metodologias tradicionais, que são fortemente focadas em processos e geração de documentação, um dos principais fundamentos do Manifesto Ágil é o foco nos indivíduos e suas interações. Não se trata de desprezar elementos e ferramentas tradicionais de desenvolvimento de software, mas sim de estabelecermos uma escala de valores, na qual a flexibilidade e a colaboração são mais relevantes do que a rigidez de processos e planejamento clássicos.

Posso fortemente afirmar que não é possível sobreviver com ferramentas tradicionais para um ambiente ágil de desenvolvimento. Para isso é necessário um ambiente que facilite o atendimento dos requisitos regulatórios sem onerar o dia-a-dia dos desenvolvedores.

Uma solução talvez mais racional e simples seja a adoção de ferramentas que suportam a interação entre pessoas, também chamamos de ferramentas colaborativas de ALM (Application Lifecycle Managment). Essas ferramentas além de suportar o ambiente colaborativo de desenvolvimento permitem o registro e as evidências necessárias para o processo de auditoria dos requisitos regulatórios, através, por exemplo, de relatórios automatizados e dahsboards.

Falando ainda de ferramentas, vale mencionar que existem empresas que optam por adotar o papel de “documentador”, antigamente também chamado de “Escriba” somente para atuar na geração e arquivamento das evidências e artefatos obrigatórios para atender a requisitos regulatórios com o objetivo de eliminar essa carga de trabalho dos times ágeis. Francamente, não sei dizer se seria ou não a melhor solução.

Utilizaremos neste artigo o ambiente colaborativo de desenvolvimento Jazz para exemplificar alguns cenários de como uma ferramenta poderá apoiar no atendimento a esses requisitos sem impactar a produtividade dos times:

Rastreabilidade

O código alterado em coerência com as varias disciplinas como requisitos, design, testes e deploy é essencial. A rastreabilidade estabelece relações entre os artefatos de software garantindo a cobertura em todas as disciplinas.

Podemos citar alguns dos exemplos mais comuns de visões de rastreabilidade como requisitos e código, casos de testes e requisitos, elementos de design e requisitos.

O auditor quer ver:

• Matrizes de rastreabilidade entre as disciplinas de desenvolvimento;
• Evidências de análise de impacto de mudanças em uma disciplina afetando outra;
• Evidências da realização de análises adequadas e medidas corretivas associadas à mudanças que causam impactos.

A ferramenta deve estar preparada para:

• Utilizar dashboards para manter e rastrear as visões:

• Configurar visões de análise de impacto:

•  Utilizar revisões e comentários para suportar análises e ações corretivas:

Autorização do trabalho

Processos ágeis e iterativos devem ser suportados por “gates” de autorização e gerência de mudanças para garantir que apenas o trabalho aprovado é incluído em um release de produção.

A Sarbanes Oxley, por exemplo, exige que controles internos apropriados sejam estabelecidos para mitigação de riscos de alterações não desejadas nos sistemas que manipulam dados de negócio. A aprovação do conteúdo e da release a ser implantada em produção é um dos principais controles a serem auditados.

O auditor quer ver:

1. Quem (usuário e papel) autorizou o conteúdo de uma release.
2. Quem (usuário e papel) autorizou a implantação de uma release em produção.
3. Os Requisitos a serem implantados foram devidamente validados e autorizados pelo usuário que irá utiliza-lo.

A ferramenta deve estar preparada para:

• Fornecer um mecanismo de autorização do trabalho ou aprovação de requisitos através de assinatura eletrônica:

Controle do processo e segregação de papéis

Em um ambiente regulado, é necessário que os controles internos implementados nos processos sejam seguidos e qualquer mudança relacionada a esses controles sejam devidamente registradas e controladas.

Uma pessoa de um determinado time pode receber diferentes atribuições, principalmente quando se trata de desenvolvimento ágil, portanto o processo que orienta o desenvolvimento de sistemas deve permitir a segregação clara dos papéis e responsabilidades de acesso. Existem determinadas regras a serem seguidas quando se trata da definição de papéis e responsabilidades. Por exemplo:

A utilização de usuários genéricos para realizar diferentes operações como desenvolvimento de código, testes ou aprovação não é permitida para manter o controle do ambiente. Outro exemplo seria termos o aprovador de uma user story responsável pela tarefa de desenvolvimento desta ou mesmo uma mesma pessoa testar o trabalho que ela tenha desenvolvido.

O auditor quer ver:

1. O balanceamento sobre os papéis e responsabilidades executadas pelos times.
2. Como a configuração do processo e controles estão definidos.
3. Quais mudanças feitas, por quem, quando e quem autorizou (como estava antes e como está depois).

A ferramenta deve estar preparada para:

• Permitir a definição do processo de desenvolvimento e suas devidas regras:

•  Permitir a configuração de regras que controlam a violação dos requisitos de segurança a serem auditados:

• Controlar o histórico de mudanças das definições do processo a ser seguido pelos times:

Conclusão

O objetivo deste artigo foi mostrar que as normas regulatórias aqui citadas estão relacionadas à transações que afetam ativos da empresa. Em uma instituição financeira onde grande parte dos os processos de negócio estão automatizados por uma ferramenta de software, o papel de TI passa a ser fundamental para o atendimento destes requisitos, ressaltando que nenhuma ferramenta de software poderá de forma individual e exclusiva tornar a empresa compatível com SOX.

De uma forma resumida para ajudarmos no entendimento destas normas, do ponto de vista do desenvolvedor precisamos entender que é necessário:

“Dizer o que você faz:”

• Ter evidências documentadas que você possui um processo completo, bem comunicado e de fácil compreensão, definido para construir seu código

“Fazer o que você diz:”

• Utilize o processo definido, bem como seus controles
• Capture e aprove seus requisitos com integridade
• Rastreie seus requisitos da implementação ao teste
• Gerencie suas entregas de software para prevenir mudanças não autorizadas
• Utilize os controles de mudanças do seu processo bem como a utilização de métricas de execução e monitoração de uso
• Automatize o seu processo para garantir que suas regras serão seguidas

“Esteja preparado para provar”

• Utilize um ambiente de desenvolvimento colaborativo onde será possível documentar evidências e histórico de aderência aos controles internos através de dashboards, relatórios, histórico de eventos para o processo de auditoria.

Referência

• Software Development Compliance for Regulated Industries
  Nik Teshima – Rational IT Risk Management and Compliance Solution Lead
• Disciplined Agile Delivery
  https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/disciplined_agile_delivery?lang=en_us
• Disciplined Agile Delivery (DAD) Lifecycles
  https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/disciplined_agile_delivery_dad_lifecycle14?lang=en
• Surviving SOX with Scrum
  Simon Roberts MBA and. Dr. Christoph Mathis – Scrum Alliance
  http://www.scrumalliance.org
• Disciplined Agile Delivery (DAD) Lifecycles

  https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/disciplined_agile_delivery_dad_lifecycle14?lang=en_us

***

Sobre a autora: Sandra Sergi Santos é formada pela Universidade Mackenzie e Pós-graduada pela FAAP, atua na área de desenvolvimento de sistemas a 15 anos . Certificada em Scrum Master, RUP (Rational Unified Process) , PMP (Project Management Professional), Gerência de Requisitos e Gerência de Configuração de Mudanças (IBM Rational Team Concert, Requirements Composer, Clearcase e Clearquest). Atualmente trabalha como Especialista em Engenharia de Software na brand Rational da IBM Brasil.

***

A versão original deste artigo está em: http://www.ibm.com/developerworks/br/local/rational/agile_projects_compliance_reqs/index.html