Artigo Engenharia de Software - Melhorando Processos Através da Análise de Risco e Conformidade

Processo

Melhorando Processos Através da Análise de Risco e Conformidade

Um dos fatores importantes para a construção de um software de qualidade é o processo de desenvolvimento utilizado e como este é implantado na organização. A inexistência ou a não utilização de processos bem definidos e de boas práticas de desenvolvimento, mesmo que informais, faz com que o desenvolvimento de software seja realizado de forma ad-hoc, ficando altamente dependente da experiência e do conhecimento das pessoas envolvidas. Este cenário resulta na realização de projetos cujos resultados são imprevisíveis, onde cada um realiza as suas atividades da forma que lhe convém, e dificulta a reutilização de boas práticas e de lições aprendidas.

Com a crescente demanda por qualidade dos produtos de software, a adoção de modelos de maturidade, normas de qualidade e guias de boas práticas na definição de processos tem se tornado cada vez mais freqüente. Modelos como CMMI-DEV e MPS.BR e normas como a ISO/IEC 15504 e 12207 definem um conjunto de boas práticas e características que devem estar presentes em um processo para que este possa ser gerenciado e resulte na entrega de produtos de qualidade. Entretanto, como têm o objetivo de serem aplicáveis a quase todo tipo de organização, estes modelos ou normas muitas vezes não definem como estas boas práticas e características devem ser implementadas e implantadas. Uma das maiores dificuldades de organizações que iniciam um programa de melhoria de processos enfrentam é a dificuldade de adaptar este conjunto de boas práticas para a sua realidade, identificando quais áreas são mais relevantes e devem ser abordadas com maior urgência. Cada organização possui políticas, crenças e uma cultura específica, que deve ser levada em conta para que as melhorias sejam bem aceitas e realmente contribuam com um desenvolvimento mais eficiente.

Para orientar a necessidade de adaptação apresentada acima, utilizamos o conceito de risco associado à não utilização das boas práticas de desenvolvimento de software nos projetos e processos da organização. Consideramos também que a qualidade do produto (software) está diretamente relacionada à qualidade dos processos utilizados na sua produção e ao conhecimento técnico que os usuários deste processo têm sobre as práticas definidas (institucionalização do processo). Partindo-se destas premissas pode-se concluir que qualquer risco à qualidade e à institucionalização do processo se reflete em riscos na qualidade do produto que será entregue e, consequentemente, em riscos para a organização. Sendo assim, ações de gerência de risco nos processos podem contribuir diretamente com a garantia da qualidade do produto final e fornecem dados que permitem identificar quais ações devem ser tomadas com maior urgência.

Neste artigo apresentamos uma abordagem de análise de processos na qual é identificado de forma customizada tanto o nível de conformidade (quantidade de recomendações do modelo de referência implementadas nos processos da organização) quanto o nível de risco (quantidade de riscos presentes no processo de desenvolvimento devido às recomendações não implementadas) em cada área de processo. Dessa maneira, uma análise dos processos da organização fornece duas classes de dados para a tomada de decisão e direcionamento de recursos, indicando o que deve ser feito para melhorar o processo (conformidade) e quais ações devem ser tomadas primeiro (risco).

Uma das formas mais indicadas para a definição e implantação de processos de maneira eficiente é a utilização de um ciclo de melhoria contínua. Esta forma pode ser comparada ao desenvolvimento iterativo de um sistema, onde o processo é definido e implantado na organização em fases direcionadas pelas necessidades e características da organização. O modelo IDEAL, desenvolvido pelo Software Engineering Institute (SEI), ilustra a utilização deste conceito. A implantação deste ciclo de melhoria faz com que os processos de uma organização sejam constantemente avaliados e melhorados.

No modelo IDEAL destacam-se duas fases: Diagnóstico e Estabelecimento. A fase de Diagnóstico consiste em avaliar o ambiente produtivo e identificar as oportunidades de melhoria. Em geral, nesta fase é realizado um estudo no qual um cenário esperado é definido e o cenário atual é avaliado segundo algum critério de qualidade (“Gap Analysis”). O cenário esperado pode ser definido a partir de um ou mais modelos ou normas de referência, como, CMMI-DEV 1.2 ou ISO 9001:2000. Dessa forma, obtém-se a diferença entre o que se espera dos processos da organização e onde eles realmente estão. A partir daí, elaboram-se planos de ação para que esta distância seja diminuída ou eliminada, a partir da priorização e seleção dos planos de ação que serão implantados (fase de Estabelecimento).

