anais do wtdqs 2014

Transcrição

anais do wtdqs 2014

ANAIS DO WTDQS 2014
XII Workshop de Teses e Dissertações em Qualidade de Software
04 de Agosto de 2014
Blumenau • Santa Catarina • Brasil
WTDQS 2014
Apresentação do WTDQS
Esta coletânea reúne os trabalhos selecionados para apresentação no XII Workshop de
Teses e Dissertações em Qualidade de Software (WTDQS 2014). Este workshop é parte
das atividades do Simpósio Brasileiro de Qualidade de Software que está atualmente em
sua 13ª edição. O objetivo do WTDQS é permitir que alunos de pós-graduação, de
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 para aprimorar seus trabalhos.
O comitê de programa do WTDQS é formado por especialistas em Qualidade de
Software que fazem parte de grupos de pesquisa reconhecidos da área. Este ano o
WTDQS recebeu 19 artigos, sendo 5 de doutorado e 14 de mestrado, provenientes dos
vários programas de pós-graduação do Brasil. Dessas 19 submissões, 18 submissões
eram válidas e 13 artigos foram selecionados para apresentação e publicação nesta
coletânea, sendo 2 de doutorado e 11 de mestrado. Cada artigo foi avaliado por 3 (três)
membros do comitê de programa. Essas avaliações foram a fonte principal para seleção
dos artigos. Elas certamente são importantes contribuições na evolução das pesquisas
dos autores.
Agradecemos, especialmente, à organização geral do SBQS, na pessoa de Marcello
Thiry, à organização local do SBQS, na pessoa de Everaldo Artur Grahl, às
organizadoras do WTDQS 2013, Ana Regina Rocha e Káthia Oliveira, e aos autores e
orientadores dos trabalhos submetidos ao WTDQS 2014.
Blumenau, 04 de agosto de 2014
Leonardo Gresta Paulino Murta
Sérgio Teixeira de Carvalho
Coordenadores do Comitê de Programa do WTDQS 2014
ii
Biografia dos Coordenadores
Leonardo Gresta Paulino Murta é professor do Instituto de
Computação da Universidade Federal Fluminense (UFF) desde 2008.
Obteve em 2006 doutorado em Engenharia de Sistemas e
Computação pela COPPE/UFRJ, com estágio de doutorado em 2004
na Universidade da Califórnia em Irvine. Foi professor visitante da
Universidade de Nova Iorque em 2013. Além disso, é bolsista de
Produtividade em Pesquisa do CNPq e Jovem Cientista da FAPERJ. Já publicou mais
de 130 artigos em periódicos e congressos, tendo ganho diversos prêmios, dentre eles o
ACM SigSoft Distinguished Paper Award, no ASE 2006. Tem experiência na área de
Ciência da Computação, com ênfase em Engenharia de Software. Seus principais
campos de atuação são Gerência de Configuração, Evolução de Software, Arquitetura
de Software e e-Science. Mais informações podem ser obtidas em
http://lattes.cnpq.br/1565296529736448.
Sérgio Teixeira de Carvalho é professor do Instituto de Informática
(INF) da Universidade Federal de Goiás (UFG) desde 2006. Obteve
Mestrado e Doutorado em Computação pela Universidade Federal
Fluminense (UFF). Tem experiência na área de Ciência da
Computação, com ênfase em Sistemas Distribuídos e Engenharia de
Software, atuando principalmente em Arquitetura de Software,
Linhas de Produto de Software, Arquiteturas Autoadaptáveis e Computação Ubíqua.
Mais informações podem ser obtidas em http://lattes.cnpq.br/2721053239592051.
iii
WTDQS 2014
Coordenadores do Comitê de Programa do WTDQS
Leonardo Gresta Paulino Murta, UFF
Sérgio Teixeira de Carvalho, UFG
Comitê de Programa do WTDQS
Adriano Albuquerque, UNIFOR
Alexandre Vasconcelos, UFPE
Ana Regina Rocha, COPPE/UFRJ
Carlos Pietrobon, UFOP, PUC-MG
Gleison Santos, UNIRIO
Guilherme Travassos, COPPE/UFRJ
Humberto Marques, PUC-MG
Juliano Oliveira, UFG
Káthia Oliveira, UVHC
Marcelo Thiry, UNIVALI
Marco Tulio Valente, UFMG
Rafael Prikladnicki, PUC-RS
Raul Wazlawick, UFSC
Ricardo Falbo, UFES
Rodrigo Reis, UFPA
Sandra Fabbri, UFSCar
Sheila Reinehr, PUC-PR
Tayana Conte, UFAM
Toacy Oliveira, COPPE/UFRJ
Uirá Kulesza, UFRN
Avaliadores Externos do WTDQS
Arilo Dias Neto, UFAM
Coordenador Geral do SBQS
Coordenação Local do SBQS
Everaldo Artur Grahl, FURB
Comitê Diretivo do SBQS
Adriano Albuquerque, UNIFOR
Ana Regina Rocha, COPPE/UFRJ
Andreia Malucelli, PUC-PR
Eduardo Almeida, UFBA
Everaldo Grahl, FURB
Glauco Carneiro, UNIFACS
Kival Weber, PBQP/Software
Rossana Andrade, UFC
Sheila Reinehr, PUC-PR
iv
Índice
Mechanisms to Support Automated Testing of Mobile Applications ....................................................... 1
Autor: Guilherme de Cleva Farto
Orientador: André Takeshi Endo
Instituição: UTFPR
Proposta para Teste de Usabilidade para Aplicações Móveisno Contexto de Computação Ubíqua ......... 7
Autor: Rodrigo dos Anjos Cruz Reis
Orientador: Arilo Cláudio Dias Neto
Instituição: UFAM
Um Framework para as Micro e Pequenas Empresas de Desenvolvimento de Software Baseado no
MPT.BR e na ISO/IEC/IEEE 29119-2 ...................................................................................................... 13
Autora: Dianne Dias Silva
Orientadores: Edmundo Sérgio Spoto, Leandro Luís Galdino de Oliveira
Instituição: UFG
Uma Proposta de Metodologia para Gerenciamento de Riscos em Projetos de Software Aderente a
Modelos e Normas de Qualidade de Processo de Software ...................................................................... 19
Autor: Heresson João Pampolha de Siqueira Mendes
Orientador: Sandro Ronaldo Bezerra Oliveira
Instituição: UFPA
Proposta de um Modelo para Mapear a Transparência no Processo de Software ..................................... 25
Autor: Fernando C. Lima
Orientador: José A. Fabri
Instituição: UTFPR
Uma Proposta de Medidas de Qualidade para Avaliação da Confiança em Sistemas Ubíquos ................ 31
Autora: Andressa Bezerra Ferreira
Orientadores: Reinaldo Bezerra Braga, Rossana Maria de Castro Andrade
Instituição: UFC
Diagnóstico do Cenário Atual da Organização para Implementação de Iniciativas de Melhoria de
Processo de Software ................................................................................................................................. 37
Autora: Patrícia Lima
Orientador: Gleison Santos
Instituição: UNIRIO
Facilitando a Aprendizagem Organizacional em Melhorias de Processo de Software ............................. 43
Autor: Davi Viana
Orientadores: Cleidson de Souza, Tayana Conte
Instituição: UFAM
Towards Understanding Project Actuality in Small Software Development Organizations..................... 51
Autora: Suzana Cândido de Barros Sampaio
Orientador: Hermano Perrelli Moura
Instituição: UFPE
Riscos em Iniciativas de Melhoria de Processo de Software:
Uma Investigação no Contexto Brasileiro ................................................................................................. 59
Autor: Eliezer Dutra
Orientador: Gleison Santos
Instituição: UNIRIO
v
WTDQS 2014
Aplicação de Pontos de Função em Projetos que Usam Métodos Ágeis .................................................. 65
Autor: Eduardo Garcia Wanderley
Orientadores: Alexandre Marcos Lins Vasconcelos, Bruno Tenório Ávila
Instituição: UFPE
Um Mapeamento para Apoio ao Processo de Gerência de Portfólio de Projetos no Contexto
do MR-MPS-SW adotando Práticas Ágeis ................................................................................................ 71
Autora: Gleise Pinheiro Baldez
Orientador: Sandro Ronaldo Bezerra Oliveira
Instituição: UFPA
Estratégia de Apoio à Seleção de Técnicas para Elicitação de Requisitos ................................................ 77
Autora: Renata Magalhães Rêgo
Orientador: Arilo Cláudio Dias Neto
Instituição: UFAM
vi
Mechanisms to support automated testing of mobile
applications
Guilherme de Cleva Farto 1,2,3, André Takeshi Endo1
1
Universidade Tecnológica Federal do Paraná (UTFPR)
Avenida Alberto Carazai, 1640 – 86300-000 – Cornélio Procópio, PR – Brasil
2
Fundação Educacional do Município de Assis (FEMA)
Avenida Getúlio Vargas, 1200 – 19807-635 – Assis, SP – Brasil
3
TOTVS Agroindústria
Rua Prudente de Moraes, 654 – 19806-160 – Assis, SP – Brasil
[email protected], [email protected]
Abstract. Due to the high number and diversity of users, new testing
approaches are necessary to reduce the occurrence of faults and ensure better
quality in mobile applications. The major objective of this project is to propose
mechanisms to support automated testing of mobile applications with an
emphasis on solutions developed for the Android platform. Specifically, we
will investigate the application of the Model-Based Testing (MBT) in order to
validate and improve the reliability of Android applications. The proposed
approach and tool will be evaluated in an industrial configuration with
professional developers of mobile applications.
1. Problem Characterization
Currently, there is a rapid growth in popularity of mobile devices, such as tablets,
smartphones, and e-readers, expanding the variety of applications that are developed with
the support of mobile computing technologies. A 2013 survey on sales of mobile devices
reports that the Android platform had an increase of 127% over the previous year with
approximately 121 million units sold [Gartner 2014]. Thus, Android took the lead, with
62% of systems and development environments for mobile applications, well ahead of
Apple’s iOS and Microsoft’s Windows Phone.
While mobile applications were initially developed for the entertainment industry,
there is a more widespread adoption in critical areas (e.g., financial systems, health care,
and industries) [Muccini et al. 2012]. As a large number and diversity of users as well as
critical systems have benefited from the mobility provided by these applications, the
occurrence of faults can result in human and economic loss. In this context, software testing
has been applied during the development process to minimize the occurrence of faults. The
activity of testing consists of designing test cases, executing the software with these test
cases, and examining the results with the central goal of detecting faults [Harrold 2000].
The mobile application testing provides many challenges to be overcome and has
received special attention from Software Engineering and Mobile Computing community
[Delamaro et al. 2006, Bo et al. 2007, Maji et al. 2010, Hu and Neamtiu 2011, Muccini et
al. 2012, Pathak et al. 2012, Yang et al. 2013, Liu et al. 2014]. Muccini et al. [2012]
1
WTDQS 2014
argue that there is a need for approaches specialized in testing of mobile applications. They
identified characteristics of mobile applications that influence the testing activity, such as
connectivity, limited resources, autonomy, user interface, context awareness, adaptation,
new programming languages and operating systems, diversity of settings, and touch
screens.
The dynamics of mobile applications and their use in critical environments demand
more accurate and repeatable tests. These characteristics can be obtained by the application
of formal approaches and automated tests. Formal testing is characterized by the adoption
of mathematical models to support the testing activity. Examples of formal models are
Finite State Machines (FSMs), Labelled Transition Systems (LTS), and Event Sequence
Graphs (ESGs) [Belli et al. 2006]. According to Hierons et al. [2009], the presence of
formal specifications and designs can lead to more efficient and effective testing. These
models also provide benefits to automation since their syntax and semantics are welldefined and allow the development of tools to manipulate such models. In this context, this
project aims to investigate mechanisms to support automated tests for mobile applications.
Specifically, we plan the development of an approach and a supporting tool based on
concepts of model-based testing and on the Android platform.
2. Background
Several techniques can be applied during the development process in order to reveal faults
in the software artifacts. One of these techniques proposes the automatic generation of test
cases through a behavioral or structural model, named test model, of the software under
test (SUT); this approach is known as Model-Based Testing (MBT). The MBT process can
be more efficient because the tester can update the model and regenerate the test suite,
avoiding manual and error-prone changes [Utting and Legeard 2006]. The literature of
MBT reports a set of benefits resulting from its appropriate adoption, such as high fault
detection rate, reduced cost and time for testing, supporting of the requirements’ evolution,
and a high level of automation [Grieskamp et al. 2011].
Pieces of research on the MBT process suggest four main steps: (i) modeling, (ii)
test generation, (iii) concretization, and (iv) test execution [Pretschner and Philipps 2004,
El-Far and Whittaker 2001, Bouquet et al. 2006]. In modeling, the tester uses her/his
understanding of the software to design a model focused on testing. It is advisable the use
of requirements as the main source of information in order to maximize the independence
between the model and the SUT [Utting and Legeard 2006]. In test generation, the
algorithm to derive test cases from the model depends on the modeling technique adopted.
According to El-Far e Whittaker [2001], modeling techniques should have properties that
make both less costly test generation and easier automation. This step requires a tool to
receive the test model as input and automatically generate a set of test cases as output. The
generated test cases are abstract and not executable because they are in a different level of
abstraction of the SUT. In concretization, the tester provides means to transform abstract
test cases into ones executable in the SUT. To do so, abstract test cases could be
implemented using adapters [Pretschner and Philipps 2004]. In MBT, an adapter is a
software component that enables the execution of abstract test cases. In test execution, the
concretized test cases are executed in the SUT. The results are analyzed and corrective
actions can be taken if faults are revealed.
Event Sequence Graph (ESG). In this project, the expected behavior of the SUT
is going to be modeled by Event Sequence Graphs (ESGs). The choice of ESG as the test
2
modeling technique is backed up by ease of use and successful experience on MBT.
According to Belli et al. [2006], an ESG is a directed graph used to model possible
interactions between the events of the SUT and is formed by nodes that represent events
and by edges that represent valid sequences between these events. The ESG technique can
be learned in a short period, requires little manual work, and is supported by specific tools
[Belli et al. 2006]. Figure 1 illustrates an ESG model for the “cut-copy-paste” procedure.
The brackets represent the beginning and end of event sequences.
Figure 1. ESG for a “cut-copy-paste” procedure – adapted from [Endo 2013].
3. Related Work
The emergence of technologies and platforms for software expands or creates new fields of
study, despite the existing researches on software testing [Muccini et al. 2012]. Thus, the
mobile applications introduce new testing challenges that must be overcome and, as a
consequence, have been investigated by researchers of software engineering and mobility.
These studies can be divided into two lines. In the first line, traditional testing techniques
have been adapted to mobile applications. Delamaro et al. [2006] describe a strategy to
support structural testing of mobile applications and enable test execution through
emulators and physical devices in the Java Micro Edition (JME) platform. In functional
testing, Bo et al. [2007] implement a tool, named MobileTest, to automate the black-box
testing from an event-based approach to simplify and improve the design of test cases. Its
functionalities include the record of sensitive events, a schedule mechanism for regression
testing, and adapters for future devices to be added.
The second line investigates faults characteristic of mobile applications and, based
on them, new testing strategies are proposed. Maji et al. [2010] evaluate the reported
failures in Symbian and Android platforms resulting in: a detailed analysis of faults found,
a characterization of corrections made, and a comparison between the two operating
systems. Neamtiu and Hu [2011] describe an approach to test Android applications,
emphasizing the user interface’s faults. Random testing, instrumentation of virtual
machine, and log analysis were employed. Pathak et al. [2012] investigate software faults
related to excessive energy consumption on smartphones running Android and provide an
automatic solution to detect these problems using a data flow analysis algorithm. Yang et
al. [2013] propose a testing technique to identify and quantify faults related to excessive
waiting times for certain events in Android applications. For this, the authors rely on the
artificial insertion of delay instructions in typical problematic operations. Finally, Liu et al.
[2014] characterize a set of performance faults commonly identified in Android mobile
applications. The paper also presents a source code analyzer to detect the identified
performance fault patterns in Android applications.
3
WTDQS 2014
Notice that several researchers have investigated techniques for mobile application
testing, highlighting the most notorious adoption of the Google Android platform. So far,
few efforts have been spent to evaluate mechanisms for test automation in mobile
applications. Moreover, most of the papers are academic and there is a lack of research on
applying automated testing in industrial configurations. As mobile applications pose
challenges to software testing, many topics can be further explored.
4. Project Planning and its Current State
This section shows the activities planned to achieve the research project’s goal; its current
state is also presented. The activities are briefly described as follows.
1. Study of the Android platform: this activity aims to study the Android operating
system and how applications are developed for the given platform. In particular, we will
emphasize the tool named Android Studio. Android Studio is an integrated development
environment that provides mechanisms to design, code, debug and test Android
applications using emulators and different devices. Existing open source applications will
also be studied and collected as examples or case studies for future evaluations.
2. Study of the mobile application testing: this activity aims to understand the
challenges and limitations faced by testers during the development of mobile applications.
Another point is to identify tools that automate the testing of mobile applications,
specifically for Android. A starting point is the testing capabilities already provided by
Android Studio. Another interesting tool is Robotium [2014], which is a framework for
automating functional GUI testing in Android applications. Native capabilities for Android
test automation as Instrumentation and MonkeyRunner may also be studied [Android
Testing Fundamentals 2014]. Finally, a detailed literature review about mobile application
testing will be performed.
3. Conduction of an exploratory study: based on the elicited knowledge in previous
activities, we will conduct a first exploratory study to investigate the application of MBT in
mobile applications for the Android platform. This study aims to identify tools, lessons
learned, and limitations to be considered in the next activities.
4. Proposal of a testing approach: a model-based testing approach will be proposed to
verify mobile applications, taking into account the results obtained in previous activities.
The purposes of the approach are to maximize the fault detection rate, minimize the testing
rework, and reduce the test execution time. It is expected to maximize the fault detection
rate because it becomes possible to create and reuse test models to evaluate the SUT on
different configurations of mobile devices. The testing rework will be minimized because
the models can be updated and the test suite regenerated.
5. Development of supporting tools: this activity aims to develop supporting tools for the
proposed approach. Existing tools can also be modified to integrate with the developed
tool. A possible candidate would be the Astah tool; plug-ins could be developed to simplify
the modeling and test generation steps.
6. Case studies in an industrial setting: the evaluation of software testing approaches
basically involves two aspects: cost and effectiveness. We should consider the most
appropriate metrics to evaluate these aspects, e.g., the time elapsed to design and
implement the tests. The guidelines proposed in the literature [Wohlin et al. 2000,
Kitchenham et al. 2002] will guide the planning, execution, and analysis of experimental
4
studies performed. Initially, we plan to evaluate our proposal by conducting case studies in
industrial settings with real-world applications and experienced professionals.
7. Elaboration of scientific papers: this activity aims to report the findings of this
master’s project as scientific papers that will be submitted to journals and conferences of
the software engineering and mobility areas.
Current State of the Project. So far, we have worked on Activities 1, 2, and 3, described
previously. A summary of Activity 2 is shown in Section 3. As Activities 1 and 2 involve
literature review, future updates along the project are still necessary. Activity 3 was also
performed. In summary, we evaluated the adoption of MBT concepts and modeling with
ESG in the testing of Android applications. The preliminary results give evidences of the
feasibility of TBM to verify mobility solutions with Android, observing automatic
generation and execution of test cases, ability to detect faults, and reduced time for
regression tests. This study and obtained results have been compiled in a submitted paper.
Currently, the master’s candidate is working on Activities 4 and 5. Particularly, the result
of Activities 1-4 is planned to be presented as a master’s proposal in December 2014.
5. Expected Results
This section presents the results and benefits expected from this master’s project. The
desired results are described as follows: (i) Mechanisms to support automated testing of
mobile applications on Android: this result will be an approach based on MBT to verify
mobile applications developed on Android platform. (ii) Supporting tools: testing tools
will be developed and/or adapted to support the proposed approach. Furthermore, training
materials will be prepared to use the tools. (iii) Experimental evaluation: case studies will
be conducted in order to evaluate the applicability of the proposed approach, providing
evidence on cost and effectiveness, relevant to industrial adoption. (iv) Technology
transfer: we expect to transfer the technology developed to software companies that
develop Android applications.
We expect that the results bring the following benefits: (i) Strengthen the software
engineering area in the master’s program, encouraging the transfer of technology to
industry and disseminating the acquired knowledge through papers; (ii) collaboration with
other research centers; and (iii) cooperation with technology incubators to implement
software testing best practices in incubated companies that develop mobile applications.
References
Android Testing Fundamentals (2014) “Android Testing Framework”, available at
http://developer.android.com/tools/testing/testing_android.html, June.
Belli, F., Budnik, C. J. and White, L. (2006) “Event-based modelling, analysis and testing of
user interactions: approach and case study”, Software Testing, Verification & Reliability, v.
16, n. 1, pages 3–32.
Bo, J., Xiang, L. and Xiaopeng, G. (2007) “MobileTest: A Tool Supporting Automatic Black
Box Test for Software on Smart Mobile Devices”, In: Proc. of the Second Int. Workshop on
Automation of Software Test (AST).
Bouquet, F., Debricon, S., Legeard, B. and Nicolet, J. B. (2006) “Extending the unified
process with model-based testing”, In: 3rd Int. Workshop on Model Development,
Validation and Verification (MoDeVa), Genova, Italy, pages 2-15.
5
WTDQS 2014
Delamaro, M. E., Vincenzi, A. M. R. and Maldonado J. C. (2006) “A strategy to perform
coverage testing of mobile applications”, In: Proc. of the 2006 Int. Workshop on
Automation of Software Test (AST), pages 118–124.
El-Far, I. K. and Whittaker, J. A. (2001) “Model-based software testing”, In: Encyclopedia on
Software Engineering, Wiley, pages 825-837.
Endo, A. T. (2013) “Model-based testing of service oriented applications”, PhD dissertation,
ICMC/USP,
São
Carlos,
SP,
available
at
http://www.teses.usp.br/teses/disponiveis/55/55134/tde-20062013-140259.
Gartner, Inc. Press release (2014), available at: http://www.gartner.com/newsroom/id/2674215.
Grieskamp, W., Kicillof, N., Stobie, K. and Braberman, V. A. (2011) “Model-based quality
assurance of protocol documentation: tools and methodology”, Software Testing,
Verification and Reliability, v. 21, n. 1, pages 55-71.
Harrold, M. J. (2000) “Testing: A Roadmap”, In: Proceedings of the Conference on The Future
of Software Engineering (ICSE), pages 61-72.
Hierons, R. M., Bogdanov, K., Bowen, J. P., Cleaveland, R., Derrick, J., Dick, J., Gheorghe,
M., Harman, M., Kapoor, K., Krause, P., Lüttgen, G., Simons, A. J. H., Vilkomr, S.,
Woodward, M. R. and Zedan, H. (2009) “Using formal specifications to support testing”,
ACM Computing Surveys (CSUR), v. 41, n. 2, pages 1-76.
Hu, C. and Neamtiu, I. (2011) “Automating GUI Testing for Android Applications”, In: Proc.
of the 6th Int. Workshop on Automation of Software Test (AST), pages 77–83.
Kitchenham, B. A., Pfleeger, S. L., Pickard, L. M., Jones, P. W., Hoaglin, D. C., Emam, K. E.
and Rosenberg, J. (2002) “Preliminary guidelines for empirical research in software
engineering”, IEEE Transactions on Software Engineering, v.28, 721–734.
Liu, Y., Xu, C. and Cheung, S.C. (2014) “Characterizing and Detecting Performance Bugs for
Smartphone Applications”, In: The 36th International Conference on Software Engineering
(ICSE), Hyderabad, India.
Maji, A. K., Hao, K., Sultana, S. and Bagchi, S. (2010) “Characterizing Failures in Mobile
OSes: A Case Study with Android and Symbian”, In: The International Symposium on
Software Reliability Engineering (ISSRE), pages 249–258.
Muccini, H., Di Francesco, A. and Esposito, P. (2012) “Software testing of mobile
applications: Challenges and future research directions”, In: The 7th International
Workshop on Automation of Software Test (AST), IEEE.
Pathak, A., Jindal, A., Hu, Y. C. and Midkiff, S.P. (2012) “What is keeping my phone awake?
Characterizing and detecting no-sleep energy bugs in smartphone apps”, In: The Int’l Conf.
Mobile Systems, App’s, and Services (MobiSys), pages 267-280.
Pretschner, A. and Philipps, J. (2004) “Methodological issues in model-based testing”, In:
Model-Based Testing of Reactive Systems, LNCS, pages 281-291.
Robotium (2014) “Robotium – The world’s leading Android test automation framework”,
available at https://code.google.com/p/robotium/, April.
Utting, M. and Legeard, B. (2006) “Practical model-based testing: A tools approach”, San
Francisco, CA, USA: Morgan Kaufmann Publishers Inc.
Wohlin, C., Runeson, P., Hoest, M., Ohlsson, M. C., Regnell, B. and Wesslon, A. (2000)
“Experimentation in Software Engineering: an Introduction”, Kluwer.
Yang, S., Yan, D. and Routev, A. (2013) “Testing for poor responsiveness in Android
applications”, In: Proc. Int’l Workshop on the Engineering of Mobile-Enabled Systems
(MOBS), pages 10-20.
6
Proposta para Teste de Usabilidade para Aplicações
Móveis no Contexto de Computação Ubíqua
Rodrigo dos Anjos Cruz Reis, Arilo Cláudio Dias Neto
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
[email protected]; [email protected]
Abstract. The applicability of mobile devices has considerably increased in
recent years, allowing users to perform more tasks in a mobile context.
Moreover, the technological advances in the mobile devices and communication
networks fields have making possible the ubiquitous computing. Since different
people profiles are using this platform, it is necessary to analyze the usability
of the applications developed to these devices in some contexts, including
computing ubiquity. This work proposes the definition of a usability
testing technique for mobile applications with ubiquity features aiming at
increasing the quality of this category of software.
Resumo. A utilidade de dispositivos móveis tem aumentado consideravelmente
nos últimos anos, permitindo aos usuários executar mais tarefas em um contexto
móvel. Além disso, os avanços tecnológicos nas áreas de dispositivos móveis e
redes de comunicação tem tornado possível a computação ubíqua. Visto que
pessoas com perfis diferentes estão usando esta plataforma é preciso ter
atenção a usabilidade dos aplicativos desenvolvidos para esses dispositivos em
alguns contextos, sendo um deles o de ubiquidade computacional. Este trabalho
propõe a definição de uma técnica de teste de usabilidade para aplicativos
móveis com características de ubiquidade visando aumentar a qualidade desta
categoria de software.
Palavras-Chave: Avaliação de Usabilidade, Aplicações móveis, Teste,
Ubiquidade, Qualidade de software.
1. Introdução e Caracterização do Problema
O cenário de aplicações para dispositivos móveis (neste trabalho serão chamadas
simplesmente de aplicativos móveis), desde a sua criação e até os dias atuais, vem
evoluindo em tecnologia e se disseminando na população. Segundo Harrison (2013), a
variedade e a disponibilidade de aplicativos móveis estão se expandindo rapidamente. Os
desenvolvedores estão aumentando os serviços que são fornecidos devido ao aumento do
poder de processamento disponível nos dispositivos móveis. Aliado a este cenário de
evolução na plataforma móvel, é preciso ter atenção aos avanços tecnológicos nas áreas
de dispositivos móveis e redes de comunicação que, segundo Spínola (2010), tornaram
possível a computação ubíqua.
Assim como qualquer outra categoria de software, os aplicativos móveis e ubíquos
requerem qualidade para atender aos requisitos propostos e, assim, satisfazer às
necessidades de seus usuários finais. Nesta pesquisa, optou-se por medir a usabilidade,
que é um dos atributos de qualidade definidos pela norma ISO/IEC 25000 (2014).
7
WTDQS 2014
Com base nos resultados parciais de um mapeamento sistemático que está sendo
conduzido, percebeu-se a existência de diversas técnicas de teste de usabilidade para
diversos tipos de aplicações desenvolvidas para a plataforma móvel. Alguns testes são
conduzidos levando-se em conta fatores de acordo com normativas para usabilidade de
software listadas por Nielsen (1993), outros se concentram apenas em um subconjunto.
No entanto, essas técnicas não capturam adequadamente as complexidades de interação
com aplicações em uma plataforma móvel. Estas complexidades podem existir por causa
das caraterísticas diferenciadas existentes na plataforma como o pequeno tamanho da tela,
conectividade e entradas limitadas, o que restringe as maneiras pelas quais os usuários
podem interagir com eles e que, segundo Harrison (2013), possuem um efeito sobre a
usabilidade de aplicações móveis.
Ainda baseado nos resultados do mapeamento sistemático citado, percebeu-se que
na literatura ainda não pode ser identificada uma técnica de teste de usabilidade cujo foco
seja atingir as características de ubiquidade descritas por Spínola (2010), existentes em
aplicações móveis. Essas características serão abordadas na seção seguinte. Portanto, o
objetivo deste trabalho é definir uma técnica de teste de usabilidade com foco em
aplicações móveis com características de ubiquidade visando aumentar a qualidade
destes.
2. Fundamentação Teórica
2.1. Aplicações Móveis
Segundo Kirubakaran (2013), de acordo com as últimas pesquisas do Wireless
Smartphone Strategies (WSS), o número de smartphones em uso no mundo ultrapassou
a marca de 1 bilhão de unidades pela primeira vez no terceiro trimestre de 2012.
Passaram-se 16 anos para a indústria de telefonia inteligente chegar a este marco histórico,
mas o próximo bilhão pode ser alcançado em menos de três anos, ou seja, até 2015.
As aplicações móveis foram desenvolvidas inicialmente em sua maioria para o
setor de entretenimento. Atualmente, já estão em domínios mais críticos, tais como varejo
(ex: locação-inteligente de comércio móvel), mídia (revistas e jornais 100% digitais),
viagens (reservas de imóveis, check-ins em viagens aéreas, mapas, ofertas, etc), educação
(uso de tablets e aplicativos em salas de aula), saúde (registros de consulta a pacientes,
notas de médicos, etc), finanças (aplicativos para negociação em tempo real, análise de
portfólio, movimentação financeira) e sociais (jogos e plataformas de mídia social)
(KIRUBAKARAN, 2013).
No entanto, apesar do crescimento e inserção das aplicações móveis em nossa
sociedade, elas possuem limitações. Zhang e Adipat (2005) destacam uma série de
questões que foram introduzidas com o advento de dispositivos móveis e que precisam
ser consideradas durante o desenvolvimento destas aplicações: contexto celular,
conectividade, pequeno tamanho da tela, resolução diferente em displays, capacidade e
poder de processamento limitados e métodos de acesso de dados.
2.2. Computação Ubíqua
Aliado ao cenário apresentado na seção anterior de evolução na plataforma móvel, é
preciso ter atenção aos avanços tecnológicos nas áreas de dispositivos móveis e redes de
comunicação que, segundo Spínola (2010), tornaram possível a computação ubíqua. O
termo computação ubíqua pode ser entendido como alto grau de dispositivos embarcados
8
da computação pervasiva juntamente com o alto grau de mobilidade da computação
móvel, onde computação pervasiva diz que o computador está embarcado no ambiente de
forma invisível para o usuário (ARAUJO, 2010). O objetivo da computação ubíqua é
tornar os serviços computacionais embutidos no ambiente que nos cerca, de forma que
seu uso seja não intrusivo para os usuários (WEISER, 1991)(ABOWD,1999).
Spínola (2010) definiu características funcionais de ubiquidade que podem compor
projetos de software: onipresença de serviços, invisibilidade, sensibilidade ao contexto,
comportamento adaptável, captura de experiências, descoberta de serviços, composição
de funcionalidade, interoperabilidade espontânea, heterogeneidade de dispositivos e
tolerância a falhas. Em um projeto de software ubíquo, estas características resultarão em
requisitos funcionais e não-funcionais a serem atendidos.
2.3. Teste de software
Teste de Software é uma das técnicas de verificação e validação de software (V&V) e
consiste em uma investigação experimental conduzida para prover informações aos
usuários e envolvidos no processo sobre a qualidade do software sob teste no contexto no
qual este será operado (KANER, 2006).
As atividades de teste de software possuem um papel fundamental no
desenvolvimento de um software como mecanismo de apoio à garantia da qualidade do
produto, pois corresponde ao último recurso para avaliação do produto antes da sua
entrega ao usuário final. Segundo Nielsen (1994), em teste de software deve-se avaliar
diferentes níveis, atingindo não só como requisitos funcionais, mas como também
requisitos não-funcionais. O foco deste trabalho está nos requisitos não-funcionais,
especificamente teste de usabilidade
2.4. Avaliação de Usabilidade em Aplicações Móveis
Assim como qualquer outra categoria de software, os aplicativos móveis e ubíquos
requerem qualidade para atender aos requisitos propostos e, assim, satisfazer às
necessidades de seus usuários finais. A ISO/IEC 2500 (2014), composta por Requisitos,
Modelo, Gerenciamento, Medições e Avaliação, divide os atributos do seu Modelo de
Qualidade
em:
Funcionalidade,
Confiabilidade,
Usabilidade,
Eficiência,
Manutenibilidade e Portabilidade. Neste trabalho, o foco será em características de
Usabilidade.
Na literatura técnica, várias definições de usabilidade podem ser encontradas. Por
exemplo, Jakob Nielsen (1993) divide a usabilidade em cinco fatores: facilidade de
aprendizagem, eficiência, facilidade de memorização, erros e satisfação. A ISO-9241
(2002), define usabilidade como "a extensão em que um produto pode ser usado por
usuários específicos para alcançar objetivos específicos com efetividade, eficiência e
satisfação em um contexto de uso especificado". Abran et al. (2007) apresentaram um
modelo de usabilidade consolidado que define usabilidade como uma combinação de
eficácia, eficiência, satisfação, capacidade de aprendizado, e segurança, juntamente com
um conjunto recomendado de medidas relacionadas. Nayebi et al. (2012) resumem que
seria importante considerar três aspectos de usabilidade para todos os tipos de software:
mais eficiente de usar, mais fácil de aprender e mais satisfação do usuário.
A avaliação de usabilidade pode ser feita por meio de técnicas estáticas (ex:
revisão de software) ou dinâmicas (ex: teste de software). Este trabalho está focado na
9
WTDQS 2014
aplicação de técnicas dinâmicas (teste de software) como instrumento para avaliação da
usabilidade de aplicações móveis ubíquas.
Contextualizando o cenário de teste de software para avaliação de usabilidade de
sistemas, um teste de usabilidade eficaz deve ser capaz de obter feedback dos usuários
sobre se eles usam uma aplicação sem (ou quase sem) dificuldade e como eles gostam de
usar a aplicação, bem como avaliar os níveis de desempenho da tarefa alcançados pelos
usuários (WICHANSKY, 2000).
3. Metodologia e Estado Atual do Trabalho
A metodologia a ser empregada para o desenvolvimento da pesquisa envolve duas fases:
fase de concepção e fase de avaliação. Na primeira fase, são coletadas as informações
através de investigações da literatura. É nesta fase também que a técnica será definida e
uma ferramenta de implementação da técnica será desenvolvida. Na fase de avaliação, os
experimentos serão planejados, executados e analisados. As atividades correspondentes a
esta metodologia são apresentadas a seguir, de acordo com suas fases.
3.1. Fase de Concepção:
 C1) Investigação da literatura técnica para identificação de trabalhos científicos e
