AUTONOMAÇÃO NA PRODUÇÃO DE SOFTWARE

Transcrição

1 XXX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO Maturidade e desafios da Engenharia de Produção: competitividade das empresas, condições de trabalho, meio ambiente. São Carlos, SP, Brasil, 12 a15 de outubro de AUTONOMAÇÃO NA PRODUÇÃO DE SOFTWARE FERNANDO LUIZ DE CARVALHO E SILVA (IFF) nando.carvalho@gmail.br Gabriel Manhães Monnerat (UCAN) gabrielmonnerat@gmail.com Rogério Atem de Carvalho (IFF) ratem@cefetcampos.br A produção de bens intangíveis tem crescido devido ao maior acesso a Tecnologia da Informação e Comunicação (TIC) (BARRET, 1998). Um dos mais valiosos commodities atualmente é o software pois sua produção requer investimentos relativamente menores e possibilita a geração de valor agregado elevado, sem no entanto ser um objeto físico. Segundo Cusumano (1999) o sofware é estratégico para as empresas podendo ser a base de novos negócios baseados em tecnologia. Grandes vantagens tem sido obtidas pela aplicação de software para apoio a gestão empresarial (ERP). Portanto, a produção de software torna-se uma importante atividade econômica e esta precisa ser tratada à luz das técnicas modernas da gestão de produção. Desta feita, a qualidade de software é talvez uma das maiores preocupações nos dias de hoje nesta área (HAMILTON, 2007). Se por um lado convivemos há algumas décadas com software, que já é considerado uma ferramenta estratégica para empresas (PORTER, 2001), simultaneamente fomos doutrinados a acreditar que anormalidades como travamentos, mal funcionamento, inconsistências são normais, toleráveis e esperáveis nestes produtos, mas não são. O objetivo deste artigo é, sob a ótica da Engenharia de Produção, alertar para a tendência e as vantagens em automatizar Testes de Software, e que desta forma podem cobrir aproximadamente 99% da extensão real do produto, facilitando identificação precoce de anormalidades e diminuindo drasticamente a ocorrência de falhas junto ao cliente. Palavras-chaves: Enxuto Software Testes

2 1. Introdução Tradicionalmente, vários autores da Engenharia de Software (ES) (PRESMAN, 1995; SOMMERVILE, 2003) afirmam que o controle da qualidade deve ser feito por testes e inspeções em uma etapa do processo específica após a produção. Nesta etapa, 100% da produção deve ser testada e inspecionada. Os produtos onde forem detectadas anormalidades devem retornar a produção. Por um outro lado, segundo vários autores da Engenharia de Produção (EP) (OHNO, 1997; SHINGO, 1996; SLACK, 2007), as taxas de anormalidades e retrabalho devem ser minimizadas para obter qualidade e estabilidade na produção. Durante a evolução dos sistemas de produção, no início do século XX, ainda sofrendo influência da produção artesanal, os produtos apresentavam elevadas imprecisões, dificultando a montagem e substituição de peças. Nesta época Frederich Taylor introduz os métodos de inspeção manual de 100% da produção para verificar a qualidade de produtos. Segundo OHNO (1997), apesar de filtrar a chegada de produtos defeituosos às mãos dos clientes, estas inspeções geram grande desperdício na forma das perdas de materiais, salários de inspetores, funcionários para recuperar os produtos e disponibilizá-los para as vendas. A Produção Enxuta (PE) (WOMACK & JONES, 1992) apresenta soluções para a verificação autônoma na linha de produção (SHINGO, 1996) através da autonomação, liberando os operadores dos esforço manual de teste e verificação de anormalidades. De forma muito similar aos conceitos da PE, Kent Beck (2002) propõe a técnica TDD (Test-driven Development) para produção de software, que pretende garantir a detecção de anormalidades em aproximadamente 100% do código produzido. Nesta mesma obra, Beck descreve um processo de desenvolvimento de software que vem obtendo espaço na comunidade de ES, o extreme Programming (XP), que se alinha com vários dos conceitos da PE, porém sem referenciá-la explicitamente, todavia ainda não é completamente aceito pela comunidade de ES. Ocorre que a técnica de testes TDD, proposta pelo autor não é dependente deste novo processo, podendo ser utilizada em outros processos. O objetivo deste trabalho não é discutir os detalhes desta técnica de teste de software, mas sim apresentar um caso prático em que esta técnica foi implementada para aplicações empresariais (Enterprise Information Systems - EIS) baseadas em software livre, nas áreas de ERP e ECM (Enterprise Content Management), em ambiente acadêmico, onde os dados referentes ao controle da produção são descritos para a demonstração gráfica dos resultados obtidos. Espera-se que este artigo fomente o interesse na utilização da autonomação de testes de software que já apresenta resultados satisfatórios na literatura, mostrando que a mesma se aplica na construção de EIS. 2. Revisão da Literatura 2.1. Produção Enxuta (PE) Nesta seção serão revistos alguns conceitos com o objetivo de entender o ponto de vista da Produção Enxuta com relação as perdas, e possibilitar o aproveitamento destes conceitos para a melhoria da qualidade no processo de produção de software. Segundo Womack e colaboradores (1998), a produção artesanal se mostrava um processo lento e dependente do artesão para adaptação das partes até que o produto estivesse completo. O artesanato portanto depende do trabalho minucioso e da experiência do artesão para 2

