FACULDADE LOURENO FILHO SISTEMAS DE INFORMAO

NATHAN AZEVEDO GUIMARES

UMA ABORDAGEM DE REUSO UTILIZANDO REPOSITRIOS PARA ARTEFATOS DE SOFTWARE COM REDES SOCIAIS

FORTALEZA/CE 2010

FACULDADE LOURENO FILHO SISTEMAS DE INFORMAO

NATHAN AZEVEDO GUIMARES

UMA ABORDAGEM DE REUSO UTILIZANDO REPOSITRIOS PARA ARTEFATOS DE SOFTWARE COM REDES SOCIAIS

Monografia apresentada Faculdade Loureno Filho, como requisito parcial para a obteno do grau de Bacharel em Sistemas de informao. Orientador: Msc. Nauber Gois

FORTALEZA/CE 2010

NATHAN AZEVEDO GUIMARES

UMA ABORDAGEM DE REUSO UTILIZANDO REPOSITRIOS PARA ARTEFATOS DE SOFTWARE COM REDES SOCIAIS

Monografia apresentada Faculdade Loureno Filho como requisito parcial para obteno do grau de Bacharel em Sistemas de Informao.

Monografia aprovada em: ______ / ______ / ______ Nota obtida: ______________

BANCA EXAMINADORA

___________________________________ Prof. Msc. Francisco Nauber Gois(FLF)

_______________________________________ Prof. Msc. Andr Barros Pereira (FLF)

___________________________________ Prof. Msc. Joo Frederico Rolosn Viana (FLF)

DEDICATRIA

Dedico essa monografia a minha famlia.

AGRADECIMENTOS

Agradeo aos meus pais por me proporcionarem e apoiarem nessa conquista. Agradeo o suporte de minha famlia em todos os momentos difceis, inclusive nas revises gramaticais da minha monografia (Neusa e Sergio). Agradeo ao meu orientador Nauber Gois pela dedicao e o timo trabalho. Agradeo o apoio de meus amigos e colegas durante mais essa fase, especialmente a Jehny e Michelle. Agradeo aos meus professores pela pacincia e dedicao durante minha graduao. 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 repositrios para artefatos reutilizveis de software tem se mostrado uma tima abordagem para se promover o reuso sistemtico, consequentemente, diminuindo os custos do processo de desenvolvimento de software nas suas diferentes fases. Entretanto a abordagem de reuso utilizando repositrios no eficiente na promoo dos artefatos contidos, bem como na evoluo dos artefatos e profissional dos prprios desenvolvedores. Esse trabalho apresenta um estudo de uma abordagem de reuso com repositrios para artefatos de software reutilizveis combinada aos conceitos de redes socais para promoo evoluo dos mesmos, bem como a evoluo dos desenvolvedores. O estudo foi realizado a partir de pesquisas bibliogrficas e de mercado, resultando num projeto de um ambiente onde o reuso dos artefatos promovido atravs da interao entre os desenvolvedores, o que tambm promove as transformaes bsicas de conhecimentos tcitos em explcitos e vice-versa.

Palavras-chave: Repositrios, Redes sociais, Reuso.

LISTA DE FIGURAS
FIGURA 1 DIAGRAMA DE OBJETOS PARA IMPLEMENTAO DE UM REPOSITRIO 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 VISUALIZAO DE ARTEFATOS. ................................................................................... 44 TABELA 1 - BENEFCIOS DO REUSO. .......................................................................................................... 14

LISTA DE SIGLAS E ABREVIATURAS

UML CORBA CBSE COTS IDE Unified Modeling Language. Common Object Request Broker Architecture Component-Based Software Engineering Comercial off-the-shelf Integrated Development Environment

SUMRIO

INTRODUO ...................................................................................................................................6

1.1 1.2 1.4

MOTIVAO ......................................................................................................................................6 OBJETIVOS .......................................................................................................................................8 ESTRUTURA DA MONOGRAFIA ............................................................................................................8

DISTRIBUIO DE ARTEFATOS UTILIZANDO UM REPOSITRIO.............................................9

2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.2 2.2.1 2.2.2 2.2.3 2.3 2.3.1 2.3.2 2.4

REUSO ........................................................................................................................................... 11 REUSO OPORTUNSTICO ............................................................................................................... 12 REUSO DE OBJETOS E FUNES ................................................................................................... 13 REUSO DE COMPONENTES ........................................................................................................... 13 REUSO DE SISTEMAS DE APLICAES ........................................................................................... 14 TCNICAS PARA REUSO DE ARTEFATOS ........................................................................................... 15 PADRES DE PROJETO (DESIGN PATTERNS)................................................................................. 16 FRAMEWORKS DE APLICAO ...................................................................................................... 17 ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES .............................................................. 18 REPOSITRIOS PARA ARTEFATOS ................................................................................................... 20 CATLOGO .................................................................................................................................. 21 MODELAGEM DA ESTRUTURA DE UM REPOSITRIO PARA ARTEFATOS. ............................................. 22 EXEMPLOS DE REPOSITRIOS ......................................................................................................... 25

REDES SOCIAIS ............................................................................................................................ 27

3.1 3.2 3.3 3.4 3.4.1 3.4.2 3.5

AS REDES SOCIAIS E AS ORGANIZAES ......................................................................................... 28 OS TIPOS DE INFORMAES E SUA UTILIZAO NA REDE SOCIAL ...................................................... 29 A IMPORTNCIA DAS REDES SOCIAIS SOBRE AS INFORMAES ......................................................... 30 TIPOS DE REDES SOCIAIS ................................................................................................................ 31 FRUNS DE DISCUSSES ............................................................................................................. 31 BLOGS ........................................................................................................................................ 32 FERRAMENTAS PARA CRIAO DE REDES SOCIAIS ........................................................................... 33

REUSO UTILIZANDO REPOSITRIOS PARA ARTEFATOS COM REDES SOCIAIS. .............. 36

4.1 4.2

PESQUISA DE MERCADO.................................................................................................................. 37 REQUISITOS DO SISTEMA PROPOSTO ............................................................................................... 38

4.3 4.4 4.5 4.6

UMA VISO ARQUITETURAL DO SISTEMA PROPOSTO ......................................................................... 39 NOVOS CRITRIOS PARA CLASSIFICAO DOS ARTEFATOS. .............................................................. 43 AS INFORMAES NO REPOSITRIO ................................................................................................ 44 INTEGRAO 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 - FORMULRIO DE PESQUISA CIENTFICA PARTE I. ................................................... 54

ANEXO E - FORMULRIO DE PESQUISA CIENTFICA PARTE II. ................................................. 55

ANEXO F - FORMULRIO DE PESQUISA CIENTFICA PARTE III. ................................................. 56

1 INTRODUO
A crescente demanda de sistemas informatizados tem desencadeado uma busca por tcnicas e boas prticas que agilizem o desenvolvimento e melhorem a manutenibilidade do software a ser construdo ou modificado (SOMMERVILE, 2007, p. 275). O reuso de software j era uma prtica conhecida h muitos anos, mas somente na ltima dcada essa tornou-se de fato a ser usada no desenvolvimento de software rotineiro. Essa mudana veio da necessidade de entregas mais rpidas, prazos mais curtos, custos menores e manutenes mais rpidas. Em meio a essas mudanas, o software desenvolvido ou adquirido passou a ser visto como um ativo importante que deveria ser aproveitado ao mximo, sendo assim, pode-se concluir que uma das solues seria aplicar tcnicas 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 reutilizao no uma abordagem eficiente, pois podem existir artefatos que cumpram com a necessidade de um desenvolvedor da instituio e esse no conhea o mesmo, fazendo com que seja construdo um segundo artefato, trazendo um retrabalho quando este custo poderia ser evitado. Uma das ideias mais populares para a promoo do reuso so os repositrios para artefatos de software, em que estes artefatos reutilizveis so disponibilizados num ambiente de distribuio comum para um grupo de indivduos, seja na intranet ou internet. Nesse trabalho sero abordadas as caractersticas comuns desses repositrios e os conceitos envolvidos no reuso de artefatos. 1.1 Motivao A reutilizao de artefatos de software atravs de repositrios no 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 tcnicas e conceitos

