Artigo
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]
2
E-mail: [email protected]
3
E-mail: [email protected]
107
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
108
Uma Aplicação de MARPS para Gerenciamento de Risco em uma Fábrica de Software
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].
109
Denis Ávila Montini, Mauri Aparecido de Oliveira, Alessandra de Ávila Montini
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
110
Uma Aplicação de MARPS para Gerenciamento de Risco em uma Fábrica de Software
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.
111
Denis Ávila Montini, Mauri Aparecido de Oliveira, Alessandra de Ávila Montini
Quadro 02 – Resultados das quatro avaliações das dimensões SWOT
Particpantes
Somatória
1
2
3
4
4
1
5
1
6
1
7
T - Threats - Ameaças
Indisponibilidade do servidores. Infraestrutura perda
de dados do projeto.
1
1
1 Equipe restrita e mudanças organizacionais.
Particpantes
Somatória
1
2
3
4
5
6
O - Opportunities - Pontos Oportunidades
4
1
1
2
1
1
Criação de novos indicadores. Exemplos:
Produtividade.
1
Clarity
1
1
1
7
1
Integração das ferramentas do projeto
1
Project Server
Particpantes
Somatória
1
2
6
1
3
1
3
1
2
1
3
1
4
5
1
1
1
1
2
6
7
1
W - Weaknesses - Pontos Fracos, Vulnerabilidades
1 F05 - Relatório de Desempenho do Projeto V3 Draf.doc
Utilização, treinamento Harvest - indefinição da
utilização das documentações
1
1
Suporte técnico ao projeto
1
F07 - Registro de Monitoramento do Processo v1.doc
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
1
Utilização do Oracle, espaço em disco
Falta de conhecimento na gestão de projeto para seguir o
processo.
1
Particpantes
Somatória
1
7
4
5
6
7
S - Strengths - Pontos fortes
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.
2
1
3
1
3
112
2
1
1
Template_Medicoes_Coleta_Analise_V4.xls
Identificação da Variação de Cornograma
1
1
1
Metadados
-
Uma Aplicação de MARPS para Gerenciamento de Risco em uma Fábrica de Software
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.
Combinação
AMEAÇAS
OPORTUNIDADES
Minimizar / Evitar
Conversão
FRAQUEZAS
FORÇAS
Minimizar / Evitar Combinação
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
113
Denis Ávila Montini, Mauri Aparecido de Oliveira, Alessandra de Ávila Montini
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.
y
B = (0 , 1)
falso
C = (1 , 1)
inconsistente
1
µ2 = grau de
evidência
contrária
x
A = (0 , 0)
paracompleto
0
µ1 = grau de
evidência
favorável
1
D = (1 , 0)
verdadeiro
Figura 02: QUPC – Quadrado Unitário do Plano Cartesiano e as respectivas regiões
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.
114
Uma Aplicação de MARPS para Gerenciamento de Risco em uma Fábrica de Software
Quadro 03 – Legenda da Divisão do reticulado τ em 12 regiões.Da Costa et al (1999)
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 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
115
Denis Ávila Montini, Mauri Aparecido de Oliveira, Alessandra de Ávila Montini
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.
116
Uma Aplicação de MARPS para Gerenciamento de Risco em uma Fábrica de Software
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.
2.
3.
4.
5.
6.
7.
Certeza da ocorrência,
Altamente provável,
Provável,
Pouco provável,
Improvável,
Altamente improvável e
Certeza da não ocorrência.
Quadro 04 – Atribuição de valores aos fatores
Base de Dados
FeS
Escolha do Item
Peso
Seção
Fator
Numeração
Pesquisa e Aplicação
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
0,90
0,24
µ23
1
F01
S1
7
1
F01S1
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,55
0,12
35
F05
S7
3
1
37
F06
S2
6
1
0,10
0,03
48
F07
S6
3
1
55
F08
S6
3
1
62
F09
S6
2
1
F02S5
70
F10
S7
1
1
77
F11
S7
2
1
84
F12
S7
2
91
F13
S7
98
F14
102
112
0,79
1,04
0,54
0,11
0,61
0,12
0,62
0,13
0,63
0,15
0,10
0,02
0,10
0,02
0,10
0,02
0,43
0,09
0,44
0,10
0,44
0,09
0,44
0,09
0,10
0,03
0,10
0,03
1
0,48
0,10
0,49
0,11
2
1
0,48
0,10
0,49
0,11
S7
2
1
F02S6
0,45
0,09
0,45
0,10
F15
S4
4
1
F02S3
0,69
0,83
0,71
0,91
0,72
1,01
0,73
1,11
F16
S7
2
1
F02S6
0,53
0,64
0,54
0,70
0,61
0,73
0,60
0,72
0,30
0,56
0,32
0,61
0,36
0,68
0,39
0,74
0,54
0,71
0,59
0,78
0,65
0,86
0,72
0,95
F02S5
0,46
0,11
0,45
0,10
F02S6
0,48
0,10
F02S6
0,48
0,10
119
F17
S7
1
1
F02S6
126
F18
S7
1
1
F02S6
130
F19
S4
4
1
F02S3
140
F20
S7
1
1
0,45
0,59
0,45
0,49
0,10
0,65
0,45
0,10
0,49
0,11
0,49
0,11
117
Denis Ávila Montini, Mauri Aparecido de Oliveira, Alessandra de Ávila Montini
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
118
Uma Aplicação de MARPS para Gerenciamento de Risco em uma Fábrica de Software
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
119
Denis Ávila Montini, Mauri Aparecido de Oliveira, Alessandra de Ávila Montini
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
120
Uma Aplicação de MARPS para Gerenciamento de Risco em uma Fábrica de Software
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.
121
Denis Ávila Montini, Mauri Aparecido de Oliveira, Alessandra de Ávila Montini
Referências Bibliográficas
[ABNT03]
[Albr81]
[Carvr02]
[Carv03]
[CMMI06]
[Daaetal99]
[Hump60]
[Mont05]
[Oliv01]
[Port86]
[Tsuk95]
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.
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.
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.
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.
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/.
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.
HUMPHREY Albert S. SWOT. Stanford University, 1960. Disponível em:
http://en.wikipedia.org/wiki/SWOT_analysis.
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.
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.
PORTER, Michael E. Estratégia competitiva – técnicas para análise de indústrias
e da concorrência. Rio de Janeiro: Editora Campus, 1986.
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
122
Uma Aplicação de MARPS para Gerenciamento de Risco em uma Fábrica de Software
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
123
Denis Ávila Montini, Mauri Aparecido de Oliveira, Alessandra de Ávila Montini
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.
124