FACULDADE LOURENÇO FILHO
SISTEMAS DE INFORMAÇÃO
NATHAN AZEVEDO GUIMARÃES
UMA ABORDAGEM DE REUSO UTILIZANDO REPOSITÓRIOS
PARA ARTEFATOS DE SOFTWARE COM REDES SOCIAIS
FORTALEZA/CE
2010
FACULDADE LOURENÇO FILHO
SISTEMAS DE INFORMAÇÃO
NATHAN AZEVEDO GUIMARÃES
UMA ABORDAGEM DE REUSO UTILIZANDO REPOSITÓRIOS
PARA ARTEFATOS DE SOFTWARE COM REDES SOCIAIS
Monografia
apresentada
à
Faculdade Lourenço Filho,
como requisito parcial para a
obtenção do grau de Bacharel
em Sistemas de informação.
Orientador: Msc. Nauber Gois
FORTALEZA/CE
2010
NATHAN AZEVEDO GUIMARÃES
UMA ABORDAGEM DE REUSO UTILIZANDO REPOSITÓRIOS
PARA ARTEFATOS DE SOFTWARE COM REDES SOCIAIS
Monografia apresentada à Faculdade Lourenço Filho como requisito parcial
para obtenção do grau de Bacharel em Sistemas de Informação.
Monografia aprovada em: ______ / ______ / ______
Nota obtida: ______________
BANCA EXAMINADORA
___________________________________
Prof. Msc. Francisco Nauber Gois(FLF)
_______________________________________
Prof. Msc. André Barros Pereira (FLF)
___________________________________
Prof. Msc. João Frederico Rolosn Viana (FLF)
DEDICATÓRIA
Dedico essa monografia a minha família.
AGRADECIMENTOS
Agradeço aos meus pais por me proporcionarem e apoiarem nessa
conquista.
Agradeço o suporte de minha família em todos os momentos difíceis,
inclusive nas revisões gramaticais da minha monografia (Neusa e Sergio).
Agradeço ao meu orientador Nauber Gois pela dedicação e o ótimo
trabalho.
Agradeço o apoio de meus amigos e colegas durante mais essa fase,
especialmente a Jehny e Michelle.
Agradeço aos meus professores pela paciência e dedicação durante minha
graduação.
Grato a todos pelo apoio que mostraram sem exigir nada em troca.
"O que prevemos raramente
ocorre;
o
que
menos
esperamos
geralmente
acontece."
Benjamin Disrael.
RESUMO
O uso de repositórios para artefatos reutilizáveis de software tem se mostrado uma
ótima abordagem para se promover o reuso sistemático, consequentemente,
diminuindo os custos do processo de desenvolvimento de software nas suas
diferentes fases. Entretanto a abordagem de reuso utilizando repositórios não é
eficiente na promoção dos artefatos contidos, bem como na evolução dos artefatos e
profissional dos próprios desenvolvedores. Esse trabalho apresenta um estudo de
uma abordagem de reuso com repositórios para artefatos de software reutilizáveis
combinada aos conceitos de redes socais para promoção evolução dos mesmos,
bem como a evolução dos desenvolvedores. O estudo foi realizado a partir de
pesquisas bibliográficas e de mercado, resultando num projeto de um ambiente onde
o reuso dos artefatos é promovido através da interação entre os desenvolvedores, o
que também promove as transformações básicas de conhecimentos tácitos em
explícitos e vice-versa.
Palavras-chave: Repositórios, Redes sociais, Reuso.
LISTA DE FIGURAS
FIGURA 1 – DIAGRAMA DE OBJETOS PARA IMPLEMENTAÇÃO DE UM REPOSITÓRIO PARA ARTEFATOS PROPOSTO
POR EZRAN.....................................................................................................................................
23
FIGURA 2 - TELA INICIAL DO SISTEMA PROPOSTO. ...................................................................................... 39
FIGURA 3 – DIAGRAMA DE CASOS DE USO DO AMBIENTE PROPOSTO. .......................................................... 40
FIGURA 4 - DIAGRAMA DE CLASSES DO CROSSDEV. .................................................................................. 41
FIGURA 5 - TELA DE VISUALIZAÇÃO DE ARTEFATOS. ................................................................................... 44
TABELA 1 - BENEFÍCIOS DO REUSO. .......................................................................................................... 14
LISTA DE SIGLAS E ABREVIATURAS
UML
– Unified Modeling Language.
CORBA
– Common Object Request Broker Architecture
CBSE
– Component-Based Software Engineering
COTS
– Comercial off-the-shelf
IDE
– Integrated Development Environment
SUMÁRIO
1
INTRODUÇÃO ...................................................................................................................................6
1.1
MOTIVAÇÃO ......................................................................................................................................6
1.2
OBJETIVOS .......................................................................................................................................8
1.4
ESTRUTURA DA MONOGRAFIA ............................................................................................................8
2
DISTRIBUIÇÃO DE ARTEFATOS UTILIZANDO UM REPOSITÓRIO.............................................9
2.1
REUSO ........................................................................................................................................... 11
2.1.1
REUSO OPORTUNÍSTICO ............................................................................................................... 12
2.1.2
REUSO DE OBJETOS E FUNÇÕES ................................................................................................... 13
2.1.3
REUSO DE COMPONENTES ........................................................................................................... 13
2.1.4
REUSO DE SISTEMAS DE APLICAÇÕES ........................................................................................... 14
2.2
TÉCNICAS PARA REUSO DE ARTEFATOS ........................................................................................... 15
2.2.1
PADRÕES DE PROJETO (DESIGN PATTERNS)................................................................................. 16
2.2.2
FRAMEWORKS DE APLICAÇÃO ...................................................................................................... 17
2.2.3
ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES .............................................................. 18
2.3
REPOSITÓRIOS PARA ARTEFATOS ................................................................................................... 20
2.3.1
CATÁLOGO .................................................................................................................................. 21
2.3.2
MODELAGEM DA ESTRUTURA DE UM REPOSITÓRIO PARA ARTEFATOS. ............................................. 22
2.4
3
EXEMPLOS DE REPOSITÓRIOS ......................................................................................................... 25
REDES SOCIAIS ............................................................................................................................ 27
3.1
AS REDES SOCIAIS E AS ORGANIZAÇÕES ......................................................................................... 28
3.2
OS TIPOS DE INFORMAÇÕES E SUA UTILIZAÇÃO NA REDE SOCIAL ...................................................... 29
3.3
A IMPORTÂNCIA DAS REDES SOCIAIS SOBRE AS INFORMAÇÕES ......................................................... 30
3.4
TIPOS DE REDES SOCIAIS ................................................................................................................ 31
3.4.1
FÓRUNS DE DISCUSSÕES ............................................................................................................. 31
3.4.2
BLOGS ........................................................................................................................................ 32
3.5
4
FERRAMENTAS PARA CRIAÇÃO DE REDES SOCIAIS ........................................................................... 33
REUSO UTILIZANDO REPOSITÓRIOS PARA ARTEFATOS COM REDES SOCIAIS. .............. 36
4.1
PESQUISA DE MERCADO.................................................................................................................. 37
4.2
REQUISITOS DO SISTEMA PROPOSTO ............................................................................................... 38
4.3
UMA VISÃO ARQUITETURAL DO SISTEMA PROPOSTO ......................................................................... 39
4.4
NOVOS CRITÉRIOS PARA CLASSIFICAÇÃO DOS ARTEFATOS. .............................................................. 43
4.5
AS INFORMAÇÕES NO REPOSITÓRIO ................................................................................................ 44
4.6
INTEGRAÇÃO COM OUTROS SISTEMAS.............................................................................................. 45
ANEXO A - WIREFRAME DA TELA INICIAL DO AMBIENTE CROSSDEV ...................................... 51
ANEXO B - WIREFRAME ARTEFATOS EM FOCO............................................................................ 52
ANEXO C - WIREFRAME DA TELA INICIAL DA ABA ARTEFATOS DO AMBIENTE CROSSDEV 53
ANEXO D - FORMULÁRIO DE PESQUISA CIENTÍFICA PARTE I. ................................................... 54
ANEXO E - FORMULÁRIO DE PESQUISA CIENTÍFICA PARTE II. ................................................. 55
ANEXO F - FORMULÁRIO DE PESQUISA CIENTÍFICA PARTE III. ................................................. 56
6
1 INTRODUÇÃO
A crescente demanda de sistemas informatizados tem desencadeado uma
busca por técnicas e boas práticas que agilizem o desenvolvimento e melhorem a
“manutenibilidade” do software a ser construído ou modificado (SOMMERVILE,
2007, p. 275).
O reuso de software já era uma prática conhecida há muitos anos, mas
somente na última década essa tornou-se de fato a ser usada no desenvolvimento
de software rotineiro. Essa mudança veio da necessidade de entregas mais rápidas,
prazos mais curtos, custos menores e manutenções mais rápidas. Em meio a essas
mudanças, o software desenvolvido ou adquirido passou a ser visto como um ativo
importante que deveria ser aproveitado ao máximo, sendo assim, pode-se concluir
que uma das soluções seria aplicar técnicas de reuso (SOMMERVILE, 2007, p. 276).
Durante o desenvolvimento dos sistemas, alguns artefatos podem ser
reusados, mesmo que informalmente. Isso ocorre quando os envolvidos no projeto
conhecem os artefatos de outros projetos e os reutilizam, às vezes até mesmo
modificando e incorporando-os em seus sistemas (SOMMERVILE, 2007, p. 275).
Conclui-se que esse tipo de reutilização não é uma abordagem eficiente, pois podem
existir artefatos que cumpram com a necessidade de um desenvolvedor da
instituição e esse não conheça o mesmo, fazendo com que seja construído um
segundo artefato, trazendo um retrabalho quando este custo poderia ser evitado.
Uma das ideias mais populares para a promoção do reuso são os repositórios
para artefatos de software, em que estes artefatos reutilizáveis são disponibilizados
num ambiente de distribuição comum para um grupo de indivíduos, seja na intranet
ou internet. Nesse trabalho serão abordadas as características comuns desses
repositórios e os conceitos envolvidos no reuso de artefatos.
1.1
Motivação
A reutilização de artefatos de software através de repositórios não é uma ideia
nova, entretanto, pode-se encontrar alguns riscos ou problemas pertinentes do fator
humano ou do processo para desenvolvimento adotado (SANCHES, 2005;
PRESSMAN, 2006). Isso pode ocorrer mesmo com todas as técnicas e conceitos
7
que facilitam e indicam essa prática, tais riscos apresentados abaixo, podem ser
minimizados através da implementação de técnicas e conceitos apresentadas no
capítulo 4.
O processo de desenvolvimento que adote o reuso de artefatos pode ser
acometido pelo insucesso devido à síndrome do NIH, do inglês Not Invented Here,
que acomete os desenvolvedores de forma a acreditar, que todo software que é
desenvolvido por terceiros não é tão eficiente e nem possui qualidade tanto quanto o
desenvolvido pessoalmente (NORTON apud SANCHES, 2005). Uma das possíveis
soluções para se resolver este problema é a de tornar mais próximos os
desenvolvedores que se utilizam dos componentes, dos seus criadores, através de
uma rede social, demonstrando suas qualificações, ou a quantidade de pessoas que
aprovam ou que já utilizaram esses componentes.
Existe também a possibilidade de que ao se adquirir um artefato de software
de terceiros, os mesmos não sejam confiáveis, sejam por questões legais, de
qualidade ou de segurança, contendo algum código malicioso em meio a seu código
fonte que possam vir a prejudicar a organização ou os usuários da aplicação
(TRACZ apud SANCHES, 2005).
Durante o desenvolvimento, é normal que o artefato contenha algumas falhas
de baixa severidade, porém, se esse componente for reusado num contexto
diferente, a falha pode tornar-se de alta severidade ou no caso de serem
encontradas diversas falhas, isso pode acabar resultando desencorajamento de todo
o programa de reuso, por parte do desenvolvedor e sua equipe (MCCONNELL apud
SANCHES, 2005). Se há uma aproximação entre a equipe que está desenvolvendo
o projeto e os criadores, os erros podem ser reportados mais diretamente, isso pode
trazer ganhos tanto na qualidade, já que erros corrigidos no artefato disponibilizado
no repositório podem ser refletidos com menos impacto nos projetos que já o
utilizam, mantendo assim a confiança e vantagem do reuso, tendo como base que
esse artefato foi construído de acordo com os padrões apresentados neste trabalho
no capitulo 2.
Verifica-se que há diversos problemas de âmbito social na utilização de
repositórios para artefatos, mesmo numa organização, onde os envolvidos no
processo de disponibilização e reuso são devidamente identificados. Uma das
soluções poderia ser a de repositório para artefatos reutilizáveis incorporado a redes
8
sociais com o intuito de aproximar os desenvolvedores como um todo, maximizando
assim o reuso e qualidade dos artefatos nas organizações, com base no aumento da
confiança dos artefatos disponibilizados, bem como na promoção desses.
1.2
Objetivos
O trabalho de monografia tem como objetivo realizar um estudo sobre o uso
de repositórios de artefatos, utilizando redes sociais com o intuito de aumentar
eficientemente o reuso, qualidade e promoção dos artefatos disponibilizados, bem
como definir as características básicas da integração de ambos os conceitos.
1.3
Estrutura da monografia
O capítulo 2 explana sobre os conceitos básicos sobre a reuso e a distribuição
de artefatos utilizando um repositório de software. Nos tópicos relativos à distribuição
de artefatos é descrito um repositório com ideias baseadas em conceitos de
diferentes autores e são citados exemplos de repositórios.
No capitulo 3 são abordadas as redes sociais, seus tipos, suas formas de
utilização e sua importância num contexto organizacional. Nesse capítulo também
são apresentados alguns exemplos de ferramentas que poderiam ser usadas para
criação de redes sociais.
No capítulo é proposto uma abordagem de reuso utilizando repositórios para
artefatos de software reutilizáveis combinada aos conceitos de redes socais. Esse
capítulo agrupa detalhes que correspondem ao planejamento do ambiente citado
anteriormente, inclusive uma pesquisa de mercado realizada em algumas
organizações para definir o nível de reuso e as ferramentas utilizadas a fim de
justificar a proposta.
9
2 DISTRIBUIÇÃO DE ARTEFATOS UTILIZANDO UM REPOSITÓRIO
Este capítulo dedica-se à explanação de conceitos referentes a um repositório
para artefatos de software, bem como os conceitos básicos que embasem a ideia,
como: componentes, artefatos e como reutilizá-los.
Segundo Pádua (2005, p. 8), um artefato é um produto de software, que pode
ser códigos executáveis, códigos fontes, modelos, relatórios e outros documentos.
Então,
temos
que
um
artefato
é
qualquer
resultado
gerado
durante
o
desenvolvimento de um software. Note que esse conceito aproxima-se do conceito
de componente, abordado por Booch et al(1998).
Conforme Booch et al(1998), um componente é qualquer elemento de
software que pode ser empacotado, tais como bibliotecas, arquivos, códigos
executáveis e documentos. Essa afirmação define o que chamamos de
componentes reutilizáveis e esses serão inseridos no repositório juntamente com os
outros artefatos reutilizáveis. Portanto, temos um componente como um artefato,
com base no conceito explicado anteriormente.
Componentes ou módulos são itens mais comuns para serem reutilizados
durante o desenvolvimento, por serem artefatos que são geralmente melhores
projetados e separados por funcionalidades ou finalidades, como explica Pádua
(2005) a seguir:
Um módulo é uma unidade de programa discreta e identificável em relação
à compilação, à combinação com outras unidades e à carga. Para UML, um
módulo é uma unidade de armazenamento e manipulação de software.
Módulos são coleções de rotinas, dados e tipos correlatados,
implementados por meio de componentes cuja interface com o restante de
um sistema é bem definida. As interfaces dos componentes de um módulo
podem também ser consideradas as interfaces do módulo. Um módulo pode
conter outros módulos, formando uma hierarquia (PÁDUA, 2005).
Segundo Ezran (apud SANCHES, 2005), podemos classificar componentes
em dois tipos distintos:

