uma aplicação de marps para gerenciamento de risco em … · qualidade, e por fim a lógica ......

107

Informática Pública ano 11 (1) 107 – 124, 2009

Uma Aplicação de MARPS para Gerenciamento de Risco em uma Fábrica de Software

denis ávila Montini1

Mauri aPareCido de oliveira 2

alessandra de ávila Montini3

Palavras-Chave

MARPS, Fábrica de Software, SWOT, ISO-9126.

resumo Este artigo propõe um modelo de aplicação para análise de riscos, que integra um plano de ação que abrange os níveis estratégicos, táticos e operacionais sugeridos pela análise SWOT, no entanto o conceito clássico SWOT foi adaptado para projetos de software. A empresa estudada aplicou aos projetos de software um plano de qualidade referenciado com modelos CMMI e ISO-9126. Neste estudo de caso, houve a necessidade de se utilizar uma técnica que permitisse incorporar os conceitos de quadrantes da SWOT com medidas escalares. Propôs-se a indexação da SWOT com a Lógica Paraconsistente Anotada Bivalorada - LPA2v para resolver a tarefa de representar graficamente de uma forma escalar as informações quantificadas e qualificadas.

1. Introdução

Durante o desenvolvimento de diferentes projetos de software voltados para a área financeira, notou-se a carência de um modelo para a análise de risco em projetos de software, que auxilie os desenvolvedores, no que se refere à busca dos pontos fracos, fortes e oportunidades de melhoria no projeto, além de uma forma de representação gráfica para este modelo de informações. Com isso, ocorriam situações em que os riscos ocorriam e eram contigenciados e não mitigados.

Neste artigo, serão apresentados os conceitos utilizados no desenvolvimento de um Modelo para Análise de Riscos para Projetos de Software – MARPS, [Mont05], utilizando três métodos integrados, análise da ISO-9126 [ABNT03], no embasamento da coleta de evidências, pela análise Forças – Strengths – Fraquezas, Weaknesses, Oportunidades – Opportunities e Ameaças – Threats (SWOT) [Hump60], para a indexação dessas evidências à referência de qualidade, e por fim a Lógica Paraconsistente Anotada Bivalorada – LPA2v [Costa99], como método de apoio para as tomadas de decisões nas mitigações e contingenciamento para os riscos de projeto.

Estes métodos usados para se desenvolver o MARPS foram utilizados em um cenário de fábrica de software, nos quais se mapearam as tomadas de decisões pela representação gráfica

1 E-mail: [email protected] E-mail: [email protected] E-mail: [email protected]

Artigo

108

Denis Ávila Montini, Mauri Aparecido de Oliveira, Alessandra de Ávila Montini

dos conflitos de informações no projeto. O método de pesquisa foi utilizado em casos de uso de desenvolvimento de projetos

de componentes de software em diferentes graus de customizações, por meio de entrevistas e observações diretas, para representar os diferentes graus de Risco do projeto.

Durante o desenvolvimento de diferentes projetos de software voltados para a área financeira, notou-se a carência de um modelo para a análise de risco em projetos de software, que auxilie os desenvolvedores, no que se refere à busca dos pontos fracos, fortes e oportunidades de melhoria no projeto, além de uma forma de representação gráfica para este modelo de informações. Com isso, ocorriam situações em que os riscos ocorriam e eram contigenciados e não mitigados.

Neste artigo, serão apresentados os conceitos utilizados no desenvolvimento de um Modelo para Análise de Riscos para Projetos de Software – MARPS, [Mont05], utilizando três métodos integrados, análise da ISO-9126 [ABNT03], no embasamento da coleta de evidências, pela análise Forças – Strengths – Fraquezas, Weaknesses, Oportunidades – Opportunities e Ameaças – Threats (SWOT) [Hump60], para a indexação dessas evidências à referência de qualidade, e por fim a Lógica Paraconsistente Anotada Bivalorada – LPA2v [Costa99], como método de apoio para as tomadas de decisões nas mitigações e contingenciamento para os riscos de projeto.

Estes métodos usados para se desenvolver o MARPS foram utilizados em um cenário de fábrica de software, nos quais se mapearam as tomadas de decisões pela representação gráfica dos conflitos de informações no projeto.

O método de pesquisa foi utilizado em casos de uso de desenvolvimento de projetos de componentes de software em diferentes graus de customizações, por meio de entrevistas e observações diretas, para representar os diferentes graus de Risco do projeto.

2. Contexto

Na realização de projetos, são frequentemente encontrados fatores não mensuráveis, intangíveis e conflitantes, nos quais as questões que envolvem fenômenos não previstos nas equações de dimensionamento de projetos de software, neste caso Análise de Ponto de Função (APF) [Albr81], que embasam o planejamento da engenharia de software. Nestes planejamentos, os números são expostos buscando a precisão segundo técnicas sofisticadas e usadas neste segmento da ciência computacional.

Neste cenário, a análise de risco no desenvolvimento de software mostra sua relevância, pois, muitas vezes, os desenvolvedores de software ou contratantes deste tipo de serviço precisam de competitividade e, devido a esforços e à eficiência de seus processos, quando problemas específicos aparecem, torna-se difícil identificá-los, mitigá-los e contingenciá-los, evitando assim maiores prejuízos. Segundo o modelo de Porter [Port86], as raízes da competitividade de um negócio estão relacionadas com a sua estrutura econômica, ou seja, no controle dos elementos que constituem um risco econômico para um empreendimento.

3. ProBlema