que facilitam e indicam essa prtica, tais riscos apresentados abaixo, podem ser minimizados atravs da implementao de tcnicas e conceitos apresentadas no captulo 4. O processo de desenvolvimento que adote o reuso de artefatos pode ser acometido pelo insucesso devido sndrome do NIH, do ingls Not Invented Here, que acomete os desenvolvedores de forma a acreditar, que todo software que desenvolvido por terceiros no to eficiente e nem possui qualidade tanto quanto o desenvolvido pessoalmente (NORTON apud SANCHES, 2005). Uma das possveis solues para se resolver este problema a de tornar mais prximos os desenvolvedores que se utilizam dos componentes, dos seus criadores, atravs de uma rede social, demonstrando suas qualificaes, ou a quantidade de pessoas que aprovam ou que j utilizaram esses componentes. Existe tambm a possibilidade de que ao se adquirir um artefato de software de terceiros, os mesmos no sejam confiveis, sejam por questes legais, de qualidade ou de segurana, contendo algum cdigo malicioso em meio a seu cdigo fonte que possam vir a prejudicar a organizao ou os usurios da aplicao (TRACZ apud SANCHES, 2005). Durante o desenvolvimento, normal que o artefato contenha algumas falhas de baixa severidade, porm, 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 aproximao 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 repositrio podem ser refletidos com menos impacto nos projetos que j o utilizam, mantendo assim a confiana e vantagem do reuso, tendo como base que esse artefato foi construdo de acordo com os padres apresentados neste trabalho no capitulo 2. Verifica-se que h diversos problemas de mbito social na utilizao de repositrios para artefatos, mesmo numa organizao, onde os envolvidos no processo de disponibilizao e reuso so devidamente identificados. Uma das solues poderia ser a de repositrio para artefatos reutilizveis incorporado a redes

sociais com o intuito de aproximar os desenvolvedores como um todo, maximizando assim o reuso e qualidade dos artefatos nas organizaes, com base no aumento da confiana dos artefatos disponibilizados, bem como na promoo desses. 1.2 Objetivos O trabalho de monografia tem como objetivo realizar um estudo sobre o uso de repositrios de artefatos, utilizando redes sociais com o intuito de aumentar eficientemente o reuso, qualidade e promoo dos artefatos disponibilizados, bem como definir as caractersticas bsicas da integrao de ambos os conceitos. 1.3 Estrutura da monografia O captulo 2 explana sobre os conceitos bsicos sobre a reuso e a distribuio de artefatos utilizando um repositrio de software. Nos tpicos relativos distribuio de artefatos descrito um repositrio com ideias baseadas em conceitos de diferentes autores e so citados exemplos de repositrios. No capitulo 3 so abordadas as redes sociais, seus tipos, suas formas de utilizao e sua importncia num contexto organizacional. Nesse captulo tambm so apresentados alguns exemplos de ferramentas que poderiam ser usadas para criao de redes sociais. No captulo proposto uma abordagem de reuso utilizando repositrios para artefatos de software reutilizveis combinada aos conceitos de redes socais. Esse captulo agrupa detalhes que correspondem ao planejamento do ambiente citado anteriormente, inclusive uma pesquisa de mercado realizada em algumas organizaes para definir o nvel de reuso e as ferramentas utilizadas a fim de justificar a proposta.

2 DISTRIBUIO DE ARTEFATOS UTILIZANDO UM REPOSITRIO

Este captulo dedica-se explanao de conceitos referentes a um repositrio para artefatos de software, bem como os conceitos bsicos que embasem a ideia, como: componentes, artefatos e como reutiliz-los. Segundo Pdua (2005, p. 8), um artefato um produto de software, que pode ser cdigos executveis, cdigos fontes, modelos, relatrios e outros documentos. Ento, 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, cdigos executveis e documentos. Essa afirmao define o que chamamos de componentes reutilizveis e esses sero inseridos no repositrio juntamente com os outros artefatos reutilizveis. Portanto, temos um componente como um artefato, com base no conceito explicado anteriormente. Componentes ou mdulos so itens mais comuns para serem reutilizados durante o desenvolvimento, por serem artefatos que so geralmente melhores projetados e separados por funcionalidades ou finalidades, como explica Pdua (2005) a seguir:
Um mdulo uma unidade de programa discreta e identificvel em relao compilao, combinao com outras unidades e carga. Para UML, um mdulo uma unidade de armazenamento e manipulao de software. Mdulos so colees 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 mdulo podem tambm ser consideradas as interfaces do mdulo. Um mdulo pode conter outros mdulos, formando uma hierarquia (PDUA, 2005).

Segundo Ezran (apud SANCHES, 2005), podemos classificar componentes em dois tipos distintos: Componentes Verticais; Componentes Horizontais.

10

Componentes Verticais so aqueles componentes que esto vinculados a um domnio de aplicao, ou seja, englobam as regras de negcio embutidas nas aplicaes da empresa e com isso representam o know-how da organizao e sua vantagem competitiva frente concorrncia (SANCHES, 2005). Exemplos de componentes verticais: Modelos de objetos financeiros; Bibliotecas C++ para instrumentos mdicos; Design e cdigo para mdulo de gerenciamento de clientes; Algoritmos para clculo de geoprocessamento; Um framework para aplicaes de telemetria.

Como explica Sanches (2005), esses componentes so mais difceis de serem reutilizados por serem muitos especficos da aplicao, mas no os impede de serem publicados no repositrio com esse intuito. Em contra partida, Componentes Horizontais so mais genricos e fceis de serem identificados e reusados, alm de que geralmente so independentes do domnio da aplicao. A maior restrio desses componentes que a arquitetura da aplicao deve ser compatvel com o modelo arquitetural adotado pelo componente (SANCHES, 2005). Para amenizar o problema, pode-se citar algumas tcnicas que sero abordadas no tpico 2.3.2 Reuso de componentes. A seguir, alguns exemplos de componentes horizontais: Componentes de GUI (Graphical User Interface): tabelas, botes, campos de texto; Estrutura de dados e algoritmos bsicos (como ordenao por exemplo); Bibliotecas de acesso a banco de dados; Bibliotecas de comunicao de redes; Servio de relatrios, trace e logging.

Nota-se que por executarem ou proverem servios mais ordinrios, esses componentes seriam timos candidatos a serem inseridos no repositrio. Uma vez

11

inserido no repositrio, um componente ou artefato precisa ser classificado para que seja possvel busc-lo e evitar possveis ambiguidades durante essa busca. Segundo Sanches (2005, p. 13), durante a busca e anlise de um componente no repositrio, esse pode ser considerado vertical, embora o mesmo possa ser reusado nos subdomnios da aplicao. Isso ocorre porque os domnios podem ser definidos de forma muito especifica, embora esses pertenam a domnios mais genricos. Como por exemplo, um componente para gerenciamento de desempenho de redes que pertenam a domnios mais genricos, como gerenciamento de redes. Para evitar essas ambiguidades, a classificao dos componentes deve ser feita da forma mais precisa possvel a fim de aperfeioar ainda mais as buscas por componentes. 2.1 Reuso Um dos requisitos mais importantes de um artefato a ser inserido no repositrio que esse seja reusvel, para isso existe uma srie de tcnicas e padres 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 indstria elucidam substanciais benefcios na aplicao de um reuso agressivo de software, sendo esses benefcios 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 repositrio. Isso nos leva a concluso que

qualquer artefato de software com potencial de reuso possa ser inserido no repositrio.
O processo de projeto, na maioria das disciplinas de engenharia, baseia-se no reuso de sistemas existentes ou componentes. Engenheiros mecnicos ou eltricos normalmente no especificam um projeto em que cada componente tenha de ser fabricado especialmente. Eles baseiam seus projetos em componentes j experimentados e testados. Esses componentes no so apenas pequenos componentes como flanges e vlvulas, mas incluem subsistemas maiores, como motores, condensadores ou turbinas (SOMMERVILE, 2007, p. 275).

12

A reusabilidade no se restringe apenas a componentes de software, essa viso limita dramaticamente os benefcios da reutilizao, podendo at anular quaisquer benefcios dessa pratica. A componentizao (CBD Component-Based Development) tem sido uma das prticas que obteve os melhores resultados em critrios de reutilizao, pois o seu conceito de reutilizao no se estende apenas aos cdigos executveis, mas como tambm a todos os artefatos criados desde a especificao at distribuio do componente (MAGELA, 2006, p. 46). Antes de tudo, o reuso tambm uma das metas da engenharia de software mais difceis de serem atingidas (PRESSMAN, 2006, p. 81). Atualmente, existe uma estratgia 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 construo 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, possvel citar quatro tipos de reuso, caracterizados pelo tamanho de seus contedos (SOMMERVILE, 2007, p. 276): Reuso oportunstico; Reuso de objetos e funes; Reuso de componentes; Reuso de sistemas de aplicaes.

2.1.1 Reuso oportunstico Esta forma de reuso se d quando o desenvolvedor conhece algum cdigo ou sistema que possua uma parte que poder ser reutilizada mediante a alguns ajustes quando necessrio, ento, esse desenvolvedor copia essas partes para o novo sistema, reduzindo assim os investimentos de custo e tempo; essa tcnica conhecida como Cut-and-Paste (SANCHES, 2005). Essa tcnica de reuso uma das mais perigosas e ineficientes de reuso, conforme Ezran (apud SANCHES, 2005), pois os fragmentos de cdigos so

13

