A capacidade de relacionar processos de trabalho com os respectivos resultados esperados é um diferencial importante para as organizações, por oferecer subsídios ao gestor que levem ao aprimoramento dos seus processos de trabalho. Produtos de maior qualidade e equipe mais produtiva e valorizada são algumas das consequên- cias imediatas de melhorias na gestão da produção. Aplicações de descoberta de conhecimento em bases de dados constituem uma importante alternativa para rela- cionar variáveis de processo com as características dos produtos gerados, forne- cendo informações estratégicas relevantes. Em ambientes de desenvolvimento de software, essas informações são de grande valia para a tomada de decisão quanto ao dimensionamento dos recursos aplicados e controle de qualidade em projetos de desenvolvimento e manutenção de software.
Os objetivos geral e específicos deste trabalho eram identificar relações entre o processo de desenvolvimento de software e a qualidade do produto e elencar um conjunto de variáveis relevantes do processo de desenvolvimento de software, mu- nindo gestores do projeto de informação com potencial de melhoria da qualidade do produto final. Acreditamos que os resultados foram satisfatórios, e também que es- tes objetivos foram atingidos, porém cabem algumas considerações.
Em primeiro lugar, ainda que tenhamos utilizado o universo de dados disponí- veis, o seu tamanho reduzido permitiu apenas um estudo exploratório, evidenciando relações ao nível de hipóteses que, eventualmente, possam ser confirmadas por meio de estudos futuros. Apesar disto, três contribuições relevantes podem ser des- tacadas: (i) no nível da aplicação, os resultados são aderentes aos dados utilizados e podem ser aplicados na gestão de configuração da empresa analisada, (ii) em termos metodológicos, desenhou-se um processo de análise que pode ser aplicado sobre uma amostra maior e controlada, e finalmente, (iii) foram identificadas variá- veis do processo de desenvolvimento que mais se correlacionam com a qualidade do produto em suas diversas fases, variáveis estas previamente elencadas pela pró- pria organização, cujos gestores poderão atuar em projetos reais durante o ciclo de vida dos mesmos. Assim, por exemplo, um gestor teria elementos plausíveis para defender o investimento em capacitação visando o aumento da produtividade de um implementador ou nas revisões de GQS, já que estas duas variáveis mostraram forte correlação com a qualidade do produto.
Em segundo lugar, a ferramenta utilizada não gerou informações sobre os re- sultados produzidos por alguns algoritmos, o que prejudicou a análise comparativa dos modelos.
Um aspecto observado nesta pesquisa é a diferença entre as variáveis do processo ideais e as realmente disponíveis na organização. Apesar da empresa alvo possuir uma grande variedade de tecnologias e amplas bases, não foi possível estu- dar além da qualidade intrínseca.
Por último, a impossibilidade de uso de determinadas bases que pudessem ser analisadas para se avaliar a qualidade extrínseca dos produtos da empresa alvo restringiu o escopo da pesquisa, não deixando margem para se discutir outros pon- tos igualmente interessantes sobre a qualidade do produto.
Como recomendações, pode-se sugerir:
Estender a pesquisa para as atividades de engenharia de requisitos, análise e projeto, implementação, gestão de configuração e gestão de projetos.
Realizar um estudo comparativo dos resultados aqui apresentados em relação a outros algoritmos.
Ampliar a lista de atributos do processo, considerando-se a arquitetura como forte fator influenciador da qualidade do produto.
Estender a pesquisa considerando-se novas variáveis a serem coletadas na organização, principalmente relacionadas a requisitos não funcionais, como por exemplo, a modificabilidade, a interoperabilidade, a eficiência, a confiabilidade, a testabilidade e a reusabilidade.
Considera-se que este trabalho contribuiu para a incorporação de resultados técnico-científicos na prática de ES para a empresa alvo. Não se pode afirmar que os modelos gerados sejam aplicáveis a qualquer empresa. Acreditamos ser possível a aplicação da metodologia seguida em outros contextos, em particular em empre- sas de desenvolvimento de software com perfil semelhante.
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS-ABNT. ISO/IEC TR 9126-1: Software Software engineering - Product quality - Part 2: 1 Quality Model. 2003. BARRETO, P. L. Identificação de propriedades de software que beneficiam a sua manutenibilidade. 2011. 264 f.. Dissertação (Mestrado em Gestão do
Conhecimento e Tecnologia da Informação) - Universidade Católica de Brasília, Brasília, 2011.
BOEHM, B. W. Value-Based Software Engineering. Software Engineering Notes, v. 28, n. 2, 2003.
BUSCHMANN, F. et al. Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, John Wiley & Sons, V.2, 2000.
CHAPMAN, P. et al. CRISP-DM 1.0: Step-by-step data mining guide. SPSS, 2000. Disponível em: http://www.crisp-dm.org/download.htm. Acesso em: 20/06/2010. CHULANI, S., STEECE, B., BOEHM, B. Determining software quality using
COQUALMO, In: BLISCHKE, W. ; MURTHY, D. (Eds.), Case Studies in Reliability and Maintenance. Sidney: Wiley, 2002.
CAPABILITY MATURITY MODEL INTEGRATION-CMMI. Product Team. CMMI for Development, Version 1.2, SEI, 2006. Disponível em:
<http://www.sei.cmu.edu/cmmi/.> Acesso em: 07/10/2011.
FAUST, R. Software como interpretação: uma estratégia de software centrada no registro linguístico dos usuários. 1995. Dissertação(Mestrado em Engenharia de Produção). Florianópolis: Programa de Pós-graduação em Engenharia de Produção, Universidade Federal de Santa Catarina, 1995.
FAYYAD, U.M. et al. The KDD Process for Extracting Useful Knowledge from Volumes of Data. In: ______. Advances in Knowledge Discovery in Data Mining. Menlo Park: AAAI Press, 1996. P. 27-34.
GOLDSCHMIDT, R.; PASSOS, E. Data Mining: um guia prático. Rio de Janeiro: Campus, 2005.
GOMES, A.; OLIVEIRA, K.; ROCHA, A.R. Avaliação de Processos de Software Baseada em Medições. SIMPÓSIO BRASILEIRO DE ENGENHARIA DE
SOFTWARE, Anais .... Rio de Janeiro, 2001.
GONÇALVES, H. O Que é Qualidade?, 2007. Disponível em:
<http://hgespuny.sites.uol.com.br/bluesquare/qualidade.htm.> Acesso em: 15/03/2011.
INTERNATIONAL FUNCTION POINT USERS GROUP - IFPUG. Function point counting practices manual, Release 4.3.1. 2009. Disponível em: <ifpug-
INTERNATIONAL STANDARD ORGANIZATION- ISO. ISO/IEC STANDARD, ISO- 9000. Quality Management. Geneva: 2000. Disponível em:
<http://www.iso.org/iso/home.html.> Acesso em: 22/05/2011.
ISO 9000. In: Wikipedia. http://pt.wikipedia.org/wiki/ISO_9000. Acesso em: 21 jun 2010.
KANER,C., BOND, W. P. Software Engineering Metrics: What do they measure and how do we know?, 10TH INTERNATIONAL SOFTWARE METRICS SYMPOSIUM, Proceedings ..., 2004.
KANTORSKI, G. Z. Controle de Métricas no Processo de Desenvolvimento de Software através de uma Ferramenta de Workflow. In: I WORKSHOP DE COMPUTAÇÃO - WORKCOMP-SUL, Anais ..., 2004.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de software. São Paulo: Novatec, 2. Ed., 2007.
KRIESER, P. Métricas de Software. Disponível em: <http://www.baguete.com.br/colunistas/colunas/51/paulo-
krieser/28/04/2010/metricas-de-software.> Acesso em: 19/06/2010.
MACHADO, M. P.; SOUZA, S. F. Métricas e qualidade de software. Disponível em: <www.fattocs.com.br/download/qualidade-sw.pdf>. 2008. Acesso em: 18/07/2010. MARSHALL, I. J. et al. Gestão da qualidade. 8.ed. Rio de Janeiro: FGV, 2006. MCCULLAGH, P.; NELDER, J. A. Generalized linear models. London: Chapman and Hall. 1989.
MELO, W. “Qualidade”+“Testes de Softwares”=“Qualidade de Software”. Disponível em: <http://www.ogerente.com.br/qual/dt/qualidade-dt-ws-
testes_software.htm.> Acesso em: 19/06/2010.
MPS.BR. ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX - Guia Geral do MPS-Br: versão 1.0, maio 2006.
Disponível em:
<http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2011.pdf>. Acesso em: 21/09/2011.
OAKLAND, J. S. Gerenciamento da qualidade total: TQM; o caminho para aperfeiçoar o desempenho / Total quality management: TQM; the way for performance improvement. São Paulo: Nobel, 1994. 459 p.
PFLEEGER, S., J., R.; CURTIS, B.; KITCHENHAM, B. Measurement bases Process Improvement. IEEE Software, v.11, n. 6, pp. 8-11,1994.
PLATT, J. C. Sequential minimal optimization: A fast algorithm for training support vector machines. MSR-TR-98-14, Microsoft Research, April 1998. PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach, 6th ed, Nova York, NY: McGraw-Hill, 2005.
REIS, R. Q. APSEE–Reuse: um Meta-Modelo para Apoiar a reutilização de Processos de Software. Porto Alegre, UFRGS, 2002. 215p. Tese (Doutorado em Ciência da Computação). Instituto de Informática, Universidade Federal do Rio Grande do Sul, 2002.
RUDD, C.; LLOYD, V. Service Design Book (Itil). The Stationery Office, 2007 SANTOS, Carla. Estatística descritiva: manual de auto-aprendizagem, Lisboa: Edições Sílabo. 2007.
SFERRA, H. H.; CORREA, A. M. C. J. Conceitos e Aplicações de Data Mining, Revista Ciência & Tecnologia, Jul/Dez de 2003, p. 19-34.
SILVA, E. L.; MENEZES, E. M. Metodologia da pesquisa e elaboração de dissertação. 4 ed. Florianópolis: UFSC, 2005.
SOFTWARE ENGENEERING INSTITUTE - SEI. Capability Maturity Model Integration (CMMI), Version 1.1. Disponível em:
<http://www.sei.cmu.edu/reports/02tr002.pdf>. Acesso em: 20/10/2011.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Addison Wesley, 2007.
TEIXEIRA, E. A. Estimativa de prazo para manutenção de software baseada em data mining. 2009. 79 f.. Dissertação (Mestrado em Gestão do Conhecimento e Tecnologia da Informação) - Universidade Católica de Brasília , Brasília, 2009. WEKA. Disponível em: http://www.cs.waikato.ac.nz/ml/weka. Acessado em: 20 jun 2010.
WITTEN, I. H.; FRANK, E. Data Mining: Pratical machine learning tools and techniques, 2nd Edition, San Francisco: Morgan Kaufmann, 2005.
APÊNDICE A – Elementos que podem influenciar a qualidade de um produto de software (visão da empresa alvo)
A qualidade de um produto de software pode ser medida em 2 níveis: Qualidade Intrínseca do Produto e Satisfação do Cliente.
A Qualidade Intrínseca do Produto pode ser medida pela confiabilidade, pela disponibili- dade e pela densidade ou taxa de defeito.
A confiabilidade de software é, geralmente, definida como a probabilidade do software ope- rar sem ocorrência de falhas durante um período especificado de tempo em um determinado ambiente. A confiabilidade geralmente é definida pelo MTTF (Tempo médio para falha). A disponibilidade é um outro atributo importante de sistemas que têm software como com- ponente. Disponibilidade é a probabilidade, em qualquer instante de tempo, de um sistema funcionar satisfatoriamente em um determinado ambiente. Em outras palavras, é a probabi- lidade de um sistema está disponível quando necessário. Disponibilidade pode ser determi- nada pela relação:
Disponibilidade = 100
MTTR
MTTF MTTF
(8)
onde MTTF (Mean Time to Failure) é o tempo médio até a ocorrência de falha e MTTR (Me-
an Time to Repair) é o tempo médio de reparo.
O tempo médio para a falha descreve o tempo esperado para a falha de sistemas. Por exemplo, suponha que você testou 3 sistemas idênticos a partir do tempo 0 até que todos eles venham a falhar. O primeiro sistema falhou em 10 horas, a segunda falha ocorreu às 12 horas e a terceira falha ocorreu às 13 horas. O MTTF é a média dos três tempos de falha, que é 11,6667 horas.
É o tempo médio efetivamente gasto para o diagnóstico, localização e remoção da falha e o retorno do produto ao seu estado normal de operação, contado a partir do início do processo de manutenção.
O processo de aquisição das bases de log dos sistemas obedecem as seguintes regras: - A área de suporte a banco não fornece dados de servidor, pois infringe norma de se-
gurança (norma 10).
- Cada unidade de relacionamento com o cliente é responsável pela gestão de um ou mais sistemas.
- Há a possibilidade do centro de dados informar dados de logs de aplicação, sob a condição de que seja solicitado pelo gestor da unidade via acionamento.
- A SUPCD guarda em backup durante 1 ano o logs das aplicações após passado 1 mês.
- As bases apenas estarão disponíveis quando a autorização for conseguida pela res- pectiva URC.
Em geral, o procedimento de resgate do backup dos logs é mais demorado que o do mês atual.
Quanto à densidade de defeitos, na empresa alvo, os dados dos testes de software são guardados na ferramenta Mantis e no Relatório de Avaliação dos Testes. Lá são guardados os dados dos defeitos encontrados nas etapas de desenvolvimento e pré- operação(homologação).
O Relatório de Avaliação dos Testes contém análise dos resultados dos testes realizados, indicando:
- Defeitos encontrados com seus respectivos graus de severidade; - A cobertura dos testes de requisitos obtida em relação à planejada; - A cobertura de casos de teste obtida em relação ao total;
- Progresso dos testes por meio de métricas;
- Recomendações apropriadas aos respectivos responsáveis.
Na visibilidade do Pólo, com as manutenções corretivas do sistema que o Escritório de Pro- jetos coleta, consegue-se medir quais erros são do sistema.
O acesso aos dados de teste deve ser solicitado ao EP(Escritório de Projeto), onde o Coor- denador de Testes pode fazer o cadastro de usuário para acesso aos dados dos projetos, mediante permissão desta referida área.
Na empresa alvo, alguns projetos estão pontuados em PF (pontos de função), assim o de- nominador escolhido para o cálculo da métrica densidade de defeito pode ser o tamanho em PF, porém deve-se ter o cuidado da escolha de qual projeto a ser considerado.
A Satisfação do Cliente pode ser medida em função dos erros cometidos pelo próprio cli- ente (problemas do cliente) e do seu nível de satisfação.
Algumas métricas usadas por desenvolvedores de software na indústria medem os proble- mas dos clientes que utilizam o produto. São todos os defeitos considerados válidos e os não considerados como defeitos válidos, como por exemplo problemas de usabilidade, falta de documentação, erros do próprio usuário, desinformação de correções já realizadas). Quanto ao nível de satisfação do cliente (SLA, Remedy, etc), alguns meios aqui na empre- sa alvo são utilizados para aferir a qualidade de um produto de software.
- Faz-se uma pesquisa através de formulário, encaminhada aos clientes finais (solicitan- tes dos serviços) a cada final de projeto (encerramento). Ao final do projeto, o gerente de projeto/líder envia o Questionário de Avaliação (QA) para a unidade de relaciona- mento preencher junto ao cliente, e se responsabiliza por este preenchimento.
- Avaliação obtida através de preenchimento na própria “ordem de manuten- ção/demanda”. Via de regra, esta forma mais simples de pesquisa, nos posiciona ape- nas quanto a visão do cliente sobre a ação pontual do atendimento prestado – pesqui- sa pouco abrangente;
- Consulta telefônica, efetuada através do “call center” que recebe as solicitações, sobre a qualidade do atendimento (objetividade e treinamento do atendente, fila de espera na ligação telefônica, “approach” do técnico de manutenção, seu conhecimento e pre- paração prévia para o atendimento). Esta consulta é direcionada aos solicitantes de serviços já executados, escolhidos aleatoriamente dentro de um “espaço amostral” (geralmente as OSs atendidas no dia), com uma periodicidade muito menor do que a pesquisa de satisfação semestral.
- Controle de Backlog. Backlog é o tempo que a equipe de manutenção deverá trabalhar para executar os serviços pendentes, supondo que não cheguem novos pedidos ou Ordens de Serviço durante a execução dessas pendências. Sob o ponto de vista da
Teoria das Filas, é o tempo que os pedidos de manutenção aguardam na fila, para
atendimento, ou seja, considerando a equipe de manutenção como uma estação de Serviços e as Ordens de Serviço em uma fila de espera, o backlog será obtido a partir da relação entre a taxa de chegada e a taxa de atendimento.
A qualidade intrínseca pode também estar relacionada à arquitetura escolhida para o sof- tware, bem como os requisitos não-funcionais. Tal qualidade pode ser observável durante a execução do sistema, por meio de atributos relativos a, por exemplo, performance, seguran- ça, disponibilidade, funcionalidade e usabilidade, e também durante a não execução, por
meio atributos relativos a modificabilidade, portabilidade, reusabilidade, integrabilidade e tes- tabilidade.