O problema consistiu em dotar os profissionais envolvidos com o planejamento de engenharia, da Fábrica de Software da Tata Consultancy Services – TCS de São Paulo, de um Modelo para Análise de Riscos em Projetos de Software, que permitisse representar

109


graficamente o projeto e as anomalias para compor o SWOT, que fossem identificadas durante o processo de desenvolvimento, visando garantir que os riscos do projeto fossem identificados, analisados, documentados, monitorados, reduzidos e controlados.

4. metodologIa

As aquisições dos dados que formaram a base dos estudos experimentais procederam do processo de auditoria formal interna. Os dados e as interpretações decorrentes do uso desta metodologia tornaram-se evidências categorizadas, durante o desenvolvimento de software. Tais evidências são fundamentais para empresas, com experiência no uso da ISO 9126 [ABNT03], em auditorias formais internas consolidadas nas análises de não conformidade, GAP’s, previstas no programa de do Modelo de Integração de Capacitação de Maturidade, Capability Maturity Model Integration - CMMI [CMMI06], nível 2, particularmente nas áreas de utilização da qualidade de software, Process and Product Quality Assurance - PPQA, prestadoras deste tipo de serviço.

Durante o desenvolvimento de um produto de software, foi realizada uma avaliação de risco através de uma auditoria de qualidade, com o propósito de expor o processo para localizar e coletar as evidências dos elementos favoráveis e desfavoráveis do projeto. Para a seleção dos assuntos a serem pesquisados foi escolhido arbitrariamente um cenário específico de utilização, contendo os conceitos delimitados pela customização da ISO 9126 [ABNT03], para a validação de produtos de software. A modelagem de risco foi derivada do modelo de indicadores de risco para células de manufatura desenvolvida por MONTINI [Mont05].

O Quadro 01 contém as subcaracterísticas abstraídas da norma, que fundamentaram o desdobramento dos “fatores” que formaram a base da modelagem paraconsistente explicada na sequência deste artigo. Para cada elemento identificado da ISO 9126 [ABNT03], descrito na coluna “Subcaracterísticas – Fn” do Quadro 01, atribuiram-se variações, que foram definidas ao entrevistar um envolvido. A essas variações atribuiu-se um valor de acordo com a seguinte variabilidade semântica: 1 - Certeza da ocorrência, 2 - Altamente provável, 3 - Provável, 4 - Pouco provável, 5 - Improvável, 6 - Altamente improvável e 7 - Certeza da não ocorrência. As subcaracterísticas enumeradas no Quadro 01 foram fundamentais para a classificação que foi realizada na Lógica Paraconsistente Bivalorada Anotada - LPA2v, prevista por Da Costa [Costa99] [Tset95].

110

Quadro 01 – Escopo da norma ISO/IEC 9126


Subcaracterísticas – Fn Perguntas chave para a subcaracterísticas

1 Adequação Propõe-se a fazer o que é apropriado?

2 Acurácia Faz o que foi proposto de forma correta?

3 Interoperabilidade Interage com os sistemas especificados?

4 Conformidade Está de acordo com as normas, leis etc. ?

5 Segurança de acesso Evita acesso não autorizado aos dados?

6 Maturidade Com que frequência apresentam falhas?

7 Tolerância a falhas Ocorrendo falhas, como reage?

8 Recuperabilidade É capaz de recuperar dados em caso de falha?

9 Inteligibilidade É fácil entender o conceito e a aplicação?

10 Apreensibilidade É fácil aprender a usar?

11 Operacionalidade É fácil de operar e controlar?

12 Tempo Qual é o tempo de resposta, a velocidade de execução?

13 Recursos Quantos recursso usa? Durante quanto tempo?

14 Analisabilidade É fácil de encontrar uma falha quando ocorre?

15 Modificabilidade É fácil modificar e adaptar?

16 Estabilidade Há grande risco quando se fazem alterações?

17 Testabilidade É fácil testar quando se fazem alterações?

18 Adaptabilidade É fácil adaptar a outros ambientes?

19 Capacidade para ser instalado É fácil instalar em outros ambientes?

20 Conformidade Está de acordo com padrões de portabilidade?

21 Capacidade para substituir É fácil usar para substituir outro?

Fonte: [Mont0] Apud, [TsuK95]

Um dos fatores considerados foram que, para um mesmo evento, com as mesmas regras e condições, dois especialistas em um mesmo assunto, experiência e conhecimentos, podem realizar análises independentes e distintas, que podem ser concordantes, discordantes ou até mesmo contraditórias e concorrentes. Dado este evento, foi possível a verificação e validação dos diversos argumentos, e das análises procedentes, que foram evidenciados para poder pertencer à massa crítica de análise.

Houve então a associação de uma medida, descrita e passível de verificação pelas evidências geradas, quantificadas e associadas a uma incerteza. Criou-se então uma dificuldade na representação dessa contradição e na definição de áreas de atuação, que possibilitam a

111

determinação de planos de ações setoriais; esta dificuldade foi sanada com o uso do método LPA2v que propiciou a visualização dessas contradições mediante uma instrumentação gráfica do processo de tomada de decisões.

4.1 a sOluçãO: a inTegraçãO De TrÊs méTODOs COmplemenTares

4.1.1 Método aplicado para a técnica SWOT

O uso da análise SWOT foi verificado quando, após um processo formal de auditoria, houve a necessidade de se estabelecerem orientações e recomendações sobre os desvios e anomalias encontrados, assim como dos estudos de Gap Analysis durante as fases de projeto. O processo de Gap Analysis ou de diagnóstico da situação atual serviu para fornecer os parâmetros necessários para a montagem de um plano adequado de implementação, ou ainda para revisar o plano de implementação em curso.