A abordagem que apresentaremos facilita a realização das fases de Diagnóstico e Estabelecimento de um ciclo de melhoria contínua, identificando claramente os riscos associados aos processos definidos (Diagnóstico) e fornecendo um critério de priorização destes riscos (Estabelecimento).  Para isso, são utilizadas uma estratégia de avaliação e atividades de avaliação e melhoria de processos de desenvolvimento de software. A avaliação verifica tanto a dimensão de conformidade entre o processo e modelos de maturidade ou normas de qualidade, quanto à dimensão dos riscos que a não utilização das boas práticas definidas nestas referências oferecem à qualidade do produto desenvolvido pela organização e aos seus objetivos de negócio. Esta ferramenta também indica como estes pontos podem ser solucionados de forma que a organização obtenha uma maior qualidade ou resultados a partir deste ciclo. O diferencial desta abordagem é a utilização da análise de risco como um instrumento de priorização das ações que devem ser tomadas pelas empresas para mitigar (reduzir as chances de ocorrência) os riscos identificados durante a fase de diagnóstico fornecendo um critério concreto para definição do escopo de cada ciclo de melhoria.

A próxima seção apresenta alguns conceitos básicos sobre riscos e como este conceito é utilizado neste domínio. Em seguida a estratégia e a ferramenta que compõem a abordagem serão apresentadas e um exemplo da sua utilização será discutido.

Análise de Risco

Risco é a “exposição à chance de perdas ou danos”. Embora exista também uma chance de alguma coisa sair melhor do que o esperado, o risco geralmente costuma ser associado a possíveis perdas ou danos. O conceito de risco resulta da incerteza quanto a eventos futuros e é parte de todas as atividades de desenvolvimento. Um processo de desenvolvimento bem definido e institucionalizado visa reduzir a chance de ocorrência de ameaças (perdas ou danos). Toda oportunidade de sucesso sempre carrega consigo uma possibilidade de falha, cabendo a cada empresa avaliar a relação risco versus retorno e determinar se “estar” sujeito a esta perda é aceitável, se este evento é muito grave, ou ainda se o procedimento para a mitigação não oferece um retorno satisfatório.

Por mais controlada e precisa que seja a execução de uma atividade de desenvolvimento, sempre existe o risco, mesmo que muito remoto, de algo dar errado. Este fato decorre do grande número de variáveis que podem influenciar no resultado final e da sua natureza muitas vezes imprevisível. A partir desse cenário, torna-se necessário aprender a conviver com riscos, minimizando suas possíveis conseqüências negativas.

As principais atividades da disciplina de gerência de riscos são:

·         Identificação corresponde à identificação dos riscos inerentes a uma etapa do desenvolvimento (fase, processo, iteração). Isto é feito através do levantamento das ameaças presentes e do impacto que podem provocar caso se realizem.

·         Análise corresponde à reflexão sobre os riscos identificados, a partir da identificação do nível de exposição de cada projeto. É também realizado um estudo de classificação dos riscos no qual, baseando-se no relacionamento entre a exposição e conseqüência negativa do risco e o benefício da oportunidade, determina-se quais serão eliminados, quais serão mitigados, quais serão aceitáveis e quais serão acompanhados.

·         Planejamento observa e determina como e quando os riscos serão abordados ao longo do projeto. Comumente são elaborados planos de mitigação, eliminação e acompanhamento de riscos que serão utilizados como base para a gerência de riscos.

·         Controle corresponde à execução e ao acompanhamento dos planos elaborados para o projeto. Os riscos identificados são analisados constantemente para a identificação do seu estado atual e atualização dos planos elaborados. Novos riscos podem ser identificados também.

A gerência de riscos utiliza como base o conceito de exposição de risco. Para cada ameaça ou possível fonte de problema que possa causar perdas ao projeto, a exposição (Exp) é definida como o produto da probabilidade da perda ocorrer (P) e do tamanho da perda (impacto I no projeto, artefato, ativo ou qualquer elemento que seja o foco da análise de risco): .