conhecidos apenas por poucos desenvolvedores, alm de ser uma prtica individual e aleatria ao longo dos projetos, o que limita ainda mais seu reuso e torna difcil de implantar em outras reas ou departamentos da organizao, esse artefato que o fragmento de cdigo. Esta abordagem no necessariamente reduz os custos ou melhora a qualidade, podendo at mesmo influir negativamente nesses fatores quando h falhas nos cdigos copiados e esses se proliferam e diferenciam do cdigo original aumentando o tempo de desenvolvimento, porque os desenvolvedores so forados a corrigir as mesmas falhas diversas vezes em locais diferentes, quando esses cdigos so possveis de serem encontrados, pois nem sempre possvel rastrelos nos projetos em que foram implantados (SCHMIDT, 2002; EZRAN, 2002 apud SANCHES, 2005). 2.1.2 Reuso de objetos e funes O reuso baseado em bibliotecas de funes era comumente utilizado na dcada de 40, citado por Sommervile (2007, p. 276),o qual indica que era uma abordagem particularmente eficiente, pois muitas bibliotecas de cdigos para diferentes aplicaes e plataformas esto disponveis e podem ser facilmente acopladas a um projeto em desenvolvimento. 2.1.3 Reuso de componentes Segundo Sommervile (2007, p. 291), um componente mdio

significativamente maior que um procedimento ou funo, e at pouco tempo, era difcil reus-los. Os avanos permitiram uma padronizao promovida pelos principais fornecedores de software que possibilitaram uma interoperabilidade de componentes dentro de um framework, como o CORBA, que impulsionou o reuso sistemtico por meio da tcnica conhecida como a CBSE Component Based Software Engineering. Sommervile (2007, p. 292) explica que a CBSE um processo de integrao de componentes independentes para formao de um novo sistema, conceito esse fundamental para a promoo e idealizao de um repositrio de componentes. A CBSE ser explicada com mais detalhes no prximo tpico.

14

2.1.4 Reuso de sistemas de aplicaes Esse conceito de reuso, segundo Sommervile (2007), envolve o reuso de aplicaes inteiras com algumas configuraes para integrao, caracterizando-se por ser uma das tcnicas mais eficientes de reuso, pois envolve o reuso de grandes ativos que podem ser rapidamente configurados para criao de um novo sistema. Podemos citar como exemplo as aplicaes comerciais (COTS - Commercial off-theshelf) que so disponibilizadas com uma configurao comum para serem reutilizadas por diferentes ambientes e usurios (SOMMERVILE, 2007, p. 287). Um exemplo comum de um produto COTS que foram reusados por muitos anos so os sistemas de banco de dados, pois poucos desenvolvedores consideram implementar (SOMMERVILE, 2007). Alm da vantagem bvia do reuso que a de reduo dos custos de desenvolvimento, notamos que menos componentes de software tm que passar pelas fases de desenvolvimento padres de um produto que so especificao, projeo, implementao e validao. Entretanto, a reduo de custos apenas uma das vantagens relativas ao reuso, como demonstrado a seguir:
Tabela 1 - Benefcios do reuso (SOMMERVILE, 2003, p. 261).

Benefcios Maior confiabilidade

Explicao Os componentes reutilizados que so empregados nos sistemas em operao devem ser mais confiveis do que os componentes novos. Eles j foram experimentados e testados em diferentes ambientes. Os defeitos de projeto e de implementao so descobertos e eliminados no uso inicial dos componentes, reduzindo, assim, o nmero de falhas quando o componente reutilizado.

Reduo dos riscos de processo

Se recorrermos a um componente j existente, sero menores as incertezas sobre os riscos relacionados ao reuso desses componentes 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 especialistas

Em vez de os especialistas em aplicaes fazerem o mesmo trabalho em diferentes projetos, eles podem desenvolver componentes reutilizveis, que englobam seu conhecimento.

Conformidade com os padres

Alguns padres, como padres de interface com o usurio, podem ser implementados como um conjunto de componentes-padro. Por exemplo, os componentes reutilizveis podem ser desenvolvidos para implementar menus em uma interface com o usurio. O uso de interfaces-padro com o usurio melhora a confiabilidade, uma vez que os usurios possivelmente cometem menos enganos quando utilizam uma interface familiar.

Desenvolvimento acelerado

De modo geral, mais importante fornecer um sistema para o mercado o mais rpido possvel do que se prender aos custos gerais de desenvolvimento. O reuso de componentes acelera a produo, porque o tempo de desenvolvimento e o de validao tende a ser reduzido.

Verifica-se que os nveis 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. possvel concluir que o reuso de software mostra-se uma alternativa a ser considerada pelos desenvolvedores e organizaes, no apenas pela reduo de custos, mas tambm pelo aumento da qualidade, manutenabilidade e reduo dos riscos inerentes ao desenvolvimento. 2.2 Tcnicas para reuso de artefatos O reuso pode ser abordado nos diferentes nveis de um processo de desenvolvimento, inferindo no mesmo. Verifica-se que os conceitos que sero apresentados esto intimamente ligados ao conceito de arquitetura, que na Engenharia de Software possui algumas definies diferentes dependendo em qual contexto essa palavra empregada (MAGELA, 2006, p. 36). Em virtude da definio de arquitetura ser um conceito chave amplamente utilizado no processo de desenvolvimento de componentes, os

16

pargrafos seguintes definiro seu conceito em cada contexto que esse pode ser empregado. No contexto de estilo, arquitetura define quais padres arquiteturais um componente dever atender, delimitando assim o escopo a ser construdo. Essa definio mostra que um componente ou artefato possui um conjunto limitado de formas que permitam seu uso ou sua reutilizao (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 mdulos), reuso ou eliminao de recursividade (MAGELA, 2006). Sob a definio de arquitetura de sistemas, temos que essa engloba todas as dependncias do software em questo, como redes, banco de dados,

processadores, infra-estrutura e quaisquer outras dependncias. A viso arquitetural representa uma viso partilhada de todas as definies apresentadas acima, relevando as partes ditas como menos importantes para escopo de acordo com os riscos (MAGELA, 2006). Existem vrias tcnicas ou tecnologias que atravs de um contexto de arquitetura tentam aumentar a eficincia do reuso dos artefatos de software. Note que nada impede que elas possam ser empregadas em conjunto, aumentando ainda mais a eficincia em termos de reuso (SANCHES, 2005; SOMMERVILE, 2007). As tcnicas so as seguintes: Padres de Projeto; Frameworks de Aplicao; Processo de desenvolvimento baseado em componentes;

2.2.1 Padres de Projeto (Design Patterns) Ao tentar reutilizar artefatos executveis, o desenvolvedor estar

inevitavelmente limitado arquitetura escolhida para esse artefato. Essa definio de arquitetura pode variar desde a implementao de algoritmos especficos aos objetos e tipos descritos nas interfaces desses artefatos (SOMMERVILE, 2007).

17

Verifica-se que projetar uma arquitetura adaptvel a diversas situaes pode ser bastante problemtico dependendo da complexidade do artefato para o qual essa arquitetura definida. Sobre essa perspectiva verificou-se que h certos padres no projeto de arquitetura para resoluo desses problemas, padres esses que podem ser reusados em diferentes aplicaes. Um padro de projeto no uma especificao detalhada do problema, e sim uma abstrao que define uma soluo baseada em conhecimentos empricos comprovados para os problemas descritos por eles. O uso de um padro de projeto se d quando o desenvolvedor verifica que a descrio de um problema se enquadra na descrio de um padro de projeto comum a ele, sendo assim, o desenvolvedor aplica esse padro (PRESSMAN, 2006; SANCHES, 2005). De acordo com Gamma (apud SANCHES, 2005), padres de projeto so uma tentativa de superar o reuso de artefatos na busca de reusar tambm o projeto de arquitetura de uma aplicao. Uma clara vantagem na utilizao de padres de projeto a facilidade de comunicao entre os desenvolvedores, promovida pela definio de um nome comum para uma determinada soluo arquitetural (EZRAN apud SANCHES, 2005). 2.2.2 Frameworks de Aplicao Um framework um agrupamento de classes concretas e abstratas, e interfaces que tem um objetivo em comum, como um subsistema. Comportamentos especficos so adicionados atravs da implementao das classes abstratas ou configuraes especficas nos insumos desse subsistema. Note que um framework raramente uma aplicao propriamente dita, geralmente ela formada pela integrao de vrios frameworks (SOMMERVILE, 2007, p. 282). Conforme Sommervile (2007), um framework uma arquitetura genrica que pode ser utilizada para criar um subsistema ou aplicao mais especfica, sendo apontado como um problema dessa tcnica o tempo necessrio para se aprender a utiliz-lo, que encoraja a criao de profissionais especialistas em determinados frameworks. A arquitetura de um framework em particular geralmente se utiliza de padres de projeto para a sua organizao, o que lhe garante um rpido entendimento de como o framework poder ser agrupado para criao de um novo sistema.