Componentes Verticais;

Componentes Horizontais.
10
Componentes Verticais são aqueles componentes que estão vinculados a um
domínio de aplicação, ou seja, englobam as regras de negócio embutidas nas
aplicações da empresa e com isso representam o know-how da organização e sua
vantagem competitiva frente à concorrência (SANCHES, 2005). Exemplos de
componentes verticais:

Modelos de objetos financeiros;

Bibliotecas C++ para instrumentos médicos;

Design e código para módulo de gerenciamento de clientes;

Algoritmos para cálculo de geoprocessamento;

Um framework para aplicações de telemetria.
Como explica Sanches (2005), esses componentes são mais difíceis de serem
reutilizados por serem muitos específicos da aplicação, mas não os impede de
serem publicados no repositório com esse intuito.
Em contra partida, Componentes Horizontais são mais genéricos e fáceis de
serem identificados e reusados, além de que geralmente são independentes do
domínio da aplicação. A maior restrição desses componentes é que a arquitetura da
aplicação deve ser compatível com o modelo arquitetural adotado pelo componente
(SANCHES, 2005). Para amenizar o problema, pode-se citar algumas técnicas que
serão abordadas no tópico 2.3.2 – Reuso de componentes. A seguir, alguns
exemplos de componentes horizontais:

Componentes de GUI (Graphical User Interface): tabelas, botões,
campos de texto;

Estrutura de dados e algoritmos básicos (como ordenação por
exemplo);

Bibliotecas de acesso a banco de dados;

Bibliotecas de comunicação de redes;

Serviço de relatórios, trace e logging.
Nota-se que por executarem ou proverem serviços mais ordinários, esses
componentes seriam ótimos candidatos a serem inseridos no repositório. Uma vez
11
inserido no repositório, um componente ou artefato precisa ser classificado para que
seja possível buscá-lo e evitar possíveis ambiguidades durante essa busca.
Segundo Sanches (2005, p. 13), durante a busca e análise de um
componente no repositório, esse pode ser considerado vertical, embora o mesmo
possa ser reusado nos subdomínios da aplicação. Isso ocorre porque os domínios
podem ser definidos de forma muito especifica, embora esses pertençam a domínios
mais genéricos. Como por exemplo, um componente para gerenciamento de
desempenho de redes que pertençam a domínios mais genéricos, como
gerenciamento de redes.
Para evitar essas ambiguidades, a classificação dos componentes deve ser
feita da forma mais precisa possível a fim de aperfeiçoar ainda mais as buscas por
componentes.
2.1
Reuso
Um dos requisitos mais importantes de um artefato a ser inserido no
repositório é que esse seja reusável, para isso existe uma série de técnicas e
padrões que definem e maximizam reusabilidade de um artefato.
Segundo All (2002), Hen (1995) e MCM (1995) (apud Pressman 2006, p. 675),
os casos de estudo aplicados na indústria elucidam substanciais benefícios na
aplicação de um reuso agressivo de software, sendo esses benefícios a qualidade
do produto, a produtividade e os custos globais melhorados.
O conceito de reuso explicado por Sommervile (2007) é baseado em outras
áreas da engenharia, é importante salientar que qualquer item que possa ser
reutilizado poderá ser inserido no repositório.
Isso nos leva a conclusão que
qualquer artefato de software com potencial de reuso possa ser inserido no
repositório.
O processo de projeto, na maioria das disciplinas de engenharia, baseia-se
no reuso de sistemas existentes ou componentes. Engenheiros mecânicos
ou elétricos normalmente não especificam um projeto em que cada
componente tenha de ser fabricado especialmente. Eles baseiam seus
projetos em componentes já experimentados e testados. Esses
componentes não são apenas pequenos componentes como flanges e
válvulas, mas incluem subsistemas maiores, como motores, condensadores
ou turbinas (SOMMERVILE, 2007, p. 275).
12
A reusabilidade não se restringe apenas a componentes de software, essa
visão limita dramaticamente os benefícios da reutilização, podendo até anular
quaisquer benefícios dessa pratica. A componentização (CBD – Component-Based
Development) tem sido uma das práticas que obteve os melhores resultados em
critérios de reutilização, pois o seu conceito de reutilização não se estende apenas
aos códigos executáveis, mas como também a todos os artefatos criados desde a
especificação até distribuição do componente (MAGELA, 2006, p. 46).
Antes de tudo, o reuso é também uma das metas da engenharia de software
mais difíceis de serem atingidas (PRESSMAN, 2006, p. 81). Atualmente, existe uma
estratégia para reuso especializada da engenharia de software, essa, conhecida
como a engenharia de software baseada em reuso, citada por Sommervile como um
processo de desenvolvimento de software voltado para o reuso do software
existente. Embora possa haver problemas na construção desses sistemas, existem
muitos casos de sucesso que demonstram sua viabilidade. (Baker, 2002; Balk e
Kedia 2000; Pfarr e Reis 2002 apud SOMMERVILE, 2007, p. 283).
Sobre a engenharia de software baseado em reuso, é possível citar quatro
tipos de reuso, caracterizados pelo “tamanho” de seus conteúdos (SOMMERVILE,
2007, p. 276):

Reuso oportunístico;

Reuso de objetos e funções;

Reuso de componentes;