3 aproveitamento das peças produzidas com anormalidades. Este problema só é sanado pelo esforço da indústria em produzir eliminando as anormalidades, o que ficou conhecido por produção de peças substituíveis ou intercambiáveis. A solução utilizada no início do século XX, foi a inspeção de 100% da produção. A desvantagem deste método são os custos excessivos e, mesmo assim, não solucionando o problema. A evolução deste método foi a inspeção aleatória, dentro de uma visão estatística, que conseguia diminuir a quantidade de anormalidades que chegavam ao consumidor. Porém o problema ainda persistia, pois a correção de anormalidades nas peças exigiria um esforço de engenharia ainda maior. A própria produção em massa só é tida como implantada de fato quando a indústria de Ford consegue padronizar as peças utilizadas na montagem do seu vigésimo modelo (Modelo T), o que possibilitou o salto qualitativo e produtivo que configura a produção em massa (WOMACK et al., 1992). As peças utilizadas para montar o modelo T, com anormalidades desprezíveis para o processo, eram tão facilmente encaixáveis ou substituíveis que tornaram o Modelo T um carro no qual os proprietários podiam operar a substituição de peças pessoalmente. A indústria aprendeu que as anormalidades geram baixa produtividade e podem se traduzir em altos custos relativos a recuperação, aproveitamento ou perda de produtos. Segundo OHNO (1997), todas estas opções configuram desperdícios, porque ao tentar utilizar um produto com anormalidades retrocede-se ao tempo da manufatura artesanal. A raiz do problema está no processo produtivo que produziu erradamente a anormalidade. Esta e outras constatações foram percebidas na origem do Sistema Toyota de Produção (STP). Segundo HOLWEG (2007), em 1918 Sakichi Toyoda já havia inventado o tear automático, que parava sua produção assim que faltasse linha (insumo), por falta ou quebra, evitando assim a necessidade de um operador ficar assistindo a produção de uma máquina, e que o produto fosse perdido no caso de alguma anormalidade. Esta forma de automação é conceituada como uma auto-inspeção (SHINGO, 1996), onde as máquinas são responsáveis pela verificação de anormalidades. Taiichi Ohno (1997) cita que este é um dos pilares do STP, chamado de Autonomação, do original em japonês Jidoka, refletindo a autonomia da máquina em detectar problemas ou anormalidades. A Autonomação representa uma forma de automação com um toque humano, e representa uma transferência do conhecimento acerca de problemas detectados no processo para a máquina (SHINGO, 1996). Uma das características da Produção Enxuta é a preocupação com o processo. Segundo Ohno (1997), um dos desperdícios da produção é se produzir anormalidades. O produto fora de conformidade pode ser perdido, retrabalhado ou vendido abaixo do preço. No melhor dos casos gera prejuízo financeiro, podendo acarretar inclusive em uma visão negativa da empresa. Uma das ferramentas para a autonomação é o Poka-yoke ou Baka-yoke, que envolve também modificar as máquinas para realizar a auto-inspeção da produção e tentar impedir o uso inadequado ou distrações no manuseio das mesmas. No STP as máquinas eram capazes de detectar anormalidades na entrada de insumos, impedindo entradas que pudessem causar problemas para o processamento e detecção de saídas com anormalidades. Dependendo da máquina ou da gravidade do caso, a máquina deveria alertar o operador e parar seu processamento, causando a parada da linha de produção. 3

