RAFAEL PIMENTA TUVO         JOSÉ ADAUTO OLIVEIRA DE MENEZES JUNIOR                           ERCOLABUm ambiente colaborati...
RAFAEL PIMENTA TUVO         JOSÉ ADAUTO OLIVEIRA DE MENEZES JUNIOR                           ERCOLABUm ambiente colaborati...
CERTIFICADOCertifico que a presente memória, ERCOLAB - Um ambiente colaborativo para auxiliar aelicitação de requisitos ba...
DEDICATÓRIA“Dedico este trabalho a minha mãe Yara Menezes Pimenta por todo o incentivo durantea empreitada e a minha namor...
AGRADECIMENTOS           Agradecemos a Deus por mais esta etapa e esperamos que ainda nosaconteçam muitas outras. Agradece...
RESUMOSabe-se que um dos maiores problemas no desenvolvimento de software é a escolhaequivocada dos seus requisitos e tamb...
ABSTRACTA biggest problems in software development is the wrong choice of their requirements. Thetheory of collaboration i...
LISTA DE FIGURASFigura 1 – Diagrama do Modelo de Colaboração 3C .................................................14Figura ...
LISTA DE ABREVIATURASAJAX - Asynchronous JavaScript and XMLCRC – Cooperative Requirements CaptureJAD – Joint Application D...
SUMÁRIOINTRODUÇÃO ..........................................................................................112. FUNDAMENT...
11INTRODUÇÃO            A maneira de trabalhar da sociedade é revolucionada por tecnologia e dásuporte às formas de relaci...
12          O capitulo 4 encerra a fundamentação teórica explicando o que são casos deuso e todas as características que o...
132. FUNDAMENTAÇÃO TEÓRICA2.1 Colaboração            Como o aumento das demandas e do volume de trabalho nas organizaçõesc...
142.1.1.    Elementos da Colaboração          O modelo 3C para sistemas colaborativos, proposto em 1991 por (ELLISapud FUK...
15todas as classificações conhecidas. Exemplos de sistemas síncronos distribuídos sãoos editores multi-usuários de tempo r...
16        Figura 3 – Relação Memória do Grupo X Colaboração (ARAUJO apud ROSA , 2005)          Com a comunicação, compromi...
172.1.1.2     Coordenação           Segundo Karl Marx, “Colaboração são múltiplos indivíduos trabalhandojuntos de maneira ...
18          Como os participantes colaboram a todo tempo, idéias antagônicas podem edevem acabar ocorrendo nos trabalhos e...
19          Zanlorenci e Burnett (2001), Sommerville, entre outros autores, dividem osrequisitos em funcionais e não funci...
202.2.1       Fase de Levantamento de Requisitos            Na fase de levantamento de requisitos, os analistas de sistema...
21      •   Problemas de Compreensão: Os próprios usuários do sistema muitas vezes          não sabem do que precisam. Exi...
222.3 Casos de Uso           Os casos de uso foram propostos inicialmente pelo cientista da computaçãosueco Ivar Hjalmar J...
23atores e definir qual o fluxo principal e os possíveis fluxos alternativos docomportamento (BOOCH; RUMBAUGH ; JACOBSON ,...
24num único caso de uso pode ajudar a garantir que todos os possíveis cenários sejamtrabalhados em conjunto:   Caso de Uso...
25                A máquina continua a aceitar moedas e aceitar outra escolha do                cliente.   Pós-condições: ...
26Figura 4 – Exemplo de Diagrama de Casos de Uso
273. ERCOLAB          O projeto consiste em desenvolver um ambiente que auxilie aos analistas desistemas durante as fases ...
28          A dificuldade de comunicação entre os envolvidos no processo é uma dasprincipais causas deste problema (BORTOL...
29          A comunicação é incentivada com a utilização de um fórum de discussão(para dar apoio à comunicação offline) so...
30módulo específico para casos de uso para ser instalado no portal então havia duaspossibilidades a fazer: criar um módulo...
31            A arquitetura do XOOPS possui as seguintes características: linguagem PHPcom banco de dados MySql, voltado t...
323.4 Módulos do Sistema          O módulo de projeto, disponível em www.xoops.pr.gov.br , foi instalado porser essencial ...
33              Figura 7 - Tela do Módulo de Projeto para Cadastro do Casos de Uso                          Figura 8 – Tri...
34uma cor para este usuário e qualquer alteração que ele fizer no caso de uso seráautomaticamente salva com a cor definida...
35Figura 9 - Tela com o caso de uso “Emprestar Fita” cadastrado, como exemplo
36          Figura 10 – Trigger que cria um item sobre o caso de uso no fórum          A figura 11 apresenta a tela do fór...
37Figura 11 – Tela de diálogo sobre o caso de uso ”Emprestar Fita” no fórum
38          Um outro módulo instalado foi o de chat. Ele permite que os analistas queestejam on-line no portal em determin...
39tela de um e-mail como exemplo. Na parte inferior da figura, do lado esquerdo, podem-se observar os usuários on-line no ...
40                              Figura 14 – Módulo de Notícias3.5 Modelo de Dados          O modelo de dados do ERCOLAB é ...
41•   A tabela xoops_bbbex_forums é criada com a instalação do módulo de fórum    e foi editada para que obtivesse informa...
423.6 Avaliação da Ferramenta             Para realizar a avaliação da solução proposta neste projeto, foi desenvolvido   ...
43         O ERCOLAB possui uma limitação com relação ao browser utilizado. Ele secomportou perfeitamente quando foi utili...
44CONCLUSÃO            Neste trabalho foi apresentado um ambiente que irá auxiliar no levantamentoe elicitação de requisit...
45interatividade entre eles e a eficiência do trabalho como um todo. Neste projeto, acolaboração foi utilizada num sistema...
46REFERÊNCIASANTILLANCA, Hector; FULLER, David, [1996?]. Sistemas síncronicos cara-a-cara:requisitos, problemas y resultad...
47Internet: http://kuainasi.ciens.ucv.ve/ideas07/documentos/articulos_ideas/Articulo74.pdf.Acesso em 15/09/2007FUKS, Hugo....
48ROSA, Márcio. Groupware: um caminho para a cooperação. 2005. Disponível naInternet:   http://www.frb.br/ciente/2005.1/BS...
Upcoming SlideShare
Loading in …5
×

Projeto final rafael pimenta - adauto junior 2

1,192 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,192
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Projeto final rafael pimenta - adauto junior 2

  1. 1. RAFAEL PIMENTA TUVO JOSÉ ADAUTO OLIVEIRA DE MENEZES JUNIOR ERCOLABUm ambiente colaborativo para elicitação de requisitos baseado em casos de uso SALVADOR 2007
  2. 2. RAFAEL PIMENTA TUVO JOSÉ ADAUTO OLIVEIRA DE MENEZES JUNIOR ERCOLABUm ambiente colaborativo para elicitação de requisitos baseado em casos de uso Monografia apresentada por Rafael Pimenta Tuvo e José Adauto de Oliveira Junior como requisito parcial para aprovação na disciplina Projeto Final. Orientador: Profº Antonio Cláudio P. Neiva SALVADOR 2007
  3. 3. CERTIFICADOCertifico que a presente memória, ERCOLAB - Um ambiente colaborativo para auxiliar aelicitação de requisitos baseado em casos de uso, foi realizada sob minha direção porRAFAEL PIMENTA TUVO E JOSÉ ADAUTO OLIVEIRA DE MENEZES JUNIOR,constituindo o Projeto Final de Curso do Bacharelado em Informática da UniversidadeCatólica do Salvador - UCSal.Salvador, 30 de Dezembro de 2007.Antônio Cláudio NeivaCurso de Bacharelado em InformáticaUniversidade Católica do Salvador Salvador 30/12/2007
  4. 4. DEDICATÓRIA“Dedico este trabalho a minha mãe Yara Menezes Pimenta por todo o incentivo durantea empreitada e a minha namorada Luana por nunca me deixar desanimar”.(RafaelPimenta)“Dedico esse trabalho a minha mãe Maria da Glória Brito Sapucaia e a meu pai JoséAdauto Oliveira de Menezes, que sempre estiveram e estão presentes em toda a minhacaminhada, me orientando e fazendo com que eu me tornasse o homem que sou hoje,a minha namorada Ingrid Daiane, que mesmo nos momentos onde eu achava que nadairia dar certo, estava alí incentivando, me enchendo assim de garra para lutar, e aonovo amigo, Rafael Pimenta, que lutou a todos os instantes comigo em busca do nossocrescimento” . (Adauto Júnior)
  5. 5. AGRADECIMENTOS Agradecemos a Deus por mais esta etapa e esperamos que ainda nosaconteçam muitas outras. Agradecemos a todos os nossos amigos, sem exceção, que,direta ou indiretamente, de alguma forma, contribuíram para a construção desseprojeto. Aos colegas de trabalho que gastaram inúmeras horas a fim de nos ajudar comos problemas deste. Ao nosso orientador Cláudio Neiva que sempre nos incentivou eapontou o melhor caminho a ser tomado para conclusão deste projeto. Em especial,agradecemos a dona Glória, por suportar os dias e noites de incomodo durante aelaboração desse projeto e fazer de tudo para tornar o trabalho menos desgastante. Eaos que acharam que não daria certo, nos estimulando assim a superar mais estedesafio.
  6. 6. RESUMOSabe-se que um dos maiores problemas no desenvolvimento de software é a escolhaequivocada dos seus requisitos e também que a colaboração aumenta a comunicaçãoe a interação entre as pessoas. O objetivo deste trabalho é mostrar que a colaboraçãopode ser eficiente quando aplicada a ferramentas de levantamento de requisitos desoftware uma vez que aproxima os analistas minimizando assim a ocorrência de idéiascontroversas e estimula a discursão sobre o projeto. Para exemplificar, foi desenvolvidoo ERCOLAB, um ambiente onde é possível estabelecer a comunicação entre seusmembros de variadas formas, através de seus módulos, e definir colaborativamente oscasos de uso que irão compor o sistema, influenciado pelos conceitos de coordenação,cooperação e comunicação, base da colaboração.Palavras chaves: Engenharia de Software, colaboração, requisitos, casos de uso,comunicação
  7. 7. ABSTRACTA biggest problems in software development is the wrong choice of their requirements. Thetheory of collaboration increases the communication and interaction between people. Theobjective of this work is to show that cooperation can be effective when applied to tools ofSoftware Engineering since it brings together analysts thus minimizing the occurrence ofcontroversial ideas and encourages debate on the project. To illustrate, has developed theERCOLAB, an environment where it is possible to define collaboratively the use cases that willcompose the system, influenced by the concepts of coordination, cooperation andcommunication, the basis of cooperation.Keywords: Software Engineering, collaboration, requirements, use cases, communication
  8. 8. LISTA DE FIGURASFigura 1 – Diagrama do Modelo de Colaboração 3C .................................................14Figura 3 – Relação Memória do Grupo X Colaboração .............................................16Figura 4 – Exemplo de Diagrama de Casos de Uso ..................................................26Figura 5 – Diagrama de caso de uso do portal. .........................................................30Figura 6 - Tela de Gerenciamento dos Módulos do XOOPS.....................................31Figura 7 - Tela do Módulo de Projeto para Cadastro do Casos de Uso...................33Figura 8 – Trigger para criação da categoria .............................................................33Figura 9 - Tela com o caso de uso “Emprestar Fita” cadastrado, como exemplo .35Figura 11 – Tela de diálogo sobre o caso de uso ”Emprestar Fita” no fórum........37Figura 12 – Chat do Sistema .......................................................................................38Figura 13 – Exemplo de email utilizado no portal .....................................................39Figura 14 – Módulo de Notícias...................................................................................40Figura 15 – Modelo de Dados do Sistema..................................................................41Figura 16 – Tela de avaliação da contribuição do sistema.......................................42
  9. 9. LISTA DE ABREVIATURASAJAX - Asynchronous JavaScript and XMLCRC – Cooperative Requirements CaptureJAD – Joint Application DevelopmentPD – Participatory DesignPHP - Hypertext PreprocessorQFD – Quality Function DeploymentSQL – Structure Query LanguageUML – Unified Modeling LanguageXOOPS - eXtensible Object Oriented Portal System
  10. 10. SUMÁRIOINTRODUÇÃO ..........................................................................................112. FUNDAMENTAÇÃO TEÓRICA ............................................................13 2.1 Colaboração .....................................................................................13 2.1.1. Elementos da Colaboração ........................................................14 2.1.1.1 Comunicação ......................................................................14 2.1.1.2 Coordenação.......................................................................17 2.1.1.3 Cooperação..........................................................................18 2.2 Requisitos.........................................................................................18 2.2.1 Fase de Levantamento de Requisitos ........................................20 2.2.1.1 Problemas da Fase de Levantamento de Requisitos............20 2.3 Casos de Uso ...................................................................................22 2.3.1 Especificação de Casos de Uso .................................................22 2.3.2 Diagramas de Caso de Uso........................................................253. ERCOLAB.............................................................................................27 3.1 Identificação do Problema ................................................................27 3.2 Objetivo do Sistema .........................................................................28 3.3 Definição da linguagem e arquitetura do portal.................................29 3.4 Módulos do Sistema .........................................................................32 3.5 Modelo de Dados .............................................................................40 3.6 Avaliação da Ferramenta..................................................................42CONCLUSÃO ...........................................................................................44REFERÊNCIAS.........................................................................................46
  11. 11. 11INTRODUÇÃO A maneira de trabalhar da sociedade é revolucionada por tecnologia e dásuporte às formas de relacionamento humano. A criação de espaços compartilhados detrabalho propicia o trabalho colaborativo distribuído e descentralizado (FUKS, 2002). Entretanto, softwares colaborativos, chamados de groupware, só começarama surgir efetivamente em meados dos anos oitenta (ROSA, 2005). O desenvolvimento ea usabilidade de ferramentas colaborativas ainda são dificultados por sua ampladisciplinaridade. É custoso produzir um software que seja simples e tenha o dinamismonecessário à interação entre as várias áreas do conhecimento. O objetivo deste projeto é mostrar que a colaboração, quando aplicadaferramentas de levantamento de requisitos de software, pode aumentar a produtividadedo trabalho, uma vez que aproxima os analistas e aumenta a percepção do trabalhocomo um todo. Para dar suporte a esse objetivo, será desenvolvido um ambiente que,durante a produção de software, auxilie na especificação de casos de uso, de formacolaborativa, ou seja, que vários analistas de sistemas possam contribuir para ummesmo documento, fazendo um trabalho em conjunto. Portanto, será disponibilizadauma área de trabalho compartilhada para tal atividade, levando em consideração osprincípios da colaboração e da engenharia de software. O capítulo 2 desta monografia discorrerá sobre o conceito de colaboração eestruturas envolvidas em sistemas colaborativos, base para o entendimento do trabalhoem grupo. No capitulo 3, serão abordados os conceitos e as características dosrequisitos de software. Uma breve explanação sobre algumas fases do processo dedesenvolvimento de software também será encontrada.
  12. 12. 12 O capitulo 4 encerra a fundamentação teórica explicando o que são casos deuso e todas as características que os compõem. O capitulo 5 apresenta o projeto, falando da sua estrutura, seus módulos edescrevendo a colaboração dentro do ambiente proposto. A conclusão do projeto segue ao final, fazendo uma análise dos resultados.
  13. 13. 132. FUNDAMENTAÇÃO TEÓRICA2.1 Colaboração Como o aumento das demandas e do volume de trabalho nas organizaçõescresce a cada dia, a maneira de se trabalhar acabou por receber um novo foco. Otrabalhador sempre acostumado a tarefas vindas de cima para baixo na hierarquiapouco se comunicava e grande parte das suas tarefas era resolvida de forma individual(FUKS, 2002). Até meados dos anos oitenta, o auxilio informatizado para acomunicação e resolução de problemas envolvendo varias pessoas era reduzido(ROSA,2005). Em contrapartida, as pessoas da área de informação têm a facilidade detrabalhar em equipe e de evoluir juntamente com os procedimentos inerentes as suastarefas (FUKS, 2002). Existe a comunicação constante em busca de tudo que possaauxiliar na execução de suas atribuições. Muitas dessas envolvem outras áreas doconhecimento e grupos aparecem para discutir e solucionar os percalços que vãoaparecendo. A antiga idéia de individualidade das empresas se rende ao espírito deequipe e à realização de trabalhos em grupo a todo o momento. Em ambientes cooperativos podem-se produzir melhores resultados queindividualmente (FRANCO, 2003). Dessa forma, um membro pode suprir a falta dooutro, promovendo uma ajuda mútua e equilibrando o conhecimento. É possíveltambém o surgimento de idéias e vários caminhos para a solução dos diversosproblemas, discutindo e, em comum acordo, tomar a decisão mais apropriada a cadaum deles. Contudo, como sugere Fuks (2003), “colaborar demanda um esforçoadicional de coordenação dos seus membros”. A coordenação é necessária para quetoda essa cooperação entre os membros seja aproveitada com a maior eficiênciapossível. Todo grupo tem suas divergências e essa coordenação vem para tratá-las eadministrá-las de forma a atingir um bom nível de satisfação dentro da equipe.
  14. 14. 142.1.1. Elementos da Colaboração O modelo 3C para sistemas colaborativos, proposto em 1991 por (ELLISapud FUKS, 2004), baseia-se no tripé cooperação, comunicação e coordenação, sobreuma determinada percepção do problema, para em grupo chegar a uma solução. Odiagrama apresentado na figura 1 ilustra os três conceitos inter-relacionados: Figura 1 – Diagrama do Modelo de Colaboração 3C (GEROSA, 2005)2.1.1.1 Comunicação No processo de colaboração, não basta apenas que a mensagem sejaenviada pelo emissor e recebida pelo receptor, o mesmo entendimento por ambas aspartes é de grande importância. Uma distorção dela pode causar diferentesinterpretações, dificultando a soma dos seus esforços nas tarefas (FUKS ,2002). A forma mais comum de realizar a comunicação é face a face mas quandoisso não é possível outros canais de comunicação podem ser utilizados como bate-papos, e-mails, entre outros. Independente do método, o recebimento da mensagemestá sujeito ao canal de percepção que liga o emissor e o receptor (ROSA, 2005). Ellis et. al. (1991) propõe uma classificação para as formas de comunicaçãobaseados na taxonomia espaço-tempo, onde o espaço determina a localização físicados participantes (local ou distribuída) e o tempo determina o momento em que osparticipantes trabalham (síncrono ou assíncrono) e é, sem dúvida, a mais aceita entre
  15. 15. 15todas as classificações conhecidas. Exemplos de sistemas síncronos distribuídos sãoos editores multi-usuários de tempo real e teleconferências; de interação síncrona tem-se as ferramentas de revisão de documentos; de interação assíncrona distribuída,correio eletrônico, sistemas de workflow (ANTILLANCA ; FULLER, 1996). A figura 2apresenta a matriz Espaço x Tempo proposta: Figura 2 – Matriz Espaço X Tempo (ANTILLANCA, 2006?) Marcio Rosa (2005) afirma em seu trabalho que existe uma forte ligaçãoentre o conhecimento formal e informal gerados durante a interação dos membros dogrupo, onde artefatos são produzidos e informações são geradas durante a interação(idéias surgidas, mensagens trocadas, pontos de vista defendidos, etc) sendo queambos são importantes para a construção da memória do grupo. A falta de umamemória do grupo freqüentemente leva a reuniões e discursões sobre temas jáabordados, caracterizando assim uma baixa produtividade. “Os membros do grupoalcançam o conhecimento compartilhado com o auxilio dos conhecimentosarmazenados na memória do grupo.” (DIAS apud ROSA, 2005). A figura 3 mostra as relações entre a memória do grupo e os elementos dacolaboração.
  16. 16. 16 Figura 3 – Relação Memória do Grupo X Colaboração (ARAUJO apud ROSA , 2005) Com a comunicação, compromissos são gerados ( WINOGRAD ; FLORESapud FUKS , 2002) e é preciso uma coordenação para que eles sejam realizados etambém para que haja a união dos trabalhos individuais de cada um. Tal coordenaçãogarante a excelência nos prazos estabelecidos, mantém o foco no objetivo e evitadesperdício de empenho durante os trabalhos (FUKS,2002). É necessário citar sobre a importância da percepção em trabalhoscolaborativos. A percepção pode ser conceituada como “ter conhecimento, ter ciênciadas atividades do grupo, das atividades que influenciarão no trabalho como um todo“,(PINHEIRO, 2000). Ela se refere tanto a identificação e localização dos outros membrosde um sistema colaborativo quanto ao que compete a eles, que atividades eles estãorealizando e já realizaram anteriormente. Sem ela, os membros do grupo não sabemem que contexto estão atuando, dificultando a visão de como suas atividadesindividuais podem ser unidas aos outros resultados do resto do grupo. A percepção éum ato individual sendo que uma mesma informação pode ser percebida de formadiferente pelos vários membros do grupo (ROSA, 2005).
  17. 17. 172.1.1.2 Coordenação Segundo Karl Marx, “Colaboração são múltiplos indivíduos trabalhandojuntos de maneira planejada no mesmo processo de produção ou processos deprodução diferentes mas conectados” (citado em (FUKS, 2002)). Coordenar é, antes detudo, planejar. Fazer o planejamento da delegação de tarefas é uma ação importantena coordenação, evitando assim que membros realizem tarefas redundantes ouconflitantes entre si. Mas, além disso, a coordenação passa também pelo gerenciamento durantea execução das tarefas e pela documentação dos trabalhos após elas terminarem. Oplanejamento é a preparação da colaboração, é a identificação dos objetivos, definiçãodas tarefas focando nesse objetivo, escolha dos membros e de suas respectivasatividades, etc... Ao final, tem-se a análise, avaliação e documentação das mesmas,detalhando o processo desde o inicio. Entretanto a parte fundamental é mesmo ogerenciamento das ações. O ambiente vai sendo alterado e as ações precisamacompanhar essas mudanças, tornando essa fase extremamente dinâmica etrabalhosa, exigindo comunicação e cooperação a todo tempo para sua eficiência,novamente explanado por Fuks (2002). Em alguns casos, os próprios participantes se encarregam de coordenar, oumelhor, não há uma coordenação explícita para administrar as tarefas, simplesmenteporque as características delas não exigem uma, por exemplo, um chat. O ditoprotocolo social e a habilidade dos participantes se encarregam da moderação dastarefas mas isso é definido pelo desenvolvedor do sistema. Já em outros casos, sãonecessários robustos mecanismos de coordenação. Sistemas de fluxo de trabalho sãobons exemplos (FUKS ; GEROSA, 2002).
  18. 18. 18 Como os participantes colaboram a todo tempo, idéias antagônicas podem edevem acabar ocorrendo nos trabalhos em grupo. A coordenação deve tratar esses etodos os outros tipos de conflito que por ventura ocorram, por exemplo, demasiadacompetição entre os componentes, definição exata do que compete a quem, etc (FUKS;GEROSA, 2002).2.1.1.3 Cooperação Cooperação é a operação conjunta dos membros do grupo no espaçocompartilhado visando a realização das tarefas gerenciadas pela coordenação (FUKS,H., et al, 2002). Cooperação é se ajudar mutuamente, trocar idéias, organizar opensamento, discutir e produzir em grupo um documento com o auxilio da coordenaçãoe da comunicação. Todo tipo de cooperação em um sistema deve ser arquivado de algumaforma. Assim, ao final do trabalho colaborativo existe um catálogo com tudo o que foifeito, discutido e decidido. “O registro da informação visa aumentar o entendimentoentre as pessoas, reduzindo a incerteza (relacionada com a ausência de informação) ea equivocidade (relacionada com a ambigüidade e com a existência de informaçõesconflitantes)” (DAFT ; LENGEL, 1986). Essa forma de registro pode ser útil caso essetrabalho sirva de base para um outro, caso alguma coisa dê errado posteriormente ouaconteça algum reconhecimento pelo que foi realizado.2.2 Requisitos A complexidade dos problemas que os engenheiros de software tem quesolucionar, muitas vezes, é muito grande. É complicado estabelecer com precisão tudoque um sistema deve fazer. Chama-se de requisito a descrição das funções e asrestrições que um sistema terá; já todo o trabalho em cima dele (levantamento, análise,documentação e verificação) chama-se de engenharia de requisitos (SOMMERVILLE,2003).
  19. 19. 19 Zanlorenci e Burnett (2001), Sommerville, entre outros autores, dividem osrequisitos em funcionais e não funcionais. Funcionais: São declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas especificas e como deve se comportar em determinadas situações. Não Funcionais: São as restrições sobre os serviços ou as funções do sistema. Sommerville (2003). Exemplos de limitações não funcionais são valores para tempo de resposta,espaço em disco, entre outros. Segundo (THAYER apud BELGAMO, 2000), as fases da Engenharia deRequisitos são: elicitação, análise, especificação, verificação e gerenciamento. Aelicitação é o processo através do qual clientes e usuários são questionados por umdesenvolvedor para falarem “o quê” o software deve fazer (ou seja, os requisitos). Aanálise é o processo onde são analisadas as necessidades dos clientes e usuários parase chegar na definição dos requisitos de software. A especificação é o processo decriação de um documento no qual estão definidos todos os requisitos analisados. Averificação é o processo que busca assegurar que a especificação de requisitos desoftware está em concordância com os requisitos elicitados e analisados nas fasesanteriores, ou seja, estão de acordo com o desejo do cliente. O gerenciamento: é oplanejamento e controle da atividade de elicitação, especificação, análise e verificaçãodos requisitos. Na verdade, antes da elicitação existe ainda uma breve fase chamadaEstudo de Viabilidade. Para Sommerville (2003), ela consiste num rápido e objetivoestudo procurando responder a questões como: o sistema colabora para os objetivosda organização? Mesmo com as restrições de prazo e custos o sistema poderá serimplementado com tecnologia recente? Poderá ele ser integrado com outros sistemas jáimplantados na empresa? Assim um relatório é gerado e os resultados apontam serealmente vale a pena começar o processo de desenvolvimento do sistema.
  20. 20. 202.2.1 Fase de Levantamento de Requisitos Na fase de levantamento de requisitos, os analistas de sistemas trabalhamjunto aos usuários que terão, de alguma forma, influência sobre o sistema(stakeholders), a fim de definir o domínio da aplicação, qual a performance exigida pelosistema, que interfaces serão necessárias, restrições legais, de hardware, etc..., sugereSomerville. “O levantamento de requisitos é uma fase que compreende o período em que o engenheiro de requisitos procura entender o problema e a necessidade do usuário. Esta é uma atividade multidisciplinar, pois lida com aspectos sociais e humanos de forma tão intensa quanto com os aspectos técnicos” (FREITAS, Danilo, 2007). Ainda segundo Sommerville, a descoberta tardia de falhas no documento derequisitos pode levar a enormes custos relacionados ao retrabalho para corrigi-las,quando a fase de desenvolvimento já está em andamento ou quando o sistema já estáem operação. O custo de se reparar um erro e alterar o sistema, proveniente de umequívoco de requisitos, é muito maior do que erros de projeto e implementação.Estudos realizados por BOEHM (apud CYSNEIROS , 2001) indicam que, após osistema implementado, as despesas com erros em requisitos de software chegam a ser20 vezes maiores que qualquer outro erro em outra fase. Isso porque o projeto e aimplementação do sistema devem ser redesenhados e os testes novamente realizados.Por este motivo é importante executar de maneira criteriosa essa atividade.2.2.1.1 Problemas da Fase de Levantamento de Requisitos Christel e Kang (1992) descrevem 3 grupos para classificar problemas nafase de levantamento de requisitos: • Problemas de Escopo: Quando as fronteiras do sistema ainda não estão bem definidas, os requisitos podem fornecer muita ou pouca informação. Pode acontecer também de haver perda do foco do sistema com informações desnecessárias, mais profundas e técnicas que o exigido em tal momento.
  21. 21. 21 • Problemas de Compreensão: Os próprios usuários do sistema muitas vezes não sabem do que precisam. Existem usuários de várias áreas e formações, ou seja, muitos pontos de vista diferentes. Até mesmo entre o analista e os usuários existe esse desentendimento, havendo assim requisitos conflitantes, ambíguos e instáveis. • Problemas de Volatilidade: Os requisitos mudam muito do inicio ao fim do projeto. E essas mudanças são necessárias para não tornar partes do sistema obsoletas, incompletas ou até inúteis. A cada mudança suas conseqüências precisam ser avaliadas. Além dessas 3 classificações ainda existem mais 2 grandes blocos deproblemas (FAULK apud FREITAS, 2007): • Problemas Acidentais: São aqueles provenientes da falta de organização e planejamento sobre o que precisa ser construído. Por exemplo, pouca dedicação na coleta de informações dos usuários, descrição superficial dos requisitos obtidos e pressa para o início da fase de implementação (MARTINS apud FREITAS , 2007). • Problemas Essenciais: São aqueles inerentes à elicitação de requisitos. Por exemplo, a dificuldade de comunicação entre os analistas e os usuários e a mudanças constantes dos requisitos (MARTINS apud FREITAS, 2007). Percebe-se que os problemas acidentais podem ser evitados aplicandocorretamente as fases da engenharia de requisitos. Visando minimizar e até eliminar os impactos dos problemas nesta fase,algumas técnicas para elicitação de requisitos foram difundidas e abordadas porBelgamo: Observação, Entrevista, Análise de Protocolo, JAD (Joint ApplicationDevelopment), PD (Participatory Design), QFD (Quality Function Deployment), CRC(Cooperative Requirements Capture), Prototipação, Cenários.
  22. 22. 222.3 Casos de Uso Os casos de uso foram propostos inicialmente pelo cientista da computaçãosueco Ivar Hjalmar Jacobson em sua metodologia de desenvolvimento de sistemasorientados a objetos, e ele define caso de uso como sendo uma “descrição de umconjunto de seqüências de ações, inclusive variantes, que um sistema executa paraproduzir um resultado de valor observável por um ator” [BOOCH, 2000]. Posteriormenteeles foram incorporados a UML (Unified Modeling Language) onde seu uso se tornouextremamente freqüente na identificação dos requisitos de sistema. Os objetivos dos casos de uso são decidir e descrever os requisitosfuncionais do sistema, apresentar com clareza e consistência o que o sistema irá fazere permitir descobrir os requisitos funcionais das classes e operações do sistema,sugere Macoratti (2004). É importante enfatizar que os casos de uso irão descrever ocomportamento do sistema e não como ele será construído.2.3.1 Especificação de Casos de Uso Um dos componentes dos casos de uso são os atores. Um ator representa afigura de um ser humano, de algum dispositivo de hardware ou de algum outro sistemaque interaja com o sistema. Embora se utilize dos atores para compor a modelagem,eles não fazem parte, de fato, do sistema. São agentes externos a ele. (BOOCH;RUMBAUGH; JACOBSON, 2000). Exemplos de atores são clientes, usuários,computadores, impressoras, entre outros. É importante também entender o que é o fluxo de eventos dos casos de uso.A descrição dos casos de uso precisa ser suficientemente clara para que alguém defora do desenvolvimento do sistema possa compreendê-lo. É fundamental a separaçãoentre a visão externa e interna da construção do sistema. O fluxo de eventos deveincluir quando e como o caso de uso inicia e termina, como se dá a interação com os
  23. 23. 23atores e definir qual o fluxo principal e os possíveis fluxos alternativos docomportamento (BOOCH; RUMBAUGH ; JACOBSON , 2000). Booch, Rumbaugh e Jacobson (2000), propõem o exemplo a seguir,adaptado, no contexto de um caixa eletrônico, para apresentar o que são os fluxos deeventos básicos e fluxos alternativos a ele: 1. Fluxo de Eventos Principal: O caso de uso inicia quando o sistema pede ao cliente seu número de identificação pessoal, o PIN. O cliente pode, neste momento, digitar o PIN através do teclado do caixa. Após digitá-la, o cliente confirma a entrada apertando o botão Enter no teclado. O sistema então verifica a validade do PIN do cliente. Caso seja válido, o sistema permite acesso ao sistema, finalizando o caso de uso. 2. Fluxo de Eventos Alternativo: Se o cliente entrar com o número PIN inválido, o caso de uso é reiniciado. Se isso ocorrer 3 vezes seguidas, a transação é cancelada e o cliente tem seu acesso ao sistema bloqueado por 1 minuto. 3. Fluxo de Eventos Alternativo: O cliente pode cancelar a transação a qualquer momento pressionando a tecla Cancelar, reiniciando o caso de uso. Para cada uma dessas variações do fluxo de eventos é dado o nome decenário. Segundo Furlan (1998), um cenário é “uma narrativa de uma parte docomportamento global do sistema” e uma coleção completa de cenários é usada paraespecificar completamente o sistema. Furlan faz a seguinte analogia para evidenciar taldependência: ”os cenários estão para os casos de uso assim como as instancias estãopara as classes”. O simples exemplo de um caso de uso (adaptado) “Comprar refrigerante”(BLAHA, 2006), a seguir, explica como agrupar comportamentos normais e anormais
  24. 24. 24num único caso de uso pode ajudar a garantir que todos os possíveis cenários sejamtrabalhados em conjunto: Caso de Uso: Comprar refrigerante Resumo: O cliente recebe da máquina de venda um refrigerante após o cliente pagar e escolher qual refrigerante deseja. Atores: Cliente Precondições: A máquina está esperando que o dinheiro seja inserido Descrição: O estado de espera da máquina é iniciado e a mensagem “Insira moedas” é mostrada no visor da máquina. Um cliente insere moedas na máquina. A máquina mostra o valor inserido e acende no painel quais são os produtos que podem ser comprados com aquele valor. O cliente aperta um dos botões, escolhendo seu pedido. A máquina libera o produto escolhido e, se o valor inserido for maior que o valor do produto, devolve o troco ao cliente. Exceções: 1. Cancelado: Se o botão de cancelamento for apertado antes do item ser escolhido a máquina devolve o dinheiro ao cliente e reinicia o estado de espera. 2. Em falta: Se o produto que o cliente escolheu estiver em falta, a mensagem “Este item está em falta” é mostrada no visor. A máquina continua a aceitar moedas e aceitar outra escolha do cliente. 3. Quantia insuficiente: Se o item escolhido for mais caro do que o valor inserido pelo cliente, a mensagem “Você precisa de mais R$ XX para comprar este item”, onde XX é a quantidade de dinheiro que falta para a compra do produto. A máquina continua a aceitar moedas e aceitar outra escolha do cliente. 4. Não há troco: Se o cliente inseriu uma quantidade suficiente de moedas para comprar o produto mas a máquina não tem o troco necessário a mensagem “Não há troco suficiente” é mostrada no visor.
  25. 25. 25 A máquina continua a aceitar moedas e aceitar outra escolha do cliente. Pós-condições: A máquina está esperando que o dinheiro seja inserido.2.3.2 Diagramas de Caso de Uso A UML possui uma representação gráfica para os casos de uso e o exemploda figura 4 ilustra essa representação. Os diagramas de casos de uso são um doscinco diagramas disponíveis na UML para modelagem de aspectos dinâmicos desistemas. Eles mostram o conjunto de casos de uso, os atores e seus relacionamentos(os outros diagramas são o de atividades, de gráficos de estados, de sequências e decolaboração). “Os diagramas de casos de uso são importantes para visualizar, especificar edocumentar o comportamento de um elemento”, (BOOCH; RUMBAUGH ; JACOBSON ,2000). Eles tornam os sistemas e subsistemas acessíveis e compreensíveis porpermitirem uma visão externa de como esses elementos podem ser utilizados nocontexto. Entretanto, é importante salientar também que os diagramas não sãoestritamente necessários para o andamento do projeto. Os casos de uso são representados pelos nomes dentro das elipses. Umretângulo engloba os casos de uso para um sistema que irá interagir com os atoreslistados na parte externa, representados pelos bonecos com o nome do ator abaixo ouadjacentes ao boneco. O nome do sistema pode acompanhar o retângulo que orepresenta. As linhas conectam os atores aos casos de uso.
  26. 26. 26Figura 4 – Exemplo de Diagrama de Casos de Uso
  27. 27. 273. ERCOLAB O projeto consiste em desenvolver um ambiente que auxilie aos analistas desistemas durante as fases de levantamento e elicitação de requisitos em um projeto desoftware com o auxilio de módulos colaborativos que irão estabelecer a comunicação ea percepção entre os membros que o utilizam focando no desenvolvimento dos casosde uso. O ERCOLAB é baseado no XOOPS (eXtensible Object Oriented PortalSystem), um sistema para criação de sites dinâmicos, distribuído em código aberto, edesenvolvido na linguagem PHP (Hypertext Preprocessor) orientada a objetos,utilizando banco de dados MySql. O XOOPS foi escolhido pela facilidade deimplementação, instalação, manutenção e manipulação dos seus componentes. Todos os módulos utilizados no ambiente são componentes independentese mas sofreram alterações em sua implementação para que atendessem ascaracterísticas desejadas. Com isso eles passaram a “conversar” entre si, dando maisdinamismo e interatividade dentro do ERCOLAB.3.1 Identificação do Problema Um dos grandes problemas hoje nas empresas de software é oestabelecimento correto dos requisitos que devem ser atendidos num software a serdesenvolvido. Um documento de requisitos mal elaborado pode comprometer os prazose custos de desenvolvimento do produto de software, como dito anteriormente. Os requisitos são expressos na forma de casos de uso na grande maioriados sistemas. Ao fim do processo de levantamento, o software é desenvolvidofundamentado no documento de casos de uso gerado, sendo ele a base para aconstrução do sistema.
  28. 28. 28 A dificuldade de comunicação entre os envolvidos no processo é uma dasprincipais causas deste problema (BORTOLI ; PRICE, 2000), fazendo com que osrequisitos necessários sejam mal interpretados ou passem despercebidos econseqüentemente trazendo insatisfação ao usuário com o produto recebido por nãoatender suas exigências e necessidades reais. Para minimizar este problema, foi idealizado um ambiente comum aos osanalistas de sistemas que aumentasse a interação e permitisse a participaçãocolaborativa entre eles e assim construíssem, juntos, um mesmo documento derequisitos. Como ele proporcionará o debate e a discursão entre os membros, estedocumento estará menos sujeito a problemas de interpretação.3.2 Objetivo do Projeto O objetivo do projeto é fornecer um ambiente de trabalho aos analistas desistemas onde eles possam interagir e cooperar entre si para definir os casos de usoque irão compor o sistema. O ERCOLAB deverá permitir o registro dos casos de uso eagilizar o processo de elicitação deles, uma vez que o ambiente é o mesmo para todosos analistas e toda a equipe tem acesso aos dados registrados podendo assimcompartilhar conhecimento. Uma área compartilhada de trabalho a todos os analistas cria umaproximidade entre os membros desta equipe, onde todos podem visualizar como vai aevolução dos trabalhos de uma maneira geral. Aplica-se assim o conceito depercepção, discutido no capitulo 2, onde a equipe tem ciência do andamento do projetocomo um todo, inclusive discutindo e participando dos vários aspectos dele. A coordenação está inserida no ambiente no momento em que quem definequais casos de uso irão definitivamente compor o documento de requisitos é ocoordenador projeto, definido pelo administrador do sistema. É ele também que delegaas permissões e autoriza o acesso dos analistas ao portal.
  29. 29. 29 A comunicação é incentivada com a utilização de um fórum de discussão(para dar apoio à comunicação offline) sobre dúvidas e sugestões no desenrolar daprodução dos casos de uso e um chat para que os analistas on-line durante o processopossam interagir e dar mais dinamismo e rapidez ao trabalho, além de uma caixa demensagens para cada membro do portal. Todos os registros desses componentes irãocompor a memória do projeto. Sendo assim, o ERCOLAB se propõe a dar um suporte necessário aosanalistas para que, de variadas formas, possam se relacionar durante o processo dedesenvolvimento de software (mais especificamente, das fases de levantamento eelicitação de requisitos) e definir qual o melhor documento de requisitos parafundamentar o sistema.3.3 Definição da linguagem e arquitetura do portal Como citado anteriormente, o PHP foi escolhido como linguagem paradesenvolvimento do portal. Esta linguagem possui grande compatibilidade com o bancode dados MySql. Ambas são ferramentas open source, o que ajudou bastante nadifusão do seu uso em conjunto. Durante o desenvolvimento do ERCOLAB foi utilizada a ferramentaphpMyAdmin para manipulação da base de dados MySql. Também de código aberto,ela permite uma administração do banco MySql através de uma interface web. A partirdela é possível criar, alterar e excluir tabelas do banco de dados, adicionar, remover eeditar campos das tabelas, executar códigos SQL e manipular campos chaves. O XOOPS é um modelo de portal e pode ser utilizado nas várias áreas doconhecimento, portanto a personalização dele cabe ao desenvolvedor de acordo comas necessidades do negócio. Durante a pesquisa deste projeto, não foi encontrado um
  30. 30. 30módulo específico para casos de uso para ser instalado no portal então havia duaspossibilidades a fazer: criar um módulo para tal ou alterar um módulo existente eadaptar ao sistema. A segunda alternativa foi escolhida, já que seria a mais simples dese trabalhar e traria o resultado esperado no que se propõe o projeto. A figura 5 apresenta o diagrama de casos de uso do sistema. Nele podem-sevisualizar as relações entre os requisitos funcionais do portal bem como os atores quetrabalharão nele. System Manter Módulos Criar Notícia Adminstrador do Sistema Manter Coordenador Autorizar acesso Coordenador de Equipe Definir Permissões Criar Projeto Solicitar acesso <<extend>> Participar do chat <<extend>> Analista de Sistemas Utilizar Caixa de Emails <<include>> Manter Caso de Uso Criar Fórum Figura 5 – Diagrama de caso de uso do portal.
  31. 31. 31 A arquitetura do XOOPS possui as seguintes características: linguagem PHPcom banco de dados MySql, voltado também para implementação de portaiscoorporativos, seus componentes (módulos) podem ser instalados e desinstalados eativados e desativados de forma extremamente simples. Nele ainda podem-sepersonalizar os perfis dos usuários e os temas e a possibilidade de troca de mensagensdiretamente entre os usuários (existe uma caixa de entrada para cada um). Por essesmotivos ele foi escolhido como base para a implementação do sistema. A figura 6apresenta a tela de gerenciamento dos módulos do XOOPS: Figura 6 - Tela de Gerenciamento dos Módulos do XOOPS É importante salientar que todos os módulos instalados são independentesentre si, porém foi necessário que os módulos tivessem uma comunicação para facilitaro trabalho dos analistas. Todos os vínculos entre eles foram feitos via triggers no bancode dados.
  32. 32. 323.4 Módulos do Sistema O módulo de projeto, disponível em www.xoops.pr.gov.br , foi instalado porser essencial ao sistema aqui proposto. Nele é possível criar um projeto descrevendoseu nome, descrição, suas datas de início e fim e definir quem serão os membroscadastrados que terão acesso ao projeto. Havia uma funcionalidade chamada “Criar Tarefa” onde era possível, como opróprio nome sugere, criar uma nova tarefa para determinado projeto. Essa opção foialterada para “Criar Caso de Uso”, onde os membros que possuem tal permissãopodem criar casos de uso para o projeto. Sua implementação foi alterada para quefosse possível cadastrar os casos de uso com todos os seus campos (Nome,Descrição, Atores, Fluxo Básico de Eventos, Pré-Condições, Pós-Condições,Exceções). É possível ainda definir o esforço, em horas, que será designado para otérmino do caso de uso. Neste módulo de projeto, ao criar um novo projeto, é disparadauma trigger que cria uma categoria na tabela do módulo de fórum. A figura 7 apresentao módulo de projeto já alterado para o cadastro dos casos de uso e a figura 8 a triggerimplementada para a criação da categoria.
  33. 33. 33 Figura 7 - Tela do Módulo de Projeto para Cadastro do Casos de Uso Figura 8 – Trigger para criação da categoria Ao escolher a opção “Editar” (Figura 9), será disponibilizada para o analista atela de edição do caso de uso em que se está trabalhando. Neste momento, é arbitrada
  34. 34. 34uma cor para este usuário e qualquer alteração que ele fizer no caso de uso seráautomaticamente salva com a cor definida para o analista. Se em uma próxima sessão,um outro analista desejar editar o caso de uso, uma cor diferente será atribuída a ele esuas alterações também terão a respectiva cor. Dessa forma, qualquer pessoa quevisualize o caso de uso irá perceber que ele foi composto por analistas diferentes. Naparte inferior da tela existirá uma legenda indicando o analista e sua respectiva cor.Existe um controle onde apenas um analista poderá editar um determinado caso de usopor vez. Caso um segundo analista tente editar o caso de uso no mesmo momento emque outro o esteja fazendo, uma mensagem será exibida negando o acesso. A figura 9mostra essa tela de edição com as cores e a legenda identificando os analistas. Pode-se perceber na figura 9 as opções “Visualizar”, “Editar” e “Histórico”. OAjax1 (Asynchronous JavaScript and XML) foi utilizado para abrir as páginas com essasopções sem a necessidade de carregar todo o conteúdo da página, dando assim maisdinamismo e rapidez em sua utilização. Ainda no módulo de projeto, ao clicar em “Criar Caso de Uso” uma outratrigger é disparada, adicionando na categoria do fórum anteriormente criada um itemcom o nome do caso de uso, onde é possível a todos os analistas discutir sobre o casode uso. Esse vínculo automático com o fórum, e a discursão dentro dele, geramregistros que podem servir posteriormente para compor a memória do projeto, sendopossível, por exemplo, verificar quem fez qual alteração e por que. A figura 10apresenta a trigger usada:1 Técnica utilizada pelos browsers para fazer pedidos ao servidor sem ter que recarregar toda a página
  35. 35. 35Figura 9 - Tela com o caso de uso “Emprestar Fita” cadastrado, como exemplo
  36. 36. 36 Figura 10 – Trigger que cria um item sobre o caso de uso no fórum A figura 11 apresenta a tela do fórum onde foi criado um item para discussãosobre um caso de uso “Emprestar Fita”, um exemplo para a ilustração.
  37. 37. 37Figura 11 – Tela de diálogo sobre o caso de uso ”Emprestar Fita” no fórum
  38. 38. 38 Um outro módulo instalado foi o de chat. Ele permite que os analistas queestejam on-line no portal em determinado momento possam conversar e trocar idéiassobre o projeto. Assim como o fórum, o chat foi customizado para que esteja vinculadoespecificamente a um projeto. Assim, toda a conversa que aconteça no chat serátambém um registro a ser salvo e utilizado quando necessário. É também um suporte acomunicação síncrona do sistema. A figura 12 mostra a tela do chat. Figura 12 – Chat do Sistema Outra funcionalidade do ERCOLAB é a troca de e-mails entre os usuários.Ela não é um módulo instalado como os demais e sim uma estrutura do próprio XOOPSque serve para estabelecer a comunicação entre os membros. A figura 13 apresenta a
  39. 39. 39tela de um e-mail como exemplo. Na parte inferior da figura, do lado esquerdo, podem-se observar os usuários on-line no portal no momento, com seus nomes logo abaixo.Ao clicar em um dos usuários dessa lista, abre-se a tela para envio de e-mail aomesmo. Figura 13 – Exemplo de email utilizado no portal Há ainda um módulo de notícias que exibe a todos os membros do portalmensagens e notificações da empresa. Apenas os coordenadores poderão criarnotícias e enviá-las. Elas podem ser enviadas a determinados grupos de analistas enão necessariamente a todos os membros. A figura 14 mostra o funcionamento domódulo de notícias.
  40. 40. 40 Figura 14 – Módulo de Notícias3.5 Modelo de Dados O modelo de dados do ERCOLAB é apresentado de acordo com a figura 15.O modelo de dados completo contém 57 tabelas, isso porquê a estrutura do XOOPS jávem com diversas tabelas, além das que são criadas com a instalação dos módulos ecom as adicionais, caso sejam necessárias. Neste modelo, são apresentadas 19tabelas que são mais importantes para ilustrar a estrutura do projeto e o relacionamentoentre os módulos do sistema. Estas tabelas suportam as principais funcionalidades dosistema, como, por exemplo: • A tabela xoops_ws_use_case foi criada para armazenar todas as informações do template de casos de uso. Nela estão presentes os campos use_case_id, task_id e project_id, que compõem a chaves da tabela, sendo que use_case_id é a chave primaria e as duas últimas chaves estrangeiras, além de outros atributos abstraídos da figura.
  41. 41. 41• A tabela xoops_bbbex_forums é criada com a instalação do módulo de fórum e foi editada para que obtivesse informações do caso de uso e da categoria a que está associado. A chave primária é composta pelo campo forum_id e as chaves estrangeiras pelos campos cat_id e task_id, além de outros atributos abstraídos da figura. A inserção nessa tabela é baseada na criação dos casos de uso, isto é, cada vez que um analista cria um caso de uso é inserido um registro, vinculando assim os fóruns aos casos de uso. Figura 15 – Modelo de Dados do Sistema
  42. 42. 423.6 Avaliação da Ferramenta Para realizar a avaliação da solução proposta neste projeto, foi desenvolvido um ambiente que possibilita o trabalho colaborativo durante a definição dos casos de uso em um projeto de software. Sua implementação procurou minimizar as principais deficiências encontradas em ferramentas colaborativas, como aponta a pesquisa feita recentemente por uma firma de consultoria especializada em ferramentas colaborativas2, a Avanade, como, por exemplo, a falta de integração entre as aplicações colaborativas, que frustra os usuários finais. Outra deficiência apontada foi a dificuldade de mensuração das contribuições num ambiente colaborativo em números concretos. O ERCOLAB procura fazer essa quantificação, ainda que de forma bastante simples, como mostra a figura 16. É uma mensuração quantitativa da colaboração a partir das contribuições no fórum do ERCOLAB, mas não qualitativa que seria o ideal. Figura 16 – Tela de avaliação da contribuição do sistema2 http://cio.uol.com.br/gestao/2007/10/10/idgnoticia.2007-10-10.9894265708/
  43. 43. 43 O ERCOLAB possui uma limitação com relação ao browser utilizado. Ele secomportou perfeitamente quando foi utilizado o Mozilla Firefox versão 2.0, porémquando utilizado com o Microsoft Internet Explorer versão 7.0 ocorre um problema coma atribuição das cores, usada no módulo de projeto. Caso um segundo analista tenteinserir um texto em meio a um outro já criado por outro analista, o Internet Explorer 7altera toda a cor do texto já existente para a nova cor do analista atual que estáeditando o caso de uso, dando uma falsa impressão de que todo o texto foi criado porele.
  44. 44. 44CONCLUSÃO Neste trabalho foi apresentado um ambiente que irá auxiliar no levantamentoe elicitação de requisitos durante o processo de produção de software. Para tanto aferramenta permite a especificação de casos de uso através da Colaboração(Coordenação, Comunicação e Cooperação) entre os analistas de sistemas envolvidosnum dado projeto. Desta forma os mesmos podem interagir durante o processo,aumentando a produtividade e a qualidade das informações geradas e obtidas. O portal foi desenvolvido sobre o XOOPS, um modelo de portal, onde sãoimplantados módulos que irão compor a ferramenta, dando suporte a interação online eoffline aos analistas. No processo de desenvolvimento do portal foram customizados os módulosde fórum, chat, notícias e projeto para que fosse possível a cooperação entre seususuários. Foi implementado, no módulo de projeto, um template para que os analistaspossam especificar casos de uso durante a construção de um produto de software. Acolaboração pode ser explicitada através do portal à medida que é possível visualizarquem fez e quando foi feita cada alteração nos casos de uso, pois esse histórico éarmazenado e sua exibição utiliza cores para diferenciar as contribuições de cadaanalista. Dentre os problemas enfrentados durante a construção deste projeto, pode-se destacar a falta de interação entre os módulos. Não havia relação entre eles, poissão componentes independentes. Desta forma, foi necessário alterá-los para que aessa comunicação acontecesse, fazendo com que trabalhassem em conjunto paraauxiliar o trabalho dos analistas. O histórico em cores também foi um desafio a sersuperado, tomando grande parte do tempo de desenvolvimento. Conclui-se que a colaboração pode ser muito útil quando aplicada a umprojeto de software. Ela elimina as fronteiras entre os analistas, aumentando a
  45. 45. 45interatividade entre eles e a eficiência do trabalho como um todo. Neste projeto, acolaboração foi utilizada num sistema de auxilio à elicitação de requisitos, incentivandoa comunicação e a cooperação entre os analistas para elaborar os casos de uso de umprojeto de software. Como projetos futuros, pode-se implementar uma área que possibilite acriação, de forma colaborativa, de diagramas da UML (de casos de uso, de atividades,de gráficos de estados, de seqüências e de colaboração). O suporte a voz e imagemtambém seria um importante acréscimo ao portal, tornando mais versátil acomunicação. Uma área onde os stakeholders pudessem também debater sobre osistema poderia minimizar o problema da má interpretação dos requisitos.
  46. 46. 46REFERÊNCIASANTILLANCA, Hector; FULLER, David, [1996?]. Sistemas síncronicos cara-a-cara:requisitos, problemas y resultados. Disponível na Internet:www.diinf.usach.cl/ArchivosSubidos%5C17620041627143erECHC%2095%20HAE.pdf.BELGAMO, Anderson. Estudo Comparativo Sobre as Técnicas de Elicitação deRequisitos de Software. Artigo. 2000. Disponível na Internet:http://www.niee.ufrgs.br/SBC2000/eventos/ctic/ctic002.pdf. Acesso em 15/09/2007.BLAHA, Michael; RUMBAUGH, James. Modelagem e Projetos Baseados em Objetoscom UML 2. Tradução: Daniel Vieira. Rio de Janeiro. Editora Elsevier. 2006.BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML - Guia do Usuário.Tradução: Fabio Freitas da Silva. Rio de Janeiro. Editora Campus. 2000.BORGES, Marcos. R. S.; PINO, José A.; SALGADO, Ana C. 2000. Requirements forShared Memory in CSCW Applications. 10th Anual Workshop on InformationTechnologies and Systems. Australia. Disponível na Internet:http://equipe.nce.ufrj.br/mborges/publicacoes/DBSCW%20COOPIS.doc.BORTOLI, Lis Ângela de; E PRICE, Ana Maria de Alencar. O uso de workflow paraapoiar a elicitação de requisitos. 2000. Universidade Federal do Rio Grande do Sul.CHRISTEL, M. G.; KANG, K. C. Issues in Requirements Elicitation, TechnicalReport Software Engineering Institute. 1992. Disponível na Internet:http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf. Acesso em28/09/2007.CYSNEIROS, Luiz Marcio. Requisitos Não Funcionais: Da Elicitação ao ModeloConceitual. 2001. Disponível na Internet: http://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdf. Acesso em 01/10/2007.DAFT, R.L.; LENGEL, R.H. (1986) Organizational information requirements, media richness and structural design, Organizational Science, 32/5: Pág. 554-571ELLIS, C. A.; GIBBS, S.J.; REIN, G.L. Groupware: Some issues and experiences.Communications of the ACM, New York, v.34, n.1, Jan. 1991.FRANCO, Fabio Vilela.. COLAB - Ferramenta Colaborativa para Co-autoria deTextos via Web. 2003. Monografia. Centro Universitário do Triangulo (UNIT),Uberlândia-MG.FREITAS, Danilo Pestana de; BORGES, Marcos R. S.; ARAÚJO, Renata Mendes de.Colaboração e Negociação na Elicitação de Requisitos. [2007?] Disponível na
  47. 47. 47Internet: http://kuainasi.ciens.ucv.ve/ideas07/documentos/articulos_ideas/Articulo74.pdf.Acesso em 15/09/2007FUKS, Hugo.; RAPOSO, Alberto B.; GEROSA, Marco Aurélio. Engenharia deGroupware: Desenvolvimento de Aplicações Colaborativas. XXI Jornada deAtualização em Informática, Anais do XXII Congresso da Sociedade Brasileira deComputação, V2, Cap. 3. 2002.FUKS, Hugo.; RAPOSO, Alberto B. ; GEROSA, Marco Aurélio. Do Modelo deColaboração 3C à Engenharia de Groupware, 2003. Simpósio Brasileiro de SistemasMultimídia e Web – Webmidia 2003, Salvador-BA.FUKS, Hugo. (Org.). Suporte à Coordenação e à Cooperação em uma Ferramentade Comunicação Textual Assíncrona: Um Estudo de Caso no Ambiente AulaNet.2004. Anais do Workshop Brasileiro de Tecnologias para Colaboração 13-14 deOutubro, Ribeirão Preto-SP . Disponível na Internet: http://www.les.inf.puc-rio.br/groupwareFURLAN, José Davi. Modelagem de Objetos através da UML: Análise e DesenhoOrientados a Objeto. São Paulo. Makron Books. 1998.GEROSA, Marco Aurélio. et. al. Componentes Baseados no Modelo 3C para oDesenvolvimento de Ferramentas Colaborativas, 2005. Anais do 5º Workshop deDesenvolvimento Baseado em Componentes, Juiz de Fora-MG, Disponível na Internet:http://www.les.inf.puc-rio.br/groupwareLARMAN, Craig. Utilizando UML e padrões: Uma introdução à analise e ao projetoorientados a objetos. Tradução: Luiz A. Meirelles Salgado. Porto Alegre – RS. EditoraBookman. 2000MACORATTI, José Carlos. Modelando Sistemas em UML - Casos de Uso. 2004.Disponível na Internet:http://www.imasters.com.br/artigo/2753/uml/modelando_sistemas_em_uml_-_casos_de_uso/. Acesso em 03/10/2007.NOGUEIRA, Admilson. Casos de Uso (Cenários). 2006. Disponível na Internet:http://www.imasters.com.br/artigo/3811/uml/casos_de_uso_cenarios/. Acesso em03/10/2007.OLIVEIRA, Carla. Sistemas Colaborativos. 2006. Disponível na Internet:http://cursoyai.googlepages.com/sistemasColaborativos.pdf, acesso em 12/09/2007.PINHEIRO, Manuele Kirsch. Mecanismo de suporte à percepção em ambientescooperativos. Porto Alegre: PPGC da UFRGS, 2000.
  48. 48. 48ROSA, Márcio. Groupware: um caminho para a cooperação. 2005. Disponível naInternet: http://www.frb.br/ciente/2005.1/BSI/ciente_v.1_bsi.rosa.pdf. Acesso em:01/09/2007.SOMMERVILLE, Ian. Engenharia de Software. 6ª Edição. Cap. 5 e 6. 2003Zanlorenci, Edna Pacheco; Burnett, Robert Carlisle. 2001. Requisitos funcionais enão-funcionais, as duas faces da moeda aplicáveis à engenharia de software.Disponível na Internet:http://www.pr.gov.br/batebyte/edicoes/2001/bb115/requisitos.htm. Acesso em02/10/2007

×