Modelo para Análise de Riscos em Projetos de Software (MARPS)

(1)

Modelo para Análise de Riscos em Projetos de Software

(MARPS)

Denis Ávila Montini

Msc. Engenharia de Produção São Paulo - SP Av. Paulista 949 (0xx11) – 9829-8216

Denisavila.montini@tcs.com

Daniel Machado dos Santos Bsc. Engenharia de Computação Instituto Tecnológico de Aeronáutica

São José dos Campos - SP Praça. Marechal Eduardo Gomes 50

(0xx12) – 3947-5843

danielsbr@yahoo.com.br

Luiz Alberto Vieira Dias PhD. Space Physics Instituto Tecnológico de Aeronáutica

São José dos Campos - SP Praça. Marechal Eduardo Gomes 50

(0xx12) – 3947-5843

vdias@ita.br

Adilson Marques da Cunha Dsc. Computer Engineering Instituto Tecnológico de

Aeronáutica Praça. Marechal Eduardo

Gomes 50 (0xx12) – 3947-5843

cunha@ita.br

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 sofware. 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 a busca dos pontos fracos, fortes e oportunidades de melhoria no projeto, alem de uma forma para 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, vão ser apresentados os conceitos utilizados no desenvolvimento de um Modelo para Análise de Riscos para Projetos de Software – MARPS, [01], utilizando três métodos integrados, análise da ISO-9126 [02], no embasamento da coleta de evidências, pela análise Forças - Strengths, Fraquezas - Weaknesses, Oportunidades - Opportunities e Ameaças - Threats (SWOT) [03], para a indexação destas evidências à referência de qualidade, e por fim a Lógica Paraconsistente Anotada Bivalorada - LPA2v [04], como método de apóio 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 através da 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, através de entrevistas e a observações diretas, para representar os diferentes graus de Risco do projeto.

2. CONTEXTO

Na realização de projetos, são freqüentemente 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) [05], 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 a eficiência de seus processos, quando problemas específicos aparecem, torna-se difícil se identificá-los, mitigá-los e contingenciá-los, evitando assim maiores prejuízos. Segundo o modelo de Porter [06], 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, com um Modelo para Análise de Riscos em Projetos de Software, que permitisse representar graficamente o projeto e as anomalias para compor com 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 à base dos estudos experimentais vieram 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 [02], 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 [07], 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.

(2)

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 [02], 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 [01].

O Quadro 01 contém as sub-características abstraídas da norma, que fundamentaram o desdobramento dos “fatores” que formaram à base da modelagem paraconsistente explicada na seqüência deste artigo. Para cada elemento identificado da ISO 9126 [02] descrito na coluna “Sub-características – Fn” do Quadro 01, atribuí-se variações, que foram definidas ao entrevistar um envolvido. A estas 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 sub-características enumeradas no Quadro 01 foi fundamental para a classificação que foi realizada na , Lógica Paraconsistente Bivalorada Anotada - LPC2v, prevista por Da Costa [04] [08].

Quadro 01 – Escopo da norma ISO/IEC 9126 (Fonte: MONTINI 2005 Apud, TSUKUMO, 1995)

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 freqüências apresentam falhas? 7 Tolerância à falhas Ocorrendo falhas, como ele 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 Quanto recurso 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?

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 desta contradição, e na definição de áreas de atuação, que possibilitam a determinação de planos de ações setoriais, esta dificuldade foi sanada com o uso do método LPA2v

que propiciou a visualização destas contradições através de 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. O Método aplicado para a técnica SWOT

O uso da análise SWOT foi verificado quando após um processo formal de auditoria há 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.

É objetivo deste trabalho identificar as lacunas existentes, Gap Analysis, no processo de desenvolvimento de software.que serve como uma fonte de pesquisa para a identifiçã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.