4 Segundo Shigeo Shingo (1996) o abastecimento de materiais de forma inadequada nas máquinas, por distração ou qualquer outro motivo, deve ser fiscalizado pela própria máquina. Para tanto, Shingo especificava modificações para que sempre que uma anormalidade fosse detectada, as próprias máquinas alertassem ao operador. Anormalidades na saída do processamento também deveria ser alertadas ao operador, que poderia manualmente acender o Andon, que é um dispositivo que sinaliza a parada da produção através de uma lâmpada, alertando aos supervisores sobre um problema a ser estudado. A importância desta parada é a valorização da melhoria não só do produto, mas principalmente do processo. É importante notar que o momento da parada é um feedback que possibilita conhecer o problema, o levantamento de dados e a identificação da causa raiz do problema. Esta é uma visão industrial do problema de diminuição de erros e anormalidades através prevenção e da melhoria contínua do processo. A proposta deste artigo é a utilização destes conceitos para o contexto do desenvolvimento de software, visando a otimização do seu processo que produz bens intangíveis Validação e Verificação de software Além da validade do software quanto a aderência aos objetivos especificados, o software deve estar correto quanto a sua construção, isto é, ser executado para verificar se atinge aos objetivos sem erros. As falhas em software geram custos para concerto que fogem aos orçamentos de sua construção, por isso devem ser evitadas. Entretanto, os maiores prejuízos são advindos da ocorrência de falhas durante seu uso em produção, onde podem trazer prejuízos ainda maiores aos usuários (GORADIA, 1993). Atualmente considera-se que a qualidade de software está associada a inspeções e testes. As inspeções são realizadas sobre os documentos de especificação do projeto, enquanto os testes são realizados sob o código executável ou programa. As inspeções foram definidas originalmente por Fagan (1976), buscando incorreções técnicas ou quanto ao domínio do problema. Este processo é normalmente dividido em preparação, encontro e correção das anomalias encontradas. As inspeções normalmente são feitas em 100% da documentação existente, porém Thelin e colaboradores (2004), argumentam que muitas das anormalidades encontradas são sistêmicas, sendo portanto refletidas em vários outros documentos, sendo portanto bastante eficiente a amostragem de documentos, para posterior busca dos problemas encontrados em outros documentos somente quando necessário. Alguns trabalhos, por exemplo Deeprasertkul e colaboradores (2005), também apontam para a inspeção de código fonte, que verifica certas condições de programação e alerta ao programador sobre o uso inadequado de ponteiros e estruturas de programação Técnicas de Teste de Software Segundo PRESMAN (1995), testes devem ser feitos para garantir a qualidade do software, prevenindo que defeitos possam acontecer quando o software entrar em execução pelo usuário. Para tanto, durante a codificação do software, deve ser idealizado o Plano de Testes do Sistema, a ser executado na fase de Testes. Um problema grave relacionado aos testes é que uma alteração para solução de um determinado problema pode gerar mal funcionamento em outro componente não alterado, através de dependências lógicas internas. Portanto, após cada reparo torna-se necessário testar 4

5 novamente todo o sistema verificando as consequências das mudanças realizadas. Caso o sistema não seja totalmente testado a cada mudança, a demora na detecção dos erros acarreta na perda do contexto de trabalho, o que dificulta a correção dos erros. Entretanto, tais testes são custosos uma vez que demandam de um planejamento prévio, tempo para sua execução, controle do processo buscando garantir sua eficácia. Os testes realizados manualmente também agregam a possibilidade de falhas humanas, distrações ou falhas no entendimento. O teste do código possui duas descrições principais. A primeira foi a proposta de MYERS (1979) que descreve o processo de executar um programa ou sistema com a intenção de encontrar defeitos, sendo portanto um teste negativo, que é melhor quanto mais erros encontra. Na segunda descrição proposta por HETZEL (1988), o autor sugere que é mais importante avaliar o atingimento dos resultados esperados, sendo portanto essencial a definição prévia de quais entradas devem gerar quais resultados. Presman (1995) e Sommerville (2003) destacam que no ciclo de vida estruturado de software existem fases específicas para o levantamento das necessidades do usuário, análise do problema, projeto da solução, codificação do software, testes do software e aceite pelo usuário. Segundo estes autores, na fase de codificação, os requisitos são implementados, e é desenvolvido um plano de testes. Após o término da fase de codificação, pode ser iniciada a fase de testes, onde o plano de testes será executado e os resultados documentados. Cada anormalidade será reconduzida para uma das fases anteriores (análise, projeto ou codificação), visando os ajustes necessários. A fase de testes, tem especial importância pois nela se valida e verifica o software, determinando se efetivamente é atingido o objetivo desejado e com que grau de eficiência. Segundo Sommerville (2003), dentre os recursos investidos em software o montante direcionado para a manutenção de software é em média superior ao investido para seu desenvolvimento. Adicionalmente, vários autores concordam (SOMMERVILLE, 2003; PRESMAN, 1995) que mesmo durante o desenvolvimento do software, mas principalmente depois de sua conclusão, podem ocorrer mudanças na lógica do negócio a ser automatizado, gerando necessidades de manutenção do software, o que justifica o maior gasto em manutenção. É importante observar que cada modificação no software requer que todos os testes sejam refeitos, pois uma alteração pode refletir em outros pontos em função das dependências lógicas e funcionais internas comuns nestes produtos, efeito conhecido como problema de regressão. Os testes são portanto desenhados para cobrir vários pontos do projeto, desde os requisitos até as unidades de programação. Porém todos estes processos, apesar de serem importantes, são executados posteriormente às operações de produção, normalmente por outras pessoas. A programação seguida da detecção de erros ou problemas permanece sujeita ao re-trabalho, o que segundo SHINGO (1996) deveria ser evitado. Segundo CUSUMANO (1995), a empresa Microsoft, uma das maiores empresas de produção de software no mundo, durante a década de 1980 apresentava uma taxa de ocorrência de erros muito elevada, causando uma certa desmoralização da empresa frente à seus clientes e usuários. A sustentação desta empresa deveu-se a sua eficiência como player no mercado de software e à sua carteira de clientes já instalada, que era mantida através de atualizações 5