18

2.2.3 Engenharia de software baseada em componentes O processo de desenvolvimento de componentes reutilizveis conta com uma especializao da engenharia de software, chamada de engenharia de software baseada em componentes, que prove algumas tcnicas e conceitos fundamentais no momento da projeo 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 projeo dos mesmos: Componentes independentes: so componentes com a incluso de interfaces, que so descries da arquitetura de comunicao de um componente, em que essas serviro de para separar a de

implementao

dos

componentes

suas

interfaces

comunicao com os sistemas que os usaro. Padres de componentes que facilitam a integrao de

componentes: So padres 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 padres, os mesmos devero ser independentes de linguagem de programao. Um middleware que fornea apoio de software para integrao de componentes: Utilizado quando se necessita de um software que controle a comunicao entre componentes independentes e distribudos, como o CORBA, que manipula os recursos de baixo nvel eficientemente e permite enfocar problemas relacionados aplicao. Alm disso, um middleware que implemente o modelo de componentes pode fornecer apoio alocao de recursos, ao gerenciamento de transaes, proteo e concorrncia. 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 construo de

19

sistemas complexos e de alta qualidade, em prazos menores. Isto tambm uma das premissas do reuso de software, sendo tambm uma das abordagens do reuso. A construo de componentes reutilizveis procura disponibilizar

componentes que possam ser agrupados facilmente, a fim de formar novos sistemas. Entretanto, no se pode construir um sistema apenas selecionando componentes de software reutilizveis e conect-los de forma automtica a fim de formar um sistema completo. A atividade de inter-relacionamento de componentes uma das mais difceis de serem resolvidas pela engenharia de software atualmente (SZYPERSKI apud SANCHES, 2005). O processo CBSE (Component-Based Software Engineering) no deve apenas ter como atividades a identificao de candidatos a componentes, mas tambm a adaptao de interfaces entre os componentes a fim de criar sistemas atendendo aos requisitos dos mesmos, atualizando-as caso necessrio e classificando-os segundo os critrios de qualidade adotados (PRESSMAN, 2006, p. 663). O ponto crtico para um desenvolvedor que utiliza a engenharia de software baseada em componentes a analise de domnio, em que o desenvolvedor precisa projetar os componentes de modo a atender a uma grande variedade de aplicaes num domnio especifico (SANCHES, 2005, p. 38). Uma vantagem clara para a utilizao dessa engenharia eficincia na qual se desenvolve novas aplicaes em termos de prazo, pois a utilizao de componentes prontos que necessitam de poucas adaptaes reduz dramaticamente o tempo de desenvolvimento de um sistema, reduzindo por consequncia o custo do mesmo (SANCHES, 2005, p. 38). possvel notar que o emprego da engenharia de software baseada em componentes aumenta dramaticamente a possibilidade de reutilizao e construo de artefatos com essa caracterstica, consequentemente propiciando uma tima abordagem a ser utilizada em conjunto a um ambiente para distribuio de artefatos utilizando um repositrio.

20

2.3

Repositrios para Artefatos Um repositrio para artefatos de software um local para armazenamento de

artefatos que podem ser reutilizados, a fim de prover a disponibilizao para os interessados. Nota-se que este repositrio conter informaes intelectuais importantes da empresa, fazendo com que deva ser criada uma forma de acesso e identificao para os usurios (SANCHES, 2005). A distribuio de artefatos de software reutilizveis utilizando um repositrio no um tema novo na engenharia de software, porm ainda no existe soluo eficiente para propagao do reuso desses artefatos, bem como descrio ou classificao dos artefatos que residem no repositrio, 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 repositrio centralizado e disponibilizados para os desenvolvedores. Pressman (2006, p. 674) prope que um ambiente semelhante a um conceito de biblioteca, contendo, em vez de livros, artefatos para reuso software, devendo preencher os seguintes critrios bsicos: Um banco de dados para armazenar capaz de guardar

componentes de software e a informao de classificao necessria para recuper-los; Um sistema de gesto de bibliotecas que fornea acesso ao banco de dados; Um sistema de recuperao de componentes de software (por exemplo, um negociador de solicitao entre objetos) que permita a uma aplicao capaz de recuperar componentes e servios do servidor da biblioteca; Ferramentas CBSE que do suporte integrao de componentes reusados a um novo projeto ou implementao. Esta biblioteca, denominada de biblioteca de reuso, pode ser um componente de um repositrio maior para artefatos de software reusveis, fornecendo facilidades para a guarda de componentes de software e uma serie de artefatos reusveis,

21

como por exemplo, especificaes, projetos, padres, frameworks, fragmentos de cdigo, casos de teste, guias de usurio (PRESSMAN, 2006, p. 674). Segundo Ezran (apud SANCHES, 2005), existe uma lista de vantagens relacionadas ao uso de um repositrio para artefatos reutilizveis 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 mudanas e melhorias nos artefatos. 2.3.1 Catlogo A idia de repositrio pressupe um catlogo, em que estes artefatos sero devidamente identificados para um posterior reuso. No caso, onde haja poucos artefatos reutilizveis ou pouco desenvolvedores, pode-se questionar se h necessidade de criao de um repositrio (SANCHES, 2005). No decorrer do crescimento do nmero de artefatos reusveis, haver a necessidade de definir e reestruturar o catlogo dos mesmos, pois o desenvolvedor poder deparar-se com situaes as quais no sabe que artefatos ele poder reutilizar, ou no saber onde encontrar um artefato, ou onde armazen-lo (SANCHES, 2005). Verifica-se, ento, que h uma necessidade de manuteno desse repositrio com relao aos artefatos que j existem nele. H dois modos de manuteno do repositrio, a forma gerenciada, que algum ficar responsvel pelo controle do repositrio; e a forma no gerenciada, a qual ningum ficar responsvel por esse controle. Esta segunda forma acarreta na variao da taxa de reuso dos componentes, pois o prprio desenvolvedor ficar responsvel por saber encontrar cada artefato, que provavelmente estar misturado em meio a outros, alm do risco de utilizar uma verso obsoleta daquele (SANCHES, 2005).

22

2.3.2 Modelagem da estrutura de um repositrio para artefatos. Embora os artefatos de software compartilhem de caractersticas comuns, estes podem variar quanto linguagem, ao formato de arquivo, granularidade e documentao (EZRAN apud SANCHES, 2005, p. 63). Contudo, como visto anteriormente, faz-se necessrio um catalogo de artefatos para o repositrio, com intuito de facilitar as buscas e identificao dos artefatos, com isso, pode-se concluir que o repositrio ser composto por um catlogo e de vrios artefatos reutilizveis. Tem-se que os artefatos podem ser diferentes entre si, porm, em termos de modelagem, todos possuem informaes para sua classificao, as quais sero referenciadas no catlogo. Esta parte comum so as informaes, que em conjunto, formam sua ficha cadastral, a qual ser referenciada pelo catlogo. 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 tambm pode ser chamada de metadado, devendo essa conter uma srie de campos a fim de facilitar sua busca no catlogo (NORTON apud SANCHES, 2005). Norton prope uma ficha cadastral para artefatos com as seguintes informaes: Nome nico de identificao do artefato; Autor; Data de criao; Data da ltima atualizao; Verso atual; Lista de palavras chave associadas ao artefato; Breve descrio do componente (rea de uso ou tecnologia envolvida). Detalhes relativos usabilidade, instalao e descrio dos artefatos poderiam ser descritos em documentos a parte, ou no prprio corpo do artefato. Outra informao importante sobre o artefato seria a sua localizao, seja num servidor interno a organizao ou externo em posse de terceiros (NORTON apud SANCHES, 2005).

23

Ezran (apud SANCHES, 2005) prope o seguinte modelo bsico, descrito na linguagem UML como um diagrama de objetos de um repositrio para artefatos:

Figura 1 Diagrama de objetos para implementao de um repositrio para artefatos proposto por Ezran (apud SANCHES, 2005).

O modelo acima representa a diagramao do repositrio e pode ser descrito da seguinte forma: Um repositrio possui apenas um catalogo; Um catlogo possui zero ou mais fichas cadastrais; Uma ficha cadastral descreve um componente, que por sua vez armazenado num nico repositrio; Um componente possui um nico corpo ou contedo.

A partir do modelo descrito por Ezran, verifica-se que esse repositrio no garante o versionamento dos artefatos inseridos, bem como tambm restringe o artefato a uma localizao fsica. Alem da viso arquitetural do contexto do repositrio Ezran props as possveis atividades realizadas pelos usurios: Busca pelo artefato; Incluso de um novo artefato; Alterao de um artefato;

24

Excluso de um artefato; Visualizao do catlogo; Organizao do catlogo; Histrico dos artefatos; Estatsticas sobre o repositrio; Controle de acesso.

