Proposta de utilização de Mapas Conceituais em um contexto de
Desenvolvimento Distribuído de Software
Rafael Prikladnicki
Pontifícia Universidade Católica do Rio Grande do Sul, Faculdade de Informática
Programa de Pós-Graduação em Ciência da Computação
Av. Ipiranga, 6681 – Prédio 16 – Sala 106
Porto Alegre, RS – CEP 90619-900
rprik@inf.pucrs.br
Resumo
O desenvolvimento distribuído de software tem atraído um grande número de pesquisas na área de engenharia de software nos últimos anos. Os engenheiros de software têm reconhecido a grande influência desta nova forma de trabalho e estão em busca de modelos que facilitem o desenvolvimento de software com equipes geograficamente distantes. Além dos engenheiros, gerentes e executivos têm enfrentado diversos desafios e dificuldades em diferentes níveis, desde os aspectos técnicos até os aspectos não-técnicos. Neste sentido, o objetivo deste artigo é discutir a possibilidade de utilizar mapas conceituais para a organização e visualização dos aspectos existentes em um determinado projeto que envolve o desenvolvimento de software utilizando equipes distribuídas. A contribuição principal está na possibilidade de organizar as atividades de modo a auxiliar o gerente de projeto e a sua equipe a entender que aspectos estão presentes quando se desenvolve software de forma distribuída, a priorização de atividades e a relação entre elas.
1. Introdução
Nos últimos anos, percebe-se um grande avanço em direção a globalização dos negócios, em particular nos negócios relacionados com um intenso investimento na tecnologia de desenvolvimento de software. Sabe-se que nos últimos anos o software tem se tornado um componente vital para quase todos os negócios. Neste sentido, para as organizações que buscam sucesso é clara a necessidade do uso da Tecnologia da Informação (TI) como diferencial competitivo. Com o objetivo de ter custos menores, maior qualidade no processo de desenvolvimento de software e a possibilidade de dispor estes recursos em âmbito global [1] e [5], muitas
organizações começaram a investir em ambientes de desenvolvimento distribuído de software e outsourcing. Na área de Engenharia de Software (ES), mercados nacionais têm se transformado em mercados globais, criando novas formas de competição e cooperação que vão além das fronteiras dos países. O desenvolvimento distribuído de software tem sido caracterizado principalmente pela colaboração entre departamentos de organizações internacionais e pela criação de pequenos grupos de desenvolvedores que trabalham junto, mas vivem em cidades ou países diferentes [16].
Diversos fatores têm contribuído para isto, entre eles: • A necessidade de possuir recursos globais para
serem utilizados a qualquer hora;
• As vantagens de estar perto do mercado local, incluindo o conhecimento dos clientes e as condições locais;
• A rápida formação de organizações e equipes virtuais para explorar as oportunidades de mercado;
• A grande pressão para o desenvolvimento
time-to-market, utilizando as vantagens
proporcionadas pelo fuso horário diferente, no desenvolvimento conhecido como
round-the-clock, ou seja, o desenvolvimento quase que
contínuo (24 horas sem parar, contando com as equipes fisicamente distantes em países com fusos horários diferentes).
Estas mudanças estão causando um grande impacto não apenas no mercado propriamente dito, mas na maneira como os produtos de software estão sendo criados, modelados, construídos, testados e entregues para os clientes. Neste sentido, o desenvolvimento distribuído
de software tem atraído um grande número de pesquisas na área de engenharia de software nos últimos anos (e.g. [2], [6] e [7]). Os engenheiros de software têm reconhecido a grande influência desta nova forma de trabalho e estão em busca de modelos que facilitem o desenvolvimento de software de forma distribuída, com equipes geograficamente distantes. São freqüentes os esforços que os pesquisadores têm feito no intuito de entender os fatores que permitem organizações multinacionais ou virtuais a obterem sucesso trabalhando através das fronteiras físicas e culturais dos países. Também são freqüentes os diversos desafios e dificuldades que os engenheiros, gerentes e executivos têm enfrentado em diferentes níveis de complexidade, desde os aspectos técnicos até os aspectos não-técnicos [7]. Os aspectos técnicos envolvem questões como o processo de desenvolvimento de software, a existência de padrões, a sincronização de ambientes, os tipos de projetos, a complexidade dos projetos, os tipos de atores envolvidos, etc. Já os aspectos não-técnicos envolvem questões como a confiança entre as equipes, as diferenças culturais, a forma de se comunicar, o idioma, entre outros.
Neste sentido, uma das principais dificuldades existentes quando se desenvolve software de forma distribuída é o entendimento de que aspectos estão envolvidos em um determinado projeto, onde está a causa das dificuldades, como os conceitos estão organizados e como uma equipe de projeto pode trabalhar estes conceitos de forma a minimizar os problemas existentes quando se trabalha neste tipo de ambiente.
Este artigo tem por objetivo discutir a possibilidade de utilizar mapas conceituais para a organização e visualização dos aspectos existentes em um determinado projeto que envolve o desenvolvimento de software com equipes distribuídas. A contribuição principal está na possibilidade de organizar as atividades de modo a auxiliar o gerente de projeto e a sua equipe a entender que aspectos estão presentes quando se desenvolve software de forma distribuída, a priorização de atividades e a relação entre elas. Um estudo de caso realizado em uma organização multinacional que possui um ambiente de desenvolvimento distribuído de software é utilizado para identificar alguns aspectos existentes em ambientes assim configurados e como estes aspectos podem ser relacionados.
A proposta descrita neste estudo visa contribuir com a ainda pequena, mas crescente base de conhecimento empírica sobre desenvolvimento distribuído de software. Este artigo tem a seguinte estrutura: o item 2 apresenta a base teórica utilizada, o item 3 discute o método de pesquisa utilizado, o item 4 descreve o estudo de caso, identificando os principais aspectos identificados e o item 5 apresenta uma proposta de utilização de mapas conceituais no contexto de desenvolvimento distribuído
de software. Finalmente, o item 6 apresenta as considerações finais.
2. Base Teórica
2.1. Desenvolvimento Distribuído de Software
Segundo [9], um processo de desenvolvimento de software é definido por um conjunto de atividades, métodos, práticas e tecnologias que as pessoas e as empresas utilizam para desenvolver e manter software e produtos relacionados. O interesse no processo de software está baseado nas seguintes premissas:
• A qualidade de um produto de software é fortemente dependente da qualidade do processo pelo qual ele é construído e mantido;
• O processo de software pode ser definido, gerenciado, medido e melhorado.
Mas desenvolver software utilizando um processo de desenvolvimento bem definido não é uma tarefa simples. Ao contrario, ao longo dos anos tem se tornado cada vez mais complexa, na exata medida em que as demandas de software das empresas aumentam em importância estratégica para suas operações.
As equipes de projeto de software vêm se distribuindo geograficamente em escala mundial, inseridas no conceito de globalização que a sociedade têm vivenciado nos últimos anos. Isto configura então o Desenvolvimento Distribuído de Software (DDS), onde atores envolvidos no processo estão fisicamente distantes, e é também conhecido como Desenvolvimento Global de Software (DGS), quando estas equipes estão distribuídas em uma escala mundial.
Várias ferramentas e ambientes têm sido desenvolvidos ao longo dos últimos anos para ajudar no controle e coordenação das equipes de desenvolvimento que estão inseridas neste tipo de ambiente. Muitas destas ferramentas estão focadas no suporte aos procedimentos de comunicação formal tais como elaboração de documentos, processos automatizados e outros canais de comunicação não interativos.
Além disso, [4] destaca que trabalhar com DDS é um dos maiores desafios que o atual ambiente de negócios apresenta do ponto de vista do processo de desenvolvimento de software. Muitas empresas estão distribuindo seu processo de desenvolvimento de software em países como Índia, Irlanda, Singapura, Filipinas, China, México, Austrália e Brasil. Muitas vezes este processo ocorre em um mesmo país, em regiões com incentivos fiscais ou de concentração de massa crítica em determinadas áreas.
As empresas buscam obter vantagens competitivas em termos de custos, qualidade e flexibilidade na área de desenvolvimento de sistemas [10] e [11], além de ganhos de produtividade e diluição de riscos [8]. Muitas vezes estas vantagens competitivas levam as empresas a buscar soluções externas até mesmo em outros paises. Neste contexto, surgem os conceitos de outsourcing e offshore
outsourcing, o que potencializa os problemas e os
desafios existentes no DDS.
2.1.1. As Dimensões do DDS. A pesquisa realizada por
[3] propõe algumas dimensões para o desenvolvimento distribuído de software. Estas dimensões auxiliam no entendimento dos problemas, vantagens e desvantagens deste tipo de ambiente. Sendo assim, [3] define dez dimensões para o DDS (Figura 1), a saber:
DDS
DDS
Confiança Distância Percebida Nível de Dispersão Sincronização Tipo de Atores Stakeholders Complexidade Cultura Tipo de Projeto Processo de Desenvolvimento Procedimentos e Padrões Figura 1 – As dimensões do DDS.• Confiança: confiar nas equipes geograficamente
distribuídas é essencial para desenvolver um projeto em um ambiente assim configurado;
• Distância Percebida: existem diversas
possibilidades entre a habilidade de encontrar uma pessoa face a face freqüentemente (fisicamente perto), e de nunca ser capaz de encontrá-la (fisicamente longe). Esta dimensão considera todos os participantes de um projeto, mas desconsidera papéis, que são considerados apenas em níveis de dispersão. A distância percebida afeta as atividades de coordenação; • Nível de Dispersão: a distância percebida entre os
membros de um determinado grupo de
stakeholders (clientes, usuários ou equipe de
projeto, por exemplo) é chamado de nível de dispersão. O trabalho de [10] explora algumas possibilidades de caracterização do nível de dispersão considerando a existência de três atores no desenvolvimento de um projeto (equipe de projeto, clientes e usuários);
• Sincronização: é a capacidade das pessoas
trabalharem no mesmo projeto de forma concorrente;
• Tipos de Atores (stakeholders): diferentes tipos
de grupos de stakeholders existem em cada projeto, cada um com percepções diferentes sobre o projeto. Quanto maior o número de
stakeholders envolvidos, maior pode ser a
distribuição do projeto;
• Complexidade: o nível de complexidade de um
projeto pode afetar a performance de projetos distribuídos. Existem diversos fatores de complexidade, entre eles o nível de tecnologia utilizada em um projeto;
• Cultura: cultura é um fator multidimensional que
afeta a performance de projetos distribuídos de diversas maneiras. Podem ser considerados aspectos da cultura nacional, cultura organizacional, entre outros;
• Tipo de Projeto: esta dimensão define o tipo de
um projeto (manufatura, modelagem, hardware, software, misto). Dependendo do tipo de projeto, isto afeta a maneira como ele será gerenciado;
• Processo de Desenvolvimento: o
desenvolvimento de software deve considerar um processo bem definido e conhecido pelas equipes geograficamente distribuídas. Não é interessante que um gerente deva coordenar um projeto tendo um processo sendo executado por cada equipe; • Existência de Procedimentos e Padrões: a idéia
desta dimensão é a de criar procedimentos e padrões e tornar eles parte da cultura da organização, para haver principalmente um padrão entre os grupos geograficamente distribuídos no âmbito organizacional.
As dimensões propostas por [3] se concentram nos principais aspectos de ambientes de DDS. Estudos realizados por [2], [6], [7], [13], [15] e [16] identificam a existência de diversos outros aspectos presentes neste tipo de ambientes. Neste caso, este estudo une as propostas existentes na literatura e considera assim duas grandes dimensões para a área de DDS: a dimensão técnica e a dimensão não-técnica. A dimensão técnica é composta de conhecimentos considerados como base para a construção de software, isto é, conhecimentos técnicos. Já a dimensão não-técnica é composta de conhecimentos que são a base para a estruturação dos conhecimentos técnicos, envolvendo fatores sociais, culturais, lingüísticos, comportamentais e políticos.
2.2. Outsourcing
Outsourcing é a prática de contratar uma organização
externa para desenvolver um sistema, ao invés de desenvolver na sua própria sede (in-house) [8]. Segundo [1] e [5], trabalhar com outsourcing necessita de muito mais gerenciamento do que um desenvolvimento in-house. E, quando o processo é bem gerenciado, obtêm-se as vantagens deste tipo de ambiente.
Uma das opções do outsourcing que vem se tornando bastante popular ao longo dos últimos anos é o offshore
outsourcing. Organizações offshore são empresas que
estão localizadas em algum outro país, e que oferecem custos, prazos ou qualidade melhores que as organizações podem obter de forma autônoma [8].
A estabilização dos conceitos, o desenvolvimento de modelos e ferramentas para atuar neste ambiente tem motivado diversos pesquisadores e empresas a desenvolverem estudos e buscarem soluções para a nova classe de problemas. Mas ao optar pelo outsourcing ou
offshore outsourcing uma empresa não configura um
ambiente de desenvolvimento de software fisicamente distribuído, pois a empresa externa que foi contratada pode exercer suas atividades na própria sede da empresa contratante. A distribuição do processo de desenvolvimento de software ocorre somente quando parte dos envolvidos no processo estão fisicamente distantes.
2.3. Mapas Conceituais
Os Mapas Conceituais se originaram do relacionamento de assuntos da área de Educação (Teoria de David Ausubel) e Inteligência Artificial (Redes Semânticas). A Figura 2 ilustra esta relação:
Ausubel
Redes Semânticas Mapas ConceituaisEducação
IA
Figura 2 – Origem dos Mapas Conceituais.
Na área da educação, existe a teoria de Ausubel, que possui os seguintes princípios [17]:
• As idéias mais gerais de um assunto devem ser apresentadas primeiramente, e se diferenciarem progressivamente nos termos e detalhes específicos;
• Os materiais instrucionais devem tentar integrar no material novo informação previamente já apresentada, enfatizando com as comparações a referência cruzada entre idéias novas e velhas. A aprendizagem significativa, segundo Ausubel, é o processo através do qual uma nova informação relaciona-se com um aspeto relevante da estrutura de conhecimento do indivíduo. A aprendizagem ocorre quando uma nova informação ancora-se em conceitos ou proposições relevantes preexistentes na estrutura cognitiva do indivíduo. Além disso, Ausubel dizia que quando o material a ser aprendido não consegue ligar-se a algo já conhecido, ocorre o que ele chamou de aprendizagem mecânica (rote learning). Ou seja, isto ocorre quando as novas informações são aprendidas sem interagirem com conceitos relevantes existentes na estrutura cognitiva [17].
Na área da Inteligência Artificial, existe o conceito de Redes Semânticas, que é definida como uma estrutura para a representação do conhecimento definida como padrão de nodos interconectados por arcos rotulados. As redes deste tipo não só captam as definições dos conceitos, mas também proporcionam ligações com outros conceitos [18].
Tendo esta fundamentação teórica, John Novak desenvolveu os chamados Mapas Conceituais, que são representações gráficas semelhantes a diagramas, que indicam relações entre conceitos ligados por palavras. Representam uma estrutura que vai desde os conceitos mais abrangentes até os menos intrusivos. São utilizados para auxiliar na ordenação e a seqüenciação hierarquizada dos conteúdos de ensino, de forma a oferecer estímulos adequados ao aluno. Eles dispõem de uma representação em duas dimensões de um conjunto de conceitos construída de tal forma que as inter-relações entre eles fica evidente. O eixo vertical expressa a estrutura hierárquica dos conceitos. Os conceitos mais gerais se encontram nos níveis mais altos, e os conceitos mais específicos nos níveis progressivamente mais baixos. No eixo vertical, os mapas conceituais representam a idéia de submissão de Ausubel, que diz que a informação nova freqüentemente é associada a conceitos mais inclusivos [17].
MU Constante Tema/Contexto Movimento Módulo Direção MUR MUA MUVR MUVA MV MUV
Variável Constante Variável
Retilíneo Curvilíneo Generalização Contexto Tema/Contexto Ligação Tema MU Constante Tema/Contexto Movimento Módulo Direção MUR MUA MUVR MUVA MV MUV
Variável Constante Variável
Retilíneo Curvilíneo Generalização Contexto Tema/Contexto Ligação Tema Figura 3 – Exemplo de Mapa Conceitual.
Uma análise, mesmo que superficial, deste mapa conceitual permite ao leitor identificar os conteúdos que são interdependentes ou inter-relacionados. Desta forma, fica mais fácil para organizar os conteúdos e fazer uma associação entre os conceitos abordados.
Os mapas conceituais são geralmente aplicados à organização de conteúdos de disciplinas, organização de disciplina de cursos, organização de cursos de uma mesma área, ou ainda organização de atividades em eventos. A vantagem da sua utilização é a possibilidade de identificar a forma como as pessoas percebem, armazenam e priorizam um conjunto de informações. Neste estudo, os mapas conceituais serão utilizados para organizar os conceitos envolvidos em projetos em ambientes de desenvolvimento distribuído de software.
3. Método de Pesquisa
Muito embora a ampla revisão teórica desenvolvida, não se tem conhecimento de que o problema apresentado tenha sido abordado sob a mesma perspectiva. Assim, esta pesquisa se caracteriza como um estudo predominantemente exploratório, sendo que o método de pesquisa principal foi o estudo de caso. O método de estudo de caso é adotado conforme proposto por [12]. Por tratar-se de uma pesquisa qualitativa, devem-se ter claras as limitações deste tipo de pesquisa, principalmente no que se refere ao número de organizações estudadas, restringindo a generalização dos resultados obtidos.
O estudo de caso realizado considerou a coleta de dados através de entrevistas semi-estruturadas com questões abertas com os membros da organização.
4. Estudo de Caso
O estudo de caso realizado objetivou a identificação de aspectos existentes em ambientes de desenvolvimento distribuído de software, tanto na dimensão técnica quanto na dimensão não-técnica. Para isso, dez entrevistas foram realizadas com os membros de equipes de dois projetos, selecionados obedecendo ao critério de possuir equipes distribuídas. Estas entrevistas foram realizadas durante dois dias, em uma unidade de desenvolvimento de
software de uma organização multinacional. Primeiramente os entrevistados foram convidados a falar sobre as dificuldades que enfrentavam em ambientes de DDS, em que tipo de atividades estas dificuldades eram encontradas, as soluções adotadas e o impacto destas soluções no projeto. Logo após, questionou-se sobre os fatores críticos de sucesso para desenvolver projetos neste tipo de ambiente e uma comparação entre desenvolver software com equipes centralizadas e com equipes distribuídas.
4.2. Aspectos encontrados
O estudo de caso realizado permitiu a identificação de diversos aspectos existentes em ambientes de DDS. Considerando-se as duas dimensões (técnica e não-técnica), os principais aspectos encontrados foram:
• Dimensão Técnica
o Processo de Desenvolvimento de Software Engenharia de Requisitos
o Sincronização de Ambientes
o Ferramentas de desenvolvimento
o Tipos de atores envolvidos
o Complexidade dos projetos
o Tipo de projetos envolvidos
o Procedimentos e Padrões o Velocidade o Níveis de Dispersão • Dimensão Não-Técnica o Diferenças Culturais o Contexto o Confiança o Comunicação o Idioma o Coordenação o Fatores políticos o Relacionamento Interpessoal
4.3. Discussão sobre os aspectos identificados
A identificação dos aspectos citados anteriormente não indica que eles são ou podem ser sinônimos de dificuldades ou problemas dentro dos projetos em ambientes de desenvolvimento distribuído de software. Eles apenas indicam que estes aspectos estão neste tipo de ambiente e devem ser considerados. Os principais problemas identificados nos projetos estudados estão relacionados com alguns destes aspectos. Observaram-se dificuldades em definir um protocolo de comunicação adequado, dificuldades em se comunicar formalmente, decorrentes do problema com o idioma diferente (uma equipe do Brasil freqüentemente não entendia o que uma equipe dos Estados Unidos estava querendo dizer). Além
disso, alguns problemas relacionados às diferenças culturais foram identificados com o projeto em andamento, e isto comprometeu algumas atividades e em certos casos afetou o relacionamento interpessoal e a confiança entre as equipes. Identificaram-se também muitos problemas na fase de levantamento de requisitos dos projetos e de sincronização de ambientes, bem como da utilização do mesmo processo de desenvolvimento de software por parte das equipes geograficamente distribuídas. Neste sentido, embora os dados extraídos da coleta realizada tenham identificado alguns problemas decorrentes da existência destes aspectos em ambientes de desenvolvimento distribuído de software, a principal contribuição da identificação destes aspectos é a possibilidade de atuar de forma preventiva ao invés de atuar de forma reativa aos problemas. O que se viu na maioria das dificuldades encontradas é que a equipe espera algum problema ocorrer para então decidir como agir. Neste caso, muito tempo pode ser gasto e a solução ainda assim não ser encontrada. Por isso, este estudo discute a possibilidade da utilização de mapas conceituais para representar hierarquicamente as dimensões e os aspectos existentes em cada uma delas, bem como a relação entre os aspectos presentes, podendo evidenciar as possíveis causas de problemas.
5. Mapas Conceituais como um recurso
facilitador em ambientes de DDS
A idéia de utilizar mapas conceituais como um recurso facilitador para projetos em ambientes de DDS surgiu da
possibilidade de representar, através de diagramas, os aspectos envolvidos em um determinado projeto e a relação entre eles. Acredita-se que são poucas as pessoas que, trabalhando em ambientes de desenvolvimento distribuído de software, conseguem visualizar a complexidade envolvida antes de algum problema ocorrer. Talvez nem os mapas conceituais consigam representar da melhor maneira possível os aspectos existentes e a relação entre eles. Mas vislumbra-se a possibilidade de atuar de forma preventiva utilizando-se mapas conceituais como recurso.
Desta forma, a idéia é criar um mapa conceitual geral, unindo o conhecimento de todos os projetos já desenvolvidos de forma distribuída, e ao mesmo tempo também se pretende criar um mapa conceitual para cada projeto, que contém informações apenas do mesmo. Desta forma, quando um projeto é iniciado, a equipe do projeto consulta o mapa conceitual geral para identificar os aspectos identificados ao longo de todos os projetos, qual a relação existente, e assim é possível concentrar os esforços em ações preliminares que podem evitar ou minimizar diversos problemas que ocorrem naturalmente em projetos deste tipo, simplesmente por não haver algum trabalho de prevenção.
5.1. Exemplificando
Para entender melhor a proposta deste estudo, a seguir (Figura 4) apresenta-se o que se espera de um mapa conceitual de um projeto desenvolvido em um ambiente de desenvolvimento distribuído de software.
O exemplo da figura 4 não ilustra todos os conceitos possíveis envolvidos no projeto, sendo apenas de caráter ilustrativo. Um estudo mais aprofundado deve ser feito de modo a gerar um mapa conceitual que represente todos os conceitos envolvidos em um determinado projeto e um mapa conceitual geral, considerando o histórico de projetos desenvolvidos na organização.
6. Considerações Finais
Este artigo avançou o conhecimento na área de DDS, identificando aspectos importantes existentes em ambientes de desenvolvimento distribuído de software e discutindo a possibilidade de representar estes aspectos através de mapas conceituais, facilitando a visualização e o entendimento da relação entre eles.
Para isso, primeiramente identificaram-se alguns dos principais aspectos existentes em ambientes de DDS, considerando-se duas dimensões: a dimensão técnica, composta de conhecimentos considerados como base para a construção de software, e a dimensão não-técnica, composta de conhecimentos que são a base para a estruturação dos conhecimentos técnicos.
Logo após, discutiu-se a possibilidade da utilização de mapas conceituais para organizar e visualizar os aspectos existentes em um determinado projeto, objetivando auxiliar o gerente de projeto e a sua equipe a entender que aspectos estão presentes quando se desenvolve software de forma distribuída, a priorização de atividades e a relação entre elas. Também se propôs a criação de um mapa conceitual geral, representando o conhecimento consolidado de todos os projetos desenvolvidos em ambientes de DDS, possibilitando assim um aperfeiçoamento do trabalho, trabalhando de forma pró-ativa ao invés de uma forma repró-ativa, recorrendo-se também a informações históricas dos projetos.
Desenvolver software em ambientes de desenvolvimento distribuído tem se tornado uma atividade cada vez mais freqüente. Muitas dificuldades estão presentes, e cada vez mais se percebe a importância do papel de outras áreas do conhecimento nesta atividade. Entre elas é possível citar a psicologia, a sociologia e a educação. Desta forma, como mapas conceituais têm sua origem também da área da educação, através das teorias de Ausubel, acredita-se que esta abordagem pode ser útil no sentido de auxiliar equipes de projeto a trabalharem de uma forma mais sólida. E se existem dificuldades em motivar uma troca de experiências através de conversas ou ambientes de gestão de conhecimento, a utilização de mapas conceituais talvez possa contribuir no sentido de mostrar a importância de cada aspecto existente, e quem sabe, no futuro, motivar a criação de outros recursos para trabalhar na prevenção de problemas existente em ambientes de DDS, desde que estes recursos estejam
adequados aos interesses da organização e ao investimento que se deseja fazer neste sentido.
7. Referências
[1] Cockburn. A. Agile Software Development – The
Agile Software Development Series. Addison-Wesley,
2002.
[2] Damian, D., The study of requirements engineering in
global software development: as challenging as important, Anais do International Workshop on Global
Software Development – ICSE 2002, Florida, USA,
2002.
[3] Evaristo, R., and Scudder, R., Geographically
Distributed Project Teams: A Dimensional Analysis,
Anais do 33o Hawaii International Conference on
Systems Sciences, 2000.
[4] Grinter, R. E., Herbsleb, J. D., and Perry, D. E, The
Geography of Coordination: Dealing with Distance in R&D Work. ACM, 1999.
[5] Herbsleb, J.D. and Grinter, R. (1999): Splitting the
organization and integrating the code: Conway's Law revisited, Anais da 21a International Conference on
Software Engineering (ICSE 99), 85-95.
[6] Herbsleb, J.D., Mockus, A., Finholt, T.A. and Grinter, R. E., An empirical study of global software development:
distance and speed, Anais da International Conference
on Software Engineering, Toronto, Canada, pp 81-90,
2001.
[7] Herbsleb, J. D., and Moitra, D., Global Software
Development, IEEE Software, pp. 16-20.
March/April/2001.
[8] McConnel, S., Rapid Development. Microsoft Press, 1996.
[9] Pressman, R. S., Software Engineering: A
Practitioner’s Approach. Quinta Edição, 2001.
[10] Prikladnicki, R., Audy, J., and Evaristo, R.,
Distributed Software Development: Toward an understanding of the relationship between project team, users and customers, Anais da 5a International
Conference on Enterprise Information Systems, Angers,
France, 2003.
[11] Prikladnicki, R., Audy, J., and Evaristo, R.,
Requirements Management in Global Software Development: Preliminary Findings from a Case Study in
a SW-CMM context, Anais do Workshop on Global
Software Development, ICSE 2003, Portland, Oregon,
2003.
[12] Yin, R. K, Case study research: design and
methods, Sage, 2001.
[13] Layzell, P., Breneton, O. P., French, A., Supporting
Collaboration in Distributed Software Engineering Teams, Anais da 7a Asia-Pacific Software Engineering
Conference, 2000.
[14] Desouza, K. C., Evaristo, J. R. Managing Knowledge
in Distributed Projects, Communications of the ACM,
2002.
[15] Rus, I. Lindvall, M., Knowledge Management in
Software Engineering, IEEE Software, pp. 26-38.
May/June, 2002.
[16] Kiel, L. Experiences in Distributed Development: A
Case Study, Anais do Workshop on Global Software
Development, ICSE 2003, Portland, Oregon, 2003.
[17] Giraffa, L. Mapas Conceituais, Apresentação da
disciplina de Inteligência Artificial, Mestrado em
Ciência da Computação, PUCRS, 2003. Disponível online em www.inf.pucrs.br/~giraffa, último acesso em 10/05/2003.
[18] Giraffa, L. Página da disciplina de Inteligência
Artificial, Mestrado em Ciência da Computação, PUCRS,
2003. Disponível online em www.inf.pucrs.br/~giraffa, último acesso em 12/05/2003.