No modelo SWOT existem quatro categorias que são baseadas em dois conjuntos de conceitos sendo: (Interno X Externo) e (Positivo X Negativo), é aconselhável a utilização do SWOT, somente após se ter estabelecidas as metas e objetivos a serem analisados, diversos tipos de cenários podem ser escolhidos a fim de se conhecer, através de uma pesquisa investigativa, as forças e fraquezas do projeto, nesse caso, a contextualização foi feita com a ISO 9126, realizado pela equipe do CMMI.

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 às necessidades do consumidor, no entanto, as oportunidades e ameaças que ocorram nos ambientes externos a 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 através de atividades, decorrente deste fato, o método SWOT foi obtido através 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.

(3)

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.

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.

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

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

Neste estudo de caso, foram selecionados aos 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, nos quais foram 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 Figura 01 representa o modelo SWOT convencional, no qual foi 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égico, táticos e operacionais, de forma que é possível atuar em cada um dos quadrantes em quaisquer fases ou atividades da empresa, neste

S o mató 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

S o mató 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 Clarity 1 1 Project Server

S o mató ria 1 2 3 4 5 6 7

T -

Threats - Ameaças

4 1 1 1 1 Indisponibilidade do servidores. Infra-_{estrutura perda de dados do projeto.}

1 1 Equipe restrita e mudanças organizacionais.

S omató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 1

Aparecimento 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

(4)

adaptação para projetos. Cabe a cada empresa desenvolver os seus respectivos planos para cada uma destas 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 propou-se a indexação da SWOT com a LPA2v para atender o fato de representar quantitativamente e qualitativamente de uma forma escalar.

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 LPC2v foi estudado por Da Costa [04] na 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, a cada um dos para cada resposta foi atribuido graficamente um ponto no Quadrado Unitário do Plano Cartesiano - QUPC, representado na Figura 02.

y x A = (0 , 0) paracompleto C = (1 , 1) inconsistente B = (0 , 1) falso 0 1 D = (1 , 0) verdadeiro 1 µ2 = grau de evidência contrária µ1 = grau de evidência favorável (0, 1) (0,1/2) (0, 0) (1/2, 0) (1, 0) (1,1/2) (1/2, 1) (1, 1)

µ

C

µ

E A J F K H G L I B D

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

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 (µ1) e um grau de falta de evidências (µ2). Nota-se:

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 [09] [10].

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

Legenda

Regiõ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 o verdadeiro K Quase paracompleto tendendo ao falso L Quase paracompleto tendendo ao verdadeiro

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

O grau de exigência determinou o tamanho das regiões do QUPC, a Figura 03, apresenta os valores entre 0% e 100%. Estes valores variariam de acordo com a análise do líder do projeto. A

(5)

determinação estratégica de cenários sugeridas por Oliveira [11]. 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, apresentadas na Figura 02 e utilizadas neste estudo de caso na Figura 03, adaptação do modelo de Da Costa [04].

Análise SWOT - LPA

0,00 0,05 0,10 0,15 0,20 0,25 0,30 0,35 0,40 0,45 0,50 0,55 0,60 0,65 0,70 0,75 0,80 0,85 0,90 0,95 1,00 0,00 0,05 0,10 0,15 0,20 0,25 0,30 0,35 0,40 0,45 0,50 0,55 0,60 0,65 0,70 0,75 0,80 0,85 0,90 0,95 1,00 Grau de crença G rau de de sc renç a

Fatores Baricentro Contorno Div Centrais Div Diagonais

Região Falsa Região Paracompleta Região Paraconsistente Região Verdade B M A B M A A M B A M B Weaknesses (Fraquezas)

Threats (Ameaças) Opportunities (Oportunidades)

Strengths (Forças)

Figura 03 - Resultados plotados nos gráficos QUPC.

Tarefa 3.1 - Expansão para diversos especialistas

Neste processo, foi realizado a composição categorizada através do uso de um meio de informação, com base na utilização da ISO 9126 [02], nos quais 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, que foram obtidos através da realização do cálculo do baricentro – MAB.

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 sendo simplesmente µ, seguidos do número do grupo a que pertença, exemplo µ1, µ2, . µn, e para o grau de falta de evidências - µ2, como λ, seguidos 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, haviam a disposição do projeto sete especialistas que estavam disponíveis e satisfaziam aos pré-requisitos para a realização das técnicas.

