anais do wtdqs 2015

Transcrição

anais do wtdqs 2015

ANAIS DO WTDQS 2015
XIII Workshop de Teses e Dissertações em Qualidade de Software
17 de agosto de 2015
Manaus  Amazonas  Brasil
Apresentação do WTDQS
Esta coletânea reúne os trabalhos selecionados para apresentação no XIII Workshop
de Teses e Dissertações em Qualidade de Software (WTDQS 2015). O workshop é parte
integrante das atividades do Simpósio Brasileiro de Qualidade de Software que está
atualmente em sua 14ª edição. O objetivo do WTDQS é permitir que alunos de pósgraduação stricto sensu (mestrado e doutorado), apresentem trabalhos, ainda em
andamento, para que sejam discutidos com especialistas da área. É uma oportunidade
para que os pós-graduandos possam receber críticas e sugestões que venham a
aprimorar seus trabalhos.
O comitê de programa do WTDQS é formado por professores especialistas em
Qualidade de Software que fazem parte de grupos de pesquisa reconhecidos da área.
Este ano o WTDQS recebeu 14 trabalhos provenientes dos vários programas de pósgraduação do Brasil. Dessas, 12 foram selecionadas para apresentação e publicação
nesta coletânea, sendo 6 propostas de doutorado e 6 propostas de mestrado. Cada
trabalho foi avaliado por 3 (três) membros do comitê de programa, que forneceram
suas valiosas contribuições para a melhoria da qualidade dos trabalhos de pesquisa.
Agradecemos, especialmente, à organização geral do SBQS, na pessoa da professora
Tayana Conte (UFAM), à coordenação técnico-científica, na pessoa do professor
Marcello Thiry (UNIVALI), aos autores e orientadores dos trabalhos submetidos ao
WTDQS 2015 e aos membros do Comitê de Avaliação.
Curitiba, 17 de agosto de 2015.
Sheila Reinehr
Coordenadora do Comitê de Programa do WTDQS 2015
Coordenadora
Sheila Reinehr possui Doutorado em Engenharia pela Escola Politécnica da
USP (2008), Mestrado em Informática pela Pontifícia Universidade Católica do
Paraná (2001) e Graduação em Engenharia Mecânica pela Universidade
Federal do Paraná (1986). Atualmente é Diretora de Cultura e Esporte na
PUCPR, professora da PUCPR, Pesquisadora do PPGIa/PUCPR na qual é líder
do grupo de pesquisa em Engenharia de Software, é consultora em melhoria
de processos e qualidade de software. Foi Diretora de Educação Continuada
na PUCPR no período 2012-2013. Tem experiência na área de Ciência da
Computação, com ênfase em Engenharia de Software, atuando
principalmente nos seguintes temas: melhoria de processos de software,
qualidade de software, gerência de projetos e portfólio de projetos, reuso de
software, linhas de produto de software e métricas de software. Possui
certificação PMP, ITIL e SCRUM. É implementadora e avaliadora líder MPS.BR
autorizada pela SOFTEX e membro da Equipe Técnica do Modelo (ETM) na
área de MPS para Serviços. Foi membro da Comissão de Gerenciamento de
Ciclo de Vida de Software da ABNT, participando de elaboração de normas
nacionais e internacionais, como a ISO/IEC 12207 e a ISO/IEC 15288.
COMITÊ DE AVALIAÇÃO
Adriano Albuquerque - Universidade de Fortaleza
Alexandre Vasconcelos - Universidade Federal de Pernambuco
Ana Regina Rocha - COPPE/UFRJ
Andreia Malucelli - PUCPR
Gleison Santos - Unirio
Humberto Marques - PUC Minas
Juliano Lopes de Oliveira - Universidade Federal de Goiás
Kathia Marçal de Oliveira - Université de Valenciennes et du Hainaut-Cambrésis
Raul Wazlawick – Universidade Federal de Santa Catarina
Ricardo Falbo - Universidade Federal do Espírito Santo
Rodrigo Reis – Universidade Federal do Pará
Toacy Oliveira - COPPE/UFRJ
Uirá Kulesza - Universidade Federal do Rio Grande do Norte
Sistema de Recomendação de APIs na Engenharia de Software
Luisa Hernández, Heitor Costa
Programa de Pós-Graduação em Ciência da Computação (PPGCC)
Universidade Federal de Lavras (UFLA) - Lavras, MG - Brasil
[email protected], [email protected]
Resumo. A maioria dos sistemas de software depende de bibliotecas externas
para alcançar seus objetivos, conhecidas como Application Programming
Interfaces (Application Programming Interfaces - APIs). Neste trabalho, o
objetivo é apresentar uma análise empírica de sistemas de software quanto à
utilização de APIs e elaborar uma metodologia para apoiar o
desenvolvimento de software com qualidade. Essa metodologia considera
categorias de aplicação de software e recomenda APIs para desenvolvedores
com sistemas em estado inicial (podem ou não ter código, mas não usam
APIs). Além disso, recomenda APIs para sistemas em desenvolvimento que
utilizam APIs. Nessa metodologia, a técnica de filtragem colaborativa e o
método de itens mais frequentes são utilizados. Desse modo, as
recomendações serão mais "exatas" e úteis aos desenvolvedores. Um sistema
de recomendação de APIs será desenvolvido para avaliar a metodologia
proposta, utilizando medidas, por exemplo, Precision, Recall e MissRate. Os
resultados podem ser utilizados para apoiar Engenheiros de Software na
tomada de decisões sobre quais APIs utilizar. Com isso, espera-se ter
benefícios como o aumento na produtividade dos desenvolvedores e na
qualidade de sistemas de software.
Palavras-chave: Sistema de recomendação, reúso de APIs, filtragem
colaborativa.
Abstract. Software depends on external libraries to achieve their goals known
as Application Programming Interfaces (APIs). This work aims to propose an
empirical analysis of software about APIs usage and to elaborate a
methodology to support software development with quality. This methodology
considers software categories and recommends APIs to developers with
systems in initial state (which do not use APIs). Besides, it recommends APIs
for software on development that uses a few APIs. In this methodology, we will
use collaborative filtering technique and frequent itemset mining method.
Thus, recommendations are more "accurate" and useful for developers. We
will develop a recommendation system of APIs to evaluate the proposed
methodology. In that evaluation, we will use metrics, for example, Precision,
Recall, and MissRate. The results can support Software Engineers in making
decisions about which APIs to use. Thus, we expected to have benefits, such
as, increase the developers’ productivity and the software quality.
Keywords: Recommendation system, APIs reuse, collaborative filtering.
1
1. Caracterização do Problema
Desenvolvimento de software não é uma tarefa fácil. Prova disso é a existência de várias
propostas metodológicas que afetam diversos componentes e aspectos do processo de
desenvolvimento [Canós et al., 2003]. Entre os diferentes componentes, há bibliotecas
de software conhecidas como Interfaces de Programação de Aplicativos (Application
Programming Interfaces - APIs). Muitos sistemas de software dependem de funções
reutilizáveis fornecidas pelas APIs e o desenvolvimento de software moderno é
inseparável desse reúso [Duala-Ekoko; Robillard, 2012]. Entre as vantagens de utilizar
APIs, está o fato dos desenvolvedores não reconstruírem recursos existentes [Teyton et
al., 2013], proporcionando uma forma rentável para construir sistemas de software com
melhora na (i) produtividade dos programadores, fornecendo variedade de funções
desejadas e na (ii) qualidade de software, pois são geralmente "bem-testadas" e
utilizadas por grande quantidade de usuários (desenvolvedores) [Sun et al., 2011].
Para os Engenheiros de Software, é difícil selecionar de forma eficaz as APIs
durante o desenvolvimento e verificar o uso correto depois da construção do sistema.
Por causa do aumento do tamanho e da quantidade de APIs, os desenvolvedores devem
frequentemente aprender como usar APIs desconhecidas [Acharya et al., 2007]. Isso
significa que, antes de aproveitar os benefícios de uma API para determinadas tarefas,
um desenvolvedor deve descobrir e entender o comportamento e as relações entre os
elementos de uma API [Duala-Ekoko; Robillard, 2012]. Para ajudar os desenvolvedores,
foi proposta uma engine de busca de desenvolvedores especialistas em APIs Java
chamada LIBTIC, que utiliza mineração no repositório GitHub [Teyton et al., 2013a].
No entanto, contratar especialistas em APIs requer investimento, disponibilidade e
recursos humanos que podem não estar no escopo do projeto de desenvolvimento. Por
outro lado, uma metodologia que combina Mineração de Regras de Associação e
Filtragem Colaborativa foi apresentada para analisar as APIs utilizadas por sistemas de
software e sugerir APIs aos desenvolvedores [Thung et al., 2013].
A motivação deste trabalho é apoiar Engenheiros de Software na tomada de
decisões sobre quais APIs utilizar em seus projetos. Assim, o objetivo é apresentar uma
metodologia de recomendação de APIs que considere categorias de domínios de
aplicação de software. Essa metodologia pode ser utilizada para sistemas em estado
inicial (sem uso de APIs) ou em desenvolvimento (utilizam APIs). Além disso, um
sistema de recomendação de APIs será desenvolvido para automatizar a recomendação.
Este artigo está organizado da seguinte forma. Técnicas e medidas de avaliação
para sistemas de recomendação são apresentadas na Seção 2. Contribuições do trabalho
proposto são abordadas na Seção 3. Trabalhos relacionados estão resumidos na Seção 4.
O estado atual do trabalho e a proposta da metodologia adotada para o desenvolvimento
de um sistema de recomendação são discutidos na Seção 5. A metodologia para
avaliação dos resultados é apresentada na Seção 6.
2. Fundamentação Teórica
2.1. Sistemas de Recomendação na Engenharia de Software
Sistemas de recomendação para engenharia de software (Recommendation Systems for
Software Engineering - RSSEs) são aplicações de software que fornecem itens de
2
informação considerados valiosos para tarefas de engenharia de software em
determinados contextos. A maior parte desses sistemas está surgindo para ajudar os
desenvolvedores em diversas atividades, desde reúso de código à escrita de relatórios
eficazes de bugs [Robillard et al., 2010]. Hoje em dia, mais esforços são necessários
para realizar essas atividades por causa de novas tecnologias, componentes e ideias que
desenvolvedores são continuamente introduzidos [Robillard et al., 2010].
Entre as vantagens do uso de RSSEs, podem ser citadas a diminuição do esforço,
o aumento da produtividade e o auxílio nas tomadas de decisões [Robillard et al., 2010].
Para desenvolver esses sistemas, são comumente utilizadas técnicas que dependem do
contexto do problema e dos itens a serem recomendados, por exemplo: i) Filtragem
Baseada no Conteúdo: fundamentada nas características ou palavras-chave dos itens e
nas preferências do usuário; e ii) Filtragem Colaborativa: utilizada para recomendar
itens com base nos outros usuários que interagem com o software. A Filtragem
Colaborativa será utilizada neste estudo e há dois principais métodos [Breese et al.,
1998]: i) baseado na memória, opera sobre a base de dados inteira para fazer
recomendações; e ii) baseado no modelo, utiliza parte da base de dados do usuário para
aprender um modelo e realiza predições sobre preferências dos usuários sobre os itens.
2.2. Avaliação de Sistemas de Recomendação
Sistemas de recomendação (Recommendation Systems - RSs) tornaram-se populares em
diversos cenários de aplicações, desde a modelagem de processos de negócio à
manipulação de código. Diferentes abordagens e medidas foram propostas para
avaliação por causa da variedade de domínios de aplicação [Robillard et al., 2010].
A qualidade dos RSs pode ser definida em termos de avaliação centrada no
usuário ou de métodos centrados no sistema. Na avaliação centrada no usuário, os
usuários interagem com RS e recebem recomendações. As medidas são calculadas
perguntando ao usuário e observando o seu comportamento durante a utilização ou
automaticamente registrando suas interações. Com métodos centrados no sistema, o RS
é avaliado em relação a um dataset de avaliações pré-construído. Os usuários não
interagem com o sistema em teste, mas a avaliação, em termos de precisão, baseia-se na
comparação entre as avaliações dos usuários sobre os itens estimados pelo RS e
coletadas de usuários reais sobre os mesmos itens [Cremonesi et al., 2013].
A qualidade dos sistemas de recomendação pode ser definida e avaliada em
termos de medidas. Nos métodos centrados no sistema, são utilizadas [Cremonesi et al
2013]: i) medidas de precisão, por exemplo, Precision, Recall e MissRate; ou ii)
medidas de erro, por exemplo, Raiz do Erro Médio Quadrático (Root Mean Square
Error - RMSE) e Erro Médio Absoluto (Mean Absolute Error - MAE). Essas medidas
permitem avaliar as recomendações e determinar a qualidade delas e do RS.
3. Contribuições
Espera-se apoiar Engenheiros de Software na tomada de decisões sobre quais APIs
utilizar em seus projetos. Entre as contribuições, podem ser citadas (i) o
desenvolvimento de um apoio computacional à recomendação automatizada de APIs,
(ii) a identificação das APIs mais utilizadas para as categorias de domínio de aplicação
sugeridas pelo SourceForge e (iii) avaliação da qualidade das recomendações geradas
3
pelo apoio desenvolvido. Com isso, espera-se ter alguns benefícios, por exemplo,
aumento na (i) produtividade dos desenvolvedores, pois serão reutilizadas funções,
evitando a reconstrução e, consequentemente, minimização do tempo de
desenvolvimento e na (ii) qualidade do software, sendo que, o uso de APIs populares é
um indicador da qualidade das APIs e, portanto, da qualidade dos sistemas de software.
Espera-se divulgar os avanços da pesquisa em futuras publicações.
4. Trabalhos Relacionados
Os trabalhos relacionados consistem em entender e recomendar APIs, seus métodos,
suas versões, etc. Por exemplo, foi desenvolvida APIExample, uma ferramenta que
fornece uma visão completa sobre os exemplos de uso de uma API java com base em
pesquisa na web. Essa ferramenta auxilia ao programador no entendimento do uso de
APIs para aprender a usar a API de forma eficiente [Wang et al., 2011]. Por outro lado,
para apoiar desenvolvedores na escolha das APIs e sua respectiva versão, foi
desenvolvida uma metodologia que utiliza uma técnica baseada no voto popular da
maioria. Essa técnica baseia-se na tendência do uso de cada versão da biblioteca [Mileva
et al., 2009]. De modo similar, com a finalidade de auxiliar os desenvolvedores na
escolha correta das APIs, foram combinadas técnicas de mineração de regras de
associação e de filtragem colaborativa. Desse modo, a partir das bibliotecas utilizadas
por outros projetos, é possível recomendar determinada quantidade de APIs para
sistemas de software em desenvolvimento que usa algumas APIs [Thung et al., 2013].
Este trabalho diferencia-se dos demais por utilizar critérios das categorias de
domínio de aplicação, técnicas de filtragem colaborativa e itens mais frequentes. Assim,
são realizadas recomendações de APIs para desenvolvedores com sistemas em estado
inicial (não usam APIs) ou em desenvolvimento (utilizam APIs).
5. Estado Atual do Trabalho
O cronograma das atividades é apresentado na Tabela 1. As atividades realizadas são
representadas pelos números 1 a 4 e as atividades em andamento pelos números 5 a 9.
Tabela 1. Cronograma
As atividades do cronograma são: 1) Pesquisa de artigos científicos e livros; 2)
Especificação dos objetivos e estabelecimento de uma metodologia para implementar
um sistema de recomendação de APIs para sistemas em desenvolvimento e em estado
inicial; 3) Participação nas disciplinas; 4) Exame de qualificação; 5) Desenvolvimento
de um plug-in para a mineração de APIs para sistemas em um repositório principal - P e
a recomendação de APIs para um sistema alvo - SA; 6) Coleta de sistemas para construir
o repositório P (~1.000 sistemas de software), classificando-os segundo critérios
4
estabelecidos e as categorias indicadas pelo repositório SourceForge; 7) Coleta de
sistemas de teste para simular usuários reais (alvos da recomendação); 8) Teste da
metodologia e do plug-in por meio de medidas de avaliação para sistemas de
recomendação; e 9) Escrever a dissertação e realizar a defesa.
A metodologia proposta aprovada no exame de qualificação é apresentada na
Figura 1. Essa metodologia permitirá recomendar APIs, sendo composta por duas fases:
Fase A) Recomendação de APIs para os desenvolvedores em etapa inicial do
desenvolvimento de um sistema de software (sem uso de APIs), considerando uma ou
mais categorias de aplicação; e Fase B) Recomendação de APIs para sistemas de
software em desenvolvimento que utilizam algumas APIs e que podem ser classificados
em uma ou mais categorias de aplicação.
Figura 1. Proposta da Metodología de Desenvolvimento da Pesquisa
Por causa do contexto do problema deste projeto e das necessidades da Fase A,
as técnicas de recomendação não são uma boa escolha, pois não têm APIs para
relacionar. No entanto, existe a possibilidade de recomendar APIs para os
desenvolvedores determinando a popularidade, identificando APIs mais frequentes para
cada categoria do repositório principal de sistemas de software e relacionando esses
resultados com as categorias consideradas pelo desenvolvedor alvo de recomendação.
Por outro lado, quanto à Fase B, será utilizada a filtragem colaborativa. Isso implica que
as categorias serão consideradas e a similaridade será estabelecida entre os projetos do
repositório principal e o sistema alvo (SA) de recomendação, obtendo os sistemas "mais
próximos". Em seguida, será estabelecida a similaridade entre as APIs do SA e as APIs
dos sistemas mais próximos, permitindo gerar uma lista de possíveis APIs a
recomendar. Nessa fase, poderá ser feita a união entre a lista gerada por itens mais
frequentes e a lista gerada pela técnica de filtragem colaborativa.
5
6. Avaliação dos Resultados
Para avaliar os resultados e retirar a necessidade de usuários reais, dois repositórios de
teste serão criados (Teste A - TA e Teste B - TB) com os sistemas alvo de recomendação
segundo as necessidades de cada fase. Para a Fase A (Figura 1), os sistemas alvo de
recomendação não utilizam APIs e consideram as categorias do domínio de aplicação.
Para simular a Fase A, n sistemas de TA serão selecionados. Quanto à Fase B (Figura 1),
os sistemas alvo de recomendação utilizam algumas APIs e consideram uma ou mais
categorias de domínio de aplicação. Portanto, sistemas de TB serão coletados para
simular a Fase B, sendo que diferentes percentagens de APIs serão retiradas, avaliando
a qualidade das recomendações em cada caso. Em ambas as fases, as informações sobre
as APIs removidas serão guardadas para, posteriormente, aplicar as medidas de
avaliação (Precision, Recall e MissRate) entre as APIs removidas e as APIs recomendas.
Referências
Acharya, M.; Xie, T.; Pei, J.; Xu, J. (2007). Mining API Patterns as Partial Orders from
Source Code : From Usage Scenarios to Specifications. In: Joint Meeting of the
European Software Engineering Conference and the ACM SIGSOFT Symposium on
the Foundations of Software Engineering. pp. 25-34.
Breese, J. S.; Heckerman, D.; Kadie, C. (1998). Empirical Analysis of Predictive
Algorithms for Collaborative Filtering. In: Conference on Uncertainty in Artificial
Intelligence. V. 40, pp. 43-52.
Canós, J. H.; Letelier, P.; Penadés, C. (2003). Metodologías Ágiles en el Desarrollo de
Software. In: DSIC Universidad Politécnica De Valencia. pp. 1-8.
Cremonesi, P.; Garzotto, F.; Turrin, R. (2013) User-Centric vs. System-Centric
Evaluation of Recommender Systems. In: Lecture Notes in Computer Science
(including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in
Bioinformatics), part 3. pp. 334-351.
Duala-Ekoko, E.; Robillard, M. P. (2012). Asking and Answering Questions about
Unfamiliar APIs: An Exploratory Study. In: International Conference on Software
Engineering. pp. 266-276.
Robillard, M. P.; Walker, R. J.; Zimmernann, T. (2010). Recommendation Systems for
Software Engineering. IEEE Software, pp.80-86.
Sun, C.; Khoo, S.; Zhang, S. J. (2011). Graph-Based Detection of Library API
Imitations. In: International Conference on Software Maintenance. pp. 183-192.
Teyton, C.; Falleri, J.-R.; Morandat, F.; Blanc, X. (2013a). Find your Library Experts.
In: Working Conference on Reverse Engineering. pp. 202-211.
Teyton, C.; Falleri, J.-R.; Palyart, M.; Blanc, X. (2013). A Study of Library Migration in
Java Software. The Computing Research Repository (CoRR). University Bordeaux,
LaBRI. pp. 1-20. Software Engineering.
Thung, F.; Lo, D.; Lawall, J. (2013). Automated Library Recommendation. In: Working
Conference on Reverse Engineering. pp. 182-191.
Wang, L.; Fang, L.; Wang, L.; Li, G.; Xie, B.; Yang, F. (2011). APIExample: An
Effective Web Search Based Usage Example Recommendation System for Java
APIs. In: International Conference on Automated Software Engineering. pp. 592-595.
6
MSECO Cert: Uma Abordagem Baseada em Processo
para Apoiar a Certificação de Apps em Ecossistemas de
Software Móvel
Awdren de Lima Fontão, Arilo Claudio Dias-Neto
Mestrado em Informática – Programa de Pós-Graduação em Informática
Instituto de Computação (IComp) – Universidade Federal do Amazonas (UFAM)
Av. General Rodrigo Octávio, 6.200, Campus Universitário Senador Arthur Virgílio
Filho – Setor Norte - Manaus - CEP 69.077-000 – Manaus – AM – Brasil
Abstract. Software organizations began to open its structure to external
developers, impacting the traditional development process. In mobile
applications (apps), this scenario is called Mobile Software Ecosystem
(MSECO), in which the App Store, through acceptance criteria, certifies the
quality of apps. However, these criteria do not ensure that apps get the desired
performance against the number of downloads and positive reviews. In this
paper, we propose an approach for quality certification of apps in MSECO
through processes, practices and recommendations before the app is
submitted to the app store.
Resumo. Organizações de software passaram a abrir a sua estrutura para
desenvolvedores externos, impactando o processo de desenvolvimento
tradicional. Em aplicações móveis (apps), este cenário é chamado
Ecossistemas de Software Móvel (MSECO), no qual a Loja de Apps, por meio
de critérios de aceitação, certifica a qualidade de apps. No entanto, estes
critérios não garantem que as apps obtenham o desempenho desejado em
relação a número de downloads e avaliações positivas. Neste trabalho, é
proposta uma abordagem para certificação de qualidade de apps no contexto
de MSECO por meio de processos, recomendações e práticas na fase de prépublicação, ou seja, antes da aplicação ser submetida à loja de apps.
Palavras-chave: ecossistemas de software, aplicações móveis, modelagem de
processos, processos de software.
Um Ecossistema de Software Móvel (em inglês, Mobile Software Ecosystem –
MSECO) é formado por diversos elementos que possuem responsabilidades distintas
dentro do MSECO e que precisam se relacionar de forma harmônica dentro do
ecossistema. Dentre esses elementos, podem ser citados a Aplicação Móvel,
Desenvolvedores, Usuários, Keystone (representante da organização que mantém o
MSECO), Evangelistas (especialista da organização no suporte aos desenvolvedores) e
7
a Loja de Aplicações. Todos eles possuem um papel fundamental para o sucesso do
MSECO, definindo políticas de aceitação de aplicações móveis que irão ser
disponibilizadas aos usuários do MSECO [Fontão et al. 2015].
O desempenho destes elementos precisa ser acompanhado com o objetivo de
identificar e prever áreas de melhoria, assim como validar mudanças. Este cenário na
literatura técnica se refere ao conceito de saúde de ecossistema. Manikas e Hansen
(2013) definem saúde de um ecossistema como a sua habilidade em suportar e
permanecer variável e produtivo durante o tempo.
Em MSECO, os elementos já citados focam no desenvolvimento de aplicações
móveis de qualidade de forma a impactar positivamente na saúde do ecossistema. No
entanto, não se pode garantir que aplicações móveis aprovadas pelos critérios de
aceitação de uma loja resultarão em um número alto de downloads e nem que serão
reconhecidas como “populares” entre usuários e desenvolvedores. Desta forma, a
submissão de uma aplicação baseada somente em critérios da loja, pode causar a
“doença” em elementos do MSECO. A desmotivação do usuário para adquirir uma
aplicação, a desmotivação dos desenvolvedores para criar novas aplicações e a
adaptação constante de estratégias pelo keystone podem ser citados como sintomas.
A partir desta constatação, observa-se que a prevenção para não gerar impacto
negativo na saúde do MSECO não deve ser somente focada na qualidade do produto,
mas deve levar em consideração a qualidade dos processos executados pelo
desenvolvedor (durante a criação e desenvolvimento da aplicação móvel), pelo keystone
(durante a orquestração do ecossistema) e pelo evangelista (durante o suporte e
efetivação de elo entre a organização e o desenvolvedor), uma vez que a saúde do
MSECO é diretamente influenciada por todos os elementos que o compõe.
Logo, há a necessidade de estruturar processos que permitam a definição e
organização das atividades realizadas pelos elementos mencionados e que adotem
mecanismos de qualidade de forma a se obter aplicações móveis que impactem
positivamente na saúde do MSECO. A qualidade do processo impacta na qualidade do
produto que está sendo desenvolvido e, assim, há o impacto na saúde do MSECO. A
utilização de processos pode, então, contribuir para a certificação de que uma aplicação
poderá impactar positivamente na saúde do ecossistema.
O MSECO consiste então de um sistema de evolução cooperativa de aplicações móveis,
desenvolvedores e usuários que formam complexos relacionamentos preenchendo
nichos, competindo e cooperando, de uma forma similar a ecossistemas biológicos [Lin
e Ye 2009].
Em um MSECO, empresas precisam agregar valor a seus produtos, neste caso,
os dispositivos móveis, através das aplicações disponibilizadas em suas lojas. No
entanto, dificilmente estas empresas conseguem atender toda a demanda da sociedade
somente com sua estrutura interna [Bosch 2009]. Neste contexto, as comunidades de
desenvolvedores atuam diretamente na solução para esta limitação [Cusumano 2010].
2.1. Elementos e atividades de MSECO
A seguir são listados os principais elementos que atuam em um MSECO:
8
•
•
•
•
•
•
•
Plataforma: Uma plataforma é a base na qual vários elementos técnicos de um
MSECO são construídos [Taylor 2013]. Ela deve prover o suporte para a
customização em larga escala [Berger et al. 2014].
Aplicações Móveis (Apps): um artefato produzido por desenvolvedor(es) e
adquirido por usuários [Bentley 2014]. Uma app deve obedecer padrões
mínimos de qualidade impostos pelas organizações através da Loja de Apps
[Santos et al. 2014].
Loja de Aplicações Móveis (Loja de Apps): um canal de distribuição utilizado
para publicar, armazenar, buscar e recuperar apps [Fontão et al. 2014]. É um
mercado altamente competitivo [Lim et al. 2014].
Usuário: representa o núcleo de um MSECO. É responsável por adquirir
conteúdo de uma loja de apps e criar novas formas de interação [Fontão et al.
2014].
Desenvolvedor: responsável por novas ideias e o desenvolvimento de apps no
MSECO, respondendo aos requisitos dos usuários [Fontão et al. 2014].
Evangelista: elemento interno da organização patrocinadora do MSECO que
participa em treinamentos, palestras e competições de desenvolvimento com o
objetivo de ajudar na expansão do MSECO e na formação de novos
desenvolvedores [Fontão et al. 2014].
Keystone: cria uma comunidade para adicionar valor aos usuários e aumenta o
número de usuários [Hyrynsalmi et al. 2012].
O desempenho destes elementos precisa ser acompanhado com o objetivo de
identificar e prever áreas de melhoria, assim como validar mudanças [Manikas e Hansen
2013]. A Figura 1 sumariza as etapas necessárias para a organização do trabalho no
contexto de desenvolvimento de aplicações móveis em MSECO.
Na primeira etapa (E1), o keystone precisa empreender esforços na disponibilização
de uma estrutura de base para que o MSECO possa se expandir (Processo de
Orquestração). Isso é pode ser feito por meio de diretrizes que formam o fundamento
para a atração de novos desenvolvedores e, consequentemente, a criação de apps, além
do fornecimento de ferramentas e suporte à comunidade.
Na segunda etapa (E2), o evangelista precisa motivar e engajar outros
desenvolvedores externos e suportá-los para ajudar na expansão da comunidade e,
consequentemente, na disponibilização de uma maior quantidade de apps para os
usuários (Processo de Suporte). Ainda nesta etapa, o desenvolvedor precisa criar e
disponibilizar apps que atendam da melhor forma os nichos existentes de usuários
(Processo de Construção) e, também, obter visibilidade dentro da loja de apps devido à
qualidade das apps por ele desenvolvidas.
9
Fig. 1.Processos e Etapas em MSECO
Na terceira etapa (E3), acontece a publicação da app na Loja de Aplicações Móveis
(Processo de Construção). Assim, a app poderá ser adquirida por usuários e já
contribuirá para as metas do keystone, como: quantidade de aplicações e avaliações do
usuário. Essas métricas de quantidade de apps, média de avaliações dos usuários e
quantidade de desenvolvedores que publicam apps alimentam os indicadores do
MSECO, na etapa E4.
A etapa E5 compreende as análises de estratégias que podem ser realizadas pelo
keystone para a adequação de modos de trabalho com a comunidade de
desenvolvimento e com a equipe de evangelismo. A proposta dessas etapas e processos
responde à categoria 1 de desafios de qualidade em ECOS, Processos de Software e
Padrões, indicada em [Santos et al. 2014].
As etapas E1 e E2 compreendem uma fase de Pré-Publicação, ou seja, antes da
aplicação ser submetida à loja, na etapa E3. Esta pesquisa possui como foco essas etapas
(E1 e E2), propondo a abordagem MSECO Cert (Mobile Software Ecossystem app
Certification), composta pelos processos de Orquestração, Suporte e Construção e o
conjunto de recomendações e práticas, com o objetivo de certificar aplicações antes da
submissão à loja de forma a impactar positivamente a saúde do MSECO. Isso poderá ser
avaliado por meio de indicadores de saúde de MSECO, tais como: número de
downloads e avaliação das apps que foram desenvolvidas a partir da abordagem.
Os trabalhos relacionados a esta pesquisa estão sumarizados na Tabela 1, com as
seguintes colunas: (1) Trabalho: referência do estudo; (2) Contribuição: o resultado
principal provido no estudo; (3) Certificação: como o trabalho trata a questão de
certificação de qualidade em software; e (4) ECOS (Ecossistemas de Software)? Se o
trabalho faz alguma utilização do conceito de ECOS.
O foco da garantia de qualidade nos trabalhos apresentados é a qualidade do
produto, que neste caso, é a aplicação móvel. Assim, existe a necessidade da definição
de recomendações para desenvolvimento para lojas de apps, de modelos, processos,
práticas, abordagens ou metodologias que permitam gerenciar as contribuições, neste
caso, a aplicação móvel. Observou-se ainda a necessidade de envolver os outros
elementos, como evangelista, desenvolvedor e keystone, para certificar a qualidade de
aplicações no contexto de MSECO.
10
Tabela 1. Sumarização de trabalhos relacionados.
Trabalho
Contribuição
Certificação de qualidade
ECOS?
Costan et al.
(2013).
Processo de Evolução
de Aplicação
Deve considerar as contribuições dos usuários.
A Loja tem a “missão” de certificar a qualidade.
Sim
Fontão et al.
(2012)
Metodologia para
desenvolvimento
Visa atender às necessidades dos usuários,
levando em consideração os requisitos da Loja.
Não
Corral et al.
(2014)
Análise da literatura
sobre práticas de
qualidade de apps
Menciona o avanço de ecossistemas móveis,
mas não utiliza esse contexto na análise de
uma forma aprofundada envolvendo a
certificação de qualidade.
Não
Jansen et al.
(2013)
Abordagem que
envolve políticas de
Loja de Apps
Visão geral de características e políticas que
determinam a estrutura de uma loja de apps.
Sim
Bettenburg
et al. (2013)
Modelo de
gerenciamento de
contribuições
Modelo de gerenciamento de contribuições com
fases de gerenciamento de software.
Sim
Franco et al.
(2014)
Modelo de qualidade
para Ecossistemas de
Software Livre
Modelo de qualidade como uma forma de
prevenir decisões ruins, desviar problemas e
permitir a verificação com requisitos e objetivos
de negócios.
Sim
MCTI-BR
(2013)
CERTICS:
Metodologia para
certificação de
software
Certifica se um software é produzido a partir de
atividades de desenvolvimento e inovação
tecnológica do país.
Não
4. Método de Pesquisa e Estado Atual do Trabalho
Esta pesquisa foi estruturada em duas fases principais, concepção e avaliação, conforme
descrito nas subseções.
4.1. Fase de Concepção
•
•
•
•
C1) Mapeamento sobre MSECO, seguindo os princípios de um mapeamento
sistemático [Kitchenham et al. 2007]. Os resultados deste mapeamento
sistemático foram publicados e estão disponíveis em [Fontão et al. 2015].
C2) Definição de processos que estruturam as atividades dentro de um MSECO
com o objetivo de entender as atividades, elementos e artefatos envolvidos.
C3) Definição de recomendações e práticas para cada atividade como forma de
suportar a execução da atividade visando impactar positivamente na saúde do
MSECO. A definição dos processos de Orquestração (seguido pelo keystone),
Suporte (seguido pelo evangelista) e Construção (seguido pelo desenvolvedor) e
o conjunto de recomendações e práticas estão disponíveis em:
http://1drv.ms/1Ikokmw.
C4) Estudos Experimentais: dois estudos foram realizados nesta fase da pesquisa
o Revisão por Pares: com objetivo de avaliar se os processos especificados
neste trabalho estão adequados para atender às necessidades de
orquestração, desenvolvimento de aplicações móveis e evangelismo, do
ponto de vista de profissionais com experiência nas áreas de
11
•
conhecimento dos processos (keystones - gerentes ou coordenadores de
MSECO, desenvolvedores de aplicações móveis e evangelistas).
o Questionários: com o objetivo de analisar os processos em suas práticas
e recomendações para analisar os benefícios percebidos por especialistas
(evangelistas e desenvolvedores). Estes questionários avaliarão os
processos de Suporte e Construção, uma vez que são processos onde
pode-se atuar diretamente neste trabalho por meio de treinamentos
ministrados por evangelistas para comunidades de desenvolvedores.
C5) Definição da abordagem MSECO Cert a partir dos resultados da etapa C4,
visando certificar aplicações móveis em MSECO com o objetivo de impactar
positivamente na saúde do MSECO.
A Fase de Concepção descrita neste trabalho já foi concluída. Neste momento da
pesquisa, está sendo iniciada a fase de avaliação, descrita na próxima subseção.
4.2. Fase de Avaliação
Para avaliação desta pesquisa, faz-se necessária a realização de estudos experimentais
visando caracterizar a abordagem proposta em relação ao seu objetivo, identificar
defeitos, visando permitir a transferência dessa tecnologia para o contexto industrial.
A análise da qualidade dos processos se dará a partir do impacto que a utilização
deles gera em indicadores, como: número de desenvolvedores treinados (a partir de
survey sobre o conhecimento adquirido), qualidade das apps desenvolvidas (avaliação
da app pelos usuários), quantidade de apps geradas e desenvolvedores que se tornaram
publicadores de apps. Para isso, duas etapas foram definidas:
•
•
(A1) Aplicação da MSECO Cert no cenário da indústria: em treinamentos para
desenvolvimento de apps ministrados por evangelistas para comunidade de
desenvolvedores;
(A2) Refinamento da MSECO Cert: a partir dos resultados de A1, aprimorar a
abordagem (atividades, artefatos, recomendações e práticas) para a adequação a
atividades de desenvolvimento e evangelismo no contexto de MSECO.
Serão executadas 3 rodadas das atividades A1 e A2 no MSECO Microsoft,
especificamente para a plataforma Windows Phone, conforme a descrição a seguir:
•
•
1ª) (Junho e Julho) e 2ª) (Agosto e Setembro) rodadas: aplicação em paralelo
da MSECO Cert: serão realizados treinamentos em paralelo com 2 turmas de
desenvolvedores, sendo 1 turma com aplicação da MSECO Cert pelo
responsável pela pesquisa (que possui essa função dentro de uma organização de
software que atua no MSECO Microsoft) e 1 turma sem aplicação da MSECO
Cert, por outro evangelista da mesma organização.
3ª) (Outubro e Novembro) rodada: aplicação da MSECO Cert por outro
evangelista (diferente do pesquisador responsável por este trabalho) com uma
turma de desenvolvedores a fim de avaliar a aplicabilidade da abordagem por
outros profissionais.
A abordagem pode ser aplicada a qualquer MSECO como forma de apoio ao
evangelista para o alcance das metas organizacionais definidas pelo keystone. A partir
de cada rodada avaliaremos o impacto da abordagem no alcance de metas através dos
indicadores já citados.
12
5. Resultados Esperados
Em resumo, espera-se como contribuição deste trabalho a definição de uma abordagem
de certificação de qualidade de aplicações móveis para MSECO. Essa abordagem
resultará na modelagem dos processos (Orquestração, Suporte e Construção), definição
de atividades, papéis responsáveis, artefatos e relacionamentos, definição de um
conjunto de recomendações que servirão como base para a realização de uma atividade
de um dos processos definidos e elaboração de um conjunto de práticas visando a
aplicação de uma regra para a obtenção de resultados concretos.
Referências
Bentley, P. J. (2012). How to be a Successful App Developer: Lessons from the
Simulation of an App Ecosystem. Em: GECCO 2012, Philadelphia, pp. 129-136.
Berger, T., Pfeiffer, R.-H., Tartler, R., et al. (2014). Variability mechanisms in software
ecosystems. Information and Software Technology, v. 56, n. 11, p. 1520–1535.
Bosch, J. (2009). From Software Product Lines to Software Ecosystems. Em SPLC ’09
Proceedings of the 13th International Software Product Line Conference, Pittsburgh.
Cusumano, M. A. (2010). Platforms and Services: Underständing the Resurgence of
Apple. Communications of the ACM, v. 53, p. 22–24.
Fontão, A., Bonifácio, B., Dias-Neto, A., Bezerra, A. and Santos, R. (2014). MSECO
Skill: Construção de Competências de Desenvolvedores em Ecossistemas de
Software Móvel. Em: 17th CIBSE, Pucón, Chile.
Fontão, A., Santos, R. P. and Dias-neto, A. C. (2015). Mobile Software Ecosystem
(MSECO): A Systematic Mapping Study. Em: COMPSAC 2015, Taichung, Taiwan.
Hyrynsalmi, S., Mäkilä, T., Järvi, A., et al. (2012). App store, marketplace, play! an
analysis of multi-homing in mobile software ecosystems. Em: 4th IWSECO.
Kitchenham, B. and Charters, S. (2007). Guidelines for performing Systematic
Literature reviews in Software Engineering Version 2.3.
Lim, S. L., Bentley, P., Kanakam, N., Ishikawa, F. and Honiden, S. (2014).
Investigating Country Differences in Mobile App User Behavior and Challenges for
Software Engineering. IEEE Transactions on Software Engineering, v. 5589, n. c, p.
1–1.
Lin, F. L. F. and Ye, W. Y. W. (2009). Operating System Battle in the Ecosystem of
Smartphone Industry. 2009 International Symposium on Information Engineering
and Electronic Commerce,
Manikas, K. and Hansen, K. M. (2013). Reviewing the Health of Software Ecosystems
– A Conceptual Framework Proposal. Em: 5th IWSECO.
Santos, R., Valença, G., Viana, D., et al. (2014). Qualidade em Ecossistemas de
Software: Desafios e Oportunidades de Pesquisa. Em:VIII WDES, CBSoft, Maceió,
2014, pp. 41-44.
Taylor, R. N. (2013). The role of architectural styles in successful software ecosystems.
Em ACM International Conference Proceeding Series.
13
Estratégia de Apoio à Seleção de Elementos de Elicitação
de Requisitos
Renata Magalhães Rêgo (Aluna), Arilo Cláudio Dias-Neto (Orientador)
Instituto de Computação (IComp) – Universidade Federal do Amazonas (UFAM)
Av. General Rodrigo Octávio, 6.200, Campus Universitário Senador Arthur Virgílio
Filho – Setor Norte - Manaus - CEP 69.077-000 – Manaus – AM – Brasil
Resumo. A elicitação de requisitos é uma atividade fundamental em um projeto
de software e geralmente depende de três elementos chaves: a técnica usada
para identificar/coletar os requisitos, os analistas alocados para realizar essa
tarefa e os patrocinadores disponíveis para fornecer as necessidades dos
clientes. A seleção adequada desses elementos durante o processo de elicitação
tem impacto direto sobre o sucesso/fracasso do projeto. Neste trabalho propõese desenvolver uma estratégia que auxilie o Engenheiro de Software na seleção
destes elementos durante a fase de elicitação de requisitos de um projeto,
considerando as suas particularidades, utilizando estratégias de SBSE
multiobjetivo que visa maximizar a adequação e reduzir os custos de tais
elementos em relação ao projeto de software. Foi realizado um estudo empírico
utilizando dados de um projeto real comparando os resultados providos por um
algoritmo evolutivo multiobjetivo (NSGA-II) e um algoritmo Randômico. Os
resultados sugerem a viabilidade de aplicar algoritmos evolutivos, pois o
mesmo forneceu as melhores soluções de compromisso para este problema.
Abstract. Requirements elicitation is a fundamental activity in a software
project that depends on three key elements: the technique used to identify/collect
the requirements, the analysts allocated to accomplish this task and the
available suppliers to provide customer´s needs. The adequate selection of these
elements during the elicitation process has a direct impact on the software
project’s success/failure. This work proposes to develop a strategy to assist the
software engineer in selecting the most appropriate combination of elicitation
elements for each project, considering their particularities, using a
multiobjective SBSE strategies that aims to maximize the suitability and reduce
the costs of these elements in a software project. An empirical study was
performed using data from a real software project comparing the results
provided by a multi-objective evolutionary algorithm (NSGA-II) and a Random
algorithm. The results suggest the feasibility of applying evolutionary
algorithms, because it provided the best compromise solutions to this problem.
Palavras-Chave: Elicitação de Requisitos, Seleção de Tecnologias, Otimização
Combinatória, Metaheurísticas, SBSE.
14
1. Introdução e Caracterização do Problema
A Engenharia de Requisitos (ER) é uma fase comum em processos de desenvolvimento
de software, pois trata da concepção do projeto e permite que seja examinado o contexto
de negócio, as necessidades específicas do cliente e os comportamentos que terão um
impacto profundo no projeto, dentre outros [Sommerville, 2011]. Pressman (2014) divide
esta fase em algumas tarefas: Concepção, Elicitação, Negociação, Especificação e
Validação. Esta pesquisa concentra-se na tarefa de ER, que consiste em descobrir e extrair
as informações sobre o sistema a ser desenvolvido.
A ER é realizada de forma recorrente durante o projeto de software e existem
vários elementos envolvidos na sua realização, tais como: analistas responsáveis pela
coleta de requisitos; os patrocinadores que têm as informações sobre os requisitos; e as
técnicas que serão utilizadas para apoiar a elicitação. Cada elemento possui características
próprias que podem influenciar a ER [Carrizo et al. 2014].
Com base neste cenário, este trabalho descreve o problema de selecionar três
elementos presentes nas atividades de ER (técnicas, analistas e patrocinadores)
considerando as peculiaridades de cada elemento e as características do projeto de
software. Acredita-se que a seleção adequada de tais elementos pode contribuir para a
qualidade da informação coletada para um projeto de software e, consequentemente, a
qualidade do produto final.
O Problema de Seleção de Elementos de ER (em inglês, Selection of Requirements
Elicitation Elements – SREE) pode ser caracterizado como um cenário onde o gerente de
um projeto de software possui (ver Figura 1): (1) um conjunto de técnicas de elicitação
de requisitos; (2) um conjunto de patrocinadores ou usuários do software a ser
desenvolvido; e (3) um conjunto de analistas disponíveis para realizar a elicitação. Esse
gerente precisa encontrar uma combinação entre técnicas, patrocinadores e analistas que
possibilite a coleta do maior número de requisitos sem que isso exceda o custo destinado
a elicitação.
Considerando o número crescente de técnicas de elicitação publicadas na
literatura técnica, o conjunto de analistas e patrocinadores disponíveis para um projeto e
as características envolvidas no contexto do projeto, o SREE torna-se uma tarefa
complexa em um projeto de software, pois quando são feitas todas as possíveis
combinações, o conjunto de soluções aumenta significativamente, inviabilizando a
análise manual.
Nesse contexto, diversos problemas de Engenharia de Software (ES) possuem
natureza complexa e que não podem ser tratados por técnicas convencionais, pois
envolvem a seleção de uma solução dentro de um grande conjunto [Freitas et al., 2009].
Tais problemas requerem soluções automatizadas que tratem seus diversos aspectos de
forma eficiente [Harman et al., 2010]. Algoritmos com estratégias avançadas de busca,
especialmente metaheurísticas, podem ser utilizados para resolver esses problemas. A
aplicação de metaheurísticas em tais problemas se intensificou nos últimos anos, dando
origem a uma nova e promissora área, conhecida como Engenharia de Software Baseada
em Busca (do inglês, Search-Based Software Engineering – SBSE). Segundo Colanzi et
al., (2013), SBSE é o campo de pesquisa e prática que aplica técnicas baseadas em busca
para resolver diferentes problemas de otimização em ES. Para Harman et al. (2010), as
abordagens de SBSE oferecem um conjunto de soluções adaptativas para situações em
que o problema envolve múltiplos objetivos concorrentes e conflitantes.
15
Figura 1: Problema da Seleção de Elementos de Elicitação de Requisitos.
Este artigo apresenta uma proposta de dissertação de mestrado sendo
desenvolvida no Programa de Pós-Graduação em Informática da Universidade Federal do
Amazonas. Nesta pesquisa, pretende-se construir e avaliar uma abordagem para a
recomendação de elementos de elicitação utilizando estratégias de SBSE, a fim de auxiliar
ao Engenheiro de Software na seleção dos elementos de elicitação de requisitos. Neste
problema são considerados dois objetivos: maximizar a adequação dos elementos ao
projeto e minimizar o custo de alocação e utilização desses elementos.
Nesta seção, serão apresentados os conceitos relevantes relacionados ao desenvolvimento
dessa pesquisa.
2.1. Elicitação de Requisitos
A Elicitação de requisitos é um conjunto de ações que ocorrem junto aos patrocinadores
e usuários visando capturar as informações que subsidiarão o entendimento do problema
e a modelagem do software a ser desenvolvido [Dias et al., 2006]. Executar essas ações
não é uma tarefa trivial, e se ela não for feita de forma adequada, poderá comprometer as
demais fases do processo, inviabilizando o projeto como um todo [Sadiq et al., 2009].
Figura 2: Identificação das técnicas de Elicitação (Zhang, 2007).
As técnicas de elicitação são utilizadas para dar apoio ao processo de ER. De
acordo com Zhang (2007) e Tiwari et al. (2012), elas podem divididas em 4 categorias,
conforme apresentado na Figura 2. As técnicas conversadas são as baseadas em perguntas
de respostas, as colaborativas são aplicadas em grupos e precisam de um moderador, as
16
cognitivas são baseadas em conhecimentos e as observacionais são para coletar
informações difíceis de serem verbalizadas.
2.2. Fatores de Influência
Existem elementos de elicitação que podem influenciar a aplicação das técnicas, e por
consequência a elicitação de requisitos. Esses elementos, chamados de fatores de
influência, são: o patrocinador ou usuário, o analista e o projeto de software a ser
desenvolvido. Na Tabela 1 são apresentados esses elementos e os atributos que foram
utilizados para fazer a sua caracterização.
Essa caracterização foi definida seguindo os trabalhos de [Carrizo et al., 2014],
[Kausar et al., 2010] e [Tiwari et al., 2012]. Nela, o analista possui 11 atributos, o
patrocinador possui 10 atributos e o projeto possui 8. Para cada um dos atributos, foi
apresentada uma possível classificação, ou seja, quais valores esse atributo pode assumir
na caracterização.
Tabela 1. Fatores de influência e seus atributos.
Projeto
Patrocinador (Informante)
Analista
Ele. ID
A01
A02
A03
A04
A05
A06
A07
A08
A09
A10
A11
I01
I02
I02
I04
I05
I06
I07
I08
I09
I10
P01
P02
P03
P04
P05
P06
P07
P08
Atributo
Treinamento em técnicas de elicitação
Experiência com elicitação
Experiência com técnicas de elicitação
Familiaridade com o domínio
Habilidade na condução de conversas
Habilidades na resolução de conflitos
Habilidades com liderança e motivação
Habilidades com trabalho em equipe
Habilidade em registrar eventos
Habilidade com e captura de ideias
Habilidade analítica
Pessoas por sessão
Consenso entre os patrocinadores
Interesse do patrocinador
Nível de Experiência
Capacidade de Articulação
Disponibilidade de tempo
Localização/ Acessibilidade
Habilidade de comunicação
Habilidade de trabalho em equipe
Habilidade em expressar ideias
Tipo de informação a ser coletada
Disponibilidade da informação
Definição do problema
Restrição de Tempo do Projeto
Tempo de processo
Status do Projeto
Escopo do Projeto
Tipo de projeto
Possível Classificação
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Individual, Grupo (2-5), Muitos (+5)
Alto, Baixo
Alto, Médio, Baixo
Especialista, Conhecedor, Iniciante
Alto, Médio, Baixo
Alto, Baixo
Longe, Perto
Alto, Médio, Baixo
Alto, Médio, Baixo
Alto, Médio, Baixo
Estratégica, Tática, Básica
Muito, Pouco, Zero
Alto, Baixo
Alto, Baixo, Zero
Início, Meio, Fim
Novo, Existente
Específico, Genérico
Críticos, Tempo Real, Distribuídos,
Interativos, Pequeno e médio porte.
Os trabalhos correlatos identificados abordam a seleção de elementos da fase de ER (em
geral, técnicas) e outros que tratam a seleção de tecnologias em geral, utilizando
17
estratégias de SBSE), cujas contribuições são úteis para essa pesquisa, conforme
apresentado na Tabela 2.
Como se pode observar na Tabela 2, os trabalhos de Kausar et al. (2010) e Tiwari
et al. (2012) tratam da seleção de técnicas ER. Eles utilizam como estratégia de solução
função matemática e mapeamento, e as soluções são apresentadas, respectivamente, em
forma e ranking e lista de técnicas. O trabalho de Carrizo et al. (2014) também trata da
seleção de técnicas e ainda considera os outros elementos (analistas e patrocinadores)
para a seleção. Como limitação, ele não faz a combinação entre esses, mas apenas o
mapeamento que torna possível fazer o ranking das técnicas. Os trabalhos de Dias-Neto
et al. (2011) e Grande et al. (2014) tratam a seleção de tecnologias de software em geral
aplicando estratégias de SBSE (metaheurísticas) e em ambos, as respostas são
apresentadas em forma de gráfico, apresentando os itens considerados na seleção.
Esta pesquisa visa recomendar ao engenheiro de software soluções que contenham
a combinação dos elementos de elicitação adequados ao projeto utilizando estratégias de
SBSE (metaheurísticas) para encontrar o conjunto soluções. Elas serão apresentadas no
Gráfico da Frente de Pareto de forma a identificar a adequação e o custo de cada solução
ao projeto, facilitando assim a tomada de decisão.
Tabela 2. Trabalhos Relacionados e Proposta de Pesquisa.
Trabalho
Contribuição
Kausar, et. al.
(2010)
Tiwari et al.
(2012)
Seleção de técnica de elicitação de
requisitos
requisitos
Carrizo et al.
requisitos considerando perfil de
(2014)
analistas e patrocinadores
Dias-Neto et
Seleção de tecnologias de software
al. (2011)
Grande et al.
Seleção de tecnologias de software
(2014)
Combinação e Seleção de elementos
Esta Proposta
de elicitação de requisitos
Estratégia
Utilizada
Função
matemática
Solução
Ranking
Mapeamento
Lista de Técnicas
Mapeamento
Ranking
Metaheurísticas SBSE
Metaheurísticas –
SBSE
Metaheurísticas –
SBSE
Gráfico da Frente
de Pareto
Gráfico de radar
Gráfico da Frente
de Pareto
Na próxima seção será apresentado a metodologia e o estado atual do trabalho.
4. Metodologia e Estado Atual do Trabalho
A metodologia empregada para o desenvolvimento deste trabalho de pesquisa está
dividida em duas fases: Concepção e Avaliação. Estes encontram-se descritos a seguir.
4.1. Fase de Concepção
 C1) Levantamento na Literatura Técnica acerca das Técnicas e Metodologias
