116

si.facol.com  · Web viewVariability management in software product lines: a systematic review. ... in critical situations, how ... uma fatia do mercado para garantir destaque internacional

  • Upload
    lyhanh

  • View
    218

  • Download
    0

Embed Size (px)

Citation preview

ISSN 2316-5804

S.I.NFORME

Revista de Tecnologia da Informação do Curso de Sistemas de Informação

Faculdade Escritor Osman da Costa Lins - FACOL

Vitória de Santo Antão, PE – ANO 2, Nº. 2 – dez.2013

S.I.nforme

Publicação anualRevista do Curso de Sistemas de Informação – Bacharelado da Faculdade Escritor Osman da Costa Lins – Facol

Diretor da FACOL:Dr. Paulo Roberto de Leite Arruda

Vice-Diretor da FACOL:Túlio Albuquerque Duarte

Diretor Pedagógico:Prof. Péricles Tavares Austregésilo Filho

Coordenadora Geral Acadêmica:Profª. Nancy Farias Martins Leite

Coordenador do Curso de Sistemas de InformaçãoProf. MSc. Cleyton Mário de Oliveira Rodrigues

Conselho Editorial:Cleyton Mario de Oliveira RodriguesElcias Ferreira da Costa Péricles Tavares Austregésilo FilhoJosé Procópio da SilveiraGleibson Rodrigo Silva de Oliveira

Conselho Científico:Prof. MSc. Cleyton Mário de Oliveira RodriguesProf. MSc. Ryan Ribeiro de AzevedoProfª. MSc. Ana Cristina Freitas CesarStefano ToscanoProfª. Esp. Audrey Bezerra de VasconcelosProf. Esp. Iuri Santos SouzaProfª. Msc. Jailze de Oliveira SantosProfº. Esp. Gleibson Rodrigo Silva de Oliveira

Diagramação:Evandro Bonifácio de Andrade – Departamento de Web Design.

Publicação:Associação Vitoriense de Educação, Ciências e Cultura, entidade mantenedora da Faculdade Escritor Osman da Costa Lins – FACOL.  CNPJ: 03.391.726/0001-90.

Endereço:Rua do Estudante, 85, Bairro Universitário, Vitória de Santo Antão/PE. CEP 55612-650. Tel. (81) 3114-1200 www.facol.com - e-mail: [email protected]

IMPRESSÃO:Luci Artes Gráficas [email protected]

REVISTA DE TECNOLOGIA DA INFORMAÇÃO DO CURSO DE SISTEMAS DE INFORMAÇÃO: S.I.nformeVitória de Santo Antão, PE: Facol, a. 2, n.2 ___. 2013, ____p.

ISSN 2316-5804

SUMÁRIOMetodologia Científica: A carência das Faculdades de Computação...............................3O Uso do Software Clic Adaptado no Processo de Aprendizagem da Escrita do Aluno Cego Congênito.................................................................................................................9Solução DSM para Micro e Pequenas Software House..................................................13Uma proposta de Gerenciamento BPO baseada em análise de mudanças para empresas de software.......................................................................................................................24Assessing Intra-Application Exception Handling Reuse with Aspects...........................37EH-Meter – Uma Ferramenta para Coleta de Métricas de Tratamento de Exceções......53ODST: Uma Ontologia para o Domínio e Estudo das Doenças Sexualmente Transmissíveis.................................................................................................................59Desenvolvimento distribuído de software utilizando Scrum: O estudo de caso do Firescrum.........................................................................................................................65

5

EDITORIAL

6

Metodologia Científica: A carência das Faculdades de Computação

Cleyton Mário de Oliveira Rodrigues

Centro de Informática – Universidade Federal de Pernambuco, (CIn/UFPE) Código Postal 7851 – RECIFE – PE – [email protected]

Resumo. Numa área onde algoritmos funcionando, simulações com resultados e demais atividades práticas é sempre mais bem vista que qualquer outra atividade mais teórica, o uso de metodologias científicas na prática da pesquisa, e no seguimento de padrões é deixado em segundo plano. Neste contexto, observa-se que as faculdades de computação pecam por não utilizar ou não saber como e quando utilizar a disciplina de Metodologia Científica. Na visão dos estudantes (uma visão, sobretudo, incorreta) é uma disciplina que não traz muitos benefícios para a área da Computação. Isto faz com que os alunos e até mesmo os professores percam o entusiasmo em praticar e usar normas da metodologia científica. Como resultado, temos ao final do curso alunos que sabem programar bem, mas não sabem escrever, ou seja, não sabem expressar formalmente suas opiniões, suas idéias. Este artigo visa então esclarecer alguns pontos a respeito dos problemas e impactos do não respeito ao rigor científico, além de algumas idéias sobre como e quando ministrar a disciplina nas faculdades de computação.

