Evolução de Software: uma experiência prática Pós-Graduação em Informática – PUC-Rio disciplina: Evolução de Software prof. Julio Cesar Sampaio do Prado Leite por: Claudio Nogueira Sant'Anna Kleyna Moore Almeida Miriam Sayão

1) Contexto no TôSobrando/CEL O processo de evolução do software TôSobrando iniciou-se após o grupo da disciplina de Evolução de Software ter trabalhado, em sala de aula e em estudos individuais, aspectos relativos a evolução de software, software legado, gerenciamento e controle de versões e configuração de software e desenvolvimento de software livre.

O software recebido para evolução foi resultado do trabalho do semestre anterior de um grupo de alunos de graduação, e apresentava-se incompleto, já que o período de um semestre não havia sido suficiente para a conclusão de uma versão que pudesse ser considerada em condições de uso. Os objetivos desse trabalho incluíam funcionalidades para a fase de Requisitos de um processo de desenvolvimento de software, mais especificamente para edição de Cenários e Léxicos.

Numa avaliação inicial foram detectadas as seguintes necessidades para evolução do TôSobrando:

• escolha de nome que fizesse referência aos objetivos do software • detecção e correção de bugs existentes • migração do sistema gerenciador de banco de dados de Postgrees para

MySQL (mais adequada às necessidades do software) • inclusão de funcionalidades, priorizando Lembrança de Senha e Logout • complementação e adequação da documentação existente às

funcionalidades efetivamente implementadas • inserção dos cenários nos correspondentes arquivos PHP da aplicação • utilização de um software para gerenciamento e controle de versões e

configuração, visando a experimentação desta por parte do grupo e um efetivo apoio ao gerenciamento das atividades de evolução

• verificação da qualidade dos artefatos produzidos Nesse contexto, inicialmente decidimos trabalhar aspectos relativos ao gerenciamento de configuração e controle de versões, além da tarefa de identificação de bugs, a ser trabalhada por todos. Entendemos que, num processo cooperativo e distribuído de evolução de software, o gerenciamento das atividades é muito facilitado quando se conta com ferramentas de apoio à gestão e controle de configuração e de versões.

O software em evolução, inicialmente denominado "TôSobrando" e posteriormente "CEL – Cenários e Léxicos", é uma ferramenta destinada ao apoio

do gerenciamento de requisitos. Atualmente tem-se a convicção que mudanças em requisitos ao longo do processo de desenvolvimento de software fazem parte do processo. Entre os motivos para que ocorram alterações em requisitos identificamos necessidades não identificadas inicialmente, correção de erros detectados por processos de qualidade ou mesmo novas perspectivas por parte dos stakeholders. A ferramenta em evolução integra aspectos da criação de uma baseline necessária para o registro e acompanhamento da evolução dos requisitos ao longo do ciclo de desenvolvimento. A proposta de Leite [Lei97] para a baseline inclui um modelo de léxico (apoio à elicitação da linguagem do macrosistema), um modelo básico (diagramas E-R para requisitos externos), modelo de cenários (situações de comportamento da aplicação em momentos específicos), modelo de hipertexto e um modelo de configuração (estes dois últimos são na verdade serviços de suporte aos demais componentes da baseline). O software sendo evoluído, portanto, pode ser visto como uma ferramenta para a criação desta baseline, visando apoiar o processo de gerenciamento de requisitos.

Num momento posterior, após concluídas as principais atividades em relação ao inicialmente estabelecido, escolhemos trabalhar aspectos relativos ao controle da qualidade dos artefatos de software produzidos no processo de evolução. A qualidade de um artefato de software pode ser trabalhada através da utilização de métricas, indicadores ou por meio de testes; a avaliação crítica desses artefatos pode ser realizada através de inspeções. Métricas fornecem subsídios importantes para o gerenciamento do projeto, e podem ser aplicadas em diferentes etapas do processo de desenvolvimento. As inspeções ajudam a encontrar defeitos em artefatos, antes que se passe à fase seguinte do processo; no cerne do processo de inspeção estão a identificação das informações a serem checadas e a técnica a ser utilizada para identificar defeitos nessas informações. Testes são efetuados após a implementação dos componentes estabelecidos no processo de desenho/projeto e visam identificar erros que possam comprometer a funcionalidade do software; geralmente são efetuados testes do tipo caixa branca (executados pelo programador visando verificar a correção da implementação) e caixa preta (executados por equipe externa visando verificar completude e funcionalidades) [OLI01]. No trabalho de evolução optamos pela utilização de inspeções e de testes para aferição e melhoria da qualidade do produto. Essas duas técnicas localizam e apontam defeitos/problemas no artefato em questão, sendo então possível ações corretivas que melhorem a qualidade do artefato antes que se passe à fase seguinte no processo de evolução. A literatura aponta que, quanto mais cedo se

faz essa correção, menor será o custo a ela associado; estima-se que o custo de descobrir e corrigir um defeito na fase de testes seja de 5 a 100 vezes maior que o de descobrir e corrigir o problema ainda no Processo de Requisitos [BLA01].

2) Tarefas executadas A equipe auto-denominada Equipe da Qualidade executou um conjunto de tarefas relacionadas ao gerenciamento do projeto e à verificação de qualidade do processo e dos produtos desenvolvidos. A equipe às vezes contou com participação de outros integrantes da disciplina de Evolução de Software; sempre que isto aconteceu, o correspondente registro foi feito.

2.1) Registro da reunião ocorrida em 13.09.2002 (vide anexo 1) Descrição: Nesta reunião, o grupo de alunos discutiu aspectos relacionados à evolução do software CEL, tendo sido definidos tópicos de interesse e pessoas a integrarem cada uma das equipes. O registro das definições efetuadas foi realizado para possibilitar acompanhamento das tarefas que o grupo se propôs.

2.2) Avaliação crítica do CEL, envolvendo testes do software e registro de problemas encontrados (vide anexo 2)

Descrição: A documentação disponível não incluía casos de teste; a seqüência de testes disponível na página do CEL, além de se referir a outro trabalho, não era consistente com a implementação realizada. Optamos, então, por executar um conjunto de testes baseados na experiência dos participantes, buscando uma cobertura integral das funcionalidades próprias do software. Dificuldades: A equipe não encontrou dificuldades na realização desta tarefa. Tecnologias/Técnicas utilizadas: Para a execução dos testes foram utilizados os navegadores Internet Explorer versão 5.00 e o Netscape Communicator versão 4.7.

2.3) Avaliação de ferramentas para controle de versões de software e escolha daquela a ser utilizada pelo grupo de Evolução do CEL

Descrição: A equipe dispôs-se a avaliar diferentes ferramentas para controle de versões, a saber: Clear Case, integrante da Rational suite, da Rational

