ANÁLISE DE PROCESSOS EM UMA EMPRESA DE DESENVOLVIMENTO DE SOFTWARES USANDO SIMULAÇÃO

Transcrição

1 ANÁLISE DE PROCESSOS EM UMA EMPRESA DE DESENVOLVIMENTO DE SOFTWARES USANDO SIMULAÇÃO Rafael Alves de Souza Universidade Federal de Minas Gerais Av. Antônio Carlos, Belo Horizonte - Minas Gerais - Brasil rafaelproducao@yahoo.com.br Luiz Ricardo Pinto Universidade Federal de Minas Gerais Av. Antônio Carlos, Belo Horizonte - Minas Gerais - Brasil luiz@dep.ufmg.br RESUMO Neste trabalho é apresentado e discutido o uso da simulação na análise dos processos de uma empresa de desenvolvimento de softwares, na qual diferentes práticas de organização do trabalho são testadas, combinadas e então comparadas em busca da redução nos prazos de entrega dos softwares desenvolvidos. PALAVRAS CHAVE. Simulação. Apoio à decisão. de software. SIM Simulação ABSTRACT This article presents and discusses the use of simulation to analyze the work process from a software company. Distinct types of organization techniques were tested. They were combined and then were compared in order to reach a reduction of the software delivery period. KEYWORDS. Simulation. Support decision. Software development. SIM - Simulation [ 2092 ]

2 1. Introdução O uso da simulação como ferramenta de apoio à tomada de decisão em processos de desenvolvimento de software teve suas primeiras aplicações práticas a partir da década de 90 [Ahmed e outros (2004)] e tem encontrado cada vez mais espaço nesta área nos últimos anos [Andersson e Runeson (2004)]. Esta tendência ocorre porque a simulação permite às empresas projetar e estudar sistemas complexos sem interromper o funcionamento normal de suas atividades [McLean e Leong (2001)]. Segundo Shannon (1998), a simulação consiste em construir um modelo representativo de um sistema real para experimentação e avaliação de estratégias alternativas de operação. Com isso, processos e sistemas de produção podem ser melhor compreendidos e as variáveis que realmente influenciam o desempenho identificadas [Law e Kelton (1991)]. Em uma pesquisa realizada por Ahmed e outros (2004), observou-se que grande parte dos analistas envolvidos com modelagem de processos de desenvolvimento de softwares consideram a modelagem e a avaliação como os tópicos mais relevantes do processo. Andersson e Runeson (2004) investigaram o impacto do uso de modelos de simulação na análise de custo, programação da produção e qualidade dos softwares. Segundo eles, os projetos apoiados pela simulação possibilitaram um melhor entendimento e visualização do processo como um todo, bem como um melhor desempenho dos gerentes de projetos em suas decisões. De acordo com Padberg (2004), o planejamento de projetos de softwares é coberto de incertezas, devido a diversas razões, entre elas a dificuldade de se estimar o tempo a ser gasto para completar cada atividade e os problemas de re-trabalho e atrasos operacionais causados pela constante retro-alimentação de informações entre as etapas. Padberg (2004) também realizou um estudo sistemático onde comparou os resultados de programação da produção gerados por modelos determinísticos com modelos de simulação. Seus resultados mostraram que a simulação além de apresentar um resultado satisfatório, possuía a vantagem de oferecer uma visualização da construção de suas soluções. Atualmente, com o crescente nível de serviço exigido pelo mercado, as empresas de software se deparam com a necessidade de sofisticar cada vez mais seus processos, o que muitas vezes é feito com o uso de metodologias de desenvolvimento complexas e dispendiosas. Com isso, muitos gestores têm buscado metodologias alternativas para otimizar recursos e maximizar o valor de seus projetos. Uma alternativa experimental, de caráter acadêmico, foi vivenciada pelos gestores de uma empresa de desenvolvimento de softwares de Gestão Acadêmica de médio porte localizada na região metropolitana de Belo Horizonte, Minas Gerais. Nesta experiência foram utilizadas técnicas de modelagem por simulação para avaliar o impacto de processos alternativos de desenvolvimento de software no escopo, qualidade, prazo e custos de seus projetos. O objetivo da realização deste trabalho é apresentar os passos de implementação desta ferramenta de modelagem quantitativa na empresa e seus benefícios no apoio às decisões de melhoria de processos de desenvolvimento de softwares. 2. Metodologia de Pesquisa e Ferramentas Adotadas O estudo foi conduzido segundo o referencial metodológico de pesquisa-ação [Coughlan e Coghlan (2002)], que consiste no aprendizado científico através de ações aplicadas com o fim de solucionar o problema proposto. Este método é recomendado para casos em que a investigação está vinculada a implementações sucessivas, cujos resultados se tornam a base para um novo ciclo de melhoria ou solução. A primeira fase do trabalho consistiu em definir o objetivo do estudo, que inclui a abrangência dos modelos e o nível de detalhamento dos mesmos. Em seguida, foram identificadas as variáveis relevantes do processo de desenvolvimento atual e coletados os dados históricos de produção para tratamento estatístico. Finalmente, os modelos foram propostos e implementados em software ARENA versão 8.01, para então serem validados com as equipes e utilizados nas decisões de melhoria dos processos. [ 2093 ]

