Planejador: Uma Ferramenta de Coleta de Tempos do Processo de Desenvolvimento de Software

Transcrição

1 Planejador: Uma Ferramenta de Coleta de Tempos do Processo de Desenvolvimento de Software Rodolfo M. de BARROS Eduardo C. TEIXEIRA Elieser B. MANHAS JR. Fábio C. MARTINS Departamento de Computação, Universidade Estadual de Londrina Londrina, PR, CEP , Brasil e Ruy T. NISHIMURA Sergio A. TANAKA Departamento de Computação, Centro Universitário Filadélfia Londrina, PR, CEP , Brasil RESUMO O planejamento do processo de desenvolvimento do software é uma atividade fundamental na busca pela qualidade do processo e do produto final. Neste sentido, este trabalho apresenta a ferramenta intitulada PLANEJADOR. A ferramenta coleta os tempos estimados e realizados referentes ao processo de desenvolvimento do software. Busca-se com a ferramenta a montagem de um banco de dados histórico para subsidiar futuros planejamentos independentes da técnica de metrificação empregada. Palavras-chave: Planejamento, Processo, Qualidade, CMM, Estimativas. 1. INTRODUÇÃO O software é um agente integrante e ativo da sociedade em que vivemos. Desde aplicações simples e caseiras, até em situações complexas e que podem trazer riscos à mesma (financeiros, perda de vidas humanas, perda de dados, etc.), o software está presente e ajudando no dia a dia das empresas, das pessoas, enfim, da sociedade como um todo. Mediante esta afirmação, existe uma grande preocupação que este software tenham qualidade, qualidade está que evidencia o bom funcionamento do produto, no que tange à sua funcionalidade, operacionalidade, eficiência, além da sua segurança, uma vez que o mesmo não deve trazer nenhum risco à sociedade. Apesar desta preocupação, a baixa qualidade no processo de desenvolvimento de software é uma realidade presente em grande parte de empresas de software no Brasil. O Ministério da Ciência e Tecnologia em sua última pesquisa, realizada em 2001 (publicada no ano de 2002) através da Secretaria de Política de Informática e Automação SEPIN, apontou que apenas 18,6% das empresas de software utilizam métricas para medir a qualidade dos processos de software. Diversos problemas são causados pela falta de definição de um processo de desenvolvimento: aumento no custo de desenvolvimento, atraso na entrega do produto, baixa qualidade do produto, comprometimento na organização de projetos de desenvolvimento, inexistência de um processo repetível, falta de controle (mensuração) de processos, visibilidade de processos (caixa-preta) entre outros [4]. Apesar da mesma pesquisa apontar que um grande número de empresas de desenvolvimento não definem seus processos de software, a mesma não indica os fatores que as impedem. Diversas hipóteses podem ser consideradas como motivadoras deste cenário: falta de recursos (humano, financeiro);