Tarefa 3.5 - 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, desta forma foi 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 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 como 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 foram diferenciados, 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.6 - Evitando efeitos indesejáveis através 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

(6)

especialistas tivessem um peso maior nas questões de sua área de conhecimento.

Tarefa 3.7 - 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.8 - A fixação de faixas para os fatores (Sx)

Após o estabelecimento de faixas para análise, foi necessária atribuição de valores para estas regras, suponha a faixa em questão sendo avaliados “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.

Quadro 04 – Atribuição de valores aos fatores

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 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, nos quais são exemplificados no Quadro 04.

(7)

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 podem-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, 06 deste artigo, e na Figura 03, com o uso do modelo MARPs, foi possível identificar representar gráficamente as falhas, e o método sugeriu uma tomadas de decisão com base no conecimentos sobre o assunto relatados 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

Desição parciais Desição parciais

1 F01 S1 7 1 F01S1 VIÁVEL Monitoramento

9 F02 S2 6 1 F09S6 NÃO CONCLUSIVO Padronização

17 F03 S3 6 1 F2S2 NÃO CONCLUSIVO Compromentimento e formalização.

27 F04 S6 2 1 F2S4 NÃO CONCLUSIVO Template_Medicoes_Coleta_Analise_V4.xls - Identificação da Variação de Cornograma

35 F05 S7 3 1 NÃO CONCLUSIVO Metadados

37 F06 S2 6 1 NÃO CONCLUSIVO F05 - Relatório de Desempenho do Projeto V3 Draf.doc

48 F07 S6 3 1 F2S5 NÃO CONCLUSIVO Utilização, treinamento Harvest - indefinição da utilização das documentações

55 F08 S6 3 1 NÃO CONCLUSIVO Suporte técnico ao projeto

62 F09 S6 2 1 F2S5 NÃO CONCLUSIVO F07 - Registro de Monitoramento do Processo v1.doc

70 F10 S7 1 1 F2S6 NÃO CONCLUSIVO GPS

77 F11 S7 2 1 F2S6 NÃO CONCLUSIVO Perda de prioridade pela Média Gerência e pela área usuária

84 F12 S7 2 1 NÃO CONCLUSIVO Aparecimento de outros trabalhos mais urgentes, impactando no tempo de utilização dos processos que dificulta a assimilação do projeto.

91 F13 S7 2 1 NÃO CONCLUSIVO Utilização do Oracle, espaço em disco

98 F14 S7 2 1 F2S6 NÃO CONCLUSIVO Falta de conhecimento na gestão de projeto para seguir o processo.

102 F15 S4 4 1 F2S3 NÃO CONCLUSIVO Integração das ferramentas do projeto

112 F16 S7 2 1 F2S6 NÃO CONCLUSIVO Criação de novos indicadores. Exemplos: Produtividade.

119 F17 S7 1 1 F2S6 NÃO CONCLUSIVO Clarity

126 F18 S7 1 1 F2S6 NÃO CONCLUSIVO Project Server

130 F19 S4 4 1 F2S3 NÃO CONCLUSIVO Indisponibilidade do servidores. Infra-estrutura perda de dados do projeto.

140 F20 S7 1 1 NÃO CONCLUSIVO Equipe restrita e mudanças organizacionais. Desição final VIÁVEL Resultado Pesquisa e aplicação Num er aç ão Fat or Seç ão Pes o Esc ol ha do i tem F e S

(8)

na Figura 2a onde o QUPC é dividido em 12 áreas, sendo 8 delas pertencentes ao estado ‘não conclusivo’, que embora sendo ‘não

conclusivo’ nos evidencia sua tendência, e exemplificamos da seguinte maneira. Dividindo 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 LPC2v

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 re-planejamento e alinhamento correto com os objetivos planejados. Ao se deparar com o conhecimento do “estado de uma variável”, não temos apenas a informação verdadeiro ou falso, mas também de informações faltantes ou conflitantes, da equipe sobre um ponto insolvível que são 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ção 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 esta 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 sutindo 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 Pontos Fracos e um Ponto-forte através de um conjunto de ações estruturadas para atingir este objetivo.