O repositrio dever prover as informaes bsicas de manuteno, como busca, incluso, alterao e excluso dos artefatos contidos nele bem como as informaes da ficha cadastral dos artefatos. A operao de busca poderia ser incrementada com mecanismos avanados de busca por informaes da ficha cadastral do artefato (EZRAN, MORISIO e COLIN, 2002). A visualizao do catalogo de artefatos do repositrio prov um meio rpido de visualizao de todos os artefatos contidos no repositrio, que no caso de existir apenas algumas dezenas de artefatos no repositrio torna uma excelente abordagem de busca (EZRAN, MORISIO e COLIN, 2002). No caso do repositrio conter vrios artefatos, a busca sobre suas informaes podem se tornar ineficientes em vista da quantidade de resultados retornados, sendo assim, verifica-se que pode ser necessrio uma forma de classificao dos artefatos por sua estrutura (exemplo: framework, tutorial, cdigo, template etc), reas de aplicao (JAVA, Biologia, Matemtica, Segurana, C++, etc.) ou palavras que fazem analogia descrio do artefato (EZRAN, MORISIO e COLIN, 2002). Durante o uso do repositrio, haver casos em que um artefato dever ser substitudo por outro, seja por melhorias ou correes, as informaes sobre essas mudanas, como autor da mudana, uma lista de modificaes feitas no artefato e data da mudana, devero ser armazenadas para uma futura auditoria ou contato com os responsveis de alguma forma, levando em considerao a sugesto de Ezran, na sua ficha cadastral (EZRAN, MORISIO e COLIN, 2002).

25

2.4

Exemplos de repositrios Existem diversos repositrios para artefatos de software reutilizveis, eles

podem ser de acesso publico ou privado. Na internet encontram-se disponveis inmeros repositrios pblicos para artefatos, dentre eles possvel citar alguns como: jars (1998): Repositrio especializado na linguagem Java que apresenta componentes e programas executveis para soluo de problemas ou que auxiliem no desenvolvimento de software. Possui uma forma de classificao por categoria, em que os artefatos podem ser categorizados em suas reas de aplicao como matemtica, biologia, jogos ou grficos 3D; SourceForge (1999): Um dos mais conhecidos repositrios pblicos para artefatos de software de cdigo aberto. Nesse site possvel encontrar artefatos que podem ser agregados sem custos a uma aplicao, ou se utilizar o prprio domnio como um repositrio para o projeto e os desenvolvedores que queiram colaborar como codificadores; planetsourcecode (1997): outro repositrio para artefatos e tutoriais para diversas linguagens de programao. A maioria de seus artefatos consiste de fragmentos de cdigos, o que nos leva a concluso de um repositrio voltado para o reuso oportunstico. Os exemplos citados acima possuem o problema da sndrome do N.I.H. (Not invented here), ou seja, um problema de confiana nos artefatos por parte da organizao ou dos prprios desenvolvedores. No entanto, os repositrios desenvolvidos e utilizados internamente nas organizaes esto livres da maioria desses problemas, pois os desenvolvedores podem ser devidamente identificados. Pode-se citar como exemplo de um repositrio projetado para ser usado internamente a organizao: o CORE, utilizado e desenvolvido pela empresa brasileira C.E.S.A.R (2008). Suas caractersticas so descritas a seguir: Projetado para apoiar o reuso sistemtico de software;

26

Reuso de artefatos no geral (templates, cdigos e frameworks); Utilizado atravs do browser, o que permite o uso atravs da intranet da organizao e um plugin integrado a IDE (Integrated Development Environment, ou ambiente de desenvolvimento integrado) eclipse;

Possui uma definio de responsabilidades atravs de papis; Possui as funcionalidades bsicas de um repositrio, como pesquisa e manuteno dos itens inseridos.

Sobre

suas

caractersticas

possvel

destacar

da

diviso

de

responsabilidades em papis descritos a seguir (C.E.S.A.R, 2008): Produtor: Responsvel por criar e armazenar os artefatos de software reutilizveis; Consumidor: Ir utilizar os artefatos de softwares publicados no repositrio; Certificador: Esse papel responsvel pela validao da qualidade dos artefatos publicados no repositrio. No caso dos artefatos serem documentos, esses podem ser avaliados perante o ser formato ou padro. E no caso dos artefatos serem executveis, o certificador poder test-los perante alguns requisitos bsicos ou premissas assumidas para aquele artefato. Uma de suas funcionalidades permitir que os usurios avaliem o artefato atravs de uma mtrica pr-definida, e essas avaliaes so utilizadas como forma de classificao desses artefatos. Existem diversas solues que promovem o reuso de artefatos nas organizaes, entretanto, nos captulos seguintes, sero abordados os repositrios para artefatos reutilizveis demonstrando que os mesmos podem ser ineficientes na promoo desses artefatos e na evoluo profissional dos desenvolvedores.

27

3 REDES SOCIAIS
As redes scias podem ser importantes para a distribuio da informao dos artefatos, no somente para divulgao dos mesmos, mas como tambm para um meio que favorea a evoluo e criao de novas ideias atravs da interao dos desenvolvedores. Existem diversos significados para o conceito de redes, dentre eles, as que se aplicam a este trabalho so as seguintes: estrutura de nodos e elos; uma comunidade no geogrfica; um sistema de apoio ou sistema fsico que se parea com uma rvore ou uma rede. A rede social, derivando deste conceito, passa a representar um conjunto de participantes autnomos, unindo ideias e recursos em torno de valores e interesses compartilhados (MARTELETO, 2001). O termo rede social surgiu em conjunto com anncio do termo Web 2.0, descrito pela empresa OReilly em 2004. O termo Web 2.0 marcou uma quebra de paradigma, onde antes, os servios que eram oferecidos na internet tinham como caractersticas a falta de interatividade entre os usurios e o servio oferecido, fazendo uma analogia ao conceito de produtor e consumidor, em que os internautas at ento, eram apenas telespectadores do contedo encontrado na internet (COUTINHO, 2007). Os padres dos novos produtos e servios caracterizaram uma quebra do paradigma predominante at ento, seguindo para uma nova forma de comunicao, cujos usurios poderiam agora colaborar ou interagir com os produtos e servios oferecidos, alm 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, no mais necessrio conhecimentos em programao ou a utilizao de ferramentas complexas, ou seja, seus servios e produtos tornaram-se mais acessveis (COUTINHO, 2007). A seguir, a frase de Tim OReilly, o primeiro a identificar e definir o termo Web 2.0 (COUTINHO, 2007, p. 2; PEREIRA, 2010):

28

A Web 2.0 a mudana 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 so usados pelas pessoas, aproveitando a inteligncia coletiva.

Conclui-se ento que as ferramentas criadas no contexto da Web 2.0 procuram promover a interao entre os usurios com os produtos e servios disponibilizados na plataforma Web, sendo esse um dos objetivos bsicos do trabalho proposto nessa monografia. 3.1 As redes sociais e as organizaes A formao de redes nas organizaes ocorre de forma variada e s vezes comum, desde a conversa na hora do caf at listas de discusses. Essas interaes, quando voltadas para o mbito organizacional, geralmente apresentam dois objetivos bsicos: confirmar a existncia e contedo do conhecimento ou criar novos conhecimentos. Esse intercambio de ideias, opinies e crenas

proporcionados por essas discusses alavanca o primeiro e o mais importante passo para a criao do conhecimento: o compartilhamento do conhecimento tcito dentro da comunidade da rede, ou no caso, a organizao (INS, ROSECLER e GUERREIRO, 2005). Capra (apud INS, ROSECLER, & GUERREIRO, 2005) elucida a afirmao anterior atravs da frase abaixo:
[...] na era da informao na qual vivemos as funes e processos sociais organizam-se cada vez mais em torno de redes. Quer se trate das grandes empresas, do mercado financeiro, dos meios de comunicao ou das novas ONGs globais, constatamos que a organizao em rede tornouse um fenmeno social importante e uma fonte crtica de poder.

A caracterstica de dinamismo das redes sociais fez com que esta seja aplicada no mbito organizacional como espaos para compartilhamento da informao e do conhecimento. Esses espaos podem ser tanto virtuais quanto presencias, nos quais as pessoas com objetivos em comum trocam experincias, criando bases e gerando informaes importantes para o setor nas quais atuam (INS, ROSECLER e GUERREIRO, 2005). Quanto maior a interao entre os indivduos, no contexto da troca de conhecimento, maior ser a bagagem de conhecimentos ou estoque de informao. Entretanto, somente nas ltimas dcadas as redes sociais passaram a ser vistas

29