3 3. Metodologias de de Softwares As metodologias tradicionais, baseadas na execução de atividades seqüenciais por equipes específicas, são muito utilizadas por empresas de desenvolvimento de softwares de médio e grande porte. Este método, também conhecido como desenvolvimento orientado ao planejamento, é indicado principalmente para projetos complexos de longa duração e grandes estruturas hierarquizadas de profissionais dedicados. Entretanto, apesar de seguir as tendências internacionais de garantia da qualidade em software, possui a desvantagem de requisitar um grande volume de documentação interna entre equipes e recursos de apoio ao processo, o que eleva os custos de produção [Brooks (1987)]. Há também no mercado as metodologias ágeis, cujas atividades são estruturadas em projetos de curta duração e executadas por equipes multifuncionais reduzidas. Neste modelo de organização, o objetivo é investir menos tempo em documentação detalhada de uso interno e mais em implementação através da interação entre as equipes e clientes. A metodologia produz bons resultados mesmo quando os requisitos do software são dinâmicos ao longo do tempo, mas possui a desvantagem de não se adequar bem a projetos de grande porte e equipes maiores [Charette (2001)]. 4. Descrição dos Modelos Desenvolvidos Foram desenvolvidos três modelos de cenários produtivos com o objetivo de identificar gargalos que pudessem ser atenuados e pontos de eficiência a serem maximizados. A abrangência e o nível de detalhes dos modelos contemplavam a representação do trabalho das equipes de documentação de casos de teste, banco de dados, desenvolvimento e qualidade. Isso permitiu observar o comportamento de cada tipo de organização do trabalho em relação à complexidade necessária de planejamento, alocação de atividades, tempos de execução, formação de filas, eficiência produtiva e custos. Quanto aos impactos referentes à qualidade dos sistemas, requisitos de infra-estrutura, adaptação técnica, comunicação interna e relacionamento com o cliente, um comitê representativo das equipes foi criado para discutir e avaliar os efeitos das mudanças no curto, médio e longo prazo. 4.1 Primeiro Modelo: Metodologia Tradicional de O primeiro modelo de simulação construído foi uma representação do atual processo de desenvolvimento da empresa, baseado na metodologia tradicional. Ele contempla apenas as atividades de projetos de versões de aplicativos, já que os serviços de manutenção dos sistemas eram prestados após o lançamento de novas versões, quando algum recurso se tornava disponível. O processo se inicia com o planejamento da versão do software e a distribuição de tarefas pelo gerente de projetos. Esta etapa requer uma documentação técnico-comercial que especifica o que os clientes desejam, juntamente com as horas de produção necessárias e uma documentação de desenvolvimento detalhado, onde são descritas todas as instruções e requisitos a serem implementados por cada equipe ao longo do processo, além de definir os profissionais responsáveis por cada atividade. Uma vez que o escopo do projeto foi aprovado pelos clientes, as equipes de desenvolvimento, de banco de dados e de documentação de casos de testes iniciam suas atividades simultaneamente. Em seguida, cada programador responsável integra ao sistema os bancos de dados e, de posse da documentação de casos de teste, realiza a primeira bateria de testes das funcionalidades. Logo após, outra bateria de testes manuais é realizada pela equipe de homologadores que finalmente encerram o processo com os testes automáticos, que são processados por um software específico. Durante o ciclo produtivo, se algum erro ou problema for identificado, a funcionalidade é retornada ao responsável anterior para correção, se não, o pacote da versão é gerado pelo gerente de projetos e entregue aos clientes. Na figura 1 está representado a lógica de funcionamento desse modelo organizacional. [ 2094 ]