É objetivo deste trabalho identificar as lacunas existentes, Gap Analysis, no processo de desenvolvimento de software que serve como uma fonte de pesquisa para a identificação e diagnóstico dos pontos de não conformidade entre o estabelecido e o encontrado, de acordo com um modelo ou padrão de qualidade estabelecido. Este processo foi reaplicado nas fases de auditorias dos projetos, com o objetivo de buscar as evidências para a próxima etapa do SWOT.

Na análise SWOT, existem quatro categorias baseadas em dois conjuntos de conceitos: (Interno versus Externo) e (Positivo versus Negativo). É aconselhável a utilização da análise SWOT somente após terem sido estabelecidas as metas e objetivos a serem analisados; diversos tipos de cenários podem ser escolhidos a fim de se conhecer, mediante uma pesquisa investigativa, as forças e fraquezas do projeto. Neste trabalho, a contextualização foi realizada pela equipe do CMMI, tendo como base a ISO 9126.

As evidências coletadas são significativas, apenas quando orientam ou impedem a organização de satisfazer a uma necessidade do consumidor, contrato ou lei, e devem focar nos processos gerenciais ou nas soluções que sejam importantes para atender as necessidades do consumidor; no entanto, as oportunidades e ameaças que ocorram nos ambientes externos à empresa não devem ser ignoradas à medida que a organização não esteja interessada em ser uma organização eficiente, mas ineficaz.

4.1.2 O método SWOT customizado

As tarefas específicas foram definidas por atividades. Decorrente desse fato, o método SWOT foi obtido por meio de um processo que organizou as informações obtidas pela auditoria.

Cada análise leva em conta a capacidade de percepção dos fenômenos que dependem do ambiente. Uma oportunidade também pode ser uma ameaça quando não realizada e, por sua vez, um ponto forte pode ser um ponto fraco em outro cliente ou cenário.

O método foi obtido com a utilização de quatro tarefas principais:

� Tarefa 1: Realizar a avaliação SWOT – após auditoria ISO. � Tarefa 2: Equiparação de Forças e Oportunidades. � Tarefa 3: Estudo de conversão de Fraquezas em Forças, Ameaças em Oportunidades

e de Oportunidades em Forças. � Tarefa 4: Desqualificação das Fraquezas e ameaças que não podem ser transformadas.


112

ParticpantesSomatória 1 2 3 4 5 6 7 O - Opportunities - Pontos Oportunidades

4 1 1 1 1 Integração das ferramentas do projeto

2 1 1 Criação de novos indicadores. Exemplos: Produtividade.

1 1 Clarity1 1 Project Server

ParticpantesSomatória 1 2 3 4 5 6 7 S - Strengths - Pontos fortes

7 1 1 1 1 1 1 1 Monitoramento

6 1 1 1 1 1 1 Padronização

6 1 1 1 1 1 1 Compromentimento e formalização.3

1 1 1 Template_Medicoes_Coleta_Analise_V4.xls - Identificação da Variação de Cornograma

2 1 1 Metadados

ParticpantesSomatória 1 2 3 4 5 6 7 W - Weaknesses - Pontos Fracos, Vulnerabilidades

6 1 1 1 1 1 1 F05 - Relatório de Desempenho do Projeto V3 Draf.doc

3 1 1 1 Utilização, treinamento Harvest - indefinição da utilização das documentações

3 1 1 1 Suporte técnico ao projeto

2 1 1 F07 - Registro de Monitoramento do Processo v1.doc

2 1 1 GPS

2 1 1 Perda de prioridade pela Média Gerência e pela área usuária

2 1 1Aparecimento de outros trabalhos mais urgentes, impactando no tempo de utilização dos processos que dificulta a assimilação do projeto.

2 1 1 Utilização do Oracle, espaço em disco

1 1 Falta de conhecimento na gestão de projeto para seguir o processo.

Quadro 02 – Resultados das quatro avaliações das dimensões SWOT


ParticpantesSomatória 1 2 3 4 5 6 7 T - Threats - Ameaças

4 1 1 1 1 Indisponibilidade do servidores. Infraestrutura perda de dados do projeto.

1 1 Equipe restrita e mudanças organizacionais.

113

Combinação

AMEAÇAS

Minimizar / Evitar

FRAQUEZAS

Minimizar / Evitar Combinação

OPORTUNIDADES

Conversão

FORÇAS

Tarefa 1 – A avaliação SWOT customizada

A avaliação SWOT foi baseada em um conjunto de entrevistas estruturadas com os participantes dos projetos, nos quais, de forma anônima, verbalizaram suas percepções sobre a operação. A verbalização ocorreu em dois momentos distintos, antes do começo da operação e depois da sua realização.

Como resultado da primeira tarefa, apresentam-se, a seguir, as informações tabuladas com a ponderação realizada pelo total de respondentes, sete entrevistados. O resultado foi agrupado por conceitos comuns, organizados em torno de uma oração descrita em relação à qual todos os entrevistados concordaram que manteve o sentido original. No Quadro 02, apresentam-se os quatro Quadros em que se relacionam alguns dos resultados apontados.