Na abordagem apresentada, o conceito de exposição foi estendido, permitindo uma melhor determinação do impacto da concretização de um risco. Para cada ativo da organização ou projeto avaliado (pessoa que participa do desenvolvimento ou processos utilizados) é determinado um índice de exposição balanceado. Este índice, denominado PSR, determina a exposição através da probabilidade da ocorrência do risco (P), a severidade dessa ocorrência para o projeto ou para a organização (S) e a relevância do ativo da organização (pessoa ou processo) na qualidade do produto final. Dessa forma é possível obter um retrato mais preciso da distribuição e do impacto dos riscos.  

A estratégia de diminuição de riscos utilizada nos planos elaborados durante a atividade de planejamento pode tentar reduzir sensivelmente a probabilidade do risco se realizar, fazendo com que a concretização da perda seja algo muito difícil de ocorrer. É possível tentar reduzir o impacto do risco, fazendo com que a conseqüência da materialização dele seja tão pequena que a sua ocorrência pouco afetará o resultado final do projeto. Por fim, é possível reduzir tanto a probabilidade quanto a severidade do risco, resultando em um balanceamento razoável entre as possíveis perdas e a probabilidade de sua ocorrência no projeto.

A eliminação total dos riscos associados a um projeto ou iniciativa é um conceito utópico. Cada ação de identificação, acompanhamento e controle (redução, mitigação ou contenção de riscos) possui um custo associado, cabendo a cada indivíduo ou organização identificar o ponto de equilíbrio entre o nível de exposição aos riscos e o custo de redução. Para cada projeto ou iniciativa deve-se determinar um índice aceitável de exposição aos riscos, que seja suficiente para as características do projeto e tenha um custo que não comprometa os resultados.

A Estratégia de Avaliação

A estratégia de avaliação que utilizaremos se baseia no conceito de análise de risco na verificação dos processos de uma organização e compreende os conceitos apresentados na ISO/IEC 17799. Esta estratégia recomenda a avaliação de uma equipe de desenvolvimento ou processo de software em duas etapas, onde a primeira (etapa de Abrangência) representa uma verificação mais abrangente e menos rigorosa da implementação dos modelos e normas de referência, para identificar quais são as áreas críticas para a organização (onde está o problema). Na etapa seguinte (etapa de Profundidade) são definidas quais áreas devem ser o foco de uma avaliação mais rigorosa e da próxima iteração do ciclo de melhoria contínua (qual é o problema e como ele pode ser solucionado). Em cada uma das etapas, são realizadas as fases de Diagnóstico (identificação dos riscos) e Estabelecimento (priorização e definição dos planos de ação). Na etapa de Abrangência o diagnóstico é mais abrangente e os planos de ação são menos detalhados e, na etapa de Profundidade, o diagnóstico é mais específico e os planos de ação são mais detalhados.

O objetivo desta estratégia é complementar métodos como SCAMPI, MA-MPS e ISO/IEC 15504, oferecendo propostas de soluções a alguns potenciais problemas encontrados na aplicação destes métodos. Os princípios que guiam a estratégia são:

·         Mapear resultados aos objetivos do negócio da organização;

·         Minimizar o esforço de avaliação segundo critérios de importância definidos pela própria organização;

·         Obter maior aproveitamento dos resultados gerados;

·         Utilizar duas dimensões de análise: conformidade e risco.

O primeiro princípio tem como objetivo sanar uma característica identificada na maioria dos métodos de avaliação de processos de desenvolvimento. De forma geral, a aplicação destes métodos gera conclusões ou resultados que estão restritos ao nível das diretivas do modelo de maturidade ou norma de qualidade utilizada. Este fato faz com que o trabalho de convencimento da alta gerência (geralmente não técnica) acerca da importância dos investimentos em engenharia de software ou qualidade seja dificultado e, consequentemente, o projeto de melhoria de processos fique ameaçado devido à falta de comprometimento dos patrocinadores. O objetivo destes princípios é dar ênfase às necessidades e prioridades da empresa, ao invés de impor uma estrutura que pode não ser a mais adequada a ela. O mapeamento dos resultados do nível de TI para o nível de negócios facilita o seu entendimento, podendo orientar a empresa a como atingir suas metas.