1. Introdução É comum na academia avaliar o aprendizado dos alunos através de relatórios ou resenhas científicas, focando em um determinando assunto, ou até mesmo validar e estudar dados de uma pesquisa de campo realizada. Muitos até acreditam que tal prática pedagógica, em certas situações, é mais propícia para avaliar o quanto de informação que o aluno consegue adquirir com relação a um tema ou algum conceito explorado em aula. Evidentemente que o foco principal do trabalho é o valor agregado ao tema de pesquisa. Contudo, nos últimos anos, observa-se que as Instituições de Ensino Superior (IES) incentivam práticas que auxiliem os alunos a desenvolverem seu sensocrítico e a produzirem textos de caráter científico. Alguns trabalhos (http://www.urutagua.uem.br/014/14maia.htm) destacam a importância da disciplina de Metodologia Científica, mas também descrevem a pouca relevância que muitos pesquisadores ainda lhe atribuem.

A área da computação, prática por sua natureza, também sofre pela falta de entusiasmo dos alunos e professores em ministrar essa disciplina. Não há uma porcentagem concreta, mas uma rápida examinada nas grades curriculares dos cursos de computação (Engenharia, Ciências da Computação, Sistemas de Informação e Licenciatura) revela que muitos cursos não possuem nem a disciplina na grade curricular (como na Universidade Estadual de Minas Gerais, CEFET-SP e na PUC-RIO). Mesmo aquelas IES que possuem estas disciplinas, erram por não saber quando aplicar (isto é, no começo, meio, ou no término do curso), ou até mesmo a forma como é ensinada não desperta nos alunos a importância de se escrever com coesão e

7

coerência. Esse fator é grave na área da computação porque nesse meio nota-se certa preocupação pela praticidade, pelo “algo” funcionando, deixando para segundo plano (isto quando há um segundo plano) as normas de regulamentação de uma boa escrita.

2. A importância da Metodologia CientíficaDe forma geral a Metodologia Científica é o estudo dos caminhos do saber, isto é, como se adquire conhecimento. Muitos se enganam ao pensar que a disciplina é de cunho apenas teórico; ao contrário, em seu maior tempo é totalmente prática (pelo menos, deveria ser). Estão a cargo da disciplina, algumas ações fundamentais: (i) como se organiza um relatório ou um trabalho científico, (ii) como é realizada uma pesquisa científica, (iii) como adequar um texto a um padrão, entre outros pontos. Estes serão mais explorados abaixo.

Todo docente já viveu a situação de solicitar um relatório para a turma, como parte da nota, e escutar dos alunos críticas como: “Eu não sei por onde começar a escrever”. Por parte do aluno, umas das primeiras ações a tomar é estruturar o relatório. Estruturar significa dividir em tópicos, capítulos e/ou seções a organização do documento. Quando o assunto é um artigo de pesquisa científica, esta organização já vem pré-configurada, ou seja, os responsáveis pelo evento onde o artigo será submetido já indicam a quantidade mínima e máxima de páginas, além de informar que o artigo, por exemplo, possui uma introdução, com os pontos principais que serão discutidos, e uma conclusão, com o que se aprendeu após o trabalho.

Outra reclamação recorrente dos alunos é que eles não sabem onde procurar e extrair informações relevantes para seu trabalho, ou melhor dizendo, como se realiza uma pesquisa e como identificar as melhores referências. É tarefa do docente mostrar as diferentes formas de pesquisa, e como cada uma pode ser realizada. Também deve ser motivo de estudo saber como analisar dados e como refinar o conteúdo pesquisado para extrair o que é importante para o documento final.

Por fim, a qualidade dos trabalhos entregues falha, não em valor de conteúdo, mas sim como ele foi disposto, isto é, o documento não seguiu as normas de regulamentação. Seguir normas não quer dizer tão somente formatação do texto, mas engloba, sobretudo, outros aspectos mais técnicos. Como exemplo, imaginem que durante uma pesquisa um aluno encontre uma frase bastante pertinente ao seu trabalho. Para evitar cópias indevidas, isto é, o uso desautorizado de textos de outros autores, os alunos devem aprender a fazer citações (de forma direta e indireta). Isto representa apenas um dos vários outros casos que impactam a importância da metodologia científica.

3. ABNTA ABNT se refere à Associação Brasileira de Normas e Técnicas. É uma entidade, sem fins lucrativos, fundada em 1940 para gerenciar a normalização técnica do Brasil. É importante ressaltar que a ABNT está alinhada com os padrões internacionais de normalização, como a ISSO (International Organization For Standardization) e também com o padrão do MERCOSUL – Associação MERCOSUL de Normalização (AMN).

Embora cada IES possa criar seus regimentos internos, normalmente, estes regimentos têm como base as normas da ABNT. Ela atua fortemente no

8

desenvolvimento científico e tecnológico do país, fomentando e promovendo a produção, comercialização e o uso correto de bens e serviços produzidos. A ABNT regula a estruturação e formatação de documentos comuns no ambiente acadêmico, tais como, relatórios, monografias, dissertações e teses.

Este órgão surge então como um grande parceiro das IES. Estas por sua vez, devem apoiar práticas pedagógicas que disseminem seu uso durante a graduação, não só de Computação, mas toda e qualquer formação profissional. Uma forma de se trabalhar isso é através de palestras e mesas redondas, onde aspectos relativos à normalização e pesquisa científica (publicação, patentes) são abertamente discutidos.

O problema da não adequação as normas e aos padrões não é de inteira responsabilidade do corpo discente. Pelo contrário, as IES devem incentivar que o seu corpo docente esteja hábil a avaliar os relatórios e monografias, não apenas com base nos conceitos empregados, mas como eles foram pesquisados e como eles estão sendo exibidos ao leitor. Infelizmente, o que se observa é professores que não estão atentos a estas práticas, e pior, definem muitas vezes um padrão próprio que seus alunos devam seguir.

3. Metodologia Científica: Quando aplicar?Em um curso de graduação de Computação muito se tem questionado quando aplicar a disciplina de Metodologia Científica, isto é, no começo, no meio ou no fim. Cada defensor possui seus argumentos, e alguns destes são listados no que se segue.

Aqueles que defendem que a disciplina seja ministrada no começo do curso têm como suporte a idéia de que todos os trabalhos científicos da graduação realizados dentro das IES devem seguir as normas da ABNT conforme descrito na seção anterior. Essa corrente (se assim pudermos chamar) acredita que o uso constante motiva os alunos a estruturarem seus trabalhos conforme as normas e os regimentos reguladores. Também, ao final do curso, os trabalhos de conclusão (as monografias) serão mais organizadas e estruturadas. Aqueles que motivam o uso mais tardio da disciplina são os que defendem justamente que a proximidade da disciplina com a Monografia será mais produtiva para os alunos, uma vez que eles terão tido contato com as normas mais recentemente. Ainda há aqueles, em menor quantidade, que incentivam que a disciplina seja ministrada no fim do curso.

Uma pequena reflexão e até mesmo uma análise (informal) leva a algumas conclusões esclarecedoras. Inicialmente, deve-se lembrar que as IES estão formando profissionais para o mercado, para a vida, e não apenas para realizar uma monografia de final de curso. Só a partir deste fato, derruba-se a hipótese de que ministrar a disciplina nas proximidades dos trabalhos de conclusão é uma saída. Logicamente que quando mais recente em memória, mais fácil de usar os conceitos. Acontece que o foco do corpo docente não deve ser um aprendizado conseguido por decorar os conceitos, mas sim um aprendizado mais eficiente e longo, obtido através de análises e experiências passadas. Daí, acredita-se que a solução mais adequada seja o uso precoce da disciplina, isto é, nos primeiros períodos da graduação do aluno.

É verdade que algumas argumentações das correntes que pregam o uso tardio das Metodologias Científicas são bem embasadas. Um destes argumentos se respalda no fato do esquecimento das normas quando ensinadas no início do curso. Contudo, essa hipótese também pode ser derrubada com a seguinte contra-argumentação: se todos os

9

profissionais das IES incentivam o uso em todas as disciplinas das normas técnicas da ABNT, os conceitos não estarão fadados ao esquecimento. Pelo contrário, o uso exaustivo fará com que os alunos aprendam pela experiência, e um conhecimento obtido segundo estes moldes é bem mais difícil de perder.

4. ImpactosNa academia, a falta de uma disciplina de Metodologia Científica traz fortes impactos negativos aos alunos e, como conseqüência, as IES. É comum que os alunos terminem uma graduação sem ao menos publicar um artigo em algum congresso. O que não é tão perceptível é que a falta da disciplina na grade gera um desestímulo perante aos alunos para que eles possam tentar publicar alguma idéia nova ou algum conceito revisto sob outra perspectiva. Daí explica-se o nível tão baixo de publicações na graduação.

Outro impacto negativo é com relação à Monografia. Normalmente, as IES empregam nos últimos períodos uma disciplina voltada à escrita de um trabalho final para a conclusão do curso. Acontece que as próprias IES não dão o subsídio para que os trabalhos sejam bem formulados. Na prática, os trabalhos finais falham sob diversos pontos, como: estrutura, viabilidade da idéia, falta de padrão, cópias, entre outros pontos.

Mais grave ainda, é que estes alunos saem da graduação com uma fraca teoria sobre como escrever trabalhos científicos. No mercado, estas falhas surgem como uma deficiência do profissional, levando a conclusão que as IES não estão cumprindo bem seu papel de formação de mão-de-obra eficiente e produtiva.

5. Iniciação Científica: Uma saída complementarAlém do emprego correto e eficiente da disciplina nas grades curriculares dos cursos de graduação, uma segunda alternativa que pode ser tomada como complementação é difundir a Iniciação Científica (I.C.). Defini-se I.C. como uma prática de formação, onde o aluno desenvolve e aprimora seu lado técnico. Note que o termo “iniciação” indica que o aluno está sendo “iniciado” como pesquisador acadêmico e, por isso, não se pode comparar o valor de qualidade de um trabalho de I.C., como outros trabalhos de pesquisa mais avançados, como uma dissertação de mestrado, ou até mesmo uma tese de doutorado. Formalmente falando, a I.C. é uma atividade constante realizada pelas IES, podendo ser financiada por instituições de pesquisa como CAPES, CNPq, órgãos estaduais (como FACEPE) ou até programas internos das IES (PIBIC – Programa Institucional de Bolsas de Iniciação Científica). Normalmente, os alunos contam com o apoio de um orientador, o qual geralmente é um professor da IES.

Durante o período de I.C., é posto em prática todo o arcabouço de tarefas definido pela metodologia científica: o aluno aprende a pesquisar, a escrever, a respeitar padrões e a refinar referências bibliográficas. Evidentemente que a realidade brasileira das IES (públicas ou particulares) não permite que todos os alunos possam receber uma bolsa auxílio. Assim, ocorre que apenas um número reduzido de alunos tem acesso a I.C.

Para conciliar e difundir as práticas de I.C. a todo o corpo discente, requer inicialmente uma mudança de atitude. As IES devem apoiar a iniciação à pesquisa, mesmo sem auxílio financeiro. Uma forma de se fazer isso é alterar as grades curriculares para incluir uma disciplina de “Práticas de Iniciação Científica”.

10

Dependendo da duração do curso e da disponibilidade de orientadores, esta disciplina pode ser realizada em um ou dois períodos. Logicamente que a disciplina de Metodologia seria tomada como pré-requisito desta cadeira de prática. Nesta, os alunos escolheriam um tema de pesquisa de interesse, e desenvolveriam ao longo da disciplina um projeto de desenvolvimento. Como medida de avaliação de desempenho, todos os alunos deveriam submeter o projeto em alguma revista científica, ou algum congresso pertinente. Também, ao término do curso, este projeto poderia ser expandido até tomar o aspecto de uma monografia de final de curso, alavancando a qualidade destes trabalhos.

6. ConcluindoOs problemas destacados neste artigo não são exclusivos das IES de computação, mas também podem ser facilmente diagnosticados neste campo. O uso de disciplinas que estimulem os alunos a pesquisar, redigir redações e relatórios científicos deve ser incentivado. A produção intelectual das IES brasileiras é relativamente baixa quando comparada com outros países de primeiro mundo, ou até em desenvolvimento. Há uma cultura de se esperar que o aluno ingresse em uma pós-graduação para que possam ser cobrados artigos científicos. Contudo, é na graduação que deve ser despertado o interesse pela pesquisa, pela leitura, e a redação de novas idéias.

Muitas IES falham por não saber quando aplicar a disciplina de Metodologia Científica. Conforme descrito no texto, é necessário que esta disciplina esteja presente nos primeiros períodos da graduação. Mas para que ela possa ser bem aproveitada, deve haver um alinhamento estratégico entre coordenação, corpo docente e corpo discente. Os professores precisam ser capacitados a explorar do aluno sua veia de pesquisador, seja em qualquer outra disciplina da graduação. Isto é, não se deve esperar pela monografia para que os alunos ponham em prática tudo aquilo que foi visto com respeito a padrões e normas de escrita.

A adoção de uma nova disciplina “Prática em Iniciação Científica” (dividida em um ou mais módulos) incentivaria os alunos a praticar todos os conceitos vistos na cadeira de metodologia. Esta nova disciplina ajudaria a solucionar alguns dos problemas destacados ao longo deste artigo, como: a carência da pesquisa, o baixo nível de publicações científicas, e a qualidade das monografias do curso.

É necessário que haja uma conscientização que um dos papéis fundamentais da IES é fornecer mão-de-obra qualificada para o mercado e para a sociedade. Ser qualificado não se restringe, contudo, ser um bom desenvolvedor ou testador de sistemas, mas também saber se expressar, tanto verbalmente, como na forma escrita.

RecursosABNT – Associação Brasileira de Normas e Técnicas – http://www.abnt.org.br/

AMN – Associação MERCOSUL de Normalização – http://www.amn.org.br/

CAPES – Coordenação de Aperfeiçoamento de Pessoal de Nível Superior –http://www.capes.gov.br/

CNPq – Conselho Nacional de Desenvolvimento Científico e Tecnológico – http://www.cnpq.br/

11

FACEPE – Fundação de Amparo à Ciência e Tecnologia do Estado de Pernambuco –http://www.facepe.br/

ISO – International Organization For Standardization – http://www.iso.org

MAIA, R. T. (2008) A importância da disciplina de metodologia científica no desenvolvimento de produções acadêmicas de qualidade no nível superior – Revista Urutágua. Maringá, Paraná, Brasil. ISSN 1519.6178. Disponível em http://www.urutagua.uem.br/014/14maia.htm

CEFET-SP - http://www.cefetsp.br/edu/gru/GradeCurricularInformatica.html

PUC/RIO - http://www.puc-rio.br/ensinopesq/ccg/eng_computacao.html#periodo_1

UEMG - http://www.ituiutaba.uemg.br/ec/site/gradeec.pdf

12

O Uso do Software Clic Adaptado no Processo de Aprendizagem da Escrita do Aluno Cego Congênito

Christiane de Melo Cabral1, Cleyton Mário de Oliveira Rodrigues1,2

1FACOL – Faculdade Osman da Costa Lins – Vitória de Santo Antão – PE - Brasil2Centro de Informática – Universidade Federal de Pernambuco – CIn-UFPE, Brasil

[email protected], [email protected]

Abstract. This article contains information about the use of free software as a resource to support learning in a congenitally blind student. The main objective is to investigate the contribution of the Click software tailored to the learning process of writing in the 3rd. Series (4th. year) of the elementar school. Through feedback, the software provides opportunities for student learning in spelling activity. Furthermore, this application may have its use improved and expanded, in writing and other content studied by the blind student.

Resumo. Este artigo apresenta informações quanto ao uso de um software gratuito como recurso de apoio na aprendizagem de um aluno cego congênito. O objetivo principal é investigar a contribuição do software Clic adaptado no processo de aprendizagem da escrita, na 3ª. Série (4º. Ano) do ensino fundamental. Por intermédio do feedback, o software traz possibilidades de aprendizado para o aluno na execução da atividade ortográfica. Ademais, este aplicativo pode ter o seu uso aperfeiçoado e ampliado, na aprendizagem da escrita e demais conteúdos estudados pelo aluno cego.

1. Introdução Os softwares em geral são ricos em imagens e sons, porém muitas vezes esses sons não descrevem o que está na tela do computador. A escolha desse tema surgiu a partir de análises de softwares educacionais feitos em sala de aula do curso de especialização em Informática Educacional. Na apresentação do software Clic, observou-se as possibilidades de gravação de sons, e personalização das atividades para os alunos cegos, que geralmente ficam fora das atividades tecnológicas educacionais que priorizam a imagem. A figura 1 ilustra um exemplo de tela ao se trabalhar com a letra “S”.

Num ambiente de sala de aula, o aluno cego escreve em Braille palavras e frases ora ditadas pela professora, ora por um colega da turma, que em sua maioria soletra as palavras, evitando assim que este aluno cometa seus próprios erros ortográficos. Ocorre que, desta forma, o aluno sequer pensa na maneira como é escrita a palavra, tornando sua escrita uma mera repetição de letras transcritas para o código Braille.

A adaptação desse software na criação de uma seqüência didática como reforço numa sala de atendimento especializado (SAE), com o apoio sistemático do professor itinerante, permite contribuir para o desenvolvimento da escrita deste aluno. Além do mais, o Clic pode ser adaptado com recursos de uso de sons variados em cada atividade apresentada, o que torna prazeroso e eficaz o aprendizado. Os recursos de sons, com descrição da atividade que aparece na tela do software Clic adaptado, diminuem as

13

barreiras de comunicação do aluno cego na sua interação com a atividade descrita utilizando o programa. Caminhar com o aluno cego congênito no campo da educação informatizada, em uma perspectiva de educação inclusiva leva à avaliação de elementos importantes na criação de uma nova ordem educacional.

Este trabalho está organizado como se segue. Na seção 2 será explicado o objetivo geral da pesquisa, bem como os objetivos mais específicos. Já a seção 3 detalha a metodologia utilizada para conduzir esta pesquisa, sendo que os resultados alcançados são conseqüentemente discutidos na seção seguinte. Por fim, a seção 5 discute as conclusões alcançadas ao longo deste trabalho.

Figura 1: Exemplo de Tela do Clic para aluno cego.

2. Objetivos No objetivo geral procurou-se investigar a contribuição do uso de um ambiente informatizado no processo de ensino e aprendizagem de conceitos científicos por alunos com cegueira congênita. Os objetivos específicos, por sua vez, trataram de: sensibilizar a escola quanto à importância do uso do computador pelos alunos com cegueira congênita para a construção de conceitos científicos; investigar a ação de alunos com cegueira congênita e professores itinerantes em ambientes informatizados, a fim de verificar seu benefício para o ensino e a aprendizagem de conceitos diversos e analisar o uso de software educacional voltado para o ensino como suporte facilitador do processo de ensino e aprendizagem de conteúdos científicos com alunos com cegueira congênita.

3. MetodologiaInicialmente, a técnica de coleta de dados utilizada foi à observação participante. O sujeito desta pesquisa é um aluno cego congênito que se encontra na 3ª. Série (4º. Ano) de uma escola pública. Em um segundo momento as observações foram realizadas na SAE. Foi construída uma seqüência didática e análise de sua aplicação, de forma a permitir uma interação entre o aluno e a pesquisadora na aprendizagem da escrita,

14

particularmente na ortografia. A aplicação do Clic fundamentou-se em Manzini e Santos (2002 apud MANZINI, 2005, p. 180), que descreve sete passos necessários para a adaptação de um recurso pedagógico; dos quais os seguintes foram utilizados: entender a situação que envolve o estudante; gerar idéias; conversar com o estudante e os colegas; escolher a alternativa viável; construir o objeto para experimentação e avaliar o uso do objeto.

Com a ajuda de uma profissional de informática, especialista em softwares educacionais, optou-se pelo software Clic que melhor se adaptou às necessidades educacionais do aluno cego. A partir daí foi elaborada uma situação didática contendo uma seqüência de palavras, para a memorização do aluno sobre o uso correto da escrita da língua portuguesa. Criamos uma situação envolvendo os conhecimentos ensinados em sala de aula, pelo professor regente. Em seguida, foi possível construir uma resposta favorável da seqüência didática na SAE, utilizando o computador como apoio e a pesquisadora como mediadora do processo. Para a seleção dos alunos, foram usados os seguintes critérios: ser uma criança cega congênita, estar incluído na sala de aula regular, ser alfabetizada na escrita do código Braille, utilizar com freqüência a máquina Braille, ter apoio na escola de uma SAE e ter apoio de um professor itinerante ou especializado.

A elaboração do software adaptado seguiu as seguintes etapas, interdependentes com os sujeitos da pesquisa, sendo esta caracterizada nas seguintes ações: escolha planejamento do software; desenvolvimento do software Clic adaptado e suas aplicações na aprendizagem ortográfica. Foram dadas as devidas orientações básicas sobre a execução da atividade, levando em consideração os conhecimentos prévios do aluno cego necessário para a compreensão do conteúdo trabalhado.

4. ResultadosNesta pesquisa, ao usar o tipo de software de exercício-e-prática com o aluno cego, acompanhamos mais de perto as dificuldades do aluno na aprendizagem da escrita das palavras. Ficou claro que a abordagem do software utilizado é de cunho Behaviorista. No entanto, especificamente neste caso, a mediação proporcionou uma interação entre o aluno e o software identificando em algumas fases do processo, uma postura construtivista, que favoreceu a aprendizagem da escrita. Caracterizando o que Vygostsky chamou de "zona de desenvolvimento potencial ou proximal" de acordo com [Rego 2000, p. 138].

No final da atividade utilizando o software personalizado, concluímos que o uso do computador contribuiu de forma positiva no processo de ensino e aprendizagem da escrita, pois, o aluno demonstrou maior nível de participação, interesse e motivação para executar o trabalho proposto, superando sua dificuldade na escrita de palavras anteriormente difíceis para ele. Entendendo escrita [Ferreiro 1992, p. 79] quando enfatiza a produção da língua escrita. Fazendo uma comparação entre o uso da máquina Braille e o computador, solicitamos ao aluno cego que realizasse a atividade com o uso da máquina Braille, antes do uso do computador, na SAE, porém, ele não apresentou os mesmos resultados. Utilizando o computador o aluno podia refazer, com facilidade, a atividade, mesmo que não conseguisse durante a primeira tentativa, o que possibilitou um melhor aproveitamento do tempo disponível. O aluno cego, ao trabalhar com este tipo de recurso sentiu-se mais independente, motivado e até mesmo sua auto-estima

15

parece ter melhorado, pois o aluno percebeu-se refletindo sobre sua produção escrita e na sua capacidade de utilizar o computador. Como enfoca [Valente, 2007] alguns alunos se beneficiam de novas concepções de ensino e aprendizagem.

5. ConclusõesA pesquisa apontou que, a escolha do software permitiu ao aluno cego autonomia ao utilizar o computador. O software Clic, adaptado como tecnologia assistiva, possibilitou acessibilidade ao computador, ajudando no desenvolvimento das habilidades sensoriais auditivas e cognitivas, inclusive, de escrita e leitura. Enfim, podemos incluir digitalmente os alunos cegos congênitos no ambiente digital escolar.

ReferênciasBersch, R. and Shirmer, C. (2005) “Tecnologia Assistiva no Processo Educacional. ”

Ensaios Pedagógicos. Construindo Escolas Inclusivas. Brasília: MEC, SEESP.

Caiado, K. R. M. (2003) “Aluno Deficiente Visual na Escola. ” Campinas, São Paulo: Autores Associados.

Ferreiro, E. (1992) “Com Todas as Letras. ” São Paulo: Cortez, vol. 2. 7.

Freire, P. (1996) “Pedagogia da Autonomia. ” 35 ed. São Paulo: Paz e Terra.

Lima, S. M. C. C. (2005) “A SUESP hoje: realizando e tencionando ensaios pedagógicos. ” Construindo Escolas Inclusivas. Brasília: MEC, SEESP.

Machado, O. T. M. (2004) “Educação para a Diversidade. ” Conhecimento Local e Conhecimento Universal: diversidade, mídias e tecnologia na educação. Curitiba: Champagnat.

Manzini, E. J. (2005) “Tecnologia Assistiva para a Educação: Recursos Pedagógicos Adaptados. ” Ensaios Pedagógicos. Construindo Escolas Inclusivas. Brasília: MEC, SEESP.

Rego, T. C. (2000) “Vygotsky, uma Perspectiva Histórico-Cultural da Educação. ” 8 ed. Petrópolis: Editora Vozes.

Santos, M. M. M. (2005) “As Experiências de Inclusão Educacional nas Escolas da Rede Municipal do Recife/PE. ” Ensaios Pedagógicos. Construído Escolas Inclusivas. Brasília; MEC/SEESP.

Valente, J. A. A. (2007) “Diferentes Usos do Computador” Disponível em: <http://www.educacaopublica.rj.gob.br/biblioteca/educação/edu2007.ghtm> Acesso em: julho.

16

Solução DSM para Micro e Pequenas Software House

Luiz Carlos d’Oleron1,2, Cleyton Mário de Oliveira Rodrigues1,2, Gleibson Oliveira1,2, Lúcio santos1,2

1Centro de Informática – Universidade Federal de Pernambuco (CIn/UFPE) P.O. Box 7851 – Recife – PE - Brasil

2Improvess, Avenida Governador Carlos de Lima Cavalcante, 421 Olinda– PE–Brasil.{lcadb, cmor, grso, ljfs}@cin.ufpe.br

Abstract. Software engineering always sought techniques to leverage productivity for Product Lines, removing from the end-developer the hard task to program the entire solution. A model-centric, domain-based software development (Domain Specific Modeling, DSM) fits well this scenario: taking models as primary artifacts is the key business to keep model and code synchronized throughout the project. This paper therefore discusses the benefits that can be achieved by micro and small software product line enterprises when incorporating within the organizational environment a software development guided by domain-specific models. Further, a simulation for an integrated solution for inventory management will be discussed.

Resumo. A Engenharia de Software sempre buscou técnicas para alavancar a produtividade para linhas de produto, removendo do desenvolvedor a árdua tarefa de programar toda a solução final. Um desenvolvimento baseado em modelos de domínio da aplicação se encaixa bem neste cenário: tomar modelos como artefatos primários é a chave do negócio para mantê-los sincronizados com o código ao longo do projeto. Este artigo, portanto, discute os benefícios que podem ser alcançados por micro e pequenas empresas que trabalham em linhas de produtos de software, ao incorporar dentro do ambiente organizacional um desenvolvimento de software orientado por modelos de domínio. Além disso, uma simulação para uma solução integrada de gestão de estoques será discutida.

1. IntroduçãoA crise financeira que abalou o cenário macroeconômico mundial, entre os anos de 2008 e 2009, paradoxalmente, revelou uma forte tendência para investir em mercados emergentes. No pós-crise que se seguiu, a retomada do crescimento econômico experimentado por este seleto grupo de países emergentes, chamou a atenção de todo o mercado internacional, incluindo o mercado de tecnologia da informação e produção de software. Dentro deste contexto, a América Latina e especialmente o Brasil está emergindo como o carro-chefe na nas vendas de software e serviços [Gandra]. Micro e pequenas empresas, juntas, representam a maior parte das indústrias de software.

Não obstante, para continuar (ou voltar) a crescer em ritmo acelerado é importante que estas continuem a ser maduras o suficiente para competir no mercado. Tempo de entrega de um produto no mercado (time-to-market), produtividade, custos e qualidade continuam a ser fortes parâmetros para manter ou remover uma empresa no mercado de software.

17

A Indústria de Software tem sido alvo de constantes transformações tanto metodológicas, como tecnológicas, tais como o surgimento de novas IDE (Integrated Development Environment) e ferramentas CASE (Computer-Aided Software Engineering), focando sempre na produtividade, qualidade, reusabilidade, interoperabilidade, além de eliminar redundâncias e inconsistências, e também, promover a entrega rápida de produtos e/ou serviços, a um baixo custo. Uma das experiências mais recentes é remover do programador final todo o árduo trabalho da construção da solução final, a qual era baseada quase que exclusivamente em sua própria interpretação do problema, e na sua experiência em programação.

Nesse novo roteiro [Stahl and Völter 2006], os modelos estão assumindo o papel de “principal artefato”. Em um nível abstrato, a solução do problema é modelada a partir das entidades presentes no domínio da aplicação, e, sistematicamente, este modelo é refinado em direção a uma plataforma de desenvolvimento (Java, .Net, por exemplo). O modelo original, portanto, é passível de ser reutilizado para a mesma aplicação, porém visando diferentes plataformas, ou até mesmo ser estendido para aplicações diferentes.

Dentro do contexto de Software Product Line (SPL) [Software Engineering Institute 2010], onde produtos dentro de uma mesma família compartilham parcialmente algumas peculiaridades (arquitetura, features, casos de testes), o uso de modelos de domínio favorece a reusabilidade e, consequentemente, produtividade e baixo custo de desenvolvimento. Assim, este artigo explora os benefícios tangíveis que podem ser alcançados pelo uso de uma solução DSM dentro de uma família de produtos de software. Também, ao final do artigo é exibido um pequeno estudo de caso, utilizando ferramentas gratuitas e disponíveis na Web, tornando a solução compatível com a realidade das micro e pequenas empresas de software.

Este artigo está organizado como se segue. Na seção 2 será discutido o cenário atual financeiro das micro e pequenas software house, bem como o cenário metodológico, isto é, as abordagens que existem e tratam o problema em discussão neste artigo. Já na seção 3é discutido o estado da arte de soluções de engenharia de software dirigida por modelos. Na Seção 4 apresentamos a solução DSM através de um conjunto de 5 atividades, bem como identificamos os benefícios advindos do uso desta solução. Por fim, as seções 5 e 6 tratam de um estudo de caso, instanciando estas atividades e das conclusões acerca do trabalho, como também as perspectivas para trabalhos futuros, respectivamente.

2. Cenário AtualEsta seção faz uma correlação entre dois aspectos que tangem as software-house, o cenário financeiro e o cenário metodológico. Enquanto, por um lado, explora como as empresas de desenvolvimento de software (em particular, as micro e pequenas) estão se comportando face à grande demanda do mercado, por outro, destacamos as ferramentas, processos e metodologias disponíveis na literatura que podem ser utilizadas como subsídio ferramental para aprimorar o desenvolvimento de sistemas baseado em modelos de domínio.

18

Figura 1: Taxa de crescimento no mercado Brasileiro (em Bilhões) [ABES 2010].

2.1. Cenário Financeiro

De acordo com a ABES [ABES 2009], o mercado brasileiro de software movimentou mais U$ 15 bilhões em 2009 e 2010, mantendo um crescimento constante [ABES 2010], em relação aos últimos anos, figura 1. Estima-se uma movimentação de mercado em 2012 em cerca de U$ 20,2 bilhões e uma projeção de 24% no número de empresas atuantes no segmento, fornecendo indicadores de crescimento da demanda de software no país. Do total movimentado em 2009, cerca de U$ 4,35 bilhões foram com desenvolvimento de software, sendo U$ 1,12 bilhões a movimentação relacionada a softwares customizáveis provenientes de software-houses, representando perto de 35% da demanda de desenvolvimento de software.

O crescimento do mercado da Tecnologia da Informação (T.I.) reflete o aumento da demanda por software e a constante necessidade de investimento, com foco na competitividade das empresas. Além do mais, o aumento da demanda por serviços e produtos de T.I. leva ao aumento da competitividade no setor, fomentando novos entrantes no mercado e a necessidade de aperfeiçoamento da eficiência e competitividade empresarial de tais empresas.

Todavia, o processo de produção da grande maioria das software-houses em mercados como o brasileiro não suporta o aumento crescente da demanda. A incapacidade operacional de fabricação entra em conflito com os resultados comerciais conquistados, gerando cenários onde as empresas vendem muito, mas não tem fôlego para atender às demandas vendidas [SOFTEX 2009]. Em particular, as software-houses possuem, em geral, um processo de fabricação mais próximo do artesanal (onde cada produto exige um grande grau de personalização manual para um cliente) do que industrial (onde produtos são gerados em linhas de produção, mas mesmo assim, atendem às necessidades específicas de cada cliente).

2.2. Cenário Metodológico

Linhas de Produtos de Software (em inglês Software Product Line, SPL) - um conjunto de sistemas de software que satisfaz as necessidades específicas de um segmento

19

específico do mercado [Software Engineering Institute 2010] - é uma abordagem de desenvolvimento comumente aplicada para produção de uma ampla gama de produtos. A partir de requisitos de um domínio específico, SPL advoga que estes sejam refinados até um produto alvo; esta abordagem, por natureza, incorpora e elava o reuso em uma família de produtos similares, uma vez que a partir do mesmo conjunto de requisitos iniciais, uma linha de produtos pode ser desenvolvida. Neste contexto, SPL introduz métodos de análise de Variabilidade, para identificar dentre estes requisitos, aqueles que são obrigatórios, alternativos ou opcionais; a diversidade de produtos de uma família dar-se-á a partir desta configuração.

Em termos gerais, a Análise de Variabilidade contempla a definição do escopo, semelhanças e pontos de variabilidades entre produtos de software de uma determinada família [Myllymäki 2001] [Coplien et al. 1998]. A identificação pode ser realizada em nível de componentes, arquitetural, de artefatos e até mesmo em casos de testes [Chen et al. 2009]. Variabilidade pode ser definida como “[...] a capacidade de um ativo se adaptar em contextos de produtos diferentes que estão no escopo da mesma linha de produtos” [Bachmann e Clements 2005]. Dentre os métodos mais utilizados para se realizar análise de variabilidade, destaca-se o FODA - Feature Oriented Domain Analysis [Kang et al. 1990], o qual pode ser delineado em três passos consecutivos: (I) Análise de Domínio, (II) Extração dos pontos comuns e variáveis, e (III) Refinamento do modelo em diferentes aplicações.

Recentes estudados na literatura discutem uma visão multidisciplinar, ao incorporar Engenharia Dirigida por Modelos (em inglês Model-Driven Development, MDD) como um processo inerente à SPL. Em particular, explora-se o uso de modelos específicos de domínio (em inglês Domain Specific Modeling, DSM) ao invés de modelos de propósito geral, uma vez que, os primeiros podem ser mais expressivos e mais coerentes com o domínio que se deseja modelar [Kelly e Tolvanen 2008], [White et al. 2009].

3. MDD e DSMDesenvolvimento dirigido por modelos, (em inglês Model Driven Development, MDD) um paradigma de desenvolvimento onde os modelos (gráficos e/ou textuais) não são meros artefatos utilizados informalmente. Pelo contrário, esta abordagem surgiu para fechar a lacuna entre a solução, especificada por modelos com um alto nível de abstração e o código fonte final da aplicação. Elevando o nível de abstração da solução, independente de qualquer plataforma subjacente de codificação, é possível ganhar mais em termos de reutilização e produtividade.

De acordo com [Stahl e Völter 2006], MDD introduz vários outros benefícios tais como: velocidade de desenvolvimento, qualidade do software, facilidade no gerenciamento de mudanças tecnológicas, entre outros pontos. Diversos estudos na literatura [Kelly e Tolvanen 2008], [Tolvanen 2004], [Kärnä 2009] apontam que o desenvolvimento baseado em modelo não é mais um mito, e sim uma realidade já presente em muitos projetos nas empresas de desenvolvimento de software.

Em [Atkinson e Kuhne 2003], os autores definem a infra-estrutura de MDD como sendo formada de conceitos, regras e restrições, além de uma notação formal para a definição de modelos expressivos, adaptáveis e abstratos. Esta infra-estrutura também

20

deve prover meios que permitam a troca de modelos entre plataformas distintas, além de geradores de código inteligentes.

Figura 2: Atividades para Solução DSM

À Luz deste novo contexto de desenvolvimento, a Modelagem específica de Domínio (DSM) surge como uma solução de duas vias: “Em primeiro lugar, eleva o nível de abstração além da programação, especificando a solução em uma linguagem que usa diretamente conceitos e regras de um determinado problema de domínio. Segundo, gera produtos finais em uma linguagem de programação escolhida ou em outra forma, a partir dessas especificações de alto nível” [Kelly e Tolvanen 2008].

4. Solução DSMNo intuito de explorar os benefícios advindos do uso de soluções DSM dentro do contexto de SPL, definimos neste artigo, um conjunto de 5 atividades para guiar o desenvolvimento de aplicações. A figura 2 ilustra estes cinco passos.

4.1. Análise de Domínio

O analista, durante a análise de domínio, depende de variáveis como sua experiência, percepção, além de necessitar de participação ativa do cliente, para delimitar bem o escopo da aplicação. Nesta fase, as entidades do domínio e das regras de negócio da aplicação são definidas. Também, os relacionamentos entre estas entidades são gerados e, a partir destes, as entidades passam a ser classificadas com entidades fracas, ou entidades fortes. Para se obter mais exatidão na modelagem do domínio, documentações disponíveis produtos pertencentes à mesma SPL da aplicação original são recolhidos para análise. Ao final, se faz necessário a confecção de um relatório listando todos os artefatos, cenários, requisitos discutidos ao longo desta fase.

4.2. Análise de Variabilidade

Conforme discutido anteriormente, analisando as entidades em comuns e, consequentemente, as entidades obrigatórias e opcionais entre os produtos dentro de um SPL, pode- se definir o nível de variabilidade para uma família de produtos. Tomando como ponto de partida o documento da análise de domínio criado anteriormente, e através do modelo FODA, pode-se definir visualmente, ou através de uma estrutura de árvore, todas as entidades, bem como os relacionamentos entre estas, deixando claro o que é obrigatório, opcional ou alternativo. Após esta fase, o modelo criado é a base de todas as possíveis configurações, isto é, para cada aplicação este modelo será sistematicamente refinado, até que a aplicação na plataforma alvo seja alcançada. Vale salientar que, a cada transformação imposta no modelo, este tornará cada vez menos abstrato e, portanto, menos reusável.

4.3. Definição da Linguagem

Dando continuidade, a próxima atividade corresponde à criação da Linguagem. Baseado no modelo FODA, é possível agora analisar quais as entidades que estarão disponíveis para o usuário, além de definir as customizações necessárias para estas. É nesta fase que

21

restrições relativas ao domínio são criadas. Para tal, a linguagem é especificada através de um metamodelo. Usualmente escritos em UML (Unified Modeling Language)1, estes metamodelos descrevem abstratamente a sintaxe da Linguagem. Esta fase possibilita verificações sintáticas na definição da DSM, proibindo que configurações inválidas sejam criadas.

4.4. Criação da Ferramenta Gráfica

Para que o cliente possa criar, sem maiores dificuldades, sua DSM, a quarta fase visa à criação de uma ferramenta gráfica construída sobre o metamodelo. Neste sentido, um Modelo Gráfico é criado, onde cada entidade passa a ter uma representação visual. É nesta fase também, que ligações semânticas entre o metamodelo e o modelo gráfico são criadas. Portanto, o que é válido no metamodelo será válido no modelo gráfico e precisa ser mantido. Além do mais, podem-se construir paletas para auxiliar o usuário final na criação da DSM. Mensagens de alerta e de erro também são customizadas. Por exemplo, se existe uma ligação mandatória entre duas entidades no metamodelo, e se, ao construir a DSM, esta ligação não for representada, caberá a ferramenta informar que existe o erro.

4.5. Criação do Gerador de Código

A automação completa da geração do código final, a partir de modelos de domínio não é totalmente possível, pois para se construir a aplicação final é necessário antes definir o gerador de código. Neste, os templates que definem a estrutura do código fonte são criados. Além disso, é possível também criar otimizações, deixando-o mais acessível para futuras (e inevitáveis) manutenções. Como será observado no estudo de caso, esta atividade é a mais demorada dentre as cinco, uma vez que requer mais cuidados devido à intervenção humana. Em certas ocasiões, o gerador de código pode tornar-se o gargalo da solução DSM, e a tarefa de programar a solução final no desenvolvimento radicional, pode ser refletido na tarefa de se programar o gerador de código. Assim, é preciso tomar cuidados extras para que esse possa ser expansível, simples, mas não deixando de ser completo.

4.6. Benefícios da Solução

A partir da solução DSM descrita acima, podemos listar os benefícios diretos obtidos pelo uso de Modelos de Domínio em dois grandes subconjuntos: produtividade e qualidade:

Com relação à Produtividade:

Menor Tempo na Entregado do Produto, e esse tempo tende a diminuir a cada novo produto, pois a reusabilidade aumenta;

Rapidez no feedback para o usuário, uma vez que a análise pode ser feita em nível de modelo (mais abstrato) sem riscos deste não estar sincronizados com o código;

Baixo custo no desenvolvimento, pois há ferramentas disponíveis para auxiliar as fases da solução DSM;

1 http://www.uml.org/

22

Fácil Manutenção da Aplicação: a manutenção pode ser refletida de duas formas: adição de novas funcionalidades, e o responsável pela análise de domínio e variabilidade deverá identificar os impactos que a mudança irá acarretar nos produtos SPL; ou correção de erros, sendo realizadas nos modelos, mais simples de entender e alterar;

Redução de recursos humanos, pois diminui a necessidade de profissionais experts em programação;

Facilidade na imersão de novos desenvolvedores;

Com relação à Qualidade:

Regras de Corretude no domínio, dificultando a criação de especificações não desejadas;

Eliminação de bugs nas fases iniciais do projeto;

Geração de código que não precisa ser editado a partir da especificação;

Suporte a validações em protótipo.

5. Sistema de Gestão de Estoque: Um Estudo de CasoUm pequeno projeto piloto foi realizado para avaliar o desenvolvimento da solução DSM: um software para gestão de estoque. De forma simples, a gestão de estoques é um sistema de atividades logísticas com foco estratégico e todo o processo produtivo. Isto envolve uma série de entidades, desde o inventário de materiais de transporte, bem como o controle total sobre a logística: quando (segurança), quanto, onde (fornecedores) e como compras os produtos, mantendo o estoque equilibrado, sem falta de produtos, ou em quantidade excessiva.

Após a análise de domínio, um documento com as entidades/relacionamentos foi criado. Este documento serviu como argumento para gerar o modelo FODA. O modelo foi criado usando o Eclipse plugin Compositional Variability Management0 que permite a edição visual ou através de estrutura de árvore. Após a análise de Variabilidade foram obtidos os seguintes resultados:

Entidades Obrigatórias: 5

Entidades Opcionais: 4

Entidades Alternativas: 5

Relacionamentos: 20

Além das entidades, é possível associar atributos a estas, o que dá um caráter de infinita variabilidade para a aplicação. Suponha, por exemplo, que uma empresa solicite um aplicativo para gerenciamento de estoque, e exija a presença da entidade Produto. Um produto, por exemplo, pode ter várias peculiaridades, em termos de descrição, preço, data de estoque, embalagem e transporte. Todas essas características são atributos inerentes do produto e que podem ser modelados. Nesta perspectiva, defendemos que há infinitas possibilidades de variação. Para desenvolver o metamodelo (Definição da Linguagem), foi utilizado o Eclipse Modeling Framework Project [Dave Steinberg e

0 http://www.cvm-framework.org/

23

Merks 2009]. Por razões de propriedade intelectual, apenas uma parte do metamodelo é ilustrada na figura 3(a).

Figura 3: Metamodelo (a) e Exemplo de uma DSM (b)

Após a conclusão desta fase, a definição da ferramenta gráfica foi feita através do Eclipse Graphical Editing Framework (GEF)0. O modelo gráfico também foi criado para representar as entidades mapeadas para cada elemento do domínio de aplicação. Tomemos, por exemplo, a entidade Product na Figura 3(b), nada mais do que uma imagem cuja semântica está vinculada à classe Product no metamodelo.

Figura 4: Exemplo de Aplicação

Com base nesse mapeamento, é possível definir todas as aplicações de estoque que podem ser criadas a partir do Metamodelo, desde que se cumpram todas as restrições expressas. Por exemplo, a multiplicidade mínima entre as entidades Inventory e Product é 1 (um), portanto, em nenhuma circunstância pode ser possível definir um sistema de gerenciamento de estoque, sem a participação da entidade produto. Nessas situações, mensagens de erro (também implantadas nesta fase) deverão alterar as possíveis inconsistências e omissões do atual modelo.

Na última etapa, o gerador de código foi criado. A linguagem de desenvolvimento adotada foi Java. Sua construção dói realização utilizando o código fonte original. Não foram feitas melhorias como refatoração dos modelos para gerar um código fonte de melhor qualidade que o sistema original. Portanto, espera-se que a estrutura e o comportamento do sistema permaneçam idênticas ao do sistema original. A figura 4 mostra um exemplo de aplicação criada, utilizando modelos DSM. Para este caso, a 0 http://www.eclipse.org/gef/

24

solução continha as entidades de Produto, Fornecedor, Cliente, Grupo e Família. A figura ilustra também o processo de criação de um novo produto, ilustrando os atributos que foram associados a esta entidade (código, nome e descrição). Vale lembrar que tais atributos configuram a infinita variabilidade associada à família de aplicações de gestão de estoque. O tempo gasto para criar o gerador de código foi superior em relação às outras atividades, como pode ser observado na figura 5.

Figura 5: Tempo gasto nas Atividades

Como resultado preliminar, foi utilizado teste de regressão [Myers e Sandler 2004]: o comportamento gerado pela solução DSM permaneceu o mesmo quando comparado com a solução desenvolvida pela engenharia tradicional. Além disso, pela análise estática do código [Ayewah ET AL. 2008] utilizada para medir acoplamentos e presença de ciclos. Indicou que a estrutura do código-fonte gerado é praticamente mantida em relação ao código fonte original. A figura 6 mostra alguns resultados comparativos entre packages de ambos os códigos. Vale salientas que estes foram desenvolvidos pela mesma equipe, evitando qualquer tipo de viés por utilizar membros com proficiência diferentes.

6. ConclusãoA solução DSM pretende ser genérica o suficiente para ser apropriada para qualquer plataforma de desenvolvimento. Com os resultados satisfatórios obtidos até então, este projeto está sendo aprimorado, para que diferentes aplicações possam ser geradas e assim, avaliarmos efetivamente o ganho em reusabilidade, produtividade, e baixo custo.

Vale lembrar, contudo, que o desenvolvimento do estudo de caso foi conduzido utilizando plugins na plataforma Eclipse, o que não introduziu nenhum custo financeiro. Ao contrário do que se possa pensar, todos estes se adequaram perfeitamente às atividades, mostrando estáveis e de fácil usabilidade. Também, como dito antes, a partir da análise estática e do teste de regressão, o código da solução DSM manteve-se próximo ao código da aplicação gerada por um desenvolvedor padrão.

25

Figura 6: Resultados Preliminares

Finalmente, saliente-se que, em caso da necessidade de gerar a mesma aplicação para uma plataforma diferente, o foco do trabalho será na reconfiguração dos templates do gerador de código, pois os artefatos das etapas iniciais (documentos e modelos) podem ser reutilizados, impactando diretamente na redução dos cursos. Através do estudo de caso, pode-se perceber que a solução está ao alcance de pequenas e microempresas de desenvolvimento de software. Isto é importante, pois refuta a idéia de que para se manter competitiva no mercado, empresas deste nível precisam investir tanto quanto as grandes software-house.

Como trabalho futuro, propomos a implantação de um processo baseado nestas 5 atividades, com seus respectivos marcos, produtos de trabalho e responsáveis. Este processo pode servir como guia de desenvolvimento, auxiliando os analistas desde a concepção até a implantação e manutenção da aplicação.

ReferênciasABES (2009). Mercado brasileiro de software: Panorama e tendeˆncias - 2009.

Technical report, ABES - Associac¸a˜o Brasileira de Empresas de Software.

ABES (2010). Mercado brasileiro de software 2010. http://www.abes.org.br/UserFiles/Image/PDFs/Mercado\_BR2010.pdf.

Atkinson, C. and Kuhne, T. (2003). Model-driven development: a metamodeling founda- tion. Software, IEEE, 20(5):36–41.

Ayewah, N., Hovemeyer, D., Morgenthaler, J. D., Penix, J., and Pugh, W. (2008). Using static analysis to find bugs. IEEE Software, 25:22–29.

Bachmann, F. and Clements, P. C. (2005). Variability in software product lines. Technical Report September.

Chen, L., Babar, M. A., and Ali, N. (2009). Variability management in software product lines: a systematic review. In SPLC ’09: Proceedings of the 13th International Soft- ware Product Line Conference, pages 81–90, Pittsburgh, PA, USA. Carnegie Mellon University.

26

Coplien, J., Hoffman, D., and Weiss, D. (1998). Commonality and variability in software engineering. Software, IEEE, 15(6):37–45.

Dave Steinberg, Frank Budinsky, M. P. and Merks, E. (2009). EMF: Eclipse Modeling Framework (2nd Edition) (Eclipse). Addison-Wesley Longman, Amsterdam, 2nd re- vised edition (rev). edition. Gandra, A. Setor de software no brasil deve crescer.

Kang, K., Cohen, S., Hess, J., Nowak, W., and Peterson, S. (1990). Feature-Oriented Domain Analysis (FODA) Feasibility Study.

Kelly, S. and Tolvanen, J.-P. (2008). Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE Computer Society Pr.

Kärnä, J., T. J.-P. K. S. (2009). Evaluating the use of domain-specific modeling in practice.

Myers, G. J. and Sandler, C. (2004). The Art of Software Testing. John Wiley & Sons.

Myllymäki, T. (2001). Variability management in software product-lines. Technical report, Institute of Software Systems, Tampere University of Technology. Technical report 30.

SOFTEX (2009). Software e serviço de ti: A indústria brasileira em perspectiva. Technical report, Associação para Promoção da Excelência do Software Brasileiro.

Software Engineering Institute, C. M. U. (2010). Software product lines. http://www. sei.cmu.edu/productlines/.

Stahl, T. and Völter, M. (2006). Model-Driven Software Development: Technology, Engineering, Management. Wiley, Chichester, UK.

Tolvanen, J.-P. (2004). Metaedit+: domain-specific modeling for full code generation demonstrated [gpce]. In OOPSLA Companion, pages 39–40.

White, J., Hill, J. H., Gray, J., Tambe, S., Gokhale, A. S., and Schmidt, D. C. (2009). Improving domain-specific language reuse with software product line techniques. Software, IEEE, 26(4):47–53.

27

Uma proposta de Gerenciamento BPO baseada em análise de mudanças para empresas de software

Hugo Vieira Lucena de Souza

Faculdade Escritor Osman da Costa Lins (UFPE Rua do Estudante, 85, Bairro Universitário – Vitória de Santo Antão – PE – Brazil

{hvlsouza}@gmail.com

Abstract. The series of changes that can occur when one utilizes the services of business process outsourcing becomes inevitable for any businesses requiring flexible its business focus as the management activities are decentralized. Although the responsibilities are assigned to institutions specialists, the dependencies of contractors creates risk factors for adverse situations, letting the professionals in critical situations, how they should act to overcome any problems. This article will bring a proposal for a process that aims to provide strategic indicators show properly managing partner of software companies using the Business Process Outsourcing.

Resumo. A série de mudanças que pode ocorrer quando se utilizam os serviços de terceirização de processos torna-se algo inevitável para quaisquer empresas que necessitem flexibilizar seu foco de negócios à medida que as atividades administrativas são descentralizadas. Apesar das responsabilidades estarem atribuídas às instituições especialistas, as dependências dos contratantes geram fatores de riscos para situações adversas, deixando os profissionais em situações críticas, de como devem agir para contornar eventuais problemas. Este artigo trará uma proposta de um processo que tem como objetivo evidenciar indicadores estratégicos para prover corretamente a gerencia dos parceiros em empresas de software com o uso de Business Process Outsourcing.

1. IntroduçãoA evolução tecnológica vem desencadeando ao longo dos anos a busca pela obtenção de um diferencial competitivo pelas empresas em virtude das mudanças que ocorrem na estrutura organizacional de seus processos. Grande parte desta contribuição parte do surgimento de novos modelos de mercado que demandam flexibilidade para adaptarem-se as necessidades atuais, sem comprometer os resultados esperados para a satisfação dos clientes e das organizações envolvidas nos negócios [CLICK e DUENNING, 2005b].

Segundo Paim et. al. (2009), a implantação de um ou mais processos de gestão torna-se essencial para garantir o controle das mudanças e prover uma competitividade ascendente. O estudo das deficiências existentes nos negócios, alinhado com a definição de soluções estratégicas, fornece uma visão concreta de ações preventivas e corretivas que auxiliam as empresas a melhorarem o fluxograma de suas atividades e tarefas, e consequentemente dedicarem recursos voltados com foco no produto ou serviço oferecido para fornecer melhorias gradativas.

28

Os investimentos para o core dos processos de negócios, como são conhecidos, têm incentivado as empresas a recorrem de soluções eficientes para dar conta das responsabilidades administrativas e atribuí-las para terceiros, facilitando a redução de custos organizacionais [ACCENTURE, 2010]. O Business Process Outsourcing é utilizado em várias áreas, dentre elas para a indústria de software, seja com serviços que não exigem total conhecimento para sua execução, ou mesmo para atividades bem específicas, como codificação, testes, etc..

Desta forma para prover uma gestão comum dentre as empresas e seus parceiros é necessário instituir indicadores que facilitem o acesso e a modificação das informações de maneira coesa e segura. Este artigo propõe o desenvolvimento de um processo para gerência de parceiros, com o objetivo de auxiliar as empresas associadas a manterem um padrão comum de entendimento das atividades e garantir que o uso BPO seja estabelecido com resultados positivos para ambos os lados.

2. Business Process OutsourcingA abordagem dos processos de negócios vem sendo destacada há algumas décadas com a crescente evolução mercadológica. Segundo Seiffert (2010), as empresas iniciaram uma nova fase de crescimento acelerado acompanhando a aquisição de novos modelos de negócios que necessitam progressivamente de esforços concentrados em três fatores essenciais tais como, a formulação de investimentos em estratégias de negocio, a descentralização de operações cotidianas, e principalmente, a satisfação dos clientes como ponto-chave do sucesso.

A implantação desses fatores para a formação de uma boa infraestrutura organizacional é proposta pelo Business Process Outsourcing, também conhecido como BPO. Para Click e Duenning (2005a), o BPO é a expansão das relações empresariais com o melhoramento dos serviços operacionais por terceiros especializados em suas áreas afins para garantir flexibilidade nos processos de negócios de acordo com as necessidades de cada empresa. As atividades e tarefas internas de um determinado processo são transferidas tornando a serem executadas externamente, porém sem desvincular a gerencia, acesso e alteração dos dados pelos proprietários das informações.

Alguns dos países que se destacam como hot spots do BPO para exportação dos serviços de suporte para processos estão listados de acordo com o tipo de negócios que cada um tornou-se pioneiro, segundo o site de negócios indiano rediff.com, em uma pesquisa realizada em 2009. Com o título The world's top 10 BPO hotspots, a pesquisa aponta alguns dos principais pólos mundiais de BPO, dentre eles a Índia (Engenharia), China (Manufatura) e Filipinas (Administração).

2.1. Categorias do Business Process Outsourcing

Para facilitar a identificação das áreas que as empresas podem adequar seus modelos de negócios para os serviços de terceirização, duas categorias são descritas de acordo com a classificação dos processos como internos ou externos, os chamados Back Office e Front Office. Blokdijk (2008) apresenta em seu livro Outsourcing 100 sucess secrets, as diferenças dentre estas duas categorias sendo as seguintes:

29

Back Office: Inclui todas as funções internas de negócio tais como recursos humanos, folha de pagamento, contas e finanças e demais processos que envolvam a infraestrutura interna de serviços da empresa;

Front Office: Inclui operações externas de negócio tais como atendimento ao cliente, consultoria e serviços gerais e processos que envolvam os clientes.

Ainda sobre o Front Office, há uma segunda divisão, de acordo com a localização geográfica, quanto a nacionalidade e distância da prestadora para com seu contratante. Blokdijk (2008) cita que os três tipos de Outsourcing Front Office são:

Onshore: A terceirização é realizada por uma empresa do mesmo país.

Nearshore: A terceirização é realizada por uma empresa de um país vizinho.

Offshore: A terceirização é realizada por uma empresa de um país distante.

A decisão sobre qual tipo de Front Office adotar torna-se difícil a cada dia que passa. Os riscos de gerenciar os processos de forma correta adjunto a qualidade dos serviços e o custo que tudo isso pode gerar, revela uma preocupação da viabilidade em se empregar um investimento que retorne benefícios competitivos de acordo com o porte da empresa e a demanda de negócios, para que no futuro a decisão não possa ser encarada como um erro que poderia ter sido evitado [BLOKDIJK, 2008].

2.2. Ciclo do Business Process Outsourcing

O processo de repassar todas as informações necessárias de uma empresa contratante para uma empresa de Outsourcing exige uma organização bem elaborada, dividida e etapas. A KMPG (2005) descreve cada passo que deve ser adotado, no formato de uma metodologia com uma análise e detecção de áreas críticas, questões, desafios e outros indicadores que possam afetar os processos que estão sendo terceirizados. As fases estão concentradas em práticas simples que auxiliam o uso de BPO da seguinte forma:

Figura 1: Ciclo de uso BPOFonte: [KPMG, 2005, p.3]

A primeira etapa é o diagnóstico. Este passo formula a coleta dos primeiros dados dos processos de negócios e o armazenamento de suas informações para verificar as condições atuais dos processos de negócios, como por exemplo, a insuficiência administrativa. Este primeiro passo subdivide-se em fases seqüenciais [KMPG, 2005]:

Entendimento da empresa: É a fase de conhecimento das perspectivas industriais e organizacionais para estipular quais os desafios, limitações e benefícios poderão ser encontrados com a terceirização.

Análise dos processos: É a fase da análise estratégica, gerencial e operacional dos processos para verificar se os mesmos comportam ser terceirizados. Em empresas de médio e grande porte, esta fase se dá com o estudo da matriz hierárquica e o índice de dependências existentes dentre os processos.

30

Determinação das regras de negócio: Nesta fase são apresentados os requisitos que devem ser atendidos pela empresa contratada de acordo com as políticas de controle e atuação da organização.

Estrutura de suporte: É a análise da infraestrutura física, tecnológica e de recursos humanos para previsão de despesas em geral que serão contabilizadas.

Plano de trabalho para transição: Desenvolvimento do Plano de Transição com cronogramas, datas, planos de ação, etc.

A segunda etapa é a transição. Durante esta etapa é implantado o Plano de Ação como os demais planos anexos para emissão dos relatórios diários, mensais e a transferência dos arquivos físicos e lógicos para a empresa terceirizada. As fases da transição correspondem [KMPG, 2005]:

Sistematização dos dados: Correspondem da inserção dos dados dos processos de negócios para os sistemas especialistas das empresas terceirizadas provendo uma atualização e comparação prévia com os dados recebidos.

Customização dos dados: Corresponde a aplicação de correções e o envio do feedback inicial para a empresa contratante a respeito de possíveis melhorias que precisam serem inseridas.

A terceira e última etapa, é considerada por muitos profissionais como a mais difícil. Manter o padrão de funcionalidades, disponibilidade dos serviços, e fornecer informações precisas e com qualidade é o propósito planejado para continuar os processos à medida que as mudanças surgem. As atividades da continuidade são descritas por algumas das seguintes fases [KPMG, 2005]:

Monitoramento para entrega: Consiste em cumprir os prazos estabelecidos por ambas as partes, sejam com produtos, serviços ou informações com Outsourcing.

Suporte estratégico: Prover o auxílio necessário para o crescimento contínuo nas operações dos processos de maneira que as empresas contratantes obtenham competitividade.

Treinamento e Inovação tecnológica: Capacitar os envolvidos nas operações dos processos sempre com novos recursos tecnológicos para sempre fornecer melhorias nas atividades e nos negócios.

De acordo com a NASSCOM (2008), não existe um ciclo ou conjunto de etapas padrão para o uso BPO. Cada empresa que exporta serviços Outsoucing sintetiza seu próprio processo ou metodologia de acordo com a abrangência das áreas de negócios. O perfil de cada empresa remete a capacidade que a mesma tem de oferecer garantias de expansão com boas oportunidades e alternativas para solucionar os problemas que podem ser encontrados nos processos terceirizados mediante a complexidade de solucioná-los com a eficiência esperada.

2.3. Business Process Outsourcing e a Tecnologia da Informação

Mesmo com a diversidade de oportunidades para implantação de Outsourcing existente no mercado, a contratação dos serviços de empresas externas pode divergir pontos que trazem benefícios relevantes para o modelo de negócios adotado, com os riscos de

31

eventuais problemas, quando são quebradas as regras e as políticas da empresa contratante.

Paula (2010) aborda em sua apresentação intitulada BPO do processo de gestão da informação e do conhecimento corporativo, que o contraste das vantagens e desvantagens nivela o chamado “body shop”, com o planejamento e gerenciamento sob a responsabilidade do contratante. A confiança é o fator chave para facilitar as relações de compartilhamento das estratégias e a posse do serviço ou produto terceirizado quanto na questão dos direitos autorais e no sigilo das informações, como por exemplo, na terceirização dos processos de negócios de empresas de Tecnologia da Informação.

Neste campo, o crescimento de Outsourcing tem caminhado a passos largos, segundo apontam Albertin e Sanchez (2008) em seu livro Outsourcing sobre T.I.. Setores como Suporte Técnico, Consultoria em T.I., e até mesmo papéis mais específicos para concepção de produtos de software, como análise, codificação e testes estão ascendendo no mercado a cada dia com as “células de projeto”, termo usado para terceirização de sistemas, seja com organizações privadas especializadas ou instituições de ensino superior [ALBERTIN e SANCHEZ, 2008]. Um exemplo da dimensão funcional com a Cadeia de Valores do Outsourcing na T.I. é descrito na Tabela 1:

Tabela 1: Cadeia de Valor de T.I. e OutsourcingFonte: [Adaptado de McSinkey, 2010]

As categorias de serviços e a dimensão funcional que a terceirização pode abranger, apenas exemplificam o uso BPO que está presente muito mais do que se imagina atualmente. Se levar-se em consideração que a melhoria dos processos de negócios no core também contabiliza a transição de operações críticas e operações básicas, a estratégia focaliza-se como peça chave para prover um gerenciamento eficaz dentre um ou mais terceirizados, formulando um ecossistema dentre organizações, onde se uma empresa ganha, todas as outras ganham ao mesmo tempo.

32

O Observatório Digital da SOFTEX publicou uma pesquisa em 2005 apontando as principais metas buscadas pelas empresas brasileiras quanto à exportação de serviços de T.I.. O Brasil está aos poucos assegurando competências como país de referência tecnológica devido à injeção de investimentos em BPO por pequenas e médias empresas que almejam alavancar uma fatia do mercado para garantir destaque internacional. O contingente desse crescimento representa 7% do PIB nacional segundo descreve um estudo realizado em 2009 pela Associação Brasileira de Empresas de Tecnologia da Informação e Comunicação.

2.4. O futuro do Business Process Outsourcing

Para muitos especialistas o momento ideal para a aquisição de serviços BPO pelas empresas está em um futuro bem próximo. A crise mundial exigiu que muitos profissionais das TICs0 reprimissem táticas empresariais de cortes de investimento, recursos humanos e infraestrutura tecnológica para evitar o efeito de diminuição de lucros, perda de clientes no mercado, enfim, com tudo que equalizasse as dificuldades de obter bons resultados mediante um cenário econômico em uma situação frágil [BRASSCOM, 2009].

Esse problema em escala mundial inseriu a política de “pagar barato para fazer” ao invés de “gastar caro para vender”, segundo diz a pesquisa BRASSCOM realizada em 2009. A substituição de concentrar esforços desnecessários para gerar um potencial efetivo sobre a demanda tem gerado bons resultados e um futuro promissor com dados bem expressivos com desenvolvimento Outsourcing nos últimos dois anos. Para se ter uma idéia, a movimentação financeira gerada com o TI-BPO em 2008 foi de US$ 2,2 bilhões com previsão para 2011 de US$ 5,7 bilhões, considerando apenas as exportações realizadas pelo mercado brasileiro.

Os números realmente impressionam e estimulam cada vez mais a contratação de mão-de-obra especializada e novas tecnologias devido ao offshore outsourcing. Um possível cenário bem próximo nesse contexto, o que já se torna uma realidade, é a escassez por profissionais qualificados que preencham as vagas de emprego para áreas específicas em empresas de BPO em contraponto ao volume de demissões que estão sendo veiculadas com a terceirização dos processos de negócios pelas empresas contratantes [BRASSCOM, 2009].

3. Gerenciamento de mudançasA adaptação das empresas para as situações adversas que o mercado pode proporcionar influencia diretamente na formação da cultura organizacional para os envolvidos direta e indiretamente. A volatilidade de estratégias, recursos, e a reavaliação das atividades nos processos de negócio exigem dos profissionais o uso de técnicas que gerenciem um conjunto de mudanças que tragam benefícios, quando planejadas corretamente, como também desagradáveis, quando acontecem de forma emergente.

O importante em se implantar um controle quanto ao fato de mensurar as mudançaspositivas e negativas, para evitar o crescimento e o acúmulo dos problemas, é destacado por Hrebiniak (2005) em seu livro Fazendo a estratégia funcionar. Segundo o autor, o quesito “transição” de um determinado estado para outro similar ou diferente, 0 TICs e a abreviatura de Tecnologias da Informação e Comunicação. Ferramentas que utilizam T.I. para automação e comunicação de processos de negócios.

33

ainda é um déficit que merece ser analisado e que as conseqüências da execução desta prática podem influenciar na qualidade de um produto ou serviço determinado.

A maneira para prover o equilíbrio aos possíveis novos cenários é definida de acordo com a amplitude da estratégia utilizada e alguns fatores, como pode ser observado na Figura 2. Se uma empresa possuir um ou mais parceiros que estejam envolvidos e precisam alterar características de um processo, é inevitável instituir um modelo envolvendo a comparação do tempo e o tamanho do problema para facilitar novas medidas que contornem as dificuldades encontradas [HREBINIAK, 2005].

Figura 2: Um modelo de mudança e execuçãoFonte: [Hrebiniak, 2005, p. 233]

3.1. Tipos de mudanças

O tipo da mudança também representa como será modificada a estrutura dos processos e negócio. A resistência a mudança é estimulada devido aos diferentes meios de percepções que podem ser gerados acarretando a falta de entendimento e confiança sobre o que pode acontecer no futuro, sem a prescrição de um diagnóstico preciso sobre os hábitos e interesses pessoais que estabeleçam o motivo real de uma nova rotina [SIQUEIRA, 2010].

Para Siqueira (2010), as pessoas são as peças-chaves para agregar valores a cada nova reformulação. O empenho de cada profissional depende do nível de envolvimento que o mesmo exerce em cada processo e a contribuição que pode ser inserida em cada nível de mudança de acordo com conhecimento da hierarquia tratada. Em uma ordem organizacional, Siqueira (2010) descreve os tipos de mudanças e as características de cada uma de acordo com as seguintes categorias:

Estratégica: Compreende da alteração estratégica das políticas de visão, missão e metas que precisam ser atingidas.

Estrutural: Corresponde a alteração das estruturas das organizações dentre uma ou mais empresas envolvidas, com downsizing0, unidades de negócio, etc.

0 Racionalização ou simplificação de níveis hierárquicos em uma organização. Uma empresa pode ser considerada uma única entidade jurídica. Uma organização, uma ou mais agregadas [KOTH, 1996].

34

Centradas nos processos: Compreende a inserção ou remoção de artefatos aos processos de negócios, como por exemplo, novas tecnologias, adotando novos métodos para automação de produção, melhoria de processos de software, soluções de problemas, etc.

Centrado nas pessoas: Corresponde ao direcionamento de atitudes, comportamentos, habilidades, ou desempenho dos trabalhadores e o suporte para a infraestrutura de recursos humanos.

Além das categorias apresentadas neste artigo, sabe-se que muitos outros motivos estão agregados diretamente aos resultados esperados. A formação de etapas bem definidas para analisar, implantar e avaliar a alteração de um determinado processo facilita uma visualização mais completa, com o intuito mapear o passo a passo de como as medidas podem ser tomadas para evitar que a mudança, mesmo que seja planejada, gere novos problemas em níveis estratégicos, estruturais, de processos ou com as pessoas.

3.2. Processo para gerência das mudanças

Um artifício necessário durante a realização de uma mudança é justamente adotar-se um processo, por mais simples que ele possa ser. Segundo Koth (1996), a quantidade de informações que circulam durante a criação de um novo contexto de trabalho necessita de organização para o desenvolvimento de novos fluxos na execução dos processos de negócios. Para Koth (1996), a empresa pode desenvolver seu próprio processo de mudanças, mas para isso devem ser considerados oito pontos básicos que regem um uma mudança bem-sucedida [KOTH, 1996]:

Sentido de urgência: Conscientiza os participantes de que a mudança precisa ser realizada de maneira dedicada e imediata.

Desenvolvimento de uma estratégia de mudança: A mudança irá afetar parcialmente ou totalmente tudo que esteja veiculado a empresa.

Comunicação: A compreensão de que as idéias antigas serão substituídas pelas novas detém da transmissão da informação confiável, segura e consistente.

Equipe envolvida: Os profissionais devem dispor de capacidade de análise, execução e liderança para trabalhar em equipe.

Motivação: Instituir um sentimento de que a mudança é possível de ser realizada removendo as barreiras e impedimentos que existirem.

Vitórias como foco: Produzir resultados positivos, mesmo que estes ainda estejam em fase de consolidação representa o avanço gradativo da mudança.

Criação e adaptação de uma nova cultura: A mudança dos hábitos requer uma nova análise da sistematização da empresa. Mudança de cargos, setores, responsabilidades, etc.

Não desistir: A força de vontade e a dependência e muitos casos fazem que os profissionais não desistam de seus objetivos, o que pode diferenciar o sucesso do fracasso.

A relação da gerência com o processo de mudanças ocorre à medida que os estágios acima são abordados em cada fase estabelecida. Para Click e Duenning (2005a) no

35

Business Process Outsourcing esses princípios também são relevados durante o tratamento de mudanças, diferenciando apenas de um conjunto de práticas voltadas para o gerenciamento de projetos nos processos de negócios, que envolvem as empresas especialistas e seus respectivos contratantes.

3.3. Gerência de mudanças e BPO

Os níveis operacionais para o uso BPO, comparados às mudanças estendem um estudo mais criterioso com o desenvolvimento de vários planos. A responsabilidade de integrar dados de terceiros, mediante aos acontecimentos diversos que podem ocorrer, demanda dos profissionais um empenho valoroso do uso de técnicas e ferramentas que avaliem principalmente os riscos em compartilhar suas informações com terceiros que muitas vezes são desconhecidos [CLICK e DUENNING, 2005a].

A gerência de mudanças nesse sentido está alinha-se com os contratos fixados entre o vendedor BPO e o contratante. “Apesar de assinado e selado, o contrato de BPO não fornece a flexibilidade e agilidade necessárias para se adaptar conforme as necessidades e condições competitivas de cada empresa, como metas e objetivos, prazos, metas, e os principais prazos definidos de trabalho” [CLICK e DUENNING, 2005a, p. 137], no que diz respeito que as mudanças e suas causas devem ser preestabelecidas bem antes do fechamento da parceria entre os envolvidos.

Portanto, a flexibilidade de suportar as mudanças é relativa à liberdade das empresas para adotarem uma ou várias medidas para resolver os problemas quanto a novas perspectivas dos processos de negócios. Apesar da burocracia está presente na maioria dos casos em que as mudanças devem ser implementadas, isso se torna algo inevitável de acontecer na rotina das atividades e deve ser proposto com destaque especial quando o problema em questão envolve gerencia de mudanças e Business Process Outsourcing.

4. Um processo de gerenciamento BPO baseado em mudançasDiante disso, a proposta deste artigo foi desenvolver um processo que possa ser utilizado pelas empresas de serviços Outsourcing para facilitar o entendimento do problema através de um conjunto de atividades que compreendem a análise da mudança, com suas devidas causas, as possíveis maneiras de executar a mudança, por meio de tarefas que compatibilizem a transição das informações, e a validação da mudança, com um fluxo iterativo para verificar e fixar novas alterações que possam ser realizadas.

Há também uma representação gráfica do processo com o uso da notação de processos de negócios (BMPN). A ferramenta BPMS0 utilizada foi a Bizagi, onde cada etapa do processo é especificada com artefatos que descrevem um leque de possibilidades em diferentes estados do processo de acordo com a situação atual em que se encontra a mudança. Por fim, há uma seção pela qual são descritos cenários de empresas que podem ser aplicados o processo dependendo da abordagem que as mesmas adotam o Outsourcing para identificar a viabilidade da aplicação do processo de gerência BPO para mudanças.

0 BPMS é a abreviação de Business Process Management System. Ferramentas que automatizam os processos de negócios.

36

4.1. Fases do processo

Por se tratar de um processo que possui atividades genéricas, que devem ser aplicadas em mudanças de complexidades diversas, as fases propostas para gerência contínua são divididas em três passos. Apesar do processo não caracterizar obrigatoriamente como flexível, a seqüência de operações é devidamente importante ser aplicada na forma como se segue. Desta forma, as etapas para o processo de gerencia BPO baseado em mudanças são:

Análise da mudança: A primeira etapa consiste em analisar a causa e os possíveis efeitos que a mudança pode ocasionar, mesmo que não seja planejada. Nesta etapa são verificados os fatores responsáveis que geraram a necessidade de alterar o fluxo de um ou vários processos desenvolvendo um plano de contingência para promover o estudo da mudança com todas as informações possíveis que possam ser agregadas.

Execução da mudança: Nesta etapa é executada a mudança baseada no estudo realizado na fase anterior. Por se tratar de uma fase de um contexto operacional não existem muitos atributos que possam ser realizados nas atividades, além da implantação de novas rotinas, tarefas, etc. É importante registrar em um documento toda a etapa de implantação da mudança para contabilizar diretrizes e limitações.

Validação da mudança: A última etapa consiste em verificar se a mudança foi bem aceita e o feedback que pode ser obtido com um novo cenário em execução. Nesta fase são realizadas correções para facilitar a adaptação das mudanças e prover um acompanhamento com suporte das principais dificuldades encontradas pelos envolvidos em manter o processo coeso, seja na parte estratégica, estrutural, nos próprios processos, ou com as pessoas.

As atividades de cada etapa indicam algumas práticas que auxiliam o controle baseados em situações comuns encontradas pela maioria das empresas. O processo foi desenvolvido com o intuito de possuir total liberdade para que novas atividades sejam adicionadas ou removidas, desde que mantida a ordem das etapas durante sua aplicação. É importante que em cada etapa seja desenvolvido um documento que contenha os dados da aplicação de cada fase, para que no futuro, mudanças semelhantes sejam realizadas de maneira mais objetivas, em conseqüência do aprendizado adquirido com as mudanças anteriores.

4.2. Modelagem do processo com a notação BPMN

A modelagem do processo é dividida considerando o fluxo existente entre as empresas contratante (cliente) e contratada (Outsourcing) com a criação de duas raias, uma para cada ator no cenário do processo. As fases possuem uma sequência de atividades, tendo cem algumas situações uma condição para ser aceita para dar prosseguimento ao término da mudança. A interação entre as empresas foi destacada neste modelo com o objetivo de que a comunicação e a transparência dessas operações não projudiquem as relações existentes e consequentemente a execução da mudança.

37

Figura 3: Processo de Gerenciamento BPO baseado em mudançasFonte: [próprio autor, 2010]

Uma das vantagens propostas na modelagem para o processo de negócio deste artigo é a simplificidade de abstração que foi desenvolvida para o entendimento da proposta pelas empresas. Cada atividade tem por base sua funcionalidade descrita na Figura 3, mas as tarefas ficaram explícitas devido aos tipos de mudanças (seção 3.1) possíveis de estarem sendo aplicadas, ficando invíavel restringir uma ou mais dessas atividades para um único tipo. O importante é que sua aplicação compatibiliza não só as responsabilidades administrativas, mas também técnicas, como por exemplo, no desenvolvimento de software.

4.3. Cenários de aplicação do processo

Em relação aos cenários para aplicação do processo, as limitações são poucas. Sabe-se que empresas de Outsourcing de grande porte possuem suas respectivas metodologias e uma série de requisitos para aceitarem seus clientes, limitando às vezes a participação dos mesmos no processo de mudança. Cada metodologia para indexação da terceirização dos processos de negócio deve obedecer no mínimo uma análise do problema, um roteiro de implantação da mudança e seus respectivos resultados de aceitação.

Como foi proposto, esse processo é indicado para empresas de desenvolvimento de software. O foco em primeira instância fornecer um apoio no processo de desenvolvimento e integração de software visando adequar melhorias no produto, mas isso não limitando empresas para agregarem esses procedimentos de BPO como alternativas de revisões ou adaptações. Cada caso se torna peculiar de acordo com a gestão atribuída para lidar com mudanças, seja com o uso BPO, ou com gestão de projetos para empresas de Tecnologia da Informação.

38

5. ConclusõesAo longo da elaboração do processo observou-se que a necessidade de implementar um conjunto de práticas para gerir as mudanças é inevitável para qualquer organização que adote produtos ou serviços de terceiros. A pesquisa sintetizou que a grande dificuldade das empresas atuais é manter um bom relacionamento para garantir credibilidade com o auxílio, ou muitas vezes a dependência de um grupo de profissionais que não faz parte do quadro de colaboradores, mas que tem total envolvimento com o sucesso ou fracasso com as metas almejadas.

Alguns pontos que puderam ser considerados como negativos para o desenvolvimento desta proposta foi a pouca quantidade de trabalhos publicados com Business Process Outsourcing, principalmente relacionando mudanças ou gestão. O paradigma de restringir o funcionamento do processo e apenas fornecer o serviço as empresas contratantes é algo que muito encontrado na literatura que descreve a situação atual como falha no processo de comunicação. Em contraponto, a contribuição que se espera deste artigo é que o mesmo possa servir como base para o desenvolvimento de novas propostas mais específicas que moldem as atividades de acordo com as necessidades para cada tipo de mudança existente com uso BPO.

O investimento para manter um bom relacionamento dentre o contratante e a contratada se dá com a com a junção de vários fatores básicos como uma boa comunicação e a transição das informações de maneira confiável e segura, características que serviram como base para a elaboração deste processo. Pode-se concluir que a gerência de mudanças para Business Process Outsourcing não é apenas mais um elemento adicional para ser inserido durante a gerência de projetos, mas algo para ser levado em conta no cotidiano das empresas para a manutenção de seus processos de negócios.

ReferênciasACCENTURE. Business Process Outsourcing Big Bang: Creating Value in Expanding

Universe. 2002.

ALBERTIN, Alberto Luiz. SANCHEZ, Otávio Próspero. Outsourcing sobre T.I. FGV Editora, 1ª Edição. 2008

BLOKDIJK, Gerard. Outsourcing 100 sucess secrets. Emereo Pty Ltd, primeira versão, 2008.

BRASSCOM. Associação Brasileira de Empresas de Tecnologia da Informação e Comunicação. Brasscom lança o mais completo relatório do setor brasileiro de Tecnologia da Informação. Disponível em: <http://www.brasscom.org.br/brasscom/content/view/full/3079> Acesso em 5 dez. 2010

CLICK, Thomas N. CLICK, Rick L. Essentials of Business Processing Outsourcing. John Wiley & Sons, Inc, 2005a.

CLICK, Thomas N. CLICK, Rick L. Business Processing Outsourcing: The competitive Advantage. John Wiley & Sons, Inc, 2005b.

HREBINIAK, Lawrence G. Fazendo a estratégia funcionar: O caminho para uma execução bem-sucedida. Pearson Education Inc. 2005

39

KOTTER, John P. Leading Change. Harvard Business School Press. 1ª Edição.1996 MCSinkey and Company do Brasil. Cadeia de Valor de TI. Disponível em: http://www.google.com.br/url?sa=t&source=web&cd=1&ved=0CBcQFjAA&url=http%3A%2F%2Fce.desenvolvimento.gov.br%2FSOFTWARE%2F0%2520-%2520MDIC%2520STI%2520-%2520Cadeia%2520de%2520Valor%2520em%2520Software.doc&ei=MIf7TN6pL8L98Abtv9D1Cg&usg=AFQjCNGbTVsHJxEUF9vKyuV6cUn3jEdplQ&sig2=EUcEGrVKlhNitBqdZB9q2w Acesso em: 5 dez. 2010

SEIFFET, Marilia Ometto. Mercado de Outsourcing: Analáise Setorial com foco em BPO. 2010. Disponínel em: <http://www.slideshare.net/fabiofischer/mercado-deoutsoucing-bpo-v1> Acesso em 2 dez. 2010.

REDIFF. The world's top 10 BPO hotspots. 2009. Disponível em: http://business.rediff.com/slide-show/2009/may/22/slide-show-1-worlds-top-10-bpohotspots.htm Acesso em 2 dez. 2010.

NASSCOM, Everest India BPO Study. Roadmap 2012 - Capitalizing on the Expanding BPO Landscape. 2008.

PAUL, Rosália Paraiso Matta. Terceirização ou BPO: Business Process Outsourcing do processo de gestão da informação e do conhecimento corporativo. Disponível em: <http://www.slideshare.net/documentar/tercerizao-ou-bpo-business-processoutsourcing-do-processo-de-gesto-da-informao-e-do-conhecimento-corporativo> Acesso em: 3 dez. 2010.

SIQUEIRA, Jairo. Gestão de Mudanças. Disponível em: <http://www.slideshare.net/Siqueira/gesto-de-mudanas> Acesso em 6 dez. 2010

SOFTEX. Observatório Digital da SOFTEX. Clipping da Pesquisa Business Process Outsourcing (BPO). 2009.

40

Assessing Intra-Application Exception Handling Reuse with Aspects

Júlio César Taveira, Cristiane Queiroz, Rômulo Lima, Juliana Saraiva, Sérgio Soares, Hítalo Oliveira, Nathalia Temudo, Amanda Araújo, Jefferson Amorim

Department of Computing and Systems, University of Pernambuco, Recife, Brazil{jcft2, ccq, rsl, julianajags, hos, nmt, ara, jsa}@dsc.upe.br

Fernando Castor, Emanoel Barreiros

Informatics Center, Federal University of Pernambuco, Recife, Brazil{castor, efsb}@cin.ufpe.br

Abstract: Recent studies have attempted to evaluate the benefits and drawbacks of using aspect-oriented programming to modularize exception handling code. In spite of their many interesting findings, these studies have not reached a consensus when it comes to the impact of aspectization on exception handler reuse. In fact, their results are sometimes in direct contradiction.In this paper we describe a study aiming to answer the question of whether AOP really promotes the implementation of reusable exception handling. We analyze reuse in a specific context: in terms of the number of duplicated or very similar error handlers that can be removed from a program when extracting error handling code to aspects. Our study targets three industrial-strength, medium-size software systems from different domains and employs a comprehensive set of concern-specific metrics.

Resumo: Estudos recentes tentaram avaliar os benefícios e desvantagens de se empregar a programação orientada a aspectos (POA) para modularizar código de tratamento de exceções. Apesar dos muitos achados interessantes desses estudos, eles não atingiram um consenso no tocante ao impacto de POA no reuso de tratadores de exceções. Inclusive, em alguns casos, os resultados desses estudos estão em contradição direta. Tendo isso em vista, este artigo descreve um novo estudo cujo objetivo é responder se aspectos realmente promovem a implementação de tratamento de exceções reusável. Reuso é analisado em um contexto específico: em termos do numero de tratadores de erros duplicados ou muito similares que podem ser removidos de um programa quando código de tratamento de exceções é extraído para aspectos. O estudo tem como alvos três sistemas de software reais, de tamanho médio, oriundos de domínios distintos, e emprega um conjunto abrangente de métricas específicas para o interesse analisado, tratamento de exceções.

1. IntroductionException handling [Goodenough 1975] is a technique used in software development that allows one to structure a program to deal with exceptional situations. Many mainstream programming languages, such as Java, Ada and C++, have an exception handling mechanism. An exception handling mechanism supports the separation between the code responsible for handling errors and the code implementing the main

41

system functionality [Parnas and Wurges 1976]. Ideally, this separation results in systems that are less complex and, hence, easier to understand and more evolvable and reliable [Randell and Xu 1995].

In spite of all its potential benefits, effectively using exception handling is not a simple task. The main problem is that error handling code usually gets tangled with code associated with other concerns and scattered throughout many program units. This hinders maintainability and understandability and negates some of the expected benefits of exception handing mechanisms. In addition, developers are often only interested in the main system functionality [Shah, Görg and Harrold 2008]. Exception handling is often addressed at the implementation phase, in an ad hoc way. As a consequence, exception handling code is, in general, not well-understood, tested, and documented [Cristian 1979]. Another problem of exception handling in object-oriented systems written in mainstream programming languages is code duplication. It is often the case that identical exception handlers can be found in many different places within a system [Cabral and Marques 2007]. Duplicated code can have a negative impact on several software quality atributes [Juergens et al. 2009], including maintainability and reliability.

The use of new separation of concerns techniques such as aspect-oriented programming (AOP) [Kickzales et al. 1997] can help developers in taming the inherently crosscutting nature of error handling. In AOP, crosscutting concerns, such exception handling, authentication, and logging, can be implemented by a new abstraction, called aspect, while the concerns that are not crosscutting are implemented with plain object-oriented programming. AOP can also help developers in reducing the amount of duplicated error handling code in an application, by localizing similar exception handlers within the same program unit. This means that, when an exception handler is refactored to an aspect, all the clones of that handler can be removed and the aspectized handler can be reused instead, without duplication.

The intra-application reuse of exception handling code promoted by AOP has been discussed in at least two previous studies. Lippert and Lopes (2000) found out that, when extracting to aspects the error handling code of a reusable infrastructure, a large amount of reuse can be achieved and, as a consequence, system size is reduced. On the other hand, some of us [Castor et al 2006] conducted an independente study targeting four deployable systems and found out that very little reuse could be achieved through the aspectization of exception handling. In fact, system size consistently grew after we extracted error handling to aspects. In our view, these conflicting results stem from the focus of these studies. The first one aimed to assess the feasibility of using AOP to modularize exception handling whereas the second one assessed the quality of the resulting code, when compared to a purely object-oriented version. Even though both studies attempted to measure system attributes typically associated with intra-application exception handling reuse, such as number of lines of code (LOC) and number of catch blocks, none of them was specifically designed with reuse in mind. Therefore, it is difficult to extrapolate their findings to general software development.

This paper addresses these limitations of previous studies and presents a new study with the goal of assessing the extent to which AOP promotes intra-application reuse of exception handling code. We compare three alternatives for modularizing exception handling: a “regular” object-oriented approach, a refactored object-oriented

42

approach where exception handlers are implemented in special-purpose classes, as an attempt to maximize the reuse of objectoriented exception handlers, and an aspect-oriented approach where exception handlers are implemented in AspectJ [Laddad 2003], an aspect-oriented extension to Java. For the latter two alternatives, the code was thoroughly and methodically reviewed to spot reuse opportunities and combine identical handlers. Our study targets three medium-size industrialstrength Java applications where exception handling code is non-trivial. We try to elicit situations where AOP creates opportunities for reuse whereas object-oriented programming does not and vice-versa. We also analyze the language constructs that influence these opportunities, i.e., the root causes for one approach to be more powerful than the other. We employ a set of software metrics to assess the quality of each version of the three systems. These metrics have the peculiarity of being capable of directly measuring system features that are related to reuse of exception handling code. To collect these metrics, we have built a measurement tool that works with both Java and AspectJ programs.

It is important to stress the main differences between this study and previous studies addressing the combination of AOP and exception handling. First, we use medium-size, industrial-strength applications with non-trivial exception handlers, whereas Lippert and Lopes (2000) have employed a reusable infrastructure with very simple exception handling policies. Our study is also different from the one conducted by Castor Filho et al. (2006), since we have employed pairs of developers attempting to systematically reuse exception handling as much as possible. In addition, these pairs have also reviewed each other's work, to spot missed reuse opportunities Finally, this study employs a set of 10 different concern-specific metrics, all of them focusing on exception handling. This set of metrics provides a more precise Picture of the impact of each modularization approach on the amount of exception handling reuse that could be achieved.

This paper is organized as follows. Section II presents the target applications of our study (Section II.A), explains how we extracted exception handling code to both aspects and new classes (Section II.B), and describes our approach for finding and eliminating duplicated handlers (Section II.C). It also presents the employed metrics suite (Section II.D). Section III presents the results of the study. Sections IV and V discuss related work and round the paper, respectively.

2. Study StettingIn this section we describe the configuration of our study. Section II.A describes its target systems. Sectin II.B explains how we extracted error handling code to aspects and to new classes. We assume that the reader has a basic knowledge of AOP and AspectJ. The adopted approach for detecting and combining duplicated exception handlers is explained in Section II.C. Section II.D presents the metrics suite that we employed in order to quantify reuse

2.1 Our Case Studies

In this study we refactored three Java applications. These applications are significant for our study because they are real industrial-strength applications and have some relevant characteristics. The first one is that all of them have at least 15K LOC and at least 1% of LOC pertaining to exception handling. A second characteristic is that the applications are from different domains and written in Java. The third characteristic is that the

43

applications have many non-trivial exception handlers. Finally, the three target systems come from different domains and application development platforms. The original implementations of the three applications are in plain Java. For each application, two new versions were developed: one where exception handling is modularized using AspectJ aspects and another one where exception handling is modularized using Java classes (Section II.A). On the remaining of this section, we describe the three target systems.

The first application is Checkstyle0, a plugin that checks coding style for Java programs. This application comprises 19,197 LOC (compilable code, excluding comments and blank lines) and more than 290 classes and interfaces. The second application, Java PetStore0, is a demo for the Java platform, Enterprise Edition0 (Java EE). This application employs various technologies based one the Java Enterprise Edition (EE) platform and is representative of e-commerce applications. Its implementation has approximately 17,500 LOC and 330 classes and interfaces. The third application is JHotDraw0, a Java GUI framework for technical and structured graphics. JHotDraw comprises 23k LOC and more than 400 classes and interfaces.

2.2 Extracting Exception Handling

This study compared three different versions of each of the target systems: (i) an original version, implemented in Java; (ii) a refactored OO version, also implemented in Java; and (iii) and AO version, implemented in AspectJ. The latter are functionally equivalent versions of the original system where the exception handling code was moved to new classes and new aspects, respectively. To obtain versions (ii) and (iii) of each target systems, we extracted, from original version, exception handling code to new classes and aspects whose sole responsibility is to implement the exception handling concern.

It is important to emphasize that, in the refactored OO versions, the code that captures exceptions (try-catch-finally blocks) cannot be extracted, diferently from the refactored AO versions. Only the internal statements of the catch and finally blocks. We perform this extraction, nonetheless, to evaluate the capability of object-oriented languages to promote error handling reuse, so as to allow a fair comparison with AspectJ. We consider that exception handling code is all the code that exists solely due to the need to handle exceptions (i.e., we could remove it if exceptions never had to be handled). This is in accordance to the ideas of Eaddy et al. [Eaddy, Aho and Murphy 2007]. This definition includes catch blocks, finally blocks and the definition of try blocks (but not the code within a try block). It excludes throw statements and throws clauses, as well as code that checks for erroneous conditions. In this study, eight different programmers conducted the extraction of the exception handlers. These programmers worked in pairs. Each pair systematically reviewed the work of the others. The first step of exception handler extraction was to move exception handlers out of the regular Java classes to Java classes concerned only with exception handling (handler classes). One handler class was created for each package in the system. Only the contents of catch and finally blocks were removed to these classes and the catch and

0 http://eclipse-cs.sourceforge.net/0 http://java.sun.com/developer/releases/petstore/0 http://java.sun.com/j2ee0 http://www.jhotdraw.org/

44

finally blocks therefore contained only calls to the new handler methods. Figure 1 present an example of this refactoring. Figure 1(a) presents the original code whereas Figure 1(b) shows the same method after its exception handler is extracted to a handler class. Figure 1(c) shows the affected parts of a handler class. If a catch or a finally block writes (in primitives types) or performs assingments to a private field of the enclosing class, or a local variable or parameter of the enclosing method, this refactoring cannot be performed, because these elements are not accessible to a handler class.

The second step of the extraction consisted of moving to aspects (handler aspects) the error handlers of the original version of each target system. One handler aspect was created for each package in the system. For uniformity’s sake, we employed only around advice to implemente handlers (handler advice), since they are powerful enough to implement a wide variety of error handling strategies [Castor et al 2006]. In this phase of the study, we created new advice on a per-tryblock basis, i.e., all the catch blocks associated to a try block in the original version of each system were moved to the same advice. The finally blocks were moved to separate advice to promote the conceptual separation between exception handlers and clean-up actions. Figure 1(d) shows a class affected by AO refactoring, where the try-catch blocks were removed. Figure 1(e) presents the resulting handler advice. In cases where a handler depends on fields of the enclosing class, we declare the aspects to which they are extracted to be privileged. On the other hand, when a handler depends on local variables of the enclosing method, we first employ the Extract Method [Fowler 1999] refactoring to expose these variables as parameters of the new method and then extract the handler to an aspect. In a small number of situations, e.g., a handler that writes to two or more local variables of the enclosing method, it was not possible extract exception handlers to aspects without redesigning of the original system. The handlers in these cases were not modified.

2.3 Reusing Exception Handlers

To reuse exception handlers, a similar approach was conducted for both the refactored OO versions and the AO versions, taking into account the differences between the two paradigms. For the refactored OO versions, we first put all the exception handling code that could be extracted to classes in a single class per package. Next, we look for similar exception handlers within the handler class of each package. Methods implementing duplicated exception handlers are eliminated and references to these methods are modified to point out to the appropriate handlers. Each handler class is systematically reviewed by at least two pairs of developers. The next step is to combine duplicated handlers appearing in different packages. In this case, we compare handler classes across unrelated packages. In this case, duplicated handlers are moved to a global parente handler class and the handler classes are modified to inherit from it. Whenever, due to reuse, a handler class becomes empty, we remove it from the system.

For the AO versions, we start by putting all the source code relative to the capture and handling of exceptions in a single aspect per package. Then, we check the possibility of reuse inside each package. The complicating factor in this case is the flexibility of AspectJ. For example, diferente (unrelated) return types do not necessarily mean that two handler advice cannot be combined. This greater flexibility also means that developers have more issues to consider, when combining handler advice, e.g., the return type of the method to which the handler advice will be associated, the number of

45

arguments of the method, if other exceptions can be thrown, etc. In addition, sometimes the sets of catch blocks associated to different try blocks cannot be reused, but the individual catch blocks can. In these fairly frequente situations, it is necessary to create handler advice on a percatch block basis, instead of a per-try block basis.

After checking if there are reuse possibilities inside each package, we proceed as described for the refactored OO versions. A global general aspect was created to contain the similar handlers that are duplicated across diferente packages. However, differently from the general handler class, there is no inheritance relationship between the handler aspects. Due to the limited form of inheritance supported by AspectJ and the richer reuse scenarios promoted by AOP, we found that aspect inheritance would not suit our needs.

46

Figure 1 - Examples of the extraction of exception handling code.

Figure 2 illustrates the amount of exception handling code reuse that could be achieved in some situations. Figure 2(a) shows a simple method that is called by twelve different catch blocks. Figure 2(b), shows the same exception handler in the AspectJ version of the system. The handler in this case is not called by any catch blocks. Instead, it is associated to twelve different join points in the system. It is important to stress that scenarios such as this one are only possible when exception handlers are very simple. Even though some amount of reuse is possible with more complicated handlers, this is not always easy to spot and is limited to a few places in the code.

47

Figure 2 - Examples of the reused exception handling code.

2.4 Metrics Suite

We evaluated the three versions of each target system based on a suite of code metrics. To collect them, we used a tool that we have developed as an extension to AopMetrics 0, EH-Meter0. The latter is a metrics collection tool that Works with both Java and AspectJ programs. Since this study focuses on evaluating reuse, we choose a set of metrics capable of measuring quantities that, we believe, indicate exception handling reuse or the lack thereof. More specifically, we have selected 11 metrics, all but one of them directly applicable to the error handling concern. For all the employed metrics, a lower value is better.

The selected metrics are divided in two groups: size metrics and concern metrics. Table 1 lists these metrics and briefly describes them. The first group, size metrics, includes metrics for both general system attributes (e.g. Number of Lines of code) and quatities that are specific to exception handling (e.g. Number of try Blocks). The selected size metrics are: number of Lines Of Code (LOC), Number of try blocks (NOT), Number Of Catch blocks (NOC), Number Of Finally blocks (NOF), number of Lines Of Code implementing Exception Handling (LOCEH), and Number of Exception Handlers (NEH). The latter counts the number of blocks of code that implement exception handling strategies. It is useful to quantify reuse of exception handling in the refactored OO versions.

0 http://aopmetrics.tigris.org/0 http://www.dsc.upe.br/~jcft2/eh-meter

48

Concerns metrics, measure how the source code is directed to analyze concerns [Tarr et al. 1999]. We employ these metrics to assess the extent to which the modularization of exception handling influences reuse and vice-versa. Moreover, some of these metrics simply count the number of occurrences of a certain kind of element pertaining to a specific concern. This is not different from what the aforementioned size metrics do. In this study, we consider only two concerns: exception handling and the main system functionality, which comprises all the remaining system concerns. The first three metrics [Sant'Anna et al. 2003] are well-known in the AO software development community: Concern Diffusion over Components (CDC), Concern Diffusion over Operations (CDO), and Concern Diffusion over LOC (CDLOC). The justification for using those metrics is to verify the diffusion of the exception handling concern, analising: (i) how many componentes (classes and aspects) and operations (methods) implemente the exception handling concern; and (iii) how many transitions exists between exception handling and normal behaviour.

Table 1 - The employed metrics suite

In addition, we use two more recent metrics that were proposed in order to circumvent some of the limitations of the aforementioned concern metrics. The first one, Lack Of Focus (LOF), is an adaptation of the Degree Of Focus (DOF) metric, proposed by Eaddy et al. [Eaddy, Aho and Murphy 2007]. DOF measures the extent to which a component’s lines of code are dedicated to the implementation of a given concern. Its value ranges between 0 (completely unfocused) and 1 (completely focused). A component’s LOF is equal to 1 – DOF. The last concern metric, Degree of scattering (DOS) [Eaddy, Aho and Murphy 2007] measures the extent to which the LOC related to a concern are contained within a specific component. More information about DOF and DOS is available elsewhere [Eaddy, Aho and Murphy 2007].

3. Study ResultsThe main goal of this study is to check if AOP promotes greater reuse of exception handling code than a traditional, object-oriented approach. It also attempts, to a certain extent, to understand the relation between reuse and modularization of exception handling. The employed metrics support the evaluation of the changes applied to code, highlighting the benefits and drawbacks stemming from these changes. We investigate the impacts in reuse and separation of concerns of using aspect-oriented programming to modularize exception capture and handling. Besides this, refactored objectoriented versions of each application were developed to guarantee a better reuse. The refactored OO version was employed in order to make the comparison between OOP and AOP

49

fair, since the original version of each target system was not designed or implemented with exception handling reuse in mind.

Table 2 presents size metrics collected from the three versions of each target system. Original OO indicates the original OO versions. Ref. OO refers to the object-oriented refactored versions, and Ref. AO indicates the aspectoriented refactored versions. A percentage increase (% Incr.) indicates that the values of the metrics have increase after refactoring an application, when compared with the original version. As previously mentioned, for almost all the employed metrics, a lower value is better. The only exception is metric LOC=0 (Table 3), where it is not really possible to infer if a value is good or not without comparing it with the value of the same metric for a different version of the same system. In this case, higher is better.

Some results of the metrics presented expected values. For number of try blocks (NOT), number of catch blocks (NOC) and number of finally blocks (NOF) there was no variation between Original OO and Ref. OO versions. However, their values decreased sensibly for all the target systems, in many cases by more than 40%. This indicates that try, catch, and finally blocks are being reused in the Ref. AO versions, although not as much as reported by Lippert and Lopes (2000).

The number of LOC grew in the refactored versions of all applications. Even though the increment might seem to be small (between 0.51% and 3.38%), it is considerable if we consider that it is solely a consequence of attempting to better modularize exception handling. In a similar vein, the Lines of Exception Handling Code (LOCEH) metric increased for all the refactored versions of the target systems. This overhead, affecting LOC and LOCEH, occurred because: (a) the Ref. OO version has more source code from calling new methods and new classes, and from method declarations; (b) in the Ref. AO version we need to create new aspects, advice, pointcuts and sometimes use the declare soft intertype declaration to suppress the checks that the Java compiler performs for checked exceptions.

The Number of Exception Handlers (NEH) metric decreased in both Ref. OO and Ref. AO versions. The reduction in the value of the metric for these versions of the applications stems from the separation between exception capture and exception handling. Since the handlers in the Ref. OO versions are methods whose parameters are the exceptions to be handled, in many cases these methods can take as arguments exceptions of types that are more general than the actual types of the exceptions being handled, thus creating new opportunities for reuse. This is possible because the exceptions are still captured in terms of their specific types, avoiding exception subsumption [Robillard and Murphy 2003]. In the Ref. AO versions, since capture and handling of exceptions are performed by the advice, the latter must catch the exceptions using their specific types, to avoid catching exceptions unintentionally. If, in the Ref. AO version, the handler advice were responsible solely for handling exceptions and regular try-catch blocks were responsible for capturing them, it would be possible to achieve an even greater amount of reuse than was achieved in the Ref. OO versions.

Table 2 - Size Metrics Results. Shows the absolute values and the increments with respect to measurements for the original version.

50

Table 3 exposes results relative to the concern metrics. Metrics CDO (Concern Diffusion of Operation), CDLOC (Concern Diffusion of Lines of Code) and CDC (Concern Diffusion of Components) indicate how the exception handling concern is scattered and tangled throughout the application. Version Ref. AO obtained the best results for all the target systems. This result is consistent with results obtained in previous studies [Castor et al 2006], pertaining to the ability of AOP to textually separate error handling from other system concerns. The values of CDO and CDLOC for the Ref. AO versions of the target applications decreased by more than 50%. The values for CDO indicate that fewer operations in the systems implement the exception handling concern (less scattering). The obtained values for CDLOC point out that there is almost no intermingling between error handling code and code implementing other concerns (less tangling). In the Ref. OO versions, try, catch and finally were not removed from the Java classes, unlike the Ref. AO versions. In additions, new methods solely responsible for handling exceptions were created in the handler classes. As a consequence, the values of CDO and CDC were strongly affected. On the other hand, the values for CDLOC remained largely unaffected, since no new concern transition points (Section II.D) were created.

The LOF (Lack of Focus) metric is normalized and Table 3 presents two different pieces of information pertaining to it. First, it presents the average LOF for all the componentes of each target application. Table 3 also indicates the number of components where LOF is 0 (LOF=0). By comparing the values of LOF=0 for the different versions of a target system, it is possible to assess the extent to which each approach for modularizing exception handling results in a system where each system component is focused on a single concern, a desirable property.

In the Ref. AO version both the average LOF and the number of components where LOF is 0 were better than the others versions. These results mean that, in the Ref. AO versions, error handling components are only responsible for handling exceptins and non-error handling componentes almost never handle exceptions (as highlighter by the CDLOC results). The LOF and LOF=0 results for the Ref. OO versions were slightly better than the ones for the original versions of the applications. This result must be analyzed with care, though. Since CDLOC did not change in the Ref. OO versions, it is possible to deduce that the system components that are present in both original and Ref. OO versions did not get more focused because they still mix error handling and normal behavior. Hence, the improvement in the value of these metrics for the Ref. OO versions is a consequence of the error handling components. They are highly focused and increase the overall number of system components.

51

The last metric presented in Table 3 is DOS (Degree of Scattering). Similarly to DOF, the value of this metric is normalized between 0 and 1. A value of 0 for this metric means that the implementation of a concern is entirely contained within a single program unit. A value of 1 means that the implementation of a concern is scattered throughout all the components of the system. For this metric, the Ref. AO versions exhibited the best results, although not by a large difference. This is understandable, since the Ref. AO versions concentrate all the error handling code within the aspects, thus reducing the number of program units responsible for this concern. The Ref. OO versions had slightly worse results than the original ones because the implementation of error handling is scattered throughout a larger number of components. Finally, for all the versions of all the systems, the values of DOS were very high. Since this study only considers two concerns (exception handling and the normal behavior), it is natural that at least one of them (the normal behavior) is scattered throughout the system components.

The percentage of increment for each metric is presented in Figures 3 and 4. The size metrics are depicted in Figure 3 whereas the increments related to concern metrics are presented in Figure 4. Looking up these figures we can conclude that, for each approach to modularizing exception handling, the three target applications were consistent when each metric is considered. For example, all the Ref. AO versions exhibited a lower number of try blocks and a greater amount of lines of exception handling code. This suggests that the obtained results might be applicable to a wider range of applications.

Table 3 - Concern Metrics Results. Shows the absolute values and the increments with respect to measurements for the original version.

52

Figure 3 - How the size metrics changed for the Ref. OO and Ref. AO versions.

Figure 4 - How the concern metrics changed for the Ref. OO and Ref. AO versions.

A careful analysis of the figures reveals some interesting points. First of all, there is a relationship between reduction in LOC and reuse when using AOP. JHD, the system where the lowest amount of reuse could be achieved, was also the one where LOCEH grew the most. This indicates that reuse of exception handlers actually influences the final number of LOC. Nonetheless, the overhead of using AOP, in terms of LOC, is considerable. For all the systems, LOCEH grew by at least 25%. Most importantly, this overhead is, for all the situations we have analyzed so far, much greater than the economy in LOC afforded by AOP. This observation raises another important point. This study has evidenced that, when applied in the modularization of error handling, AOP promotes reuse. However, it is not clear whether this reuse results in code that is more maintainable or understandable. Arguably, developers attempting to understand a system where exception handling is modularized with aspects would need to understand a greater number of modules and a larger number of LOC. Moreover, exception handling aspects influence program control flow in subtle ways that are not evidenced by the code [Coelho et al. 2008][Cacho at al 2009].

53

4. Related WorkSeveral researchers have tried to evaluate advantages and disadvantages of employing AOP to modularize crosscutting concerns [Castor et al 2006][Coelho et al. 2008][Figueiredo et al. 2008][Garcia et al. 2006][Greenwood 2007][Hoffman and Eugster 2008][Lippert and Lopes 2000]. The seminal paper on AOP [Kickzales et al. 1997] already referenced the exception handling concern as a good candidate to be modularized with aspects. There are specific studies that focus on implementing exception handling with aspects [Castor et al 2006][Castor, Garcia and Rubira 2007][Lippert and Lopes 2000]. Lippert and Lopes (2000) performed a study with a medium size reusable infrastructure (the JWAM framework) in which the goal was to modularize exception handling, extracting the exception detection and handling code to aspects. This study used the AspectJ language. This study found out that AOP promotes better tolerance to changes in the specification of the error handling behavior of a system, better support to incremental development, better reuse, and decreased system size.

Castor Filho et al. (2006) conducted another study about the adequacy of the AspectJ language to modularize exception handling. They refactored four full-fledged applications (three object-oriented and aspect-oriented), moving exception handling to aspects. This study employed a set of static code metrics to compare the refactored and original versions of each target system. Similarly to the Lippert and Lopes study, Castor Filho and colleagues concluded that the degree of tangling and scattering decreased with the aspectization. Moreover, despite the growing number of operations, these new operations were simpler and responsible solely for implementing error handling. Furthermore, this study found out that reusing exception handlers is difficult and that previous findings pertaining to the amount of reuse that could be achieved by using AOP were not generally applicable. A limitation of both of these studies is that they assumed a correlation between exception handler reuse and number of LOC. As evidenced by our study, this is not the case and large amounts of reuse can be achieved without a reduction in the number of LOC of the system.

Recently, Cacho and colleagues [Cacho at al 2009] devised a domainspecific extension of AspectJ, EJFlow, whose goal is to modularize error handling code. EJFlow includes mechanisms to associate exception handlers with exception flows in a Java program, providing developers with local control over global exceptions. The evaluation of EJFlow has shown it promotes increased reuse of exception handling code. Similar results were obtained by Hoffman and Eugster (2008), with the use of explicit join points (EJP), a means to reduce the amount of obliviousness of aspect-oriented programs. These two works represent importante improvements over AspectJ and their results are complementary to ours. In fact, the results of Setion 3 might serve as a motivation for the development of new language constructs aiming to improve AspectJ, in particular, and AOP languages, in general.

5. Concluding RemarksIn this paper, we presented a study aiming to assess the potential of different modularization approaches to promote intra-application reuse of exception handling code. More specifically, we compared aspect-oriented and objectoriented implementations of three different applications and employed a set of metrics

54

specifically targeting the exception handling concern. The study results have shown that aspectoriented programming promotes reuse of exception handling code. Even though a certain amount of reuse can also be obtained by employing pure OO programming, the study provides evidence that AOP allows for a larger amount of reuse while resulting in a better textual separation of concerns and less concern scattering. At the same time, for the three systems, there was considerably more code related to the error handling concern in the aspect-oriented versions of the target systems than in the object-oriented versions. These results contradict two previous well-known studies that evaluated the suitability of AOP to modularize error handling [Lippert and Lopes 2000][Castor et al 2006].

It is important make it clear that the modularization and reuse of exception handling was performed exclusively within each application. In the future, we plan to assess the possibility of reusing aspectized exception handling code across different applications, ideally based on a common underlying platform. Applications from different development platforms might use very different exceptions and handling strategies. Another thread of future work that we intend to follow consists of evaluating how the reuse promoted by AspectJ aspects affects software maintenance activities. Finally, our ultimate goal is to develop a tool capable of automatically detecting duplicated exception handlers and combining them into error handling aspects, so as to maximize code reuse

AcknowledgmentsWe would like to thank the anonymous referees, who helped to improve this paper. Júlio and Juliana are supported by CAPES/Brazil. Cristiane and Hítalo are supported by FACEPE/Brazil. Sérgio is partially supported by CNPq, grants 309234/2007-7 and 480489/2007-6. Fernando is partially supported by CNPq/Brazil, grants 308383/2008-7, 481147/2007-1, and 550895/2007-8. Emanoel and Nathalia are supported by CNPq/Brazil. This work is partially supported by the National Institute of Science and Technology for Software Engineering (INES), funded by CNPq and FACEPE, grants 573964/2008-4 and APQ-1037-1.03/08.

ReferencesCabral, B.; Marques, P. (2007), "Exception Handling: A Field Study in Java and .NET",

in Proc. of the 21st European Conference on Object Oriented Programming, Berlin, Germany.

Cacho, N; Dantas, F; Garcia, A; Castor, F. (2009), “Exception Flows made Explicit: An Exploratory Study”, in: Proceedings of the 23rd Brazilian Symposium on Software Engineering. Fortaleza, Brazil. October 2009. To appear.

Castor Filho, F. et al. (2006), “Exceptions and aspects: The devil is in the details”, in: Proceedings of the 14th SIGSOFT FSE, pages 152–162.

Castor Filho, F.; Garcia, A; Rubira, C. (2007), "Extracting Error Handling to Aspects: A Cookbook", In: 23rd IEEE International Conference on Software Maintenance.

Coelho, R; Rashid, A; Garcia, A; Ferrari, F. C.; Cacho, Nélio; Kulesza, Uirá; von Staa, A.; Lucena, C. J. P. (2008), “Assessing the Impact of Aspects on Exception Flows:

55

An Exploratory Study”, in : Proceedings of the 22nd European Conference on Object-Oriented Programming, pages 207—234, Paphos, Cyprus, July.

Cristian, F. (1979) “A recovery mechanism for modular software”, In: 4th ICSE, pages 42–51.

Dooren, M. van; Steegmans, E. (2005), “Combining the robustness of checked exceptions with the flexibility of unchecked exceptions using anchored exception declarations”, In: Proceedings of OOPSLA’05, pages 455–471.

Eaddy, M., Aho, A., Murphy, G. C. (2007), “Identifying, Assigning, and Quantifying Crosscutting Concerns”. Proceedings of the 1st Workshop on Assessment of Contemporary Modularization Techniques, Minneapolis, USA.

Figueiredo, E.; et al. (2008), “Evolving Software Product Lines with Aspects: An Empirical Study on Design Stability”, In: Proceedings of the 30th International Conference on Software Engineering, pp. 261-270.

Fowler, M. (1999), “Refactoring: Improving the Design of Existing Code”, Addison-Wesley.

Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. (1995), “Design Patterns: Elements of Reusable Software Systems”. Addison-Wesley.

Garcia, A.,; C. Rubira, C.; Romanovsky, A.; Xu, J. (2001), “A comparative study of exception handling mechanisms for building dependable object-oriented software”, In: Journal of Systems and Software, 59(2):197–222.

Garcia, A. et al. (2006), "Modularizing design patterns with aspects: A quantitative study. In: Trans. AOSD 2006, 1:36-74.

Goodenough, J. B. (1975) “Exception handling: Issues and a proposed notation.” Comm. of the ACM, 18(12):683–696.

Greenwood, P. et al. (2007), “On the impact of aspectual decompositions on design stability: An empirical study”, In: Proc. Of the 21st ECOOP.

Hoffman, K.; Eugster, P. (2008), “Towards Reusable Components with Aspects: An Empirical Study on Modularity and Obliviousness” In: Proceedings of the 30th

International Conference on Software Engineering (ICSE).

Juergens, E; Deissenboeck, F.; Hummel, B.; Wagner, S. (2009), “Do Code Clones Matter?”. In: Proc. of the 31st International Conference on Software Engineering (ICSE'2009), pages 485—495, Leipzig, Germany, May.

Kickzales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J.; Irwin, J. (1997), “Aspect-Oriented Programming”, In: ECOOP.

Kulesza, U. et al. (2006), “Quantifying the effects of aspect-oriented programming: A maintenance study”, In: Proc. of the 22nd ICSM, pages 223–233.

Laddad, R. (2003), “AspectJ in Action”, Manning.

Lippert M.; Lopes C. V. (2000), “A study on exception detection and handling using aspect-oriented programming”, In: Proceedings of ICSE’2000, pages 418–427.

Parnas, D. L.; W¨urges, H. (1976), “Response to undesired events in software systems”, In: 2nd ICSE, pages 437–446, San Francisco, USA.

56

Randell, B.; Xu, J. (1995), “The evolution of the recovery block concept”, In: Software Fault Tolerance, chapter 1, pages 1–21. John Wiley Sons Ltd.

Robillard, M.P.; Murphy, G.C. (2003) “Static analysis to support the evolution of exception structure in object-oriented systems”. ACM Trans. Softw. Eng. Methodol. 12(2): 191--221.

Sant'Anna, C.; Garcia, A; Chavez, C.; Lucena, C; Staa, A. von (2003), “On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework”, in: XVII Brazilian Symposium on Software Engineering, Manaus, Brazil.

Shah, H.; Görg, C.; Harrold, M. J (2008), “Why Do Developers Neglect Exception Handling?” Proceedings of the 4th International Workshop on Exception Handling , Atlanta, USA.

Tarr, P. et al. (1999), “N Degrees of Separation: Multi –Dimensional Separation of Concerns”. Proceedings of the 21st International Conference on Software Engineering.

Wong, W. E.; Gokhale, S. S.; Horgan, J. R. (2000), "Quantifying the closeness between program components and features,"Journal of Systems and Software, 54(2):87-98.

57

EH-Meter – Uma Ferramenta para Coleta de Métricas de Tratamento de Exceções

Júlio César Taveira1, Fernando Castor2, Sergio Soares1,2

1Departamento de Sistemas e Computação – Universidade de Pernambuco (UPE) Recife – PE – Brasil

2Centro de Informática – Universidade Federal de Pernambuco (UFPE) Recife – PE – Brasil

{jcft2, scbs}@dsc.upe.br, [email protected]

Abstract: Most of the existing metrics collection tools do not cover aspect-oriented programming languages. In addition, these tools implement generic metrics, not always appropriate to evaluate quality attributes pertaining to specific system concerns. This work presents a metrics collection tools specifically targeting the exception handling concern and capable of working with both Java and AspectJ programs. The proposed tool was employed to measure a number of software systems written in both languages.

Resumo: A maioria das ferramentas de coleta de métricas existentes não contemplam linguagens de programação orientadas a aspectos e adicionalmente, implementam métricas genéricas, nem sempre ideais para avaliar atributos de qualidade relativos a interesses específicos do sistema. Este trabalho apresenta uma ferramenta que coleta métricas referentes ao interesse de tratamento de exceções em sistemas escritos nas linguagens Java e AspectJ. A ferramenta proposta foi utilizada na coleta de métricas em vários sistemas escritos nessas duas linguagens.

1. IntroduçãoMétricas estáticas de código são amplamente utilizadas para avaliar atributos de qualidade de sistemas de software [Sommerville 2007]. Métricas de código podem fornecer desde informações básicas, como número de linhas de código e de módulos no sistema, até informações mais refinadas como as dependências entre os elementos do sistema e o quão focados esses elementos são [Ceccato e Tonella 2004, Eaddy et al. 2007]. Idealmente, métricas de código devem ser coletadas de maneira automática, a fim de acelerar o processo de medição, evitar os erros inerentes à coleta manual e garantir a uniformidade dos resultados, tornando possível a realização de comparações. Existem diversas ferramentas capazes de coletar métricas estáticas de código a partir de programas escritos em diferentes linguagens de programação. Por exemplo, Metrics0 e FindBugs0 coletam diversas métricas a partir de programas escritos em Java.

Apesar da crescente popularidade da programação orientada a aspectos (POA) [Kiczales et al. 1997], há poucas ferramentas de coleta de métricas capazes de medir programas escritos em linguagens de POA. Um exemplo de tais ferramentas é o AOPMetrics0, que coleta métricas de programas em AspectJ [Laddad 2003], uma

0 http://metrics.sourceforge.net/0 http://findbugs.sourceforge.net/0 http://aopmetrics.tigris.org/

58

extensão orientada a aspectos da linguagem Java. Para que POA possa se consolidar como o próximo passo na evolução das linguagens de programação, essa técnica precisa ser avaliada exaustivamente, idealmente tanto qualitativa quanto quantitativamente.

Até onde foi possível averiguar, todas as ferramentas de coleta de métricas existentes trabalham com métricas gerais, aplicáveis a todos os interesses (do inglês: concerns) de um sistema. Consequentemente, não é possível avaliar alguns atributos de qualidade no contexto de interesses específicos. Entretanto, alguns autores [Castor et al. 2009, Eaddy et al. 2008, Couto et al., 2009] acreditam que, para avaliar o impacto de novas abordagens de desenvolvimento, como POA, em atributos de qualidade como reuso, métricas focadas em interesses específicos são mais eficazes do que as independentes de interesse. Utilizar apenas métricas que se aplicam ao sistema como um todo, sem levar em conta os interesses que o compõem, pode fazer com que a avaliação de tais abordagens não reflita adequadamente seus benefícios e limitações.

Este trabalho propõe uma ferramenta de coleta de métricas que visa preencher parcialmente essa lacuna. A ferramenta proposta, chamada de EH-Meter, é capaz de coletar 11 métricas descritas em diferentes trabalhos na literatura [Eaddy et al. 2007, Sant’Anna et al. 2003] a partir de programas escritos em Java ou AspectJ. Dez dessas métricas lidam com um interesse específico, tratamento de exceções. O interesse de tratamento de exceções foi escolhido por dois motivos: (i) é o alvo de vários trabalhos realizados pelos autores no passado; e (ii) é um interesse demarcado sintaticamente no código do programa, o que evita dificuldades ligadas à mineração de interesses [Robillard e Murphy 2002] e permite que o foco se mantenha na atividade de medição.

2. FuncionalidadesNessa seção são descritas as métricas que foram implementadas e maneira como o EHMeter pode ser utilizado na prática.

Métricas Implementadas. O EH-Meter é capaz de colher diversas métricas relativas ao interesse de tratamento de exceções. As métricas escolhidas são divididas em dois grupos: métricas de tamanho e métricas de interesses. O primeiro grupo engloba diversas métricas que visam determinar a quantidade de código em um sistema relativa ao interesse de tratamento de exceções. Para tanto, inclui desde métricas tradicionais, como numero de linhas de código (tanto total quanto especificamente de tratamento de exceções) e outras menos comuns, como números de blocos catch e finally. Essas métricas são apresentadas e descritas na parte superior da tabela Tabela 1. Para as métricas NOT, NOC e NOF, caso o bloco try (catch, finally) apareça dentro de outro bloco catch ou finally (mas não try), ele não é levado em conta. A justificativa para isso é que, para fins de separação de interesses, tal bloco não precisaria ser separado pois não está misturado a outros interesses.

O outro grupo de métricas, relativas a separação de interesses, tem o intuito de medir o quanto o código está direcionado aos interesses analisados, que no caso desse trabalho é o tratamento de exceções, e separado do código relativo aos outros interesses do sistema. Essas métricas são também apresentadas na Tabela 1, na parte inferior. As três primeiras delas mostram valores absolutos, para os valores coletados. As duas últimas métricas relativas a interesses contabilizam de forma normalizadas os valores apresentados. Para todas as métricas, um valor menor implica em um resultado melhor.

59

Execução e Resultados da Ferramenta. Do mesmo modo que a ferramenta AopMetrics, a ferramenta EH-Meter também funciona através de tasks do Apache Ant0. Através de um arquivo de configurações XML é especificado quais serão os programas Java que a ferramenta vai analisar, quais as bibliotecas que devem ser utilizadas como referência, versão da linguagem e o nome do arquivo de saída. Arquivo de saída produzido pela ferramenta é uma planilha eletrônica no padrão do Microsoft Excel. Essa planilha contém, para cada componente do sistema, o valor de cada uma das métricas, descritas na Seção 2.1. Apenas a métrica DOS depende do sistema completo.

3. ImplementaçãoO EH-Meter é uma extensão da ferramenta AopMetrics. Para facilitar a implementação do EH-Meter, recursos como os parsers para Java e AspectJ o engenho de coleta de métricas do AopMetrics foram utilizados. Para a maior parte das métricas, foi necessário apenas implementar as classes responsáveis pelas novas métricas. Algumas delas, porém, exigem que a medição seja feita de um modo diferente do que tradicionalmente acontece no AopMetrics, levando em conta o sistema como um todo. Para estes casos, foi necessário modificar o engenho de medição do AopMetrics.

Arquitetura e Modificações no Código Original. A arquitetura da ferramenta é simples, dividida em módulos (pacotes) com propósitos bem definidos. No pacote principal se encontram o código responsável por receber entradas do usuário para execução da ferramenta e outros recursos comuns a toda a ferramenta, como o engenho de coleta de métricas. Em outros pacotes, source e ajdt, são encontrados elementos que fazem referência a um projeto Java e AspectJ e transformações necessárias, respectivamente. O pacote metrics contém as classes que implementam as métricas a serem coletadas. A maior parte das alterações aplicadas ao AopMetrics resultaram em novas classes sendo incluídas neste pacote. Os últimos pacotes, export e results, contém o código responsável por exportar os resultados da medição para planilhas em formato XLS e como são as saídas das métricas. A Figura 1 mostra as dependências entre os pacotes do sistema.

Tabela 1 - Resumo das métricas, grupos e respectivas descrições.

0 http://ant.apache.org/

60

A primeira modificação para dar suporte às novas métricas diz respeito a como é calculado o valor para cada uma. Normalmente, as medições são executadas individualmente para cada componente (classe, interface e aspecto). Assim, cada métrica é executada uma vez para cada componente, retorna o valor resultante e a execução prossegue para o próximo componente, sem um valor intervir no outro. A métrica DOS, porém, é calculada para todos os componentes do sistema. Logo, foi necessário levar em conta os valores relativos a cada componente do sistema para poder fazer o calculo da métrica. Esse comportamento precisou ser incorporado ao engenho de coleta do AopMetrics, já que este é construído partindo da suposição de que todas as métricas podem ser coletadas de forma independente, para cada componente.

A segunda modificação diz respeito à listagem de todas as métricas. A classe Metrics contém todas as métricas que devem ser coletadas. Para o EH-Meter, foram adicionadas as novas métricas implementadas e suas respectivas strings de identificação. Ponto comum entre todas as métricas as métricas é a interface MetricsCalculator. Entretanto, essa interface é aplicável apenas para métricas que não precisam ser coletadas globalmente. Logo, a ultima modificação consistiu na criação de uma interface para abranger as métricas que sejam calculadas utilizando dados de todo o sistema. Essa interface foi denominada de MetricsCalculatorGeneral e pode ser usada na implementação de novas métricas com essa característica.

Novas Métricas. Para as novas métricas implementadas na maioria dos casos foi extendida a classe ASTVisitor, para detectar ocorrências de trechos de código relativos ao tratamento de exceções. Esses trechos de código na maioria dos casos foram ocorrências de blocos try (catch, finally), declarações de método e blocos de código. Para as métricas de tamanho (mostradas na Tabela 1), os resultados foram são

61

obtidos apenas através da contagem das ocorrências do pedaço de código desejado. Para métricas de interesses, interfaces não foram consideradas por não incluírem comportamento, sendo apenas analisadas classes e aspectos. CDC e CDO foram bem simples, bastando apenas marcar para cada componente e operação, respectivamente, a existência de haver códigos tratadores de exceções. Para LOF (medida utilizando DOF) e DOS, apenas foi necessário utilizar informações de outras métricas e trabalhar corretamente com os valores.

A Métrica CDLOC é a que apresenta a implementação mais complexa. Em todos os trabalhos anteriores dos quais temos conhecimento [Castor Filho et al. 2006, Castor et al. 2009, Garcia et al. 2005, Sant'Anna et al. 2003], essa métrica foi coletada manualmente. A Figura 2 mostra um exemplo de como é diferenciado as áreas de transições entre o interesse do tratamento de exceção (fundo amarelo) e o interesse de comportamento normal do sistema (fundo branco). Na implementação, foi necessário detectar e marcar essas áreas, a fim de calcular as transições. Para essa métrica, têm que ser levados em conta diversos casos de transição entre o código referente ao tratamento de exceções e o código relativo ao comportamento normal do sistema.

4. Um Estudo de CasoAtualmente, está sendo conduzido um estudo com o objetivo de identificar o efeito da modularização de tratamento de exceções usando POA no reuso do código desse interesse. Neste novo estudo, o EH-Meter é usado em todas as atividades de medição. Foram utilizados três sistemas, em versões Java e AspectJ, com diferentes características. No total, as medições foram aplicadas a nove versões distintas, 3 em AspectJ e 6 em Java. Enquanto a medição manual feita por dois desenvolvedores durou cerca de 16 horas para apenas uma das versões, a ferramenta coletou as informações em menos de um minuto. Além disso, a ferramenta foi empregada diversas vezes para refazer as medições de forma rápida. Adicionalmente, a contagem manual apresentou problemas de uniformidade que não ocorreram com a ferramenta.

O emprego de métricas centradas em um interesse ressaltou que POA de fato promove o reuso de tratadores de exceções. Também deixou claro que o código de tratamento de exceções cresce de maneira não desprezível quando extraído para aspectos em um sistema não-trivial. A combinação dessas duas descobertas complementa estudos anteriores [Castor Filho et al. 2006, Lippert e Lopes 2000] sobre POA e tratamento de exceções. Mais informações sobre esse estudo podem ser obtidas em outro trabalho [Taveira et al. 2009].

62

5. ConclusãoNeste trabalho foi apresentada a ferramenta EH-Meter, que implementa métricas específicas de tratamento de exceções. Foram descritas as métricas implementadas pela ferramenta, bem como sua arquitetura e as principais escolhas de projeto envolvidas no seu desenvolvimento. O EH-Meter é capaz de coletar métricas tanto a partir de programas escritos em Java quanto de programas em AspectJ. Até onde pudemos averiguar, o EH-Meter é a primeira ferramenta capaz de coletar métricas para um interesse específico de forma completamente automática.

No Endereço, http://www.dsc.upe.br/~jcft2/eh-meter, a ferramenta EH-Meter está disponível. No mesmo endereço também está disponível o código fonte e também outras informações. A licença do EH-Meter é a GPL.

ReferênciasCastor Filho, F. et al. (2006), “Exceptions and aspects: The devil is in the details”, In:

14th SIGSOFT FSE, pages 152–162.

Castor, F. et al. (2009), “On the Modularization and Reuse of Exception Handling with Aspects”. Submitted to Software – Practice & Experience.

Ceccato, M. and Tonella P. (2004), “Measuring the Effects of Software Aspectization”, In: 1st Workshop on Aspect Reverse Engineering (WARE 2004).

Couto, C. F. M. et al. (2009), “Estimativa de Métricas de Separação de Interesses em Processos de Refatoração para Extração de Aspectos.”, In: VI Workshop de Manutenção de Software Moderna, Ouro Preto. p. 1-8

Eaddy, M., Aho, A., Murphy, G. C. (2007), “Identifying, Assigning, and Quantifying Crosscutting Concerns”, In: Proceedings of the 1st ACoM Workshop.

Eaddy, M. et al. (2008), “Do Crosscutting Concerns Cause Defects?”, In: IEEE Transactions on Software Engineering (34):July 2008, pp. 497-515.

Garcia, A. et al. (2005), “Modularizing Design Patterns with Aspects: A Quantitative Study”, In: 4th AOSD.

Kickzales, G. et al. (1997), “Aspect-Oriented Programming”, In: 11th ECOOP.

Laddad, R. (2003), “AspectJ in Action”, 1st ed., Manning.

Lippert, M.;Lopes, C. (2000), “A study on exception detection and handling using aspect-oriented programming”, In: Proceedings of the 22nd ICSE, pages 418-427.

Robillard, M. P.; Murphy, G. C. (2002), “Concern graphs: finding and describing concerns using structural program dependencies”, In: Proc. of the 24th ICSE.

Sant'Anna, C. et al. (2003), “On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework”, In: XVII SBES, Manaus, Brazil.

Sommerville, I. (2007), “Software Engineering”, 8th ed., Addison-Wesley.

Taveira, J. C. et al. (2009) “Assessing Intra-Application Exception Handling Reuse with Aspects”. Submitted to SBES'2009.

63

ODST: Uma Ontologia para o Domínio e Estudo das Doenças Sexualmente Transmissíveis

Armanda Maria Correia de A. Oliveira1, Lídia F. Nunes de Melo Roque1, Hugo Vieira L. de Souza2, Mauricio de Oliveira Dias Fernandes3.

1Centro de Informática – Universidade Federal de Pernambuco (CIn-UFPE) Caixa Postal 7851 – CEP 50732-970 – Recife – PE – Brasil

2Faculdade Escritor Osman da Costa Lins (FACOL) CEP: 55612-650 – Vitória de Santo Antão – PE – Brasil

3Faculdade Integrada do Recife (FIR) CEP: – 50720-635 – Recife – PE – Brasil{amcao, lfnmr}@cin.ufpe.br, [email protected],

[email protected]

Abstract: It's remarkable the rise of problems related to public health worldwide. From these problems, can be present relevance in the Sexually Transmitted Diseases (STDs), although they are not considered degenerative diseases are difficult to identify their symptoms, to diagnose and treat. From this, came the need to acquire more knowledge about the various aspects related to STDs in general, basing in a measure of information that cannot be ignore. Therefore, this paper proposes the ODST, an ontology developed using the Methontology methodology, that specify, formalize and store knowledge in a easy way about the STD, being able to group concepts, classes, constraints and properties.

Resumo: É notável a ascensão dos problemas relacionados à saúde pública no mundo. Desses, pode-se apresentar a extrema relevância em que se encontram as Doenças Sexualmente Transmissíveis (DST), pois apesar de não serem consideradas doenças degenerativas, são difíceis de identificar seus sintomas, de diagnosticar e tratar. Diante disto, surgiu a necessidade de aprofundar os conhecimentos sobre os vários aspectos referentes às DST em geral, fundamentando uma grande quantidade de informações impossíveis de serem ignoradas. Portanto, este artigo propõe a ODST, uma ontologia desenvolvida utilizando como metodologia a Methontology, capaz de especificar, formalizar e armazenar os conhecimentos de forma clara acerca do domínio das DST, sendo capaz de reunir inúmeros conceitos, classes, restrições e propriedades.

1. IntroduçãoAs Doenças Sexualmente Transmissíveis (DST) são um dos grandes problemas da saúde pública, atingindo milhares de pessoas e trazendo consequências em curto prazo, a exemplo das uretrites (doenças inflamatórias e infecciosas da uretra) e salpingites (doenças inflamatórias e infecciosas das trompas de falópio) e, em longo prazo, infertilidade, gravidez ectópica (gestação fora da cavidade uterina, ou seja, o embrião não se desenvolve no útero) e o câncer de colo de útero [TAQUETE, 2004]. Com isso, novas questões são apresentadas à sociedade e aos profissionais, com a necessidade de um maior cuidado por parte dos serviços de saúde na abordagem adequada àqueles que necessitam de atendimento e tratamento [FONSECA e PEREIRA, 2007].

64

Devido à complexidade do entendimento médico e biológico, o desenvolvimento de sistemas tradicionais torna-se difícil, pois para assistir tarefas médicas, os sistemas precisam de muito conhecimento e capacidade de inferência. Sendo assim, é preciso haver eficiência e confiabilidade nas informações, possibilitando o reuso e uso dos processos mais adequados. Destarte, a criação e desenvolvimento de ontologias tornam isso possível.

A medicina e a biologia estão entre as principais áreas de aplicação das ontologias, existindo centros de estudos dedicados exclusivamente para a prática desta tecnologia [FREITAS e SCHULZ 2009]. As ontologias padronizam o significado através de identificadores semânticos podendo representar o mundo real e conceitual. O processamento de informações através das ontologias facilita o entendimento das mesmas, tanto para os usuários quanto para os agentes de software tornando-se, assim, tendência nas mais diversas áreas e aplicações.

Este artigo propõe a ODST, uma ontologia para o domínio de doenças sexualmente transmissíveis. A partir da ODST considera-se que o entendimento no domínio das DST, bem como nos processos de tratamento, na prevenção e dentre outros assuntos relacionados, serão mais eficientes, além de auxiliar estudiosos em pesquisas científicas e profissionais da área de saúde, desenvolvendo, portanto, uma base de conhecimento com possibilidade de inserção de novas informações, permitindo ainda o desenvolvimento de outras ontologias a partir dela, proporcionando reuso. As seções deste artigo estão estruturadas da seguinte forma: a Seção 2 foca os métodos utilizados para o desenvolvimento da ODST, enquanto que a Seção 3 apresenta a proposta e os resultados parciais. Por fim, na Seção 4 apresentam-se as considerações finais.

2. MétodosA seguir serão apresentados os métodos utilizados no desenvolvimento da ODST.

2.1 Estudo das DST

As DST, também conhecidas por doenças venéreas, são doenças cujo principal meio de transmissão é através da relação sexual e do contato íntimo com órgãos genitais [Araújo et al 2009]. Existem diversos tipos de DST, podendo-se listar algumas tais como: Acquired Immune Deficiency Syndrome – Síndrome da Imuno Deficiência Adquirida (AIDS), Sífilis Congênita, Herpes Genital, Clamídia, Gonorréia, dentre outras. Em virtude da complexidade dos estudos relacionados às DST, considera-se a relevância de vários aspectos, como meios de transmissão, disseminação e contaminação da doença, as maneiras de prevenção e conscientização da população em geral e os meios de tratamentos imediatos utilizados para as DST.

2.2. OntologiaO conceito de ontologia foi originado a partir da filosofia, onde Onto significa Ser e Logos, Lógica. Um dos principais conceitos de ontologia, diz que “uma ontologia é uma especificação explícita e formal de uma conceitualização compartilhada” [GRUBER, 2003]. Para a Inteligência Artificial (IA) as ontologias possuem destaque, pois reúnem conceitos diversificados acerca de determinado domínio, constituindo um vocabulário com uma definição exata do conhecimento, além de possibilitar a modelagem, o compartilhamento e o reuso das informações por outros desenvolvedores para a

65

construção de ontologias de diversos domínios, facilitando o entendimento e a interpretação dos dados disponibilizados na web.

Além disso, há uma vasta disponibilidade de ontologias para os mais diversos domínios, com possibilidade de tradução entre as linguagens e os formalismos de representação de conhecimento. É possível ainda o armazenamento on-line de ontologias, possibilitando acesso às classes e instâncias por empresas e/ou grupos de estudos, disponibilizando uma variedade de domínios e mapeamento entre os formalismos de representação de conhecimento [Freitas 2009].

2.3. Methontology

A metodologia Methontology foi desenvolvida no laboratório de IA da Universidade Politécnica de Madri. Esta metodologia permite a construção de ontologias baseadas no processo padrão de desenvolvimento de software do Institute of Electrical and Electronics Engineers (IEEE) [CORCHO et. al., 2000].

A Methontology tem como finalidade auxiliar no processo de desenvolvimento de ontologias, de modo a facilitar a integração dos profissionais pertencentes à equipe, definindo e alocando as atividades em três grupos para construção da ontologia, tais como: atividades de gerenciamento de ontologias, atividades ligadas ao desenvolvimento de ontologias e atividades de suporte [BREITMAN, 2005]. O processo de desenvolvimento de ontologias, proposto pela Methontology, segue as seguintes etapas: Planejamento, Especificação, Conceitualização, Formalização, Integração, Implementação, Avaliação, Documentação e Manutenção [FERNÁNDEZ et. al., 1997].

2.4. Framework Protegé

O framework Protégé, segundo o Protégé (2009), é um ambiente integrado para edição de ontologias e construção de sistemas baseados em conhecimento, podendo ser usado também para carregar, editar e salvar ontologias em vários formatos, tais como, RDF, XML, OWL, Unified Modeling Language – Linguagem de Modelagem Unificada (UML), entre outros. Dentre essas linguagens, a mais utilizada é a OWL, podendo subdividir-se em três: OWL Lite, OWL DL e OWL full. O framework Protégé atualmente encontra-se na versão 4.0 para desenvolvimento de ontologias em OWL, possuindo ainda tutoriais para auxiliar a instalação e manipulação do mesmo.

2.5. OWL DL

A OWL DL proporciona um elevado grau de expressividade à medida que mantém a decidibilidade. Apresenta a semântica e as propriedades bem definidas, e a completude de sistemas de raciocínio, tendo como base a Lógica de Descrição (DL – Description Logics) e, devido a isto, a extensão DL [CASARES, 2005]. A OWL DL contém algumas restrições, como por exemplo, a separação cautelosa dos tipos, evitando que um componente da ontologia possa obter duas classificações, ou seja, impede que uma classe seja uma instância e uma propriedade ao mesmo tempo, permitindo também a verificação da classificação de hierarquia.

66

3. Proposta e Resultados ParciaisSabendo que a necessidade de armazenar as informações referentes às DST está em ascensão, ao mesmo tempo que a utilização de ontologias torna-se um artifício para descrever um determinado domínio de conhecimento, este artigo propõe a ODST, a qual será capaz de especificar, formalizar e armazenar conhecimentos, de forma clara, reunindo inúmeros conceitos, classes, restrições e propriedades referentes as DST.

A ODST foi desenvolvida utilizando o framework Protégé 3.4, além de seguir os passos definidos pela metodologia Methontology. A linguagem utilizada foi a OWL DL, que incorpora facilidades para publicar e compartilhar a ontologia proposta na web, além de ser a linguagem ontológica da web [BERNERS-LEE e HENDLER, 2001]. A ODST apresenta todas as classes como subclasses da classe Thing (do framework Protégé) onde essas classes são definidas através de descrições.

Apresenta-se na Figura 1 deste artigo, parte do modelo implementado gerado pelo plugin OWL VIZ do framework Protégé, demonstrando as principais entidades definidas na ODST. As classes da ODST são representadas através de retângulos, necessariamente interligadas através das linhas de cor azul e preta, referentes aos relacionamentos entre as classes e a determinação das subclasses respectivamente.

Figura 1 - Entidades da ODST Fonte: [próprio autor, 2011]

As principais classes da ODST são:

DST: classe principal da ontologia, onde o processo está designado de acordo com o domínio exposto, ou seja, o domínio das DST. A partir dela, derivam-se várias outras classes, onde posteriormente serão especializadas, contendo instâncias referentes ao armazenamento específico das informações e tendo como base o levantamento de requisitos;

TIPOS: esta classe armazena alguns dos tipos principais de DST, informação essencial para estudiosos buscando conhecer os diversos tipos de DST;

TRATAMENTO: esta classe armazena os principais tratamentos das DST, mostrando quais tratamentos podem ser realizados para curar ou melhorar as condições de saúde do paciente;

MEIOS DE TRANSMISSÃO: classe responsável por armazenar informações sobre os meios de transmissão das DST;

67

PREVENÇÃO: classe responsável por armazenar dados sobre os meios de prevenção das DST;

CONSEQUÊNCIAS: classe que contém informações sobre as principais consequências das DST. A partir dela são geradas subclasses como, por exemplo, INFLAMAÇÕES, que informa sobre a incidência e ocorrência das inflamações ocasionadas pelas DST;

Para utilização da ODST, alguns cenários podem ser utilizados, citando a exemplos: Estudos para expandir o conhecimento a respeito das DST: pretende-se

através da ODST expandir as informações referentes às DST nas bases de conhecimento.

Pesquisas científicas: auxiliar as pesquisas científicas com objetivos de buscar técnicas de tratamentos para as doenças já existentes, novos modos de prevenção e até a descoberta de novas doenças.

Novos programas governamentais: a ODST poderá auxiliar em programas governamentais principalmente para a população de baixa renda com relação à conscientização sobre as DST e suas técnicas de prevenção;

Área acadêmica e educativa: a ODST também deverá ser capaz de atender as necessidades da área acadêmica e educativa, auxiliando os profissionais a ministrarem os conteúdos de uma forma mais eficiente e dinâmica.

Espera-se que a ODST auxilie a comunidade científica no desenvolvimento de estudos e pesquisas relacionados à saúde, possibilitando a origem de novas ontologias para domínios específicos ou de atividades da área da saúde, além de servir de base para estudiosos da área da saúde no desenvolvimento de novos tratamentos ou medicamentos para as DST.

Com o intuito de validar o trabalho, a ODST deverá ser capaz de possibilitar a busca e reutilização das informações referentes ao domínio, sendo então capaz de responder as seguintes questões de competência: (a) Quais os principais meios de transmissão e prevenção atuais das DST? (b) Quais os tipos de doenças consideradas DST e as bactérias responsáveis pela sua propagação? (c) Quais os danos individuais ou sociais gerado pelas DST?

4. Considerações FinaisNeste artigo foi apresentada a ODST, uma ontologia para o domínio das Doenças Sexualmente Transmissíveis, a qual se constituirá em uma ferramenta computacional com potencialidade interdisciplinar, unindo os campos da tecnologia da informação com a área de saúde. Após a conclusão do levantamento bibliográfico e da construção da base da ontologia, será iniciado um estudo mais aprofundado sobre o domínio, o que permitirá estender as funcionalidades da ontologia.

Pretende-se em trabalhos futuros, estender as funcionalidades da ODST, de modo que sejam adicionadas maiores informações a respeito de novos conceitos e novas técnicas de tratamento e prevenção, sempre proporcionando o reuso das mesmas para domínios específicos. Considerando o levantamento de informações que já foi concluído, a finalização e a validação da ontologia serão realizadas de forma gradativa, sendo possivelmente, necessários alguns ajustes conceituais. Por fim, considera-se que o entendimento e os processos das DST serão mais eficientes tendo como base um

68

modelo formal de informações, as quais podem ser reutilizadas para a construção de ontologias de aplicações.

ReferênciasARAÚJO M A L; DIÓGENES S, SILVA, R M. (2005) Comportamento De Homens

Com Dst Atendidos Em Unidade De Saúde De Referência De Fortaleza. DST – J bras Doenças Sex Transm 17(2):107-110 [atualizado em 2005; citado em 20 setembro 2009]. Available from: http://www.uff.br/dst/revista17-2-2005/3-comportamento%20de%20homens.pdf

BERNERS-LEE T, HENDLER J L. (2009) The Semantic Web. In Scientific American [updated 2001, cited Nov 2009. Available from: http://www.sciam.com/article.cfm?SID=mail&articleID=00048144-10D2-1C70-84A9809EC588EF21

BREITMAN K. (2005) Web Semântica: A Internet do Futuro. São Paulo, 2005.

CASARE S J. (2005) Uma Ontologia Funcional de Reputação para Agentes [atualizado em 2005, citado em 01 Agosto 2009]. São Paulo, 2005. 170f Texto (Mestrado em Engenharia Elétrica) Escola Politécnica da Universidade de São Paulo – USP, São Paulo 2005. Avaliado de: http://www.teses.usp.br/teses/disponiveis/3/3141/tde-22052006-221632.

CORCHO O, et al. (2005) Building legal ontologies with METHONTOLOGY and WebODE. In Benjamins, R.; Casanovas, P.; Breuker, J. & Gangemi, A. (ed.): Law and the Semantic Web.

FREITAS F L G. (2009) Ontologias e Web Semântica [citado em 15 de agosto 2009]. Avaliado de: http://www.inf.ufsc.br/~gauthier/EGC6006/material/aula 3/ontologia_web_semantica Freitas.pdf.

FERNÁNDEZ M A, GÓMEZ-PÉREZ A, JURISTO N. (1997) Methontology: From ontological art towards ontological engineering. In: Proceedings Of The Aaai Spring Symposium Series. P. 33-35

FREITAS F, SCHULZ S. (2009) Ontologias, Web Semântica e Saúde. In: RECIIS Revista Eletrônica de Comunicação Informação e Inovação em Saúde. Rio de Janeiro, v.3, n.1, p 4-7 março 2009.

FONSECA M G P; PEREIRA G F M. (2007) Doenças Sexualmente Transmissíveis e AIDS no Brasil do Século XXI: o desafio e a resposta. In: Cad. Saúde Pública. Rio de Janeiro, 2007.

GRUBER T R. (2010) Toward Principles for the Design of Ontologies used for Knowledge Sharing. In: International Workshop on Formal Ontology. Padova, [updated 2003 March; cited oct 2009.]. Available from: http://www.ahusieg.com/bibliography/bibpapers/ Grub93.pdf Acesso em:17 de dez. 2010

PROTÉGÉ. (2011) Protégé ontology editor. [Online]. Disponível: http://protege.stanford.edu/doc/users.html. Acessado em: Jan. 2011.

TAQUETE, R S, et al (2004). Doenças Sexualmente Transmissíveis na Adolescência: Estudo de fatores de risco. In: Rev. Soc. Bras. Med. Trop., Vol.37, No. 3.

69

70

Desenvolvimento distribuído de software utilizando Scrum: O estudo de caso do Firescrum.

Crescencio R. Lima Neto1, Emmanuel B. Carvalho1, Willame Pereira1, Rafael B. Di Bernardo1, Pietro P. Pinto1, Helaine Lins1, Jonatas Bastos1, Silvio R. L. Meira1

1Centro de Informática – Universidade Federal de Pernambuco (UFPE) Caixa Postal 7851 – 50.732-970 – Recife – PE – Brasil

{crln,ebc2,wpo,ppp,rbdb,hsl,jfb,srlm}@cin.ufpe.br

Abstract: This article discusses the empirical way, of impact and concepts about quality in software and documentation, testing approach, configuration management, level of knowledge and communication, applied to an adaptation of the agile methodology like Scrum for distributed teams. Broking the paradigm "Face to Face", a new challenge, to maintain the productivity and quality with some measure of communication and interaction between distributed teams to develop a framework Scrum called by FireScrum. The methodology focused interviews, analysis of documents, literature, the case study Project FireScrum in the subject of Software Engineering at the postgraduate UFPE.

Resumo: Este artigo aborda de forma empírica, o impacto de conceitos de qualidade de software como documentação, abordagem de testes, gerência de configuração, nivelamento do conhecimento e comunicação, aplicados a uma adaptação da metodologia ágil como SCRUM para times distribuídos. Na quebra do paradigma “Face to Face”, surge um novo desafio, o de manter a produtividade e qualidade com a medida certa de comunicação e interação entre times distribuídos para desenvolvimento de um framework SCRUM chamado FireScrum. A metodologia abordou entrevistas, análise de documentos, pesquisa bibliográfica, o estudo de caso do projeto FireScrum, na disciplina de Engenharia de Software na pós-graduação da UFPE.

1. IntroduçãoA globalização e o desenvolvimento tecnológico são os principais responsáveis por eliminar a barreira geográfica, permitindo que times localizados a quilômetros de distância interajam como se estivessem no mesmo ambiente. O fato é que a sociedade global, cada vez mais interconectada, se relaciona através da formação de centros que interagem constantemente, trocando produtos, conhecimentos e serviços, propiciando o desenvolvimento de inovações.

Neste contexto, destacam-se quatros mudanças principais: 1) A emergência e o fortalecimento de uma economia global; 2) A transformação de economias e sociedades industriais em economias de serviços, baseadas no conhecimento e na informação; 3) As mudanças do empreendimento empresarial e 4) O surgimento da empresa digital [Castells 2003], [Laudon 2005].

O mercado de projetos vem sofrendo impactos da crise econômica mundial e passa por mudanças. Neste clima de incertezas e constantes modificações, os atores deste setor se deparam com uma diminuição dos recursos disponíveis, limitação de

71

crédito, pressões por menores margens de lucro e problemas financeiros por parte dos clientes. Neste cenário, o processo decisório se torna mais longo e gera uma notável redução na demanda por projetos. A nova realidade exige que as organizações mudem sua forma de trabalhar para conseguirem sobreviver [Norris 2008].

As mudanças implicam em funcionar bem nos ambientes que mudam rapidamente, permitindo freqüentes avaliações do planejamento; Focar a maximização do retorno de investimento (ROI) do cliente; Possibilitar a redução do tempo de entrada em produção ou o tempo de lançamento do produto no mercado; Evitar desperdício de esforço e tempo com subprodutos e funcionalidades que nunca ou pouco serão utilizados; Sempre agregar valor para o cliente, mesmo que o projeto seja interrompido antes do seu final previsto e priorizar a comunicação e feedback entre as pessoas do projeto, para que todos saibam o que deve e o que está sendo feito.

A grande demanda por desenvolvimento de software de forma distribuída já está sendo vivenciada por várias organizações nos últimos anos. Entretanto, agregados aos benefícios existem grandes desafios ao utilizar o desenvolvimento distribuído de software. Dentre esses desafios, destacam-se: Dificuldades em gerenciar a equipe; Dificuldades na comunicação e na criação do espírito de equipe.

Esses empecilhos podem comprometer significativamente o desempenho do projeto. Devido à escassez de dados e informações de projetos desta natureza, observou-se a necessidade de um estudo de caso que pudesse envolver as características de um projeto real distribuído.

Este trabalho tem por objetivo relatar a experiência obtida na disciplina Engenharia de Software da pós graduação do Centro de Informática (CIn) da Universidade Federal de Pernambuco (UFPE), no primeiro semestre de 2009. Nessa disciplina, 62 alunos trabalharam utilizando a metodologia Scrum [Schwaber 2004] de forma distribuída implementando uma ferramenta Open Source, chamada Firescrum.

2. Metodologia do ProjetoO grupo da disciplina era coordenado por dois alunos doutorandos pela UFPE,

um aluno do mestrado do CESAR.edu0 e também por alunos mestrandos pela UFPE coordenados pelos professores Silvio Meira e Jones Albuquerque. A grande equipe foi dividida em seis outras compostas por no máximo 10 pessoas, obedecendo assim aos critérios do Scrum. Todos os grupos estavam focados no mesmo objetivo o desenvolvimento do FireScrum, entretanto trabalharam de forma que o trabalho de um conjunto impacta-se o mínimo possível no de outro. Para cada grupo foi escolhido um Scrum Master responsável por facilitar a comunicação e garantir que a metodologia Scrum fosse seguida. De uma maneira geral, dentro dos times o desenvolvimento também ocorreu de forma distribuída. Cada membro tinha liberdade de realizar suas atividades em casa. Não existia um ambiente de trabalho em comum. Além dos Scrum Masters dos times, os dois doutorandos ficaram responsáveis por todos os times. Semanalmente aconteciam duas reuniões de acompanhamento com pelo menos um integrante de cada time, era o Scrum de Scrums. Nestas reuniões eram abordadas as dificuldades e impedimentos que os times estavam enfrentando, sendo possível obter-se uma visão mais transparente do andamento do projeto.

0 C.E.S.A.R.edu,- http://www.cesar.edu.br/, Ultimo acesso 05/julho/2009.

72

No Scrum, outro papel essencial é o de Product Owner (PO). Este é responsável por definir os objetivos do desenvolvimento, definir o valor de negócio de cada funcionalidade do produto e decidir junto aos grupos quais requisitos deveriam ser primeiro atendidos. O PO é considerado parte da equipe e necessita estar em contato constante com os outros integrantes do grupo. Esse papel foi muito bem desempenhado no decorrer do trabalho. Outras funções acumulado pelo PO foram as de definições e validações das interfaces gráficas, estas sempre analisadas por ele.

O Firescrum é uma ferramenta Open Source desenvolvida para oferecer suporte ao gerenciamento de projetos que utilizem a metodologia Scrum, de forma distribuída ou não. Construiu-se então, a partir das necessidades do mercado, um framework com interface gráfica, que prioriza a usabilidade, e possui o intuito de auxiliar pessoas, gerentes e times na concretização de suas metas.

Os seguintes módulos da ferramenta foram desenvolvidos: 1) Task Board: Simula o quadro de tarefas do Scrum, onde o usuário visualiza os Post-Its das tarefas e os pode mover de acordo com a mudança de status da tarefa; 2) Test Module: Constituído pelos cadastros de Casos de teste, Suíte de testes, dentre outras funcionalidades; 3) Bug Tracking: Permite o controle dos erros surgidos durante o desenvolvimento: 4) Desktop Agent: Permite o acesso à aplicação por meio de um ícone no Systray do Sistema Operacional; 5) Planning Poker: Permite a realização do Planning Poker numa reunião distribuída, simulando um ambiente “face-to-face”. e 6) Core module: Constituído pelas funcionalidades essenciais da ferramenta. Todos os demais módulos dependem desse.