2 desconhecimento dos modelos de processos existentes ou inadequação destes modelos frente a realidade destas empresas; a definição de processos não é uma prática considerada importante pelas empresas no desenvolvimento de software; o tempo necessário para formalização dos processos inviabiliza sua implantação; falta de um programa de qualificação profissional nas empresas. Portanto, é necessário investigar as reais causas que impedem a definição de processos de software e, com base nestas causas apontar diretrizes que auxiliem as empresas na formalização de seus processos contribuindo, conseqüentemente, com a qualidade de seus produtos. A qualidade final de um software está diretamente relacionada com a qualidade do seu processo de desenvolvimento. O primeiro passo para se conquistar um nível adequado de qualidade neste processo está no estabelecimento de um desenvolvimento definido onde se consiga alocar os melhores recursos para aquelas tarefas mais relevantes do software. Tarefas identificadas como fundamentais devem ser melhor gerenciadas e previstas dentro do fluxo de trabalho, não somente em relação a sua qualidade, como também em relação ao seu tempo de desenvolvimento. Desta forma, busca-se alcançar um gerenciamento sobre o tempo de desenvolvimento, aptidões dos implementadores, custos e produtividade. Neste contexto, as organizações vêm adotando modelos de Qualidade de Software, visando melhorar a gerência de seu processo. Como exemplo, pode ser citado o modelo Capability Maturity Model (CMM). De acordo com este modelo, uma organização madura possui habilidade para gerenciar e manter seus processos, planejar suas atividades e monitorar a qualidade de seus produtos e a satisfação de seus clientes. Além disso, a organização busca um melhoramento constante de seus processos. A maturidade do processo de software representa o grau em que um processo de software específico é explicitamente definido, gerenciado, mensurado, controlado e eficaz. O Modelo (Figura 1) é organizado em cinco níveis de maturidade, a saber: Inicial, Repetível, Definido, Gerenciado e Otimização. O objetivo principal nas transações destes níveis de maturidade é a realização de um processo controlado e mensurado buscando a melhoria contínua. Cada nível de maturidade possui um conjunto de práticas de software e gestão específicas, denominado áreas-chave do processo. Estas devem ser implantadas para a organização atingir o nível de maturidade em questão. Figura 1: Níveis do Modelo CMM [3] O nível 2 (Repetível) do modelo preconiza o estabelecimento e implantação de processos básicos de gerenciamento de projeto para planejar e acompanhar custo, cronograma, esforço e funcionalidade. Os processos são realizados de forma a repetir o sucesso de projetos anteriores em novos projetos similares. Dentre estes processos, encontra-se o chamado Planejamento do Projeto de Software, que tem como objetivo estabelecer planos exeqüíveis para o projeto de desenvolvimento de soluções, com estimativas, compromissos, alocação de recursos, bem como gerenciar o projeto de desenvolvimento segundo estes planos. O planejamento de projetos está diretamente relacionado com o desenvolvimento de um plano, que especifique o que deve ser feito, quanto tempo demorará para ser executado, quem deve realizar cada tarefa e qual é o custo previsto. O processo de planejamento de software inclui passos para estimar o tamanho dos produtos de software e os recursos necessários, para produzir um cronograma, para identificar e avaliar riscos e para negociar compromissos. Nesta área-chave, estimativas precisas de tamanho, custo, prazo e esforço são fundamentais para o