O segundo e terceiro princípio é resultado da constatação de um ponto fraco identificado nos métodos mais utilizados. A grande maioria realiza inspeções e análises rigorosas, que abrangem todo o modelo de referência e geram relatórios com uma grande quantidade de informações sobre diversas áreas da engenharia de software mas, na maioria dos casos, outra grande quantidade de informações é desperdiçada. Uma avaliação indica o estado atual da organização e aponta as oportunidades de melhoria na implementação das diretivas do modelo de maturidade ou norma de qualidade utilizada como referência. Entretanto, devido a restrições de orçamento e ao impacto que elas representam no ambiente produtivo, apenas uma pequena parte destas recomendações pode ser implementada na próxima iteração do programa de melhoria. Após a implementação da primeira iteração de melhoria, o estado da organização já não é o mesmo de quando a avaliação foi realizada, tornando obsoletos os dados relativos às áreas de processos e as oportunidades de melhoria que não foram abordadas. A utilização de uma estratégia em duas etapas permite identificar, através de uma análise menos elaborada, as áreas mais relevantes e realizar uma análise mais elaborada apenas nestas áreas.

Finalmente, o quarto princípio tem como objetivo oferecer dados de um nível de abstração menos granular para a tomada de decisão. Embora a utilização da capacidade de processo e do nível de maturidade seja o parâmetro mais utilizado no direcionamento de recursos na área de desenvolvimento de software, estes conceitos são um tanto abstratos e em muitos casos dificultam esta atividade (se vários processos apresentam a mesma capacidade e o mesmo gap entre a capacidade esperada e a avaliada, qual deve receber os recursos?). A utilização de uma análise de risco oferece um critério de desempate ou uma opção para a priorização de investimentos.

Ferramenta de apoio à avaliação

Para auxiliar a realização da avaliação dos processos de uma organização utilizamos uma ferramenta de apoio à execução de avaliações.

A metodologia de análise de risco implementada pela ferramenta se baseia na avaliação de características de ativos da organização, que podem representar pessoas da organização, processos utilizados, tecnologias e características do ambiente de desenvolvimento. Cada ativo é mapeado em componentes de negócio (para o contexto de desenvolvimento de software foram utilizados objetivos do negócio ou de TI) da organização e possui uma relevância que está diretamente relacionada à relevância dos objetivos aos quais ele se relaciona. A Figura 1 ilustra este conceito.

Figura 1. Mapeamento dos ativos em objetivos do negócio da organização

A cada ativo podem ser associados um ou mais componentes, que representam características que serão avaliadas em um projeto de avaliação que estão relacionadas à participação deste ativo, ou seja, ao adicionar um componente a um ativo estamos dizendo que ele é um coletor de dados que indicam o estado de implementação de um conjunto de boas práticas na organização. Um projeto de avaliação pode utilizar todos os componentes ou apenas um conjunto que seja relevante para esta instância de avaliação. Cada componente possui um checklist associado, composto por um ou mais controles, que representam os itens atômicos de verificação da implementação das boas práticas. Cada controle possui uma estrutura com os seguintes elementos:

·         Nome do Controle indica uma característica (boa prática ou requisito) que deve estar presente no ativo para que o controle seja considerado implementado e seu risco associado seja eliminado.

·         Justificativa define os termos e conceitos necessários para o entendimento do controle e fornece uma justificativa que explique porque aquele controle deve ser implementado. Neste elemento são apresentadas as vantagens que se obtém com a implementação do controle e as conseqüências da sua não implementação.

·         Ameaças indicam quais elementos podem se aproveitar da não implementação do controle para se manifestar e causar danos ao negócio da organização.

·         Recomendação fornece razões e dados para a elaboração de um plano de ação após a realização da avaliação, através de uma sugestão de como o controle pode ser implementado para diminuir a exposição da organização aos riscos e atingir a conformidade desejada com o modelo ou norma de referência.

·         Referências relacionam referências bibliográficas para que mais informações acerca do controle e da sua implementação possam ser obtidas.

·         Probabilidade representa a probabilidade de uma ameaça se manifestar caso o controle não esteja implementado na organização. Este elemento é representado por um número de 1 (menor) a 5 (maior probabilidade).

·         Severidade indica o grau do impacto negativo na organização, caso uma ou mais ameaças se manifestem. Este elemento é representado por um número de 1 (menor) a 5 (maior severidade).

·         Agrupamento indica a qual agrupamento o controle pertence. Os agrupamentos são comuns a todos os checklists, permitindo verificar o estado da implementação de características espalhadas em vários checklists.