O estudo de caso relatando as experiências vividas neste trabalho é da equipe responsável pelo módulo Core.

3. Estudo de caso: Scrum e DDSA primeira dificuldade encontrada no início do projeto foi com relação à metodologia: O que é o Scrum? Como funciona? Pra quê serve? Solucionadas essas dúvidas entrou-se então no contexto do grupo: Como mudar a mentalidade das pessoas para trabalhar com o Scrum?

A maioria dos integrantes dos times tinha experiência na utilização do modelo em Cascata. Para eles o papel do gerente (ou líder técnico) era fundamental para o funcionamento do time. Este fator ocasionou uma má interpretação com relação ao papel do Scrum Master, que no modelo do Scrum nada mais é do que um integrante do grupo que auxilia no processo de comunicação e solução de impedimentos.

A oportunidade de o time tomar as decisões parecia um tanto absurda para as pessoas que não tinham experiência com o Scrum, o que levou a hipótese de fracasso do projeto. Porém, à medida que a ferramenta evoluía e os integrantes conheciam melhor o sistema de trabalho essas dificuldades culturais iam sendo superadas.

3.1. Planejamento e Acompanhamento

Diversos aspectos do Scrum puderam ser utilizados durante o desenvolvimento. Algumas práticas foram adaptadas, pelo fato dos times e seus respectivos integrantes muitas vezes não estarem em um local de trabalho em comum, porém sempre seguindo as boas práticas e a essência da metodologia utilizada.

