Relatório do Projeto C&L Equipe de Desenvolvimento Carolina Felicissimo Leonardo Amaral Reubem Alexandre Richard Werneck Roberto Christoph Prof. Júlio César Sampaio do Prado leite
1) Contexto O objetivo desse estudo é verificar as características da evolução de software em um projeto acadêmico. Para isso foi utilizado o projeto To Sobrando que foi elaborado pelos alunos do professor Júlio César Sampaio do Prado Leite na matéria Projeto de Engenharia de Software no período 2002.1 da graduação. Com o intuito de evoluir o projeto, este sofreu algumas modificações para seu aperfeiçoamento. Durante o curso de evolução de software, os alunos da matéria se organizaram procurando reproduzir a cultura de desenvolvimento da comunidade de software aberto. O trabalho de desenvolvimento da equipe do projeto foi dividido em grupos onde os integrantes se organizaram segundo seus interesses de estudo e conhecimentos prévios. Dessa forma, alguns integrantes acabaram participando de mais de um grupo. Os seguintes grupos foram formados: grupo de desenvolvimento, grupo de qualidade, grupo de controle de versão, grupo de documentação, grupo de banco de dados e grupo de gerência e administração. Foi criada uma estrutura hierárquica para centralizar coordenação do projeto. Um participante com perfil de gerente ficou encarregado de acompanhar o progresso dos trabalhos e, na medida do possível, resolver os conflitos e demandas dos diversos grupos. Além disso, semanalmente havia um encontro presencial de todos os integrantes de todos os grupos onde eram apresentados os resultados obtidos durante a semana e definidas as atividades da semana seguinte. Esse encontro também servia para troca de experiências. Analisamos o produto original e identificamos algumas oportunidades de melhorias tais como a troca do banco de dados de PostGre para MySQL, substituição da versão da linguagem Php3 para Php4, implementação de novas funcionalidades e melhoria das existentes. Além do uso da prática de engenharia reversa para melhorar a documentação existente. Com o intuito de preparar o ambiente colaborativo, instalamos um programa para gerência de configuração e outro de acesso remoto.
2) tarefas realizadas O software produzido pelo antigo grupo de desenvolvimento se encontrava em um servidor pertencente a esse grupo, e portanto a primeira tarefa a ser realizada seria a instalação de um servidor próprio para o projeto e que se encontrasse dentro da universidade( para que todos os membros pudessem ter acesso). Um computador foi cedido pelo departamento em conjunto com uma licença do Windows NT Server. Após a formatação da máquina e a instalação do sistema operacional, era necessário a instalação dos softwares necessários para que a aplicação pudesse rodar. Esse softwares seriam um servidor HTTP, um banco de dados e o suporte a linguagem da aplicação. O objetivo seria conseguir softwares que fossem gratuitos e possuíssem boa confiabilidade e desempenho. Após algum tempo de pesquisa, chegamos a seguinte escolha de softwares: Servidor HTTP : Apache HTTP Server 2.0 É um famoso servidor HTTP gratuito, sendo amplamente usado pelo mercado. É um servidor bem simples de se usar e possui um bom desempenho e confiabilidade. Banco de dados: MySQL - É um banco de dados gratuito e bem famoso. Essa foi nossa primeira grande decisão sobre uma evolução no projeto, já que o banco original era o PostGre e uma mudança na base de dados acarretaria em diversos problemas. Essa decisão foi tomada em conjunto com o grupo responsável pelo banco de dados que fez uma comparação entre esses dois bancos(os documentos relativos se encontram no relatório deste grupo) e chegou a conclusão de que a mudança da base seria uma boa evolução para o software. A versão usada foi a 3.23.51 que era a mais estável na época da instalação. Linguagem de programação utilizada: Php4. O software foi inicialmente feito usando Php3 e a versão 4 da linguagem possuía várias diferenças muito significativas, a ponto de que a aplicação necessitaria de diversos ajustes para poder rodar como antes. Essa foi a segunda grande decisão de evolução do projeto, já que caso instalássemos a versão 4, teríamos que gastar um tempo considerável para fazer tudo voltar a funcionar. Decidimos por essa versão já que ela possuía diversas novas funções, além de que todas as novas versões da linguagem usariam essa nova versão como base e não a 3. Foi
necessário instalar não somente o pacote básico, mas também as bibliotecas de XSL adicionais. Todos os softwares foram instalados no servidor a contento, sendo que todos eram gratuitos com exceção do sistema operacional cuja licença foi fornecida pelo departamento. Cogitou-se o uso do Linux como sistema operacional do servidor, já que todos esses softwares instalados possuíam versão para esse sistema operacional e ao contrário do Windows, o Linux é gratuito. Após uma análise essa opção foi descartada pois já possuíamos uma licença do Windows NT e a grande maioria dos membros não tinha muita intimidade com o Linux, e o tempo disponível para o aprendizado era demasiado curto( o tempo completo de desenvolvimento foi de apenas 3 meses ). De posse de um servidor com todos os softwares necessários instalados, o próximo passo era a instalação do software em si, que era composto de diversas páginas php e html, a base de dados usando PostGre e alguma documentação( Diagrama dos cenários e o MER ). Todos os arquivos php e html foram colocados no servidor HTTP, mas a base de dados precisou ser convertida para o MySQL. Essa operação não foi tão trivial, já que nem todos os tipos de dados suportados pelo banco antigo eram suportados no MySQL e vice-versa, essa operação de conversão foi realizada em conjunto com o grupo responsável pelo banco de dados e demorou por volta de 1 semana. Após a conversão da base de dados para o MySQL era necessário fazer algumas alterações na código fonte da aplicação, para que essa estivesse de acordo com o novo banco, essas conversões demoram mais 2 semanas, pois a aplicação fazia uso de algumas bibliotecas exclusivas para PostGre e era necessário que todas fossem convertidas manualmente. Mesmo após a instalação da nova base, muito pouco da aplicação estava funcional, devido ao fato de estarmos usando php4. Os problemas resultantes devido ao uso dessa versão foram bem maiores do que o esperado, já que a aplicação fazia uso extensivo de várias técnicas usadas em php3 que não foram trazidas para a versão 4, uma dessas era a forma de como era feita a passagem de parâmetros para outras páginas, com isso muito pouco da aplicação estava funcional. A equipe de desenvolvimento contava com 6 integrantes, mas apenas 2 já tinham tido contado com a linguagem de programação usada na aplicação, por causa disso a equipe demorou um pouco para se familiarizar com seus conceitos e a conversão total da aplicação para a versão 4 do Php demorou cerca de 1 mês. Após esse tempo, tínhamos finalmente a aplicação plenamente funcional e devidamente convertida para usar o MySQL e o Php4.
Durante o período de desenvolvimento foram feitas várias melhorias no código, assim como a implementação de diversas novas funcionalidades, entre elas podemos citar: Esqueci Senha Foi incluída a opção de se ter a sua senha enviada por e-mail em caso de esquecimento por parte do usuário do sistema. Essa opção se encontra logo abaixo da tela de login, e para ter acesso a ela basta preencher o um campo relativo ao login do usuário solicitante que a senha será enviado para o e-mail cadastrado no banco de dados. Alterar Cadastro Foi incluída uma opção para o caso de um usuário que já esteja cadastrado no sistema possa alterar seus dados( o que pode ser necessário por exemplo no caso de uma mudança de e-mail ). Essa opção está disponível assim que o usuário se autentica no sistema. Javascripts de testes de formulários Foi feita a inserção de diversas funções feitas em JavaScript que tem a funcionalidade de checar se os dados entrados pelos usuários são válidos e podem ser adicionados sem problemas no banco de dados. Novo Logo O nome da aplicação foi mudado. O antigo nome era To Sobrando e o novo nome escolhido foi C&L ( Editor de Cenários e Léxicos ). Para acompanhar essa mudança foi desenvolvido um novo Logo que foi colocado em diversos pontos da aplicação. Sair Foi feita uma opção para que o usuário que esteja dentro do sistema possa sair. Antes dessa opção o único meio de entrar no sistema novamente era fechando o navegador e abrindo outro, já que as variáveis de sessão não permitiam ao usuário utilizar a mesma janela. Essa opção termina toda e qualquer variável da sessão corrente e chama novamente a página de entrada.
Gerar XML Uma nova opção de geração e armazenamento de XML foi incluída. Agora é possível gerar um XML do projeto corrente ( com ou sem XSL ) e armazená-lo no banco de dados com uma versão para futura referência. Recuperar XML Juntamente com a opção de geração de XML, foi feita uma de recuperação. Com ela é possível recuperar ou apagar XMLs gerados pela opção acima através de sua versão. Tabelas novas no BD Foram adicionadas novas tabelas ao banco de dados, algumas já são utilizadas, como é o caso da tabela publicação(que é usada para armazenar e recuperar XMLs do projeto), outras como a tabela Status ainda não são usados, mas serão no futuro. Correção de Bugs Diversos bugs foram corrigidos durante a fase de desenvolvimento. Durante essa fase, alguns membros da equipe se responsabilizaram por percorrer a aplicação inteira e mapear todos os problemas encontrados(por menor que fossem) para que esses pudessem ser corrigidos. Os problemas variaram desde problemas graves( travamento do sistema) até triviais(erros de português). 3) Produtos produzidos Nesta seção, estaremos enumerando os produtos produzidos pela equipe de desenvolvimento durante o processo de evolução do software em questão. Para isso, podemos tomar como base à seção anterior, tarefas realizadas, como subsídio para obter tais produtos produzidos. No caso da equipe de desenvolvimento, estes são basicamente o código fonte gerado. Por isso, vamos referenciar o código gerado de cada tarefa a partir dos nomes dos arquivos relacionados com tal tarefa. Como dito na seção tarefas realizadas, houveram dois grandes processos durante a fase inicial da evolução do sistema. A primeira foi a migração do banco de dados. A segunda é referente à mudança na versão da linguagem Php utilizada. Ambos geraram várias alterações no código, abrangendo quase todos os arquivos que compunham a aplicação.
Para a migração do banco de dados, podemos enumerar como produtos produzidos os seguintes arquivos: Add_lexico.php Add_projeto.php Add_usuario.php Alt_cenario.php Alt_lexico.php Bd_class.php Call_UpdUser.php Code.php Enviar_senha.php Frame_inferior.php Funcoes_genericas.php Gerador_xml.php Heading.php login.php main.php mostraprojeto.xml mostraxml.php projetos.php recuperarxml.php rel_usuario.php ver_pedido_cenario.php ver_pedido_lexico.php upduser.php bd.inc httprequest.
A migração do PHP3 para a versão 4 desta mesma linguagem gerou alterações em todos os arquivos que continham código php, já que foram necessárias várias mudanças e algumas inclusões de novas bibliotecas criadas: bd.inc httprequest.inc Abaixo encontra a relação de novas funcionalidades desenvolvidas no sistema e os respectivos arquivos produzidos ou alterados: Esqueci Senha Foi incluída a opção de se ter a sua senha enviada por e-mail em caso de esquecimento por parte do usuário do sistema. Login.php esquecisenha.php Alterar Cadastro Foi incluída uma opção para o caso de um usuário que já esteja cadastrado no sistema possa alterar seus dados. heading.php Call_UpdUser.php upduser.php Javascripts de testes de formulários Alt_cenario.php Alt_lexico.php login.php Add_lexico.php Add_projeto.php Add_usuario.php Novo Logo index.php
heading.php login.php Sair Foi feita uma opção para que o usuário que esteja dentro do sistema possa sair. heading.php logout.php Gerar XML Uma nova opção de geração e armazenamento de XML foi incluída. main.php form_xml.php gerador_xml.php projeto.xsl Recuperar XML Juntamente com a opção de geração de XML, foi feita uma de recuperação.. main.php recuperarxml.php mostraxml.php projeto.xsl Tabelas novas no BD Foram adicionadas novas tabelas ao banco de dados. gerador_xml.php motrarprojeto.php projetos.php recuperarxml.php Correção de Bugs Diversos bugs foram corrigidos durante a fase de desenvolvimento.
4- Relação com a literatura, com ênfase na evolução. Nesse capitulo, vamos procurar traçar um paralelo da nossa experiência no desenvolvimento do C&L, com as 8 leis da evolução de software apresentadas por Lehman em [Law]. I Mudança Contínua Um sistema de informação que é usado deve ser continuamente adaptado caso contrário se torna progressivamente menos satisfatório. No nosso projeto, as mudanças que nortearam a evolução do sistema foram definidas no início do curso a partir de análise prévia do produto original e não devido ao seu uso. II- Complexidade crescente À medida que um programa é desenvolvido, sua complexidade cresce a menos que um trabalho seja feito para mantê-la ou diminui-la. Uma vez que a necessidade de adaptação cresce e as mudanças são sucessivamente implementadas, interações e dependências entre os elementos do sistema crescem em um padrão desestruturado e levam a um crescimento da entropia do sistema. Uma constatação dessa lei dentro do nosso projeto foi novamente a migração da linguagem Php3 para o Php4. Essa necessidade de evolução, que foi originalmente determinada pela primeira lei, desencadeou uma série de mudanças em diversas partes do código que deixaram de funcionar devido à migração, e tiveram, portanto, que ser revistas. III Auto-regulação O processo de evolução de software é auto-regulado próximo a distribuição normal com relação às medidas de produtos e atributos de processos. Não chegamos a estabelecer medidas que nos possibilitassem constatar empiricamente essa característica de evolução no nosso projeto. Mesmo porque, o porte/duração do projeto não nos possibilitaria gerar um conjunto de medições suficiente para tal.
Por outro lado, uma observação não empírica sugere que o processo de evolução não sofreu grandes variações, que, se caso ocorressem, poderiam ir contra essa lei. IV Conservação da estabilidade organizacional (taxa constante de trabalho) A taxa de atividade global efetiva média em um sistema em evolução é constante sobre o tempo de vida do produto. A taxa de trabalho foi na maioria das vezes constante, mesmo que em alguns momentos, percebemos alguns picos de desenvolvimento, como por exemplo, a troca do banco de dados, que precisava ser feita no menor tempo possível. V Conservação da Familiaridade Durante a vida produtiva de um programa em evolução, o conteúdo de lançamentos sucessivos é estatisticamente invariante. Um dos fatores que determina o progresso do desenvolvimento do software é a familiaridade de todos os envolvidos com seus objetivos. Quanto mais mudanças e adições forem associadas a uma determinada versão, maior será a dificuldade para que todos os envolvidos se familiarizem com elas. A taxa e qualidade de progresso e outros parâmetros são influenciados, até mesmo limitado, pela taxa de aquisição da informação necessária pelos participantes coletivamente e individualmente. Durante o projeto tivemos duas grandes mudanças que permearam praticamente todo o sistema. A primeira foi a foi a mudança do banco de dados, e a segunda a alteração do Php3 para o Php4. Ambas envolviam a familiaridade da equipe com todo o sistema legado. A segunda mudança foi muito mais demorada e seu progresso foi visivelmente menor que a segunda, isso se deveu principalmente ao maior tamanho desta tarefa e não ao seu nível superior de complexidade, ao ponto que foi necessário alterar partes de todos os arquivos com extensão php do software. VI Crescimento contínuo O conteúdo funcional de um programa deve ser continuamente aumentado para manter a satisfação do usuário durante seu tempo de vida. Á medida que o usuário adquire familiaridade com o produto, ele tende a fazer pressão por novas funcionalidades. A maioria das mudanças implementadas pelo grupo durante o curso foi definida no início do projeto, e aparentemente foram fruto da experiência da equipe com outros
sistemas, e não percebidas pelo uso rotineiro desse. A única funcionalidade que talvez tivesse essa característica foi a criação de um repositório de publicações. Essa mudança foi demandada por um dos participantes de um dos grupos, que era um usuário da ferramenta. VII Qualidade decrescente Programas apresentarão qualidade decadente a menos que sejam rigorosamente mantidos e adaptados às mudanças no ambiente operacional. A motivação da mudança de linguagem de php3 para o php4 tem base nessa lei. A tendência é que todo novo suporte a linguagem seja oferecida a para sua versão mais recente. Dessa forma, se mantivéssemos a versão anterior do php, poderíamos perder o seu suporte e manutenção do sistema ficaria obsoleta. VIII Sistema de Feedback Processos de programação constituem sistemas de multi-loop, multi-level e devem ser tratados como tais para serem modificados e melhorados com sucesso. O processo de desenvolvimento adotado previa reuniões presenciais que geravam feedback para o sistema. 5- Aprendizado: O trabalho de desenvolvimento da equipe do projeto foi dividido em grupos onde cada integrante especializou-se naquilo que mais tinha afinidade. O trabalho, na maioria das vezes, foi remoto num ambiente de desenvolvimento colaborativo (tanto de desenvolvedores quanto de usuários), baseado no processo de desenvolvimento conjunto e compartilhado. Os programadores do projeto, como os programadores de softwares livres, são pessoas completamente diferentes que usam da prática de programação do software livre um hobby, ou seja, não existe um período ou horário pré-estabelecido para o desenvolvimento. É sobretudo uma atividade prazerosa. Vale ressaltar que, apesar da flexibilidade de horário do desenvolvimento, existe a preocupação com o cumprimento de prazos pré-estabelecidos.
Para que o desenvolvimento do projeto desse certo, criou-se uma estrutura hierárquica em que existiam pessoas com determinadas responsabilidades e deveres e o próprio desenvolvimento também caminhou com regras específicas para cada grupo. Esta prática já é percebida na comunidade de software livre e foi um aprendizado para a viabilização do trabalho em conjunto. Desse desenvolvimento, tivemos a geração de produtos com qualidade. A cultura do software livre que, apesar de já ser robusto e eficiente ainda possui interface com o usuário pobre no sentido do conceito "user-friendly", foi assimilada. Essa afirmativa foi confirmada ao se tentar utilizar o software de controle de versão usado nessa cultura, o CVS. Isto porque, não conseguimos instalar a sua versão Windows ("user-friendly") para o uso nos clientes tendo, assim, que estes utilizarem o software via linha de comando. Assim, a vontade, o conhecimento e entendimento de comandos básicos e a tentativa existiram mas, infelizmente, o uso efetivo do software não aconteceu. Vale lembrar que a rica documentação dos software livres ajudou muito no desenvolvimento do projeto. Seja por tutoriais em diversos níveis de dificuldades e idiomas, seja por bibliotecas já desenvolvidas, seja por dúvidas mais freqüentes já respondidas. No entanto, houve a criação de uma lista eletrônica de discussão própria do grupo em que várias mensagens foram trocadas. Novidades foram informadas, votações foram feitas, gerenciamento através de cobrança de prazos e divisão de tarefas, documentação criada e divulgada. As mensagens trocadas podem ser conferidas em: http://139.82.35.67/cel/emails/email.html Também houve a prática do exercício da engenharia reversa em que, a partir de códigos-fontes, geramos documentação (ex: Arquitetura do sistema) e, até, novos módulos do projeto (ex: Funcionalidade Sair ). Para isto, houve um estudo e análise do software original. Por fim, tivemos o aprendizado da teoria e prática de uso de cenários e léxicos num nível de entendimento tão satisfatório que foi possível para o grupo de qualidade a prática de outro aprendizado, o de inspeção de software.
6- Referências: [Law] Lehman M M, Laws of Software Evolution Revisted. http://www.mozilla.org/ http://www.apache.org http://www.cvshome.org/ http://www.php.net/ http://www.mysql.com/