4 Planejamento da Versão Distribuição de Tarefas Teste de Funcionalidade Homologador Desenvolvedor BD Documentador Documentação de Casos de Teste Homologador Testes Automáticos Criação do Pacote de Versão Figura 1 Metodologia tradicional de desenvolvimento baseado em atividades seqüenciais. Após a definição da lógica do modelo, coletaram-se os dados históricos de produção das três últimas versões para criar as estatísticas básicas para os modelos. Cada projeto de versão utilizado possui uma duração média de três meses. Neste modelo tradicional de desenvolvimento, cada equipe realiza um tipo de atividade e possui uma produtividade média específica, que é representada por uma distribuição de probabilidade. Esta informação é obtida a partir do comportamento dos desvios existentes entre o tempo planejado e o tempo realmente gasto em cada tarefa, ou seja, o erro de estimativa de tempo para execução das tarefas, calculado pelo quociente do tempo real pelo previsto. Desta forma, o tempo amostrado para realização de cada tarefa no modelo é obtido multiplicando-se o tempo previsto de execução da tarefa na versão vigente por um índice aleatório de erro baseado em dados históricos. No modelo de simulação desenvolvido, cada solicitação de funcionalidade é considerada como uma entidade e possui como atributos dados de tempos previstos para cada atividade. Essas informações são lidas pelo modelo a partir de um planejamento de versão armazenado em planilhas M.S. Excel e são utilizadas pelos recursos, representados por cada profissional, para o cálculo de tempo de realização de suas tarefas. Também foi relevante considerar no modelo que os profissionais possuam restrições de expediente de oito horas diárias de trabalho, paradas nos finais de semana e feriados e uma carga horária específica de trabalho nas versões, de acordo com o total de solicitações alocadas para cada um. Com isso, o primeiro modelo de simulação foi concluído com a implementação da lógica do processo seqüencial de desenvolvimento de softwares e com a criação de atributos e [ 2095 ]

5 variáveis que permitirão obter informações úteis do modelo. Todas as informações e dados gerados durante a execução do modelo também são registrados em planilhas M.S. Excel para posterior análise. 4.2 Segundo Modelo: Metodologia Ágil com Projetos por Módulos de Aplicativo O segundo modelo de simulação desenvolvido é baseado na metodologia ágil de desenvolvimento de softwares, cujas premissas básicas são: equipes reduzidas, multifuncionais e projetos pequenos de curta duração. Através deste modelo pretende-se avaliar os impactos da mudança de um processo seqüencial de desenvolvimento de softwares para um processo com projetos paralelos (Figura 2). Para tal, foi simulado o desenvolvimento de uma versão trimestral assim como no primeiro modelo. Planejamento da Versão Cliente via Portal WEB Registro de Erros de Sistema Distribuição de Tarefas Manutenção do Sistema Equipe 1 Equipe N Atualização das Funcionalidades Documentação de Casos de Teste Documentação de Casos de Teste Testes Automáticos Testes Automáticos Criação do Pacote de Versão Figura 2 Metodologia ágil de desenvolvimento por módulos de aplicativo. [ 2096 ]