A Tabela 1 apresenta um exemplo de controle de uma prática de gerência de configuração.

Tabela 1. Exemplo de controle

A avaliação consiste em responder aos checklists associados aos ativos e selecionados na configuração do projeto de avaliação. Estes podem ser respondidos diretamente ou através de questionários enviados via WEB, onde o conteúdo dos controles pode ser interpretado para um domínio específico, por exemplo, para os diversos papéis de uma organização. A utilização dos questionários permite um ganho de escala e de cobertura da avaliação, ao mesmo tempo em que diminui o impacto da avaliação e aumenta a aceitação das melhorias no processo de desenvolvimento uma vez que todos se sentem parte da avaliação e podem contribuir com comentários e sugestões.

Após a coleta dos dados, é gerado um conjunto de relatórios contendo tabelas e gráficos que indicam o estado da implementação das boas práticas e os riscos presentes na organização e fornecem dados para a tomada de decisão (o que e como deve ser feito). Cada controle não implementado ou implementado parcialmente, contribui com um índice de risco (PSR) que é obtido pela multiplicação da relevância do ativo avaliado (R), da probabilidade da concretização das ameaças possíveis (P) e da severidade desta concretização (S) . Além do PSR, os seguintes indicadores são utilizados:

Índice de Segurança =

Índice de Conformidade =

A partir destes índices, pode-se gerar um grande número de interpretações, através da filtragem e agrupamento de dados das áreas de processo, ativos, ameaças, departamentos ou objetivos de negócio.

Utilizando a Abordagem

Para utilização desta abordagem em uma avaliação, utilizamos um conjunto de atividades.

A primeira atividade consiste na criação de um processo padrão para a área de processo de definida em algum modelo ou norma de referência, como Gerência de Configuração e Solução Técnica do CMMI, ou grupo de áreas de processo, que será utilizado como base para a elaboração das recomendações de implementação de controles. Esta atividade possui tarefas de elaboração e revisão de conteúdo e aderência aos modelos ou normas de qualidade utilizadas como referência. Em seguida, atividades de geração e revisão de arquitetura dos checklists são executadas de forma iterativa e concorrente, até que um produto com qualidade assegurada seja desenvolvido. A arquitetura do checklist consiste da identificação dos controles que serão desenvolvidos e dos questionários que serão utilizados como coletores automáticos de dados.

Tendo um conjunto revisado dos controles que devem ser implementados e um questionário que interpreta e responde estes controles do checklist através de uma lógica bem definida para as suas perguntas, inicia-se uma nova etapa de implementação e revisão dos controles, onde o conteúdo dos controles identificados é elaborado e o questionário desenvolvido é refinado. Finalmente, os checklists são homologados e adicionados à ferramenta.

Tendo um guia para a elaboração dos checklists, o segundo passo é a identificação dos checklists que seriam utilizados para a realização das avaliações. Como os checklists são associados aos ativos da organização, através dos componentes, esta atividade foi realizada utilizando como parâmetro os tipos de ativos.

A ferramenta define quatro tipos de ativo para a realização das avaliações: “Pessoa”, “Processo”, “Ambiente” e “Tecnologia”. Para o domínio de processos de desenvolvimento, definiu-se que cada ativo funciona como uma dimensão de coleta de dados sobre os processos da organização, das pessoas, dos fornecedores ou do projeto ao qual ele pertence.  Sendo assim, chegou-se a seguinte taxonomia para os ativos:

·         Processos representam fluxos de trabalho, áreas de processo ou disciplinas da organização. Cada checklists associado a este tipo de ativo possui o escopo de uma área de processo do modelo de maturidade ou norma de qualidade. A utilização destes ativos define uma dimensão da avaliação onde os processos são o principal fator para o alcance dos objetivos da organização e, consequentemente, a principal fonte de evidências da implementação do modelo ou norma de referência.

·         Pessoa representa os atores da organização. Os checklists associados a este tipo de ativo verificam as diretivas da norma relativas a um papel da organização (desenvolvedor, gerente, analista de requisitos, etc.) que é assumido pela pessoa que é referenciada pelo ativo. A utilização de ativos do tipo Pessoa define uma dimensão da avaliação onde as pessoas e os papéis que elas executam são o principal fator para o alcance dos objetivos da organização e, consequentemente, a principal fonte de evidências da implementação do modelo ou norma de referência.