• As questões identificadas no 3º Quadrante, - O - Opportunities - Vulnerabilidades - Pontos de Oportunidades, da mesma forma que para as quetões no Quadrante 2, devem ter um plano de mitigação para converter 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. Desta forma o projeto em si não pôde colher os frutos destas 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 indiponibilidade constate de serviços e infra-estrutura, também identificadas no GAP de CMMI nível 2 de gestão. Neste caso foi orientado a revisão dos contratos e Service Level Agreement - SLA, para cada fornecedor. Com um contrato de clausula multa para a não prestação de serviço. Problemas ocorreram e a manifestação deste risco foi identificada, mas a organização já estava precavida para as eventialidades de forma pró-ativa. Esta avaliação teve o objetivo é

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 há 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 que foram identificadas no porcesso MARPS e classificadas durante o processo de Gap analysis. Com base em cada uma das faixas classificadoas 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 probelas Interno foram identficidados e resolvidos, enquanto que os problemas que depndiam de forncedores, 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 institições financeiras nacionais, e seviu como ponto de partida para adoção de planos de ação, a fim de minimizar os efeitos, dos riscos pontenciais encontrados.

6. CONCLUSÃO

Selecionado o grau de exigência de 30 %, na inexistência dessas informações o resultado desta composição do MAB acabou sendo localizado na área de “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.

Dentro deste modelo, estar 100 % aderente à área paracompleta significaria que não há informações suficientes nem contrárias, a favor e nem de contradições devido a 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 de podem representar problemas, pois o grau de certeza do projeto não é absoluto.

Selecionado o grau de exigência de 30 %, na inexistência dessas informações o resultado desta composição do MAB acabou sendo localizado na área de “G” que representa a região - Quase verdadeiro tendendo ao paracompleto. Dentro deste modelo estar

(9)

evidências de informações contrárias e a certeza de uma realização sem dúvidas, contradições ou falta de informações.

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

7. RECOMENDAÇÕES

Embora os resultados obtidos sinalizassem para a tendência na qual se constatou os projetos obtiveram êxito e os fenômenos de ocultos acabaram ocorrendo. A utilização deve ser relacionada com o poder de correção de processos, e alterações hora estruturas hora de planejamento. O fato de encontrar um problema complexo de modelado e em seguida não interagir com a solução significa que o trabalho de mitigação ou de contingência ficou incompleta.

O processo pode ser extenuante e se o projeto não tiver valor agregado suficiente o custo benefício pode não ser recompensador. Uma parte deste trabalho só foi possível devido a particiação do PSF, que contribuíu com o capital intelectual para a sua realização [12].

8. REFERÊNCIAS BIBLIOGRÁFICAS

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

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

[3]. HUMPHREY Albert S Humphrey - SWOT - Stanford University http://en.wikipedia.org/wiki/SWOT_analysis (1960).

[4]. 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).

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

[6]. PORTER, Michael E. – Estratégia Competitiva – Técnicas para Análise de Indústrias e da Concorrência. Editora Campus: Rio de Janeiro - (1986).

[7]. CMMI Capability Maturity Model Integration Version 1.2 - http://www.sei.cmu.edu/CMMI/ - Technical Report CMU/SEI-2006-TR-008 Carnegie Mellon University © - (2006).

[8]. TSUKUMO, ALFREDO, et al. Avaliação de Produto de Software: algumas questões relevantes e a ISO/IEC 9126. In: WORKSHOP DE QUALIDADE DE SOFTWARE, Recife. Anais… Recife: Sociedade Brasileira de Computação. p 116-121. Março/1995 - (1995).

[9]. CARVALHO, Fábio Romeu – Lógica paraconsistente aplicada em tomadas de decisões: uma abordagem para a administração de universidades. Aleph: São Paulo - (2002). [10]. CARVALHO, Fábio Romeu de (2003); 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).

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

[12]. PSF, www.pesquisadoressemfronteira.org.br, Pesquisadores sem fronteira , ONG de suporte a pesquisa do estado de São Paulo, Brasil. - (2007).