6 anuais ou bianuais pagas. Relatos do autor descrevem que a quantidade de erros era tão volumosa que diversos projetos foram cancelados porque os concertos dos erros geravam cada vez mais erros, em um ciclo intenso que levava ao cancelamento dos projetos (CUSUMANO, op.cit). Ainda neste trabalho, Cusumano descreve que no início da década de 1990, Chris Mason escreve um relatório interno desta empresa, intitulado Zero-defect code, alertando para o problema da instabilidade do processo, e sugere a mudança do processo produtivo, adotando entregas de produção diárias, busca das causas raízes dos problemas, prevenção de erros ao invés de concertos e foco em funcionalidades ao invés de desenvolvimento concomitante de diversas funcionalidades. Segundo o Middleton (2005) a busca pela simplificação do escopo ao se trabalhar orientado para as funcionalidades pequenas com entregas diárias é similar ao dimensionamento do tamanho do lote de trabalho, e a orientação às funcionalidades atinge também aos objetivos da eliminação de estoque em processo, pois não se desejava que algo ficasse inacabado e não testado. Todo software produzido e não testado, ia se acumulando, até que fosse iniciada a fase de testes, quando então durante a execução dos planos de testes, se descobria grande quantidade de erros que forçavam os desenvolvedores a chavear novamente para um contexto antigo, já abandonado, das funcionalidades já terminadas. A solução de focar em funcionalidades, mantinha o contexto aberto, exigindo que cada produção fosse imediatamente inspecionada, diminuindo o custo de setup para ajuste de anormalidades caso fosse necessário. Neste caso também diminui ou extingue o estoque de concertos a serem resolvidos, simplesmente pela mudança do processo. Ao mesmo tempo não se pode garantir que todo o planejamento e controle do processo tornem o software testado manual ou automaticamente seja isentos de falha. De fato o que se propõem com a técnica TDD é que o planejamento de testes seja feito, e ainda mais intensivo e profundo do que o manual, porém que este planejamento seja executável automaticamente e que evolua dinamicamente junto com o produto Test-Driven Development (TDD) Este artigo não se destina à descrição da técnica de TDD, pois existe suficiente material para o aprendizado disponíveis e fugiria a abordagem industrial desejada. Esta forma de testes automatizados também são conhecido como testar antes (Test-First), enquanto os testes manuais são tratados como testar depois. Os testes antes, vem do fato de se buscar de forma incremental, respostas esperadas para um sistema, módulo ou função a ser construído. Segundo Beck (2002), o teste automático de software é inspirado no processo de construção e manutenção de software, no qual se espera determinados valores que não aparecem, ou se espera por resultados que não são inicialmente atingidos. TDD busca automatizar a busca por resultados especificados antes da construção do produto. Basicamente, cada teste é uma especificação executável que mapeia as expectativas de resultados normais ou esperados para cada parte do produto. Sua execução envolve a invocação da parte do produto a ser testada, e a verificação do seu comportamento e dos resultados obtidos contra os resultados esperados. O produto só é desenvolvido após uma versão de sua especificação de comportamento e resultados esperados estar pronta. A evolução se da passo a passo, primeiro pela a evolução da 6

7 especificação seguida da evolução do produto. Tudo isso ocorre dentro de um ambiente no qual todos os testes já produzidos podem ser facilmente/automaticamente executados, verificando todo o software e gerando um feedback global sobre anormalidades encontradas. A maior vantagem esperada pela aplicação desta técnica é a segurança para o desenvolvedor, para que durante a evolução do produto, seja possível trabalhar e verificar instantaneamente anormalidades causadas pelas mudanças (BECK, 2002). Como os testes estão automatizados, o tempo e custo para sua execução caem drasticamente, e portanto estes podem ser executados mais frequentemente, tantas vezes quando necessário a qualquer momento ao longo da produção. Como consequência do feedback dos testes automatizados e frequentes, os desenvolvedores se tornam cada vez mais confiantes em produzir incrementos e melhorias no produto. Beck (op. cit.), também sugere trazer os testes automatizados para serem executados automaticamente durante a integração do produto. Esta integração pode também a ser realizada automaticamente, assim que as modificações do produto são submetidas durante o processo de produção. Neste caso, os resultados encontrados tornam-se visíveis aos desenvolvedores e aos clientes declarados como interessados, anunciando quando ocorrem problemas e quando ficam disponíveis novas versões do produto a serem testadas pelo cliente. 3.2 Estudos sobre TDD Segundo Larman e Basili (2003), uma técnica semelhante ao TDD foi inicialmente utilizada no projeto Mercury da NASA, realizado na década de 60. De acordo com Gelperin e Hetzel (1987), nesta época já se praticava os testes preventivos, onde todo o planejamento dos testes e do próprio programa se baseava nos resultados esperados, com eficiência muito superior na cobertura de testes e na quase eliminação da procura por erros. Os autores descrevem em seu artigo a técnica STEP que possui ciclo de vida paralelo a programação, e propõe o desenvolvimento simultâneo de testes e produto com a participação do cliente. Crispin (2006), começa seu artigo deixando seu depoimento: "Eu posso afirmar por experiência pessoal que TDD produz código que tem ordens de magnitude menos erros de unidade, muito menos erros funcionais, e uma probabilidade de atendimento das expectativas do cliente exponencialmente mais alta, quando comparado com técnicas de programação convencionais.". Neste artigo a autora descreve suas experiências com três equipes diferentes, quanto à evolução da capacitação destas equipes, nas quais ela atuou como treinadora de testes. As equipes estudadas variaram entre estados em que precisavam de treinamento em três estágios: ajuda com testes de unidade, ajuda com testes funcionais e já experientes. Outro ponto destacado neste trabalho (CRISPIN, op. cit.) é que os testes automáticos, também servem como exemplos e como documentação para futura recuperação do contexto do projeto. Os testes buscam por resultados seguindo exemplos passados pelos clientes, portanto ao ler os testes se consegue recuperar os objetivos de requisitos, módulos e unidades (funções e procedimentos) desenvolvidos, simplificando a recuperação do contexto. Ainda segundo a autora, com um ano e meio de treinamento as equipes estava fazendo bons testes de unidade e testes de requisito. O início do processo, ao levantar os requisitos, passa a ser a documentação dos resultados esperados para os testes, utilizando valores e condições concretas e objetivas que devem ser atingidas, descritas pelo próprio usuário. Os resultados obtidos foram de melhoria na diminuição de 65% de erros encontrados em testes posteriores ao desenvolvimento. Em seu artigo, Williams e colaboradores (2003) descrevem seus experimentos para 7