Neste estudo de caso, foram selecionados os sete participantes que cuidavam de projetos distintos, porém com as mesmas características. A cada participante solicitou-se a apresentação dos pontos fortes e fracos, oportunidades e ameaças em dois momentos distintos dos projetos, respectivamente antes e depois do processo de auditoria da ISO 9126. Um especialista ficou responsável por realizar a padronização e o agrupamento dos assuntos coletados; o resultado desta atividade do processo de pesquisa foi tabulado e agrupado por afinidades de assuntos.

Tarefa 2 – A equiparação de Forças e Oportunidades

Os stakeholders tiveram que avaliar os processos dentro do programa de qualidade estabelecido pelo CMMI. A área de processos PPQA baseou-se nas percepções dos participantes durante o processo de avaliação das forças e fraquezas do objeto de estudo. A empresa possuía, nos projetos, necessidades particulares nas quais a conversão da percepção em dados foi necessária para a representação gráfica dos acontecimentos segunda a notação SWOT. O método ofereceu soluções para os problemas potenciais dos participantes, em produtos e serviços específicos.


Figura 01 – Figura do conceito da análise SWOT

A FIG. 01 representa o modelo SWOT convencional, proposto para ser utilizado na formulação de estratégica que busca atingir uma adequação entre as capacidades internas e as possibilidades externas.

É neste tipo de representação que se pode estabelecer um plano de ação para integrar os três níveis – estratégicos, táticos e operacionais, de forma que é possível atuar em cada um dos quadrantes em quaisquer fases ou atividades da empresa. Neste artigo, ambientamos o conceito SWOT clássico com uma adaptação para projetos. Cabe a cada empresa desenvolver

114

os seus respectivos planos para cada uma dessas questões de adaptação e ambientação. Há a necessidade de se utilizar uma técnica que permita incorporar os conceitos de quadrantes da SWOT com medidas escalares. Nesta pesquisa, é proposta a indexação da SWOT com a LPA2v para atender o fato de representar quantitativa e qualitativamente de uma forma escalar.

Figura 02: QUPC – Quadrado Unitário do Plano Cartesiano e as respectivas regiões

y

x

A = (0 , 0)paracompleto

C = (1 , 1)inconsistente

B = (0 , 1)falso

0

1

D = (1 , 0)verdadeiro

1

µ2 = grau deevidênciacontrária

µ1 = grau deevidênciafavorável


Tarefa 3: Estudo de conversão de Fraquezas em Forças, Ameaças em Oportunidades e de Oportunidades em Forças.

O método aplicado para a lógica LPA2v foi estudado por [Costa99] no qual se sugere que: “...nessa Lógica, as anotações são representativas de graus de evidências e falta de evidências atribuídos à proposição, dando-lhe conotações de valoração...”. Após a valoração dos graus de evidências e descrenção, obtidos durante o GAP analysis, para cada resposta foi atribuído graficamente um ponto no Quadrado Unitário do Plano Cartesiano - QUPC, representado na FIG.2.

Essa Lógica consiste em estabelecer as proposições e parametrizá-las, de forma a poder isolar os fatores de maior influência nas decisões por meio de especialistas. A obtenção de anotações para esses fatores é realizada, atribuindo-lhes um grau de evidências (m1) e um grau de falta de evidências (m2). Nota-se que a valoração de cada um esses valores são independentes, e a variação é definida dentro do intervalo compreendido entre “0” e “1” no eixos cartesianos [Carv02] [Carv03].

O QUPC pode ser subdividido em subáreas de forma a evidenciar diversas características, apresentado na FIG. 02 e explicado no Quadro 03. Selecionou-se um grau de exigência para atender um dos requisitos de uso da técnica LPA2v, após a atribuição gráfica dos pontos 1 e 2 no QUPC. Esta seleção deveria ser feita preferencialmente por meio de bases de dados históricos; na inexistência dessas informações, foi válida a utilização de uma percepção que o líder do projeto tinha a respeito da seleção do grau de exigência.

115

Quadro 03 – Legenda da Divisão do reticulado τ em 12 regiões.Da Costa et al (1999)

LegendaRegiões Estados resultantes

A Inconsistente

B Paracompleto

C Falso

D Verdadeiro

E Quase falso tendendo ao inconsistente

F Quase falso tendendo ao paracompleto

G Quase verdadeiro tendendo ao paracompleto

H Quase verdadeiro tendendo ao inconsistente

I Quase inconsistente tendendo ao falso

J Quase inconsistente tendendo ao verdadeiro

K Quase paracompleto tendendo ao falso

L Quase paracompleto tendendo ao verdadeiro

O grau de exigência determinou o tamanho das regiões do QUPC; a FIG. 03 apresenta os valores entre 0% e 100%. Esses valores variariam de acordo com a análise do líder do projeto. A adoção do grau de exigência variou em função da metodologia na determinação estratégica de cenários sugeridas por Oliveira [Oliv01]. As alternativas que fizeram o processo de variação das funções foram: fatores a serem avaliados, levantamento da base de dados e grupos de especialistas consultados. Para ilustrar a exposição, foi adotado um grau de exigência de 0,25 (25%) e a fixação de 21 regiões, apresentados na FIG. 02 e utilizados, neste estudo de caso, na FIG. 03, adaptação do modelo de Da Costa [Costa99].


Figura 03 - Resultados plotados nos gráficos QUPC

116

Tarefa 3.1 - Expansão para diversos especialistas

Neste processo, foi realizada a composição categorizada por intermédio do uso de um meio de informação, com base na utilização da ISO 9126 [ABNT03], em que vários especialistas se organizaram em grupos, que foram estrategicamente selecionados de acordo com áreas de conhecimento afins. Para cada resposta de um especialista, foram atribuídas evidências para embasar a análise. A implementação foi realizada com a construção de um protótipo que contém uma escala do processo de classificação de cada um dos dados, obtidos por meio da realização do cálculo do baricentro – MAB (Método de Análise pelo Baricentro).