·         Ambiente representam o ambiente organizacional, caracterizado pelas acomodações, aspectos inter-pessoais, política motivacional e outros fatores que afetam indiretamente a execução dos processos. Os checklists associados a este tipo de ativo verificam as características gerais da organização e como ela contribui ou não com o alcance dos objetivos da organização.

·         Tecnologia representa a estrutura tecnológica da organização, definida por suas máquinas e ferramentas.  Os checklists associados a este tipo de ativo verificam características da infra-estrutura referenciada pelo ativo, como segurança em servidores, funcionalidades de ferramentas, entre outros.

Como terceiro passo da customização, a estrutura para a geração de checklists foi elaborada. Esta atividade contou com a definição dos agrupamentos, ameaças e do escopo dos controles.

Como o objetivo da avaliação é obter resultados mapeados nas áreas de processo do modelo ou norma de qualidade de referência, independente de quais ativos foram utilizados para coletar os dados, foi definido que os agrupamentos utilizados seriam as áreas de processo.

Uma área de processo possui características específicas, que determinam a sua implementação, e características comuns a todas as áreas, que indicam a sua capacidade. Para facilitar a utilização de modelos de maturidade que utilizam o conceito de capacidade de processos foi definido também que deve existir um agrupamento para cada nível de capacidade.

A Figura 2 ilustra este conceito para o CMMI-DEV 1.2, onde um Checklist para o ativo desenvolvedor (papel) contém os agrupamentos Definição do Processo Organizacional, Desenvolvimento de Requisitos, Foco no Processo Organizacional, Garantia da Qualidade, Gerência de Configuração e Gerência de Requisitos que representam as características específicas de cada área de processo e o agrupamento GG2 – Processo Gerenciado representa as características genéricas. Estão também ilustrados controles dos agrupamentos de Gerência de Configuração e Gerência de Requisitos.  Cada agrupamento contém um conjunto de controles.   

Figura 2. Checklist com agrupamentos para características específicas e genéricas

Com a estrutura de agrupamentos definida, os resultados das análises de risco e conformidade podem ser consolidados pelos agrupamentos, resultando em relatórios (exemplificados no próximo tópico), que indicam risco e conformidade de cada área de processo, e que deixam de forma transparente quais tipos de ativo foram utilizados.

Para o escopo dos controles, foi definida a utilização do item de menor granularidade do modelo ou norma de referência. Como em muitos modelos e normas o item de menor granularidade possui mais de um item de verificação em seu escopo, foi definida também a realização de uma análise da atomicidade. Esta análise tem como objetivo quebrar o item em elementos de verificação atômicos, evitando situações de falha no preenchimento do controle (se existem dois ou mais pontos de verificação conectados por um operador “e” ou “ou” em um controle, como respondê-lo no caso de alguns estarem implementados e outras não?).

Finalmente, para uniformizar as análises de risco e conformidade em processos de desenvolvimento realizados com a utilização da ferramenta, foi elaborada uma lista de ameaças.

Tendo em vista que a grande maioria dos métodos de avaliação de processos de desenvolvimento (SCAMPI, MA-MPS, ISO/IEC 15504) utiliza uma estrutura de níveis para a classificação da implementação de uma diretiva do modelo ou norma, utilizamos nesta solução a mesma abordagem. Desta forma, cada controle pode ser classificado como “Implementado”, “Não Implementado” ou “Parcialmente Implementado”. Partindo do fato de que um controle parcialmente implementado não se encontra implementado, foi determinado que, quando a análise realizada indicasse que um controle não foi totalmente atendido, este deve ser preenchido como “Não implementado”. Utilizando a premissa de que um controle parcialmente implementado possui uma probabilidade menor de causar danos do que um controle não implementado, foi determinado que, para cada nível de implementação atingido pelo controle, a sua probabilidade será diminuída em uma unidade, até chegar ao valor mínimo 1.

Para exemplificar a abordagem, considere um controle cuja probabilidade seja quatro. Em uma avaliação que utiliza o modelo CMMI como referência, um controle classificado como parcialmente implementado será preenchido como Não Implementado e a sua probabilidade será alterada para três. O resultado desta abordagem é que, ao final da análise de risco, os controles parcialmente implementados contribuirão com menos risco do que os controles do mesmo tipo classificados como não implementados.