8 comparação da eficácia do TDD, em projetos industriais, realizados na Microsoft Corporation, onde o autor relata redução de tempo de projeto e incremento da qualidade. Os estudos foram realizados no sistema operacional Windows e no sistema MSN, pois foram considerados projetos grandes e distintos em complexidade e linguagens de programação. Foram escolhidos programadores experientes e produtividade e qualidade similares para comparação entre testes convencionais e TDD. Neste artigo foi considerado para avaliação um critério de densidade de erros por quantidade de linhas de código. No primeiro estudo realizado, foi detectado uma taxa de erros sobre quantidade de linhas de código (densidade de erros) de 2,6 vezes maior, referente ao desenvolvimento sem TDD, gerada por programadores de mesma habilidade e no mesmo projeto. Entretanto, estimativas dos gerentes indicam um acréscimo de 25 a 35% no tempo de produção. Neste estudo o índice de cobertura (quantidade de linhas de teste sobre quantidade de linhas de código) foi de 66% de cobertura. No segundo estudo, com um índice de cobertura de 88%, a densidade de erros em termo foi 4,2 vezes maior no desenvolvimento sem TDD, apesar do aumento de tempo de desenvolvimento pelo uso desta técnica ter representado somente 15% a mais. Entretanto, os autores (op.cit) deixam claro como restrições do trabalho que, apesar de acreditarem nas conclusões, mais experimentos são necessários para comprovação dos resultados obtidos, várias outras equipes já praticavam esta técnica em seus projetos, e que pelos resultados obtidos já havia uma expectativa positiva pelos resultados. Huang e Holcombe (2009) buscaram comprovação estatística em experimento conduzido com estudantes de programação em curso de graduação. Para execução de projetos foram designados grupos para utilização de TDD e testes convencionais, e foram testadas a produtividade, o esforço em programação de testes e a qualidade dos software produzidos pelas equipes. A produtividade foi medida pela quantidade de linhas de código / homem-hora. O esforço em programação dos testes foi obtido pela medição e comparação do tempo gasto em codificação de testes e do programa real. A qualidade foi obtida por um questionário aplicado aos clientes dos programas, contendo variáveis como: boa aparência, inteligibilidade, facilidade de uso, tratamento de erros, manuais, inovação, robustez e satisfação geral. Estes experimentos foram realizados com o agravante de mudanças periódicas nos requisitos estabelecidos inicialmente, com o objetivo de observar a vantagens na adaptabilidade das técnicas. Os resultados foram para o critério produtividade foram testados estatisticamente para verificar sua distribuição e coerência interna. A produtividade ficou comprovada apresentando 12,38 linhas/homem-hora desenvolvidas usando TDD, enquanto somente 7,21 linhas/homehora em não-tdd, demonstrando que esta técnica aumenta em 70% em média a produtividade de equipes. Cabe ressaltar que equipes sem treinamento não atingirão esta performance, entretanto entre os indivíduos testados foram uma mistura onde haviam alunos com habilitações baixas e médias. Os resultados obtidos foram que o tempo médio gasto com testes em TDD foi de 8,56 horas com desvio padrão de 7,41 horas, enquanto que com testes convencionais foi de 4,58 horas com desvio de 3,98 horas. Neste critério os autores relataram que os programadores que não utilizaram TDD, deixaram para fazer testes somente ao terminar os programas, e testaram muito menos. As equipes que 8