CVS (Concurrent Version System), software livre SourceSafe, integrante do pacote Visual Studio, da Microsoft Nos levantamentos iniciais consideramos que o processo de trabalho a ser utilizado pela equipe envolvia distribuição e cooperação na execução de tarefas. A avaliação inicial das ferramentas apontavam para as seguintes características: Clear Case: além de ser um sistema de controle de versões, esta ferramenta assegura a recuperação de qualquer versão e organiza um processo efetivo de desenvolvimento distribuído. Integrado a outras ferramentas da Rational para gerenciamento do processo de desenvolvimento. Disponível para plataformas Windows (interface gráfica) e Linux. CVS: software livre para controle de versões; mantém diferentes versões de um arquivo de forma a minimizar o espaço ocupado em disco, armazenando apenas as diferenças entre essas versões. Distribuído através da Internet, endereço http://www.cvshome.org ; disponível em plataformas Linux e Windows (interface orientada a linhas de comandos). SourceSafe: controle de versões orientado a projetos, apóia o gerenciamento de desenvolvimento de sites da Web e de software. Integrado com os ambientes de desenvolvimento Visual Basic, Visual C++, Visual J++, Visual InterDev e Visual FoxPro e com aplicativos do Microsoft Office. Esta ferramenta manipula qualquer tipo de arquivo; os usuários podem trabalhar tanto no nível de arquivos quanto de projetos e também promover a reutilização de arquivos. Disponível em ambientes Windows (interface gráfica) e Linux. Das três ferramentas inicialmente selecionadas, sabíamos que a PUC-Rio tinha licenciada a SourceSafe e, como o Departamento de Informética da PUC-Rio tinha convênio com a Rational, imaginávamos ter acesso à ferramenta Clear Case. Após contato com o pessoal de suporte para acesso à suíte da Rational, que não estava operacional nas máquinas do Lab-Pos, identificamos que não havia licenciamento para Clear Case; esta ferramenta foi então descartada para uso no processo de evolução do CEL. Partimos então para a instalação da SourceSafe na máquina servidora do projeto, e também buscamos o CVS para instalação e comparação das características de ambas. A versão obtida do CVS não se mostrou operacional, e então optamos pela definição da SourceSafe para o projeto. A instalação foi feita com sucesso, e a equipe pôde testar e experimentar diversas funcionalidades do SourceSafe.

Apresentamos na reunião do grupo os motivos para a escolha da ferramenta SourceSafe; fomos questionados em relação ao fato desta ferramenta não ser software livre. O que de certa forma se buscava no processo de evolução do CEL era a geração de software livre, e o uso de ferramenta que não seguisse esta filosofia invalidaria o posterior controle de versões do próprio software gerado. Retomamos o trabalho em busca por uma ferramenta para gerenciamento e controle de versões; localizamos outra versão do CVS com apoio de pessoal do TecCom, e conseguimos a instalação de uma nova versão. Esta versão necessitou ser instalada em ambiente Windows, já que a equipe de Evolução não mostrou disposição em trabalhar no ambiente Linux. Nesta versão não conseguimos uma interface gráfica adequada, e portanto trabalhamos no sentido de preparar manuais de apoio ao trabalho com o CVS, através de linhas de comando em janelas DOS, sob Windows. Também necessitamos apoio do pessoal de suporte do LES, para possibilitar acesso remoto da equipe de desenvolvimento ao repositório dos arquivos do projeto, já que o firewall que protegia o acesso externo às portas lógicas dos servidores do LES impedia acesso às portas do servidor do projeto Evolução para uso com o CVS. Após contato, solicitação e justificativas, com a intervenção do prof. Julio, a liberação das portas foi efetivada. Dificuldades: Apenas um dos integrantes da equipe já havia utilizado, ainda que minimamente, uma ferramenta para controle de versões. Não tínhamos portanto domínio das funções que uma ferramenta deste tipo deve efetuar; somamos a isto o fato da documentação encontrada para utilização do CVS não trazer exemplos práticos de uso, o que tornou um pouco demorada a identificação dos comandos adequados a cada necessidade do grupo de Evolução. Também encontramos resistências, por parte da equipe de desenvolvimento, na utilização de um software sem interface gráfica. Apesar de termos elaborado um “manual de uso diário” do CVS, com os comandos do dia-a-dia, identificamos baixa utilização deste software por parte dos desenvolvedores. Tecnologias/Técnicas utilizadas: Acesso à Internet via navegador Netscape para download do CVS; Acrobat Reader versão 4.0 para leitura do manual que acompanha o software.

2.4) Elaboração de Manual de referência rápida do software CVS – Concurrent Version System (vide anexo 4)

Descrição: Com a intenção de agilizar o processo de utilização da nova tecnologia, CVS, pelas equipes de Documentação e Desenvolvimento, elaboramos um “Manual do Gerenciador de Versões de Software”, utilizando a ajuda on-line do CVS e também testando a execução dos comandos para identificar os mais adequados às várias tarefas no gerenciamento e controle de versões. Este manual abrange todos os comandos de uso do CVS, com as várias opções para cada comando. Dificuldades: Não encontramos dificuldades na realização desta tarefa. Tecnologias/Técnicas utilizadas: Editor de textos Word versão 2000 e ambiente MS/DOS para execução de estudo e testes de utilização da ferramenta.

2.5) Elaboração do “Manual de uso diário do CVS”, com comandos mais freqüentemente utilizados (vide anexo 5)

Descrição: Por se tratar de comandos para ambiente MS/DOS, houve uma certa restrição na utilização do CVS por parte de ambas as equipes de Desenvolvimento e Documentação; assim elaboramos um relatório de treinamento básico “Como utilizar o Gerenciador de Versões de Software CVS – Concurrent Version System”, que foi aprimorado para “Guia para o Uso do CVS”.

Dificuldades: A equipe não encontrou dificuldades na realização desta tarefa. Tecnologias/Técnicas utilizadas: Editor de textos Word versão 2000 e ambiente MS/DOS para execução de estudo e testes de utilização da ferramenta.

2.6) Criação de propostas de nome e acrônimos para o TôSobrando (vide anexo 6)

Descrição: Como o nome do sistema, "TôSobrando", não expressava a natureza nem os objetivos do software, o grupo de Evolução foi solicitado a apresentar sugestões. A equipe sugeriu o nome "Cenários e Léxicos" e também apresentou duas sugestões para acrônimos – CEL e CenLex. Desta forma, foram colocados em discussão as sugestões; o grupo de Evolução aceitou o nome sugerido e votou para escolha do melhor acrônimo, escolhendo o acrônimo CEL. A equipe de Desenvolvimento ficou responsável pelos ajustes e alterações no código. Dificuldades: A equipe não encontrou dificuldades na realização desta tarefa. Tecnologias/Técnicas utilizadas: Não houve utilização de tecnologia.