6 Os projetos de versão são constituídos por várias funcionalidades solicitadas pelos clientes via portal WEB e podem ser subdivididos em projetos menores por módulos comuns, como tesouraria, biblioteca, rematrícula, etc. ou por clientes. Para fins de comparação, optou-se nesse segundo modelo agrupar as solicitações por módulos comuns, dividindo-as de forma eqüitativa entre os responsáveis pelo desenvolvimento. Neste modelo organizacional, cada profissional é multifuncional, isto é, fica responsável por executar todas as tarefas relacionadas a uma determinada solicitação alocada a ele. Assim, foram alocados aos projetos desse cenário apenas os programadores, que eram os únicos profissionais preparados para assumir todas as responsabilidades com pouca necessidade real de treinamento. Como na simulação anterior, apenas sete profissionais eram programadores dentre os quinze participantes, para efeito de comparação, foi utilizado o mesmo número nesse segundo modelo. Também os índices aleatórios de erros de execução de cada tipo de atividade, representados pelas distribuições de probabilidade, foram mantidos neste cenário para estudo e avaliação de resultados. Diferentemente do primeiro modelo, a manutenção do sistema deixa de ser realizada através de recursos ociosos após o lançamento das versões para ser assumida por um programador específico. Esse programador estará alocado a esta atividade durante todo o tempo da versão, permitindo que os demais possam se dedicar exclusivamente às tarefas de desenvolvimento. O efeito dessa alteração no modelo possibilitará conhecer o dimensionamento necessário de uma equipe de manutenção e avaliar a redução do tempo de resposta aos clientes quanto à correção de erros. Outra diferença em relação ao primeiro modelo, é que se algum erro ou problema for identificado em alguma das etapas do processo, a correção é feita pela mesma pessoa, evitando-se assim a formação de filas de tarefas entre as etapas. Por fim, a versão é concluída com a montagem de um pacote único pelo gerente de projetos, onde todos os módulos desenvolvidos pelas equipes são integrados e disponibilizados aos clientes via Portal WEB. Nesta configuração organizacional, uma nova versão só inicia quando todas as equipes estão disponíveis, já que um mesmo cliente deseja receber suas funcionalidades de diversos módulos, espalhados entre as equipes, de uma vez só. Esse cenário é proposital para estudo e percepção de comportamentos. 4.3 Terceiro Modelo: Metodologia Ágil com Projetos por Clientes O terceiro e último modelo implementado computacionalmente foi desenvolvido após diversas discussões com o comitê de mudanças a respeito dos resultados obtidos nos dois primeiros modelos. Conseqüentemente, o processo de desenvolvimento por módulos de aplicativo foi substituído pelo desenvolvimento por projetos de clientes ou grupos deles, no caso de pouco volume de atividades. Esta escolha foi baseada em algumas premissas da metodologia ágil, a qual valoriza o relacionamento estreito entre equipes e clientes. Deste modo, as equipes passam a ter a oportunidade de interagir diretamente com o cliente, definindo as características das funcionalidades, os pacotes de solicitações, prazos de entrega e custos. Nesse modelo (Figura 3), os antigos gerentes de projetos passam a ser gerentes de produtos, os quais assumem o papel de captadores de oportunidades de projetos junto aos clientes e orientadores de equipes. Com isso, as equipes de programadores assumem a responsabilidade de documentar o que os clientes desejam registrando no Portal a documentação técnicocomercial, juntamente com as horas de produção necessárias. E no momento da entrega do sistema, são eles quem disponibilizam os aplicativos e a lista de checagem, que contém todos os pontos de função testados e aprovados. Outra melhoria implementada neste cenário de simulação foi a eliminação das equipes de banco de dados e qualidade, bem como a documentação de desenvolvimento detalhado, pois agora pelo fato de todo o processo de desenvolvimento ser assumido por um mesmo profissional, não há necessidade de existir uma documentação para que uma equipe específica entenda outra. A documentação de casos de teste também deixa de ser necessária, já que o programador conhece o que o cliente deseja das funcionalidades e será ele próprio quem planejará e realizará os testes manuais. Os testes automáticos igualmente são excluídos devido à adoção da nova técnica de [ 2097 ]

7 testes. Todavia, caso ocorra erros entre as etapas do processo, o programador é o único responsável pela avaliação e correção do problema. Cliente via Portal WEB Demanda de funcionalidades ou manutenção do sistema Gerente de Produtos Estudo de Projetos e Apoio às Equipes Projeto Cliente 1 Projeto Cliente N Projeto de Manutenção Manutenção do Sistema Atualização das Funcionalidades Entrega Sistema ao Cliente Entrega Sistema ao Cliente Figura 3 Metodologia ágil de desenvolvimento por projetos de clientes. Quanto ao serviço de manutenção, este passa ser visto como um projeto de manutenção, cujos recursos e custos poderão ser melhor definidos e administrados. Como haverá um rodízio de profissionais nestes projetos, todas as falhas e erros reportados pelos clientes, bem como os procedimentos de correção, serão registrados em um banco de conhecimento, o que permitirá aos gerentes de produtos promoverem treinamentos de qualificação dos programadores através de estudos preventivos. Finalmente, após a conclusão dos projetos, o sistema é disponibilizado ao cliente solicitante e um novo projeto organizado pelo gerente de produtos é assumido pela equipe disponível, formando assim um ciclo contínuo de desenvolvimento de curta duração. Este efeito durante a simulação também é registrado em planilhas M.S. Excel para análise de resultados. 5. Validação dos Modelos e Análise de Resultados Para validação da lógica e informações geradas pelos três modelos, foram modeladas e simuladas três versões passadas de aplicativos da empresa, cujos resultados já eram conhecidos. Todas as informações utilizadas para o estudo foram obtidas a partir da média de 100 replicações no ambiente de simulação ARENA versão O erro médio associado à representatividade dos modelos propostos com a realidade foi de 4%, o que segundo o comitê de mudanças era aceitável para as decisões. [ 2098 ]