relatos de experiência que abordem a avaliação de usabilidade em aplicações
móveis (destacando aquelas aplicadas no contexto de ubiquidade).
 C2) Análise do resultado das investigações realizadas no passo anterior a fim de
selecionar quais características de ubiquidade serão abordadas nessa proposta.
 C3) Estudo sobre desenvolvimento de teste de usabilidade em aplicações móveis a
fim de adaptá-las às aplicações móveis ubíquas.
 C4) Definição da técnica em conformidade com os princípios e normas estudados
no passo anterior.
 C5) Desenvolvimento da ferramenta que implemente a técnica proposta no passo
anterior.
3.2. Fase de Avaliação:
 A1) Planejamento dos estudos a serem realizados na fase de avaliação.
 A2) Realização do estudo de viabilidade com estudantes da UFAM para avaliar a
qualidade da técnica e da ferramenta desenvolvida nesse trabalho.
 A3) Realização de um estudo qualitativo através de um experimento in vivo (em um
cenário real da indústria de software) para avaliar a técnica e ferramenta proposta.
Atualmente, está sendo concluída a atividade C2 da metodologia apresentada
através de um mapeamento sistemático para identificar o que tem sido pesquisado com
relação à avaliação de usabilidade em aplicações móveis no contexto de ubiquidade para
ajudar a definir qual(is) característica(s) de usabilidade será(ão) tratada(s) neste trabalho.
4. Trabalhos Relacionados
Segundo Machado-Neto (2013), a usabilidade de aplicativos móveis vem sendo avaliada
através das heurísticas de Nielsen (1994). No entanto, este estudo avaliou que as
heurísticas de Nielsen são deficientes em identificar problemas de usabilidade destes
aplicativos. Sendo assim em Machado-Neto(2013), foram desenvolvidas novas
heurísticas apropriadas para aplicativos móveis baseada nas heurísticas de Nielsen.
10
Alguns trabalhos anteriores apresentaram uma análise sobre avaliação de
usabilidade para aplicativos móveis. Por exemplo, Zhang et al. (2005) apresentaram um
panorama dos estudos de usabilidade existentes, com foco em testes de usabilidade, e
discutem as principais questões que têm sido investigadas. Em seguida, propõe-se uma
estrutura genérica e fornece orientações detalhadas sobre como conduzir tais estudos de
usabilidade em dispositivos móveis. Duh et al. (2006) descrevem um estudo que
investigou as diferenças entre os testes de usabilidade em celulares conduzidos em
laboratório e em situação real de uso. Foram encontradas diferenças significativas,
incluindo a frequência e gravidade dos problemas de usabilidade encontrados, o
comportamento dos usuários e respostas subjetivas para o dispositivo e a interação. Em
(Nayebi et al., 2012), é apresentado um estudo que analisou as metodologias utilizadas
para avaliar empiricamente a usabilidade em aplicações móveis, classificando como
experimentos de laboratório, estudos de campo e prática de medição. O estudo descreve
vantagens e limitações de cada metodologia. Existe também um modelo de avaliação de
usabilidade criado por Harrison (2013) chamado PACMAD (People At the Centre of
Mobile Application Development). Este modelo de usabilidade foi projetado para lidar
com as limitações dos modelos existentes, quando aplicado a dispositivos móveis. Porém,
esse modelo apresenta a mesma deficiência quando se trata de aplicativos móveis que
possuem características de ubiquidade, ao não tratar diretamente essas características.
Recentemente, Kjeldskov et al. (2014) apresentam e avaliam seis técnicas para avaliar a
usabilidade de aplicações móveis em laboratório. As seis técnicas são avaliadas através
de dois experimentos de usabilidade.
Spínola (2010) diz que é importante que novas pesquisas sejam realizadas na
engenharia de software considerando a computação ubíqua e seus desafios associados.
Esses desafios se encontram em cada etapa do ciclo de vida do software. A pesquisa
proposta neste artigo se concentra na etapa de testes onde, segundo Spínola (2010),
existem lacunas a serem preenchidas tais como: quais abordagens de teste podem ser
utilizadas e como garantir a qualidade dos requisitos oferecidos pelo sistema.
Neste contexto, este trabalho propõe enriquecer esta linha de pesquisa,
desenvolvendo uma técnica para Testes de Usabilidade que esteja de acordo com a
situação atual da tecnologia e o conceito ubíquo, que possa ser instanciado de acordo com
especificações dentro do contexto da plataforma móvel. Fatores abordados neste modelo
poderão ser encontrados em normativas de usabilidade e através do resultado de um
mapeamento sistemático executado durante o desenvolvimento da técnica.
5. Resultados Esperados
Espera-se como resultado ter a primeira abordagem (técnica + ferramenta) de teste de
usabilidade que apoie especificamente a avaliação de aplicações móveis que possuam
características de ubiquidade integradas aos seus serviços.
Pretende-se nessa ferramenta especificar e mostrar os tipos de contextos da
aplicação testada para o testador, contextos esses que foram definidos na técnica, em
seguida a tela será percorrida e resultados obtidos com resultados esperados ja definidos
pela técnica serão comparados.
Também é esperado com os resultados obtidos desta pesquisa que seja possível a
implementação de tal abordagem por empresas que desejam aperfeiçoar seu
11
WTDQS 2014
desenvolvimento com estas melhorias, fornecendo um meio com bom custo benefício
para o teste dessas aplicações.
Referências
Araujo, R. B. (2003) “Computação ubíqua: Princípios, tecnologias e desafios”. In: XXI
Simpósio Brasileiro de Redes de Computadores. p. 11-13.
Abowd, G. (1999). “Software engineering issues for ubíquos computing”. Proceedings of
the 21 International Conference on Software Engineering. Pages: 75 – 84, Los
Angeles, USA.
Duh, H., G. Tan, V. Chen. (2006) “Usability evaluation for mobile device: a comparison
of laboratory and field tests”. Proceedings of the 8th conference on Human-computer
interaction with mobile devices and services (MobileHCI '06), pp. 181-186.
Harrison, R., Flood, D., & Duce, D. (2013). “Usability of mobile applications: literature
review and rationale for a new usability model”. Journal of Interaction Science, p 116.
ISO 9241-11 (2002) “Ergonomic Requirements for Office Work with Visual Display
Terminals (VDTs)” Part 11: Guidance on Usability.
ISO/IEC 25000. (2003/2014)” Software Engineering -- Software product Quality
Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE”.
Kaner, C. (2006)_“Exploratory Testing, Florida Institute of Technology”, Quality
Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL,
Novembro.
Kjeldskov, J., J. Paay. (2012) “A longitudinal review of Mobile HCI research methods”.
In: International Conference on Human-computer interaction with mobile devices and
services (MobileHCI'12), pp. 69-78.
Kirubakaran, B.; Karthikeyani, V. (2013) “Mobile application testing—Challenges and
solution approach through automation.” In: Pattern Recognition, Informatics and
Medical Engineering (PRIME), International Conference on. IEEE, p. 79-84.
Machado-Neto, J. O., (2013) “Usabilidade da interface de dispositivos móveis:
heurísticas e diretrizes para o design”. Tese de Doutorado. Universidade de São Paulo.
Nielsen, J. (1993) “Usability engineering”. San Diego: Academic Press.
Nayebi, F., J.M. Desharnais, A. Abran. (2012) “The State of the Art of Mobile
Application Usability Evaluation”. In: 25th IEEE Canadian Conference on
Electrical Computer Engineering CCECE, p:1-4.
Nielsen, Jakob. Usability inspection methods. In: Conference companion on Human
factors in computing systems. ACM, 1994. p. 413-414
Spinola. R. O., “Apoio A Especificação e Verificação De Requisitos Funcionais De
Ubiquidade Em Projetos De Software”. Tese de Doutorado. Alberto Luiz Coimbra De
Pós-Graduação E Pesquisa De Engenharia (Coppe) Da Universidade Federal Do Rio
De Janeiro 2010.
Weiser M. (1991) “The Comouter for the 21st Century”. Scientific American 1991, p: 94104.,
Wichansky, A. (2000) “Usability test in 2000 and beyond. Ergonomic”, 43(7), 998-1006.
Zhang, D, & Adipat, B. (2005). “Challenges, methodologies, and issues in the usability
testing of mobile applications”. International Journal of Human-Computer Interaction,
18(3), p:293–308.
12
Um Framework para as Micro e Pequenas Empresas de
Desenvolvimento de Software Baseado no MPT. BR e na
ISO/IEC/IEEE 29119-2
Dianne Dias Silva, Edmundo Sérgio Spoto, Leandro Luís Galdino de Oliveira
Instituto de Informática – Universidade Federal do Goiás (UFG)
Caixa Postal 131 – 74001-970 – Goiânia – GO – Brasil
[email protected], [email protected], [email protected]
Abstract. This paper proposes a framework based on the Model of Software
Testing Process MPT.BR and Standard ISO/IEC/IEEE 29119-2 in order to
build a proper process for micro and small enterprises software development
and to bring improvements to Freetest Method. The article also presents a
theoretical foundation on which this framework will be supported, as well as
its methodology, the current state, the related work and the expected results of
this work.
Resumo. Esse artigo propõe um framework baseado no Modelo de Processo
de Teste de Software MPT.BR e na Norma ISO/IEC/IEEE 29119-2, visando à
construção de um processo adequado para as micro e pequenas empresas de
desenvolvimento de software e, que traga melhorias para o Método Freetest.
O artigo apresenta ainda, uma fundamentação teórica na qual esse framework
se apoiará, assim como sua metodologia, o estado atual, os trabalhos
relacionados e os resultados esperados desse trabalho.
1. Caracterização do Problema
A crescente demanda e, consequentemente, a complexidade dos produtos de software
ocorrida nas últimas décadas, exige cada vez mais que as equipes envolvidas nos
projetos de desenvolvimento sejam maiores e especializadas, provocando um anseio por
qualidade e produtividade, tanto do ponto de vista do processo de produção como do
ponto de vista dos produtos gerados. Diante disso, as micro e pequenas empresas de
desenvolvimento de software têm se preocupado e investido na Garantia da Qualidade,
que está diretamente relacionada com a qualidade do Processo de Teste ao qual foi
submetido [Staab 2003].
Ainda que haja inúmeras técnicas, políticas e metodologias na área de Teste
de Software, existem deficiências evidentes em relação à integração entre o Processo de
Teste e Ferramentas no âmbito desse tipo de organização. Considerando esse panorama,
estabeleceu-se o Método Freetest através do programa PAPPE Integração apoiado pela
FAPEG/FINEP (Fundação de Amparo à Pesquisa do Estado de Goiás/Financiadora de
Estudos e Projetos) e pelos profissionais do INF (Instituto de Informática) da UFG
(Universidade Federal de Goiás) em conjunto com grandes nomes da indústria de
software do estado de Goiás.
Entretanto, o Método Freetest requer aprimoramento principalmente no que
tange à descrição e ao detalhamento do Processo de Teste estruturado, uma vez que, os
Níveis de Maturidade, as Áreas do Processo e as Práticas Genéricas que o contemplam
13
WTDQS 2014
são expostos de maneira sintética. Logo, a implementação e a institucionalização do
referido método tornam-se onerosas e complexas para as empresas de desenvolvimento
de software.
Portanto, esse trabalho objetiva: desenvolver um framework de Processo de
Teste de Software embasado nos pontos fortes do MPT.BR (Melhoria do Processo de
Teste Brasileiro) e da ISO/IEC/IEEE (International Organization for
Standardization/International Electrotechnical Commission/Electrical and Electronic
Engineers) 29119-2 que resultará na melhoria do Método Freetest; implementar o
Método Freetest após sua respectiva reformulação nas organizações que fazem o uso
desse processo; certificar a consistência do modelo em questão depois da coleta e
apuração dos resultados obtidos com a implementação do método reformulado;
contribuir com as micros e pequenas empresas de desenvolvimento de software na
produção de produtos de baixo custo e com alta qualidade.
Esse trabalho está dividido em 5 seções. Na Seção 2 são apresentados os
principais conceitos e terminologias referentes à fundamentação teórica. Nas Seções 3 e
4 são demonstrados a metodologia e estado atual do trabalho, bem como os trabalhos
relacionados. E, na Seção 5 são tratados os resultados esperados do trabalho em
questão.
Atualmente, a gerência da Qualidade de Software não se restringe apenas a definir
procedimentos, padrões e verificar se estes estão empregados no desenvolvimento de
software. Essa atividade determina uma cultura de qualidade na organização, na qual
todos os envolvidos no desenvolvimento do produto detêm um nível de qualidade
(individual) a ser alcançado. A Garantia da Qualidade é composta por três atividades
principais (Pilares da Qualidade de Software): Planejamento, Garantia e Controle da
Qualidade [Bartié 2002]. O Teste de Software é considerado um elemento crítico da
Garantia da Qualidade, cuja finalidade é detectar o maior número de defeitos no
software, por meio de um conjunto de atividades planejadas antecipadamente e
executadas de maneira sistemática antes da entrega final do produto. O seu principal
foco é a redução da probabilidade de ocorrência de defeitos quando o sistema já estiver
em produção, sendo esses erros, defeitos ou falhas diretamente ligados aos riscos que
podem prejudicar o negócio. Em outros termos, quanto antes os testes forem iniciados,
menos dispendiosas serão as correções dos erros e/ou falhas encontrados. [Bastos et al.
2012].
Para que isso seja possível, faz-se necessária a definição de um Processo de
Teste com um ciclo de vida estabelecido (MPT.BR, ISO/IEC/IEEE 29119-2 e Método
Freetest), em que suas respectivas atividades devem ser desenvolvidas ao longo do
próprio Processo de Desenvolvimento de Software, que em geral, concretizam-se em
quatro níveis: Unidade, Integração, Sistema e Aceitação [Pressman 2002].
Fundamentado nisso, os critérios de teste são estabelecidos a partir de três técnicas:
Funcional (Particionamento em Classes de Equivalência e Análise do Valor Limite),
Estrutural (Baseado em Fluxo de Controle e Baseado em Fluxo de Dados) e a Baseada
14
em Erros (Semeadura de Erros e Análise de Mutantes) [Budd 1981] [Rapps e Weyuker
1985] [DeMillo et al. 1978].
Sendo assim, o MPT.BR trata da melhoria do Processo de Teste através de
práticas que envolvem as atividades projetadas ao longo do ciclo de vida de teste do
produto de software. Sua estrutura é dada por dois componentes: o Guia de Referência
(apresenta a estrutura, as áreas de processo e as práticas do modelo) e o Guia de
Avaliação (contém o processo de avaliação e instruções para a realização da mesma em
uma organização baseada no MPT.BR). Esse modelo têm como principais objetivos:
tornar-se um modelo de referência para definição, implantação e melhoria dos Processos
de Teste; abordar a melhoria contínua nos Processos de Teste conforme os objetivos
organizacionais e o nível de maturidade almejado; fornecer uma base para avaliação e
consequente identificação do grau de maturidade presente nas organizações; e reunir as
melhores práticas e estruturá-las segundo o grau de complexidade versus o nível de
maturidade na qual as organizações estão relacionadas [Softex 2011].
Porém, a ISO/IEC/IEEE 29119 é um conjunto de padrões de Teste de Software
acordados internacionalmente que podem ser usados em qualquer ciclo de vida de
desenvolvimento de software ou organização, fornecendo aos mesmos uma abordagem
de alta qualidade para essa atividade. Essa norma especifica os Processos de Teste que
podem ser utilizados para controlar, gerenciar e implementar Teste de Software em
qualquer atividade da organização, projeto ou teste. Ela é composta de quatro normas
ISO/IEC/IEEE: 29119-1 (Conceitos e Definições), 29119-2 (Processos de Teste),
29119-3 (Documentação de Teste) e 29119-4 (Técnicas de Teste). A avaliação do
processo estabelecido na ISO/IEC/IEEE 29119-2 ocorre de acordo com a ISO/IEC
33063 (Modelo de Avaliação de Processo de Teste de Software) e ainda, substituem
uma série de padrões existentes: IEEE 829 (Documentação de Teste), IEEE 1008
(Testes Unitários), BS (British Standards) 7925-1 (Vocabulário de Termos em Teste de
Software) e BS 7925-2 (Componente Padrão de Teste de Software) [ISO/IEC/IEEE
2013].
Em contrapartida, o Método Freetest consiste em um conjunto de processos e
ferramentas para Teste de Software estruturado especificamente para as micro e
pequenas empresas de desenvolvimento de software, cuja metodologia estabelece
soluções de fácil aplicação juntamente com as ferramentas de desenvolvimento. Sua
organização se dá através três componentes: o Manual de Instalação (detalha o processo
de integração entre as ferramentas de teste Testlink e Mantis), o Manual de Utilização
(expõe o uso da integração entre as ferramentas de teste Testlink e Mantis) e o Manual
do Modelo (mostra a estrutura, as áreas de processo e as práticas do modelo). Esse
modelo tem como propósito a realização de testes de forma sistemática por meio da
instanciação de um Processo de Teste com suporte automatizado. São contemplados
ainda, nesse método a integração de quatro ferramentas de teste: Bug Wizard Report
(integração do Testlink ao Mantis), JinFeng (integração de diferentes plataformas de
teste baseada em ferramentas de código aberto e escrito em Python/Jython), JMeter
(Teste de Performance, Carga e Stress), Selenium (automação de Teste Funcional para
15
WTDQS 2014
interfaces Web) e Sikuli (automação e Teste de Interfaces Gráficas utilizando imagens)
[INF/UFG, 2013].
Inicialmente, tanto o Guia de Referência do MPT.BR quanto a ISO/IEC/IEEE 29119-2
assim como o Manual do Modelo do Método Freetest, serão estudados a fim de
identificar e explorar os Níveis de Maturidade, as Áreas de Processo, as Práticas
Genéricas, as Multicamadas do Processo e também, as Atividades e Tarefas que os
compõem respectivamente. Isto é, cada um dos Modelos de Processo de Teste e da
Norma citados anteriormente, terão a Visão Geral, o Propósito, os Produtos Típicos e
Resultados além, das Vantagens e Desvantagens mapeados. Possibilitando assim, a
detecção das potenciais melhorias a serem incorporadas no Método Freetest.
Em seguida, a partir da seleção das Áreas de Processo e das Práticas Genéricas
compreendidas nos Níveis de Maturidade do MPT.BR e, das Atividades e Tarefas
delimitadas nas Multicamadas do Processo referentes à ISO/IEC/IEEE 29119-2
consideradas viáveis (baixo custo e fácil implementação) de acordo com o contexto das
organizações, um framework será desenvolvido e agregado ao Método Freetest. Após a
remodelagem desse método, as micro e pequenas empresas de desenvolvimento de
software que o utilizam serão visitadas, com o intuito de verificar a aderência ou não do
processo implantado previamente. Onde, essa verificação consistirá na análise dos seus
devidos ambientes de teste por meio de brainstorming, entrevistas e reuniões com as
equipes de teste envolvidas nos Projetos de Teste. Que por consequência, apoia a
calibragem do referido Processo de Teste.
Posteriormente à reformulação do Método Freetest, ocorrerá a sua reimplantação
em cada uma dessas organizações, que serão monitoradas e controladas de maneira
presencial. Visto que, o ciclo de vida definido para os Projetos de Teste destas, são
comprovados através dos produtos de trabalho gerados, ou seja, dos artefatos. Contudo,
os resultados obtidos com a execução desse Processo de Teste serão coletados segundo
o sumário dos registros de teste presentes nos artefatos estipulados no método em
questão e logo após, comparados com os resultados esperados pela Gerência de Projeto
de Teste e de Desenvolvimento de Software. Por fim, os Projetos de Teste passarão por
uma inspeção de software envolvendo as equipes de teste das micro e pequenas
empresas de desenvolvimento de software objetivando a certificação da conformidade
com o Método Freetest.
Nesse momento, o framework baseado no MPT.BR (Níveis de Maturidade,
Áreas de Processo e Práticas Genéricas) e na ISO/IEC/IEEE 29119-2 (Multicamadas do
Processo, Atividades e Tarefas) que incorporará o Método Freetest está sendo
construído e também, observados os pontos a serem aperfeiçoados nesse modelo.
A metodologia de Crespo et al. (2004), está fundamentada na adoção de um Processo de
Teste e nos artefatos sugeridos pelo padrão IEEE 829-1998, que descreve os
documentos originados durante o seu ciclo de vida. Essa metodologia de teste foi
16
projetada e desenvolvida de forma a possibilitar que as empresas instanciem o Processo
de Teste de acordo com as suas necessidades e disponibilidade de recursos, podendo
ainda ser aplicada a qualquer tipo de software, seja ele sistema de informações ou
software científico. Em Sartori (2005), foi definido um Modelo de Melhoria de
Processo de Teste para pequenas empresas tendo como base o TMM (Test Maturity
Model), levando-se em consideração suas diretrizes essenciais. O modelo proposto
conta com um mecanismo de avaliação que permite identificar o nível de maturidade
em que a dada empresa desenvolvedora se encontra, fornecendo dessa forma, subsídios
para auxiliar a implantação de melhorias na área de Teste.
Silva (2011), também estruturou uma metodologia de teste viável para as micro
e pequenas empresas baseado nos modelos de documentos disponibilizados pelo padrão
IEEE 829-1998. A metodologia contou com o apoio de especialistas em teste e de
profissionais que atuam em pequenas empresas para que sua estruturação fosse
viabilizada, por meio da abordagem do multicritério de apoio à decisão. O objetivo é
diminuir a quantidade de documentos, bem como o escopo desses documentos, gerados
no decorrer do Processo de Teste, de forma a conter apenas os itens mais relevantes para
a realidade das micro e pequenas empresas.
O arcabouço estabelecido por Araújo (2013), avalia o nível de maturidade do
Processo de Teste com base nas práticas do TMMI (Test Maturity Model Integration)
que possibilite as micro e pequenas empresas realizarem a autoavaliação da maturidade
do seu respectivo processo sem possuir um conhecimento avançado do modelo. Por fim,
o trabalho em questão determina a construção de um framework cujo público alvo são
as micro e pequenas empresas de desenvolvimento de software baseado no Modelo de
Processo de Teste de Software MPT.BR e na Norma ISO/IEC/IEEE 29119-2 que
possibilite a melhoria do Método Freetest.
O Teste de Software não é uma atividade trivial devido à flexibilidade para mudanças,
complexidade e intangibilidade, ou seja, às próprias características do software. E para
que essa atividade obtenha êxito, é imprescindível o conhecimento, planejamento,
projeto, acompanhamento, recursos e também a interação com as equipes envolvidas na
construção do produto de software [Crespo et al. 2004].
Dessa forma, os resultados esperados com esse trabalho são: a construção de um
framework de Processo de Teste baseado nos pontos fortes do MPT.BR e da
ISO/IEC/IEEE 29119-2 que contribua com a melhoria do Método Freetest e, a aplicação
desse método após sua respectiva reformulação nas organizações que fazem o seu uso.
Verificando assim, os benefícios e ganhos proporcionados desde o início até a
conclusão do Processo de Desenvolvimento de Software juntamente com um Processo
de Teste efetivo, estruturado especificamente para micro e pequenas empresas de
desenvolvimento de software.
17
WTDQS 2014
Referências
Araújo, A. F. (2013) “Um Arcabouço para Avaliação do Nível de Maturidade em Teste
de
Software
para
Micro
e
Pequenas
Empresas”,
http://www.inf.ufg.br/mestrado/sites/www.inf.ufg.br.mestrado/files/uploads/Dissert
acoes/adailton_ferreira_de_araujo.pdf.
Bartié, A. (2002), Garantia de Qualidade de Software, Campus.
Bastos, A., Cristalli, R., Moreira, T. e Rios, E. (2012), Base de Conhecimento em Teste
de Software, Martins, 3ª edição.
Budd, T. A. (1981) “Mutation Analysis: Ideas, Example, Problems and Prospects”,
Computer Program Testing: Proceedings of the Summer School on Computer
Program Testing held at SOGESTA, Urbino, Italy, North-Holand Publishing
Company, p. 129 – 148.
Crespo, A. N., Silva, O. J., Borges, C. A., Salviano, C. F., Teive, M., Junior, A. e Jino,
M. (2004) “Uma Metodologia para Teste de Software no Contexto da Melhoria de
Processo”, http://www.lbd.dcc.ufmg.br/colecoes/sbqs/2004/024.pdf.
DeMillo, R. A., Lipton, R. J. and Sayward, F. G. (1978) “Hints on Test Data Selection:
Help
for
the
Practicing
Programmer”,
https://www.st.cs.unisaarland.de/edu/recommendation-systems/papers/Hints_on_Test_Data_Selection1.pdf.
INF/UFG, (2013) “Manual do Processo de Teste de Sofware para Micro e Pequena
Empresas”, versão 2.0, Manual Técnico, http://www.freetest.net.br/ferramentas.
ISO/IEC/IEEE (2013), ISO/IEC/IEEE 29119-2, Software and Systems Engineering –
Software Testing – Part 2: Test Process.
Pressman, R. S. (2002), Engenharia de Software, McGraw-Hill, 5 edição.
Sartori, L. E. S. (2005) “Melhoria do Processo de Teste para Pequenas Empresas”,
http://aberto.univem.edu.br/bitstream/handle/11077/335/Melhoria%20do%20Proce
sso%20de%20Teste%20para%20Pequenas%20Empresas.pdf?sequence=1.
Silva, A. R. (2011) “Uma Metodologia de Testes em Software para Micro e Pequenas
Empresas
Estruturada
em
Multicritério”,
http://uol11.unifor.br/oul/conteudosite/F1066341385/Dissertacao.pdf.
Softex (2011), MPT.BR – Melhoria de Processo de Teste Brasileiro: Guia de
Referência.
Staab, T. C. (2003) “Improving the Test Process – Looking at The Test Process –
Getting Started”, The Journal of the Software Testing Professionals.
Rapps, S. e Weyuker, E. J. (1985) “Selecting Software Test Data Using Data Flow
Information”, IEEE Transactions on Software Engineering, p. 367–375.
18
Uma Proposta de Metodologia para Gerenciamento de
Riscos em Projetos de Software aderente a Modelos e Normas
de Qualidade de Processo de Software
Heresson João Pampolha de Siqueira Mendes1, Sandro Ronaldo Bezerra Oliveira1
1
Programa de Pós-Graduação em Ciência da Computação (PPGCC) – Universidade
Federal do Pará (UFPA) - Rua Augusto Corrêa, 01 – Guamá – Belém - PA - Brasil
Abstract. This paper presents a proposal of methodology for Risk
Management process, which intends to comply with the best practices of the
leading software quality models: MR-MPS-SW, CMMI-DEV, ISO/IEC 12207,
PMBoK and ISO/IEC 16085.
Resumo. Este trabalho apresenta uma proposta de metodologia para
implementação do processo de Gerência de Riscos em organizações
desenvolvedoras de software, que visa atender às boas práticas apresentadas
em alguns dos principais modelos e normas relacionados à qualidade de
software: MR-MPS-SW, CMMI-DEV, ISO/IEC 12207, PMBoK e ISO/IEC
16085.
O desenvolvimento de um software é não repetitivo e imprevisível, envolvendo alta
complexidade, necessitando estar em conformidade com as necessidades do cliente,
sujeito a constante mudanças, além de ser intangível [BROOKS, 1986]. Uma maneira
encontrada para tentar ultrapassar estas dificuldades é através de modelos e normas, que
são guias para executar boas práticas em processos de software, fornecendo diretrizes
em diversas disciplinas relacionadas ao desenvolvimento de software, entre elas está o
Gerenciamento de Riscos.
As dificuldades apresentadas por Brooks (1986), perduram até hoje,
confirmando-se com a citação de Pressman (2011), que evidencia a importância desta
área do conhecimento ao afirmar que software é uma empreitada difícil, muitas coisas
podem dar errado, portanto entender os riscos e tomar medidas proativas para evitá-los é
essencial para um bom gerenciamento do projeto de software.
Profissionais e pesquisadores concordam que para a gerência de riscos ser
efetiva é necessário incluí-la desde as fases iniciais do processo de desenvolvimento
[ISLAM, 2011], pois requisitos é uma das principais causas de falhas nos projetos
[GLASS, 1998]. Uma vantagem de considerar gerência de riscos desde as fases iniciais
do processo de desenvolvimento do software é a possibilidade de identificar
prematuramente problemas futuros que aumentariam os custos do projeto [VAN
LAMSWEERDE, 2009].
Diversos modelos e guias de boas práticas para projetos e projetos de software,
como MR-MPS-SW [SOFTEX, 2012], PMBOK [PMI, 2013], ISO/IEC 12207 [ABNT,
2009] e CMMI-DEV [SEI, 2010], possuem referência à área de Gerenciamento de
Riscos, embasando a importância deste processo. Cada modelo possui um conjunto de
metas a serem alcançadas no Gerenciamento de Riscos e algumas sugestões de como
implementá-lo, porém organizações consideradas de micro, pequeno e médio porte
19
WTDQS 2014
muitas vezes não possuem recursos suficientes para implementar um processo e avaliálo [SOFTEX, 2012].
No contexto nacional, atualmente, existem cerca de 533 empresas avaliadas no
MR-MPS-SW e dentro do prazo de vigência de três anos. Deste total, apenas 34
empresas já foram avaliadas no nível de maturidade C [SOFTEX, 2014], no qual está
situado o processo de Gerência de Riscos, ou seja, 93,5% das organizações
desenvolvedoras de software que buscam qualidade de processo no Brasil não possuem
experiência e maturidade comprovadas no gerenciamento de riscos.
Este trabalho tem o objetivo auxiliar estas organizações a implementarem um
processo de extrema importância, como o gerenciamento de riscos. Serão
disponibilizados uma metodologia e uma ferramenta de software, que têm como
diferencial a compatibilidade com as melhores práticas recomendadas em modelos de
qualidade de software, coletadas através do mapeamento entre as mesmas.
Processo de software é denominado por Pressman (2011), como um arcabouço para as
tarefas necessárias para a construção de um software de alta qualidade. Além disso, um
processo deve estar alinhado a métodos técnicos, abrangendo um arcabouço de
processo, muitas vezes denominado framework. O guia PMBOK [PMI, 2013], define
processo como uma combinação de atividades inter-relacionadas realizadas, com o
intuito de atingir um objetivo, como alcançar resultados, produtos ou serviços.
A qualidade do processo de software é uma abordagem comumente utilizada
para alcançar a qualidade do software, como podem ser vistos em Humphrey (1989) e
IEEE (2014). Portanto, atualmente existem algumas iniciativas na busca pela qualidade
de software de forma padronizada, possibilitando melhor avaliação dos processos. Entre
os padrões internacionais destacam-se o modelo de maturidade CMMI-DEV [SEI, 2010]
e a norma ISO/IEC 12207 [ABNT, 2009], no âmbito nacional o MR-MPS-SW,
integrante do programa MPS.BR [SOFTEX, 2012]. Também considerado uma
referência em boas práticas no gerenciamento de projetos, há o guia PMBOK [PMI,
2013], porém de forma mais abrangente, determina boas práticas para projetos de
quaisquer natureza, não especificamente para software.
Todos estes padrões abordam a área de Gerenciamento de Riscos de maneira
detalhada, porém com algumas semelhanças e diferenças entre si. Segundo o guia
PMBOK, risco pode ser definido como a possibilidade de ocorrência de um evento ou
condição que pode ter efeito positivo ou negativo em um objetivo de um projeto [PMI,
2013]. Logo o gerenciamento de riscos em projetos de software descreve uma
abordagem integrada entre métodos, processos e artefatos, para analisar, controlar e
monitorar continuamente os riscos, com o objetivo de reduzir as chances de falha do
projeto [ABNT, 2008].
O trabalho de Ropponen e Lyytinen (2000), define gerência de riscos como uma
abordagem que tenta formalizar práticas de sucesso orientadas a riscos em um conjunto
de princípios e práticas prontamente aplicáveis. Enquanto que Chapman e Ward (2003),
definem que o propósito da gerência de riscos é de melhorar a performance do projeto,
através da identificação e avaliação sistemática de riscos, desenvolvendo estratégias
para reduzi-los ou evitá-los, minimizando perdas e maximizando o sucesso do
desenvolvimento do software.
20
A partir destas definições, pode-se concluir, juntamente com a afirmativa de
Avdoshin e Pesotskaya (2011), que um entendimento sistemático e profundo do
domínio do problema, uma poderosa ferramenta de gerenciamento de riscos e práticas
padronizadas ajudam a minimizar as perdas que eventuais riscos ocorridos podem
proporcionar.
Segundo Boehm (1991), a gerência de riscos pode ser dividida em oito
principais passos: identificação, análise, priorização, gerência, planejamento, mitigação,
resolução e monitoramento de riscos. Avdoshin e Pesotskaya (2011) identificaram que
estudos mais recentes sintetizaram estes passos em cinco características: documentação
de lições aprendidas e identificação, análise, planejamento de respostas e
monitoramento de riscos. Estes passos vão nortear os diversos modelos de qualidade
que abordam a gerência de riscos.
Entre os modelos e normas de qualidade de software que determinam boas
práticas para o gerenciamento de riscos, destacam-se a norma ISO/IEC 12207, os
modelos CMMI-DEV e MR-MPS-SW, e os guias de práticas PMBOK e o padrão
internacional para gerência de riscos definido pelo IEEE e ISO/IEC, a ISO/IEC
16085:2006 [IEEE, 2006].
A realização deste trabalho iniciou-se com uma pesquisa exploratória relacionada ao
referencial teórico do gerenciamento de riscos e de melhoria de processo de software
(Etapa 1). Em seguida, foi realizada uma pesquisa bibliográfica para formar a base
teórica relacionada ao gerenciamento de riscos e identificar trabalhos relacionados.
Deste modo, foi possível identificar quais normas e modelos de qualidade de software
poderiam ser agregados ao estudo (Etapa 2).
A partir dos modelos e normas de qualidade selecionados, realizou-se uma
análise documental do conteúdo relacionado ao gerenciamento de riscos, identificando
as práticas de cada modelo ou norma envolvidos (Etapa 3). Em seguida, foi realizado
um mapeamento entre estas práticas, identificando quais são semelhantes entre todos os
modelos e/ou quais destacam-se em apenas um ou mais modelos (Etapa 4).
Posteriormente, através do método hipotético-dedutivo, utilizando-se do
conhecimento teórico adquirido, será realizada a proposta da metodologia de
gerenciamento de riscos envolvendo todas as boas práticas coletadas, dando destaque
para as que são aderentes a todos os modelos e normas envolvidos (Etapa 5). A
metodologia deve detalhar atividades, papéis, ferramentas envolvidas e sugestões de
implementação de cada atividade.
Avaliações através de revisões por pares foram realizadas nos documentos
gerados em cada etapa até aqui descrita (Etapa 6). Esta avaliação é sempre realizada por
pelo menos um especialista em melhoria de processo de software, com experiência em
gerenciamento de projetos de software e em implementação e avaliação de processo de
software.
A avaliação da metodologia em um ambiente real é um impeditivo, pois há um
tempo reduzido para a conclusão do projeto, porém serão realizadas outras alternativas
para consolidar informações e agregar sugestões. Assim, pretende-se realizar entrevistas
com gerentes de projetos de software experientes, afim de coletar dados e observar
comentários e feedbacks em relação à metodologia proposta (Etapa 7).
21
WTDQS 2014
Também pretende-se conduzir um experimento controlado com grupos de
alunos, afim de coletar métricas e ratificar a metodologia, identificando que é adequada
para aprendizagem ao facilitar o entendimento da gestão de riscos (Etapa 8). O
experimento consistirá em selecionar dois grupos de alunos: um que utilizará a proposta
de metodologia desenvolvida; e o outro que utilizará uma metodologia qualquer.
Pretende-se avaliar a condução das tarefas definidas e monitorar sua execução utilizando
sugestões de Travassos et al. (2002).
Este trabalho culmina com a produção de uma ferramenta de software,
atualmente em desenvolvimento, que terá o objetivo de sistematizar as tarefas descritas
na metodologia proposta (Etapa 9). Porém, levando em consideração a possibilidade de
adaptação da metodologia às particularidades das organizações. Os dados resultantes das
etapas que serão realizadas também serão avaliados através de revisões por pares, como
descrito na Etapa 6. A ferramenta também será avaliada através de questionários
preenchidos por usuários, que testarão cenários hipotéticos.
Um artigo retratando parte dos resultados desta pesquisa (Etapas 1 a 4) foi aceito
para publicação na Revista Abakós (periodicos.pucminas.br/index.php/abakos).
Temporariamente estes resultados estão disponíveis na forma de relatório técnico em
http://spider.ufpa.br/projetos/spider_riscos/SPIDER_RelatorioTecnico.pdf.
Através de uma revisão na literatura, foram analisados diversos trabalhos relacionados
ao gerenciamento de riscos. Algumas propostas assemelham-se, porém não englobam
práticas de diversos modelos de qualidades associadas às sugestões de implementação
de processo, que é o objetivo geral deste projeto.
A pesquisa de Raz e Hillson (2005) e de Gusmão e Moura (2004), apresentam
uma comparação entre os principais padrões internacionais para o gerenciamento de
riscos, com o objetivo de identificar quais etapas são similares em cada padrão. Por
serem estudos mais antigos, podem ser considerados desatualizados, pois atualmente
existem novas versões para alguns dos padrões abordados.
Outros trabalhos mais recentes apresentaram mapeamentos entre modelos de
qualidade de software, como o de Von Wangenheim et al. (2010), que realiza um
mapeamento entre o modelo CMMI-DEV v1.2 e o Guia de Gerência de Projetos
PMBOK 4ª edição, porém contempla apenas atividades relacionadas diretamente ao
gerenciamento de projetos do guia CMMI-DEV (PP - Project Planning, PMC - Project
Monitoring and Control, SAM - Supplier Agreement Management).
Mutafelija e Stromberg (2009) realizam também um mapeamento entre o
modelo CMMI, versão 1.2, e as diversas normas ISO (9001:2000; 20000:2005;
15288:2008; 12207:2008) através de uma relação binária entre o modelo CMMI e as
normas ISO.
O trabalho de Islam (2011), apresenta um framework para gerenciamento de
riscos orientado a objetivos. O framework, denominado GSRM, possui quatro níveis de
abstração: (1) objetivos do projeto; (2) identificação de obstáculos que impeçam que o
projeto atinja seus objetivos (fatores de riscos ou perfil dos riscos); (3) para cada fator
de risco, identificação de conseqüências (definição dos riscos); e finalmente, (4)
definição de como deve ser realizado o tratamento e monitoramento aos riscos. O foco
deste trabalho é relatar um estudo de caso, realizado com a implementação deste
22
framework, no qual é apresentada a forma de avaliação e coleta de dados, o
detalhamento do estudo de caso com as atividades realizadas, e uma discussão sobre
resultados e conclusões obtidas após a finalização do experimento. Porém, a realidade
apresentada no estudo de caso é apenas local (Europa), podendo haver grande diferença,
caso haja aplicação do framework em outros contextos. Além disso, todo o processo
poderia ser sistematizado, facilitando sua implementação, que inclusive, segundo o
autor, pode ser complexa, caso hajam inúmeros objetivos em um projeto.
Em seu trabalho, Tianyin (2011) apresenta uma visão geral sobre a gerência de
riscos e cita alguns modelos de processos de gerenciamento de riscos. Há uma detalhada
descrição de padrões, modelos e normas relacionados ao gerenciamento de riscos desde
os anos 80 e citando os principais nomes e técnicas definidas na área. Apesar da lista de
modelos de processos apresentada ser bastante diversificada, não há um detalhamento
das práticas, também não são apresentados mapeamentos entre os modelos, a fim de
concluir quais vantagens e desvantagens de cada um.
Esta pesquisa destaca-se dos trabalhos relacionados, pois apresenta uma
metodologia para implantação da gestão de riscos embasada nas versões mais atuais dos
modelos de qualidade de software, através da identificação de boas práticas comuns
encontradas no mapeamento entre estes modelos. Além disso o modelo de qualidade
que recebe maior atenção neste trabalho é o MR-MPS-SW, modelo nacional que possui
uma carência em estudos de mapeamentos relacionados a modelos de maturidade.
Este projeto tem o objetivo de propor uma metodologia abrangente para implantação da
Gerência de Riscos em uma organização desenvolvedora de software. A metodologia a
ser proposta deve agrupar boas práticas de Gerenciamento de Riscos constantes em
modelos e normas, porém estas práticas devem ser totalmente aderentes às exigências
do MR-MPS-SW, pois este projeto faz parte do escopo do Projeto SPIDER [OLIVEIRA
et al., 2010]. O Projeto SPIDER tem como objetivo criar um suíte ferramentais aderente
ao MR-MPS-SW para reduzir os custos de implementação deste modelo.
Para alcançar este objetivo, espera-se que o projeto contemple os seguintes
resultados: apresentação de como se dá o mapeamento da Gerencia de riscos entre os
principais modelos e normas de qualidade de software; especificação do conjunto de
boas práticas em Gerência de Riscos; definição do conjunto de técnicas e métodos
usados na implementação da gerência de riscos; proposição de um modelo de processo
de gerência de riscos; definição de um guia de entrevistas com Gerentes de Projetos,
bem como a extração de seus resultados; elaboração e execução de experimento
controlado para ratificar e consolidar a metodologia proposta; o desenvolvimento de
software de apoio à gerencia de riscos, aderente à metodologia definida.
6. Agradecimentos
Este trabalho recebe o apoio financeiro da CAPES a partir da concessão de bolsa
institucional de mestrado ao PPGCC-UFPA. Este projeto é parte do Projeto SPIDERUFPA.
Referências
ABNT - Associação Brasileira De Normas Técnicas, (2009) “NBR ISO/IEC
12207:2009 - Engenharia de Sistemas de Software - Processos de Ciclo de Vida de
Software”.
23
WTDQS 2014
Avdoshin, S. M., Pesotskaya, E. Y. (2011) "Software risk management". 7th Central and
Eastern European Software Engineering Conference (CEE-SECR).
Boehm, B. (1991) "Software risk management: principles and practices". IEEE
Software, 8, 1 , p. 32 - 41
Brooks, F. P. (1986) "No Silver Bullet — Essence and Accident in Software
Engineering". In: IFIP Tenth World Computing Conference, p. 1069–1076.
Chapman C. B., Ward, S.C. (2003) "Project Risk Management, Processes, Techniques
and Insights". 2ª Edição. John Wiley. Chichester. Reino Unido.
Glass, R. L. (1998) "Software Runaways: Monumental Software Disasters", PrenticeHall.
Humphrey, W. S. (1989) "Managing the Software Process, The SEI Series in Software
Engineering". Addison-Wesley.
IEEE - Institute of Electrical and Electronics Engineers (2006). "ISO/IEC 16085 - IEEE
Std 16085-2006 - Systems and software engineering - Life cycle processes - Risk
management". USA.
IEEE - Institute of Electrical and Electronics Engineers (2014). "Guide to Software
Engineering Body of Knowledge - SWEBOK". Version 3.0. USA.
Islam, S. (2011) "Software development risk management model-a-goal-driven
approach". Tese (Doutorado em Ciência da Computação), Institute für Informatik,
Technische Universität München, Munique.
Mutafelija, B., Stromberg, H. (2009) "Process Improvement with CMMI v1.2 and ISO
Standarts". CRC Press, 2009.
Oliveira, S. R. B. et al. (2010) “SPIDER - Um Suite de Ferramentas de Software Livre
de Apoio à Implementação do modelo MPS.BR”. Anais do VIII Encontro Anual de
Computação – ENACOMP 2010, Catalão - GO.
PMI - Project Management Institute (2013) "A Guide to the Project Management Body
of Knowledge". Campus Boulevard, Newton Square, 5th Edition.
Pressman, R. S. (2011) “Engenharia de Software: Uma Abordagem Profissional”.
Mcgraw Hill.
Raz, T., Hillson, D. (2005) "A comparative review of risk management standarts". Risk
Management: An International Journal, v.7, n.4, p. 53-66.
Ropponen, J., Lyytinen, K. (2000) "Components of Software Development Risk: How
to Address Them?". IEEE Transactions on Software Engineering, v. 26, p.98-111.
SEI - Software Engineering Institute (2010) "Capability Maturity Model Integration
(CMMI) for Development". , Version 1.3, Carnegie Mellon, USA.
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro (2012)
"Melhoria do Processo de Software Brasileiro (MPS.BR) - Guia Geral 2012". Brasil.
"Avaliações MPS-SW (Software) Publicadas (prazo de validade: 3 anos)".
Disponível
em
http://www.softex.br/wp-content/uploads/2013/07/2AvaliacoesMPSSW-Publicadas_29.JAN_.2014_5331.pdf. Acesso em 02 de fevereiro de 2014.
Sommerville, I. (2007) "Engenharia de Software". 8 ed. São Paulo. Pearson AddisonWesley.
Tianyin, P. (2011) "Development of software project risk management model review".
2nd International Conference on Artificial Intelligence, Management Science and
Electronic Commerce (AIMSEC), p. 2979-2982.
Travassos, G. H., Gurov, D., Amaral, E. A. G. (2002). "Introdução à Engenharia de
Software Experimental". Programa de Engenharia de Sistemas e Computação.
COPPE/UFRJ. Relatório Técnico RT-ES-590/02.
Van Lamsweerde, A. (2009). " Requirements Engineering: From System Goals to UML
Models to Software Specifications", Wiley.
Von Wangenheim, C. G., Da Silva, D. A., Buglione, L., Scheidt, R., Prikladnicki, R.
(2010). "Best practice fusion of CMMI-DEV v1.2 (PP, PMC, SAM) and PMBOK
2008." Information and Software Technology, 52, p. 749-757.
24
Proposta de um Modelo para Mapear a Transparência no
Processo de Software
Fernando C. Lima1, José A. Fabri1
Programa de Pós-Graduação em Informática (PPGI) - Universidade Tecnológica
Federal do Paraná (UTFPR)
Cornélio Procópio – PR – Brasil
1
Abstract. This research presents a proposed model for mapping the
transparency of the software's process. The bibliographic references that
supports the model consists of theories inherent transparency, transparency
software, software and mind mapping process. The proposal joins the idea of
pharmaceutical inserts, normalized by the National Health Surveillance
Agency Sanitary - ANVISA to the concepts of mental maps, proposed by Tony
Buzan. Through conducting two experiments, the research shows how the
adoption of the model can raise the transparency in the software process.
Resumo. Esta pesquisa apresenta a proposta de um modelo para mapear a
transparência no processo de software. O referencial bibliográfico que
embasa o modelo é composto das teorias inerentes à transparência,
transparência de software, processo de software e mapas mentais. A proposta
une a ideia de bulas de medicamentos, normatizada pela Agência Nacional de
Vigilância Sanitária – Anvisa aos conceitos de mapas mentais, propostos por
Tony Buzan. Por meio da realização de dois experimentos, a pesquisa mostra
como a adoção do modelo pode elevar a transparência no processo de
software.
1. Caracterização do problema
Atualmente a transparência tem sido almejada pela sociedade forçando a iniciativa
pública e privada a redefinir sua forma atual de trabalho para atingir este objetivo.
Cappelli, Leite e Araújo (2010) relatam que diversas iniciativas têm sido
realizadas no sentido de atendimento destas necessidades. Exemplos como o portal da
transparência dos gastos públicos fornecido pelo governo federal do Brasil, podem ser
citados de forma a corroborar com o relatado por tais autores.
Porém de acordo com Baía e Braga (2013), “A transparência é um princípio
democrático que permite aos cidadãos buscarem informações sobre fatos e processos”,
assim, o conceito de transparência pode ser definido como algo mais abrangente do que
a demonstração de informações referentes às receitas e despesas. Seguindo a ideia
apresentada pelos autores Tu, Thomborson e Tempero (2011), o termo transparência
também deve refletir a clareza dada aos processos de tomada de decisão de uma
determinada instituição, além da disponibilização das demais informações.
Com o objetivo de elevar a transparência no processo de software, um modelo de
mapeamento será proposto. O modelo fará uso dos mapas mentais seguindo uma
25
WTDQS 2014
estrutura similar àquela utilizada atualmente nas bulas de medicamento.
2. Fundamentação teórica
2.1. Transparência em Software
A palavra transparência tem origem no termo “transparentia” do latim, relacionada ao
verbo “transparere”, que significa “mostrar a luz através, deixar a luz atravessar”. O
vocábulo é formado pelo prefixo “trans” que significa “através”, unido do sufixo
“parere”, que significa “aparecer, chegar à vista”.
Leite e Cappelli (2008) afirmam que um software é transparente se as
informações com as quais ele trabalha forem transparentes e se o software por si próprio
também for transparente, informando como trabalha, o que faz e porque o faz
2.2. Processos de Software
Um dos princípios básicos da engenharia de software é possuir um processo de
produção claro, conciso e consistente que prime, principalmente, pelas questões ligadas
a qualidade e produtividade.
Segundo Pádua Filho (2009) um processo é qualificado como um conjunto de
atividades, parcialmente, ordenadas constituídas por métodos, práticas e transformações,
usadas para atingir uma determinada meta. O processo pode ser visto como uma receita
que é seguida por um projeto, sendo assim, o projeto é considerado uma instanciação do
processo. Peters e Pedrycz (2001) apresentam o processo como uma sequência de
atividades que produzem vários documentos, culminando em um produto satisfatório
que possa ser utilizado pelo consumidor. No caso de um processo de software, o
produto é classificado como um programa executável.
2.3. Mapas Mentais
Herman e Bovo (2005) definem que “um mapa mental é essencialmente um diagrama
hierarquizado de informações, no qual podemos facilmente identificar as relações e os
vínculos entre as informações”. O mapa mental facilita a interpretação das palavras,
imagens, números e conceitos lógicos de maneira clara, concisa e consistente1 (BUZAN,
2009).
Seguindo o exemplo dado por Buzan (2005), um mapa mental elementar para
planejar as atividades de um determinado dia poderia ter a seguinte aparência:
Figura 1 – Exemplo de Mapa Mental para o Planejamento Diário
Cada ramo que se desenvolve a partir do centro tem relação com diferentes
tarefas que precisam ser realizadas hoje, como por exemplo telefonar para o encanador
ou fazer compras no mercado (BUZAN, 2005).
1 Esta definição justifica a inserção dos mapas na composição do modelo proposto neste trabalho.
26
3. Proposta do Modelo
O objetivo deste trabalho é propor um modelo para mapear a transparência tanto do
processo quanto do produto de software. O artefato que será produzido contendo o
mapeamento será denominado bula de software. A seguir segue um fragmento de bula
não instanciada tanto do produto como do processo:
Figura 2 – Fragmento da bula não instanciada com foco no produto de software
Figura 3 – Fragmento da bula não instanciada com foco no processo
A estrutura de tópicos da bula de produto foi elaborada com base no modelo
antigo de bulas. O segundo modelo de bula, aquele focado no processo, em atendimento
às mudanças promovidas pela RDC 140/2003 utiliza-se do modelo atual de bulas.
4. Metodologia e estado atual do trabalho
4.1. Metodologia
De acordo com Contó et al. (2012) a metodologia de pesquisa experimental realiza
testes por meio de um experimento controlado com o objetivo de produzir dados para
serem analisados. Segundo o mesmo autor, para utilizar o referido método é necessário
executar as atividades de definição da hipótese, concepção do protocolo experimental,
execução do experimento e análise dos resultados.
Este trabalho procura validar a hipótese de que a transparência no processo de
software, quando mapeada seguindo o modelo proposto, poderá ser elevada. Para
validar tal hipótese, serão necessários dois experimentos.
No primeiro deles, a bula das funcionalidades de um determinado software será
elaborada e apresentada a um grupo, e posteriormente, um questionário focando os
aspectos apresentados pela bula será aplicado. No segundo experimento, a bula de uma
das atividades do processo será elaborada e apresentada para um segundo grupo, o qual
também deverá responder um questionário focando os aspectos da atividade mapeada
pela bula. Para a realização de ambos os experimentos, o protocolo experimental foi
estruturado de forma a contemplar os seguintes itens:
•
Definição do ambiente;
•
Definição das entidades envolvidas;
27
WTDQS 2014
•
Caracterização das entidades;
•
Definição da amostra;
•
Definição da forma de coleta das informações.
No quadro abaixo é possível visualizar a definição do protocolo experimental do
primeiro experimento:
Tabela 1. Protocolo do Experimento com Foco na Transparência do Produto
Item
Definição
Definição do ambiente
Campo do conhecimento. O experimento será realizado nas empresas
onde os clientes do software trabalham.
Definição das entidades
Apenas pessoas físicas participarão do experimento.
Caracterização das entidades
Pessoas de ambos os sexos, com formação em diversas áreas que
trabalham em diferentes empresas.
Definição da amostra
24 pessoas. Serão elaboradas 4 bulas de 4 produtos.
Definição da forma de coleta
Aplicação de um questionário contendo 10 questões focando as
funcionalidades do software.
O protocolo que será utilizado na realização do segundo experimento é similar
àquele utilizado pelo primeiro, porém diferencia-se no tipo de bula de software que será
aplicada, o que justifica a necessidade de dois experimentos distintos para validar a
hipótese defendida por este trabalho.
No quadro a seguir é possível visualizar o protocolo que será utilizado no
segundo experimento:
Tabela 2. Protocolo do Experimento com Foco na Transparência do Processo
Item
Definição
Definição do ambiente
Campo do conhecimento. O experimento será realizado com os
estudantes da turma do ano de 2014 do Programa de Pós-Graduação em
Informática – PPGI da Universidade Tecnológica Federal do Paraná –
UTFPR – Campus de Cornélio Procópio.
Definição das entidades
Apenas pessoas físicas participarão do experimento.
Caracterização das entidades
Pessoas de ambos os sexos, com formação em computação ou áreas
afins que trabalham em diferentes empresas de software.
Definição da amostra
33 pessoas.
Definição da forma de coleta
Será aplicado um questionário contendo 10 questões focando os
aspectos de uma das atividades do processo de um determinado
software.
Em termos das ferramentas que serão utilizadas no experimento, a aplicação de
ambos os questionários será realizada utilizando-se da ferramenta para criação de
questionários da plataforma Google chamada GoogleForms. Para a elaboração dos
mapas mentais das bulas de software, a ferramenta FreeMind será utilizada. O uso de tal
ferramenta se justifica pelo fato de ser gratuita e de simples utilização, além de permitir
a exportação do mapa mental para o formato textual, possibilitando assim a geração da
bula no formato convencional.
28
4.2. Estado Atual do Trabalho
Parte do primeiro experimento já foi realizada, onde o foco foi a transparência do
produto. A bula das funcionalidades de um software foi elaborada por 2 analistas de
sistemas da empresa Lima Software e apresentada a um grupo de 6 pessoas. Após
analisarem a bula por um tempo de 30 minutos, foi solicitado a cada um deles que
respondessem a um questionário com 10 questões. Ainda é necessário que o
procedimento ocorra novamente envolvendo 18 pessoas, onde a bula de mais 3 software
serão elaboradas.
Para a realização do segundo experimento, cujo foco será a transparência em
relação ao processo, a bula dos aspectos de uma das atividades do processo de software
será elaborada por 2 analistas da mesma empresa. Em seguida, um grupo de 33 pessoas
receberão a bula para ser analisada por um período de 30 minutos. Em seguida, será
solicitado a cada um dos participantes que responda a um outro questionário contendo
10 questões focadas nos aspectos da atividade mapeada.
5. Trabalhos relacionados
A busca por transparência no processo de software é abordada por trabalhos nas esferas
nacionais e internacionais. Tu, Thomborson e Tempero (2011) caracterizam o termo
transparência com o objetivo de melhorar a comunicação entre as partes envolvidas no
projeto de software. Em âmbito nacional é possível citar trabalhos como o apresentado
por Leite e Cappelli (2008) o qual caracteriza a transparência como um requisito não
funcional de um projeto de software.
A ideia de propor um modelo para mapear a transparência no processo de
software surgiu a partir do trabalho realizado por Leal et al. (2012). Neste trabalho,
intitulado “Bula de Software: Uma Estrutura Definida para Promover a Melhoria da
Transparência em Software”, o autor trata da especificação de um modelo de
documentação chamado bula de software que organiza as informações de um software a
partir de questões técnicas e de utilização, o qual influenciaria no requisito de
transparência.
6. Resultados esperados
Espera-se que os resultados obtidos com a adoção deste modelo impactem na área de
gestão e processo de produção, além de atingir diretamente o produto de software
gerado por tal processo, elevando a transparência de ambos. Vide figura 2:
Figura 4 – Áreas que Podem ser Impactadas com a Adoção da Transparência
29
WTDQS 2014
7. Referências
Baía, Joás W.; Braga, José L. Uso de Sinônimos na Identificação de Atributos
deTransparência. Workshop em Engenharia de Requisitos, Montevideo, Uruguay,
abr. 2013.
Buzan, Tony. Mapas mentais e sua elaboração: um sistema definido de pensamento que
transformará a sua vida. São Paulo: Cultrix, 2005.
Buzan, Tony. Mapas Mentais: métodos criativos para estimular o raciocínio e usar ao
máximo o potencial do seu cérebro. Rio de Janeiro: Sextante, 2009.
Campos, Rosana; Paiva, Denise; Gomes, Suely. Gestão da informação pública: um
estudo sobre o Portal Transparência Goiás. Revista Sociedade e Estado. Brasília, v.
28, n. 2, ago 2013. Disponível em: <http://www.scielo.br/scielo.php?
script=sci_arttext&pid=S0102-69922013000200012&lng=en&n rm=iso>. Acesso
em 06/12/2013.
Cappelli, Claudia; Leite, Julio C. S. do P.; Araújo, Renata M. A importância de um
Modelo de Estágios para avaliar Transparência. Revista TCMRJ, Rio de Janeiro, n.
45,
set.
2010.
Disponível
em:<http://www.tcm.rj.gov.br/Noticias/4916/RevTCMRJ45.pdf>. Acesso em: 13
jan. 2014.
Contó, José A. P. et al. Metodologias de Modelagem de Requisitos: KAOS x Mapas
Mentais. CISTI'2012 - 7ª Conferencia Ibérica de Sistemas y Tecnologías de
Información, Madrid, Espanha, jun. 2012.
Filho, Wilson de P. P. Engenharia de software: fundamentos, métodos e padrões. 3. ed.
Rio de Janeiro: Ltc, 2009.
Hermann, Walther; Bovo, Viviani. Mapas Mentais Enriquecendo Inteligências:Manual
de Aprendizagem e Desenvolvimento de Inteligências: captação, seleção,
organização, síntese, criação e gerenciamento de conhecimentos. 2. ed. Campinas:
Walther Herman, 2005.
Leal, André L. de C. et al. Bula de Software: Uma Estrutura Definida para Promover a
Melhoria da Transparência em Software. XV Workshop on Requirements
Engineering - WER2012, Buenos Aires, Argentina, abr. 2012.
Leite, Julio C.S. do P.; Cappelli, Claudia. Exploring i* Characteristics that Support
Software Transparency. 3rd International i* Workshop, Recife, fev. 2008.
Peters, James F.; Pedrycz, Witold. Engenharia de Software: Teoria e Prática. Rio de
Janeiro: Campus, 2001.
Tu, Yu-Cheng; Thomborson, Clark; Tempero, Ewan. Illusions and Perceptions of
Transparency in Software Engineering. 18th Asia-Pacific Software Engineering
Conference, Ho Chi Minh, Vietnam, dec. 2011.
30
Uma Proposta de Medidas de Qualidade para Avaliação da
Confiança em Sistemas Ubíquos
Andressa Bezerra Ferreira1,2,a, Reinaldo Bezerra Braga 1, Rossana Maria de
Castro Andrade1,2,b
1
2
Grupo de Redes de Computadores, Engenharia de Software e Sistemas (GREat)
Mestrado e Doutorado em Ciência da Computação (DC), Universidade Federal do
Ceará (UFC)
{andressaferreira, reinaldo, rossana}@great.ufc.br
Abstract. Ubiquitous systems use information from user current activities to
provide important services. These information lead to several questions,
mainly related to system trustability. Therefore, the trust evaluation becomes a
major issue to adopt these systems. The evaluation can be made through
measures that characterize the system based on security, privacy, awareness
and control. Furthermore, specific features of ubiquitous systems, such as
context sensitivity, must be taken into account to evaluate the trustability.
Hence, this study aims to propose a series of measures to evaluate the
trustability of ubiquitous systems. These measures will be evaluated through
three case studies.
Resumo. Sistemas ubíquos utilizam informações do contexto atual do usuário
para prover serviços relevantes. O uso dessas informações gera
questionamentos, principalmente relacionados à confiança do sistema.
Portanto, avaliar a confiança se torna então um elemento essencial para a
adoção desses sistemas. A avaliação pode ser feita por meio de um conjunto
de medidas que buscam caracterizar o sistema em função do seu grau de
segurança, privacidade, consciência e controle. Além disso, é importante
destacar que características específicas dos sistemas ubíquos, como
sensibilidade ao contexto, sugerem que novas medidas sejam definidas para
avaliação da confiança. Assim, o objetivo deste estudo é propor um conjunto
de medidas para avaliação da confiança em sistemas ubíquos. Essas medidas
serão avaliadas em três estudos de casos.
1.
Caracterização do Problema
Os sistemas ubíquos representam o conceito de computação em todo lugar e a qualquer
momento [Yau et al. 2002]. Para tanto, este tipo de sistema pode ser sensível ao contexEste trabalho é resultado parcial do projeto Maximum, processo INC-0064-00012.01.00/12, suportado pela
FUNCAP.
a Bolsista de mestrado do MDCC/UFC, financiada pela CAPES
b Bolsista do CNPq de Prod. em Des. Tecn. e Extensão Inovadora (DT) 2, processo 314021/2009-4
31
WTDQS 2014
to, o que implica na captura de informações sobre as circunstâncias nas quais o usuário
se encontra e, baseado em regras ou estímulos inteligentes, reagir provendo serviços
[Lima 2011] [Debashis e Amitava 2003].
Um exemplo de aplicação sensível ao contexto é um sistema de monitoramento
de quedas em pessoas com cuidados especiais. Utilizando, em tempo real, dados dos
sensores do dispositivo do usuário, que podem servir para representar seu atual
contexto, é possível detectar e alertar quedas.
Fazer com que aplicações percebam o contexto no qual o usuário está inserido é
fundamental para que a tomada de decisão seja a mais benéfica e adequada possível.
Porém, a obtenção das informações bem como seu uso por parte da aplicação acarreta
em questões não triviais: Como garantir que a informação contextual seja verdadeira e
realmente corresponda ao contexto atual do usuário? Como garantir que a informação
contextual não possa ser acessada por quem não tem permissão? Como garantir que a
informação contextual não foi comprometida?
O interesse da comunidade de computação na área de sistemas ubíquos tem
aumentado nos últimos anos. Porém, na maioria dos trabalhos relacionados à área de
avaliação da qualidade, as normas e técnicas usadas para a avaliação da confiança não
levam em consideração as diferenças entre sistemas convencionais e ubíquos (e.g.,
sensibilidade ao contexto, mobilidade e heterogeneidade).
Apesar da confiança ser uma importante questão, garanti-la é uma tarefa difícil,
pois poucos trabalhos apresentam uma definição detalhada de medidas de confiança,
principalmente em sistemas ubíquos. Portanto, definir quais medidas podem ser usadas
para avaliar a confiança em sistemas ubíquos ainda é um desafio aberto de pesquisa e,
sendo assim, a proposta de dissertação de mestrado objetiva propor medidas para
avaliação da confiança* em sistemas ubíquos. As medidas serão avaliadas através dos
estudos de caso, que fazem parte da metodologia Goal-Question-Metric (GQM).
2.
Objetivos
O objetivo geral deste trabalho é propor um conjunto de medidas para avaliar a
confiança em sistemas ubíquos. Para tanto, alguns objetivos específicos foram
definidos, a seguir: (i) investigação da possibilidade de adaptação de medidas existentes
para a definição de novas medidas, (ii) definição de novas medidas que completem as
lacunas deixadas pelas medidas já existentes.
3.
Fundamentação Teórica
Marc Weiser, considerado o pai da computação ubíqua, vislumbrou que, no futuro,
computadores habitariam os mais triviais objetos: etiquetas de roupas, xícaras de café,
interruptores de luz, canetas, entre outros [Stajano 2002]. Desta nova visão de interação
e convivência surge a capacidade de computadores agirem de forma “inteligente” no
ambiente no qual nos movemos.
*Confiança (trustability): é a garantia de que o sistema utilizará os dados pessoais coletados dos usuários de maneira
correta, sem intervenção de terceiros ou qualquer outro possível dano a informação [Santos 2013].
32
A computação sensível ao contexto remete à idéia de que os computadores podem tanto
perceber quanto reagir ao ambiente em que estão inseridos para facilitar as atividades
humanas [Loureiro et al. 2008].
Como citado na Seção 1, o desenvolvimento e a avaliação dos sistemas ubíquos
devem considerar os possíveis problemas de confiança acarretados pela sensibilidade ao
contexto e os riscos que o compartilhamento de determinadas informações podem
acarretar para a segurança e privacidade, sendo esses, fatores de impacto para a
confiança [Santos 2013].
Segundo [Santos et al. 2013], a confiança em um sistema ubíquo é a garantia de
que o sistema utiliza os dados pessoais coletados dos usuários de maneira correta, sem
intervenção de terceiros ou qualquer outro possível dano a informação.
Consequentemente, as questões estão diretamente relacionadas à segurança,
privacidade, consciência e controle. Ainda segundo [Santos el al. 2013], a confiança do
usuário em relação ao sistema pode ser avaliada por meio de medições.
Uma medição consiste no processo contínuo de definição, coleta e análise de
dados sobre o processo de desenvolvimento de software e seus produtos, a fim de
entender e controlar o processo e seus produtos, fornecendo informações significativas
com o objetivo de melhorá-los [Solingen and Berghout 1999]. O resultado da medição é
chamado de medida. De acordo com a [ISO 25010], uma medida de qualidade é
definida como uma variável a qual é atribuído um valor como o resultado da medição
[ISO 25010], as medidas quantitativas são também chamadas de métricas. O conjunto
de propriedades de um produto de software, pelas quais a qualidade pode ser descrita e
avaliada é chamado de característica [ISO/IEC 2001]. A característica pode ser refinada
em múltiplos níveis chamados de subcaracterísticas.
De acordo com o modelo de qualidade encontrado em [Santos et al. 2013], o
conjunto de subcaracterísticas que impactam na característica Confiança do usuário com
relação ao sistema pode ser dividido em: segurança, privacidade, controle e consciência.
A avaliação desse conjunto de subcaracterísticas, consequentemente a avaliação
da confiança, é um elemento essencial para a adoção dos sistemas ubíquos [Santos
2013], essa avaliação pode ser feita através de um conjunto de medidas de qualidade. A
metodologia para definição de medidas adotada neste trabalho é a Goal-QuestionMetric (GQM), baseada na premissa de que as medições de software devem ser
orientadas a objetivos [Basili et al 2002].
4.
Metodologia e Estado Atual do Trabalho
A metodologia a ser empregada no trabalho de mestrado foi dividida da seguinte forma:
(i) realização de revisões bibliográficas (ii) definição de medidas de confiança, e (iii)
realização de estudos de caso com GQM.
Ao longo da pesquisa, será utilizada a metodologia GQM como suporte para as
etapas (ii) e (iii). A idéia básica do GQM [Basili et al. 2002] é derivar medidas de
software a partir de perguntas e objetivos. Essa técnica foi escolhida por ter sido
utilizada para a definição das medidas da ISO 25000, usadas como base para a definição
das medidas deste trabalho, além de ser bastante difundida na literatura e pelo
conhecimento já existente no grupo de pesquisa GREat onde este trabalho está sendo
desenvolvido.
33
WTDQS 2014
Para os processos de realização dos estudos de caso, extração de medidas e
coleta de resultados, três aplicações serão levadas em consideração: um guia de visitas
móveis sensível ao contexto, produto de uma Linha de Produto de Software Sensível ao
Contexto chamada Mobiline, desenvolvida pelo grupo GREat e que pode ser encontrada
em [Marinho et al. 2012]; um sistema de estacionamento ubíquo chamado SFPark
(http://sfpark.org/); e um sistema médico para auxiliar idosos. Atualmente o trabalho
está na fase de definição de medidas por meio do GQM, posteriormente serão realizados
os estudos de caso citados.
5.
Trabalhos Relacionados
O processo de identificação dos trabalhos que propõem medidas de confiança para
sistemas ubíquos foi feito por meio de revisões bibliográficas considerando as bases
eletrônicas ACM e IEEE, e os trabalhos de pesquisa realizados pelo laboratório GREat
na Universidade Federal do Ceará. No primeiro momento, com buscas por palavraschave (sistemas ubíquos, sistemas pervasivos, computação ubíqua, computação móvel,
computação pervasiva, qualidade de software, qualidade de software em sistemas
ubíquos, segurança, confiança, segurança em sistemas ubíquos, confiança em sistemas
ubíquos, trust, dependability).
Os principais e mais completos trabalhos, em relação à definição de medidas
para avaliação da confiança, foram [Ranganathan et al. 2005], [Kemp et al. 2008], [AbiChar et al. 2010], [Stajano, 2002] e [Lee e Yun 2012] estando estes, diretamente
relacionados à segurança, [Scholtz e Consolvo 2004], [Sun e Denko 2008],
[Langeheinrich, 2001] e [Jia et al. 2009] tendo destaque relevante em relação à
privacidade, e os trabalhos de [Nixon, 2005] e [Santos et al. 2013], abordando de
maneira mais direta a avaliação da confiança em sistemas ubíquos.
Os trabalhos citados anteriormente propõem medidas de qualidade associadas às
características e subcaracterísticas estudadas neste trabalho, porém, a falta de funções de
medição para as medidas definidas representam uma desvantagem que esta pesquisa
pretende solucionar. De acordo com [Ranganhatan, 2005], a lista de medidas
encontradas contribuem de maneira significativa para lidar com a ambiguididade e gerar
mais clareza no processo de avaliação da confiança em sistemas ubíquos, representando
assim uma vantagem dos trabalhos relacionados, mas, segundo o autor, não são
suficientes.
Há também necessidade de outros estudos de caso que possibilitem a coleta e
interpretação das medidas, a interpretação consiste em analisar os dados coletados e
elaborar relatórios dos resultados encontrados.
6.
Resultados Esperados e Trabalhos Futuros
Como resultado esperado da dissertação de mestrado espera-se um conjunto de medidas
de qualidade para a avaliação da confiança em sistemas ubíquos. Para o sistema de
detecção de quedas, por exemplo, apresentado na Seção 1, podemos avaliar, entre
outras, as medidas a seguir, adaptadas para esse tipo de sistema:
34
Tabela 1: Medidas para a Avaliação da Confiança em Sistema de Detecção e Alerta de Quedas
ID
Nome
Descrição
Função de Medição
Interpretação
M1
Sensibilidade
Capacidade
quedas
de
detectar
Positivos ÷ (Positivos +
Falsos Negativos)
Quanto
mais
próximo de 100%,
melhor
M2
Precisão
Capacidade de
somente quedas
detectar
Negativos ÷
(Negativos + Falsos
Positivos)
Quanto
mais
próximo de 100%,
melhor
Onde: Positivos: uma queda ocorreu e o sistema detectou. Negativos: não ocorreu queda e o sistema não detectou.
Falsos Positivos: não ocorreu queda, mas o sistema detectou. Falsos Negativos: Ocorreu queda mas o sistema não
detectou.
O próximo passo é realizar reuniões e estudos de caso GQM com o intuito de
definir as medidas para a avaliação da confiança em sistemas ubíquos. Os trabalhos
futuros para a continuação, conclusão e aprimoramento deste trabalho são: (i) propor
medidas de qualidade para a característica confiança e suas subcaracterísticas; (ii)
avaliar a qualidade das medidas por meio de requisitos de qualidade para medidas.
7.
Referências
Abi-Char, P., Mhamed, A., El-Hassan, B. and Mokhtari, M. (2010). “A Flexible Privacy
and Trust Based Context-Aware Secure Framework”. In Lecture Notes in Computer
Science.
Basili V., Caldiera G.. The Goal Question Metric Approach, 2002.
Davis, A., Overmyer, S. ; Jordan, K. ; Caruso, J. ; Dandashi, F. ; Dinh, A. ; Kincaid,
G. ; Ledeboer, G. ;Reynolds, P. ; Sitaram, P. ; Ta, A. ; Theofanos, M. Identifying and
Measuring Quality in a Software Requirements
Specification, Proc. 1st Intl.
Software Metric Symposium, IEEE, Baltimore, MD, 1993, pg. 141-152
Debashis S., Amitava M., "Pervasive Computing: A Paradigm for the 21st Century,"
Computer, pp. 25-31, March, 2003
ISO/IEC 25010 (2011). “Software Engineering - Software Product Quality
Requirements and Evaluation (New SQuaRE)
ISO/IEC 9126 (2001).“Software Engineering – Product Quality – Part 1”
Jia, L., Collins, M. and Nixon, P. (2009). “Evaluating Trust-Based Access Control for
Social Interaction”. In 3rd International Conference on Mobile Ubiquitous
Computing, Systems, Services, and Technologies, UBICOMM 2009, Ieee.
Kemp, E. A., Johnson, R. S. and Thompson, A.-J. (2008). “Interface Evaluation for
Invisibility and Ubiquity: An Example from E-learning”. In 9th ACM SIGCHI New
Zealand Chapter’s International Conference on Human-Computer Interaction:
Design Centered HCI. . ACM.
35
WTDQS 2014
Langeheinrich M., Privacy by Design – Principles of Privacy Aware Ubiquitous
Systems, in UBICOMP 2001, LNCS 2201, pp 273 291
Lee, J. and Yun, M. H. (2012). “Usability Assessment for Ubiquitous Services:
Quantification of the Interactivity in Inter-Personal Services”. In IEEE International
Conference on Management of Innovation & Technology (ICMIT). . Ieee.
Lima, F. F. P., Rocha, L. S., Maia, P. H. M. and Andrade, R. M. C. (2011). “Uma
Arquitetura Desacoplada e Interoperável para Coordenação em Sistemas Ubíquos”.
In Software Components, Architectures and Reuse (SBCARS)
Loureiro E., Ferreira G., Almeida H., Perkusich A., Pervasive Computing: What Is It
Anyway? Ubiquitous Computing: Design, Implementation and Usability.
Information Science Reference, 2008, p. 9-36.
Nixon P A , W. Wagealla, C. English, S. Terzis, Security, Privacy and Trust Issues in
Smart Environments,The Global and Pervasive Computing GroupDepartment of
Computer and Information Sciences University of Strathclyde, Glasgow, Scotland,
2005.
Ranganathan, A., Al-Muhtadi, J., Biehl, J., Ziebart, B., Campbell, R. H., Bailey, B.
(2005). “Towards a Pervasive Computing Benchmark”. In Third IEEE International
Conference on Pervasive Computing and Communications Workshops. . Ieee.
Santos M. R., Oliveira K. M., Andrade R. M. C., Santos I. S., Lima E. R.; “A Quality
Model
for Human-Computer Interaction Evaluation in Ubiquitous Systems” In:
6th Latin American Conference on Human Computer Interaction (CLIHC 2013).
Scholtz, J. and Consolvo, S. (2004). “Toward a Framework for Evaluating Ubiquitous
Computing Applications”. IEEE Pervasive Computing.
Stajano F., Security for Ubiquitous Computing, Wiley Press, 2002
Sun, T. and Denko, M. K. (2008). “Performance Evaluation of Trust Management in
Pervasive Computing”. In International Conference on Advanced Information
Networking and Applications, AINA. . Ieee.
Yau, S. S., Wang, Y. and Karim, F. (2002). “Development of Situation-Aware
Application Software for Ubiquitous Computing Environments”. In Computer
Software and Applications Conference.
Weiser M., The Computer for the Twenty-First Century, Scientific American, pp. 9410, September 1991.
36
Diagnóstico do Cenário Atual da Organização para
Implementação de Iniciativas de Melhoria de Processo de
Software
Patrícia Lima, 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
{patricia.lima, gleison.santos}@uniriotec.br
Abstract. Quality Models are adopted as a way to promote Software Process Improvement and to achieve other benefits expected. The lack of an easy and efficient way to identify potential problems in the development process often results
in inadequate diagnosis for software process improvement initiatives. There is also the need to support the prioritization of the identified problems. This paper
aims to establish an approach to characterize the organization’s current scenario,
identifying the deficiencies and indicating which process or MR-MPS-SW level is
the most indicated to be implemented in order to minimize or solve the existing
problems.
Resumo. Modelos de qualidade são cada vez mais adotados com a finalidade de
promover a melhoria de processo e alcançar outros benefícios esperados pelas
organizações. A falta de um instrumento de fácil utilização e eficiente para a
identificação dos problemas encontrados no processo de desenvolvimento resulta
muitas vezes em um diagnóstico inadequado para implementação de iniciativas
de melhoria. Há também a necessidade no auxílio de priorização do problema a
ser tratado caso muitos problemas forem identificados. Este trabalho tem o objetivo de definir uma abordagem para caracterização do cenário atual da organização identificando as deficiências existentes e, a partir desse diagnóstico, indicar que processo(s) ou nível MR-MPS-SW é mais indicado para a implementação, de forma a minimizar ou resolver os problemas existentes.
1. Introdução
A melhoria do processo envolve a compreensão dos processos existentes e posterior modificação a fim de influenciar a qualidade do produto e os controles para sua construção, como redução de tempo, custo e esforço de desenvolvimento. Muitas vezes, o caminho encontrado para guiar a melhoria de processos de software nas organizações passa pela adoção de
normas e/ou modelos de maturidade relacionados ao desenvolvimento de software. Dentre
as normas e modelos de maturidade mais conhecidos estão ISO/IEC12207 (2008), ISO/IEC
15504 (2003), CMMI-DEV (CMMI Product Team, 2010) e, no cenário nacional, o MRMPS-SW (SOFTEX, 2012), o modelo de referência para melhoria do processo de software
do Programa MPS.BR.
Pesquisas mostram que o esforço empregado nestas normas e modelos podem ajudar
na produção de software de maior qualidade, na redução de custo, tempo e aumento da produtividade. No entanto, a falta de uma estratégia eficaz de implementar com sucesso essas
normas ou modelos afeta o sucesso das iniciativas de melhoria de processos de software
(Niazi et al., 2005).
Existem modelos, como, por exemplo, o IDEAL (SEI, 1996), que fornecem um guia
para as organizações no planejamento e implementação de um programa efetivo de melho37
WTDQS 2014
ria de processo de software. Durante a fase de diagnóstico do cenário atual, são identificadas as necessidades e metas de negócios organizacionais, a cultura da organização, as metas
a serem atingidas com as iniciativas de melhoria, ou seja, o estado atual da organização e o
estado futuro desejado. Podemos chamar de baseline de processo cada um desses estados
mapeados. A partir destas informações é desenvolvida uma abordagem para a implementação de melhoria de processo de software na organização (SEI, 1996). Para se obter esta baseline do processo (estado atual dos processos da organização) é necessária a utilização de
recursos com conhecimento muito específico e muitas vezes é realizada uma avaliação de
aderência ao modelo de maturidade considerado. A execução dessa avaliação costuma ser
muito custosa e nem sempre evidencia os problemas existentes no processo de desenvolvimento.
Assim, o objetivo desse trabalho é definir uma abordagem para caracterização do cenário atual da organização e identificação das deficiências existentes no processo de desenvolvimento. A partir da análise dessas deficiências, indicar qual processo ou nível do MRMPS-SW é o mais indicado para que seja implementado pela organização, na tentativa de
minimizar ou resolver estes problemas.
Além desta introdução, este trabalho apresenta 5 seções. A seção 2 descreve a caracterização do problema. A seção 3 apresenta uma breve fundamentação teórica. A seção 4
descreve a metodologia de pesquisa e a situação atual do trabalho. A seção 5 apresenta trabalhos relacionados, e por fim, a seção 6 descreve os resultados esperados e considerações
finais.
Quando uma organização de software adota uma iniciativa de melhoria de processos de
software baseada em um modelo de maturidade, a principal decisão é selecionar a ordem de
implementação das áreas de processo que melhor atendem aos objetivos de negócio organizacionais. Uma escolha inadequada afeta negativamente o resultado das atividades, além de
reduzir o entusiasmo para a melhoria de processo. A escolha de um caminho que favoreça
iniciativas de melhoria precisa ser aderente ao ambiente de desenvolvimento, levando em
consideração as características do software que está sendo desenvolvido (Huang e Han,
2006).
A caracterização do cenário atual da organização e identificação de suas deficiências
não tem uma solução trivial. Os problemas do desenvolvimento de software muitas vezes não
são aparentes. A decisão sobre o nível ou o processo a ser adotado pode ser inadequado por não
endereçar os itens relevantes, na percepção das pessoas envolvidas no processo de desenvolvimento ou tomadores de decisão.
A realização de um diagnóstico, que consiste na identificação de problemas relacionados ao processo de desenvolvimento, além de difícil e trabalhoso, também requer um conhecimento muito específico sobre os modelos de melhoria de processos existentes e sobre engenharia de software. Apesar da existência de alguns instrumentos utilizados para a realização de
diagnósticos, existe a carência de instrumentos que utilize como base a análise das deficiências
encontradas no processo de desenvolvimento. E também, que seja simples o suficiente para que
possa ser executado por algum recurso da organização que tenha conhecimento em engenharia
de software mas tenha pouco conhecimento dos modelos de qualidade, no caso o modelo MRMPS-SW, e de rápida reprodutibilidade, não demandando muitas horas de esforço para ser executado.
Alternativas de diagnóstico existentes incluem a realização de entrevistas (mas não
há guias para nortear as entrevistas) ou simulação de uma avaliação (que pode ser muito
demorado ou complexo, principalmente se a organização não tiver processos estabelecidos
38
ou documentação disponível e representativa dos projetos para análise).
Os modelos de qualidade, através dos resultados esperados definidos em cada área de
processo, avaliam a execução dos processos utilizados pelas organizações e são capazes de detectar problemas associados ao processo de desenvolvimento. Utilizar esse conjunto de conhecimentos descritos nos modelos de qualidade para auxiliar na identificação dos problemas do
processo de desenvolvimento pode ser uma solução para auxiliar no diagnóstico do cenário
atual dos processos da organização.
Para iniciar projeto de planejamento de um processo de melhoria é necessário identificar qual
será o alvo da melhoria, quais processos ou atividades precisam ser melhorados. Para isso, é
necessário a identificação do cenário atual da organização. Existem alguns instrumentos que
auxiliam na identificação deste cenário, por exemplo, entrevistas, aplicação de questionários,
simulação de avaliação de modelo de maturidade, modelos de melhoria organizacional, entre
outros. Porém, a aplicação desses instrumentos pode ser muito custosa, pois é necessário um
conhecimento muito específico, profissionais qualificados ou contratação de consultoria para
avaliação, o que muitas vezes não é entendido pela organização como um investimento com alto
valor de retorno ao seu negócio.
Na fase do diagnóstico, o modelo IDEAL (SEI, 1996) baseia o plano de ação de melhoria de processos considerando a visão organizacional, plano estratégico de negócios, lições
aprendidas e até mesmo atividades de avaliação de modelos de maturidades estão previstas. O
objetivo é estabelecer uma baseline do processo organizacional. A baseline irá prover informações de como e quão bem a organização desempenha atualmente suas atividades de software.
Por sua característica de iteratividade as baselines principais fornecem uma fotografia dos vários processos e ações da organização em um certo ponto no tempo. O conhecimento dos pontos
fortes e oportunidades de melhoria é um pré-requisito essencial para identificação e priorização
de um programa de melhoria efetivo e eficiente (SEI, 1996).
Ainda durante a fase de diagnóstico, são desenvolvidos dois cenários dos processos da
organização, o estado atual e o estado futuro desejado. O produto primário desta fase é um relatório final de resultados e recomendações que é produzido como um resultado das atividades de
baseline. Outros produtos secundários podem ser revisões da visão organizacional e do plano de
negócios, que são alguns dos insumos desta fase (SEI, 1996).
A gap analysis, pode auxiliar a revelar áreas ou processos que precisam de melhorias. E também auxiliar no mapeamento dos problemas que podem ocorrer durante o processo de desenvolvimento, utilizando como fonte os resultados esperados dos modelos de
maturidades. Como produto deste mapeamento será apresentado um relatório com os processos ou resultados esperados mais críticos, de acordo com os problemas mapeados e adequados para possíveis indicações de iniciativas de melhoria de processo.
Durante a realização do mapeamento e análise é importante identificar características ou
problemas comuns ao processo de desenvolvimento que possam estar relacionados a diversos
processos ou resultados esperados. A utilização de procedimentos baseados no método
Grounded Theory (Strauss e Corbin, 1998), gerando uma teoria, no mapeamento e análise traria
benefícios perceptíveis nesta questão. Os resultados obtidos fornecerão as indicações dos problemas encontrados no processo atual e auxiliará na identificação do processo deficiente a receber ações de melhoria.
A Grounded Theory (GT, ou Teoria Fundamentada em Dados), consiste em um método
de pesquisa qualitativa que realiza uma análise profunda dos dados e identifica relações entre as
informações coletadas. Dados são sistematicamente coletados e analisados por meio do processo
de pesquisa gerando uma teoria. O objetivo da análise utilizando GT é o entendimento profundo
39
WTDQS 2014
do problema a ser analisado a partir da identificação de padrões e tendências, realizado por meio
do processo de codificação (Schots, 2010). Para realizar a codificação, são propostos três procedimentos (Strauss e Corbin, 1998): (i) Codificação aberta (open coding): processo analítico
onde são identificados os conceitos e categorias; (ii) Codificação axial (axial coding): processo
de relacionamento entre categorias formando explicações mais precisas sobre o fenômeno; (iii)
Codificação seletiva (selective coding): processo de integração e refinamento da teoria, organizando as categorias em torno de um conceito central.
Neste trabalho será utilizado o método de análise qualitativa, estruturado em algumas etapas
discutidas a seguir. O trabalho encontra-se atualmente na etapa 2 que consiste na elaboração de
prova de conceito do instrumento de gap analysis.
Etapa 1 – Identificação do modelo alvo da proposta: O modelo escolhido foi o MRMPS-SW por ser o modelo de referência nacional. Para identificação de trabalhos relacionados
que abordam a fase de diagnóstico, uma atividade muito comum na condução de iniciativas de
melhoria, foi utilizada uma revisão informal da literatura. Foi realizada uma análise exploratória
do modelo IDEAL (SEI, 1996) (realização de diagnósticos – gap analysis) e na estratégia de
execução de melhoria de processo SPI-KM (Santos et al., 2007). Nesta análise percebeu-se que
as técnicas de diagnósticos e as estratégias de implementação de melhorias podem ser complexas, custosas e requerem conhecimento muito específico. A proposição de um instrumento mais
simples para a realização do diagnóstico se faz necessário.
O instrumento de diagnóstico proposto neste trabalho inclui o mecanismo de diagnóstico e os procedimentos de análise dos resultados obtidos. O mecanismo de diagnóstico proposto,
bem como os procedimentos de análise dos resultados utilizam como base um método de análise
qualitativa baseado na Grounded Theory (GT).
Como insumo para identificação dos problemas de desenvolvimento (conceitos e categorias – codificação aberta) serão utilizados os guias de implementação do modelo MR-MPSSW e do CMMI-DEV (mesmo não sendo o modelo foco da análise, este modelo será utilizado
para que se tenha uma base rica de informações, neste caso, de problemas a serem mapeados),
além das planilhas utilizadas para avaliação do modelo MR-MPS-SW. Após a identificação
inicial dos problemas, será aplicado o processo de relacionamento entre as categorias identificadas (codificação axial) formando explicações mais precisas sobre o fenômeno estudado.
Etapa 2 – Elaboração de prova de conceito do instrumento de gap analysis: Inicialmente optou-se pela realização de uma prova de conceito escolhendo dois processos do modelo
MR-MPS-SW, porém no instrumento está previsto o mapeamento de todos os processos do
modelo. Os processos iniciais escolhidos foram Gerência de Requisitos (GRE) e Desenvolvimento de Requisitos (DRE), que são os processos relativos a requisitos e que pertencem, respectivamente, aos níveis G e D do MR-MPS-SW. Atualmente o trabalho encontra-se nesta fase e
como produto desta etapa está em elaboração o mapeamento dos problemas percebidos inerentes aos processos de GRE e DRE utilizando GT. Na figura 1 pode ser observado um exemplo do
mapeamento dos problemas identificados no processo de GRE, relacionado aos seus respectivos
resultados esperados e a sua fonte (Guia de Implementação do MR-MPS-SW, planilha de avaliação
MR-MPS-SW, Guia de Implementação CMMI-DEV), utilizando GT.
Etapa 3 – Avaliação preliminar do instrumento: Uma avaliação piloto considerando os
processos GRE e DRE com um profissional praticante dos processos selecionados, por exemplo, um
analista de sistemas, um gerente de projetos, com a finalidade de verificar se o mecanismo é de fácil
compreensão e entendimento, além de ser capaz de identificar os problemas apresentados no processo de desenvolvimento de software. A escolha desses papéis se deve ao conhecimento e percepção
de problemas comuns inerentes ao processo de desenvolvimento e aos processos do MR-MPS-SW.
40
Figura 1 – Exemplo de problemas mapeados no processo GRE do MR-MPS-SW utilizando GT
Etapa 4 – Extensão do instrumento para considerar todos os processos do MR-MPSSW: Evolução do instrumento proposto (mecanismo de diagnóstico e procedimento de análise)
com as devidas correções ou inclusões dos demais processos no instrumento. Uma vez encerrada as avaliações preliminares já descritas, o mecanismo de diagnóstico e os procedimentos de
análise serão completados para contemplar o restante dos processos do MR-MPS-SW
Etapa 5 – Avaliação do instrumento: Uma nova rodada de avaliações está prevista com
a participação de profissionais praticantes, especialistas e/ou organização de software de acordo
com os papeis relacionados aos processos em questão. E, finalmente, com base nesta avaliação,
evoluir o produto final do trabalho.
Etapa 6 – Proposta do instrumento final.
A estratégia de desenvolvimento de melhoria de processo SPI-KM (Santos et al., 2007) em sua
fase de diagnóstico, assim como no modelo IDEAL (SEI, 1996) e PmCOMPETISOFT (Pino et
al., 2010), procuram compreender as necessidades de negócio da organização e as atuais deficiências dos seus processos. Para esse diagnóstico é fundamental o mapeamento de problemas
recorrentes do desenvolvimento de software e que podem ser analisados e priorizados para a
indicação de um processo ou nível de maturidade para implementação da melhoria de processos.
Sunetnanta e Chortkiertikul (2012) propuseram um modelo de avaliação quantitativa do
CMMI para monitoramento de risco e do processo de qualidade de software na melhoria do processo
de software. Este modelo apresenta uma pontuação quantificada, em valor absoluto, pela observância dos resultados esperados em cada área de processo do CMMI em um projeto. Demonstrando que
é possível utilizar este modelo para auxiliar na redução de custo e esforço na implementação de melhorias de processo no ambiente de desenvolvimento através do monitoramento contínuo da qualidade e de riscos. E também, o resultado da avaliação quantitativa, gerada pelo modelo, pode ser utilizado como um programa de auto-avaliação, facilitando e guiando a interpretação e implementação
do CMMI antes do início de qualquer avaliação real.
Huang e Han (2006) propuseram um modelo de suporte a decisão gerencial que determina a prioridade das áreas de processo do CMMI a ser implementado pela organização, basea41
WTDQS 2014
do nas características do projeto que está sendo desenvolvido, ou seja, indica as áreas de processo do CMMI para inicializar o processo de melhoria de software.
Muñoz et al. (2013) propuseram um método que permite uma rápida avaliação interna do
desempenho dos processos de software de uma organização utilizando dois elementos chaves: melhores práticas executadas internamente na organização e objetivos de negócio definidos pela organização. Esse método de avaliação permite que as organizações executem de forma rápida e frequente avaliações de desempenho dos seus processos de negócios em um menor tempo e utilizando poucos recursos, deste modo a organização é capaz de obter uma baseline sólida relacionada às suas
necessidades de objetivos de negócio quando estiver implementando uma iniciativa de melhoria de
processos de software.
A proposta de caracterização do cenário atual utilizando os resultados esperados do
modelo MR-MPS-SW, apresentada neste trabalho, visa não só mapear os problemas de desenvolvimento associados aos resultados esperados mas também fornecer subsídios para a tomada
de decisão de por qual processo ou nível do MR-MPS-SW deve-se iniciar as iniciativas de melhoria de processo de software.
Com o trabalho proposto, espera-se auxiliar as organizações, orientando o trabalho dos implementadores do MR-MPS-SW e membros de organizações na implementação de melhorias de processos e
no diagnóstico dos processos atuais de uma organização, a partir da análise do cenário atual, facilitando a identificação do processo ou do nível do MR-MPS-SW mais indicado a ser implementado.
Outra contribuição relevante será a o mapeamento dos problemas comumente associados à
implementação dos processos de software. Além de auxiliar a empresa no aprendizado do modelo de
maturidade MR-MPS-SW.
Referências
CMMI Product Team (2010) CMMI for Development, Version 1.3 (CMU/SEI-2010-TR-033). Software
Engineering
Institute,
Carnegie
Mellon
University,
2010.
http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm
Huang, S., Han, W. (2006) “Selection priority of process areas based on CMMI continuous representation”, Information and Management 43 (2006), 297-307.
ISO/IEC (2003) "15504: Information Technology – Process Assessment." The International Organization
for the Standardization and the International Electrotechnical Commission.
ISO/IEC (2008) "ISO/IEC 12207: System and software engineering – Software life cycle processes", The
International Organization for the Standardization and the International Electrotechnical Commission.
Muñoz, M., Mejia, J., Calvo-Manzano, J. A., et al., (2013) “Method to Evaluate Process Performance Focused
on Minimizing Resistance to Change”, International Journal of Human Capital and Information Technology
Professiosnals (JHCITP), April-June 2013, pp. 1-15.
Niazi, M., Wilson, D., Zowghi, D. (2005) “A framework for assisting the design of effective software process
improvement implementation strategies”, The Journal of Systems and Software, vol. 78, pp. 204-222, 2005
Pino, F. J., Pardo, C., García, F., Piattini, M. (2010) “Assessment methodology for software process improvement in small organizations”, Information and Software Technology 52 (2010), pp. 1044-1061.
Santos, G., Montoni, M., Figueiredo, S., et al., (2007), "SPI-KM - Lessons Learned from Applying a Software
Process Improvement Strategy Supported by Knowledge Management", Product-Focused Software Process
Improvement.
Schots, N. (2010) “Uma Abordagem para a Identificação de Causas de Problemas Utilizando Grounded
Theory”, Dissertação (mestrado) UFRJ/COPPE.
SEI (1996) IDEAL. Disponível em www.sei.cmu.edu/library/assets/idealmodel.pdf
SOFTEX
(2012)
MPS.BR
Guia
Geral
MPS
de
Software.
Disponível
em
http://www.softex.br/mpsbr/guias/. Acesso em 01/12/2013.
Strauss, A., Corbin, J., 1998, “Basics of Qualitative Research: Techniques and Procedures for Developing
Grounded Theory”. 2 ed. London, SAGE Publications.
Sunetnanta, T. T., Choetkiertikul, M., 2012, “Quantitative CMMI Assessment for Software Process Quality and
Risk Monitoring in Software Process Improvement”, International Journal of Digital Content Technology
and its Applications (JDCTA), vol. 6, number 21, November 2012.
42
Facilitando a Aprendizagem Organizacional em Melhorias
de Processo de Software
Davi Viana1, Cleidson de Souza2, Tayana Conte1
1
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
2
Instituto Tecnológico Vale e Universidade Federal do Pará (UFPA), Belém – PA –
Brasil
{davi.viana, tayana}@icomp.ufam.edu.br, [email protected]
Abstract. Performing software processes improvements involves knowledgeintensive activities that might be new to the members of the organization.
Furthermore, such improvements should not be seen as a single effort, but an
evolutionary process requiring constant learning through the organization. In
that context, organizational learning can support collaborators in reaching
and achieving a better comprehension of relevant knowledge regarding
process improvement. In order to support software organizations aiming at
improving their development processes, this research presents the
development of a framework containing specific components for stimulating
organizational learning.
Resumo. Realizar melhorias nos processos de software envolve atividades
intensas de conhecimento que podem ser novas para os membros das
organizações. Além disso, as melhorias não devem ser vistas como um esforço
único, mas sim como algo evolutivo necessitando, assim, de constante
aprendizagem por toda a organização. Aprendizagem organizacional pode
auxiliar com que os conhecimentos importantes para as melhorias nos
processos sejam compreendidos e alcançados por todos os colaboradores.
Neste contexto, este trabalho apresenta o desenvolvimento de um framework
que contém componentes para estimular a aprendizagem organizacional em
organizações de software que buscam melhorar seus processos.
A aplicação das boas práticas de ES através de iniciativas de Melhoria de Processo de
Software (MPS) tem se tornado uma estratégia constante em organizações que buscam
aumentar a qualidade dos seus produtos (Montoni e Rocha, 2011). Essas melhorias são
ações executadas com o objetivo de evoluir os processos de software para que eles se
tornem mais alinhados aos objetivos de negócio da organização. Essas ações podem ser
executadas de acordo com as necessidades organizacionais ou podem seguir boas
práticas de ES promovidas pelos modelos de maturidade em MPS utilizados pela
Indústria de Software, como o Capability Maturity Model Integration for Development
- CMMI-DEV (Sei, 2010) e o Modelo de Referência de Melhoria de Processo de
43
WTDQS 2014
Software – MR-MPS-SW (Softex, 2012). Essas boas práticas podem contribuir para
aperfeiçoar o desenvolvimento de software com qualidade, aumentar a produtividade e
melhorar a vantagem competitiva das organizações (Santos, 2011).
Contudo, a implantação de iniciativas de Melhoria de Processo de Software não é
uma atividade trivial. É necessário manter, de forma balanceada, as três dimensões
críticas dos processos (Sei, 2010): (1) pessoas; (2) procedimentos e métodos; e, (3)
ferramentas. Em relação às pessoas é preciso garantir que tenham as capacidades
necessárias para realizar as atividades do processo, assim como pessoas capacitadas em
relação ao treinamento nesses processos e suas melhorias. Os procedimentos, métodos e
ferramentas também precisam ser aprendidos pelos colaboradores para garantir a
execução coerente dos processos.
Para que a melhoria de processos ocorra continuamente é necessário um
comprometimento com a aprendizagem (Garvin, 1994). A aprendizagem dos
conhecimentos necessários à melhoria de processos é relevante para que as melhorias
realmente sejam disseminadas e permaneçam vivas na organização (Almeida et al.,
2011). Para Ruhe (2001), a melhoria de processos é o objetivo de todas as Organizações
de Software de Aprendizagem. Além disso, a aprendizagem pode auxiliar na obtenção de
conhecimento necessário à indústria de software (Angkasaputra et al., 2003).
É necessário garantir que todos os membros da organização aprendam as
mudanças realizadas nos processos com a finalidade de ter sucesso nas implantações das
melhorias dos processos. Além disso, Travassos e Kalinowski (2013) apontam que há
uma correlação entre o aumento do número de colaboradores e execução de iniciativas
de MPS. Desta forma, é necessário garantir também que os novos colaboradores tenham
conhecimento suficiente para a execução dos processos. Em vista disso, o objetivo deste
trabalho consiste na definição de um framework que possibilite a promoção da
aprendizagem organizacional em melhorias de processo de software. Para isto, está se
realizando investigações sobre tecnologias (processos, técnicas, métodos, práticas e
ferramentas) que promovam a aprendizagem organizacional visando à melhoria de
processo de software. Estas investigações partem do ponto de vista dos profissionais das
organizações de software, visto que a execução de Melhorias de Processo de Software
depende do conhecimento humano e que as pessoas estão no centro do processo de
aprendizagem, pois são elas que criam e compartilham o conhecimento.
A aprendizagem organizacional e a Gerência do Conhecimento são visões
complementares do processo de tratamento do conhecimento. A Gerência do
Conhecimento é um facilitador da Aprendizagem Organizacional (Aurum et al., 2008).
Ao gerenciar o conhecimento, as organizações podem reagir melhor às demandas de
clientes e mercados, provendo resultados mais rápidos e com melhor qualidade
(Schneider, 2009). Os objetivos da gerência do conhecimento (GC) são coletar novos
conhecimentos, tratar esses conhecimentos de forma que seja possível uma futura
utilização, armazená-lo, disseminá-lo e, por fim, disponibilizar estratégias de aplicação
desses conhecimentos em novas situações (Schneider, 2009). Segundo Nonaka e
Takeuchi (1995), existem dois tipos de conhecimento que precisam ser gerenciados:
tácito e explícito. O conhecimento tácito é altamente pessoal e difícil de formalizá-lo,
44
sendo normalmente compartilhado de forma direta, por contato face a face (Ruhe, 2001).
Por outro lado, o conhecimento explícito ou codificado é considerado transmissível em
linguagem formal (ou semi-formal) e sistemática. O conhecimento explícito pode ser
representado por diversas formas, como documentos, relatórios, base de dados e lições
aprendidas (Nonaka e Takeuchi, 1995). Em ES, o conhecimento é representado de
diversas formas, como a documentação dos softwares, no próprio código fonte, nas
práticas e processos de desenvolvimento. Além disso, há o conhecimento que é trocado
através da socialização dos colaboradores.
Contudo somente gerenciar os tipos de conhecimento não é suficiente. É
necessário que esse conhecimento seja aprendido a nível organizacional, de forma que
agregue sucesso às atividades de desenvolvimento de software realizadas. A
aprendizagem é importante, pois considera as experiências e conhecimentos passados,
buscando não repetir os mesmos erros e evitando gastar recursos “reinventando a roda”
(Land et al., 2001). Além disso, a melhoria realizada no processo não deve ser vista
como esforço único, mas sim como algo evolutivo necessitando, assim, de constante
aprendizagem. A aprendizagem organizacional é uma abordagem que estimula a
aprendizagem individual, coleção do conhecimento e incentiva a criação de uma
infraestrutura para compartilhamento de conhecimento (Schneider, 2009). Para isso, os
membros da organização devem ser capazes de interpretar o conhecimento.
3. Metodologia e estado atual do trabalho
Visto que a pesquisa leva em consideração o ponto de vista dos colaboradores
envolvidos com atividades que demandam a aprendizagem de conhecimentos relevantes,
esta pesquisa está levando em consideração estudos de caso na indústria. Para o
propósito deste trabalho, definiu-se a metodologia de pesquisa apresentada na Figura 1.
Em seguida, as etapas a serem desenvolvidas nesta pesquisa são descritas.
1
2
3
4
Figura 1. Definição da Metodologia de Pesquisa
1. Execução do Mapeamento Sistemático da Literatura (Kitchenham et al., 2011): este
mapeamento visa à caracterização da área de pesquisa. Foram analisados os
45
WTDQS 2014
trabalhos disponíveis na literatura sobre aprendizagem organizacional em engenharia
de software e melhoria do processo de software que irão auxiliar na execução desta
pesquisa e na definição do framework proposto.
2. Condução de Estudos de Caso (Runeson e Höst, 2009): Os estudos de caso foram
executados paralelamente ao mapeamento sistemático da literatura. Esses estudos de
caso visam obter o ponto de vista dos profissionais de software sobre a
aprendizagem organizacional e gerência do conhecimento durante melhorias
realizadas nos processos de software.
3. Definição do framework KL-SPI (Knowledge and Learning to facilitate Software
Process Improvement). Esse framework contém um modelo conceitual com os
seguintes componentes: ciclo de vida do conhecimento, atividades para apoiar a
aprendizagem organizacional em MPS e ferramentas de apoio à aprendizagem
organização e gerência do conhecimento.
4. Avaliação Experimental do framework – avaliação da viabilidade desses
componentes buscando garantir um auxílio adequado à indústria de Software.
No estágio atual do trabalho está sendo definido o detalhamento de como será de
fato o uso dos componentes do framework. Para isso os resultados levantados nos
estudos de caso e os resultados do mapeamento sistemático estão sendo utilizados para a
definição das atividades para apoiar a aprendizagem organizacional em melhorias de
processo de software. Uma ferramenta para apoio à codificação do conhecimento já foi
definida e avaliada experimentalmente (Rabelo et al., 2012). Além disso, a definição de
outras abordagens de apoio ainda está em análise.
Aprendizagem Organizacional pode ser estimulada através da aplicação de diversas
abordagens de Gerência de Conhecimento. Basili et al. (1994) apontam que um processo
sistemático de aprendizagem requer um suporte onde seja possível gravar experiências,
criar generalizações, adaptar experiências e formalizar essas experiências. A abordagem
de fábrica de experiência é uma organização lógica ou física que auxilia o
desenvolvimento de projetos através da análise e síntese de todos os tipos de experiência
(Basili et al., 1994). Visando a melhoria de processos, Falbo et al. (2004) definiram uma
arquitetura baseada em Fábrica de Experiência. Essa arquitetura, a ProKnowHow,
possui uma memória organizacional que armazena inicialmente conhecimentos informais.
Após um tratamento deste conhecimento, o mesmo é disponibilizado para a organização.
Os autores descrevem que a arquitetura pode contribuir para a melhoria do processo de
software, pois auxilia na definição dos processos, no armazenamento e reutilização das
lições aprendidas e, por fim, contribui para fazer estimativas de maneira mais fácil, uma
vez que utiliza experiências anteriores. Parte da definição da arquitetura utilizada neste
trabalho está sendo considerada no modelo conceitual proposto para a definição do
framework desta Tese.
Alagarsamy et al. (2007) desenvolveram o modelo KDM (Knowledge Driven
Model) que busca sistematizar a aprendizagem organizacional em melhorias de processo
de software. Esse modelo busca incentivar a organização sobre a necessidade de um
programa de MPS e auxilia no levantamento de conhecimento importante sobre o MPS
46
que os colaboradores devem possuir. De maneira similar, Santos et al. (2007) descrevem
uma estratégia, a SPI-KM (Software Process Improvement Approach supported by
Knowledge Management). Essa estratégia visa auxiliar organizações que estão inseridas
no contexto de MPS através do diagnóstico sobre as necessidades de negócio da
organização em relação ao MPS e definição de instrumentos de aquisição de
conhecimento tanto dos consultores em melhoria de processo quanto dos colaboradores
das organizações. Segundo Bellini e Lo Storto (2006), um processo de software
disciplinado através da melhoria de processos pode prover um gerenciamento do
conhecimento mais efetivo entre os projetos da organização. Os autores investigaram o
impacto da implementação do CMM (Capability Maturity Model) na gerência do
conhecimento e aprendizagem organizacional, mas precisamente como o CMM cria um
ambiente propício para dar suporte à aprendizagem organizacional. Os autores
observaram que a maioria das áreas de processo do CMM induz a aprendizagem em
nível de projeto e outras áreas de processo induzem a aprendizagem no nível da
organização, como a Garantia da Qualidade.
Os trabalhos apresentados nesta seção apresentam tipos de abordagens para a
aprendizagem organizacional. Contudo se baseiam em definições vindas da literatura ou
partem do ponto de vista de consultores em melhoria de processo de software. Em vista
disto, buscou-se definir, nesta pesquisa, uma abordagem mais voltada para o ponto de
vista dos profissionais das organizações, para desta forma garantir um diferencial em
relação às abordagens apresentadas.
5. Resultados esperados e contribuições parciais
O principal resultado esperado deste trabalho será a definição de um framework para
facilitar a aprendizagem organizacional em melhorias de processos de software guiadas
ou não por modelos de maturidade. Esse framework conterá uma definição de ciclo de
vida de lições aprendidas, conjunto de atividades e ferramentas de apoio à aprendizagem
organizacional em melhorias de processo de software. A definição das atividades e
ferramentas deve ser cuidadosa de forma que essas atividades tenham o menor impacto
possível nos custos associados à sua implementação. Para alcançar essa meta, resultados
são esperados e detalhados a seguir, assim como as contribuições parciais desta pesquisa.
5.1. Abordagens de AO e GC identificadas na literatura e fatores de influência
Após o mapeamento sistemático da literatura, definiu-se de um conjunto de abordagens
de aprendizagem organizacional e/ou gerência do conhecimento aplicáveis em
organizações desenvolvedoras de software. Essas abordagens, em sua maioria, buscam
tratar o conhecimento explícito da organização.
Adicionalmente, diversos aspectos podem influenciar positiva e negativamente a
Aprendizagem Organizacional em empresas de desenvolvimento de software. Entre esses
aspectos podem-se citar: a estrutura organizacional, atividades que estimulam a
disseminação, o fluxo e a forma de aprendizagem de conhecimentos (Smolander et al.,
2005; Škerlavaj e Dimovski, 2006; Sandhawalia e Dalcher, 2010).
47
WTDQS 2014
5.2. Investigações sobre a ocorrência do ciclo de vida de conhecimento e
aprendizagem nas organizações de software
Neste resultado esperado, busca-se obter evidências sobre o ciclo de vida de
conhecimento e sobre como a aprendizagem organizacional é abordada nas organizações
de software que estejam ou não no contexto de melhorias de processo de software. Estes
resultados são importantes para a definição das atividades e ferramentas de apoio
voltadas para a aprendizagem e gerência do conhecimento.
Como contribuições parciais, realizaram-se estudos sobre a ocorrência do ciclo
de vida das lições aprendidas nas organizações de software (Viana et al., 2013). As
lições aprendidas são conhecimentos organizacionais que descrevem discussões e
soluções para resolver problemas e possíveis oportunidades de melhoria. Além disso,
auxiliam a evitar a repetição de problemas similares nos projetos. Neste estudo foi
possível verificar que há três fases do ciclo de vida das lições aprendidas: definição,
manutenção e finalização das lições aprendidas. Durante a execução dessas fases é
possível verificar a troca de conhecimento entre os colaboradores das equipes de
desenvolvimento. Além deste estudo de caso sobre as lições aprendidas, foram feitas
análises sobre como o conhecimento é disseminado em organizações de software através
de redes sociais. As análises de redes sociais permitiram verificar obstáculos e possíveis
pontos de melhoria da transmissão do conhecimento em organizações de software
(Wasserman e Faust, 1994). Por fim, um estudo foi realizado buscando verificar como o
conhecimento é transmitido de colaboradores experientes para colaboradores novatos
(Viana et al., 2014). Os resultados desses estudos de caso serão utilizados para formar a
base do framework KL-SPI.
5.3. Condução de Investigações sobre ferramentas/abordagens de apoio à AO e GC
As ferramentas/abordagens de apoio buscam apoiar a organização e disseminação do
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.
Uma das abordagens desenvolvidas foi a PABC-Pattern – Problema, Ação,
Benefício, Contexto - Padrão (Rabelo et al., 2012). Essa abordagem 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 auxiliar tanto a aprendizagem de
conhecimentos explícitos quanto o incentivo à troca de conhecimento tácito.
5.4. Definição Inicial do framework
A primeira etapa para a definição do framework é a elaboração de um modelo conceitual
que irá nortear os resultados das investigações que estão sendo realizadas nesta Tese.
Esse modelo conceitual leva é baseado na ontologia de organização de software definida
no trabalho de Vilella (2004). Além disso, está sendo realizada uma extensão desta
ontologia, onde foram incluídos elementos de aprendizagem organizacional e gerência do
conhecimento. Para a definição desta extensão, levaram-se em consideração os três
resultados esperados do processo Gerência de Recursos Humanos GRH do MR-MPSSW relacionados à gerência do conhecimento.
48
Este modelo conceitual irá integrar os resultados do mapeamento sistemático da
literatura juntamente com os resultados obtidos através dos estudos de caso. Ao final
desta integração, será possível a verificação e definição de estímulos à aprendizagem que
representam um conjunto de ações que podem ser recomendadas para o estabelecimento
do aprendizado e da disseminação do conhecimento. Essas ações estarão relacionadas os
componentes de processo definidos a partir de Villela (2014), como atividades, recursos
e artefatos. Além dos estímulos à aprendizagem, o modelo conceitual irá integrar
estratégias de GC e AO aplicáveis à engenharia de software. No momento, a definição
inicial do modelo conceitual está sendo verificada pelos pesquisadores envolvidos na
pesquisa.
A segunda etapa da definição do framework compreende a análise dos resultados
obtidos com o modelo conceitual com a finalidade de elaborar uma nova estratégia de
aprendizagem organizacional ou evoluir abordagens existentes. A criação de apoio
computacional da abordagem também será analisada nesta etapa.
O propósito do framework é que seja possível apoiar o estabelecimento do
aprendizado e a disseminação do conhecimento sobre as melhorias do processo de
software em toda a organização. Desta forma, a etapa final consiste em avaliação
experimental da abordagem. Essa avaliação experimental irá auxiliar na verificação dos
componentes criados com o objetivo de obter indícios para a aplicabilidade da
abordagem para à indústria de software.
Referências
Alagarsamy, K., Justus, S., Iyakutti, K., 2007, "On the Implementation of a Knowledge
Management Tool for SPI". In: International Conference on Computational Intelligence
and Multimedia Applications, 2007., v. 2, pp. 48-55, 13-15 Dec. 2007.
Almeida, C.D.A., Albuquerque, A.B., Macedo, T.C., 2011, "Analysis of the continuity of
software processes execution in software organizations assessed in MPS.BR using
Grounded Theory". In: Proceedings of the 23rd International Conference on Software
Engineering and Knowledge Engineering (SEKE 2011), pp. 792-797, Miami, USA.
Angkasaputra, N., Pfahl, D., Ras, E., et al., 2003, "The Collaborative Learning Methodology
CORONET-Train: Implementation and Guidance". In: HENNINGER, S., MAURER, F.
(eds), Advances in Learning Software Organizations, Springer Berlin Heidelberg.
Aurum, A., Daneshgar, F., Ward, J., 2008, "Investigating Knowledge Management practices in
software development organisations – An Australian experience", Information and
Software Technology, v. 50, n. 6, pp. 511-533.
Basili, V.R., Caldiera, G., Rombach, H.D., 1994, "Experience Factory", Encyclopedia of
Software Engineering, John Wiley & Sons, Inc.
Bellini, E., Storto, C.L., 2006, "The impact of software capability maturity model on knowledge
management and organisational learning\&\#58; empirical findings and useful insights",
Int. J. Inf. Syst. Chang. Manage., v. 1, n. 4, pp. 339-373.
Falbo, R.A., Borges, L.S.M., Valente, F.F.R., 2004, "Using knowledge management to improve
software process performance in a CMM level 3 organization", pp. 162-169.
Garvin, D.A., 1994, "Building a learning organization", BUSINESS CREDIT-NEW YORK-, v.
96, pp. 19-19.
Kitchenham, B.A., Budgen, D., Pearl Brereton, O., 2011, "Using mapping studies as the basis for
further research – A participant-observer case study", Information and Software
Technology, v. 53, n. 6, pp. 638-651.
49
WTDQS 2014
Land, L.P.W., Aurum, A., Handzic, M., 2001, "Capturing implicit software engineering
knowledge". In: Proceedings of Australian Conference in Software Engineering, 2001,
pp. 108-114, 2001.
Montoni, M.A., Rocha, A.R., 2011, "Uma Investigação sobre os Fatores Críticos de Sucesso em
Iniciativas de Melhoria de Processos de Software". In: Proceedings of X Simpósio
Brasileiro de Qualidade de Software, v. 1, pp. 1-15, Curitiba, PR.
Nonaka, I., Takeuchi, H., 1995, The Knowledge-Creating Company, 17th ed. Oxford Oxford
Univerity Press.
Rabelo, J., Viana, D., Conte, T., et al., 2012, "Comparing Knowledge Codification Approaches:
An Empirical Study". In: Proceedings of 2012 Brazilian Symposium on Collaborative
Systems (SBSC), , pp. 136-145.
Ruhe, G., 2001, "Learning Software Organisations", Handbook of Software Engineering and
Knowledge Engineering (S.K. Chang, ed.), World Scientific Publishing 2001.
Runeson, P., Höst, M., 2009, "Guidelines for conducting and reporting case study research in
software engineering", Empirical Software Engineering, v. 14, n. 2, pp. 131-164.
Sandhawalia, B.S., Dalcher, D., 2010, "Knowledge flows in software projects: An empirical
investigation", Knowledge and Process Management, v. 17, n. 4, pp. 205-220.
Santos, G., 2011, "Influência e Impacto do Programa MPS.BR na Pesquisa Relacionada à
Qualidade de Software no Brasil". In: Proceedings of X Simpósio Brasileiro de
Qualidade de Software (SBQS 2011), v. 1, pp. 73-87, Curitiba, PR.
Santos, G., Montoni, M., Figueiredo, S., et al., 2007, "SPI-KM - Lessons learned from applying
a software process improvement strategy supported by knowledge management", v. 4589
LNCS, pp. 81-95.
Schneider, K., 2009, Experience and Knowledge Management in Software Engineering
Heidelberg, Springer
Sei, 2010, CMMI® for Development, Version 1.3, Improving processes for developing better
products and services.
Škerlavaj, M., Dimovski, V., 2006, "Social Network Approach To Organizational Learning",
Journal of Applied Business Research, v. 22, n. 2, pp. 89-98.
Smolander, K., Schneider, K., Dingsøyr, T., et al., 2005, "Future Studies of Learning Software
Organizations". In: ALTHOFF, K.-D., DENGEL, A., BERGMANN, R., et al. (eds),
Professional Knowledge Management, Springer Berlin Heidelberg.
Softex, 2012, MPS.BR: Guia Geral MPS de Software, Disponível em:
http://www.softex.br/mpsbr/guias/. Acessado em 21 de Setembro de 2013.
Travassos, G.H., Kalinowski, M., 2013, "iMPS 2012 : evidências sobre o desempenho das
empresas que adotaram o modelo MPS-SW desde 2008", SOFTEX, Campinas, SP.
Viana, D., Conte, T., Souza, C.D., 2014, "Knowledge Transfer between Senior and Novice
Software Engineers: A Qualitative Analysis". In: Proceedings of the 26th International
Conference on Software Engineering and Knowledge Engineering, Vancouver, Canada.
Viana, D., Rabelo, J., Conte, T., et al., 2013, "A qualitative study about the life cycle of lessons
learned". In: 6th International Workshop on Cooperative and Human Aspects of
Software Engineering (CHASE) - ICSE 2013 Workshop, pp. 73-76, San Francisco,
United States.
Villela, K., 2004, Definição e Construção de Ambientes de Desenvolvimento de Software
Orientados à Organização, Tese de D. Sc., COPPE, UFRJ, Rio de Janeiro, Brasil.
Wasserman, S., Faust, K., 1994, Social network analysis: Methods and applications,
Cambridge university press.
50
Towards understanding project actuality in small software
development organizations
Suzana Cândido de Barros Sampaio1,2, Hermano Perrelli Moura2
1
2
Federal Rural University of Pernambuco (UFRPE), Recife-PE-Brazil
Informatics Center (CIn), Federal University of Pernambuco (UFPE), Recife-PE-Brazil
{scbs2,hermano}@cin.ufpe.br
Abstract. In recent years has been a significant growth in project work across
different sectors and industries. The increased complexity involving projects
and its environment are leading practitioners and researchers to investigate
new approaches to analyze and contribute to project management field.
Actuality of projects means focusing on social process and in how
practitioners think in action. This article presents an approach to analyze and
to understand the nature of project actuality by describing how actors actually
think and act in small development organization and also to help these
organizations to enhance their project management practices and produce
reflexive practitioners being able to achieve organizational success.
1. Introduction and motivation
In recent years, the world has been going through profound social, economic, political,
and cultural transformation. In this highly competitive environment, the urge to adapt,
to reinvent and to implement new strategies, new products and services have become a
major advantage or even a requirement for business survival. For small software
development organizations this is a daily concern due to this competitive environment
and the necessity of transforming project in organization success.
For over twenty years the definition of project success was to perform an activity with time restriction, costs and performance [Kerzner 2003]. We supports a long time
concept of success that goes beyond these simple aspects [Pinto and Slevin 1988,
Morrison 2004 and Shenhar et al. 2001]. That means organizational success through
project success. The real success provides organizational growth, such as contributing
for launching new products, gaining a strategic client or achieving a strategic goal.
The 2013 CHAOS Manifesto [Standish Group 2013] presented a special version
of the Success Factors for Small Projects using their database and analytic tools. Optimization, skilled resources, project management expertise, agile process and emotional
maturity are some of the factors. Since project can be seen as temporary organizations
[Turner and Muller 2003; Packendorff 1995], it is useful to analyze the Manifesto´s
results by small organization perspective. It also motivates this work on defining
software development operational work as project to be able to offer senior management visibility and control, as well as team's sense of success and accomplishment.
Over the past 20 years, there has been a substantial improvement in the quality
and rigor of research in project management [Turner 2010]. Among the recent
initiatives to expand and improve project management, stands out the network on
rethinking project management (RPM) [Winter et al. 2006]. The network results pointed
51
WTDQS 2014
to five major areas of research, among them: social process, broader conceptualization
of projects and reflective practice. Actuality research, arose from the RPM network,
with the aim to understand what is actually in the arrangements labeled ‘project’ over
time [Cicmil et al. 2006]. It seeks for a better understanding of projects reality. Cicmil
et al. argued that ‘project actuality’ encompasses the understanding of the lived
experience of organizational members with work and life in their local project
environments.
By analyzing this lived experience and by understanding its actuality we intend
to contribute on enhancing organizational project management practices and to trace
improvement with the help of the project team as reflexive practitioners. This paper is
part of an ongoing research of an approach to support the observations, analyzes and
understanding the actuality of software development projects. And it presents the
concept of project actuality and the results of a few observations in small software
development organizations in Brazil. It also aims on develop reflexive practitioners,
who can learn, adapt and engage in reaching organization success.
Besides this introductory Section, this paper is organized as follows: Section 2
gives some relevant background, definitions and related works. Section 3 explains
briefly the methodological aspects. Section 4 shows the approach used to understand
project actuality. In Section 5, the observation sample is presented. Section 6 analyzes
some results. And then, Section 7 presents concluding remarks and father research.
2. Literature review and background
2.1. Project Actuality
Researching the actuality of projects means focusing on social process and how
practitioners think in action, in the local situation [Cicmil 2006]. Thereby achieving an
idea of what project managers do in concrete project situations and to explore skills and
knowledge that constitute the social and political action in managing projects. Cicmil et
al. proposed a shift in thinking and research orientation to tackle the identified and so
far neglected themes, creating knowledge which is relevant to practice and reflects the
interests of both academic and practitioner communities [Cicmil et al. 2006].
Winter and Szczepanek, encourages practitioners to think about projects from
multiple perspectives. Just like organizations, projects mean different things to different
people, and can also be viewed in different ways by practitioners [Winter and
Szczepanek 2009]. Therefore research project actuality is to collect, analyze and
disseminate knowledge about people working together and with each other, and the way
in which these relations are coordinated and controlled to accomplish the objectives
[Cicmil 2006]. Actuality focuses on practical action, on lived project team experience,
optimization abilities and emotional maturity, on quality of the social interaction inside
the team (internal) and also with users and clients (external).
2.2. Related works and Background
Lalonde et al. proposed a framework to examine project management from the practice
viewpoint, where they explore the inquiry process by which actors grasp project situations [Lalonde et al. 2012]. For the authors, the project per se is a social fieldwork. The
project was a large-scale architecture with a budget of over $ billion. The basic data
52
were derived from verbal interactions but a variety of data collection devices were used.
Our data collection is a bit different from the ones used by Lalonde et al
[Lalonde et al.2012]. We use actors’ affirmations as much as actions, practices, methods
and context, in observations, interviews and document analyzes. We also used the actors
as researcher but our field was software development in small organizations.
According to Crawford et al. [Crawford et al. 2006] the knowledge and practices
covered by project management bodies of knowledge represent only a relatively narrow
part of what is needed to effectively fulfill their roles. According to the authors, the
need for practitioner development goes beyond the development of trained technicians
to reflective practitioners. The authors also stated that the range of roles that have
project responsibility is broadening and that it is no longer just the responsibility of the
project manager. This aspect was also noticed and analyzed during our observations.
Maaninen-Olsson and Muller analyzes project focusing on understanding the
ways in which project-centered activities are shaped in time and space. The authors use
semi-structured interviews, observations and secondary data to analyze the combined
effects of the spatial and temporal aspects [Maaninen-Olssan and Mullern 2009]. The
study was conducted in a large industrial company in Sweden. Our research was
inspired by theirs, were the activities were undertaken as they came up and the learning
had to cope with situations as they emerged during project whole life cycle.
Jafari [Jafari 2007] presented a systematic approach to assess the health of large
projects or programs at any point in their life cycle, by analyzing how systemic the
project team is in its management of project variables. Jafari understood that different
projects need different approaches to succeed. Our approach was inspired by Jafari's
process, we also analyze project by a key factors perspective, but we did not considered
just the PMBOK process areas [PMI 2004]. We also used capability maturity model
such as MR-MPS-SW [SOFTEX 2012] to analyze the project and mainly to guide the
action plans in the intervention step described in Section 4.
In Brazil, a Brazilian software process improvement program was developed
with the objective of improving maturity and capability of software development and
services in Brazilian companies [SOFTEX 2012]. Each model has its process and each
process has some expected results. Expected result is "an observable result of the
successful achievement of the purpose of the process" [ISO 2004]. These results were
and will be used to narrow the action plan. The idea is not to be adherent to the model,
just to use it to enhance project management practices.
Cicmil et al. proposed a pragmatic research of project actuality to generate
knowledge and to build theories [Cicmil et al. 2006]. Cicmil [Cicmil 2006], in her work
on understanding the practical action and managerial conduct in complex project
environments, presented a research approach that can generate insights and illustrates
the key claims. The approach proposed in this article, follows the same line of a
pragmatic research to understand the practical action in managerial conduct and hopes
to explore this idea of project as a knowledge process and analyze the mindset of small
software development organizations.
3. Methodology
The methodology gathers a few methods, some of them as part of the approach taken to
understand the actuality of software projects. First a systematic literature review was
53
WTDQS 2014
conducted to evaluate and interpret all available research concerning project actuality, in
between the year of 2000 to 2013, using the engines ACM Portal, IEEE Xplore and
Science Direct. The research questions used were: What is project actuality?(1); How
can we observe and analyze project actuality?(2); How current theories, concepts and
methodologies underpinning project management research could be enriched by
understanding project actuality?(3); and by understanding project actuality can we
enrich the knowledge created in the research process in project environments?(4). The
literature review was enriched by an exploratory review of the studies mentioned by the
papers brought up in the systematic review. Along with an exploratory review on
project management practices, before and along the observations that used ethnography
methods [Robinson et al. 2007] that emphasizes the researcher's presence in the field.
Action research methodology [Santos and Travassos 2009] was used after step
four in our approach (intervention) presented in the next Section. The intervention aims
on the team learning process, focusing on the project management practices and with
the help of a maturity model and its results (or requirements) to draw the action plan.
4. Approach to understand project actuality
The investigation on social concept surrounding software development started after
analyzing several approaches or empirical method to study how a community of people
interacts [Cicmil 2006; Lalonde et al. 2012; Robinson et al. 2007 and Patton 2002]. The
objective of the analysis is to go beyond a description of particular scenario or project
but to identify the patterns that occur, and document and understand the ongoing inquiry
process through which project actors face project situations. This method of accessing
knowledge consists in seeing what happens in person, spending time in the field, and
eventually leaving the field. Therefore, the method considered the importance of
investigating and understands software projects actuality, for fulfilling the gaps and
contributing to a more efficient project management.
The research learning approach is presented in Fig.1. Theory was used to
understand the concept of project actuality, project management, methods of inquiring
and elicitation, and then the observations and interventions were conducted to generate
knowledge and reflexive practitioners. Theory was taken to the organizations to help
them to enhance their project management practices and produce reflexive practitioners.
Fig. 1. Research project actuality approach.
Some ideas were presented or exchanged with project actors and actions were
immediately implemented or adjusted promoting findings for this research and
knowledge for the organizations. During the intervention, the goal is "Not to provide
'quick fixes' or 'off the shelf' solutions to management problems, but to encourage a
different way of viewing and thinking about a social phenomenon or to consider other
54
lines of reasoning and practice" [Huczynski and Buchanan 2001]. Aiming to
understand project actuality, and enhance the knowledge in process, as well as to
produce better organizational results, the general following steps were conducted:
�
Step #1 - Literature review (as mentioned in previous section).
�
Step #2 - Planning: First the creation of a specific script for the investigation, since
we don’t have a pattern for ethnography studies. Second the definition of the
sample, what teams/project will be observed. The goal is to have more than one
project in the sample, but at least one has to be observed through it entire life cycle.
�
Step #3 - Understanding the actuality: Interviews with staffs, managers,
programmers as the perception of how good the company, "what sticks", problems,
strengths. Analysis of the documentation of the project or operation. Participation
with observation of project or team meetings. Interviews and informal conversation
at various times of the project / operation, with intervention of the actors and
researchers. Analyze conflicts, problems, singularities, and fortresses.
�
Step #4 - Intervention : Action research [Santos and Travassos 2009] with the suggestions of process improvements and discussion with team leaders and managers.
�
Step #5 - Analyze organization gain and publish the findings on project actuality.
4. Brazilians software industry panorama and sample of observation
Brazilian Information Technology domestic market, which includes hardware, software,
and services, handled 60.2 billion dollars in 2012. Out of this value, 9.5 billion came
from the software market and 15.5 billion from the services market [ABES 2013]. Over
85% companies can be classified as Micro or Small Business [ABES 2013]. Table 1
presents the annual revenue distribution, helping to understand the relevance of small
organizations in the Brazilian software development business.
Table 1. Annual revenue distribution - R$ (R$/US$: 2011 – 1.674; 2012 - 1.955)
Thousands of reais R$
Up to 1000
From 1001 to 2000
From 2001 to 4000
From 4001 to 10000
More than 10001
% Organizations
57%
21%
8%
6%
8%
It was not common to come across project oriented organizations. The organizations have more than 10 years old, a few or dozen or even hundreds of faithful clients. A
lot of them has developers with at least three year as an employee, 50% of them has at
least five years or more. The overall management has a lot of practices suggested by
agile methods [Schwaber 2009]. To most of them, to define software development
operational work as projects was one of the first interventions agreed by researchers in
action. Table 2 presents the research field (organization) data. The column “Projects”
presents the number of projects during observation or intervention or "0" every time in
the beginning of the work there was no development work structured as projects. For
organizations "F" and "G", there is still no structured project. The column “Team”
presents project's roles or development team: Project Manager (PM); Developer (Dev);
Tester (T); Support (S); Scrum master (SCM); Product Owner (PO); Configuration
55
WTDQS 2014
Manager (CM); Quality Assurance (QA); Director (D). The column “Research Effort”
represents the effort spent by researchers in observation and intervention.
Table 2. Research field data.
Org.
Projects
Technology
A
0, 3
Delphi and Java
B
5
Delphi
Team
Research
Effort
Project Type
1 PM+D, 5 Dev, 2 T+S
72
New, Maintenance
Team 1: 1SCM+Dev, 1 PO, 2 T, 5
Dev, 1CM, 1QA
139
Maintenance
Team 2:1SCM+Dev, 1 PO, 1 T, 3
Dev, 1CM, 1QA
C
2
Java
1PM, 2 Dev, 1T+QA
66
New, Maintenance
D
2
Java
1PM+PO, 1SCM+Dev, 2 Dev,
1T+QA
78
New, Maintenance
E
0, 3
Java, C#
1PO, 1SCM, 4 Dev, 1QA+CM
134
New, Maintenance
F
0
Delphi
1 D, 8 Dev + S
21
Maintenance
G
0
Java
1 D + dev, 5 Dev
24
Maintenance
5. Results
Indeed a unified theory of management of project does not exist [Smyth and Morris
2007]. The actuality of small development organizations are really not what we see in
the books. PMBOK [PMI 2004] is known but not used as is written. There is no classic
problem or resolution. The observations helped to analyze not only the actuality of
projects but, also the frequency and/or use of traditional practices of project
management, the maturity of managerial practices and which body of knowledge are
more used or understood by small software development organization in Brazil.
Among the actions we suggested some are accepted by MR-MPS-SW [SOFTEX
2012] and agile principles, the alignment between this two "methodologies" can be seen
in a lot of studies [Prikladnicki and Magalhães 2010; Silva et al. 2009; Boria et al.
2013]. The most flat action was to define software development operational work as
monthly project. The team started to have a small feeling of success and
accomplishment and the motivation had an improvement. Measurements and risk
management were also something not used and introduced. Just “F” does not use a tool
to help management practices. “A”, “F” and “G” has their owner as PM or similar,
generating a not healthy centralized management where time is not enough to close
deals, selling the product, listening to customers, sine checks and still participate in all
project decisions. The management role is distributed among the team member.
All of them are willing to improve their process by practice, not by new courses
or training, even though all leaders were graduated from a computer science, some of
them with a MBA. Pretty consistent with Mintzberg’s viewpoint [Mintzberg 2011].
Similar with pointed out by Klaff [Klaff 2011], the management in small organizations
function as our brain “First, survival. Then, social relationships. Finally, problem
solving”. All organizational leaders approved the approach, and by the end of the intervention “A, B and D” engaged in a maturity level of the MR-MPS-SW [SOFTEX 2012].
6. Conclusion
Nowadays organizations need to be constantly changing, readapting and redefining it.
The only way to do it is through projects. Reflexive practioners and project actuality
56
came up among the recent initiatives to expand and improve the project management.
This ongoing effort aims to contribute to this line of research, by performing
observations and interventions to extract, analyze and understand project actuality and
to build along reflexive practitioners engaged in long term success. The biggest challenge was the amount of detailed data collected (77 minutes, besides all notes, audios and
action plans) and the time necessary to conduct these observations and interventions.
By understanding project actuality and by developing reflexive practitioners, we
can help to improve project management practices in small software development
organizations. MR-MPS-SW can help priorizing what to discuss and reflect about. This
article presents an approach to understand project actuality in small software
development organizations and also to help their leaders and managers on maximizing
their projects potential by enhancing their learning process. A few results is also
presented. Indeed there is no classic problem or resolution, but that is a lot to contribute
in those organizations to make even a bigger impact in the Brazilian economy. As future
works we intend to expand our sample and publish a detailed results report.
7. References
Kerzner, Harold (2009) Project Management: A Systems Approach to Planning,
Scheduling, and Controlling. 10th. ed. New Jersey, NJ, USA: Wiley.
Pinto J.K. and Slevin D.P (1998) Project success: definitions and measurement
techniques . Project Management Journal; v.19, n.3, p. 67–73.
Morrison J. and Brown C. (2004) Project Management effectiveness as a construct: a
conceptual study. South African Journal of Business Management 35 (4),73-94.
Shenhar A., Dvir D., Levy O. and Maltz A. (2001) Project Success: a multidimensional
strategic concept. Long Range Planning 34(6),699-725.
Standish
Group
(2013)
The
Standish
Group
International,
2013.
th
http://www.standishgroup.com/chaos_news/newsletter.php?id=54 [April 20 2014].
Turner J.R. and Muller R. (2003) On the nature of the project as a temporary
organization. International Journal of Project Management 21(1), 1-8.
Packendorff J.(1995) Inquiring into the temporary organization: New directions for project management research, Scandinavian Journal of Management, V11-4, 319-333.
Turner J. R. (2010) Evolution of project management research as evidenced by papers
published in the International Journal of Project Management, 28: 1-6.
Winter M., Smith C., Morris P. and Cicmil S. (2006) Directions for future research in
project management: The main findings of a UK government-funded research
network. International Journal of Project Management 24, no. 8: 638-649.
Lalonde P. L., Bourgault M., Findeli A. (2012) An empirical investigation of the project
situation: PM practice as an inquiry process, International Journal of Project
Management, Volume 30, Issue 4, May 2012, Pages 418-431, ISSN 0263-7863
Cicmil S., Williams T., Thomas J. and Hodgson D. (2006) Rethinking Project Management: researching the actuality of projects. Int. Journal of Project Man. 24: 675-686.
Cicmil S. (2006) Understanding project management practice through interpretative and
critical research perspectives. Project Management Journal 37(2): 27-37.
57
WTDQS 2014
Winter M. and Szczepanek T. (2009) Images of projects. Gower.
Crawford L., Morris P., Thomas J. and Winter M.(2006) Practitioner development:
From trained technicians to reflective practitioners. IJPM 24, 722-733.
Maaninen-Olssan E. and Mullern T. (2009) A contextual understanding of projects. The
importance os space and time. Scandinavian Journal of Management 24, 327-339.
Jaafari A. (2007) Project and program diagnostic: A systemic approach. International
Journal of Project Management Volume 25, Issue 8, November 2007, Pgs 781–790.
SOFTEX (2012) Associação para a Promoção da Exelencia do Software Brasileiro.
MPS.BR Guia Geral 2012. Avalilable at <http://www.softex.br/wp-content/uploads/
2013/07/MPS.BR_Guia_Geral_Software_20121.pdf> [April 20th 2014]
ISO(2004) International Organization for Standardization and the International
Electrotechnical Comission (2004) “ISO/IEC 15504-1: Information Technology Process Assessment - Part 2: Performing an Assessment”. Geneve.
Robinson H., Segal J., Sharp H. (2007) Ethnographically-informed empirical studies of
software practice. Inf. Softw. Technol. 49, 6, 540-551.
Santos P. S. and Travassos G. H. (2009). Action Research Use in Software Engineering:
an Initial Survey. Third International Symposiumm on Empirical Software
Engineering and Measurement 978-1-4244-4841.
Patton M Q. (2002) Qualitative Research & Evaluation Methods. Sage Publications,
Thousand Oaks.
Huczynski A., Buchanan D. A (2001). Organizational behaviour: An introdutory text.
Harlow Essex, UK: Finacional Times PRencive Hall.
ABES, 2013. Brazilian Software Market: scenario and trends. 1Ed. São Paulo: ABES.
Schwaber (2009) K. Agile project management with Scrum. O’Reilly Media, Inc., 2009.
Smyth H. J, Morris P. W G. (2007). An epistemological evaluation of research into
projects and their management: Methodological issues, International Journal of
Project Management, Volume 25, Issue 4, Pages 423-436, ISSN 0263-7863.
PMI (2004) P. M. Institute. A guide to the project management body of knowledge:
PMBOK Guide. Project Management Institute Newtown Square PA,USA, 2004.
Prikladnicki R. and Magalhães A. (2010) “Implantação de Modelos de Maturidade com
Metodologias Ágeis: Um Relato de Experiências”. WAMPS`2010.
Silva F. G., Hoentsch S. P. and Silva L. (2009) Uma análise das Metodologias Ágeis
FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR”. Scientia Plena.
Boria J., Rubinstein V. and Rubinstein A. (2013) “A história da Tahini-Tahini Melhoria de processos de software com métodos ágeis e modelo MPS”.
Klaff O. P. (2011) Anything: An Innovative Method for Presenting, Persuading, and
Winning the deal. McGraw-Hill.
Mintzberg H. (2011) Managing.Publisher: Berrett-Koehler Publishers; First Edition
(March 10, 2011) ISBN-13: 978-1605098746.
58
Riscos em Iniciativas de Melhoria de Processos de Software:
Uma Investigação no Contexto Brasileiro
Eliezer Dutra1,2, Gleison Santos1
1
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
2
Centro Federal de Educação Tecnológica Celso Suckow da Fonseca (CEFET/RJ)
Estrada de Adrianópolis, 1317 - Santa Rita, CEP: 25265-000 - Nova Iguaçu, RJ
{eliezer.goncalves, gleison.santos}@uniriotec.br
Abstract. This article aims to present a proposal for a dissertation that will
examine the risks in software processes improvement (SPI) initiatives based
on the MR-MPS-SW and CMMI-DEV models in the context of Brazilian
organizations. The concepts related to the risk will be extracted from
experience reports and mapped using procedures based on the scientific
method Grounded Theory. Thus, a base of risks will be established to assist
the definition of a risk plan. A survey with consultants and professionals
involved with the SPI implementation will enable the analysis, validation and
classification of risks.
Resumo. Este artigo tem o objetivo de apresentar uma proposta de uma dissertação que analisará os riscos em iniciativas de melhoria em processos de
software (MPS) baseadas nos modelos MR-MPS-SW e CMMI-DEV no contexto de organizações brasileiras. Os conceitos relacionados aos riscos serão extraídos de relatos de experiência e mapeados utilizando procedimentos baseados no método científico Grounded Theory. Dessa forma, será estabelecida
uma base de riscos que auxiliará a definição de um plano de riscos. Um survey com consultores e profissionais envolvidos com a implantação de MPS
permitirá a análise, validação e classificação dos riscos.
1. Introdução
A competitividade atual exige das organizações que desenvolvem software a implantação de melhorias em seus processos com o objetivo de aumentar a qualidade do produto
e diminuir o custo, possibilitando, assim, aumento de rentabilidade. Modelos de maturidade, como MR-MPS-SW (SOFTEX, 2012) e CMMI-DEV (Chrissis et al., 2011), e
normas, como ISO/IEC 15504 (ISO/IEC, 2003) e ISO/IEC 12207 (ISO/IEC, 2008) auxiliam na definição e na implementação de melhorias em processos de software (MPS).
Vários relatos de projetos de implantações de melhoria de processos de software
(MPS) apresentam baixos níveis de aprovação ou sucesso limitado (Niazi et al., 2006;
Niazi, 2012; Paulk et al., 2000). Em qualquer projeto, problemas podem impactar negativamente os objetivos. Resolver esses problemas depois que eles ocorrem pode ser disruptivo e caro (Chrissis et al., 2011). O processo de gestão de riscos propõe uma análise
crítica dos riscos, através da aplicação sistemática de políticas, procedimentos e práticas
de gestão (ISO, 2009a). Embora os efeitos de uma gestão de riscos ineficaz ou ausente
sejam conhecidos (Iversen et al., 2004), existem poucas pesquisas que identificaram
59
WTDQS 2014
riscos propondo ações de controle em iniciativas de MPS. Na literatura é comum encontrar pesquisas que apresentam fatores críticos de sucesso ou insucesso, dificuldades,
barreiras ou lições aprendidas.
Cada projeto é um esforço temporário único para a realização de um produto ou serviço
(PMI, 2013). As iniciativas de MPS devem ser tratadas como um projeto (Montoni et
al., 2007). Existem vários riscos, barreiras ou dificuldades que podem atrapalhar a implantação de um projeto de MPS (Niazi et al., 2006; Niazi, 2012; Paulk et al., 2000;
Rodrigues e Kirner, 2010; Mendes et al., 2007; Iversen et al., 2004).
É possível encontrar na literatura pesquisas que apontam alguns elementos que
dificultam a resolução de problemas em projetos de iniciativas de MPS. Por exemplo,
Dyba (2002) indica que enquanto a engenharia de software tem oferecido algumas maneiras de tratar problemas intrínsecos, problemas organizacionais necessitam de outra
abordagem. Os problemas organizacionais são tratados implicitamente ou, em muitos
casos, não são totalmente tratados. Segundo Zanetti (2008), os recursos humanos especializados não são facilmente encontrados dentro das organizações desenvolvedoras de
software. Birk e Pfahl (2002) relatam que muitas vezes os programas de melhoria não
são tratados como projetos reais, o que dificulta a aplicação de métodos e técnicas já
estabelecidas na área de gerência de projetos para estimar custos e prazos.
Nesse contexto, iniciativas de MPS são confrontadas com uma série de riscos
que dificultam o desenvolvimento e implantação do projeto, que em alguns casos,
proporciona um pequeno ou nenhum aumento da capacidade de desenvolver software
com qualidade (Iversen et al., 2004).
Um risco é um evento incerto ou condição que, se ocorrer, tem um efeito positivo ou
negativo em um ou mais objetivos do projeto (PMI, 2013). Boehm (1991) foi um dos
primeiros a estruturar a análise de riscos em projetos de software. Ele propôs atividades
que permitem a identificação, análise, planejamento, resolução e monitoramento dos
riscos. Os principais modelos de maturidade, normas ou frameworks propõem práticas
para identificação e tratamento dos riscos (Chrissis et al., 2011; SOFTEX, 2012;
ISO/IEC, 2003; ISO/IEC, 2008; PMI, 2013; ITGI, 2007).
O MR-MPS-SW fundamenta que os riscos do projeto devem ser identificados e
documentados, incluindo seu contexto, fontes, condições e possíveis consequências para
o projeto e as partes interessadas (SOFTEX, 2012). O estabelecimento do contexto do
risco é essencial para sua identificação, análise e controle. Pois todos os outros
elementos, i.e., fontes, causas e consequências devem refletir o estado das
circunstâncias em que o risco está inserido. No entanto, estabelecer a gestão de riscos
em projetos de iniciativas em MPS, nos quais, muitas vezes, os reais contextos
organizacionais são ignorados, não é uma tarefa trivial (Niazi, et al., 2005; Birk e Pfahl,
2002). Niazi (2012) acredita que um bom entendimento dos riscos é vital para o sucesso
de iniciativas de MPS. Embora as iniciativas de MPS possuam riscos semelhantes, as
ações de controle serão próprias de cada organização, pois elas serão realizadas através
de uma análise de contexto. Porém, é possível agrupar riscos e ações de controle
oferecendo um catalisador para futuras tomadas de decisão.
60
4. Metodologia de Pesquisa
Este trabalho tem o objetivo de entender os riscos, seus elementos, suas ações de
controles e seus respectivos efeitos percebidos em iniciativas de MPS. Para isso, esperase construir uma base de riscos, positivos e negativos, que possibilite uma organização
utilizá-la ao iniciar uma iniciativa de melhoria de processos própria.
Para realizar a análise qualitativa e facilitar o processo de entendimento e codificação das informações serão utilizados dois procedimentos da Grounded Theory (GT),
que é uma metodologia que propõe a construção da teoria a partir dos dados (Corbin e
Strauss, 2008): (i) Codificação aberta: processo de rotulação dos conceitos e das
categorias que reflete a interpretação do pesquisador ao que está sendo dito. (ii)
Codificação axial: processo de relacionamento dos conceitos.
4.1. Coleta de Dados
Em um primeiro momento, os dados para derivarem os riscos a serem identificados
serão coletados a partir dos relatos de experiência ou trabalhos técnicos que abordem
implantações de melhorias em processo de software publicados nos principais eventos
no Brasil que tratam do assunto, como o SBQS (Simpósio Brasileiro de Qualidade de
Software) e o WAMPS (Workshop Anual do MPS.BR). Apenas os artigos que relatem
lições aprendidas, oportunidades, barreiras, fatores críticos, dificuldades ou problemas
na implantação baseada nos modelos de maturidade mais utilizados do país, i.e., MRMPS-SW e CMMI-DEV, farão parte do escopo. As consultas serão manuais. Ainda está
em aberto se outras fontes de dados serão utilizadas.
A inclusão do trabalho no escopo de pesquisa dar-se-á após a leitura e
interpretação de que foram relatadas circunstâncias que influenciaram negativamente ou
positivamente uma implantação de MPS. Para nortear essa etapa, estabeleceu-se uma
questão principal e quatro questões secundárias, sendo elas: “QP. Como os riscos
influenciam iniciativas de MPS?”; “QS1. Que riscos comumente afetam essas
iniciativas?”; “QS2. Como os riscos são percebidos (o que desencadeou o risco - o fato
- a causa - fonte geradora)?”; “QS3. Que ações são tomadas para tratar ou
potencializar os riscos?”; “QS4. Qual efeito das ações tomadas?”. Para cada artigo
selecionado, está sendo preenchida uma ficha de resumo com a referência do artigo e
possíveis repostas às questões secundárias.
4.2. Análise de Dados
Os dados serão analisados em seu contexto, com objetivo de um entendimento teórico
que permita respostas à questão principal e as questões secundárias. Um fato que dificulta a identificação de um risco negativo é um possível entendimento referente à associação de um risco afetar a credibilidade externa da organização. Dessa forma, muitas
vezes, estes fatores negativos foram associados a termos positivos como: lições aprendidas ou oportunidades. Outro problema é que alguns relatos não contextualizam os
riscos, apresentando apenas uma lista de categorias, fontes ou fatores de riscos. Consequentemente, compreender a construção proposicional das argumentações que relatam
os riscos associados a uma implantação de MPS é uma tarefa difícil. Nesse sentido, espera-se que a GT auxilie no surgimento de propriedades, categorias e relacionamentos
que permita uma compreensão contextualizada e categorizada e relacional dos contextos.
61
WTDQS 2014
Cada norma, modelo ou framework possui processos e nomenclaturas próprias
para conceituar os elementos da gestão de riscos. Por isso, este trabalho será norteado
com a norma ISO 31000:2009 (ISO, 2009a) “Gestão de riscos — Princípios e
diretrizes”, pois ela apresenta processos e uma nomenclatura padrão para ser utilizada
em qualquer domínio de gestão de risco. Para corroborar com o entendimento da teoria
oriunda da GT, será desenvolvido um metamodelo de gestão de riscos baseado na ISO
31000. Falbo (2010) propôs uma ontologia de riscos com o objetivo de estabelecer uma
definição comum em relação ao domínio de riscos de software. O trabalho de Falbo
(2010) auxiliará na identificação de alguns conceitos do metamodelo. Dessa forma,
através das iterações da GT, da estruturação dos conceitos das normas e da análise de
algumas ontologias, uma nomenclatura padrão, independente do modelo de maturidade,
norma ou framework será estabelecida.
Espera-se que o processo de codificação e a análise do contexto dos riscos,
embasado nos conceitos presentes nas normas internacionais (ISO, 2009a; ISO, 2009b;
IEC/ISO, 2009), possibilite gerar uma base de riscos que contemple os elementos dos
riscos contextualizados e categorizados nos seus respectivos cenários.
4.3. Avaliação do Estudo
Strauss e Corbin (2008) apresentam dez critérios para avaliar a qualidade de um estudo
que utiliza GT. Alguns desses critérios serão utilizados para avaliação deste estudo,
sendo eles: (i) adaptação – a teoria deve corresponder aos dados, (ii) aplicabilidade – a
teoria tem sentido e adiciona conhecimento para os profissionais da área, (iii) conceito –
a teoria deve ser abstrata para servir de guia geral sem perder sua relevância, e (iv)
contextualização do conceito – a teoria atua como um guia geral e possibilita a uma
pessoa entender completamente a situação.
Dessa forma, ao final da aplicação da GT os critérios (i) e (ii) serão avaliados
através auditoria da teoria por consultores especialistas em MPS. A aplicação de um
survey, com profissionais de grupos de MPS e consultores, permitirá a análise da
relevância dos riscos e um possível levantamento da probabilidade, impacto e
classificação dos riscos, assim os critérios (iii) e (iv) também serão avaliados. Por fim, a
utilização da base de riscos em uma iniciativa real de MPS permitirá avaliar os critérios
(ii), (iii) e (iv). Testes estatísticos poderão estabelecer alguma confiabilidade,
significância ou correlação dessa classificação ou do instrumento.
4.4. Estado Atual
O presente trabalho está na fase de coleta e análise de dados, através do levantamento
das propriedades, categorias e relacionamentos que emergem do processo de codificação propostos pela GT. A Figura 1 apresenta a identificação e análise de um risco extraído de uma das publicações já analisada dos autores Ricardo e Corrêa (2011). O risco
extraído apresenta algumas dificuldades de uma empresa pública em convencer os gestores municipais com o financiamento de um projeto de MPS apoiada por um modelo de
maturidade. Os retângulos representam as propriedades que emergiram dos dados através da rotulação dos conceitos (codificação aberta) e as setas representam os relacionamentos entre os conceitos (codificação axial).
62
Figura 1 - Exemplo da descrição de um risco e suas ações de controle
O evento denominado “EV1. Gestores municipais desconhecem
em os benefícios de
implantar um processo de desenvolvimento de software”
software representa uma
um ocorrência
que poderia impedir a implantação
plantação da iniciativa.
iniciativa Uma das causas encontradas nesse
n
evento é a “CA1. Alto
lto custo para a implantação”.. Algumas ações aconteceram para que
as consequências do evento fossem
fosse mitigadas, como por exemplo, “AC100. Utilizar
grupos de trabalho com apoio financeiro” e a “AC102. Convencer
cer os gestores com
abordagens técnicas e comerciais”.
comerciais” Os efeitos das ações foram “EF51. Apoio dos GesGe
tores” e o “EF50.
EF50. Execução de um projeto com baixo investimento”.
invest
Para o levantamento do estado da arte foi
f realizada uma revisão informal da literatura na
base da Compendex e manualmente nos anais do SBQS e WAMPS.
WAMPS Dois dos trabalhos
correlatos identificados são descritos a seguir. Mendes et al. (2007) identificaram
identific
na
literatura os riscos mais citados com o intuito de apresentar os dez mais recorrentes em
projetos de implementação de MPS. Além disso, foram propostas ações com o objetivo
objet
de mitigar, minimizar ou diminuir a probabilidade
probabilidade da ocorrência dos riscos. Contudo,
essas ações de controle não foram fundamentadas na literatura e são, de fato, muito
semelhantes
melhantes a uma lista de fatores de sucesso.
sucesso Niazi (2011) rodou um estudo
exploratório
tório com profissionais da Austrália para identificação de riscos em MPS. O
objetivo do estudo foi obter uma compreensão dos riscos que podem comprometer a
implementação de MPS a partir da perspectiva dos profissionais de desenvolvimento de
software. Todavia,
ia, não foram propostas ações de controle dos riscos identificados.
identificados
6. Resultados esperados
Com este trabalho espera-se
se a definição de uma base de riscos e suas respectivas ações
de controles relacionados
dos com iniciativas de MPS no contexto de organizações brasileibras
ras. A elaboração de um metamodelo
met
para o domínio de gestão de risco
iscos permitirá o
conhecimento
mento dos elementos conceituais presentes na ISO 31000 e seus relacionamentos, assim um vocabulário e exemplos
exe
de riscos contextualizados serão
rão apresentados.
apresent
Além disso, após a aplicação de procedimentos
procedimentos baseados em GT, espera-se
espera que a
criação de categorias possibilite
possibili um agrupamento mais genérico do que as descritas no
contexto dos relatos. Assim,
Assim, será possível realizar comparações com outras pesquisas
que apontem riscos, dificuldades, barreiras, fatores
fatores desmotivadores ou fatores críticos
de sucesso. Após essas comparações e validações com consultores especialistas em
MPS, espera-se
se também, a elaboração e aplicação de um survey que permita a classificlassif
63
WTDQS 2014
cação, análise do impacto e probabilidades dos riscos.
Finalmente, espera-se que o processo de codificação e a análise dos contextos
dos riscos, possibilitem um modelo que auxilie os consultores e os profissionais de grupos de implantação em MPS na identificação, análise, avaliação e controle de riscos.
Referências
Birk, A., Pfahl, D. (2002). “A Systems Perspective on Software Process Improvement”.
Em: Proc. of the 4th Int. Conf. on Prod. Foc. Soft. Proc. Impr., v. 2559, p. 4-18, Dec.
Boehm, B. W. (1991). “Software Risck Management: Principles e Practtices”, IEEE
Software, vol. 8, n. 1 (January), pp 32-41.
Chrissis, M. B.; Konrad, M., Shrum, S. (2011). “CMMI for development: Guidelines for
Process Integration and Product Improvement”. Addison-Wesley. 3rd ed.. Boston.
Corbin, J., Strauss, A. (2008). “Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory”. 3rd. London, SAGE Publications.
Dyba, T. (2002) “Enabling Software Process Improvement: An Investigation of the Importance of Organizational Issues.” Empirical Software Engineering 7 (4): 387–90.
Falbo, R. A. (2010). Uma Ontologia de Riscos de Software, IX Simpósio Brasileiro de
Qualidade de Software (SBQS 2010). Belém, PA.
ISO/IEC (2003) ISO/IEC 15504: Information Technology – Software Process - Part 6:
An exemplar system life cycle process assessment model.
ISO/IEC (2008) ISO/IEC 12207: System and soft. Engine. – Soft. life cycle processes.
ISO/IEC (2009) ISO/IEC 31010: Risk management – Risk assessment techniques.
ISO (2009a) ISO 31000: Risk Management – Principles and Guidelines.
ISO (2009b) ISO Guide 73: Risk Management - Vocabulary.
ITGI - IT Governance Institute (2007). “COBIT 4.1 – Control Objectives
ManagementGuidelines Maturity Models”. Rolling Meadows, IL – USA.
Iversen, J., Mathiassen, L., Axel, N. (2004). “Managing Risk in SPI: AN Action Research Approach.” MIS Quarterly: Manag. Inform. Systems 28 (3): 395–434.
Mendes, F. F., Oliveira, J. L., Fernandes, P. G., et al. (2007). “Análise de Riscos na
Implantação de MPS”. III Workshop Anual do MPS. Campinas, SP.
Montoni, M., Cerdeiral, C., Zanetti, D., Rocha, A. R. (2007). "Uma Abordagem para
Condução de Iniciativas de MPS". III Workshop Anual do MPS. Campinas, SP.
Niazi, M., Wilson, D., Zowghi, D. (2006). “Critical success factors for SPI implementation: an empirical study”, Soft. Proc.: Imp. and Prac., v. 11, n. 2 (Mar), pp. 193-211.
Niazi, Mahmood. (2012). “An Exploratory Study of Software Process Improvement
Implementation Risks”. Journal of Soft.: Evolution and Process 24 (8): 877–94.
Paulk, M., Goldenson, D., White, D. (2000). “The 1999 Survey of High Maturity Organizations”, Soft. Eng. Institute, Carnegie Mellon University, Pittsburgh, PA.
PMI – Project Management Institute. (2013) “Um Guia do Conjunto de Conhecimentos
em Gerenciamento de Projetos: Guia PMBOK”. Pensilvânia: PMI, Quinta ed. 2013.
Ricardo, M., Corrêa, A. S. (2011). “MPS.BR Nível D – A Experiência em Implantar o modelo
na Área de Governo Municipal”. VII Work. A. do MPS. Campinas, SP.
Rodrigues, J., Kirner, T. (2010). “Benefícios, Fatores de Sucesso e Dif. da Implantação do Mod.
MPS.BR”, IX Simp. Bras. de Qual. Soft.(SBQS2012). Belém, PA.
SOFTEX (2012) “MPS.BR - Guia Geral MPS de Software”. Disponível em
http://www.softex.br/mpsbr/guias/. Acesso em 16/04/2014.
Zanetti, D. B. (2008). “Uma Abordagem para Benchmarking em Iniciativas de Implementação
de MPS”, Diss. de Mest., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, 2008.
64
Aplicação de Pontos por Função em Projetos que Usam
Métodos Ágeis
Aluno
Eduardo Garcia Wanderley
Orientador
Prof. Dr. Alexandre Marcos Lins Vasconcelos
Co-Orientador
Prof. Dr. Bruno Tenório Ávila
Pós-graduação em Ciência da Computação – Centro de Informática (CIn)
Universidade Federal de Pernambuco (UFPE) – Pernambuco, PE – Brasil
{egw,amlv,bta}@cin.ufpe.br
Nível: Mestrado
Ano de Ingresso: março de 2013
Previsão de Conclusão: março de 2015
Aprovação da Proposta: não há qualificação para mestrado no Cin-UFPE
Evento Relacionado: SBES
Resumo. Contexto: O desenvolvimento ágil tem se tornado cada vez mais
comum no ambiente de desenvolvimento de software, contudo estimativas de
tamanho em projetos de software que usam metodologias ágeis são feitas de
maneira diferente das realizadas em projetos tradicionais.
Objetivo: Este artigo apresenta o progresso de uma análise comparativa entre
as diferentes abordagens de aplicação da Análise de Pontos de Função (APF)
em projetos de software que fazem uso de alguma metodologia ágil existente no
mercado.
Método: Através de uma revisão sistemática, serão discutidos, de forma
comparativa e funcional, os conceitos de metodologia ágil e de APF e seu
trabalho em conjunto para a resolução de problemas em medição de software.
Por meio de uma pesquisa experimental, empírica e controlada, as propostas
existentes na literatura são avaliadas no intuito de testar sua aplicação e
analisar seus resultados.
Resultados esperados: Espera-se desta forma, definir os pontos de
convergência e de divergências entre as metodologias ágeis e os elementoschave da APF; identificar as possibilidades de aplicação desta integração e
apresentar uma análise detalhada sobre as propostas de aplicação da APF em
projetos de software com metodologias ágeis existentes na literatura.
Palavras-chave. Pontos de Função, Métricas de Software, Metodologias Ágeis,
Gerenciamento, Medição.
65
WTDQS 2014
1. INTRODUÇÃO
A demanda por produtos e serviços na área de tecnologia de informação vem
crescendo continuamente, contudo os orçamentos e cronogramas estão cada vez mais
inflexíveis devido, por exemplo, à necessidade de redução de custos e cumprimentos de
prazos cada vez mais curtos. Para isso, aumentar a qualidade e produtividade do
desenvolvimento de software é primordial para qualquer organização que lida com
projetos de tecnologia da informação [Mens et al., 2001]. Desta forma, o uso de métricas
torna-se essencial para o controle desses projetos.
Selecionar métricas adequadas para poder mensurar custos e receitas não é uma
tarefa fácil, principalmente devido as inúmeras transformações que acontecem
constantemente na área de tecnologia da informação. Isso leva a importantes
questionamentos: Quanto vamos cobrar ao cliente pelo desenvolvimento de um projeto
de software? Quanto vai custar o desenvolvimento desse projeto de software? Como
podemos medir o que a fábrica de software contratada fez? Esses questionamentos
levaram as organizações a adotar a técnica de Análise de Pontos de Função (APF)
[Albrecht, 1979] como critério de mensuração de custos a pagar pelos seus produtos, e
seus sistemas de informação. No âmbito da Administração Pública Brasileira, foi criada
a lei nº 8.666 [Lei 8666, 1993], que estabelece normas gerais sobre licitações e contratos
administrativos, indica que deve-se de forma clara e objetiva mensurar o tamanho do
software pedido e esforço de desenvolvimento do mesmo e uma das principais formas de
mensuração feita é através da APF. Essa também tornou-se referência para estimativas
formais de tamanho funcional de software sendo esta normatizada através da ISO 20926
[ISO 20926, 2009].
No entanto, em projetos de software que utilizam metodologias ágeis, as
estimativas são realizadas de maneira distinta das realizadas em projetos tradicionais.
Iterações rápidas e curtas, rápido feedback são algumas características diferenciadas de
projetos que utilizam metodologias ágeis e, por isso, podem não se adequar às técnicas e
métodos mais conhecidos de estimativa de esforço. O primeiro passo do processo de
medição em APF, por exemplo, consiste em buscar a documentação disponível sobre o
sistema e/ou projeto que será medido. Uma documentação adequada pode incluir
requisitos, modelos de dados/objetos, diagramas de classe, diagramas de fluxo de dados,
casos de uso, descrições procedurais, layout de relatórios e telas, manuais de usuário e
outros artefatos do desenvolvimento de software [IFPUG, 2010]. Nenhum destes
documentos é comum em métodos ágeis. Assim, técnicas particulares para metodologias
ágeis vêm sendo criadas e utilizadas nos projetos [Fuqua, 2003].
Com a ascensão das metodologias ágeis nos meios empresariais [Abrahamsson et
al., 2002], torna-se necessário a detecção de uma forma de relacionar pontos de função
com métodos ágeis.
Este trabalho está organizado da seguinte forma. A Seção 2 introduz a
fundamentação teórica da pesquisa. A Seção 3 discute os objetivos e metas da pesquisa.
A Seção 4 explora os métodos de pesquisa utilizados e o estado atual da pesquisa. A
Seção 5 expõe os trabalhos relacionados e, na Seção 6, a contribuição esperada é
apresentada.
66
2. FUNDAMENTAÇÃO TEÓRICA
2.1 Metodologias Ágeis
As metodologias ágeis são abordagens para desenvolvimento de software
baseadas no desenvolvimento iterativo e incremental, no envolvimento direto do cliente
no processo, na entrega rápida de features de maior valor de negócio e em respostas
rápidas às mudanças [Sommerville, 2011]. Elas compartilham princípios comuns entre
si, definidos em fevereiro de 2001 por profissionais da comunidade ágil que sentiram a
necessidade de diferenciar essa abordagem da tradicional, sintetizando seus pilares no
Manifesto Ágil [Agile Manifest, 2001], o qual afirma:
Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e
ajudando os outros fazê-lo. Através deste trabalho devemos valorizar: indivíduos e
interações sobre processos e ferramentas; software desenvolvido sobre documentação
abrangente; a colaboração do cliente sobre negociação de contratos; respondendo a
mudanças mais que seguir um plano; ou seja, enquanto há valor nos itens à direita, nós
valorizamos os itens mais à esquerda. (Agile Manifest, 2001)
As metodologias ágeis são abordagens atuais para criação de software baseada na
colaboração com o cliente, trabalho em equipe, desenvolvimento iterativo e incremental,
e com respostas rápidas às mudanças. Essas metodologias estão se tornando alternativas
ao desenvolvimento de software tradicional, pois eliminam a dependência em realizar um
extenso planejamento inicial e documentação dos requisitos do sistema, dando ênfase na
flexibilidade, comunicação informal e código funcionando.
Cockburn e Highsmith [Cockburn et al., 2001], afirmam que as metodologias
ágeis enfatizam talentos e habilidades inerentes aos indivíduos, moldando o processo as
pessoas e equipes específicas. Portanto, para uma metodologia se enquadrar na categoria
de metodologias ágeis, segundo Abrahamsson [Abrahamsson et al., 2002], deve utilizar
o desenvolvimento iterativo e incremental, valorizar a colaboração e comunicação entre
cliente e toda a equipe, e ser adaptativa, com capacidade de responder às mudanças.
Em projetos ágeis, os requisitos a serem desenvolvidos são expressos na forma de
estórias feitas por usuários [Leffingwell et al., 2009]. E um dos métodos mais populares
de dimensionamento destas estórias é uso de Story Points, que são unidades subjetivas de
estimativa obtida por equipes ágeis. Neste método, uma equipe se compara a estória do
usuário a uma ou mais estórias semelhantes e dá à estória um tamanho em termos de Story
Points ou "dia ideal de trabalho". O número de Story Points associados com uma estória
representa o tamanho global da estória. Não há uma fórmula definida para definir o
tamanho de uma estória [Santana et al., 2011]. Cada equipe pode definir Story Points
como quiser.
Assim, com base nas metodologias ágeis, diversos metodologias têm sido
propostas, tais como: Adaptative Software Development, Crystal, Dynamic Systems
Development, eXtreme Programming (XP), Feature Driven Development e Scrum.
2.2 Análise de Pontos por Função (APF)
Análise de pontos por função é uma técnica que permite medir a funcionalidade
de um software ou aplicativo sob a visão do usuário e a partir da descrição dos requisitos
do usuário.
67
WTDQS 2014
De acordo com a técnica de APF, uma aplicação de software, vista sob a ótica do
usuário, é um conjunto de funções ou atividades do negócio que o beneficiam na
realização de suas tarefas [IFPUG, 2010].
Desde a sua criação em 1986, a International Function Point Users Group
(IFPUG) vem continuamente, aprimorando o método de dimensionamento de software.
A versão atual (4.3.1) da IFPUG sobre o método está publicada no The Counting
Practices Manual. Este manual classifica os seguintes tipos de elementos funcionais: 1.
Entrada Externa – EI (External Input) – transações lógicas onde dados entram na
aplicação e mantêm dados internos; 2. Saída Externa – EO (External Output) – transações
lógicas onde dados saem da aplicação para fornecer informações para usuários da
aplicação; 3. Consulta Externa – EQ (External Query) – transações lógicas onde uma
entrada solicita uma resposta da aplicação; 4. Arquivos Lógicos Internos – ILF (Internal
Logical File) – grupo lógico de dados mantido pela aplicação; 5. Arquivos de Interface
Externa – EIF (External Logical File) – grupo lógico de dados referenciado pela
aplicação, mas mantido por outra aplicação.
A complexidade das transações é baseada utilizando dois dados: 1. O número de
Arquivos Referenciados – FTR (File Types Referenced); 2. O número de Itens de Dados
Referenciados – DET (Data Element Type).
Os elementos identificados são totalizados para calcular os pontos por função nãoajustados. Em seguida, o fator de ajuste é calculado a partir de 14 características gerais
dos projetos que permitem uma avaliação geral da funcionalidade da aplicação. A cada
característica é atribuída um peso variando de 0 até 5, de acordo com o nível de influência
na aplicação. O nível de influência geral é obtido pelo somatório do nível de influência
de cada característica e o fator de ajuste é obtido pela expressão:
Fator de Ajuste = 0,65 + Nível de Influência Geral × 0,01.
O total de pontos por função da aplicação será encontrado mediante a multiplicação do
número de pontos por função não ajustados pelo fator de ajuste.
3. PROPOSTA DA PESQUISA
A pesquisa se propõe a apresentar uma análise comparativa entre as diferentes
abordagens de aplicação da APF em projetos de software que fazem uso de alguma
metodologia ágil existente na literatura.
As abordagens, escolhidas através da revisão sistemática, serão aplicadas em
projetos reais de uma empresa pública municipal e analisadas sobre vários pontos de vista:
facilidade do uso, facilidade de aprendizagem, grau de precisão da medição e tempo gasto
para se fazer a medição.
Após aplicação e análise das abordagens, será feito um relatório contendo o
resultado do experimento, os pontos fortes e fracos de cada abordagem e uma
recomendação de quando usar uma determinada abordagem e a sua justificativa.
4. METODOLOGIA E PROGRESSO
Antes da definição do método de pesquisa, Easterbrook [Easterbrook et al., 2008]
recomendam que seja definido o posicionamento filosófico a ser seguido pela pesquisa,
podendo ser: positivista, construtivista, teoria crítica ou pragmático.
O posicionamento filosófico escolhido foi o pragmático, pois o mesmo considera
o conhecimento prático, e o uso de métodos de pesquisa mista. O posicionamento
68
Pragmático acredita que todo conhecimento é aproximado e incompleto, e seu valor
depende dos métodos pelos quais foi obtido, sendo portanto, a verdade relativa ao
observador [Easterbrook et al., 2008].
A abordagem escolhida foi a indutiva, caracterizada por partir de um conjunto de
dados particulares, suficientemente constatados (amostra), inferindo-se uma verdade
universal, não contida nas partes examinadas (população) [Marconi et al., 2008].
O escopo da pesquisa envolveu dois métodos de pesquisa: revisão sistemática da
literatura [Kitchenham et al., 2007], como forma de analisar e interpretar um conjunto
de dados obtidos na literatura existente sobre uma questão de investigação particular, área
temática ou fenômeno de interesse, baseando-se em evidências; e a partir dos estudos
escolhidos na revisão, um experimento controlado [Juristo et al., 2010], como forma de
analisar as abordagens existente e a partir desta análise avaliar qual a melhor forma de
utilizar pontos de função em projetos que utilizam metodologias ágeis para o
desenvolvimento de software. A análise do experimento será feita levado em
consideração os valores obtidos sobre os aspectos da precisão do valor estimado e do
tempo gasto para se chegar ao valor estimado.
Com relação ao progresso da pesquisa, a revisão sistemática já foi realizada e as
abordagens existentes já foram escolhidas: Extending Function Point Analysis [Banerjee
et al., 2012], Function Point Analysis and Cost Estimation in An Agile Development
Environment [Alexander, 2009] e Agile Estimation Using Functional Metrics [Cagley,
2009]. O planejamento do experimento controlado está na fase de validação. A Tabela 1
mostrar o cronograma da pesquisa.
Tabela 1. Cronograma da pesquisa.
Atividade/Período
2013.1
2013.2
2014.1
2014.2
1. Estudo Inicial e Créditos do Mestrado
2. Revisão Sistemática e Planejamento do Experimento
3. Execução do Experimento e Análise dos Resultados
4. Escrita da Dissertação
5. TRABALHOS RELACIONADOS
Não foi encontrado nenhum estudo de comparação semelhante ao proposto. No
entanto, foram encontrados trabalhos específicos sobre o uso de APF em métodos ágeis.
Santana [Santana et al., 2011] realizou uma pesquisa sobre o relacionamento entre Pontos
de Função e o valor inicial de Story Points descobertos após o planning poker de SCRUM.
Cong e Cao [Cong et al., 2013] fizeram uma revisão sistemática sobre formas de medição
de software existentes. Banerjee [Banerjee et al., 2012] observou que existe uma
correlação linear entre o esforço consumido e o tamanho estimado de cada iteração.
6. CONTRIBUIÇÃO ESPERADA E TRABALHOS FUTUROS
A proposta desta pesquisa é examinar as soluções existentes no uso de pontos por
função em projetos de software que utilizam metodologias ágeis e determinar a melhor
abordagem. O principal desafio deste trabalho é encontrar uma proposta de uso que seja
de fácil utilização e que realmente faça o relacionamento entre as metodologias de forma
correta e concisa. Como contribuição, espera-se que a partir da análise feita pelo estudo
das diferentes soluções, as empresas que precisem realizar este tipo de medição possam
69
WTDQS 2014
usar o estudo como base para a escolha de qual solução lhe atende melhor e, assim,
escolher a que mais lhe satisfizer.
Considerando que o experimento possui um número limitado de propostas e
projetos, é interessante que o estudo seja ampliado para que os resultados possam ser
generalizados e aproveitados por empresas de diferentes perfis.
REFERÊNCIAS
Abrahamsson P.; Salo, O.; Ronkainen J.; Warsta J., 2002; “Agile software development methods Review
and analysis”. VTT Publications, Finland.
Agile Manifest, 2001; Disponível em http://agilemanifesto.org.
Albrecht A. J., 1979; Measuring Application Development Productivity. In Proc. IBM Applications
Development Symposium. GUIDE Intl. and Share Inc., IBM Corp., Monterey, pp. 83.
Alexander A. J., 2011; Case Study: Function Point Analysis and Cost Estimation in An Agile Development
Environment. Disponível em http://www.devdaily.com/fpa/fpa-louisville-agile/.
Banerjee A. U.; Narayanan B. K.; Mahadevan P C., 2012; Estimating Agile Iterations by Extending
Function Point Analysis. In: WORLDCOMP’12.
Cagley T., 2009; Agile Estimation Using Functional Metrics. The IFPUG Guide to IT and Software
Measurement IFPUG CRC Press.
Cockburn, A.; Highsmith, J., 2001; “Agile Software Development: The Business of Innovation” Journal
Computer archive Volume 34 Issue 9, September 2001 Page 120-122.
Cong D. N.; Cao D. T., 2013; A Review of Effort Estimation Studies in Agile, Iterative and Incremental
Software Development. 2013 IEEE RIVF Intl. Conf. on Computing & Communication Technologies Research, Innovation, and Vision for the Future (RIVF).
Easterbrook, S., Singer, J., Storey, M. A., & Damian, D. (2008). Selecting empirical methods for software
engineering research. In Guide to advanced empirical software engineering (pp. 285-311). Springer
London.
Fuqua, A. M., 2003; “Using Function Points in XP-Considerations”. In: Extreme Programming and Agile
Processes in Software Engineering, LNCS vol. 2675/2003, pp. 1013.
IFPUG, 2010: Function Point Counting Practices Manual, v4.3.1. Disponível em http://www.ifpug.org
ISO
20926,
2009:
Disponível
em
http://www.iso.org/iso/iso_catalogue/catalogue_tc/
catalogue_detail .htm?csnumber=35582.
Juristo N., Moreno A. M.: 2010; Basics of software engineering experimentation. Kluwer Academic
Publishers.
Kitchenham, B.; Charters, S. 2007; Guidelines for performing systematic literature reviews in software
engineering, Technical Report EBSE-2007-01, School of Computer Science and Mathematics, Keele
University.
Leffingwell D., Behrens P. 2009; A User Story Primer, Leffingwell, LLC.
Lei 8666, 1993: Disponível em http://www.planalto.gov.br/ccivil_03/leis/l8666cons.htm.
Marconi, M. A.; Lakatos, E. M., 2008; Metodologia Científica. 6a. ed. São Paulo: Atlas.
Mens, T.; Demeyer, S., 2001; Future Trends in Software Evolution Metrics. IWPSE '01 Proceedings of the
4th International Workshop on Principles of Software Evolution, pp. 83-86.
Santana, C. A. ; Leoneo, F. S. ; Gusmão, C. M. G. ; Vasconcelos, A. M. L. , 2011; Using Function Points
in Agile Projects. 12 Int. Conf. Agile Processes and eXtreme Programming in Software Engineering.
Sommerville, I., 2011; Engenharia de Software. Editora Addison-Wesley.
70
Um Mapeamento para Apoio ao Processo de Gerência de
Portfólio de Projetos no Contexto do MR-MPS-SW adotando
Práticas Ágeis
Gleise Pinheiro Baldez¹, Sandro Ronaldo Bezerra Oliveira¹
1
Programa de Pós-Graduação em Ciência da Computação (PPGCC) – Universidade
Federal do Pará (UFPA) - Rua Augusto Corrêa, 01 – Guamá – Belém - PA - Brasil
Abstract. This paper presents a work that aims to provide a mapping that can
be adopted by institutions that seek to implement the Project Portfolio
Management process adhering to the MPS.BR quality model and do it using
the flexibility proposed by practices included in agile methods. With this we
intend to contribute to decrease the time for decision making in the process
and to create an environment which changes can be more easily circumvented.
Resumo. Este artigo apresenta um trabalho que tem como objetivo fornecer
um mapeamento que possa ser adotado por instituições que busquem
implementar o processo de Gerência de Portfólio de Projetos aderente ao
modelo de qualidade MPS.Br e que o faça utilizando a flexibilidade proposta
por práticas contidas nos métodos ágeis. Com isso, pretende-se contribuir
com a diminuição do tempo para tomada de decisão no processo e ainda criar
um ambiente cuja as mudanças possam ser contornadas mais facilmente.
A relevância da área da Tecnologia da Informação (T.I) nas organizações vem
crescendo a cada ano que passa, devido ao aumento dos investimentos e a sua
importância para a realização das atividades dentro das empresas. Dessa forma, os
gestores têm sido pressionados a levarem em consideração os riscos e retornos das suas
decisões (KIM e SANDERS, 2002).
A consequência de decisões incorretas pode ser observada em: sistemas não
concluídos ou abandonados; sistemas que não trouxeram o retorno esperado; sistemas
concluídos em desconformidade com o que foram solicitados pelo cliente; sistemas que
excederam o tempo que foi planejado; dentre outros fatores. Esses projetos drenam
recursos escassos que poderiam ser direcionados a projetos capazes de trazer mais
benefícios para as organizações (YELIN, 2007).
Dentro deste contexto e segundo a definição do PMI(2006), a Gerência de
Portfólio - GPP ajuda na tomada de decisões quanto: a identificação; priorização;
autorização; gerência e controle de projetos, programas e outros trabalhos relacionados;
para atingir objetivos específicos da estratégia de negócio. Consequentemente, a GPP
deve ajudar a organização no alcance dos seus principais objetivos, mesmo que ocorram
mudanças nos requerimentos mais importantes dos projetos alocados neste portfólio.
Ratificando a importância da GPP para a tomada de decisão, observa-se a
recente incorporação deste processo na norma ISO/IEC 12207:2008 (ABNT, 2009) e
em seguida ao MPS.BR (Programa de Melhoria do Processo de Software Brasileiro)
(SOFTEX, 2012), ambos voltados especificamente ao ciclo de vida de software.
Segundo Cooper et al. (2001) e Henriksen e Traylor (1999), a seleção de
projetos para a formação de portfólios não é uma área de conhecimento recente e vem
71
WTDQS 2014
sendo estudada há décadas por diversas outras áreas, tais como: a indústria de novos
produtos, a farmacêutica e a de exploração de petróleo. No entanto, na área de
desenvolvimento de software estes estudos não são muito aprofundados e não existem
em abundância (BIFFL et al., 2006).
Mesmo com a adoção de modelos, onde o processo de GPP está presente, as
empresas estão incluídas em ambientes de negócios dinâmicos, o que gera incertezas e
grandes desafios para lhe dar com mudanças constantes. Nesse contexto, o modelo
tradicional de gestão de projetos tem sido questionado quanto a sua eficácia, e novas
competências vem sendo desenvolvidas (CONFORTO e AMARAL, 2007).
Desta forma, o gerente de portfólio de projetos precisa de mecanismos aliados a
processos que justifiquem a tomada de decisão no momento de selecionar os projetos
que estejam de acordo com os objetivos estratégicos da organização e ainda realizar isso
com a agilidade que se espera no contexto onde mudanças estão muito presentes.
Para Humphrey (1989) um processo de software é definido como o conjunto de tarefas
de Engenharia de Software necessárias para converter requisitos dos usuários em
software. O mesmo autor define a busca pela qualidade de duas formas: a qualidade do
processo, a partir da obtenção da melhoria no processo, impactando diretamente na
qualidade do produto; e a qualidade do produto, baseada na identificação das
características dos produtos a serem desenvolvidos.
Voltados à qualidade do processo, observa-se que modelos e normas têm sido
definidas e adotadas por empresas de software. Podem-se citar as seguintes: no cenário
internacional, o modelo CMMI (Capability Maturity Model Integration) (SEI, 2010) e a
Norma ISO/IEC 12207 (ABNT, 2009); e no cenário nacional, desde 2003, o Programa
de Melhoria do Processo de Software Brasileiro (MPS.BR) (SOFTEX, 2012) é um
grande incentivador à competitividade das empresas brasileiras, definindo um modelo
de referência, o MR-MPS-SW (Modelo de Referência do MPS.BR para Software), que
é compatível ao CMMI e a ISO/IEC 12207.
No MR-MPS-SW, o processo de Gerência de Portfólio de Projetos - GPP é
descrito com o seguinte propósito: “iniciar e manter projetos que sejam necessários,
suficientes e sustentáveis, de forma a atender os objetivos estratégicos da organização.
Este processo compromete o investimento e os recursos organizacionais adequados e
estabelece a autoridade necessária para executar os projetos selecionados. Ele executa a
qualificação contínua de projetos para confirmar que eles justificam a continuidade dos
investimentos, ou podem ser redirecionados para justificar” (SOFTEX, 2012).
Souza (2013) definiu um framework de processos para GPP com base em
padrões de qualidade para que empresas pudessem ter ao menos um modelo básico a ser
configurado e, em alguns casos, adaptados à realidade da instituição e assim conseguir
realizar as práticas de GPP aderentes a padrões de qualidade.
Para validar este framework, o mesmo foi inserido no contexto de uma fábrica
de software identificando assim: pontos fortes, pontos fracos e oportunidades de
melhoria. Sendo que anteriormente a isto, para que pudesse servir como base de
conhecimento para a sua construção foi realizado um mapeamento, onde o autor optou
por analisar a compatibilidade e a complementaridade entre modelos, normas e padrões
estabelecidos que disseminassem boas práticas para GPP. Como forma de avaliação
72
quanto à conformidade do mapeamento, foi realizada uma avaliação por especialista.
Desta forma, o mapeamento serviu de insumo para o framework com o objetivo de
analisar a sua aplicabilidade.
Mesmo com este processo bem definido e com a adoção de padrões de
qualidade, empresas, principalmente as de pequeno porte, buscam mais flexibilidade no
desenvolvimento de seus produtos e respostas rápidas a questões de processo e
organizacionais.
No século passado nasceram vários métodos de desenvolvimento que se
apoiavam nas idéias de produção da Toyota. Em uma tentativa de encontrar formas
comuns, dezessete destes criadores reuniram-se em fevereiro de 2001 em Utah para o
surgimento do manifesto ágil. Embora o manifesto descreva as idéias mais básicas, há
entre os autores mais acordos que expostos no documento com foco na qualidade.
Desde seu surgimento, os métodos ágeis têm despertado interesse na
comunidade de desenvolvimento de software por representarem uma alternativa aos
modelos e processos mais tradicionais de Engenharia de Software. Neste sentido, o
desenvolvimento ágil é uma tendência devido ao ritmo acelerado de mudanças que as
empresas lidam diariamente, além da questão de constantes pressões por inovação,
concorrência acirrada e grande dinamismo no ambiente de negócios (BOEHM, 2006).
Trabalhos recentes discutem as potencialidades do relacionamento entre
métodos ágeis e modelos de maturidade sob diferentes perspectivas. De tal forma que
haja um equilíbrio para utilização de métodos ágeis e modelos de maturidade.
Dentre os relatos de experiências enocntrados na literatura podem-se citar:
Catunda et al. (2010) relatam o processo de implementação do nível F do MR-MPS
com práticas do método ágil Scrum, onde os autores relatam que a empresa já adotava
algumas práticas do Scrum e que tinha o interesse de melhorar a qualidade dos seus
processos; e Silva et al. (2011) apresentam a definição de um processo padrão resultante
da combinação de elementos do Processo Unificado, do Scrum e do XP – eXtreme
Programming para alcançar o nível F do MR-MPS.
Antes de formalizar a metodologia de pesquisa, iniciou-se este trabalho com um
aprofundamento dos estudos relacionados aos seguintes tópicos: Gerência de Portfólio
de Projeto em seu contexto geral e específico como um processo dentro do MPS-BR
(SOFTEX 2012), a fim de conhecer a área de pesquisa, para que fosse possível
identificar o que a literatura expõe sobre este assunto; os conceitos e as práticas
adotadas pela metodologia ágil por empresas, a fim de identificar os métodos que
poderiam melhor relacionar-se dentro do contexto de atividades de um processo. Este
processo é o definido previamente no trabalho de Souza (2013).
Do ponto de vista da natureza desta pesquisa, pretende-se realizar uma pesquisa
aplicada, buscando oferecer suporte ao processo de GPP segundo uma visão flexível e
com um modelo estabelecido e validado com qualidade. Este trabalho tem como
proposta auxiliar as empresas que implementam ou pretendem implementar o processo
de GPP a fazerem conforme os resultados esperados do MR-MPS-SW, porém com as
características de flexibilidade que as empresas procuram.
Em posse das informações iniciais estudadas e descritas acima. A metodologia
adotada seguirá os seguintes passos:
73
WTDQS 2014
Verificação das atividades definidas por Souza (2013), para verificar como a
empresa participante da pesquisa executa as atividades de GPP;
• Análise do questionário, para que os resultados gerados possam integrar no
mapeamento, já que a forma como a empresa realiza o processo GPP servirá
como base para o entendimento do problema a ser resolvido;
• Estudo de práticas ágeis que possam ser mapeadas e aderentes às práticas do
processo de GPP;
• Realização de um Survey em empresas avaliadas no nível F e superior, que
tenham como processo de desenvolvimento de software práticas ágeis, buscando
avaliar a forma de implementação da GPP nestas empresas e as dificuldades
encontradas pelas mesmas;
• Elaboração do mapeamento;
• Avaliação do Mapeamento por um especialista da área;
• Realização de um estudo de caso, para aplicar os resultados gerados na pesquisa
e observar as proposições.
Foram considerados trabalhos que estão associados ou próximos ao contexto que se
procura investigar, que são: (i) definição de frameworks, Processos e Metodologias para
o processo de GPP; (ii) aplicação de metodologias ágeis em empresas que possuem a
certificação em algum nível de maturidade do MR-MPS-SW.
No contexto de trabalhos relacionados ao tópico (i), Correia (2005) traz como
proposta um modelo para gestão de portfólio denominado de “Portfolius”, onde o
mesmo busca definir um modelo de gestão de portfólio, levando em consideração riscos
e decisões estratégicas para que estes fatores pudessem auxiliar na gestão de portfólio
de múltiplos projetos. O ponto negativo identificado desta pesquisa foi a falta de
formalismo na definição do processo que foram empregados nos módulos do modelo.
A monografia de Medeiros e Simões (2006) analisou a aderência entre a
ferramenta Rational Portfolio Manager (RPM) e o modelo Portfolius (CORREIA,
2005), onde o foco foi observar o quanto a ferramenta RPM fornece suporte ao que foi
definido no modelo, sendo enfatizado os níveis mais altos do modelo (Planejamento
Estratégico, Seleção e Priorização de Projetos e Revisão). A flexibilidade da ferramenta
investigada mostrou que ela pode atender a outros processos de gestão em si, porém o
trabalho ressalta que a maior dificuldade é definir critérios claros, efetivos e
consistentes para gestão de portfólio.
Souza et al. (2009) propõem um processo para apoiar a gerência estratégica de
portfólio. Este trabalho busca identificar regras de governança do portfólio,
identificação e categorização dos projetos, seleção, priorização e balanceamento do
portfólio, manutenção do pipeline (projetos em execução) e encerramento dos projetos.
Este trabalho orientou-se com base nas melhores práticas de projetos, programa e
portfólio. Possui, ainda, aderência ao processo de GPP da norma ISO/IEC 12207:2008.
O ponto negativo é que este trabalho é anterior à adição no MR-MPS-SW do GPP.
Posterior a este trabalho, Souza (2013) propõe um framework de processos para
apoiar o processo de GPP, abrangendo as atividades que não foram apontadas por Costa
(2010). Assim, este trabalho possui conformidade com as orientações fornecidas pelo
Guia de Implementação do MPS.BR, pela Norma ISO/IEC 12207 e pelo Padrão para
Gerência de Portfólio do PMI. O trabalho de Souza é extremamente relevante para
•
74
pesquisa, pois nele foi feito o mapeamento completo das atividades que devem ser
realizadas para obter conformidade ao processo de GPP com sucesso e aderente às
melhores práticas, porém o autor não instrui o “como fazer”, ou seja, executar tais
atividades.
No que diz respeito aos trabalhos relacionados ao tópico (ii), Catunda et al.
(2011) relata uma experiência de implantação do Nível F do MR-MPS-SW. Neste
trabalho, os autores relatam os desafios que foram encontrados em cada um dos
processos que devem ser implementados neste nível, sendo que no processo de GPP o
maior desafio foi elaborar critérios e a pontuação necessária para priorização de
projetos. Vale ressaltar, que mesmo o trabalho tendo grande relevância dentro do
contexto desta pesquisa, o mesmo não apresentou claramente como foram realizadas as
tarefas para atender os resultados esperados do processo.
O livro de Rubinstein et al. (2013) relata a história de Tahini – Tahini, uma
empresa fictícia que busca inter-relacionar métodos ágeis com resultados esperados do
MR-MPS. O livro mostra claramente como é o contexto da empresa durante a evolução
dos níveis e como as discursões levam à implantação dos resultados esperados. Porém,
mas uma vez, não fica claro como são realizadas as atividades que suprem o
atendimento dos resultados esperados do processo de GPP.
O trabalho de Souza et al. (2010), mostra como resultado um estudo empírico
sobre a utilização de metodologias ágeis no desenvolvimento de software, sendo de
fundamental importância para entender como utilizar as práticas ágeis, porém não é
aderente a nenhum modelo de qualidade.
O objetivo geral deste trabalho é definir como MPEs – Micro e Pequenas Empresas,
podem utilizar um framework de processo, definido para gerência seu portfólio de
projetos em conformidade ao modelo de referência do MPS.BR (MR-MPS-SW)
utilizando práticas constantes em métodos ágeis.
Para que este objetivo seja alcançado, os seguintes resultados foram
estabelecidos como metas:
Mapear as atividades do framework que será utilizado, quanto aos resultados
esperados constantes no processo de GPP do Nível F do MR-MPS-SW;
• Identificar práticas definidas nos métodos ágeis que sejam capazes de atender
aos resultados esperados do processo de GPP;
• Verificar a aplicabilidade das atividades mapeadas do framework e as práticas
referentes aos métodos ágeis;
• Conduzir a aplicação do processo definido de gerência de portfólio de projetos
aderente a práticas de metodologias ágeis em uma organização de software
paraense, para observar sua aplicabilidade.
6. Agradecimentos
Este trabalho é parte do Projeto SPIDER – Software Process Improvement:
DEvelopment and Research, da UFPA.
Referências
ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (2009) “NBR
ISO/IEC 12207:2009 – Engenharia de Sistemas de Software – Processos de Ciclo de
Vida de Software”. Rio de Janeiro.
•
75
WTDQS 2014
Biffl, S., Boehm, B., Aurum, A., Grümbacher, P. (2006) “Value-Based Software
Engineering”. Springer-Verlag, Germany.
Boehm, B. (2006) “A View of 20th and 21st Century Software Engineering”. In
Proceedings of the ICSE.
Catunda, E., Nascimento, C., Cerdeiral, C., Santos, G., Rocha, A. R. (2010)
“Implementando o Nível F do MR-MPS com Práticas da Metodologia Ágil Scrum”.
In: VI Workshop Anual do MPS.
Conforto, E, Amaral, D. (2007) “Escritório de projetos e gerenciamento ágil: Um novo
enfoque para a estrutura de apoio à gestão de projeto ágeis”. Anais do Encontro
Nacional de Engenharia de Produção - ENEGEP.
Correia, B. C. S. (2005) “Portfolius: Um Modelo de Gestão de Portfólio de Projetos de
Software”. Dissertação de Mestrado apresentada à Pós-Graduação em Ciência da
Computação da Universidade Federal de Pernambuco – CIN/UFPE. Recife, PE.
Costa, C. S. (2010) “Uma abordagem baseada em evidências para o gerenciamento de
projetos no desenvolvimento distribuído de software”. Dissertação de Mestrado –
Programa de Pós-Graduação em Ciência da Computação - Universidade Federal de
Pernambuco, Recife.
Cooper, R. G., Edgett, S. J., Kleinschmidt, E. J. (2001) “Portfolio management for new
products, Cambridge, Mass.: Perseus.
Henriksen, A. D., Traylor, A. J. (1999) “A Practical R&D Project-Selection Scoring
Tool”. IEEE Transaction on Engineering Management. New York, v.43, n.42, May.
Humphrey, W. S. (1989) “Managing the Software Process”. The SEI Series in Software
Engineering. Addison-Wesley.
Kim, Y. J., Sanders, G. L. (2002) “Strategic actions in formation technology investment
based on real option theory”. Decision Support Systems, v. 33, nº 1, p. 1-11.
Medeiros, A., Simões, R. (2006) “Investigando o Modelo de Gestão Portfolius no
Rational Portfolio Manager®”. Trabalho de Conclusão para o Programa de
Residência Quality-Pitang.
Rubinstien, V. L., Boria, J. L., Rubinstein, A. (2013) “A História da Tahini-Tahini:
Melhoria de Processos de Software com Métodos Ágeis e Modelo MPS”. PBQP-SW.
SEPIN-MCTI.
SEI – Software Engineering Institute (2010) “Capability Maturity Model Integration for
Development – CMMI-Dev”. Versão 1.3. Carnegie Mellon.
"Melhoria do Processo de Software Brasileiro (MPS.BR) - Guia Geral 2012". Brasil.
Souza, A. D., Rocha, A. R. C., Santos, G., Carmo, T. V. P., Alexandre, D. B. (2009)
“Uma Abordagem para Gerência Estratégica de Portfólio com Foco na Seleção de
Projetos”. VIII Simpósio Brasileiro de Qualidade de Software – SBQS 2009, Ouro
Preto, MG.
Souza, C. R. B., Treccani P. J. F. (2010) “Utilização de Metodologias Ágeis no
Desenvolvimento de Software: Resultados de um Estudo Empírico”. In Proceedings
of 7th Experimental Software Engineering Latin American Workshop.
Souza, M. R. A. (2013) “Um framework de processo para gerência de portfólio de
projetos de software com base em Padrões de qualidade”. Dissertação de Mestrado
apresentada ao Programa de Pós graduação em Ciência da Computação - UFPA.
76
Estratégia de Apoio à Seleção de Técnicas para Elicitação
de Requisitos
Renata Magalhães Rêgo, Arilo Cláudio Dias Neto
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
{renata.rego, arilo}@icomp.ufam.edu.br
Abstract. The requirements elicitation deals of project´s conception and
allows that specific necessity of customer be examined with the purpose of
design a solution. One of found difficulties is the definition of the appropriate
technique to perform the requirements elicitation, since the projects have their
peculiarities as well as development teams and involved stakeholders. This
work purposes to develop a strategy that assists the software engineer in the
selection (s) technique (s) most appropriate (s) for each project, considering
the particularities of each project and the involved team profile. To implement
this strategy this problem will be modeled as a optimization combinatory
problem. Thus algorithms will be implemented using meta-heuristics.
Resumo. A Elicitação de Requisitos trata da concepção do projeto e permite
que necessidades específicas do cliente sejam examinadas com o propósito de
projetar uma solução. Uma das dificuldades encontradas é a definição da
técnica adequada para realizar a elicitação de requisitos, visto que os
projetos têm suas particularidades, bem como as equipes de desenvolvimento
e os stakeholders envolvidos. Neste trabalho propõe-se desenvolver uma
estratégia que auxilie o Engenheiro de Software na seleção da(s) técnica(s)
mais apropriada(s) para cada projeto, considerando as particularidades de
cada projeto e o perfil do time envolvido. Para implementar essa estratégia,
este problema será modelado como um problema de otimização combinatória.
Desta forma, algoritmos serão implementados utilizando meta-heurísticas.
1. Introdução e Caracterização do Problema
A Engenharia de Requisitos é uma fase comum em processos de desenvolvimento de
software, pois se trata da concepção do projeto e permite que seja examinado o contexto
no qual um determinado negócio está inserido, as necessidades específicas do cliente, as
prioridades entre as atividades, as informações, funções e comportamentos que terão um
impacto profundo no projeto resultante (Pressman, 2011).
Estudos realizados por Boulila et al. (2011) indicam que problemas identificados
em fases posteriores à de Elicitação de Requisitos do projeto têm solução mais cara que
os problemas identificados durante essa fase, e que 40% das causas de falhas em
projetos de softwares estão relacionadas ao fato de que as funcionalidades entregues não
atendem às necessidades do cliente.
Carrizo et al. (2014) afirmam que geralmente os engenheiros de software
tendem a selecionar técnicas com as quais estão familiarizados, ou uma técnica muito
conhecida, ou uma técnica que já funcionou em outros projetos. No entanto, essa forma
de seleção subjetiva pode trazer resultados negativos a elicitação, impactando na
qualidade do produto final.
77
WTDQS 2014
Para Barbosa et al. (2009) e Kausar et al. (2010), tanto projetos quanto times de
desenvolvimento e stakeholders possuem características peculiares, formando assim
perfis que deveriam ser considerados durante o processo de escolha das técnicas para
coleta dos requisitos.
Diversos problemas de Engenharia de Software 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 conjunto muito grande de possíveis soluções (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 tais problemas.
A aplicação de metaheurísticas em problemas da Engenharia de Software 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 de Engenharia de Software que aplica técnicas baseadas em busca para resolver
diferentes problemas de otimização em diversas áreas de Engenharia de Software.
Para Harman et al. (2010), as abordagens de SBSE oferecem um conjunto de
soluções adaptativas automáticas e semiautomáticas para situações em que o problema
envolve múltiplos objetivos concorrentes e conflitantes. Essas abordagens permitem
obter automaticamente soluções para tarefas complexas e contribuem para redução de
esforço/custo associado ao desenvolvimento de software (Colanzi et al., 2013).
Este artigo apresenta o andamento de uma 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 semiautomatizada para seleção de técnica(s) de elicitação de requisitos baseadas nos perfis
dos membros do time de desenvolvimento e no tipo de projeto de software a ser
desenvolvido, a fim de auxiliar ao Engenheiro de Software na seleção de técnicas de
elicitação de requisitos em projetos de software.
Nesta seção, serão apresentados
desenvolvimento dessa pesquisa.
os
conceitos
relevantes
relacionados
ao
2.1. Engenharia de Requisitos
O processo de desenvolvimento de software é composto por fases que variam de acordo
com o método utilizado pela equipe. Uma fase comum a todos os processos é a
Engenharia de Requisitos que, para Sommerville (2011), é um estágio particularmente
crítico do processo de software, pois os erros nesse estágio conduzem inevitavelmente a
problemas posteriores no projeto e na implementação do sistema. Esse trabalho está
focado no segundo na fase de Elicitação, que será detalhada a seguir.
2.2. Elicitação de Requisitos
Elicitação de requisitos é a parte do processo onde os analistas trabalham com os
clientes e usuários finais para que possam aprender sobre o domínio do sistema, quais
serviços que o sistema deve oferecer, o desempenho esperado, restrições de hardware,
dentre outros aspectos (Sommerville, 2011). É um conjunto de ações que ocorrem no
universo de informações visando capturar as informações que subsidiarão o
78
entendimento do problema (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).
Em (Batista e Carvalho, 2003) e (Barbosa et al., 2009) os autores afirmam que
levar em consideração o perfil da equipe de projeto, no que se refere a analistas e
stakeholders, pode contribuir com a seleção da técnica de elicitação mais adequada.
Segundos os autores, existem fatores que se não forem levados em consideração, como
por exemplo o conhecimento do analista sobre a técnica a ser aplicada, a familiaridade
com o domínio do problema, a experiência com elicitação, a analise de situações, entre
outros, podem interferir na aplicação da técnica e esta pode não trazer um resultado tão
satisfatório quanto o esperado.
Outro fator importante que deve ser visto como contribuição para uma seleção
de técnicas de elicitação de requisitos apropriada são os tipos de projeto. De acordo com
Kausar et al. (2010), estes tipos podem ser de várias naturezas, como por exemplo:
Sistemas Críticos, Distribuídos, Interativos, Pequeno, Médio ou Grande porte. Saber a
natureza do problema é um fator importante, pois viabiliza a avaliação das técnicas e a
construção de fundamentos iniciais com base nos tipos de problemas.
Existem algumas técnicas de Elicitação de Requisitos já conhecidas na literatura
técnica, como por exemplo: Entrevistas, Questionário, Brainstorming, Etnografia,
Análise de Documentos, JAD, Prototipação, Cenários, Workshops, entre outras. Cada
técnica possui características específicas e contextos mais adequados para serem
aplicadas. O objetivo desta pesquisa é estudar estas (e outras) técnicas de elicitação de
requisitos a fim de prover uma abordagem para auxiliar o engenheiro de software a
selecionar qual a mais adequada para ser aplicada ao projeto levando em conta suas
características, e outras variáveis no que se refere ao perfil do time de desenvolvimento
e dos stakeholders envolvidos.
2.3. Trabalhos Relacionados
Existem trabalhos correlatos encontrados até o momento deste artigo que abordam a
seleção das técnicas de elicitação de requisitos cujas contribuições podem ser
comparadas com a desta proposta. Alguns destes trabalhos serão apresentados a seguir:
 [Zhang, 2007]: os autores apresentam uma comparação entre as técnicas de
elicitação de requisitos para identificar fatores comuns que afetam o método de
seleção. O autor categoriza os métodos de elicitação de requisitos, posteriormente
são descritos os fatores de influência na seleção do método de elicitação, e a partir
desses fatores e das categorias, é construída uma matriz para resumir o nível de
aplicabilidade dos métodos em diferentes contextos e apresentar as estratégias para
selecionar métodos adequados para a elicitação de requisitos.
 [Barbosa et al., 2009]: os autores apresentam um processo focado na seleção da
técnica de elicitação de requisitos e a evolução do mesmo, o qual é descrito através
de cinco atividades distintas: (1) identificação do contexto do projeto, (2) realização
da apresentação inicial, (3) seleção da técnica de elicitação de requisitos; (4)
aplicação da técnica para elicitar os requisitos e (5) elaboração da lista de requisitos.
Para a atividade (3), foram escolhidas apenas cinco técnicas: Brainstorming,
Entrevistas, JAD, Questionários e Prototipação Descartável. Foram elaboradas duas
Matrizes de Decisão: uma referente aos stakeholders e a outra referente ao Projeto.
Desta forma, a seleção da técnica mais indicada passa por duas etapas e abrange
79
WTDQS 2014
características relacionadas ao perfil dos envolvidos e do projeto em questão,
avaliando as mesmas técnicas em ambos os casos para se obter o resultado final.
 [Kausar et al., 2010]: os autores apresentam diretrizes para a seleção de técnicas de
elicitação de requisitos. Diferentes técnicas foram analisadas em função das
diferentes configurações do projeto. A partir dessa análise, foram identificados os
seguintes parâmetros para seleção: a) tipo de projeto; b) tipo de stakeholder; c)
número de stakeholder; d) envolvimento do stakeholder; e) status do projeto; f)
restrição de recursos; g) restrição de agenda; h) restrição de orçamento; i) correção
funcional e j) preocupação com a qualidade. A partir dos parâmetros identificados,
foi proposta uma fórmula matemática chamada Goodness Count
, onde é o número de stakeholders, é o nível de interação, é a
qualidade dos requisitos coletados como resultado de uma técnica particular, é a
eficácia do tempo e a rentabilidade.
Em cada um dos trabalhos, aborda-se estratégias que o analista possa ter
mecanismos para realizar a seleção da técnica para a coleta de requisitos, no entanto
nem todos levam em contas as características das pessoas envolvidas e do projeto a ser
desenvolvido. Nesta proposta, pretende-se recomendar técnicas de Elicitação Requisitos
baseadas no perfil do time de desenvolvimento e dos stakeholders, bem como nas
características particulares dos projetos de software.
A metodologia empregada para o desenvolvimento deste trabalho de pesquisa está
dividida em cinco fases, conforme apresentado na Figura 1. Todas as fases estão
descritas ao longo dessa seção.
Figura 1. Metodologia da Pesquisa
3.1. Fase 1: Identificar Características das Técnicas de Elicitação de Requisitos
A primeira fase dessa metodologia é responsável por montar uma base de dados
contendo as Técnicas de Elicitação de Requisitos com um mapeamento das
características relevantes para a seleção de tais técnicas em projetos de software.

A1 – Realizar estudos exploratórios sobre a linha de pesquisa e definição dos
artigos de controle.

A2 – Realizar mapeamento sistemático da literatura sobre as técnicas de
elicitação de requisitos, dos modelos, métodos, abordagens, processos ou
metodologias são utilizados para selecionar tais técnicas em projetos de
desenvolvimento.

A3 – Analisar o material coletado para identificar as características relevantes
para a seleção da técnica de Elicitação de Requisitos.
3.2. Fase 2: Criar corpo de conhecimento sobre perfis de time de desenvolvimento,
stakeholders e projetos de software
80
A segunda fase dessa metodologia é responsável por criar um corpo de conhecimento
inerente à membros dos times de desenvolvimento, dos stakeholders e dos tipos de
projetos de software.

A4 – Evoluir o mapeamento sistemático da literatura incluindo a identificação
das características que compõem o perfil de membros do time desenvolvimento,
dos stakeholders e dos projeto de software.

A5 – Construir um corpo de conhecimento sobre perfis de time de
desenvolvimento, stakeholders e projetos de software.
3.3. Fase 3: Definir um Modelo em Otimização Combinatória para o problema
A terceira fase dessa metodologia é responsável por definir o modelo em otimização
combinatória para o problema de seleção de técnicas de elicitação de requisitos
utilizando as características identificadas nas fases anteriores.

A6 – Identificar um problema em otimização combinatória que tenha
semelhança ao de seleção de técnicas de elicitação de requisitos. Neste caso o
que mais se assemelha é o problema do Menor Conjunto Dominante

A7 – Modelar o problema de seleção de técnicas de elicitação de requisitos
como problema de otimização combinatória. Para esta atividade deve-se utilizar
o corpo de conhecimento gerado nas atividades A3 e A5.
3.4. Fase 3: Analisar, Definir e implementar metaheuristicas
A quarta fase dessa metodologia é responsável por analisar, definir e implementar as
metaheurísticas a serem utilizadas para o problema de seleção de técnicas de elicitação
de requisitos.

A8 – Analisar metaheurísticas utilizadas para resolver o problema do Menor
conjunto dominante.

A9 – Definir/Customizar metaheurísticas analisadas na atividade A8 para que
sejam aplicadas ao problema de seleção de técnicas de elicitação de requisitos.

A10 – Implementar as metaheurísticas definidas/customizadas na atividade A9.
3.5. Fase 5: Analisar os Resultados
A quinta fase dessa metodologia é responsável por realizar experimentos com as
metaheuríticas implementadas na fase anterior e avaliar os resultados obtidos.

A11 – Realizar de experimentos nas metaheurísticas implementadas na atividade
A10, onde os algoritmos devem receber alguns parâmetros como: dados do
projeto, do time e dos stakeholders. Como resultado esperado, espera-se receber
um conjunto de técnicas de elicitação de requisitos adequado para os parâmetros
recebidos.

A12 - Avaliar dos resultados obtidos confrontando-os com os modelos descritos
na literatura técnica e com opiniões de Analistas experientes a fim de identificar
as principais contribuições e possíveis melhorias.
Espera-se como resultado dessa pesquisa metaheurísticas que auxiliem na seleção de
técnicas para elicitação de requisitos em projetos de software, levando em consideração
as características do projeto, do time e dos stakeholders envolvidos, de forma que o
81
WTDQS 2014
Engenheiro de software tenha mais segurança na hora de realizar a seleção da técnica ou
do conjunto de técnicas para serem aplicadas durante a coleta dos requisitos,
contribuindo para a compreensão dos requisitos, e consequentemente na qualidade do
produto final.
Referências
Batista, E. A.; Carvalho, A.M., "Uma Taxonomia Facetada para Técnicas de Elicitação
de Requisitos". International Workshop on Requirements Engineering, Piracicaba,
2003.
Barbosa, G.; Werneck, M.; Assis, H.; Fernandes, U.; Silva, I., "Um processo de
Elicitação de Requisitos com foco na seleção da Técnica de Elicitação," VIII
Simpósio Brasileiro de Qualidade de Software, 2009, pp. 159-173.
Barbosa, G.; Werneck, M.; Assis, H.; Silva, I.; Fernandes, U., "Evoluindo um processo
de Elicitação de Requisitos com foco na seleção da Técnica mais adequada de
Elicitação," iSys – Revista Brasileira de Sistemas de Informação, vol 2, 2009,
PPGI/INIRIO.
Boulila, N.; Hoffmann, A.; Herrmann, A., "Using Storytelling to record requirements:
Elements for an effective requirements elicitation approach," Multimedia and
Enjoyable Requirements Engineering - Beyond Mere Descriptions and with More
Fun and Games (MERE), 2011 Fourth International Workshop on , 30-30 Aug. 2011.
Carrizo, D.; Dieste, O. e Juristo, N. (2014) "Systematizing requirements elicitation
technique selection," Inform. Softw. Technol.
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, F.; Morgado, G.; Oscar, P.; Silveira, D.; Alencar, A.J.; Lima, P. Schmitz, E. "Uma
Abordagem para a Transformação Automática do Modelo de Negócio em Modelo de
Requisitos," WER06 – Workshop em Engenharia de Requisitos, Rio de Janeiro,
pp.51-60, 2006.
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).
Harman, M. e Mansouri, A. (2010). "Search Based Software Engineering: Introduction
to the Special Issue of the IEEE Transactions on Software Engineering," Software
Engineering, IEEE Transactions on , vol.36, no.6, pp.737, 741.
Kausar, S.; Tariq, S.; Riaz, S.; Khanum, A., "Guidelines for the selection of elicitation
techniques," Emerging Technologies (ICET), 2010 6th International Conference on,
vol., no., pp.265,269, 18-19 Oct. 2010.
Pressman, R.S. "Engenharia de Software: Uma abordagem Profissional" 7ª Ed. - Porto
Alegre: AMGH, 2011
Sadiq, M.; Ghafir, S.; Shahid, M., "An Approach for Eliciting Software Requirements
and its Prioritization Using Analytic Hierarchy Process", International Conference on
Advances in Recent Technologies in Communication and Computing, 2009.
ARTCom '09, vol., no., pp.790,795, 27-28 Oct. 2009.
Sommerville, I. "Engenharia de Software". 9ª Ed. – São Paulo: Pearson Prentice Hall,
2011.
Zhang, Z., "Effective Requirements Development - A Comparison of Requirements
Elicitation techniques" SQM conference, 2007.
82

anais do wtdqs 2014

Transcrição

Documentos relacionados

6º Energy Efficiency Challenge

Pergunte ao especialista - PMI-ES

Pergunte ao especialista - PMI-ES

Circular 28 - Sindicato dos Bancários do Norte

Gerenciando Projetos na Era de Grandes Mudanças

2. Relatór - Professor Marcos Berenguer

Disponível para convenções, eventos, showcases etc.

Instituto Eu Quero Viver

PPA - Concursos Internacionais

Pergunte ao especialista - PMI-ES