3 estabelecimento de planos realistas. A estimativa é um exercício importante. Fatores como o esforço humano exigido (pessoas/mês), duração cronológica do projeto, custo, e outros devem ser levantados neste momento. O problema é como definir estes fatores. As estimativas, principalmente as de tempo, são as atividades que subsidiam o planejamento do desenvolvimento de um software, pois elas são obtidas através da análise de dados coletados durante projetos anteriormente realizados. Em grande parte dos casos, as estimativas são feitas com base na experiência passada. No caso de se ter um projeto relativamente similar a um projeto já realizado, não fica difícil estimar questões como esforço, cronograma e custo, uma vez que estes serão muito próximos daqueles relativos ao projeto anterior. Por outro lado, a estimativa através desta abordagem pode tornar-se complexa se o novo projeto apresenta características inovadoras com relação ao(s) projeto(s) anterior(es). O principal objetivo da implantação de um processo de medição de software é fornecer aos gestores um conjunto de dados úteis e tangíveis para dimensionar, estimar, planejar e controlar os projetos com rigor e precisão. As principais razões para se medir software são as seguintes [1]: formar uma base para estimativas; determinar se as metas de produtividade do processo estão sendo atingidas; determinar se as metas de qualidade do processo estão sendo atingidas; determinar se as metas de qualidade do produto estão sendo atingidas; avaliar os benefícios de novos métodos, treinamentos e ferramentas de software; melhorar o relacionamento com o cliente; melhorar a gerência de contratos de software e relacionamentos com terceiros; melhorar a gerência de projetos de desenvolvimento de software; entender e aperfeiçoar o processo de software; Como mencionado anteriormente sobre a importância dos dados históricos, eles são fundamentais para se ter estimativas com maior segurança, estabelecendo prazos ideais para a entrega do projeto, dessa forma os riscos são reduzidos, tornando mais fácil a missão de medir o custo, tempo e pessoal necessário para o desenvolvimento de um projeto. Entre os métodos de estimativas usados para mensurar um projeto estão: Técnica de Delphi, Técnica de Wideband-Delphi, COCOMO 1, Análise de Pontos de Função e Análise de Casos de Uso. Os dois primeiros métodos estão baseados em opiniões de especialistas da área específica do software em desenvolvimento. O COCOMO estima o esforço, prazo, custo e tamanho da equipe de um projeto de software através de linhas de código. O método de Análise de Pontos de Função baseia-se em requisitos funcionais, experiência prática e no método dedutivo para dimensionamento de uma aplicação, sendo necessário ter em mãos tanto o layout da tela da aplicação, quanto os arquivos e as manutenções necessárias para cada funcionalidade. Já o método de estimativas por Casos de Uso mensura um projeto em nível de Casos de Uso, sem precisar definir layout, sendo também baseado nos requisitos funcionais. Neste sentido, este trabalho relata os resultados do projeto de pesquisa intitulado Definição, Planejamento e Gerenciamento do Processo de Desenvolvimento de Software realizado pelo Grupo de Pesquisa em Engenharia de Software e Banco de Dados do Departamento de Computação da Universidade Estadual de Londrina e de professores do Centro Universitário Filadélfia. Mais especificamente, este trabalho apresenta a ferramenta PLANEJADOR, cuja funcionalidade principal é coletar os tempos planejados (estimados) e os de tempos de execução das atividades relacionadas ao processo de desenvolvimento de software, com o intuito de se ter um banco de dados histórico sobre os desenvolvimentos visando utilizalo em futuras estimativas de tempo e, conseqüentemente, de custo de desenvolvimento. A primeira sessão deste trabalho apresenta o modelo CMM e o Planejamento do Projeto Software, 1 COCOMO - Constructive Cost Model

4 pertencente ao nível 2 do referido modelo, bem como a importância de estimativas de software. Já a segunda, faz apresenta o modelo de processo utilizado pela ferramenta PLANEJADOR como referência para coleta dos tempos. A sessão 3 apresenta a ferramenta PLANEJADOR, especificando suas funcionalidades. Finalmente são apresentadas as conclusões e trabalhos futuros. 2. MODELO DE PROCESSO Para formalizar e conduzir o desenvolvimento de um software é utilizado um modelo de processo. Este trabalho utilizou um modelo apresentado em [2]. Este modelo de processo é composto por outros elementos, que por sua vez também são constituídos por outros elementos, formando assim uma estrutura organizacional que pode ser observada na Figura 2. processo, e trabalharmos na busca de ajustar estes tempos. 3. FERRAMENTA DE COLETA DE TEMPOS DE PLANEJAMENTO E DE EXECUÇÃO Visando armazenar tempos sobre o processo de desenvolvimento e, conseqüentemente, criar um banco de dados histórico sobre estes tempos desenvolveu-se a ferramenta de coleta de tempos de planejamento e de execução intitulada PLANEJADOR (Figura 3). A ferramenta para coleta de dados sobre o desenvolvimento tem como principal funcionalidade a capacidade de coletar os dados de tempo de execução das tarefas durante o processo de software, bem como cadastrar os tempos estimados no planejamento, criando-se assim um banco de dados histórico sobre o processo. Esses dados são extremamente importantes no cálculo de estimativas de projetos, pois somente com o subsídio de dados anteriores se consegue uma estimativa com maior precisão. Figura 2: Modelo de Processo [1] Analisando-se a Figura 2, tem-se um processo composto por subprocessos. Já os subprocessos são compostos de atividades, estas por procedimentos e estes por tarefas. Suponha que para cada atividade tenha sido estabelecido um tempo de execução (tempo planejado), ou seja, um tempo para que um determinado funcionário (programador, analista, etc) a execute. Após sua execução, temos o tempo efetivo da realização da atividade (tempo realizado). Caso se deseje, por exemplo, obter o tempo efetivo de realização do processo, deve-se somar todos os tempos de todas as subdivisões do mesmo. Dessa forma o tempo do processo é o somatório do tempo de todos os seus subprocessos, que por sua vez é o somatório de suas atividades, e assim sucessivamente com todas as suas subdivisões. Da mesma forma, também podemos somar os tempos planejados e estabelecermos uma comparação entre tempo planejado e tempo realizado, que poderá no sindicar onde estamos adiantando ou atrasando o Figura 3: Ferramenta PLANEJADOR A ferramenta coleta os tempos realizados nas tarefas de um determinado processo e compara com os tempos estimados anteriormente, no momento do planejamento. Vale ressaltar que cada tarefa está relacionada a um funcionário (ator), o que também possibilita um acompanhamento da performance do mesmo. Assim, como citado anteriormente, tem-se um comparativo para os próximos planejamentos, ou seja, tem-se mais subsídios. Esta ferramenta calcula o tempo percorrido, a partir da hora/data inicial e final apontada pelo usuário, e transporta o número de horas trabalhadas para o tempo da tarefa relacionada. Ao transportar o número de horas, deve-se atualizar os dados da