como um instrumento organizacional, mesmo constada como um importante recurso profissional (INS, ROSECLER e GUERREIRO, 2005).
A importncia da informao no desempenho das empresas destacada por diversos autores, entre os quais Lesca e Almeida (1994, p.67) quando afirmam que a informao um vetor estratgico importantssimo, pois pode multiplicar a sinergia dos esforos ou anular o resultado do conjunto dos esforos. Drucker (1992 apud INS, ROSECLER, & GUERREIRO, 2005) acrescenta ainda que ela fator de produo importante para a obteno de vantagem competitiva, uma vez que os fatores tradicionais terras, mo-de-obra e recursos financeiros por si ss j no garantem a competitividade.

Verifica-se que o principal objetivo de uma rede a troca de informaes e evoluo das mesmas, isto a torna uma excelente ferramenta a ser agregada com o intuito de maximizar a interao entre seus participantes, assim como a evoluo das informaes trocadas. Todavia, o propsito da rede poder ser desvirtuado se no houver uma forma de controle ou interesse de seus participantes (INS, ROSECLER e GUERREIRO, 2005). 3.2 Os tipos de informaes e sua utilizao na rede social As informaes esto classificadas em trs grupos, conforme explica Miranda (apud INS, ROSECLER, & GUERREIRO, 2005): Conhecimentos Explcitos; Conhecimentos Tcitos; Conhecimentos Estratgicos.

O conhecimento explcito aquele conhecimento ou saber que j est disponvel em alguma mdia, como livros, documentos, artigos etc. Diferente do conhecimento explcito, o conhecimento ttico o acmulo de experincias com base em conhecimentos explcitos (INS, ROSECLER e GUERREIRO, 2005). O conhecimento estratgico a combinao dos conhecimentos tcitos e explcitos, a fim de elencar informaes para as tomadas de deciso, sejam para minimizar riscos ou aumentar a eficincia dos resultados das aes executadas (INS, ROSECLER e GUERREIRO, 2005).

30

Numa viso organizacional, Choo ( apud INS, ROSECLER, & GUERREIRO, 2005) prope que a informao requisitada em uma rede social para ser utilizada para trs finalidades distintas: Para construo de significados (sense making) atravs da coleta de informaes do ambiente; Construo de novos conhecimentos (knowledge creating) por meio da converso dos conhecimentos de tcito para explcito e da partilha desses conhecimentos a fim de inovar; A terceira finalidade diz respeito busca de informaes para tomada de deciso, que os indivduos da rede usam das informaes contidas nela para tomada de deciso. 3.3 A importncia das redes sociais sobre as informaes Dixon (apud INS, ROSECLER, & GUERREIRO, 2005) elucida que no eficiente criar uma grande base de dados contendo enormes volumes de informaes, quando o desafio real responder como esses recursos sero utilizados. Se o recurso citado por Dixon for pensado como um repositrio simples contendo informaes sobre os artefatos e os artefatos em si, o mesmo no ser devidamente aproveitado, pois esse modelo no suporta a interao entre seus atores (desenvolvedores participantes), de forma que esses possam compartilhar informaes e experincias, visando ao aprendizado organizacional,

consequentemente contribuindo para o crescimento profissional individual e a criao de novos conhecimentos (INS, ROSECLER e GUERREIRO, 2005). Lemos (apud INS, ROSECLER, & GUERREIRO, 2005) ressalta a importncia do uso das redes scias no contexto atual das organizaes, afirmando que sua utilizao uma das mais adequadas para intensificar o aprendizado, a gerao de conhecimentos e inovaes.

31

3.4

Tipos de redes sociais As ferramentas sociais citadas a seguir podem vir a auxiliar na troca de

informaes de forma colaborativa entre seus usurios, visando tambm auxiliar na evoluo de cada usurio, transformando conhecimentos tcitos em explcitos e vice-versa. O acmulo de experincias e conhecimentos uma base para o conhecimento estratgico, ou seja, informaes que auxiliem na tomada de deciso. 3.4.1 Fruns de discusses Fruns assumem um papel de infra-estrutura base para a colaborao entre os usurios sobre assuntos relevantes, possibilitando que qualquer usurio em especfico possa intervir nos assuntos que so objetos de estudo e responder quaisquer questes propostas, tornando dessa forma, mais eficiente a resoluo de problemas comuns a um grupo de usurios (MIRANDA, MORAIS, et al., 2001). A forma como acontece comunicao entre os usurios de um frum de discusso permite aos participantes refletir nas contribuies 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 frum geralmente aumenta a cada resposta publicada, pois os usuarios tm tempo para pensar, processar e relacionar suas ideias com as publicaes anteriores sobre o assunto em questo. O fato das publicaes anteriores serem registradas para uma futura visualizao ajuda a solucionar dvidas repetidas de usurios diferentes e a relembrar discusses anteriores ou respostas anteriores (MIRANDA, MORAIS, et al., 2001). O frum, quando utilizado como ferramenta didtica, promove alm do reuso uma forma eficaz para resoluo de problemas, embora no seja considera uma ferramenta que nasceu da Web 2.0. Como exemplo de fruns de discusses utlizados no desenvolvimento de software com sucesso tem-se a lista a seguir: GUJ (2002 ) - Grupo de Usurios Java; CEJUG (2002) - Cear Java User Group; JavaRanch (1998).

32

Todas as comunidades j citadas so exemplos de fruns de discusso que fazem sucesso e se tornaram uma inestimvel fonte de pesquisa para diversos desenvolvedores que alm de aprimorar seus conhecimentos atravs de experincias alheias que foram transmitidas para o grupo, tambm contribuem formando assim uma rede social para troca de informaes 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 pgina na Web que se pressupe ser atualizada com grande frequncia atravs da colocao de mensagens que se designam posts constitudas por imagens e/ou textos normalmente de pequenas dimenses (muitas vezes incluindo links para sites de interesse e/ou comentrios e pensamentos pessoais do autor) e apresentadas de forma cronolgica, sendo as mensagens mais recentes normalmente apresentadas em primeiro lugar.

Gomes (apud COUTINHO, 2007) explica que existem duas possveis utilizaes de blogs com intuitivo educativo: Como recurso pedaggico; Como estratgia educativa.

A utilizao de blogs como recurso pedaggico caracterizado, conforme Gomes (apud COUTINHO, 2007), em dois modos, quando utilizado para disponibilizao de informaes especializadas, no caso de blogs que um professor o autor. Dessa forma, possvel fazer uma analogia queles desenvolvedores que se tornam especialistas em determinados assuntos, frameworks, banco de dados, tcnicas para gerenciamento de projeto ou que simplesmente possuem um conhecimento diferenciado. As informaes especializadas disponibilizadas nos blogs podem ainda ser utilizadas como fonte de pesquisa para os desenvolvedores da organizao, sendo esse o seu segundo modo de utilizao como recurso pedaggico (COUTINHO, 2007).

33

A outra forma de utilizao de um blog descrita como estratgia educativa, cujos usurios utilizam-se do blog como integrao, intercambio, debate e colaborao, ambiente esse que conveniente a inovao ou criao de novos conhecimentos (COUTINHO, 2007). Diferente de um frum, um blog caracteriza-se por ser mantido, geralmente, por apenas uma pessoa, porm, h blogs que so mantidos por um conjunto de pessoas em que os responsveis podem publicar pesquisas, trabalhos ou experincias 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 implantao com intuito de levantar novos conhecimentos e experincias que no se sobressaem nos fruns em que o foco so as dvidas ou assuntos especficos levantados pelos usurios. 3.5 Ferramentas para criao de redes sociais Existem algumas ferramentas no mercado que proporcionam a criao de uma rede social de forma facilitada, em sua maioria esses produtos so caracterizados como CMS (Sistema Gerenciador de Contedo, ou do ingls Content Manager System), ou similares. Essas ferramentas tm como objetivo a alta usabilidade proporcionada atravs de modelos pr-configurados de arquitetura, no sentido de viso arquitetural, como estipulao de um SGBD (Sistema gerenciador de banco de dados) padro, ou dependncia de condies especiais para execuo como ambientes com suporte a determinadas tecnologias ou mesmo um modelo padro de dados, onde so definidas quais informaes so persistidas. Algumas destas ferramentas so um exemplo de reuso sistemtico, pois a partir da reutilizao de modelos (o conceito de modelos envolve quaisquer artefatos que possam ser reutilizados) e configuraes numa arquitetura pr-definida,

34

possvel se criar um sistema dentro do contexto ao qual sua arquitetura permita, no caso, blogs, fruns ou outros tipos de redes. Existem inmeras ferramentas no mercado que proporcionam a usurios inexperientes um ambiente simples e eficiente para criao redes sociais. Dentre essas ferramentas podemos citar algumas que se destacaram em nmeros de usurios como: WordPress (2003); Blogger (1999); JForum (2005).