utilizadas para Elicitação de Requisitos de Software. Nesta atividade, foram
encontradas 23 técnicas divididas em 4 categorias (Figura 2).
 C2) Levantamento na Literatura Técnica acerca dos Atributos e Fatores
contextuais que podem influenciar a seleção das técnicas de elicitação. Foram
encontrados 3 fatores de influência, que juntos somam 29 atributos (Tabela 1).
18




C3) Definição da estratégia para caracterizar os elementos de requisitos e coletar
a situação contextual do projeto e dos elementos de elicitação. Foram definidas
perguntas para cada um dos 29 atributos dos fatores de influência.
C4) Definição do modelo de Matemático para o problema SREE para tornar
possível a utilização de metaheurísticas. Foram definidos: o modelo dos
cromossomos e as duas funções objetivo (f1 = função de maximização da
adequação e f2 = função de minimização do custo).
C5) Análise, definição e implementação de metaheurísticas para realização dos
experimentos. Foram definidas para implementação as Metaheurísticas: NSGAII,
MOCell, e SPEA2, por serem algoritmos evolutivos multiobjetivo.
C6) Implementação da Ferramenta de Apoio para que o Engenheiro de Software
possa inserir os dados do projeto, dos analistas e dos patrocinadores/usuários e
solicitar a recomendação visando obter como resposta um conjunto de possíveis
soluções, para que ele possa tomar as decisões de projeto conforme a adequação
e custo dos elementos para o projeto. Esta ferramenta torna-se importante no
contexto da proposta pois, em geral, engenheiros de software não possuem tempo
suficiente em um projeto real para configurar ambientes e dados para a execução
de metaheurísticas, pois estas requerem um conhecimento aprofundado em tais
conceitos. Desta forma, a ferramenta servirá como interface entre o engenheiro de
software e os algoritmos a serem modelados nesta pesquisa, facilitando sua
aplicação em projetos de software. Além disso, a sua construção possibilitaria a
realização de experimentos comparando os dados providos pelos algoritmos com
dados oriundos de especialistas na área. A arquitetura dessa ferramenta encontrase na Figura 3.
Figura 3: Arquitetura da Ferramenta de Apoio.
4.2. Fase de Avaliação
 A1) Condução do Estudo de Viabilidade com um algoritmo randômico e uma
metaheurística. Esse estudo foi realizado com o algoritmo NSGA-II, no qual, os
resultados do algoritmo NSGA-II superaram o algoritmo randômico em todas as
instancias.
 A2) Condução do Estudo comparativo do resultado do primeiro estudo com outras
metaheurísticas. Para esse estudo serão utilizados o NSGA-II (avaliado no passo
anterior), MOCell e SPEA2. A pesquisa encontra-se atualmente nesta fase.
 A3) Refinamento da abordagem e calibragem dos pesos de características,
penalidades e restrições. A partir dos experimentos, identificar pontos de melhoria
nos parâmetros dos algoritmos.
 A4) Avaliação da abordagem por meio da sua comparar com outras propostas da