Reuso de sistemas de aplicações.
2.1.1 Reuso oportunístico
Esta forma de reuso se dá quando o desenvolvedor conhece algum código ou
sistema que possua uma parte que poderá ser reutilizada mediante a alguns ajustes
quando necessário, então, esse desenvolvedor copia essas partes para o novo
sistema, reduzindo assim os investimentos de custo e tempo; essa técnica é
conhecida como “Cut-and-Paste” (SANCHES, 2005).
Essa técnica de reuso é uma das mais perigosas e ineficientes de reuso,
conforme Ezran (apud SANCHES, 2005), pois os fragmentos de códigos são
13
conhecidos apenas por poucos desenvolvedores, além de ser uma prática individual
e aleatória ao longo dos projetos, o que limita ainda mais seu reuso e torna difícil de
implantar em outras áreas ou departamentos da organização, esse artefato que é o
fragmento de código.
Esta abordagem não necessariamente reduz os custos ou melhora a
qualidade, podendo até mesmo influir negativamente nesses fatores quando há
falhas nos códigos copiados e esses se proliferam e diferenciam do código original
aumentando o tempo de desenvolvimento, porque os desenvolvedores são forçados
a corrigir as mesmas falhas diversas vezes em locais diferentes, quando esses
códigos são possíveis de serem encontrados, pois nem sempre é possível rastreálos nos projetos em que foram implantados (SCHMIDT, 2002; EZRAN, 2002 apud
SANCHES, 2005).
2.1.2 Reuso de objetos e funções
O reuso baseado em bibliotecas de funções era comumente utilizado na
década de 40, citado por Sommervile (2007, p. 276),o qual indica que era uma
abordagem particularmente eficiente, pois muitas bibliotecas de códigos para
diferentes aplicações e plataformas estão disponíveis e podem ser facilmente
acopladas a um projeto em desenvolvimento.
2.1.3 Reuso de componentes
Segundo
Sommervile
(2007,
p.
291),
um
componente
médio
é
significativamente maior que um procedimento ou função, e até pouco tempo, era
difícil reusá-los. Os avanços permitiram uma padronização promovida pelos
principais fornecedores de software que possibilitaram uma interoperabilidade de
componentes dentro de um framework, como o CORBA, que impulsionou o reuso
sistemático por meio da técnica conhecida como a CBSE – Component Based
Software Engineering.
Sommervile (2007, p. 292) explica que a CBSE é um processo de integração
de componentes independentes para formação de um novo sistema, conceito esse
fundamental para a promoção e idealização de um repositório de componentes. A
CBSE será explicada com mais detalhes no próximo tópico.
14
2.1.4 Reuso de sistemas de aplicações
Esse conceito de reuso, segundo Sommervile (2007), envolve o reuso de
aplicações inteiras com algumas configurações para integração, caracterizando-se
por ser uma das técnicas mais eficientes de reuso, pois envolve o reuso de grandes
ativos que podem ser rapidamente configurados para criação de um novo sistema.
Podemos citar como exemplo as aplicações comerciais (COTS - Commercial off-theshelf) que são disponibilizadas com uma configuração comum para serem
reutilizadas por diferentes ambientes e usuários (SOMMERVILE, 2007, p. 287).
Um exemplo comum de um produto COTS que foram reusados por muitos
anos são os sistemas de banco de dados, pois poucos desenvolvedores consideram
implementar (SOMMERVILE, 2007).
Além da vantagem óbvia do reuso que é a de redução dos custos de
desenvolvimento, notamos que menos componentes de software têm que passar
pelas fases de desenvolvimento padrões de um produto que são especificação,
projeção, implementação e validação. Entretanto, a redução de custos é apenas
uma das vantagens relativas ao reuso, como demonstrado a seguir:
Tabela 1 - Benefícios do reuso (SOMMERVILE, 2003, p. 261).
Benefícios
Explicação
Maior
Os componentes reutilizados que são empregados nos sistemas em
confiabilidade
operação devem ser mais confiáveis do que os componentes novos.
Eles já foram experimentados e testados em diferentes ambientes. Os
defeitos de projeto e de implementação são descobertos e eliminados
no uso inicial dos componentes, reduzindo, assim, o número de falhas
quando o componente é reutilizado.
Redução dos
Se recorrermos a um componente já existente, serão menores as
riscos de
incertezas sobre os riscos relacionados ao reuso desses componentes
processo
do que sobre os custos de desenvolvimento. Esse é um fator
importante para o gerenciamento do projeto, pois reduz as incertezas
nas estimativas de custos de projeto. É particularmente verdadeiro
quando reutilizamos componentes grandes, como subsistemas.
15
Uso efetivo de
Em vez de os especialistas em aplicações fazerem o mesmo trabalho
especialistas
em diferentes projetos, eles podem desenvolver componentes
reutilizáveis, que englobam seu conhecimento.
Conformidade
Alguns padrões, como padrões de interface com o usuário, podem ser
com os padrões
implementados como um conjunto de componentes-padrão. Por
exemplo, os componentes reutilizáveis podem ser desenvolvidos para
implementar menus em uma interface com o usuário. O uso de
interfaces-padrão com o usuário melhora a confiabilidade, uma vez que
os usuários possivelmente cometem menos enganos quando utilizam
uma interface familiar.
Desenvolvimento
De modo geral, é mais importante fornecer um sistema para o mercado
acelerado
o mais rápido possível do que se prender aos custos gerais de
desenvolvimento. O reuso de componentes acelera a produção, porque
o tempo de desenvolvimento e o de validação tende a ser reduzido.
Verifica-se que os níveis de reuso relacionam-se, pois grandes sistemas
ainda podem ser componentes de outros sistemas maiores, caracterizando assim
uma hierarquia que deve ser considerada ao se classificar o tipo de reuso utilizado.
É possível concluir que o reuso de software mostra-se uma alternativa a
ser considerada pelos desenvolvedores e organizações, não apenas pela redução
de custos, mas também pelo aumento da qualidade, manutenabilidade e redução
dos riscos inerentes ao desenvolvimento.
2.2
Técnicas para reuso de artefatos
O reuso pode ser abordado nos diferentes níveis de um processo de
desenvolvimento, inferindo no mesmo.
Verifica-se que os conceitos que serão apresentados estão intimamente
ligados ao conceito de arquitetura, que na Engenharia de Software possui algumas
definições diferentes dependendo em qual contexto essa palavra é empregada
(MAGELA, 2006, p. 36). Em virtude da definição de arquitetura ser um conceito
chave amplamente utilizado no processo de desenvolvimento de componentes, os
16
parágrafos seguintes definirão seu conceito em cada contexto que esse pode ser
empregado.
No contexto de estilo, arquitetura define quais padrões arquiteturais um
componente deverá atender, delimitando assim o escopo a ser construído. Essa
definição mostra que um componente ou artefato possui um conjunto limitado de
formas que permitam seu uso ou sua reutilização (MAGELA, 2006).
No contexto de software, arquitetura define a forma como um software foi
modularizado, que pode ter diversas finalidades, como induzir o baixo acoplamento
entre os subsistemas (ou módulos), reuso ou eliminação de recursividade (MAGELA,
2006).
Sob a definição de arquitetura de sistemas, temos que essa engloba todas as
dependências
do
software
em
questão,
como
redes,
banco
de
dados,
processadores, infra-estrutura e quaisquer outras dependências.
A visão arquitetural representa uma visão partilhada de todas as definições
apresentadas acima, relevando as partes ditas como menos importantes para
escopo de acordo com os riscos (MAGELA, 2006).
Existem várias técnicas ou tecnologias que através de um contexto de
arquitetura tentam aumentar a eficiência do reuso dos artefatos de software. Note
que nada impede que elas possam ser empregadas em conjunto, aumentando ainda
mais a eficiência em termos de reuso (SANCHES, 2005; SOMMERVILE, 2007). As
técnicas são as seguintes:

Padrões de Projeto;

Frameworks de Aplicação;

Processo de desenvolvimento baseado em componentes;
2.2.1 Padrões de Projeto (Design Patterns)
Ao
tentar
reutilizar
artefatos
executáveis,
o
desenvolvedor
estará
inevitavelmente limitado à arquitetura escolhida para esse artefato. Essa definição
de arquitetura pode variar desde a implementação de algoritmos específicos aos
objetos e tipos descritos nas interfaces desses artefatos (SOMMERVILE, 2007).
17
Verifica-se que projetar uma arquitetura adaptável a diversas situações pode
ser bastante problemático dependendo da complexidade do artefato para o qual
essa arquitetura é definida. Sobre essa perspectiva verificou-se que há certos
padrões no projeto de arquitetura para resolução desses problemas, padrões esses
que podem ser reusados em diferentes aplicações.
Um padrão de projeto não é uma especificação detalhada do problema, e sim
uma abstração que define uma solução baseada em conhecimentos empíricos
comprovados para os problemas descritos por eles. O uso de um padrão de projeto
se dá quando o desenvolvedor verifica que a descrição de um problema se
enquadra na descrição de um padrão de projeto comum a ele, sendo assim, o
desenvolvedor aplica esse padrão (PRESSMAN, 2006; SANCHES, 2005).
De acordo com Gamma (apud SANCHES, 2005), padrões de projeto são uma
tentativa de superar o reuso de artefatos na busca de reusar também o projeto de
arquitetura de uma aplicação. Uma clara vantagem na utilização de padrões de
projeto é a facilidade de comunicação entre os desenvolvedores, promovida pela
definição de um nome comum para uma determinada solução arquitetural (EZRAN
apud SANCHES, 2005).
2.2.2 Frameworks de Aplicação
Um framework é um agrupamento de classes concretas e abstratas, e
interfaces que tem um objetivo em comum, como um subsistema. Comportamentos
específicos são adicionados através da implementação das classes abstratas ou
configurações específicas nos insumos desse subsistema. Note que um framework
raramente é uma aplicação propriamente dita, geralmente ela é formada pela
integração de vários frameworks (SOMMERVILE, 2007, p. 282).
Conforme Sommervile (2007), um framework é uma arquitetura genérica que
pode ser utilizada para criar um subsistema ou aplicação mais específica, sendo
apontado como um problema dessa técnica o tempo necessário para se aprender a
utilizá-lo, que encoraja a criação de profissionais especialistas em determinados
frameworks. A arquitetura de um framework em particular geralmente se utiliza de
padrões de projeto para a sua organização, o que lhe garante um rápido
entendimento de como o framework poderá ser agrupado para criação de um novo
sistema.
18
2.2.3 Engenharia de software baseada em componentes
O processo de desenvolvimento de componentes reutilizáveis conta com uma
especialização da engenharia de software, chamada de engenharia de software
baseada em componentes, que prove algumas técnicas e conceitos fundamentais
no momento da projeção de um software (SOMMERVILE, 2007).
Existem alguns pontos essenciais da engenharia de software baseados em
componentes citados por Sommervile (2007, p. 292) que se deve ter em mente no
momento da projeção dos mesmos:

Componentes independentes: são componentes com a inclusão de
interfaces, que são descrições da arquitetura de comunicação de
um
componente,
implementação
em
dos
que
essas
componentes
servirão
de
para
suas
separar
a
interfaces
de
integração
de
comunicação com os sistemas que os usarão.

Padrões
de
componentes
que
facilitam
a
componentes: São padrões de interface que definem a forma como
os componentes comunicam-se, sendo assim implementados por
todos os componentes e esses estiverem de acordo com os
padrões, os mesmos deverão ser independentes de linguagem de
programação.

Um middleware que forneça apoio de software para integração de
componentes: É Utilizado quando se necessita de um software que
controle a comunicação entre componentes independentes e
distribuídos, como o CORBA, que manipula os recursos de baixo
nível eficientemente e permite enfocar problemas relacionados à
aplicação. Além disso, um middleware que implemente o modelo de
componentes pode fornecer apoio à alocação de recursos, ao
gerenciamento de transações, à proteção e à concorrência.

Processo de desenvolvimento voltado à engenharia de software
baseado em componentes.
Pressman (Engenharia de software, 2006, p. 665) explica que a engenharia
de software baseada em componentes nasceu da necessidade de construção de
19
sistemas complexos e de alta qualidade, em prazos menores. Isto também é uma
das premissas do reuso de software, sendo também uma das abordagens do reuso.
A
construção
de
componentes
reutilizáveis
procura
disponibilizar
componentes que possam ser agrupados facilmente, a fim de formar novos
sistemas. Entretanto, não se pode construir um sistema apenas selecionando
componentes de software reutilizáveis e conectá-los de forma automática a fim de
formar um sistema completo. A atividade de inter-relacionamento de componentes é
uma das mais difíceis de serem resolvidas pela engenharia de software atualmente
(SZYPERSKI apud SANCHES, 2005).
O processo CBSE (Component-Based Software Engineering) não deve
apenas ter como atividades a identificação de candidatos a componentes, mas
também a adaptação de interfaces entre os componentes a fim de criar sistemas
atendendo aos requisitos dos mesmos, atualizando-as caso necessário e
classificando-os segundo os critérios de qualidade adotados (PRESSMAN, 2006, p.
663).
O ponto crítico para um desenvolvedor que utiliza a engenharia de software
baseada em componentes é a analise de domínio, em que o desenvolvedor precisa
projetar os componentes de modo a atender a uma grande variedade de aplicações
num domínio especifico (SANCHES, 2005, p. 38).
Uma vantagem clara para a utilização dessa engenharia é eficiência na qual
se desenvolve novas aplicações em termos de prazo, pois a utilização de
componentes prontos que necessitam de poucas adaptações reduz dramaticamente
o tempo de desenvolvimento de um sistema, reduzindo por consequência o custo do
mesmo (SANCHES, 2005, p. 38).
É possível notar que o emprego da engenharia de software baseada em
componentes aumenta dramaticamente a possibilidade de reutilização e construção
de artefatos com essa característica, consequentemente propiciando uma ótima
abordagem a ser utilizada em conjunto a um ambiente para distribuição de artefatos
utilizando um repositório.
20
2.3
Repositórios para Artefatos
Um repositório para artefatos de software é um local para armazenamento de
artefatos que podem ser reutilizados, a fim de prover a disponibilização para os
interessados. Nota-se que este repositório conterá informações intelectuais
importantes da empresa, fazendo com que deva ser criada uma forma de acesso e
identificação para os usuários (SANCHES, 2005).
A distribuição de artefatos de software reutilizáveis utilizando um repositório
não é um tema novo na engenharia de software, porém ainda não existe solução
eficiente para propagação do reuso desses artefatos, bem como descrição ou
classificação dos artefatos que residem no repositório, mostrando-se ainda um
problema sem resposta definitiva (PRESSMAN, 2006, p. 273). Ainda assim, como
Pressman (2006, p. 665) sugere, num contexto ideal, onde os artefatos que já
existem, deveriam ser pesquisados e retornados de um repositório centralizado e
disponibilizados para os desenvolvedores.
Pressman (2006, p. 674) propõe que um ambiente semelhante a um conceito
de biblioteca, contendo, em vez de livros, artefatos para reuso software, devendo
preencher os seguintes critérios básicos:

Um
banco
de
dados
para
armazenar
capaz
de
guardar
componentes de software e a informação de classificação
necessária para recuperá-los;

Um sistema de gestão de bibliotecas que forneça acesso ao banco
de dados;

Um sistema de recuperação de componentes de software (por
exemplo, um negociador de solicitação entre objetos) que permita a
uma aplicação capaz de recuperar componentes e serviços do
servidor da biblioteca;

Ferramentas CBSE que dão suporte à integração de componentes
reusados a um novo projeto ou implementação.
Esta biblioteca, denominada de biblioteca de reuso, pode ser um componente
de um repositório maior para artefatos de software reusáveis, fornecendo facilidades
para a guarda de componentes de software e uma serie de artefatos reusáveis,
21
como por exemplo, especificações, projetos, padrões, frameworks, fragmentos de
código, casos de teste, guias de usuário (PRESSMAN, 2006, p. 674).
Segundo Ezran (apud SANCHES, 2005), existe uma lista de vantagens
relacionadas ao uso de um repositório para artefatos reutilizáveis de software, como
por exemplo:

Lugar único para a pesquisa e armazenamento dos artefatos;

Forma padronizada para documentar e enumerar os artefatos;

Forma padronizada para controlar mudanças e melhorias nos
artefatos.
2.3.1 Catálogo
A idéia de repositório pressupõe um catálogo, em que estes artefatos serão
devidamente identificados para um posterior reuso. No caso, onde haja poucos
artefatos reutilizáveis ou pouco desenvolvedores, pode-se questionar se há
necessidade de criação de um repositório (SANCHES, 2005).
No decorrer do crescimento do número de artefatos reusáveis, haverá a
necessidade de definir e reestruturar o catálogo dos mesmos, pois o desenvolvedor
poderá deparar-se com situações as quais não sabe que artefatos ele poderá
reutilizar, ou não saber onde encontrar um artefato, ou onde armazená-lo
(SANCHES, 2005). Verifica-se, então, que há uma necessidade de manutenção
desse repositório com relação aos artefatos que já existem nele.
Há dois modos de manutenção do repositório, a forma gerenciada, que
alguém ficará responsável pelo controle do repositório; e a forma não gerenciada, a
qual ninguém ficará responsável por esse controle. Esta segunda forma acarreta na
variação da taxa de reuso dos componentes, pois o próprio desenvolvedor ficará
responsável por saber encontrar cada artefato, que provavelmente estará misturado
em meio a outros, além do risco de utilizar uma versão obsoleta daquele
(SANCHES, 2005).
22
2.3.2 Modelagem da estrutura de um repositório para artefatos.
Embora os artefatos de software compartilhem de características comuns,
estes podem variar quanto à linguagem, ao formato de arquivo, à granularidade e à
documentação (EZRAN apud SANCHES, 2005, p. 63). Contudo, como visto
anteriormente, faz-se necessário um catalogo de artefatos para o repositório, com
intuito de facilitar as buscas e identificação dos artefatos, com isso, pode-se concluir
que o repositório será composto por um catálogo e de vários artefatos reutilizáveis.
Tem-se que os artefatos podem ser diferentes entre si, porém, em termos de
modelagem, todos possuem informações para sua classificação, as quais serão
referenciadas no catálogo. Esta parte comum são as informações, que em conjunto,
formam sua ficha cadastral, a qual será referenciada pelo catálogo. A outra parte é o
“corpo” do artefato em si, que pode conter outro conjunto de artefatos (EZRAN apud
SANCHES, 2005, p. 63).
A ficha cadastral de um artefato também pode ser chamada de metadado,
devendo essa conter uma série de campos a fim de facilitar sua busca no catálogo
(NORTON apud SANCHES, 2005). Norton propõe uma ficha cadastral para artefatos
com as seguintes informações:

Nome único de identificação do artefato;

Autor;

Data de criação;

Data da última atualização;

Versão atual;

Lista de palavras chave associadas ao artefato;

Breve descrição do componente (área de uso ou tecnologia
envolvida).
Detalhes relativos à usabilidade, instalação e descrição dos artefatos
poderiam ser descritos em documentos a parte, ou no próprio corpo do artefato.
Outra informação importante sobre o artefato seria a sua localização, seja num
servidor interno a organização ou externo em posse de terceiros (NORTON apud
SANCHES, 2005).
23
Ezran (apud SANCHES, 2005) propõe o seguinte modelo básico, descrito na
linguagem UML como um diagrama de objetos de um repositório para artefatos:
Figura 1 – Diagrama de objetos para implementação de um repositório para artefatos
proposto por Ezran (apud SANCHES, 2005).
O modelo acima representa a diagramação do repositório e pode ser descrito
da seguinte forma:

Um repositório possui apenas um catalogo;

Um catálogo possui zero ou mais fichas cadastrais;

Uma ficha cadastral descreve um componente, que por sua vez é
armazenado num único repositório;

Um componente possui um único corpo ou conteúdo.
A partir do modelo descrito por Ezran, verifica-se que esse repositório não
garante o versionamento dos artefatos inseridos, bem como também restringe o
artefato a uma localização física. Alem da visão arquitetural do contexto do
repositório Ezran propôs as possíveis atividades realizadas pelos usuários:

Busca pelo artefato;

Inclusão de um novo artefato;

Alteração de um artefato;
24

Exclusão de um artefato;

Visualização do catálogo;

Organização do catálogo;

Histórico dos artefatos;

Estatísticas sobre o repositório;

Controle de acesso.
O repositório deverá prover as informações básicas de manutenção, como
busca, inclusão, alteração e exclusão dos artefatos contidos nele bem como as
informações da ficha cadastral dos artefatos. A operação de busca poderia ser
incrementada com mecanismos avançados de busca por informações da ficha
cadastral do artefato (EZRAN, MORISIO e COLIN, 2002).
A visualização do catalogo de artefatos do repositório provê um meio rápido
de visualização de todos os artefatos contidos no repositório, que no caso de existir
apenas algumas dezenas de artefatos no repositório torna uma excelente
abordagem de busca (EZRAN, MORISIO e COLIN, 2002).
No caso do repositório conter vários artefatos, a busca sobre suas
informações podem se tornar ineficientes em vista da quantidade de resultados
retornados, sendo assim, verifica-se que pode ser necessário uma forma de
classificação dos artefatos por sua estrutura (exemplo: framework, tutorial, código,
template etc), áreas de aplicação (JAVA, Biologia, Matemática, Segurança, C++,
etc.) ou palavras que fazem analogia à descrição do artefato (EZRAN, MORISIO e
COLIN, 2002).
Durante o uso do repositório, haverá casos em que um artefato deverá ser
substituído por outro, seja por melhorias ou correções, as informações sobre essas
mudanças, como autor da mudança, uma lista de modificações feitas no artefato e
data da mudança, deverão ser armazenadas para uma futura auditoria ou contato
com os responsáveis de alguma forma, levando em consideração a sugestão de
Ezran, na sua ficha cadastral (EZRAN, MORISIO e COLIN, 2002).
25
2.4
Exemplos de repositórios
Existem diversos repositórios para artefatos de software reutilizáveis, eles
podem ser de acesso publico ou privado. Na internet encontram-se disponíveis
inúmeros repositórios públicos para artefatos, dentre eles é possível citar alguns
como:

jars (1998): Repositório especializado na linguagem Java que
apresenta componentes e programas executáveis para solução de
problemas ou que auxiliem no desenvolvimento de software. Possui
uma forma de classificação por categoria, em que os artefatos
podem ser categorizados em suas áreas de aplicação como
matemática, biologia, jogos ou gráficos 3D;

SourceForge (1999): Um dos mais conhecidos repositórios públicos
para artefatos de software de código aberto. Nesse site é possível
encontrar artefatos que podem ser agregados sem custos a uma
aplicação, ou se utilizar o próprio domínio como um repositório para
o projeto e os desenvolvedores que queiram colaborar como
codificadores;

planetsourcecode (1997): É outro repositório para artefatos e
tutoriais para diversas linguagens de programação. A maioria de
seus artefatos consiste de fragmentos de códigos, o que nos leva a
conclusão de um repositório voltado para o reuso oportunístico.
Os exemplos citados acima possuem o problema da síndrome do N.I.H. (Not
invented here), ou seja, um problema de confiança nos artefatos por parte da
organização ou dos próprios desenvolvedores. No entanto, os repositórios
desenvolvidos e utilizados internamente nas organizações estão livres da maioria
desses problemas, pois os desenvolvedores podem ser devidamente identificados.
Pode-se citar como exemplo de um repositório projetado para ser usado
internamente a organização: o CORE, utilizado e desenvolvido pela empresa
brasileira C.E.S.A.R (2008). Suas características são descritas a seguir:

Projetado para apoiar o reuso sistemático de software;
26

Reuso de artefatos no geral (templates, códigos e frameworks);

Utilizado através do browser, o que permite o uso através da
intranet da organização e um plugin integrado a IDE (Integrated
Development Environment, ou ambiente de desenvolvimento
integrado) eclipse;

Possui uma definição de responsabilidades através de papéis;

Possui as funcionalidades básicas de um repositório, como
pesquisa e manutenção dos itens inseridos.
Sobre
suas
características
é
possível
destacar
a
da
divisão
de
responsabilidades em papéis descritos a seguir (C.E.S.A.R, 2008):

Produtor: Responsável por criar e armazenar os artefatos de
software reutilizáveis;

Consumidor: Irá utilizar os artefatos de softwares publicados no
repositório;

Certificador: Esse papel é responsável pela validação da qualidade
dos artefatos publicados no repositório. No caso dos artefatos
serem documentos, esses podem ser avaliados perante o ser
formato ou padrão. E no caso dos artefatos serem executáveis, o
certificador poderá testá-los perante alguns requisitos básicos ou
premissas assumidas para aquele artefato.
Uma de suas funcionalidades é permitir que os usuários avaliem o artefato
através de uma métrica pré-definida, e essas avaliações são utilizadas como forma
de classificação desses artefatos.
Existem diversas soluções que promovem o reuso de artefatos nas
organizações, entretanto, nos capítulos seguintes, serão abordados os repositórios
para artefatos reutilizáveis demonstrando que os mesmos podem ser ineficientes na
promoção desses artefatos e na evolução profissional dos desenvolvedores.
27
3 REDES SOCIAIS
As redes sócias podem ser importantes para a distribuição da informação dos
artefatos, não somente para divulgação dos mesmos, mas como também para um
meio que favoreça a evolução e criação de novas ideias através da interação dos
desenvolvedores.
Existem diversos significados para o conceito de redes, dentre eles, as que se
aplicam a este trabalho são as seguintes: estrutura de nodos e elos; uma
comunidade não geográfica; um sistema de apoio ou sistema físico que se pareça
com uma árvore ou uma rede. A rede social, derivando deste conceito, passa a
representar um conjunto de participantes autônomos, unindo ideias e recursos em
torno de valores e interesses compartilhados (MARTELETO, 2001).
O termo rede social surgiu em conjunto com anúncio do termo Web 2.0,
descrito pela empresa O’Reilly em 2004. O termo Web 2.0 marcou uma quebra de
paradigma, onde antes, os serviços que eram oferecidos na internet tinham como
características a falta de interatividade entre os usuários e o serviço oferecido,
fazendo uma analogia ao conceito de produtor e consumidor, em que os internautas
até então, eram apenas telespectadores do conteúdo encontrado na internet
(COUTINHO, 2007).
Os padrões dos novos produtos e serviços caracterizaram uma quebra do
paradigma predominante até então, seguindo para uma nova forma de
comunicação, cujos usuários poderiam agora colaborar ou interagir com os produtos
e serviços oferecidos, além da possibilidade de poderem se expressar e interagir
(COUTINHO, 2007; PEREIRA, 2010).
Em parte, o sucesso da Web 2.0 deu-se pelo fato de que, na maioria casos,
não é mais necessário conhecimentos em programação ou a utilização de
ferramentas complexas, ou seja, seus serviços e produtos tornaram-se mais
acessíveis (COUTINHO, 2007).
A seguir, a frase de Tim O’Reilly, o primeiro a identificar e definir o termo Web
2.0 (COUTINHO, 2007, p. 2; PEREIRA, 2010):
28
A Web 2.0 é a mudança para uma Internet como plataforma, e um
entendimento das regras para obter sucesso nesta nova plataforma. Entre
outras, a regra mais importante é desenvolver aplicativos que aproveitem os
efeitos de rede para se tornarem melhores quanto mais são usados pelas
pessoas, aproveitando a inteligência coletiva.
Conclui-se então que as ferramentas criadas no contexto da Web 2.0
procuram promover a interação entre os usuários com os produtos e serviços
disponibilizados na plataforma Web, sendo esse um dos objetivos básicos do
trabalho proposto nessa monografia.
3.1
As redes sociais e as organizações
A formação de redes nas organizações ocorre de forma variada e às vezes
comum, desde a conversa na hora do café até listas de discussões. Essas
interações, quando voltadas para o âmbito organizacional, geralmente apresentam
dois objetivos básicos: confirmar a existência e conteúdo do conhecimento ou criar
novos
conhecimentos.
Esse
intercambio
de
ideias,
opiniões
e
crenças
proporcionados por essas discussões alavanca o primeiro e o mais importante passo
para a criação do conhecimento: o compartilhamento do conhecimento tácito dentro
da comunidade da rede, ou no caso, a organização (INÊS, ROSECLER e
GUERREIRO, 2005). Capra (apud INÊS, ROSECLER, & GUERREIRO, 2005)
elucida a afirmação anterior através da frase abaixo:
[...] na era da informação – na qual vivemos – as funções e processos
sociais organizam-se cada vez mais em torno de redes. Quer se trate das
grandes empresas, do mercado financeiro, dos meios de comunicação ou
das novas ONGs globais, constatamos que a organização em rede tornouse um fenômeno social importante e uma fonte crítica de poder.
A característica de dinamismo das redes sociais fez com que esta seja
aplicada no âmbito organizacional como espaços para compartilhamento da
informação e do conhecimento. Esses espaços podem ser tanto virtuais quanto
presencias, nos quais as pessoas com objetivos em comum trocam experiências,
criando bases e gerando informações importantes para o setor nas quais atuam
(INÊS, ROSECLER e GUERREIRO, 2005).
Quanto maior a interação entre os indivíduos, no contexto da troca de
conhecimento, maior será a bagagem de conhecimentos ou estoque de informação.
Entretanto, somente nas últimas décadas as redes sociais passaram a ser vistas
29
como um instrumento organizacional, mesmo constada como um importante recurso
profissional (INÊS, ROSECLER e GUERREIRO, 2005).
A importância da informação no desempenho das empresas é destacada
por diversos autores, entre os quais Lesca e Almeida (1994, p.67) quando
afirmam que “a informação é um vetor estratégico importantíssimo, pois
pode multiplicar a sinergia dos esforços ou anular o resultado do conjunto
dos esforços”. Drucker (1992 apud INÊS, ROSECLER, & GUERREIRO,
2005) acrescenta ainda que ela é fator de produção importante para a
obtenção de vantagem competitiva, uma vez que os fatores tradicionais –
terras, mão-de-obra e recursos financeiros – por si sós já não garantem a
competitividade.
Verifica-se que o principal objetivo de uma rede é a troca de informações e
evolução das mesmas, isto a torna uma excelente ferramenta a ser agregada com o
intuito de maximizar a interação entre seus participantes, assim como a evolução
das informações trocadas. Todavia, o propósito da rede poderá ser desvirtuado se
não houver uma forma de controle ou interesse de seus participantes (INÊS,
ROSECLER e GUERREIRO, 2005).
3.2
Os tipos de informações e sua utilização na rede social
As informações estão classificadas em três grupos, conforme explica Miranda
(apud INÊS, ROSECLER, & GUERREIRO, 2005):

Conhecimentos Explícitos;

Conhecimentos Tácitos;

Conhecimentos Estratégicos.
O conhecimento explícito é aquele conhecimento ou saber que já está
disponível em alguma mídia, como livros, documentos, artigos etc. Diferente do
conhecimento explícito, o conhecimento tático é o acúmulo de experiências com
base em conhecimentos explícitos (INÊS, ROSECLER e GUERREIRO, 2005).
O conhecimento estratégico é a combinação dos conhecimentos tácitos e
explícitos, a fim de elencar informações para as tomadas de decisão, sejam para
minimizar riscos ou aumentar a eficiência dos resultados das ações executadas
(INÊS, ROSECLER e GUERREIRO, 2005).
30
Numa visão organizacional, Choo ( apud INÊS, ROSECLER, & GUERREIRO,
2005) propõe que a informação é requisitada em uma rede social para ser utilizada
para três finalidades distintas:

Para construção de significados (sense making) através da coleta
de informações do ambiente;

Construção de novos conhecimentos (knowledge creating) por meio
da conversão dos conhecimentos de tácito para explícito e da
partilha desses conhecimentos a fim de inovar;

A terceira finalidade diz respeito à busca de informações para
tomada de decisão, que os indivíduos da rede usam das
informações contidas nela para tomada de decisão.
3.3
A importância das redes sociais sobre as informações
Dixon (apud INÊS, ROSECLER, & GUERREIRO, 2005) elucida que não é
eficiente criar uma grande base de dados contendo enormes volumes de
informações, quando o desafio real é responder como esses recursos serão
utilizados.
Se o recurso citado por Dixon for pensado como um repositório simples
contendo informações sobre os artefatos e os artefatos em si, o mesmo não será
devidamente aproveitado, pois esse modelo não suporta a interação entre seus
atores (desenvolvedores participantes), de forma que esses possam compartilhar
informações
e
experiências,
visando
ao
aprendizado
organizacional,
consequentemente contribuindo para o crescimento profissional individual e a
criação de novos conhecimentos (INÊS, ROSECLER e GUERREIRO, 2005).
Lemos (apud INÊS, ROSECLER, & GUERREIRO, 2005) ressalta a
importância do uso das redes sócias no contexto atual das organizações, afirmando
que sua utilização é uma das mais adequadas para intensificar o aprendizado, a
geração de conhecimentos e inovações.
31
3.4
Tipos de redes sociais
As ferramentas sociais citadas a seguir podem vir a auxiliar na troca de
informações de forma colaborativa entre seus usuários, visando também auxiliar na
evolução de cada usuário, transformando conhecimentos tácitos em explícitos e
vice-versa. O acúmulo de experiências e conhecimentos é uma base para o
conhecimento estratégico, ou seja, informações que auxiliem na tomada de decisão.
3.4.1 Fóruns de discussões
Fóruns assumem um papel de infra-estrutura base para a colaboração entre
os usuários sobre assuntos relevantes, possibilitando que qualquer usuário em
específico possa intervir nos assuntos que são objetos de estudo e responder
quaisquer questões propostas, tornando dessa forma, mais eficiente a resolução de
problemas comuns a um grupo de usuários (MIRANDA, MORAIS, et al., 2001).
A forma como acontece à comunicação entre os usuários de um fórum de
discussão permite aos participantes refletir nas contribuições anteriores e construir
com base nelas uma resposta bem elaborada antes de publicá-la. Nesse aspecto,
Karayan e Crowe( apud MIRANDA, MORAIS, DIAS, & ALMEIDA, 2001) afirmam que
a qualidade das respostas num fórum geralmente aumenta a cada resposta
publicada, pois os usuarios têm tempo para pensar, processar e relacionar suas
ideias com as publicações anteriores sobre o assunto em questão.
O fato das publicações anteriores serem registradas para uma futura
visualização ajuda a solucionar dúvidas repetidas de usuários diferentes e a
relembrar discussões anteriores ou respostas anteriores (MIRANDA, MORAIS, et al.,
2001).
O fórum, quando utilizado como ferramenta didática, promove além do reuso
uma forma eficaz para resolução de problemas, embora não seja considera uma
ferramenta que nasceu da Web 2.0. Como exemplo de fóruns de discussões
utlizados no desenvolvimento de software com sucesso tem-se a lista a seguir:

GUJ (2002 ) - Grupo de Usuários Java;

CEJUG (2002) - Ceará Java User Group;

JavaRanch (1998).
32
Todas as comunidades já citadas são exemplos de fóruns de discussão que
fazem sucesso e se tornaram uma inestimável fonte de pesquisa para diversos
desenvolvedores que além de aprimorar seus conhecimentos através de
experiências alheias que foram transmitidas para o grupo, também contribuem
formando assim uma rede social para troca de informações sobre o desenvolvimento
de software.
3.4.2 Blogs
Segundo Gomes (apud COUTINHO, 2007), o blog, ou Weblog, é uma das
ferramentas mais conhecidas e utilizadas da Web 2.0 no contexto educativo.
Segundo Gomes (Blog e Wiki: Os Futuros Professores e as Ferramentas da web 2.0,
p. 2), o termo blog é definido da seguinte forma:
É uma página na Web que se pressupõe ser atualizada com grande
frequência através da colocação de mensagens – que se designam “posts”
– constituídas por imagens e/ou textos normalmente de pequenas
dimensões (muitas vezes incluindo links para sites de interesse e/ou
comentários e pensamentos pessoais do autor) e apresentadas de forma
cronológica, sendo as mensagens mais recentes normalmente
apresentadas em primeiro lugar.
Gomes (apud COUTINHO, 2007) explica que existem duas possíveis
utilizações de blogs com intuitivo educativo:

Como recurso pedagógico;

Como estratégia educativa.
A utilização de blogs como recurso pedagógico é caracterizado, conforme
Gomes (apud COUTINHO, 2007), em dois modos, quando utilizado para
disponibilização de informações especializadas, no caso de blogs que um professor
é o autor. Dessa forma, é possível fazer uma analogia àqueles desenvolvedores que
se tornam especialistas em determinados assuntos, frameworks, banco de dados,
técnicas para gerenciamento de projeto ou que simplesmente possuem um
conhecimento diferenciado. As informações especializadas disponibilizadas nos
blogs podem ainda ser utilizadas como fonte de pesquisa para os desenvolvedores
da organização, sendo esse o seu segundo modo de utilização como recurso
pedagógico (COUTINHO, 2007).
33
A outra forma de utilização de um blog descrita como “estratégia educativa”,
cujos usuários utilizam-se do blog como integração, intercambio, debate e
colaboração, ambiente esse que é conveniente a inovação ou criação de novos
conhecimentos (COUTINHO, 2007).
Diferente de um fórum, um blog caracteriza-se por ser mantido, geralmente,
por apenas uma pessoa, porém, há blogs que são mantidos por um conjunto de
pessoas em que os responsáveis podem publicar pesquisas, trabalhos ou
experiências pessoais sobre determinados assuntos. Temos a seguir alguns
exemplos de blogs voltados para o desenvolvimento de software:

ZonaJ (2007);

Desenvolvimento para Web (2006);

Improve it – Desenvolvimento Ágil (2001).
O blog tem como foco os seus criadores, promovendo suas iniciativas
pessoais, demonstrando ser uma ótima ferramenta para implantação com intuito de
levantar novos conhecimentos e experiências que não se sobressaem nos fóruns em
que o foco são as dúvidas ou assuntos específicos levantados pelos usuários.
3.5
Ferramentas para criação de redes sociais
Existem algumas ferramentas no mercado que proporcionam a criação de
uma rede social de forma facilitada, em sua maioria esses produtos são
caracterizados como CMS (Sistema Gerenciador de Conteúdo, ou do inglês Content
Manager System), ou similares. Essas ferramentas têm como objetivo a alta
usabilidade proporcionada através de modelos pré-configurados de arquitetura, no
sentido de visão arquitetural, como estipulação de um SGBD (Sistema gerenciador
de banco de dados) padrão, ou dependência de condições especiais para execução
como ambientes com suporte a determinadas tecnologias ou mesmo um modelo
padrão de dados, onde são definidas quais informações são persistidas.
Algumas destas ferramentas são um exemplo de reuso sistemático, pois a
partir da reutilização de modelos (o conceito de modelos envolve quaisquer artefatos
que possam ser reutilizados) e configurações numa arquitetura pré-definida, é
34
possível se criar um sistema dentro do contexto ao qual sua arquitetura permita, no
caso, blogs, fóruns ou outros tipos de redes.
Existem inúmeras ferramentas no mercado que proporcionam a usuários
inexperientes um ambiente simples e eficiente para criação redes sociais. Dentre
essas ferramentas podemos citar algumas que se destacaram em números de
usuários como:

WordPress (2003);

Blogger (1999);

JForum (2005).
Dentre as ferramentas citadas, o WordPress é talvez a mais utilizada, seu
número de usuários é cerca de dez milhões. O WordPress começou em 2003, antes
da criação da Web 2.0, o que é perfeitamente normal por que mostra que o a Web
2.0 é apenas o ponto onde se percebeu a mudança de paradigma, e não
exatamente o período em que o mesmo ocorreu (WordPress, 2003).
Atualmente o WordPress passou de uma ferramenta de “blogging” para um
CMS completo, em que podem ser agregados mini-aplicativos chamados de widgets
ou plugins, que são mini-aplicações que podem ser agregadas ao blog
dinamicamente, contando que esse seja devidamente configurado, o que na maioria
das vezes não exigem muito dos usuários (WordPress, 2003).
O Blogger é uma ferramenta da Google, comprada posteriormente ao seu
lançamento em 1999, ferramenta que originou o termo blog, fazendo sucesso desde
então, porém devido à cobrança pelo serviço, não se tornou tão utilizada até que
depois da compra pela Google em 2003, seus serviços foram liberados sem custos
aos usuários. O Blogger fez uma importante inovação com a possibilidade dos
usuários lançarem os “posts” sem a necessidade de qualquer ferramenta adicional,
sendo todo o processo através do site principal, ou seja, de forma online pelo próprio
browser (Blogger, 1999).
Dentre as ferramentas para fóruns, pode-se citar uma que é conhecida e
utilizada mundialmente, e há muito tempo, o JForum, um software voltado para
criação de fóruns de discussões em geral, com conteúdo altamente adaptável e
suporte a diversas línguas com base na plataforma Java. Além de ser a base para
35
alguns dos exemplos de fóruns citados anteriormente, o JForum representa um outro
software que se utiliza de plugins e pode ser classificado em termos de reuso como
reuso sistemático (STEIL, 2005).
No próximo capítulo será apresentada a proposta de um ambiente onde os
conceitos de redes sociais e repositórios para artefatos são mesclados a fim de
formar um ambiente em que as transformações da informação possam ocorrer mais
facilmente através da interação entre os desenvolvedores e os artefatos reutilizáveis
de software para que sejam mais eficientemente promovidos.
36
4 REUSO UTILIZANDO REPOSITÓRIOS PARA ARTEFATOS COM
REDES SOCIAIS.
Este capítulo dedica-se ao planejamento de um repositório para artefatos
utilizando redes sociais com base nos conceitos que foram explicados nos capítulos
2 e 3. Será demonstrado o planejamento desse ambiente a partir de um grupo de
requisitos básicos, que serão desenvolvidos utilizando ferramentas de diagramação
e prototipação para expressar as características desse sistema.
Pressman (Engenharia de software, 2006, p. 706), na sua visão de futuro faz a
seguinte afirmação:
Quando duas importantes tecnologias são combinadas, o impacto do
resultado da combinação é frequentemente maior que a soma do impacto
de cada uma separadamente...Tecnologias frequentemente evoluem ao
longo de caminhos separados, mas um impacto significativo em negócio ou
na sociedade ocorre somente quando alguém as combina para resolver um
problema...Neste contexto, redes implicam em conexões entre pessoas ou
pessoas entre informação. À medida que a rede cresce, a probabilidade de
sinergia entre dois nós da rede (por exemplo, pessoas e fontes de
informação) também cresce. Uma conexão acidental (descoberta por acaso)
pode levar à inspiração e a uma nova tecnologia ou aplicação.
É proposto então um ambiente onde seja integrado o reuso, qualidade,
evolução dos artefatos de software reutilizáveis e a não menos importante interação
entre os próprios desenvolvedores,
a fim de aumentar a eficiência do
desenvolvimento de software em questões de qualidade, reusabilidade, evolução
dos
artefatos
e
de
crescimento
profissional
dos
desenvolvedores,
consequentemente diminuindo os custos e riscos.
Na criação de uma rede social é importante ter em mente que seu propósito
poderá ser desvirtuado se não houver uma forma de controle ou interesse de seus
participantes, podendo até necessitar de auxílio de uma metodologia ou de um forte
hábito que elucide sua utilização (MARTELETO, 2001). A fim de aumentar o
envolvimento dos desenvolvedores na rede, faz-se necessário um agrupamento das
informações relativas ao processo de desenvolvimento num ponto central que
proporcione alguma forma de comunicação, como fóruns para discussões ou blogs.
37
4.1
Pesquisa de mercado
Para melhor avaliar a importância desse trabalho, foi realizada uma pesquisa
que teve como público alvo pessoas relacionadas com as organizações que
trabalham com o desenvolvimento de software. No total foram avaliadas 13 pessoas,
das quais todas trabalhavam no desenvolvimento de software, sendo 2 em cargos
de nível gerencial, como gestores de projeto.
Em termos de meio para troca de informações, pode-se observar perante a
pesquisa realizada através do questionário no Anexo D -, que 100% das pessoas
informaram que suas organizações procuram promover a troca de informações de
seus desenvolvedores através de blogs ou fóruns internos, o que mostra a
importância que o mercado está dando às ferramentas, promovendo a interação
entre os desenvolvedores e os artefatos.
Em discordância quanto aos dados citados anteriormente, verifica-se que
58,3% dos entrevistados afirmaram que suas organizações não procuram alcançar o
reuso sistemático, desse grupo 85,7% afirmaram que sua organização possui
apenas a ferramenta de controle de versão, enquanto os 15% restante adicionou a
resposta que sua organização possui uma ferramenta para gerenciar testes
automatizados.
Como verificado anteriormente, existem ótimas ferramentas que podem ser
utilizadas para criação de redes sociais que não possuem custos e não exigem
conhecimentos avançados em informática de quem às utiliza, enquanto que a
construção de um artefato de software reutilizável consome bem mais recursos
organizacionais, como pessoas, tempo e conhecimentos específicos, podendo ser
esse o motivo pelo qual as empresas estão investindo mais em blogs do que
ferramentas para alavancar o reuso e a qualidade dos softwares. Apoiando essa
teoria, 58,3% das pessoas afirmaram que o motivo pelo qual sua organização não
promove o reuso sistemático de software é a falta de ferramentas e de um processo
de desenvolvimento que auxilie nessa tarefa.
Ainda de acordo com a pesquisa, 58,3% das pessoas afirmaram que a
organização onde trabalham não promove a evolução dos artefatos criados, e 91,6%
das pessoas entrevistadas afirmaram que sua organização não possui um
repositório para artefatos de software reutilizáveis.
38
Esses números indicam a carência das organizações quanto a um ambiente
que promova os objetivos desse trabalho.
4.2
Requisitos do sistema proposto
A fim de melhor direcionar e controlar as expectativas desse trabalho, faz-se
necessário definir os requisitos do sistema proposto no início desse capítulo, tendo
como base as informações apresentadas nos capítulos 2 e 3. Os requisitos do
sistema a seguir foram definidos a partir da técnica conhecida como brainstorming,
em que as possíveis funcionalidades do sistema são criadas a partir do seu próprio
contexto. (VARGAS, 2009).

Promover a interação entre os desenvolvedores, garantindo as
transformações dos conhecimentos em seus três níveis;

Promover para os desenvolvedores os artefatos de softwares que a
organização possui;

Promover a evolução dos artefatos e desenvolvedores através da
maior interação entre eles;

Promover o reuso sistemático e uma melhor qualidade dos
softwares da organização;

Melhorar a forma de classificação dos artefatos através da utilização
de informações dos desenvolvedores e projetos que se relacionam
com ele.
A partir dos requisitos acima, foram elaborados alguns protótipos, que estão
anexados ao final da monografia, das possíveis interfaces do sistema utilizando a
ferramenta de prototipação conhecida como Pencil. Pode-se verificar, através da tela
apresentada na figura, que foram mantidos os conceitos de repositórios e redes
sociais através da colaboração com fóruns e blogs.
39
Figura 2 - Tela inicial do sistema proposto.
A forma de funcionamento pensada foi a que cada aba representa um foco
diferente da rede social, como exemplo, no caso da aba projetos, seria mostrado
apenas às informações relacionadas com os projetos da organização. Em vista
disso, faz-se necessário a definição de um modelo de entidades para aplicação que
elucide as inter-relações e os fluxos do sistema, como demonstrado no tópico
seguinte.
4.3
Uma visão arquitetural do sistema proposto
Pode-se perceber que o diagrama de classes proposto por Ezran (apud
SANCHES, 2005), descrito na Figura 1, onde o mesmo demonstra uma visão
arquitetural do contexto do repositório, é insuficiente para agregar uma rede social,
pois não há suporte na troca de informações entre os desenvolvedores ou mesmo
no objeto que representa o próprio desenvolvedor.
Em vista da mudança de escopo do ambiente proposto por Ezran (apud
SANCHES, 2005), o ambiente deve ser modificado de forma a suportar os novos
40
requisitos levantados no tópico 4.2. Foi-se utilizada a linguagem UML para a
modelagem desse ambiente de integração, o qual será chamado de CrossDev.
Como cada desenvolvedor terá seu perfil adicionado ao sistema, bem como
suas contribuições em forma de posts e artefatos, faz-se necessário um sistema
controle de acesso. Abaixo um diagrama de casos de uso que representa o novo
ambiento em alto nível:
Figura 3 – Diagrama de casos de uso do ambiente proposto.
Pode-se perceber que a mudança de escopo do sistema acarreta na mudança
do diagrama de classes onde agora são acrescidas as informações pertinentes aos
desenvolvedores e as formas de interações escolhidas para o ambiente. A fim de
facilitar o entendimento dos relacionamentos, foi-se incorporado no diagrama de
classes as funcionalidades relativas às formas de comunicação, porém elas não
represetam entidades nativas do modelo de dados do sistema ou, em outras
palavras, as classes persistentes do sistema.
41
Figura 4 - Diagrama de classes do CrossDev.
Note que foi incrementado ao diagrama de Ezran (apud SANCHES, 2005),
citado no tópico 2.3, informações pertinentes aos desenvolvedores e as formas de
redes sociais adotadas. A seguir serão descritas as novas relações adicionadas ao
diagrama de Ezran:

Projeto;

Desenvolvedores;

Histórico;

Artefato-artefato;

Testes;

Fórum;

Blog;

Lista de discussão.
A entidade que representa o projeto é importante pois agrupa tanto um
conjunto de artefatos utilizados bem como um conjunto de desenvolvedores
elucidando o sentimento de equipe, podendo até mesmo ser relacionada com um
blog ou fórum. No caso dos blogs devem ser postados no blog de cada projeto
alguns de seus documentos de acompanhamento e suas lições aprendidas, e no
42
caso dos fóruns deve existir uma lista de discussão particular do projeto onde seriam
discutidos quaisquer tópicos relacionados ao projeto, porém essas são ideias
complementares que podem ser adaptadas sem necessidade de modificar o modelo
acima.
Os desenvolvedores são as entidades básicas do sistema, contendo seus
perfis e informações relacionadas a sua formação ou especialização. Segundo o
diagrama de classes (figura 4), os desenvolvedores possuem as seguintes relações:

Podem possui um único blog pessoal;

Podem estar participando de várias discussões nos fóruns;

Podem participar da várias discussões sobre artefatos;

Podem ter participado da criação de vários artefatos.
Um fórum é uma ideia bastante popular no contexto organizacional, pois
podem
ser
publicados
problemas
individuais
ou
comuns
ao
grupo
de
desenvolvedores da organização, bem como podem ser encontrada soluções para
problemas anteriores em seu histórico, entretanto a classe fórum, definida no
diagrama de classes acima, especifica a funcionalidade fórum e não a entidade
persistente em si, assim como a classe blog descrita abaixo.
O objeto Blog é individual para cada desenvolvedor, o que traz uma
valorização a individualidade e originalidade de cada um. Neste espaço o
desenvolvedor pode publicar e promover suas ideias em particular, assim como seus
trabalhos e pesquisas.
O objeto Histórico representa o histórico do artefato, listas de discussões
sobre as versões anteriores, testes anteriores, etc. Note que um artefato pode
possuir inúmeras versões anteriores, e essas estão vinculadas a um único artefato
que representa a versão atual. Assim como os fóruns e blogs, esse objeto histórico
representa apenas sua ideia básica e não faz menção a forma como será
implementado.
O objeto Testes representa um conjunto de testes para um artefato, esses
objetos são importantes para promover a qualidade do artefato através do total de
cobertura de seus códigos, obviamente, quanto mais coberto por testes o artefato,
mais garantido será seu comportamento esperado.
43
A lista de discussão por artefato parte do mesmo principio do fórum por
projeto, onde quaisquer questões sobre aquele artefato poderão ser expostas para
que os desenvolvedores da organização, inclusive facilitando o levantamento de
problemas.
4.4
Novos critérios para classificação dos artefatos.
Como já é sabido, uma pesquisa em um repositório com diversos de artefatos
pode retornar vários resultados: artefatos construídos por diversos desenvolvedores,
e artefatos com as mesmas funcionalidades. Para ajudar o desenvolvedor a escolher
um dentre esses resultados pode-se utilizar algumas das formas de classificação
descritas abaixo:

Nível de formação da equipe de criadores do artefato;

Quantidade de projetos que estão utilizando aquele artefato;

Total de cobertura de testes nos artefatos;

Pode-se utilizar também os posts e discussões que referenciaram
aquele artefato;