Dentre as ferramentas citadas, o WordPress talvez a mais utilizada, seu nmero de usurios cerca de dez milhes. O WordPress comeou em 2003, antes da criao da Web 2.0, o que perfeitamente normal por que mostra que o a Web 2.0 apenas o ponto onde se percebeu a mudana de paradigma, e no exatamente o perodo 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 so mini-aplicaes que podem ser agregadas ao blog dinamicamente, contando que esse seja devidamente configurado, o que na maioria das vezes no exigem muito dos usurios (WordPress, 2003). O Blogger uma ferramenta da Google, comprada posteriormente ao seu lanamento em 1999, ferramenta que originou o termo blog, fazendo sucesso desde ento, porm devido cobrana pelo servio, no se tornou to utilizada at que depois da compra pela Google em 2003, seus servios foram liberados sem custos aos usurios. O Blogger fez uma importante inovao com a possibilidade dos usurios lanarem os posts sem a necessidade de qualquer ferramenta adicional, sendo todo o processo atravs do site principal, ou seja, de forma online pelo prprio browser (Blogger, 1999). Dentre as ferramentas para fruns, pode-se citar uma que conhecida e utilizada mundialmente, e h muito tempo, o JForum, um software voltado para criao de fruns de discusses em geral, com contedo altamente adaptvel e suporte a diversas lnguas com base na plataforma Java. Alm de ser a base para

35

alguns dos exemplos de fruns citados anteriormente, o JForum representa um outro software que se utiliza de plugins e pode ser classificado em termos de reuso como reuso sistemtico (STEIL, 2005). No prximo captulo ser apresentada a proposta de um ambiente onde os conceitos de redes sociais e repositrios para artefatos so mesclados a fim de formar um ambiente em que as transformaes da informao possam ocorrer mais facilmente atravs da interao entre os desenvolvedores e os artefatos reutilizveis de software para que sejam mais eficientemente promovidos.

36

4 REUSO UTILIZANDO REPOSITRIOS PARA ARTEFATOS COM REDES SOCIAIS.

Este captulo dedica-se ao planejamento de um repositrio para artefatos utilizando redes sociais com base nos conceitos que foram explicados nos captulos 2 e 3. Ser demonstrado o planejamento desse ambiente a partir de um grupo de requisitos bsicos, que sero desenvolvidos utilizando ferramentas de diagramao e prototipao para expressar as caractersticas desse sistema. Pressman (Engenharia de software, 2006, p. 706), na sua viso de futuro faz a seguinte afirmao:
Quando duas importantes tecnologias so combinadas, o impacto do resultado da combinao frequentemente maior que a soma do impacto de cada uma separadamente...Tecnologias frequentemente evoluem ao longo de caminhos separados, mas um impacto significativo em negcio ou na sociedade ocorre somente quando algum as combina para resolver um problema...Neste contexto, redes implicam em conexes entre pessoas ou pessoas entre informao. medida que a rede cresce, a probabilidade de sinergia entre dois ns da rede (por exemplo, pessoas e fontes de informao) tambm cresce. Uma conexo acidental (descoberta por acaso) pode levar inspirao e a uma nova tecnologia ou aplicao.

proposto ento um ambiente onde seja integrado o reuso, qualidade, evoluo dos artefatos de software reutilizveis e a no menos importante interao entre os prprios desenvolvedores, a fim de aumentar a eficincia do

desenvolvimento de software em questes de qualidade, reusabilidade, evoluo dos artefatos e de crescimento profissional dos desenvolvedores,

consequentemente diminuindo os custos e riscos. Na criao de uma rede social importante ter em mente que seu propsito poder ser desvirtuado se no houver uma forma de controle ou interesse de seus participantes, podendo at necessitar de auxlio de uma metodologia ou de um forte hbito que elucide sua utilizao (MARTELETO, 2001). A fim de aumentar o envolvimento dos desenvolvedores na rede, faz-se necessrio um agrupamento das informaes relativas ao processo de desenvolvimento num ponto central que proporcione alguma forma de comunicao, como fruns para discusses ou blogs.

37

4.1

Pesquisa de mercado Para melhor avaliar a importncia desse trabalho, foi realizada uma pesquisa

que teve como pblico alvo pessoas relacionadas com as organizaes 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 nvel gerencial, como gestores de projeto. Em termos de meio para troca de informaes, pode-se observar perante a pesquisa realizada atravs do questionrio no Anexo D -, que 100% das pessoas informaram que suas organizaes procuram promover a troca de informaes de seus desenvolvedores atravs de blogs ou fruns internos, o que mostra a importncia que o mercado est dando s ferramentas, promovendo a interao entre os desenvolvedores e os artefatos. Em discordncia quanto aos dados citados anteriormente, verifica-se que 58,3% dos entrevistados afirmaram que suas organizaes no procuram alcanar o reuso sistemtico, desse grupo 85,7% afirmaram que sua organizao possui apenas a ferramenta de controle de verso, enquanto os 15% restante adicionou a resposta que sua organizao possui uma ferramenta para gerenciar testes automatizados. Como verificado anteriormente, existem timas ferramentas que podem ser utilizadas para criao de redes sociais que no possuem custos e no exigem conhecimentos avanados em informtica de quem s utiliza, enquanto que a construo de um artefato de software reutilizvel consome bem mais recursos organizacionais, como pessoas, tempo e conhecimentos especficos, podendo ser esse o motivo pelo qual as empresas esto 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 organizao no promove o reuso sistemtico 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 organizao onde trabalham no promove a evoluo dos artefatos criados, e 91,6% das pessoas entrevistadas afirmaram que sua organizao no possui um repositrio para artefatos de software reutilizveis.

38

Esses nmeros indicam a carncia das organizaes 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 necessrio definir os requisitos do sistema proposto no incio desse captulo, tendo como base as informaes apresentadas nos captulos 2 e 3. Os requisitos do sistema a seguir foram definidos a partir da tcnica conhecida como brainstorming, em que as possveis funcionalidades do sistema so criadas a partir do seu prprio contexto. (VARGAS, 2009). Promover a interao entre os desenvolvedores, garantindo as transformaes dos conhecimentos em seus trs nveis; Promover para os desenvolvedores os artefatos de softwares que a organizao possui; Promover a evoluo dos artefatos e desenvolvedores atravs da maior interao entre eles; Promover o reuso sistemtico e uma melhor qualidade dos softwares da organizao; Melhorar a forma de classificao dos artefatos atravs da utilizao de informaes dos desenvolvedores e projetos que se relacionam com ele. A partir dos requisitos acima, foram elaborados alguns prottipos, que esto anexados ao final da monografia, das possveis interfaces do sistema utilizando a ferramenta de prototipao conhecida como Pencil. Pode-se verificar, atravs da tela apresentada na figura, que foram mantidos os conceitos de repositrios e redes sociais atravs da colaborao com fruns 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 informaes relacionadas com os projetos da organizao. Em vista disso, faz-se necessrio a definio de um modelo de entidades para aplicao que elucide as inter-relaes e os fluxos do sistema, como demonstrado no tpico seguinte. 4.3 Uma viso 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 viso arquitetural do contexto do repositrio, insuficiente para agregar uma rede social, pois no h suporte na troca de informaes entre os desenvolvedores ou mesmo no objeto que representa o prprio desenvolvedor. Em vista da mudana 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 tpico 4.2. Foi-se utilizada a linguagem UML para a modelagem desse ambiente de integrao, o qual ser chamado de CrossDev. Como cada desenvolvedor ter seu perfil adicionado ao sistema, bem como suas contribuies em forma de posts e artefatos, faz-se necessrio um sistema controle de acesso. Abaixo um diagrama de casos de uso que representa o novo ambiento em alto nvel:

Figura 3 Diagrama de casos de uso do ambiente proposto.

Pode-se perceber que a mudana de escopo do sistema acarreta na mudana do diagrama de classes onde agora so acrescidas as informaes pertinentes aos desenvolvedores e as formas de interaes 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 comunicao, porm elas no 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 tpico 2.3, informaes pertinentes aos desenvolvedores e as formas de redes sociais adotadas. A seguir sero descritas as novas relaes adicionadas ao diagrama de Ezran: Projeto; Desenvolvedores; Histrico; Artefato-artefato; Testes; Frum; Blog; Lista de discusso.

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 frum. No caso dos blogs devem ser postados no blog de cada projeto alguns de seus documentos de acompanhamento e suas lies aprendidas, e no

42

caso dos fruns deve existir uma lista de discusso particular do projeto onde seriam discutidos quaisquer tpicos relacionados ao projeto, porm essas so ideias complementares que podem ser adaptadas sem necessidade de modificar o modelo acima. Os desenvolvedores so as entidades bsicas do sistema, contendo seus perfis e informaes relacionadas a sua formao ou especializao. Segundo o diagrama de classes (figura 4), os desenvolvedores possuem as seguintes relaes: Podem possui um nico blog pessoal; Podem estar participando de vrias discusses nos fruns; Podem participar da vrias discusses sobre artefatos; Podem ter participado da criao de vrios artefatos.