Utilizando a abordagem

Para demonstrar a aplicabilidade da abordagem proposta, foram realizados vários estudos de caso, nos quais o processo utilizado por equipes de desenvolvimento de software de organizações distintas foi avaliado.  A seguir, é apresentado um resumo de uma das avaliações realizadas onde se realizou apenas a etapa de Abrangência. Para preservar a confidencialidade, as informações apresentadas foram descaracterizadas (ver Tabela 2).

Tabela 2. Resumo do objetivo e escopo da avaliação

A avaliação considerou somente o perfil de desenvolvedor, portanto o peso das áreas técnicas do modelo será maior que o peso das áreas de gestão ou das áreas organizacionais. Além disso, nesta etapa, os objetivos do negócio da organização não foram identificados e mapeados nos ativos de software.

Abaixo são apresentados os resultados da avaliação:

Conforme apresentado na Tabela 3 e na Figura 3, as áreas de Planejamento de Projetos, Solução Técnica e Definição do Processo Organizacional têm o maior índice de Segurança indicando que a maior parte das práticas destas áreas estão implementadas. Ao contrário, as áreas de Treinamento Organizacional, Gerência de Requisitos, Integração do Produto e Gerência de Configuração têm o menor índice de Segurança indicando que poucas práticas destas áreas estão implementadas. As áreas de Definição do Processo Organizacional, Medição e Análise, Monitoramento e Controle de Projetos e Gerência de Configuração têm um índice de Conformidade relativamente maior que o índice de Segurança indicando a implementação de práticas pouco eficientes na mitigação dos riscos.

Tabela 3. Resultados da avaliação em abrangência por área de Processo

Figura 3. Resultados da avaliação em Abrangência – Gráfico de Índices de conformidade e segurança para cada área de Processo (Ordenação decrescente pelas áreas de maior índice de Segurança)

De acordo com a Figura 4, pode-se verificar que as áreas de Gerência de Configuração, Verificação, Integração do Produto, Desenvolvimento de Requisitos e Gerência de Requisitos têm maior PSR Não implementado indicando maior probabilidade de manifestação dos riscos durante sua execução. Ao contrário, as áreas de Definição do Processo Organizacional, Avaliação e Melhoria do Processo, Planejamento de Projetos e Medição e Análise têm menor PSR não implementado, indicando menor probabilidade de manifestação dos riscos durante sua execução. 

As áreas de Solução Técnica, Planejamento de Projetos e Monitoramento e Controle de Projetos têm maior PSR implementado, indicando a implementação de práticas que evitaram a manifestação de um maior número de riscos.

Figura 4. Resultados da avaliação em Abrangência – Gráfico de PSR por área de Processo (Ordenação decrescente pelas áreas de maior PSR)

Verificando as informações apresentadas na Tabela 4 e nas Figuras 5 e 6, conclui-se que na organização, as áreas de Gerência de Configuração, Verificação, Integração do Produto, Desenvolvimento de Requisitos e Gerência de Requisitos têm maior probabilidade de manifestação dos riscos durante sua execução. Entretanto, quando os dois setores são avaliados separadamente conclui-se que:

o        No Setor 1 as áreas de Gerência de Configuração, Solução Técnica, Integração do Produto, Verificação, Desenvolvimento de Requisitos e Gerência de Requisitos têm maior probabilidade de manifestação dos riscos durante sua execução, ou seja, a área de Solução Técnica tem um peso importante nos riscos das atividades do Setor 1;

o        No Setor 2, as áreas de Verificação, Desenvolvimento de Requisitos, Gerência de Configuração, Integração do Produto e Gerência de Requisitos têm maior probabilidade de manifestação dos riscos durante sua execução, ou seja, o mesmo resultado da organização com a inversão de algumas posições.

Tabela 4. Resultados da avaliação em Abrangência – por Setor e Área de Processo

Figura 5. Resultados da avaliação em Abrangência – Gráfico de PSR do Setor 1 por Processo (Ordenação decrescente pelas áreas de maior PSR)

Figura 6. Resultados da avaliação em Abrangência – Gráfico de PSR do Setor 2 por Processo (Ordenação decrescente pelas áreas de maior PSR)

Pelo apresentado na Figura 7, as ameaças mais relevantes estão relacionadas com:

