diagnÓstico de processos em organizaÇÕes intensivas …siaibib01.univali.br/pdf/chaiene da silva...
TRANSCRIPT
CHAIENE M. DA SILVA MINELLA
DIAGNÓSTICO DE PROCESSOS EM ORGANIZAÇÕES
INTENSIVAS EM SOFTWARE UTILIZANDO UM SISTEMA
ESPECIALISTA
Itajaí(SC), Dezembro de 2014
ii
UNIVERSIDADE DO VALE DO ITAJAÍ
CURSO DE MESTRADO ACADÊMICO EM
COMPUTAÇÃO APLICADA
DIAGNÓSTICO DE PROCESSOS EM ORGANIZAÇÕES
INTENSIVAS EM SOFTWARE UTILIZANDO UM SISTEMA
ESPECIALISTA
por
Chaiene M. da Silva Minella
Dissertação apresentada como requisito parcial à
obtenção do grau de Mestre em Computação
Aplicada.
Orientador: Marcello Thiry, Dr.
Co-Orientadora: Anita Maria da Rocha
Fernandes, Dra.
Itajaí (SC), Dezembro de 2014
iii
Dedico esta pesquisa a minha filha Vitória e ao meu pai Valdemiro e à minha mãe Fátima.
“As páginas da vida são cheias de surpresas. Há capítulos de alegrias, mas também de tristezas, há
mistérios e fantasias, sofrimentos e decepções. Por isso, não rasgue páginas e nem solte capítulos.
Não se apresse em descobrir os mistérios. Não perca as esperanças, pois muitos são os finais
felizes. E nunca se esqueça do principal: No livro da vida, o autor é VOCÊ.”
(Desconhecido)
AGRADECIMENTOS
Primeiramente agradeço a Deus, essa luz que me guia dia após dia e me dá forças para
enfrentar todos os obstáculos.
Aos meus pais Fátima e Valdemiro que sempre me apoiaram e nunca deixaram de acreditar
que o estudo é a maior das heranças.
A toda minha família, especialmente as minhas irmãs Iassanã e Thayná que me ajudaram a
cuidar da Vitória sempre que precisei me ausentar.
Ao professor Marcello Thiry que esteve comigo durante toda esta trajetória, me orientando e
dando apoio, na conclusão deste trabalho.
A professora Anita, que me orientou nos assuntos relacionados a inteligência artificial.
A todos os outros professores da Univali, pela excelência na condução do mestrado.
Aos meus amigos Rafael, Sidnei e Débora, que me ajudaram nas avaliações.
A todos os outros amigos e familiares que sempre me perguntavam do andamento do
mestrado e se mostravam interessados na pesquisa.
As organizações e especialistas que me apoiaram nas avaliações.
À todos vocês, o meu MUITO OBRIGADA, vindo do coração.
DIAGNÓSTICO DE PROCESSOS EM ORGANIZAÇÕES
INTENSIVAS EM SOFTWARE UTILIZANDO UM SISTEMA
ESPECIALISTA
Chaiene M. da Silva Minella
12/2014
Orientador: Marcello Thiry, Dr.
Co-Orientadora: Anita Maria da Rocha Fernandes, Dra.
Área de Concentração: Computação Aplicada
Linha de Pesquisa: Engenharia de Software
Palavras-chave: Ciclo de Vida de Desenvolvimento, Melhoria de Processos de Software, Avaliação,
Diagnóstico.
Número de páginas: 163
RESUMO
O mercado de desenvolvimento de software busca cada vez mais qualidade de seus produtos
desenvolvidos. Muitas organizações têm investido em processos de avaliação e melhoria de
software com o intuito de se tornarem cada vez mais competitivas, lançando no mercado produtos
com alta qualidade. O presente estudo propõe a construção de uma base de conhecimento
explorando características do ciclo de vida e processos adotados pelas organizações como forma de
obter o diagnóstico inicial do desenvolvimento de software como um todo, utilizando um sistema
especialista, construído com o auxílio de árvores de decisão. Para tanto, a ferramenta de sistema
especialista, juntamente com a base de conhecimento e com o apoio de organizações
desenvolvedoras de software e especialistas na área de melhoria de processos, foram utilizados para
permitir uma visão geral do processo de desenvolvimento de software da organização. O
diagnóstico realizado através do sistema especialista traz como resultados pontos fortes, pontos
fracos e oportunidades de melhorias nas organizações entrevistadas. A abordagem GQM, foi
utilizada a fim de avaliar a contribuição obtida com a utilização do sistema especialista nas
organizações, demonstrando resultados, em sua maioria, positivos trazendo confiabilidade e
produtividade na condução do processo de melhoria do desenvolvimento de software,
especialmente na visão dos especialistas.
DIAGNOSTIC PROCESS IN INTENSIVE ORGANIZATIONS IN
SOFTWARE USING AN EXPERT SYSTEM
Chaiene M. da Silva Minella
12/2014
Advisor: Marcello Thiry, Dr.
Co-Advisor: Anita Maria da Rocha Fernandes, Dra.
Area of Concentration: Applied Computer Science
Research Line: Software Engineering
Keywords: Lifecycle Development, Software Process Improvement, Evaluation, Diagnostic.
Number of pages: 163
ABSTRACT
The software development market is looking increasingly quality of its products developed.
Many organizations have invested in processes of evaluation and improvement of software in order
to become increasingly competitive, attempting to market products with high quality. This paper
proposes the establishment of a knowledge base exploring life cycle characteristics and processes
adopted by organizations as a way to get the initial diagnosis of software development as a whole,
using an expert system, built with the aid of decision trees. Therefore, the expert system tool, along
with the knowledge base and with the support of software developer’s organizations and experts in
the field of process improvement, were used to allow an overview of the organization's software
development process. The diagnosis made by the expert system brings as strengths results,
weaknesses and opportunities for improvements in the interviewed organizations. The GQM
approach was used to assess the contribution obtained with the use of expert systems in
organizations, demonstrating results, mostly positive bringing reliability and productivity in the
conduct of the software development process improvement, especially in view of experts.
LISTA DE ILUSTRAÇÕES
Figura 1. Visão geral do trabalho proposto ........................................................................................ 22
Figura 2. Modelo Cascata .................................................................................................................. 30 Figura 3. Modelo Evolucionário ........................................................................................................ 32 Figura 4. Modelo Espiral ................................................................................................................... 33 Figura 5. Modelo Incremental ............................................................................................................ 34 Figura 6. Diagrama do ciclo de vida Incremental e Iterativo............................................................. 35
Figura 7. eXtreme Programming ....................................................................................................... 40 Figura 8. Visão geral do Scrum ......................................................................................................... 42
Figura 9. Fluxo de atividades do Scrum ............................................................................................ 43 Figura 10. Dimensões do RUP ........................................................................................................... 44 Figura 11. Grupos de Processos de Ciclo de Vida ............................................................................. 53 Figura 12. Modelo conceitual de processo de avaliação .................................................................... 55 Figura 13. Fluxograma de implantação de melhorias ........................................................................ 57
Figura 14. Visão geral do processo de avaliação de contextualização .............................................. 59 Figura 15. Arquitetura do sistema especialista .................................................................................. 65 Figura 16. Metodologia ...................................................................................................................... 93 Figura 17. Trecho da árvore inicial .................................................................................................... 99
Figura 18. Trecho da árvore Requisitos ........................................................................................... 100 Figura 19. Trecho da árvore Projeto ................................................................................................ 101
Figura 20. Trecho da árvore de solução técnica ............................................................................... 102
Figura 21. Trecho da árvore Construção .......................................................................................... 103
Figura 22. Trecho da árvore Testes .................................................................................................. 104 Figura 23. Trecho da árvore de documentação ................................................................................ 105
Figura 24. Trecho da árvore Manutenção ........................................................................................ 106 Figura 25. Trecho contendo uma regra de produção ....................................................................... 110 Figura 26. Trecho das perguntas feitas pelo Sistema Especialista ................................................... 114
Figura 27. Trecho dos resultados emitidos pelo Sistema Especialista ............................................. 116 Figura 28. Visão geral do processo de entrevistas ........................................................................... 118 Figura 29. Fluxo de atividades ......................................................................................................... 119
Figura 30. Avaliação GQM – Organizações .................................................................................... 126 Figura 31. Avalição GQM – Especialistas ....................................................................................... 127
Figura 32. Distribuição das respostas de acordo com a classificação (Especialistas) ..................... 128 Figura 33. Distribuição das respostas de acordo com a classificação (Organizações) .................... 129
Figura 34. Total de trabalhos retornados ......................................................................................... 154 Figura 35. Distribuição por data de publicação ............................................................................... 156
Quadro 1. CMMI - Áreas de processo ............................................................................................... 46 Quadro 2. Processos do MR-MPS-SW .............................................................................................. 48
Quadro 3. Exemplo de trecho de uma regra de produção .................................................................. 63 Quadro 4. Trabalhos relacionados ..................................................................................................... 67 Quadro 5. PICOC para a primeira pergunta. ...................................................................................... 73
Quadro 6. PICOC para a segunda pergunta. ...................................................................................... 74 Quadro 7. Representação da entrevista relacionada a árvore inicial ................................................ 100
Quadro 8. Características dos entrevistados .................................................................................... 106 Quadro 9. Características das organizações ..................................................................................... 107
Quadro 10. Regras de Produção. ...................................................................................................... 114 Quadro 11. Definição das métricas para o objetivo G1 segundo a abordagem GQM ..................... 121
Quadro 12. Definição das métricas para o objetivo G2 segundo a abordagem GQM ..................... 121 Quadro 13. Métricas para avaliação da abordagem. ........................................................................ 122 Quadro 14. Atributos de avaliação do framework ........................................................................... 123 Quadro 15. Interpretação da adequação da abordagem* ................................................................. 123 Quadro 16. Interpretação da aderência da abordagem* ................................................................... 124
Quadro 17. Perfil das organizações.................................................................................................. 124 Quadro 18. Perfil dos entrevistados nas organizações ..................................................................... 125 Quadro 19. Perfil dos especialistas .................................................................................................. 125 Quadro 20. Interpretação da avaliação subjetiva da abordagem. ..................................................... 130
Quadro 21. Avaliação dos entrevistados .......................................................................................... 131 Quadro 22. Avaliação dos dados ...................................................................................................... 133 Quadro 23. Caminho para as árvores. .............................................................................................. 157
LISTA DE TABELAS
Tabela 1. Fonte de Dados ................................................................................................................... 74
Tabela 2. Estudos que adotam modelos de ciclo de vida em suas abordagens .................................. 90 Tabela 3. Artigos retornados ............................................................................................................ 154 Tabela 4. Trabalhos selecionados .................................................................................................... 154 Tabela 5. Trabalhos selecionados com base nas strings do trabalho anterior .................................. 156
LISTA DE ABREVIATURAS E SIGLAS
ABNT Associação Brasileira de Normas Técnicas
ANSI American National Standards Institute
CMMI Capability Maturity Model Integration
CMMI-DEV Capability Maturity Model Integration for Development
CMMI-ARC Appraisal Requirements for CMMI
CMMI-SVC Capability Maturity Model Integration for Services
GQM Goal Question Metric
IA Inteligência Artificial
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
ISO International Organization for Standardization
MA-MPS Modelo de Avalição para Melhoria de Processo de Software
MCA Mestrado em Computação Aplicada
MPE Micro e Pequenas Empresas
MPS Melhoria de Processo de Software
MPS.BR Melhoria de Processo de Software Brasileiro
MPS-SW Melhoria de Processo de Software
MPS-SV Melhoria de Processo de Software para Serviços
MR-MPS Modelo de Referência para Melhoria de Processo de Software
MR-MPS-SW Modelo de Referência para Software
MR-MPS-SV Modelo de Referência para Serviços
OWPL Observatoire des Wallon Pratiques Logicielles
PICOC Population, Intervention, Comparison, Outcames and Context
PMBOK Project Management Body of Knowledge
QIP Quality Improvement Paradigm
RUP Rational Unified Process
SDLC Software Development Life Cycle
SCAMPI Standard CMMI Appraisal Method for Process Improvement
SE Sistema Especialista
SEI Software Engineering Institute
SWEBOK Software Engineering Body of Knowledge
TI Tecnologia da Informação
UNIVALI Universidade do Vale do Itajaí
USA United States of America
XP eXtreme Programming
SUMÁRIO
1 INTRODUÇÃO .................................................................................... 15
1.1 PROBLEMA DE PESQUISA........................................................................... 17
1.1.1 Solução Proposta ............................................................................................. 20
1.1.2 Delimitação de Escopo .................................................................................... 22
1.1.3 Justificativa ...................................................................................................... 24
1.2 OBJETIVOS ...................................................................................................... 25
1.2.1 Objetivo Geral ................................................................................................. 25
1.2.2 Objetivos Específicos ...................................................................................... 25
1.3 METODOLOGIA .............................................................................................. 25
1.3.1 Metodologia da Pesquisa ................................................................................ 25
1.3.2 Procedimentos Metodológicos ........................................................................ 26
2 FUNDAMENTAÇÃO TEÓRICA ...................................................... 28
2.1 MODELOS DE CICLO DE VIDA DE DESENVOLVIMENTO ................. 28
2.1.1 Modelo Cascata ............................................................................................... 29
2.1.2 Modelo Evolucionário ..................................................................................... 31
2.1.3 Modelo Espiral ................................................................................................ 32
2.1.4 Modelo Incremental ........................................................................................ 33
2.1.5 Modelo Incremental e Iterativo ..................................................................... 34
2.2 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE ...................... 35
2.2.1 Extreme Programming (XP) .......................................................................... 37
2.2.2 Scrum ............................................................................................................... 40
2.2.3 RUP ................................................................................................................... 43
2.3 MODELOS DE REFERÊNCIA DE AVALIAÇÃO DE PROCESSOS ....... 45
2.3.1 CMMI ............................................................................................................... 45
2.3.2 MPS.BR ............................................................................................................ 47
2.4 CORPO DE CONHECIMENTO PARA ENGENHARIA DE SOFTWARE
(SWEBOK) ................................................................................................................. 49
2.5 NORMA ISO/IEC 12207 ................................................................................... 52
2.6 AVALIAÇÃO DE SOFTWARE ...................................................................... 54
2.6.1 Avaliação de Processo de Software ............................................................... 56
2.6.2 Automatização de Diagnóstico ....................................................................... 60
2.7 SISTEMA ESPECIALISTA ............................................................................. 61
3 ESTADO DA ARTE ............................................................................ 66
3.1 REVISÃO EXPLORATÓRIA ......................................................................... 66
3.1.1 Trabalhos Relacionados ................................................................................. 67
3.1.2 Análise dos Trabalhos Relacionados ............................................................. 72
3.2 MAPEAMENTO SISTEMÁTICO .................................................................. 72
3.2.1 Objetivo Principal ........................................................................................... 73
3.2.2 Protocolo de Busca .......................................................................................... 73
3.2.3 Questões de Pesquisa ...................................................................................... 73
3.2.4 Fontes de Dados ............................................................................................... 74
3.2.5 Palavras Chave ................................................................................................ 75
3.2.6 String de Busca ................................................................................................ 76
3.2.7 Critérios de Inclusão e Exclusão .................................................................... 76
3.2.8 Extração dos Dados ......................................................................................... 77
3.2.9 Análise dos Trabalhos Selecionados .............................................................. 78
3.2.10 Resultados ........................................................................................................ 89
3.2.11 Considerações Finais ....................................................................................... 91
4 MODELO PROPOSTO ...................................................................... 92
4.1 VISÃO GERAL ................................................................................................. 92
4.2 METODOLOGIA PARA CONSTRUÇÃO E AVALIAÇÃO DA BASE DE
CONHECIMENTO ................................................................................................... 94
4.2.1 Revisão da Literatura ..................................................................................... 94
4.2.2 Modelagem das Árvores de Decisão .............................................................. 95
4.2.3 Regras de Produção ...................................................................................... 109
4.2.4 Ferramenta de Sistema Especialista ............................................................ 111
4.2.5 Avaliação da Base de Conhecimento ........................................................... 111
4.2.6 Aplicação do Diagnóstico .............................................................................. 112
4.3 O SISTEMA ESPECIALISTA DESENVOLVIDO ..................................... 113
5 AVALIAÇÃO ..................................................................................... 117
5.1 ENTREVISTAS ............................................................................................... 117
5.2 MODELO DE AVALIAÇÃO ......................................................................... 119
5.2.1 Avaliação pelo Método GQM....................................................................... 120
5.3 RESULTADOS ................................................................................................ 124
5.3.1 Perfil dos participantes ................................................................................. 124
5.3.2 Resultados das métricas subjetivas ............................................................. 126
5.3.3 Avaliação ........................................................................................................ 130
5.3.4 Síntese dos resultados ................................................................................... 132
5.3.5 Considerações ................................................................................................ 138
6 CONCLUSÃO .................................................................................... 140
6.1 PRINCIPAIS CONTRIBUIÇÕES ................................................................. 142
6.2 TRABALHOS FUTUROS .............................................................................. 143
REFERÊNCIAS ..................................................................................... 144
APÊNDICE A – Mapeamento Sistemático .......................................... 153
A1 String de Busca .............................................................................................. 153
A2 Resultado da Extração dos Dados ............................................................... 153
APÊNDICE B – Árvores ....................................................................... 157
APÊNDICE C – Questionário de avaliação para as organizações.... 159
APÊNDICE D – Questionário de avaliação para os especialistas ..... 161
15
1 INTRODUÇÃO
Com as mudanças que vem surgindo nos ambientes de negócios, as empresas de software têm
buscado mudar suas estruturas organizacionais e processos, para seguir em direção a redes de
processos centradas no cliente. Os estabelecimentos de conexões nestas redes criam elos entre as
cadeias produtivas. Chegar em um nível elevado de qualidade, para as empresas de software, implica
em alcançar a competitividade tanto na melhoria da qualidade dos produtos de software e serviços,
como dos processos de produção de distribuição do software (SOFTEX, 2012).
O processo de software é um conjunto de atividades que tem por finalidade gerar um produto
de software, em que os modelos de processo representam esse processo. A padronização, medição e
gerenciamento destes processos pode aperfeiçoa-los, aprimorando a comunicação e redução no tempo
de treinamento, fazendo com que o processo automatizado seja mais econômico (SOMMERVILLE,
2007).
Pensando nisso, muitas organizações estão investindo em avaliação e melhoria de seus
processos, tendo como resultado a melhoria contínua dos mesmos, uma vez que pesquisas mostram
que a qualidade do produto de software depende da qualidade de seus processos de desenvolvimento
(FUGGETTA, 2000).
Os modelos e normas não descrevem os processos a serem seguidos pelas organizações. A
definição de um processo de desenvolvimento é responsabilidade da organização avaliada e existem
vários fatores que influenciam esta definição como, estrutura, tamanho da organização, incluindo o
domínio da aplicação (SEI, 2010a). O objetivo dos modelos é assegurar a visibilidade dos processos
relativos aos produtos de software. A maioria dos modelos tem como objetivo a organização como um
todo, não se preocupando com cada processo de trabalho, indivíduo, equipe ou características
individuais de cada projeto (TONINI, SPINOLA e CARVALHO, 2008).
Sendo assim, as organizações têm investindo em projetos de melhoria de processo de software,
com o intuito de se tornarem mais competitivas, buscando atender as necessidades dos clientes, que
buscam mais qualidade para seus produtos de software (CERDEIRAL, 2008). Segundo Rocha (2009),
os responsáveis por manter e evoluir os processos de software, é a melhoria na qualidade de processos.
16
Em um processo de desenvolvimento de software, a escolha de um modelo de ciclo de vida, é o
início para a arquitetura de um processo (PAULA FILHO, 2005). O processo de desenvolvimento de
software também chamado de ciclo de vida do software, descreve a “vida” do produto de software
desde a concepção passando pela implementação, entrega, utilização e manutenção (PFLEEGER,
2004).
A definição do ciclo de vida de software permite a visão completa do desenvolvimento do
software. Com isto, é possível definir etapas que abrangem desde a análise dos requisitos até a entrega
do software para o cliente. O ciclo de vida permite detectar os erros o mais rápido possível e assim
manter a qualidade do software, os prazos da sua realização e os custos associados. Para dar início a
identificação do ciclo de vida do software é necessário mapear a situação atual do processo. Essa
verificação inicial é o diagnóstico do processo. Tipicamente, essa atividade é realizada através de
entrevistas que visam a modelagem de processos a partir de reuniões com a participação dos
envolvidos, que são os principais atores da organização (THIRY et al., 2006).
Nas entrevistas iniciais que tem por objetivo mapear o processo de desenvolvimento e obter um
diagnóstico inicial, é possível analisar o desenvolvimento de forma ampla, o que nem sempre é
possível aos olhos de gerentes e coordenadores, que no dia a dia não conseguem verificar e analisar
possíveis pontos fracos a serem melhorados ou oportunidades de melhorias a serem implementadas.
Após a atividade de diagnóstico, é necessário que um especialista na área de processos analise
as informações do mesmo e emita um parecer sobre o processo. Esta atividade por ser complexa do
ponto de vista da análise das informações, deve ser realizada apenas por um profissional capacitado
para poder avaliar o resultado do diagnóstico. Todo este processo implica na contratação de mão de
obra especializada, o que gera um custo alto para a organização, principalmente para as de pequeno
porte (MOREIRA, 2012).
Uma pesquisa iniciada por Moreira (2012) define uma abordagem de autodiagnostico
utilizando sistemas especialistas, apoiado por uma ferramenta web, que permite mapear pontos fortes e
fracos do processo de uma organização. Nesta pesquisa não há um recurso que possa mapear o ciclo de
vida adotado na organização, com entrevistas que pudessem abranger todo o processo de
desenvolvimento de software. O trabalho em questão avaliou o gerenciamento de requisitos e
gerenciamento de projetos no nível G do MPS.BR, utilizando árvores de decisão para gerar regras de
produção que pudessem incrementar uma base de conhecimento para gerar os resultados.
17
De acordo com Nunes (2009) uma árvore de decisão é definida como sendo uma representação
gráfica de um instrumento de apoio a tomada de decisão, gerada a partir de uma decisão inicial. Uma
das vantagens de uma árvore de decisão é a possibilidade de transformar um problema complexo em
vários subproblemas mais simples e de uma forma recursiva, os subproblemas identificados voltam a
ser decompostos em subproblemas ainda mais simples (NUNES, 2009).
Este trabalho visa contribuir com a área de melhoria de processos de software através da
proposta, desenvolvimento e avaliação de uma abordagem automatizada que apoie as organizações na
qualidade de seus processos. O foco desta abordagem está no mapeamento do processo de
desenvolvimento adotado por organizações intensivas em software.
Um sistema especialista será construído para permitir executar uma série de questionamentos
que terá como resultado final o levantamento de informações relevantes para a melhoria do processo
de desenvolvimento da organização.
1.1 PROBLEMA DE PESQUISA
O mercado de TI (Tecnologia da Informação) tem exigido maior qualidade nos produtos de
software, segundo o estudo produzido por Travassos e Kalinowski (2012), no qual revela que as
organizações que investem em qualidade de software são mais competitivas. Para alcançar este
resultado de modo consistente, as organizações intensivas em software precisam adotar processos de
desenvolvimento de software bem estruturados (ALMEIDA, 2011). Para apoiar a definição destes
processos, têm sido utilizados modelos de referência com boas práticas e resultados esperados de
processo, como os modelos CMMI-DEV (Capability Maturity Model Integration for Development) e
MR-MPS-SW (Modelo de Referência para Melhoria de Processos com foco em Desenvolvimento de
Software) (SEI; SOFTEX, 2014). Estes modelos têm por objetivo relacionar as melhores práticas,
auxiliando organizações a atingir determinados níveis de maturidade. Entretanto, melhorar os
processos necessita de tempo e de investimento financeiro, que pode ser alto, dependendo do porte da
organização (MIYASHIRO et al., 2011).
Organizações que não possuem um processo de desenvolvimento de software definido são
facilmente identificadas; não há formalidade na realização das atividades de desenvolvimento de
software; não há definição de papéis nos projetos, dificultando a cobrança do andamento do projeto;
não há treinamento para os desenvolvedores; não há avaliação de custos e benefícios dos projetos; os
18
ambientes de trabalho são inadequados; não utilizam ferramentas para suporte dos seus processos; seus
procedimentos e padrões, quando existem, são burocráticos (MIYASHIRO et al., 2011).
Com o mercado cada vez mais competitivo, a velocidade com que as organizações respondem
as novas demandas, oportunidades e ameaças do mercado, são aspectos que fazem com que haja uma
busca por um nível de competitividade. As organizações buscam cada vez mais agilidade nos seus
processos, informações e conhecimentos disponíveis e facilmente acessíveis, mas esse conhecimento
deve auxiliar de forma inteligente a gestão da organização, para que a mesma consiga se manter no
mercado de forma competitiva (BARBIERI, 2001; KALINOWSKI et al., 2010).
Programas de Melhoria de Processo de Software (MPS) são conduzidos visando diminuir o
retrabalho e aumentar a produtividade das organizações desenvolvedoras de software (ROCHA et al.,
2005).
Em busca de uma melhor qualidade de seus produtos, uma organização precisa, tipicamente,
investir na contratação de especialistas na área de melhoria de processo para avaliar e adaptar os
processos, além de treinar o pessoal envolvido. Em geral os altos custos na contratação de consultoria
especializada para definir e prestar suporte na implementação dos processos, inviabilizam os
investimentos nesta área principalmente em se tratando de organizações pequenas e médias, visto que
nem sempre a organização disponibiliza destes recursos. Além disso, o retorno deste investimento não
é imediato (MEGA et al., 2008; MIYASHIRO et al., 2011).
Uma das principais características das pequenas empresas é a falta de recursos atribuídos a
processos de software, em geral, e para funções de melhoria da qualidade, em particular. Na verdade,
as estruturas de software de pequeno porte têm, por definição, as equipes pequenas, e as pessoas são
absorvidas por assuntos urgentes relacionados aos prazos apertados que estão geralmente ligadas a
tarefas de produção. Modelos comuns, como CMMI e ISO/IEC 155041 não são facilmente utilizáveis
por essas organizações. Eles são muito complicados e tem um custo elevado para se implementar
(HABRA et al., 2008).
1 A ISO/IEC 15504, também conhecida como SPICE, é a norma ISO/IEC que define processo de desenvolvimento de
software. Ela é uma evolução da ISO/IEC 12207 mas possui níveis de capacidade para cada processo assim como o CMMI.
19
Para as pequenas e médias organizações a melhoria de processo de software, tem por objetivo
inicial, gerar um diagnóstico para identificar a situação da empresa e com isso mapear um
planejamento para o programa de melhoria. Esse diagnóstico permite, por exemplo, fazer o
levantamento da situação atual dos processos de software utilizados com o objetivo de identificar
pontos de melhoria e pontos fracos.
Este diagnóstico pode ser realizado de forma simplificada, mas deve se basear na lógica de
avaliação seguida pelos métodos de avaliação existentes, sem o rigor de uma avaliação formal
(PRIKLADNICKI; BECKER; YAMAGUTI, 2005). Habra et al. (2008) propõem uma abordagem
gradual para a melhoria de processo. Numa primeira etapa, uma micro avaliação é usada para coletar
informações sobre as práticas atuais de software em pequenas etapas e sensibilizar as pessoas para a
importância da qualidade do software. A informação levantada é então utilizada como um ponto de
partida para determinar a ideia principal e o objetivo de uma avaliação mais precisa. As grandes
empresas, com um nível médio e alto de maturidade podem, eventualmente, implantar a norma
ISO/IEC 15504, ou uma avaliação baseada em CMMI (HABRA et al., 2008).
Sendo assim, no trabalho realizado por Moreira (2012), percebeu-se a necessidade de uma
sistemática que permitisse a realização de um autodiagnostico, fazendo com que uma empresa tenha
condições de avaliar seus processos sem a necessidade de contratar um especialista naquele momento.
Uma limitação do trabalho de Moreira (2012) foi a ausência de recursos para realizar um
levantamento inicial do ciclo de vida de desenvolvimento da organização. Esta limitação dificulta a
identificação da sequência de atividades utilizadas pela organização para o desenvolvimento de
software. Moreira (2012) não apresenta um conjunto de diálogos automatizados para abranger todo o
fluxo de desenvolvimento, uma vez que o foco foi nos processos de gerência de projetos e gerência de
requisitos. A materialização do ciclo de vida adotado por uma organização já pode ser considerada
uma melhoria, pois permite que a organização tenha uma visão geral da sequência de trabalho e que
identifique seus principais pontos fracos. Neste sentido, o objetivo desta pesquisa é evoluir a proposta
de diagnóstico de Moreira (2012), visando a construção de um conjunto de diálogos automatizados que
complementem o processo de diagnóstico para permitir que ele gere uma visão geral do ciclo de vida
adotado pela organização, incluindo a identificação correlacionada de pontos fracos, fortes e possíveis
oportunidades de melhoria.
20
O conjunto de diálogos automatizados se dá através das perguntas que são emitidas pelo
sistema especialista e das respostas informadas por quem é responsável pela a avaliação. Conforme o
sistema especialista for avançando para as próximas perguntas o participante vai respondendo e de
acordo com as respostas o sistema especialista segue uma direção, emitindo ao final, os resultados com
o mapeamento de pontos a serem considerados dentro do processo de desenvolvimento de software.
Dentro da problematização apresentada, este trabalho pretende responder a seguinte questão de
pesquisa: “Uma abordagem baseada em diálogos automatizados, no contexto de um ambiente de
diagnóstico semi automatizado, permite modelagem inicial do ciclo de vida adotado em
organizações intensivas em software?”.
1.1.1 Solução Proposta
Considerando as necessidades apontadas na problematização, o presente trabalho estende a
proposta de diagnóstico realizada por Moreira (2012), na qual foi desenvolvida uma abordagem para
autodiagnostico de processos de software utilizando sistemas especialistas e visando a melhoria do
processo de desenvolvimento. A ferramenta web desenvolvida por Moreira (2012) permite a coleta de
dados por meio da aplicação de diálogos com base no nível G do MPS.BR permitindo verificar
práticas existentes em relação a gerência de projetos e gerência de requisitos, além de emitir um
relatório que indica pontos fortes, pontos fracos e oportunidades de melhoria.
O objetivo desta pesquisa é propor a construção de uma nova base de conhecimento explorando
características do ciclo de vida e processo de desenvolvimento adotado em organizações intensivas em
software, como forma de obter um diagnóstico da situação atual do desenvolvimento como um todo e
não somente sob a área de análise de requisitos e gerenciamento de projeto. Para que o trabalho atual
possa complementar a pesquisa de Moreira (2012), foi realizado um mapeamento sistemático, a
construção de novas árvores de decisão, a criação de novas regras de produção e por fim a construção
de um sistema especialista.
Para o mapeamento sistemático, foram analisados os trabalhos que continham metodologias de
avaliação, descrição dos processos de avalição e resultados obtidos com a aplicação das metodologias
nas organizações. Essas informações serviram de base para a construção do processo de avaliação com
as organizações e os especialistas, envolvidos nesta pesquisa.
21
O presente trabalho propõe a construção de árvores de decisão, com a aplicação de uma
avaliação em 3 organizações de desenvolvimento de software, após essa avaliação, as árvores são
revisadas, a partir dessa revisão, entrevistas com especialistas são conduzidas com intuito de avaliar os
diagnósticos obtidos com a avaliação das árvores junto as organizações. Essas árvores, por sua vez,
geram as regras de produção, necessárias para a construção do sistema especialista. O mesmo é
avaliado por especialistas em MPS e por organizações de desenvolvimento de software. Após essas
avaliações, é então realizada uma revisão no sistema especialista que, por fim, é novamente avaliado
por 2 especialistas em MPS.
Através do conjunto de diagnósticos, profissionais da área de MPS analisam a base de
conhecimento e emitem uma avaliação sob o ponto de vista da aderência do conteúdo da base em
relação ao conteúdo utilizado em avaliações de melhoria de processo de software. O conjunto de
diagnósticos, também é avaliado pelos responsáveis das organizações sob o ponto de vista da
adequação dos resultados à realidade do processo de desenvolvimento de software das mesmas.
Em relação ao trabalho de Moreira (2012), a contribuição do mesmo para o trabalho atual se dá
através da utilização das 23 árvores de decisão, sendo 7 voltadas para a gerência de requisitos e 16
voltadas para a gerência de projetos, que foram construídas para contemplar o nível G do MPS.BR.
Para o trabalho atual foram construídas 33 árvores abrangendo a fundamentação teórica (ver Seção 2).
A Figura 1 apresenta uma visão geral do trabalho realizado.
22
Figura 1. Visão geral do trabalho proposto
Fonte: Próprio autor.
Diante do problema apresentado na Seção 1.1 e da solução proposta, foram estabelecidas as
seguintes hipóteses:
O ciclo de vida de desenvolvimento de software de uma organização pode ser mapeado
através de uma abordagem baseada em diálogos automatizados realizados através de um
sistema especialista, trazendo resultados similares aos resultados obtidos por um
especialista da área de melhoria de processo.
A abordagem baseada em diálogos automatizados pode ser avaliada sob o ponto de
vista da adequação como sob o ponto de vista da aderência, em relação aos resultados
obtidos com o sistema especialista.
As avaliações destas hipóteses podem ser obtidas com o resultado do diagnóstico apresentado
pela avaliação de especialistas da área de melhoria de processos e organizações de desenvolvimento de
software.
1.1.2 Delimitação de Escopo
23
Este trabalho teve enfoque no desenvolvimento de uma abordagem para autodiagnostico do
ciclo de vida e processo de desenvolvimento de organizações intensivas em software, utilizando um
Sistema Especialista (SE). O foco principal é identificar como estas organizações desenvolvem
software, mapeando seu ciclo de vida de desenvolvimento. Este trabalho não pretende realizar uma
verificação da aderência dos processos de uma organização ao modelo de referência MR-MPS-SW.
Entretanto, foram considerados àqueles resultados que estiveram mais relacionados ao processo de
desenvolvimento. Da mesma forma, o modelo de referência CMMI-DEV e a norma ISO/IEC 12207
também foram considerados, bem como o corpo de conhecimento para engenharia de software, o
SWEBOK. Também foram considerados os processos como XP, RUP e Scrum. Embora o Scrum seja
um framework de processo para gerenciamento de projetos, ele será considerado por ter sido criado
inicialmente para gerenciar projetos de software. Além disso, as práticas do Scrum têm sido
amplamente adotadas por organizações intensivas em software.
Não faz parte do escopo deste trabalho modelos e normas que não sejam voltados ao
desenvolvimento de software. Portanto modelos de referência como MR-MPS-SV e CMMI-SVC não
foram considerados.
Para o desenvolvimento desta abordagem foram entrevistadas organizações intensivas em
software que trabalhem com projetos, ou seja, que possuam características de fábrica ou
desenvolvimento de produtos de software. A avaliação teve como base organizações das regiões de
Blumenau e Joinville.
Também foram considerados um conjunto de implementadores e avaliadores MPS.BR de
várias regiões do país. As avaliações foram realizadas basicamente por compartilhamento do sistema
especialista, para facilitar a logística e a utilização do SE.
Este estudo limitou-se a fontes de pesquisa na área de melhoria de processos de software.
Quaisquer outras áreas ou campos de pesquisa que possam beneficiar-se da abordagem deverão ser
tratados em trabalhos futuros. A abrangência da abordagem automatizada está limitada ao
conhecimento dos profissionais de MPS e ao conhecimento dos recursos2 das organizações.
2 Entende-se por funcionários.
24
1.1.3 Justificativa
Nos últimos anos as organizações de software estão cada vez mais em uma busca contínua para
se obter um melhor serviço e funcionalidade de produto de software. Entretanto, os produtos de
software continuam a ter custos elevados, atrasos na entrega e baixa qualidade (GARCÍA, 2010).
Os resultados da pesquisa sobre a implementação do programa MPS.BR apresentados por
Travassos e Kalinowski (2012) evidenciam a importância da busca por altos níveis de maturidade para
uma melhoria da produtividade, qualidade e precisão de estimativa. Em relação à produtividade e o
número de projetos, a pesquisa apresentou evidência de que empresas de alto nível de maturidade se
mostram mais capazes de lidar com um número maior de projetos sem sacrificar a produtividade
individual de cada projeto (TRAVASSOS; KALINOWSKI, 2012). Em relação ao processo, têm-se os
modelos de referência bem definidos que são largamente adotados pela indústria e estudos recentes
indicam a satisfação das organizações em aplicar estes modelos em seus processos (TRAVASSOS;
KALINOWSKI, 2010).
No início de um programa de melhoria de processos é fundamental fazer um levantamento da
situação atual e mapear pontos fortes e fracos visando ações de melhoria às características e
necessidades reais de uma empresa. Geralmente, são feitas avaliações no início do programa de
melhoria. Essa avaliação é uma análise dos processos utilizados pela organização, e pode ser feita
contra um modelo de referência para determinar a capacidade destes processos na sua execução de
acordo com as metas de qualidade, cronograma e custos estabelecidos (ANACLETO;
WANGENHEIM; SALVIANO, 2005).
Para organizações que não dispõem de recursos financeiros que possibilitem a implantação de
um programa de melhoria de processo de software, o diagnóstico inicial por meio de uma auto
avaliação, disponibilizada por um sistema especialista, permite o mapeamento do processo buscando
pontos fracos e possíveis melhorias, facilitando a busca por uma melhor qualidade no processo da
organização e consequentemente na qualidade do produto final.
Sendo assim surge à necessidade de uma abordagem de diálogos automatizados, apoiada por
uma ferramenta computacional, que permita que as organizações se auto avaliem, reduzindo os custos
e a complexidade desta atividade (MOREIRA, 2012). As limitações no trabalho de Moreira (2012),
como a falta de um levantamento do ciclo de vida de desenvolvimento, podem resultar na falta de
identificação das características do processo da organização.
25
1.2 OBJETIVOS
Esta seção formaliza os objetivos do trabalho, conforme descrito a seguir.
1.2.1 Objetivo Geral
Desenvolver uma abordagem de autodiagnostico para apoiar o mapeamento do ciclo de vida e
processo de desenvolvimento de software adotado para organizações intensivas em software.
1.2.2 Objetivos Específicos
1) Mapear os diferentes processos de desenvolvimento de software, adotado por organizações, a
partir das características das mesmas;
2) Desenvolver um sistema especialista que possa trazer como resultados pontos fracos, pontos
fortes e oportunidades de melhoria no processo de desenvolvimento de software adotado por
uma organização;
3) Desenvolver uma base de conhecimento que apoie o sistema especialista integrando as árvores
de decisão com o conhecimento das árvores de decisão desenvolvidas em Moreira (2012) e
4) Avaliar o sistema especialista por especialistas e a partir de sua aplicação em empresas reais de
desenvolvimento de software.
1.3 METODOLOGIA
Nesta seção, apresenta-se a metodologia de pesquisa e os procedimentos metodológicos
adotados neste trabalho.
1.3.1 Metodologia da Pesquisa
O método científico é importante em computação porque como Ciência ela não pode se limitar
apenas da coleta de dados. A explicação dos dados é mais importante (WAZLAWICK, 2010).
Neste trabalho utilizou-se o método hipotético dedutivo, e foram utilizados experimentos com
empresas de software e especialistas em melhoria de processo, visando como resultado o mapeamento
do ciclo de vida e processo de desenvolvimento das organizações.
26
O presente trabalho, do ponto de vista de sua natureza, caracteriza-se como uma pesquisa
aplicada. Dentro deste contexto, o resultado final visa uma abordagem para mapear o processo adotado
pela organização a partir de informações coletadas da ferramenta de autodiagnostico, ou seja, o sistema
especialista.
Com relação ao ponto de vista da abordagem do problema, este trabalho enquadra-se como
uma pesquisa qualitativa. Neste caso a avaliação da abordagem será dada de forma subjetiva.
Do ponto de vista dos seus objetivos, considera-se essa pesquisa como exploratória. Utilizou-se
a pesquisa bibliográfica baseada em livros, teses e dissertações, artigos de periódicos disponibilizados
na internet, para realizar uma fundamentação teórica e guiar o desenvolvimento. Por se tratar de uma
pesquisa exploratória, permite-se propor uma visão mais ampla do aspecto da abordagem aplicada para
a implantação da melhoria de processo de software.
1.3.2 Procedimentos Metodológicos
O presente trabalho engloba várias etapas, descritas a seguir:
1) Fundamentação Teórica: A fim de criar um embasamento sólido para a fundamentação
teórica deste estudo, utiliza-se dos métodos de pesquisa bibliográfica além do conteúdo
relacionado aos modelos de ciclo de vida, processos de desenvolvimento de software,
modelos de referência e normas, avaliação de software, sistemas especialistas e
diagnósticos.
2) Estado da Arte: Nesta etapa, realizou-se uma pesquisa sobre trabalhos correlatos existentes
na literatura que fazem o diagnóstico de forma automatizada, bem como as metodologias
existentes para o mapeamento de ciclos de vida e processos de desenvolvimento de
software, documentando o resultado da pesquisa. Por meio de uma revisão sistemática da
literatura identificou-se o grau de originalidade do trabalho e diferenças entre o trabalho
proposto frente aos trabalhos similares.
3) Modelo Proposto: Analisando as documentações geradas anteriormente, foram
identificados os requisitos necessários para implementar o sistema especialista que apoie o
27
mapeamento do ciclo de vida de desenvolvimento de software de uma organização
intensiva em software. O modelo foi construído utilizando o conteúdo do mapeamento
sistemático e da fundamentação teórica, árvores de decisão, regras de produção, entrevistas
com organizações e especialistas em MPS. Os resultados desta etapa foram analisados e
documentados, para serem utilizados na etapa seguinte.
4) Avaliação: Utilizou-se a abordagem GQM (Goal/Question/Metrics), proposto por Basili et
al. (1994). Foram duas avaliações, uma sob o ponto de vista de profissionais da área de
MPS e uma sob o ponto de vista das organizações. Na primeira, foi avaliada a adequação do
conteúdo da abordagem em relação ao conteúdo da área de melhoria de processos de
software (modelos estudados e a partir das informações coletadas na revisão da literatura).
Na segunda, foi avaliada a aderência da abordagem em relação ao resultado emitido pelo
sistema especialista.
5) Resultados: O resultado da avaliação foi analisado por especialistas em MPS.
Com a abordagem desenvolvida, foram realizados experimentos reais em organizações
intensivas em software. O diagnóstico pode ser realizado por meio da ferramenta de sistema
especialista e o resultado avaliado por especialistas da área de Melhoria de Processos de Software.
Por fim, os resultados obtidos com a avaliação do sistema especialista (experimento real) foram
registrados e analisados, dando origem a pelo menos um artigo científico, para submissão em
congressos ou periódicos da área de engenharia de software.
28
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo tem como objetivo apresentar os principais conceitos teóricos necessários ao
desenvolvimento deste trabalho, como: modelos de ciclos de vida de desenvolvimento, processos de
desenvolvimento, modelos de referência e normas, avaliação de software e por fim, sistemas
especialistas.
2.1 MODELOS DE CICLO DE VIDA DE DESENVOLVIMENTO
Os modelos podem ser usados para representar toda a vida desde a concepção até o descarte ou
para representar a parte da vida correspondente ao projeto atual. O modelo de ciclo de vida é composto
por uma sequência de fases que podem se sobrepor e/ou iterar, conforme apropriado para o escopo do
projeto, magnitude, complexidade e necessidades de mudanças e oportunidades. Cada fase é descrita
com uma declaração de propósito e resultados. Os processos e as atividades do ciclo de vida são
selecionados e empregados em uma fase para cumprir o propósito e os resultados da mesma (ISO/IEC
12207, 2008).
Um ciclo de vida de desenvolvimento de Software é a forma de construção do desenvolvimento
de um produto de software. Geralmente as atividades relacionadas a cada fase são consideradas um
subconjunto de ciclo de vida de desenvolvimento de sistemas. Existem modelos para tais processos,
cada um descrevendo abordagens para uma variedade de tarefas ou atividades que ocorrem durante o
processo (BHUVANESWARI; PRABAHARAN, 2013).
Modelos de ciclo de vida de desenvolvimento de software (SDLC3) descrevem as fases e a
ordem em que essas fases são executadas de modo a desenvolver um produto de software. As fases
comuns são levantamento de requisitos, especificação, projeto, codificação, testes e manutenção
(RAGUNATH, 2010; KHURANA, 2012; CLARA, 2013). Cada fase produz resultados finais exigidos
pela próxima fase do ciclo de vida. Existe grande variedade de modelos de desenvolvimento de cada
um com os seus procedimentos e passos específicos. (GUPTA; AGGARWAL, 2012).
3 Software Development Life Cycle (Ciclo de vida de desenvolvimento de software)
29
Modelos de ciclo de vida de desenvolvimento de software são mecanismos que garantem que o
software atenda aos requisitos estabelecidos. Estes modelos impõem vários graus de disciplina para o
processo de desenvolvimento de software com o objetivo de tornar o processo mais eficiente e
previsível. Nos dias de hoje, as empresas têm diversas opções de modelos a adotar para o
desenvolvimento de software. Cada modelo satisfaz a necessidade específica de cada cliente
(KHURANA; GUPTA, 2012).
O modelo de ciclo de vida de desenvolvimento de software refere-se às fases do processo de
desenvolvimento. Na produção de um software há um ciclo de vida ou uma série de fases que,
naturalmente, estão interligadas. O modelo de ciclo de vida descreve as fases envolvidas no
desenvolvimento de software, a partir de um estudo de viabilidade (CLARA, 2013).
Dentre os modelos de ciclos de vida de desenvolvimento de software existentes na literatura,
pode-se destacar os modelos cascata, evolucionário, espiral, incremental e incremental iterativo
(PAULA FILHO, 2009; PRESSMAN, 2010; SOMMERVILLE, 2007).
As fases são, por vezes, decompostas em partes menores, descritas como atividades. Uma
atividade pode ser considerada simplesmente como um conjunto de tarefas (ISO/IEC 12207, 2008).
2.1.1 Modelo Cascata
O modelo cascata é o modelo clássico da engenharia de software. Este modelo é um dos mais
antigos e é muito utilizado em projetos de grandes empresas (VERMA et al., 2013). Ainda, segundo
Verma et al. (2013), o modelo enfatiza o planejamento nas fases iniciais, pois evita falhas de projeto
antes mesmo que elas se desenvolvam. O modelo cascata contém várias fases não sobrepostas, como
apresentado na Figura 2. O modelo começa com o estabelecimento de requisitos de sistema e
requisitos de software e continua com o projeto arquitetônico, projeto detalhado, codificação, testes e
manutenção. O modelo cascata serve como base para vários outros modelos de ciclo de vida (VERMA
et al., 2013).
De acordo com Ragunath et al. (2010), o modelo cascata possui as seguintes características:
Fases de especificação e desenvolvimento separadas e distintas;
Todas as atividades de forma linear e
30
A próxima fase só começa quando a primeira está completa.
A Figura 2, representa o modelo cascata de acordo com Verma et al. (2013).
Figura 2. Modelo Cascata
Fonte: Adaptado de Verma et al. (2013).
A lista a seguir detalha as etapas utilizadas no modelo Cascata, de acordo com a Figura 2:
1) Requisitos de Sistema: Estabelecem os componentes para a construção do sistema,
incluindo os requisitos de hardware, ferramentas de software e outros componentes
necessários. Exemplos incluem decisões sobre hardware, como placas e as decisões
sobre peças externas de software, tais como bancos de dados ou bibliotecas.
2) Requisitos de Software: Estabelecem as expectativas para a funcionalidade do software
e identifica quais os requisitos do sistema afetam o software. Análise de requisitos
inclui determinar a interação necessária com outras aplicações e bancos de dados,
requisitos de desempenho e requisitos de interface do usuário.
3) Projeto Arquitetônico: Determina o framework do sistema, necessário para atender os
requisitos específicos de software. Esta fase define os componentes principais e a
interação dos mesmos. As interfaces externas e ferramentas utilizadas no projeto podem
ser determinadas nesta fase.
4) Projeto Detalhado: Examina os componentes de software definidos na fase anterior e
produz uma especificação de como cada componente é implementado.
5) Codificação: Implementa a especificação detalhada do projeto.
6) Testes: Determina se o software atende aos requisitos especificados e encontra erros
presentes no código.
31
7) Manutenção: Aborda os problemas e pedidos de melhorias após os lançamentos de
software. Em algumas organizações, o controle de mudanças mantém a qualidade do
produto, revendo cada alteração feita na fase de manutenção.
2.1.2 Modelo Evolucionário
O objetivo deste modelo é descrever um processo no qual o software pode ser desenvolvido a
partir da evolução de protótipos iniciais. Este modelo é baseado na prototipação (ou prototipagem),
que sugere uma abordagem baseada numa visão evolutiva do desenvolvimento de software. Esta
abordagem produz versões iniciais (protótipos) com a qual podem ser realizadas verificações e
experimentações, a fim de avaliar os requisitos antes que o software venha a ser desenvolvido por
completo (BARROS, 2011).
Um protótipo tem por objetivo permitir que os usuários do software possam avaliar propostas
dos desenvolvedores através de um desenho do produto final, ao invés da interpretação e avaliação do
projeto somente com base em descrições. A prototipação também pode ser usada por usuários finais
para descrever e comprovar os requisitos que os desenvolvedores não consideraram, e que pode ser um
fator chave na relação comercial entre os desenvolvedores e seus clientes. A prototipação envolve as
seguintes etapas (GUPTA; AGGARWAL, 2012):
1) Identificar os requisitos básicos, através de análise dos itens a serem implementados;
2) Desenvolver protótipo inicial, como forma de fazer uma apresentação gráfica do que
será desenvolvido;
3) Os clientes, incluindo usuários finais, examinam o protótipo e fornecem um feedback
sobre aditamentos ou alterações e
4) Usando o feedback tanto as especificações quanto o protótipo podem ser melhorados
(GUPTA; AGGARWAL, 2012).
Na Figura 3, segue uma representação de como é o ciclo de desenvolvimento para o modelo
evolucionário.
32
Figura 3. Modelo Evolucionário
Fonte: Sommerville (2007).
O modelo evolucionário ou prototipação, segundo Carvalho e Chiossi (2001) pode ser de dois
tipos: desenvolvimento exploratório, em que o objetivo do processo é trabalhar junto com o usuário
para descobrir seus requisitos, de maneira incremental até alcançar o produto final; e o protótipo
descartável que objetiva entender os requisitos do usuário para obter uma melhor definição dos
requisitos do sistema. O objetivo desta seção foi apresentar o modelo exploratório, uma vez que o foco
do trabalho está no ciclo de desenvolvimento.
2.1.3 Modelo Espiral
O modelo em espiral é semelhante ao modelo incremental, com mais ênfase colocada na
análise de risco. O modelo espiral tem quatro fases: Planejamento, Análise de Risco, Engenharia e
Avaliação. Um projeto de software passa repetidamente através dessas fases através de iterações (neste
modelo, chamadas de espirais). A espiral da linha de base, a partir da fase de planejamento, os
requisitos estão reunidos e o risco é avaliado. Cada espiral subsequente baseia-se na linha de base da
espiral. Os requisitos são recolhidos durante a fase de planejamento. Na fase de análise de risco, um
processo é realizado para identificar soluções de risco e alternativas. Um protótipo é produzido no final
da fase de análise de risco. O software é produzido na fase de engenharia, juntamente com o teste no
final da fase. A fase de avaliação permite o cliente avaliar a saída do projeto antes que o projeto
continue para a próxima espiral. No modelo de espiral, o componente angular representa progredir, e o
raio da espiral representa custo (MUNASSAR; GOVARDHAN, 2010).
A Figura 4 representa o modelo espiral.
33
Figura 4. Modelo Espiral
Fonte: Sommerville (2007).
2.1.4 Modelo Incremental
No modelo incremental, tem-se como primeiro incremento o núcleo do produto, onde apenas os
requisitos básicos são definidos. Esse núcleo do produto é enviado para o cliente e um próximo
incremento é desenvolvido (PRESSMAN, 2010).
O modelo incremental combina elementos do modelo em cascata aplicado de maneira
incremental, conforme ilustrado na Figura 5. Cada sequência linear produz incrementos do software
passíveis de serem entregues. Em cada incremento é realizado todo o ciclo do desenvolvimento de
software, do planejamento aos testes do sistema já em funcionamento. Cada etapa produz um sistema
totalmente funcional, apesar de ainda não cobrir todos os requisitos.
34
Figura 5. Modelo Incremental
Fonte: Pressman (2010).
Pode-se notar pela Figura 5 que o modelo incremental aplica sequências lineares (como no
modelo cascata) de forma escalonada, à medida que o tempo do projeto for avançando. Cada uma das
sequencias lineares gera um incremento do software. Esses incrementos são entregáveis e estão
prontos para o cliente.
2.1.5 Modelo Incremental e Iterativo
O modelo incremental corresponde à ideia de aumentar pouco-a-pouco o sistema em sucessivos
incrementos. Por sua vez, o modelo iterativo corresponde à ideia de refinar o sistema pouco-a-pouco.
A essência do sistema não é alterada, mas o seu detalhe vai aumentando em iterações sucessivas
(SILVA; VIDEIRA, 2001).
O desenvolvimento iterativo é uma abordagem para a construção de software, em que o ciclo
de vida total é composto de várias iterações em sequência. Cada iteração é um mini projeto
independente composto por atividades como análise de requisitos, design, programação e teste
(LARMAN, 2004)
O modelo Incremental e Iterativo, é a união destes dois modelos, onde para cada requisito é
definido o que é mais importante e o que é menos importante, assim um número de incrementos para
35
entrega é definido, com cada incremento fornecendo um subconjunto das funcionalidades do sistema.
Após a priorização dos incrementos, os requisitos são detalhados. Em seguida, iterações são criadas e
um processo mini cascata é iniciado. Depois de desenvolvidas as iterações, as mesmas são entregues.
A medida que novos incrementos são construídos eles vão sendo agregados aos já existentes
(LARMAN, 2004; SOMMERVILLE, 2007).
Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto,
conforme a Figura 6.
Figura 6. Diagrama do ciclo de vida Incremental e Iterativo
Fonte: Larman (2004).
No modelo Incremental e Iterativo, mesmo que todas as fases tenham uma única iteração, o
modelo ainda é diferente do Cascata, pois permite que cada iteração passe por todas as atividades.
Tipicamente, este modelo de ciclo de vida consegue compreender tanto o desenvolvimento (ciclo
inicial) de um produto quanto a sua manutenção (ciclos evolutivos).
2.2 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Atualmente, as organizações buscam cada vez mais, uma forma de alcançar a melhoria no
processo de desenvolvimento do software, por meio da formalização de seus processos. Os processos
de desenvolvimento de software possibilitam a melhoria na qualidade dos produtos desenvolvidos.
36
Na literatura existem muitos conceitos em relação a processos de software. Para Fugetta (2000)
“Um processo de software pode ser definido como um conjunto coerente de políticas, estruturas
organizacionais, tecnologias, procedimentos e artefatos que são necessários para conceber,
desenvolver, implantar e manter um produto de software”. Pressman (2006) define “Processo de
software como um arcabouço para as tarefas que são necessárias para construir software de alta
qualidade”. Já para, Sommerville (2007) “Um processo de software é um conjunto de atividades,
métodos e práticas utilizados para produzir um software”.
Contudo processo de software nada mais é que uma sequência de atividades, a serem aplicadas
sistematicamente por pessoas que desenvolvem e mantém um produto de software e os artefatos
associados como projeto, documentação de projeto, planos de teste, códigos, protótipos, casos de teste
e manuais. Essas atividades podem ser agrupadas em fases que possuem entradas e produzem saídas.
A fim de especificar quais atividades devem ser executadas e em qual ordem, têm-se os modelos de
processo de software.
O modelo de processo de software consiste de um conjunto de atividades realizadas para criar,
desenvolver e manter sistemas de software. Uma variedade de modelos de processos de software foi
concebida para estruturar, descrever e prescrever o processo de desenvolvimento de software. Os
modelos de processo de software desempenham um papel muito importante no desenvolvimento de
software, de modo que forma o núcleo do produto de software (KAUR, 2011).
Dentre os processos de desenvolvimento de software da literatura estão o XP, Scrum e RUP. O
presente trabalho irá utilizar em seus estudos esses três processos por se tratarem de serem os mais
citados na literatura, apesar de não ter sido encontrada uma métrica que determine que os três são os
mais citados. O XP é projetado principalmente para equipes menores com dois a dez membros
(FOJTIK, 2011). O RUP se encaixa tanto para pequenas equipes, como para grandes organizações de
desenvolvimento (IBM, 2001). O Scrum é um framework voltado para gerenciamento de projetos
(SCHWABER, 2004).
A utilização do Scrum e do XP nesta pesquisa é importante devido ao seu grau de utilização
nas organizações, ultimamente e o RUP por envolver os modelos mais clássicos. Processos ágeis são
aplicados em projetos em que há muitas mudanças, em que os requisitos são passíveis de alterações,
onde refazer partes do código não é uma atividade que apresenta alto custo, as equipes são pequenas,
as datas de entrega são curtas e o desenvolvimento rápido é fundamental. Enquanto no ciclo de vida
37
tradicional as equipes de desenvolvimento costumam realizar uma reunião com os stakeholders para
obter todos os requisitos detalhados em fases precoces do processo de desenvolvimento. Em seguida,
as equipes de desenvolvimento iniciam a fase de construção. A fase de testes, só terá início quando
todo o processo de codificação for concluído (LEAU et al., 2012).
É importante que a equipe de desenvolvimento selecione o processo que melhor se adapte ao
projeto. Existem alguns critérios que a equipe de desenvolvimento pode usar para identificar o
processo desejado, estes incluem o tamanho da equipe, situação geográfica, o tamanho e a
complexidade do software, tipo de projeto, estratégia de negócios, capacidade de engenharia, entre
outros. Também se faz necessário estudar as diferenças, vantagens e desvantagens de cada um dos
tipos de processo. Além disso, a equipe deve analisar o contexto de negócios, as exigências da
indústria e estratégia de negócios para ser capaz de avaliar o processo de desenvolvimento (LEAU et
al., 2012).
2.2.1 Extreme Programming (XP)
O processo de desenvolvimento de software ágil como Extreme Programming tenta diminuir o
custo da mudança e com isso reduzir os custos globais de desenvolvimento. O elemento principal do
ciclo de vida do XP é a "iteração". A iteração é um evento recorrente na qual uma versão atual é
editada, por exemplo, adicionando uma funcionalidade, corrigindo erros ou removendo uma
funcionalidade desnecessária. O resultado de cada iteração é validado através de um teste de aceitação.
No XP a duração de cada iteração é muito curta (1-4 semanas) em comparação com o desenvolvimento
de software tradicional. Assim, a fase de planejamento, também é muito curta e realizada
principalmente pela definição de tarefas (DUMKE et al., 2008).
O XP possui 5 valores (BECK, 2004):
1) Comunicação: Muitos problemas de desenvolvimento se encontram na comunicação
incorreta entre membros da equipe de desenvolvimento e até mesmo com o cliente. Para
resolver isso, o XP pratica a comunicação frequente. Grandes equipes de
desenvolvimento atribuem um papel especial, chamado de treinadores, onde os mesmos
detectam falhas de comunicação e praticam a comunicação correta entre todos os
envolvidos;
38
2) Simplicidade: O processo XP, diz que não deve-se criar uma arquitetura mais robusta
do que o necessário para o momento, o processo procura desenvolver software tão fácil
quanto possível, para lidar com todas as funcionalidades que não são importantes
atualmente e que podem ser trabalhadas no futuro;
3) Feedback: É muito importante para o desenvolvimento correto. Está em vários níveis.
Um deles é o teste, que deve ser realizado em todas as fases de desenvolvimento e não
após a fase de implementação;
4) Coragem: Um valor muito importante do XP é a coragem de corrigir e remover os erros
a todo custo. Ele ainda significa remover uma grande parte do código ou a parte
fundamental e tão logo refazer o projeto de arquitetura. De acordo com a experiência
com o uso prático de XP nas empresas, parece que este requisito é difícil de ser
aplicado. Os desenvolvedores acham que a remoção de uma grande parte do código
assina seu fracasso e eles são menos propensos a tentar mais;
5) Respeito: Os membros da equipe devem estar interessados no trabalho de seus colegas.
No caso de indivíduos que trabalham sozinhos, sem relações estreitas com os outros o
XP será inútil.
O XP possui doze práticas que consistem no núcleo principal do processo e que foram criadas
com base nos ideais pregados pelos valores. Segundo Beck (2004), um dos criadores do XP, estas
práticas não são novidades, mas sim práticas que já vêm sendo utilizadas a muitos anos, com
eficiência, em projetos de software. As doze práticas do XP são (BECK, 2004):
1) Jogo de Planejamento (Planning Game): Determina o escopo das próximas versões
combinando a prioridades do negócio e estimativas técnicas. Como prática, estrutura e
atualização do plano.
2) Fases pequenas (Small Releases): Rapidamente um sistema simples consegue ir para
produção, e o atualiza frequentemente em ciclos curtos.
3) Metáfora (Metaphor): A intenção da metáfora é oferecer uma visão geral do sistema,
em um formato simples, que possa ser compartilhada por clientes e programadores.
39
4) Projeto Simples (Simple Design): O sistema precisa ser projetado o mais simples
possível satisfazendo os requisitos atuais.
5) Testes constantes: Os testes em XP são feitos antes da programação. Existem dois tipos
de teste: teste de unidade e teste funcional.
6) Refactoring: Os times procuram aperfeiçoar o projeto do sistema durante todo o
desenvolvimento, mantendo a clareza do software: sem ambiguidade, com alta
comunicação, simples, porém completo.
7) Programação em pares (Pair Programming): Todo o código produzido em XP é escrito
por um par de programadores, que possuem papéis distintos, sentados lado-a-lado e
trabalhando no mesmo computador.
8) Padronização do Código (Coding Standards): A equipe de desenvolvimento precisa
estabelecer regras para programar e todos devem seguir estas regras. Desta forma
parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a
equipe possui 10 ou 100 membros.
9) Propriedade coletiva (Colletive ownership): Todo o código pertence a todo o time.
Então, qualquer um pode alterar qualquer código em qualquer tempo.
10) Integração Contínua (Continuous Integration): Sempre que produzir uma nova
funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto
só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte.
Integrar de forma contínua permite saber o status real da programação.
11) Semana de 40-horas (40-hour week): Como regra, não se deve trabalhar mais que 40
(quarenta) horas na semana. Programadores exaustos cometem mais erros.
12) Cliente no local (On-site customer): Deve ser incluído na equipe uma pessoa da parte do
cliente, que irá usar o sistema, para trabalhar junto com os outros e responder as
perguntas e dúvidas.
As características gerais do ciclo de vida XP são mostradas na Figura 7.
40
Figura 7. eXtreme Programming
Fonte: Adaptado de Wells (2000).
O processo de desenvolvimento de software XP foi projetado para uso iterativo com um breve
planejamento (3 meses para releases e iterações de 1-2 semanas). No XP, uma liberação corresponde a
uma versão, entregue para o cliente que poderá utilizá-la. Iterações são mais curtas que os incrementos
de desenvolvimento onde as tarefas individuais são atribuídas aos desenvolvedores e um protótipo
funcional do sistema é desenvolvido e periodicamente avaliados pelos participantes do projeto. As
práticas do XP não incluem uma extensa preparação de requisitos ou documentos de projeto antes de
iniciar o desenvolvimento. Consequentemente, o XP é fortemente dependente da contínua
comunicação entre as partes interessadas (LAYMAN, 2006).
2.2.2 Scrum
Scrum é um framework que está sendo usado para gerenciar o desenvolvimento de produtos
complexos desde o início de 1990. Scrum não é um processo ou uma técnica para construir produtos,
em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas
(SCHWABER, 2011).
Baseia-se, em princípios como: equipes pequenas; com requisitos que são pouco estáveis ou
desconhecidos; com pequenos ciclos que divide o desenvolvimento em intervalos de tempos de no
máximo 30 dias, também chamados de sprints (SCHWABER, 2004).
41
O Scrum implementa modelo iterativo e incremental cujas atividades são assumidas por três
papéis principais (SCHWABER, 2004):
• Product Owner: é o dono do produto; define os fundamentos do projeto como os requisitos
iniciais e gerais (Product Backlog), retorno de investimento, objetivos e formas de entregas;
priorização para o Product Backlog a cada sprint, garantindo que as funcionalidades de maior valor
sejam desenvolvidas prioritariamente;
• ScrumMaster: gerencia o processo do Scrum, ensina e implementa o Scrum de modo que
esteja adequado à cultura da organização; deve garantir que todos sigam as regras e práticas do Scrum;
e também é responsável por remover os impedimentos do projeto e
• Time: desenvolve o produto; define como transformar o Product Backlog em incremento de
funcionalidades numa sprint. O time é responsável pelo sucesso da sprint e consequentemente pelo
projeto como um todo.
Todo o trabalho no Scrum é realizado em iterações chamadas de sprints. Schwaber (2004)
explica que:
O coração do Scrum é a Sprint, um time-box de um mês ou menos, durante o qual um “Pronto”, versão
incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o
esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior. As
Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de
desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.
A Figura 8 representada abaixo apresenta uma visão geral do Scrum.
42
Figura 8. Visão geral do Scrum
Fonte: Marçal (2009).
De acordo com Schwaber (2004), o Scrum introduz os seguintes artefatos principais usados ao
longo do seu fluxo de desenvolvimento: Product Backlog, Sprint Backlog e incremento de
funcionalidade do produto.
O Product Backlog contém uma lista de itens priorizados que incluem os requisitos funcionais
e não funcionais do sistema/produto que está sendo desenvolvido no projeto. O Sprint Backlog
corresponde à lista de tarefas que o time do projeto define para implementar na sprint os requisitos
selecionados do Product Backlog. Os incrementos de funcionalidade consistem de códigos testados,
bem estruturados e bem escritos, que são executáveis acompanhados da documentação necessária para
a sua operação (MARÇAL, 2009).
A Figura 9 apresenta uma visão geral do processo do Scrum.
43
Figura 9. Fluxo de atividades do Scrum
Fonte: Simões (2011).
2.2.3 RUP
O RUP é um framework de processo de engenharia de software que pode ser adaptado para
uma grande variedade de projetos ou organizações. Ele fornece uma abordagem disciplinada para
delegar tarefas e responsabilidades em uma organização de desenvolvimento de software
(KRUCHTEN, 2000; IBM, 2001).
Segundo Tamaki (2007), as melhores práticas referentes ao RUP são:
Desenvolvimento de software iterativo;
Gerenciamento de requisitos;
Arquitetura baseada em componentes;
Modelagem visual;
44
Verificação contínua da qualidade e
Gerenciamento de mudanças.
A Figura 10 apresenta as duas dimensões do RUP. O eixo horizontal representa o aspecto
dinâmico do processo enquanto o eixo vertical representa o aspecto estático do processo.
A dimensão dinâmica representa o tempo e os aspectos do ciclo de vida do software à medida
que se desenvolve. A dimensão estática apresenta as disciplinas do RUP que agrupam as atividades do
processo pela sua natureza.
Figura 10. Dimensões do RUP
Fonte: IBM (2007).
Embora o nome dos fluxos possa caracterizar fases sequenciais de desenvolvimento em um
modelo de ciclo de vida cascata, deve-se ter em mente que as fases de um fluxo iterativo são diferentes
e os mesmos são revisitados várias vezes ao logo do ciclo de vida (IBM, 2007).
A abordagem iterativa tem impacto positivo no controle de execução do projeto, pois através
das iterações os gerentes de projeto controlam melhor as atividades. As atividades realizadas durante
as fases de iniciação e elaboração aumentam a previsibilidade da execução do projeto, abordando os
45
riscos do negócio. O RUP permite uma entrega mais rápida e mais frequente, devido o
desenvolvimento iterativo. Essa abordagem também permite que se tenha uma quantidade maior de
feedback, do cliente com a equipe de desenvolvimento, permitindo o auxílio à equipe a ajustar o
software para melhor adequação às expectativas dos clientes (OSORIO; CHAUDRON; HEIJSTEK,
2011).
2.3 MODELOS DE REFERÊNCIA DE AVALIAÇÃO DE PROCESSOS
Modelo de referência de avaliação de processos ou modelo de avaliação de processos é um
modelo que descreve os processos do ciclo de vida do software, baseado em uma boa engenharia e nos
princípios de gerência de processos e é adaptável ao propósito de avaliar a capacidade do processo
(ISO/IEC 15504, 2004).
O objetivo desta pesquisa é utilizar como apoio para as avaliações do ciclo de vida de
desenvolvimento das organizações intensivas em software, as metodologias utilizadas nos modelos de
referência, CMMI, MPS.BR e ISO/IEC 12207.
Os modelos de referência possuem estágios de maturidade e capacidade que envolvem todo o
ciclo de vida de desenvolvimento e que através de avaliações atingem uma estratégia confiável para
um processo de melhoria de desenvolvimento de software dentro das organizações. Dentro deste
contexto o trabalho atual faz menção à estes modelos, como base para construir e organizar as
avaliações para identificação do ciclo de vida de desenvolvimento de software.
2.3.1 CMMI
O Capability Maturity Model Integrated é um modelo de qualidade para processos de
desenvolvimento de software. Idealizado pelo Instituto de Engenharia de Software (SEI) da
Universidade Carnegie Mellon – USA, teve sua primeira versão lançada em 1991, com limitação
somente voltada as práticas de engenharia de software.
O CMMI oferece a oportunidade de acabar com barreiras e possíveis problemas por meio de
modelos. O CMMI para desenvolvimento (CMMI-DEV), consiste das melhores práticas relacionadas
as atividades de desenvolvimento e manutenção de produtos e serviços. Ele abrange práticas que
cobrem todo o ciclo de vida do produto desde a concepção até a entrega e manutenção e se concentra
no trabalho de construção e manutenção do produto (SEI, 2010a).
46
O CMMI-DEV contém 22 áreas de processos que são um conjunto de práticas inter-
relacionadas, que, quando implementadas coletivamente, satisfazem os objetivos considerados
importantes para obter melhoramentos numa determinada área. Essas práticas abrangem, gestão de
projetos, gestão de processos, engenharia de sistemas, engenharia de hardware, engenharia de
software, e outros processos de apoio utilizados no desenvolvimento e manutenção (SEI, 2010a).
De acordo com Quadro 1, pode-se visualizar os níveis e as áreas de processos equivalentes
(SEI, 2010a).
Quadro 1. CMMI - Áreas de processo
Nível Foco Área de processo
5 - Otimizado Melhoramento Contínuo do
Processo
Inovação Organizacional
Análise de causas e resoluções
4 – Gerenciado
Quatitativamente
Gerenciamento
Quantitativo
Performance organizacional do processo
Gerenciamento quantitativo de projetos
3 – Definido Padronização do Processo Requisitos de desenvolvimento
Soluções técnicas
Integração de produtos
Verificação
Validação
Foco no processo organizacional
Definição do processo organizacional
Treinamento organizacional
Gerenciamento de projeto integrado
Gerenciamento de riscos
Integração da equipe de trabalho
Gerenciamento integrado de suprimentos
Análise de decisões
Ambiente organizacional para integração
2 – Gerenciado Gerenciamento Básico de
Projetos
Gerenciamento de requisitos
Planejamento do projeto
Controle e monitoração do projeto
Gerenciamento de suprimentos
Avaliação e análise
Garantia da qualidade do processo e produto
Configuração do gerenciamento
1 – Inicial - -
Mesmo não sendo criado por uma instituição normativa como ISO, ANSI ou ABNT, a
aceitação do CMMI na indústria de software mundial é tão relevante que ele é o principal modelo de
referência para iniciativas de melhoria de processo de software, inclusive no Brasil (SANTANA, 2007;
SEI, 2014).
47
Em diversos países as organizações intensivas em software têm adotado, com sucesso, o
modelo CMMI. Há evidências de que as organizações que implementaram esse modelo obtiveram
melhorias significativas no desempenho dos seus processos, como o aumento da produtividade e da
qualidade dos produtos e dos processos, bem como a diminuição de custos, entre outras (GIBSON et
al., 2006). No entanto, esses resultados, geralmente, são observados em organizações de grande porte
com disponibilidade adequada de recursos para investir em melhorias de processos.
Um dos fatores limitantes deste modelo é que ele requer um grupo de especialistas em cada
empresa, voltado única e exclusivamente para a melhoria de processos. Considerando que em grande
parte das empresas, especialmente em grupos menores, a existência de um grupo especialista não é
uma prática comum, o próprio SEI tem recomendado o estabelecimento de modelos voltados para cada
desenvolvedor em particular e para os pequenos grupos (HUMPHREY, 1989).
2.3.2 MPS.BR
O programa MPS.BR é uma iniciativa de melhoria na capacidade de desenvolvimento de
software das empresas brasileiras. Seu objetivo principal é desenvolver e disseminar modelos de
melhoria de processos que atendam às necessidades da Indústria Brasileira de Software e Serviços de
TI (atualmente a família de modelos é composta pelos modelos de referência MPS-SW para Software
e MPS-SV para Serviços de TI), visando auxiliar economicamente as organizações, incluindo as
pequenas e médias empresas, para que alcancem os benefícios da melhoria de processos e da utilização
de boas práticas da engenharia de software e da prestação de serviços de TI em um curto intervalo de
tempo (TRAVASSOS; KALINOWSKI, 2012).
O MPS.BR é composto de um modelo de referência para processos de software MR-MPS-SW,
que contém os requisitos que os processos das unidades organizacionais devem atender para estar em
conformidade com o modelo MPS. Também faz parte do modelo um método de avaliação de
processos, o MA-MPS, que assegura a coerência na aplicação do MR-MPS-SW e suas definições
(SOFTEX, 2012).
O Modelo de Referência MR-MPS-SW descreve os processos em termos de propósito e
resultados. O propósito descreve o objetivo geral a ser atingido durante a execução do processo. Os
resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva
48
implementação do processo. Estes resultados podem ser evidenciados por um produto de trabalho
produzido ou uma mudança significativa de estado ao se executar o processo (SOFTEX, 2012).
O Quadro 2 apresenta os processos descritos pelo MR-MPS-SW.
Quadro 2. Processos do MR-MPS-SW
Processos
Gerência de Projetos – GPR (evolução)
Gerência de Riscos – GRI
Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
Verificação – VER
Validação – VAL
Projeto e Construção do Produto – PCP
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
Gerência de Projetos – GPR (evolução)
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional – AMP
Medição – MED
Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
Gerência de Requisitos – GRE
Gerência de Projetos – GPR
Fonte: Softex (2012).
Segundo Kalinowski et al. (2010), o conjunto de processos e os atributos de processos indicam
onde a organização tem que investir esforço para melhoria, de forma a atender seus objetivos de
49
negócio e ao MR-MPS-SW. Contudo, pode-se destacar que no modelo MR-MPS-SW, as boas práticas
são exigidas através de resultados de processos e de atributos de processo e cada vez mais a indústria
brasileira vem adotando-o como modelo para as boas práticas da engenharia de software nele previstas
(TRAVASSOS; KALINOWSKI, 2012).
2.4 CORPO DE CONHECIMENTO PARA ENGENHARIA DE SOFTWARE
(SWEBOK)
A área da Engenharia de Software passou por um estudo de uma comissão internacional de
especialistas, visando a uma definição das fronteiras que a delimitam. Esse estudo foi conduzido no
âmbito da IEEE e chama-se SWEBOK (Software Engineering Body of Knowledge, ou Corpo de
Conhecimento de Engenharia de Software) (IEEE, 2004).
O SWEBOK é dividido em um total de onze áreas de conhecimento (KOSCIANSKI;
SOARES, 2007; IEEE, 2014), sendo elas:
1) Requisitos de Software: A área de conhecimento de Requisitos de Software se preocupa
com a licitação, análise, especificação e validação de requisitos de software, bem como
o gerenciamento de requisitos durante todo o ciclo de vida do produto de software. Os
Requisitos de Software expressam as necessidades e restrições colocadas em um
produto de software que contribui para a solução de algum problema do mundo real.
2) Design de Software: Visto como um processo, projeto de software é a atividade do ciclo
de vida em que os requisitos de software são analisados a fim de produzir uma
descrição da estrutura interna do software que servirá como base para a sua construção.
Um projeto de software (o resultado), descreve a arquitetura de software, isto é, como o
software é decomposto e organizado em componentes, e as interfaces entre os
componentes. Deve também descrever os componentes em um nível de detalhe que
permite a sua construção.
3) Construção de Software: O termo construção de software refere-se à criação detalhada
de software através de uma combinação de codificação, verificação, testes unitários,
testes de integração e depuração. A área de conhecimento de Construção de Software
está ligada a todas as outras, mas é mais fortemente ligada ao Design de Software e
Teste de Software, porque o processo de construção de software envolve design de
50
software e testes, significativamente. O processo utiliza a saída de projeto e fornece
uma entrada para testar ("design" e "teste" neste caso referindo-se às atividades, e não
as áreas de conhecimento). Limites entre projeto, construção e testes (se houver) irão
variar de acordo com os processos de ciclo de vida de software que são usados em um
projeto. Embora alguns detalhes de projetos possam ser realizados antes da construção,
o trabalho de design é realizado durante as atividades de construção.
4) Teste de Software: O teste de software consiste na verificação dinâmica de
comportamentos esperados, que um programa fornece em conjunto com um finito de
casos de teste.
5) Manutenção de Software: Esforços de desenvolvimento de software resultarão na
entrega de um produto de software que satisfaça as necessidades dos utilizadores.
Assim, o produto de software deve mudar ou evoluir. Uma vez em operação, os defeitos
são descobertos, ambientes operacionais mudam, e surgem novas necessidades dos
utilizadores. A fase de manutenção do ciclo de vida começa após um período de
garantia de atividades ou pós implementação de entrega.
6) Gerenciamento de Configuração de Software: O gerenciamento de configuração, é a
disciplina de identificar a configuração de um sistema em pontos distintos com a
finalidade de controlar sistematicamente as alterações da configuração e manutenção,
da integridade e rastreabilidade da configuração ao longo do ciclo de vida do sistema.
7) Gestão de Engenharia de Software: Gestão de engenharia de software pode ser definida
como a aplicação de atividades de planejamento, coordenação, medição,
monitoramento, controle e emissão de relatórios, para garantir que os produtos de
software e serviços de engenharia de software sejam entregues de forma eficiente,
eficaz e em benefício das partes interessadas.
8) Software Engenharia de Processos: Um processo de engenharia consiste em um
conjunto de atividades inter-relacionadas que transformam uma ou mais entradas em
saídas ao consumir recursos para realizar essa transformação.
9) Modelos e Métodos de Engenharia de Software: Modelos e métodos de engenharia de
software impõe uma estrutura de engenharia de software que tem como objetivo fazer
51
com que as atividades sistemáticas e repetíveis estejam orientadas para o sucesso.
Modelos fornecem uma abordagem para a resolução de problemas, através de
procedimentos para análise e construção do modelo. Métodos fornecem uma abordagem
sistemática para a especificação, projeto, construção, teste e verificação de software.
10) Qualidade de Software: A qualidade do software também é considerada em muitas das
áreas do SWEBOK porque é um parâmetro fundamental de um esforço de engenharia
de software. Para todos os produtos de engenharia, o principal objetivo é entregar o
valor máximo das partes interessadas, enquanto equilibra as restrições do custo de
desenvolvimento e cronograma. Essa área de conhecimento aborda definições e fornece
uma visão geral de práticas, ferramentas e técnicas para a definição de qualidade de
software e para avaliar o estado da qualidade do software durante o desenvolvimento,
manutenção e implantação.
11) Prática de Engenharia de Software Profissional: Esta área de conhecimento está
preocupada com o conhecimento, habilidades e atitudes que os engenheiros de software
devem possuir para a prática de engenharia de software de uma forma profissional,
responsável e ética. Por causa das aplicações generalizadas de produtos de software na
vida pessoal e social, a qualidade de produtos de software pode ter um impacto
profundo em nossa vida pessoal, bem-estar e harmonia social.
12) Economia em Engenharia de Software: Esta área trata sobre a tomada de decisões
relacionadas com a engenharia de software em um contexto de negócios. O sucesso de
um produto de software, serviços e solução depende de uma boa gestão empresarial. No
entanto, em muitas empresas e organizações, as relações comerciais para
desenvolvimento de software e engenharia de software podem permanecer vagas. Esta
área do conhecimento fornece uma visão geral sobre a economia da engenharia de
software.
13) Fundamentos Computacionais: O escopo desta área de conhecimento, engloba o
ambiente de desenvolvimento e operacional em que o software evolui e executa. Porque
nenhum software pode existir em um vácuo, o núcleo de tal ambiente é o computador e
seus diversos componentes. O conhecimento sobre o computador e seus princípios
52
subjacentes de hardware e software serve como um quadro para a engenharia de
software.
14) Fundamentos Matemáticos: A área de conhecimento Fundamentos Matemáticos ajuda
os engenheiros de software compreender a lógica, que por sua vez é traduzida em
código de linguagem de programação. A matemática que é o foco principal da área de
conhecimento é bastante diferente da aritmética típica, em que os números são tratados
e discutidos. Lógica e raciocínio são a essência da matemática que um engenheiro de
software deve conhecer.
15) Fundamentos da Engenharia: Como a teoria e prática da engenharia de software
amadurece, é cada vez mais evidente que a engenharia de software é uma disciplina da
engenharia que se baseia em conhecimentos e habilidades comuns a todas as disciplinas
de engenharia. Esta área de conhecimento está preocupada com os fundamentos de
engenharia que se aplicam a engenharia de software e outras disciplinas de engenharia.
2.5 NORMA ISO/IEC 12207
A norma ISO/IEC 12207 provê um conjunto de processos, atividades e tarefas para ciclos de
vida de produtos e serviços de software. O objetivo desta norma é fornecer um conjunto definido de
processos para facilitar a comunicação entre compradores, fornecedores e outras partes interessadas no
ciclo de vida de um produto de software (ISO/IEC 12207, 2008).
Segundo a norma ISO/IEC 12207 (2008), a mesma possui um grupo de atividades que podem
ser realizadas durante o ciclo de vida de um sistema de software e está dividida em sete grupos de
processo. Cada um dos processos do ciclo de vida dentro desses grupos é descrito em termos de seu
propósito e resultados desejados e atividades de listas e tarefas que precisam ser executadas para
atingir esses resultados.
Para esta pesquisa, apenas o conteúdo relacionado ao processo de implementação de software,
é demonstrado na Figura 11, por ser o objetivo principal do trabalho em relação a norma. A Figura 11,
representa a organização da norma em termos de processos.
53
Figura 11. Grupos de Processos de Ciclo de Vida
Fonte: ISO/IEC 12207 (2008).
Processo de Implementação de Software: A finalidade do processo de implementação de
software é produzir um elemento específico do sistema, implementado como um produto ou serviço de
software. Este processo transforma um comportamento específico, interfaces e restrições de
implementação em ações que criam um elemento do sistema como um produto ou serviço de software,
também conhecido como um "item de software." Este processo resulta em um item de software que
54
satisfaça os requisitos de projeto de arquitetura através de requisitos de verificação e de interessados
através de validação.
Processo de Análise de Requisitos de Software: O objetivo deste processo é estabelecer os
elementos de requisitos do sistema de software.
Processo de Projeto de Arquitetura de Software: O objetivo deste processo é fornecer um
projeto de implementação de software que possa ser verificado em relação aos requisitos.
Processo de Projeto Detalhado de Software: O objetivo deste processo é fornecer um projeto de
implementação de software que possa ser verificado em relação aos requisitos e à arquitetura de
software, e é suficientemente detalhado para permitir a codificação e os testes.
Processo de Construção de Software: O objetivo do processo de construção de software é
produzir unidades de software executáveis que refletem adequadamente o projeto de software.
Processo de Integração de Software: O propósito deste processo é combinar as unidades de
software e componentes de software, produzindo itens de software integrados, de acordo com o projeto
de software e que demonstram que os requisitos de software funcionais e não-funcionais são satisfeitos
em uma plataforma operacional.
Processo de Teste e Qualidade de Software: O propósito deste processo é confirmar que o
produto de software integrado atende os seus requisitos definidos.
2.6 AVALIAÇÃO DE SOFTWARE
Processo de avaliação é uma avaliação disciplinada de processos de uma unidade
organizacional contra um Modelo de Processo de Avaliação, que é um modelo adequado para a
finalidade de avaliar a capacidade do processo. Um modelo de avaliação baseia-se em um ou mais
modelos de processos de referência, que compreendem as definições de processos em um ciclo de
vida, em conjunto com uma arquitetura que descreve as relações entre os processos (ISO/IEC 15504-1,
2004).
Para Mäkinen, Varkoi e Soini, (2007) um processo de avaliação estuda a capacidade do
processo com base em atributos de processo definidos no modelo de avaliação. Modelagem de
processos compreende a análise de atividades, artefatos, funções e ferramentas.
55
Dentro do contexto de avaliação de processo, Gray, Sampaio e Benediktsson (2005), destacam
que a mesma é a primeira fase de um programa de melhoria e por isso é importante que esta fase seja
feita de forma correta e através de técnicas de avaliação conforme Figura 12. Essas técnicas de
avaliação são baseadas em:
Listas de verificação enumeram as práticas da organização, mas não fornecem
informações suficientes para serem usadas sozinhas com uma técnica de avaliação;
Questionários permitem reunir informações mais completas, geralmente são utilizados
modelos como o questionário de maturidade do Software Engineering Institute (SEI);
Nos workshops, é possível ouvir grupos de funcionários em diferentes sessões, cada
uma conduzida por um facilitador e
Pro-formas, são pastas de trabalho, onde são organizados os resultados de uma
avaliação.
Figura 12. Modelo conceitual de processo de avaliação
Fonte: Adaptado de GRAY (2005).
Segundo Prikladnicki, Becker e Yamaguti (2005), devido ao alto grau de rigor e custos
associados a uma avaliação formal, além da necessidade de haver avaliações intermediárias, métodos
56
de mini avaliação e de diagnóstico foram sendo desenvolvidos por empresas de consultoria e
implementadores de modelos de qualidade.
2.6.1 Avaliação de Processo de Software
Ao iniciar um programa de melhoria de processos de software é necessário obter um
levantamento da situação atual, para isto, geralmente, são feitas avaliações no início do programa de
melhoria. Uma avaliação é uma análise dos processos utilizados por uma organização, que pode ser
feita contra um modelo de referência para determinar a capacidade destes processos na sua execução
de acordo com as metas de qualidade, cronograma e custo estabelecidos (ANACLETO;
WANGENHEIM; SALVIANO, 2005).
A motivação para a realização da avaliação de processos e atividades de melhoria é coletar
informações sobre o que precisa ser mudado e para estabelecer como buscar as melhorias, a fim de
minimizar o custo de desenvolvimento e maximizar a qualidade dos produtos produzidos
(PETTERSSON et al., 2008).
A partir da avaliação inicial são determinados pontos de maior prioridade a serem melhorados
considerando, principalmente, as metas de melhoria da organização e os benefícios que cada melhoria
pode trazer (ANACLETO; WANGENHEIM; SALVIANO, 2005).
Ao definir uma avaliação para melhoria de processo é necessário que seja construído um
modelo que o represente. Essa representação suporta o entendimento e a visualização do processo,
facilita sua disseminação e comunicação, auxilia na gerência de projetos, e é importante na avaliação,
evolução e melhoria contínua do processo (THIRY et al., 2006).
No trabalho de Mendes, Almeida e Arruda Jr., (2011), um modelo de avaliação para melhoria
de processo é ilustrado através da Figura 13.
57
Figura 13. Fluxograma de implantação de melhorias
Fonte: Mendes; Almeida; Arruda Jr., (2011).
No que se refere a processos de software, a importância da avaliação e melhoria é reconhecida
pelos vários modelos de qualidade. O CMMI (SEI, 2010a), por exemplo, define a área de processo
com foco no Processo Organizacional, cujo objetivo é planejar, implementar e implantar melhorias nos
processos organizacionais tomando por base um levantamento macro dos pontos fortes e fracos dos
processos da organização. Já o MPS.BR (SOFTEX, 2012) define o processo com foco na Avaliação e
Melhoria do Processo Organizacional, cujo propósito é determinar o quanto os processos padrão da
organização contribuem para alcançar os objetivos de negócio da organização e para apoiar a
organização a planejar, realizar e implantar melhorias contínuas nos processos com base no
levantamento de seus pontos fortes e fracos.
O MPS.BR possui o método de avaliação MA-MPS, cujo o propósito é verificar a maturidade
da organização na execução de seus processos de software e de serviços. O processo de avaliação
descreve o conjunto de atividades e tarefas a serem realizadas para atingir este propósito. Ele tem
início com a seleção de uma Instituição Avaliadora (IA) e encerra com o registro dessa avaliação na
base de dados confidencial da SOFTEX (SOFTEX, 2013).
O CMMI possui o Método Padrão para Melhoria de Processos (SCAMPI), que é projetado para
fornecer avaliações de qualidade de referência em relação ao modelo CMMI. O SCAMPI satisfaz
todas as Exigências de Avaliação para CMMI – ARC sendo por isso, um método de avaliação Classe
A que pode ser utilizado para avaliações do modelo ISO/IEC 15504 (SEI, 2011).
58
2.6.1.1 Diagnósticos
Quando uma empresa decide investir na melhoria de seus processos de software, surgem uma
série de questionamentos e debates envolvendo dúvidas em relação aos possíveis benefícios a serem
obtidos com a mudança. Porém, um fato é imprescindível: deve-se conhecer a situação atual dos
processos de software da empresa antes de iniciar um projeto de melhoria, através do diagnóstico.
Diagnóstico de processos em uma pequena empresa requer práticas de avaliação de processos
que dão resultados qualitativos e quantitativos, os quais devem oferecer uma visão geral da capacidade
do processo. O objetivo é a obtenção de informações relevantes sobre o funcionamento dos processos,
para uso em seu controle e melhoria. No entanto, as pequenas empresas têm alguns problemas na
execução da avaliação do processo, em razão das suas características e limitações específicas (PINO et
al., 2010). Um exemplo destes problemas, é o custo e o esforço relacionado a utilização da avaliação
de processo de software padronizada (WANGENHEIM; VARKOI; SALVIANO, 2006).
Diagnóstico de processos trata-se de um grupo de atividades a serem realizadas com a
finalidade de se obter um entendimento mais detalhado do programa de melhoria. Para isso, deve ser
realizada uma caracterização do estado atual e desejado da organização, através de atividades de
avaliação. Com base nessas avaliações, deve ser proposto um conjunto de recomendações para que o
estado desejado seja atingido. O resultado é um relatório detalhado e objetivo dos processos de
software da organização diagnosticada, servindo como referência e base para o planejamento e
decisões a respeito de melhoria de processos (PAULA FILHO et al., 2003).
Dentro do diagnóstico dos processos de software, pode-se citar as avaliações de
contextualização que identificam fatores organizacionais importantes e avaliam brevemente o processo
de software como um todo (JÄRVINEN, 2000). Os resultados da avaliação caracterizam a organização
numa visão alto nível do processo de software identificando processos importantes e críticos em
relação as metas de negócio. Perfis alvo de processos são definidos identificando processos mais
relevantes e os níveis de capacidade que devem ser atingidos para alcançar as metas de melhoria e
contribuir para as metas de negócio da organização (WANGENHEIM et al., 2005).
O processo de avaliação de contextualização é composto por 4 fases principais: Planejamento,
Coleta de dados, Análise de dados, Validação, Apresentação de resultados e Documentação, sendo
complementado pelo Controle e Finalização.
59
A Figura 14 ilustra o processo de avaliação de contextualização.
Figura 14. Visão geral do processo de avaliação de contextualização
Fonte: Wangenhein et al. (2005).
A pesquisa de Wangenhein et al. (2005), destaca as seguintes características para a avaliação de
contextualização:
O planejamento da avaliação envolve o contato com a organização a ser avaliada e a criação de
um planejamento de atividades que identificam o escopo da avaliação e são selecionados o método e o
modelo de avaliação a serem utilizados. Ainda nesta fase é definido o plano de avaliação que inclui
requisitos, método e modelo(s) a serem utilizados, estimativas, riscos e considerações práticas.
Na coleta de dados, são levantadas informações sobre a organização avaliada referentes aos
fatores organizacionais e ao processo de desenvolvimento do software. Faz parte da coleta de dados,
obter as informações através de questionários, conduzir uma reunião de abertura, identificar os fatores
de negócio com o propósito de mapear oportunidades e ameaças de negócio e metas de melhoria. E
ainda obter uma visão geral do processo de desenvolvimento do software, de forma ampla e alto nível,
por meio de entrevistas.
Na análise de dados, todas as informações coletadas na fase anterior são analisadas,
identificando informações gerais da organização, características, metas, principais produtos e/ou
serviços, informações sobre o processo de desenvolvimento do software identificando os principais
pontos fortes e fracos e identifica oportunidades de melhoria de forma geral.
60
Seguindo para a fase de validação e apresentação, todos os resultados são validados e
apresentados. Esses resultados são documentados em um relatório que é entregue aos responsáveis
pela avaliação na organização. Esta fase inclui o relatório preliminar com base no plano de avaliação e
nos resultados da análise da avaliação. Uma revisão preliminar em relação à consistência, completude,
corretude, não-ambiguidades e omissões.
Por fim na fase de controle e finalização, toda a avaliação é monitorada e controlada,
principalmente em termos de esforço e duração/prazos. Com foco na melhoria da avaliação, ao término
da mesma, as experiências adquiridas são avaliadas por meio de discussões com os avaliadores e por
questionários de satisfação obtendo um feedback do patrocinador.
No presente trabalho, parte das etapas descritas por Wangenhein et al. (2005), para avaliação
de contextualização, foram seguidas, como coleta dos dados, análise, validação e apresentação. A
coleta se dá através do sistema especialista, a análise é a etapa onde os resultados são exibidos com os
pontos fortes, pontos fracos e oportunidades de melhoria, a validação e apresentação se dão através das
avaliações feitas pelos gestores das organizações e especialistas em MPS.
2.6.2 Automatização de Diagnóstico
Recentemente, muitos esforços estão sendo feitos para a implementação da Melhoria de
Processo de Software em pequenas empresas e uma vez que se compromete a iniciar este processo, o
próximo passo é avaliar a capacidade atual da empresa para desenvolver e manter a melhoria do
software. Após isso, deve-se definir planos de ação relacionados a implementação dos processos de
melhoria. Existem uma série de estudos de casos que demonstram a aplicabilidade destas propostas em
um ambiente de pequena empresa, mas, infelizmente, há uma falta de informação sobre ferramentas de
software que, na verdade, sejam dirigidas as pequenas empresas na implementação de um programa de
MPS (GARCÍA; ANDREA, 2010).
Segundo Young, Fang e Hu (2006), são necessárias abordagens mais viáveis para implementar,
medir e melhorar os processos de software em pequenas empresas. Ou seja, para realizar avaliações é
necessário um processo automatizado de software como uma questão de interesse primário para as
melhorias. Com base na experiência de Young, Fang e Hu (2006), as ferramentas não são apenas
importantes, mas essencial para a perfeita integração de processos e também na produção de diferentes
produtos de trabalho.
61
Em 2008, Thiry et al. (2008) desenvolveu uma ferramenta de suporte a avaliação, alinhada ao
MPS.BR e a outro modelo de referência simultaneamente, onde é permitida a realização de avaliações
integradas, em que os artefatos coletados na fase preparatória de uma avaliação poderão ser
reutilizados para evidenciar a execução de práticas de um segundo e terceiro modelo de referência,
sem a necessidade de serem coletados novamente. Isto oferecerá maior flexibilidade e abrangência
para a equipe de avaliação.
Outras ferramentas têm sido desenvolvidas para apoiar a execução da melhoria de processo nas
organizações. Uma delas é o desenvolvimento da ferramenta de software livre SPIDER-PE proposto
por Silva et al. (2012), que tem o intuito de apoiar a execução flexível e semi automatizada de
processos de software a partir das boas práticas definidas pelos modelos de qualidade e melhoria do
processo.
No projeto de Mendes e Oliveira (2006), é proposto um método de diagnóstico de processos
através de uma ferramenta, com o intuito de eliminar tarefas mecânicas como a consolidação de
questionários. O projeto possibilitou, a identificação de boas práticas que, se adotadas, poderão trazer
ainda mais qualidade aos diagnósticos que utilizam o método proposto. A principal delas foi a
necessidade de uma melhor definição dos papéis nas entrevistas.
2.7 SISTEMA ESPECIALISTA
As organizações têm o paradigma de redução de custos adotado frequentemente em suas
operações. Para apoiar as organizações nesse objetivo, pode-se contar com um recurso computacional
denominado sistema especialista, que é descrito por Munárriz (1994) como um programa de
computador, cujo comportamento seria de uma pessoa, especialista, ao resolver um problema, em um
domínio especifico para o qual foi designado. Desta forma, observa-se que o uso de sistemas
especialistas pode, em muitas situações, reduzir os custos operacionais oferecendo maior agilidade na
resolução de problemas específicos que pessoas, em sua grande maioria, demorariam mais tempo para
resolver.
Segundo Haykin (2008), um sistema de Inteligência Artificial (IA) deve ser capaz de armazenar
conhecimento e aplicá-lo para resolver problemas e adquirir novo conhecimento através da
experiência. Os sistemas especialistas (SE) são ferramentas computacionais cujo objetivo é simular as
decisões que seriam tomadas por uma pessoa especializada na área que pretende-se explorar, tentando
62
reproduzir boa parte do conhecimento do especialista (COWELL et al., 1999). No contexto de um SE,
um especialista é alguém com conhecimentos e habilidades em determinada área capaz de resolver
problemas específicos.
Os SE podem atuar na forma de sistemas interativos, respondendo questões, solicitando ou
fornecendo esclarecimentos e recomendações, podendo também auxiliar o usuário na tomada de
decisões. De modo geral, podem simular o raciocínio humano ao fazer inferências, julgamentos ou
projetar resultados (LINARES, 1997).
São utilizados quando um problema ou sua solução conduza a um processamento muito
demorado. Dentre seus objetivos, está o de preservar e transmitir o conhecimento de algum especialista
em determinada área (ROSSO, 2002).
Um Sistema Especialista, também pode ser definido como um sistema de computador, que
contém um corpo de conhecimento que imita a capacidade de um especialista em resolver problemas.
Por outro lado, um SE baseado em regras é um programa de computador que é capaz de usar
informações de uma base de conhecimento, através de um conjunto de procedimentos de inferência,
para resolver problemas que são difíceis o suficiente para exigir experiência humana significativa para
a sua solução (HARMON; KING, 1985).
Segundo Keller (1991) um SE pode ser definido como sendo uma parte da Inteligência
Artificial que utiliza regras de “condição-ação”. Um Sistema Especialista é aquele que através de
informações reunidas em um banco de dados, por um especialista humano no assunto, ajuda a resolver
determinado problema.
Na área de Sistemas Especialistas tem-se os sistemas baseados em regras, no qual o
conhecimento é representado na forma de regras de produção. O raciocínio é modelado através de
encadeamento de regras. A associação empírica entre premissas e conclusões na base de conhecimento
é a sua principal característica. Sistemas baseados em regra não necessitam de um modelo de processo,
no entanto, eles exigem uma multiplicidade de regras para cobrir todas as falhas possíveis em um
sistema técnico e têm dificuldades com operações inesperadas ou novos equipamentos. Além disso, a
abordagem baseada em regras tem uma série de deficiências, como a falta de generalidade e
manipulação incorreta das situações novas, mas também oferece eficiência e eficácia na detecção de
falhas. Entre as principais limitações dos sistemas especialistas de diagnóstico precoce são
63
considerados a incapacidade de representar com precisão e variando espacialmente fenômenos
variando em tempo, a incapacidade do programa de aprender com os erros, bem como as dificuldades
para os engenheiros de conhecimento para adquirir o conhecimento de especialistas de forma confiável
(ANGELI, 2008).
O Quadro 3 mostra um exemplo de regras de produção.
Quadro 3. Exemplo de trecho de uma regra de produção
Regra 1
SE Trab_proj = Sim
E Utiliza_mod = Sim
E ModeloCV = Casc
E Todos_Cada = Todos os projetos
E Organizados = Fases/etapas
E Fases = Fase_01
ENTÃO Diag_01 = Result_Diag_01
A regra representada no Quadro 3 possui a seguinte estrutura de perguntas e respostas:
Pergunta: “A organização trabalha por projeto?”
Resposta: Sim
Pergunta: “Utiliza algum modelo de ciclo de vida?”
Resposta: Sim
Pergunta: “Qual modelo é utilizado?”
Resposta: Cascata
Pergunta: “Todos os projetos utilizam o modelo?”
Resposta: Todos os projetos
Pergunta: “Como os projetos são organizados?”
Resposta: Fases e etapas
“Quais são as fases do projeto?”
Resposta: (descrição das fases)
A arquitetura típica de um SE consiste de três componentes principais, que incluem a base de
conhecimento, o motor de inferência e a interface do usuário.
64
A base de conhecimento contém o conhecimento necessário para resolver um problema
específico. O conhecimento pode ser representado utilizando uma variedade de técnicas de
representações do conhecimento (por exemplo, redes semânticas, frames, lógica de predicados), mas a
técnica mais utilizada são as regras if - then, também conhecidas como regras de produção. Mecanismo
de inferências determina a ordem em que as inferências são feitas e, finalmente, a interface de usuário
que permite parte da comunicação entre o sistema e o usuário (METAXIOTIS; PARRAS, 2003).
O motor de inferência é um elemento essencial para a existência de um SE. Ele é considerado o
núcleo do sistema, uma vez que é por intermédio dele que os fatos, heurísticas e relações compõem a
base de conhecimento que são aplicados no processo de resolução do problema (IGNIZIO, 1991). O
motor de inferência aplica o conhecimento na solução de problemas reais, sendo um interpretador para
a base de conhecimento (MOREIRA, 2012).
O motor de inferência representa a forma de manipular o conhecimento já representado na base
de conhecimento, a fim de resolver o problema. Ele determina a ordem com que serão processadas as
informações, manipulando os dados a fim de inferir novos fatos, chegar a conclusões ou recomendar
ações (FIGUEIRA FILHO, 2000).
Portanto, motor de inferência representa o “cérebro” do sistema especialista, nele são realizadas
as operações necessárias para transformar os dados em informações relevantes. Para tal, utiliza-se do
conteúdo existente na base de conhecimento.
O motor de inferência é quem define o método de encadeamento das regras, ou seja, como elas
serão processadas. Segundo Oliveira (2001) o conjunto de várias inferências que ligam o problema
com a sua solução dá-se o nome de chaining ou encadeamento. O encadeamento que é percorrido
tendo como ponto de partida o problema e como alvo a solução é denominado de forward chaining ou
encadeamento progressivo. Ao contrário do encadeamento progressivo, quando um conjunto de
inferências que ligam o problema com a solução é percorrido a partir da hipótese até os fatos que a
suportam, este processo é denominado de backward chaining ou encadeamento regressivo (o processo
é o inverso do encadeamento progressivo).
A interface do usuário é responsável pela iteração do usuário com o sistema. Normalmente ela
é composta de interfaces de visualização e diagnóstico e pode também prover interfaces de
comunicação para ferramentas externas, como bancos de dados (SOUZA, 2013).
65
A Figura 15, representa a arquitetura do sistema especialista desenvolvida para este trabalho.
Figura 15. Arquitetura do sistema especialista
Fonte: Adaptado de Luger (2004).
Ferramentas de validação e verificação são softwares que combinam fatos e regras de modos
diversos, embutem uma máquina de inferência específica, assim como uma representação própria de
conhecimento, e permite a construção de sistemas especialistas que utilizem a sua representação de
conhecimento e máquina de inferência (MOURA; CRUZ, 2001).
66
3 ESTADO DA ARTE
Tendo como objetivo a proposta de uma abordagem de autodiagnostico para o levantamento
inicial do ciclo de vida e processos de desenvolvimento em organizações intensivas em software, esta
seção descreve abordagens encontradas através de pesquisas e estudos de caso. Deste modo, duas
revisões distintas foram realizadas: a primeira, um estudo para identificar abordagens de
autodiagnostico para o levantamento inicial do ciclo de vida através de uma busca informal e a
segunda, realizada de modo sistemático, que tem por enfoque a identificação destas abordagens em
fontes de pesquisa acadêmicas reconhecidas.
3.1 REVISÃO EXPLORATÓRIA
Considerando a dificuldade em encontrar trabalhos científicos que avaliam o ciclo de vida de
desenvolvimento, optou-se pela realização de um estudo de pesquisa informal com o objetivo de
identificar trabalhos que relatam a condução de avaliações do ciclo de vida de desenvolvimento de
software em organizações intensivas em software, como forma de melhoria de processo.
A pesquisa retornou resultados que ajudaram a construir uma base para o mapeamento
sistemático descrito na Seção 3.2, tipicamente, mais específico para responder as perguntas de
pesquisa.
Para o processo de revisão informal foi determinado o período de 2008 a 2014, para que
retornassem pesquisas atuais sobre o assunto e foram utilizadas as strings em inglês e português:
Software Process Improvement / Melhoria de Processo de Software
Assessment or Appraisal or Evaluation / Avaliação
Lifecycle or “Life cycle” / Ciclo de Vida
Tool / Ferramenta
A revisão informal foi realizada na ferramenta de busca Google Scholar
(http://scholar.google.com.br/). A seleção dos estudos analisou os primeiros 100 (cem) resultados
encontrados, considerando que o buscador prioriza os resultados mais relevantes. Desta forma, alguns
estudos isolados podem ter sido desconsiderados nesta revisão informal, mas espera-se que sejam
identificados num mapeamento sistemático posterior.
67
3.1.1 Trabalhos Relacionados
Os resultados da revisão informal forneceram parâmetros para fundamentar a abordagem
proposta neste trabalho. O Quadro 4 apresenta os trabalhos selecionados com a revisão informal.
Quadro 4. Trabalhos relacionados
Ano Título Referências
2010 A Web-based Tool for Automatizing the Software Process
Improvement Initiatives in Small Software Enterprises
García, I.; Pacheco, C.
2011 SPIALS: A Light-Weight Software Process Improvement Self-
Assessment Tool
Homchuenchom, D.;
Piyabunditkul, C.;
Lichter, H.; Anwar, T.
2012 Autodiagnostico de Processo de Software Baseado em
Sistema Especialista
Moreira, D.; Fernandes,
A. M. R.; Castro, F. S.;
Thiry, M.
2012 ReMo: A Recommendation Model For Software Process
Improvement
Sujin Choi; Dae-Kyoo
Kim; Sooyong Park
3.1.1.1 A WEB-BASED TOOL FOR AUTOMATIZING THE SOFTWARE PROCESS
IMPROVEMENT INITIATIVES IN SMALL SOFTWARE ENTERPRISES
Este artigo apresenta uma investigação sobre uma proposta que estabelece que uma pequena
organização pode usar uma ferramenta de software para avaliar e melhorar o seu processo de software,
identificação e implementação de um conjunto de práticas de gerenciamento de projetos ágeis, que
podem ser reforçadas usando o modelo CMMI-DEV como referência.
Metodologia de avaliação utilizada: Utiliza a ferramenta web para avaliação
SysProVal que tem como base o modelo IDEAL.
Descrição do processo de avaliação: SysProVal consiste de um mecanismo que
gerencia a melhoria de processo de software, pois compara as práticas atuais com as
práticas do CMMI-DEV adaptado para pequenas empresas, além de determinar os
processos selecionados, gerando um plano de melhoria apropriado e iterativo.
Tipo de organização/produto avaliados: Pequenas empresas de software.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): A pesquisa
mostrou que a ferramenta SysProVal facilita a implementação do CMMI-DEV através
68
das três fases iniciais do modelo IDEAL. O SysProVal apresenta boa cobertura dessas
fases a nível de projeto. O mecanismo de avaliação SysProVal provou ser uma
ferramenta de diagnóstico conveniente e útil para pequenos ambientes. O SysProVal
apresentou boa cobertura no nível "pesquisa e aperfeiçoamento".
Ciclo de vida: A proposta desta pesquisa não está em mapear o ciclo de vida da
organização, mas sim, apresentar uma ferramenta web para avaliação de processos que
gera um plano de melhorias.
3.1.1.2 SPIALS: A LIGHT-WEIGHT SOFTWARE PROCESS IMPROVEMENT SELF-
ASSESSMENT TOOL
Este trabalho, propõe uma abordagem baseada na ferramenta chamada CMMIbySCRUM para
melhorar os processos baseados no CMMI. Para apoiar as organizações no seu caminho para melhores
processos, é apresentado o projeto de uma ferramenta genérica (SPIALS: Software Process
Improvement Adaptive Learning System) aplicável para medir o status de capacidade de processo das
organizações. Microempresas podem utilizar a ferramenta para realizar uma auto avaliação, reduzindo
assim o processo de avaliação complexo. A estratégia de avaliação da ferramenta apresentada é
baseada no SCAMPI, que é reconhecido para avaliação CMMI.
Metodologia de avaliação utilizada: A metodologia SPIALS de auto avaliação,
propõe uma abordagem baseada na ferramenta CMMIbySCRUM. A SPIALS utiliza
questionários que devem ser preenchidos pelos representantes da organização. Estes
questionários são gerados com base em informações da organização. Todos os
questionários em conformidade com um modelo subjacente comum. É necessário
introduzir a entrada de dados por um representante da organização que define
evidências para processos de desenvolvimento de software. O resultado é apresentado
automaticamente indicando aceitação nas áreas dos processos selecionados.
Descrição do processo de avaliação: SPIALS auxilia pequenas e médias empresas a
realizar auto avaliações. Seu procedimento é consistente com os princípios do SCAMPI
incluindo as três fases; Planejar e preparar para Avaliação, Conduta de Avaliação e
relatório de resultados.
69
Tipo de organização/produto avaliados: A metodologia SPIALS é útil para pequenas
e médias empresas.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Não houve a
realização de diagnóstico.
Ciclo de vida: O ciclo de vida não é analisado nesta pesquisa, o propósito dela é
contribuir com uma abordagem para a realização de auto avaliação através de
questionários. Compõe a abordagem fases de avaliação que são sugeridas na melhoria
de processo de software.
70
3.1.1.3 AUTODIAGNOSTICO DE PROCESSO DE SOFTWARE BASEADO EM SISTEMA
ESPECIALISTA
Este trabalho propõe o desenvolvimento de uma abordagem de autodiagnostico utilizando
Sistemas Especialistas, apoiado por uma ferramenta computacional para web. Os resultados
apresentados na avaliação desta abordagem indicam que a utilização do SE permite mapear os pontos
fortes e fracos do processo de uma organização, contribuindo como uma nova sistemática de avaliação
na área de melhoria de processos de software.
Metodologia de avaliação utilizada: Abordagem de autodiagnostico utilizando
Sistemas Especialistas (SE) apoiado por uma ferramenta computacional para web. A
avaliação é realizada com base no nível G do MPS.BR.
Descrição do processo de avaliação: Entrada dos dados vem através de um
questionário de fatores organizacionais, questionário de caracterização da empresa e
entrevistas. A análise é feita através da análise dos questionários e das respostas das
entrevistas realizada com especialistas em melhoria de processo. A saída é o
diagnóstico do processo de software apresentando pontos fortes e pontos fracos.
Tipo de organização/produto avaliados: Foram avaliadas quatro (4) organizações.
Das quais duas (2) são do setor privado e duas (2) são do setor do público.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): 45, 75% das
avaliações foram consideradas totalmente de acordo com o diagnóstico apresentado pela
ferramenta e 25% delas parcialmente de acordo. O percentual de respostas do
especialista em relação aos critérios avaliados na abordagem é de 82% das respostas do
especialista estão de acordo com a abordagem proposta.
Ciclo de vida: O propósito não foi analisar o ciclo de vida da organização e sim
modelar o conhecimento referente aos resultados esperados do nível G do MPS.BR em
organizações desenvolvedoras de software, através de entrevistas.
71
3.1.1.4 REMO: A RECOMMENDATION MODEL FOR SOFTWARE PROCESS
IMPROVEMENT
Este trabalho apresenta um método sistemático para o desenvolvimento de recomendações
baseadas em um modelo de referência, como CMMI. O método apresentado é avaliado utilizando
dados de avaliações reais da indústria e os resultados mostram o potencial do método.
Metodologia de avaliação utilizada: A avaliação do modelo é realizada por um
consultor de processo com 17 anos de experiência no setor e engenheiros de processo
com uma experiência de 2 anos na indústria, ambos envolvidos na avaliação de
processos e consultoria de empresas.
Descrição do processo de avaliação: A análise dos resultados tem como foco a
avaliação do processo e a visão de 4 correlações: Visão do modelo de avaliação, Visão
com foco nos negócios, visão organizacional e visão do ciclo de vida do software.
Tipo de organização/produto avaliados: Avaliou-se o modelo apresentado, utilizando
dados reais de avaliação recolhidos de três empresas, incluindo uma grande empresa de
desenvolvimento de aplicativos corporativos e duas pequenas e médias empresas o
desenvolvimento de aplicações multimídia.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): O modelo
considera vários aspectos de recomendações de profundidade. As recomendações
resultantes do modelo são eficazes no planejamento de ações de melhoria em
comparação com a prática tradicional. Este modelo pode ser utilizado como um modelo
de referência para a análise de planos de ação. A análise de resultados é não-trivial,
devido à subjetividade em estabelecer correlações e pode ser difícil para os engenheiros
novatos pôr em prática.
Ciclo de vida: O presente trabalho não mapeou o ciclo de vida das organizações
avaliadas, mas contribuiu para a pesquisa com informações sobre o modelo de processo
para desenvolvimento de recomendações para melhoria de processo de software –
REMO.
72
3.1.2 Análise dos Trabalhos Relacionados
Os resultados retornados com a revisão informal trouxeram trabalhos que contribuíram para
esta pesquisa, descrevendo abordagens para avaliação de melhoria de processo de software, ferramenta
para auto avaliação e material sobre métodos de diagnósticos. Apesar dos trabalhos não relatarem
alguma pesquisa relacionada ao ciclo de vida das organizações avaliadas/entrevistadas, o método de
avaliação ou diagnóstico realizado nas mesmas, foi analisado com o objetivo de contribuir na
composição da metodologia de entrevistas utilizada nesta pesquisa.
O trabalho de Moreira (2012) teve sua importância no que diz respeito as informações contidas
nas árvores de decisão, que serviram para complementar as questões desenvolvidas para as árvores de
decisão do presente estudo. Considerou-se também, a proposta de autodiagnostico idealizada por
Moreira (2012), como contribuição para a construção da abordagem desta pesquisa.
Por fim, pode-se dizer que o retorno dos trabalhos da revisão informal, teve sua importância
para o desenvolvimento da abordagem deste trabalho, que considerou as avaliações, ferramentas e
metodologias, encontradas nesta revisão.
3.2 MAPEAMENTO SISTEMÁTICO
Tendo como objetivo a proposta de uma abordagem para um modelo de autodiagnostico para o
levantamento inicial do ciclo de vida e processo de desenvolvimento em organizações intensivas em
software, esta seção descreve trabalhos encontrados através do mapeamento sistemático. Deste modo,
o mesmo foi realizado com foco na identificação de formas de avaliação de melhoria de processo de
software e no levantamento de trabalhos que utilizam métodos de diagnóstico de processos. Sendo
assim, o mapeamento apresenta estudos sobre os temas abordados.
Um mapeamento sistemático provê uma visão geral sobre a área de interesse identificando a
quantidade de pesquisas, seus diferentes tipos e respectivos resultados, diferenciando-se da revisão
sistemática em questão de profundidade e abrangência da pesquisa (PETERSEN et al., 2008).
Petersen et al. (2008), com fundamentos em Kitchenham e Charters (2007), compara o
mapeamento sistemático com a revisão sistemática, mostrando que os dois possuem objetivos
diferentes e que em parte podem se contradizer. Petersen et al. (2008) diz que o mapeamento
sistemático deveria ser utilizado como uma primeira etapa para a revisão sistemática, entretanto, ele
73
afirma que sozinho o mapeamento já tem o seu valor, ajudando a identificar possíveis lacunas de
pesquisas de uma determinada área e fornecer potenciais carências em avaliações e validações em
áreas com pouco estudo.
3.2.1 Objetivo Principal
Este mapeamento sistemático tem por objetivo principal mapear pesquisas focadas no
mapeamento inicial do ciclo de vida adotado por organizações intensivas em software através de
diagnósticos de processos.
3.2.2 Protocolo de Busca
O protocolo de busca foi elaborado com base na estrutura proposta por Kitchenham e Charters
(2007), uma vez que esta abordagem foi adaptada para estudos em Engenharia de Software.
3.2.3 Questões de Pesquisa
Um dos objetivos deste mapeamento sistemático foi mapear técnicas ou métodos de
diagnósticos que identificam ciclos de vida de desenvolvimento adotados por organizações intensivas
em software. Outro objetivo foi mapear modelos de avaliação utilizados para a identificação de ciclos
de vida adotados por estas organizações desenvolvedoras de software. Para a elaboração das perguntas
de pesquisa, foi adotada a estrutura PICOC4 com a definição dos seguintes elementos: população,
intervenção, comparação, resultados e contexto. Os Quadros 5 e 6 apresentam as duas questões de
pesquisa relacionadas com a estrutura PICOC.
Quadro 5. PICOC para a primeira pergunta.
1. O ciclo de vida mapeado através do diagnóstico é realmente aquele adotado pela
organização desenvolvedora de software?
População Organizações desenvolvedoras de software;
Intervenção Reunir informações das organizações desenvolvedoras de software e aplicar um
método de levantamento do ciclo de vida da mesma;
4 Em inglês: Population, Intervention, Comparison, Outcames and Context.
74
Comparação Comparar os diferentes tipos de ciclos de vida que são adotados pelos diferentes
tipos de organizações com aqueles ciclos de vida identificados pela literatura;
Resultados Mapeamento do ciclo de vida da organização com foco no levantamento do tipo de
ciclo de vida e suas características, características da organização, dos projetos,
dos produtos, dos clientes;
Contexto No contexto deste trabalho está o levantamento das organizações, características, o
porte e população.
Quadro 6. PICOC para a segunda pergunta.
2. Quais os principais trabalhos que envolvem a identificação dos diferentes tipos de ciclo de
vida adotados pelas diferentes organizações desenvolvedoras de software, comparados
àqueles identificados na literatura?
População Organizações desenvolvedoras de software;
Intervenção Reunir informações de trabalhos que mapeiam um ciclo de vida;
Comparação Aplicar um método de mapeamento do ciclo de vida da organização e comparar o
resultado aos ciclos de vida identificados na literatura;
Resultados Verificação do tipo de ciclo de vida que a organização está utilizando;
Contexto No contexto deste trabalho está o levantamento dos tipos de ciclo de vida.
3.2.4 Fontes de Dados
Esta seção descreve onde e como foram realizadas as buscas, bem como as palavras-chave que
geraram a String de busca para os resultados selecionados.
O fato dessas fontes de dados oferecerem acesso a publicações significativas na área de
engenharia de software contribuiu para suas escolhas. Na Tabela 1 podem ser visualizadas as fontes
escolhidas.
Tabela 1. Fonte de Dados
Nome da fonte Link de acesso
IEEExplore http://ieeexplore.ieee.org
ScienceDirect
http://www.sciencedirect.com
ACM Digital library http://portal.acm.org
SpringerLink http://www.springerlink.com
Google Scholar http://scholar.google.com.br
75
3.2.5 Palavras Chave
As palavras chave foram definidas levando em consideração que todas elas fazem combinações
que podem listar trabalhos relacionados ao ciclo de vida de desenvolvimento de software.
Lifecycle
Software development
Method, Methodology, Methodologies
Diagnostic, Diagnosis
Assessment
Appraisal
Evaluation
Process Modeling
Modeling
76
3.2.6 String de Busca
A string definida foi adotada como referência para a busca em todas as fontes de dados
planejadas. Entretanto, como existem diferenças nos motores de busca de cada fonte de dados, houve a
necessidade de realizar adaptações na estrutura da string de busca para cada fonte. O objetivo desta
adaptação foi garantir que o objetivo da pesquisa fosse alcançado, evitando a perda de
documento/artigos científicos relevantes. As strings definidas em cada fonte de dados, são
apresentadas no Apêndice A.
A seguir tem-se a string de busca definida:
(lifecycle OR life cycle OR life-cycle) AND (software development) AND (method OR
methodology OR methodologies OR diagnostic OR diagnosis OR Assessment OR
Appraisal OR Evaluation OR Process OR Modeling)
3.2.7 Critérios de Inclusão e Exclusão
Nos critérios de inclusão os termos utilizados tiveram como objetivo identificar estudos sobre o
processo de desenvolvimento de software, de forma a identificar os tipos de ciclos de vida de
diferentes tipos de organizações, bem como analisar formas de diagnósticos para a identificação desses
ciclos de vida.
Para que o processo de seleção pudesse ter sucesso, foi de grande importância o uso dos
critérios de inclusão e exclusão.
Os critérios de inclusão são os seguintes:
Pesquisas que apontem tipos de ciclos de vida do processo de desenvolvimento do
software analisado;
Pesquisas que apresentem formas de diagnóstico ou autodiagnostico de processos de
desenvolvimento de software;
Pesquisas que apresentem as características das organizações, dos produtos, dos projetos,
dos clientes e dos ciclos de vida;
77
Pesquisas que comparam os ciclos de vida de desenvolvimento identificados no
diagnóstico com os ciclos de vida que são tratados na literatura;
Artigos científicos, publicados em fontes de dados que sejam bem conceituadas na
comunidade científicas;
Os artigos devem possuir em seu resumo ou título pelo menos uma das palavras usadas na
string de busca;
Artigos escritos na língua inglesa, preferencialmente;
Artigos no formato .pdf;
Artigos científicos publicados a partir de 01/2008 e
Somente os 100 primeiros títulos retornados de cada base de dados.
Os critérios de exclusão são os seguintes:
Artigos publicados antes de 01/2008;
Artigos que não estiverem entre os primeiros 100 títulos retornados de cada base de dados;
Artigos que não possuam em seu título ou resumo, pelo menos uma das palavras da string
de busca;
Artigos que não contenham informações sobre ciclo de vida de desenvolvimento de
software ou informações sobre avaliação do ciclo de vida e
Artigos que contenham informações sobre gerenciamento de projetos.
3.2.8 Extração dos Dados
Para cada uma das publicações aprovadas no processo de seleção, os seguintes dados devem ser
extraídos:
Título e Autor(es), o título será o primeiro a ser analisado, levando em conta que nele deve
haver pelo menos uma referência ligada a ciclo de vida ou diagnóstico, avaliação ou
78
processo de desenvolvimento de software. Juntamente ao título o nome dos autores se faz
necessário para obter a origem/nacionalidade da pesquisa em questão;
Data de publicação, a data da publicação deve ser maior ou igual a 01/2008, quanto mais
recente a publicação melhores informações se terá em relação a pesquisa dos ciclos de vida
de desenvolvimento;
Referências, são relevantes pelo fato delas mencionarem outras pesquisas relacionadas ao
tema em questão;
Resumo da publicação, nele deve conter informações pertinentes ao processo de
desenvolvimento de software, bem como avaliações e diagnóstico do processo,
organizações pesquisadas e características das mesmas;
Descrição da abordagem, técnica e/ou processo proposto, com essas informações pode-se
fazer uma análise comparativa entre pesquisa e o estudo que será realizado;
Levantamento da metodologia utilizada para desenvolvimento de software, a extração
dessa informação também servirá de análise comparativa para o estudo que será realizado;
Tipos de ciclo de vida e as características dos mesmos, estas informações servirão de base
para a elaboração do o questionário para o diagnóstico de processos e
Perfil dos clientes e/ou organizações estudadas, essa informação indicará os tipos de
organizações que estão utilizando diagnóstico para melhoria de processos.
O critério para a seleção dos estudos é apresentar no mínimo uma seção sobre a metodologia
utilizada para diagnóstico do processo. Os resultados da extração dos dados encontram-se no Apêndice
A desta dissertação.
3.2.9 Análise dos Trabalhos Selecionados
Este capítulo apresenta algumas considerações a respeito da sistematização do mapeamento
realizado, assim como as evidências que respondem a cada uma das questões de pesquisa que guiaram
o estudo.
79
Como resultado deste estudo, foram analisadas as strings de buscas utilizadas no trabalho de
Moreira (2012) e dos artigos retornados através de uma string de busca definida para esta pesquisa.
Estes artigos abordam ferramentas para avaliação do processo, descrição de etapas evolutivas para
desenvolvimento de sistema de avaliação, micro avaliação utilizando questionários, avaliações em
organizações de pequeno e médio porte e questionários de avaliação.
O quadro com os trabalhos selecionados e suas referências encontram-se no Apêndice A.
A seguir são apresentadas as considerações de cada trabalho utilizado para esta pesquisa.
3.2.9.1 INITIATING SOFTWARE PROCESS IMPROVEMENT IN SMALL ENTERPRISES:
EXPERIMENT WITH MICRO-EVALUATION FRAMEWORK.
Metodologia de avaliação utilizada: A abordagem é gradual, e com base numa
estrutura de três fases de melhoria do processo de software. Na primeira fase, um
questionário simplificado, chamado de Micro Avaliação é usado para coletar
informações sobre as práticas atuais de software. A segunda Micro Avaliação poderia
ser realizada alguns meses mais tarde para avaliar os progressos realizados. As
informações coletadas e as conclusões retiradas, como resultado da análise também
pode ajudar a determinar o escopo e os objetivos de uma avaliação mais precisa, que
será realizada de acordo com o modelo OWPL (Observatoire des Wallon Pratiques
Logicielles5). Na segunda etapa, o componente central da metodologia, o modelo
OWPL, é aplicado. O modelo OWPL permite microempresas realizarem uma avaliação
proporcionando uma visão ampla e completa de seus processos de software. Ele foi
desenvolvido com base no conhecimento do público-alvo através da realização de um
grande número de micro avaliações e com foco nas metas da abordagem. Como micro
avaliação, a avaliação OWPL pode ser realizada várias vezes para medir a melhoria, e
poder servir como um ponto de entrada para o passo seguinte e final do método, a fase
3. Eventualmente, quando o tamanho ou no contexto de uma empresa justifica a
necessidade de marcação padrão e quando a empresa atinge um nível de qualidade
suficientemente elevada, uma avaliação SPICE ou CMM pode ser realizada.
5 Valónia Observatório de Práticas de Software
80
Descrição do processo de avaliação: A micro avaliação usa uma entrevista com base
em um questionário que abrange seis eixos como os mais pertinentes e mais importantes
para as organizações. Estes eixos são: Gestão da qualidade, Gestão de clientes, Gestão
subcontratado, Desenvolvimento e gerenciamento de projetos, Gestão de produtos e
Formação e Gestão de recursos humanos. Os entrevistados devem ter conhecimento
suficiente sobre as atividades de TI da organização. O questionário cobre os 6 eixos
listados acima. As perguntas são abertas, e cada um deles está associado a uma ou mais
sub-perguntas, permitindo que o entrevistador possa ajustar e refinar a informação como
for necessário. Existem dois tipos de questões: as que abordam práticas essenciais
relacionadas com a organização e que são classificados numa escala linear de acordo
com a qualidade da prática avaliada e as práticas que são de acordo com a qualidade da
prática e de sua efetiva implementação na organização, isto é, algumas práticas podem
estar presentes, mas usadas apenas em alguns projetos e não sistematicamente para
todos os projetos.
Tipo de organização/produto avaliados: 1ª amostra com 20 organizações, entre
empresas de TI e empresas prestadoras de serviços de TI. 2ª amostra com 7
organizações, dentre os tipos citados.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): A
experiência mostrou que a micro avaliação é muito atraente como uma ferramenta
inicial, principalmente por causa de sua simplicidade, e também porque ajuda a chamar
a atenção das pessoas para o problema da qualidade no campo da engenharia de
software. Além disso, ela pode ajudar na elaboração de uma lista de recomendações
para orientar as empresas de pequeno porte nos primeiros passos de melhoria. Para as
pequenas empresas que procuram um modelo mais exaustivo, o modelo OWPL deve ser
a resposta adequada, uma vez que foi desenvolvido tendo o CMM e o SPICE como
referências, por um lado e especificidades das pequenas empresas, que são destacadas
graças a micro avaliação.
Ciclo de vida: O propósito da pesquisa não está em avaliar ou identificar um ciclo de
vida. O objetivo desta pesquisa foi sugerir uma abordagem para avaliações com base em
81
entrevistas que permita pequenas empresas obterem uma visão completa de seus
processos de desenvolvimento de software.
3.2.9.2 ASSESSING – LEARNING – IMPROVING AN INTEGRATED APPROACH FOR
SELF ASSESSMENT AND PROCESS IMPROVEMENT SYSTEMS
Metodologia de avaliação utilizada: Um ambiente que fornece serviços de status de
avaliação, de aprendizagem e de melhoria contínua com base em diferentes padrões e
abordagens. Esta abordagem já está sendo implementada para a área de gerenciamento
de projetos.
Descrição do processo de avaliação: No período de 2004 a 2010, o trabalho realizado
e planejado pode ser dividido em 5 etapas evolutivas: (1) Desenvolver um sistema de
avaliação; (2) Assegurar a melhoria do conhecimento por wikis6; (3) Estruturar o
conhecimento em ontologias; (4) Definir estruturas de informação e (5) Construir um
sistema de conhecimento do usuário focado em informações sobre a avaliação.
Tipo de organização/produto avaliados: Organizações de desenvolvimento de
software.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Estudos no
campo do gerenciamento de projetos em relação à redução do esforço usando este
sistema mostrou: 24% de redução do esforço através da realização da avaliação CMMI
e em paralelo a ISO 15504, 39% de redução do esforço através da realização de uma
avaliação CMMI em uma organização já certificada ISO 9001:2000, 45% de redução do
esforço através da realização da ISO 15504, avaliação CMMI e avaliação ISO 90003
em paralelo, em uma organização já certificada na ISO 9001:2000.
Ciclo de vida: A pesquisa propõe uma abordagem que combine ferramentas de
avaliação, plataformas de conhecimento baseados em wiki e sistemas especialistas de
auto aprendizagem. Não tem por foco o mapeamento ou avaliação do ciclo de vida de
6 A ideia central do sistema Wiki é que qualquer texto original possa ser alterado, de modo que novos conhecimentos sejam
incorporados aos já existentes.
82
organizações desenvolvedoras de software. Seu foco está em gerir conhecimento para
reduzir o esforço em iniciativas de avaliações MPS.
3.2.9.3 A QUESTIONNAIRE BASED METHOD FOR CMMI LEVEL 2 MATURITY
ASSESSMENT
Metodologia de avaliação utilizada: Um conjunto de questões foram desenvolvidas
com o propósito relativamente fácil e de uma forma mais ou menos confiável de se
indicar se uma empresa atende aos requisitos do CMMI nível de maturidade 2.
Descrição do processo de avaliação: O questionário foi aplicado em cinco empresas
de software. Uma pessoa responsável foi identificada para responder as questões
colocadas. As entrevistas geralmente levavam cerca de 1 hora e meia. Estas empresas
alegaram terem adotado uma abordagem de processo para obtenção de qualidade,
alguns muito recentemente, alguns por mais tempo. As respostas de cada empresa para
as perguntas em uma área de processo foram calculados.
Tipo de organização/produto avaliados: 5 organizações de software da Turquia.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Os
resultados mostram que o método pode ser utilizado para os fins declarados. Um limite
pode ser colocado em uma pontuação de cerca de 80% para indicar êxito. O método não
se preocupa em absoluto com níveis mais elevados. No entanto, uma pontuação de 80
ou mais, indica ter alcançado o nível de maturidade 2. Os resultados também reforçaram
a crença de que o tamanho de uma empresa de software é um fator importante na sua
capacidade de alcançar níveis mais elevados na escada de maturidade do CMMI.
Ciclo de vida: O propósito desta pesquisa foi desenvolver um questionário para
verificar se organizações de desenvolvimento de software atendem aos requisitos do
CMMI nível 2.
83
3.2.9.4 USING SCRUM TO GUIDE THE EXECUTION OF SOFTWARE PROCESS
IMPROVEMENT IN SMALL ORGANIZATIONS
Metodologia de avaliação utilizada: O objetivo deste artigo é apresentar o processo
PfemCOMPETISOFT, que utiliza o framework de melhoria COMPETISOFT. O
PfemCOMPETISOFT é usado para orientar a incorporação em seus processos e das
oportunidades de melhoria que possam ser descobertas na atividade de diagnóstico.
Descrição do processo de avaliação: O processo utiliza o Scrum.
Tipo de organização/produto avaliados: 2 organizações de pequeno porte. Empresa 1:
Desenvolvimento de portais organizacionais, soluções de e-commerce, sistemas de
informação geográfica e software de suporte para os centros de educação. Empresa 2:
Organização acadêmica que combina atividades de pesquisa e desenvolvimento com
projetos de desenvolvimento de software para outras organizações.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Empresa 1:
Ficou satisfeita com o resultado do ciclo de melhoria, já que ter um processo visível e
explicitamente definido para o desenvolvimento de software e gerenciamento de
projetos permitiu a empresa atender a demanda de mais clientes, e para aumentar a
equipe. A Empresa 1 particularmente apreciou a abordagem de trabalhar com pequenos
passos de melhoria com uma recompensa tangível de curto prazo. O programa
estabeleceu a base para a melhoria do processo, e a Empresa 1 está melhorando seus
processos para ser compatível ao CMMI nível 2. Quanto a Empresa 2, o ciclo de
melhoria permitiu a esta organização ter uma melhor percepção e controle sobre o
desenvolvimento de software e processos de gerenciamento de projeto. Tal como no
caso da Empresa 1, a organização apreciou a abordagem de trabalhar com pequenos
passos de melhoria.
Ciclo de vida: A pesquisa não tem por objetivo identificar o ciclo de vida de uma
organização desenvolvedora de software. O principal objetivo desta pesquisa está em
propor às organizações uma abordagem que possa orientar oportunidades de melhorias
através de relatórios de diagnóstico.
84
3.2.9.5 ASSESSMENT METHODOLOGY FOR SOFTWARE PROCESS IMPROVEMENT
IN SMALL ORGANIZATION
Metodologia de avaliação utilizada: Metodologia de avaliação
METvalCOMPETISOFT
Descrição do processo de avaliação: Esta metodologia: (i) incorpora a estratégia de
avaliações internas conhecidas como avaliação rápida, o que significa que estas
avaliações não ocupam muito tempo ou utilizam uma quantidade excessiva de recursos,
nem são muito rigorosas e (ii) atende a todos os requisitos descritos na literatura para
uma proposta de avaliação que é personalizada para as características típicas de
pequenas empresas. Esta metodologia inclui: (i) Um processo para avaliação de
processos de software, PvalCOMPETISOFT, para ajudar a diagnosticar o processo de
software passo a passo. (ii) Um modelo de avaliação para a determinar da capacidade de
processos de uma organização de software pequena e (iii) Uma ferramenta de apoio ao
processo de avaliação.
Tipo de organização/produto avaliados: 8 Organizações (Desenvolvimento Web,
Desenvolvimento customizado, Desenvolvimento para organizações públicas, Sistemas
integrados de gestão de serviços, Software para gerenciar e controlar o sistema de
gestão da qualidade ISO 9001-2000, Software para telefonia móvel e dispositivos
portáteis, Software para apoiar os processos de gestão do conhecimento organizacional,
Software para gestão financeira, sistemas de automação e logística).
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Os
resultados obtidos a partir dos estudos de caso mostram que esta metodologia é
aplicável a pequenas organizações. A metodologia de avaliação proposta estabelece os
elementos necessários para ajudar a diagnosticar o processo em pequenas organizações,
enquanto procuram fazer a sua aplicação economicamente viável em termos de recursos
e tempo. A partir da aplicação inicial nas oito organizações e tendo em conta o esforço
envolvido, o conhecimento de processos, a melhoria do processo realizado com base
neste conhecimento e os benefícios descritos pelas empresas, pode ser visto que o
método de avaliação proposto é útil, prático e apropriado para diagnóstico de processos
em pequenas empresas. Além disso, os resultados de sua aplicação em EThree mostram
85
que a metodologia de avaliação proposta também pode ser adequada a organizações de
médio porte. Com a informação gerada pela metodologia de avaliação e com o plano de
avaliação preliminar, seis ciclos de melhoria foram realizados e concluídos em seis
organizações, que lhes permitiu aumentar o nível de capacidade dos processos
avaliados.
Ciclo de vida: O levantamento do ciclo de vida, foi mapeado através da metodologia
METvalCOMPETISOFT, a mesma buscou apresentar uma metodologia de avaliação
para organizações de desenvolvimento de software, de forma rápida e simples.
3.2.9.6 SURVEYING AND EVALUATING TOOLS FOR MANAGING PROCESSES FOR
SOFTWARE-INTENSIVE SYSTEMS
Metodologia de avaliação utilizada: Para capturar o processo existente, uma série de
entrevistas foram realizadas com as equipes de desenvolvimento e integradores do
processo. Um critério de avaliação, com base nos quadros de requisitos de Kellner, foi
considerado para avaliar aspectos de modelagem de processos das ferramentas. Todas
as entrevistas foram realizadas utilizando o mesmo questionário. O questionário foi
dividido em sete seções relacionadas com a organização, planejamento do projeto,
projeto de arquitetura e design, transferência do desenvolvimento para a integração,
integração, testes e também algumas questões gerais.
Descrição do processo de avaliação: Com os dados coletados nas entrevistas, foram
identificados elementos de processo básicos, tais como papéis, atividades e produtos de
trabalho.
Tipo de organização/produto avaliados: Organização de desenvolvimento de
software. Software aplicativo de automação de processos.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Não
demonstra um quadro de resultados de avaliação.
Ciclo de vida: O resultado da organização avaliada demonstrou que a mesma usa uma
combinação de modelo cascata e metodologias de processos ágeis para o
desenvolvimento de seus produtos.
86
3.2.9.7 USING THE SOFTWARE PROCESS IMPROVEMENT APPROACH FOR
DEFINING A METHODOLOGY FOR EMBEDDED SYSTEMS DEVELOPMENT
USING
Metodologia de avaliação utilizada: Metodologia SPIES.
Descrição do processo de avaliação: SPIES é organizado por fases que são compostas
por atividades mais específicas. A abordagem iterativa de SPIES assegura que o
processo de desenvolvimento deve ser testado, em cada fase, e não no fim do projeto.
Essa metodologia utiliza um repositório de artefatos (ou repositório de ativos) para
introduzir a melhoria de processos em cada fase. Este repositório contém modelos para
cada atividade (produtos), diretrizes para executar atividades e atribuições de papéis. Da
mesma forma que o CMMI-DEV v1.2, SPIES recomenda para cada atividade (quanto
possível) o uso de uma ferramenta específica para o planejamento do projeto, estimativa
e processo de trabalho, a modelagem de requisitos, validação do sistema, entre outros.
Tipo de organização/produto avaliados: Organização desenvolvedora de sistemas
embarcados.
Resultado obtido com o diagnóstico/avaliação: Para testar a metodologia SPIES e
avaliar a aplicabilidade, foi implementado com sucesso um protótipo de sistema de
semáforos, em uma universidade. Uma das desvantagens observadas, na SPIES, está
relacionada com o conhecimento anterior. Um repositório de conhecimento pode
resolver este problema, através do feedback dos usuários.
Ciclo de vida: O ciclo de vida de desenvolvimento do sistema de semáforos não foi
mapeado mas a metodologia SPIES possui as seguintes fases do processo: Planejamento
de projeto, Especificação de requisitos, Design de produto, Desenvolvimento de
produto, Integração do produto, Validação do produto, Entrega e manutenção do
produto e Melhoria contínua do produto.
- Características do ciclo de vida/processo da organização: O sistema de semáforo foi
projetado para ser usado dentro do campus da universidade e inclui três componentes: o
componente de sensor para detecção de veículos e pedestres, um visor do painel frontal
(FPD) para configurar automaticamente o sistema e o componente interno para
gerenciar o tráfego. É importante dizer que, trata-se de um ambiente universitário, não
87
há o tipo de tráfego, como uma rua comum. O componente de gestão do tráfego inclui
cinco modos: modo seguro, interseção noite modo de baixo volume, modo de ciclo de
resposta, o modo de tempo de ciclo fixo e modo adaptativo. O sensor pode detectar
veículos (prioridade de veículos e de veículos de emergência) e pedestres.
- Ciclo de vida comparado a literatura: O ciclo de vida do SPIES pode ser comparado ao
modelo iterativo.
3.2.9.8 SOFTWARE PROCESS IMPROVEMENT THROUGH THE LEAN
MEASUREMENT (SPI-LEAM) METHOD
Metodologia de avaliação utilizada: Método Lean. O método permite a avaliação do
desempenho do processo de desenvolvimento e toma ações contínuas para se chegar a
um processo de software mais enxuto ao longo do tempo. O método combina o
paradigma de melhoria da qualidade com método Lean. O método baseia-se na medição
de inventários que representam diferentes dimensões do desenvolvimento de software
(desenvolvimento normal, trabalho, trabalho extra e qualidade de software).
Descrição do processo de avaliação: O método se baseia no fundamentos do QIP
(Quality Improvement Paradigm). E consiste nas etapas: (1) caracterizar o projeto atual,
(2) definir metas quantificáveis e medições, (3) escolher modelos e métodos de
processo, (4) executar processos e coletar e validar os dados coletados, (5) analisar os
dados coletados e recomendar melhorias, e (6) do pacote e armazenar experiências
feitas.
Tipo de organização/produto avaliados: Não houve uma organização para ser
avaliada. O método foi avaliado sob o ponto de vista de 2 representantes da Ericsson
AB, na Suécia, responsáveis pela melhoria de processos de software na empresa.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): O Lean é
flexível, pois permite que as empresas escolham os inventários e métodos de análise
ajustando as suas necessidades da melhor forma. Assim, o método poderá ser aplicável
em vários contextos. Os praticantes que refletiram sobre o método e concordaram em
relação a como há proximidade do problema. Eles, por exemplo, observaram que os
inventários estavam abaixo do nível de capacidade. Além disso, eles concordaram com
88
a necessidade de realizar uma análise combinada de inventários para ter uma visão
completa da situação atual. Ou seja, o risco de medidas de otimização é drasticamente
reduzido.
Ciclo de vida: A pesquisa propõe um método que permite a avaliação do desempenho
do processo de desenvolvimento de organizações desenvolvedoras de software e a partir
desta avaliação é possível tomar ações de melhoria para se atingir um processo de
desenvolvimento mais enxuto.
3.2.9.9 AN APPLICATION TOOL TO SUPPORT THE IMPLEMENTATION OF
INTEGRATED SOFTWARE PROCESS IMPROVEMENT FOR MALAYSIA'S SME
Metodologia de avaliação utilizada: A pesquisa propõe uma ferramenta de auxílio as
implementações de melhoria de processo de software em organizações de pequeno
porte na Malásia. A proposta ferramental contém os módulos de coleta de dados para o
processo/projeto, Gap Analisys7, Avaliação de capacidades, Plano de melhorias e um
Gerador de relatórios.
Descrição do processo de avaliação: A ferramenta possui uma camada de dados que
está relacionada com a base de conhecimento (Estudos de caso e Normas) e o usuário
fornece uma entrada de dados através de auto avaliação.
Tipo de organização/produto avaliados: Ferramenta desenvolvida para auxiliar a
melhoria de processo em pequenas organizações da Malásia.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Não
apresenta resultados da ferramenta aplicada em organizações.
Ciclo de vida: A proposta desta pesquisa não está em avaliar ou identificar um ciclo de
vida, mas sim em propor uma ferramenta que gere relatórios que possam ser utilizados
como plano de melhoria em processos.
7 Comparativo de desempenho operacional atual com o melhor desempenho possível.
89
3.2.9.10 SOFTWARE PROCESS IMPROVEMENT SUCCESS FACTORS FOR SMALL AND
MEDIUM WEB COMPANIES: A QUALITATIVE STUDY
Metodologia de avaliação utilizada: Pesquisa qualitativa, através dos princípios da
grounded theory (teoria fundamentada).
Descrição do processo de avaliação: A pesquisa foi realizada através de entrevista
com 21 profissionais paquistaneses de 11 pequenas e médias empresas de
desenvolvimento web.
Tipo de organização/produto avaliados: Organizações desenvolvedoras de aplicações
web.
Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): As quatro
principais contribuições deste estudo foram: (1) Criação de um quadro exploratório dos
fatores de sucesso da melhoria de processo de software para pequenas e médias
empresas de aplicativos web; (2) Apresenta o ponto de vista da melhoria de processo
para pequenas e médias empresas de aplicativos web a partir da perspectiva dos
praticantes; (3) Faz uma contribuição metodológica, demonstrando como técnicas de
teoria fundamentada podem ser aproveitado na disciplina de engenharia de software e
de aplicativos web, para dar maiores retornos sobre o estado atual da prática de MPS e
(4) Ajuda na obtenção de uma perspectiva dos profissionais para identificar as
características das pequenas e médias empresas de aplicativos web.
Ciclo de vida: A pesquisa não teve como propósito mapear o ciclo de vida de
organizações de software, o objetivo foi elaborar uma pesquisa que pudesse demonstrar
fatores de sucesso de MPS aplicados em organizações desenvolvedoras de aplicativos
web.
3.2.10 Resultados
3.2.10.1 Questão de pesquisa 1
Q1. O ciclo de vida mapeado através do diagnóstico é realmente aquele adotado pela
organização desenvolvedora de software?
90
O objetivo desta questão de pesquisa foi analisar os estudos que identificam o ciclo de vida da
organização desenvolvedora de software, por meio de técnicas de diagnóstico ou outro tipo de
avaliação. A maioria dos trabalhos avalia os ciclos de vida das organizações pesquisadas, mas a
principal contribuição dos mesmos, está em relação as metodologias de avaliações desenvolvidas para
a implementação de iniciativas de melhoria de processo de software. Embora haja entre os trabalhos,
àqueles que de certa forma contribuem com metodologias que mapeiam o ciclo de vida e processo de
desenvolvimento de software.
Os trabalhos que se aproximam da resposta para esta pergunta foram sintetizados na Tabela 2.
Tabela 2. Estudos que adotam modelos de ciclo de vida em suas abordagens
Estudos
Using the software process improvement approach for defining a methodology for embedded systems
development using
Surveying and evaluating tools for managing processes for software-intensive systems
Assessment methodology for software process improvement in small organization
Using Scrum to guide the execution of software process improvement in small organizations
3.2.10.2 Questão de pesquisa 2
Q2. Quais os principais trabalhos que envolvem a identificação dos diferentes tipos de ciclo de
vida adotados pelas diferentes organizações desenvolvedoras de software, comparados àqueles
identificados na literatura?
O objetivo desta questão de pesquisa foi analisar estudos que identificam os diferentes ciclos de
vida adotados por organizações desenvolvedoras de software e compará-los aos ciclos de vida
descritos na literatura. Os trabalhos levantados identificam ou avaliam ciclo de vida, a contribuição dos
mesmos em relação a esta pergunta foi no sentido de proporem metodologias que possam ajudar a esta
pesquisa, desenvolver uma abordagem que consiga atingir um resultado na qual possa ser mapeado o
ciclo de vida de uma organização desenvolvedora de software e verificar se o mesmo poder comparado
a algum ciclo de vida existente na literatura. Para aqueles que de certa forma contribuem para o
levantamento inicial do ciclo de vida, a metodologia apresentada pelos mesmos, serviu de base para a
abordagem desenvolvida para o trabalho atual.
91
3.2.11 Considerações Finais
Este mapeamento sistemático mostrou que mapear ciclos de vida de desenvolvimento de
software, não é um tema muito fácil de se encontrar. A maioria dos trabalhos pesquisados, trata do
assunto como metodologia, incorporando isso nos conceitos dos desenvolvimentos ágeis como Scrum
e de modelos como cascata, iterativo e incremental, espiral e ágil.
Embora os trabalhos focados em analisar o ciclo de vida do desenvolvimento do software
tenham sido poucos, há entre eles àqueles que de certa forma contribuíram com metodologias para
uma avaliação inicial do ciclo de vida e processo de desenvolvimento da organização. Apesar de haver
poucos resultados com relação ao levantamento inicial de ciclos de vida, a pesquisa trouxe materiais
importantes a respeito de avaliações/diagnóstico, bem como a forma como as avaliações foram
tratadas. Estes trabalhos contribuíram na elaboração do experimento utilizado no trabalho final.
Pode-se dizer que esta pesquisa vem consideravelmente contribuir para a área da melhoria de
processos, por ser um tema pouco explorado, mostrando que apesar dos avanços na qualidade do
software desenvolvido, ainda há um déficit em trabalhos que relatem tal importância para o mercado.
A contribuição deste trabalho, visa atender em parte, as organizações que desejam iniciar um processo
de melhoria de desenvolvimento. Os trabalhos analisados, apontam que as organizações, estão cada
vez mais em busca de qualidade para o produto final e buscam constantemente maneiras de se produzir
um software com qualidade e baixo custo.
Por fim, a conclusão extraída desse mapeamento, é que o ciclo de vida de desenvolvimento de
software embora pouco explorado, traz soluções eficientes ao desenvolvimento do software,
levantando pontos forte, fracos e oportunidades de melhoria através de metodologias e abordagens que
atendam as expectativas das organizações na busca de melhoria de processo de software.
92
4 MODELO PROPOSTO
Tendo sido levantadas as fases presentes no processo de identificação do ciclo de vida de
desenvolvimento de uma organização intensiva em software que foram detalhadas na fundamentação
teórica (Capítulo 2) e no estado da arte (Capítulo 3) é possível identificar as necessidades e propor uma
abordagem de apoio à identificação do ciclo de vida de desenvolvimento de software a partir de uma
metodologia organizada em 6 etapas. Cada uma das etapas é detalhada nas próximas seções.
Este capítulo é organizado da seguinte forma: a Seção 4.1 apresenta uma visão geral da
abordagem proposta; em seguida a Seção 4.2 com a metodologia para construção e avaliação da base
de conhecimento e dentro dela tem-se as subseções 4.2.1 que descreve a revisão da literatura, a
Subseção 4.2.2 descreve a modelagem das árvores de decisão, na 4.2.3 apresenta as regras de
produção, a 4.2.4 aborda a ferramenta de sistema especialista, a 4.2.5 descreve a avaliação da base de
conhecimento, e por fim a 4.2.6 aborda a aplicação do diagnóstico.
4.1 VISÃO GERAL
A abordagem para autodiagnostico proposta neste trabalho é uma continuação da proposta de
diagnóstico realizada por Moreira (2012), na qual foi proposto o mapeamento do processo de
desenvolvimento de software, levando em consideração a análise de requisitos e a gerência de projetos
de acordo com o nível G do MPS.BR. Visando a construção de um sistema especialista para mapear o
ciclo de vida e processo de desenvolvimento adotado pela organização, foi construída uma nova base
de conhecimento.
A base de conhecimento é composta pelo material analisado na revisão da literatura para a
construção das árvores de decisão, na qual essas árvores foram avaliadas por especialistas de três
organizações e a mesma foi realizada presencialmente e através de vídeo conferência. Após essa
avaliação, uma revisão com correções e alterações nas árvores foi realizada com o objetivo de refinar o
conteúdo. A partir desta revisão, profissionais da área de MPS avaliaram as árvores como parte da
aquisição do conhecimento, para a base de conhecimento. Foi então realizada mais uma revisão dessas
árvores.
A partir desta última revisão nas árvores, regras de produção foram construídas para o
desenvolvimento do sistema especialista. Em seguida, o sistema especialista foi construído com base
93
nessas regras de produção e avaliado inicialmente por um especialista e um gerente de projetos, para
então passar por uma revisão. Avaliações em organizações de software e com especialistas MPS foram
realizadas. Com os resultados obtidos destas avaliações, uma nova revisão do sistema especialista foi
realizada, por fim foi aplicada mais uma avaliação com 2 especialistas MPS. Junto as avaliações foi
aplicado o método GQM.
A Figura 16, representa a metodologia que foi adotada para o modelo proposto incluindo a
avaliação GQM.
Figura 16. Metodologia
Fonte: Próprio autor.
Revisão da literatura
Modelagem das árvores de decisão
1) Construção
2) Avaliação com 3 organizações
3) Revisão
4) Entrevista ccom 3 especialistas MPS
5) Revisão
Sistema Especialista
1) Construção
2) Entrevista com especialista e gerente de projetos
Avaliação do Sistema Especialista e Avaliação GQM
1) Especialistas
2) Organizações
Revisão dos resultados com 2 especialistas
94
4.2 METODOLOGIA PARA CONSTRUÇÃO E AVALIAÇÃO DA BASE DE
CONHECIMENTO
Uma base de conhecimento é um conjunto de sentenças, que expressam uma linguagem que
representa alguma asserção sobre o mundo, ou seja, o conhecimento está contido em agentes sob a
forma de sentenças em uma linguagem de representação do conhecimento que estão armazenadas em
uma base de conhecimento. O conhecimento que será adquirido pelo sistema é a fonte de raciocínio do
mesmo (RUSSELL; NORVIG, 2004).
A base de conhecimento é considerada a parte principal de um sistema especialista pois contem
conhecimento sob a forma de regras de produção, quadros, redes semânticas, ou seja, de várias formas.
Uma das mais comuns é por sentenças do tipo: “SE – ENTÃO”.
Neste trabalho, para a construção da base de conhecimento foram utilizadas várias técnicas de
aquisição de conhecimento, que foram implementadas da seguinte forma: uma revisão da literatura foi
realizada com objetivo de se obter conteúdo suficiente para em seguida construir as árvores de decisão,
após uma validação, foram realizadas entrevistas com especialistas de 3 organizações de software, para
então ser realizado um refinamento dessas árvores, seguido de uma revisão e a partir deste contexto
foram estabelecidas as variáveis que deram início a construção das regras de produção.
A metodologia para construção e avaliação do sistema especialista proposta neste trabalho
possui as seguintes etapas: Revisão da literatura, Modelagem das árvores de decisão, Regras de
produção, Validação da base de conhecimento e Aplicação da base de conhecimento.
4.2.1 Revisão da Literatura
No mapeamento sistemático realizado foram levantados através de pesquisas em sites de
artigos científicos internacionais, trabalhos relacionados a abordagens desenvolvidas para identificação
do ciclo de vida de desenvolvimento visando a melhoria no processo de software. Através do
mapeamento sistemático realizado foram identificados métodos de diagnóstico, conceitos de avaliação
do SCAMPI e MA-MPS, modelos de referência com CMMI e MPS.BR, entre outros conceitos já
estudados anteriormente no presente trabalho. Estas pesquisas estão melhor descritas na Seção 3 e no
Apêndices A. Todo conteúdo pesquisado faz parte do material que contribuiu para o desenvolvimento
de uma metodologia que atenda o sistema especialista apresentado neste trabalho.
95
Realizou-se uma busca e seleção de pesquisas relacionadas a autodiagnostico, diagnóstico e
avaliação, a fim de levantar um escopo maior de informações acerca da maneira como os diagnósticos,
ferramentas de diagnóstico, avaliações do ciclo de vida de desenvolvimento e avaliações de melhoria
de processo de desenvolvimento vêm sendo conduzidas pelas pesquisas. Esta busca e seleção retornou
um conjunto de estudos que foram avaliados pelo pesquisador quanto às ferramentas de diagnóstico
utilizadas e maneira de conduzir uma avaliação para melhoria de processos de software. Neste ponto
da pesquisa, não se faz evidente a existência de estudos, com a utilização de ferramentas para
diagnóstico, envolvendo a identificação do ciclo de vida de uma organização.
As pesquisas abordam metodologias para avaliação de processos de software, ferramentas para
diagnóstico, abordagens para realização de diagnóstico, tipos de organizações, metodologia adequada a
cada tipo e métodos para aplicação de avaliação com foco na melhoria de processo. As pesquisas ainda
mostraram que a utilização de metodologias para avaliação tem apresentado relevante aceitação em
organizações de pequeno e médio porte.
Embora trabalhos relacionados a ciclos de vida de desenvolvimento tenham sido poucos, o
retorno das pesquisas trouxe materiais importantes para a construção de uma abordagem para avaliação
e diagnóstico do processo de desenvolvimento de software, contribuindo para a elaboração da
metodologia de avaliação deste estudo.
A fundamentação teórica e o mapeamento sistemático contribuíram para estruturar a
abordagem proposta e levantar informações a respeito de: Metodologias de Avaliação, Diagnóstico,
Abordagens para Avaliação, Organizações Desenvolvedoras, Porte/Características das organizações,
Modelos de Ciclo de Vida, Processos de desenvolvimento.
4.2.2 Modelagem das Árvores de Decisão
Uma árvore de decisão toma como entrada um objeto ou situação descritos por um conjunto de
atributos e retorna uma “decisão” – o valor de saída previsto, de acordo com a entrada (RUSSELL;
NORVIG, 2004). A fim de modelar o conhecimento envolvendo as fases de um ciclo de vida de
desenvolvimento de software, foi criado um conjunto de árvores de decisão. Estas árvores permitiram
a definição das regras de produção que serão utilizadas pelo sistema especialista.
96
Para criar essas árvores foi necessário basear-se nos modelos de referência como o MPS.BR e o
CMMI-DEV, nos relatórios com resultados de avaliações realizadas por uma empresa de consultoria em
melhoria de processo de software, em um experimento inicial realizado com gerentes de projetos de 3
organizações de desenvolvimento de software da região de Blumenau e Joinville, e em entrevistas
realizadas com especialistas em MPS. As perguntas e respostas utilizadas para compor a estrutura de
cada árvore baseiam-se nos modelos de referência:
CMMI-DEV (Capability Maturity Model Integration for Development) (SEI, 2010a);
Neste modelo contribuíram para a construção das árvores de decisão os conceitos das áreas de
processo (Gestão de Requisitos, Planejamento de Projeto, Monitoramento e Controle de Projeto,
Garantia da Qualidade e Gestão de Configuração) e por fim foram utilizados os conceitos relacionados
as métricas e práticas das áreas de processo. Para construir as árvores foram mapeadas as áreas de
processo e a partir das metas e práticas de cada processo, os nós e as ramificações das árvores foram
sendo definidos.
MR-MPS-SW (Modelo de Referência para Melhoria de Processo de Software)
(SOFTEX, 2012).
Para o MR-MPS-SW, foi utilizada a Guia Geral de Software do MPS, onde há uma descrição
detalhada dos processos. Para compor as árvores foi utilizado os processos do Nível G do MPS.BR,
que já haviam sido utilizados no trabalho de Moreira (2012) e os processos de Gerência de
Configuração e Garantia da Qualidade do Nível F do MPS.BR. Para construir as árvores foram
mapeadas as áreas de processo e a partir dos resultados esperados, foram definidos os nós e
ramificações das árvores.
Nos processos de ciclo de vida:
RUP (Rational Unified Process) (IBM, 2007);
O RUP possui duas dimensões, as fases e as disciplinas, que juntamente aos conceitos do
CMMI-DEV e do MR-MPS-SW foram utilizadas para definir algumas árvores. Os conceitos das
disciplinas (Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste,
Implantação e Gerenciamento de Projeto) foram traduzidos em perguntas e respostas para que
97
pudessem compor os nós das árvores de decisão. As fases do RUP (Iniciação, Elaboração, Construção
e Transição) foram necessárias para organizar a sequência de perguntas e respostas em cada árvore.
XP (Extreme Programming);
Do modelo XP, foram extraídas informações a respeito das práticas utilizadas no modelo. Esses
conceitos foram mapeados e utilizados na forma de perguntas e respostas (nós das árvores).
Scrum, como um framework para suportar o desenvolvimento e manutenção de
produtos complexos (SCHWABER; SUTHERLAND, 2011).
O Scrum possui termos específicos do processo, os mesmos foram utilizados nas árvores como
forma de identificar se a organização trabalha ou não com esses conceitos.
No corpo de conhecimento:
SWEBOK (Software Engineering Body of Knowledge) (IEEE, 2014);
Em relação ao guia SWEBOK, para auxiliar na construção das árvores, as áreas da engenharia
de software que foram utilizadas são: Requisitos de Software, Construção de Software, Qualidade de
Software, Teste de Software e Manutenção de Software. Para compor a estrutura das árvores, os
conceitos das áreas relacionadas acima, foram traduzidas em perguntas e respostas.
E na norma:
ISO/IEC 12207 (Systems and software engineering - Software life cycle processes)
(ISO/IEC 12207, 2008);
A contribuição da ISO/IEC 12207 foi em relação a estrutura de cada árvore. Por se tratar de
uma norma voltada para processos de ciclo de vida, ela auxiliou na nomeação, distribuição das fases de
um ciclo de vida em árvores e parte do conteúdo foi utilizado para compor as perguntas e respostas de
cada árvore.
Foram elaboradas árvores de decisão, que se referem as fases do ciclo de vida de
desenvolvimento de software. São elas: Inicial, Requisitos, Gerência de Projeto, Construção, Testes,
Documentação e Manutenção.
98
4.2.2.1 Descrição das árvores
Após o estudo dos modelos de referência (CMMI-DEV e MPS.BR), da norma ISO/IEC 12207,
do corpo de conhecimento SWEBOK, dos processos de desenvolvimento e modelos de ciclo de vida
citados anteriormente (Seção 2), foram construídas árvores de decisão, onde os ramos de cada árvore
contem perguntas e respostas que abrangem informações pertinentes as informações citadas
anteriormente.
As árvores são focadas nas etapas:
1) Inicial: Possui informações iniciais a respeito de como o desenvolvimento é conduzido.
Esta etapa é conduzida com o objetivo de fazer um levantamento inicial do processo de
desenvolvimento da organização. Identificando se a organização trabalha com algum
modelo de ciclo de vida e como este modelo é trabalhado.
2) Requisitos: Possui informações pertinentes a fase de levantamento e análise de
requisitos. Esta etapa busca levantar a forma como são tratados os requisitos do
software, desde seu levantamento até a sua “entrada” na fase de desenvolvimento.
3) Gerenciamento/Acompanhamento de Projeto: Possui informações sobre como é feito o
gerenciamento do projeto de desenvolvimento. Nesta etapa o objetivo é identificar
como o responsável pelo projeto conduz o mesmo.
4) Solução Técnica: Possui informações a respeito dos diagramas utilizados para modelar
o sistema. O objetivo principal é levantar se a organização trabalha com diagramas e
quem os desenvolve.
5) Construção: Possui informações sobre a etapa de desenvolvimento/implementação dos
requisitos. O objetivo desta fase é identificar as etapas de construção do requisito.
6) Testes: Possui informações sobre a fase de planejamento e elaboração dos testes. Na
etapa de testes, o objetivo é identificar se a organização trabalha com um planejamento
de testes e se possui casos de testes, bem como a condução dos mesmos.
99
7) Documentação: Possui informações sobre a fase de documentação dos requisitos do
sistema. Nesta etapa, geralmente, são elaborados os manuais que são disponibilizados
para os clientes/usuários, a fim de facilitar o entendimento e a usabilidade do produto.
8) Manutenção: Possui informações a respeito das correções que ocorrem após uma
versão/release liberada para o cliente, que devido a ocorrência de erros, retornam a
equipe de desenvolvimento;
A árvore “Inicial” (ver Apêndice B) busca desenhar um perfil da organização, verificando se
ela trabalha por projeto, qual metodologia de desenvolvimento que ela adota, como os projetos são
organizados, fases ou etapas e atividades. O objetivo destas informações é possibilitar distinguir o
processo da organização, como sendo voltado a projeto ou por demanda. A Figura 17 apresenta um
trecho da árvore Inicial.
Figura 17. Trecho da árvore inicial
Fonte: Próprio autor.
100
Para a entrevista utilizando o sistema especialista, o trecho da árvore ilustrado na Figura 17, foi
representado no Quadro 7.
Quadro 7. Representação da entrevista relacionada a árvore inicial
Entrevistador: “A sua organização costuma trabalhar por projeto?”
Organização: “Sim”
Entrevistador: “Ela utiliza alguma metodologia em seus projetos?”
OU
Entrevistador: “A sua organização costuma trabalhar por projeto?”
Organização: “Não”
Entrevistador: “A organização trabalha por demanda?”
Organização: “Sim”
As demais entrevistas seguem o mesmo padrão da entrevista relacionada a árvore inicial,
representada no Quadro 7, sendo cada uma voltada para suas características.
A árvore “Requisitos” (ver Apêndice B) levanta informações a respeito da análise de requisitos,
como quem avalia, como é registrado, quem são os responsáveis pela aprovação, prioridade do
requisito entre outros aspectos. O objetivo desta árvore é mapear a forma como o requisito chega ao
desenvolvimento, isto é, o entendimento dos requisitos junto ao fornecedor de requisitos e como ele é
tratado, quem avalia, quem aprova, a prioridade e principalmente como ele é documentado. A Figura
18 mostra um exemplo da árvore de requisitos.
Figura 18. Trecho da árvore Requisitos
Fonte: Próprio autor.
101
A árvore “Projeto” (ver Apêndice B) levanta informações a respeito do projeto de
desenvolvimento do software, como responsáveis pela aprovação, documentos utilizados, medição,
cronograma, orçamento, escopo e ferramentas de gerenciamento. O objetivo desta árvore é utilizar os
conceitos de gerência de projeto e mapear se a organização utiliza esses conceitos ou parte deles. A
Figura 19 mostra um exemplo da árvore de projetos.
Figura 19. Trecho da árvore Projeto
Fonte: Próprio autor.
A árvore “Solução Técnica” (ver Apêndice B) levanta informações a respeito da fase de
elaboração de diagramas, como o de atividades, casos de uso e classes. Verifica quem é o responsável
pela construção e manutenção dos mesmos. O objetivo desta árvore é mapear o processo antes de
iniciar a construção e verificar se a organização possui esse nível de detalhamento de requisitos. A
Figura 20 mostra um exemplo da árvore de solução técnica.
102
Figura 20. Trecho da árvore de solução técnica
Fonte: Próprio autor
A árvore “Construção” (ver Apêndice B) levanta informações a respeito do desenvolvimento
do software, tais como, prioridade de execução de tarefas, quem participa, quem é o responsável, como
as informações são documentadas, quem faz a análise, quem implementa, se há teste unitário. O
objetivo desta árvore é mapear o processo de desenvolvimento da organização, identificando o escopo
do trabalho para o projeto e contribuindo para o mapeamento do ciclo de vida. A Figura 21 mostra um
exemplo da árvore de construção.
103
Figura 21. Trecho da árvore Construção
Fonte: Próprio autor.
A árvore “Testes” (ver Apêndice B) levanta informações a respeito da etapa de testes, como
quem elabora o plano de testes, quem participa, quem acompanha, quem testa as rotinas entre outros.
O objetivo desta árvore é identificar a estratégia de validação da organização mapeando as atividades
de teste e contribuindo para identificação do ciclo de vida. A Figura 22 mostra um exemplo da árvore
de testes.
104
Figura 22. Trecho da árvore Testes
Fonte: Próprio autor.
A árvore “Documentação” (ver Apêndice B) levanta informações a respeito da documentação
dos requisitos para envio ao usuário/cliente, para que o mesmo possa através de um documento, como
um manual, trabalhar com o requisito implementado. O objetivo desta árvore é mapear como o
requisito chega nesta fase, quem é o responsável e como é liberada essa documentação. A Figura 23
mostra a árvore de documentação.
105
Figura 23. Trecho da árvore de documentação
Fonte: Próprio autor
A árvore “Manutenção” (ver Apêndice B) levanta informações a respeito das correções que
ocorrem no software depois que uma versão/release é liberada para o cliente, como é priorizada a
correção, se existe uma equipe destinada a realização apenas das correções, quem é o responsável,
como é feita a liberação. O objetivo desta árvore é identificar a estratégia de gerenciamento de projeto
para quando ocorrer um erro no software depois de liberado para o cliente. Identificar como
desenvolvimento conduz a correção destes erros. Esta árvore também levanta informações a respeito
das alterações de requisito e como elas são tratadas. Questões como, reaprovação do requisito, quem
faz, quem avalia a alteração do requisito, como é feito o mapeamento das partes alteradas
(rastreamento) e como é feita a atualização. Levantar as tomadas de decisão do responsável, quando as
alterações ocorrerem, sem prejudicar a entrega final deste requisito. A Figura 24 mostra a árvore de
manutenção.
106
Figura 24. Trecho da árvore Manutenção
Fonte: Próprio autor.
4.2.2.2 Avaliação inicial das árvores
Uma avaliação inicial foi realizada para que se pudesse fazer um primeiro refinamento das
árvores, buscando atingir um nível de informação semelhante às informações utilizadas por
especialistas em consultorias de melhoria de processos, na qual os mesmos buscam inicialmente
mapear o ciclo de vida de desenvolvimento das organizações.
As entrevistas iniciais foram realizadas com três pessoas ligadas a área de engenharia de
software de três diferentes empresas, cada uma de um ramo de atividade diferente da outra. O Quadro
8 apresenta algumas características de cada pessoa entrevistada.
Quadro 8. Características dos entrevistados
Avaliação Conhecimentos em: Função atual Tempo na organização
A CMMI, Scrum, RUP Gerente de Projetos 1 ano e 3 meses
B CMMI, Scrum Gerente de Projetos 3 anos e 8 meses
C CMMI, MPS.BR, Scrum, RUP Coordenador de Projetos 1 ano e 1 mês
107
O Quadro 9 apresenta algumas características das organizações entrevistadas para a avaliação
inicial.
Quadro 9. Características das organizações
Avaliação Porte Principal
atividade
Possui processo formal? Tipo de produto de
software
A Média Software padrão
com
customizações
para clientes.
Não. Ainda em fase de
implantação
- Software voltado para
web
- Software voltado para
desktop
B Média Software padrão
com
customizações
para clientes.
Processo desenvolvido pela
empresa com base nos conceitos
do CMMI
- Software voltado para
desktop
C Média Software por
encomenda
(fábrica)
Sim. A base é o modelo cascata
(desenvolvimento) e PMBOK
(gerenciamento de projetos)
- Software voltado para
web
- Prestação de serviços
A primeira entrevista foi realizada presencialmente, nomeou-se de “Avaliação A”, que serviu
de alinhamento possibilitando uma melhor qualidade de material para as outras duas entrevistas. As
demais entrevistas foram realizadas por e-mail, na qual o material foi enviado e respondido.
O primeiro material utilizado foram as árvores de decisão, de acordo com o resultado foi
mapeado o processo e o mesmo desenhado em forma de fluxo, em seguida esse material foi avaliado
pelo entrevistado para verificar se o texto e fluxo formulado estavam de acordo com a realidade da
organização.
Por último, questões relacionadas ao perfil da empresa, perfil do entrevistado e algumas
questões sobre o experimento foram respondidas.
A “Avaliação A” teve pontos de discussão relevantes, como por exemplo, o fluxo das árvores
de decisão, muitos pontos tiveram que ser redesenhados para que pudesse facilitar o entendimento do
entrevistado em relação ao conteúdo.
Outro ponto chave da avaliação presencial foi em relação a alguns termos, que para o
entrevistado teve um sentido e para o entrevistador teve outro sentido, resultando numa dupla
interpretação. Em relação ao texto o mesmo foi ajustado em alguns pontos e o fluxo também. Esse
ajuste foi devido a ordem em que as perguntas das árvores foram formuladas, a ordem das mesmas não
108
garante a ordem das atividades do processo, ocasionando em um erro de fluxo na etapa de requisitos,
mais precisamente entre a validação do requisito e o início do projeto.
A segunda entrevista, nomeou-se de “Avaliação B”, feita por e-mail, o entrevistado não relatou
dificuldades. O texto formulado não sofreu mudanças, assim como o fluxo. O entrevistado não relatou
sentir falta de nenhuma etapa.
A terceira entrevista, nomeou-se de “Avaliação C”, feita por e-mail, o entrevistado teve dúvidas
em relação ao objetivo do experimento o que dificultou um pouco as respostas, o mesmo também
sentiu falta de abordar alguns temas da área de engenharia de software, como as fases “Projeto
Arquitetural” e “Documentação”. Em relação ao texto formulado de acordo com as respostas o mesmo
foi ajustado em alguns pontos. O fluxo sofreu uma pequena mudança em relação a etapa de testes e na
etapa de construção teve que ser inserido a atividade de documentação.
Em resumo, com as árvores de decisão desenvolvidas para essa avaliação inicial com o objetivo
de desenhar o ciclo de vida da organização, foi importante, pois com os resultados obtidos, melhorias
no fluxo das árvores foram feitas, assim como a inclusão de mais perguntas e novas árvores que irão
atender melhor as etapas do ciclo de desenvolvimento de software de uma organização.
Conclusões
As avaliações realizadas puderam mostrar parte do processo de desenvolvimento de cada
organização, sendo que alguns pontos no que diz respeito ao desenho das árvores sofreram melhorias,
visando como resultado a modelagem do fluxo de atividades de forma mais ordenada. Foram
desenvolvidas mais algumas árvores de decisão visando atender outras fases do processo.
Em geral os resultados das avaliações realizadas mostraram-se adequados, apresentando
relatórios com uma modelagem do fluxo de atividades satisfatórios e alinhados com o ciclo de vida de
desenvolvimento das organizações.
4.2.2.3 Revisão das árvores de decisão
Após a avaliação realizada nas 3 organizações, foi realizada uma revisão nas árvores de
decisão, para que pontos onde houve discussão, solicitações de mudança e correções pudessem ser
ajustados, visando a melhora na qualidade das informações contidas nas árvores.
109
4.2.2.4 Entrevista com especialistas
Segundo Rezende (2003), uma entrevista estruturada é uma abordagem correlata embora
significativamente mais produtiva, referindo-se à identificação dos elementos e relações do domínio,
essas podem ser feitas na fase de identificação e conceituação, na qual é formulada a descrição do
domínio. Essa abordagem é baseada em um processo sistemático orientado a um objetivo que leva a
uma comunicação organizada entre o especialista e o entrevistador, ajudando a evitar distorções
decorrentes da subjetividade.
Nesta etapa da metodologia, foi realizada entrevistas com especialistas da área de melhoria de
processos de software, a fim de, verificar e validar as informações contidas nas árvores de decisão e
como forma de aquisição de conhecimento. Para estas entrevistas foram entrevistados 3 avaliadores e
implementadores MPS. As entrevistas foram realizadas através de videoconferência. No momento da
entrevista foram realizados apontamentos que geraram informações necessárias para mais um
refinamento nas árvores.
O objetivo desta nova revisão nas árvores de decisão, foi agregar o conhecimento levantado
com as entrevistas. Com essa revisão, as árvores de decisão sofreram alterações como forma de se
atingir um maior nível de conhecimento, para que o mesmo possa chegar o mais próximo ao nível de
conhecimento de um especialista.
4.2.3 Regras de Produção
Para modelar as informações necessárias para serem utilizadas nas organizações de
desenvolvimento de software, regras de produção foram criadas com o intuito de mapear o maior
número de informações em relação ao ciclo de vida de desenvolvimento de software de uma
organização intensiva em software e um mecanismo de inferência foi construído a fim de definir a
ordem com que serão processadas as informações das árvores de decisão para chegar a conclusões ou
recomendações de ações.
Antes de definir as regras de produção foi necessário modelar o conhecimento envolvendo
conteúdo relacionado aos modelos de referência, processos de ciclo de vida e corpo de conhecimento.
Para as regras de produção que foram utilizadas no SE do presente trabalho foram criadas
árvores de decisão (Subseção 4.2.2), que compõem as fases do ciclo de vida de desenvolvimento, as
110
mesmas têm como finalidade fazer com que o SE adquira conhecimento suficiente para demonstrar
resultados de forma confiável e o mais próximo possível do conhecimento de um especialista em
melhoria de processos de software.
Com base nas regras de produção o sistema especialista foi desenvolvido com as definições
apresentadas neste trabalho, considerando o método de avaliação MA-MPS, os requisitos estabelecidos
no CMMI-ARC e na ISO/IEC 12207. Desta forma, a avaliação suporta os modelos MPS.BR, CMMI e
norma ISO/IEC 12207, respectivamente.
O uso do modelo CMMI e da norma ISO/IEC 12207 foram considerados devido seu
reconhecimento internacional. O modelo MPS.BR foi também considerado porque além de ter sido
desenvolvido de forma compatível ao modelo e norma supracitados é nacionalmente reconhecido e
está também alinhado à realidade das MPEs (Micro e Pequenas Empresas) de software brasileiras.
A Figura 25 apresenta uma regra de produção da árvore inicial, utilizadas para compor a
metodologia do SE.
Figura 25. Trecho contendo uma regra de produção
Fonte: Próprio autor.
Para esta pesquisa, o encadeamento progressivo será utilizado em todas as árvores de decisão,
visto que o ponto de partida de cada uma é o problema inicial (“Quais são as atividades de cada fase
do ciclo de vida?”) e o alvo é a solução (“Atividades que caracterizam as fases do ciclo de vida”). O
nó inicial começa com a fase do ciclo e então vários outros nós são percorridos buscando uma solução,
que seria a relação de atividades executadas para cada fase do ciclo de vida.
No trabalho realizado por Moreira (2012), foram construídas 23 árvores de decisão que
geraram 236 regras de produção. Para o trabalho atual, foram construídas 33 árvores de decisão que
geraram aproximadamente 572 regras de produção, evoluindo o trabalho iniciado em 2012, para uma
111
base de conhecimento mais robusta, que gera resultados mais sólidos para as organizações de
desenvolvimento de software. A justificativa que se dá para a quantidade de regras de produção do
trabalho atual em relação ao anterior é devido ao tamanho das árvores de decisão, que possuem mais
nós do que as árvores construídas anteriormente.
4.2.4 Ferramenta de Sistema Especialista
A ferramenta construída para o trabalho de Moreira (2012), não foi utilizada, devido sua
limitação em fazer um levantamento de todas as fases de um ciclo de vida. A ferramenta apenas
considerou o nível G do MPS.BR, que trata o gerenciamento de projetos e de requisitos. No presente
trabalho foram construídas novas regras de produção geradas a partir de árvores de decisão e que
contemplam todas as fases de um ciclo de vida.
Para a construção do sistema especialista, foi utilizada a ferramenta CLIPSJNI. Uma
ferramenta para construção de sistemas especialistas, de domínio público, desenvolvida pela NASA. A
linguagem CLIPS foi escrita na linguagem C, que permite portabilidade e rapidez nas execuções e tem
sido instalada em diversos tipos de plataformas. Além de possuir vários manuais, incluindo o manual
de referência e o manual do usuário.
4.2.5 Avaliação da Base de Conhecimento
A avaliação da base de conhecimento junto a ferramenta de SE, se deu através de um piloto que
realizado em uma organização de Joinville e com um especialista em MPS. Para essa avaliação, foi
entrevistado um gerente de projetos responsável pelo processo na organização com 10 anos de
experiência em gerência de projetos e um especialista MPS com 20 anos de experiência entre
coordenação, gerência de projetos e melhoria de processos, em seguida uma revisão do SE foi
realizada com as informações coletadas através desta primeira avaliação.
Após esta primeira avaliação foram corrigidas algumas perguntas para que as mesmas
pudessem ser mais legíveis aos entrevistados. Algumas respostas receberam mais opções de escolha,
em outros casos as opções foram alteradas. Foi incluído um espaço ao final dos questionamentos para
que os entrevistados pudessem deixar registrados alguns pontos que não foram tratados pelo SE.
112
O resultado desta primeira avaliação gerou um diagnóstico com o ciclo de vida da organização,
detalhando pontos fortes, pontos fracos e oportunidade de melhorias para a organização avaliada. O
especialista simulou uma organização e obteve um diagnóstico semelhante ao diagnóstico já realizado
por sua empresa de consultoria.
Por fim a base de conhecimento foi revisada com o intuito de melhorar o conteúdo para que os
resultados possam chegar o mais próximo ao resultado emitido por um especialista MPS.
4.2.6 Aplicação do Diagnóstico
Após a revisão da base de conhecimento, foram realizadas 2 avaliações de diagnóstico, por 2
especialistas em MPS. O principal objetivo desta avaliação foi fazer um refinamento final, antes do SE
ser aplicado em organizações de desenvolvimento e com especialistas MPS.
Essas 2 avaliações mapearam alguns pontos de melhoria para o SE, como o reforço de
perguntas mais elaboradas para o acompanhamento de projetos, tratamento de problemas, desvios e
alterações de requisitos durante o desenvolvimento e ainda foram incluídas perguntas relacionadas a
rastreabilidade do requisito.
Após a revisão da base de conhecimento e refinamento do SE, foram realizadas avaliações de
diagnóstico em organizações de desenvolvimento de software, seguindo a metodologia de entrevistas
descrita na Seção 5.1. Para tal, foi utilizada a ferramenta de SE, na qual os responsáveis pelo processo
de desenvolvimento avaliaram o ciclo de vida de desenvolvimento que a organização utiliza e a partir
disso, foram mapeados pontos positivos e negativos do desenvolvimento, bem como a possibilidade de
realizar um levantamento de melhorias.
Além das organizações, foram realizadas avaliações com o SE com especialistas MPS,
seguindo a metodologia de entrevistas descrita na Seção 5.1. Foi utilizada a ferramenta de SE, na qual
os especialistas simularam o processo de uma organização, já avaliada por eles e seus trabalhos de
consultoria.
113
4.3 O SISTEMA ESPECIALISTA DESENVOLVIDO
A partir destas regras de produção um sistema especialista foi desenvolvido, utilizando a
ferramenta CLIPSJNI. O motor de inferência utilizado foi o forward chaining por se tratar de uma
lógica que parte do problema para a solução, que neste caso, temos como problema identificar partes
do processo de desenvolvimento de software que possuem pontos fracos ou que precisam de melhorias
e a partir deste levantamento obter um diagnóstico para a solução. O forward chaining foi utilizado
devido ao fato de ser o motor que melhor se adequa a realidade da estrutura do sistema especialista
desenvolvido para este trabalho.
O sistema especialista conta com aproximadamente 132 perguntas, distribuídas entre a fase de
requisitos até a fase de manutenção. Após responder às perguntas do sistema, o mesmo emite vários
resultados considerando alguns pontos fracos, pontos fortes e oportunidades de melhoria.
Para validação inicial do SE, foram entrevistados 1 gerente de projeto e 2 especialistas. Os
resultados destas 3 validações, permitiram corrigir falhas no SE, bem como inserir mais perguntas e
excluir outras. Foi possível também, melhorar a descrição dos resultados emitidos pelo SE.
Após a revisão do SE com base nesta primeira validação inicial, foi possível fazer avaliações
do SE junto a especialistas e organizações de desenvolvimento. Ao todo foram 6 organizações
entrevistadas e 7 especialistas em MPS.
As Figuras 26 e 27, demonstram parte das perguntas e resultados.
114
Figura 26. Trecho das perguntas feitas pelo Sistema Especialista
Na Figura 26, é possível verificar um trecho das perguntas feitas pelo sistema especialista. No
início o sistema procura fazer perguntas que abranjam todo o processo de desenvolvimento. Em
seguida, ele segue fazendo perguntas mais específicas à cada fase do ciclo de vida de desenvolvimento.
No caso do exemplo exposto pela Figura 26, as regras de produção disparadas podem ser
identificadas no Quadro 10.
Quadro 10. Regras de Produção.
(defrule arv_ini_1
(pergunta (pergunta regra_org_trab_proj) (resposta SIM))
(pergunta (pergunta regra_utiliza_metod) (resposta SIM))
(pergunta (pergunta utiliza_fases) (resposta SIM))
(pergunta (pergunta fases_sequenciais1) (resposta SIM))
=>
(assert (regra_arv_ini_1 "RP005"))
)
(defrule arv_ini_2
(pergunta (pergunta regra_metodologia) (resposta A))
(pergunta (pergunta regra_possui_levantamento1) (resposta SIM))
=>
(assert (regra_arv_ini_2 "RP_001"))
)
(defrule arv_ini_3
(pergunta (pergunta regra_possui_construcao) (resposta SIM))
(pergunta (pergunta regra_possui_testes1) (resposta SIM))
115
(pergunta (pergunta regra_possui_implantacao1) (resposta NAO))
(pergunta (pergunta regra_possui_manutencao1) (resposta NAO))
=>
(assert (regra_arv_ini_3 "RP_004"))
)
(defrule arv_ini_4
(pergunta (pergunta regra_analise_riscos) (resposta NAO))
(pergunta (pergunta regra_prototipo2) (resposta SIM))
(pergunta (pergunta regra_prot_con_desenv2) (resposta SIM))
(pergunta (pergunta regra_valida_cliente2) (resposta SIM))
(pergunta (pergunta regra_refina_prot2) (resposta SIM))
(pergunta (pergunta regra_valida_novamente2) (resposta SIM))
=>
(assert (regra_arv_ini_4 "RP_011"))
)
O motor de inferência, no caso da Figura 26, age sempre fazendo uma pergunta e ao receber a
resposta dispara a pergunta seguinte de acordo com a resposta informada pelo usuário. Pode-se
observar que a primeira pergunta “A organização trabalha por projeto?” recebe a resposta “S” (Sim),
prosseguindo para a próxima pergunta “A organização utiliza alguma metodologia em seus projetos?”
que também recebe como resposta “S” (Sim). Através deste raciocínio o sistema especialista vai
chegando a conclusões que são detalhadas ao final, no detalhamento dos resultados, demonstrado pela
Figura 27.
O Quadro 10, demonstra como o raciocínio é feito para o sistema especialista chegar as
conclusões de quais regras utilizar para disparar, ao final, os resultados. Cada regra é resultado de um
conjunto de perguntas e respostas.
Na Figura 27, é possível verificar um trecho dos resultados emitidos pelo sistema especialista.
Os resultados são descritos, por árvore de decisão, indicando por onde o SE passou.
116
Figura 27. Trecho dos resultados emitidos pelo Sistema Especialista
O diagnóstico dos resultados considera os pontos fortes, pontos fracos e oportunidades de
melhorias listados pelo SE. A organização pode, com esta informação, aplicar medidas de melhoria,
correções, adaptações e mudanças no seu processo de desenvolvimento de software. Para os
especialistas, verificar os resultados emitidos pelo sistema especialista, de uma organização avaliada,
pode servir como forma de mapear as informações colhidas nas entrevistas e verificar se as mesmas
estão de acordo com a realidade da organização sob seu ponto de vista.
Embora a interface do sistema especialista precise de melhorias, isto não impede que a
avaliação seja realizada. A melhoria na interface pode vir a facilitar as avaliações para quem as realiza.
Após a avaliação do SE realizada junto aos especialistas em MPS e organizações de
desenvolvimento foi possível fazer uma avaliação GQM sob dois pontos de vista, dos especialistas e
das organizações.
117
5 AVALIAÇÃO
Avaliação de processo de software é um processo de medição subjetivo que envolve o
julgamento de pessoas qualificadas para identificação quantitativa de pontos fortes e fracos nos
processos (EL-EMAM et al., 1998).
O trabalho foi avaliado considerando dois pontos de vista diferentes, utilizando a abordagem
GQM (Goal/Question/Metric) proposto por Basili et al. (1994). Uma sob o ponto de vista dos
especialistas, a fim de avaliar a adequação do conteúdo da abordagem em relação ao conhecimento em
melhoria de processos destes profissionais, o que traz maior confiabilidade dos resultados para as
organizações. O segundo ponto de vista, sob a perspectiva das organizações, tem o propósito de
verificar a aderência ao resultado, isto é, possibilitar a organização confrontar os dados analisados
resultantes da abordagem apresentada neste estudo, com a realidade da mesma.
Foram entrevistados 6 especialistas em melhoria de processo de software e 6 organizações
intensivas em software situadas em Joinville e Blumenau.
Este capítulo apresenta a seguinte organização: a Seção 5.1 detalha a metodologia das
entrevistas prevista para a avaliação semi automatizada e a Seção 5.2 aborda as considerações para a
aplicação da avaliação e resultados esperados.
5.1 ENTREVISTAS
Um processo de entrevista foi desenvolvido visando contemplar a avaliação do sistema
especialista. Para tal foi enviado um convite por e-mail ao entrevistado, descrevendo o processo de
avaliação do SE, após o aceite, foi realizada uma reunião presencial (no caso das organizações) e a
pesquisa foi apresentada de forma mais detalhada, por fim, durante a reunião, iniciou-se o processo de
execução do sistema especialista.
Os resultados do sistema especialista foram apresentados ao entrevistado, que após a entrevista,
recebeu o documento gerado com os resultados e um documento de avaliação do SE. Com os
resultados em mãos o entrevistado então respondeu ao documento de avaliação e o enviou ao
entrevistador. Em posse deste documento de avaliação o entrevistador pode então documentar a
avaliação utilizando a abordagem GQM, descrita na Seção 5.2.1.
118
No caso dos especialistas, a entrevista de avaliação do SE, se deu enviando um e-mail com um
convite à participação do mesmo na pesquisa. Após o aceite, o ambiente de execução do sistema
especialista foi compartilhado. Para os especialistas a metodologia foi adotada desta forma para que os
mesmos, de posse do sistema especialista, possam simular diversos processos de desenvolvimento,
permitindo uma avaliação de forma mais completa do seu ponto de vista. Em seguida, os especialistas
respondem a um documento de avaliação e o enviam ao entrevistador, que sob posse desse documento
pode então documentar a avaliação utilizando a abordagem GQM, descrita na Seção 5.2.1.
A Figura 28, apresenta o processo de entrevistas realizado com as organizações e especialistas.
Figura 28. Visão geral do processo de entrevistas
Fonte: Próprio autor
A Figura 29, apresenta um fluxo de atividades proposto para o processo.
Organização
1ª fase
- Apresentação da pesquisa
2ª fase
- Reunião e Entrevista
- Execução do SE
- Apresentação dos resultados
3ª fase
- Envio dos resultados
- Envio do documento de avaliação
Especialistas
1ª fase
- Apresentação da pesquisa
2ª fase
- Compartilhamento do ambiente para execução do SE
- Envio do documento de avaliação
Entrevistador
- Análise dos documentos de avaliação enviados pelos especialistas e organizações
119
Figura 29. Fluxo de atividades
Fonte: Próprio autor
A partir da metodologia apresentada, sem um tratamento estatístico amplo, podemos considerar
que o trabalho pode contribuir para o processo de melhoria na organização, uma vez que é permitido
que as organizações e empresas implementadoras, realizem a execução do sistema especialista de
forma semi automatizada, trazendo maior agilidade, flexibilidade ao processo e reduzindo custos.
Tendo em vista, que a organização poderá realizar um autodiagnostico do seu processo a qualquer
momento, sem a necessidade da presença de uma empresa implementadora.
5.2 MODELO DE AVALIAÇÃO
A avaliação do estudo proposto foi realizada através da abordagem GQM, que representa uma
abordagem sistemática para a adaptação e integração de objetivos para os modelos dos processos de
software, produtos e perspectivas de interesse de qualidade, com base nas necessidades específicas do
projeto e da organização. A abordagem é composta por uma estrutura hierárquica que inicia com a
definição, em um nível conceitual, dos objetivos a serem medidos (goals), que são então refinados em
várias questões, a fim de decompor o problema em seus componentes principais. Estas perguntas
constituem o nível operacional do modelo, que é finalmente refinado em métricas objetivas ou
subjetivas (por exemplo, a quantidade de estudos selecionados, e a percepção do pesquisador a respeito
Convite•Feito por e-mail, para organizações e especialistas, descrevendo a pesquisa.
Execução do SE
•Nas organizações a execução do SE foi realizada presencialmente. Para os especialistas, o ambiente de execução do SE foi compartilhado.
Avaliação (GQM)
•Tanto para as organizações quanto para os especialistas, um documento com um questionário foi enviado.
120
da produtividade obtida, respectivamente). Uma única métrica pode ser utilizada para responder
diferentes perguntas sob o mesmo objetivo (BASILI; CALDEIRA; ROMBACH, 1994).
De acordo com a abordagem GQM, foi realizada uma avaliação descrita como pré-execução,
específica do questionário que será utilizado para mapear o perfil de desenvolvimento da organização,
bem como as questões descritas nas árvores de decisão. Esta avaliação foi realizada por profissionais
da área de melhoria de processos.
A avaliação descrita como pós-execução, será em relação à condução da abordagem nas
organizações, avaliando os resultados esperados do processo de autodiagnostico do ciclo de vida de
desenvolvimento, através de diálogos automatizados. Esta avaliação foi realizada pelos responsáveis
pelo processo de desenvolvimento das organizações.
Conforme descrito na problematização (Seção 1.1), este trabalho avaliou, através da abordagem
GQM, um sistema especialista que possui uma estrutura de diálogos automatizados para apoiar o
mapeamento do ciclo de vida e processo de desenvolvimento de organizações intensivas em software
baseado em árvores de decisão, que tem por objetivo contribuir com a redução do custo final de
implementações na área de MPS, na adequação e na aderência aos resultados esperados com o uso do
sistema especialista.
5.2.1 Avaliação pelo Método GQM
O principal objetivo deste estudo quantitativo é efetuar uma avaliação os resultados produzidos
pelo sistema especialista em organizações intensivas em software e por especialistas em MPS.
Portanto, visando um melhor direcionamento desta pesquisa e as hipóteses relacionadas a esta questão,
os objetivos (goals) da abordagem GQM foram elaborados para avaliação quantitativa.
Seguindo a definição proposta pela abordagem GQM, nos Quadros 11 e 12 são detalhadas as
questões relacionadas a adequação e aderência para a avaliação dos resultados emitidos pelo sistema
especialista, relacionadas a cada objetivo proposto.
Adequação
121
Quadro 11. Definição das métricas para o objetivo G1 segundo a abordagem GQM
Objetivo 1)
Propósito: Adequar
Questão: Base de Conhecimento
Objetivo: Abranger grande parte do conteúdo da melhoria de processo de software
Ponto de vista: Analisado pelo ponto de vista dos especialistas
Questão 1.1: A quantidade de perguntas é adequada à quantidade estimada de fases de um ciclo de
vida de desenvolvimento de software?
Questão 1.2: O conteúdo do sistema especialista é adequado às situações praticadas nas
organizações?
Questão 1.3: As perguntas descritas no sistema especialista estão adequadas a realidade de cada fase
do ciclo de desenvolvimento de software?
Questão 1.4: As perguntas descritas no sistema especialista estão adequadas com a realidade de um
especialista, ao entrevistar uma organização?
Questão 1.5: A execução da avaliação do ciclo de vida de desenvolvimento de software através de
diálogos automatizados (SE) está de acordo com a primeira etapa de avaliação de um processo de
melhoria de desenvolvimento de software?
Questão 1.6: O resultado do diálogo automatizado (SE) é tão confiável quanto o resultado de um
diálogo verbal feito por um especialista na área de melhoria de processo de software?
Aderência
Quadro 12. Definição das métricas para o objetivo G2 segundo a abordagem GQM
Objetivo 2)
Propósito: Aderir
Questão: Abordagem proposta
Objetivo: Confrontar os resultados da abordagem com a realizada das organizações
Ponto de vista: Gerentes e Diretores das organizações entrevistadas
122
Questão 2.1: Os resultados obtidos com a execução do sistema especialista estão aderentes com a
realidade da organização?
Questão 2.2: O ciclo de vida identificado pelo sistema especialista corresponde ao ciclo de vida de
desenvolvimento da organização?
Questão 2.3: As fases do ciclo de vida da organização estão aderentes ao resultado do sistema
especialista?
Questão 2.4: Os resultados são aderentes ao ciclo de vida da organização?
Questão 2.5: As perguntas realizadas no sistema especialista permitem entender a estrutura da
abordagem para a identificação do processo de desenvolvimento da organização?
Questão 2.6: O sistema especialista e seus resultados contribuem positivamente para a área de MPS
da organização?
Hipótese: a avaliação foi planejada para testar a seguinte hipótese (nula e alternativa) a respeito dos
indicadores de adequação e aderência:
H1: O ciclo de vida e processo de desenvolvimento de software de uma organização
pode ser mapeado através de uma abordagem baseada em diálogos automatizados
realizados com base em árvores de decisão, trazendo resultados confiáveis aos
resultados obtidos por um especialista da área de melhoria de processo.
Por se tratar de avaliações subjetivas, os procedimentos para obtenção de métricas subjetivas
fundamentam-se na realização de entrevistas com avaliadores que possuam experiência com melhoria
de processos e entrevistas com as organizações desenvolvedoras de software. Cada uma das questões
possui um conjunto de resultados possíveis classificados por importância conforme o Quadro 13. A
distribuição de métricas para avaliação subjetiva estão ilustradas no Quadro 14.
Quadro 13. Métricas para avaliação da abordagem.
Métrica Descrição
M1 Quantidade de pessoas que responderam “Concordo totalmente”
123
M2 Quantidade de pessoas que responderam “Concordo parcialmente”
M3 Quantidade de pessoas que responderam “Discordo parcialmente”
M4 Quantidade de pessoas que responderam “Discordo totalmente”
M5 Quantidade de pessoas que responderam “Indiferente”
Cada uma das métricas subjetivas é obtida através da soma das respostas obtidas para a questão
específica. Para possibilitar avaliações subjetivas pelo questionário a ser realizado, adota-se um
conjunto de atributos classificados por importância, conforme apresentado no Quadro 14. Para
computar o valor atribuído a cada métrica em cada questão específica, um somatório de respostas é
realizado para cada atributo, obtidas nos questionários aplicados na comunidade.
Quadro 14. Atributos de avaliação do framework
Atributos Classificação Subjetiva Correspondência Numérica
A1 Concordo Totalmente > 75%
A2 Concordo Parcialmente 51~75%
A3 Discordo Parcialmente 26~50%
A4 Discordo Totalmente < 26%
Indiferente - Sem opinião definida* -
* não contribui para a avaliação, atuando como uma possibilidade ao respondente em isentar-se daquela questão.
Assim para que cada uma das questões tenha um valor computado, realiza-se a interpretação da
contribuição da abordagem proposta através de configurações descritas no Quadro 15 para os fatores
de adequação da abordagem, alinhados ao objetivo G1 e no Quadro 16 para a aderência aos
resultados da abordagem, alinhados ao objetivo G2. Cada uma das métricas descritas anteriormente
conduz a um atributo de comparação que subtraído a média dos atributos, permite a interpretação
daquela questão específica dentro do contexto avaliado.
Quadro 15. Interpretação da adequação da abordagem*
Expressão Interpretação
A1 > MÉDIA (A2, A3, A4) A abordagem proposta está totalmente adequada a área de melhoria
de processos de software.
A2 > MÉDIA (A1, A3, A4) A abordagem proposta está parcialmente de modo positivo
adequada a área de melhoria de processos de software.
A3 > MÉDIA (A1, A2, A4) A abordagem proposta está parcialmente de modo negativo
adequada a área de melhoria de processos de software.
A4 > MÉDIA (A1, A2, A3) A abordagem proposta impede ou restringe a adequação a área de
melhoria de processos de software.
* lido da seguinte forma: “Se Expressão então Interpretação”.
124
Quadro 16. Interpretação da aderência da abordagem*
Expressão Interpretação
A1 > MÉDIA (A2, A3, A4) A abordagem proposta está totalmente aderente a realidade da
organização.
A2 > MÉDIA (A1, A3, A4) A abordagem proposta está parcialmente de modo positivo aderente
a realidade da organização.
A3 > MÉDIA (A1, A2, A4) A abordagem proposta está parcialmente de modo negativo aderente
a realidade da organização.
A4 > MÉDIA (A1, A2, A3) A abordagem proposta impede ou restringe a aderência a realidade
da organização.
* lido da seguinte forma: “Se Expressão então Interpretação”.
5.3 RESULTADOS
Através dos questionários de avaliação apresentados nos Apêndices C e D, os participantes
relataram suas impressões a respeito das contribuições obtidas em termos de adequação e aderência
com a adoção do sistema especialista com forma de diálogo automatizado para mapear o ciclo de vida
e processo de desenvolvimento de software de organizações intensivas em software.
5.3.1 Perfil dos participantes
O Quadro 17, informa o perfil das organizações participantes no processo de avaliação do
sistema especialista. Cada organização recebeu um código, denominado O1, O2 até O6, o que mantém
a confidencialidade das organizações.
Quadro 17. Perfil das organizações
Porte Principal atividade Possui processo formal? Tipo de produto de
software
O1 Médio Desenvolver software
padrão com customizações
para clientes
Ainda não possui um processo
formal, pois o mesmo está em
fase de implantação
Software voltado para
web e desktop
O2 Médio Desenvolver software
padrão com customizações
para clientes
Possui processo definido pela
empresa com base nos
conceitos do CMMI.
Desenvolve software
voltado para desktop
O3 Médio Software por encomenda
(fábrica)
Não, mas pretende implantar
em 2015
- Software voltado para
web
- Prestação de serviços
O4 Médio Desenvolver software
padrão com customizações
para clientes
Não - Software voltado para
web
O5 Médio Software por encomenda
(fábrica)
Sim. Nível G – MPS.BR Desenvolve software
voltado para desktop
125
O6 Médio Software por encomenda
(fábrica)
Sim. A base é cascata
(desenvolvimento de software)
e PMBOK (gerenciamento de
projetos)
- Software voltado para
web
- Prestação de serviços
O Quadro 18, apresenta o perfil dos entrevistados nas organizações que participaram da
avaliação do sistema especialista. A organização O5 teve a presença de 2 profissionais participando da
entrevista e execução ao sistema especialista.
Quadro 18. Perfil dos entrevistados nas organizações
Cargo Tempo na organização Conhecimento
em MPS
Conhecimento
de MPS.BR
Conhecimento
de CMMI
O1 Coordenador de
desenvolvimento
1 ano e 10 meses Sim Não Sim
O2 Gerente de
projeto
5 anos Sim Não Sim
O3 Gerente de
operações
7 anos Sim Sim Sim
O4 Scrum Master 6 meses Sim Não Sim
O5 Gerente de
desenvolvimento
10 anos Sim Sim Sim
O5 Coordenador de
desenvolvimento
6 anos Sim Sim Sim
O6 Gerente de
projeto
1 ano e 8 meses Sim Sim Sim
O Quadro 19 apresenta o perfil dos especialistas em melhoria de processo de software, que
participaram da avaliação do sistema especialista.
Quadro 19. Perfil dos especialistas
Tempo de
experiência em
MPS
Empresas avaliadas
(Modelo MPS.BR)
Qtdade. de
implantações
(Modelo
MPS.BR)
Empresas
avaliadas
(Modelo
CMMI)
Qtdade. de
implantações
(Modelo
CMMI)
E1 20 anos 25 29 1 3
E2 5 anos 0 0 0 0
E3 8 anos 0 11 0 1
E4 13 anos 14 14 0 3
E5 11 anos 31 50 0 11
E6 2 anos 0 Acompanhou 2
implantações
0 0
E7 10 anos 2 5 0 0
126
5.3.2 Resultados das métricas subjetivas
Após a execução das entrevistas com os recursos da organização, o sistema especialista gerava
um relatório com pontos fortes, pontos fracos e possíveis melhorias do processo da organização. Em
seguida, através de um documento de avaliação o SE era avaliado conforme descrito na Seção 5.2.1.
Para avaliar cada objetivo, foi definido um conjunto de questões (Quadros 11 e 12). Para cada
questão, as respostas possíveis são: CT – Concordo Totalmente; CP – Concordo Parcialmente; IN –
Indiferente; DP – Discordo Parcialmente e DT – Discordo Totalmente.
A Figura 30, apresenta os resultados da avaliação das organizações desenvolvedoras de
software, em relação a cada atributo.
Figura 30. Avaliação GQM – Organizações
Fonte: Próprio autor
Na avaliação dos resultados do sistema especialista, sob o ponto de vista das organizações,
pode-se verificar uma forte tendência de respostas positivas (concordo totalmente e concordo
parcialmente). Pelo resultado parcial, há uma indicação inicial que o objetivo de aderência dos
resultados do diagnóstico realizado pelo sistema especialista está sendo alcançado. As organizações se
identificaram com as argumentações geradas e acreditam que estas informações podem ajuda-las a
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Organização 1 Organização 2 Organização 3 Organização 4 Organização5A
Organização5B
Organização 6
50
%
66
,66
%
83
,34
%
50
%
50
%
83
,33
%
50
%
16
,66
%
16
,66
%
50
%
50
%
50
%
16
,66
%
50
%
16
,66
%
Avaliação das organizações
CT CP DP DT I
127
encontrar possíveis melhorias no processo. Vale ressaltar que as organizações não responderam com
“discordo totalmente”.
Os especialistas também avaliaram os resultados do sistema especialista, conforme descrito na
Seção 5.2.1. Esses especialistas, executaram o SE simulando uma organização de desenvolvimento de
software. Eles puderam trabalhar no SE por diversas vezes, podendo avaliar de forma mais ampla os
resultados que o SE emite.
A Figura 31, apresenta os resultados da avaliação dos especialistas em melhoria de processo de
software em relação a cada atributo.
Figura 31. Avalição GQM – Especialistas
Fonte: Próprio autor
Na avaliação realizada com os especialistas também é possível verificar a tendência de
respostas positivas em relação à adequação dos resultados obtidos com o sistema especialista. As
respostas estão mais centradas em uma concordância parcial, demonstrando que o sistema especialista
precisa ainda ser evoluído. Um dos pontos identificados de melhoria está na fase de
gerenciamento/acompanhamento de projetos, na qual foram adicionadas perguntas e outras sofreram
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
70,00%
80,00%
90,00%
100,00%
Especialista 1 Especialista 2 Especialista 3 Especialista 4 Especialista 5 Especialista 6 Especialista 7
42
,86
%
14
,28
%
71
,43
%
57
,14
%
14
,28
%
57
,14
%
28
,57
%
57
,15
%
85
,72
%
28
,57
%
42
,86
%
71
,43
%
42
,86
%
28
,57
%
14
,28
%
14
,28
%
28
,57
%
Avaliação dos especialistas
CT CP DP DT I
128
um melhor detalhamento. Outra melhoria identificada está na adição de mais pontos fracos e fortes. Os
especialistas apontaram para algumas conclusões que podem ser incluídas nos resultados do SE.
Com relação a obtenção da métrica de adequação dos resultados do sistema especialista, os
especialistas demonstraram uma tendência em considerar os atributos A1 - “Concordo totalmente” e
A2 - “Concordo parcialmente”, em aproximadamente 28,57% e 53,06% das questões, respectivamente,
conforme detalhado na Figura 31. Os atributos A3 - “Discordo parcialmente” e A4 - “Discordo
totalmente” obtiveram respectivamente 14,29% e 4,08% de respostas. Nenhuma resposta foi obtida
para o atributo A5 - “Indiferente”, conforme ilustra o gráfico.
Figura 32. Distribuição das respostas de acordo com a classificação (Especialistas)
Fonte: Próprio autor
Com relação a obtenção da métrica de aderência aos resultados do sistema especialista, as
organizações demonstraram uma tendência em considerar os atributos A1 - “Concordo totalmente” e
A2 - “Concordo parcialmente”, em aproximadamente 54,76% e 35,71% das questões, respectivamente,
conforme detalhado na Figura 32. Os atributos A3 - “Discordo parcialmente” e A5 - “Indiferente”
obtiveram respectivamente 7,14% e 2,38% de respostas. Nenhuma resposta foi obtida para o atributo
A4 - “Discordo totalmente”, conforme ilustra o gráfico.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Concordototalmente
Concordoparcialmente
Discordoparcialmente
Discordototalmente
Indiferente
28
,57
%
53
,06
%
14
,29
%
4,0
8%
Avaliação dos especialistas - por atributo
129
Figura 33. Distribuição das respostas de acordo com a classificação (Organizações)
Fonte: Próprio autor
O Quadro 20 apresenta, para cada questão, o atributo (conforme orientação do Quadro 14)
relacionado à opção de resposta mais indicada pelos participantes. Juntamente com o atributo, nesta
coluna é apresentada a informação do percentual que esta opção de resposta mais indicada obteve em
relação ao total de participantes. Com base nisso as médias e interpretações descritas nos Quadros 14,
15 e 16 foram realizadas, resultando na coluna “MÉDIA”.
O percentual apresentado na coluna média é obtido da seguinte maneira: primeiramente
verifica-se qual atributo a opção de resposta mais indicada representa (conforme parâmetros do Quadro
13). Com base nisso e de acordo com o objetivo que está sendo avaliado, aplica-se uma das
interpretações indicadas (Quadro 15 e 16). Por exemplo, para o objetivo da adequação na questão 1.1,
obteve-se 1 resposta indicando “Concordo totalmente”, 5 respostas indicando “Concordo
parcialmente” e 1 resposta indicando “Discordo parcialmente”. Observando o Quadro 14, a opção mais
indicada (71,43%) encontra-se dento do conjunto de valores do atributo A2 (conforme Quadro 14).
Dessa forma, a média foi realizada entre os atributos A1, A3 e A4 (14,29% + 14,29% + 0%)/3) tendo
em vista que A2 > MEDIA (A1, A2 e A4).
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Concordototalmente
Concordoparcialmente
Discordoparcialmente
Discordototalmente
Indiferente
54
,76
%
35
,71
%
7,1
4%
2,3
8%
Avaliação das organizações - por atributo
130
Quadro 20. Interpretação da avaliação subjetiva da abordagem.
Questão Atributo – Valor Média
Questão 1.1 A2 – 71,43% 9,52%
Questão 1.2 A2 – 71,43% 9,52%
Questão 1.3 A2 – 71,43% 9,52%
Questão 1.4 A2 – 57,14% 14,29%
Questão 1.5 A3 – 42,86% 28,57%
Questão 1.6 A3 – 42,86% 19,05%
Questão 1.7 A2 – 71,43% 23,81%
Adequação 61,23% 17,46%
Questão 2.1 A2 – 57,14% 14,28%
Questão 2.2 A2 – 57,14% 19,04%
Questão 2.3 A2 – 71,43% 23,81%
Questão 2.4 A2 – 57,14% 14,28%
Questão 2.5 A2 – 71,43% 28,57%
Questão 2.6 A2 – 57,14% 23,81%
Aderência 61,90% 20,63%
5.3.3 Avaliação
Uma análise adicional realizada a partir das respostas fornecidas pelos participantes consiste
em organizar os principais comentários e críticas realizadas e efetuar possíveis correções no sistema
especialista. O Quadro 21 expõe os comentários realizados por dois participantes, relacionando o
questionário aplicado com o SE, para contribuição na melhoria de processo de desenvolvimento de
software. São apresentadas as avaliações ao sistema especialista, por um especialista e por um
entrevistado de uma das organizações participantes. Os mesmos foram selecionados levando em
consideração que as suas justificativas foram as que melhor justificaram suas respostas contribuindo
assim para a melhoria do SE.
De maneira geral, os comentários acerca do sistema especialista direcionam a uma melhoria
contínua em relação ao conteúdo apresentado. As sugestões propostas pelo especialista 4 se
apresentaram realmente interessantes e instigaram numa melhoria em incrementar o sistema
especialista com mais perguntas e melhorar o direcionamento das respostas. No caso do especialista 4,
nem todas as questões foram justificadas pelo entrevistado. As justificativas apresentadas pelo
entrevistado da organização 5, demonstram que o sistema especialista atinge o objetivo de mapear o
processo de uma organização de desenvolvimento de software.
131
Quadro 21. Avaliação dos entrevistados
Especialista 4 Possui 13 anos de experiência em melhoria de processo de software,
14 empresas avaliadas no modelo MPS.BR, 14 implantações do
modelo MPS.BR e 3 implantações no modelo CMMI.
Questão 1.2 O conteúdo do sistema especialista é adequado às situações praticadas
nas organizações?
Resposta: Concordo parcialmente
Justificativa Algumas atividades são executadas pelo mesmo papel, principalmente
em empresas pequenas. Por exemplo, mesmo havendo uma fase e
atividades de testes na empresa que utilizei como exemplo, ela é
realizada pelo analista de sistemas, não existindo figura ou papel de
testador ou analista de testes.
O analista de sistemas também executa o papel de documentador, por
exemplo, o que não pôde ser explicado no sistema.
Questão 1.4 As perguntas descritas no sistema especialista estão adequadas com a
realidade de um especialista, ao entrevistar uma organização?
Resposta: Concordo parcialmente
Justificativa Nas fases iniciais de planejamento e levantamento de requisitos até
podemos dizer que sim. Somente acho que as perguntas que falam a
respeito do acompanhamento de projetos são muito superficiais, assim
como alguns detalhes do planejamento que são explorados. Não percebi
perguntas de como tratar problemas e desvios, assim como alterações de
requisitos durante o desenvolvimento. Não percebi pergunta específica
para a rastreabilidade de requisitos, por exemplo.
Questão 1.6 O resultado do diálogo automatizado (SE) é tão confiável quanto o
resultado de um diálogo verbal feito por um especialista na área de
melhoria de processo de software?
Resposta: Discordo parcialmente
Justificativa Não é tão confiável pois algumas questões precisariam ser mais
detalhadas. No caso da empresa exemplo o resultado apresenta: Ele
estima o projeto em unidade de tempo, não utiliza pontos de função,
utiliza um cronograma para o escopo do projeto e faz revisão do mesmo.
Não há como explicar qual o método de estimativas utilizado o que
normalmente seria questionado, que neste exemplo seria com base na
complexidade de cada requisito e valores específicos para as etapas de
planejamento.
Organização 5 O entrevistado, responsável pelo setor de desenvolvimento possui 6
anos de trabalho na organização, é coordenador de desenvolvimento
e tem conhecimentos em MPS, nos modelos MPS.BR e CMMI
Questão 2.1 Os resultados obtidos com a execução do sistema especialista estão
aderentes com a realidade da organização?
132
Resposta: Concordo parcialmente
Justificativa Em parte são aderentes, porém como temos uma metodologia de gestão
dos projetos diferenciada, alguns itens não se enquadram adequadamente.
Questão 2.2 O ciclo de vida identificado pelo sistema especialista corresponde ao
ciclo de vida de desenvolvimento da organização?
Resposta: Concordo totalmente
Justificativa Sim! Possuem nomenclaturas um pouco diferentes, mais são abordados
todos os ciclos da organização.
Questão 2.3 As fases do ciclo de vida da organização estão aderentes ao resultado do
sistema especialista?
Resposta: Concordo parcialmente
Justificativa Alguns pontos do projeto, possuem um tratamento distinto do sugerido
pelo sistema especialista, principalmente pelo fato de possuirmos uma
metodologia própria para gestão do projeto.
Questão 2.4 Os resultados são aderentes ao ciclo de vida da organização?
Resposta: Concordo parcialmente
Justificativa São parcialmente, pois alguns pontos possuem tratamentos distintos em
nossa organização.
Questão 2.5 As perguntas realizadas no sistema especialista permitem entender a
estrutura da abordagem para a identificação do processo de
desenvolvimento da organização?
Resposta: Concordo totalmente
Justificativa Avaliando as perguntas e as respostas, é possível compreender o
processo da organização.
Questão 2.6 O sistema especialista e seus resultados contribuem positivamente para a
área de MPS da organização?
Resposta: Concordo totalmente
Justificativa Sim! Como os questionamentos são relacionados a gestão dos projetos,
contribuem com as boas práticas de gestão, auxiliando no cumprimento
dos requisitos da MPS.
5.3.4 Síntese dos resultados
Tendo finalizados os procedimentos de avaliação para coleta das métricas subjetivas, é
possível sintetizar o resultado obtido no Quadro 22. Nela são apresentados os objetivos da avaliação
133
(G1 – adequação e G2 – aderência), suas questões relacionadas e as métricas que as compõe. São
demonstradas também as medições obtidas através do questionário (na forma de uma expressão
matemática de comparação) e nos procedimentos de avaliação (na forma de um coeficiente percentual)
que representa o atendimento de um determinado atributo de resposta que aponta, por sua vez, a
síntese obtida para aquela questão e objetivo.
Quadro 22. Avaliação dos dados
Objetivo Questão Métrica(s) Medição Resposta Síntese
G1 1.1 M1, M2, M3, M4 71,43% > 9,52% A2 A abordagem proposta está
parcialmente de modo positivo
adequada a área de melhoria
de processos de software.
G1 1.2 M1, M2, M3, M4 71,43% > 9,52% A2 A abordagem proposta está
parcialmente de modo positivo
adequada a área de melhoria
de processos de software.
G1 1.3 M1, M2, M3, M4 71,43% > 9,52% A2 A abordagem proposta está
parcialmente de modo positivo
adequada a área de melhoria
de processos de software.
G1 1.4 M1, M2, M3, M4 57,14% > 14,29% A2 A abordagem proposta está
parcialmente de modo positivo
adequada a área de melhoria
de processos de software.
G1 1.5 M1, M2, M3, M4 42,86% > 28,57% A3 A abordagem proposta está
parcialmente de modo
negativo adequada a área de
melhoria de processos de
software.
G1 1.6 M1, M2, M3, M4 42,86% > 19,05% A3 A abordagem proposta está
parcialmente de modo
negativo adequada a área de
melhoria de processos de
software.
G1 1.7 M1, M2, M3, M4 71,43% > 23,81% A2 A abordagem proposta está
parcialmente de modo positivo
adequada a área de melhoria
de processos de software.
G2 2.1 M1, M2, M3, M4 57,14% > 14,28% A2 A abordagem proposta está
parcialmente de modo positivo
aderente a realidade da
organização.
134
G2 2.2 M1, M2, M3, M4 57,14% > 19,04% A2 A abordagem proposta está
parcialmente de modo positivo
aderente a realidade da
organização.
G2 2.3 M1, M2, M3, M4 71,43% > 23,81% A2 A abordagem proposta está
parcialmente de modo positivo
aderente a realidade da
organização.
G2 2.4 M1, M2, M3, M4 57,14% > 14,28% A2 A abordagem proposta está
parcialmente de modo positivo
aderente a realidade da
organização.
G2 2.5 M1, M2, M3, M4 71,43% > 28,57% A2 A abordagem proposta está
parcialmente de modo positivo
aderente a realidade da
organização.
G2 2.6 M1, M2, M3, M4 57,14% > 23,81% A2 A abordagem proposta está
parcialmente de modo positivo
aderente a realidade da
organização.
Considerando a síntese exposta, é possível listar os resultados obtidos com relação a cada uma
das questões de avaliação, realizar uma interpretação da medição obtida, do procedimento de avaliação
e lacunas evidenciadas durante o processo:
Questão 1.1: O sistema especialista proposto pode contribuir com a melhoria de
processo pois possui uma quantidade de perguntas adequadas à quantidade estimada de
fases de um ciclo de vida de desenvolvimento de software, visto que 71,43% dos
especialistas concordaram parcialmente com esta afirmação. Apesar disso, uma das
justificativas dentre os especialistas, ressalta a necessidade de agrupar as perguntas para
que o questionário do SE se torne menor.
Questão 1.2: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está adequado às situações praticadas nas organizações, visto que 71,43%
dos especialistas concordaram parcialmente com esta afirmação. Apesar disso, uma das
justificativas dentre os especialistas, ressalta que o SE não trata a execução de várias
funções para o mesmo papel, na qual, como solução foi inserir mais opções de cargos
para perguntas que tratam as diversas funções dentro de um setor de desenvolvimento.
135
Outra solução foi inserir pontos fracos para que a organização avaliada possa tratar a
questão de possuir um recurso executando diversas funções.
Questão 1.3: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está adequado com perguntas que descrevem a realidade de cada fase do
ciclo de vida de desenvolvimento do software, visto que 71,43% dos especialistas
concordaram parcialmente com esta afirmação. Apesar disso, uma das justificativas
dentre os especialistas, ressalta que as questões do SE não abordam de forma completa
o processo de software e em outros casos as questões ficaram descontextualizadas.
Como solução foram inseridas mais questões e em outros casos, as mesmas foram
alteradas, para que pudessem se encaixar melhor no contexto da fase do ciclo de vida
que se encontram.
Questão 1.4: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está adequado com perguntas que descrevem a realidade de um
especialista, ao entrevistar uma organização, visto que 57,14% dos especialistas
concordaram parcialmente com esta afirmação. Uma das justificativas dentre os
especialistas sugere incluir mais perguntas em relação ao acompanhamento de projetos
e rastreabilidade de requisitos. Em outra justificativa, um dos especialistas relata que os
questionamentos não são apresentados de uma só vez, mas sim, tratados de forma mais
genérica, num primeiro momento, e num segundo momento os assuntos se especializam
e se aprofundam conforme a entrevista vai sendo conduzida.
Questão 1.5: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está adequado com perguntas que estão de acordo com a primeira etapa
de avaliação de um processo de melhoria, visto que 42,86% dos especialistas
concordaram parcialmente de modo negativo com esta afirmação. Uma das
justificativas, dentre os especialistas, concorda que num primeiro momento, esta
avaliação, feita pelo SE, é executada, mas falta a cobertura mais ampla de algumas
fases.
Questão 1.6: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está adequado com perguntas que geram um resultado tão confiável
quanto o resultado de um diálogo verbal feito por um especialista, visto que 42,86% dos
136
especialistas concordaram parcialmente de modo negativo com esta afirmação. Uma das
justificativas, dentre os especialistas, é em relação a falta de interação entre o
entrevistado e o entrevistador, caracterizando um ponto frágil, segundo o especialista.
Outra justificativa seria em relação a necessidade de um detalhamento maior das
questões.
Questão 1.7: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está adequado com a possibilidade de levantar pontos fortes, pontos
fracos e oportunidades de melhorias com os resultados gerados, visto que 71,43% dos
especialistas concordaram parcialmente com esta afirmação. Uma das justificativas,
dentre os especialistas, é que ainda falta uma melhor cobertura das fases do ciclo de
vida de desenvolvimento do software.
Questão 2.1: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está aderente com a realidade da organização em relação aos resultados
gerados, visto que 57,14% dos entrevistados concordaram parcialmente com esta
afirmação. Uma das justificativas entre os entrevistados, é em relação a dificuldade em
encaixar os termos e as fases ao processo de desenvolvimento da organização. Outra
justificativa, é que em relação a metodologia de gestão de projetos da organização, ser
diferenciada, na qual algumas questões não se enquadraram adequadamente.
Questão 2.2: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está aderente com a realidade da organização identificando o seu ciclo de
vida de desenvolvimento, visto que 57,14% dos entrevistados concordaram
parcialmente com esta afirmação. Uma das justificativas entre os entrevistados, é em
relação a nomenclatura que não ficou de acordo com a adotada pela organização. Em
outra justificativa o entrevistado relata a falta de perguntas abordando o tratamento de
erros antes da entrega oficial para o mercado. Como resposta a esta última justificativa é
possível incrementar a fase de testes, incluindo questões de tratamento de erros antes da
entrega oficial.
Questão 2.3: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está aderente às fases do ciclo de vida da organização com o resultado
gerado pelo SE, visto que 71,43% dos entrevistados concordaram parcialmente com
137
esta afirmação. Uma das justificativas entre os entrevistados, é que em algumas
atividades do projeto, há um tratamento distinto do sugerido pelo sistema especialista.
Questão 2.4: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está aderente com o ciclo de vida da organização em relação ao resultado
gerado pelo SE, visto que 57,14% dos entrevistados concordaram parcialmente com
esta afirmação. Uma das justificativas entre os entrevistados, é que a organização possui
tratamentos distintos em algumas fases do ciclo de vida.
Questão 2.5: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está aderente com perguntas que permitem entender a estrutura do
processo da organização, visto que 71,43% dos entrevistados concordaram parcialmente
com esta afirmação. Uma das justificativas entre os entrevistados, é que o sistema
especialista tratar de forma mais ampla algumas fases com perguntas mais específicas.
Questão 2.6: O sistema especialista proposto pode contribuir com a melhoria de
processo pois está aderente com os resultados gerados, visto que 57,14% dos
entrevistados concordaram parcialmente com esta afirmação. Uma das justificativas
entre os entrevistados, é que o resultado trouxe uma situação que para ele não se
encaixa com a organização. Em uma das perguntas foi respondido que não fazem
análise de risco do projeto. Entretanto, a conclusão do sistema especialista foi que é
preciso fazer análise de risco criando protótipos de tela, validando com o cliente e
fazendo refinamentos. Segundo o entrevistado, esse processo é executado pelo designer
de iteração e é fundamental para definir os requisitos. Não entende-se isso como uma
análise de riscos. A solução foi melhorar as perguntas relacionadas aos riscos do
projeto.
De um modo geral, a interpretação dos resultados da avaliação responde à questão de pesquisa
apontada na problematização deste trabalho (Seção 1.1.1) ao afirmar que “uma abordagem baseada em
diálogos automatizados, no contexto de um ambiente de diagnóstico semi automatizado, permite
modelagem inicial do ciclo de vida adotado em organizações intensivas em software”, possibilitando o
mapeamento do processo de desenvolvimento de software, através de um sistema especialista.
138
5.3.5 Considerações
Levando em consideração a participação de 6 organizações e 7 especialistas, há uma tendência
em considerar o sistema especialista, um recurso positivo, em relação aos seus resultados, pode-se
considerar também, que esta pesquisa contribui efetivamente para a realização de um autodiagnostico
com resultados próximos ao de um especialista em MPS. Também há uma tendência positiva na
utilização do sistema especialista como um meio de obtenção de melhoria no processo de
desenvolvimento de software das organizações.
Embora o número de especialistas MPS envolvidos na avaliação do SE seja pequeno (6
profissionais), a qualidade da avaliação pode-se considerar positiva, visto que no perfil dos mesmos,
há uma média de aproximadamente 10 anos em experiência com melhoria de processos e uma média
de aproximadamente 19 implantações e 10 avaliações, aos modelos MPS.BR e CMMI, uma média
considerável para a avaliação exigida nesta pesquisa.
Não pode-se descartar também, os riscos que uma avaliação pode ter com 14 profissionais,
entre organizações e especialistas MPS, participando. Riscos esses que podem acarretar na
inviabilidade de se ter um sistema especialista mapeando o desenvolvimento de organizações de
grande porte. Inviabilidade essa, que caracteriza uma dispersão dos resultados que pode ser alvo de
aprimoramentos futuros.
Para esses riscos, o trabalho buscou com as avaliações dos especialistas e organizações, corrigir
alguns pontos dentro do sistema especialista que pudessem gerar um mapeamento de processo
incompleto, do ponto de vista de uma possível discordância de resultados, caso o sistema seja
executado em grandes organizações. Após as avaliações, buscou-se também, executar o sistema
novamente, com 2 especialistas MPS mais experientes e que pudessem apontar possíveis causas de
insucesso, nos resultados emitidos pelo SE.
Apesar dos riscos apresentados, pode-se considerar que o fato de haver um sistema especialista,
com tendências positivas aos resultados, já demonstra uma contribuição na melhoria no processo de
desenvolvimento de organizações intensivas em software.
Em relação as avaliações GQM, as mesmas precisam de refinamento e adaptação constante,
portanto as métricas definidas devem auxiliar não só na avaliação do objeto de estudo, mas também na
confiabilidade do modelo utilizado para avaliação (BASILI; CALDIERA; ROMBACH, 1994). Deste
139
modo, pretende-se ainda a utilização dos resultados obtidos como modelo para avaliações futuras
realizadas sobre o sistema especialista, a fim de obter dados mais abrangentes sobre as contribuições
possíveis da ferramenta a processos de melhoria de software.
Os resultados obtidos com a avaliação da abordagem, alinhados aos objetivos deste trabalho
(Seção 1.2) serve ainda, para apontar evidências das contribuições obtidas, verificar as hipóteses
supostas, além de identificar lacunas e oportunidades de pesquisa ou manutenção da abordagem em
situações futuras.
140
6 CONCLUSÃO
Este trabalho propôs um estudo de continuação da proposta desenvolvida por Moreira (2012)
na qual foi desenvolvida uma abordagem para diagnóstico semi automatizado. Entretanto a pesquisa de
Moreira (2012) ficou limitada aos processos de análise de requisitos e gerência de projetos, do nível G
do MPS.BR.
Sendo assim, foi realizado um estudo de planejamento, elaboração e avaliação de uma
abordagem automatizada, ou seja, um sistema especialista, que apoie organizações desenvolvedoras de
software no diagnóstico inicial do seu processo de desenvolvimento, mapeando seu ciclo de vida. Para
tanto, foram necessários estudos específicos sobre a área, envolvendo pesquisas em melhoria de
processo, avaliação de processos, diagnósticos, levantamento de ciclo de vida e ferramentas que dão
suporte a condução de um processo de melhoria de software.
O presente estudo inclui uma análise mais abrangente do processo de desenvolvimento de
organizações intensivas em software utilizando referências em modelos de capacidade e maturidade
(MPS.BR e CMMI) na norma ISO/IEC 12207 e em processos conhecidos de desenvolvimento de
software (XP, Scrum e RUP).
A fim de alcançar o objetivo geral, foi desenvolvida uma abordagem de autodiagnostico para
apoiar o mapeamento do ciclo de vida e processo de desenvolvimento de software. Para tal, foram
analisadas metodologias de avaliação de ciclos de vida de desenvolvimento e ferramentas de
autodiagnostico, por meio de mapeamento sistemático, árvores de decisão, regras de produção, sistema
especialista, entrevistas com especialistas e organizações de desenvolvimento de software.
Ainda dentro dos objetivos deste trabalho é possível analisar cada objetivo específico conforme
descrito abaixo:
1) Mapear os diferentes processos de desenvolvimento de software, adotado por
organizações, a partir das características das mesmas. Este objetivo foi alcançado
baseado na construção das árvores de decisão, que através de perguntas e respostas
conseguem, descrever o processo de desenvolvimento de uma organização;
141
2) Desenvolver um sistema especialista que possa trazer como resultados pontos fracos,
pontos fortes e oportunidades de melhoria no processo de desenvolvimento de software
adotado por uma organização. Este objetivo foi alcançado com o desenvolvimento de
um sistema especialista que apresenta resultados relevantes ao processo de
desenvolvimento, facilitando para os responsáveis da organização, observar possíveis
pontos de melhoria;
3) Desenvolver uma base de conhecimento que apoie o sistema especialista. A primeira
etapa do desenvolvimento da mesma foi o mapeamento sistemático e com base nele,
árvores de decisão foram construídas. Também foram realizadas entrevistas com
gerentes de projetos e especialistas em MPS que contribuíram na modelagem das
árvores. Por fim, foi possível criar regras de decisão que serviram de base para o
desenvolvimento do sistema especialista;
4) Integrar as árvores de decisão deste trabalho com o conhecimento das árvores de
decisão desenvolvidas em Moreira (2012). Perguntas relacionadas à análise de
requisitos e gerência de projetos presentes nas árvores de decisão do trabalho de
Moreira (2012) foram integradas nas árvores de decisão construídas para o presente
estudo; e
5) Avaliar o sistema especialista com especialistas e a partir de sua aplicação em empresas
reais de desenvolvimento de software. Este objetivo foi obtido na forma de avaliações
realizadas tanto por organizações da região de Joinville e Blumenau, como por
especialistas de diversas partes do país. Os resultados descritos na Seção 5.3 evidenciam
que a adoção de uma ferramenta de sistema especialista pode contribuir positivamente
para a melhoria no processo de software.
A execução da abordagem proposta na forma de uma ferramenta especialista pretende
apresentar para as organizações um mapeamento detalhado de como funciona o seu processo de
desenvolvimento de software. Para tanto optou-se pela obtenção de resultados através da aplicação da
abordagem GQM que avaliou a adequação dos resultados emitidos pelo SE na visão de especialistas
em MPS e a aderência dos resultados sob a visão dos responsáveis.
142
Considerando as hipóteses (Seção 1.1.1) e tendo por fundamento as contribuições da
ferramenta de sistema especialista, tornou-se possível a elaboração desta avaliação, tratando dos
impactos destas em fatores de adequação e aderência do processo. Neste contexto, a adequação é
obtida com as avaliações realizadas pelos especialistas em MPS, que garantem a confiabilidade das
informações do SE, e a aderência mediante a execução do SE pelas organizações que avaliaram os
resultados e asseguram a qualidade dos mesmos. Para tal avaliação, optou-se pela obtenção de
métricas, com adoção da abordagem GQM, através de um questionário direcionado a especialistas em
MPS e organizações de software. Sendo assim é possível afirmar, com base nos resultados da
abordagem GQM, que um diálogo automatizado traz resultados que podem ser similares aos resultados
propostos por um especialista em MPS.
Por fim, pode-se afirmar que os objetivos propostos para este trabalho foram alcançados,
embora seja importante destacar que os resultados apresentados não são definitivos, sendo passíveis de
aprimoramentos e revisões, conforme identificados na Seção 6.2, trabalhos futuros.
6.1 PRINCIPAIS CONTRIBUIÇÕES
As principais contribuições apresentadas para este trabalho são:
Uma revisão informal que identificou trabalhos que apresentam abordagens para o uso
de ferramentas que auxiliam na melhoria de processos de software em organizações de
desenvolvimento.
Uma revisão formal, na forma de um mapeamento sistemático, que evidenciou por meio
de publicações acadêmicas, o atual estado da arte de metodologias que apoiam o estudo
aos processos de melhoria de software. O mapeamento sistemático, constatou a falta de
ferramentas que possam mapear o processo de desenvolvimento de software de uma
organização, trazendo como resultados pontos fortes, fracos e oportunidades de
melhoria. O mapeamento, em sua maioria, retornou trabalhos que apresentam
metodologias de avaliação inicial aderentes aos processos de melhoria baseados em
modelos de referência como CMMI e MPS.BR.
143
A construção de árvores de decisão que apoiaram o desenvolvimento do sistema
especialista, que traz como resultados pontos fortes, pontos fracos e oportunidades de
melhoria.
Desenvolvimento de uma ferramenta computacional que atendesse ao modelo de
abordagem proposto, considerando a estrutura de desenvolvimento definidas, e
disponível para organizações e especialistas em MPS; e
Avaliação da abordagem automatizada através de um questionário de avaliação com
organizações e especialistas MPS, objetivando demonstrar as melhorias obtidas em
fatores de adequação e aderência aos resultados da ferramenta SE, que podem ser
utilizados por outros profissionais para o mapeamento de seus processos de
desenvolvimento.
6.2 TRABALHOS FUTUROS
Ao término da pesquisa que resultou neste trabalho, foram identificadas as seguintes
oportunidades de trabalhos futuros:
Melhorar a interface do sistema especialista, possibilitando inserir dicas
autoexplicativas para cada pergunta. Essa medida facilita o entendimento a cada
questão, possibilitando que o usuário tenha uma melhor interpretação e responda
corretamente cada questão.
Permitir que o sistema especialista seja uma versão voltada para web, sendo possível
que os usuários acessem o sistema de qualquer lugar;
Inserir perguntas no sistema especialista que explorem as descrições organizacionais.
Através destas perguntas seria possível mapear o porte da organização, quantidade de
funcionários, papéis exercidos pelos principais responsáveis pelo processo de
desenvolvimento, entre outras informações pertinentes a organização e que contribuem
para um resultado mais amplo; e
Por fim, a possibilidade de incrementar o sistema especialista com análises de tomada
de decisão para os pontos fracos levantados nos resultados.
144
REFERÊNCIAS
ALMEIDA, C. D. A. Continuidade da Execução de Processos de Software em Empresas Avaliadas no
MPS.BR. 2011. 95f. Dissertação (Mestrado em Informática Aplicada), Universidade de Fortaleza
(UNIFOR), Fortaleza. 2011.
ANACLETO, A.; WANGENHEIM, C. G.; SALVIANO, C. Um método de avaliação de processos de
software em micro e pequenas empresas. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DE
SOFTWARE – SBQS, IV, Porto Alegre. Anais ... Porto Alegre: SBQS, 2005.
ANGELI, Chrissanthi. Online Expert Systems for Fault Diagnosis in Technical Processes. Expert
Systems. Wiley Online Library, May 2008. p. 115 - 132.
BARBIERI, C. BI – Business Intelligence: Modelagem e Tecnologia, Axcel Books, 2001.
BARROS, Renata P. Evolução, Avaliação e Validação do Software RoboEduc. 2011. 102f.
Dissertação (Mestrado em Engenharia Elétrica da UFRN (área de concentração: Engenharia da
computação)). Universidade Federal do Rio Grande do Norte (UFRN), Natal, 2011.
BASILI, V.R.; CALDEIRA, G.; ROMBACH, D.; The Goal Goal Question Metric Approach. In:
MARCINIAK, J.J. (editor). Encyclopedia of Software Engineering, v.2, New York, NY: John Wiley
& Sons, 1994.
BECK, K. Extreme Programming Explained: Embrace Change. 2. ed. Reading, Massachusetts:
Addison-Wesley, 2004.
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. Editora CAMPUS, 2002.
BHUVANESWARI, T.; PRABAHARAN, S. A Survey on Software Development Life Cycle Models.
International Journal of Computer Science and Mobile Computing - IJCSMC. v.2, n.5, p. 262 –
267, May 2013.
CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introdução a engenharia de software. Campinas:
Unicamp, 2001.
CERDEIRAL, C. Uma Abordagem para Gerência e Avaliação de Projetos de Melhoria de Processos
de Software do Ponto de Vista da Instituição de Consultoria. Dissertação (Mestrado em Ciências em
Engenharia de Sistemas e Computação) Programa de Pós-Graduação em Engenharia de Sistemas e
Computação, UFRJ, Rio de Janeiro, 2008.
CLARA, V. T. SDLC and Model Selection: A Study. International Journal of Application or
Innovation in Engineering & Management - IJAIEM. v.2, n.1, p. 273 – 277, January 2013.
COLETTA, Antonio. An Industrial Experience in Assessing the Capability of Non-software Processes
Using ISO/IEC 15504. Software Process: Improvement and Practice. Wiley InterScience, Mar. 2007.
p. 315 – 319.
145
COWELL, R.G.; DAWID, P.; LAURITZEN, S.L.; SPIEGELHALTER, D.J. Probabilistic Networks
and Expert Systems. 11ª ed. New York: Springer, 1999.
DUMKE, R. R.; SCHMIETENDORF, A.; KUNZ, M.; GORGIEVA, K. Software Metrics for Agile
Software Development. In: AUSTRALIAN SOFTWARE ENGINEERING CONFERENCE
(ASWEC). 19th, 2008. Perth, WA. Proceedings… IEEE Computer Society, 2008, p. 673 – 678.
ERICSSON, E.; GUSTAFSSON P.; HÖÖK, D.; MARCKS, V. W. L.; ROCHA, F. W. Process
Improvement Framework Evaluation. In: INTERNATIONAL CONFERENCE ON MANAGEMENT
SCIENCE & ENGINEERING, 17., 2010. Melbourne, Australia. Proceedings… IEEE Computer
Society, 2010, p. 319 – 326.
EL-EMAM, K.; SIMON, J.-M. ; ROUSSEAU, S.; JACQUET, E. Cost Implication of Interrater
Agreement for Software Process Assessments. In: SOFTWARE METRICS SYMPOSIUM, 50., 1998.
Bethesda, MD. Proceedings Fifth International Software Metrics Symposium. Metrics, 1998, p. 38
– 51.
EL-EMAM, K.; GOLDENSON, D. R. An Empirical Review of Software Process Assessment.
1999. Disponível em: <http://www.nrc-cnrc.gc.ca/eng/index.html>. Acesso em: Jan. 2014.
ENTINEX, Inc. How much does it cost? - CMMIFAQ. Disponível em: http://www.cmmifaq.info/.
Acesso em: Dezembro de 2013.
FELIZ, Tom. Lightweight Software Process Assessment and Improvement. In: PACIFIC
NORTHWEST SOFTWARE QUALITY CONFERENCE – PNSQC, 30., 2012, Portlan, Oregon.
Proceedings... PNSQC, 2012, p. 405 – 424.
FIGUEIRA FILHO, C. S. JEOPS – Integração entre Objetos e Regras de Produção em Java. 2000.
Dissertação de Mestrado. Universidade Federal de Pernambuco (UFPE), Recife. 2000.
FOJTIK, R. Extreme Programming in development of specific software. In: WORLD CONFERENCE
ON INFORMATION TECHNOLOGY – WCIT, 2., 2011, Antalya, TR. Proceedings Computer
Science. Elsevier, 2011, p. 1464–1468.
FUGGETTA, A. Software Process: A Roadmap. In: INTERNATIONAL CONFERENCE ON
SOFTWARE ENGINEERING – ICSE, 22., 2000, Limerick, Ireland. Proceedings of the Future of
Software Engineering. ACM Press, 2000, p. 25 – 34.
GARCIA, I.; ANDREA, I. Using the Software Process Improvement approach for defining a
Methodology for Embedded Systems Development using the CMMI-DEV v1.2. 10th IEEE
International Conference on Computer and Information Technology (CIT 2010). 2010.
GIBSON, D.L.; GOLDENSON, D.R.; KOST, K. Performance Results of CMMI-Based Process
Improvement, Technical Research CMU/SEI-2006-TR-004, Software Engineering Institute,
Pittsburgh, 2006. Disponível em: < http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8065>
Acesso em: Oct. 2013 Software Engineering Institute. Carnegie Mellon. 2006.
GRAY, E.; SAMPAIO, A.; BENEDIKTSSON, O. An Incremental Approach to Software Process
Assessment and Improvement. Software Quality Journal. v. 13, n.1, 2005. Disponível em: <
http://www.informatik.uni-trier.de/~ley/db/journals/sqj/sqj13.html>. Acesso em: Nov. 2013.
146
GREEN, G. C.; HEVNERB, A. R.; COLLINS, R.W. The impacts of quality and productivity
perceptions on the use of software process improvement innovations. Proceedings Information and
Software Technology. Elsevier, v. 47, n. 8, p. 543 – 553, Jun. 2005.
GUPTA, S.; AGGARWAL, A. Study of Software Development Process and Development Models.
International Journal of Research in Engineering & Applied Sciences - IJREAS. v.2, n.2, p. 1522
– 1528, February 2012.
HABRA, N.; ALEXANDRE, S.; DESHANAIRS, J.; LAPORTE, C. Y.; RENAULT, A. Initiating
software process improvement in very small enterprises - Experience with a light assessment tool.
Information and Software Technology. v.50, n. 7-8, p. 763-771, Jun. 2008.
HARMON, P.; KING, D. Artificial Intelligence In Business – Expert Systems. Wiley, New York.
1985.
HAYKIN, S. Introdução. Redes neurais: princípios e práticas. 2. ed. São Paulo-SP: Artmed
Editora. p. 27-74. 2008.12
HEIKKILÄ, M. Learning and Organizational Change in SPI Initiatives. Springer-Verlag Berlin
Heidelberg. p.216 – 230. 2009.
HUMPHREY, W. S. Managing the software process. Reading, Addison-Wesley (SEI series in
software engineering), 1989.
IBM. Rational Unified Process 2007. Disponível em:
<http://www.wthreex.com/rup/v711_sp_ptbr/index.htm>. Acesso em: Junho de 2013.
IBM. Rational Unified Process – Best Practices for Software Development Teams. Rational Software
White Paper TP026B, Rev 11/01. 2001.
IEEE Computer Society. SWEBOK. Guide to the Software Engineering Body of Knowledge.
Version 3.0. 2014.
IGNIZIO, J. P. Introduction to Expert Systems – The Development and Implementation of Rule-
Based Expert Systems. New York: McGraw-Hill, 1991.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 15504-1: Information
Technology – Process Assessment, 2004.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 12207: Systems and
software engineering - Software life cycle processes. 2008.
JÄRVINEN, J. Measurement Based Continuous Assessment of Software Engineering Process.
Technical Research Centre of Finland, Oulu, 2000. Disponível em <
http://www.vtt.fi/inf/pdf/publications/2000/P426.pdf>. Acesso em: Dezembro de 2013.
KALINOWSKI, M.; SANTOS, G.; REINEHR, S.; MONTONI, M.; ROCHA, A.R.; WEBER, K.C.;
TRAVASSOS, G.H. MPS.BR: A Tale of Software Process Improvement and Performance Results in
the Brazilian Software Industry. In: QUALITY OF INFORMATION AND COMMUNICATIONS
147
TECHNOLOGY - QUATIC, 70th, 2010, Porto. Proceedings… IEEE Computer Society, 2010, p. 412
– 417.
KAUR, R; SENGUPTA, J. Software Process Models and Analysis on Failure of Software
Development Projects. International Journal of Scientific & Engineering Research – IJSE. v. 2,
n.2, p. 1 – 4, February 2011
KELLER, R. Tecnologias do Sistema Especialista. São Paulo (SP); Mcgraw- Hill; 1991.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de Software. 2ª edição. São Paulo (SP); Novatec;
2007.
KHURANA, G.; GUPTA, S. Study & Comparison of Software Development Life Cycle Models.
International Journal of Research in Engineering & Applied Sciences - IJREAS. v.2, n.2, p. 1513
– 1521, February 2012.
KITCHENHAM, B.; CHARTERS, S. Guidelines for performing Systematic Literature reviews in
Software Engineering. EBSE Technical Report 2007-001, Keele University and University of Durha,
2007. Disponível em: <http://citeseerx.ist.psu.edu/viewdoc/download?
doi=10.1.1.154.1446&rep=rep1&type=pdf>. Acesso em: jan. 2014.
KRUCHTEN, P. Introduction to the Rational Unified Process, Addison-Wesley, 2000.
LARMAN, C. Software Development: Iterative & Evolutionary. 2004. Disponível em: <
http://www.informit.com/articles/article.aspx?p=102256> Acessado em: 05/04/2014
LAYMAN, L.; WILLIAMS, L.; DAMIAN, D.; BURES, H. Essential communication practices for
Extreme Programming in a global software development team. Information and Software
Technology. Science Direct. Elsevier. v. 48, p. 781–794, 2006.
LEAU, Yu Beng; LOO, Wooi Khong; THAM, Wai Yip; TAN Soo Fun. Software Development Life
Cycle Agile vs Traditional Approaches. In: INTERNATIONAL CONFERENCE ON
INFORMATION AND NETWORK TECHNOLOGY – ICINT, 2012, Singapore. Proceedings...
IPCSIT Press, 2012, p. 162 - 167.
LINARES, K. S. C. Sistema Especialista Nebuloso para Diagnóstico Médico, 116f. Dissertação
(Mestrado em Engenharia Elétrica). 1997. Universidade Federal de Santa Catarina, Florianópolis-SC.
LUGER, G. Inteligência Artificial – Estruturas e Estratégias para Resolução de Problemas
Complexos. 4. ed. Porto Alegre: Bookman, 2004.
MÄKINEN, T.; VARKOI, T.; SOINI, J. Integration of Software Process Assessment and Modeling.
In: PROTLAND INTERNATIONAL CENTER FOR MANAGEMENT OF ENGINEERING AND
TECHNOLOGY – PICMET, 2007, Portland. Proceedings... Portland : PICMET, 2007, p. 2476 –
2481.
MARÇAL, A. S. C. SCRUMMI: Um processo de gestão ágil baseado no Scrum e aderente ao CMMI.
2009. 205f. Dissertação (Mestrado em Informática Aplicada), Universidade de Fortaleza (UNIFOR),
Fortaleza. 2009.
148
MEGA, B.; FONSECA, K.; BOESSIO, R.; MASSA, P.; MONTONI, M.; VASCONCELOS, J.;
KATSURAYAMA, A. E.; ROCHA, A. R. Melhoria de Processos de Software na Drive. 2013.
Disponível em: <http://www.softex.br/wp-content/uploads/2013/09/T3-Drive-WE.pdf>. Acesso em:
Outubro de 2013.
MENDES, F. F.; ALMEIDA, J. N.; ARRUDA JR., E. A. Experiência de Implantação de Melhoria de
Processos de Software em um Laboratório de Pesquisa. In. WORKSHOP ANUAL DO MPS –
WAMPS, VII, 2011, Campinas, SP. Proceedings… Softex, 2011, p. 114 - 123
MENDES, F. F., OLIVEIRA, J. L. Validação de um método de Diagnóstico de processos Software. In:
CONGRESSO DE PESQUISA, ENSINO E EXTENSÃO DA UFG – CONPEEX, 3. 2006, Goiânia.
Anais eletrônicos do XIV Seminário de Iniciação Científica [CDROM], Goiânia: UFG, 2006. n.p
METAXIOTIS, K.; PARRAS, J.; Expert System in Business: Applications and Future Directions for
Operations Research. Industrial Management & Data Systems. v. 103, n. 5, p. 361–368, 2003.
MIYASHIRO, M.A.S.; FERREIRA, M.G.V.; SANT’ANNA, N.; SILVA, J.D.S. Uma Aplicação para
Auxiliar nas Atividades de Pré-Auto-Avaliação da Maturidade dos Processos de uma Organização
Utilizando os Modelos CMMI v 1.3 e MPSR. In: WORKSHOP EM ENGENHARIA E
TECNOLOGIA ESPACIAIS, 2 ed., 2011, São José dos Campos. Proceedings... São José dos
Campos: WETE, 2011.
MOREIRA, D. S. Abordagem para realização de autodiagnostico de processos de software. 2012.
163f. Dissertação (Mestrado em Computação Aplicada), Universidade do Vale do Itajaí (UNIVALI),
Itajaí. 2012.
MOURA, M. F.; CRUZ, S. A. B. Estudo de Expert System Shells para o Ambiente de Diagnose
Remota, Relatório Técnico, Embrapa, Campinas, 22 p. 2001.
MUNÁRRIZ, A. L. Fundamentos de Inteligência Artificial. Murcia, Espanha: Selegráfica, 1994.
MUNASSAR, N. M. A.; GOVARDHAN, A. A Comparison Between Five Models Of Software
Engineering. International Journal of Computer Science - IJCS. v. 7, n. 5, p. 94 – 101, Sep. 2010.
NUNES, Paulo. Conceito de árvore de decisão. 2009. Disponível em:
<http://www.knoow.net/cienceconempr/gestao/arvore_de_decisao.htm#vermais>. Acessado em: Julho
de 2013.
OLDONI, A; FERNANDES, A. M. R; DETERS, J. I. Desenvolvimento de uma Arquitetura da
Comunicação de um Agente Pedagógico Inteligente em JAVA. Revista Eletrônica de Sistemas de
Informação - RESI, ed. 10, v. 12, n. 2 , 2007.
OLIVEIRA, Ricardo F. Conceitos que compõem um Expert System. Disponível em: <
http://tede.unifacs.br/tde_busca/arquivo.php?codArquivo=204>. Acessado em: Março de 2014.
OSORIO, Jorge A.; CHAUDRON, Michel R. V.; HEIJSTEK, Werner. Moving FromWaterfall to
Iterative Development – An Empirical Evaluation of Advantages, Disadvantages and Risks of RUP.
In: CONFERENCE ON SOFTWARE ENGINEERING AND ADVANCED APPLICATIONS –
EUROMICRO, 37th, 2011, Oulu. Proceedings… IEEE Computer Society, 2011, p.453 - 460.
149
PAULA FILHO, Wilson P.; MACHADO, F. T.; DRUMOND, F. P.; NOGUEIRA, M. M.;
FERREIRA, G. R. M. Aplicação da fase de Diagnóstico de um processo para melhoria de
organizações técnicas. In: SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSO DE
SOFTWARE, 5th, 2003, Recife. Anais do SIMPROS 2003.
PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª
edição. Rio de Janeiro: LTC, 2005.
PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 3ª
edição. Rio de Janeiro: LTC, 2009.
PETERSEN, K.; FELDT, R.; MUTJABA, S.; MATTSON, M.. Systematic Mapping Studies in
Software Engineering. In: INTERNATIONAL CONFERENCE ON EVALUATION EVALUATION
AND ASSESSMENT IN SOFTWARE ENGINEERING – EASE, 12., 2008, Bari. Proceedings... BCS
eWIC, 2008. p 502-505.
PETTERSSON, F.; IVARSSON, M.; GORSCHEK, T.; OHMAN, P. A practitioner’s guide to light
weight software process assessment and improvement planning. The Journal of Systems and
Software. v. 81, p. 972 – 995, 2008.
PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. [Traduzido do original:
Software engineering - theory an practice]. Tradução de Dino Franklin. 2. ed. São Paulo: Prentice Hall,
2004.
PINO, F. J.; PARDO, C.; GARCÍA, F.; PIATTINI, M. Assessment methodology for software process
improvement in small organizations. Information and Software Technology. v. 52, p. 1044 – 1061,
2010.
PRESSMAN, Roger S. Engenharia de Software, Sexta Edição. Editora MCGrawHill: Porto Alegre,
2010.
PRICOPE, S.; LICHTER, H. Towards a Systematic Metric Based Approach to Evaluate SCAMPI
Appraisals. In: INTERNATIONAL CONFERENCE ON PRODUCT-FOCUSED SOFTWARE
PROCESS IMPROVEMENT – PROFES, 10th, 2009, Oulu - Finland. Proceedings Lecture Notes in
Business Information Processing – LNBIP. Berlin: Springer-Verlag, 2009. p. 261–274.
PRIKLADNICKI, R.; BECKER, C. A.; YAMAGUTI, M. H. Uma Abordagem para a Realização de
Diagnóstico Inicial em Empresas que Implementam o MPS.BR. 2005. Disponível em:
<http://www.softex.br/wp-content/uploads/2013/09/MPSBR2005_Artigo_Softsul_WSI_7ago05.pdf>.
Acessado em: Abril de 2013.
RAGUNATH, P.K.; VELMOUROUGAN, S.; DAVACHELVAN, P.; KAYALVIZHI, S.;
RAVIMOHAN, R. Evolving a New Model (SDLC Model-2010) for Software Development Life Cycle
(SDLC). International Journal of Computer Science and Network Security - IJCSNS, v.10, n.1, p.
112 – 119, January 2010.
REZENDE, S. O. Sistemas Inteligentes: Fundamentos e Aplicações; Editora Manole; Barueri, SP.
2003.
150
ROCHA, V. C. Metodologia para implementação do MPS.BR utilizando o ambiente Webapsee.
Dissertação (Mestre em Engenharia Elétrica) – Programa de Pós-Graduação em Engenharia Elétrica,
UFPA, Belém, 2009.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de Software: Teoria e Prática,
São Paulo: Prentice Hall, 2001. Cap. 12 (Automatização da Definição de Processos de Software).
ROCHA, A.R.; MONTONI, M.; SANTOS, G.; OLIVEIRA, K.; NATALI, A. C.; MIAN, P.; CONTE,
T.; MAFRA, S.; BARRETO, A.; ALBUQUERQUE, A.; FIGUEIREDO, F.; SOARES, A.; BIANCHI,
F.; CABRAL, R.; DIAS, A. Dificuldades e Fatores de Sucesso na Implementação de Processos de
Software Utilizando o MR-MPS e o CMMI. 2005. Disponível em: <http://www.softex.br/wp-
content/uploads/2013/09/ROCHA_ET_AL_W2-MPS.BR_05.pdf>. Acesso em: Novembro de 2013.
ROSSO, M. Sistema Especialista de Apoio à Decisão em Ventilação Mecânica. In: VIII
CONGRESSO BRASILEIRO DE INFORMÁTICA EM SAÚDE, Natal. Anais eletrônicos do VIII
Congresso Brasileiro de Informática em Saúde. SBIS, 2002.
RUPARELIA, N. B. Software Development Lifecycle Models. ACM SIGSOFT Software
Engineering Notes. V. 35, N. 3, p. 8 – 13, May 2010.
RUSSELL, S., NORVIG, P. Inteligência Artificial, Editora Campus, 2004.
SALO, O.; ABRAHAMSSON, P. Agile methods in European embedded software development
organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum. The
Institution of Engineering and Technology - IET. v.2, n.1, p. 58–64, February 2008.
SANTANA, André Felipe Lemos. Problemas em Iniciativas de Melhoria de Processos de Software sob
a Ótica de uma Teoria de Intervenção. 2007. 191f. Dissertação (Mestrado em Ciência da Computação),
Universidade Federal de Pernambuco (UFPE), Recife, 2007.
SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2004
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum – Um guia definitivo para o Scrum : As
regras do jogo. 2011.
SEI - Software Engineering Institute. CMMI-DEV: CMMI for Development. Technical Report
CMU/SEI-2010-TR-033, ESC-TR-2012-033. Software Engineering Institute, 2010a. Disponível em:
<http://cmmiinstitute.com/resource/cmmi-for-development-version-1-3/>. Acesso em: Abril 2013.
SEI - Software Engineering Institute. Process Maturity Profile. 2010b. Disponível em: <
http://cmmiinstitute.com/assets/presentations/2010MarCMMI.pdf >. Acesso em: Abril 2013.
SEI - Software Engineering Institute. Standard CMMI® Appraisal Method for Process
Improvement (SCAMPISM) A, Version 1.3: Method Definition Document. 2011. Disponível em:
<http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9703>. Acesso em: Abril 2013
SEI - Software Engineering Institute. CMMI Institute – Maturity Profile Report. 2014. Disponível em:
<http://cmmiinstitute.com/wp-content/uploads/2014/05/Maturity-Profile-Ending-March-2014.pdf>.
Acesso em: Maio 2014.
151
SILVA, A.A.C.; SILVA, E.J.F.; PORTELA, C. S.; VASCONCELOS, A. M. L.; OLIVEIRA, S. R. B.
Spider-PE: Uma Ferramenta de Apoio à Execução de Processos de Software aderente ao CMMI-DEV
e MR-MPS. In: VIII WORKSHOP ANUAL DO MPS – WAMPS. 2012, Itupeva – SP. Anais...
Itupeva. 2012. p. 186 – 194.
SILVA, A. M. R.; VIDEIRA, C. A. E. UML, Metodologias e Ferramentas Case. Lisboa: Centro
Atlântico, 2001.
SIMOES, R. Expandindo a Aplicação e os Benefícios do Scrum. 2011. Disponível em: <
http://scrumex.com.br/blog/?p=907>. Acesso em: Maio de 2014.
SOFTEX - Associação para a Promoção da Excelência do Software Brasileiro. “Guia Geral MPS de
Software”. 2012. Disponível em: <http://www.softex.br/mpsbr/guias/>. Acesso em: Março 2013.
SOFTEX – Associação para a Promoção da Excelência do Software Brasileiro. “Guia de Avaliação”.
2013. Disponível em: <http://www.softex.br/mpsbr/guias/>. Acesso em Março 2013.
SOFTEX – Associação para a Promoção da Excelência do Software Brasileiro. “Avaliações no
Brasil”. 2014. Disponível em: < http://www.softex.br/mpsbr/avaliacoes/mps-sw/mpsbr-ma-mps/>.
Acesso em Maio 2014.
SOMMERVILLE, I. Engenharia de Software, 8ª edição. São Paulo: Pearson Addison Wesley, 2007.
STALLINGER, F.; PLOSCH, R.; POMBERGER, G.; VOLLMAR, J. Integrating ISO/IEC 15504
Conformant Process Assessment and Organizational Reuse Enhancement. Journal of Software
Maintenance and Evolution: Research and Practice. v.22, n.4, p. 307 – 324, September 2009.
STELL, A. C.; TOLEMAN, M.; ROUT, T. Process improvement for small firms: An evaluation of the
RAPID assessment-based method. Information and Software Technology. v.48, p. 323-334, 2006.
TAMAKI, P. A. O. Uma extensão do RUP com ênfase no gerenciamento de projetos do PMBoK
baseada em Process Patterns. 2007. 211f. Dissertação de mestrado em engenharia. Escola Politécnica
da Universidade de São Paulo. São Paulo, 2007.
THIRY, M.; WANGENHEIM, C.G.V.; ZOUCAS, A.; PICKLER, K. Uma Abordagem para a
Modelagem Colaborativa de Processos de Software em Micro e Pequenas Empresas. In: V SIMPÓSIO
BRASILEIRO DE QUALIDADE DE SOFTWARE. 2006. Vila Velha - ES. Anais... Vila Velha, 2006,
p. 189 – 202.
THIRY, M.; WANGENHEIM, C.G.V.; ZOUCAS, A.; TRISTÃO, L. FAPS: Ferramenta para
apoiar Avaliações Integradas de Processos de Software. 2008. Disponível em: <
http://www.incremental.com.br/fapesc032006/pub/ComunicadoWSIIMPSBR2008_FAPS_VFINAL.p
df>. Acesso em Abril 2013.
TONINI, A.C.; SPINOLA, M. M.; CARVALHO, M. M. Contribuição dos modelos de qualidade e
maturidade na melhoria dos processos de software. Revista Produção (EPUSP). v. 18, n. 2, p. 275-
286. 2008.
152
TRAVASSOS, G. H.; KALINOWSKI, M. iMPS 2010: desempenho das empresas que adotaram o
modelo MPS de 2008 a 2010, Relatório Técnico, Softex, Campinas – SP, 2010. 32p. Disponível em: <
http://www.softex.br/wp-content/uploads/2013/08/iMPS-2010-Desempenho-das-Empresas-que-
Adotaram-o-Modelo-MPS-de-2008-a-2010.pdf>.
TRAVASSOS, G. H.; KALINOWSKI, M. iMPS 2012: Evidências sobre o desempenho das
empresas que adotaram o MPS-SW desde 2008, Relatório Técnico, Softex, Campinas – SP, 2012.
36p. Disponível em: < http://www.softex.br/wp-
content/uploads/2013/08/Softex_iMPS_2012_Portugues.pdf>.
VERMA, K.; KUMAR, P.; KUMAR, M.; TIWARI, G. An Assessment between Software
Development Life Cycle Models of Software Engineering. International Journal of Electronics and
Computer Science Engineering. v.2, n.2, p. 700 – 711, 2013.
WANGENHEIM, C. G. V.; PICKLER, K.K.; THIRY, M.; ZOUCAS, A. C.; SALVIANO, C. F.
Aplicando Avaliações de Contextualização em Processos de Software Alinhados ao CMMI-SE/SW.
In: VII SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE. 2005.
São Paulo, SP – Brasil. Anais... São Paulo, 2005.
WANGENHEIM, C. G. V.; VARKOI, T.; SALVIANO, C. F. Standard Based Software Process
Assessments in Small Companies. Software Process Improvement and Practice. v. 11, pg. 329 –
335, 2006.
WAZLAWICK, Raul Sidnei. Uma Reflexão sobre a Pesquisa em Ciência da Computação à Luz da
Classificação das Ciências e do Método Científico. Revista de Sistemas da Informação da FSMA,
n.6, p. 3 – 10, 2010.
WEBER, K. C.; ARAUJO, E.; MACHADO, C. A. F.; SCALET, D.; SALVIANO, C. F.; ROCHA, A.
R. C. Modelo de Referência e Método de Avaliação para Melhoria de Processo de Software – versão
1.0 (MR-MPS e MA-MPS). In: IV SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE
(SBQS), 2005, Porto alegre - RS. Anais... Porto Alegre, 2005.
WELLS, J. Donovan. Extreme Programming: A gentle introduction. 2000. Disponível em:
<http://www.extremeprogramming.org/map/project.html>. Acessado em: Abril 2014
YOUNG, H.; FANG, T.; HU, C. A Successful Practice of Applying Software Tools to CMMI Process
Improvement. CMMI practices and experiences. Journal of Software Engineering Studies, Vol. 1,
No. 2, p. 78-95, December 2006.
153
APÊNDICE A – Mapeamento Sistemático
A1 String de Busca
IEEE: (("Document Title":"Software Process Improvement") AND (p_Abstract:assessment
OR "Abstract":"Self-Assessment" OR "Abstract":"Self Assessment" OR "Abstract":appraisal OR
"Abstract":evaluation OR "Abstract":Tool OR p_Abstract:lifecycle OR "Abstract":"life cycle" OR
p_Abstract:method OR "Abstract":methodology OR "Abstract":methodologies OR
"Abstract":diagnostic OR "Abstract":diagnosis))
ScienceDirect: pub-date > 2007 AND Title("Software Process Improvement") AND
Abstract (assessment OR "Self-Assessment" OR "Self Assessment" OR appraisal OR evaluation
OR Tool OR lifecycle OR "life cycle" OR method OR methodology OR methodologies OR
diagnostic OR diagnosis) [Journals(Computer Science)]
ACM: ((Title: "Software Process Improvement") AND (Abstract: assessment OR abstract:
"Self-Assessment" OR abstract: "Self Assessment" OR abstract: appraisal OR abstract: evaluation
OR abstract: Tool OR abstract: lifecycle OR abstract: "life cycle" OR abstract: method OR abstract:
methodology OR abstract: methodologies OR abstract: diagnostic OR abstract: diagnosis)) and
(PublishedAs:journal OR PublishedAs:proceeding) AND (PublishedAs:journal OR
PublishedAs:proceeding)
SpringerLink: '(ti:("software process improvement")) AND (ab: assessment OR "Self-
Assessment" OR "Self OR Assessment" OR appraisal OR evaluation OR Tool OR lifecycle OR
"life OR cycle" OR method OR methodology OR methodologies OR diagnostic OR diagnosis)'
Google Scholar: tudonotítulo: "Software Process Improvement"
A2 Resultado da Extração dos Dados
Nesta seção são apresentados os resultados das seleções e análise dos resultados do
mapeamento sistemático. A Tabela 3 mostra a quantidade de artigos retornados para cada base de
dados.
154
Tabela 3. Artigos retornados
Nome da fonte Qtdade. retornada Selecionados
IEEExplore 42 2
ScienceDirect
8 5
ACM Digital library 0 0
SpringerLink 0 0
Google Scholar 501 12
Total 551 19
A Figura 32 é uma representação gráfica da quantidade de artigos retornados.
Figura 34. Total de trabalhos retornados
Após efetuar as buscas nas bases de dados, foram obtidos um total de 551 estudos. A base
que apresentou maior número de resultados foi a Google Scholar com 501 estudos, dos quais, 12
foram selecionados. A seleção realizada no Google Scholar consiste em ordenar os artigos por
relevância, realizando a análise do título seguido pelo resumo, introdução e artigos em inglês.
Em um total de 551 estudos retornados, foram selecionados 19 estudos baseados nos
critérios de inclusão e exclusão definidos, totalizando 3,45% do total retornado. Sendo que desses
19 resultados, 4 deles aparecem em duas bases de dados. Portanto apenas 15 trabalhos são
relevantes para a pesquisa. Na Tabela 4 são apresentados os 15 trabalhos selecionados.
Tabela 4. Trabalhos selecionados
Ano Título do trabalho Bases de
dados
Autores
2008 Software Process Improvement
Methodologies for Small and Medium Enterprises
Scholar
Deepti Mishra, Alok
Mishra
2008 Framework to Evaluate Software Process
Improvement in Small Organizations
Scholar
Pedro E. Colla, Jorge
Marcelo Montagna
42 80
0
501
IEEExplore
ScienceDirect
ACM Digital library
SpringerLink
Google Scholar
155
2008 A Knowledge Management Approach to
Support Software Process Improvement
Implementation Initiatives
Scholar
Mariano Angel Montoni,
Cristina Cerdeiral, David
Zanetti, Ana Regina
Cavalcanti da Rocha
2008 Initiating software process improvement in
very small enterprises: Experience with a light
assessment tool
ScienceDirect
Scholar
Naji Habra; Simon
Alexandre; Jean-Marc
Desharnais; Claude Y.
Laporte; Alain Renault.
2009 MPS.BR: a successful program for software
process improvement in Brazil
Scholar
Mariano Angel Montoni;
Ana Regina Rocha; Kival
Chaves Weber
2009 An Integrated Framework to Guide Software
Process Improvement in Small Organizations
Scholar
Francisco J. Pino, Félix
García, Mario Piattini
2009 Toward Automated Support for Software
Process Improvement Initiatives in Small and
Medium Size Enterprises
Scholar
Ivan Garcia, Carla
Pacheco
2010 Using Scrum to guide the execution of
software process improvement in small
organizations
ScienceDirect Francisco J.; Oscar
Pedreira; Félix García;
Miguel Rodríguez
Luaces; Mario Piattini
2010 Using a web-based tool to define and
implement software process improvement
initiatives in a small industrial setting
Scholar
I. Garcia; C. Pacheco; J.
Calvo-Manzano
2010 Assessment methodology for software
process improvement in small organizations
ScienceDirect
Scholar
Francisco J. Pino, César
Pardo, Félix García,
Mario Piattini
2010 Surveying and Evaluating Tools for
Managing Processes for Software-Intensive
Systems
Scholar
Anuradha Suryadevara
2010 Using the Software Process Improvement
approach for Defining a Methodology for
Embedded Systems Development using the CMMI-
DEV v1.2
IEEExplore
Scholar
Garcia, I.; Andrea, I
2010 Software process improvement through the
Lean Measurement (SPI-LEAM) method
ScienceDirect
Scholar
Kai Petersen; Claes
Wohlin
2011 An application tool to support the
implementation of integrated software process
improvement for Malaysia's SME
IEEExplore Ali, R.Z.R.M. ; Ibrahim,
S.
2012 Software process improvement success
factors for small and medium Web companies: A
qualitative study
ScienceDirect Muhammad Sulayman;
Cathy Urquhart; Emilia
Mendes; Stefan Seidel
Neste trabalho estendemos à pesquisa anterior. As strings de busca utilizadas no trabalho de
Moreira (2012), foram utilizadas nas bases de dados IEEE e Google Scholar, onde foram revisadas
e refeitas, retornando trabalhos significantes para esta pesquisa.
156
O trabalho de Homchuenchom (2011), também foi encontrado na revisão informal.
A Tabela 5 apresenta os trabalhos extraídos das strings de busca utilizadas na pesquisa
anterior.
Tabela 5. Trabalhos selecionados com base nas strings do trabalho anterior
Ano Título do trabalho Bases de
dados
Autores
2009 Assessing - Learning - Improving, an Integrated
Approach for Self Assessment and Process
Improvement Systems
IEEE Malzahn, Dirk
OrgaTech GmbH, Lunen
2009 A questionnaire based method for CMMI level 2
maturity assessment
Scholar
Fatih YUCALAR, Senol
Zafer ERDOGAN
2011 SPIALS: A light-weight Software Process
Improvement self-assessment tool
IEEE Homchuenchom, D. ;
Piyabunditkul, C. ;
Lichter, H. ; Anwar, T.
Outra informação importante para mostrar uma tendência, é a distribuição por data de
publicação, conforme o gráfico da Figura 33.
Figura 35. Distribuição por data de publicação
É possível observar que o assunto teve um pico de publicações no ano de 2010 e após houve
uma grande queda, chegando a zero em 2013 e 2014.
4
5
6
2
1
0 00
1
2
3
4
5
6
7
2008 2009 2010 2011 2012 2013 2014
Estudos
157
APÊNDICE B – Árvores
Devido ao tamanho das árvores, fica inviável inseri-las neste documento, para tanto, elas
constam nos arquivos em anexo.
Quadro 23. Caminho para as árvores.
Árvore Inicial
...\Árvores\1. Inicial\Inicial_1.pdf
...\Árvores\1. Inicial\Inicial_2.pdf
...\Árvores\1. Inicial\Inicial_3.pdf
...\Árvores\1. Inicial\Inicial_4.pdf
...\Árvores\1. Inicial\Inicial_5.pdf
...\Árvores\1. Inicial\Inicial_6.pdf
Árvore Requisitos
...\Árvores\2. Requisitos\Árvore Requisitos_0.pdf
...\Árvores\2. Requisitos\Árvore Requisitos_1.pdf
...\Árvores\2. Requisitos\Árvore Requisitos_2.pdf
...\Árvores\2. Requisitos\Árvore Requisitos_3.pdf
...\Árvores\2. Requisitos\Árvore Requisitos_4(cliente).pdf
...\Árvores\2. Requisitos\Árvore Requisitos_5(cliente).pdf
Árvore Gerência de Projetos
...\Árvores\3. Gerência de Projetos\Árvore_GerenciaProjeto_1.pdf
...\Árvores\3. Gerência de Projetos\Árvore_GerenciaProjeto_2.pdf
...\Árvores\3. Gerência de Projetos\Árvore_GerenciaProjeto_3.pdf
...\Árvores\3. Gerência de Projetos\Árvore_GerenciaProjeto_4.pdf
...\Árvores\3. Gerência de Projetos\Árvore_GerenciaProjeto_5.pdf
Árvore Solução Técnica
...\Árvores\4. SolucaoTécnica\Arvore_SolucaoTecnica.pdf
Árvore Construção
...\Árvores\5. Construção\Árvore Construção_1.pdf
...\Árvores\5. Construção\Árvore Construção_2.pdf
...\Árvores\5. Construção\Árvore Construção_3.pdf
Árvore Testes
...\Árvores\6. Testes\Árvore Testes_Auto.pdf
...\Árvores\6. Testes\Árvore Testes_1.pdf
...\Árvores\6. Testes\Árvore Testes_Auto1.pdf
...\Árvores\6. Testes\Árvore Testes_AutoManual.pdf
...\Árvores\6. Testes\Árvore Testes_CasosTestes.pdf
...\Árvores\6. Testes\Árvore Testes_Manual.pdf
...\Árvores\6. Testes\Árvore Testes_Manual1.pdf
158
...\Árvores\6. Testes\Árvore Testes_PlanoTeste.pdf
Árvore Documentação
...\Árvores\7.Documentação\Documentação_1.pdf
...\Árvores\7.Documentação\Documentação_2.pdf
Árvore Manutenção
...\Árvores\8.Manutenção\Árvore Manutenção_1.pdf
...\Árvores\8.Manutenção\Árvore Manutenção_2.pdf
159
APÊNDICE C – Questionário de avaliação para as organizações
DOCUMENTO DE AVALIAÇÃO DO SISTEMA ESPECIALISTA
Nome da organização:
Nome do(a) avaliador(a):
Tempo de trabalho na organização:
Cargo:
Conhecimentos em melhoria de processos de software ( )sim ( )não
Conhecimentos em MPS.BR ( )sim ( )não
Conhecimentos em CMMI ( )sim ( )não
Questão 1.1: Os resultados obtidos com a execução do sistema especialista estão
aderentes com a realidade da organização?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.2: O ciclo de vida identificado pelo sistema especialista corresponde ao ciclo
de vida de desenvolvimento da organização?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.3: As fases do ciclo de vida da organização estão aderentes ao resultado do
sistema especialista?
( ) Concordo totalmente
160
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.4: Os resultados são aderentes ao ciclo de vida da organização?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.5: As perguntas realizadas no sistema especialista permitem entender a
estrutura da abordagem para a identificação do processo de desenvolvimento da
organização?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.6: O sistema especialista e seus resultados contribuem positivamente para a
área de MPS da organização?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
161
APÊNDICE D – Questionário de avaliação para os especialistas
DOCUMENTO DE AVALIAÇÃO DO SISTEMA ESPECIALISTA
Nome do(a) especialista:
Tempo de experiência em melhoria de processos de software:
Quantidade de empresas avaliadas (Modelo MPS.BR):
Quantidade de implantações (Modelo MPS.BR):
Quantidade de empresas avaliadas (Modelo CMMI):
Quantidade de implantações (Modelo CMMI):
Questão 1.1: A quantidade de perguntas é adequada à quantidade estimada de fases de
um ciclo de vida de desenvolvimento de software?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.2: O conteúdo do sistema especialista é adequado às situações praticadas nas
organizações?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.3: As perguntas descritas no sistema especialista estão adequadas a realidade
de cada fase do ciclo de desenvolvimento de software?
( ) Concordo totalmente
( ) Concordo parcialmente
162
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.4: As perguntas descritas no sistema especialista estão adequadas com a
realidade de um especialista, ao entrevistar uma organização?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.5: A execução da avaliação do ciclo de vida de desenvolvimento de software
através de diálogos automatizados (SE) está de acordo com a primeira etapa de
avaliação de um processo de melhoria de desenvolvimento de software?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
Questão 1.6: O resultado do diálogo automatizado (SE) é tão confiável quanto o resultado
de um diálogo verbal feito por um especialista na área de melhoria de processo de
software?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique:
163
Questão 1.7: É possível levantar pontos fracos, pontos fortes e oportunidades de
melhorias com os resultados do sistema especialista?
( ) Concordo totalmente
( ) Concordo parcialmente
( ) Discordo parcialmente
( ) Discordo totalmente
( ) Indiferente
Justifique: