Engenharia de requisitos em ambientes distribudos de ...

  • Published on
    08-Jan-2017

  • View
    216

  • Download
    4

Transcript

  • Engenharia de requisitos em ambientes distribudos de desenvolvimento

    de software: resultados preliminares de um estudo etnogrfico

    Alline de Melo Lemos, Cleidson R. B. de Souza Faculdade de Computao, Instituto de Cincias Exatas e Naturais,

    Universidade Federal do Par

    {alline, cdesouza}@ufpa.br

    Resumo

    A indstria de software uma das vrias indstrias

    que tem sofrido alteraes com o advento da

    globalizao. A crescente demanda por software e a

    escassa mo-de-obra qualificada motivaram o

    surgimento do Desenvolvimento Distribudo de

    Software. Dentre os principais desafios a serem

    vencidos em projetos distribudos de software, esto

    aqueles relacionados Engenharia de Requisitos. O

    objetivo deste artigo apresentar os resultados

    iniciais de um estudo emprico que est sendo

    realizado em uma organizao de desenvolvimento de

    software que elicita, analisa e gerencia requisitos de

    clientes situados em locais diversos. Pretende-se com

    este artigo, sugerir recomendaes para as

    dificuldades at ento identificadas, na tentativa de

    melhorar o processo j adotado pela empresa em

    questo.

    1. Introduo

    A indstria de software uma das vrias indstrias que tem sofrido os efeitos da globalizao [1]. Percebe-se uma crescente demanda por software de um lado e uma conseqente escassez de mo-de-obra qualificada de outro. Isto forou as empresas a buscarem solues em outros pases especialmente, Brasil, Irlanda, Rssia, ndia, Israel e China. Dentro deste contexto, surge o conceito de Desenvolvimento Distribudo de Software (DDS), uma nova rea da Engenharia de Software que se caracteriza pela distncia fsica e/ou temporal entre alguns elementos (cliente, usurio e desenvolvedores, por exemplo, envolvidos no processo de desenvolvimento [2].

    De uma maneira geral, os seguintes fatores podem ser citados como motivaes para o DDS [3; 4]: 1) a necessidade de uma empresa estar prxima de seus clientes; 2) o surgimento de naes como participantes ativas no mercado mundial de software; 3) os benefcios econmicos encontrados nestas naes (mo-de-obra qualificada e de 10 a 30% mais barata),

    e; 4) a possibilidade de desenvolvimento follow-the-sun, isto , as equipes esto distribudas em diversos pases permitindo que o desenvolvimento do software nunca pare.

    Em DDS, entretanto, existe uma srie de desafios a serem vencidos, sendo o maior deles a engenharia de requisitos [2]. Segundo Damian e Zowghi [5], a engenharia de requisitos (ER) j envolve atividades suficientemente complicadas quando realizadas de forma local. Em ambientes distribudos, estas atividades se tornam ainda mais problemticas, sobretudo em virtude das diferenas culturais, temporais e geogrficas enfrentadas pelos integrantes das equipes envolvidas.

    Para ser mais especfico, a globalizao gera dois grandes desafios comunidade de pesquisa em engenharia de requisitos [6]. O primeiro desafio diz respeito criao ou aprimoramento de tcnicas de ER que apiem as demais atividades envolvidas no desenvolvimento distribudo de software, como a codificao ou o teste do sistema. Isto necessrio porque a distncia agrava a lacuna existente entre os analistas de requisitos e os desenvolvedores, sobretudo se so indivduos que trabalham em organizaes situadas em pases diferentes. Esta lacuna tambm pode existir entre analistas de requisitos e seus clientes, exigindo que os primeiros se desloquem ao ambiente de trabalho dos segundos e vice-versa. Uma vez que a comunicao entre os stakeholders diminui devido distncia [7], aumentam as chances de os requisitos serem mal interpretados e conseqentemente de pouca utilidade ao cliente final. O segundo desafio consiste em permitir que as etapas da ER sejam realizadas de forma eficiente em ambientes distribudos. A tendncia que analistas de requisitos lidem cada vez mais com stakeholders distribudos, assim, estes profissionais necessitam de apoio (tcnicas, ferramentas, metodologias, etc) que facilitem atividades distribudas como elicitao, negociao e modelagem de requisitos.

    Este trabalho descreve a realizao de um estudo etnogrfico em uma empresa (chamada simplesmente de Alpha para preservar sua identidade) em que

    11th. Workshop on Requirements Engineering

    85

  • algumas tarefas da ER so realizadas distncia. Contatos iniciais com a empresa sugerem que a mesma enfrenta problemas durante o processo de Engenharia de Requisitos porque se encontra localizada distante de seu cliente. A empresa em questo caracterizada principalmente pela prtica da elicitao de requisitos com clientes geograficamente separados da equipe responsvel pelo desenvolvimento do sistema. H ainda uma grande preocupao por parte da empresa em alcanar nveis mais elevados de maturidade do seu processo de desenvolvimento de software. Portanto, torna-se relevante realizar uma pesquisa cujos resultados podem auxiliar na melhoria do processo utilizado pela empresa.

    Estudos etnogrficos requerem que eles sejam conduzidos no ambiente de trabalho das equipes sendo estudadas [8]. Desta forma, este estudo est sendo conduzido na prpria empresa Alpha. Isto tambm inclui a necessidade de coletar dados no domnio do cliente desta empresa, o qual fica localizado em outra cidade. Isto um importante aspecto do estudo, pois evita uma das limitaes observadas na maioria dos estudos empricos anteriores: a coleta de dados de apenas um dos stios. Resultados extrados de apenas um contexto de trabalho possuem problemas de validade, uma vez que descrevem problemas a partir de uma nica tica: a da equipe responsvel pela construo do software [9]. Desta forma, a realizao de estudos etnogrficos que incluam coletas de dados no contexto do cliente importante porque auxilia na obteno de resultados teoricamente mais vlidos.

    O estudo etnogrfico descrito neste artigo possui carter exploratrio e vem identificando os problemas enfrentados por engenheiros de software envolvidos em projetos de DDS na empresa Alpha. Alm das dificuldades, o estudo tambm visa identificar as boas prticas de trabalho realizadas pela empresa, isto , as estratgias j utilizadas pelas equipes para minimizar os efeitos causados pela distncia. Este artigo rene resultados preliminares de um estudo etnogrfico de uma empresa e seus clientes envolvidos em atividades de ER em contextos distribudos. No futuro, espera-se que estes resultados, futuramente mais consolidados, sejam traduzidos em um processo de Engenharia de Requisitos que apie suas atividades quando realizadas distncia.

    O restante deste artigo est organizado da seguinte forma: a seo 2 apresenta o estado atual da arte no que diz respeito ER distribuda. A seo 3 define a metodologia utilizada no trabalho: o mtodo etnogrfico e suas caractersticas. A seo 4 caracteriza o estudo etnogrfico, ilustrando o contexto da organizao e resumindo as atividades realizadas at o momento. A seo 5 apresenta a discusso em torno de

    resultados preliminares obtidos do estudo etnogrfico. Finalmente, a ltima seo contm as consideraes finais e os trabalhos futuros.

    2. Estado-da-arte em ER distribuda

    O processo de DDS, como o prprio nome sugere, envolve equipes de um projeto que se encontram separadas geograficamente e que, no entanto, cooperam no sentido de alcanar um mesmo objetivo: o desenvolvimento de um software. Tais equipes enfrentam diversas barreiras: organizacionais, culturais, tcnicas, temporais, todas causadas pela distncia geogrfica que as separa [10]. Os problemas so inmeros e esto refletidos em todas as etapas do processo de desenvolvimento de software. Segundo Damian e Zowghi [9], diversos desafios so enfrentados durante as atividades da ER em contextos distribudos e caracterizam os quatro maiores problemas decorrentes da distribuio geogrfica dos stakeholders: 1) comunicao inadequada; 2) gerncia ineficiente de conhecimento; 3) diversidade cultural; e 4) diferena de fuso-horrio. Estes problemas, por sua vez, originam uma srie de dificuldades especficas rea de ER: 1) diversidade de cultura e de negcio dos clientes; 2) pouca participao dos usurios do sistema com o corpo tcnico (desenvolvedores, gerentes, analistas, etc); 3) falta de comunicao informal e pouca percepo do contexto local de trabalho; 4) reduo do nvel de confiana; 5) dificuldade na gerncia de conflitos e na ocorrncia de discusses entre os integrantes da equipe, 6) dificuldade na obteno de uma interpretao comum dos requisitos; 7) ineficincia de reunies para tomada de deciso e, finalmente, 8) demora na execuo das tarefas.

    Na tentativa de minimizar estes problemas, vrias abordagens tm sido propostas para aperfeioar o processo de ER em ambientes distribudos. Estas abordagens podem ser classificadas genericamente em metodologias, ferramentas e estudos empricos.

    2.1. Metodologias

    Vrias abordagens j foram propostas no sentido de facilitar o processo de ER em ambientes distribudos. Em [11] um estudo experimental foi realizado com o intuito de avaliar ferramentas e abordagens utilizadas em um processo de DDS. Como resultado, os autores obtiveram o que se pode considerar um guia de recomendaes para a engenharia de software distribuda. Uma das recomendaes o uso de um wiki contendo uma matriz de rastreabilidade a partir da

    11th. Workshop on Requirements Engineering

    86

  • qual existiriam links para descries em alto nvel, casos de uso, outros diagramas relevantes e casos de teste relacionados a um determinado requisito.

    EasyWinWin [12] uma metodologia que apia atividades da ER distribuda, sobretudo a de negociao de requisitos. Ela funciona integrando tcnicas de grupo (como a realizao de sesses de brainstorming) e ferramentas de colaborao. Estudos de caso sugerem que o uso da EasyWinWin aprimora o envolvimento dos stakeholders e a interao entre eles durante o processo de ER, pois prioriza condies de ganho-mtuo entre eles.

    A metodologia proposta em [13] fundamentada na psicologia cognitiva, segundo o modelo de classificao Felder Silverman (FS). Ela consiste em definir quais ferramentas de groupware e tcnicas de elicitao de requisitos melhor se adequam a um determinado tipo de pessoa. A maior contribuio desta metodologia para a ER sua capacidade de sugerir que tipo de ferramentas e tcnicas de elicitao de requisitos pode ser o mais adequado a uma pessoa segundo suas caractersticas pessoais.

    Lopes e Audy [14] propem uma adaptao ao processo de ER de forma a minimizar os principais desafios oriundos de ambientes de desenvolvimento de software distribudos. A adaptao proposta visa reduzir as dificuldades enfrentadas durante o processo distribudo de requisitos, a partir da introduo de tarefas que devem ser realizadas pela equipe de desenvolvimento: entender e alterar a especificao de requisitos sempre que necessrio. Com esta proposta, espera-se que se minimizem, sobretudo, problemas relacionados comunicao entre os stakeholders(eventualmente causados por questes de idioma), assim como a ocorrncia de ambigidade e falta de clareza na descrio dos requisitos.

    2.2. Ferramentas

    Pode-se citar como exemplo de ferramentas a Econference [15], uma aplicao de conferncia textual que possibilita a comunicao sncrona e estruturada entre equipes distribudas durante a realizao de atividades de ER. Existe tambm um kit de ferramentas desenvolvido como parte da metodologia EasyWinWin e baseado em um sistema de apoio a grupos (GSS do ingls, Group Support System) [11]. Stakeholders distribudos seriam capazes de coletar, elaborar, priorizar e negociar requisitos, pois o kit disponibiliza uma srie de funcionalidades colaborativas como criao de listas compartilhadas, de sesses de brainstorm e de enquetes.

    Ferramentas de propsito geral tambm podem ser adaptadas para minimizar os desafios impostos pela

    distncia, como o caso da TeamWare [16]. A TeamWare uma ferramenta de groupware, que simula uma sala de reunies equipada com uma srie de ferramentas de colaborao, tais como: quadros de avisos, visualizadores de arquivos, chat, lista de participantes, entre outras. Em [17], observa-se como as funcionalidades da TeamWare podem ser utilizadas como apoio ao processo de ER distribudo.

    Outras ferramentas de propsito geral podem auxiliar tarefas distribudas de ER como o Microsoft NetMeeting [18]. Embora alguns estudos sugiram a supremacia das ferramentas sncronas em relao s assncronas [19], argumenta-se que diversos canais de comunicao (tanto sncronos quanto assncronos) so necessrios para aprimorar as atividades relacionadas ao processo distribudo de ER [20].

    2.3. Estudos Empricos

    Conforme citado anteriormente, alm da construo de ferramentas e da criao de metodologias, muitos trabalhos que visam reduzir os problemas acarretados pela distncia geogrfica durante a fase de ER giram em torno da realizao de estudos empricos. Os mtodos empricos utilizados nestes estudos so os mais variados. Por motivos de limitao de pginas, optou-se por citar apenas um exemplo para cada mtodo emprico. Lloyd et al. [19] realizaram um experimento em que aplicavam questionrios e realizavam observaes com estudantes para avaliar como aplicaes de groupware poderiam apoiar o processo distribudo de ER, em especial a etapa de elaborao do documento de especificao de requisitos. Para mais exemplos de experimentos, consulte [18; 21]. Um exemplo de estudo de caso pode ser encontrado em [22], cujo objetivo principal analisar o processo de ER em ambientes distribudos de software. Os dados foram coletados mediante a realizao de observaes e entrevistas. Outro exemplo de estudo de caso pode ser encontrado em [9]. Em [23], os autores aplicam e avaliam um total de 744 questionrios no sentido de enfatizar quo essencial a comunicao em projetos que envolvem DDS.

    De um modo geral, pode-se observar que tanto mtodos quantitativos (experimentos e questionrios) quanto mtodos qualitativos (estudos de caso) tm sido utilizados para estudar projetos distribudos. Entretanto, nenhum destes estudos considera de maneira apropriada o ponto de vista de todos os

    stakeholders envolvidos nos projetos. Isto acontece em virtude de dois grandes motivos. O primeiro diz respeito prpria natureza dos mtodos empricos escolhidos: durante a conduo de experimentos, as variveis do ambiente so manipuladas visando obter

    11th. Workshop on Requirements Engineering

    87

  • uma relao causa-efeito [24]. J no caso dos questionrios, no se pode assegurar que as respostas fornecidas correspondem de fato realidade observada na organizao. Em ambos os casos, detalhes importantes do ambiente real de trabalho podem ser ocultados e isto no interessante para o objetivo do estudo em questo. J no estudo de caso, o pesquisador consegue ter acesso a estes detalhes uma vez que utiliza os mesmos mtodos de coleta de dados da etnografia (entrevistas e observaes), mas ainda assim no lhe exigida a presena em campo, isto , o pesquisador pode realizar timos estudos de caso sem, no entanto, precisar estar inserido na cultura de todos os informantes [25]. Isto pode ocasionar um problema grave e nos aponta o segundo motivo pelo qual nenhum trabalho considera de maneira adequada o ponto de vista de todos os stakeholders: os estudos de caso existentes normalmente levam em conta apenas uma das equipes do projeto, j que as demais se encontram distribudas, o que dificulta bastante a realizao de entrevistas presenciais e observaes de todas as equipes envolvidas. Em resumo, acaba-se perdendo o contexto de trabalho de um ou de vrios lados.

    O mtodo etnogrfico, a ser utilizado neste estudo est descrito a seguir e visa resolver estas limitaes.

    3. O Mtodo etnogrfico

    O mtodo de pesquisa utilizado neste trabalho chama-se etnografia. A etnografia o principal mtodo que a antropologia utiliza para coletar e analisar dados [8]. Estudos etnogrficos fornecem o contexto completo de uma comunidade, descrevendo de maneira bastante rica os elementos que a compem (pessoas, ambientes e interaes) e as atividades dos membros da comunidade. Alm disso, em um estudo etnogrfico as atividades so compreendidas a partir da perspectiva do informante [26]. A principal vantagem da etnografia permitir ao pesquisador entender os aspectos que so importantes para os informantes, o ponto de vista do informante, ao invs de focar em aspectos relevantes para o prprio pesquisador. Neste trabalho, os informantes so os stakeholders de um projeto de desenvolvimento distribudo de software.

    A etnografia, diferentemente de estudos quantitativos, realizada mediante a insero que neste caso exigida de etngrafos no ambiente de trabalho dos usurios [8]. Os etngrafos observam as prticas reais de trabalho, ao invs das chamadas prticas prescritas, ou seja, as prticas definidas por manuais e guias da empresa. Em outras palavras, a abordagem etnogrfica proporciona um entendimento

    acerca das reais atividades desempenhadas ao invs das atividades formais, normalmente mencionadas em um processo tradicional de conduo de entrevistas. De um modo geral, a viso dos autores que somente atravs do entendimento do ponto de vista do informante possvel desenvolver ferramentas e/ou propor recomendaes que considerem os reais problemas enfrentados tanto por engenheiros de software quanto por clientes e usurios envolvidos em projetos distribudos.

    Em razo dos pontos citados acima, a etnografia tem sido adotada por profissionais da rea de Interao Homem-Computador e Trabalho Cooperativo h dcadas [27] e, mais recentemente, por profissionais de engenharia de software [28]. A etnografia utilizada como mtodo de pesquisa especialmente na rea de engenharia de requisitos, pois considera as reais prticas de trabalho de uma organizao, identifica as reais necessidades de um cliente e facilita a construo de sistemas teis a seus usurios [29].

    O estudo etnogrfico proposto neste trabalho, particularmente, visa entender os efeitos que a distncia exerce em projetos de software, sobretudo quando clientes se encontram distantes da equipe de desenvolvimento. Mais especificamente, este trabalho visa investigar como a distncia influncia as atividades da Engenharia de Requisitos. Cabe ressaltar aqui que, enquanto um mtodo qualitativo de pesquisa, a etnografia no define suas hipteses a priori, apenas a (ampla) pergunta de pesquisa que objetiva responder.

    4. Caracterizao do estudo etnogrfico

    4.1. Contexto da organizao

    Como mencionado anteriormente, este trabalho relata resultados iniciais de um estudo etnogrfico realizado no ambiente de uma empresa de desenvolvimento de software chamada Alpha. Esta empresa certificada nvel 2 do CMMI e composta por trs equipes certificadas, das quais apenas uma foi observada at o presente momento. Esta equipe composta por um lder de projeto e analistas de sistemas, contabilizando um total de 12 pessoas.

    Em virtude da alta rotatividade observada na empresa, ou seja, da entrada e sada freqente de funcionrios, as pessoas que exercem o cargo de analistas de sistema normalmente esto envolvidas com diversos tipos de tarefas: desde a elicitao de requisitos at a execuo de testes no sistema desenvolvido.

    A empresa pratica desenvolvimento distribudo de software porque seu principal cliente est situado em

    11th. Workshop on Requirements Engineering

    88

  • outro estado. Desta forma, sempre que um novo sistema ou uma nova funcionalidade so solicitados, necessrio o deslocamento seja da equipe de desenvolvimento (com a ida de um analista) ou do cliente (com a vinda de um ou mais representantes da organizao). A distncia causa claros impactos em todas as atividades da ER, como ser visto nas prximas sees.

    4.2. Resumo das atividades

    Inicialmente, um acordo de colaborao foi estabelecido entre empresa Alpha e a Universidade Federal do Par. Este acordo previa a realizao de um estudo etnogrfico nas dependncias da empresa, sendo que a primeira autora realizaria as observaes das equipes. O critrio para a escolha da primeira (e at agora nica) equipe observada foi a etapa do processo que estava em andamento naquele momento. A equipe selecionada se encontrava, justamente, na etapa inicial de um projeto: j existia um sistema que precisava sofrer uma manuteno evolutiva e que, portanto, exigia nova elicitao de requisitos junto ao cliente.

    Uma vez que o acordo foi fechado entre Universidade e empresa Alpha, duas entrevistas exploratrias com durao mdia de uma hora foram realizadas com os lderes de projeto de duas das equipes certificadas da empresa. A partir destas entrevistas, foi possvel obter uma viso geral da empresa e das equipes a serem observadas. Aps as entrevistas, observaes no-participativas [30] foram realizadas no ambiente local (da empresa) e no ambiente remoto (do cliente). Considerando o contexto remoto, duas viagens cidade onde est situado o cliente foram realizadas visando o acompanhamento de uma reunio de elicitao de requisitos e uma reunio de fechamento do documento de especificao de casos de uso e de regras de negcio.

    Diversas atividades foram observadas. No contexto local, os analistas foram observados realizando, especialmente, atividades de documentao de requisitos, alm de reunies para acompanhamento de projeto, em que toda a equipe costumava estar presente. J no contexto remoto, a observao era realizada durante as reunies que normalmente duravam um dia inteiro. Em todos os casos, as observaes foram realizadas pela primeira autora do artigo. Tambm foram estudados os manuais da empresa visando o entendimento do processo de software adotado pelas equipes.

    A teoria fundamentada em dados (do ingls, Grounded Theory) [31] foi utilizada para analisar os dados na medida em que foram coletados. Esta

    abordagem visa originar, a partir dos dados coletados, uma teoria que explique o que foi observado nestes dados. A anlise dos dados foi auxiliada pela utilizao da ferramenta MAXqda2 [32]. Em linhas gerais, esta ferramenta permitiu a criao de rtulos para aspectos identificados como relevantes durante a anlise. Isto permitiu atribuir significado ao que antes era um grande volume de dados desestruturados. Vale ressaltar que as atividades de coleta e anlise dos dados so partes de um processo iterativo: os dados eram coletados e analisados para posteriormente novos dados serem coletados e analisados e assim por diante. A partir disto, identificaram-se (i) os problemas enfrentados pelas equipes durante as atividades de ER, e (ii) as boas prticas que a equipe realizou na tentativa de minimizar os efeitos causados pela distncia.

    5. Discusso

    O estudo etnogrfico realizado at o momento permitiu identificar uma srie de desafios causados, especialmente, pela distncia entre o cliente e a equipe de desenvolvimento. Tais desafios j foram discutidos na literatura, entretanto no se tem conhecimento de um estudo que tenha registrado o comportamento dos clientes (que, neste caso, esto separados geograficamente da equipe de desenvolvimento) a partir de observaes no-participativas. Normalmente, os estudos se concentram em entrevistar e observar apenas a equipe de desenvolvimento (ou parte dela) e, a partir disto, enumerar o que seriam desafios para uma equipe de analistas e propor solues para os problemas observados. O estudo etnogrfico deste artigo analisa as dificuldades enfrentadas pela equipe de desenvolvedores, mas tambm se preocupa em ouvir os clientes destes desenvolvedores e, assim, registrar os problemas enfrentados por estes. Esta preocupao importante porque, com o registro das impresses dos clientes, torna-se possvel a construo de ferramentas e/ou elaborao de metodologias que tragam benefcios no apenas para a equipe de desenvolvimento, mas tambm para os clientes. Analistas e clientes trabalham juntos, portanto, para que suas atividades sejam facilitadas necessrio que se identifiquem quais os problemas enfrentados por ambos. De nada adianta, por exemplo, que um template de especificao de requisitos seja o ideal para uma equipe de analistas, se clientes e usurios no so capazes de interpret-lo corretamente.

    As subsees seguintes apresentam os problemas e as boas prticas identificadas durante o estudo descrito neste artigo. Estas informaes foram organizadas em

    11th. Workshop on Requirements Engineering

    89

  • forma de vignettes, ou seja, histrias curtas1, e esto baseadas em dados reais coletados durante trs etapas do processo de ER: elicitao, documentao e validao. Vale ressaltar que as boas prticas observadas constituem um empenho da prpria equipe no sentido de suavizar os efeitos causados pela distncia.

    Para facilitar o entendimento, um breve histrico do sistema sobre o qual todas as observaes foram realizadas ser apresentado; este sistema ser chamado de SYS. O SYS vem sendo desenvolvido desde 2001 para um rgo federal. Este sistema foi pensado com o objetivo de automatizar todo um setor dentro deste rgo e cujas atividades eram realizadas de forma manual. Vale salientar que esta uma rea nova no rgo e envolve diversas reas do conhecimento. Isto propicia e acentua um problema bastante comum na ER: clientes que no sabem ou sabem, mas possuem divergncias internas, sobre as funcionalidades do sistema.

    5.1. Elicitao de requisitos

    Maria trabalha como analista de sistemas na empresa Alpha h, mais ou menos, quatro anos. Ela j trabalhou com o SYS (de 2005 a 2007) e depois se afastou do sistema para trabalhar com projetos mais curtos. Em Janeiro de 2008, Maria retornou ao SYS, embora ainda trabalhe em outros projetos, e em fevereiro do mesmo ano foi designada por seu gerente Jos para viajar e participar de uma reunio com os clientes do SYS. A reunio foi agendada para tratar da adio de novos requisitos ao SYS e da alterao de requisitos existentes. Estavam presentes na reunio, alm de Maria, a gerente de negcios da empresa Alpha, Lcia, e a cliente Selma. As histrias seguintes ilustram algumas situaes vivenciadas durante a primeira reunio com o cliente.

    Vignette 1 assumindo requisitos j elicitados por

    terceiros.

    Maria abre um documento para ler a especificao

    de um determinado requisito. Maria e Selma lem o

    documento juntas. Ao lerem a especificao, ambas se

    do conta de que o requisito est especificado

    incorretamente. Selma faz questo de deixar claro que

    o requisito est mal especificado: Maria, eu s

    queria um botozinho..., dando a entender que o que

    est implementado muito mais complexo que aquilo

    que foi pedido. No final das contas, Maria e Selma

    1 Nomes foram alterados para preservar a identidade dos envolvidos.

    riem porque aparentemente no existe motivo para o

    requisito ter sido especificado daquela forma. Maria,

    no entanto, demonstra preocupao: vou falar com o

    Jos (gerente) pra saber se ele se lembra da

    justificativa para isso ter sido especificado assim....

    Problemas de gerncia de conhecimento podem ser identificados na situao acima. Estes problemas existem em qualquer organizao, estando ela inserida ou no no contexto de DDS, entretanto so acentuados pelo efeito da distncia. Isto acontece porque o analista vai sozinho a estas reunies e o conhecimento das regras de negcio acaba ficando retido nesta pessoa. No caso acima, a situao se complica ainda mais porque Maria est assumindo requisitos j discutidos por outro analista (que no pde estar presente). Esta vignette ilustra apenas um exemplo de situaes em que Maria no pde fornecer uma resposta adequada s perguntas de sua cliente, porque no esteve presente nas primeiras reunies com o mesmo. Em equipes co-localizadas, certamente o gerente no teria problemas de restrio oramentria, logo seria capaz de deslocar mais analistas s reunies de coleta de requisitos, evitando que o conhecimento ficasse retido em uma nica pessoa. Deve-se tambm observar que existem dois lados nesta situao: de um lado, uma vez que praticamente todo o conhecimento est concentrado em uma pessoa, que no a que est junto ao cliente, corre-se o risco de uma srie de requisitos serem mal interpretados e conseqentemente mal especificados e mal implementados. De outro lado, embora este caso seja um caso extraordinrio, como o analista que vinha participando das ltimas reunies do projeto no esteve na reunio porque estava em seu perodo de frias, a ida de outro analista em seu lugar permitiu que o conhecimento fosse difundido.

    Vignette 2 construindo prottipos junto ao

    cliente.

    Antes de se deslocar para a cidade da cliente, Jos

    e Maria conversaram sobre como as coisas deveriam

    funcionar l. Maria deveria construir prottipos

    durante toda a reunio, desde o primeiro dia. Jos a

    aconselha a utilizar um editor de HTML ultrapassado

    para que a equipe seja forada a descartar totalmente

    o prottipo. J na cidade da cliente, Maria, Lcia e

    Selma comeam a se reunir, diariamente, durante

    cinco dias. O quinto e ltimo dia foi o dia que Maria

    escolheu para que todos os prottipos construdos at

    ento fossem validados pela cliente. Lcia pergunta se

    a ltima especificao tinha ocorrido dessa forma,

    com a ajuda de prottipos. Selma responde satisfeita:

    com esse nvel de detalhamento, no. Lcia ento

    estabelece: As prximas especificaes vo ser desse

    11th. Workshop on Requirements Engineering

    90

  • jeito (...) a gente pode perder um pouco de tempo, mas

    depois vai ganhar (...) e evita desgaste pra vocs

    (clientes) e pra ns (empresa Alpha). Maria adotou

    uma prtica interessante para alcanar este resultado:

    ela no fez os prottipos no primeiro dia porque

    queria que a cliente falasse o mximo possvel sobre

    os requisitos. De acordo com Maria, se ela dedicasse

    o tempo para conversar com a cliente e ao mesmo

    tempo fazer os prottipos, a conversa no fluiria bem.

    Assim, no primeiro e no segundo dia, Selma falou

    bastante, enquanto Maria s anotava e rabiscava

    prottipos no papel (paper prototyping). No terceiro

    dia de reunio, Maria chegou bem mais cedo que os

    demais integrantes e construiu vrias telas com base

    em suas anotaes. A conversa j fluiu bastante:

    Selma j falou bem menos no sentido de dar novas

    informaes e a reunio girou em torno da correo

    de requisitos mal entendidos. De um modo geral, a

    utilizao da prototipagem foi bem recebida pela

    gerente de negcios e pela cliente, que pareceram

    estar satisfeitas com os resultados obtidos da reunio.

    Duas boas prticas podem ser identificadas dentro deste contexto: primeiro o projeto de interfaces com o auxlio da prototipagem em papel e em seguida a construo propriamente dita de telas via editor de HTML. Vale lembrar que a analista no queria conversar com a cliente ao mesmo tempo em que construa prottipos com o auxlio do computador. Desta forma, o uso da prototipagem em papel em um primeiro momento foi uma estratgia eficaz, pois, por se tratar de uma metodologia rpida e barata, permitiu que a conversa flusse: enquanto a cliente falava, a analista, de forma bastante simples, esboava rascunhos das telas em um papel e j obtinha feedbackda cliente caso algum componente da tela estivesse incorreto. Posteriormente, quando a analista j tinha idia de quais requisitos seriam adicionados e quais seriam alterados, os prottipos j poderiam ser construdos com a ferramenta, pois, teoricamente, a cliente j teria dito as coisas mais importantes nos primeiros dias e agora estaria preocupada em apenas averiguar se as telas continham os campos corretos e consert-los no caso de estarem incorretos. Em suma, a boa prtica que pode ser extrada desta situao a seguinte: primeiro projetar interfaces no papel, s depois no editor de HTML. Estas boas prticas so primordiais em ambientes de DDS que carecem de oportunidades em que clientes e analistas se encontram e que, portanto, necessitam utilizar o tempo disponvel da melhor forma possvel. Deve-se observar, entretanto, que esta prtica mais apropriada para a adio de novos requisitos a um sistema existente.

    Vignette 3 conduzindo uma reunio de elicitao

    de requisitos.

    A reunio ocorreu de forma tranqila, embora

    Selma mudasse o foco da conversa freqentemente.

    Certo dia, Maria e Selma conversavam sobre uma

    determinada funcionalidade do SYS, quando Selma

    comeou a falar de outra funcionalidade,

    simplesmente por se lembrar de algum incidente

    causado pelo mau funcionamento do sistema. Maria

    foi capaz de parar e dizer: Calma, Selma. Vamos

    voltar ao que estvamos falando? Que a eu no me

    perco... Maria no tem m vontade em atender s

    exigncias de Selma, isto , no que Maria no

    queira falar sobre uma determinada funcionalidade,

    mas deixa claro que falaro sobre ela em outro

    momento mais apropriado.

    Saber conduzir uma reunio de elicitao de requisitos muito importante, sobretudo se os stakeholders envolvidos no se vem com freqncia, como em ambientes de DDS. Em projetos distribudos, os clientes tendem a falar sobre funcionalidades diferentes ao mesmo tempo, em uma tentativa desesperada de aproveitar todo o tempo disponvel para informar suas necessidades ao analista presente. H tambm os casos em que vrios clientes esto presentes na mesma reunio e comeam a conversar sobre assuntos externos ao trabalho. O analista, por sua vez, pode e deve saber identificar e conter situaes em que os clientes prejudiquem o bom andamento da reunio. Tambm importante que os analistas saibam gerenciar a conversa de forma educada, mas firme, e consigam retomar o foco da discusso cada vez que ele for perdido. Esta foi mais uma boa prtica identificada com o objetivo de aproveitar o tempo da maneira mais eficaz possvel.

    5.2. Documentao de requisitos

    Laura novata e est trabalhando na empresa Alpha como analista de sistemas h menos de um ano. Banco de dados o ponto forte de Laura, que escreveu poucos documentos de especificao de requisitos em sua vida profissional. Laura foi encarregada de especificar um conjunto de funcionalidades do SYS, fato que estar ilustrado na vignette a seguir.

    Vignette 1 Escrevendo casos de uso.

    Laura est responsvel por documentar uma

    determinada funcionalidade do SYS. Certo dia, Laura

    precisou lidar com um documento de especificao de

    casos de uso que estava fora dos padres da empresa

    11th. Workshop on Requirements Engineering

    91

  • porque vrias outras pessoas, inclusive a cliente

    Selma, j haviam alterado o documento. Laura

    detectou, por exemplo, que algumas regras de negcio

    estavam documentadas na forma de passos de um

    fluxo de um determinado caso de uso e, portanto, teve

    de reescrever vrios documentos de especificao.

    Alm disso, Laura no entendia o que uma regra de

    negcio queria dizer se lesse apenas o seu ttulo, logo

    teve que dar nomes mais intuitivos a estas regras.

    Depois de adequar os documentos aos modelos

    previstos pelo processo da empresa, ela pde ento

    continuar seu trabalho.

    Durante a reunio de elicitao de requisitos, foi possvel perceber que a cliente participava do processo de documentao de casos de uso. A primeira verso do documento partia da empresa Alpha, mas permitia-se que os clientes alterassem o documento caso os requisitos estivessem incompletos ou incorretos. Isto foi problemtico porque o documento comeou a ir e vir entre as partes, com as mesmas adicionando novas coisas e supondo que o outro lado estaria interpretando os requisitos da forma correta. Embora essa medida parea vantajosa em projetos distribudos, afinal de contas evita que as partes se desloquem para se reunir, ela causa problemas srios a longo prazo j que na medida em que o tempo passa, os requisitos esto to modificados que j no refletem as necessidades de seus usurios. A situao descrita acima ilustra um desafio clssico de DDS, que o problema de compreenso entre as partes distribudas, mas ao mesmo tempo identifica uma boa prtica seguida pela empresa: o esforo da analista em manter o documento dentro do modelo, para s ento adicionar alteraes dos respectivos requisitos.

    Vignette 2 Revisando casos de uso.

    Laura acaba de alterar dois documentos: um de

    especificao de requisitos e outro de regras de

    negcio. Laura pede ento que Maria revise suas

    modificaes, pois est preocupada e no sabe se as

    modificaes esto completas e corretas. Maria, alm

    de documentar, tambm a responsvel por revisar os

    documentos de especificao, pois a analista que

    esteve presente na reunio com o cliente. Em resposta

    ao pedido da colega, Maria deixa de fazer sua

    atividade e se dirige at a mesa de Laura para falar

    suas impresses sobre o documento. Maria sugere

    algumas modificaes Laura e retorna sua mesa

    para logo em seguida ser solicitada novamente por

    Laura.

    Como visto anteriormente, apenas um analista se desloca para conversar com o cliente, devido a restries oramentrias. Novamente, problemas na gerncia do conhecimento so notados em virtude de a equipe estar inserida em um contexto distribudo. Esta situao s um exemplo, entre tantos, em que a analista que esteve presente na reunio com o cliente tem suas atividades interrompidas para revisar o trabalho de seus colegas durante a especificao de requisitos. Embora tenha existido uma reunio de repasse para que Maria informasse os requisitos coletados distncia para seus colegas, a rigor, ela quem continua detendo o conhecimento sobre as necessidades da cliente. Logo ela a pessoa que os demais analistas procuram quando se deparam com alguma dvida. Isto causa uma sobrecarga considervel nas atividades de Maria, visto que ela precisa interromp-los freqentemente para revisar o trabalho dos demais colegas.

    5.3. Validao de requisitos

    Carlos o analista que estava de frias e que, por isso, no pde estar presente na reunio de elicitao de requisitos. Carlos, no entanto, voltou de frias a tempo de ir para a reunio de fechamento que corresponde reunio de validao de requisitos. Estiveram presentes nesta reunio: Carlos, Selma e os tambm clientes, Jlia e Luis. Luis o chefe dos demais.

    Vignette 1 Modificando a documentao.

    Selma e Jlia j leram grande parte do documento

    de especificao que havia sido enviado com

    antecedncia pela empresa Alpha e esto agora

    relendo junto a Carlos. O documento contm dvidas

    das clientes que esto marcadas em azul. Elas

    sugerem muitas alteraes no texto, alegando que os

    requisitos no esto descritos com clareza. Carlos

    conhece o SYS a fundo e isto facilita a leitura do

    documento que acontece de forma rpida. As

    alteraes propostas por Selma e Jlia so todas

    aceitas por Carlos, que toma a iniciativa de reescrever

    os casos de uso sempre com o consentimento final das

    clientes. Alm disso, Selma se aborrece inmeras vezes

    porque percebe que o que foi acordado com Maria na

    reunio anterior no foi contemplado no documento

    de regras de negcio.

    Esta situao ilustra o que talvez seja considerado como a mais importante boa prtica desta equipe neste projeto. Anteriormente, a parte final do processo de ER, isto , a validao dos requisitos era realizada

    11th. Workshop on Requirements Engineering

    92

  • distncia. Por causa da distncia, os documentos de especificao e de regras de negcio eram enviados por e-mail para os clientes que liam, sugeriam modificaes e reenviavam empresa Alpha. Os analistas, por sua vez, reescreviam o documento de acordo com as modificaes solicitadas (ou, mais precisamente, de acordo com aquilo que eles achavam serem as modificaes solicitadas) e assim o documento ia e vinha at que os clientes entrassem em um consenso e informassem, ou via e-mail ou via telefone, que estavam de acordo com o documento elaborado. Ambos os lados perceberam que as idas e vindas do documento de especificao eram arriscadas, sobretudo em virtude do risco de m compreenso dos requisitos. Isto forou a gerente de negcios a instituir um encontro presencial para a elicitao de requisitos e outro, tambm presencial, para a validao de requisitos. Segundo as palavras da prpria gerente de negcios, esse negcio da gente especificar distncia e depois mandar documento... A gente j viu que d muito problema. Uma segunda reunio importante porque, como visto na vignetteanterior, ela permite a reduo de problemas de m compreenso de requisitos causados pela distncia entre clientes e analistas.

    Durante a reunio de fechamento, pde-se perceber que o documento de requisitos possua uma srie de requisitos ambguos, incompletos e que no estavam claros para o cliente e que, portanto, precisaram ser alterados junto ao analista da empresa Alpha. Caso a reunio no tivesse ocorrido de forma presencial, possvel que estes requisitos fossem documentados de forma incorreta e estariam refletidos posteriormente em funcionalidades inteis para seus usurios finais. Ou ainda, os stakeholders no seriam capazes de identificar que determinados aspectos, que haviam sido acordados na primeira reunio, no foram considerados durante a documentao e, por isso, continuariam no sendo contemplados em nenhum documento.

    6. Consideraes finais e trabalhos futuros

    O presente trabalho apresentou os resultados preliminares de um estudo etnogrfico em andamento na empresa Alpha. Esta empresa realiza atividades de ER de forma distribuda, uma vez que seu principal cliente est situado em outra regio do pas. Atividades como elicitao, documentao e validao de requisitos so consideravelmente afetadas em virtude da distncia existente entre a equipe de desenvolvimento e o cliente.

    Os resultados deste trabalho, como de tantos outros, mostram que existe uma gama de desafios a serem vencidos em DDS. De forma particular, este trabalho ilustra que, por mais que a equipe de desenvolvimento esteja situada no mesmo local, se os seus clientes forem remotos, esta distncia causa problemas na coordenao e execuo das atividades de desenvolvimento de software comprometendo a qualidade do produto final. Ainda que a pesquisa no seja capaz de propor uma soluo para os problemas encontrados neste primeiro momento, espera-se que ela seja capaz de chamar a ateno, no s para os problemas que envolvem os desenvolvedores, mas tambm para os problemas enfrentados pelos clientes, quando distribudos.

    O mtodo etnogrfico foi escolhido por se tratar do nico mtodo emprico a permitir que o pesquisador esteja em campo para entender as prticas de uma cultura a partir do ponto de vista dos informantes. A adoo deste mtodo vem tratar da maior limitao dos estudos empricos anteriores: a coleta de dados de apenas um dos contextos de trabalho envolvidos no projeto. Esta limitao pode comprometer a validade dos resultados obtidos j que as atividades de ER dependem sempre da interao entre duas partes: clientes e/ou usurios e equipe de desenvolvimento. Em projetos distribudos, as atividades do processo de ER so severamente impactadas, sobretudo pela distncia existente entre os stakeholders.

    Como j dito no decorrer do artigo, este estudo ainda est em andamento. Desta forma, os resultados obtidos com este trabalho so ainda preliminares. Pretende-se refinar os dados coletados at ento a partir da conduo de novas entrevistas semi-estruturadas. Alm disso, observaes continuaro a ser realizadas, tanto no contexto da equipe de desenvolvimento, quanto no contexto do cliente. Neste sentido, o processo de coleta e anlise de dados continuar a evoluir de forma iterativa.

    Espera-se que os resultados finais deste estudo de campo possam servir de insumo para a proposta de um processo de Engenharia de Requisitos distribuda para a empresa Alpha. Conforme discutido no artigo, o processo atual adotado pela empresa no prev o fator da distncia em suas atividades. No entanto, o impacto causado pela distncia visvel e desencadeia uma variedade de dificuldades que, juntas, prejudicam o processo de ER. possvel tambm observar que os engenheiros de software da empresa Alpha adotam estratgias para minimizar estas dificuldades. Finalmente, entende-se que a adoo de um processo mais adequado s reais necessidades da empresa ir possibilitar que as equipes melhorem a qualidade de

    11th. Workshop on Requirements Engineering

    93

  • seu processo e, portanto, a do produto desenvolvido [34].

    Agradecimentos

    Agradecimentos especiais aos participantes da empresa Alpha e aos seus clientes. Esta pesquisa tem financiamento do CNPq atravs do Edital Universal 2006/2, processo 479206/2006-6

    .

    7. Referncias

    [1] J.D. Herbsleb, and D. Moitra, Global software development, IEEE Software, March/April, 2001, pp.16-20.

    [2] Audy, J. and Prikladnicki, R. DesenvolvimentoDistribudo de Software: Desenvolvimento de Software

    com Equipes Distribudas, Srie Livros Didticos Campus-SBC, Editora Campus/Elsevier, 2007.

    [3] A. Mockus, and J. Herbsleb, Challenges of global software development, Proc. of the 17th Software Metrics Symposium, London, IEEE Computer Society, April 2001, pp.182-184.

    [4] Ebert, Christopher. Global Software Engineering. IEEE ReadyNote (e-Book), IEEE Computer Society, Los Alamitos, USA, 2006.

    [5] Damian, D. and Zowghi, D. Requirements Engineering challenges in multi-site software development

    organizations. Requirements Engineering Journal, 8, 149-160, 2003.

    [6] Cheng, B. and Atlee, J. Research Directions in Requirements Engineering. Proc. of the Conference on the Future of Software Engineering. p.285-303. May, 2007.

    [7] Kraut, R., Egido, C. et al. Patterns of Contact and Communication in Scientific Research Collaborations. In: Intellectual Teamwork: Social and Technological

    Foundations of Cooperative Work. J. Galegher, C. Egido and R. Kraut, Lawrence Erlbaum: 149-172, 1990.

    [8] McGrath, J. E. Methodology Matters: Doing Research in the Behavioral and Social Sciences, 1994.

    [9] Damian, D. and Zowghi, D. The impact of stakeholders geographical distribution on requirements

    engineering in a multi-site development organization.Proc. of the 10th IEEE Intl Conference on Requirements Engineering (RE02). p.319-328. Essen, Germany. 2002.

    [10] Carmel, E. Global Software Teams: A Framework for Managerial Problems and Solutions. Global Information Technology and Electronic Commerce: Issues

    for the New Millennium, Ivy League Publishing, Marietta GA, 2000.

    [11] Mullick, N., Bass, N., Houda, Z., Paulish, P. and Cataldo, P. Siemens Global Studio Project: Experiences Adopting an Integrated GSD Infrastructure. Proc. of the IEEE ICGSE. Florianpolis, Brasil, 2006.

    [12] Gruenbacher, P. Collaborative Requirements Negotiation with EasyWinWin. Proc. of the Second International Workshop on the Requirements Engineering Process - Innovative Techniques, Models, Tools to support the RE Process, 2000.

    [13] Aranda, G., Vizcano, A., Cechich, A. and Piattini, M. Technology Selection to Improve Global Collaboration.Proc. of the IEEE ICGSE. Florianpolis, Brasil, 2006.

    [14] Lopes, L., Prikladnicki, R., Audy, J. and Majdenbaum, A. Requirements Specification in Distributed Software Development - A Process Proposal. Proc. of the 38th Hawaii International Conference on System Sciences - HICSS. Hawaii, USA, 2005.

    [15] Calefato, F. and Lanubile, F. Using The Econference Tool For Synchronous Distributed Requirements

    Workshops. Proc. of the 1st International Workshop on Distributed Software Development (DiSD 2005), Paris, France, Austrian Computer Society, August 2005.

    [16] TeamWave Software Ltd., http://www.teamwave.com/.

    [17] Herlea, D. and Greenberg, S., Using a Groupware Space for Distributed Requirements Engineering. Proc. of the Seventh International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, 1998.

    [18] Damian, D., Eberlein, A., Shaw, M. and Gaines, B. Using Different Communication Media in Requirements

    Negotiation. IEEE Software, v.17 n.3, p.28-36, May 2000.

    [19] Lloyd, W., Rosson, M. and Arthur, J. Effectiveness of Elicitation Techniques in Distributed Requirements

    Engineering. Proc. of the 10th Anniversary IEEE Joint Intl Conference on Requirements Engineering, p.311-318, September 09-13, 2002.

    [20] Damian, D., Lanubile, F. and Mallardo, D. The role of asynchronous discussions in increasing the effectiveness

    of remote synchronous requirements negotiations. Proc. of International Conference on Software Engineering, Shanghai, May, 2006.

    [21] Espinosa, J., Nan, N. and Carmel, E. Do Gradations of Time Zone Separation Make a Difference in

    Performance? A First Laboratory Study. Proc. of Intl Conference on Global Software Engineering, Munich, Germany. IEEE, August, 2007.

    11th. Workshop on Requirements Engineering

    94

  • [22] Prikladnicki, R. and Audy, J. Requirements Engineering in Global Software Development:

    Preliminary Findings from a Case Study in a SW-CMM

    context. Proc. of the 5th SIMPROS Simpsio Internacional de Melhoria de Processo de Software, Pernambuco, 2003.

    [23] lles-Seifert, T., Herrmann, A., Geisser, M. and Hildenbrand, T. The Challenges of Distributed Software Engineering and Requirements Engineering: Results of

    an Online Survey. Proc. of GREW07: 1st International Global Requirements Engineering Workshop, Munich, Germany, August, 2007.

    [24] Wild, C. J. and Seber, G. Chance Encounters: A First Course in Data Analysis and Inference, John Wiley & Sons, 1999.

    [25] Yin, R. Case Study Research, Design and Methods,3rd edition, Thousand Oaks, CA, Sage Publications, 2003.

    [26] Blomberg, J., Giacomi, J., Mosher, A., and Swenton-Wall, P. Ethnographic Field Methods and Their Relation to Design. In: Participatory Design: Principles and Practices. Editado by Douglas Dchuler and Aki Namioka. Lawrence Erlbaum Associates Inc., USA, 1993.

    [27] Suchman, L. Plans and situated actions: the problem of human-machine communication. Cambridge, Cambridge University Press, 1987.

    [28] Sommerville, I. Software Engineering. 7 ed. Addison-Wesley, 2004.

    [29] Sommerville, I., Rodden, T., Sawyer, P., Bentley, R. and Twidale, M. Integrating ethnography into the requirements engineering process. Proc. of IEEE International Symposium on Requirements Engineering, San Diego, CA, USA, 1993.

    [30] Jorgensen, D. L. Participant Observation: A Methodology for Human Studies. SAGE Publications, Thousand Oaks, CA, 1989.

    [31] Glaser, B. Strauss, A. The discovery of grounded Theory. Aldine de Gruyter, NY, 1967.

    [32] MAXqda2, http://www.maxqda.com/.

    [33] Fuggetta, A. Software process: a roadmap. Proc. of the Conference on The Future of Software Engineering. Limerick, Ireland. June, 2000. p.25-34.

    11th. Workshop on Requirements Engineering

    95