o        Produto não atender às necessidades dos clientes - Desenvolvimento de Requisitos, Verificação e Validação;

o        Requisitos incompletos, inconsistentes ou incorretos - Gerência e o Desenvolvimento de Requisitos e Verificação;

o        Software apresentar falhas – Solução Técnica, Integração do Produto e Verificação;

o        Perder controle sobre as solicitações de mudança - Gerência de Requisitos e Gerência de Configuração.

Figura 7. Resultados da avaliação em Abrangência – Ameaças

Como resultado final da avaliação, definiu-se um plano priorizando ações de melhoria nas áreas de Gerência de Configuração, Desenvolvimento de Requisitos e Gerência de Requisitos, que apresentaram um alto PSR não implementado, combinado com um baixo índice de segurança. Para um melhor detalhamento das ações de melhoria foi sugerida também a realização de uma avaliação em Profundidade para cada uma das três áreas mencionadas.

Em um segundo momento, foram sugeridas ações de melhoria para as áreas de Verificação e Integração do Produto, devido ao alto PSR não implementado e o estabelecimento de uma política de Treinamento Organizacional, pois apesar do PSR desta área ser menor, o índice de segurança é muito baixo. Da mesma forma foi sugerida uma avaliação em Profundidade para cada uma das três áreas mencionadas.

Foram também sugeridas ações de melhoria para o Setor 1 na área de Solução Técnica.     

Conclusão

Neste artigo apresentamos uma abordagem que define um critério concreto para priorização de melhorias a serem realizadas nos processos de desenvolvimento de software de uma organização. Este critério utiliza a análise de risco como um instrumento de priorização das ações que têm maior eficiência na mitigação das ameaças identificadas durante o diagnóstico da situação atual. A relevância das ameaças é definida com base no atendimento aos objetivos de negócio da organização e na conformidade com modelos e normas de qualidade de software.

BOEHM, B. W. Software Risk Management: Principles and Practices. IEEE Software, v. 8(1), p. 32-41, jan. 1991.

BOEHM, B. W.; DEMARCO, T. Software Risk Management. IEEE Software, v. 14(3), p. 17-19, mai./jun. 1997.

CHRISSIS, M.B.; KONRAD, M.; SHRUM, S. CMMI: Guidelines for Process Integration and Product Improvement. Boston: Addison-Wesley, 2003.

DEMARCO, T; LISTER, T. Waltzing with Bears: Managing Risks on Software Projects. New York: Dorset House Publishing, 2003.

GREMBA, J.;MYERS, C. The IDEALSM Model: A Practical Guide for Improvement. 1997.    Acesso em 18 nov.2006.

ISO/IEC. Guide 73:2002. Risk management -- Vocabulary -- Guidelines for use in standards, Reference No. ISO/IEC Guide 73:2002(E).

____. International Standard 12207. Information Technology – Software Life Cycle Processes, Reference No. ISO/IEC 12207: 1995(E): First Edition 1995.

____. International Standard 15504. Information Technology – Proces Assessment, Reference No. ISO/IEC 15504:2004(E).

____. International Standard 17799. Information Technology – Security Technics - Code of practice for information security management, Reference No. ISO/IEC 17799:2005(E): Second Edition 2005.

____. Technical Report 13335 – 1.Information technology - Guidelines for the management of IT Security - Part 1: Concepts and models for IT Security, Reference No. ISO/IEC TR 13335: 1996(E).

IT GOVERNANCE INSTITUTE (ITGI). Control Objectives for Information and Related Technology (COBIT).

POULIN, A. Reducing Risk with Software Process Improvement. Boca Raton: Auerbach Publications, 2005.

SOFTEX.. MPS.BR – Melhoria de Processo do Software Brasileiro. Guia de Avaliação. Versão 1.0, 2006a.

____. MPS.BR – Melhoria de Processo do Software Brasileiro. Guia Geral. Versão 1.1, 2006b.

SOFTWARE ENGINEERING INSTITUTE (SEI). Appraisal Requirements for CMMI, Version 1.2 (ARC, V1.2). Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, 2006a

____. CMMI for Development, Version 1.2. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, 2006b.

____. Standard CMMI Appraisal Method for Process Improvement (SCAMPI[SM]) A, Version 1.2: Method Definition Document. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, 2006c