Tarefa 3.2 Adaptações necessárias

A partir deste ponto do processo, as atividades precisaram da adoção de símbolos para o grau de evidências; foi adotado - 1 como simplesmente , seguido do número do grupo a que pertença, exemplo 1, 2, . n, e para o grau de falta de evidências - 2, como λ, seguido do número do grupo a que pertença, exemplo: λ1, λ2, . . . , λn.

Tarefa 3.3 - Escolha de n especialistas, cada um com e λ independentes

Para a escolha dos especialistas foram considerados fatores como tempo, disponibilidade, tamanho, tecnologia e complexidade do problema e do projeto. Neste estudo de caso, havia, à disposição do projeto, sete especialistas disponíveis que satisfaziam aos pré-requisitos para a realização das técnicas.

Tarefa 3.4 - Algoritmos independentes no mesmo método

Para a obtenção dos parâmetros de entrada, foram submetidos à análise paraconsistente, representando assim o grau de risco através do baricentro, para a obtenção destes parâmetros, colocou-se a composição dos três métodos, uma análise da ISO 9126, que embasou a coleta de evidências selecionadas e agrupadas de acordo com a segunda técnica, a análise SWOT; com o agrupamento foi possível determinar os perímetros, que, após identificados nas áreas SWOT foram fatores restritivos e qualificadores.

O fenômeno do risco foi, dessa forma, composto pelas evidências, falta de evidências e evidências conflitantes identificadas no projeto, ou seja, cada um dos especialistas pôde categorizar o assunto segundo sua área de atuação. O algoritmo utilizado na questão 1 pode ou não ser o mesmo utilizado na questão 2. Cada questão pode ser independente, por exemplo: a primeira questão é sobre as os requisitos do projeto, e a segunda questão é sobre as tecnologias utilizadas. Neste trabalho, a tomada de decisão sobre como trabalhar, com suas respostas foi diferenciada, pois os grupos eram de projetos de áreas diferentes, sendo grupo 1 – financeiro, grupo 2 – logística, grupo 3 – TI... grupo n – especialidade N.

Tarefa 3.5 - Evitando efeitos indesejáveis por meio da correção de fatores

O método foi desenvolvido para permitir algoritmos diferentes por item a ser analisado, permitindo assim monitorar e controlar efeitos indesejáveis decorrentes do uso do mesmo algoritmo; para exemplificar, tomou-se uma questão que fosse puramente de caráter financeiro; para esta questão, seu algoritmo foi construído de forma a ponderar que o maior peso de decisão fosse do pessoal financeiro e não dos técnicos envolvidos no processo. Tomou-se este cuidado para garantir que cada grupo de especialistas tivesse um peso maior nas questões de sua área de conhecimento.


117

Tarefa 3.6 - A Escolha dos Fatores (Fx)

Utilizaram-se os fatores de risco conforme descrito na tarefa 03 – cada especialista atribuiu os valores de e λ, conforme seu julgamento, como descrito no Quadro 1, na criação das faixas, que, na lógica paraconsistente, é definido como “Fx”. Ressaltamos que a escolha dos fatores pode ser alterada, segundo as condições do problema em questão, podendo ser dada maior importância a determinados fatores numa análise e menor valor ou até mesmo sua exclusão em outras análises.

Tarefa 3.7 - A fixação de faixas para os fatores (Sx)

Após o estabelecimento de faixas para análise, foi necessária a atribuição de valores para essas regras; suponha a faixa em questão sendo avaliada “Funcionalidade”, uma possível fixação de valores para esta proposição seria, conforme sugere a norma ISO 9126:

1. Certeza da ocorrência, 2. Altamente provável, 3. Provável, 4. Pouco provável, 5. Improvável, 6. Altamente improvável e 7. Certeza da não ocorrência.

Pesquisa e Aplicação Base de Dados

Num

eraç

ão

Fato

r

Seçã

o

Peso

Esco

lha

do It

em

F e

S

Gr. A Gr. B Gr. C Gr. D Gr. E Gr. F Gr. G

Espec 1 Espec 2 Espec 3 Espec 4 Espec 5 Espec 6 Espec 7

µ11 µ21 µ12 µ22 µ13 µ23 µ14 µ24 µ11 µ21 µ12 µ22 µ13 µ23

1 F01 S1 7 1 F01S1 0,90 0,24 0,74 0,21 0,76 0,23 0,77 0,26 0,79 0,28 0,80 0,31 0,82 0,34

9 F02 S2 6 1 F09 S6 0,80 0,14 0,81 0,15 0,83 0,16 0,84 0,18 0,86 0,20 0,88 0,22

17 F03 S3 6 1 F02S2 0,72 0,06 0,73 0,06 0,74 0,07 0,76 0,07 0,77 0,08 0,79 0,09

27 F04 S6 2 1 F02S4 0,54 0,11 0,55 0,12

35 F05 S7 3 1 0,61 0,12 0,62 0,13 0,63 0,15

37 F06 S2 6 1 0,10 0,02 0,10 0,02 0,10 0,02 0,10 0,03 0,10 0,03 0,10 0,03

48 F07 S6 3 1 F02S5 0,43 0,09 0,44 0,10 0,45 0,10

55 F08 S6 3 1 0,44 0,09 0,45 0,10 0,46 0,11