2.7) Inspeção dos cenários do CEL (vide anexo 7) Descrição: A equipe de qualidade definiu que uma das atividades para verificação da qualidade no produto envolvia inspeção nos cenários, já que uma avaliação inicial dos mesmos havia detectado inconsistências entre a implementação e os cenários, e também problemas sintáticos e de estruturação dos mesmos. Pesquisamos literatura sobre o tema [BAS00] [FAG86] [LAI01], e identificamos que as técnicas de leitura mais indicadas para artefatos produzidos na fase de requisitos são: Leitura baseada em checklists (ou ckecklists) e Leituras baseadas em perspectivas (ou PBR). Estas duas técnicas já foram validadas em processos experimentais e estão em uso na indústria de desenvolvimento de software, apesar da última, PBR, ser ainda muito recente. Após consulta ao prof. Julio sobre a técnica de leitura a ser utilizada, escolhemos a inspeção baseada em checklists; o prof. Julio nos passou um conjunto de questões a utilizar em requisitos, léxicos e cenários. O processo de inspeção pode ser visualizado na Figura 1, onde são visualizados os principais componentes. As etapas desse processo estão descritas a seguir:

• Planejamento: seleção de participantes, atribuição de papéis, agendamento da reunião de inspeção, reprodução e distribuição do material a ser utilizado

• Visão geral: autor apresenta o artefato a ser inspecionado aos participantes

• Inspeção: inspetores avaliam o artefato e registram defeitos encontrados • Coleção: defeitos são reunidos e comunicados ao autor do artefato • Correção: defeitos encontrados são corrigidos • Acompanhamento: verificação da correção dos defeitos apontados

Figura 1 – Visão geral do processo de inspeção No processo de inspeção existem diferentes papéis a serem desempenhados pelos participantes. Nossa equipe desempenhou os papéis de organizador (o que é responsável pela organização e condução do processo como um todo), inspetor (o que analisa o documento em questão) e relator (o que comunica os resultados da inspeção ao autor do artefato). O organizador atribuiu os papéis aos participantes, em acordo com estes, e se certificou que todos receberam o material para estudo (a bibliografia selecionada). À equipe uniram-se mais dois integrantes do grupo de Evolução; a equipe assim constituída se preparou para efetivação da inspeção, lendo a literatura selecionada, discutindo e se aprofundando nas atividades de um processo de inspeção. Marcada a reunião de inspeção, esta aconteceu após o material a ser utilizado no processo ser distribuído entre os integrantes. Houve participação ativa de todos, mas a reunião teve duração superior à estimada, em parte devido à nossa inexperiência com processos de inspeção. Após a inspeção, coletamos os

Inspeção

Processo

Técnicas de leitura

Artefatos • a serem inspecionados

• para conduzir a inspeção

• Ad hoc

• Check lists

• Abstração de erros

• baseada em Pontos de Função

• Baseada em Perspectivas

Papéis

• Organizador

• Moderador

• Inspetor

• Autor

• Secretário

• Relator

Planeja - mento

Inspeção Coleção CorreçãoVisão geral

Acompa - nhamento

Inspeção

Processo

Técnicas de leitura

Artefatos • a serem inspecionados

• para conduzir a inspeção

• Ad hoc

• Check lists

• Abstração de erros

• baseada em Pontos de Função

• Baseada em Perspectivas

Papéis

• Organizador

• Moderador

• Inspetor

• Autor

• Secretário

• Relator

Planeja - mento

Coleção CorreçãoVisão geral

Acompa - nhamento

defeitos encontrados, elaboramos o relatório e solicitamos espaço durante a aula para relatar ao grupo de Evolução. Neste processo, designamos um relator e um moderador; o secretário foi definido pela equipe de Documentação. Os defeitos foram relatados e buscamos o comprometimento da equipe de documentação para sanar os problemas detectados.

O acompanhamento da correção dos defeitos por parte da equipe de Documentação foi efetuado através da lista de discussão; a cada nova versão dos cenários revisada, a equipe executava a validação dos cenários e apontava eventuais erros ainda persistentes. Nesta tarefa tivemos a participação de Leonardo Almaraz e Lyrene Fernandes. Dificuldades: A única dificuldade encontrada foi, na verdade, a falta de experiência da equipe em realizar inspeções e em trabalhar com cenários. Isto fez com que tivéssemos alguma dificuldade com a identificação de defeitos sintáticos nos cenários, o que necessitou de maior tempo para a execução da inspeção. Tecnologias/Técnicas utilizadas: Utilizamos a técnica de inspeção por checklist; as atividades seguiram o modelo de inspeção criado por Feagan e relatado por Laitenberger.

2.8) Criação do Mapa da estrutura dos cenários (vide anexo 8)

Descrição: Construímos um mapa da estrutura dos cenários relacionando os cenários em termos de pré-condições, complementos e subconjuntos. Como preparação, estudamos previamente a definição dos tipos de relacionamentos possíveis entre cenários: pré-condição, possível precedência, equivalência, subconjunto, exceção, inclusão e complemento. Esta tarefa foi executada em paralelo com a correção dos cenários, por isso tivemos que nos basear nos cenários da aplicação ainda sem as correções e no relatório de inspeção. Durante a análise dos relacionamento entre os cenários da aplicação com objetivo de eliminar redundância e ambigüidade, integrar os cenários e melhorar o entendimento, verificamos alterações necessárias nos cenários existentes, surgimentos de novos cenários e eliminação de outros.

Nesta tarefa tivemos a participação de William Oliveira de Souza. Dificuldades: Tivemos muita dificuldade para entender a semântica dos tipos de relacionamento possíveis entre cenários. Esta dificuldade deveu-se provavelmente a inadequação do material de estudo utilizado para nossa preparação prévia. Tecnologias/Técnicas utilizadas: Propostas para identificação de relacionamentos entre cenários com utilização de gráficos, de Karin K. Breitman, apresentada no Tutorial40_491.swf.

2.9) Elaboração de Casos de Testes para um conjunto de cenários (vide anexo 9)

Descrição: Consideramos a garantia de qualidade uma preocupação essencial no desenvolvimento de software. Dentre outras coisas, para que a qualidade do software seja garantida, são empregadas no seu desenvolvimento ou evolução técnicas de controle de qualidade. Técnicas de testes fazem parte do conjunto de técnicas de controle de qualidade. É possível desenvolver casos de teste para os requisitos, já no processo de engenharia de requisitos. Pode-se adotar, por exemplo, técnicas baseadas em cenários e criar casos de teste; estes serão utilizados na fase de verificação do código, visando descoberta de problemas. A aplicação de testes torna-se necessária para a validação das versões geradas na evolução, já que vários componentes de código podem ser alterados ao mesmo tempo; essas alterações podem interferir no comportamento do sistema e resultar em problemas mesmo para componentes já testados com sucesso.

Tendo isso em vista, e com o objetivo de tornar a realização dos testes uma atividade mais controlada, elaboramos um conjunto de casos de teste. Devido a limitação de tempo, foram gerados casos de teste relativos a apenas os seguintes cenários: Usuário solicita alteração de Léxico, Incluir Léxico, Alterar Léxico e Excluir Léxico.

