Dívida Técnica de Usabilidade em Projetos de Software: Um Estudo de Casos Múltiplos
Palabras clave:
Dívida Técnica, Software, Usabilidade, Esforço, Estudo de CasoResumen
Contexto:Ao longo dos últimos anos, diversos estudos foram conduzidos buscando entender o fenômeno da Dívida Técnica (DT) e suas implicaçõespara o desenvolvimento de software. A maioria destes estudos foca em tipos deDT vinculados ao código-fonte. A ausência de estudos de DT do tipousabilidade motivou esta pesquisa.Objetivo:O objetivo deste artigo é caracterizar a ocorrência da dívida técnica de usabilidade, no contexto de desenvolvimento de software.Método:Realizamos um estudo de casos múltiplos, analisando itensde DT de cinco projetos de software de quatro empresas públicas Brasileiras.Resultados:Após várias etapas de seleção e validação de itens, com fortes indícios de DT, chegamos a 145 itens de DT nos sistemas de gestão de tarefasutilizados nos projetos. A análise destes itens permitiu observar que 13,79%dos itens são DT de usabilidade, e que este tipo de DT ocorreu em todos osprojetos. Numa perspectiva de esforço para pagamento da DT, medido emfunção do esforço homem-hora estimado pelas equipes para sua resolução, os itens de dívida técnica de usabilidade mostraram requerer um esforço relativamente baixo, 6,32% do total.Conclusão:Tendo em vista a importância da usabilidade para a aceitação de produtos de software e que itens de DT de usabilidade são frequentes e possuem baixo esforço para pagamento, recomendamos que ações que incluam o pagamento deste tipo de dívida num contexto de gerenciamento de DT devam ser tomadas.Descargas
Citas
Alves, N. S. R., Mendes, T. S., de Mendonça, M. G., Spínola, R. O., Shull, F., and Seaman,C. (2016). Identification and management of technical debt: A systematic mappingstudy. 70:100–121.
Ampatzoglou, A., Ampatzoglou, A., Chatzigeorgiou, A., and Avgeriou, P. (2015). Thefinancial aspect of managing technical debt: A systematic literature review. 64:52–73.
Cunningham, W. (1992). The WyCash portfolio management system. InAddendum to theProceedings on Object-oriented Programming Systems, Languages, and Applications(Addendum), OOPSLA ’92, pages 29–30. ACM.
Falessi, D., Kruchten, P., and Avgeriou, P. (2016). Introduction to the special issue ontechnical debt in software systems. 120:154–155.
Fernández-Sánchez, C., Garbajosa, J., Yagüe, A., and Perez, J. (2017). Identification andanalysis of the elements required to manage technical debt by means of a systematicmapping study. 124:22–38.
Guo, Y., Seaman, C., and Q.B. da Silva, F. (2016). Costs and obstacles encountered intechnical debt management – a case study. 120:156–169.
Kruchten, P., Nord, R., and Ozkaya, I. Technical debt: From metaphor to theory andpractice. 29(6):18–21.
Lehman, M. M. (1996). Feedback in the software evolution process. 38(11):681–686.
Li, Z., Avgeriou, P., and Liang, P. (2015). A systematic mapping study on technical debtand its management. 101:193–220.
Molich, R. and Nielsen, J. (1990). Improving a human-computer dialogue. 33(3):338–348.
Nielsen, J. (1994a). 10 heuristics for user interface design: Article by jakob nielsen.
Nielsen, J. (1994b). Usability inspection methods: Book by jakob nielsen.
Parnas, D. (1994). Software aging. pages 279–287.
Runeson,P.Host,M. (2009).Empir software eng (2009) 14:131.https://doi.org/10.1007/s10664-008-9102-8.
Runeson, Per; Host, M. R. A. R. B. (2012).Case Study Research in Software Engineering- Guidelines and Examples. John Wiley Sons Ltd.
Seaman, C. and Guo, Y. (2011). Chapter 2 - measuring and monitoring technical debt. InZelkowitz, M. V., editor,Advances in Computers, volume 82, pages 25–46. Elsevier.
Tom, E., Aurum, A., and Vidgen, R. (2012). A consolidated understanding of technicaldebt.
Tom, E., Aurum, A., and Vidgen, R. (2013).An exploration of technical debt.86(6):1498–1516.
Yli-Huumo, J., Maglyas, A., and Smolander, K. (2016). How do software developmentteams manage technical debt? – an empirical study. 120:195–218.
Zazworka, N., Spínola, R. O., Vetro’, A., Shull, F., and Seaman, C. (2013). A case studyon effectively identifying technical debt. InProceedings of the 17th InternationalConference on Evaluation and Assessment in Software Engineering, EASE ’13, pages42–47. ACM.