62 F09 S6 2 1 F02S5 0,44 0,09 0,45 0,10 0,49 0,11

70 F10 S7 1 1 F02S6 0,48 0,10

77 F11 S7 2 1 F02S6 0,48 0,10 0,49 0,11

84 F12 S7 2 1 0,48 0,10 0,49 0,11

91 F13 S7 2 1 0,48 0,10 0,49 0,11

98 F14 S7 2 1 F02S6 0,45 0,09 0,45 0,10

102 F15 S4 4 1 F02S3 0,69 0,83 0,71 0,91 0,72 1,01 0,73 1,11

112 F16 S7 2 1 F02S6 0,53 0,64 0,54 0,70

119 F17 S7 1 1 F02S6 0,61 0,73

126 F18 S7 1 1 F02S6 0,60 0,72

130 F19 S4 4 1 F02S3 0,30 0,56 0,32 0,61 0,36 0,68 0,39 0,74

140 F20 S7 1 1 0,45 0,59 0,49 0,65 0,54 0,71 0,59 0,78 0,65 0,86 0,72 0,95 0,79 1,04


Quadro 04 – Atribuição de valores aos fatores

118

Tarefa 4: A interpretação dos resultados e a desqualificação das fraquezas e ameaças que não podem ser transformadas

Tanto as fontes como as informações devem ser recentes e confiáveis; todos os participantes devem conhecer os conceitos envolvidos e pode ser desejável incluir as visões de pessoas de fora da organização e, durante o processo, pode-se utilizar brainstorming, focus groups, entrevistas, pesquisas, assim como Delphi analysis etc. Após a aplicação do método, cada faixa recebe um diagnóstico, podendo ser Viável – Que é entendido como aprovado; Inviável – O item está em desacordo com o escopo do projeto; Não Conclusivo – O item necessita novas avaliações, as quais são exemplificadas no Quadro 04.

Quadro 05 - Apresentação dos resultados


119

A representação gráfica do Quadro 05 no plano cartesiano – QUPC, na qual, de uma maneira mais rápida, visualizamos a classificação de cada um dos fatores e sua região de localização com a análise realizada na coluna: “RESULTADO”.

Quadro 06 – Região de ‘não conclusivas’ com suas tendências

O Quadro 06 ilustra os resultados. Com os resultados fornecidos pela LPA2v, pode-se abastecer as análises de um projeto antes de seu término, mostrando graficamente os possíveis problemas e fornecendo possibilidades de análise com diagnósticos parciais.

5. resultados

Como foi mostrado nos Quadros 04, 05 e 06 deste artigo, assim como na Fig. 03, com o uso do modelo MARPs, foi possível identificar e representar graficamente as falhas; o método sugeriu uma tomada de decisão com base no conhecimento sobre o assunto relatado pelos participantes. O estado ‘não conclusivo’ deve receber atenção, independentemente da quantidade de vezes que este possa vir a aparecer, uma vez que são informações contraditórias ou ausência de informação; isto é mais bem explicado na FIG. 2, na qual o QUPC é dividido


120

em 12 áreas, sendo 8 delas pertencentes ao estado ‘não conclusivo’, que, embora sendo ‘não conclusivo’, evidencia sua tendência, e exemplificamos da seguinte maneira. Dividindo-se o gráfico em quatro quadrantes e fazendo uma analogia com o método SWOT, temos que:


Quadro 07 - Classificação da Análises SWOT x LPA2v

1 Quadrante: S - Strengths - Pontos fortes 1, 2, 3, 4, 5

2 Quadrante: W - Weaknesses - Pontos Fracos 6, 7, 8, 9, 10, 11, 12, 13, 14

3 Quadrante: Vulnerabilidades O - Opportunities - Pontos Oportunidades 15, 16, 17, 18

4 Quadrante: T - Threats – Ameaças 19, 20

O cenário pesquisado auxiliou os gestores no processo de correção de percurso para um replanejamento e alinhamento correto com os objetivos planejados. Ao nos depararmos com o conhecimento do “estado de uma variável”, não temos apenas a informação “verdadeiro” ou “falso”, mas também informações faltantes ou conflitantes da equipe sobre um ponto insolvível, passíveis de novas análises. Apresenta-se então o resultado calculado.

Com a interpretação do Quadro 06 gerada pelo método, notamos que temos 20 faixas (questões a serem respondidas), cujo resultado pode ser visto na coluna “Descrições parciais”; esta coluna nos informa três estados: viável, inviável e ‘não conclusivo’, os estados viável e inviável dispensam grandes comentários, pois são conclusivos e nos informam se a faixa em questão está comprometendo ou não o projeto. Os resultados foram traduzidos em ações tomadas em diversas atividades e são descritas por cada quadrante a seguir:

� O entendimento sobre os pontos do 1º Quadrante, S - Strengths - Pontos fortes, sinalizou para os gestores quais ações deveriam ser mantidas, pois estavam surtindo o efeito desejado;

� As questões endereçadas no 2º Quadrante, W - Weaknesses - Pontos Fracos, foram questões basicamente identificadas no GAP de CMMI, nível 2 de gestão. Para cada ação de vulnerabilidade, foi desenvolvido um plano de mitigação que foi acompanhado até o momento de sua resolução. Abstrai-se desta avaliação que o objetivo é converter um Ponto Fraco em um Ponto forte mediante um conjunto de ações estruturadas para atingir esse objetivo;