Nos baseamos na análise e leitura dos cenários. Os passos de cada caso de teste foram identificados levando-se em consideração o contexto, os atores, os

recursos e os episódios de cada cenário. Geramos diferentes casos de teste para validar a execução normal dos episódios, as restrições e exceções. Dificuldades: Durante a leitura dos cenários para elaborar os casos de testes, encontramos pontos nas descrições dos cenários que ainda precisavam ser corrigidos. Isso dificultou um pouco nossa tarefa, pois desviou nossa atenção no sentido de nos preocuparmos também em verificar tais problemas e repassá-los para a equipe de documentação. Tecnologias/Técnicas utilizadas: Utilizamos os cenários da aplicação, já corrigidos, como base para elaborar os casos de teste.

2.10) Relatório de validação dos cenários corrigidos (vide anexo 10) Descrição: Os cenários gerados pela equipe de Documentação foram rapidamente verificados numa reunião de validação de duração de 1 hora e apresentados os resultados na lista para o grupo de Evolução, particularmente para a equipe de Documentação. Encontramos alguns erros de sintaxe e semântica. Dificuldades: A equipe não encontrou dificuldades na realização desta tarefa, por ter experiência prévia na inspeção. Tecnologias/Técnicas utilizadas: A equipe confrontou as especificações dos cenários apresentados com o Relatório de Inspeção.

2.11) Criação do Mapa da estrutura de arquivos com interface para BD (vide anexo 11)

Descrição: O mapa da estrutura de arquivos tem a finalidade de auxiliar no entendimento da completude e no inter-relacionamento dos arquivos existentes para apoiar a evolução da codificação. Este mapeamento foi realizado a partir da análise dos códigos dos arquivos, levando em consideração as características de intercomunicação de módulos apresentado em [CAR00]. Após apresentação ao

grupo de Evolução, foi sugerido que o mapa incluísse as ligações de importações e exportações com o Banco de Dados. Dificuldades: A equipe grande dificuldade em transformar o arquivo gfc em jpg. Tecnologias/Técnicas utilizadas: O software utilizado na elaboração do mapa foi o Flow 4, mas com o interesse de disponibilizá-lo na página do CEL, foi necessário convertê-lo para tipo jpg.

2.12) Elaboração de um relatório sobre XML, comparação com HTML e Suporte de XML em PHP para a equipe de desenvolvimento

Descrição: O sistema TôSobrando foi desenvolvido com utilização das linguagens PHP, JavaScript e Html e do Sistema Gerenciador de Banco de Dados Postgrees. A equipe de desenvolvimento possuía conhecimentos e experiência limitados tanto na linguagem PHP quanto XML e HTML integrados a PHP. Como material de apoio à equipe de desenvolvimento, foi gerado um relatório comparativo entre XML e HTML, incluindo o suporte de XML na linguagem PHP. Dificuldades:

A equipe não encontrou dificuldades na realização desta tarefa.

Tecnologias/Técnicas utilizadas: Foi utilizado o Word para edição do estudo realizado no livro "Professional PHP Programando", de J. Castagnetto et al.

2.13) Proposta de logotipos para o CEL

Descrição: Mediante a modificação do nome do sistema, foi levantada a possibilidade de criar um logotipo para o sistema; este logotipo deveria ser condizente com o acrônimo "CEL". Não havendo especialista ou web designer no grupo de Evolução, a equipe elaborou e apresentou dois logotipos.

Dificuldades: A equipe não tinha experiência na utilização ferramentas apropriadas à criação de logotipos (ou mesmo design) gráficos, como COREL DRAW, disponível nos laboratórios de pós-graduação. Foram realizadas algumas tentativas de uso desse software, com resultados insatisfatórios, o que nos levou a buscar outra ferramenta que, mesmo sendo limitada, propiciasse a criação de peças gráficas e cuja utilização fosse dominada pela equipe. Tecnologias/Técnicas utilizadas:

Para os desenhos dos logotipos sugeridos utilizamos o software Paint.

2.14) Elaboração do esboço da estrutura de arquivos da aplicação

Descrição: Para facilitar a visualização da estrutura interna dos arquivos da aplicação, elaboramos um esboço dessa estrutura, visando entender melhor o sistema. Esse esboço permite ainda ter noção dos relacionamentos que existem entre os componentes da aplicação. Dificuldades: Não tivemos dificuldades na elaboração desta tarefa. Tecnologias/Técnicas utilizadas:

Para o esboço da arquitetura utilizamos o software Together.

3) Produtos produzidos

3.1) Registro da reunião ocorrida em 13.09.2002; vide anexo 1 3.2) Avaliação crítica do CEL, envolvendo testes do software e registro de

problemas encontrados; vide anexo 2 3.3) Documento indicando motivações para escolha inicial do software

SourceSafe para controle de versões; vide anexo 3 (Ferramenta de Controle de Versões)

3.4) Manual de referência rápida do software CVS – Concurrent Version System; vide anexo 4

3.5) Manual de uso diário do CVS, com comandos mais freqüentemente utilizados; vide anexo 5

3.6) Proposta de nome e acrônimos para o TôSobrando; vide anexo 6 3.7) Relatório de Inspeção dos cenários do CEL; vide anexo 7 3.8) Mapa da estrutura dos cenários; vide anexo 8 3.9) Casos de testes para um conjunto de cenários; vide anexo 9 3.10) Relatório de validação dos cenários corrigidos; vide anexo 10 3.11) Mapa da estrutura de arquivos com interface para BD; vide anexo 11 3.12) Relato/estudo sobre XML, comparação com HTML e Suporte de XML

em PHP; vide anexo 12 3.13) Proposta de logotipos para o CEL; vide anexo 13 3.14) Esboço da estrutura de arquivos da aplicação; vide anexo 14

4) Relação com literatura O trabalho desenvolvido na disciplina de Evolução de Software envolveu detecção e correção de bugs existentes, troca do sistema gerenciador de banco de dados, inclusão de funcionalidades, complementação e adequação da documentação existente, utilização de um software para apoio ao gerenciamento das atividades de evolução e verificação da qualidade dos artefatos produzidos. Essas atividades podem ser classificadas como pertencendo a diferentes estratégias para evolução de software: algumas atividades são enquadradas em manutenção, enquanto outras são consideradas atividades de re-engenharia. Sommerville [SOM00] aponta três dessas estratégias, a saber:

a) manutenção de software: mudanças ocorrem para atender alterações em requisitos, mudança de ambiente e/ou correção de defeitos; a estrutura do software permanece estável

b) transformação estrutural: abordagem mais radical, já que envolve alterações significativas na arquitetura do sistema

c) re-engenharia de software: o sistema é modificado para tornar mais simples e facilitar sua compreensão e manutenção; não costuma ocorrer a adição de novas funcionalidades