literatura, por exemplo, com Carrizo et al. (2014), em relação ao apoio provido
para a seleção das técnicas de ER segundo a visão de especialistas em ER.
19
Espera-se como resultado dessa pesquisa: (i) a Modelagem de um novo problema em
SBSE, Seleção de Elementos de Elicitação de Requisitos, uma vez que esse problema não
havia sido tratado por essa perspectiva; (ii) Ferramenta de apoio a seleção de elementos
de elicitação, onde o engenheiro de software poderá inserir os dados relacionados ao
projeto, analistas e patrocinadores e recebe como resposta um conjunto de soluções
apresentado por meio do gráfico da Frente de Pareto, seguindo os objetivos de maior
adequação e menor custo.
Referências
Carrizo, D.; Dieste, O; Juristo, N. (2008). Study of Elicitation Techniques Adequacy. In
Workshop on Engenharia de Requisitos (WER), Barcelona, Espanha.
Carrizo, D.; Dieste, O.; Juristo, N. (2014). “Systematizing requirements elicitation
technique selection”, In: Information and Software Technology. Vol, 56, 6 (June
2014), pp. 644-669.
Colanzi, T.E.; Vergilio, S. R.; Assunção, W. K. G. E Pozo, A. (2013). Search Based
Software Engineering: Review and analysis of the field in Brazil. Journal of Systems
and Software, Volume 86, Issue 4, Pages 970-984.
Dias-Neto, A. C., Rodrigues, R. F., Travassos, G. H. (2011). Porantim-opt: optimizing
the combined selection of model-based testing techniques. In 2011 IEEE Fourth
International Conference on Software Testing, Verification and Validation
Workshops, pp. 174-183.
Freitas, F. G. de; Maia, C. L. B.; Coutinho, D. P. G.; Campos, A. L. de, e Souza, J. T. de.
(2009) "Aplicação de Metaheurísticas em Problemas da Engenharia de Software:
Revisão de literatura", II Congresso Tecnológico Infobrasil (Infobrasil 2009).
Grande, A. S.; Rodrigues, R. F.; Dias-Neto, A.C. (2014) “A Framework to Support the
Selection of Software Technologies by Search-Based Strategy”, 2014 IEEE 26th
International Conference on Tools with Artificial Intelligence (ICTAI), pp. 979-983.
Harman, M. e Mansouri, A. (2010). "Search Based Software Engineering”, IEEE
Transactions on Software Engineering , vol.36, no.6, pp.737, 741.
Kausar, S.; Tariq, S.; Riaz, S.; Khaum, A. (2010). “Guidelines for the selection of
elicitation techniques”, 6th International Conference on Emerging Technologies
(ICET), pp. 265-269.
Pressman, R. (2014). Software Engineering: A Practitioner's Approach (8th ed.).
McGraw-Hill Higher Education.
Sadiq, M.; Ghafir, S.; Shahid, M., (2009) "An Approach for Eliciting Software
Requirements and its Prioritization Using Analytic Hierarchy Process", International
Conference on Advances in Recent Technologies in Communication and Computing.
Sommerville, I. "Engenharia de Software". 9ª Ed.–SP: Pearson Prentice Hall, 2011.
Tiwari, S.; Rathore, S. S.; Gupta, A. (2012). “Selecting requirement elicitation techniques
for software projects”, 6th International Conference on Software Engineering.
Zhang, Z. (2007). “Effective Requirements Development – A Comparison of
Requirements Elicitation techniques”. In: INSPIRE 2007, Tampere, Finland.
Zowghi, D.; Coulin, C. (2005). “Requirements Elicitation: A survey of Techniques,
Approaches and Tools”. In: Engineering and Managing Software Requirements. pp:
19-46. Springer, Verlag.
20
Aprendizagem Organizacional em Instituições Implementadoras e
Avaliadoras do MPS.BR
Raphael Freire, Gleison Santos
Programa de Pós-Graduação em Informática - Universidade Federal do Estado do Rio de Janeiro
(UNIRIO) - Av. Pasteur, 458, Urca, CEP 22290-240 - Rio de Janeiro, RJ
{raphael.freire, gleison.santos}@uniriotec.br
Abstract. The successful implementation of software process improvement (SPI) initiatives
depends fundamentally on the strategies adopted to support them. In the literature, there are
several studies that use Knowledge Management (KM) to support software development
organizations. However, there are few studies that approach how the KM can support the
consultants and appraisers of MPS initiatives. The objective of this study is to verify the
necessity of training of consultants and appraisers and, thus, create a strategy to facilitate
the Organizational Learning (OL) of Implementation and Assessment Institutions.
Resumo. O sucesso na implementação de iniciativas de melhoria de processos de software
(MPS) depende fundamentalmente de estratégias adotadas para apoiar a execução de tais
iniciativas. Na literatura existem diversos estudos que utilizam a Gerência de Conhecimento
(GC) para apoiar organizações desenvolvedoras de software. Porém, há uma carência de
trabalhos que tratam de como a GC pode apoiar os consultores e avaliadores de iniciativas
de MPS. O objetivo deste trabalho é entender as necessidades de capacitação dos
consultores e avaliadores e, assim, criar uma estratégia para facilitar o Aprendizado
Organizacional (AO) de Instituições Implementadoras e Instituições Avaliadoras.
Uma das premissas para que uma organização seja competitiva é ter know-how para identificar,
gerenciar, proteger e explorar os seus recursos de forma eficiente [BASILI et al. 2001]. Em muitas
dessas organizações, o conhecimento é o mais importante, valioso, e crítico dos recursos [BASILI et
al. 2001]. Resultados de um estudo feito em 2005 [ROCHA et al. 2005] apontaram que uma das
maiores dificuldades encontradas na implantação dos processo está relacionada às competências das
equipes das empresas, em particular o pouco conhecimento em Engenharia de Software. Um novo
estudo realizado em 2014 pela SOFTEX [Rocha, 2014] também reforça essa constatação. Neste
sentido, torna-se essencial desenvolver uma estratégia efetiva para transferência do conhecimento
necessário para a execução dos processos [BARRETO et al. 2006].
Da mesma forma como na execução de um projeto de desenvolvimento, uma implantação de
processos de software em uma organização é fortemente baseada em conhecimento. É de fundamental
importância não apenas para a implantação de uma iniciativa de melhoria, mas também para sua
continuidade, que as pessoas responsáveis por executar os processos a serem implantados sejam
capacitadas para isso [BARRETO et al. 2006]. A perda do conhecimento, seja com a saída de
membros, esquecimento de soluções ou avanços tecnológicos, gera problemas significativos para as
21
organizações. Neste sentido, torna-se essencial desenvolver uma estratégia efetiva para transferência
do conhecimento necessário para a execução dos processos [BARRETO et al. 2006].
Montoni (2010) realizou uma investigação sobre fatores críticos de sucesso em iniciativas de
melhoria de processos de software. Um dos fatores de sucesso identificados está relacionado à
adequação da implementação dos processos e procedimentos com as especificidades da organização.
Segundo o autor, para alcançar este fator, os consultores devem possuir conhecimento adequado em
engenharia de software, além de serem flexíveis para lidar com situações críticas durante a
implementação [MONTONI, 2010]. No entanto, na literatura há carência de estudos relacionados ao
apoio da Gerência de Conhecimento para consultores em melhoria de processos de software. Diante
deste problema, esta pesquisa visa suprir esta lacuna e criar mecanismos de Aprendizagem
Organizacional para consultores neste sentido.
2.1 Aprendizagem Organizacional e Gerência de Conhecimento
De acordo com Senge (1994), Aprendizagem Organizacional (AO) pode ser definida como o ciclo
contínuo de experiência e sua transformação em conhecimento acessível por toda organização e que
seja relevante para suas finalidades básicas. Em outras palavras, AO é um processo adaptativo de
mudança influenciado pela experiência no passado, e é centralizado no desenvolvimento ou
modificação de rotinas e apoiado pela memória organizacional. O conhecimento é criado por
indivíduos, e suas capacidades, crenças, e experiências, e cristalizado como parte do conhecimento
organizacional [Menolli et al, 2013].
Segundo Takeuchi e Nonaka [2008], existem dois tipos de conhecimento: tácito e explícito. O
conhecimento explícito pode ser expresso em palavras, números ou sons, e compartilhado na forma de
dados, fórmulas científicas, recursos visuais, fitas de áudio, especificações de produtos ou manuais. O
conhecimento explícito pode ser rapidamente transmitido aos indivíduos, formal e sistematicamente.
O conhecimento tácito, por outro lado, não é facilmente visível e explicável. Pelo contrário, é
altamente pessoal e difícil de formalizar, tornando-se de comunicação e compartilhamento dificultoso.
As instituições e os palpites subjetivos estão sob a rubrica do conhecimento tácito. O conhecimento
tácito está profundamente enraizado nas ações e na experiência do indivíduo, assim como nos ideais,
valores ou emoções que ele incorpora.
Ainda segundo os autores, existem quatro modos de conversão de conhecimento. São eles: (i)
de conhecimento tácito em conhecimento tácito, que é chamada de socialização, (ii) de conhecimento
tácito em conhecimento explícito, que é denominada de externalização, (iii) de conhecimento explícito
em conhecimento explícito, ou combinação, e por fim, (iv) de conhecimento explícito para tácito, ou
internalização [NONAKA e TAKEUCHI, 2008].
2.2 Gerência de Conhecimento Aplicada em Iniciativas de Melhoria de Processos de
Software
O MPS.BR, criado em dezembro de 2003, é um programa mobilizador, de longo prazo, coordenado
pela Associação para Promoção da Excelência do Software (SOFTEX), que conta com o apoio do
Ministério da Ciência, Tecnologia e Inovação (MCTI), Financiadora de Estudos e Projetos (FINEP),
Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de
Desenvolvimento (BID/FUMIN) [SOFTEX, 2012]. O MPS.BR é um programa voltado para Melhoria
do Processo de Software Brasileiro. Seu objetivo é definir e aprimorar um modelo de melhoria e
22
avaliação de processo de software e serviços, visando preferencialmente às micro, pequenas e médias
empresas [SOFTEX, 2012].
A utilização de Gerência de Conhecimento (GC) é um dos resultados esperados nas
organizações que implantam o nível E do Modelo de Referência MPS para Software (MR-MPS-SW),
devido à existência do processo de Gerência de Recursos Humanos. O objetivo deste processo é
prover a organização e os projetos com os recursos humanos necessários e manter suas competências
adequadas às necessidades do negócio [SOFTEX, 2012]. De forma complementar, o processo requer
uma manutenção do conhecimento organizacional através de estratégias de GC. Assim como
empresas de desenvolvimento necessitam aplicar GC, implementadores e consultores MPS.BR
também carecem desta disciplina.
A GC em uma organização de software é vista como uma oportunidade de criar uma
linguagem comum de entendimento entre desenvolvedores de software, de tal forma que eles possam
interagir, negociar e compartilhar conhecimento e experiências [AURUM, 2003]. A necessidade de
desenvolver cada vez mais práticas de Engenharia de Software dentro das organizações aumenta a
demanda pelo conhecimento sistemático e gestão de competências em todas as fases de um ciclo de
vida de software [AURUM, 2003].
No que diz respeito à implantação de processos de software em uma organização, o
conhecimento daqueles que executarão os processos é de fundamental importância para que a
iniciativa de melhoria seja bem sucedida e produza os resultados esperados. Considerando que
organizações de consultoria em melhoria de processos de software têm a implementação de melhoria
de processos como seu negócio principal, e que o seu sucesso implica diretamente no sucesso das
iniciativas de melhoria de organizações de software que contratam seus serviços, é fundamental
fornecer mecanismos adequados de GC para apoiar organizações de consultoria em melhoria de
processos no estabelecimento de estratégias de implementação de melhorias de processos de software.
Para tanto, é essencial que as estratégias adotadas levem em consideração as condições
organizacionais favoráveis para implementar melhorias, bem como apóiem de forma adequada o
tratamento dos fatores críticos que podem influenciar o sucesso de iniciativas de melhoria ao longo da
sua condução [Montoni et al., 2008] .
Um estudo coordenado pela SOFTEX em 2014 [Rocha, 2014] buscou compreender dificuldades de
capacitação de implementadores e avaliadores MPS.BR (tanto para o MPS-SW quanto para MPS-SV).
Para isso, foram aplicados dois questionários: um deles direcionado aos coordenadores de Instituições
Implementadoras (IIs) e Instituições Avaliadoras (IAs), e o outro para avaliadores e implementadores.
Como resultado, foram encontrados dois principais problemas: (i) carências na formação teórica e
experiência prática de implementadores e avaliadores MPS-SW e MPS-SV e (ii) dificuldades de
comparecer a cursos e workshops longe da cidade de origem por custo. Os detalhes destes resultados
serão detalhados a seguir.
Após ser feita uma análise quantitativa dos resultados destes questionários, observou-se que os
temas onde as equipes de Software ou parte delas tem carências foram: Desenvolvimento para
Reutilização e Controle Estatístico de Processos. Para as equipe de Serviços, o tema com maior
carência foi Controle Estatístico de Processos. Essa carência diz respeito à formação teórica e
experiência prática com o tema.
23
Em relação à dificuldade em implementar e avaliar os níveis do MPS.BR, o resultado obtido
foi que para as IIs e IAs que estão no contexto MPS-SW, a maioria das equipes apontou que poucos
membros de suas equipes possuem formação teórica suficiente e experiência prática para implantar os
níveis A e B. No contexto MPS-SV, cerca de 50% (metade) das equipes que responderam o
questionário apontaram pouca formação teórica nos níveis A e B, e pouca experiência prática nos
mesmo níveis A, B, C e D. Em ambos contextos (Software e Serviços) foi possível verificar que as
equipes não possuem dificuldade alguma nos níveis mais baixos G e F.
Além dos resultados mencionados anteriormente, foi feita também uma análise qualitativa com
base nas respostas dos avaliadores e implementadores onde a pergunta foi “Como o MPS pode ajudar
na capacitação?”. A maioria dos respondentes apontou que eventos científicos como WAMPS e
SBQS auxiliam na capacitação de implementadores e avaliadores do modelo MPS. Uma sugestão que
foi amplamente citada é que poderia haver mais cursos na modalidade à distância, isso se justifica
principalmente devido à problemas de logística (deslocamento). Outro ponto citado é de que os cursos
e artigos científicos deveriam ter aspectos mais práticos, e não somente teóricos. Para o caso dos
artigos, em especial para relatos de experiência, percebe-se uma necessidade de que sejam
apresentados cases de implementação que não reflitam apenas resultados positivos, mas também
demonstrem erros de implementação, problemas encontrados e sugestões de soluções para contornar
e/ou resolver os problemas durante a implantação e/ou avaliação . Os assuntos em que se percebeu
maior relevância e necessidade de mais cursos e discussões foram: Controle Estatístico de Processos,
Gerência de Reutilização, Gerência de Configuração e Gerência de Portfólio.
Outra questão subjetiva feita foi “Como o MPS pode ajudar na capacitação de profissionais
das empresas?”. A partir das respostas, concluiu-se que o principal problema apontado é que há uma
deficiência cultural nas organizações que impede a institucionalização dos processos. Nesse contexto,
alguns respondentes relataram que a maioria das empresas não percebe o retorno sobre investimento
(ROI) que os modelos proporcionam, limitando-se apenas na obtenção da certificação. Outro ponto
citado refere-se ao pouco conhecimento em Engenharia de Software por parte dos membros das
empresas. Então, uma sugestão dada é que o MPS poderia estabelecer requisitos mínimos - além do
curso C1 de Introdução - para o profissional da organização que for conduzir a implementação.
Viana (2015) propôs o framework KL-SPI (Knowledge and Learning to Facilitate Software
Process Improvement) que contém três componentes: (1) processo de diagnóstico do estado da prática
de AO e GC nas organizações; (2) catálogo de práticas de AO e GC; e, (3) ferramentas de apoio à AO
e GC que foram desenvolvidas durante a execução deste estudo e identificadas na literatura. Este
modelo é genérico, ou seja, pode ser aplicado em qualquer organização desenvolvedora de software,
porém, pode também ser aplicado no contexto desta pesquisa.
4. Metodologia de Pesquisa e Estado Atual do Trabalho
Até o momento, a metodologia de pesquisa deste trabalho está composta pelos seguintes métodos:
entrevistas e estudos de caso. Os seguintes passos serão adotados: (1) revisão da literatura, (2)
entrevistas com implementadores e avaliadores, (3) aplicação do método KL-SPI no contexto das IIs
ou IAs, (4) solução proposta e (5) projeto de avaliação da solução por meio de um estudo de caso.
O passo 1 foi realizado e será continuamente feito ao longo da pesquisa. O passo 2 foi iniciado
através de uma entrevista-piloto com dois consultores com experiência em implementação e avaliação
do MPS-SW (vide Seção 4.1). Pretende-se aplicar o questionário para um número maior de
consultores a fim de se obter ganho de conhecimento neste contexto de capacitação. O passo seguinte
24
será aplicar o método KL-SPI [VIANA, 2015] em uma II ou IA para verificar os resultados iniciais.
Tendo estes passos concluídos, pretende-se construir a solução proposta deste estudo, que é criar
mecanismos de AO para consultores MPS.BR. Ao final, pretende-se realizar um Estudo de Caso em
alguma organização para confirmar se a solução proposta é válida e gera benefícios tanto para as IIs e
IAs quanto para a própria organização. Este Estudo de Caso confirmatório seria o Projeto de
Avaliação da Solução desta pesquisa.
Um exemplo prático da solução proposta seria investigar que tipo de conhecimento um
implementador deve possuir para apoiar ações a serem tomadas em situações críticas de implantação
de MPS com base na aplicação do KL-SPI. Entende-se por situação crítica, como toda situação
desfavorável à implantação da iniciativa de MPS. Diirr e Santos (2013) identificaram fatores críticos
para melhoria de processos de serviços de TI, alguns exemplos são: apoio gerencial, experiência e
competência dos envolvidos no projeto, e gerência adequada da condução do projeto. Dessa forma, na
etapa de entrevistas, pode-se verificar com implementadores como lidar com estes fatores, de acordo
com a experiência e entendimento de cada um. Ao coletar essas informações e efetuar uma série de
análises, será possível criar um corpo de conhecimento, por exemplo, com lições aprendidas (caso
indicado pela aplicação do KL-SPI). Estas lições aprendidas poderão servir de insumo para as IIs, IAs
e para os próprios consultores e implementadores de MPS. No entanto, a forma como o conhecimento
será tratado ou que abordagens de aprendizagem organizacional serão adotadas ainda depende da
aplicação do KL-SPI nesse contexto, o que será feito em um dos próximos passos da condução da
dissertação.
4.1. Entrevistas
Com o objetivo de compreender melhor as dificuldades de capacitação, um dos pontos iniciais deste
trabalho foi a criação de um questionário com perguntas mais específicas e direcionadas para o
contexto desta pesquisa objetivando entender, por exemplo, que tipo de conhecimento é necessário
durante a implementação de uma iniciativa MPS, e como o conhecimento é disseminado nas IIs e
IAs. Foram entrevistados dois consultores com experiência em implementação e avaliação do MPSSW. Alguns exemplos de perguntas foram:
● “Além do conhecimento em Engenharia de Software, que outros tipos de conhecimento um
implementador MPS.BR deve ter (na execução do seu trabalho diário)? E um avaliador?”
● “Você tem costume de ler o Guia de Implementação do MPS? Na sua opinião, o conhecimento
que está presente nele é suficiente para implementar MPS na prática? Que tipo de
conhecimento seria interessante estar contido nele e não está presente hoje?”
Em relação ao conhecimento que um implementador deve possuir, a resposta obtida foi que
um implementador deve ter conhecimento tácito durante a condução da melhoria de processos de
software. Este conhecimento caracteriza-se pela habilidade do consultor em apontar falhas, dar
sugestões e críticas para os membros da organização evitando ao máximo algum tipo de resistência ou
contrariedade por parte destes. Segundo a entrevistada, várias empresas não reconheciam que o
consultor atuava na iniciativa de MPS como um facilitador. Para a segunda pergunta, os respondentes
afirmaram, por exemplo, que o Guia de Implementação não contempla orientações e exemplos
práticos de implementação de abordagens ágeis de desenvolvimento de software.
A partir das carências de capacitação de implementadores e avaliadores do MPS.BR identificadas
através de questionários, entrevistas e relatórios de IIs e IA, pretende-se verificar quais práticas e
25
técnicas de AO e GC levantadas pelo framework KL-SPI são aplicáveis no contexto de IIs e IAs.
Posteriormente, busca-se elaborar uma abordagem, framework, ou processo que possa apoiar a AO de
consultores. Por fim, propõe-se avaliar esta solução proposta por meio de um Estudo de Caso, para
assim, verificar se a solução é válida.
A principal contribuição esperada neste trabalho é facilitar a AO de implementadores e
avaliadores na condução de iniciativas de melhoria de processos de software. Como consequência, as
organizações desenvolvedoras de software também irão se beneficiar do produto deste estudo.
Referências
Aurum, A., Jeffery, R., Wohlin, C., Handzic, M. (2003) Managing Software Engineering Knowledge, Springer, Germany.
Bandeira de Mello, R., Cunha, C., 2003, “Operacionalizando o método da Grounded Theory nas Pesquisas em Estratégia: técnicas e
procedimentos de análise com apoio do software ATLAS/TI”. Encontro de Estudos em Estratégia. Curitiba, Brasil.
Barreto, A., Montoni M., Santos G., Rocha A. R., (2006) . “Gerência de Conhecimento como Apoio para a Implantação de Processos de
Software”. Workshop de Implementadores MPS.BR, Rio de Janeiro. ProQuality - Qualidade na Produção de Software. Lavras:
ProQuality, 2006. v. 2. p. 45-50.
Basili V., Costa P., Lindvall M., Mendonca M., Seaman C., Tesoriero R., Zelkowitz M.,(2001). "An Experience Management System
for a Software Engineering Research Organization," sew, pp.29, 26th Annual NASA Goddard Software Engineering Workshop.
Diirr, T.; Santos, G. “Fatores Críticos de Sucesso para Melhoria de Processos de Serviços de TI: Um Mapeamento Sistemático” .
Simpósio Brasileiro de Qualidade de Software, 2013, Salvador, BA.
Menolli, A., Reinehr, S., Malucelli, A. “Organizational Learning Applied to Software Engineering: a Systematic Review”, International
Journal of Software Engineering and Knowledge Engineering, Vol. 23, No. 8 (2013) 1153-1175.
MONTONI, M. ; CERDEIRAL, C. ; ZANETTI, D. . Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de
Software. In: VII Simpósio Brasileiro de Qualidade de Software (SBQS), 2008, Florianópolis. VII Simpósio Brasileiro de Qualidade
de Software (SBQS), 2008. p. 263-277.
Montoni, M.; Santos, G.; Figueiredo, S.; Filho, R. C. S.; Barcelos, R.; Barreto, Ahilton.; Barreto, Andrea; Cerdeiral, C.; Lupo, P.;
Rocha, A. R. “Uma Abordagem de Garantia de Qualidade de Processos e Produtos de Software com Apoio de Gerência de
Conhecimento na Estação TABA”. Simpósio Brasileiro de Qualidade de Software, 2006, Vila Velha - ES.
Montoni, M. A. (2010) “Uma Investigação sobre os Fatores Críticos de Sucesso em Iniciativas de Melhoria de Software de Processos”.
Tese (Doutorado em Engenharia de Sistemas e Computação) – Universidade Federal do Rio de Janeiro.
Nardi, J.; Falbo, R. A. “Apoio de Gerência de Conhecimento na Engenharia de Requisitos”. Simpósio Brasileiro de Qualidade de
Software - SBQS 2007.
Oliveira, J. F.; Andrade, G. F.; Tavares, L. C.; Reis, C. A. L. (2009).“Planejamento e Execução de Gerência do Conhecimento em um
Ambiente de Desenvolvimento de Software”. Simpósio Brasileiro de Qualidade de Software - SBQS 2009. Ouro Preto, MG.
Rocha, A. R. Painel „Melhorias no Programa MPS.BR e no Modelo MPS‟ - GT/T4: Melhorias na Capacitação de Pessoas). Simpósio
Brasileiro de Qualidade de Software - SBQS 2014. Blumenau, SC.
Senge, P., Kleiner, A., Roberts, C., Ross, R. and B. J. Smith, The Fifth Discipline Field Book (Doubleday, New York, 1994).
SOFTEX (2012). “MR-MPS-SW – Guia Geral MPS de Software”. Disponível em: www.softex.br/mpsbr
Takeuchi H., Nonaka I., “Gestão do Conhecimento”; tradução Ana Thorell. Porto Alegre : Bookman, 2008.
Viana, D. “FACILITANDO A APRENDIZAGEM ORGANIZACIONAL EM MELHORIA DE PROCESSO DE SOFTWARE”. Tese
de Doutorado - UNIVERSIDADE FEDERAL DO AMAZONAS – UFAM. Manaus, Amazonas, Março de 2015.
Watson, I., 2003, Applying Knowledge Management Techniques for Building Corporate Memories, Morgan Kaufmann Publishers,
Estados Unidos.
26
Um Método para Seleção de Indicadores de Serviços de TI
1
Bianca Trinkenreich, 1Gleison Santos, 2Monalessa Perini Barcellos
1
Programa de Pós-Graduação em Informática, Departamento de Informática Aplicada,
Universidade Federal do Estado do Rio de Janeiro (UNIRIO), , Rio de Janeiro, Brasil
2
Departamento de Ciência da Computação, Universidade Federal do Espírito Santo
(UFES), Vitória, ES, Brasil
{bianca.trinkenreich, gleison.santos}@uniriotec.br,
[email protected]
Abstract. Effective measurement processes help organizations to understand their
capabilities to develop workable plans to execute and deliver agreed services.
Many organizations consider measures and indicators selection a difficult task.
This work proposes a method to select IT services indicators, supporting IT services measurement initiatives, in service maturity models context inclusive. It will
be based on GQM+Strategies approach, COBIT framework, RSMO ontology,
processes and relationships evaluation and goals and indicators reuse.
Resumo. Um processo de medição eficaz ajuda a compreensão da habilidade de
uma organização desenvolver planos viáveis para executar e entregar serviços
acordados. Muitas organizações consideram a seleção de medidas e indicadores
uma tarefa difícil. Esta dissertação apresenta um método para selecionar indicadores de serviços de TI nas organizações, apoiando iniciativas de medição de
serviços de TI, inclusive em modelos de maturidade de serviços. O método será
baseado no GQM+Strategies, no framework COBIT, na ontologia ORMS, em
avaliação de processos e relacionamentos e reuso de objetivos e indicadores.
Prestadores de serviços de TI estão continuamente à procura de métodos mais eficientes
para melhorar o desempenho dos processos de suporte ao cliente e reduzir os custos de
suporte e manutenção. Ser capaz de fazer previsões em relação aos serviços que entrega é
um fator de sucesso para uma organização. Um processo de medição eficaz ajuda a organização a compreender suas capacidades para que possa desenvolver planos viáveis para
executar e entregar os serviços acordados com seus clientes. Medições também ajudam a
detectar tendências e antecipar problemas, proporcionando, assim, um melhor controle de
custos, redução de riscos, melhoria da qualidade e garantia de alcance dos objetivos de
negócio [FLORAC e CARLETON, 1997]. Uma dificuldade que as organizações prestadoras de serviços de TI apresentam é fazer a seleção de indicadores alinhados aos objetivos
de serviços de TI. A falta de uma abordagem estruturada para seleção de indicadores de
serviços de TI e exemplos práticos são dois fatores que causam tal dificuldade, além de as
ferramentas em uso pelas equipes geralmente não incluírem a medição [JANTTI et al.,
2010] [CATER-STEEL e LEPMETS, 2014].
Considerando o provimento de serviços como uma cadeia de processos relacionados, mais do que selecionar os processos a serem medidos e entregar apenas indicadores
isolados de cada processo, também é preciso conhecer e controlar esses relacionamentos.
Para isso é necessário conhecer os processos e seus relacionamentos com outros processos,
27
além de avaliar o impacto de um serviço em outro [TRINKENREICH e SANTOS, 2015].
Em [TRINKENREICH e SANTOS, 2014], o processo de medição de uma organização foi avaliado sob a luz dos resultados esperados do processo Medição (MED) do MRMPS-SV [SOFTEX, 2012a] e a qualidade de informação de dois indicadores em uso e o
alinhamento deles com os objetivos da organização. Observou-se a dificuldade que a organização apresenta em selecionar os indicadores de desempenho mais adequados para atender o negócio e dificuldade do processo atual em atender aos indicadores existentes. Foi
observado um resultado positivo de apoio mútuo entre integrantes de uma equipe e entre
diferentes equipes quando são usados indicadores cruzados de diferentes serviços. Percebeu-se que um método de seleção de indicadores e um catálogo de indicadores serão úteis
na seleção anual que a organização realiza de indicadores de desempenho de serviços.
Em [TRINKENREICH et al., 2015a] foi apresentado um mapeamento sistemático
para encontrar medidas que podem ser usadas em iniciativas de modelos de maturidade de
serviços de TI. Este trabalho resultou em uma lista de medidas, que por meio do entendimento do significado de cada uma, foram classificadas por processo do modelo de maturidade de serviços e foram encontradas medidas relacionadas a mais de um processo. Em
[TRINKENREICH e SANTOS, 2015], estes resultados foram usados para: (i) validar o uso
das medidas encontradas em uma empresa real, (ii) incluir novas medidas que não foram
encontradas na literatura, (iii) avaliar o relacionamento entre as medidas e (iv) apresentar o
uso de testes estatísticos de correlação para apoiar análise de causa-efeito entre serviços
que possuem relacionamento entre si. Observou-se a dificuldade de selecionar indicadores
adequados que tragam visibilidade sobre o alcance dos objetivos da organização.
Contar com um catálogo de medidas a partir do qual seja possível escolher aquelas
que sejam adequadas para a organização ou inspirar a criação de novas medidas pode reduzir o esforço e acelerar a seleção de indicadores [KANEKO et al., 2011] [JANTTI et al.,
2010] [KILPI, 2001]. Entretanto, isso não é suficiente. É preciso definir medidas que possam ser usadas como indicadores, ou seja, medidas relacionadas a objetivos e que apoiam o
monitoramento do seu alcance [BARCELLOS, 2009]. Desta forma, é necessário alinhar
medidas com objetivos para definir os indicadores de serviços de TI [PARMENTER,
2013]. Para fazer este alinhamento é preciso compreender as necessidades de informações
das partes interessadas, a forma como os processos de serviços de TI foram projetados e
são executados na organização e, então, detectar quais são os processos críticos e as estratégias a serem seguidas para alcançar as metas estabelecidas.
O objetivo deste trabalho é criar um método para apoiar a seleção de indicadores de
serviços de TI através da derivação dos objetivos da organização em objetivos de serviços
de TI, estratégias e indicadores. O método será baseado em componentes do
GQM+Strategies [BASILI et al., 2007], considerará os conceitos da Ontologia de Referência para Medição de Software (ORMS) [BARCELLOS, 2009] e contará com atividades de
modelagem de processos críticos. Além disso, será fornecido um catálogo de indicadores
criado a partir do COBIT Goal Cascade [ISACA, 2012] e da lista de medidas para serviços
de TI [TRINKENREICH et al., 2015a]. O catálogo de indicadores será considerado como
entrada para algumas atividades do método. O método apoiará iniciativas de medição de
serviços de TI, relacionadas ou não e também o Processo de Medição dos modelos de maturidade de serviços de TI.
Este artigo contém uma revisão da literatura na seção 2, trabalhos relacionados de
outros autores na seção 3, a metodologia a ser seguida, o planejamento e o estado atual do
28
trabalho na seção 4, e os resultados esperados na seção 5.
2. Medição de Serviços de TI
Em geral, as definições de serviço refletem, em certo nível, o ponto de vista das disciplinas
acadêmicas ou dos sectores econômicos onde foi definido. Serviço é "uma representação
lógica de uma atividade repetitiva que tem um resultado especificado. Ele é autossuficiente
e é uma "caixa preta" aos seus consumidores" [ISACA, 2012] [CASES et al., 2010]. Serviços de TI são definidos para apoiar a realização dos negócios [CASES et al., 2010] e são
meios importantes para estabelecer o alinhamento entre a TI e o negócio [ABDI et al.,
2010]. Há várias abordagens dedicadas aos serviços de TI, tais como COBIT [ISACA,
2012], CMMI-SVC [FORRESTER et al., 2010], MR-MPS-SV [SOFTEX, 2012] e ITIL
[TSO, 2011], que endereçam os processos relacionados a serviços de TI (por exemplo,
Gerência de Incidentes, Problemas, Mudanças etc.) e fornecem orientações a suas implementações.
A fim de avaliar e melhorar a qualidade dos serviços, a qualidade dos processos
executados para oferecer os serviços precisa ser avaliada [FORRESTER et al., 2010]. A
medição desempenha papel fundamental em iniciativas de melhoria da qualidade de processos. Em geral, medições eficazes de serviços são planejadas com base em alguns indicadores vitais e significativos (ou seja, medidas usadas para verificar quantitativamente o
alcance das metas [ECKERSON, 2009]) para apoiar os resultados desejados. Assim, é importante definir os indicadores apropriados para apoiar os objetivos de qualidade de serviços e satisfação do cliente [ISACA, 2012]. Além disso, é necessário concentrar a atenção
em indicadores relacionados a processos críticos e alinhados aos objetivos organizacionais,
mas esta não é uma tarefa fácil.
Existem algumas propostas que lidam com esta questão. COBIT Gols Cascade
[ISACA, 2012] fornece um catálogo com 17 objetivos organizacionais e relacionados a TI,
e mais de 100 indicadores que podem ser reutilizados. Balanced Scorecard (BSC) [KAPLAN e NORTON,1996] é uma abordagem na qual a medição é aplicada para verificar se
as atividades da organização conseguem atingir suas metas de visão e estratégia. A abordagem GQM+Strategies [BASILI et al., 2007] é uma extensão do GQM [SOLINGEN e
BERGHOUT, 1999] e tem estratégias e medidas como entrada para um modelo desde o
nível mais alto de negócio até o mais baixo operacional, e vice-versa. GQM+Strategies
ajuda a identificar metas, estratégias e indicadores alinhados com objetivos de negócio e
fornece um mecanismo para monitorar o sucesso e o fracasso de metas e estratégias através
de medição. Os principais componentes do GQM+Strategies são [BASILI et al., 2007]:
Objetivos da Organização (o que a organização deseja alcançar), Estratégias (como atingir
as metas), Fatores de Contexto (ambientes externos e internos), Premissas (estimativas
desconhecidas), gráficos GQM [SOLINGEN e BERGHOUT, 1999] (como medir se um
objetivo foi alcançado e uma estratégia foi bem sucedida ou não) e Modelos de Interpretação (como interpretar os indicadores de medição para verificar o atendimento aos objetivos
e atender às necessidades de informação) [SOLINGEN e BERGHOUT, 1999].
Na literatura existem algumas propostas que ajudam as organizações a definir indicadores
de serviços de TI. O COBIT Gols Cascade [ISACA, 2012] recomenda que a empresa construa seus próprios objetivos e medidas em cascata, compare-os com COBIT e refine-os.
Embora o COBIT forneça um conjunto de objetivos e medidas a serem reutilizados, não
29
existe um procedimento a ser seguido para fazer a seleção. O BSC [KAPLAN e NORTON,1996] não fornece explicitamente uma forma de como definir metas, estratégias e
indicadores relacionados a diferentes níveis organizacionais, sendo mais aplicável em níveis mais altos.
Um framework de medidas para serviços de TI foi apresentado em [CATERSTEEL e LEPMETS, 2014], mas apenas um catálogo é fornecido, sem um método para
selecionar e alinhar medidas aos objetivos de negócio. Os autores afirmam que o alinhamento entre os objetivos de negócios e de serviços de TI na indústria precisa ser estudado e
poderia fornecer suporte adicional para seu framework. Em [JANTTI et al., 2010], os autores apresentam um sistema de apoio à medição de serviços de TI. Segundo os autores, além
de uma ferramenta de medição bem concebida e fácil de usar, existe a necessidade de um
processo sistemático de medição e que as medidas precisam ser baseadas em objetivos de
negócios. Para responder a essa necessidade, os autores sugerem uma estrutura resumida
de processo baseada na ITIL [TSO, 2011], mas enfatizam que o estudo se concentrou na
implementação do sistema de medição e o a estrutura não foi validada em casos reais.
Existem algumas propostas que, embora não dedicadas a serviços de TI, podem ser
utilizadas neste contexto. O GQM+Strategies [BASILI et al., 2007] não detalha como
identificar processos críticos a serem considerados nas estratégias ou como definir estratégias e medidas adequadas. Em [BASILI et al., 2013] e [KANEKO et al., 2011] as lições
aprendidas, resultados e experiências da aplicação da abordagem GQM+Strategies são
apresentadas, mas nenhum dos dois sugere um método a ser usado em associação ao
GQM+Strategies para outros casos.
O método a ser criado reutiliza o conhecimento fornecido por outras propostas
(principalmente COBIT e GQM+Strategies) e aborda algumas das lacunas citadas. Ele
define um conjunto de atividades, orienta sobre o que deve ser feito a fim de selecionar
indicadores relevantes para o monitoramento dos objetivos, sugere modelos e reutiliza metas e medidas registradas na literatura.
A metodologia a ser empregada no desenvolvimento da pesquisa está levando em consideração estudos de caso na indústria e envolve métodos de análise qualitativa e quantitativa,
tendo sido dividido em três fases: concepção, construção, avaliação e melhorias. Na fase de
concepção são coletadas as informações através de investigações da literatura, na fase de
construção o método com modelo conceitual e os processos serão definidos. Na fase de
avaliação e melhorias, os estudos de caso serão realizados, o método e os processos serão
refinados de acordo com os resultados obtidos na indústria. As atividades correspondentes
a esta metodologia são apresentadas a seguir, de acordo com suas fases.
#
Atividade
1
2
Publicação
Objetivo
Fase de Concepção
Estudo de Caso na indústria para avaliação do processo WAMPS (Campi- Entender como funciona a medide medição de serviços em uma empresa e avaliação de nas) – Premio des- ção de serviços de TI em uma
dois indicadores utilizados
taque [TRINKEN- organização real
REICH e SANTOS,
2014]
Mapeamento sistemático sobre medidas sugeridas na ICEIS (Barcelona) Entender quais são os indicadores
literatura para melhoria de processos de serviços de TI e a [TRINKENREICH de serviços de TI propostos na
quais processos do MR-MPS-SV e do CMMI-SVC elas et al, 2015a]
literatura e agrupá-los por procesestão relacionadas
so para facilitar reúso
30
#
3
4
5
6
7
Atividade
Estudo de Caso na indústria para entendimento dos relacionamentos entre os processos em medidas derivadas em
mais de um processo, encontradas pelo mapeamento
sistemático e aumento da lista de medidas obtidas no
passo anterior
Extensão do item 1, incluindo a avaliação de mais um
indicador sobre o processo MR-MPS-SV de Orçamento e
Contabilização de Serviços
Publicação
Objetivo
ICEIS (Barcelona) Validar o resultado do mapeamen[TRINKENREICH to e entender relacionamentos
e SANTOS, 2015] entre os processos de serviços
Submetido à revista
iSys (pré-aprovado
devido ao destaque
do WAMPS)
Estudo de Caso na indústria usando mineração de proces- SEKE
(Pittsburg)
sos sobre log de incidentes para utilização de descobertas [TRINKENREICH
sobre o processo para apoiar a seleção de medidas de et al, 2015b]
serviços de TI
Estudo de Caso na indústria para avaliação do processo SBQS (Manaus)
de incidentes, mapeamento dos relacionamentos com
outros processos e uso destes relacionamentos para suportar a seleção de medidas multiprocessos
Fase de Construção
Investigação na literatura técnica sobre GQM+Strategies, COBIT, RSMO, trabalhos científicos e relatos de experiência sobre métodos para seleção de medidas de serviços,
ou de software que possam ser adaptados para serviços
Desenvolvimento do método para seleção de indicadores Submetido e aguarde serviços de TI
dando resposta
Aumentar o entendimento sobre
como funciona a medição de
serviços de TI em uma organização real
Entender funcionamento do processo de incidentes e como apoiar
a seleção de indicadores
Aumentar o entendimento sobre o
processo de incidentes e como o
conhecimento do relacionamento
entre processos pode apoiar a
seleção de indicadores
Obter conhecimento sobre
bases para criação do método
as
Criação do método proposto para
seleção de indicadores de serviços
de TI
Criação do catálogo de indicadores de desempenho de Em elaboração. Sem Criação do catálogo de indicado9 serviços de TI baseado na ontologia de medição [Barcel- publicação associa- res para reúso
los, 2009]
da ainda
Fase de Avaliação
Estudo de viabilidade com área de Segurança da Informa- Em elaboração no Avaliação do método proposto
ção para avaliar a aceitação de acordo com o Modelo de momento.
10
Aceitação de Tecnologia – TAM (Laitenberger e Dreyer,
1998)
Estudos de caso da aplicação do método em uma empresa Avaliação do método proposto
pública para avaliar a aceitação de acordo com o Modelo
11
de Aceitação de Tecnologia – TAM (Laitenberger e
Dreyer, 1998)
Melhorias no método e nos processos propostos de acor- Melhorias ao método proposto
12
do com as lições aprendidas nos estudos
8
Os resultados e benefícios esperados com esta dissertação de mestrado são: (i) um método
para selecionar indicadores de desempenho e apoiar o processo de medição dos modelos de
maturidade de serviços de TI, (ii) um catálogo de indicadores de desempenho de serviços
de TI, (iii) estudos de caso a fim de avaliar a aplicabilidade do método proposto, fornecendo exemplos reais de utilização e evidências de tempo e eficácia, relevantes para adoção
industrial. Espera-se que os resultados apoiem as organizações na seleção de indicadores
de desempenho em iniciativas de melhorias de processos de serviços de TI.
Agradecimentos
Os autores agradecem à FAPERJ (projeto E-26/110.438/2014) e ao CNPq (Processo
461777/2014-2) pelo auxílio financeiro.
Referências
Abdi, M.; Dominic, P. D. (2010). “Strategic IT Alignment with Business Strategy: Service Oriented Architecture Approach”. International Symposium on Information Technology. Kuala Lam-
31
pur – Malaysia
Barcellos, M. P. (2009). “Uma Estratégia para Medição de Softwaree Avaliação de Bases de Medidas para Controle Estatístico de Processos de Software em Organizações de Alta Maturidade”.
Tese (Doutorado em engenharia de sistemas e computação). UFRJ, RJ.
Basili, V., Heidrich, J., Lindvall, M., Münch, J., Regardie, M., Trendowicz, A. (2007)
“GQM+Strategies –aligning business strategies with software measurement” pp 488–490.
ESEM Int’l Symposium Empirical Software Engineering and Measurement. Spain
Basili, V., Lampasona, C.., Ramírez, A. (2013) “Aligning Corporate and IT Goals and Strategies in
the Oil and Gas Industry” - PROFES Int’l Conference
Cases, M.; Bodner, D. A.; Mutnury, B. (2010) “Architecture of Service Organizations” In: Salvendy, G.; Karwowski, W. (Eds.). Introduction to Service Engineering. Hoboken: John Wiley &
Sons, Inc., p. 109–134.
Cater-Steel, A., Lepmets, M. (2014) “Measuring IT Service Quality: Evaluation of IT Service
Quality Measurement Framework in Industry” Journal Service Science Research pp 125-147
Eckerson, W. (2009) "Performance management strategies." Business Intelligence Journal 14.1 pp.
24-27.
Forrester, E., Buteau, B., Shrum, S.(2010) -CMMI For Services, Guidelines for Superior Service.
CMMI-SVC Version 1.3 - 2nd Edition. SEI. Addison-Wesley Professional.
Florac e Carleton (1997) “Practical Software Measurement: Measuring for Process Management
and Improvement” Software Engineering Institute
ISACA (2012) “COBIT 5 – Control Objectives Management Guidelines Maturity Models: A Business Framework for the Governance and Management of Enterprise IT”. Information Systems
Audit and Control. Association, USA
Jäntti, M., Lahtela, A., Kaukola, J. (2010) “Establishing a Measurement System for IT Service
Management Processes: A Case Study”. Int’l Journal on Advances in Systems and Measurements, vol 3 no 3 & 4
Laitenberger, O., Dreyer, H. M. (1998) “Evaluating the Usefulness and the Ease of Use of a Webbased Inspection Data Collection Tool”. IEEE Computer Society.
Kaneko, T., Katahira, M., Miyamoto, Y., Kowalczyk, M. “Application of GQM+Strategies in the
Japanese Space Industry”. Int’l Workshop on Software Measurement (2011)
Kaplan, R., Norton, D.P. (1996) “The Balanced Scorecard Translating Strategy Into Action”.
Havard Business School Press, Boston.
Kilpi, T. (2001) – “Implementing a software metrics program at Nokia”, IEEE Software, Volume18, issue 6, pp. 72–77. ISSN: 0740-7459
Parmenter, D. (2013) “Key Performance Indicators – Developing, Implementing and Using Winning KPIs” 3rd edition Wiley
Softex (2012) Associação para Promoção da Excelência do Software Brasileiro “MPS.BR – Guia
Geral MPS de Serviços” Disponível em www.softex.br
Solingen, R., Berghout, E. (1999) ”The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Development”. McGraw-Hill.
The Stationary Office – TSO (2011) ITIL Service Operation. Disponível em www.bestmanagement-practice.com.
Trinkenreich, B., Santos, G. (2014) “Avaliação do Processo de Medição em Gerência de Incidentes
e Gerência de Continuidade e Disponibilidade à Luz do MR-MPS-SV”. Workshop Anual do
MPS.BR - WAMPS, Campinas – SP, pp. 186-194.
Trinkenreich, B., Santos, G., Barcellos, M. P. (2015a) “Metrics to Support IT Service Maturity
Models – A Systematic Mapping Study”, ICEIS 17th Int’l Conference on Enterprise Information Systems, Espanha
Trinkenreich, B., Santos, G. (2015) “Metrics to Support IT Service Maturity Models – A Case
Study”, ICEIS 17th Int’l Conference on Enterprise Information Systems, Espanha
Trinkenreich, B., Santos, G., Confort, V., Santoro, F. (2015b) “Toward using Business Process
Intelligence to Support Incident Management Metrics Selection and Service Improvement”,
SEKE Int’l Conference Software Engineering Knowledge Engineering, Pittsburg.
32
Uma Análise dos Benefícios Tangíveis e Intangíveis de
Melhoria de Processo de Software
Diego Cruz e Gleison Santos
Programa de Pós-Graduação em Informática - Universidade Federal do Estado do Rio de
Janeiro (UNIRIO) - Av. Pasteur, 458, Urca, CEP 22290-240 - Rio de Janeiro, RJ
{diego.dacruz, gleison.santos}@uniriotec.br
Abstract. Benefits obtained by software process improvement are one of the various
organizational motivation factors to adopt and maintain practices proposed by maturity
models like MPS.BR and CMMI. Despite many organizational experience reports present
benefits in SPI implementation, the lack of information about how to measure SPI
benefits can affect professionals’ motivation and organizations’ decision to invest in
improvement programs. This paper presents a proposal to develop a catalog containing
SPI implementation benefits, metrics to analyze quantitative benefits and techniques to
quantitatively estimate intangible benefits. Consultancies and software organizations that
adopted or aim to adopt SPI may use this catalog as reference to support the SPI
implementation process.
Resumo. Os benefícios gerados por implementação de melhoria de processos de
software são um dos fatores motivacionais para que organizações de software adotem e
mantenham as práticas propostas em modelos de maturidade como MPS.BR e CMMI.
Ainda que no contexto de adoção de melhoria de processos de software existam diversos
relatos sobre benefícios obtidos por organizações, a escassez de informações sobre como
mensurar benefícios de melhoria de processos pode impactar na motivação de
profissionais e na decisão de organizações em investirem em programas de melhoria.
Este trabalho apresenta a proposta de desenvolvimento de um catálogo de benefícios da
implementação de melhoria de processos de software e possíveis métricas para analisar
benefícios quantitativos e técnicas para estimar quantitativamente benefícios intangíveis.
Tal catálogo pode ser usado como referência para consultorias e organizações de
software que implementaram ou pretendem implementar melhoria de processos.
1. Introdução
Melhoria de processos de software (MPS) tem sido promovida por praticantes e
pesquisadores da Engenharia de Software há anos com o objetivo de ajudar organizações
a desenvolver softwares de alta qualidade de maneira mais eficiente [Staples et al. 2007].
Dentre os modelos de melhoria de processos de software mais utilizados no Brasil,
destacam-se o MR-MPS-SW, do Programa Brasileiro de Melhoria de Processos de
Software (MPS.BR) [SOFTEX 2012], e o CMMI-Dev (Capability Maturity Model
Integration for Development) [CMMI Product Team 2010].
O objetivo do Programa MPS.BR é desenvolver e disseminar um modelo de
melhoria de processos brasileiro (MR-MPS-SW) visando estabelecer um caminho
economicamente viável para que organizações, incluindo as micro, pequenas e médias
empresas (mPME), alcancem os benefícios da melhoria de processos e da utilização de
boas práticas da engenharia de software em um intervalo de tempo razoável [Kalinowski
33
et al., 2010]. Logo, para garantir o sucesso do modelo MPS, é essencial que organizações
possam efetivamente adotá-lo e obtenham seus benefícios [Santos et al. 2012].
Este artigo propõe uma análise dos benefícios relatados por empresas que
adotaram melhoria de processos de software e, a partir dessa análise, espera-se obter um
catálogo contendo benefícios tangíveis e intangíveis de melhoria de processos, medidas
para analisar os benefícios tangíveis (quantitativos) e técnicas para quantificar benefícios
intangíveis (qualitativos). A obtenção deste catálogo tem o intuito de facilitar a
identificação dos benefícios e pode auxiliar empresas e consultorias no processo de
motivação dos profissionais envolvidos no processo de melhoria e influenciar na decisão
da alta gerência em investir em melhoria de processos de software.
A próxima seção caracteriza o problema para o qual a pesquisa está direcionada, a
seção 3 apresenta a fundamentação teórica, a seção 4 apresenta um planejamento das
etapas da pesquisa e os resultados obtidos até o momento, enquanto na seção 5 é
apresentada a conclusão.
Ainda que o conjunto de fatores que influenciam a implementação de MPS nas empresas
tenha sido largamente estudado, a evidência dos benefícios obtidos com melhoria de
processos é um ponto crítico para as empresas e carece de um aprofundamento teórico.
A melhoria de processos gera benefícios tangíveis (por exemplo, aumento da
produtividade, redução de custos) e intangíveis (por exemplo, satisfação do cliente,
melhoria no ambiente de trabalho). Alguns destes benefícios foram exemplificados por
Ramos et al. (2013) que realizaram uma revisão sistemática para identificar benefícios de
MPS e também métodos e medidas para analisar o retorno do investimento (ROI) em
iniciativas de MPS. Além da revisão sistemática, os autores propuseram uma estratégia
para análise do retorno do investimento com base na expectativa da empresa. No entanto,
apesar de diversos autores relatarem os benefícios de iniciativas de melhoria de processos
[Ferreira et al. 2007][Santos et al. 2012][Ramos 2013], ainda há escassez de informações
na literatura que facilitem a evidência destes benefícios.
É uma necessidade no estado da prática e da arte da área de melhoria de processos
do setor de software do Brasil a condução de investigações visando construir teorias
substantivas que considerem as especificidades do mercado de software brasileiro
[Montonni 2010]. Assim, acredita-se que um conjunto de informações que auxilie
empresas e profissionais a reconhecerem os benefícios de melhoria de processos no
contexto de melhoria de processos de software possa promover a melhoria do software
nacional à medida que induz a institucionalização das boas práticas do programa na
indústria de desenvolvimento de software
O modelo conceitual da Figura 1 apresenta como os benefícios estão presentes em
uma implementação de MPS. Este modelo foi elaborado com base em resultados
verificados em pesquisas anteriores sobre fatores críticos de sucesso, benefícios, Retorno
do Investimento (ROI) e motivadores de melhoria de processos. Com esta revisão da
literatura foi possível constatar que uma fonte de informações precisas sobre benefícios
tangíveis e intangíveis de MPS e de técnicas de medição para permitir o
acompanhamento do ROI é importante para o ecossistema de desenvolvimento de
software. Tal importância está ligada ao fato de que a evidência dos benefícios influencia
na motivação de empresas de software em adotar boas práticas da Engenharia de
Software [Staples et al. 2007; 2008][Santos et al., 2012] e promove a motivação dos
34
funcionários em apoiar as iniciativas, aumentando a possibilidade de sucesso [Zahran
1996][Baddoo e Hall 2002][Niazi e Ali Babar 2006][Viana et al. 2011]. Além disso,
muitas organizações de software que implementam melhoria em seus processos têm
abandonado tais práticas por não haver evidências dos benefícios obtidos [Albuquerque
2014]. Entretanto, há indícios de que a implementação de MPS promove a qualidade do
software [Staples et al. 2007], por isso, é importante para o mercado consumidor que
estas implementações tenham sucesso, que novas organizações se interessem em adotar
MPS e que as organizações que já implementaram continuem melhorando seus processos.
Figura 1: Benefícios no contexto de implementação de MPS. (Fonte: o autor)
Os benefícios relatados por organizações que implementaram melhoria de processos
estão fortemente relacionados com os motivos que levaram a organização a investir em
MPS [Solingen 2004]. Em alguns casos, benefícios intangíveis podem representar o
maior retorno desejado por uma organização que investe em melhoria de processos
[Krasner 1994][Santos et al. 2012]. No entanto, como não há nenhum modelo de
referência para medir o custo-benefício de melhoria de processos, muitas organizações
seguem uma abordagem própria para identificar e medir seus benefícios [Zahran 1996].
Assim, esta seção apresenta 3 abordagens relacionadas à identificação e medição de
benefícios de melhoria de processos.
Zhran (1996) sugere um modelo e orientações para ajudar organizações a
identificar e mensurar os custos e benefícios de melhoria de processos de software. A
abordagem é composta de um “business case” para convencer os executivos do valor do
investimento em MPS e uma estratégia para medir os custos e benefícios continuamente
após a implementação da MPS. Sua estratégia de medição busca transformar benefícios
qualitativos em quantitativos através de uma metodologia orientada a risco denominada
PRAM (Project Risk Analysis and Management).
Em 2004, Solingen apresenta uma abordagem de obtenção do ROI estimado,
considerando os benefícios de MPS. Assim como Zhran (1996), sua abordagem também
busca transformar benefícios qualitativos em quantitativos, porém a estratégia proposta é
obter uma estimativa quantitativa dos stakeholders (ex.: Quantas horas de treinamento
seriam necessárias para obter o benefício “melhoria de requisitos”? Quanto isso custa?).
35
O Projeto iMPS [SOFTEX, 2013] foi criado em 2007 com o objetivo de analisar
periodicamente o desempenho de empresas avaliadas no modelo MPS-SW através de um
survey. No entanto, os autores quantificam alguns benefícios tangíveis relatados por
empresas, enquanto os benefícios intangíveis são apenas citados. O iMPS utiliza algumas
métricas para identificação de benefícios quantitativos (ex.: Medida: Custo médio do
projeto - Medido em função do percentual do faturamento bruto dos últimos 12 meses).
Este trabalho tem o objetivo de fornecer um catálogo que contenha benefícios da
implementação de melhoria de processos de software, possíveis métricas para quantificar
benefícios quantitativos e técnicas para identificar e quantificar benefícios qualitativos.
Trata-se de um estudo exploratório de natureza qualitativa realizado em 5 etapas
(Figura 2): (i) Mapeamento sistemático para identificação de benefícios de implementação de melhoria de processos de software, métricas para mensurar benefícios tangíveis
e técnicas para estimar benefícios intangíveis; (ii) Entrevistas para identificação de
benefícios sob a perspectiva de empresas avaliadas e para entender como os benefícios
são analisados na prática; (iii) Análise qualitativa utilizando procedimentos baseados em
Grounded Theory a fim de criar conceitos a partir do estabelecimento de relações entre
benefícios, métricas e técnicas; (iv) Elaboração de um catálogo com benefícios, métricas
e técnicas; e (iv) Avaliação do catálogo por um ou mais profissionais de Engenharia de
Software com experiência em implementação de MPS.
Figura 1: Metodologia de pesquisa (Fonte: o autor)
1- Mapeamento sistemático da Literatura: O objetivo do mapeamento é identificar
estudos primários (relatos de experiência e estudos de caso) que contenham benefícios,
técnicas e medidas relacionados a MPS. Além destes estudos, o mapeamento visa
identificar outros estudos que contenham métricas aplicáveis ao contexto de medição dos
benefícios tangíveis e técnicas para quantificar benefícios intangíveis.
Esta pesquisa será realizada com base em uma questão principal assim definida:
QP: Quais são os elementos utilizados para analisar benefícios gerados por
implementação de processos de software? E nas seguintes questões secundárias: QS1:
Quais benefícios, tangíveis e intangíveis, são esperados por organizações envolvidas em
iniciativas de melhoria de processos? QS2: Quais benefícios, tangíveis e intangíveis, são
36
relatados por organizações envolvidas em iniciativas de melhoria de processos? QS3:
Quais técnicas são utilizadas para mensurar benefícios intangíveis de melhoria de
processos? QS4: Quais métricas são utilizadas para mensurar benefícios tangíveis de
melhoria de processos?
Há outros aspectos relacionados aos benefícios que não foram incluídos
diretamente nas perguntas, como a perspectiva sob a qual os benefícios são apresentados
(exemplo: de avaliadores, patrocinadores) e em que contexto os benefícios são
identificados (exemplo: porte da empresa). Como estes aspectos são específicos, os
mesmos serão coletados e avaliados indiretamente a fim de enriquecer a análise dos
estudos identificados no primeiro mapeamento.
2- Entrevistas com empresas avaliadas: O objetivo principal desta etapa é ampliação das
evidências coletadas nos estudos primários a partir de entrevistas com profissionais que
participaram da implantação de melhorias de processos. O segundo objetivo desta etapa é
obter refinamento das concepções geradas na primeira etapa.
3- Análise qualitativa: Nesta etapa, são analisadas e definidas as relações entre benefícios
de melhoria de processos, métricas e técnicas para medição. Para análise, serão aplicados
procedimentos de codificação baseados em Grounded Theory.
4- Obtenção do produto: Elaboração de um catálogo com benefícios de MPS, métricas
para medir benefícios quantitativos e técnicas para medir benefícios qualitativos.
5- Avaliação do produto: O objetivo desta etapa é que profissionais de Engenharia de
Software avaliem se as relações entre benefício-medidas-técnicas presentes no catálogo
atendem à seguinte Suposição 1: O catálogo com benefícios de MPS, estratégias para
medição de benefícios intangíveis e medidas base para identificar benefícios tangíveis
pode auxiliar organizações a planejarem melhor as iniciativas de melhoria de processos.
A pesquisa até o momento compreendeu o aprofundamento sobre os fatores
relacionados a benefícios de melhoria de processos de software a partir de artigos sobre
os temas: (i) Fatores críticos de sucesso em MPS; (ii) Motivação para adoção de MPS; e
(iii) Benefícios de implementação e ROI de MPS. O modelo conceitual da Figura 1
apresenta um dos resultados desta análise inicial. No momento está sendo realizada uma
rodada piloto que envolve a identificação de artigos que relatem benefícios de melhoria
de processos, métricas para mensurar benefícios quantitativos e técnicas para mensurar
benefícios qualitativos. Esta rodada piloto serve para avaliar primeira etapa da
metodologia definida acima e ajustar possíveis desvios.
5. Conclusão
A proposta deste estudo é identificar os benefícios de implementação de melhoria de
processos de software através de estudos presentes na literatura e estabelecer um corpo de
conhecimento composto de métricas para quantificar benefícios tangíveis e técnicas para
obtenção do valor estimado de benefícios qualitativos aplicáveis ao contexto de MPS.
Compreende ainda a realização de entrevistas em empresas que implementaram melhoria
de processos para coleta de benefícios e entender como são realizadas estas medições na
prática, e uma análise baseada em procedimentos de Grounded Theory. Por fim, um
estudo de caso para avaliar medidas e técnicas catalogadas.
Espera-se que o catálogo resultante deste estudo auxilie consultorias e empresas
na motivação de profissionais em apoiar as implementações de melhoria de processos,
aumentando a expectativa de sucesso nas avaliações de melhoria de processos e que motive a alta gestão de organizações de software a investirem na melhoria de seus processos.
37
Referências
Albuquerque, R. (2014), Estudo sobre Fatores que Influenciam a Manutenção de Processos de Software em Empresas
Avaliadas por Modelos de Referência, Programa de Pós-Graduação em Informática da Pontifícia Universidade
Católica do Paraná, Curitiba, PR.
Baddoo, N. e Hall, T. (2002), Motivators of Software Process Improvement: An analysis of Pracrioners Views - Journal
of Systems and software 62 - Pgs 83-96.
Etzkowitz, H., Mello, J. (2004), “The rise of a triple helix culture: innovation in Brazilian economic and social
development”. International Journal of Technology Management & Sustainable Development 2 (1): 159-171.
Ferreira, A. I. F., Santos, G., Cerqueira, R., Montonni, M., Barreto, A. - 2007 - Applying ISO 9001:200, MPS.BR and
CMMI to achieve Software Process Maturity: BL Informatica's Pathway - 29th International Conference on
Software Engineering (ICSE’07), , Minneapolis, USA, May 20-26.
Kalinowski, M., Santos, G., Reinehr, S., Montoni, M., Rocha, A.R., Weber, K.C., Travassos, G.H. (2010): MPS.BR:
Promovendo a Adoção de Boas Práticas de Engenharia de Software pela Indústria Brasileira. XIII Congresso
Iberoamericano de Engenharia de Software (CIBSE), Cuenca, Equador.
Krasner, H. (1994), The Payoff for SPI: what it is and how to get it. Software Process Newsletter, In: IEEE Computer
Society 1.
Montonni, M. A, Rocha, A. R. C. (2010), Uma investigação sobre os Fatores Críticos de Sucesso em Iniciativas de
Melhoria de Processos de Software, UFRJ/COPPE.
Niazi, M. e Ali Babar, M. (2006), Motivators of Software Process Improvement: An Analysis of Vietnamese
Practioner’s Views, 11th International Conference on Evaluation and Assessment in Software Engineering (EASE),
Keele University, UK.
Ramos, C. S., Rocha A. R. e Oliveira, K. M. (2013) - Towards a strategy for analysing benefits of Software Process
Improvement, The 25th International Conference on Software Engineering and Knowledge Engineering, Boston,
USA.
Santos, G., Kalinowski, M., Rocha, A. R., Travassos, G. H., Weber, K. C. e Antonioni, J. A. (2012) MPS.BR Program
and MPS Model: Main Results, Benefits and Beneficiaries of Software Process Improvement in Brazil - 2012
Eighth International Conference on the Quality of Information and Communications Technology, Lisboa, Portugal.
CMMI Product Team (2010), CMMI for Development (CMMI-DEV) Version 1.3. Software Engineering Institute.
Technical Report CMU/SEI-2010-TR-033. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon
University.
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro (2012), “Melhoria do Processo de
Software Brasileiro – Guia Geral MPS de Software”.
SOFTEX (2013) - IMPS - Informações para Acompanhar e Evidenciar Variação de Desempenho nas Empresas que
Adotaram o Modelo MPS, 2013, Disponível em www.softex.com.br.
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro (2015) - Avaliações MPS-SW (Software)
Publicadas (prazo de validade: 3 anos) - (Visualizado em 03-05-2015) http://www.softex.br/wpcontent/uploads/2013/07/2Avaliacoes-MPSSW-Publicadas_24.F EV_.2015_622.pdf
Solingen, R., V. (2004) Measuring the ROI of Software Process Improvement - IEEE Computer Society, May-June,
2004
Staples M., Niazy, M., Jeffery, R., Abrahams, A., Byatt, P., Murphy, R. (2007), An exploratory study of why
organisations do not adopt CMMI - The journal of system and software 80 (2007) - 883-895
Staples, M., Niazi, M. (2008) Systematic review of organizational motivations or adopting CMM-Based SPI Information and Software Technology 50, 2008, Pgs 605 - 620
Viana, D., Rabelo, J., Conte, T. (2011), Uma análise do aspecto motivacional na implementação de um Programa de
Melhoria de Processo de Software -VII Workshop Um Olhar Sociotécnico sobre a Engenharia de Software WOSES 2011, Curitiba, Paraná.
Zhran, S. - 1996 - Business e cost justification of software process improvement "ROI from SPI", International
Software Process Association Conference (ICSP '96), Washington, DC, USA.
38
Uma Abordagem para o Ensino de Engenharia de
Software Baseada em Estratégias de Capacitação de
Programas de Melhoria do Processo de Software
Carlos S. Portela1,3, Alexandre M. L. Vasconcelos1, Sandro R. B. Oliveira1,2
1
2
3
Centro de Informática (CIn) – Universidade Federal de Pernambuco (UFPE)
Caixa Postal 7851 – 50.740-560 – Recife – PE – Brasil
Programa de Pós-graduação em Ciência da Computação (PPGCC) – Instituto de
Ciências Exatas e Naturais (ICEN) – Universidade Federal do Pará (UFPA)
Belém – PA – Brasil
Área de Ciências Exatas e Tecnologia – Centro Universitário do Pará (CESUPA)
Belém – PA – Brasil
{csp3, amlv}@cin.ufpe.br, [email protected]
Abstract. Much of time and financial resources consumed in a Software
Process Improvement (SPI) Program is invested in team training. That is why
many professionals, mostly trained in undergraduate courses, do not have the
adequate knowledge in specific process areas. Thus, courses, workshops,
mentoring or coaching are conducted for technical transfer of specific
practices included on the process areas in order to level the team knowledge.
The origin of this problem may be in the approach adopted for teaching
Software Engineering in undergraduate courses. To solve this problem, this
PhD research aims to analyze the recommendations of curriculum guidelines
of ACM/IEEE and Brazilian Society of Computing (SBC) for Software
Engineering discipline and its applicability in undergraduate. Furthermore,
we propose a teaching approach that aims to address the topics of these
curriculum guidelines through training strategies widely adopted in SPI
programs.
Resumo. Grande parte do tempo e dos recursos financeiros consumidos em
um Programa de Melhoria do Processo de Software (MPS) é investido na
capacitação da equipe. Isso ocorre porque muitos profissionais, em sua
maioria formados em cursos de computação, não possuem conhecimento
adequado em determinadas áreas de processo. Desta forma, realizam-se
cursos, workshops, mentoring ou coaching para repasse técnico das práticas
específicas que compreendem as áreas de processo a fim de nivelar o
conhecimento desta equipe. A raiz do problema pode estar na abordagem
adotada para o ensino da Engenharia de Software em cursos de computação.
A fim de tratar este problema, esta pesquisa de doutorado objetiva analisar as
recomendações dos currículos de referências da ACM/IEEE e SBC para a
disciplina de Engenharia de Software e sua aplicabilidade na graduação.
Além disso, propõe-se uma abordagem de ensino que visa atender os tópicos
destes currículos de referências através de estratégias de capacitação
amplamente adotadas em Programas de MPS.
39
A Engenharia de Software (ES) constitui-se como uma das disciplinas de maior
relevância nos cursos da área de Computação [ACM/IEEE, 2013]. Isto decorre tanto da
importância do software em si quanto dos desafios relacionados com a formação
completa de um profissional que irá atuar no mercado, resultando em uma demanda
crescente por profissionais bem qualificados [Duley et al., 2003]. Tipicamente, estes
profissionais de software são formados em cursos de graduação como modo de
preparação para atuar na indústria [Nunes, Reis e Reis, 2010].
No entanto, a indústria de software, mais especificamente o mercado brasileiro,
apresenta escassez de profissionais devidamente qualificados para atuarem em
profissões que envolvem as etapas do processo de desenvolvimento de software,
compreendidas pela ES [ABES, 2014]. A indústria queixa-se de que os cursos de
graduação não ensinam as competências necessárias aos alunos para que eles possam
começar a executar o seu trabalho com eficiência [Wangenheim e Silva, 2009]. Desta
forma, as empresas de software têm que complementar os conhecimentos dos recémformados com treinamentos e prover habilidades relacionadas ao processo de
desenvolvimento de software [Bessa, Cunha e Furtado, 2012].
De acordo com Lethbridge et al. (2007), esta carência na formação de
profissionais graduados na área de ES pode ser resultado de uma educação inadequada.
Desta forma, esta pesquisa de doutorado analisará as recomendações constantes nos
currículos de referências dos cursos de computação, mais especificamente no que diz
respeito à área de Engenharia de Software. Esta análise objetiva obter dados qualitativos
do ensino/aprendizagem de ES a partir dos tópicos lecionados e das abordagens de
ensino aplicadas nesta disciplina. Os resultados desta análise serão utilizados na
definição de uma nova abordagem de ensino que visa desenvolver competências e
habilidades profissionais na área de ES. Esta abordagem baseia-se na adequação, para o
contexto acadêmico, de estratégias de capacitação amplamente adotadas em programas
de Melhoria do Processo de Software (MPS).
Além desta seção introdutória, a Seção 2 apresenta a fundamentação teórica
deste trabalho. A metodologia da pesquisa é descrita na Seção 3, que também apresenta
o estado atual deste trabalho. Na Seção 4, os trabalhos relacionados são analisados. Por
fim, os resultados esperados e a avaliação deste trabalho são descritos na Seção 5.
De acordo com a ACM/IEEE (2013), a ES é uma disciplina preocupada com a aplicação
da teoria, do conhecimento e da prática para o desenvolvimento efetivo e eficiente de
sistemas de software que satisfaçam os requisitos dos usuários. Para satisfazer as
necessidades dos usuários, os profissionais de ES devem ter a capacidade de entender o
desenvolvimento de software como um processo e assegurar prazos, custos e a
qualidade do produto a ser desenvolvido.
A ES constitui uma área cuja demanda está crescendo significativamente, pois os
usuários exigem cada vez mais eficiência, eficácia, dentre outras características de
qualidade importantes para um produto tão especial como o software [ABES, 2014]. A
fim de garantir produtos de alta qualidade e um competitivo grau de produtividade,
40
diversas empresas de software no Brasil têm adotado modelos de qualidade como o
CMMI-DEV [SEI, 2010] e o MR-MPS-SW [SOFTEX, 2012].
A maioria destas empresas realiza esta adoção através de programas de MPS,
implantados por empresas de consultoria. Durante estas consultorias, observou-se que se
gasta grande parte do tempo e recursos financeiros em treinamento da equipe. Isso
ocorre porque muitos profissionais envolvidos em programas de MPS não possuem
conhecimento adequado em determinados tópicos de ES [Leal et al., 2012]. Sendo
assim, os consultores de MPS adotam diversas estratégias de capacitação como cursos,
workshops, mentoring e/ou coaching para repasse técnico das práticas específicas que
compreendem áreas de processo (como por exemplo, Gerência de Configuração), a fim
de desenvolver as competências e as habilidades necessárias para a equipe.
O termo competência define a combinação de conhecimento, habilidades e
atributos pessoais que são adquiridos por meio de educação, treinamento e experiência
[SOFTEX, 2014]. Já o termo habilidade corresponde a capacidade do indivíduo de
realizar algo, como trabalhar em grupo, saber comunicar-se e expressar-se [SBC, 2005].
O principal objetivo desta pesquisa de doutorado é propor uma abordagem para apoiar o
ensino/aprendizagem de tópicos de ES em disciplinas da graduação baseada na
adequação de práticas de capacitação de programas de MPS. Esta seção apresenta as
hipóteses, as questões de pesquisa, os métodos adotados e o estado atual deste trabalho.
3.1. Hipóteses e Questões de Pesquisa
A partir da problemática exposta na Seção 1 e baseada na fundamentação teórica
apresentada na Seção 2, é possível realizar algumas observações:
I.
A maioria dos profissionais da área de software são formados em cursos de
graduação em computação [Nunes, Reis e Reis, 2010];
II.
A indústria apresenta insatisfação quanto ao nível de preparação dos
universitários recém-formados que entram no mercado de trabalho [Lethbridge
et al., 2007];
III.
Bacharéis de cursos de computação que trabalham como profissionais da área de
software aprendem mais sobre tópicos de ES após a graduação [Wangenheim e
Silva, 2009];
IV.
Existem diversas dificuldades no ensino de ES durante a graduação: (i) muito
conteúdo sendo ministrado em pouco tempo; (ii) baixa motivação que os alunos
possuem para estudar os conceitos teóricos de ES; (iii) dificuldades em preparar
os estudantes para a prática profissional dentro de ambientes acadêmicos [Braga,
2009].
Diante destas observações, esta pesquisa de doutorado tentará analisar a seguinte
Hipótese (H0):
H0. As abordagens de ensino atuais adotadas nas disciplinas de Engenharia de Software
preparam os alunos adequadamente para atuar na indústria de software.
41
Caso H0 seja refutada, pretende-se investigar uma hipótese alternativa definida a
partir da constatação de que as necessidades de formação profissional de cursos de
graduação e da indústria de software são semelhantes, bem como as dificuldades
encontradas nesse processo de formação (excesso de conteúdo, pouco tempo, etc.).
Sendo assim, esta tese tentará analisar a seguinte Hipótese Alternativa (H1):
H1. Se a disciplina de Engenharia de Software adotar abordagens de capacitação de
Programas de Melhoria do Processo então a preparação dos alunos na área de
Engenharia de Software será mais adequada do que as abordagens de ensino atuais.
A fim de atender os objetivos desta pesquisa de doutorado e analisar as hipóteses
H0 e H1, as seguintes Questões de Pesquisa (QP) foram definidas:
QP1. Quais tópicos são abordados nas ementas da disciplina de Engenharia de Software?
QP2. A aprendizagem dos alunos na disciplina de Engenharia de Software está
relacionada com a quantidade de tópicos abordados?
QP3. Os alunos aprendem de maneira mais adequada se contextualizarmos a aplicação
dos tópicos de Engenharia de Software com os papéis que irão desempenhar em um
processo de desenvolvimento?
3.2. Métodos de Pesquisa
A. Identificando os tópicos de ES contempladas nos cursos de graduação
Para responder a QP1, realizou-se uma revisão bibliográfica nos currículos de referência
da ACM/IEEE (2013) e da Sociedade Brasileira da Computação (SBC) (2005)
objetivando identificar quais tópicos de ES são recomendados por estes currículos.
Além disto, realizou-se um mapeamento entre estes tópicos dos currículos de referência
e as práticas específicas das áreas de processo dos modelos CMMI-DEV [SEI, 2010] e
MR-MPS-SW [SOFTEX, 2012] a fim de correlacionar estratégias de capacitação.
Atualmente, está sendo realizado um survey (S-I) com professores que
ministram disciplinas de ES a fim de identificar quais tópicos e abordagens de ensino
estão sendo adotados. Os resultados deste survey podem apoiar a análise da hipótese H0,
caso seja constatado que determinados tópicos de ES não estão sendo abordados por
estes professores.
B. Analisando a efetividade das abordagens de ensino atuais
A fim de responder a QP2, está sendo realizado um survey (S-II) com alunos que já
tenham concluído a disciplina de ES. O objetivo deste survey é analisar a aprendizagem
dos alunos e quais abordagens de ensino estes consideram mais efetivas. Os resultados
do S-II podem apoiar a análise de H0, dando-nos evidências de que determinados
tópicos de ES estão sendo efetivamente aprendidos. Além disto, poder-se-á
correlacionar as respostas do S-I com as respostas do S-II a fim de analisar se as
abordagens adotadas pelos professores são consideradas efetivas pelos alunos.
Tanto o S-I quanto o S-II estão sendo aplicados em cursos de graduação em
computação de universidades públicas e privadas do Brasil e seguem os guidelines de
Kitchenham e Pfleeger (2008). Estes surveys estão sendo divulgados em lista de e-mails,
42
grupos da área de ES em redes sociais e in loco em universidades públicas e privadas de
Belém-PA e de Recife-PE. O survey encontra-se disponível em http://goo.gl/vn5jHS. Já
o protocolo do survey encontra-se disponível em http://goo.gl/gqzMrP.
C. Definindo uma abordagem de ensino baseada em estratégias de capacitação
Após a realização dos estudos exploratórios, que visam responder QP1 e QP2, serão
identificados os tópicos de ES constantes nos currículos de referência, as abordagens de
ensino atuais adotadas pelos professores desta disciplina e as considerações dos alunos
em relação ao aprendizado destes tópicos e a efetividades destas abordagens. Estes
resultados serão considerados na definição da proposta de ensino apresentada nesta
pesquisa. Por exemplo, técnicas consideradas efetivas serão incorporadas na abordagem,
como a realização de projetos de desenvolvimento durante a disciplina de ES.
Além disso, pretende-se realizar um levantamento com especialistas da área
(consultores de MPS e implementadores de modelos de qualidade que também atuem
como professores de graduação) sobre as práticas de capacitação adotadas em programas
de MPS. A partir da identificação e da análise destas práticas, serão discutidas as
estratégias de adequação destas para o ensino de ES. Pretende-se, ainda, adotar a
estratégia do modelo estagiado do CMMI-DEV, onde se definem quais áreas de
processo serão foco da melhoria. Assim, alunos e professores poderão delimitar o
escopo de seus esforços, reduzindo a quantidade de tópicos de ES ministrados para
trabalhar o desenvolvimento de competências e habilidades em ES. Espera-se, a partir
da análise dos resultados da aplicação desta abordagem de ensino, responder a QP3 e
analisar a H1.
Um esboço desta abordagem foi discutido entre os autores com base em sua
experiência profissional, como professores de ES e consultores em MPS, e na proposta
pedagógica de ensino prático de ES definida por Gary et al. (2013). Este esboço é
apresentado na Figura 1.
Figura 1. Esboço da Abordagem de Ensino
Inicialmente, na fase de Preparação, os alunos deverão realizar leitura e pesquisa
dos tópicos de ES. Na fase de Discussão, serão realizados seminários e debates
relacionados a estes tópicos. Em seguida, na fase de Prática, os alunos aplicarão os
conceitos estudados através de workshops de uso de ferramentas e da realização de
dinâmicas. Na fase de Reflexão, os alunos registrarão suas expectativas e levantarão
43
hipóteses em relação aos tópicos de ES que irão aplicar no projeto prático. A fase de
Contextualização consistirá na tradicional abordagem de desenvolvimento de software
por um grupo de alunos, a fim de aplicar os tópicos de ES. Nesta fase, os alunos
levantarão requisitos de um cliente real e serão aplicadas as técnicas de mentoring (pelo
professor da disciplina) e coaching (por alunos veteranos). Por fim, os alunos realizarão
uma nova fase de Reflexão, pós-projeto, a fim de comparar os resultados obtidos com
suas expectativas no pré-projeto e se suas hipóteses foram validadas ou refutadas.
3.3. Estado Atual
A Tabela 1 apresenta as fases desta pesquisa de doutorado e seu estado atual.
Tabela 1. Status do Projeto de Pesquisa
Fase da Pesquisa
Definição da Proposta de Tese de Doutorado
Análise dos Currículos de Referência
Definição do Protocolo dos Surveys
Aplicação dos Surveys
Levantamento das Práticas de Capacitação
Definição da Proposta de Ensino
Defesa de Qualificação de Tese
Realização do Experimento Controlado
Testes das Hipóteses da Tese de Doutorado
Escrita da Tese de Doutorado
Defesa da Tese de Doutorado
Prazo
Set/2014
Nov/2014
Fev/2015
Mai/2015
Jun/2015
Jul/2015
Nov/2015
Dez/2015
Jun/2016
Dez/2016
Mar/2017
Status
Concluída
Concluída
Concluída
Concluída
Em Andamento
Em Andamento
Não Iniciada
Não Iniciada
Não Iniciada
Não Iniciada
Não Iniciada
Existem vários estudos que propõem abordagens de ensino de ES, como as de Braga
(2009), Bessa, Cunha e Furtado (2012) e Gary et al. (2013). No entanto, essas
abordagens não testam adequadamente a H0, pois restringem a avaliação dos resultados
da aplicação de suas abordagens de ensino ao conteúdo ministrado ou ao processo e ao
produto resultante da realização de uma disciplina prática de ES. Sendo assim, não se
pode concluir se preparam adequadamente os alunos para atuarem na área de ES.
Por exemplo, Bessa, Cunha e Furtado (2012) propõem um jogo de simulação de
ambientes reais para auxiliar o aprendizado de ES. Apesar dos jogos capacitarem alunos
de forma efetiva, acabam por restringirem o atendimento de determinados tópicos
curriculares à medida que não conseguem explorar adequadamente a quantidade de
tópicos de ES, pois se tornariam demasiadamente complexos, perdendo sua principal
característica de ensino/aprendizado. Já Braga (2009), propõe uma abordagem
multidisciplinar que define diretrizes para aplicação dos conceitos de ES em várias
disciplinas dos cursos de Ciência da Computação. No entanto, esta abordagem restringese à aplicação de tópicos curriculares, sem se preocupar com o desenvolvimento das
competências e das habilidades profissionais necessárias para realizar as atividades de
projetos de software de forma eficiente.
Ao contrário destes trabalhos, esta abordagem irá aplicar os tópicos de ES de
acordo com os papéis (gerente de projetos, desenvolvedor, analista de qualidade, etc.)
que os alunos irão desenvolver no projeto prático da disciplina de ES, semelhante à
estratégia de treinamentos adotada por consultores de MPS. Assim, poder-se-á focar na
44
capacitação profissional dos alunos, ao invés de focar somente na avaliação do processo
e/ou produto gerado por estes durante a disciplina de ES.
Em relação a H1, Gary et al. (2013) propõem um modelo pedagógico para o
ensino de ES em cursos de graduação em computação. Essa proposta, maturada ao
decorrer de 9 anos de aplicação na Arizona State University, combina aula tradicional
com abordagens de aprendizagem centrada em problemas (Problem Based Learning –
PBL). Assim, os alunos assistem as palestras e colocam os conceitos em prática por
meio de sessões de laboratório de desenvolvimento a cada semana. Nesta abordagem, o
professor realiza o papel de coaching e alunos veteranos o papel de mentoring.
A abordagem proposta nesta tese baseia-se fortemente neste modelo pedagógico,
agregando o uso de práticas e estratégias de programas de MPS a fim de analisar H1.
Por exemplo, a estratégia de definir as áreas de processo que serão o foco da melhoria
pode ser adequada para o contexto acadêmico, a partir da definição de unidades de
conhecimento que serão foco da ementa da disciplina de ES. Isto permitiria desenvolver
melhor determinadas competências e habilidades profissionais nestas unidades.
5. Resultados Esperados e Validação
Em resumo, esta pesquisa de doutorado é destinada a: (i) identificar tópicos de ES em
currículos de referência da área e analisar suas relevâncias para a academia e indústria
de software; (ii) identificar, por meio de surveys com professores e alunos, as atuais
abordagens de ensino adotadas por professores e eventuais problemas nestas; e (iii)
fornecer uma abordagem de ensino para atender, de maneira satisfatória, a demanda de
formação profissional para a área de ES durante a graduação.
A fim de validar nossa proposta de abordagem de ensino, pretende-se realizar
um experimento controlado em uma disciplina de ES num curso de graduação em
Sistemas de Informação. Este experimento seguirá os guidelines propostos por Wohlin
et al. (2000), onde será configurado um cenário para aplicação da proposta de ensino.
Primeiramente, será identificado o problema de um cliente real, a fim de definir os
requisitos do projeto da disciplina. Em seguida, o professor irá dividir a turma em dois
grupos (experimental e de controle). O grupo de controle seguirá a abordagem de ensino
atual da disciplina, definindo um processo tradicional de desenvolvimento de software
(baseado no RUP, SCRUM, etc.). Já o grupo experimental, adotará a abordagem de
ensino proposta neste artigo, recebendo um treinamento específico. Assim, este grupo
poderá seguir uma nova abordagem de ensino/aprendizado. O objetivo é comparar o
aprendizado dos alunos dos dois grupos, através da análise de mapas conceituais
(usando os tópicos de ES) elaborados por estes no início e ao final da disciplina.
Finalmente, pretende-se publicar os resultados para estimular replicações deste
tipo de pesquisa e, consequentemente, solucionar determinados gaps desta área de
ensino de ES. Neste contexto, ressalta-se que o ensino adequado de ES é importante
para melhorar o estado atual de desenvolvimento de software e ajudar a mitigar muitos
dos problemas tradicionais associados à indústria de software.
Agradecimentos
Os autores gostariam de agradecer à Coordenação de Aperfeiçoamento de Pessoal de
Nível Superior (CAPES) pelo apoio financeiro ao desenvolvimento desta pesquisa.
45
Referências
ABES (2014), Mercado Brasileiro de Software: Panorama e Tendências, Associação
Brasileira das Empresas de Software, 1ª edição. São Paulo, Brasil.
ACM/IEEE (2013) “Computer science curricula 2013 – Curriculum guidelines for
undergraduate degree programs in Computer Science”, https://www.acm.org, Abril.
Bessa, B. Cunha, M. e Furtado, F. (2012). ENGSOFT: Ferramenta para Simulação de
Ambientes Reais para auxiliar o Aprendizado Baseado em Problemas (PBL) no
Ensino de Engenharia de Software. Em Anais do XX Workshop sobre Educação em
Informática. Curitiba, Brasil.
Braga, J. (2009). Diretrizes para o Ensino Interdisciplinar de Engenharia de Software.
Em Anais do II Fórum em Educação em Engenharia de Software. Fortaleza, Brasil.
Duley, R. et al. (2003). Engineering an introductory software engineering curriculum. In
Proceedings of 16th Conference on Software Engineering Education and Training,
pages 99-106.
Gary, K. et al. (2013). A Project Spine for Software Engineering Curricular Design. In
Proceedings of 26th Conference on Software Engineering Education and Training,
pages 299-303.
Kitchenham, B. e Pfleeger, S. (2008) “Personal Opinion Surveys”, In: Guide to
Advanced Empirical Software Engineering, Springer, ch. 3, pages 63-92.
Leal, G. et al. (2012). Empirical study about the evaluation of the implantation of
MPS.Br in enterprises of Paraná. In Proceedings of XXXVIII Conferencia
Latinoamericana en Informatica, pages 1-9.
Lethbridge, T. et al. (2007). Improving software practice through education: Challenges
and future trends. In Proceedings of the Conference Future of Software Engineering,
pages 12-28.
Nunes, D. Reis, C. e Reis, R. (2010) “Educação em Engenharia de Software”, Em: A
carreira do pesquisador em Engenharia de Software: princípios, conceitos e direções.
1ª edição. Salvador, Brasil: UFBA, cap. 5, páginas 132-181.
SBC (2005). Currículo de Referência da SBC para Cursos de Graduação em
Bacharelado em Ciência da Computação e Engenharia de Computação,
http://www.sbc.org.br, Abril.
SEI – Software Engineering Institute (2010) “CMMI for Development – V 1.3”,
http://www.sei.cmu.edu, Abril.
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro (2012)
“Guia Geral MPS de Software: 2012”, http://www.softex.br, Abril.
Wangenheim, C. e Silva, D. (2009). Qual Conhecimento de Engenharia de Software é
Importante para um Profissional de Software? Em Anais do II Fórum de Educação
em Engenharia de Software. Fortaleza, Brasil.
Wohlin, C. et al. (2000) “Experimentation in software engineering: an introduction”.
Kluwer Academic Publishers, Norwell, MA, USA.
46
Alavancando a melhoria de processos e o desenvolvimento
de software a partir de fatores de impacto na
produtividade
Ricardo Ajax Dias Kosloski1,2, Ana Regina C. da Rocha1
1
2
COPPE/UFRJ - Universidade Federal do Rio de Janeiro – Caixa Postal 68511 –
CEP 21945-970 – Rio de Janeiro – RJ – Brasil
Universidade de Brasília (UNB) – Faculdade Gama - Área Especial de Indústria
Projeção A Brasília/DF – Bairro: Gama – Setor Leste – CEP: 72.444-240
Abstract. For the software industry to improve productivity, deadlines,
costs and quality of their projects contributes to increase its
competitiveness in a market highly susceptible to changes. The
productivity can be influenced by several factors related to the software
development, and can be considered as an important way to assess,
monitor and improve the performance of this industry in the search for
better competitive conditions. Therefore, this paper presents a proposal
to promote the improvement of processes in the software development
from the treatment of impact factors in productivity along the software
process improvement initiatives of the organization.
Resumo: Para a indústria de software, melhorar a produtividade,
prazos, custos e qualidade dos seus projetos contribui para aumentar a
sua competitividade ao atuar num mercado altamente susceptível a
mudanças. A produtividade pode ser influenciada por vários fatores
inerentes ao desenvolvimento de software, podendo ser considerada
como um importante mecanismo para avaliar, controlar e melhorar o
desempenho desta indústria na busca por melhores condições
competitivas. Desta forma este trabalho apresenta uma proposta para
fomentar a melhoria de processos no desenvolvimento de software a
partir do tratamento de fatores de impacto na produtividade ao longo
das iniciativas de melhoria dos processos da organização.
1
Introdução
A indústria de software tem enfrentado um cenário de mudanças forçando-as a
melhorar continuamente seus processos produtivos. As melhorias incluem
objetivos organizacionais almejando maiores níveis de produtividade e
previsibilidade, diminuição dos custos de projetos e, consequentemente, melhoria
da sua capacidade competitiva no mercado onde atua (Albuquerque e Rocha,
2009). Autores relatam a importância dos relacionamentos entre as variáveis
produtividade, esforço, tamanho, custos, prazos e qualidade como fontes de
estudos desde a década de 90 (Rubin, 1993; Fenton, Pfleeger, 1997; Putnam,
Mayers 2003; Wagner, Ruhe, 2008; Sampaio et al, 2010; Petersen, 2011).
Embora demonstrado por Wagner e Ruhe (2008) que a Melhoria de
Processos de Software (MPS) é um fator que causa um relevante impacto na
47
produtividade em software, ele não é o único. Outros autores relatam estudos
sobre fatores de impacto na produtividade desde a década de 70 até 2009
(Sampaio et al, 2010). Por outro lado, Petersen (2011) inclui outras abordagens de
estudos sobre produtividade em software, além dos fatores de impacto.
Atualmente a abordagem de melhoria de processos continua importante
para a indústria de software com o advento de modelos de maturidade como o
CMMI-DEV-V1.3 (SEI, 2010), o MPS-SW (Softex, 2012). Birkhölzer et al
(2011) defendem que as iniciativas de MPS precisam de guias para selecionar e
priorizar as áreas ou aspectos a serem focados na melhoria, o que é feito nesses
modelos por meio da organização em níveis de maturidade (Chrissis et al 2011;
Softex, 2012).
Os modelos de maturidade tratam um amplo espectro de elementos de
melhoria, variando desde fatores relacionados a questões técnicas, perpassando os
gerenciais e incluindo os de suporte às atividades de desenvolvimento de software
(Chrissis et al, 2011; Softex, 2012). Desta forma, neste contexto e segundo a
premissa de que é possível associar os fatores de impacto na produtividade às
áreas de processos de modelos de maturidade em desenvolvimento de software,
surgiu como questão central motivadora desta pesquisa: “Como aumentar a
produtividade de desenvolvimento de software a partir da melhoria de processos
e dos fatores que impactam a produtividade?”
Para o restante deste documento, a Seção 2 apresenta uma breve revisão de
literatura; a Seção 3 as definições básicas e etapas propostas para o trabalho e a
Seção 4 os resultados esperados e considerações finais.
2
Qualidade e Produtividade
O conceito de produtividade foi herdado da manufatura objetivando avaliar seu
desempenho (Putnam, Mayers, 2003, Fenton e Pfleeger, 1997). Outros autores
confirmam a sua definição clássica de relacionar a quantidade do produto gerado
aos insumos consumidos para produzi-lo (Maxwell 2001; Buglione, 2010;
Petersen, 2011; Lopéz et al, 2012, Cheikhi et al, 2012). Para eles, na indústria de
software, a saída é considerada como o tamanho do software e a entrada como o
esforço gasto para desenvolvê-lo. Desta forma a equação Produtividade =
Tamanho / Esforço pode ser postulada.
Morasca e Russo (2002) ressaltam que o tamanho do software pode ser
avaliado conforme os pontos de vista: interno, contabilizando as linhas de código
(KLOC); e externo, onde são usadas métricas de tamanho funcional como a APF Análise de Pontos de Função (IFPUG, 2010). Embora existam algumas críticas
sobre as métricas funcionais, elas possuem a vantagem de poderem ser usadas
desde cedo no desenvolvimento do software, devido a se basearem em requisitos
funcionais. Algumas críticas dizem respeito a:
• Existência de outros esforços devidos a treinamentos, reuniões e requisitos não
funcionais que não adicionam tamanho ao produto de software, mas são
necessários para a sua construção (Fenton e Pfleeger, 1997). Esta afirmação é
respaldada pelo IFPUG ao afirmar que existem outras dimensões de tamanho,
além da fornecida pelos requisitos funcionais, mas não mensuradas pela APF
(IFPUG, 2010).
48
• Para Buglione (2010) é incorreto tomar o tamanho do projeto como somente o
tamanho do seu produto de software, pois existem outros resultados adicionais
no projeto que não incorporam tamanho ao produto.
Sobre a qualidade em desenvolvimento de software, Vilas Boas et al
(2010) ressalta que Melhorar a qualidade significa melhorar a qualidade dos
produtos e serviços da organização, o que pode ser obtido por programas de MPS.
Santos et al (2010) afirmam que a estratégia de melhoria no Brasil, tanto do
produto, quanto do processo, existe desde 1993. Segundo esses autores, o uso das
boas práticas sugeridas pelos modelos de maturidade podem melhorar o
desempenho da organização com relação à produtividade, dentre outras variáveis
como custos, prazos e qualidade. Assim, apresentam resultados considerados
como excelentes e coletados durante vários anos com a adoção do modelo MPSSW pela indústria nacional. Os estudos foram realizados no âmbito do iMPS,
iniciado em outubro de 2007 com o objetivo geral de permitir acompanhar e
evidenciar o desempenho nas organizações de software que adotaram o MPS.Br
(iMPS, 2015).
Sampaio et al (2010) construíram o Quadro 1 no qual apresentam os
fatores que causam impactos críticos na produtividade, classificados em ordem
descendente por quantidade de citações na literatura pesquisada na época. Nele
percebe-se que não somente o fator de impacto “processo” foi o mais citado,
como também o número de citações sempre aumenta durante o período estudado.
Quadro 1: Fatores críticos de impacto na produtividade (Sampaio et al, 2010)
Fator
70
1
0
2
1
1
1
1
2
1
0
0
Processo
Ferramentas
Habilidades da equipe (Skils)
Reuso
Linguagem de programação
Complexidade do software
Tamanho do software
Tamanho da equipe
Estabilidade dos requisitos
Motivação
Qualidade da Gerência
Década
80
90
4
5
8
6
6
4
5
7
8
4
6
6
6
6
1
4
5
3
4
1
4
2
2000
15
11
12
8
8
7
6
12
3
5
4
Citações
25
25
24
21
21
20
19
19
12
10
10
Além deles, Petersen (2011) fez um trabalho baseado em Revisão
Sistemática de Literatura sobre produtividade, considerando desde a década de 70
até 2010. Neste estudo é concluído que: a medição de produtividade é essencial
para controlar e melhorar o desempenho da indústria; a capacidade de prever a
produtividade exerce um importante papel na melhoria de processos, permitindo
traçar linhas de base de desempenho para serem reavaliadas após as propostas de
ações de melhorias; as bases históricas de produtividade são importantes para
evidenciar as melhorias de processos da organização, identificar os melhores
desempenhos e aprender com eles.
Assim sendo, estudos apontam para a existência de diversos fatores que
causam impactos na produtividade. Desta forma, estabelecer uma estratégia para
aumentar a produtividade de organizações de desenvolvimento de software pode
49
ser considerada com algo relevante na busca por melhores condições competitivas
no mercado onde elas atuam.
3
Definições da pesquisa
Com base na pergunta central desta pesquisa “Como aumentar a
produtividade de desenvolvimento de software a partir da melhoria de processos
e dos fatores que impactam a produtividade?”, podem ser postuladas as seguintes
questões específicas:
• Como identificar (calcular) a produtividade em organizações de software?;
• Quais são os fatores que causam impactos na produtividade
desenvolvimento de software?
de
Desta forma, pode ser colocado o seguinte objetivo geral deste trabalho: Definir
como aumentar a produtividade de desenvolvimento de software a partir da
melhoria de processos e dos fatores que impactam a produtividade? Neste caso,
os seguintes objetivos específicos foram relacionados:
• Identificar as formas de medição de produtividade praticadas pela indústria de
software e como elas têm sido usadas para avaliar a produtividade;
• Identificar uma lista de fatores que causam impactos na produtividade em
software;
• Mapear os fatores identificados pelas áreas de processos de modelos de
maturidade em desenvolvimento de software como MPS-SW e CMMI-Dev;
• Estabelecer uma estratégia de melhoria de processos baseada no uso dos
fatores de impacto na produtividade identificados;
• Estabelecer formas de avaliar a estratégia estabelecida.
3.1
Etapas da pesquisa
Para apoiar a elaboração deste trabalho, é proposta uma metodologia de pesquisa
composta de etapas ilustradas na Figura 1 e detalhadas a seguir.
Figura 1: Etapas da pesquisa.
(1)–Realizar revisões de literatura: Para aumentar o conhecimento sobre o tema,
inicialmente foi feita uma revisão não sistemática de literatura sobre a
produtividade na indústria de software. Foram encontradas informações sobre
formas de cálculo e suas limitações de aplicabilidade e sobre fatores que
influenciam a produtividade, conforme apresentado na seção 2 deste artigo. Esta
50
revisão também buscou obter um maior conhecimento do assunto para elaborar as
definições de um estudo mais rigoroso na literatura, baseado na teoria de Revisões
Sistemáticas de Literatura - RSL (kitchenham, 2004; kitchenham, 2007),
conforme as questões definidas para a pesquisa.
No momento da elaboração deste artigo, a pesquisa se encontrava nesta fase
com a execução de verificações do protocolo de pesquisa por pesquisadores mais
experientes, além da execução de testes da expressão de busca aplicada à base
digital de publicações da SCOPUS (SCOPUS, 2015). Os resultados dos testes
estão sendo analisados juntamente com pesquisadores mais experientes, a fim de
gerar refinamentos da expressão de busca, conforme forem necessários. O
resultado desta etapa da pesquisa é o conjunto de publicações coletadas da
literatura especializada que dará suporte ao restante deste trabalho.
(2)-Elaborar Definições para avaliar a produtividade da organização: A partir
dos insumos obtidos na fase anterior é necessário definir como será feito o cálculo
e avaliação das produtividades da organização. São necessárias definições tanto
sobre o dimensionamento do tamanho do software, quanto dos esforços que foram
gastos para construí-lo. Para o tamanho existem métricas físicas como KLOC –
Milhares de Linhas de código e métricas funcionais como APF – Análise de
Pontos de Função (IFPUG, 2010) e PFCs – Pontos de Função COSMIC, dentre
outras. Para o esforço, existem atividades também importantes para o projeto de
software além das somente de cunho técnico (ex.: gerenciais, treinamentos,
qualidade, gestão de configuração; medições, etc). Compatibilizar os esforços
usados no cálculo da produtividade é importante para as aplicações a serem
executadas mais tarde na pesquisa, pois em estudos de Benchmarking de
produtividades é necessário se comparar coisas iguais (Maxwell, 2001). Assim, o
resultado desta etapa será o conjunto de definições sobre as métricas a serem
usadas de acordo com os desenvolvimentos de software, além dos tipos de
esforços que devem ser coletados para o cálculo da produtividade da organização.
(3) – Definir a estratégia de Melhoria a ser aplicada nas organizações: Esta
etapa consiste em definir a forma de alavancar a produtividade da organização de
software a partir dos fatores de impacto na produtividade. Mesmo sendo esta uma
etapa ainda a ser executada e, portanto, com possibilidade se sofrer ajustes devido
aos resultados obtidos em etapas anteriores, a ideia geral da estratégia consiste
em: I. após a identificação dos fatores de impacto na produtividade, mapeá-los
pelas áreas de processos do modelo de maturidade usado pela organização (MPSSW ou CMMI-Dev). Nesta parte, pretende-se validar o mapeamento por meio de
revisões em pares com implementadores experientes no modelo de maturidade em
desenvolvimento de software em uso pela organização. II. estabelecer uma forma
de priorizar os fatores de impacto na produtividade a serem tratados pela
organização. III. Avaliar a produtividade antes da implementação das melhorias.
IV. Aplicar as melhorias na organização. V. reavaliar os níveis de produtividade
atingidos após as implementações das melhorias.
Convém ressaltar que também faz parte da definição da estratégia a
elaboração de definições dos estudos de caso a serem executados como: critérios
para a escolha das organizações e projetos de software a serem estudados, das
medições a serem efetuadas, dos métodos e técnicas que serão usados para
analisar os dados obtidos, assim como as possibilidades de consolidação dos
51
resultados para o estabelecimento de conclusões Desta forma estes itens devem
ser considerados na próxima fase e, juntamente com os passos necessários para a
aplicação da estratégia, constituem os resultados esperados desta etapa da
pesquisa.
(4) – Aplicar a estratégia estabelecida:
Consiste basicamente em escolher as organizações e projetos que comporão os
conjunto de estudos de caso, usando as definições da fase anterior. Em seguida,
planejar e executar as atividades identificadas, a fim de prover os dados
necessários para as atividades da próxima fase. Neste caso, a lista de estudos de
casos a serem realizados, seus respectivos planejamentos além dos dados
coletados durante suas execuções são os resultados esperados desta etapa da
pesquisa.
(5) – Relatar resultados e rever estratégia: consiste basicamente em fazer as
análises críticas dos dados coletados, elaborando e consolidando conclusões em
lições aprendidas que possam ser usadas futuramente na organização ou em
organizações com programas de MPS semelhantes. Além disso, podem ser
descobertos insumos que justifiquem ajustes na própria estratégia de MPS para a
organização. Neste caso, o relato com as conclusões, recomendações, lições
aprendidas e ajustes na estratégia de melhoria da organização (caso existam), são
os resultados esperados desta etapa da pesquisa.
(6) – Ajustar estratégia para a organização. Nesta etapa, caso existam ajustes,
eles são considerados para uma aplicação complementar da estratégia na
organização em estudo.
4
Resultados esperados e considerações finais.
Os resultados esperados da pesquisa foram descritos ao longo das fases da
pesquisa apresentadas na seção 3.1. Em grandes linhas, eles consistem a princípio,
em:
• Definições sobre a forma de cálculo da produtividade em desenvolvimento de
software, para os contexto das organizações estudadas;
• A lista de fatores de impacto na produtividade em desenvolvimento de
software;
• Um mapeamento dos fatores de impacto identificados pelas áreas de processo
da organização;
• Uma forma de priorização dos tratamentos dos fatores de impacto na
produtividade a serem usados pela organização para alavancar a sua melhoria
de processos;
• Os resultados práticos da aplicação de fatores de impacto na produtividade com
conclusões, recomendações e lições aprendidas obtidas para uso posterior na
própria organização ou em organizações com programas de MPS semelhantes.
Ao final é esperado ser possível estabelecer como usar os fatores de
impacto na produtividade como insumos para o estabelecimento de estratégias de
melhorias de processos que promovam também o aumento da produtividade em
desenvolvimento de software.
52
5
Referências
Albuquerque, Adriano, B.; Rocha, Ana R. (2009) “Evaluation and Improvement
of Processes Assets: A real Colaborative Experience”, In: Wold Congress of
Software Engineering, IEEE.
Birkholzer, T., Dickmann, C., Vaupel, J., 2011, "A Framework for Systematic
Evaluation of Process Improvement Priorities". In: Software Engineering and
Advanced Applications (SEAA), 2011 37th EUROMICRO Conference.
Buglioni, Luigi (2010) “Some Thoughts on Productivity on ICT Projects” White
Paper do Autor.
Cheikhi, Laile; Al-Qutaish, Rafa E.; Idri, Ali (2012) “Software productivity:
Harmonization in ISO/IEE SW Eng. Standards”In: Journal of Software IEEE.
Chrissis, Mary B.; Konrad, Mike; Shrum, Sandy (2011) “CMMI for
Development: Guidelines for Process Integration and Product Improvement”
Third Edition, Addison-Wesley.
COSMIC (2011) “The COSMIC functional size Measurement Method, Version
4”, Common Software Measurement International Consortium.
Fenton, Norman, E.; Pfleeger, Shari, L. (1997) “Software Metrics: A Rigorous
and Practical Approach”, PWS Publishing Company.
IFPUG (2010), Function Point Analysis, Counting Practices Manual, Release
4.3.1” IFPUG – International FUnction Point Users Group.
iMPS (2015) “Resultado de desempenho de organizações que adotaram o modelo
MPS” site acessado da Internet pelo link http://www.softex.br/mpsbr/resultadode-desempenho/, em Março 2015.
Kitchenham, B., (2004), Procedures for Performing Systematic Reviews,
Technical Report, Departament of Computer Science Keele University, Keele.
Kitchenham, B., (2007), Guidelines for performing Systematic Literature Reviews
in Software Engineering, Version 2.3, Departament of Computer Science Keele
University, Keele
Kitchenham, B.; Mendes, E.; “Software productivity measurement using multiple
size measures” (2004) In: IEEE Transactions of Software Engineerinh, Vol.30,
No. 12, December 2004
Kosloski, Ricardo, A. D.; Oliveira, Káthia, M. (2005) “An Experience Factory to
Improve Software Development Effort Estimates” In: 6th International
Conference on Product Focused Software Process Improvement – PROFES
2005, Oulu, Finland.
Lopéz, Adrina H.; Palacios, Ricardo, C.; Crespo, Ángle, G. “Productivity on
software engineering: A study of its meanings for practitioners”.
Maxwell, Katrina, D. (2001) “Collecting Data for Comparatility: Benchmarking
Softwre Development Productivity”, IEEE Software.
Morasca, Sandro; Giuliano, Russo (2002) “An Empirical Study on Software
Productivity” In: Computer Software and Applications, 2001.
53
Petersen, Key (2010) “Measuring and Predicting Software Productivitqy: A
systematic Map and Review”, Elsevier.
Putnam, Lawrence, H.; Myers, Ware (2003) “Five Core Metrics: The Intelligence
Behind Successful Software Management”, Dorset House Publishing, 353
West 12th Street, New York, NY 10014.
Rubin, Howard, A. (1993) “Software Process Maturity: Measuring its Impact on
Productivity and Quality” In: Proceedings of the 15th international conference
on Software Engineering, IEEE.
Sampaio, Suzana, C.; Barros, Emanuella, A.; Soares, Junior, G.; Silva, Mauro, J.;
Meira, Silvio, R. “A review of Productivity Factors and Strategies on SW Dev”
In: 5ft, International Conference on Software Engineering Advances, IEEE.
Santos; Gleison S. (2008); Ambiente de Engenharia de Software Orientados a
Corporação, Tese apresentada à COPPE/UFRJ comoparte dos requisitos
necessários para obtenç!Ao do grau de Doutor em Ciências
Santos, G., Kalinowski, M., Rocha, A.R., Travassos, Guilherme, H.; Chaves,
Kival Weber (2010) "MPS.BR: A tale of software process improvement and
performance results in the Brazilian software industry", In: Seventh
International Conference on the Quality of Information and Communications
Technology; pp. 412-417, Porto.
SEI (2010) “CMMI for Development, Version 1.3”, Software Engineering
Process Management Program.
SCOPUS, 2015 Biblioteca digital de publicações acessada pela internet pelo link
http:// www.scopus.com, em abril/2015.
Softex (2012) “Guia Geral MPS de Software”, MPS.Br Melhoria do Processo do
Software Brasileiro, Associação para Promoção da Excelência do Software
Brasileiro.
Villas Boas, Gisele; Rocha, Ana R.C.; Amaral, Marcio, P. “An approach to
Implement SPI in midi sized organizations” In: 7th International conference on
the quality of Information and Communications Technology, IEEE.
Wagner, Stefan; Rhue, Melanie (2008) “A Systematic Review of Productivity
Factor in Software Development”, Technische Universitat München, –
Germany, Siemens AG, Germany.
54
Representação das metas estratégicas à capacidade e
desempenho do processo de desenvolvimento de software
Maria Alciléia A. Rocha12, Toacy C. de Oliveira1
1
Programa de Engenharia de Sistemas e Computação – Universidade Federal do Rio de
Janeiro (UFRJ) - Rio de Janeiro, RJ – Brasil.
2
Instituto Federal de Educação, Ciência e Tecnologia Fluminense (IFF) - Campos dos
Goytacazes, RJ – Brasil
Abstract. This article proposes a study to define an approach for represent
software development aspects, from strategic goals to indicators of process
performance and capacity. Therefore we performed an ad hoc literature
review, yielding a theoretical basis and some related work.
Resumo. Este artigo propõe uma pesquisa visando definir uma abordagem
para representar os aspectos relacionados ao desenvolvimento de software,
desde as metas estratégicas aos indicadores de desempenho e capacidade dos
processos. Para isto, foi executada uma revisão ad hoc da literatura, obtendose uma fundamentação teórica e alguns trabalhos relacionados.
1. Introdução
Atualmente, a produção de bens e serviços está sujeita ao atendimento às expectativas
dos clientes, que mudam frequentemente; ao alcance das metas estabelecidas, que
depende das estratégias adotadas por si e pelos concorrentes; e às variações do
ambiente. Isto exige flexibilidade e capacidade para lidar com as mudanças.
Nestas circunstâncias, o conhecimento sobre a capacidade e desempenho dos
processos pode contribuir para a sobrevivência de uma organização, inclusive as
desenvolvedoras de software, pois permite a definição de metas mais realistas.
Geralmente, tal conhecimento advém da análise dos resultados obtidos ao longo do
tempo, considerando variáveis e seu contexto, abordagens para medição e controle
estatístico de processo, o que viabiliza previsões mais precisas e a melhoria contínua.
Também, a concepção e disseminação do conhecimento é facilitada pela adoção
de alguma linguagem apropriada, pois o mundo é representado por imagens ou por
signos, de forma tão mais correta quanto mais se adequar ao que representa (Bicudo,
1999). No caso dos negócios, i* (i star) (YU, 1995), UML (Unified Modeling
Language) (Booch, Rumbaugh e Jacobson, 2000), BPMN (Business Process Modeling
Notation) (OMG, 2011), entre outras, permitem uma representação simplificada da
realidade, facilitando a comunicação e o entendimento sobre como ou porquê o trabalho
é realizado. No entanto, as notações não abrangem todos os aspectos relevantes de
forma integrada, requerendo complementação por meio de extensões, modelos ou
documentos, o que aumenta a complexidade e a dificuldade para mantê-los.
Neste contexto, considera-se a seguinte questão de pesquisa: como representar as
55
perspectivas do negócio de desenvolvimento de software integradas ao conhecimento
sobre capacidade e desempenho do processo?
Logo, propõe-se uma pesquisa no âmbito da modelagem de negócios, visando
representar processos de desenvolvimento de software alinhados às metas estratégicas
da fábrica de software, integrando indicadores, contexto, e outros, através de notação e
ferramenta computacional para monitoramento e comunicação. Tal proposta considera
que toda organização que nega o ócio (negócio) produzindo bens ou serviços deve ser
hábil ao equilibrar variáveis como: tempo, recursos, qualidade e conhecimento a fim de
alcançar suas metas, geralmente, relacionadas a lucro, satisfação ou reconhecimento. E,
é preciso que todos os envolvidos saibam quais são as metas, como alcançá-las no prazo
definido e quanto os resultados parciais os desviam ao executar ou simular processos.
2.1. Metas e Processos
De acordo com o Cambridge Free English Dictionary and Thesaurus, o termo goal é
definido como “a purpose, or something that you want to achieve” e pode ser traduzido
para o português como meta, definida pelo Dicionário Português Online como “fim a
que se dirigem as ações ou os pensamentos de alguém”. Yu (1995) define meta como
uma condição ou estado de negócios que o ator gostaria de alcançar, expressa como uma
afirmação da linguagem de representação. Loucopoulos e Karakostas (1995, p. 108)
afirmam que o termo meta pode ser usado em diferentes abordagens, com diferentes
significados, como: tarefas humanas, resultados de soluções de problemas, estados
desejados do mundo, políticas e orientações para ações, entre outros. Complementando,
Kueng e Kawalek (1997, p. 18) afirmam que os seres humanos têm metas, vontades e
propósitos, e tentam alcançá-las, fazendo algumas coisas e evitando outras.
No ramo dos negócios, o conceito de meta incorpora-se ao conceito de processo,
pois um processo pode ser definido como um conjunto de atividades parcialmente
ordenadas visando alcançar uma meta (Hammer e Champy, 1994). Eriksson e Penker
(2000, p. 63-38) conceituam processo referindo-se às funções em que o negócio
consome, refina, processa, transforma ou usa objetos concretos (pessoas, máquinas,
materiais, etc.) ou abstratos (conceitos, instruções, serviços, etc.) para produzir outros
objetos. Especificamente, processo de software foi definido por Fuggetta (2000) como
um conjunto coerente de políticas, estruturas organizacionais, procedimentos, artefatos e
tecnologias necessários para conceber, desenvolver, implantar e manter software.
Assim, para alcançar uma meta é preciso definir estratégias que podem ser
traduzidas em processos, que por sua vez podem desencadear metas inerentes ou
submetas. Kueng e Kawalek (1997, p. 23) destacam que as metas relacionadas ao
processo são reduzidas ou decompostas até que possam ser transformadas em
atividades, que são executadas a fim de atingi-las, considerando que podem ser
contraditórias, independentes ou complementares e tem diferentes prioridades.
Basili et. al. (2007) sugerem a definição de valores para as metas dos processos,
em termos de magnitude e prazo. Entretanto, destaca-se que tais valores não devem ser
definidos arbitrariamente, sob pena de estar aquém ou além da capacidade da
organização alcançá-las, pois, para Wheeler (2001, p. 21-22), quando as pessoas são
pressionadas a atingir um valor-alvo, há três maneiras como elas podem proceder:
trabalhar para melhorar o sistema; distorcer o sistema ou distorcer os dados.
56
Por isto, Wheeler (2001, p. 21-22) afirma que, antes de melhorar qualquer
sistema, deve-se “ouvir a voz do processo”, ou seja, entender como as entradas afetam
as saídas do sistema, para ser capaz de alterar as entradas de forma que alcance os
resultados desejados (metas). E destaca que, simplesmente comparar os números com as
especificações (voz do cliente) não levará a melhoria do processo, pois não fornece
qualquer compreensão sobre como o processo funciona. Para obter conhecimento sobre
a capacidade e estabilidade do processo, o autor sugere a abordagem de Shewhart.
2.2. Controle e Melhoria de Processos
Shewhart (1926, p. 593) parte do princípio que, independentemente do cuidado tomado
na definição do processo de produção, o fabricante percebe que não pode fazer todas as
unidades de um determinado tipo de produto idêntico, pois flutuações randômicas
diversas, em relação ao ambiente produtivo e condições psicológicas e fisiológicas dos
indivíduos que executam o processo, originam variações incontroláveis. Isto equivale
assumir a existência de causas não associadas de variação na qualidade do produto.
Na Engenharia de Software, Fuggetta (2000) também destaca que processos de
software são atividades centradas em humanos e, como tal, são propensas a
desempenhos e comportamentos inesperados ou indesejados. Além disto, a variação
pode ser potencializada pelo fato de que cada produto desenvolvido advém de requisitos
peculiares, intrínsecos, ou seja, heterogêneos.
Diante dos inúmeros desafios inerentes ao desenvolvimento de software, normas
internacionais e modelos de referência que apoiam a implantação de programas de
melhoria de processos, como ISO/IEC 12207, ISO/IEC 15504, CMMI-DEV®
(Capability Maturity Model Integration for Development) e MR-MPS (Modelo de
Referência de Melhoria do Processo de Software Brasileiro) (Softex, 2012) foram
propostos. Alguns pressupõem que as organizações definam medidas, a partir de seus
objetivos organizacionais, coletem e analisem os dados de forma que conheçam o
comportamento dos processos, e façam previsões sobre seu desempenho, ou apoiem a
tomada de decisão. Entretanto, não determinam como fazê-lo, permitindo que as
organizações adotem métodos e medidas adequadas a sua realidade.
Dentre os métodos e medidas destacam-se o PSM (Practical Software
Measurement), proposto por Mcgarry et al. (2002), que consiste em um modelo de
informação para medição e um modelo de processo de medição, fundamentados em
conceitos mensuráveis. Em consonância, Putnam e Myers (2003) propõem cinco
medidas essenciais quando consideram que pessoas, trabalhando em algum nível de
(produtividade), produzem uma quantidade de funções (tamanho) ou um produto de
trabalho com algum nível de confiabilidade (qualidade), despendendo (esforço) em um
intervalo de (tempo). Já Basili et al. (2007) propõem GQM+Strategies para ajudar a
justificar os esforços da medição de software e contribuir em decisões de alto nível,
através do GQM (Goal Question Metric), que fornece suporte quantitativo pela
decomposição de metas de medição em questões e métricas.
Quanto às formas de analisar os dados coletados, Florac, Carleton e Barnard
(2000, p. 97-99) destacam o gráfico de controle (ou Shewhart chart), que mostra o
desempenho do processo sobre o tempo e provê uma definição operacional de
estabilidade e capacidade, através de limites de controle (UCL e LCL) definidos como
3σ (onde σ é o desvio padrão) em torno da média de um conjunto de valores coletados,
57
sobre determinado atributo do processo (Jalote e Saxena, 2002). Estes limites visam
minimizar a perda total devido a processos fora de controle e alarmes falsos, sendo
denominados limites naturais do processo ou a 'voz do processo', expressando a
tendência central do processo, e são calculados conforme tipo de gráfico de controle, o
que depende da natureza dos dados (contínuos ou discretos).
10
UCL
5
Média
Período de tempo
nov
out
s et
ago
jul
jun
m ai
abr
m ar
fev
0
jan
Valores Individuais
Considerando um processo estável, é possível definir um intervalo de valores
para determinada meta associada (entre UCL e LCL), pois este intervalo representa a
capacidade do processo, fundamentados em dados históricos e não em um valor
arbitrário. Também é possível verificar o desempenho do processo em relação à meta
estipulada. Um exemplo é ilustrado no Gráfico 1.
LCL
Gráfico 1. Exemplo de gráfico de controle para valores individuais.
Para isto, é preciso implementar um programa de medição que abrange
mecanismos para coleta, validação, armazenamento e análise dos dados, bem como
comunicação dos resultados, execução e gerenciamento do programa de medição,
visando averiguar o alcance das metas e, consequentemente, promover melhorias.
Ressalta-se que o monitoramento das metas estratégicas requer agregação dos resultados
nos diversos níveis, considerando as relações entre metas e variedade dos atributos.
2.3. Representação de Negócios
De acordo com Chiavenato (1998, p. 660- 662), o desenho organizacional, que significa
o arranjo e o processo de arranjar as características estruturais da organização para
atingir ou aumentar a eficiência e eficácia organizacional, passou a ter mais relevância a
partir da Teoria da Contingência, que se baseia no conceito de não existir uma única
maneira melhor de organizar, pois as organizações precisam adaptar-se às condições do
ambiente em constante transformação, dado um enfoque sistêmico sobre a organização.
E, Azevedo e Campos (2004, p. 156) apresentam algumas perspectivas para
representação de negócios: (a) visão de negócio (business vision), modela conceitos e
objetivos de acordo com as estratégias do negócio; (b) processo de negócio (business
process) modela os processos e seus relacionamentos com os recursos a serem usados
para atingir os objetivos, ou seja, atividades, eventos, papéis, artefatos, regras e fluxos,
relacionados às metas, bem como aos problemas (ameaças) para alcançá-las e às
sugestões de solução; (c) estrutura de negócio (business structure) modela a estrutura
dos recursos (físicos ou abstratos), incluindo suas hierarquias e influências, nos diversos
níveis organizacionais; e (d) comportamento do negócio (business behavior), modela o
comportamento, a interação entre recursos e entre processos, o que pode incluir os
impactos das variações ou problemas sobre o processo e alcance das metas.
Há inúmeras linguagens e ferramentas para representar tais perspectivas,
especialmente para processos, de forma a apoiar sua execução, simulação, otimização
ou automatização; das quais algumas assumem o provérbio popular: “uma imagem fala
58
mais que mil palavras”. Além disto, Yu (1995) destacou que, geralmente, executores do
processo precisam de modelos que detalham os “como”, enquanto gestores de processos
preferem modelos que destacam os “o que”, e os engenheiros de processo, encarregados
de melhorá-los e redesenhá-los, precisam de modelos que explicitam os “porquês”.
Neste caso, o framework i* (Yu, 1995) pode ser utilizado para descrever um
processo de software em mais detalhes, em termos de elementos de processo e como
eles se relacionam entre si, por meio de decomposição tarefas, e relações causas e
efeitos. Já a UML permite a modelagem de negócio pela disponibilidade de mecanismos
para extensão como em Eriksson e Penker (2000). Também, BPMN é um padrão
internacional para modelagem de processos de negócio, cujos modelos podem ser
mapeados para padrões que permitem a execução como WSBPEL (Web Services
Business Process Execution Language) ou XPDL (XML Process Definition Language).
Entretanto, BPMN não abrange a modelagem de estratégia (OMG, 2011), não dispondo
de mecanismos formais para representar as metas dos processos e suas influências.
Em termos de planejamento e controle, Barreto (2011) propôs um método para
planejamento estratégico, tático e operacional em organizações de software; uma
infraestrutura para monitorar os objetivos (metas) e uma estratégia para recomendação
de ações corretivas, para tratar os desvios detectados. Apesar do método proposto não
ter sido integralmente utilizado por organizações de software, este trabalho pode
evidenciar algumas características do alinhamento do processo de software às metas
estratégicas, mas não trata da representação gráfica de tais aspectos.
Enquanto, Gonçalves et al (2012) apresentou um processo padrão e uma
ferramenta de apoio ao controle estatístico do processo de software integrada ao
WebAPSEE, visando a coesão entre os processos críticos e indicadores estatísticos com
os objetivos da organização e de medição; propagação dinâmica das mudanças nos
objetivos; e integração dos planos de ação a um ambiente de desenvolvimento de
software. Entretanto, sugeriu como atividade futura, adicionar funcionalidades para
verificação da capacidade do processo e definição dos modelos de desempenho. E,
apesar de dispor da WebAPSEE-PML, uma linguagem gráfica usada para modelar
processos (Lima et al, 2006), a proposta não tratou a representação através dela.
Quanto à representação gráfica, Yu (1995) propôs um framework de modelagem
denominado i*, cujos modelos representam os conceitos de capacidade, produtividade,
viabilidade e credibilidade, para apoiar a engenharia de requisitos de software,
reengenharia de processos de negócios, análise de impactos organizacionais e
modelagem de processo. A partir deste, Horkoff et al (2014) propuseram o Business
Intelligence Model (BIM), que incluiu conceitos como metas, estratégias, processos,
situações, influências, e indicadores, apoiados por ferramentas computacionais. Os
autores pretendem incorporar o BSC (Balanced ScoreCard), mapa estratégico e
relacionar os indicadores às bases de dados organizacionais.
Também, Eriksson e Penker (2000) apresentaram uma extensão da UML com
mecanismos para representação de processos e seus elementos, mas como o modelo de
negócio é mais amplo e complexo, a extensão pressupõe sua decomposição em visões
(business vision, business process, business structure e business behavior), de forma
que cada uma mostra informações sobre um ou mais aspectos específicos do negócio,
59
inclusive os desdobramentos das metas organizacionais, através de diversos diagramas,
o que dificulta a visualização, integração e atualização.
Já Braubach et al (2010) apresenta o projeto de pesquisa Go4Flex, cujo objetivo
é integrar perspectivas de especialistas de negócio à perspectiva técnica, estabelecendo
conceitos de modelagem de alto nível para o workflow, o que resulta em aumento da
inteligibilidade das descrições para os envolvidos, a partir de modelos teóricos como
BDI (Beliefs, Desires and Intentions) agents e implementações de agentes para facilitar
o tratamento de processos altamente complexos e adaptativos. Complementando este
projeto, Jander et al (2011) propõem uma abordagem baseada na noção de metas de
processo, Goal-Oriented BPMN (GO-BPMN), que representa metas como feature
functional do próprio workflow, empregando o conceito de metas abstratas para
descrever as condições alvo, em vez de defini-las implicitamente com as atividades.
Ressalta-se que propostas como Horkoff et al (2014) e Korherr e List (2007)
para o alinhamento ou representação de metas, estratégias e processos, são apresentadas
da perspectiva da Engenharia de Requisitos, ou seja, visando especificar requisitos
funcionais e não funcionais ou de medição para o software que produzirão. Entretanto,
sugere-se a inclusão da perspectiva da própria fábrica de software, conforme ilustrado
por Yu (1995) e Basili et. al. (2007), pois entende-se que tais perspectivas são
complementares e interdependentes. Afinal, uma das metas da fábrica de software é
satisfazer seus clientes fornecendo software que os ajuda a alcançar suas próprias metas.
Ao desenvolver a abordagem para responder a questão apresentada, é preciso considerar
fundamentação teórica e impactos práticos.
A fundamentação teórica pode ser obtida através de revisão ad hoc da literatura,
a fim de identificar publicações relacionadas e ajudar a direcionar a revisão sistemática
que requer definição de um protocolo como sugerido por Kitchenham (2007). Estas
revisões precisam ser executadas de forma que evidencie o estado da arte sobre as
linguagens para modelagem de negócios; favoreça o estabelecimento de requisitos e
critérios para avaliar tais linguagens, em termos de representação das perspectivas:
business vision, business process, business structure e business behavior, que abrangem
decomposição e agregação das metas, desde as intenções estratégicas aos indicadores de
capacidade e desempenho do processo de desenvolvimento de software.
Alguns impactos práticos podem ser favorecidos pela implementação de
software que apoie a modelagem integrada à coleta e análise dos dados sobre a
simulação ou execução de processos de desenvolvimento de software. Isto pode ser
através de plugins para o Redmine, uma ferramenta de código aberto que apoia o
planejamento e execução de projetos. Outros, identificados ao usar tal ferramenta para
modelar e simular determinado processo. E, ao obter a opinião de potenciais usuários
em relação aos requisitos, critérios e à abordagem proposta, através de surveys.
De forma preliminar, foi executada a revisão ad hoc da literatura e modelado um
processo de desenvolvimento de software, de uma pequena organização desenvolvedora
de software, usando BPMN, a fim de identificar oportunidades e ameaças, e favorecer a
substituição de um ambiente utilizado para controle de tarefas pelo Redmine, com
pretensão de usá-lo para apoiar a validação da proposta. Atualmente, os esforços
concentram-se na elaboração do protocolo de revisão sistemática e revisão do modelo.
60
A partir da execução da revisão sistemática, serão identificadas linguagens de
modelagem, cujas serão avaliadas em relação aos requisitos e critérios estabelecidos,
visando selecionar, adaptar ou propor notação adequada. Oportunamente, surveys serão
planejados e executados visando obter opiniões dos usuários.
Dentre os resultados esperados, destacam-se a abordagem para representar as
perspectivas do desenvolvimento de software integrada ao conhecimento sobre a
capacidade e desempenho do processo, incluindo notação e software. Além da definição
de requisitos e critérios, para avaliar linguagens de modelagem capazes de representar as
perspectivas citadas. Assim, espera-se facilitar a obtenção e disseminação do
conhecimento sobre a capacidade e dinâmica do processo de desenvolvimento de
software, promovendo a maturidade e competitividade do negócio.
Agradecimentos
Os autores agradecem à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior
(CAPES) e ao Instituto Federal de Educação, Ciência e Tecnologia Fluminense (IFF)
pelo apoio ao desenvolvimento desta pesquisa.
Referências
Azevedo, D. P. and Campos, R. (2004) “Aplicação de uma Arquitetura de Modelagem
de Processos de Negócios no Desenvolvimento de Software”, Vértices, v.6, n.3, pp.
147-175.
Barreto, A. O. S. (2011) “Definição e Gerência de Objetivos de Software Alinhados ao
Planejamento Estratégico”. Tese (Doutorado em Engenharia de Sistemas e
Computação) COPPE, Universidade Federal do Rio de Janeiro. Brasil.
Basili, et al. (2007) “Bridging the gap between business strategy and software
development”. In: ICIS 2007 Proceedings, p. 25.
Bicudo, M. A. V. A (1999) “Contribuição da fenomenologia à educação”.
Fenomenologia, uma visão abrangente da educação. São Paulo: Olho d'água.
Booch, G., Rumbaugh, J. and Jacobson, I. (2000) “UML: guia do usuário”. Tradução da
segunda edição. Elsevier Brasil.
Braubach, L. Pokahr, A. Jander, K. Lamersdorf, W. and Burmeister, B. (2010)
“Go4Flex: Goal-oriented Process Modelling”. In: 4th International Symposium on
Intelligent Distributed Computing (IDC-2010), p. 77-87, Springer Berlin Heidelberg.
Chiavenato I. (1998) “Teoria Geral da Administração”. v. 2, 5. ed. São Paulo: Makron
Books.
Eriksson, H. and Penker M.(2000) “Business Modeling with UML: Business Patterns at
Work”. United States: Wiley & Sons.
Florac, W. A., Carleton, A. D. and Barnard, J. R. (2000) “Statistical process control:
analyzing space shuttle onboard software process”. Software, IEEE, v.17, n.4, p.97106.
Fuggetta, A. (2000) “Software process: a roadmap”. In: Proceedings of the Conference
on The Future of Software Engineering, pp. 25-34, Limerick, Ireland.
61
Gonçalves, L., Lima, L., Reis, R.Q., Nascimento, L. and Ribeiro, T. (2012) “Support for
Statistic Process Control of software process”. In: XXXVIII Conferencia
Latinoamericana en Informatica (CLEI), p.1-10, 1-5 Oct.
Hammer, M. and Champy, J. (1994) “Reengineering the Corporation: a manifesto for
Business Revolution”, Nicholas Brealey Publishing, London.
Horkoff, J., Barone, D., Jiang, L., Yu, E., Amyot, D., Borgida, A. and Mylopoulos, J.
(2014) “Strategic Business Modeling: Representation and Reasoning”. Software &
Systems Modeling 13, n. 3, jul., p. 1015–41.
Jalote, P. and Saxena, A. (2002) “Optimum control limits for employing statistical
process control in software process”. Software Engineering, IEEE Transactions on,
v. 28, n. 12 , p. 1126–34.
Jander, K., Braubach, L., Pokahr, A., Lamersdorf, W. and Wack, K. (2011) “GoalOriented Processes with GPMN”. International Journal on Artificial Intelligence
Tools, v. 20, n. 06, p. 1021–1041, dez.
Kitchenham, B. (2007) “Guidelines for performing Systematic Literature Reviews in
Software Engineering”. Keele and Durham University Joint Report. EBSE 2007-001.
Korherr, B. and List, B. (2007) “Extending the EPC and the BPMN with Business
Process Goals and Performance Measures”. In: Proceedings of the 9th International
Conference on Enterprise Information Systems (ICEIS), Funchal, p. 287–294.
Kueng, P. and Kawalek, P. (1997) “Goal-based business process models: creation and
evaluation”. Business Process Management Journal, v. 3, n. 1, p. 17-38.
Lima, A., França, B, Schlebbe, H., Silva, M., Reis, R. Q. and Reis, C. L. (2006)
“WebAPSEE: Um Ambiente Livre e Flexível Para Gerência de Processos de
Software”. In: VII Workshop de Software Livre. Porto Alegre: Abril.
Loucopoulos, P. and Karakostas, V. (1995) “System requirements engineering”.
McGraw-Hill Inc.
Mcgarry, J., Card, D., Jones, C., Layman, B., Clark, E., Dean, J. and Hall, F. (2002)
“Practical Software Measurement: objective information for decision makers”.
Addison-Wesley.
OMG, Object Management Group. (2011) “Business Process Model and Notation
(BPMN)”. Version 2.0. Disponível em:<http://www.omg.org/spec/BPMN/2.0/>.
Acessado em 20 de julho de 2013.
Putnam, L. and Myers, W. (2003) “Five Core Metrics”. Dorset House Publishing.
Shewhart, W.A. (1926) “Quality Control Charts”. Bell System Technical Journal, v. 5,
n. 4, p. 593-603.
Softex. (2012) “MPS.BR: Guia Geral MPS de Software”. Disponível em:
<http://www.softex.br/mpsbr/guias/>. Acessado em 10 de Agosto de 2013.
Wheeler, D. J. (2001) “Entendendo a variação: a chave para administrar o caos”.
Tradução: Maria Cristina da Costa Muller. Rio de Janeiro: Qualitymark ed. 152 p.
Yu, E. (1995) “Modelling Strategic Relationships for Process Reengineering”. Ph.D.
Thesis. Dept. of Computer Science, University of Toronto. Canada.
62
Formação de Equipes de Alto Desempenho para
Desenvolvimento de Software
Alessandra C. S. Dutra, Rafael Prikladnicki
1
Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS)
Av. Ipiranga, 6681 – 90619-900 – Porto Alegre – RS – Brazil
{alessandra.dutra,rafaelp}@pucrs.br
Resumo. O mercado de desenvolvimento de software evolui a cada dia, e a
indústria de software tem se tornado uma das áreas mais competitivas
atualmente. Os requisitos para esta competitividade são diversos, e
dificilmente eles serão alcançados sem uma equipe orientada ao alto
desempenho, de grande domínio técnico, comportamental e de negócio. Os
cursos de capacitação em Engenharia de Software não estão alinhados com a
necessidade de formar equipes de alto desempenho em desenvolvimento de
software. Por essa razão, o objetivo dessa pesquisa é propor uma abordagem
metodológica de capacitação, visando formar equipes de alto desempenho
para o desenvolvimento de software, suprindo esta necessidade.
O mercado de desenvolvimento de software opera em um ambiente global, com
mudanças rápidas, e é necessário responder com agilidade a estas mudanças e a estes
novos mercados [Sommerville 2011]. Conseguir agilidade, competitividade e resultados
sem uma equipe de desenvolvimento de software capacitada e de alto desempenho é
uma tarefa difícil e pode trazer resultados pouco competitivos.
Esse contexto indica que a formação qualificada e a capacitação de profissionais
são cada vez mais necessárias na sociedade em que vivemos. Seja em cursos de curta
duração, graduação ou pós-graduação, formar bons profissionais faz parte do
compromisso das Instituições de Ensino Superior (IES) com a sociedade [Enricone
2002].
A qualidade da capacitação em ES pode contribuir significativamente à melhoria
do estado da arte do desenvolvimento de software e auxiliar a solução de alguns
problemas tradicionais e crises relacionadas com às práticas da indústria de software
[Gibbs 1994]. Hoje, a capacitação e o treinamento para formar profissionais de software
devem incluir não apenas conhecimentos básicos na área de computação, mas também o
ensino de conceitos, processos e técnicas para definição, desenvolvimento e
manutenção de software [Saiedian 1999] [ACM/IEEE 2008].
Nesse sentido, o processo de ensino e aprendizagem de Engenharia de Software
têm passado por questionamentos acerca dos métodos utilizados nas atividades de
capacitação [Santos et al. 2008]. Estudos demonstram que esses métodos envolvem
estratégias tradicionais de ensino, tais como apresentação de teoria, aulas expositivas e
leituras complementares, fazendo com que os alunos encontrem, na indústria, um
cenário diferente do que é ensinado na academia [Santos et al. 2008] [Prikladnicki et al.
63
2009]. Ao mesmo tempo, o desenvolvimento de software tem exigido a formação de
equipes de alto desempenho, de grande domínio técnico, comportamental e de negócio
[Nearshore 2012] [Roda 2011], uma necessidade que as atuais formações não
conseguem suprir. Uma das razões é o fato de se concentrarem na formação básica com
ênfase na abordagem tradicional do desenvolvimento de software, não preparando o
profissional para atuar como integrante de uma equipe de desenvolvimento de software,
que demanda competências multifuncionais e ambientes multidisciplinares. Dessa
forma, faz-se necessário saber quais os resultados de investigações científicas em
relação às características da formação de equipes de alto desempenho em
desenvolvimento de software e quais as atuais abordagens de capacitação existentes e
que, de alguma forma, exploram algumas destas características.
O objetivo geral deste trabalho é propor uma abordagem metodológica de
capacitação visando formar equipes de alto desempenho para o desenvolvimento de
software. Para alcançar o objetivo geral proposto, apresentam-se os seguintes objetivos
específicos:
• Identificar os estudos da base teórica sobre as características das equipes de
alto desempenho para desenvolvimento de software, através da realização de um estudo
secundário (uma revisão sistemática de literatura);
• Descrever e caracterizar as abordagens de capacitação existentes na formação
de equipes em Engenharia de Software;
• Propor e avaliar uma abordagem metodológica, focada na capacitação de
equipes de alto desempenho para desenvolvimento de software, avaliando a viabilidade,
benefícios e riscos da sua implementação;
• Analisar, documentar e reportar os resultados da pesquisa, incluindo todos os
passos do estudo, visando apresentá-los à comunidade científica.
Este artigo está dividido em 6 seções. Na seção 2, apresentamos a
fundamentação teórica; na seção 3, o método de pesquisa. Seção 4 mostramos o estado
atual do trabalho. Na seção 5, os trabalhos relacionados e para finalizar; na seção 6, os
resultados esperados.
2.1. Capacitação em Engenharia de Software
A Engenharia de Software é uma disciplina preocupada com a aplicação de teoria,
conhecimento e prática para o desenvolvimento efetivo e eficiente de sistemas de
software que satisfaçam os requisitos dos usuários [ACM/IEEE 2008]. A ES está
relacionada com todos os aspectos da produção de software, desde os estágios iniciais
até a sua manutenção, envolvendo não apenas os processos técnicos do
desenvolvimento, como também as atividades de gerenciamento de projeto e a
utilização de ferramentas, métodos e teorias que apoiem a sua produção [Sommerville
2011]. Portanto, a ES vai muito além da criação de códigos de programas: procura
disciplinar o desenvolvimento e traz para a criação de software princípios, técnicas e
conhecimento para tratar de questões de qualidade, prazos e fatores econômicos
[ACM/IEEE 2004].
64
O currículo na área de ES [ACM/IEEE 2004][ACM/IEEE 2008] aponta a
necessidade de ensino para além do formato de aula expositiva, e uma das formas de
aumentar a qualidade do ensino é aperfeiçoar os processos de ensino e aprendizagem,
através de didáticas e estratégias inovadoras. Conforme Beckman [1997], a qualidade da
educação é um dos fatores importantes que influencia na qualidade dos profissionais.
Os profissionais de ES [Conn 2002] estão insatisfeitos com a falta de preparo dos
estudantes universitários que ingressam no mercado de trabalho, o que leva a indústria a
ter que complementar a sua educação com treinamentos. Esse preparo pode envolver
profissionais ou equipes, incluindo equipes de alto desempenho.
2.2. Equipes de Alto Desempenho
Uma equipe de alto desempenho [Moscovici 2003], tem seus membros comprometidos
com o crescimento e o sucesso pessoal de cada um dos membros da equipe. Essa equipe
supera o desempenho de todas as outras, além de conseguir resultados que superam as
expectativas.
Katzenbach e Smith [1994] apresentam algumas características das equipes de
alto desempenho: “profundos compromissos pessoais de cada um para com o
crescimento e o sucesso dos outros é o que distingue as equipes de alta performance da
maioria das equipes existentes. Energizados por esse senso extra de compromisso, as
equipes de alta performance tipicamente refletem vigorosas ampliações das
características fundamentais das equipes: senso mais profundo de propósito, metas mais
ambiciosas de performance, abordagens mais completas, maior plenitude de
responsabilidade mútua, intercambiabilidade e complementaridade de conhecimentos”.
Boyett e Boyett [1999] citam algumas empresas que obtiveram grandes
resultados com equipes de alto desempenho, tais como a AT&T Credit Corporation, que
usou equipes interfuncionais de alto desempenho para melhorar a eficiência e o serviço
ao cliente. Conforme Raj [Raj et al. 2006], observa-se uma grande dificuldade nas
organizações para a disseminação das práticas das equipes de alto desempenho, como
reorganização do trabalho, envolvimento dos professionais nos processos decisórios e
melhoria das habilidades dos trabalhadores, apesar dos indícios de que as organizações
investem nessas práticas obtendo maior produtividade e eficiência.
3. Método de Pesquisa
3.1. Desenho e Etapas da Pesquisa
Para o desenvolvimento desta pesquisa, será utilizada, como base, a metodologia
proposta por Mafra [Mafra et al 2006], cujo desenho de pesquisa está representado na
Figura 1. Cada uma das etapas desta metodologia é detalhada a seguir [Mafra et al.
2006], [Shull et al. 2001]:
• Estudos Secundários: essa etapa consiste na condução de estudos secundários,
tais como revisão sistemática da literatura, que tem como objetivo buscar evidências
primárias na área em estudo.
• Proposta Inicial: essa etapa consiste na produção, com base no conhecimento
adquirido e nas evidências identificadas através da condução da revisão sistemática, de
uma proposta inicial da tecnologia.
65
• Estudo de Viabilidade: essa etapa verifica, através de estudos empíricos e
experimentais, a viabilidade do processo ou tecnologia sendo analisada. Pesquisas
utilizando estudantes são aplicáveis nessa etapa.
• Estudo de Observação: essa etapa avalia todos os passos, em detalhes, que
constituem o processo de aplicação da nova tecnologia, de forma a garantir que cada
passo seja efetivo e seja executado na ordem correta.
• Estudo de Caso com Ciclo de Vida Real: essa etapa consiste em um caso de
estudo avaliando o processo ou tecnologia em um ciclo de vida real de desenvolvimento
de software.
• Estudo de Caso na Indústria: uma vez que nas etapas anteriores o processo já
foi adaptado para ser executado em um ciclo de vida real e demonstrou ser eficaz, nessa
fase o processo ou tecnologia é avaliado em um ambiente de indústria.
Figura 1 - Metodologia Experimental – [Mafra et al. 2006]
Os seguintes passos estão planejados:
• Proposta inicial e Estudo de viabilidade: planejar e executar uma pesquisa de
campo, através de entrevistas com Gerentes de Projetos, tendo em vista dois objetivos
principais: (1) avaliar o conhecimento destes profissionais em relação as características
das equipes de alto desempenho em desenvolvimento de software e conhecer as práticas
e as abordagens de capacitação utilizadas para formar as equipes em Engenharia de
Software; (2) desenvolver uma proposta focada na capacitação de equipes de alto
desempenho para desenvolvimento de software;
• Estudo de observação: a partir do estudo de viabilidade o método será refinado,
e um estudo de observação será planejado em ambiente acadêmico a ser definido;
66
• Estudo de Caso com Ciclo de Vida Real: a partir do estudo de observação, será
feito um estudo de caso gerando, então, a versão estável do método para ser transferida
para a indústria;
• Estudo de caso na Indústria: a partir do estudo de caso com ciclo de vida real,
será feito um estudo de caso a ser executado dentro do ambiente da indústria.
Estes passos estão planejados; na próxima seção, segue o estado atual do trabalho.
4. Estado Atual do Trabalho
4.1. Estudos Secundários
Como resultados preliminares, foi executada uma Revisão Sistemática da Literatura em
que identificamos algumas características que as equipes de alto desempenho devem ter
no desenvolvimento de software. Identificamos características organizacionais,
comportamentais e técnicas. As mais citadas foram comunicação eficiente,
coordenação, trabalho em equipe, diversidade da equipe, liderança, coesão e motivação.
Podemos sugerir que as equipes de alto desempenho (1) possuem uma comunicação
eficaz, (2) apresentam uma diversidade que estimula a aprendizagem e a inovação, (3)
possuem coesão, motivação, liderança e coordenação, a fim de alcançar seus objetivos.
Esses resultados geraram uma visão inicial das características esperadas para
uma equipe de alto desempenho. Essas equipes precisam ser capacitadas e desenvolver
seus pontos fortes, visando proporcionar um conjunto de competências que somente
estas equipes apresentam. Neste caso, a capacitação é, portanto, um aspecto essencial
para o desenvolvimento dessas equipes.
Os resultados dos estudos secundários geraram dois artigos que foram
publicados em dois congressos internacionais. O artigo: “What Are the Main
Characteristics of High Performance Teams for Software Development?” [Dutra et al.
2015], foi publicado no ICEIS - 17th International Conference on Enterprise
Information System, que ocorreu em Barcelona, Espanha entre os dias 27 e 30 de abril, e
o segundo artigo: “What do we know about high performance teams in software
engineering? Results from a systematic literature review”, foi aceito no SEAA Euromicro Conference series on Software Engineering and Advanced Applications, que
será realizado em Portugal entre os dias 26 e 28 de agosto de 2015.
4.2. Proposta Inicial e Estudo de Viabilidade
Esta pesquisa tem como passo seguinte o planejamento da proposta inicial e a execução
de um estudo de viabilidade. Este estudo terá como objetivo aprofundar a análise nas
características das equipes de alto desempenho, identificando suas práticas, bem como
as abordagens de capacitação utilizadas pelas empresas para aprimorar essas práticas em
seus projetos de desenvolvimento de software.
A pesquisa será exploratória, qualitativa e executada através de uma survey. As
pessoas entrevistadas serão: gerentes de projetos, líderes de projetos e coordenadores de
projetos. A coleta de dados será feita através de entrevistas semi-estruturadas, com
questões abertas e fechadas. A aplicação do questionário será com entrevistas pessoais.
A análise de dados será feita através de uma apresentação das contribuições do
estudo e uma análise crítica com relação a esses resultados. Nesta análise, será
67
desenvolvida uma confrontação dos resultados obtidos com as teorias e com os estudos
relacionados, e será realizada uma análise qualitativa dos dados coletados, através de
um mapeamento das respostas dos entrevistados.
A partir do levantamento das características mais citadas, das práticas e das
abordagens utilizadas, será desenvolvida uma proposta de capacitação focada nas
características das equipes de alto desempenho para desenvolvimento de software.
Atualmente, encontram-se disponíveis na literatura da área alguns estudos que propõem
modelos de referência para a capacitação e para a formação de equipes de alto
desempenho. Dentre as abordagens existentes, temos: Tuckman e Jensen [1977],
Katzenbach e Smith [1994], Wellins [1994] e Boyett e Boyett [1999].
Tuckman e Jensen [1977] apresentam cinco fases de desenvolvimento de equipes, que
estão representados na Figura 2. A definição desses estágios foi fruto de uma extensa
revisão de literatura, em que o autor analisou diversos artigos científicos da época que
tratavam da formação de grupos e sintetizou as conclusões de cada autor analisado em
cinco fases gerais dentro do processo de formação de um grupo [Tuckman e Jensen
1977], [Tuckman 1965].
Figura 2 - Fases de Desenvolvimento de Grupos [Tuckman e Jensen 1977]
Nesse modelo, os grupos possuem, de forma geral, comportamentos
padronizados, que passam por cinco etapas: Formação, Confusão/Conflito,
Normatização, Desempenho e Desintegração.
Uma equipe de alto desempenho se move através das fases de formação,
confusão, normatização, desempenho e desintegração, assim como com outras equipes
de desenvolvimento. Porém, as equipes de alto desempenho utilizam a fase de confusão
e normatização de forma eficaz para definir quem são, qual o seu objetivo, como
interagir entre si e resolver conflitos. Assim, quando a equipe alcança a fase de
desempenho, eles têm comportamentos altamente eficazes que lhes permitem gerar
melhores resultados em comparação com outras equipes.
Para que uma equipe alcance o alto desempenho, é necessário passar por
algumas fases de crescimento. Katzenbach e Smith [1994] apresentam, na Figura 3,
essas fases de crescimento com a curva de desempenho da equipe. Os grupos e ou
68
equipes são classificados em cinco tipos, de acordo com seu modo de funcionamento:
Grupo de Trabalho, Pseudo-equipe, Equipe Potencial, Equipe Real e Equipe de Alto
Desempenho. Na figura 3, são apresentados, através da curva de performance, os
estágios de desempenho dos grupos.
Figura 3 - Curva de Performance da Equipe [Katzenbach e Smith 1994]
A diferença entre os trabalhos relacionados e o trabalho proposto é que os trabalhos
relacionados focam na formação da equipe em si e não na sua capacitação, que é o
objetivo deste trabalho.
Em termos de contribuições práticas, este trabalho visa a auxiliar empresas e
universidades que atuam ou ensinam desenvolvimento de software, fornecendo uma
abordagem com as quais elas possam capacitar suas equipes, tornando-as mais
produtivas e de alto desempenho, com foco em capacitação e não somente em formação
de equipe.
Como resultados esperados, pretendemos desenvolver uma abordagem metodológica de
capacitação, visando formar equipes de alto desempenho para o desenvolvimento de
software, que poderá ser aplicada tanto na academia, como na indústria, focado nas
características dos times de alto desempenho.
Referências Bibliográficas
ACM/IEEE. (2008) Computer Science Curriculum, Guidelines for Undergraduate
Degree Programs in Software Engineering.
ACM/IEEE. (2004) Software Engineering Curriculum. Guidelines for Undergraduate
Degree Programs in Software Engineering.
Beckman, K., Coulter, N., Khajenouri, S., Mead, N. (1997) “Collaborations: Closing the
industry–academia gap”. IEEE Software 14 (6), pp. 49–57.
69
Boyett, J.H; Boyett, J.T. (1999) “O guia dos gurus: os melhores conceitos e práticas de
negócios. Rio de Janeiro: Campus.
Conn, R. (2002) “Developing Software Engineers at the C-130J Software Factory”.
IEEE Software,Los Alamitos, v. 19, n. 5, p. 25-29.
Dutra, A. C. S.; Prikladnicki, R.; Conte, T. U. (2015) “What Are the Main
Characteristics of High Performance Teams for Software Development?”. 17th
International Conference on Enterprise Information Systems (ICEIS).
Enricone, D. (2002) “Ser Professor”, 3a edição, EDIPUCRS.
Gibbs, W. (1994) “Software's chronic crisis”. Scientific American 2713, pp. 86–95.
Katzenbach, J. R; Smith D. K. (1994) “A Força e o Poder das Equipes”. São Paulo:
Makron Books do Brasil Editora Ltda.
Mafra, S., Barcelos, R., Travassos, G. H. (2006) “Aplicando uma Metodologia Baseada
em Evidência na Definição de Novas Tecnologias de Software”. Proceedings of the
20th Brazilian Symposium on Software Engineering (SBES 2006), v. 1, pp. 239 –
254, Florianopolis.
Moscovici, F. (2003) “Equipes dão certo: A multiplicação do Talento Humano”. Rio de
Janeiro: José Olympio, 8a edição.
Nearshore Americas. (2012) “Collaborate. Innovate. Accelerate. Creating successful
software requires a new model of development and a new kind of development
team”. Disponível online, acesso em Abril de 2012.
Prikladnicki, R., Albuquerque, A., Wangenheim C., Cabral R., (2009) “Ensino de
Engenharia de Software: Desafios, Estratégias de Ensino e Lições Aprendidas,” no
FEES.
Raj, P.P ; Baumotte A.C.T; Fonseca D.P.D; Silva, L.H.C.M. (2006) “Gerenciamento de
pessoas em projetos”. Rio de Janeiro : Editora FGV – Fundação Getúlio Vargas,
180p.
Roda, R. (2011) “Self-Organizing Agile Teams: A Grounded Theory”, Tese de
Doutorado, Victoria University of Wellington.
Saiedian, H. (1999) “Software engineering education and training for the next
millennium, Journal of Systems and Software”, v. 49, i. 2-3, p. 113-115
Santos, R. P., Santos, P. S. M., Werner, C. M. L., Travassos, G. H. (2008) “Utilizando
Experimentação para Apoiar a Pesquisa em Educação em Engenharia de Software no
Brasil”, Fórum de Educação em Engenharia de Software.
Shull, F.; Carver, J.; Travassos, G. H. (2001) “An empirical methodology for
introducing software processes”. SIGSOFT Softw. Eng. Notes, 26(5):288–296.
Sommerville, I. (2011) “Engenharia de Software” 9a edição. São Paulo: Pearson
Prentice Hall.
Tuckman, B.; Jensen, M. (1977) “Stages of small-group development revisited. Group
and Organization Studies”. v. 2, n. 4, p. 419.
Tuckman, B. (1965) “Developmental sequence in small groups. Psychological bulletin”
v. 63, n. 6, p. 384–399.
70
Fatores Técnicos, Humanos e Organizacionais:
Qual Fator Prepondera na Produtividade do Programador de
Organizações de Software?
Edson Oliveira1, Marco Cristo1, Tayana Conte1
1
USES – Grupo de Pesquisa em Usabilidade e Engenharia de Software – Universidade
Federal do Amazonas (UFAM) – Manaus – AM – Brasil
{edson.cesar,marco.cristo,tayana}@icomp.ufam.edu.br
Abstract. Software organizations should invest in improving their
programmers to remain efficient and competitive. However, the establishment
of effective improvement practices must be based on the preponderant factors
that in fact have influence on the programmer’s productivity. Several works in
the literature have identified different factors that influence the programmer’s
productivity. This work aims to analyze technical, human and organizational
factors, and their influence on the productivity variation of programmers,
measured from data obtained in organization's software repositories.
Resumo. As organizações de software devem investir no aprimoramento de
seus programadores para se manterem eficientes e competitivas. Porém, a
criação de práticas de aprimoramento eficazes deve fundamentar-se nos
fatores preponderantes que exerçam influência de fato sobre a produtividade
do programador. Diversos trabalhos na literatura identificaram diferentes
fatores que exercem influência na produtividade do programador. Este
trabalho visa analisar os fatores técnicos, humanos e organizacionais e a sua
influência na variação da produtividade dos programadores, medida a partir
dos repositórios de software da organização.
A atividade de desenvolvimento de software tem sido caracterizada como uma atividade
essencialmente humana [Amrit et al. 2014]. Ulrich (1998) aponta que as organizações
de sucesso serão aquelas que melhor se adaptarem no recrutamento, aprimoramento e
retenção dos seus profissionais com as habilidades, perspectivas e experiências
necessárias para a organização. Uma década após, Guthridge et al. (2008) afirmam que
as organizações promovem a ideia de que seus profissionais são a sua maior fonte de
vantagem competitiva. Porém, a maioria das empresas ainda está despreparada para o
desafio de encontrar, motivar e reter os seus profissionais competentes [Guthridge et al.,
2008].
Portanto, nota-se uma necessidade de investimento das organizações de software
em práticas que possam não somente recrutar, mas principalmente aprimorar os seus
engenheiros de software, a fim de se manterem eficientes e competitivas. Os modelos de
processos People Capability Maturity Model (P-CMM) [Curtis et al. 2009] e Melhoria e
Processo do Software Brasileiro – Gestão de Pessoas (MR-MPS-RH) [Softex 2014]
foram criados com base nesta necessidade de gerir a relação das organizações de
software com os seus profissionais.
71
Uma organização de software, ao implementar a recomendação de aprimorar
continuamente seus engenheiros de software, deve estabelecer práticas eficazes. Estas
práticas devem ser baseadas nos fatores preponderantes que possam de fato influenciar e
contribuir para o aprimoramento dos seus engenheiros. Na literatura encontramos
diferentes fatores que influenciam a produtividade do programador de software,
podendo serem agrupados em: (a) fatores humanos, como a personalidade do
programador [Cruz et al. 2011] e a sua motivação [França et al. 2011]; (b) fatores
técnicos, como o conhecimento técnico e experiência do programador [CMMI Product
Team 2010] associados a elementos como a linguagem de programação, a plataforma de
desenvolvimento, as ferramentas utilizadas, etc.; e (c) fatores organizacionais, como os
processos [Curtis et al. 2009] e a cultura organizacional [Mathew et al. 2012] e seus
impactos sobre o programador e suas atividades.
Este trabalho objetiva analisar e investigar a influência dos fatores técnicos,
humanos e organizacionais, na produtividade do programador de organizações de
software. A questão de pesquisa que este trabalho visa responder é:
•! Qual a preponderância entre os fatores técnicos, humanos e organizacionais na
influência sobre a produtividade dos programadores de uma organização de
software?
Além desta seção de caracterização do problema, este artigo está organizado da
seguinte forma: a Seção 2 apresenta a fundamentação teórica e os trabalhos
relacionados; a Seção 3 apresenta os objetivos; a Seção 4 apresenta o método de
pesquisa e o estado atual do trabalho; e a Seção 5 apresenta os resultados esperados e as
considerações finais.
2. Fundamentação Teórica e Trabalhos Relacionados
O desenvolvimento de projetos de software é uma atividade humana com extremas
incertezas desde o início [Trendowicz e Münch 2009], onde as pessoas são vistas como
a maior fonte de variação no desempenho de projetos de software. Provavelmente
devido a isso, o aprimoramento contínuo dos profissionais nas organizações de software
é uma das recomendações constantes nos diversos modelos de processos que surgiram
nas últimas décadas, tais como o MR-MPS-SW (Melhoria e Processo do Software
Brasileiro – Software), o MR-MPS-RH (Melhoria e Processo do Software Brasileiro –
Gestão de Pessoas), o CMMI (Capability Maturity Model Integration) e o P-CMM
(People Capability Maturity Model) [Josko e Cortez 2005]. Porém, para avaliar a
eficácia de qualquer prática adotada pela organização de software a fim de aprimorar a
produtividade dos seus engenheiros, é necessário medir a variação de produtividade
destes engenheiros [Fenton e Pfleeger 1998].
A produtividade de um programador pode ser conceitualmente definida como o
número de unidades de produto, representadas por métricas extraídas do código fonte,
desenvolvidas em uma unidade de esforço, representadas normalmente pelo tempo ou
custo [Mockus 2009]. Existem diversos trabalhos contendo variadas estratégias de
medição da produtividade [Petersen 2011]. Uma das estratégias envolve a medição
através das informações contidas no código fonte que se encontram frequentemente
armazenadas em repositórios de software da organização. Os dados contidos nestes
repositórios têm possibilitado a extração e mineração de informações que permitem uma
análise mais específica dos programadores [Moura et al. 2014]. Na literatura são
72
encontrados trabalhos que mineram o desempenho individual em desenvolvimento
colaborativo [Zhang et al. 2008]; e que extraem métricas de repositórios de software
para comparação dos programadores [Moura et al. 2014].
Com base nas métricas extraídas dos repositórios de software, podemos
identificar indicadores de produtividade dos programadores das organizações de
software. Estes indicadores permitem caracterizar a variação da produtividade do
programador durante o desenvolvimento de software. Na literatura existem diversos
trabalhos que associam diferentes fatores à variação da produtividade do programador
[Cruz et al. 2015; Mathew et al. 2012; França et al. 2011; Trendowicz e Münch 2009],
tais como: personalidade, motivação, conhecimento, experiência, processo e cultura
organizacional, que neste trabalho são classificados como fatores humanos, técnicos e
organizacionais.
O conhecimento e a experiência nas tecnologias e ferramentas utilizadas durante
o desenvolvimento de software, como a linguagem de programação, são considerados
como o fator mais influente na produtividade de software [Trendowicz e Münch 2009].
Os fatores técnicos considerados neste trabalho referem-se à competência individual
adquirida pela educação especializada e à experiência na prática que um indivíduo
possua e deva desenvolver para realizar um tipo determinado de atribuição na
organização [Softex 2014; Curtis et al. 2009]. As organizações de software fazem as
suas definições de cargos e funções baseadas nestes fatores. Eles também servem de
requisitos para as vagas anunciadas para recrutamento de novos programadores.
Entre os fatores humanos a serem investigados estão a personalidade e a
motivação. Cruz et al. (2015) executaram um mapeamento sistemático sobre estudos
relacionados à personalidade na engenharia de software. A motivação é considerada por
pesquisadores e engenheiros de software como a fonte de muitos benefícios, tais como o
desempenho, a produtividade, a retenção e o sucesso [Beecham et al. 2008]. França et
al. (2011) fizeram uma revisão sistemática de literatura sobre a motivação e mostram
que entre os sinais externos da motivação por parte dos engenheiros de software estão a
produtividade e o sucesso do projeto.
Os fatores organizacionais investigados neste trabalho são a cultura
organizacional e a habilidade do programador relativa ao processo de software definido
pela organização. A cultura organizacional é definida como as crenças, valores e
premissas que são compartilhados pelos profissionais que influenciam as interações
entre eles e com o ambiente de uma organização de software [Kozlowski et al. 1993]. A
cultura organizacional é, portanto, um fator importante para a qualidade e produtividade
do trabalho de cada profissional, influenciando o desempenho financeiro de uma
organização [Mathew et al. 2012]. A influência do processo para o programador está na
capacidade do mesmo aplicar seus conhecimentos e realizar suas tarefas seguindo o
processo definido pela organização de software [Softex 2014].
Portanto, os fatores técnicos, humanos e organizacionais são relacionados na
literatura como fatores de influência sobre os programadores de uma organização de
software. A investigação empírica sobre a preponderância da influência que cada um
destes fatores exerce na variação de produtividade dos programadores de uma
organização de software constitui o tema principal deste trabalho.
73
3. Objetivos
O objetivo geral desta pesquisa é investigar a preponderância entre os fatores técnicos,
humanos e organizacionais com relação à produtividade dos programadores de uma
organização de software. Os objetivos específicos deste trabalho são:
•! Definir um conjunto de métricas de produtividade para programadores, a partir
de métricas da literatura e da avaliação da percepção por parte da organização de
software;
•! Avaliar a influência dos fatores humanos (personalidade e motivação), a
influência dos fatores técnicos (conhecimento e experiência), e a influência dos
fatores organizacionais (processo e contexto organizacional) na produtividade do
programador de organizações de software;
•! Avaliar a preponderância entre os fatores pesquisados na produtividade do
programador de organizações de software.
4. Método de Pesquisa e Estado Atual do Trabalho
Fase 1
Warm-up
Para alcançar os objetivos propostos e responder as questões de pesquisa neste trabalho,
propomos a utilização de diversos métodos de pesquisa que estão descritos no plano de
pesquisa e ilustrados na Figura 1.
Estudos sobre Extração e
Mineração de Dados
Estudos sobre a influência
do Gerente do Projeto em
Projetos de Software
Estudos sobre a Gestão do
Conhecimento e Cultura
Organizacional em
Organizações de Software
Mapeamento Sistemático
das Métricas de
Produtividade
Avaliação in vivo das
Métricas de Produtividade
identificadas na Literatura
Análise e Definição das
Métricas de Produtividade
de Programadores
Fase 2
Métricas de
Produtividade de
Programadores
Estudo da Influência dos
Fatores Humanos
Fatores Técnicos
Fatores Organizacionais
Avaliação e Análise da Influência dos Fatores Pesquisados
Figura 1 – Plano de Pesquisa
74
4.1 Warm-Up – Definição de Escopo e Motivação
Esta fase compreendeu estudos conduzidos antes da definição final do escopo deste
trabalho. Os Estudos sobre Extração e Mineração de Dados envolveram aprendizado e
implementação de técnicas de extração e mineração de dados utilizando algoritmos de
data mining e aprendizagem de máquina. Estas técnicas serão utilizadas na análise e
definição das métricas de produtividade dos programadores de uma organização de
software a partir dos seus repositórios.
Os Estudos sobre a influência do Gerente de Projeto em Projetos de Software
focaram-se em fatores humanos e suas influências nos projetos de software. Em
particular, estudou-se o quanto a personalidade [Myers 1962] e o papel de equipe de
Belbin [Belbin 2010] do gerente de projetos influenciam no esforço utilizado pelo
projeto de software. Como resultado destes estudos ocorreu a publicação de um artigo
em colaboração com outro pesquisador [Branco et al. 2015].
Foram realizados Estudos sobre a Gestão do Conhecimento e Cultura
Organizacional em Organizações de Software, focando na relação entre as práticas de
gestão de conhecimento adotadas com a cultura organizacional. Estes estudos, em
colaboração com outros pesquisadores, resultaram em outro artigo publicado [Rabelo et
al. 2015]. O aprendizado acumulado com a execução destes estudos, em conjunto com
os conhecimentos sobre extração e mineração de dados foram essenciais para fechar o
escopo e definir o tema principal deste trabalho, iniciando a Fase 1.
4.2 Fase 1 – Investigação da Produtividade do Programador a partir de
Repositórios de Software
Esta fase compreende a pesquisa por métricas de produtividade relacionadas com a
percepção de produtividade por parte da gerência de organizações de software. O
primeiro passo será a realização de um Mapeamento Sistemático sobre Métricas de
Produtividade existentes na literatura no contexto do desenvolvimento de software. As
métricas identificadas que sejam aplicáveis a programadores e que possam ser extraídas
a partir de repositórios de software serão selecionadas para o próximo estudo.
A Avaliação In Vivo das Métricas Identificadas na Literatura investigará a
relação entre a percepção de produtividade dos líderes quanto a sua equipe de
programadores, com as métricas de produtividade selecionadas. Para cada equipe, será
coletado junto ao líder sua percepção de ranking dos seus programadores, ordenados do
mais produtivo para o menos produtivo, e também uma divisão deste ranking em três
grupos, que aqui chamaremos de: os mais produtivos, os produtivos e os regulares. As
métricas extraídas de produtividade dos programadores serão utilizadas para criação,
por equipe, também de um ranking e de grupos utilizando um algoritmo de clustering.
As métricas serão então avaliadas quanto a similaridade entre os rankings utilizando
Kendall Tau Rank [Kendall 1938], e quanto a similaridade entre os grupos utilizando o
Fowlkes-Mallows index [Fowlkes e Mallows 1983].
Após o resultado da investigação anterior, será executada a Análise e Definição
das Métricas de Produtividade de Programadores. Esta atividade analisará através dos
resultados das similaridades entre as métricas e a percepção dos líderes de equipe, quais
métricas se destacam por equipe, se a mesma métrica se destaca em mais de uma
equipe, e se isso também ocorre por organização. Após esta análise, serão definidas uma
75
ou mais métricas que melhor descrevam a percepção de produtividade dos
programadores. Com esta definição, iniciará a Fase 2.
4.3 Fase 2 – Investigação da Influência dos Fatores Humanos, Técnicos e
Organizacionais
Esta fase investigará a influência dos fatores humanos, técnicos e organizacionais sobre
as métricas de produtividade definidas na fase anterior, com o objetivo de estudar as
suas relações de influência sobre a produtividade dos programadores de uma
organização de software.
O Estudo Qualitativo da Influência dos Fatores Humanos na Produtividade dos
Programadores investigará especificamente a personalidade e a motivação; O Estudo
Qualitativo da Influência dos Fatores Técnicos na Produtividade dos Programadores,
por sua vez, investigará a influência do conhecimento e da experiência; e o Estudo
Qualitativo da Influência dos Fatores Organizacionais na Produtividade dos
Programadores investigará as habilidades nos processos organizacionais e a cultura
organizacional. O objetivo de cada estudo é analisar a influência, pela correlação
estatística, entre os fatores e as métricas de produtividade extraídas dos repositórios da
organização. Analisaremos, por exemplo nos fatores humanos, se existem determinados
tipos de personalidades que possuam maior influência do que outras na variação da
produtividade do programador.
Por fim, a Avaliação e Análise da Influência dos Fatores Pesquisados deste
trabalho, visa explorar a preponderância entre os fatores pesquisados dentro das
observações coletadas. Os dados serão explorados utilizando técnicas estatísticas do
modelo linear generalizado, tais como a análise de fatores e a análise de componentes
principais. Também serão exploradas técnicas mais recentes utilizadas na área de
aprendizagem de máquina como a análise multivariada t-SNE. O resultado destas
análises ajudarão na compreensão da relação de preponderância entre os fatores, e desta
forma contribuirão para a construção da resposta à nossa questão de pesquisa.
No momento, estamos analisando as extrações do mapeamento sistemático sobre
métricas de produtividade encontradas na literatura. Além disso, coletamos alguns de
repositórios de software de projetos de duas organizações de software para testar nossas
rotinas de extração de métricas de produtividade a partir de repositórios de software.
5. Resultados Esperados e Considerações Finais
Ao final deste trabalho espera-se obter as seguintes contribuições:
•! Mostrar quais métricas de produtividade do programador melhor refletem as
percepções dos líderes e gerentes de organizações de software, a partir de dados
reais coletados nos repositórios de software da organização;
•! Avaliar a influência de cada fator técnico, humano e organizacional pesquisado
sobre a produtividade do programador da organização de software;
•! Avaliar e ponderar quais dos fatores pesquisados tem maior impacto, ou seja,
tem maior explicação na variação da produtividade do programador.
Espera-se que os resultados deste trabalho a longo prazo, além de viabilizar mais
pesquisas sobre os fatores relacionados à produtividade do programador, fundamentem
76
a criação de melhores práticas que facilitem o aprimoramento dos programadores, com
reflexos nos indivíduos, nas equipes e nas organizações de software.
Referencias
Amrit, C., Daneva, M., e Damian, D. (2014). “Human factors in software development:
On its underlying theories and the value of learning from related disciplines; A Guest
Editorial Introduction to the Special Issue”. Information and Software Technology
(IST). n. 56, v. 12. p. 1537-1542.
Beecham, S., Baddoo, N., Hall, T., Robinson, H., e Sharp, H. (2008). “Motivation in
Software Engineering: A systematic literature review”. Information and Software
Technology (IST), v. 50, n. 9, p. 860-878.
Belbin, R., (2010). “Management Teams: Why they succeed or Fail”. 3rd Edition.
Elsevier Butterworth-Heinemann Ltd.
Branco, D., Oliveira, E., Galvao, L., Prikladnicki, R. , e Conte, T. (2015). “An empirical
study
about
the
influence
of
project
manager
personality
in software project effort”. In 16th International Conference on Enterprise
Information Systems (ICEIS 2014), p. 102-113.
CMMI Product Team (2010). “CMMI for Development version 1.3 – Improving
processes for developing better products and services”. SEI Report CMU/SEI-2010TR-033.
Cruz, S. S. J. O., da Silva, F. Q., Monteiro, C. V., Santos, C. F., e Dos Santos, M. T.
(2011). “Personality in software engineering: Preliminary findings from a systematic
literature review”. In Evaluation & Assessment in Software Engineering (EASE
2011), 15th Annual Conference on, p. 1-10.
Cruz, S., da Silva, F. Q., e Capretz, L. F. (2015). “Forty years of research on personality
in software engineering: A mapping study”. Computers in Human Behavior, v. 46, p.
94-113.
Curtis, B., Hefley, B., e Miller, S. (2009). “People Capability Maturity Model (P-CMM)
Version 2.0”. CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE
ENGINEERING INST.
Fenton, N. E., e Pfleeger, S. L. (1998). Software Metrics: A Rigorous and Practical
Approach. PWS, London, 1997.
Fowlkes, E. B., e Mallows, C. L. (1983). "A method for comparing two hierarchical
clusterings". Journal of the American statistical association, n. 383, v. 78, pp. 553569.
França, A. C. C., Gouveia, T. B., Santos, P. C., Santana, C. A., e da Silva, F. Q. (2011).
“Motivation in software engineering: A systematic review update”. In Evaluation &
Assessment in Software Engineering (EASE 2011), 15th Annual Conference on, p.
154-163.
Guthridge, M., Komm, A. B., e Lawson, E. (2008). “Making talent a strategic
priority”. The McKinsey Quarterly, v. 1, p. 49-59.
77
Josko, J. M. B., e Côrtez, M. L. (2005). “P-CMM e outros modelos na Gestão de
Pessoas”. VII Simpósio Internacional de Melhoria de Processos (SIMPROS).
http://www.simpros.com.br/simpros2005/upload/a04_2_artigo14181.pdf
Kendall, M. G. (1938). "A new measure of rank correlation. Biometrika". n. 1/2, v. 30,
pp. 81-93.
Kozlowski, S. W., Chao, G. T., Smith, E. M., e Hedlund, J. (1993). “Organizational
downsizing: Strategies, interventions, and research implications”. International
review of industrial and organizational psychology, v. 8, n. 8, p. 263-332.
Mathew, J., Ogbonna, E., e Harris, L. C. (2012). “Culture, employee work outcomes
and performance: An empirical analysis of Indian software firms”. Journal of World
Business, v. 47, n. 2, p. 194-203.
Mockus, A. (2009). “Succession: Measuring transfer of code and developer
productivity”. In Proceedings of the 31st International Conference on Software
Engineering. IEEE Computer Society. p. 67-77.
Moura, M. H. D. De, Nascimento, H. A. D. Do, e Rosa, T. C. (2014). “Extracting New
Metrics from Version Control System for the Comparison of Software Developers”.
Simpósio Brasileiro de Software (SBES 2014), p. 41–50.
Myers, I. B. (1962). “The Myers-Briggs Type Indicator” (1962). Consulting
Psychologists Press, Palo Alto, CA.
Petersen, K. (2011). “Measuring and predicting software productivity: A systematic
map and review”. Information and Software Technology (IST), n. 53, v. 4, p. 317343.
Rabelo, J., Oliveira, E., Viana, D., Braga, L., Santos, G., Steinmacher, I., Conte, T.
2015. “Knowledge Management and Organizational Culture in a Software
Organization – a Case Study”. In: 8th International Workshop on Cooperative and
Human Aspects of Software Engineering (CHASE 2015) - ICSE Workshop,
Florence, Italy (artigo aceito para publicação).
Softex (2014). “MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral
MPS de Gestão de Pessoas”. MR-MPS-RH:2014. http://www.softex.br/wpcontent/uploads/2013/07/ MPS.BR_Guia_Geral_RH_2014_Versao_Beta-1.pdf
Trendowicz, A., e Münch, J. (2009). “Factors Influencing Software Development
Productivity – State-of-the-Art and Industrial Experiences”. Advances in
Computers, v. 77, p. 185-241.
Ulrich, D. (1998). “A new mandate for human resources”. Harvard Business Review, v.
76, p. 124-134.
Witten, I. H., e Frank, E. (2005). "Data Mining: Practical machine learning tools and
techniques". Morgan Kaufmann.
Zhang, S. Z. S., Wang, Y. W. Y., e Xiao, J. X. J. (2008). “Mining Individual
Performance Indicators in Collaborative Development Using Software Repositories”.
15th Asia-Pacific Software Engineering Conference (APSEC 2008). p. 247–254.
78
Framework de Gerência do Conhecimento e Aprendizagem
Organizacional com Fatores de Influência para Organizações
de Software
Jacilane Rabelo, Tayana Conte
Grupo de Usabilidade e Engenharia de Software (USES) – Programa de Pós-graduação
em Informática (PPGI) – Universidade Federal do Amazonas (UFAM), Manaus – AM –
Brasil
{jaci.rabelo, tayana}@icomp.ufam.edu.br
Abstract. Proper knowledge management has become a real need in the
software development industry. The organizational learning aims to promote
individual learning, knowledge collection and to encourage the creation of an
infrastructure for knowledge sharing. The influencing factors of knowledge
management refer to organizational infrastructure to improve the efficiency of
knowledge management activities. This doctorate research aims to investigate
the factors that can influence knowledge management and organizational
learning initiatives in the software industry. One of the first factors
investigated was the Organizational Culture. The Organizational Culture
influences how the organization's employees learn, acquire and share
knowledge. We also have defined the first version of the framework called
Influence Factor in Knowledge and Learning (IFactor-KL). This framework
contains components to promote organizational learning and knowledge
management in software organizations aiming to improve their processes,
showing the factors that influence these initiatives.
Resumo. A gestão adequada do conhecimento tornou-se uma necessidade real
na indústria de desenvolvimento de software. A aprendizagem organizacional
visa estimular a aprendizagem individual, coletar o conhecimento e incentivar
a criação de uma infraestrutura para compartilhamento de conhecimento. Os
fatores de influência da gestão do conhecimento referem-se à infraestrutura
organizacional para melhorar a eficiência das atividades relacionadas ao
gerenciamento do conhecimento. Esta pesquisa de doutorado objetiva
investigar os fatores que podem influenciar as iniciativas de gestão de
conhecimento e aprendizagem organizacional na indústria de software. Um
dos primeiros fatores investigados foi a Cultura Organizacional. A Cultura
Organizacional influencia a forma como os colaboradores da organização
aprendem, adquirem e compartilham o conhecimento. Foi também definida a
primeira versão do framework chamado Influence Factors in Knowledge and
Learning (IFactor-KL)(em português, Fatores de Influência em gestão do
Conhecimento e Aprendizagem) que contém componentes para estimular a
aprendizagem organizacional e gerência do conhecimento em organizações de
software que buscam melhorar seus processos, mostrando os fatores que
podem influenciar essas iniciativas.
79
O conhecimento que uma organização consegue deter e sua capacidade de criar e
utilizar esse conhecimento é a habilidade central para manter uma vantagem competitiva
e inovar [Takeuchi e Nonaka, 2008]. Em organizações de software, a Gerência do
Conhecimento (GC) é vista como uma oportunidade para criar uma linguagem comum
de entendimento entre desenvolvedores de software, para que eles possam interagir,
negociar e compartilhar conhecimentos e experiências [Rus et al., 2001].
Além do tratamento provido pela GC, é necessário estimular a aprendizagem
desses conhecimentos. Dibella e Nevis (1999) afirmam que a Aprendizagem
Organizacional (AO) é a capacidade ou processo que a organização possui para manter
ou melhorar o desempenho baseado na experiência adquirida. A aprendizagem é
essencial para organizações de software, sendo consideradas Organizações de Software
de Aprendizagem (do inglês, Learning Software Organizations - LSO) [Ruhe e
Bomarius, 2000]. Segundo Ruhe (2001), as LSOs são organizações que aprendem no
contexto de desenvolvimento, evolução e aplicação de software.
Moffett et al. (2002) afirmam que muitas organizações têm dúvidas de qual
abordagem adotar em suas iniciativas de GC. Pesquisas têm sido realizadas para
identificar os fatores que afetam a implementação de uma GC bem-sucedida, além de
verificar como esses fatores podem aumentar a inovação e melhoria do desempenho
organizacional [AL-Hakim e Hassan, 2012]. Os fatores de influência, neste contexto,
podem ser definidos como os fatores gerenciais e organizacionais que precisam ser
tratados de forma eficaz, a fim de aumentar as probabilidades de implementação de GC
com sucesso [Asoh et al., 2007].
O trabalho de Viana (2015) apresenta o framework KL-SPI (Knowledge and
Learning to Facilitate Software Process Improvement) que visa facilitar a aprendizagem
organizacional e gerência de conhecimento em organizações de software que estejam
inseridas no contexto de melhorias de processo de software. Embora o trabalho de Viana
(2015) auxilie as organizações na identificação das práticas correntes de AO e GC e
sugira práticas que essas organizações possam utilizar, a versão proposta deste
framework não considera as características de cada organização. Wong (2005) afirma
que as organizações que buscam implementar GC com sucesso devem considerar o
desenvolvimento e compreensão dos fatores de influência. Na mesma linha, segundo
Al-Mabrouk (2006), as organizações podem se beneficiar de um entendimento mais
amplo desses fatores, que são fundamentais para o sucesso da GC. No entanto, a adoção
de fatores que não são apropriados pode dificultar o desempenho desejado. Logo, é
necessário sugerir práticas para as organizações considerando os fatores que influenciam
essas iniciativas para cada organização em questão.
Alguns trabalhos da literatura mostram investigações dos fatores que
influenciam a gerência de conhecimento nas organizações [Yaghoubi e Maleki, 2012;
AL-Hakim e Hassan, 2012; Hsieh, 2007; Choi, 2002]. Porém, esses trabalhos não
sugerem práticas de GC e AO que podem ser empregadas nessas organizações. Esta
pesquisa de doutorado se diferencia dos demais trabalhos citados, pois, se pretende
sugerir práticas para iniciativas de GC e AO em Organizações de Software considerando
os fatores que influenciam essas iniciativas.
80
Desta forma, a questão que norteia esta pesquisa de Doutorado é: “Como
auxiliar as iniciativas de Gerência de Conhecimento e Aprendizagem Organizacional
em organizações de software considerando os fatores que podem influenciar essas
iniciativas em cada organização?”. A questão secundária da pesquisa é: “Quais são os
fatores específicos de organizações de software que podem influenciar as iniciativas de
GC e AO em Organizações de Software?”. Espera-se que, ao responder essas questões,
seja possível contribuir com as iniciativas de GC e AO considerando os fatores
específicos das organizações de software.
Alinhado às questões de pesquisa apresentadas anteriormente, o objetivo geral
deste trabalho consiste em: Investigar os fatores específicos que podem influenciar as
iniciativas de GC e AO em organizações de software e sugerir para as organizações
práticas que possam auxiliar nessas iniciativas. Nessa investigação serão verificados os
fatores que podem influenciar (positiva e/ou negativamente) GC e AO em Engenharia
de Software. Para alcançar este objetivo geral, buscou-se decompô-lo nos seguintes
objetivos específicos: (a) entender o corpo de conhecimento a respeito de abordagens de
AO e/ou GC aplicáveis em organizações de software; (b) identificar um conjunto de
fatores que influenciam as práticas de GC e AO em organizações de software; (c)
investigar como os fatores identificados influenciam as iniciativas de GC e AO nas
organizações de software; (d) evoluir e avaliar o framework de apoio às práticas de GC e
AO associando aos fatores que influenciam essas iniciativas nas organizações de
software.
2. Fundamentação Teórica e Trabalhos Relacionados
Devido à grande competitividade das empresas, ao avanço das tecnologias e à
necessidade de suprir o mercado em tempo hábil, o tratamento do conhecimento tornase uma medida estratégica importante para se manter no mercado [Santos-Vijande et al.,
2012]. Os líderes das organizações buscam as razões e os principais fatores de sucesso
na iniciativa de um sistema de gerência do conhecimento para executá-lo em suas
organizações [Yaghoubi e Maleki, 2012].
Segundo Zack (2002), estratégias de GC são planos de alto nível que descrevem
processos, ferramentas e infraestrutura (organizacional e tecnológica) necessárias para
gerenciar as lacunas de conhecimento ou excessos, e para permitir que o conhecimento
flua de forma eficaz em organizações. Para Chan e Chau (2005), as estratégias de GC
podem encapsular e identificar estratégias de direcionamento nas atividades de GC, e os
facilitadores de GC são os meios que podem facilitar essas atividades.
Diversos trabalhos da literatura têm investigados quais são os facilitadores que
influenciam a implementação de GC [AL-Hakim e Hassan, 2012; Yaghoubi e Maleki,
2012; Hsieh,2007; Mathi, 2004; Zack, 2002; Choi, 2002]. Por exemplo, Mathi (2004)
identifica que os principais fatores de sucesso da implementação de GC nas
organizações são a cultura, estratégia de GC, sistemas e infraestrutura de Tecnologia da
Informação (TI), processos e medidas eficazes e sistemáticas. Choi (2002) realizou uma
pesquisa empírica para verificar a relação entre estratégias de GC, processo de criação
de conhecimento, e desempenho organizacional. O processo de criação de conhecimento
foi classificado utilizando o modelo SECI (socialização, externalização, combinação e
internalização) de Nonaka e Takeuchi (1995). O trabalho de Hsieh (2007) realizou um
81
estudo para verificar a relação entre estratégias de GC, facilitadores de GC, capacidade
do processo de GC, desempenho de GC e características organizacionais.
Os autores AL-Hakim e Hassan (2012) conduziram uma pesquisa de opinião
para examinar a relação entre os fatores críticos de sucesso da gerência de
conhecimento, inovação e desempenho organizacional, em particular no setor de
telecomunicações móveis iraquiana. O objetivo do estudo era abordar os fatores críticos
de sucessos para GC, aumentar a inovação e melhorar o desempenho organizacional. Os
autores apresentam uma tabela com os resultados da pesquisa sobre fatores de influência
para GC.
Este trabalho considera o ponto de vista dos colaboradores envolvidos com atividades
que exigem o gerenciamento e aprendizagem do conhecimento relevantes. Portanto,
entrevistas semiestruturas, questionários de avaliação e estudos experimentais serão
conduzidos em organizações de software. Os procedimentos metodológicos para
elaboração deste trabalho estão de acordo com as etapas apresentadas na Figura 1 e
detalhadas a seguir:
Figura 1. Definição da Metodologia de Pesquisa
1. Revisão da Literatura sobre Fatores de Influência de GC e AO em Organizações de
Software – análise dos fatores sugeridos pela literatura e seus métodos de avaliação.
Esses fatores irão auxiliar na execução desta pesquisa e na definição do framework
proposto;
2. Condução de Investigações do estado da Prática em AO e GC – análise dos fatores
que influenciam a GC e AO em organizações de software e das iniciativas de GC e
AO praticadas por essas organizações. Essa análise será feita no contexto de
melhoria de processo de software (com ou sem processo definido). Os resultados
desses estudos vão apoiar a definição dos componentes do framework proposto;
82
3. Definição do framework IFactor-KL (Influence Factors in Knowledge and
Learning) proposto nesta pesquisa. Este framework visa identificar os fatores de
influência da organização, apoiar o diagnóstico do estado da prática e auxiliar na
inserção de práticas de AO e GC nas organizações de software. O framework
Ifactor-KL contém três componentes. Estes componentes serão detalhados na Seção
4.3.
No estágio atual do trabalho estão sendo definidos os fatores de influência para
as iniciativas de GC e AO. Com base na revisão da literatura já foi definida a utilização
de: (a) Processo de GC com base no ciclo de conhecimento SECI [Nonaka e Takeuchi,
1995]; (b) Cultura Organizacional [Choi, 2002; Cameron e Quinn, 2006]; (c) Estrutura
Organizacional (Centralização e Formalização) [Choi, 2002]; (d) Sistema de TI [Choi,
2002]. Além disso, está sendo desenvolvido um apoio ferramental para avaliar a cultura
organizacional e um estudo experimental está sendo planejado para verificar o estado da
prática desses fatores em uma organização de software.
4. Resultados Esperados e Contribuições Parciais
O principal resultado esperado deste trabalho será a definição de um framework para
gerenciamento do conhecimento e aprendizagem organizacional para apoiar essas
iniciativas em organizações de software. Na definição do framework serão considerados
os fatores que podem influenciar essas iniciativas de GC e AO em organizações de
software. Além disso, um conjunto de práticas de GC e AO também será associado a
esses fatores de influência. Para alcançar essa meta, resultados são esperados e
detalhados a seguir.
4.1. Fatores de Influência e Abordagens de Gerência de Conhecimento e
Aprendizagem Organizacional
Uma pesquisa da literatura está sendo conduzida para definir os fatores de influência de
GC e AO. Inicialmente foi identificado um trabalho da literatura que lista outros
trabalhos sobre fatores de influência de GC [AL-Hakim e Hassan, 2012]. Buscando
identificar esses fatores e de que forma eles foram avaliados, para cada um dos trabalhos
listados por AL-Hakim e Hassan (2012), as seguintes informações foram extraídas: a)
contexto de utilização do fator: descreve em que contexto o fator foi aplicado na
pesquisa; b) questionário de avaliação: verifica se o trabalho mostra o questionário
utilizado em estudos; c) base da literatura do questionário: identifica se o questionário já
foi utilizado em trabalhos anteriores ou se foi criado pelos autores da publicação; d)
validade estatística: verifica se o questionário foi validado e quais testes estatísticos
foram aplicados; e) perguntas do questionário: descrição das questões de cada fator.
Além disso, também é feita a contagem de quantas vezes o fator é citado, e de quantas
vezes a referência base do questionário foi utilizada.
Os resultados desta pesquisa estão contribuindo para a criação do corpo de
conhecimento sobre os fatores de influência, além de identificar a forma de avaliar cada
um desses fatores. Os questionários identificados com base na literatura serão utilizados
posteriormente na investigação do estado da prática em organizações de software.
Um dos primeiros fatores que está sendo investigado nesta pesquisa de
Doutorado é a Cultura Organizacional (CO). A CO influencia a forma como os
83
colaboradores da organização aprendem, adquirem e compartilham o conhecimento. Um
estudo de caso foi conduzido em uma organização de software para verificar a relação
entre o ciclo de Gerência de Conhecimento (modelo SECI) de Nonaka e Takeuchi
(1995) e a Cultura Organizacional por meio do Competing Values Framework (CVF)
[Cameron e Quinn, 2006]. Os resultados desse estudo foram publicados em [Rabelo et
al., 2015].
No trabalho de Viana (2015), através de um mapeamento sistemático da
literatura, foi definido um conjunto de tecnologias de gerência do conhecimento e/ou
aprendizagem organizacional que são aplicáveis em organizações de software. Essas
abordagens tratam, em sua maioria, do armazenamento do conhecimento da
organização. Viana (2015) também realizou a inclusão manual de alguns trabalhos
relacionados a Aprendizagem Organizacional apresentados na pesquisa de Menolli
[Menolli, 2013]. Os resultados do Mapeamento Sistemático de Viana (2015) também
fazem parte dessa Pesquisa de Doutorado, pois houve colaboração ativamente entre os
dois pesquisadores na extração dos dados.
4.2. Condução de Investigações sobre Ferramentas/abordagens de Apoio à
Gerência do Conhecimento e Aprendizagem Organizacional
As ferramentas/abordagens de apoio buscam auxiliar a organização e disseminar o
conhecimento na organização. Essas ferramentas/abordagens estão sendo desenvolvidas
no contexto do subgrupo de pesquisa sobre Learning Software Organizations do grupo
de pesquisa de Usabilidade e Engenharia de Software (USES) da UFAM.
No presente momento, está sendo elaborado o apoio ferramental para avaliar o
Perfil Cultural da Organização com base no formulário OCAI [Cameron e Quinn, 2006].
Esse formulário é útil para capturar o perfil atual e preferido da organização de software.
No escopo desta pesquisa, o formulário OCAI já foi utilizado no estudo de caso
publicado em [Rabelo et al., 2015].
Uma abordagem já desenvolvida e avaliada experimentalmente é a PABCPattern – Problema, Ação, Benefício, Contexto - Padrão [Rabelo et al., 2014]. Essa
abordagem, desenvolvida por esta aluna de doutorado, visa facilitar a codificação de
lições aprendidas em organizações de software. Foram realizados dois estudos
experimentais que evoluíram a abordagem para chegar ao modelo atual. Outras
ferramentas/abordagens estão sendo analisadas visando tanto auxiliar a aprendizagem de
conhecimentos explícitos quanto incentivar a troca de conhecimento tácito.
4.3. Definição Inicial do Framework
Os componentes do framework de fatores de influência para gerência de conhecimento e
aprendizagem organizacional em organizações de software são mostrados na Figura 1.
Esse framework possui componentes que auxiliam a capturar as características da
organização com base em fatores de influência de GC e AO, apoiar o diagnóstico do
estado da prática e sugerir práticas de AO e GC para serem executadas, e sugerir
ferramentas de apoio.
Os componentes do framework IFactor-KL são: (1) diagnóstico do estado da
prática de AO e GC relacionado aos fatores de influência: questionários serão utilizados
para capturar as características da organização em relação aos fatores de influência
84
definidos para GC e AO. Além disso, um processo será definido para a realização desse
diagnóstico; (2) catálogo de práticas de AO e GC relacionado aos fatores de influência:
o trabalho de Viana (2015) não considerou os fatores de influência de GC e AO na
catalogação das práticas. Nesta pesquisa de Doutorado, as práticas serão associadas aos
fatores que podem influenciar as iniciativas de GC e AO nas organizações de software.
Este objetivo visa garantir que as organizações possam utilizar práticas que irão atender
às suas necessidades reais; (3) ferramentas/sistemas para auxiliar AO e GC relacionadas
aos fatores de influência: apoios serão desenvolvidos para auxiliar as atividades de
aprendizagem organizacional e gerência do conhecimento na organização. O primeiro
apoio ferramental que está sendo desenvolvido é o que avalia o perfil cultural da
organização.
Agradecimentos
Os autores agradecem o apoio concedido pela: CAPES (Doutorado); FAPEAM por
meio do Projeto PROTI-Mobilidade sob o processo n. 062.00600/2014.
5. Referências
Al-Hakim, L., Hassan, S. 2012. Critical Success Factors of Knowledge Management,
Innovation and Organizational Performance: An Empirical Study of the Iraqi Mobile
Telecommunication Sector". In: British Journal of Economics, Finance and
Management Sciences, v. 4(1), p. 31-49.
Al-Mabrouk, K., 2006, "Critical Success Factors Affecting Knowledge Management
Adoption: A review of the Literature". IEEE Xplore, p. 1-6.
Asoh, D. A., Belardo, S., Crnkovic, J. 2007. Assessing Knowledge Management:
Refining and Cross Validating the Knowledge Management Index using SEM
Techniques. In: International Journal of Knowledge Management, 3(2), p. 1-30.
Cameron, K. S., Quinn, R. E. 2006. Diagnosing and Changing Organizational Culture",
The Jossey-Bass Business & Management Series, Revised Ed., 259 p.
Chan, L., Chau, P. Y. K. 2005. Getting Knowledge Management Right: Lessons from
Failure. In: The International Journal Knowledge Management, 1(3), p. 40 -54.
Choi, B. 2002. Knowledge Management Enablers, Process, and Organizational
Performance: an Integration and Empirical Examination. Unpublished doctoral
dissertation, Korea Advanced Institute of Science and Technology, Korea, 213 p.
Dibella, J., Nevis, C. 1999. Como as Organizações Aprendem: uma Estratégia Integrada
voltada para a Construção da Capacidade de Aprendizagem. São Paulo: Educator,
228p.
Hsieh, J. H. 2007. Organizational Characteristics, Knowledge Management Strategy,
Enablers, and Process Capability: Knowledge Management Performance in US
Software Companies. Unpublished doctoral dissertation. Lynn University, Florida,
224 p.
Mathi K. 2004. Key Success Factors for Knowledge Management, MBA: International
Business Management& Consulting, Unpublished masther thesis, Lindau, Germany,
102 p.
85
Menolli, A. L., Reinehr, S. Malucelli, A. 2013. Organizational Learning Applied to
Software Engineering: A Systematic Review. In: International Journal of Software
Engineering and Knowledge Engineering, v. 23, n. 8, p. 1153 – 1175.
Moffett, S., McAdam, R. and Parkinson, S. 2002. Developing a Model for Technology
and Cultural Factors in Knowledge Management: a Factor Analysis. In: Knowledge
and Process Management, v. 9, n. 4, p. 237-55.
Nonaka, I., Takeuchi, H. 1995. The Knowledge-Creating Company, 17th ed. Oxford
Oxford, 304 p.
Rabelo, J., Oliveira, E., Viana, D., Braga, L., Santos, G., Steinmacher, I., Conte, T.
2015. Knowledge Management and Organizational Culture in a Software
Organization – a Case Study. In: 8th International Workshop on Cooperative and
Human Aspects of Software Engineering (CHASE 2015) - ICSE Workshop,
Florence, Italy, p. 89-92.
Rabelo, J., Viana, D., Santos, G., Conte, T. 20014. Usando PABC-Pattern para
Codificar o Conhecimento: Um estudo Experimental. In: Simpósio Brasileiro de
Qualidade de Software - SBQS, 2014, Blumenau. Simpósio Brasileiro de Qualidade
de Software, v. 1. p. 1-15.
Ruhe, G., 2001, "Learning Software Organisations", Handbook of Software Engineering
and Knowledge Engineering (S.K. Chang, ed.), World Scientific Publishing 2001, p.
663 – 678.
Ruhe, G., Bomarius, F., 2000, Learning Software Organization - Methodology and
Applications, Springer, 230 p.
Rus, I., Lindvall, M., Sinha, S. S. 2001. Knowledge management in software
engineering. DACS state of the art report (SOAR). Disponível em:
https://www.csiac.org/sites/default/files/KM%20in%20SWE%20-%20SOAR.pdf, 57
p.
Santos-Vijande, M.L., López-Sánchez, J.Á., Trespalacios, J.A. 2012. How
Organizational Learning Affects a Firm's Flexibility, Competitive Strategy, and
Performance. In: Journal of Business Research, v. 65, n. 8 (8), p. 1079-1089.
Takeuchi, H., Nonaka, I. 2008. Gestão do Conhecimento", Porto Alegre: Bookman, 319
p.
Viana, D. 2015. Facilitando a Aprendizagem Organizacional em Melhoria de Processo
de Software". Tese de Doutorado em Informática. Programa de Pós-Graduação em
Informática. Universidade Federal do Amazonas, 435 p.
Wong, K. Y. 2005. Critical Success Factors for Implementing Knowledge Management
in Small and Medium Enterprises. In: Industrial Management & Data Systems, v. 105
(3), p.261 – 279.
Yaghoubi, N.M., Maleki, N. 2012. Critical Success Factors of Knowledge Management
(A Case Study: Zahedan Electric Distribution Company). In: Journal of Basic and
Applied Scientific Research, v. 2, n. 12, p. 12024-12030.
Zack, M.H. 2002. Developing a Knowledge Strategy: Epilogue. Retrieved July 26,
2005, http://web.cba.neu.edu/~mzack/articles/kstrat2/kstrat2.htm.
86

anais do wtdqs 2015

Transcrição

Documentos relacionados

Circular 28 - Sindicato dos Bancários do Norte

w orkshop

clique aqui

Instituto Eu Quero Viver

issn 21774013 produção científica na área do ensino de

Nota de imprensa Workshop Critical: Lisbon_143 KB

workshop “elabore um traje medieval”

EVOLUÇÃO DE 8 PACIENTES COM MPS TIPO I ACOMPANHADOS

DANILO SIQUEIRA

APISnews