� As questões identificadas no 3º Quadrante, - O - Opportunities - Vulnerabilidades - Pontos de Oportunidades, da mesma forma que para as questões no Quadrante 2, devem ter um plano de mitigação para ser convertidas em um ponto forte. Ocorre que os pontos identificados simbolizam a falta de informação e capacitação, de forma que foi endereçado para o plano de carreira e treinamento de aperfeiçoamento dos profissionais envolvidos. Dessa forma, o projeto em si não pôde colher os frutos dessas lições aprendidas, porém os gestores encaminharam o plano de contingência;

� As questões endereçadas no 4º Quadrante: T - Threats - Ameaças, sinalizaram para aspectos de indisponibilidade constate de serviços e infraestrutura, também identificadas no GAP de CMMI nível 2 de gestão. Neste caso, foi orientada a revisão dos contratos e Service Level Agreement - SLA, para cada fornecedor. Num contrato

121

com cláusula de multa para a não prestação de serviço, ocorreram problemas, e a manifestação deste risco foi identificada, mas a organização já estava precavida para as eventualidades de forma proativa. Essa avaliação teve o objetivo de converter os Pontos Ameaças em Pontos fortes, mas, neste caso, a neutralização da ameaça foi a solução encontrada.

O uso da análise SWOT foi verificado quando, após um processo formal de auditoria, houve a necessidade de se estabelecer orientações e recomendações sobre os desvios e anomalias encontrados, assim como dos estudos de Gap analysis durante as fases de projeto. O processo de Gap analysis ou de diagnóstico da situação atual serviu para fornecer os parâmetros necessários para a montagem de um plano adequado de implementação, ou ainda para revisar o plano de implementação em curso.

As lacunas identificadas no processo MARPS e classificadas durante o processo de Gap analysis: com base em cada uma das faixas classificadas, foi realizada uma triagem sobre cada uma das ações a serem tomadas de acordo com os quadrantes identificados. Na categoria do modelo SWOT, os problemas Internos foram identificados e resolvidos, enquanto os problemas que dependiam de fornecedores, logo categoria Externo, foram revistos e renegociados. As evidências coletadas na auditoria serviram de embasamento e argumento para que os gestores renegociassem com os fornecedores cada aspecto do contrato negligenciado.

Esta abordagem foi aplicada pela TCS Brasil, em uma dos maiores instituições financeiras nacionais, e serviu como ponto de partida para a adoção de planos de ação, a fim de minimizar os efeitos dos riscos potenciais encontrados.

6. ConClusão

Selecionado o grau de exigência de 30%, na inexistência dessas informações, o resultado dessa composição, obtido pelo Método de Análise pelo Baricentro (MAB), foi localizado na área “G”, que representa a região - Quase Verdadeiro Tendendo ao Paracompleto. Dentro deste modelo, a taxa de 100 % de aderência na área Verdadeiro significaria que não há evidências de informações contrárias e a certeza de uma realização sem dúvidas, contradições ou falta de informações.

No caso de estar 100% aderente à área paracompleta, significaria que não há informações suficientes nem contrárias, a favor e nem de contradições devido à falta de informações.

A falta de informações representa o risco, mas não há evidências de negação ou problemas históricos conhecidos.

A composição desta área G significa que o projeto é viável e existe um desconhecimento de vários aspectos dentro do projeto que podem representar problemas, pois o grau de certeza do projeto não é absoluto.

O método não é trivial, e requer uma preparação e capacidade de análise para a viabilização de seu uso em larga escala. Decorrente deste fenômeno, poder contar com pessoas que conhecem o assunto é um fator fundamental, e a sua falta pode inviabilizar o estudo. O uso dessas ferramentas requer conhecimentos específicos das áreas envolvidas no gerenciamento de risco em uma fábrica de software. Essas competências precisam ser desenvolvidas para diminuir as distorções no processo para obtenção de um software com qualidade.


122

referênCIas BIBlIográfICas

[ABNT03] ABNT - Associação Brasileira de Normas Técnicas. NBRISO/IEC9126-1 Engenharia de software - Qualidade de produto - Parte 1: Modelo de qualidade 01/06/2003 Em vigor, 2003. Disponível em: http://www.abnt.org.br.

[Albr81] ALBRECHT, ALLAN J. Function Points as a Measure of Productivity, Act as do 53rd meeting of GUIDE International Corp. Guidance for users of integrated data processing equipment conference. Dallas, 1981.

[Carvr02] CARVALHO, Fábio Romeu. Lógica paraconsistente aplicada em tomadas de decisões: uma abordagem para a administração de universidades. São Paulo: Aleph, 2002.

[Carv03] CARVALHO, Fábio Romeu de. Um Estudo de Tomada de Decisão Baseado em Lógica Paraconsistente Anotada: Avaliação do Projeto de uma Fábrica - Revista Pesquisa e Desenvolvimento Engenharia de Produção n. 1, p. 47-62, dez. 2003.

[CMMI06] CMMI Capability Maturity Model Integration Version 1.2 - - Technical Report CMU/SEI-2006-TR-008 Carnegie Mellon University, 2006. Disponível em: http://www.sei.cmu.edu/CMMI/.

[Daaetal99] DA COSTA, Newton C. A. ; ABE, Jair M.; MUROLO, Afrânio C.; DA SILVA Filho, João I.; LEITE, Casemiro F. S. Lógica paraconsistente aplicada. Atlas: São Paulo, 1999.

[Hump60] HUMPHREY Albert S. SWOT. Stanford University, 1960. Disponível em: http://en.wikipedia.org/wiki/SWOT_analysis.