Essas estratégias podem ser combinadas, e foi o que ocorreu na evolução do TôSobrando para o CEL: poucas funcionalidades foram adicionadas, a estrutura do sistema não sofreu alterações significativas, e a documentação existente foi complementada e melhorada para facilitar futuras manutenções. A troca do SGBD visou propiciar maior estabilidade, melhor controle de segurança com definição de privilégios e a melhor integração com a linguagem PHP, utilizada na implementação do CEL. As atividades de evolução podem ser visualizadas como continuação do processo de desenvolvimento, com as mesmas fases de especificação, desenho, implementação e validação. O modelo em espiral, conforme mostrado na figura 2 a seguir, é uma boa representação do processo de manutenção. No caso do CEL, as alterações da Release 1 para a Release 2 foram realizadas por equipes completamente distintas; é bastante provável que a próxima equipe a evoluir o CEL também seja composta por desenvolvedores distintos dos anteriores. Isto também acontece nas empresas, onde muitas vezes as atividades de manutenção são vistas como de menor importância que aquelas ligadas ao desenvolvimento e a equipe que efetuou o desenvolvimento passa a integrar um novo projeto.

Figura 2 – Modelo espiral de desenvolvimento Em casos como estes, é de vital importância que os artefatos de software produzidos reflitam todo o trabalho desenvolvido nas etapas do processo de desenvolvimento, e que não seja passado para a equipe seguinte apenas o código do sistema. Também é importante que procedimentos de testes estejam disponíveis, para verificar que alterações para correção de bugs ou mudança de ambiente não tragam novos defeitos ou falhas. A equipe que efetuou a evolução da Release 1 para a Release 2 buscou atender esses aspectos, disponibilizando para a próxima equipe um sistema com melhor qualidade, gerando e/ou corrigindo artefatos tais como mapas destinados à visualização da estrutura do software, cenários e procedimentos de testes.

4.1) Gerencia de Configuração de Software

O Instituto de Engenharia de Software (SEI) publicou vários documentos reconhecidos que revisam e asseguram o estado-da-arte em Gerência de Configuração de Software (GCS), destacando o do Feiler escrito em 1991, que classificou os sistemas GCS básicos em quatro categorias [CON88]. Estas categorias correspondem aos diferentes modos de interação do usuário com um sistema GCS. No modelo de checkout/checkin, são transferidas versões de

Operação

ImplementaçãoEspecificação

Validação

Início

Release 1

Release 2

Release 3

componente individualmente entre repositório e espaço de trabalho. O modelo de composição suporta seleção de versão através de regras e ajuda o usuário a selecionar combinações consistentes de versões de componente. No modelo de transação longa, um usuário conecta a uma transação longa e opera sobre uma versão de configuração. Finalmente, no modelo por mudança, uma configuração é descrita em termos de conjunto de mudanças e cada mudança agrega todas as modificações executadas em resposta a alguma mudança requerida. Um artefato de software (objeto de software) registra o resultado de um desenvolvimento ou de uma atividade de manutenção. Todos os tipos de objetos de software criados ao longo do ciclo de vida do software, incluindo especificações de requisitos, de projeto, de documentação, de código de programa, de planos de teste, de casos de teste, de manuais de usuário, de planos de projeto, etc, devem poder ser manipulados por um sistema GCS. Na disciplina de Evolução de Software pudemos administrar a evolução de um sistema simples e verificar a importância do GCS por meio de uma ferramenta de software livre CVS (Concurrent Version System), que controla as mudanças em produtos de software para apoiar a equipe de desenvolvedores. O CVS registra a composição de versões de produtos de software que evoluem com as revisões e modificações, mantendo consistência entre componentes interdependentes, reconstruindo previamente configurações de software registrados. Podemos dizer que este software pertence ao modelo de GCS denominado modelo de checkout/checkin. A versão é executada com diferentes intenções. Uma versão que pretende substituir sua antecessora é chamada de revisão. As revisões evoluem ao longo do tempo e podem ser criadas por várias razões, por exemplo, para retirar erros, aumentar ou estender funcionalidade, adaptar a mudanças em bibliotecas básicas, etc. Em vez de executar modificações escrevendo elaboradamente, são preservadas revisões anteriores para apoiar manutenção de software entregue a clientes, recuperar atualizações errôneas, etc. No trabalho de evolução do CEL, foram utilizadas duas revisões e múltiplas versões. A revisão rev-1 correspondeu ao conjunto de artefatos recebidos do grupo TôSobrando, incluindo código, cenários, diagramas E-R, etc. A revisão rev-2 corresponde ao conjunto de artefatos modificados e/ou gerados, refletindo o trabalho realizado pelo grupo de Evolução. No CVS também podem ser mantidas versões para suportar cooperação. Neste caso, vários desenvolvedores trabalham em paralelo sobre diferentes versões. Cada desenvolvedor opera em um espaço de trabalho que contém as

versões criadas e utilizadas. Existem políticas de cooperação que regulam quando as versões são exportadas e/ou importadas para uma área de trabalho. No trabalho de evolução do CEL, diferentes versões foram originadas ao longo do processo de evolução, já que a equipe de trabalho utilizava a política de cooperação e de distribuição de tarefas. Uma versão, desta forma, não corresponde necessariamente a uma versão pronta para liberação (ou seja, corresponde a versões intermediárias e pode estar incompleta ou mesmo conter bugs). O ClearCase, assim como o CVS, intercala as versões no grafo de versão. Por meio desta intercalação, as mudanças desempenhadas em um ramo podem ser propagadas para outro ramo. Essencialmente, isto resulta num grafo acíclico orientado. Contudo, os ramos são distintos e cada um deles continua existindo, conforme visualizado na figura a seguir.

Error!

Figura 3 – grafo das diferentes revisões/configurações de um software Uma versão é definida como um estado de um item em evolução. O modelo de versão que focaliza nos estados dos itens versionados é chamado de modelo de versão baseado em estado; versões são descritas em termos de revisões e variantes. Na evolução do TôSobrando para o CEL, utilizamos apenas revisões, não sendo necessária a criação de variantes (o que seria viável de ser feito pelo CVS).

V1

V2

V3

V1

V2

V3

V4

V1

V2

Ramo 1 Ramo 2 Ramo 3

sucessor

Entre ramos

merge