73

Inicialmente todo o Product Backlog, requisitos do sistema, foi construído junto ao Product Owner. Todos os itens do Product Backlog possuíam os seus Business Value (valor de negócio). O Business Value era considerado na definição de prioridade dos requisitos.

O ciclo de desenvolvimento foi então dividido em Sprints. As Sprints são iterações que marcam a entrega de novas funcionalidades do produto. Foi escolhida a duração de quinze dias entre uma iteração e outra. Essa duração foi escolhida devido ao curto tempo disponível para o desenvolvimento e para facilitar o acompanhamento do mesmo. Cada Sprint possuía um objetivo, que era um acordo entre PO e equipe, com relação aos Products Backlogs que deveriam ser entregues.

No início de cada iteração eram realizadas duas seções de planejamento. Na primeira, Sprint Planning 1, os itens de Backlog eram analisados pela equipe. Através de uma seção de Planing Poker, o esforço de desenvolvimento de cada item era debatido. Iniciava-se então uma negociação com o PO, via email ou lista de discussão, visando definir o objetivo da Sprint. Na segunda parte do planejamento, Sprint Planning 2, a equipe quebrava os itens de Backlog, referentes ao objetivo da Sprint, em tarefas e cada membro escolhia as suas. As tarefas eram estimadas em dias.