[Mont05] MONTINI, Denis Ávila, Modelo de indicadores de risco para o orçamento de componentes de software para célula de manufatura. 2005.. Dissertação (Mestrado) – Universidade Paulista, São Paulo, 2005. 360 p.

[Oliv01] OLIVEIRA, Djalma de Pinho Rebouças de. Estratégia empresarial e vantagem competitiva: como estabelecer, implementar e avaliar. São Paulo: São Paulo, 2001.

[Port86] PORTER, Michael E. Estratégia competitiva – técnicas para análise de indústrias e da concorrência. Rio de Janeiro: Editora Campus, 1986.

[Tsuk95] TSUKUMO, ALFREDO et al. Avaliação de produto de software: algumas questões relevantes e a ISO/IEC 9126. WORKSHOP DE QUALIDADE DE SOFTWARE, Recife. Anais… Recife: Sociedade Brasileira de Computação. p 116-121, março, 1995.

Keywords MARPS, Software Factory, SWOT, ISO-9126.

aBstraCt This article proposes a model of application for risk analysis that includes an action plan covering the level, strategic, tactical and operational levels suggested by the SWOT analysis, however the concept SWOT classic has been adapted for software projects. The company applied a software quality plan referenced with models CMMI and ISO-9126to study projects. In this case study it was necessary to use a technique that would incorporate the concepts of quarters with measures SWOT scalars. It was proposed to index the SWOT with paraconsistent logic Annotated Bivalorada - LPA2v to solve the task of representing graphically the scale of a


123

qualified and quantified information.

soBre os autores

Denis áVila mOnTini

Graduado em Mecânica de Precisão Ênfase Em Mecatrônica pela Fatec SP Faculdade de Tecnologia de São Paulo (1998) , especialização em Análise de Sistemas pelo Instituto Paulista de Ensino e Pesquisa (2000), especialização em Engenharia de Software pela Universidade São Judas Tadeu (2001), especialização em Redes e Voz Sobre IP pela Universidade São Judas Tadeu (2003) e mestrado em Engenharia de Produção pela Universidade Paulista (2005) . Atualmente é Analista Consultor da Tata Consultancy Service. Tem experiência na área de Ciência da Computação, com ênfase em Metodologias e Técnicas de Computação. Atuando principalmente nos seguintes temas: OPM3 modelos de gestão empresarial, CMMI modelo de desenvolvimento de projeto de SO, PMI modelo de gerência de projeto, ISO9000:2001 modelo de desenvolvimento de processo, BSC Modelo de indicadores de desempenho e PSP - Personal Software Process.

mauri apareCiDO De OliVeira

É engenheiro mecânico com ênfase em mecatrônica pela Escola de Engenharia de São Carlos da USP. Na graduação foi bolsista de iniciação científica do Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) tendo trabalhado no Laboratório de Inteligência Computacional do Instituto de Ciências Matemáticas e de Computação (ICMC/USP) e na Fábrica Integrada Modelo em projetos de manufatura integrada por computador (CIM) da EESC/USP. Tem especialização em engenharia automobilística pela Faculdade de Engenharia Industrial (FEI). Trabalhou como engenheiro de desenvolvimento de protótipos no departamento de engenharia experimental da General Motors do Brasil (GMB) tendo atuado em plantas do Brasil e na OPEL da Alemanha. Estudou MBA em finanças no Instituto Brasileiro de Mercado de Capitais (IBMEC/SP). É mestre em administração pela Faculdade de Economia, Administração e Contabilidade (FEA/USP) tendo publicado artigos nas áreas de finanças, econometria, tecnologia da informação, economia e processos de fabricação. Recebeu o prêmio de melhor artigo do VII Seminários em Administração (SEMEAD). Trabalhou como professor ou monitor na Universidade Presbiteriana Mackenzie, FEA/USP e Fundação Getulio Vargas (FGV/SP). Tem doutorado em administração pela Faculdade de Economia, Administração e Contabilidade (FEA/USP) tendo como principal tema de interesse a aplicação de redes neurais artificiais na previsão de séries temporais financeiras. Parecerista da RAUSP - Revista de Administração da USP. Revisor da revista FACEF Pesquisa. Atualmente trabalha na área de desenvolvimento e implantação de modelos econométricos e financeiros para gestão de negócios.

alessanDra De áVila mOnTini

Atualmente é professora da Área de Métodos Quantitativos e Informática da Faculade de Economia, Administração e Contabilidade da Universidade de São Paulo. Sua carreira universitária foi feita na Universidade de São Paulo. Doutora em Administração de Empresas pela Faculdade de Economia, Administração e Contabilidade - FEA-USP (2003), Mestra (2000) e Bacharel (1995) em Estatística pelo Instituto de Matemática e Estatística IME-USP.Tem experiência na área de Finanças e Métodos Quantitativos. Principais Temas de Estudo: Distribuição de Probabilidade Associada ao Retorno de Ativos Financeiros Previsão de


124

Retornos de Ativos Financeiros Cálculo do VaR e do CVar de Ativos Financeiros e do Portfólio de Ativos Financeiros Utilização de Modelos de Séries Temporais ARIMA-GARCH para Previsão de Ativos Financeiros Utilização de Redes Neurais para Previsão de Retornos de Ativos Financeiros Modelagem da Distribuição Multivariada de Ativos Financeiros por meio da Teoria de Funções de Acoplamentos Cópulas.


uma aplicação de marps para gerenciamento de risco em … · qualidade, e por fim a lógica ......

Documents