4.2) Qualidade de Software (testes e inspeções) A qualidade de um artefato de software pode ser trabalhada através da utilização de métricas, indicadores ou por meio de testes; no trabalho em desenvolvimento, um dos artefatos recebidos correspondia a uma seqüência de testes, derivada dos cenários da aplicação, que deveriam guiar os procedimentos de verificação da qualidade do TôSobrando. Uma avaliação inicial mostrou que essa seqüência não refletia o estado da implementação; além disto, como foram realizadas diversas mudanças no processo de evolução para o CEL, este artefato teria que ser revisto ou mesmo refeito. Existem diversos objetivos para a realização dos testes. Por exemplo, podemos querer, entre outros, encontrar possíveis desvios com relação à especificação, encontrar falhas e defeitos que comprometam a confiabilidade, verificar a adequação ao uso, encontrar dificuldades de integração considerando um usuário típico, encontrar problemas nas interfaces com equipamentos (por exemplo, impressoras), encontrar problemas de desempenho e de tempo de resposta. Cada um destes objetivos tem seus métodos próprios de formulação de casos de teste e de execução destes testes. Todos estes métodos baseiam-se na formulação dos casos de teste segundo um critério estabelecido, determinação dos resultados esperados, revisão cuidadosa dos casos de teste e dos resultados esperados antes de se realizar os testes, documentação dos resultados dos testes, comparação dos resultados obtidos com os esperados e explicação de todos os problemas encontrados de modo que se possa corrigir ou aprimorar o artefato testado. Testar artefatos é o mesmo que conduzir experimentos controlados, visando identificar possíveis problemas relativos a estes artefatos. Um teste terá alcançado sucesso se foi capaz de identificar um problema, ou seja, identificou uma falha ou defeito. Caso não encontre problemas, o teste nada terá contribuído ao que já sabíamos. Segundo Staa [STA00], testes são técnicas de controle da qualidade baseadas na realização de experimentos controlados. Testes identificam problemas de determinada classe com uma probabilidade, em geral bem menor do que 100%. A probabilidade de encontrar problemas será tão menor quanto menos sistemática for a geração dos casos de teste e quanto menor for o rigor com que os testes forem realizados. Para que um teste possa ser considerado um experimento controlado, devem ser definidos, antes da realização do mesmo, os critérios de geração de

casos de teste e os cenários de teste a serem utilizados. Posteriormente deve ser gerada a massa de teste em acordo com os critérios de teste e os cenários a utilizar e os resultados esperados para cada caso de teste contido na massa de teste. Não saber de antemão quais os resultados esperados torna inútil o teste, uma vez que não se tem como comprovar que o artefato corresponde à sua especificação. Cada vez que um componente ou programa é alterado, seja por motivo de correção, adaptação ou evolução, é necessário retestá-lo. De maneira geral o reteste deve ser completo (teste de regressão). No nosso trabalho de evolução do TôSobrando para o CEL, não realizamos testes sistemáticos. Mas, pensando na necessidade da realização dos testes ser um processo mais controlado, um conjunto de casos de teste começou a ser elaborado. Os casos de teste foram elaborados a partir da descrição dos cenários da aplicação. De cada cenário, foram levados em conta o contexto, os atores, os recursos, os episódios, as restrições e exceções. A princípio foram gerados casos de teste relativos ao cenário e sub-cenários derivados de "Usuário solicita alteração de léxico". A literatura aponta que o processo de inspeção pode detectar de 30% a 90% dos erros existentes nos artefatos gerados num processo de desenvolvimento de software [LAI01]. O processo de inspeção caracteriza-se pela utilização de uma técnica de leitura aplicável a um artefato, buscando a localização de erros ou defeitos no mesmo, segundo um critério pré-estabelecido. A inspeção é aplicável a praticamente todos os tipos de artefatos, sendo possível a utilização de diferentes técnicas de leitura. Das técnicas existentes até o presente, algumas ainda se encontram em estágio de validação e outras já estão integradas à prática empresarial. Dentre estas últimas, colocamos foco nos processos de inspeção baseados em checklists e baseados em perspectivas. O processo de inspeção baseado em prespectivas, ou PBR, caracteriza-se por considerar as diferentes perspectivas (visões) dos atores do processo [BAS00]. Os revisores para o processo são selecionados de acordo com o uso que farão do artefato, por exemplo: usuário final, system designer, representante da equipe de manutenção, testador e outros. Defeitos que podem ser detectados pela PBR:

• ausência de informação (definição de termos, unidades de medida,...)

• informação ambígua (vários significados possíveis para um termo) • informação inconsistente (dois ou mais requisitos em conflito) • fatos incorretos (fato que não pode ser verdadeiro nas condições

especificadas p/ o sistema) • informação desnecessária (pode confundir os usuários) • outros tipos de defeitos (requisito em seção incorreta)

Outra técnica de inspeção, já consolidada na indústria, utiliza a técnica de leitura baseada em checklists. Nesta técnica, os inspetores utilizam uma lista com os ítens a serem verificados; cada artefato tem uma lista específica (Documento de Requisitos, Cenários, Léxico Ampliado da Linguagem). Durante o processo de inspeção, os defeitos são anotados no artefato sendo analisado; após a coleta dos defeitos, é realizada uma reunião onde os problemas encontrados são relatados aos desenvolvedores. Nesta técnica de inspeção, quando aplicada a cenários, podem ser detectados os seguintes tipos de defeitos:

• sintaxe incorreta nos artefatos (definição de termos, unidades de medida...)

• informação inconsistente entre artefatos (cenários, léxicos e requisitos)

• requisitos não funcionais não explicitados • atores e/ou recursos incompletos ou em excesso nos cenários • pré-condições não explicitadas nos cenários • exceções não previstas nos episódios

Consideramos mais adequada ao CEL a utilização da inspeção por checklists; encontramos defeitos sintáticos e semânticos que foram comunicados ao grupo de Evolução e destacados os responsáveis pela correção dos defeitos apontados.

4.3) Mapeamento da Estrutura de Arquivos com Interface para BD

Com o objetivo de auxiliar as equipes de Documentação e Desenvolvimento, o grupo de evolução sugeriu um mapeamento dos arquivos apontando as importações e exportações. Este mapa consiste em fornecer uma visão geral da completude dos arquivos e suas interconexões. A Linguagem de Interconexão de Módulo (MIL) [CAR00] se propõe a descrever a estrutura de sistemas convencionais de software, que focalizam na importação de artefatos para mitigar a necessidade de rescrita de códigos

quando da criação de uma nova aplicação, permitindo que os módulos sejam aglutinados para interfacear com outros. Ela tem finalidade de facilitar o reuso de caixa-preta de classes na construção de aplicações orientadas a objetos. Embasado na MIL, foi realizado uma adaptação para representação da estrutura de arquivos, onde aos objetos correspondem os programas do sistema; também são representados arquivos que correspondem a artefatos como por exemplo logotipo do sistema. O mapa construído mostra a interação entre artefatos, e também as chamadas ao SGBD.

4.4) Léxicos e Cenários O objetivo principal do léxico é a captura do vocabulário da aplicação e sua semântica para auxiliar a compreensão do negócio por parte dos desenvolvedores e a comunicação entre usuários/clientes e desenvolvedores [LEI00]. Também tem o papel de partida inicial para construção dos cenários e de facilitador no processo de descrição e validação do processo. Desta forma, o léxico é uma representação de símbolos na linguagem da aplicação, ou seja, é destinado a facilitar a compreensão da linguagem do problema sem se preocupar com o entendimento do problema em si. O léxico visa registrar palavras ou frases inerentes ao domínio da aplicação. Então, cada entrada no léxico é identificada por um nome (ou nomes em caso de sinônimos) ou frase, e apresenta duas descrições:

