Os comentários estão divididos em duas partes. A primeira responde as perguntas formuladas pelos revisores e a segunda confronta algumas afirmações.
primeira parte: uma resposta para cada questão.
p1. Será que a incapacidade de encontrar todos os trechos de código impede que eles localizem os trechos mais
importantes para fazer uma alteração?
re. Eu destaco três pontos importantes para que haja uma localização precisa dos trechos.
O ponto principal é a capacidade de rastrear esses trechos para as regra de negócio (requisitos de negócio). Este artigo faz parte de um abrangente
estudo que envolve a localização de regras de negócio no código-fonte e sua posterior rastreabilidade. O objetivo final é reduzir o tempo
de manutenção dos SIs, além da redução do re-trabalho. Dois outros artigos foram submetidos para
a sessão de ferramentas deste evento. Um dedicado à extração de regras de negócio e o outro dedicado à rastreabilidade dessas regras.
p2. Qual é a influência dos estilos de projeto selecionados sobre esta questão?
re. Estamos fazendo estudos nas empresas e observamos que independentemente do estilo do projeto não há um estilo definido na escrita de regras de negócio.
Por exemplo, o código a seguir pode ser encontrado no mesmo projeto.
1.1if(c!=null) {
1.2 return c.codigo+resto;
}
2.1 if(c==null) {
2.2//lança exceção
}
2.3 return c.codigo+resto;
Embora a escrita seja completamente diferente dizem respeito a uma mesma regra de negócio. No
primeiro trecho, a regra está na linha 1.2 e no segundo na linha 2.3. Observe que os códigos das linhas 1.1, 2.1 e 2.2 dizem respeito ao requisito robustez, não sendo portanto uma
regra de negócio.
p3. Foi feito algum treinamento com os desenvolvedores ou apresentada alguma definição do que é uma
regra de negócio antes que as questões fossem apresentadas?
re. O principal objetivo desta parte do estudo é saber se os desenvolvedores de SIs "naturalmente" entram em consenso sobre a identificação de
regras de negócio no código-fonte. A hipótese original que norteia essa parte do estudo é a que os desenvolvedores de SI conseguem distinguir códigos-fontes com possíveis implementações
de regras de negócio de códigos que não têm qualquer indício da presença de regra de negócio. Por exemplo, na questão 12 não há regra de negócio em linha alguma apenas dois outros
requisitos não-funcionais de robustez (nas linhas 1 e 2 ) e adaptação (linha 3). Em questões como está esperávamos que a maioria respondesse a última alternativa "Não há regra de negócio", porém não
foi isso que ocorreu. Em uma outra análise submetida para o CLEI 2013, nós detalhamos a influência dos requisitos robustez e adaptação nas respostas.
p4. como realmente concluir que os desenvolvedores têm dificuldades de encontrar
as regras de negócio com as questões apresentadas?
re. os resultados estatísticos não deixaram dúvidas sobre a falta de consenso nas respostas. Isso mostra que os participantes
não conseguem identificar regras de negócio. Como dito na resposta em p3 uma outra análise mostrou que houve uma importante influência de outros requisitos nas respostas.
p5. No mínimo, este domínio deveria ser apresentado ao entrevistado. Como saber se algo ser ou não nulo é uma regra do negócio
sem uma apresentação prévia do domínio?
re. Em nossos estudos, nós observamos que há diversas implementações que não são regras de negócio, como os interesses robustez e adaptação apresentados anteriormente. Um fator compilador
para a análise de código-fonte é que muitas vezes a regra de negócio estão em uma única linha de um método ou simplesmente não estão implementadas no método, como é o caso da questão 12. Em casso assim, se um mantenedor que não saiba com precisão onde cada regra de negócio esteja implementada, no mínimo isso significaria um tempo gasto atoa, assim como foi observado na resposta de p1.
segunda parte: comentando algumas afirmações
a1. "As perguntas utilizadas no questionário que representa o estudo de campo são muito abertas e não permitem uma conclusão muito clara em relação a pergunta de pesquisa apresentada (que já é bastante ampla)."
re. o objetivo do artigo é mostrar que não há consenso nas respostas dos participantes. Mesmo em questões, como a 12, que não tem regra de negócio implementada os participantes não entraram em consenso.
a2. "Tal como raramente é possível afirmar que um programa está 100% testado, também é muito raro afirmar que um desenvolvedor encontrou *todos* os trechos de código que implementam determinada uma regra de negócio. No entanto, os desenvolvedores continuam trabalhando e ajustando seus sistemas."
re. As questões 6, 7, 8 e 9 obtiveram resposta que mostram que quanto mais familiar é o código-fonte maior é a impressão de que se consegue encontrar todas as regras de negócio
que estão implementadas. Esses resultados estão sendo compilados em outros artigos para submissão futura. O que podemos adiantar é que não são consistentes as respostas dessas questões com as respostas das questões 10, 11, 12 e 13. Embora "os desenvolvedores/mantenedores continuem resolvendo trabalhando e ajustando seus sistemas", esse trabalho é ineficiente quando o tarefa é manter o sistema consistente para o negócio, pois perde-se muito tempo analisando código que não faz parte do negócio.
a3. "Responder diretamente sobre a frequência de identificação de todos os trechos de software agrega pouco sobre a dificuldade de localizar as regras. Primeiro é necessário definir o que se entende como regras de negócio e depois, possivelmente com base em um exemplo, verificar se os desenvolvedores de fato não as localizam."
re. Novamente, o ponto chave é a falta de consenso, mesmo quando não há regras de negócio, como na questão 12. Neste momento não é relevante definir o que é ou não regra de negócio, pois queríamos verificar se em caso de consenso daria para tirar alguma conclusão confrontando com a literatura. Nos exemplos temos potenciais regras de negócio expressas por computações.
a4. "Os exemplos citados acima também não são sistemas de informação e, consequentemente, não são úteis para responder a pergunta de pesquisa que norteia o trabalho."
re. No nosso entendimento, a existência de computações cujos resultados são retornados, poderiam fazer parte de sistemas de informação, basta apenas uma contextualização. Perceba que as questões dizem: "possível implementação".
a5. "A análise estatística usando o teste chi-quadrado não está apresentada de forma clara: não consegui entender que distribuições são comparadas e a que se referem os p-values nas tabelas V, VII, IX e XI."
re. os p-values são claros pois revelam que não há convergência nas respostas, ou seja não há consenso.
a6. seção II.B cita três técnicas de extração de regras de negócio, mas só discute duas destas técnicas (faltou a SOFT-REDOC).
re. as técnicas são muito semelhantes entre si a soft-redoc trata de entrada e saída.
a7. "Sobre o GQM apresentado no início da seção III, não me parece que o estudo de caso esteja analisando a presença ou ausência de regras de negócio codificadas, mas a capacidade dos desenvolvedores encontrarem estas regras no código-fonte dos sistemas."
re. Sim. A palavra capacidade poderia estar presente na formulação.
a8. "Dado que o entendimento do questionário foi visto como um risco para o estudo de campo, o autor deveria relatar como foi sua aplicação no projeto piloto e que mudanças foram feitas em função destas rodadas."
re. Sim. Isso pode ser feito.
a9. "Os resultados apresentados no artigo parecem ser resultados parciais que deverão ser usados para o desenvolvimento/a conclusão de algo maior sobre regras de negócio e manutenção. Os resultados apresentados não são 'ricos' do ponto de vista de evolução de software (manutenção)."
re. Comentamos na introdução que este artigo é apenas uma expressão de um estudo mais amplo. Como foi comentado anteriormente, um outro artigo com um enfoque em outras análises foi submetido para o CLEI 2013 e dois artigos foram submetidos para a sessão de ferramentas deste evento (CBSoft 2013).
a10. Uma regra de negócio é voltada para um domínio de aplicação. No mínimo, este domínio deveria ser apresentado ao entrevistado … Além disto, outro aspecto sobre os exemplos do experimento é a própria codificação. Variáveis como 'a', 'b', 'val' são muito inapropriadas - um código-fonte com este tipo de escrita não tem qualidade. Isto dificulta a análise do código-fonte intrinsecamente.
re. Como foi abordado anteriormente, o foco deste artigo é abordar as respostas segundo o consenso sem a priori haver uma apresentação definições formais. Os participantes têm alguma experiência no desenvolvimento/manutenção de SIs, por isso, é razoável supor que haja alguma compreensão sobre o que sejam potenciais implementações de regras de negócio. O que o estudo mostrou é que essa hipótese não se confirmou na medida em que códigos que não têm regras de negócio, tais como na questão 12, como dito anteriormente, há apenas requisitos robustez e adaptação. Quanto ao nome das variáveis, elas não influenciam a resposta, pois as estruturas em si é que importam na decisão, no caso, if, else e expressões condicionais.
a11. "Quanto aos exemplos do experimento, o GUIDE Business Rules Project (2000) classifica as regras de negócio em três categorias: assertiva
estrutural, assertiva de ação e derivação. Seria interessante que a pesquisa pudesse verificar a dificuldade de cada tipo (exemplos de cada tipo) - como forma de completude."
re. No meu mestrado eu desenvolvi uma técnica de rastreabilidade para regras de negócio, para escrever a técnica eu estudei um grande conjunto de definições e modelos e posso afirmar que nenhum deles serve para precisar uma regra de negócio no código fonte. Comecei a elucidar esse caminho quando comecei a estudar as técnicas de extração de regras de negócio do código, mas mesmo essas têm importantes limitações como a falta de refinamento para outros requisitos, tais como robustez, adaptação e outros.
a12. "Falta clareza na definição do que os autores entendem sobre regras de negócio e como elas são descritas. Eles não dizem o que entendem por RN e como eles acham que os participantes esperam buscar sobre as regras de negócios no código. No casos da pesquisa, quais eram as situações específicas na qual a pesquisa foi conduzida
Os autores citam que várias técnicas de rastreabilidade foram propostas e com objetivos variados, mas não discutem quais são os objetivos e porque eles não são satisfatórios."
re. já foi comentado anteriormente.
a13. "A descrição do método da pesquisa de forma a indicar como as questões podem responder em detalhas à questão de pesquisa principal não está clara.
O artigo é parte de uma pesquisa ainda em andamento. A conclusão não enfatiza os resultados obtidos. Dizer que não há consenso não é suficiente. Espera-se encontrar causas técnicas e humanas."…"Uma melhor indicação das justificativas para a metodologia de pesquisa e para a elaboração das questões favoreceria bastante a pesquisa e o artigo. Faltou mostrar como se espera que os participantes da pesquisa deveria ter identificado a regra de negócio."
re. como dito antes, para esse artigo o foco é o consenso.