9 praticaram TDD, apesar do tempo gasto com execução dos testes ser pequeno, em escala de segundos, o tempo gasto com programação dos testes foi muito superior. Foi notado também, que por não haverem programadores maduros no uso de TDD, algum tempo foi gasto estudando e procurando como desenvolver os testes. Quanto a qualidade obtida, os dados indicaram uma leve superioridade para testes convencionais, obtendo uma pontuação de 39,4 enquanto TDD atingiu 38 pontos. A explicação encontrada pelos autores relaciona os resultados obtidos a experiência prévia em desenvolvimento dos diferentes elementos das equipes e a presença de uma grande maioria de critérios não relacionados com TDD, como manuais, aspecto visual, inteligibilidade, facilidade de uso, inovação, enquanto os objetivos do TDD poderiam ser avaliados somente por tratamento de erros e robustez. Desta forma, não foi encontrada relação entre os critérios qualidade e esforço sobre testes. Também não foi encontrada correlação entre esforço para testes e esforço de codificação, por causa da variação de tempos derivada da diferença entre habilidades dos programadores. Os tempos variaram entre 500 hh até mais de 1000 hh, inviabilizando os tratamentos estatísticos. Entretanto, foram obtidos em outros experimentos anteriores dados que possibilitaram a execução dos testes estatísticos e onde foi comprovada a existência de uma correlação entre o esforço para testes e a diminuição do codificação, conforme proposto por Beck (2002), em que o código torna-se mais simples e mais objetivo. 4. Estudo de caso O NSI (Núcleo de Pesquisa em Sistema de Informação) vem desenvolvendo sistemas ERP e ECM desde 2002, e vem aplicando as técnicas descritas neste artigo em seu ambiente produtivo desde Este estudo de casos focará um módulo específico utilizado junto à uma solução ECM mantida pelo NSI. O OOOD (OpenOffice.org Daemon), módulo monitorado neste estudo de caso, foi inicialmente desenvolvido pela Nexedi, empresa Francesa associada ao NSI, que desenvolveu está ferramenta com o objetivo de extrair e inserir metadados em um documento e converter e exportar documentos para formatos suportados pelo OpenOffice.org. Este projeto foi escolhido por ter utilizado a técnica de TDD desde o início de seu desenvolvimento até o momento atual. Inicialmente os desenvolvedores não possuíam proficiência completa no seu uso, mas durante o processo também ocorreu o aprendizado e foram obtidos os resultados esperados em termos de estabilidade. O outro projeto demonstrado neste trabalho, como grupo controle, não apresentando portanto o uso do TDD, é a Biblioteca Digital (BD). Este projeto foi desenvolvido também pelo NSI, tem o objetivo de manter dados sobre obras literárias, gráficas e vídeos. Foi desenvolvida sem a utilização das técnicas de TDD Metodologia do Estudo de Caso A metodologia utilizada espera demonstrar estabilidade durante o processo de produção e a diminuição progressiva dos erros. Ao longo do processo de produção de software normalmente ocorrem o aumento da complexidade e mudanças nos requisitos do produto, causando instabilidade no ambiente e com isso o aumento na ocorrência de erros. A estabilidade que se deseja demonstrar neste trabalho se refere a diminuição de erros e aumento das melhorias observados ao longo do desenvolvimento, atribuídos ao monitoramento contínuo do funcionamento dos software realizado pelos testes automatizados. 9

10 Estima-se empiricamente que quanto maior o grau de cobertura de testes oferecido pelo TDD, maior seja a segurança do desenvolvedor para operar o incremento, melhorias e concertos necessários, diminuindo portanto a ocorrência de erros e aumentando o número de melhorias que são tradicionalmente evitadas. Nestes projetos foram utilizados um recurso para o monitoramento da evolução do software chamado controle de versões. O Controle de versões é um recurso de monitoramento utilizado no desenvolvimento de software para acompanhar as mudanças submetidas pelos desenvolvedores. Cada incremento, alteração ou concerto é enviado para este sistema e só então é incorporado ao software. Para verificar se o crescimento do software foi realmente estável, buscou-se identificar no controle de versões quais informações poderiam sinalizar a evolução do desenvolvimento do software. Foi recuperada a lista das mudanças submetidas ao controle de versão, para a partir desta lista verificar se nas descrições das atualizações ocorriam palavras que pudessem sugerir a categoria de modificação à que cada alteração no código se referia. Idealmente buscou-se identificar três situações básicas a saber: a criação de novas funcionalidades ou evolução do código; alterações para melhoria do código ; e correção de erros. Espera-se que as modificações para crescimento ou criação de novos módulos sirvam como uma indicação da estabilidade do código. Quanto as operações de alteração para melhoria, espera-se que possam indicar a evolução qualitativa do código, pois teoricamente o software estaria funcional, porém diante de uma oportunidade de melhoria. As operações consideradas como de correção, indicam que a execução atingiu um caminho não coberto pelos testes, indicando portanto uma falha na cobertura do código e portanto instabilidade do produto. Após avaliar as informações recuperadas do sistema de controle de versão e identificar a categoria de cada operação, foi associado um vetor de inclinação para cada registro, onde as operações de crescimento indicam um ambiente estável, recebendo atribuição de valor positiva (1), denotando a evolução do código. Operações de alteração receberam uma valor neutro (0), demonstrando estabilidade do ambiente. Operações para concerto de erros recebem inclinação negativa (-2), demonstrando instabilidade. O valor atribuído aos erros (-2) foi utilizado intensificar o efeito visual (exagerar) dos erros, para facilitar a identificação dos erros no gráfico e favorecer uma avaliação visual da evolução do código. Outros valores foram experimentados (-3, -5, -10), porém não favoreceram a interpretação dos resultados. O objetivo desta atribuição de valores é plotar em um gráfico apresentando a evolução do software para inferir se este desenvolvimento foi estável ou não. Um exemplo dos registros recuperados do sistema de controle de versão pode ser visto na figura 1 e 3. 10