• Noção – descreve a denotação do símbolo, o que o símbolo é. Deve expressar em relação a outro símbolo, usando um vocabulário mínimo possível. Sintaxe: sentença = {símbolo | não-símbolo}.

• Impacto – descreve a conotação, como o símbolo atua na aplicação. Sintaxe: sentença = {símbolo | não-símbolo}.

Desta forma, a sintaxe do Léxico pode ser expressa por:

Símbolo Léxico = {Nome}1 +{Noção}1 + {Comportamento}1.

Na elaboração do léxico dois princípios devem ser seguidos: • Princípio da circularidade – maximizar o uso dos símbolos na descrição de

outros símbolos; • Princípio do vocabulário minimal – minimizar o uso de símbolos que são

externos ao léxico.

Após terem sido realizadas as entrevistas preliminares com os usuários/clientes sobre o domínio do negócio para a construção do léxico, constróem-se os cenários com o objetivo de documentar as situações que abrangem o domínio em questão durante o processo de elicitação de requisitos. Assim, os cenários são utilizados para o entendimento da aplicação e suas funcionalidades. Cada cenário descreve uma situação específica da aplicação, concentrando a atenção sobre seus comportamentos. O desenvolvimento de softwares baseados em cenários foca o uso da linguagem do problema (domínio do negócio) do qual o sistema de software a ser projetado se beneficia da interação entre usuários e desenvolvedores.

Um cenário é uma descrição parcial e concreta de um comportamento particular de um sistema em uma determinada situação a ser analisada. Os componentes de um cenário devem expressar todo o contexto, descrição, restrição e/ou exceção (situação singular aplicada a um episódio) de uma atividade de alguma entidade do sistema.

Seus componentes são:

• Título – é o identificador do cenário. Sintaxe: [ator | recurso] + verbo + predicado.

• Objetivo – é a descrição da finalidade do cenário com a descrição de como se alcança esse objetivo. Deve ser concreto e preciso. Sintaxe: [sujeito] + verbo + predicado.

• Contexto – é a descrição do estado inicial do cenário e/ou descrição das pré-condições (restrições) e/ou a localização física ou temporal. Deve conter pelo menos um item (local, tempo ou pré-condição). Sintaxe do estado e localização: substantivo. Sintaxe da restrição: {[ator | recurso] + verbo + predicado}.

• Recursos – identificam as entidades passivas com as quais os autores trabalham, sendo referenciados em pelo menos um dos episódios, ou seja, os recursos devem listar todos os recursos utilizados nos episódios, exceto aqueles utilizados em sub-cenários. Sintaxe: substantivo que pertença ao Léxico. Sintaxe da restrição: {[ator | recurso] + verbo + predicado}.

• Atores – são entidades (sistema, organização ou pessoa), que se envolvem ativamente no cenário e que devem ser referenciadas em pelo menos um dos episódios, ou seja, os atores devem listar todos os atores utilizados nos episódios, exceto aqueles utilizados em sub-cenários. Sintaxe: substantivo que pertença ao Léxico.

• Seqüência de episódios – é uma série de episódios, que devem obedecer a uma ordem temporal e cada um deve representar uma ação realizada por um ator (podendo ter participação com outros atores) e a utilização de recursos. Um episódio pode ser expresso como um sub-cenário e, além disso, devem ocorrer nas restrições impostas pelo contexto. As orações devem ser simples e curtas, contendo apenas um verbo. Os episódios podem ser sentenças simples, condicionais ou opcionais.

Desta forma, a sintaxe do cenário pode ser expressa por:

Cenário = Título + Objetivo + {Contexto + [Restrição]}1 + {Recurso + [Restrição]}1 + {Ator}1 + {Episódio + [Restrição]+ [Exceção]}2.

Um sub-cenário surge quando um comportamento comum aparece em

outros cenários, ou devido a um curso alternativo ou condicional complexo do cenário, ou também, quando é desejado realçar um objetivo preciso e concreto detectado dentro do cenário.

Observa-se que as restrições são usadas para caracterizar requisitos não

funcionais aplicados ao contexto, aos recursos e aos episódios. Um cenário pode ser interrompido por exceções, que são descritas como uma oração simples, especificando a causa da interrupção.

A construção de cenários se baseia em derivar, descrever e organizar.

Estas tarefas podem ser concorrentes, não necessariamente seqüenciais. Já as atividades de verificar e validar podem retornar para uma das três tarefas anteriores, quando houver necessidade de correção que são feitas baseadas na lista de discrepâncias, erros e omissões (DEO).

A lista DEO relaciona todas as discrepâncias, erros e omissões

encontradas durante a tarefa de verificação e validação, onde podem conter sugestões para correção.

Para derivar os cenários é necessário identificar ao atores (substantivos

do léxico), identificar os cenários candidatos e criar os cenários candidatos, fornecendo um título com o verbo no infinitivo se sujeito não for explícito.

Para descrever os cenários realiza-se uma série de novas entrevistas

planejadas com os clientes-usuário, orientadas para o preenchimento dos componentes dos cenários candidatos. Deve-se maximizar o uso de símbolos

léxicos e evitar verbos não pontuais, por exemplo, poderia, deveria, controla, trata.

Organizar os cenários é reorganizar e integrar cenários, produzindo um

conjunto de cenários consistentes e homogêneos. Aqui, deve-se ater a remoção de duplicidades, redução de ambigüidade e detecção de conflitos entre os cenários. Esta tarefa é executada somente quando se tem confiança que o conjunto de cenários esteja bem definido, ou seja, quando a lista DEO estiver vazia. Basicamente reorganizar cenários significa aglutinar dois ou mais cenários em um ou quebrar um cenário em dois ou mais.

A tarefa de verificar cenários ocorre depois de descrevê-los e organizá-

los, quando novos cenários surgem ou são integrados em outros cenários. Nesta fase deve-se verificar a forma sintaxe dos cenários e os relacionamentos entre os componentes, e realizar a análise semântica interna ao cenário. Esta análise verifica, por exemplo, se as pré-condições dos cenários são realizadas antes da ocorrência da situação descrita no cenário, se o nível de detalhamento dos episódios está adequado, se cada episódio do cenário descreve ações equivalentes, se os episódios estão na seqüência correta e se a leitura é de fácil entendimento. Finalmente, analisar a semântica externa entre os cenários, executando a verificação intercenários: a existência de sub-cenários, se as restrições do contexto e do recurso são aplicáveis aos sub-cenários.

A validação dos cenários ocorre quando estes são aprovados pelos

clientes-usuários nas várias entrevistas que se realizam. Os cenários não estão soltos, estão ligados como nós em um hipertexto [BRE00]. Eles se relacionam numa rede de relacionamento com outros cenários.

