Embed Size (px)
Citation preview
FACULDADE IETEC
ANA CRISTINA DA SILVA ANDRADE
UMA ABORDAGEM PARA AVALIAÇÃO E MONITORAMENTO DE
RISCOS EM PROJETOS DE SOFTWARE
Belo Horizonte
2018
ANA CRISTINA DA SILVA ANDRADE
UMA ABORDAGEM PARA AVALIAÇÃO E MONITORAMENTO DE
RISCOS EM PROJETOS DE SOFTWARE
Dissertação apresentada ao Programa de Mestrado da Faculdade Ietec, como requisito parcial à obtenção do título de Mestre em Engenharia e Gestão de Processos e Sistemas. Área de concentração: Engenharia e Gestão de Processos e Sistemas Linha de pesquisa: Gestão de Processos, Sistemas e Projetos.
Orientador: Prof. Dr. José Luis Braga Faculdade Ietec
Belo Horizonte
Faculdade Ietec
2018
Andrade, Ana Cristina da Silva.
A553u Uma abordagem para avaliação e monitoramento de riscos em projetos de software / Ana Cristina da Silva Andrade. - Belo Horizonte, 2018.
48 f., enc.
Orientador: José Luis Braga.
Dissertação (mestrado) – Faculdade Ietec.
Bibliografia: f. 47-48
1. Gestão de projetos de software. 2. Gestão de riscos. 3. Requisitos não funcionais. 4. Metas flexíveis. I. Braga, José Luis. II. Faculdade Ietec. Mestrado em Engenharia e Gestão de Processos e Sistemas. III. Título.
CDU: 681.3.066
Dedico essa dissertação aos meus pais Maria da Glória e José Fidêncio, exemplo de vida.
Ao meu marido
Fernando Agusto, maior companheiro desta jornada.
Aos meus filhos Luísa e Bruno, prova de amor incondicional.
Aos meus irmãos
Eudardo, Leonardo e Edvaldo, parceiros inseparáveis.
Ao meu orientador José Luis Braga, grande mentor.
E a todos amigos que me apoiaram.
AGRADECIMENTOS
Agradeço a Deus, pela vida, pela oportunidade, por me amparar e fortalecer
nos momentos dificeis, por me ensinar a levantar após cada queda, por me mostrar
a cada dia qual o verdadeiro sentido desta jornada chamada vida e por me
proporcionar mais esta conquista.
Agradeço aos meus pais José Fidêncio e Maria da Glória referências de fé,
humildade e dignidade. Eles me mostraram que com esforço e confiança em Deus
tudo é possível.
Agradeço ao meu amado marido Fernando companheiro, amigo de todos
momentos. Soube compreender e apoiar a milha escolha. Sem seu incentivo, seu
amor, seu carinho e sua dedicação aos nossos filhos nos momentos que eu estava
ausente esta consquista não seria possível.
Agradeço aos meus filhos Luísa e Bruno, razão maior do meu viver, razão
para que eu queira ser sempre melhor. Com vocês eu aprendi a ser mãe, aprendi a
entender minha mãe, aprendi que um beijo cura feridas, aprendi o que é o amor
infinito. De vocês ganho beijos, abraços, sorrisos, cartinhas, amizade, amor... que
me transformam numa “super-heroina” capaz de enfrentar tudo e todos.
Agradeço aos meus irmãos Eduardo, Leonardo e Edvaldo, amigos e
parceiros de uma vida. A presença de vocês com certeza deu um sentido muito
especial a minha vida. É uma honra ter cada um de vocês como irmão.
Agradeço ao meu orientador o professor José Luis pela sua disponibilidade,
por confiar em mim, por conduzir este trabalho com tanta serenidade e por transmitir
tanto conhecimento de forma simples e objetiva. Suas atitudes e postura foram sem
dúvidas de um grande mestre. Um grande mentor com o qual adquiri conhecimentos
que levarei pelo resto da vida.
Agradeço aos colegas, professores e amigos do mestrado da Faculdade
IETEC. A colaboração, a parceria, as gargalhadas, os e-mails e mensagens de
vocês foram essenciais por tornar esta jornada mais suave.
Agradeço a todos os amigos que fizeram parte deste momento da minha
vida, as orações e torcida de cada um foi essencial para esta conquista.
RESUMO
Em todas as etapas do processo de desenvolvimento de software existem riscos e
estes podem representar uma oportunidade ou ameaça para o projeto. A prática
precoce do gerenciamento de riscos em projetos de software possibilita conhecer e
controlar os fatores que impactam no projeto, contribuindo assim para sua qualidade
e sucesso. Esse trabalho tem como objetivo propor um modelo conceitual composto
pelos principais fatores de riscos em projetos de desenvolvimento de software que
possibilite aos gerentes de projetos avaliar e monitoriar riscos. Para atingir
resultados que satisfaçam os objetivos deste trabalho foram realizadas atividades de
maneira interativa de acordo com mapa mental previamente elaborado.
Considerando o risco como um requisito não-funcional, modelos para
gerenciamento de riscos foram propostos através do NFR (Non-Functional
Requirements) Framework e Framework i*. Através de um exemplo, conclui-se que
projetos que tratarem no tempo certo as operacionalizações de risco ou parte delas
podem ter maior chance de sucesso.
Palavras-chave: Gestão de Projetos de Software. Gestão de riscos. Requisitos Não-
Funcionais. Metas Flexíveis.
ABSTRACT
In all stages of a software development process there are risks and these may
represent an opportunity or threat to the project. The early practice of risk
management in a software project enables to know and control the factors that
impact on the project, thus contributing to the quality and the success of the project.
This paper aims to propose a conceptual model composed by the main risk factors in
software development projects that allows the project managers to evaluate and
monitor risks. To achieve results that meet the objectives of this work, activities were
carried out in an interactive manner according to a previously elaborated mental
map. Considering risk as a non-functional requirement, risk management models
were proposed through the NFR (Non-Functional Requirements) Framework and
Framework i *. Through an example, it can be concluded that projects that treat in
the righ time the risk operations or part of them may have a greater chance of
success.
Keywords: Software Project Management. Risk Management. Non-Functional
Requirements. Softgoals.
LISTA DE FIGURAS
Figura 1 - Visão geral dos processos de Gerenciamento dos riscos do projeto ....... 15
Figura 2 – Exemplo de um SIG ................................................................................. 18
Figura 3 – Exemplo de um modelo i* ........................................................................ 20
Figura 4 – Mapa Mental elaboração dissertação – visão compactada ..................... 23
Figura 5 – Mapa Mental elaboração dissertação – completo .................................... 24
Figura 6 – Mapa Mental elaboração dissertação – fase desenvolvimento ................ 25
Figura 7 – Mapa Mental elaboração dissertação – fase artigo .................................. 26
Figura 8 – SIG de Gerenciamento de Riscos em Projetos de Software ................... 33
Figura 9 – Representação gráfica da utilização do modelo ...................................... 36
Figura 10 – SIG de Riscos: Operacionalizações das Metas de Gerenciamento de
Escopo ...................................................................................................................... 37
Figura 11 – Modelo SD de Gerenciamento de Escopo ............................................. 38
Figura 12 – Modelo de processo de negócio de gerenciamento de escopo na gestão
de projetos. ............................................................................................................... 41
Figura 13 – Modelo de processo de negócio de gerenciamento de escopo com
inserção dos elementos de risco ............................................................................... 44
LISTA DE QUADROS
Quadro 1 - Notação NFR Framework........................................................................ 18
Quadro 2 - Notação Framework i* ............................................................................. 21
Quadro 3 - Fatores de Riscos de Projeto de Desenvolvimento de Software. ........... 28
Quadro 4 - Fatores de Riscos de Projeto de Desenvolvimento de Software x
Softgoals. .................................................................................................................. 30
Quadro 5 - Detalhamento Modelo SD de Gerenciamento de Escopo. ..................... 38
Quadro 6 - Detalhamento Modelo SD de Gerenciamento de Escopo:
Relacionamento entre atores. ................................................................................... 39
Quadro 7 - Detalhamento Modelo SD de Gerenciamento de Escopo – Tipos de
Dependência. ............................................................................................................ 39
Quadro 8 - Identificação das tarefas conforme processos PMBOK .......................... 42
Quadro 9 - Correspondência de Operacionalizações ............................................... 42
LISTA DE ABREVIATURAS E SIGLAS
BPM Business Process Modeling,
Modelo de Processos de Negócio
BPMN Business Process Modeling Notation,
Modelo e Notação de Processos de Negócio
EAR Estrutura Analítica dos Riscos
ISO International Organization for Standardization,
Organização Internacional de Normalização
I* IStar, IEstrela ou Intecionalidade Distribuída
MPS.BR Melhoria do Processo de Software Brasileiro
NFR Non-functional Requirements
PMBOK Project Management Body of Knowledge
RNFs Requisitos Não-Funcionais
SD Dependência Estratégica
SIG Softgooal Interdependency Graph
SR Razão Estratégica
SUMÁRIO
1 INTRODUÇÃO ............................................................................................. 9
2 OBJETIVOS ............................................................................................... 11
2.1 Objetivo geral ............................................................................................. 11
2.2 Objetivos específicos .................................................................................. 11
2.3 Objetivos propostos no projeto de dissertação .......................................... 11
3 REFERENCIAL TEÓRICO ......................................................................... 13
3.1 Gestão de Projeto de Software ........................................................................... 13
3.2 Gestão de Risco .................................................................................................. 14
3.3 Requisitos Não-Funcionais ................................................................................. 15
3.4 NFR Framework .................................................................................................. 17
3.5 Framework i* ....................................................................................................... 19
3.6 Trabalhos correlatos............................................................................................ 22
4 METODOLOGIA......................................................................................... 23
5 RESULTADOS E DISCUSSÃO ................................................................. 27
6 CONCLUSÕES .......................................................................................... 46
REFERÊNCIAS ......................................................................................................... 47
9
1 INTRODUÇÃO
Devido à evolução tecnológica e maturidade nos processos de negócio, hoje as
organizações estão em busca de sistemas mais eficientes, com isso os sistemas
legados sofrem evoluções e novos softwares são construídos. Desenvolver um
software com qualidade e no menor tempo possível para satisfazer a demanda do
mercado dá a organização uma vantagem competitiva. Porém, incertezas e riscos
existem em todas as etapas de um projeto de desenvolvimento de software (ISLAM,
2014). Segundo Charette (1989), vários estudos mostram histórias de projetos de
softwares mal sucedidos.
Nas últimas décadas, embora a engenharia de software tenha evoluído muito,
falhas em projetos de desenvolvimento de software, onde mais recursos que o
planejado são utilizados, sempre foi um assunto preocupante. No Relatório CHAOS
de 2015 (HASTIE; WOJEWODA, 2015), publicado pelo Standish Group1, onde
foram estudados 50 mil projetos da indústria de desenvolvimento de software em
todo mundo, os seguintes números foram apresentados:
29% dos projetos obtiveram sucesso (concluídos no prazo, dentro do
orçamento e com o escopo acordado).
52% dos projetos não foram executados conforme acordado (atraso na
entrega, estouro de orçamento ou redução de escopo).
19% dos projetos falharam (foram cancelados ou não utilizados).
Esses percentuais, quando expressados em valores monetários, representam
uma quantia significativa para as organizações e, numa organização de
desenvolvimento de software, é um risco corporativo que pode significar sua
sobrevivência.
Com isso, as organizações produtoras de software buscam novas estratégias
para alcançar o sucesso dos projetos e a gestão de risco vem sendo adotada de
forma a minimizar o surgimento de impedimentos que gerem declínio de
produtividade e de qualidade dos softwares gerados (SILVA, 2013). Um projeto de
desenvolvimento de software precisa satisfazer a metas (qualidade, performance,
ambiente e outras) que, normalmente, são modeladas como requisitos não-
funcionais (RNF).
1 Standish Group é uma empresa internacional de consultoria em pesquisa de TI fundada em 1985 conhecida por
seus relatórios sobre projetos de implementação de sistemas de informação no setor público e privado.
10
Requisitos não-funcionais são requisitos que não estão relacionados com os
serviços específicos oferecidos pelo software (o quê o software faz), eles estão
relacionados às propriedades do software, como confiabilidade e tempo de resposta
(como o software faz), (SOMMERVILLE, 2011).
Neste trabalho o risco será considerado um requisito não-funcional, visto que
trata-se de um fator subjetivo, dependente do domínio da aplicação e difícil de ser
avaliado pelas partes interessadas. Utilizando o NFR Framework é possível
visualizar o desdobramento da subjetividade de riscos em desenvolvimento de
software e através do modelo i* serão operacionalizadas ações e responsabilidades
para mitigação de riscos.
O estudo, dado risco como requisito não funcional e definidas suas
operacionalizações concretas que minimizem esses riscos, tem como objetivo
propor um modelo conceitual, composto pelas principais variáveis relacionadas com
risco no desenvolvimento de software, para permitir que gerentes de projetos de
software pensem em riscos sem esquecer detalhes.
Trata-se de um modelo dinâmico, em evolução, que com adoção e utilização,
será acrescido de operacionalizações de riscos e outros detalhes, que vão permitir
mais segurança no trato do risco em projetos de desenvolvimento de software.
Também faz parte do trabalho um método de uso do modelo e um exemplo que
permite aos gerentes de projetos prever como funcionará o processo acrescido das
atividades relativas a riscos e suas operacionalizações e avaliar se os projetos que
adotarem as operacionalizações ou parte delas (e porquê) podem ter maior chance
de sucesso.
Esta pesquisa foi influenciada pelos trabalhos de Chung et al. (2000) e Serrano
(2011) que modelam requisitos não-funcionais como uma rede de metas flexíveis.
De forma geral, este trabalho apresenta no Capítulo 2 o objetivo geral e objetivos
específicos da pesquisa. O Capítulo 3 apresenta o referencial teórico de Gestão de
Projetos de Software, Gestão de Riscos, Requisitos Não-Funcionais e Modelos
Intencionais (NFR Framework e Framework i*). O Capítulo 4 apresenta a
metodologia utilizada para elaboração do trabalho. No Capítulo 5 são apresentados
os principais fatores de riscos identificados no processo de desenvolvimento de
software, os modelos elaborados utilizando tais fatores, um método de uso para o
modelo e um exemplo de aplicação através de processo de negócio (BPM –
11
Bussiness Process Modeling). E por fim, no capítulo 6, são apresentadas as
considerações finais e oportunidades de trabalhos futuros a partir deste.
2 OBJETIVOS
2.1 Objetivo geral
O objetivo principal desta pesquisa é propor um modelo conceitual composto
pelas principais variáveis relacionadas com riscos no processo de desenvolvimento
de software, que permita aos gerentes de projetos avaliar e monitorar riscos
adequadamente nesse domínio de conhecimento.
2.2 Objetivos específicos
Como objetivos específicos pretende-se:
Identificar as principais variáveis de risco que têm impacto no processo de
desenvolvimento de software;
Compreender como estas variáveis se relacionam;
Criar um método de uso para o modelo;
Apresentar um exemplo de aplicação do modelo.
2.3 Objetivos propostos no projeto de dissertação
No momento da elaboração do projeto de dissertação o objetivo principal era
propor um modelo, composto pelas principais variáveis relacionadas com riscos no
processo de desenvolvimento de software, que permitisse a avaliação e
monitoramento de riscos nesse domínio de conhecimento.
Naquele momento, a ideia era construir um modelo utilizando dinâmica de
sistemas, realizar simulações, comparar os resultados destas simulações com casos
reais e produzir uma interface para facilitar a utilização do modelo.
No decorrer do levantamento bibliográfico e desenvolvimento dos modelos, não
foi possível conseguir dados reais disponíveis para alimentar os modelos e realizar
as simulações em bases reais. Esses dados certamente existem, mas nunca estão
12
disponíveis em bases públicas que possam ser usadas para estudos e reprodução
de resultados. Tomou-se então a decisão de alterar o rumo do projeto, partindo para
modelagem qualitativa, que se mostrou efetiva e com bons resultados.
Mediante os estudos realizados, chegou-se ao modelo NFR Framework, utilizado
para modelar requisitos não-funcionais. Baseado neste modelo e trabalhos
promissores correlatos nesta área, foi feita a alteração de rumo no projeto, citada
acima. Iniciou-se então o redirecionamento da dissertação, tratando risco como
requisito não-funcional, o que permitiu avançar e terminar a pesquisa.
13
3 REFERENCIAL TEÓRICO
3.1 Gestão de Projeto de Software
Projeto é um conjunto de atividades que tem início e fim definidos, são
realizadas em grupo e destinadas a criar um produto, serviço ou resultado único
(PMBOK, 2017). A finalidade de um projeto de desenvolvimento de software é obter
um produto de software.
Segundo PMBOK (2017), gerenciamento de projetos é a aplicação de
conhecimento, habilidades, ferramentas e técnicas às atividades do projeto para
atender a seus requisitos. Com o objetivo de garantir que o projeto satisfaça o
orçamento, o cronograma, a necessidade do cliente e seja entregue com qualidade,
o gerenciamento de projetos de software é uma parte primordial da engenharia de
software.
O gerenciamento de projetos pode proporcionar vantagens ao
desenvolvimento de software como cumprimento dos prazos, controle do
orçamento, flexibilidade para alterações de escopo, antecipação a possíveis
problemas, qualidade do produto entregue e outros. De acordo com Sommerville
(2011), um bom gerenciamento não garante o sucesso do projeto. Porém, o mau
gerenciamento normalmente resultará em falhas do projeto como entrega com
atraso, custo maior que estimado, software que não atende as expectativas dos
clientes e outros.
No gerenciamento de projetos de software, além de gerenciar o produto a ser
entregue, é necessário que seja feita a gestão de pessoas, processos, custos,
prazos e outros fatores que possam aparecer conforme evolução do
desenvolvimento do software.
Sommerville (2011) destaca que os critérios de sucesso para o
gerenciamento de projetos de software variam de um projeto para outro, mas, para a
maioria dos projetos, os benefícios mais importantes são: entregar o software ao
cliente no prazo estabelecido; manter os custos dentro do orçamento; entregar um
software que atenda às expectativas do cliente e manter uma equipe de
desenvolvimento que trabalhe bem e motivada.
14
3.2 Gestão de Risco
Segundo PMBOK (2017), o risco é um evento ou condição incerta que, se
ocorrer, terá um efeito positivo (oportunidade) ou negativo (ameaça) sobre pelo
menos um objetivo do projeto envolvendo tempo, custo, escopo ou qualidade.
Macedo e Salgado (2015), baseado em Charette (2005), definem risco como um
evento ou o estado que pode causar danos, perda, ou atraso num projeto de
software.
O gerenciamento de risco é fundamental para a gestão de projetos, sendo
uma das dez áreas de conhecimento do PMBOK e também tratado por modelos de
avaliação da qualidade de processos de software como ISO/IEC15504 e MPS.BR.
O gerenciamento de risco do projeto, segundo o PMBOK (2017), é composto
pelos processos abaixo, com o objetivo de aumentar a probabilidade e o impacto
dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos
ao projeto:
Planejar o gerenciamento dos riscos: etapa onde se define como as
atividades de gerenciamento de riscos do projeto serão realizadas;
Identificar os riscos: etapa que consiste na determinação dos riscos que
podem afetar o projeto e documentação destes;
Realizar a análise qualitativa dos riscos: etapa de priorização de riscos,
combinação de probabilidade de ocorrência e impacto;
Realizar a análise quantitativa dos riscos: etapa de análise numérica do
efeito dos riscos identificados nos objetivos gerais do projeto;
Planejar as respostas aos riscos: etapa para desenvolver opções e ações
para aumentar as oportunidades e reduzir as ameaças aos objetivos do
projeto;
Controlar os riscos: etapa para implementar planos de respostas aos
riscos, acompanhar os riscos identificados, monitorar riscos residuais,
identificar novos riscos e avaliar a eficácia do processo de gerenciamento
dos riscos durante todo o projeto.
15
Figura 1 - Visão geral dos processos de Gerenciamento dos riscos do projeto
Fonte: Adaptado de Project Management Institute (2017)
De acordo com PMBOK (2017), aspectos do ambiente corporativo ou do
projeto, tais como práticas imaturas de gerenciamento, falta de sistemas integrados,
vários projetos simultâneos e dependências externas contribuiem para os riscos do
projeto.
Logo, para obter sucesso em seus projetos, é importante que, durante todo o
projeto, as organizações, pessoas ou grupos estejam comprometidos com um
tratamento proativo e eficaz de gerenciamento de riscos.
3.3 Requisitos Não-Funcionais
Na engenharia de software, requisitos são definidos como as descrições do
que o sistema deve fazer, os serviços que oferecem e as restrições a seu
funcionamento, refletindo as necessidades dos clientes para um sistema
(SOMMERVILLE, 2011).
Os requisitos de software são classificados em:
Requisitos Funcionais: descrevem “o que” o sistema deve fazer, como o
sistema deve reagir a entradas específicas e como o sistema deve se
comportar em determinadas situações.
Requisitos Não-Funcionais: fixam restrições sobre “como” os requisitos
funcionais serão implementados, ou seja, restringem "como" o sistema
16
deve realizar o "o que", restrições custos de desenvolvimento,
performance, portabilidade, robustez e outros.
Ao contrário dos requisitos funcionais, os requisitos não-funcionais não
revelam nenhuma função a ser executada pelo software, e sim como o software
funcionará e restrições que ele deve satisfazer.
Um exemplo da diferença entre os tipos de requisitos:
Requisito funcional: “O sistema imprime recibos”
Requisito não-funcional: “O sistema imprime recibos rápido”.
Os requisitos não-funcionais são conhecidos como requisitos de qualidade do
software, como por exemplo, precisão, usabilidade, segurança, desempenho,
confiabilidade, segurança, (XAVIER et al, 2009).
Os requisitos não-funcionais surgem por meio das necessidades dos
usuários, devido a restrições de orçamento, políticas organizacionais, necessidade
de interoperabilidade com outros sistemas de software ou hardware, ou a partir de
fatores externos, como regulamentos de segurança ou legislações de privacidade.
A implementação de requisitos não-funcionais pode se propagar por todo o
software. Esses requisitos definem restrições globais do software, do processo de
desenvolvimento e do processo de implantação, sendo considerados globais no
sentido de que eles surgem de todas as partes do sistema e de suas interações
XAVIER et al.(2009), podendo afetar toda a arquitetura do sistema e não apenas
componentes individuais.
Requisitos não-funcionais são mais críticos no desenvolvimento de um
software, pois podem ser contraditórios entre si, são difíceis de especificar ou
modelar formalmente e muitas vezes não são considerados durante o
desenvolvimento do projeto.
A não identificação de um requisito não-funcional durante o desenvolvimento
do software pode gerar a necessidade de recodificação, que poderá ser demorada e
de difícil adaptação, e como consequência, elevar o custo do projeto gerando um
prejuízo.
Além disto, no projeto de software, se determinada função do sistema não for
implementada, o usuário pode encontrar uma maneira de contornar, porém, se um
requisito não-funcional não for atendido isso poderá significar a inutilização do
sistema.
17
3.4 NFR Framework
O NFR Framework foi proposto em 2000 por Chung et al., tendo como foco a
modelagem de requisitos não-funcionais e suas operacionalizações, através da
construção de um gráfico SIG (Softgoal Interdependency Graph), que descreve as
dependências entre softgoals (metas-flexíveis) e como eles são decompostos
(SERRANO, 2011). Meta-flexível, sinônimo de softgoal, são qualidades (segurança,
desempenho, confiabilidade e outras) desejadas pelos atores que não possuem
critérios claros para sua satisfação, ou seja, são subjetivas e dependentes dos
pontos de vista dos interessados (OLIVEIRA et al., 2011).
Neste framework os requisitos não-funcionais são tratados como metas
(softgoal) que serão identificadas e refinadas, sendo representadas por uma
estrutura gráfica inspirada nas árvores And / Or (XAVIER et al., 2009). Um softgoal é
refinado até ao ponto em que as operacionalizações sejam atingidas, gerando
assim, requisitos funcionais em função da necessidade de detalhar os requisitos
não-funcionais.
Conforme colocado por Cysneiros e Yu (2004), o requisito não-funcional
quando operacionalizado resulta em novos requisitos funcionais, um processo
iterativo onde é possível visualizar o impacto de tomar uma decisão ao invés da
outra.
Para Chung et al. (2000) as metas estão relacionadas à intencionalidade dos
atores, enquanto requisitos (funcionais e não-funcionais) são características
implementadas por funções do software.
A figura 2 apresenta um exemplo de um SIG, onde o softgoal raiz foi refinado
em mais softgoals, formando então um grafo de dependências, onde uma
dependência pode contribuir parcialmente, positivamente, ou negativamente para o
nível superior na árvore.
18
Figura 2 – Exemplo de um SIG
Fonte: Adaptado de Serrano (2011).
O quadro abaixo apresenta os principais símbolos da notação utilizada pela NFR Framework.
Quadro 1 - Notação NFR Framework
Softgoal – metas desejáveis que não possuem critérios claros para sua satisfação, ou seja, são subjetivas e dependem do ponto de vista dos interessados.
Operacionalização (uma possível operação para satisfazer um softgoal)
Observação (auxilia revisões futuras)
Help – os fluxos identificados com o Help indicam que o softgoal contribui positivamente para o elemento imediatamente superior.
Make – os fluxos identificados com o Make indica que há uma contribuição obrigatória para que a característica superior seja atendida.
Contribuição AND – Se todas as dependências forem atendidas, então a raiz também
Contribuição OR – Se uma das dependências for atendida, a raiz também será.
Contribuição positiva • Um filho satisfeito resulta num pai satisfeito • Um filho recusado resulta num pai recusado
• Contribuição negativa • Um filho satisfeito resulta num pai recusado • Um filho recusado resulta num pai satisfeito
Fonte: Adaptado Serrano (2011).
Importante: Além das relações HELP e MAKE, outras relações podem ser
definidas para indicar influência do tipo BREAK (provê contribuição negativa
suficiente para que a característica superior não seja atendida), HURT (provê
contribuição negativa parcial para que a característica superior não seja atendida) e
UNKNOWN (provê contribuição, porém não se sabe se negativa ou positiva).
19
Através do gráfico de dependências, é possível avaliar as metas e apurar se
determinado requisito não-funcional está sendo alcançado em um projeto especifico.
Porém, conforme Xavier et al.(2009), as metas representam requisitos não-
funcionais e raramente estes podem ser considerados totalmente “satisfeitos”.
3.5 Framework i*
O modelo intencional tem como objetivo descrever processos que envolvem
vários atores, refletindo as motivações e interesses destes atores, bem como o
relacionamento entre eles. A modelagem é baseada em atores, metas, crenças,
habilidades e compromissos e representam a dependência mútua nas metas,
tarefas e recursos. Diferente das demais técnicas de modelagem, expressa o
porquê de determinada ação ou tomada de decisão (YU, 1995).
O Framework i* (i-estrela), proposto em 1995 por Eric Yu, é uma técnica de
modelagem conceitual para descrição de processos que envolvem vários atores
(SERRANO, 2011). Esta técnica concentra-se no relacionamento entre atores
(homens, softwares, hardwares ou ambos) e suas dependências, focando nas
razões ou motivações que estão associadas aos comportamentos (os porquês).
O i* possui representação gráfica na forma de uma rede de relacionamentos,
sendo formado por dois modelos básicos: o Modelo SD (modelo de dependência
estratégica) e o Modelo SR (modelo de razão estratégica).
O Modelo SD descreve relações de dependência estratégica entre vários
atores. É um modelo baseado em um conjunto de nós, que representam os atores,
e arestas, que define a dependência entre os atores.
Os atores dependem uns dos outros para alcançarem seus objetivos, realizar
tarefas e fornecer recursos. Através da cooperação um ator pode alcançar objetivos
que sozinho seria difícil.
O ator que depende de outro é chamado de depender e o ator responsável
por cumprir a dependência é chamado de dependee.
De acordo com OLIVEIRA et al. (2011), existem os seguintes tipos de
dependências entre atores:
Dependência por meta: o depender necessita do dependee para
alcançar um objetivo e não se importa como vai ser atingido.
Dependência por tarefa: o depender necessita do dependee para
alcançar um objetivo e estipula como vai ser feito.
20
Dependência por recurso: o depender necessita que o dependee
forneça o recurso.
Dependência por meta-flexível: o depender tem a decisão final. A
satisfação desse tipo de objetivo é medida de forma subjetiva.
Identificados os atores relevantes e seus objetivos, o modelo SD pode ser
dado como finalizado e o modelo SR elaborado.
O Modelo SR explica como os atores atingem suas metas, visto que, este
representa de forma mais explicita como os interesses dos atores podem ser
atendidos ou como são afetados.
No Modelo SR os elementos intencionais, metas, tarefas, recursos e metas
flexíveis aparecem não apenas como dependências externas, mas também como
elementos organizados em estruturas hierárquicas com relacionamentos meio-fim,
decomposição de tarefas e relacionamento de contribuição.
De forna geral, o modelo SD pode ser entendido como um modelo em nível
maior de abstração, enquanto o modelo SR diminui esta abstração, possibilitando
entendimento mais detalhado sobre os atores envolvidos.
O Framework i* possui uma boa maturidade em função da sua propagação
na área de engenharia de software (workshops, livros, trabalhos publicados).
Figura 3 – Exemplo de um modelo i*
Fonte: Elaborado pelo autor (2018).
21
O quadro abaixo apresenta os principais símbolos da notação utilizada pelo Framework i*. Quadro 2 - Notação Framework i*
Atores: entidades ativas que podem executar ações para atingir metas
Metas: objetivos dos atores
Tarefas: ações que os atores podem realizar no ambiente visando atingir suas metas.
Softgoal – metas desejáveis
Recurso – Entradas/Saídas
Dependência
Fonte: Adaptado Serrano (2011).
Importante: As relações HELP, MAKE, BREAK e HURT também podem ser
representadas no modelo i*.
No modelo da figura 3, é apresentado um exemplo genérico do
desenvolvimento de uma funcionalidade, visualmente apresentado a partir do
modelo SD de NFR Framework, sendo possível visualizar os atores do processo,
metas, recursos e suas dependências. Os atores envolvidos (stakeholder, gerente
de projeto e desenvolvedor) possuem como meta o Requisito Desenvolvido. Trata-
se de uma meta compartilhada entre eles, o stakeholder “quer” o requisito
desenvolvido, o desenvolver pode “dar” através da intervenção do gerente de
projetos. Para alcançar a meta, dependências de tarefas e recursos são criadas:
- é necessário que o stakeholder solicite o desenvolvimento do requisito para
que então o gerente de projetos encaminhe ao desenvolvedor;
- ao receber a demanda, para que o stakeholder valide a especificação do
requisito, é preciso que o desenvolver a elabore e disponibilize ao gerente do
projeto;
- para que o desenvolvedor desenvolva/entregue o produto é necessário que
o stakeholder aprove a especificação e envie ao gerente do projeto.
Cada dependência representa um relacionamento de cooperação entre os
atores.
22
3.6 Trabalhos correlatos
Dentre trabalhos estudados, foram importantes para este estudo:
Charette, 1989: proporcionou mais conhecimento sobre riscos e impactos
deste no desenvolvimento de software. Charette apresenta dificuldades
antigas como superação de custos, atrasos no projetos e necessidades de
usuários não atendidas, que mesmo com toda evolução da Engenharia de
Software está presente nos projetos;
Schmidt, 2015; Lopes (2014) e Barki (2015): apresentam, no formato de
lista, os principais fatores de risco em projetos de desenvolvimento de
software, sendo destes extraídos e consolidados os dados para criação do
catalago de riscos utilizado neste estudo;
Chung et al. (2000); YU, E (1995) e Serrano (2011): modelam requisitos
não-funcionais como uma rede de metas flexíveis;
XAVIER et al. (2009): apresentam um estudo integrando Requisitos não
Funcionais a Processos de Negócios;
ISLAM et al. (2014): apresentam um modelo de gestão de risco em
projetos de softwares orientado por objetivos;
PMI - Um Guia Do Conhecimento Em Gerenciamento De Projetos. (Guia
Pmbok®) – Sexta Edição, 2017.
23
4 METODOLOGIA
Para elaboração desse trabalho, foi realizada uma pesquisa, através dos
principais mecanismos de busca na web, para identificar os principais fatores de
risco em projetos de desenvolvimento de software. Após esta identificação foi
elaborado um modelo composto pelas principais variáveis de risco de um projeto de
desenvolvimento de software. Criado o e um exemplo de aplicação através de
processo de negócio (BPM – Bussiness Processs Modeling) foi implementado.
Essa pesquisa possui a seguinte classificação:
Quanto à natureza: aplicada, uma vez que visa obter resultados a serem
aplicados na solução de problemas das organizações.
Quanto aos seus objetivos: exploratória, visto que irá proporcionar maior
familiaridade com o problema e aprimorar idéias.
Quanto à forma de abordagem do problema: qualitativa, visto que irá buscar
entender o porquê de certas ocorrências, considerando uma relação entre o
mundo real e seu sujeito.
Quanto ao método de pesquisa: modelagem e simulação, visto que se
pretende construir um modelo e possibilitar simulações com dados fictícios.
Para alcançar os objetivos propostos pela pesquisa, foram executados de forma
incremental e iterativa, os passos contidos no mapa mental abaixo:
Figura 4 – Mapa Mental elaboração dissertação – visão compactada
Fonte: Elaborado pelo autor (2018).
A figura 5 apresenta uma visão completa do mapa mental, com detalhamento de
todas as atividades realizadas:
24
Figura 5 – Mapa Mental elaboração dissertação – completo
Fonte: Elaborado pelo autor (2018).
25
A figura 6 apresenta uma visão do mapa mental, com foco nas atividades referente a fase de desenvolvimento:
Figura 6 – Mapa Mental elaboração dissertação – fase desenvolvimento
Fonte: Elaborado pelo autor (2018).
26
A figura 7 apresenta uma visão do mapa mental, com foco nas atividades referente a fase de elaboração do artigo:
Figura 7 – Mapa Mental elaboração dissertação – fase artigo
Fonte: Elaborado pelo autor (2018).
27
5 RESULTADOS E DISCUSSÃO
5.1 Apresentação do Estudo
A literatura existente sobre gerenciamento de riscos em projetos de
desenvolvimento de software indica que um dos maiores motivos de falhas neste
tipo de projeto é a inadequada, ou até mesmo inexistente, avaliação dos fatores
de risco.
Apoiadores de gerenciamento de riscos de software afirmam que ações
para reduzir as chances de falhas de um projeto podem ser tomadas a partir da
identificação e análise das ameaças ao sucesso do projeto, ao longo de todo o
ciclo do processo de desenvolvimento (SCHMIDT, 2015).
Para avaliar os riscos de um projeto é necessário identificar quais são na
realidade esses riscos e conhecer aqueles que merecem maior atenção do
gerente de projeto. Porém, os gerentes de projetos encontram dificuldades para
identificar os riscos mais comuns num projeto de software.
Diante deste cenário, a primeira etapa deste trabalho foi identificar, através
da literatura, as principais variáveis de risco que impactam no processo de
desenvolvimento de software. Dentre as opções encontradas na bibliografia
disponível, Schmidt (2015) apresenta uma lista extensa de fatores de riscos em
projetos de software. Esta lista foi criada baseada em pesquisas realizadas em
diferentes países (Hong Kong, Finlândia e Estados Unidos), com base no
conhecimento de diferentes gerentes de projetos e, posteriormente, os resultados
das pesquisas foram comparados com outros fatores de riscos publicados.
Para este trabalho, a lista publicada por Schmidt foi então comparada com
publicações de Lopes (2014) e Barki (2015) que também apresentam fatores de
risco em projetos de software. Com base nesta comparação, os fatores referentes
à Planejamento e Comunicação foram adicionados à lista de Schmidt, definindo
assim, o conjunto de fatores de riscos abaixo que serviu como base para o
estudo apresentado:
28
Quadro 3 - Fatores de Riscos de Projeto de Desenvolvimento de Software.
Lista de Fatores de Risco
1. Ambiente Corporativo
Mudança no ambiente empresarial e organizacional
Incompatibilidade entre cultura empresarial e novos processos
Falta de valor de negócio e apoio
Ambiente corporativo instável (pressões competitivas alteram radicalmente os requisitos do usuário)
Mudanças propriedade e/ou alta gerência
Inexistência Alinhamento Estratégico
2. Patrocínio / propriedade
Falta de comprometimento alta direção
Falta de aceitação do projeto
Falta comprometimento do usuário
Conflito entre departamentos
Falta de aprovação de todas as partes
3. Gestão de Relacionamento
Falta de gerenciar as expectativas do usuário
Envolvimento inadequado dos usuários
Falta de cooperação dos usuários
Falha na identificação/envolvimento de todos stakeholders
Aumento nas expectativas dos usuários
Gerenciando múltiplas relações com as partes interessadas
A falta de experiência adequada dos usuários chaves
4. Gerenciamento de Projetos
Não gerir ou gerir inadequadamente mudanças
Falta de habilidade/poder para gerenciar o projeto
Metodologia inexistente/inadequada
Definição inadequada dos papéis e responsabilidades
Controle pobre ou inexistente
Gerenciamento de riscos inexistente/inadequado
Escolha da estratégia de desenvolvimento errada
5. Escopo
Objetivos / Escopo mal entendidos e/ou mal definidos
Mudanças de escopo / objetivos
Má definição ou definição incompleta
Foco somente tecnológico /Ignorar requisitos de negócios
Muitas linhas de comunicação
29
6. Requisitos
Falta de Requisitos Congelados (Mudanças)
Má definição / entendimento
Falta de domínio/conhecimento do assunto
7. Financiamento
Custo de desenvolvimento mal estimado
Ausência de orçamento para custo de manutenção
8. Cronograma (Agendamento)
Prazo mal estimado
Prioridade inferior a outros projetos
9. Processo de desenvolvimento
Metodologia inexistente/inadequada
Nova metodologia / tecnologia
10. Pessoal (Personnel)
Falta de conhecimento / competência
Falta de competência / habilidade para gerenciamento
Relacionamento ruim da equipe
11. Pessoal (Sttafing)
Pessoal envolvido insuficiente / inapropriado
Rotatividade de pessoas
Uso excessivo de terceiros
Falta de conhecimento / competência e disponibilidade dos envolvidos
12. Tecnologia
Novas tecnologias
Instabilidade da arquitetura técnica
13. Dependências Externas
Dependências externas não atendidas
Múltiplos Fornecedores
Falta de controle sobre terceiros / fornecedores
14. Planejamento
Planejamento inexistente / inadequado
15. Comunicação
Comunicação inexistente / inadequada
Fonte: Elaborado pelo autor.
Para a construção desta lista foi realizada uma revisão bibliográfica, sendo
efetuadas pesquisas através dos principais mecanismos de busca na web, com o
objetivo de encontrar estudos que apresentassem a identificação de variáveis de
riscos. Não apareceram outras classificações que subjuguem as citadas acima,
utilizadas neste trabalho.
30
Identificados os principais fatores de riscos de um projeto de software, o
próximo passo foi a criação de um modelo de gerenciamento de riscos através do
NFR Framework.
Como já afirmado antes, neste trabalho risco é tratado como meta-flexível
ou um softgoal conforme o trabalho de SERRANO (2011), baseado em CHUNG
et al. (2000). A partir desta premissa, utilizando o NFR Framework, foi possível
criar um SIG de Riscos, o que facilita a análise e o entendimento de como os
fatores de risco interagem entre si.
Para criação do SIG de Riscos, utilizando o Quadro 3, os fatores de riscos
foram renomeados apropriadamente para serem tratados como softgoals,
conforme apresentado no Quadro 4 e, posteriormente o softgoal Risco foi
refinado.
Quadro 4 - Fatores de Riscos de Projeto de Desenvolvimento de Software x Softgoals.
Lista de Fatores de Risco Softgoals
1. Ambiente Corporativo Ambiente Corporativo
Mudança no ambiente empresarial e organizacional
Volatilidade ambiente corporativo
Incompatibilidade entre cultura empresarial e novos processos
Incompatibilidade entre cultura empresarial e novos processos
Falta de valor de negócio e apoio Ausência de valor de negócio e apoio
Ambiente corporativo instável (pressões competitivas alteram radicalmente os requisitos do usuário)
Instabilidade ambiente corporativo
Mudanças propriedade e/ou alta gerência Modificabilidade de propriedade e/ou alta gerência
Inexistência Alinhamento Estratégico Inexistência Alinhamento Estratégico
2. Patrocínio / propriedade Propriedade
Falta de comprometimento alta direção Ausência de comprometimento alta direção
Falta de aceitação do projeto Ausência de aceitação do projeto
Falta comprometimento do usuário Ausência comprometimento do usuário
Conflito entre departamentos Incompatibilidade entre departamentos
Falta de aprovação de todas as partes Ausência de aprovação de todas as partes
3. Gestão de Relacionamento Relacionabilidade
Falta de gerenciar as expectativas do usuário Ausência de gerenciamento das expectativas dos usuários
Envolvimento inadequado dos usuários Envolvimento inadequado dos usuários
31
Falta de cooperação dos usuários Ausência de cooperação dos usuários
Falha na identificação/envolvimento de todos stakeholders
Falha na identificação / envolvimento de todos stakeholders
Aumento nas expectativas dos usuários Aumento de expectativas dos usuários
Gerenciando múltiplas relações com as partes interessadas
Gerenciabilidade de múltiplas relações com as partes interessadas
A falta de experiência adequada dos usuários chaves
Inexperiência dos usuários chaves
4. Gerenciamento de Projetos Gerenciabilidade
Não gerir ou gerir inadequadamente mudanças
Ausência de gestão / gestão inadequadamente mudanças
Falta de habilidade/poder para gerenciar o projeto
Ausência de habilidade/poder para gerenciar o projeto
Metodologia inexistente/inadequada Metodologia inexistente/inadequada
Definição inadequada dos papéis e responsabilidades
Ineficiente definição de papéis e responsabilidades
Controle pobre ou inexistente Ineficiente / inexistente controle
Gerenciamento de riscos inexistente/inadequado
Gerenciabilidade de riscos inexistente/inadequada
Escolha da estratégia de desenvolvimento errada
Ausência de assertividade na escolha da estratégia de desenvolvimento
5. Escopo Escopo
Objetivos / Escopo mal entendidos e/ou mal definidos
Ineficiente definição/entendimento de escopo e objetivos
Mudanças de escopo / objetivos Modificabilidade de escopo / objetivos
Má definição ou definição incompleta Ineficiente / Incompleta definição
Foco somente tecnológico /Ignorar requisitos de negócios
Foco exclusivamente tecnológico
Muitas linhas de comunicação
Variabilidade de linhas de comunicação
6. Requisitos Requisitos
Falta de Requisitos Congelados (Mudanças) Instabilidade
Má definição / entendimento Ineficiente definição / entendimento
Falta de domínio/conhecimento do assunto
Ausência de domínio/conhecimento do assunto
7. Financiamento Custo
Custo de desenvolvimento mal estimado Custo de desenvolvimento mal estimado
Ausência de orçamento para custo de manutenção
Ausência de orçamento para custo de manutenção
8. Cronograma (Agendamento) Tempo de Desenvolvimento
Prazo mal estimado Tempo de desenvolvimento mal estimado
Prioridade inferior a outros projetos Prioridade inferior a outros projetos
9. Processo de desenvolvimento Metodologia
Metodologia inexistente/inadequada Metodologia inexistente/inadequada
Nova metodologia / tecnologia Imaturidade da metodologia / tecnologia
32
10. Pessoal (Personnel) Pessoas
Falta de conhecimento / competência Ausência de conhecimento / competência
Falta de competência / habilidade para gerenciamento
Ausência de competência / habilidade para gerenciamento
Relacionamento ruim da equipe Baixa afinidade da equipe
11. Pessoal (Sttafing) Pessoal (Sttafing)
Pessoal envolvido insuficiente / inapropriado Pessoal envolvido insuficiente / inapropriado
Rotatividade de pessoas Rotatividade de pessoas
Uso excessivo de terceiros Alto número de terceiro
Falta de conhecimento / competência e disponibilidade dos envolvidos
Ausência de conhecimento / competência dos envolvidos
12. Tecnologia Tecnologia
Novas tecnologias Novas tecnologias
Instabilidade da arquitetura técnica Instabilidade da arquitetura técnica
13. Dependências Externas Dependências Externas
Dependências externas não atendidas Dependências externas não atendidas
Múltiplos Fornecedores Múltiplos Fornecedores
Falta de controle sobre terceiros / fornecedores
Ausência de controle sobre terceiros / fornecedores
14. Planejamento Planejamento
Planejamento inexistente / inadequado Inexistente / inadequado
15. Comunicação Comunicação
Comunicação inexistente / inadequada Inexistente / inadequado
Fonte: Elaborado pelo autor.
Observa-se que todos os refinamentos foram realizados de acordo com o
Quadro 4: Fatores de Riscos de Projeto de Desenvolvimento de Software x
Softgoals, que é o Catálogo de Riscos de Software utilizado neste trabalho.
Com o SIG de Riscos elaborado, é possível compreender que ao gerenciar
Ambiente Corporativo, Propriedade, Relacionabilidade, Gerenciabilidade, Escopo,
Custo, Tempo de Desenvolvimento, Metodologia, Pessoas, Recursos do Projeto,
Tecnologia, Dependências Externas, Planejamento e Comunicação, os riscos do
projeto estarão sendo gerenciados. Neste caso, temos uma contribuição positiva
entre as dependências e se todas as dependências forem atendidas, então a raiz
também será.
33
Figura 8 – SIG de Gerenciamento de Riscos em Projetos de Software
Fonte: Elaborado pelo autor (2018).
34
O SIG de Riscos mostra como os requisitos não-funcionais, ou metas
flexíveis, contribuem para gestão de riscos de software, uma vez que além de
mostrar os desdobramentos, apresenta também o inter-relacionamento entre
diversos softgoals, bem como entre operacionalizações, mas também os
impactos negativos e positivos entre eles. O que pode ser transversal, ou seja,
ocorrer entre elementos de ramificações diferentes.
A árvore apresentada acima poderá ser utilizada pelos gerentes de
projetos como framework no momento da identificação de riscos de um projeto de
desenvolvimento de software. Através de sua aplicabilidade é possível verificar se
os fatores de risco mais comuns em projetos de softwares estão sendo
gerenciados e, ainda, gerar uma Estrutura analítica dos riscos (EAR) completa e
detalhada, uma vez que a árvore engloba fatores técnicos, organizacionais,
gerenciais e externos.
5.2 Método para uso do SIG de RISCOS
A criação do modelo de gerenciamento de riscos, através do NFR
Framework, possibilita que o gerente de projetos conheça os principais fatores de
riscos em um projeto de desenvolvimento de software e identifique quais destes
fatores deverão ser gerenciados em determinado projeto. Esta abordagem
permite que o gerente de projeto insira os requisitos não-funcionais, no caso os
riscos, em seu processo de desenvolvimento.
A abordagem consiste basicamente em oito fases:
Analisar do SIG de Riscos proposto;
Identificar os fatores pertinentes no projeto gerenciado;
Efetuar um recorte dos Riscos Eminentes;
Refinar os riscos identificados detalhando suas operacionalizações;
Elaborar o modelo SD;
Elaborar um modelo para o processo de desenvolvimento de software,
caso não exista;
Relacionar as tarefas do Processo x RNF x Operacionalizações;
Inserção das operacionalizações no modelo do processo de
desenvolvimento de software.
35
Abaixo é apresentada uma descrição referente a cada fase:
1ª Fase - Analisar o SIG de Riscos proposto: essa fase consiste em, de
posse do SIG de Risco apresentado neste estudo, o gerente de projetos irá
conhecer os principais riscos de projetos de desenvolvimento de software.
2ª Fase - Identificar os fatores pertinentes no projeto gerenciado: sabe-se
que nenhum projeto é igual ao outro, logo os riscos também mudam. Nesta fase,
o gerente de projetos deverá então utilizar o SIG de Risco para identificar quais
são os riscos mais prováveis para determinado projeto.
3ª Fase - Efetuar um recorte dos Riscos Eminentes: Nesta fase, com os
riscos já identificados para o projeto, deverá ser efetuado um recorte no modelo
proposto, destacando apenas os riscos identificados como pertinentes.
4ª Fase - Refinar os riscos identificados detalhando suas
operacionalizações: Como o SIG de Riscos apresentado não detalha as
operacionalizações de todas as metas, este passo consiste em refinar os riscos
identificados (RNF) até que sejam descobertas as operacionalizações destes
requisitos para que se transformem em atividades dentro do modelo de processo
de negócio. Se existir algum catálogo para requisito não-funcional em questão,
desde que adaptado para o domínio do projeto, ele poderá ser utilizado.
5ª Fase - Elaborar o modelo SD: com objetivo de visualizar e identificar as
interações entre atores, processos, metas e metas flexíveis, um modelo SD
deverá ser elaborado. Com este modelo será possível conhecer de todas as
dependências e interações do processo.
6ª Fase - Elaborar um modelo para o processo de desenvolvimento de
software; caso não exista, deverá ser elaborado um modelo de processo de
negócio para o desenvolvimento de software. Sugere-se que este modelo de
processo seja elaborado utilizando BPMN, que é uma interface amigável e de
fácil compreensão para todos os envolvidos no processo de desenvolvimento de
software. É importante que este modelo seja refinado e validado com os usuários.
7ª Fase - Relacionar as tarefas do Processo x RNF x Operacionalizações:
de posse dos riscos identificados para o projeto especifico, nesta fase eles e suas
operacionalizações serão associados de forma explicita a uma tarefa do modelo
de processo de negócio.
36
Para facilitar o rastreamento entre a tarefa do processo de negócio, o RNF
e a operacionalização, deverá ser criada uma tabela de relacionamento.
8ª Fase - Inserção das operacionalizações no modelo do processo de
desenvolvimento de software: e por último, o modelo de processo de negócio de
desenvolvimento de software deverá alterado, sendo inserido neste as
operacionalizações referentes aos RNF nas tarefas relacionadas.
Não é necessário que todas operacionalizações sejam inseridas no modelo
de processo, caberá ao gerente de projetos definir quais operacionalizações são
mais pertinentes ao projeto gerenciado.
No processo de negócio as operacionalizações se transformarão em
atividades ou macroprocessos, uma maneira explicita de introduzir no processo
de negócio a modelagem dos riscos do projeto.
A Figura 9 representa graficamente a sequência das fases a serem
executados na utilização do modelo:
Figura 9 – Representação gráfica da utilização do modelo
Fonte: Elaborado pelo autor (2018).
5.3 Um exemplo de Aplicação
De acordo com o método de utilização do modelo, para este exemplo, a
fase 1 será descartada, visto que a análise do SIG de Riscos faz parte do estudo
e não iremos tratar um projeto especifico, mas sim uma das áreas referentes a
gerenciamento de projetos, o Gerenciamento do Escopo.
Esta escolha é baseada na importância de Gerenciamento de Escopo na
estabilidade do projeto, visto que seus processos precisam estar bem integrados
com as outras áreas do gerenciamento de projeto para que resulte numa entrega
com sucesso, ou seja, produto esperado dentro do prazo e custo estimado.
Para atender a fase 2, serão considerados os riscos identificados no SIG
de Riscos referente ao nó Escopo. Logo, na fase 3, será feito um recorte do SIG
de Riscos referente a este nó.
37
Já na fase 4, como o SIG de Riscos apresentado através da figura 8 não
detalha as operacionalizações de todas as metas, a figura abaixo, apresenta o
recorte do SIG de Riscos com a inserção das operacionalizações que serão
tratadas neste estudo para o caso de Gerenciamento do Escopo.
Figura 10 – SIG de Riscos: Operacionalizações das Metas de Gerenciamento de
Escopo
Fonte: Elaborado pelo autor (2018).
A fase 5 consiste em apresentar um exemplo de interação de agentes que
será aplicado sobre o domínio de Gerenciamento de Escopo.
De acordo com o PMBOK (2017), o gerenciamento do escopo do projeto
está relacionado com a definição e controle do que está e do que não está
incluso no projeto, sendo composto pelos processos:
Planejar o gerenciamento do escopo;
Coletar os requisitos;
Definir o escopo;
Criar a EAP;
Validar o escopo;
Controlar o escopo.
38
Baseado nesta definição, os atores do processo de gerenciamento de
escopo foram identificados e o modelo SD apresentado na figura 11 foi
desenvolvido.
Figura 11 – Modelo SD de Gerenciamento de Escopo
Fonte: Elaborado pelo autor (2018).
Ao analisar o modelo SD observa-se que as metas e metas-flexíveis estão
interligadas através das dependências, correlações e contribuições. É possível
visualizar os atores do processo, seus objetivos (metas) e as metas-flexíveis da
seguinte forma:
Quadro 5 - Detalhamento Modelo SD de Gerenciamento de Escopo. DETALHAMENTO MODELO SD DE GERENCIAMENTO DE ESCOPO
Atores Stakeholder, Gerente de Projeto e Desenvolvedor
Metas Especificação de Requisitos Aprovada
Metas-Flexíveis Comunicação, qualidade, escopo/objetivo bem definido, escopo/objetivo bem entendido, foco não só tecnológico, sem mudanças de escopo.
Fonte: Elaborado pelo autor (2108).
39
É possível também visualizar o relacionamento entre atores conforme
descrito no quadro abaixo:
Quadro 6 - Detalhamento Modelo SD de Gerenciamento de Escopo: Relacionamento entre atores.
DETALHAMENTO MODELO SD DE GERENCIAMENTO DE ESCOPO –
RELACIONAMENTO ENTRE ATORES
Ator demandante
Ator Responsável
Atividade Recurso
Stakeholder Gerente de Projetos
Solicita o desenvolvimento do requisito.
Requisito
Gerente de Projetos
Desenvolvedor Solicita a especificação do requisito
Requisito
Desenvolvedor - Especifica o requisito
Desenvolvedor Gerente de Projetos
Disponibiliza especificação para validação
Especificação de Requisito
Gerente de Projetos
Stakeholder Disponibiliza especificação para validação
Especificação de Requisito
Stakeholder - Valida especificação de requisitos Especificação de Requisito
Stakeholder Gerente de Projetos
Disponibiliza especificação para revisão
Especificação de Requisito a revisar
Gerente de Projetos
Desenvolvedor Disponibiliza especificação para revisão
Especificação de Requisito a revisar
Desenvolvedor - Revisa a especificação Especificação de Requisito
Desenvolvedor Gerente de Projetos
Disponibiliza especificação revisada para validação
Especificação de Requisito
Gerente de Projetos
Stakeholder Disponibiliza especificação para validação
Especificação de Requisito
Stakeholder - Valida especificação de requisitos Especificação de Requisito
Stakeholder Gerente de Projetos
Disponibiliza especificação validada
Especificação de Requisito validada
Fonte: Elaborado pelo autor (2018).
Percebe-se também que diferentes tipos de dependências são apresentados no modelo: Quadro 7 - Detalhamento Modelo SD de Gerenciamento de Escopo – Tipos de Dependência.
TIPOS DE DEPENDÊNCIAS IDENTIFICADOS
Tipo de Dependência Atores Dependentes Exemplo da dependência
Dependência por meta Stakeholder e Gerente de Projetos
Especificação de requisitos aprovada
Gerente de Projetos e Desenvolvedor
Especificação de requisitos entregue
Dependência por tarefa Gerente de Projetos e Validar a especificação
40
Stakeholder
Dependência por recurso Gerente de Projetos e Stakeholder
Requisito
Gerente de Projetos, Stakeholder e desenvolvedor
Especificação
Dependência por meta-flexível
Gerente de Projetos e Stakeholder
Escopo / objetivo bem definido; Evitar mudanças de escopos.
Gerente de Projetos e Desenvolvedor
Escopo / objetivo bem entendido; Foco Tecnológico.
Gerente de Projetos, Stakeholder e desenvolvedor
Comunicação; Qualidade.
Fonte: Elaborado pelo autor (2018).
Com a criação do SIG de Riscos e do SD de Gerenciamento de Escopo, é
possível validar os requisitos de riscos relacionados a gerenciamento de escopo e
suas operacionalizações e visualizar as dependências entre atores, metas e
metas-flexíveis.
A figura 12 apresenta um exemplo de aplicabilidade dos modelos
elaborados. Para tal, de acordo com a fase 6 da metodologia, foi elaborado o
modelo de processo baseada na notação Business Process Modeling Notation
(BPMn) referente ao gerenciamento do escopo de um projeto. O BPMN é uma
notação padrão para desenho de fluxogramas de processos de negócios, com
uma interface amigável, porém, uma deficiência da notação está não descrição
de requisitos não-funcionais (XAVIER et al, 2009).
41
Figura 12 – Modelo de processo de negócio de gerenciamento de escopo na gestão de projetos.
Fonte: Elaborado pelo autor (2018).
42
Observa-se que o modelo apresenta as tarefas relevantes de
gerenciamento de escopo de acordo com os processos propostos pelo PMBOK
(2017), sendo possível identificá-las conforme abaixo:
Quadro 8 - Identificação das tarefas conforme processos PMBOK
Atividades do processo de Planejar o gerenciamento.
Atividades do processo de Coletar Requisitos.
Atividades do processo de Definir Escopo.
Atividade do processo de Criar EAP.
Atividades do processo de Validar o Escopo.
Atividade do processo Controlar Escopo.
Fonte: Elaborado pelo autor (2018).
Após análise do SD, é possível verificar que o processo de Gerenciamento
de Escopo, apresentado através da figura 7, representa o processo de negócio,
mas não contempla níveis de detalhe referente às atividades relacionadas aos
requisitos não-funcionais.
Baseados no estudo apresentado por Xavier et al.(2009), após desenho do
processo, identificação dos requisitos não-funcionais e definidas suas
operacionalizações, elas serão inseridas no processo de negócio.
Para atender a fase 7 da metodologia, conforme proposto por Xavier et
al.(2009), o quadro abaixo foi elaborado para facilitar o rastreamento entre as
tarefas, requisitos não-funcionais associados e operacionalizações:
Quadro 9 - Correspondência de Operacionalizações Tarefa RNF Associado Operacionalização
Planejar o gerenciamento,
Controlar Escopo e Definir
Escopo
Ineficiente
definição/entendimento
de escopo e objetivos
Realizar Status Report.
Controlar Escopo Modificabilidade de
escopo / objetivos
Registrar Mudanças e
Impactos
43
Planejar o gerenciamento Incompletude ou má
definição
Elaborar/Definir Indicadores de
Qualidade
Planejar o gerenciamento Foco exclusivamente
tecnológico
Elaborar Plano de
Gerenciamento de Técnicas e
Ferramentas
Planejar o gerenciamento Variabilidade de linhas
de comunicação
Elaborar / Publicar Plano de
Comunicação
Planejar o gerenciamento Apurar / Publicar Plano de
Comunicação
Fonte: Elaborado pelo autor (2018).
Desta forma, utilizando as operacionalizações propostas no SIG de Riscos
e as dependências do SD de Gerenciamentos de Escopo, o processo
apresentado para Gerenciamento de Escopo foi alterado com a inserção dos
requisitos não-funcionais de forma explicita no processo de negócio, atendendo a
fase 8 da metodologia, conforme apresentado na Figura 13.
44
Figura 13 – Modelo de processo de negócio de gerenciamento de escopo com inserção dos elementos de risco
Fonte: Elaborado pelo autor (2018).
45
Observa-se que desta forma é possível aumentar o nível de detalhamento do
processo, visto que atividades do gerenciamento de riscos, que até então faziam
parte do conhecimento tácito dos envolvidos no processo, foram inseridas
explicitamente no processo, sem afetar a eficiência do processo original.
É importante ressaltar que nem todas as operacionalizações do SIG e
dependências do SD apareceram no processo, até mesmo porque nem sempre
todas serão aplicáveis. Porém, quanto mais implementadas, mais detalhado será o
modelo, permitindo aos envolvidos a visualização de todas as possibilidades.
46
6 CONCLUSÕES
A principal contribuição desta pesquisa foi a obtenção do modelo conceitual
(qualitativo) de riscos em projeto de software, agrupando em uma única estrutura de
grafo para facilitar seu entendimento e aplicação prática em projetos.
Embora existam trabalhos isolados citados no corpo deste documento, foi
possível reunir as contribuições principais de todos eles em uma única estrutura que
pode ser considerada um framework conceitual para ajudar projetistas e gerentes de
projeto a enxergar melhor as situações de riscos em cada projeto, sem esquecer
detalhes, e a tratá-los adequadamente. As variáveis identificadas foram agrupadas
no Catálogo de Risco de Software, utilizado na sequência para criar o SIG de
Riscos, pelo uso da NFR Framework.
O Catálogo de Risco de Software elaborado neste trabalho é dinâmico e
representa o primeiro passo para elaboração de um catálogo mais completo, de fácil
utilização para gerenciar riscos, contribuindo positivamente para a qualidade e
sucesso do produto de software. O SIG de Riscos permitiu mostrar uma forma de
validar os requisitos de riscos através da análise de rede de metas flexíveis, com a
utilização do Catálogo de Risco de Software.
Conclui-se que os modelos e exemplos apresentados podem contribuir para
os gestores de projetos identificarem e gerenciarem os riscos do projeto em fase
inicial, o que irá gerar um alerta prévio dos possíveis problemas, possibilitando uma
ação preventiva e aumentando as chances de sucesso do projeto.
É importante ressaltar que trata-se de um modelo dinâmico, em evolução,
que com adoção e utilização, será acrescido de operacionalizações de riscos e
outros detalhes, que vão permitir mais segurança no trato do risco
Ainda há muito estudo a ser feito referente à abordagem de gestão de riscos
utilizando requisitos não-funcionais. Como trabalho futuro sugere-se a aplicação do
modelo às demais áreas de gerenciamento de projeto do PMBOK, visto que o
exemplo apresentado é somente referente ao gerenciamento de escopo. E, por fim,
um pouco mais desafiador, seria a aplicação das variáveis e modelos até aqui
apresentados para criação de um sistema de agentes intencionais.
47
REFERÊNCIAS
BARKI, Henri; RIVARD, Suzanne; TALBOT, Jean. Toward an assessment of
software development risk. Journal of management information systems, v. 10, n. 2, p. 203-225, 1993. Published online: 15 Dec 2015. Acesso em: 05 set. 2017 CYSNEIROS, Luiz Marcio; YU, Eric. Non-functional requirements elicitation.
In: Perspectives on software requirements. Springer, Boston, MA, 2004.
CHARETTE, Robert N. Software engineering risk analysis and management. New York: Intertext Publications, 1989.
CHUNG, L.; NIXON, B.; YU, E.; MYLOPOULOS, J. Non-Functional Requirements
in Software Engineering. International Series in Software Engineering, Vol. 5, Kluwer, 2000. HASTIE, Shane; WOJEWODA, Stéphane. Standish Group 2015 Chaos Report-Q&A
with Jennifer Lynch. Retrieved, v. 1, n. 15, p. 2016, 2015. Disponível em: <https://www.infoq.com/articles/standish-chaos-2015>. Acesso em: 24 jul. 2017. ISLAM, Shareeful; MOURATIDIS, Haralambos; WEIPPL, Edgar R. An empirical study on the implementation and evaluation of a goal-driven software development
risk management model. Information and Software Technology, v. 56, n. 2, p. 117-133, 2014.
LOPES, Jhoney da Silva. Um Modelo para Apoio à Decisão em Avaliação de
Riscos em Projetos de Software utilizando Simulação com Dinâmica de
Sistemas. Trabalho de Conclusão de Curso (Dissertação). Ciência da Computação, UFV, 2014. MACEDO, Mateus Henrique Basso; SALGADO, Eduardo Gomes. Gerenciamento de
Risco Aplicado ao Desenvolvimento de Software. Sistemas & Gestão, v. 10, n. 1, p. 158-170, 2015. Acesso em: 10 ago 2017.
OLIVEIRA, Antonio de Pádua et al. Engenharia de requisitos
intencional: tornando o software mais transparente. João Pessoa, PB: UFPB, 2007. Tutoriais SBES. Disponível em: <http://www.sbbd-sbes2007.ufpb.br/index.php?section=tutoriais-sbes>. Acesso em: 25 nov. 2017.
PMI - Um Guia Do Conhecimento Em Gerenciamento De Projetos. (Guia Pmbok®) – Sexta Edição, 2017. SCHMIDT, Roy; KALLE Lyytinen; PAUL Cule Mark Keil. “Identifying software project risks: An international Delphi study." Journal of management information systems 17.4 (2001): 5-36. Pages 5-36.| Published online: 09 Jan 2015. Acesso em: 05 set. 2017
48
SERRANO, Maurício. Desenvolvimento Intencional de Software Transparente
Baseado em Argumentação. Tese de Doutorado. PUC-Rio.2011.
SILVA, Fabiana Leonel Ambrósio Da. Análise do Impacto do Gerenciamento de
Riscos no Sucesso de Projetos: Um Estudo de Caso em uma Organização de Desenvolvimento de Software. Dissertação. Ciência da Computação, Universidade Federal de Pernambuco, 2013. SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
XAVIER, Laís et al. Integração de Requisitos não Funcionais a Processos de
Negócios: Integrando BPMN e NFR. 2009.
YU, E. Modeling Strategic Relationships for Process Reengineering. Tese. Departamento de Ciência da Computação, Universidade de Toronto, Canadá, 1995.
![[Call2Social] Uma metodologia para facilitar o trabalho em monitoramento e métricas](https://img.document.onl/doc/110x75/5590b2271a28abea058b46ff/call2social-uma-metodologia-para-facilitar-o-trabalho-em-monitoramento-e-metricas.jpg)