O acompanhamento das tarefas era inicialmente realizado utilizando-se uma planilha do Google Docs0 2009. Os erros que surgiam durante a implementação eram reportados no Mantis0 2009. A planilha do Google Docs funcionava como o Task Board, uma vez que listava todas as tarefas de uma Sprint com o nome do seu respectivo responsável e o seu status. Para melhor visualização do andamento geral da Sprint, as linhas da planilha eram coloridas de acordo com o status de cada tarefa.

Depois de algumas Sprints, percebeu-se que não era necessário usar esses dois recursos para acompanhar tarefas e falhas. A equipe passou a utilizar somente o Mantis para registrar essas informações. O Mantis, além de possuir um esquema de cores de acordo com o status, permite também agrupar os itens registrados. Assim, cada tarefa e erro cadastrados eram agrupados dentro do item de Backlog ao qual estavam relacionados.

Durante o andamento da Sprint, a equipe realizava a Daily Scrum Meeting via o chat do Skype [Skype 2009]. Dessa forma, todos do time sabiam o andamento das atividades e os impedimentos surgidos até o momento. O Scrum Master tinha a função de ajudar na resolução dos impedimentos levantados durante a reunião. Além dessa atividade, o Scrum Master auxiliava nas atividades de teste. O uso do chat serviu para demonstrar que o “face-to-face” não é essencial para a realização dessas reuniões.