Um diagrama de relacionamento entre os cenários ajuda a visualização da

estrutura organizacional dos cenários, exibindo o tipo de relacionamento. Pode ocorre que existam cenários que não tenham nenhum relacionamento com os outros demais cenários da aplicação.

Existem sete tipos de relacionamento que são detectados pelo conteúdo

do cenário:

1. Pré-condição – quando um cenário antecessor é obrigatório. 2. Possível precedente – ocorre quando a seqüência de cenários não é

mandatória. Dependendo da situação a seqüência é obrigatória ou não. 3. Equivalente – um cenário é equivalente a outro quando compartilham do

mesmo objetivo e também apresentam coincidência em seus

contextos. Pequenas coincidências nos recursos e grandes entre atores e episódios.

4. Subconjunto – resultante da divisão de um grande cenário numa série de pequenos cenários. Cada cenário encapsula uma parte da ação.

5. Exceção – retrata uma situação especial que foge ao cenário principal. 6. Inclusão – é um relacionamento artificial, resultante da operação M-Split.

Esta operação serve para isolar partes da ação que são comuns a uma série de cenários independentes.

7. Complemento – um cenário é complemento do outro quando participam do mesmo objetivo e também apresentam algumas coincidências em seus contextos e recursos. Podem, ainda, apresentarem coincidência quanto aos atores e apresentar alguns episódios similares.

Repare que se um grupo de cenários compartilham um mesmo objetivo eles

são tanto complementares como atendem a uma abstração maior com mesmo objetivo ou eles lidam com situações similares, como no caso de relacionamento de equivalência.

5) Aprendizado

Neste trabalho aprendemos principalmente sobre a importância do gerenciamento de configuração e de versões num processo de evolução de software. Considerando que o tipo de processo adotado foi o de open source, é de fundamental importância a utilização de uma ferramenta que possibilite o gerenciamento de tarefas sendo realizadas de forma cooperativa e distribuída. Nossa metodologia de trabalho e interação com os outros grupos e membros do projeto se deu apoiada por uma lista de e-mails. Através dessa lista foram realizadas trocas de informação, divulgações de resultados de trabalhos parciais, esclarecimentos de dúvidas, discussões. Esse tipo de metodologia de trabalho está sendo bastante usado depois do advento do software livre. No desenvolvimento do Apache [MOC02], por exemplo, o grupo de desenvolvedores usou exclusivamente listas de e-mails para se comunicar entre si. Por meio dessas listas eram trocados vários tipos de mensagens contendo discussões técnicas, propostas de mudanças do software, notificação automática de mudanças realizadas no código e relatório de problemas. A evolução do CEL foi realizada dentro de um processo semelhante ao desenvolvimento de software livre. Aprendemos que, mesmo nesse tipo de trabalho, onde não existe um processo rígido e controlado, é importante haver o controle da qualidade. Testes e inspeções são técnicas que devem ser empregadas e são bastante úteis para melhorar a qualidade do produto resultante de cada modificação realizada. Podemos ver isso na análise que Mockus, Fielding and Herbsleb fazem do processo de desenvolvimento do Apache [MOC02]. Eles relatam que uma vez identificada uma solução para um determinado problema, o desenvolvedor fazia a mudança numa cópia local do código fonte e testava as mudanças em seu próprio servidor. O nível do teste era comparável a um teste de unidade e dependia principalmente do julgamento e perícia do desenvolvedor. Após esse teste de unidade, as mudanças eram disponibilizadas em uma lista de e-mail para que fossem inspecionadas por outros desenvolvedores. Em geral, mudanças em um release estável requeriam revisão antes que o checkin fosse realizado. Já mudanças no release de desenvolvimento eram inspecionadas após o checkin.

O grupo de Evolução sugeriu a criação do Mapa de Estrutura de Cenários para auxiliar nas atividades de evolução do CEL, principalmente as tarefas sob responsabilidade das equipes de Documentação e Codificação. A criação do mapa ficou a nosso cargo, e durante a execução desta tarefa, identificamos aspectos que indicaram a necessidade de reorganição dos cenários. Isto foi feito com utilização de operações como split e especialização; alguns cenários foram redefinidos, outros integrados, outros especializados. A estrutura de cenários resultante mostrou maior consistência interna e externa, e o mapa gerado reflete adequadamente a organização final dos cenários da aplicação.

6) Bibliografia

[BAS00] Basili, V. et all; "How Perspective-Based Reading can Improve Requirements Inspections"; IEEE, 2000.

[BLA01] Blackburn, Mark R.; Busser, Robert; Nauman, Aaron; "Removing Requirement Defects

and Automating Test", Software Productivity Consortium NFP, 2001. [BRE00] Breitman, K., Leite, J.C.S.P, "Scenario Evolution: a Closer View on Relationships". In

IEEE Computer Society Press, 2000, pages 95-105. [CAR00] Carvalho, S.E.R. & Leite, J.C.S.P. "Model interconnection features in object-oriented

development tools", The Journal of Systems and Software, nº 50, 2000, pag. 57-64. [CON88] Conradi, R. and Westfechtel, B "Version Models For Software Configuration

Management", ACM Computing Surveys, Vo. 30, N. 2, 1988 [FAG86] Fagan, M. E. "Advances in Software Inspections", IEEE Transactions on Software

Engineering, vol. SE-12, nº 7, jul 86, pag. 744-751. [LAI01] Laitenberger, Oliver; "A Survey of Software Inspection Technologies", Handbook on

Software Engineering and Knowledge Engineering, IESE, 2001. [LEH97] Lehman, M. M. "Laws of Software Evolution Revisited" [LEI97] Leite, J.C.S.P, Rossi, G., Balaguer, F., Maiorana, V., "Enhancing a requirements baseline

with scenarios". In Proceedings of the Third IEEE International Symposium on Requirements Engineering – RE97, pages 44-53. IEEE Computer Society Press, January, 1997.

[LEI00] Leite, J.C.S.P, Hadad, G.D.S.,Doorn, J.H. & Kaplan, G.N., "A Scenario Construction

Process". In Springer-Veriag London Limited – Requirements Engineering, pages 38-61, 2000.

[MOC02] Mockus, Fielding and Herbsleb "Two case studies of open source software

development: Apache and Mozilla", TOSEM, V. 11, I. 3, 2002 [OLI01] Oliveira, F. & Copstein, B. "Testes de Software", notas de aula, 2001. [SCA02] Scacchi, Walt "Understanding the Requirements for Developing Open Source Software

Systems", IEE Proceedings--Software, 149(1), 24-39, February 2002. [SOM00] Sommerville, Ian "Software Engineering", 6ª edição. Addison-Wesley, 2000. [STA00] Staa, Arndt. "Programação Modular: Desenvolvendo programas complexos de forma

organizada e segura". Campus, Rio de Janeiro, 2000.

Anexos