5 tarefa, assim, conseqüentemente, o tempo do processo será atualizado. Com a coleta dos tempos de execução (tempos realizados) das tarefas de um determinado processo, a ferramenta possibilita a comparação destes tempos com os tempos estimados (coletados no momento do planejamento). Esta comparação permite que se faça, caso seja necessário, um ajuste (calibragem) na técnica (COCOMO II, Análise de Pontos de Função, etc.) usada para as estimativas do desenvolvimento. Vale ressaltar que cada tarefa está relacionada a um funcionário (ator), o que também possibilita um acompanhamento do desempenho do mesmo. A Figura 4 mostra, através de um diagrama de Casos de Usos, as funcionalidades da ferramenta. Cadastrar Empresa Cadastrar Ator Consultar Histórico para auxiliar na busca de dados mais específicos de acordo com as características do projeto, tais como: tamanho do projeto, características da equipe, características do cliente, entre outras. Pretende-se também disponibilizar a ferramenta e, conseqüentemente o datawarehouse, na Internet. Pretende-se também integrá-la com outras ferramentas, tal como o MS Project. 5. REFERÊNCIAS BIBLIOGRÁFICAS [1] C. Hazan, Metodologia para o Uso de Indicadores na Gerência de Projetos de Desenvolvimento de Software, Tese de Mestrado, IME, [2] M. Cereja Jr, et al., Process Definition Environment: Uma ferramenta para apoio à definição de Processos de Software no ambiente e-webproject, Congresso Internacional de Qualidade de Software, Curitiba, Cadastrar Projeto Cadastrar Processo Gerente de desenvolvimento Inserir Tempos Cadastrar Tarefa [3] M.L. Cortez, T.C.S. Chiossi, Modelos de Qualidade de Software, Campinas: Editora da Unicamp, Cadastrar Subprocesso Cadastrar Atividade Cadastrar Procedimento [4] R.S. Pressman, Software Engineering a practitioner s approach, New York: McGraw- Hill, Figura 4: Diagrama de Casos de Usos 4. CONCLUSÃO Boa parte dos fracassos relacionados ao desenvolvimento de software deve-se, principalmente, a problemas de gerenciamento deste desenvolvimento. Dentre as atividades de gerenciamento, destaca-se a atividade de planejamento. Neste sentido, a ferramenta PLANEJADOR busca subsidiar o planejamento com dados históricos de desenvolvimentos anteriores. Sabe-se que predizer o futuro é algo muito difícil, quiçá impossível, porém, com dados de experiências anteriores, uma estimativa do tempo de execução de uma atividade pode ser realizada com mais precisão. Após a realização de alguns testes reais, a ferramenta mostrou-se funcional e útil. Pretende-se, para a próxima versão, criar um datawarehouse para armazenar os tempos, criando se, para tanto, visões