É importante destacar que a equipe se deparou com provlemas de preseça de membros e de falta de objetividade nas Daily Scrum Meeting. Durante a execução da primeira Sprint, muitos faltavam sem uma causa justa. Uns por falta de compromisso e outros por falta de costume com o horário estabelecido para a reunião. Esse problema foi abordado na primeira Retrospectiva e a partir da segunda Sprint, esse problema foi parcialmente resolvido, pois a maioria estava acostumada com o horário e mais

0 Sistema de armazeanamento de documentos do Google. http://docs.google.com/, acessado em 01 de julho de 20090 Ferramenta para rastreamento de Bugs, online. http://factory2u.cin.ufpe.br/mantis/http://docs.google.com/, acessado em 01 de julho de 2009

74

comprometida. A não objetividade das reuniões foi outro problema, o qual se estendeu durante todo o desenvolvimento. Poucas reuniões duravam 15 minutos, que é o tempo aconselhado. Na maioria das vezes, a reunuão durava 40 minutos a 1 hora. Sempre alguém tinha algo a discutir ou fugia-se do escopo da reunião. Isso prejudicou a produtividade do time, pois diminuía o tempo dedicado à execução das tarefas.

Para resolver muitos dos impedimentos relatados durante as Daily Scrum Meeting, era necessária a comunicação com o Product Owner, a qual era realizada via email ou chat. A equipe também entrava em contato com o PO para renegociar os itens de Backlog cuja entrega não seria possível ao final de uma determinada Sprint.