8 Com o primeiro modelo construído, baseado na metodologia tradicional de desenvolvimento, foi possível observar uma intensa formação de filas de funcionalidades préacabadas na atividade de desenvolvimento, devido principalmente aos diferentes tempos de trabalho das equipes paralelas de banco de dados e documentação de casos de teste. Observou-se ainda, que o problema era agravado no decorrer da versão, já que um volume considerável de erros era encontrado pela equipe de qualidade. Conforme a avaliação do comitê, estes erros ocorriam em sua maioria devido à redução da acurácia dos programadores por terem ciência de que seu trabalho seria posteriormente testado por uma equipe específica. Com a demora dos programadores na liberação das funcionalidades, outro problema foi retratado na simulação, a ociosidade temporária de alguns recursos da qualidade no início e durante as versões. Já no fim da versão, pelo fato de alguns profissionais serem realocados para a manutenção do sistema, um novo problema de formação de filas era apontado, o que sobrecarregava aqueles profissionais com maior volume de atividades alocadas. Também foi percebido que um tempo significativo dos homologadores era destinado ao preparo dos testes automáticos, em contrapartida, um pequeno volume de erros eram encontrados por esse procedimento, o que demonstrou uma baixa eficiência desta ferramenta em relação aos testes manuais. Todos estes problemas contemplados acarretavam um potencial estouro dos prazos de entrega das versões. Porém, isso era evitado com muitas horas extras ou com o repasse dessa ineficiência para os sobreestimados tempos previstos de desenvolvimento combinados com os clientes. Enquanto o primeiro modelo simulado contava com a participação de quinze profissionais e um tempo médio de término de versão de três meses, o segundo modelo, devido à sua nova configuração de desenvolvimento de módulos por projetos paralelos, obteve uma redução de tempo de versão para um pouco mais que dois meses, com apenas sete profissionais. O principal motivo desse aumento significativo de eficiência foi a expressiva redução de filas durante o processo e a diminuição da ociosidade dos profissionais. Foi observado também, que no segundo modelo o nível de serviço oferecido aos clientes na manutenção do sistema aumentou em 20% com a alocação de um profissional exclusivo a esta atividade, isto em relação ao antigo procedimento de correção de erros externos no final das versões. Mesmo com o aumento de eficiência, algumas desvantagens ainda permaneciam neste segundo cenário simulado, como: a existência de alguns recursos ociosos próximo do fim das versões, a falta de autonomia dos programadores devido à dependência da documentação de desenvolvimento detalhado escrita pelos gerentes de projetos, os vários tipos de testes de qualidade e a necessidade da documentação de casos de teste para os testes automáticos. Já com a mudança do conceito de projetos paralelos por módulos para projetos por clientes, abordado pelo terceiro modelo, foi possível observar uma redução de 15% no prazo de entrega dos projetos aos clientes, em relação ao segundo modelo, contando também com uma equipe de apenas sete programadores. Essa melhoria foi observada principalmente devido ao término da ociosidade dos recursos no fim dos projetos e à eliminação das atividades de documentação de casos de teste e testes automáticos. Outro benefício dessa nova configuração é o reconhecimento da manutenção do sistema como um projeto. Assim, de acordo com a demanda e disponibilidade de recursos, pequenos projetos de versões podem ser construídos, aumentando-se a eficiência e o nível de serviço aos clientes. Isto possibilita uma melhor administração dos recursos e do relacionamento com o cliente, bem como um aumento da qualidade dos sistemas ao longo do tempo com o rastreamento de causas de falhas externas. Como haverá uma maior flexibilidade para os programadores negociarem melhorias, bem como para discutir dúvidas com os clientes, acredita-se que a qualidade dos sistemas aumentará ao longo do tempo. Isto devido ao estreitamento dos relacionamentos e fim das interpretações equivocadas propagadas pela divisão do trabalho e pela documentação de [ 2099 ]