Um frum uma ideia bastante popular no contexto organizacional, pois podem ser publicados problemas individuais ou comuns ao grupo de

desenvolvedores da organizao, bem como podem ser encontrada solues para problemas anteriores em seu histrico, entretanto a classe frum, definida no diagrama de classes acima, especifica a funcionalidade frum e no a entidade persistente em si, assim como a classe blog descrita abaixo. O objeto Blog individual para cada desenvolvedor, o que traz uma valorizao a individualidade e originalidade de cada um. Neste espao o desenvolvedor pode publicar e promover suas ideias em particular, assim como seus trabalhos e pesquisas. O objeto Histrico representa o histrico do artefato, listas de discusses sobre as verses anteriores, testes anteriores, etc. Note que um artefato pode possuir inmeras verses anteriores, e essas esto vinculadas a um nico artefato que representa a verso atual. Assim como os fruns e blogs, esse objeto histrico representa apenas sua ideia bsica e no faz meno a forma como ser implementado. O objeto Testes representa um conjunto de testes para um artefato, esses objetos so importantes para promover a qualidade do artefato atravs do total de cobertura de seus cdigos, obviamente, quanto mais coberto por testes o artefato, mais garantido ser seu comportamento esperado.

43

A lista de discusso por artefato parte do mesmo principio do frum por projeto, onde quaisquer questes sobre aquele artefato podero ser expostas para que os desenvolvedores da organizao, inclusive facilitando o levantamento de problemas. 4.4 Novos critrios para classificao dos artefatos. Como j sabido, uma pesquisa em um repositrio com diversos de artefatos pode retornar vrios resultados: artefatos construdos 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 classificao descritas abaixo: Nvel de formao da equipe de criadores do artefato; Quantidade de projetos que esto utilizando aquele artefato; Total de cobertura de testes nos artefatos; Pode-se utilizar tambm os posts e discusses que referenciaram aquele artefato; Pode-se utilizar de recomendaes, feitas pelos prprios

desenvolvedores para um artefato. Um dos critrios para classificao dos artefatos que poderia ser utilizados classificao com base nas informaes dos desenvolvedores, informaes sobre suas competncias ou especializaes dos desenvolvedores que participaram da construo do artefato, como conhecimentos em banco de dados, Webdesign ou diferentes certificaes (PRESSMAN, 2006). Outra forma de classificao seria utilizando o histrico, nmero de falhas ou quaisquer estatsticas que indiquem sua qualidade como o percentual de cdigo coberto por testes. Essas informaes incrementariam a pesquisa por artefatos de forma a prover ao desenvolvedor, no somente as informaes do artefato, mas tambm opinies de outros desenvolvedores e a quantidade de projetos que utilizam o artefato, ou seja, informaes de conhecimentos empricos.

44

Verifica-se que essa forma de classificao ajudaria a desenvolvedores a confiar nos artefatos disponibilizado, desde que esses estejam com nveis aceitveis de qualidade, e esses nveis expostos nesse ambiente. Atravs de wireframes, tcnica que utilizada para criao de prottipos de interfaces grficas, na figura 5 demonstrado uma tela inicial do sistema proposto que se utiliza desses critrios de classificao:

Figura 5 - Tela de visualizao de artefatos.

4.5

As informaes no repositrio importante citar que a introduo de conceitos de redes sociais sobre os

repositrios implica que as informaes podero ser extradas para fins diferentes do propsito da rede social utilizando de tcnicas como Business Intelligence (BI), onde informaes relativas a rede so extradas e utilizadas para a tomada de deciso. H diversas informaes que poderiam ser extradas desse ambiente, como (AIRTON, 2009):

45

Quais artefatos so mais reutilizados provendo assim uma viso de quais artefatos devem ser ter nfase na sua qualidade e testes; Quais artefatos esto trazendo mais problemas, e podem gerar riscos aos projetos; Atravs do conhecimento emprico dos desenvolvedores, obter informaes para decidir quais artefatos, ferramentas ou quaisquer insumos usados no desenvolvimento devem ser adquiridos ou desenvolvidos pela empresa.

Como possvel verificar nos anexos Anexo A -, Anexo B - e Anexo C - o CrossDev possui as informaes citadas acima as quais poderiam ser usadas para a tcnica de BI ou como informaes de nvel estratgico. 4.6 Integrao com outros sistemas A fim de incrementar suas funcionalidades e informaes, importante que o repositrio permitisse a integrao com outros sistemas teis como os sistemas para integrao contnua (ex: Hudson, CruiseControl, Continuum, Team City), controle de dependncias (MAVEN 2, MAVEN 1, Gradle, Ivy, Ant) e ou qualquer outro ambiente para testes automatizados (SOARES, 2009). Os ambientes de integrao contnua provem um meio de monitorar a integrao de sistemas, quando mdulos novos so integrados com os antigos. Pode-se configurar o ambiente de integrao contnua para executar a compilao e os testes vinculados aquele sistema, bem como gerar uma serie de mtricas para analise dos sistemas (SOARES, 2009). As ferramentas para gerenciamento de dependncias provem uma forma de controlar as dependncias na fase de implementao em projetos que utilizam inmeros artefatos, como controle das verses dos artefatos utilizados e a forma como so construdos. A integrao com esses sistemas agrega as vantagens para a fase de implementao do projeto como verificaes das qualidades do cdigo e controle das dependncias do sistema, ou seja, as vantagens do uso das ferramentas em si.

46

5 CONCLUSO
Pode-se verificar que atravs do uso de redes sociais a informao 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 organizaes que trabalham nesse ramo j aplica alguns conceitos de redes sociais, porem essas organizaes no se utilizam desses conceitos para promoo do reuso de seus artefatos, consequentemente no se beneficiam de uma forma de diminuir os custos e acelerar o desenvolvimento. Ainda segundo a pesquisa de mercado, a maioria das organizaes no possuem um repositrio ou ambiente dedicado ao armazenamento e manuteno de artefatos reutilizveis de software, que embora no 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 organizaes promovem o reuso sistemtico, tem uma ideia errada de reuso, pois como visto, um dos pontos bsicos para o reuso sistmico que seus nveis menores sejam cumpridos, tarefa que sem o auxilio de uma ferramenta como um repositrio bastante improvvel de acontecer. A ferramenta proposta nesse trabalho trs consigo os conceitos de redes socais e repositrio para artefatos de software, o que consequentemente promove o reuso e todos os benefcios que derivam desse atributo. Como j sabido, os custos em se construir um software reusvel so bem maiores do que softwares sem essa possibilidade, entretanto, empresas so 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 tcnicas levantadas neste trabalho em empresas de desenvolvimento de software.

48

7 REFERNCIAS
AIRTON, E. C. Inteligncia competitiva e suas conexes epistemolgicas com gesto da informao 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 Usurios Java. Grupo de Usurios 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. INS, T. M.; ROSECLER, A. A.; GUERREIRO, I. D. C. Das redes sociais inovao. Instituto Brasileiro de Informao em Cincia 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 - Princpios. Rio de Janeiro: Alta Books, 2006. MARTELETO, R. M. Anlise de redes sociais - aplicao nos estudos de transferencia da informao. Ci. Inf., Janeiro 2001. MIRANDA, L. et al. Ambientes para aprendizagem na web: Uma experincia com fruns de discusso. Conferencia Internacional de Tecnologias de Informao e Comunicao na Educao. Centro de competencia Nnio da Universidade do Minho: Braga. 2001. p. 585 - 593. PDUA, W. P. Engenharia de Software: Fundamentos, Mtodos e Padres. Rio de Janeiro: LTC Editora, 2005. PEREIRA, D. R. DISCURSOS SOBRE A WEB 2.0 E A EDUCAO: UMA ANLISE SEMITICA, 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. So Paulo: Mc Graw Hill, 2006. SANCHES, M. G. Um Estudo Sobre os Riscos Inerentes Implantao 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 Eletrnica de Sistemas de Informao, Conselheiro Lafaiete, v. 3, n. 1, 2009. ISSN 1677-3071. SOMMERVILE, I. Engenharia de Software. So Paulo: Pearson Addison Wesley, 2003. SOMMERVILE, I. Engenharia de Software. So Paulo: Pearson Addison Wesley, 2007. STEIL, R. G. JForum. JForum.net, 12 mar. 2005. Disponivel em:

<http://jforum.net/team.jsp>. Acesso em: 2010 out. 10.

50

VARGAS, R. Gerenciamento de projetos: Estabelecendo Diferencias Competitivos. 7 Edio. ed. Rio de Janeiro: BRASPORT Livros e Multimdia 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 - Formulrio de pesquisa cientfica parte I.

55

Anexo E - Formulrio de pesquisa cientfica parte II.

56

Anexo F - Formulrio de pesquisa cientfica parte III.