11 Figura 1 Evolução do Projeto O3d Na figura 1, pode-se observar que o desenvolvimento pode ser dividido em três fases. Na primeira fase (A), os desenvolvedores começaram a criar a arquitetura da solução, e os primeiros testes ainda não haviam encontrado erros. Na segunda fase (B), os erros começaram a aparecer, o que representou um aprendizado para a equipe. Esta fase apresentou 18 erros o que representou 45% do total de erros do projeto. Na terceira fase (C), a mais longa, pode-se observar uma certa estabilidade, com poucas declividades (erros). Apresentam-se dois momentos em que ocorreram mais erros no final do projeto (P1 e P2). Estes momentos foram erros críticos, porém a partir da estabilidade do ambiente, foram sanados rapidamente. Dentre os 22 erros detectados durante a terceira etapa do desenvolvimento, pode-se estimar que a dispersão destes erros no tempo foi menos densa do que os erros ocorridos durante a segunda etapa por exemplo. Esta distância entre os erros, também é uma vantagem do uso do TDD, pois existe uma tendência a que ocorram cada vez menos erros diante do aperfeiçoamento do desenvolvedor com o uso da técnica. Na figura 2, pode-se observar que a quantidade de erros foi muito pequena dentro do projeto. Também pode-se observar que as operações de refatoração (melhorias e aprimoramentos) foram muito constantes, o que só poderia ocorrer dentro de um ambiente estável e onde os desenvolvedores sentem-se confiantes. Poderia-se imaginar que em um ambiente não controlado, as melhorias poderia gerar mais erros, difíceis de ser encontrados e concertados. Figura 2 Avaliação das categorias do projeto O3d 11

12 Na figura 3 é apresentado o comportamento do outro projeto estudado, a Biblioteca Digital (BD), onde não se usou a técnica de TDD. A metodologia para plotar os dados foi a mesma já citada do caso anterior. Figura 3 Figura 3 - Evolução do projeto BD Este projeto esteve constantemente sujeito a problemas como propagação de erros, o que tornou o desenvolvimento menos estável, diminuindo as chances de melhorias do projeto. Os percentuais das categorias avaliadas encontram-se na figura 4, onde pode-se observar um número menor de melhorias e maior de erros. Pode-se observar por esta figura dois comportamentos característicos. Na fase A foi o início do desenvolvimento ocorrendo incremento de funcionalidades, porém com muitos erros e concertos. A intensidade de incrementos normalmente acompanhada de erros. Durante a fase B, entretanto, ocorreu evolução, com grande aporte de funcionalidades, também ocorreram muitos erros, no entanto o processo esteve melhor controlado, mas sem atingir a estabilidade do projeto O3d. A fase C, apresentou algum crescimento, porém foi predominante de melhorias e concertos. Pode-se observar que durante as três fases a oscilação de erros é bem distinta do projeto O3d. Figura 4 Categorias avaliadas no projeto BD Ao comparar os gráficos é possível notar que o projeto do O3d, utilizou as práticas de TDD desde o inicio, apresenta uma ocorrência de erros menor e mais distribuída, com maior distância entre erros, o que pode sugerir uma maior estabilidade do processo. A partir da figura 3, pode-se perceber um constante envio de testes após o envio do código produzido. Como foi visto empiricamente, teste depois do código produzido é um grande passo para surgimento de erros e necessidade maior de refatoração. 12