A partir da segunda Sprint, a equipe foi aperfeiçoando o uso do processo como é possível ver no gráfico do Burn Down (Figura 1). A medida que novas tarefas eram adicionadas a re-estimativa era feita. A partir da quarta Sprint os Impedimentos e as tarefas adicionadas também passaram a ser registradas no gráfico.

Figura 2 - Gráficos de Burn Down

3.2. Desenvolvimento

Devido ao Firescrum já possuir algumas funcionalidades implementadas anteriormente, a primeira atividade realizada pelo time foi analisar e entender a estrutura legada do sistema. Verificou-se a necessidade de reestruturar a arquitetura a fim de melhorar a modularidade e diminuir as dependências minimizando problemas relacionados ao desenvolvimento paralelo dos times.

75

Na fase de desenvolvimento, o paradigma “face-to-face”, foi quebrado devido as necessidades pessoais de cada integrante. Todavia, no início dessa fase, as atividades não conseguiram se dá completamente de forma distribuída, inicialmente devido ao desnivelamento do conhecimento. Para conseguir-se um melhor trabalho em equipe, o início do projeto foi marcado por reuniões presenciais com o intuito de explicar a arquitetura do sistema e treinamentos curtos com relação à tecnologia a ser adotada.

A fim de possibilitar o desenvolvimento paralelo entre os times foram criados branches [Schwaber 2004] de desenvolvimento para cada equipe e em marcos específicos realizavam a sincronização com o branch principal. Um integrante de cada time ficaria responsável por esta tarefa. Havia uma ordem preestabelecida para ocorrer tal sincronização. Sempre o primeiro time a fazê-la era o Core devido a sua característica (domínio, negocio e dados). O segundo time fazia o merge com a nova versão do branch principal assim por diante. No final o branch principal estava com todas as alterações. Neste momento o Core fazia a sincronização com o branch principal, levando para o seu branch de desenvolvimento as alterações de todos os times.