9 desenvolvimento detalhado, além de incitar uma maior atenção aos testes manuais por causa da responsabilidade pelo produto final [Lima e Moura (2003)]. Quanto à metodologia de testes adotada, os sistemas serão testados em todas as fases do seu desenvolvimento e, no final, um teste focado na visão de usuário será aplicado, em que o desenvolvedor tentará simular o máximo de possibilidades de uso do sistema pelo usuário final. Com o intuito de reduzir a ocorrência de vícios de testes, os gerentes de produtos deverão treinar e realizar estudos preventivos periodicamente com os programadores. Conforme a avaliação do comitê de mudanças, a metodologia ágil de desenvolvimento de softwares por projetos de clientes, simulada no terceiro modelo, implica também em diversas melhorias qualitativas do processo, tais como: uma melhor comunicação e gestão de equipes, melhorias de infra-estrutura, maior qualificação das equipes e melhor relacionamento com os clientes. Quanto à antiga equipe de qualidade, esta assumirá responsabilidades de suporte aos clientes e a equipe de banco de dados passará a compor o quadro de programadores da empresa. 6. Conclusão O uso da simulação na análise de alternativas de desenvolvimento de softwares se mostrou adequada, a ponto da empresa decidir pela implantação experimental da metodologia proposta no terceiro cenário. A redução de custos dos projetos ocorreu principalmente devido à redução das horas de desenvolvimento dos mesmos, já que as solicitações são cobradas dos clientes por hora de atividade. Outros motivos de redução de custos foram: o aumento da eficiência das equipes de desenvolvimento e o cancelamento das licenças do software de testes automáticos. O sucesso desta alternativa de trabalho pode também ser atribuído a outros aspectos não mensurados pela simulação, inerentes à nova metodologia de organização adotada. Contudo, foi através da simulação que se pôde ter uma estimativa cientificamente embasada de como o sistema se comportaria neste cenário. Em algumas simulações de projetos no terceiro modelo, houve casos em que os projetos foram finalizados com antecedência em relação ao número de horas combinadas com os clientes, o que pode implicar em lucros extras. A partir dessa observação, podem ser sugeridos trabalhos futuros que utilizem a simulação para previsão de taxas de riscos nos projetos da empresa. Referências Ahmed, R., Hall, T., Wernick, P. e Robinson, S., Simulation Modeling Practices of ProSim03 Participants: A Survey, In: Proceeding of the 2004 Workshop on Software Process Simulation and Modeling, Andersson, C. e Runeson, P., Evaluating the Impact of Software Process Simulation - A Case Study, In: Proceeding of the 2004 Workshop on Software Process Simulation and Modeling, Brooks, F., No Silver Bullet: Essence and Accidents of Software Engineering, In: Proceeding of the 1987 IEEE Computer Software Press, p , Charette, R., Fair Fight? Agile Versus Heavy Methodologies, Cutter Consortium E-project Management Advisory Service, Coughlan, P. e Coghlan, D., Action Research for Operations Management, International Journal of Operations & Production Management, Nº. 2, v. 22, p , Law, A. M. e Kelton, W. D., Simulation Modeling & Analysis, Second Edition, McGraw-Hill, New York, Lima, F. P. A. e Moura, J. E., Organização do Trabalho, Notas de Aula, Universidade Federal de Minas Gerais, McLean, C. e Leong, S., The Expanding Role of Simulation in Future Manufacturing, In: Proceedings of the 2001 Winter Simulation Conference, p , Padberg, F., A Comprehensive Simulation Study on Optimal Scheduling for Software Projects, In: Proceeding of the 2004 Workshop on Software Process Simulation and Modeling, Shannon, R. E., Introduction to the Art and Science of Simulation. In: Proceeding of the 1998 Winter Simulation Conference, p. 7-14, [ 2100 ]