13 5. Considerações Finais O objetivo deste artigo foi mostrar, sob a luz das origens do teste automatizado na indústria, como a mesma filosofia possui impacto positivo quando empregada no desenvolvimento de software. Esta contribuição se faz necessária em vistas da importância do software na sociedade atual e portanto, da necessidade de melhor gerenciar sua produção. Desta forma, espera-se aumentar o interesse sobre a técnica TDD para projetos que ainda não o utilizem. A partir do estudo de caso, foram avaliados os dados referentes ao desenvolvimento para avaliar a estabilidade do código. É possível observar os vários momentos de desenvolvimento, como por exemplo o início do uso da técnica, em um momento de pouca estabilidade, a evolução do uso e por fim um momento de maior estabilidade do desenvolvimento. A aplicação das técnicas de teste automatizados, refletem positivamente sob a qualidade do software, identificando rapidamente anormalidades e trazendo controle autônomo para o processo produtivo, conforme descrito pela Produção Enxuta. Este trabalho é parte de um estudo de caso mais extenso, onde o projeto será descrito sob vários outros aspectos. Como estudos futuros sugere-se o tratamento estatístico dos dados, através de técnicas de simulação e avaliação dos resultados para melhoria da qualidade no processo de desenvolvimento de software. Outra contribuição deste artigo refere-se ao fato de que as técnicas aqui apresentadas são relativamente recentes, não se encontrando ainda muito trabalhos empíricos comprovando seu desempenho, não existindo um benchmark no qual se possa basear e escalar as vantagens e adicionalmente, não há referências corretas às suas raízes, que podem ser encontradas no Pensamento Enxuto. As técnicas apresentadas apoiam o objetivo de melhoria da qualidade, geram desempenho pelo menos igual aos testes manuais, e se computados os tempos de realização de vários testes, os tempos de produção caem exponencialmente. A utilização da técnica de TDD requer um treinamento para obter os resultados de desempenho quanto a experiência com codificação de testes unitário e de requisitos, e também para ter uma visão mais próxima a do usuário, pois não se pode testar com um olhar técnico sobre o que se fez, sob pena de deixar falhas para que o usuário as encontre. Em próximos trabalhos deverão ser abordadas as vantagens da utilização de BDD (Behaviour Driven Development) (CHELIMSKI et al., 2009), com o objetivo de a validação de software nas camadas mais próximas ao usuário. Referências BECK, K. Test Driven Development: By Example. Addison Wesley. p CRISPIN, L. Driving Software Quality: How Test-Driven Development Impacts Software Quality. IEEE Software. IEEE. p CUSUMANO, M. Microsoft Secrets: How the Worlds Most Powerful Software Company Creates Tchnology, Shapes Markets and Manages People. New York: Free Press. p DEEPRASERTKUL, P.; BHATTARAKOSOL, P.; O'BRIEN, F. Automatic detection and correction of programming faults for software applications. The Journal of Systems and Software. 78. p FAGAN, M.E. Design and Code Inspection to Reduce Errors in Program Development. IBM Systems Journal, vol. 15, no. 3, pp GELPERIN, D. & HETZEL, W. Software quality engineering. Proceedings on: Fourth International 13

14 Conference on Software Testing, Washington, DC, GORADIA, T. Dynamic Impact Analysis: A Cost-effective Technique to Enforce Error-propagation. Proceedings in: ACM-ISSTA'93, Cambrige, MA, USA. p HETZEL, B. The Complete Guide to Software Testing. John Wiley & Sons, Inc, HOLWEG, M. The genealogy of lean production. Journal of Operations Management. 25 p HUANG, L. & HOLCOMBE, M. Empirical investigation towards the effectiveness of Test First programming. Information and Software Technology, n. 51, p LARMAN, G. & V. R. BASILI. Iterative and Incremental Development: A Brief History. IEEE Computer Society. 36(6): MIDDLETON, P. Lean Software Strategies: Proven Techniques for Managers and Developers. New York. Productivity Press. p MYERS, G. J. The Art of Software Testing. Wiley, New York, OHNO, T. O Sistema Toyota de Produção: Além da Produção em Larga Escala. Bookman. Porto Alegre. p PRESMAN, R. Engenharia de Software, 3a. Edição, Makron Books, São Paulo SHINGO, S. O Sistema Toyota de Produção: do ponto de vista da Engenharia de Produção. Porto Alegre: Artmed. p SLACK, N.; CHAMBERS, S.; HARLAND, C.; HARRISON, A.; JOHNSTON, R. Administração da Produção. São Paulo: Editora Atlas, p SOMMERVILLE, I. Engenharia de Software, 6ª Edição, Addison Wesley THELIN, T.; RUNESON, P.; WOHLIN, C.; OLSSON, T.; ANDERSON, C. Evaluation of Usage-Based Reading-Conclusions after Three Experiments. Empirical Software Engineering, v. 9, n. 1-2, p WILLIAMS, L.; MAXIMILIEN, E. M.; VOUK, M. Test-Driven Development as a Defect-Reduction Practice. Proceedings of IEEE International Symposium on Software Reliability Engineering, Denver, CO, pp WOMACK, J. P.; JONES, D. T.; ROSS, D. A máquina que mudou o mundo. Rio de Janeiro: Campus. p WOMACK, J. e JONES, D. (1998) A Mentalidade Enxuta nas empresas: Elimine o desperdício e crie riqueza. Rio de Janeiro: Campus, CHELIMSKI,D.; ASTELS,D.; HELMKAMP,B.; DENNIS,Z.; NORTH,D.; HELLESOY,A. The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends. Pragmatic Bookshelf. p