Também foi muito importante o uso de pair-programming, que consiste em uma dupla de programadores trabalhando em um mesmo problema e trocando experiências. Programadores mais experientes ficaram com atividades mais complexas e passaram a nivelar o conhecimento com programadores menos experientes, que trabalharam inicialmente em atividades menos complexas. Essa prática funcionou muito bem. Nas duas primeiras Sprints, alguns desenvolvedores com mais conhecimento tiveram uma perda mínima de produtividade, pois também ficaram como mentores. Entretanto, ainda na fase inicial do trabalho, um nivelamento satisfatório foi alcançado e o trabalho pôde ser melhor dividido entre mais integrantes da equipe acarretando um ganho significativo de produtividade.

Após a equiparação do nível técnico do grupo, o desenvolvimento distribuído foi praticamente unânime. Apenas na primeira iteração foi necessário haver uma grande reunião com todos os integrantes para que o objetivo da mesma fosse alcançado. No decorrer das atividades o time se tornou auto-gerenciável. Houve maturidade na quebra de tarefas e divisão destas entre os integrantes. A comunicação se deu de forma satisfatória, tanto quando o desenvolvimento por parte de um desenvolvedor impactava no trabalho de outro, tanto quando era necessário haver troca de experiências entre os integrantes. Cabia ao desenvolvedor ficar responsável por verificar os requisitos da tarefa, implementar e executar testes unitários e manter o código sempre sincronizado com o branch de desenvolvimento minimizando a possibilidade de perda de código.

3.3. Testes

O processo de testes de software não é apenas uma abordagem voltada à detecção de falhas para correção de bugs, é também uma ferramenta importante para validação das funções do software, na garantia da qualidade e otimização do esforço empregado. O maior desafio da equipe foi criar código estável para o Core da aplicação da aplicação FireScrum mantendo a integridade das funções desenvolvidas na versão anterior adequando-lhe junto ao código dos outros times participantes do projeto.

Durante o processo de desenvolvimento do Firescrum, a equipe utilizou três tipos de testes: testes de caixa preta, caixa branca e exploratório [Murnane and Redd

76

2001], todos executados de forma manual voltadas ao Scrum [IEEE Computer Society 1998]. Entretanto, um dos maiores desafios para equipe de testes foi lidar com a distribução dos seus integrantes.

3.3.1. Análise e planejamento

A definição da estratégia de testes adotada implicou em trabalhar do zero, no projeto FireScrum. De acordo com o entendimento obtido durante o fechamento da primeira Sprint, não havia uma estratégia legada dos projetos anteriores do FireScrum, nem documentação, isto é, se houve processo de teste este foi perdido e não foi passado para nvoas equipes, acredita-se que os testes limitavam-se a estratégia de testes unitários.

A estratégia definida pelo time Core consistiu em trabalhar sobre aspectos críticos da ferramenta definindo uma equipe de testes que atuou de forma assíncrona, distribuída e com níveis de conhecimento distintis sobre a engenharia do teste. Além disso, os outros times que interagiam com as aplicações relacionadas ao Core também reportavam falhas encontradas, a partir daí surge outro problema relacionado à duplicidade de falhas encontradas durante o desenvolvimento.

Para contemplar um canal eficiente de comunicação interno e externo, assíncrono e distribuído para todas as equipes do projeto, três artefatos foram criados: workflow de testes (Figura 2), Planilha de testes e um template para descrição das falhas encontradas. Todas as falhas eram reportadas no Mantis.

O ciclo de atividades de testes era composto por: 1) Criação de novos testes em uma planilha com a descrição das principais funções de cada Item de Backlog. Estes testes são selecionados para popular um ciclo de testes; 2) Os testes são executados; 3) Os testes que apresentam falha são reportados no Mantis conforme o Template e 4) As falhas são corrigidas. Durante as falhas novas propostas de testes podem surgir.

Figura 2 - Workflow do ciclo de testes

Novos testes eram adicionados na planilha à medida que novas funcionalidades eram criadas. O ciclo era exezcutado duas vezes no decorrer das Sprints. A equipe de testes era composta por testadores que eram responsáveis pela execução e criação dos testes. O reporte das falhas era feito por testadores e desenvolvedores.

3.3.2. Execução do Plano de Testes

A execução do plano de teste inicialmente foi composta por três atores. Os novos integrantes foram treinados sobre o processo de execução de testes quanto: ao conceito de identificação de falhas, classificações atribuídas ao estado de um caso de teste,

77

utilização dos artefatos e maneiras corretas de reporte no Mantis. À medida que novas funcionalidades eram desenvolvidas, os novos casos de testes eram criados e em seguida executados.

Um problema vivenciado que impactou os testes foi observado quando os demais times de desenvolvimento não sincronizavam suas versões com o repositório central nos períodos pré-estabelecidos. Isso acarretava na não validação de alguns erros reportados e erros novos eventualmente eram inseridos no código final após a rodada de testes. Para solucionar este problema foi definido um marco para sincronização e após este marco era aplicada um rótulo no código. Os testes passaram a ser executados a partir deste rótulo.

Durante o processo de testes descobrimos que algumas atividades eram realizadas pelos desenvolvedores e testadores e simplesmente não eram reportadas. Foi verificado também que atividades eram realizadas duas ou mais vezes. Isto tinha grande impacto durante a correta medição das atividades no Burn Down das Sprints, simplesmente o gráfico de atividades sofria uma inclinação brusca ao termino de cada Sprint. Conforme dito anteriormente, uma nova abordagem na forma de ordenar as atividades de testes e desenvolvimento foi criada, a planinha de atividades foi abolida e somente o Mantis seria utilizado para controle das atividades e reporte de falhas.

O ganho foi nítido, com a criação de uma Change Request(CR)0 mãe. Esta CR representava uma Sprint ou ciclo de teste e as atividades referentes a estas eram cadastradas como filhas. Com isso era possível fazer de forma mais objetiva e sem duplicidade o acompanhamento do andamento dos erros e atividades.

Outro aspecto que merece destaque, ainda em relação ao uso do Mantis, é a forma como a equipe o utilizou para garantir a qualidade das funcionalidades implementadas ou corrigidas. Para cada item dito como finalizado pela equipe de desenvolvimento, havia um engenheiro de teste dedicado a testar e verificar se aquele item podia ser dado como finalizado. Para isso, eram criadas planilhas de testes, contendo casos de teste que eram executados para cada funcionalidade recém implementada ou corrigida. Caso a funcionalidade passasse nos testes, ela tinha o seu status alterado indicando que realmente estava finalizada. A notificação entre os membros da equipe, indicando o que era finalizado e o que deveria ser testado, foi possível porque o Mantis tem um sistema de avisos, que permite um determinado usuário receber, por email, informações sobre alterações num dado registro feitas por outros usuários.

À medida que os as falhas surgiam, as CR’s relacionadas ao erro eram retestada e corrigidas, caso o erro persistisse, esta continuava aberta. Caso a CR não fosse corrigida a tempo do término da Sprint, esse erro seria associado à nova CR mãe.

4. Lições AprendidasAo final do projeto chegamos às seguintes lições aprendidas:

0 Change Resquest – É um documento contendo uma solicitação de mudança para um sistema, geralmente esta associado a uma falha no software, isto é de grande importância para o controle e gerenciamento de processos de testes de software. Fonte: Keller, A. (2005). Automating the Change Management Process with Electronic Contracts. Proceedings of the 2005 Seventh IEEE International Conference on ECommerce Technology Workshops, 99-108.

78

1) É possível realizar o Daily Scrum sem obedecer o Face-to-face. O uso de ferramentas como o Skype permitiu a comunicação diária;

2) Daily Scrum Meeting: As reuniões de diárias precisam ser sempre objetivas não necessitando mais do que 15 minutos. Uma boa solução para o problema de não objetividade dessas reuniões poderia ter sido o uso de comunicação assíncrona. O uso de email, por exemplo, não permitiria a extensão da reunião e, mesmo assim, a comunicação diária não seria prejudicada;

3) A Retrospectiva deve ser feita de forma, preferencialmente, presencial;

4) Algumas atividades poderiam ser distribuídas de forma mais equilibrada evitando que integrantes fiquem sobrecarregados e em contra partida outros ficarem com pouca atividade prejudicando o andamento do projeto.

5) As atividades de uma Sprint devem estar sempre visíveis a todos do time e seus status sempre atualizados. Isso permite que um integrante, que terminou suas tarefas, possa se alocar a alguma ainda não alocada ou ajudar algum outro integrante a terminar as dele. Além disso, os status atualizados evitam esforços desnecessários. Certa vez, dois membros da equipe corrigiram um mesmo erro ao mesmo tempo porque, no Mantis, não havia sido registrada a informação de que alguém já estava resolvendo àquele erro;

6) O uso do Mantis como notificador de alterações em registros foi essencial para a execução das atividades de teste. Assim, mesmo o Mantis possuindo sérios problemas de usabilidade e sendo rejeitado por alguns integrantes do time no início do projeto, este se mostrou uma ferramenta de acompanhamento eficiente. e

7) Alguns membros do time não tiveram tanto comprometimento como os demais membros. A exigência de comprometimento era responsabilidade do Scrum Master, mas deveria ter sido responsabilidade do time inteiro, pois o time, de acordo com o Scrum, deveria ser auto- gerenciável.

5. ConclusõesDurante todo o projeto uma base de dados foi gerada pelo time. Através dela, uma série de análises puderam ser feitas, mostrando assim a evolução do projeto. Podemos analisar que do total de 292 solicitações abertas somente 18 ficaram em aberto para serem corrigidas no futuro, 36 foram resolvidas e 238 foram analisadas e fechadas.

A quantidade de dias necessários para analisar, corrigir e validar uma solicitação de mudança foi em média 3 dias; Solicitação que passou mais tempo em aberto foi a de número 0000421 com tempo de resolução de 29 dias. No projeto como um todo foram gastos 1000 horas na análise, estudo e correção das solicitações.

É possível concluir que para se trabalhar de forma distribuída com sucesso o fator comprometimento é o mais importante. Outro ponto fundamental é a comunicação, só assim evitou-se retrabalho e perca de tempo. A escolha da metodologia Scrum e a distribuição dos membros dos times também foi um fator decisivo para o bom andamento do projeto.

Ao final da disciplina a equipe disponibilizou um módulo estável, com novas funcionalidades e com erros irrelevantes para o usuário final.

79

ReferênciasPressman, R. Software Engineering: A Practitioner's Approach, 6ªedição, Mc Graw Hill,

2005.

Kenneth E. Nidiffer , Dana Dolan, Evolving Distributed Project Management, IEEE Software, v.22 n.5, p.63-72, September 2005

Highsmith, J. (2004) “Agile Project Management – Creating Innovative Products”, AddisonWesley.

R. Zanoni, J. L. N. Audy, "Gerência de Projeto de Software em Ambiente Fisicamente Distribuído: Um Estudo de Caso," Proc. CACIC 2002

Firescrum: The Open Source Scrum Tool. 2009. Disponível em: www.firescrum.com. Acessado em: 25 de junho de 2009.

Google Docs. 2009. Disponível em: http://docs.google.com/. Acessado em: 01 de julho de 2009.

MantisBT. 2009. Disponível em: http://factory2u.cin.ufpe.br/mantis. Acessado em: 01 de julho de 2009.

Skype. 2009. Disponível em: http://www.skype.com. Acessado em: 01 de julho de 2009.

Schwaber, K. (2004), Agile Project Management With Scrum, Microsoft.

Norris F. (2008), News Analysis: Another Crisis, Another Guarantee, The New York Times, November 24, 2008 http://www.nytimes.com/2008/11/25/business/25assess.html?_r=1&hp

IEEE Computer Society, (1998) “IEEE Standard for Software Test Documentation, IEEE”, Std 829-1998

Murnane, T., Reed, K. (2001), On the Effectiveness of Mutation Analysis as a Black Box Testing Technique, IEEE

80