Pode-se
utilizar
de
recomendações,
feitas
pelos
próprios
desenvolvedores para um artefato.
Um dos critérios para classificação dos artefatos que poderia ser utilizados é
classificação com base nas informações dos desenvolvedores, informações sobre
suas competências ou especializações dos desenvolvedores que participaram da
construção do artefato, como conhecimentos em banco de dados, Webdesign ou
diferentes certificações (PRESSMAN, 2006).
Outra forma de classificação seria utilizando o histórico, número de falhas ou
quaisquer estatísticas que indiquem sua qualidade como o percentual de código
coberto por testes. Essas informações incrementariam a pesquisa por artefatos de
forma a prover ao desenvolvedor, não somente as informações do artefato, mas
também opiniões de outros desenvolvedores e a quantidade de projetos que utilizam
o artefato, ou seja, informações de conhecimentos empíricos.
44
Verifica-se que essa forma de classificação ajudaria a desenvolvedores a
confiar nos artefatos disponibilizado, desde que esses estejam com níveis aceitáveis
de qualidade, e esses níveis expostos nesse ambiente.
Através de wireframes, técnica que é utilizada para criação de protótipos de
interfaces gráficas, na figura 5 é demonstrado uma tela inicial do sistema proposto
que se utiliza desses critérios de classificação:
Figura 5 - Tela de visualização de artefatos.
4.5
As informações no repositório
É importante citar que a introdução de conceitos de redes sociais sobre os
repositórios implica que as informações poderão ser extraídas para fins diferentes do
propósito da rede social utilizando de técnicas como Business Intelligence (BI), onde
informações relativas a rede são extraídas e utilizadas para a tomada de decisão. Há
diversas informações que poderiam ser extraídas desse ambiente, como (AIRTON,
2009):
45

Quais artefatos são mais reutilizados provendo assim uma visão de
quais artefatos devem ser ter ênfase na sua qualidade e testes;

Quais artefatos estão trazendo mais problemas, e podem gerar
riscos aos projetos;

Através do conhecimento empírico dos desenvolvedores, obter
informações para decidir quais artefatos, ferramentas ou quaisquer
insumos usados no desenvolvimento devem ser adquiridos ou
desenvolvidos pela empresa.
Como é possível verificar nos anexos Anexo A -, Anexo B - e Anexo C - o
CrossDev possui as informações citadas acima as quais poderiam ser usadas para a
técnica de BI ou como informações de nível estratégico.
4.6
Integração com outros sistemas
A fim de incrementar suas funcionalidades e informações, é importante que o
repositório permitisse a integração com outros sistemas úteis como os sistemas para
integração contínua (ex: Hudson, CruiseControl, Continuum, Team City), controle de
dependências (MAVEN 2, MAVEN 1, Gradle, Ivy, Ant) e ou qualquer outro ambiente
para testes automatizados (SOARES, 2009).
Os ambientes de integração contínua provêem um meio de monitorar a
integração de sistemas, quando módulos novos são integrados com os antigos.
Pode-se configurar o ambiente de integração contínua para executar a compilação e
os testes vinculados aquele sistema, bem como gerar uma serie de métricas para
analise dos sistemas (SOARES, 2009).
As ferramentas para gerenciamento de dependências provêem uma forma de
controlar as dependências na fase de implementação em projetos que utilizam
inúmeros artefatos, como controle das versões dos artefatos utilizados e a forma
como são construídos.
A integração com esses sistemas agrega as vantagens para a fase de
implementação do projeto como verificações das qualidades do código e controle
das dependências do sistema, ou seja, as vantagens do uso das ferramentas em si.
46
5 CONCLUSÃO
Pode-se verificar que através do uso de redes sociais a informação pode ser
melhor aproveitada e difundida entre os seus pontos. No caso do desenvolvimento
de software, a pesquisa de mercado demonstrou que a maioria das organizações
que trabalham nesse ramo já aplica alguns conceitos de redes sociais, porem essas
organizações não se utilizam desses conceitos para promoção do reuso de seus
artefatos, consequentemente não se beneficiam de uma forma de diminuir os custos
e acelerar o desenvolvimento.
Ainda segundo a pesquisa de mercado, a maioria das organizações não
possuem um repositório ou ambiente dedicado ao armazenamento e manutenção de
artefatos reutilizáveis de software, que embora não seja eficientemente utilizado,
ainda provem alguns meios de maximizar o reuso e promover uma maior qualidade
dos softwares. Isso demonstra que provavelmente cerca de 40% das pessoas que
responderam que suas organizações promovem o reuso sistemático, tem uma ideia
errada de reuso, pois como visto, um dos pontos básicos para o reuso sistêmico é
que seus níveis menores sejam cumpridos, tarefa que sem o auxilio de uma
ferramenta como um repositório é bastante improvável de acontecer.
A ferramenta proposta nesse trabalho trás consigo os conceitos de redes
socais e repositório para artefatos de software, o que consequentemente promove o
reuso e todos os benefícios que derivam desse atributo. Como já é sabido, os custos
em se construir um software reusável são bem maiores do que softwares sem essa
possibilidade, entretanto, empresas são planejadas, em sua maioria, para ter uma
longevidade consideravelmente maior que seus softwares, o que vem a justificar os
custos dessa abordagem.
47
6 TRABALHOS FUTUROS
Como esta monografia compreende o planejamento do sistema CrossDev, em
trabalhos futuros pretendo implementar e aplicar as técnicas levantadas neste
trabalho em empresas de desenvolvimento de software.
48
7 REFERÊNCIAS
AIRTON, E. C. Inteligência competitiva e suas conexões epistemológicas com
gestão da informação e do conhecimento. Ci. Inf., Maio/Agosto 2009. 19-34.
BLOGGER. Blogger, 01 ago. 1999. Disponivel em: <http://www.blogger.com>.
Acesso em: 12 nov. 2010.
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. The Unified Modeling Language
User Guide. [S.l.]: Addison Wesley, 1998.
C.E.S.A.R.
CORE
-
Component
Repository,
2008.
Disponivel
em:
<http://www.rise.com.br>. Acesso em: 10 Outubro 2010.
CEJUG – The Ceará Java User Group. CEJUG, 2002. Disponivel em:
<www.cejug.org>. Acesso em: 10 out. 2010.
COUTINHO, C. P. Blog e Wiki: Os Futuros Professores e as Ferramentas da web
2.0,
14
nov.
2007.
Disponivel
em:
<http://repositorium.sdum.uminho.pt/bitstream/1822/7358/1/Com%2520SIIE.pdf>.
Acesso em: 02 nov. 2010.
EZRAN, M.; MORISIO, M.; COLIN, J. T. Practical Software Reuse. Berlin: Springer
Verlag,
2002.
Disponivel
em:
<http://books.google.com.br/books?id=kIlpuK1GkLwC&printsec=frontcover&dq=ezra
n+book&source=bl&ots=X8bXWchxRX&sig=XObYxm3vBiKlq76hvg-2trMjy4o&hl=ptBR&ei=QEngTPndFoL48Abux5GSDw&sa=X&oi=book_result&ct=result&resnum=6&
ved=0CEYQ6AEwBQ#v=onepage&q&f=false>. Acesso em: 12 ago. 2010.
GRUPO de Usuários Java. Grupo de Usuários Java, 2002. Disponivel em:
<www.guj.com.br>. Acesso em: 10 out. 2010.
HTTP://GEEK.NET/.
SourceForge.
SourceForge,
1999.
Disponivel
em:
<http://sourceforge.net/about>. Acesso em: 12 out. 2010.
INÊS, T. M.; ROSECLER, A. A.; GUERREIRO, I. D. C. Das redes sociais à inovação.
Instituto Brasileiro de Informação em Ciência e Tecnologia - IBICT, 05 Agosto
2005.
49
JAVARANCH. JavaRanch, 1998. Disponivel em: <www.javaranch.com>. Acesso
em: 10 out. 2010.
MAGELA, R. Engenharia de Software Aplicada - Princípios. Rio de Janeiro: Alta
Books, 2006.
MARTELETO, R. M. Análise de redes sociais - aplicação nos estudos de
transferencia da informação. Ci. Inf., Janeiro 2001.
MIRANDA, L. et al. Ambientes para aprendizagem na web: Uma experiência com
fóruns de discussão. Conferencia Internacional de Tecnologias de Informação e
Comunicação na Educação. Centro de competencia Nónio da Universidade do
Minho: Braga. 2001. p. 585 - 593.
PÁDUA, W. P. Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de
Janeiro: LTC Editora, 2005.
PEREIRA, D. R. DISCURSOS SOBRE A WEB 2.0 E A EDUCAÇÂO: UMA ANÁLISE
SEMIÓTICA, Julho 2010. Disponivel em: <http://www.scielo.br/pdf/tla/v49n1/19.pdf>.
Acesso em: 13 nov. 2010.
PLANETSOURCECODE. PlanetSourceCode. PlanetSourceCode, 1997. Disponivel
em: <http://www.planetsourcecode.com/>. Acesso em: 12 out. 2010.
PRESSMAN, R. S. Engenharia de software. São Paulo: Mc Graw Hill, 2006.
SANCHES, M. G. Um Estudo Sobre os Riscos Inerentes à Implantação do
Reuso de Componentes no Processo de Desenvolvimento de Software.
Campinas: Universidade Estadual de Campinas, 2005.
SOARES, M. D. S. Metodologias Ágeis Extreme Programming e Scrum para o
Desenvolvimento de Software. Revista Eletrônica de Sistemas de Informação,
Conselheiro Lafaiete, v. 3, n. 1, 2009. ISSN 1677-3071.
SOMMERVILE, I. Engenharia de Software. São Paulo: Pearson Addison Wesley,
2003.
SOMMERVILE, I. Engenharia de Software. São Paulo: Pearson Addison Wesley,
2007.
STEIL,
R.
G.
JForum.
JForum.net,
12
mar.
<http://jforum.net/team.jsp>. Acesso em: 2010 out. 10.
2005.
Disponivel
em:
50
VARGAS, R. Gerenciamento de projetos: Estabelecendo Diferencias Competitivos.
7º Edição. ed. Rio de Janeiro: BRASPORT Livros e Multimídia Ltda., 2009.
WORDPRESS. WordPress, 27 Maio 2003. Disponivel em: <http://wordpress.org>.
Acesso em: 12 nov. 2010.
WWW.IMPROVEIT.COM.BR.
Improve
It,
2001.
Disponivel
em:
<www.improveit.com.br>. Acesso em: 12 out. 2010.
WWW.JARS.COM. JARS. www.jars.com, 1998. Disponivel em: <www.jars.com>.
Acesso em: 12 out. 2010.
ZEMEL, T., 2006. Disponivel em: <www.desenvolvimentoparaweb.com>. Acesso
em: 12 out. 2010.
ZONA J. Zona J, 2007. Disponivel em: <www.zonaj.org>. Acesso em: 12 out. 2010.
51
Anexo A - Wireframe da tela inicial do ambiente CrossDev
52
Anexo B - Wireframe artefatos em foco.
53
Anexo C - Wireframe da tela inicial da aba artefatos do ambiente CrossDev
54
Anexo D - Formulário de pesquisa científica parte I.
55
Anexo E - Formulário de pesquisa científica parte II.
56
Anexo F - Formulário de pesquisa científica parte III.