Proposta de Processo de Documentação e Validação Dos Requisitos para Equipes de Desenvolvimento Distribuído de Software

Universidade Federal de Pernambuco Centro de Informtica
Ps-graduao em Cincia da Computao
Proposta de Processo de Documentao e Validao dos Requisitos para Equipes de Desenvolvimento Distribudo de Software
Leonardo Melo de Medeiros DISSERTAO DE MESTRADO Recife 29 de agosto de 2007
Universidade Federal de Pernambuco Centro de Informtica
Leonardo Melo de Medeiros
Proposta de Processo de Documentao e Validao dos Requisitos para Equipes de Desenvolvimento Distribudo de Software
Trabalho apresentado ao Programa de Ps-graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para obteno do grau de Mestre em Cincia da Computao.
Orientador: Co-orientador:
Alex Sandro Gomes Alexandre Vasconcelos
Recife 29 de agosto de 2007
Medeiros, Leonardo Melo de Proposta de Processo de Documentao e Validao dos Requisitos para Equipes de Desenvolvimento Distribudo de Software / Leonardo Melo de Medeiros. Recife: O autor, 2007. xxiii, 138 folhas: il., fig., tab., quadros, grf. Dissertao (mestrado) Universidade Federal de Pernambuco. CIN. Cincia da Computao, 2007. Inclui bibliografia, glossrio e apndices. 1. Documentao de Software. 2. Desenvolvimento Distribudo de Software. 3. Engenharia de Requisitos. 4. Processo de Engenharia de Requisitos. I.Ttulo. 005.3 CDD (22.ed.) MEI2007-064
Dedico este trabalho minha av Lanuza Ubirajara de Medeiros, que faleceu durante esse perodo e tanto fez por seus lhos e netos. Dedico tambm a todos os meus tios e avs que caram em guas Belas nesse natal e que no pude v-los.
Agradecimentos
A Deus que apesar de nossas desavenas nunca me fez sair do caminho me amparando nos momentos mais difceis. A minha famlia, por ter me dado apoiado durante toda minha formao, sou eternamente grato pelo esforo que meus pais zeram para que eu pudesse conquistar meus objetivos. Ao meu orientador, Professor Alex Sandro Gomes, pelos ensinamentos fornecidos para que eu pudesse me tornar um pesquisador. Me apoiando na concluso deste trabalho. Ao meu co-orientador, Professor Alexandre Vasconcelos, pelo apoio dado na rea de Engenharia de Software. Aos professores Jaelson Castro e Jones Albuquerque que atravs da participao em suas disciplinas me auxiliaram na proposio deste trabalho. Aos avaliadores Maria de Ftima Vieira e Carina Alves que se despuseram a avaliar este trabalho. Aos amigos Gustavo Cabral, Magno Maciel e Rafael Fonseca que me auxiliaram durante as disciplinas do mestrado. A Fbio Caparica, Almir Moura aos amigos de Petrolina e todos os integrantes do projeto Amadeus que pelas discusses ocorridas durante esse trabalho incentivaram e motivaram a realizao deste estudo de caso. A todos professores e funcionrios do Centro de Informtica, pelo conhecimento e apoio demonstrados durante o mestrado. Enm, a todos os que, direta ou indiretamente, contriburam para a realizao deste trabalho.
vii
How many roads must a man walk down Before you call him a man? Yes, n how many seas must a white dove sail Before she sleeps in the sand? Yes, n how many times must the cannon balls y Before theyre forever banned? The answer, my friend, is blowin in the wind, The answer is blowin in the wind. BOB DYLAN (Blowin in the Wind)
Resumo
A pesquisa em desenvolvimento distribudo de software est num momento relevante e oportuno. Devido a necessidade industrial em distribuir o desenvolvimento do software em diversas localidades, formando equipes distribudas de desenvolvimento. Essa forma distribuda de desenvolvimento trs preocupaes nos aspectos culturais, operacionais e tcnicos do desenvolvimento de software quando realizado por equipes distribudas. Dentro desse contexto, as atividades de documentao e validao de requisitos so necessrias para assegurar que estes estejam completos e corretos. Contudo, a distncia entre os participantes impacta na produtividade desse processo dicultando a obteno da congruncia e consenso nos requisitos por parte das equipes distribudas. Estudos indicam que o processo de validao de requisitos por parte dos stakeholders necessita estar bem estruturado para ocorrer de forma efetiva em ambientes distribudos de desenvolvimento, pois as revises consomem bastante tempo mesmo quando realizadas presencialmente atravs de comunicao face a face. Nesta pesquisa realizamos um estudo de caso com uma abordagem exploratria num projeto de desenvolvimento de software. O caso analisado ocorreu dentro das atividades do projeto Agentes Micromundo e Anlise do Desenvolvimento no Uso de Instrumentos Multimdia (AMADeUs-MM) que um projeto de pesquisa desenvolvido por vrias instituies. Devido distribuio geogrca de seus integrantes, esse projeto serviu como estudo de caso para identicar qual a estrutura das prticas relacionados validao e documentao dos requisitos de uma equipe de desenvolvimento distribudo de software. A partir da anlise do estudo de caso, propomos um processo de Engenharia de Requisitos adequado s necessidades existentes no desenvolvimento distribudo de software dentro do grupo estudado. Palavras-chave: Desenvolvimento Distribudo de Software, Engenharia de Requisitos, Processo de Engenharia de Requisitos
xi
Abstract
The distributed development software subject is timely and relevant. Almost all of todays large software development projects need to pay serious attention to cultural, operational and technical aspects when dealing with distributed development teams. In this context the requirements documentation and validation activities are necessary to ensure that requirements are consistent. Therefore, the distance of the participants impacts on the productivity of this process, diculting the consense of distributed teams regarding the requirements. Studies indicate thate requirements validation performed by distributed teams is a challenging activity. This happens because the local revisions realized in person takes a lot of time when realized by colocated teams. In this research we conducted a case study with an exploratory approach in a software development project. This case occurred in the activities of the Agentes Micromundo e Anlise do Desenvolvimento no uso de Instrumentos Multimdia (AMADeUs-MM), a research project developed by many institutions. Because of the geographical distribution of participants, this project was used as a case study to identify the practices of the software distributed team, related with the requirements documentation and validation activities. According to the analysis of this case study, we propose a requirements engineering process adjusted to existing necessities in the distributed software development on the observed group. Keywords: Distributed Software Development, Requirements Engineering, Requirements Engineering Process
xiii
Sumrio
Introduo 1.1 1.2 1.3 Motivao Problema da Pesquisa 1.2.1 Contribuio Organizao da Dissertao
1 2 4 4 5 7 7 7 8 9 9 10 11 12 13 13 14 16 18 18 18 20 20 21 21
Engenharia de Requisitos no Desenvolvimento Distribudo 2.1 Desenvolvimento Distribudo de Software 2.1.1 Desaos do Desenvolvimento Distribudo de software 2.1.1.1 2.1.1.2 2.1.1.3 2.2 2.3 Comunicao Integrao Coordenao
Engenharia de Requisitos Processo de Engenharia de Requisitos Baseado em DDS 2.3.1 2.3.2 2.3.3 2.3.4 Elicitao de Requisitos Documentao de Requisitos Validao de Requisitos 2.3.3.1 Inspeo de Requisitos Prototipagem Durante a Engenharia de Requisitos Processo de Requisitos alinhado com o CMM 2.4.1.1 2.4.1.2 2.4.2 Etapas do Processo Concluses
2.4
Trabalhos Relacionados 2.4.1
MuNDDoSS - Um Modelo de Referncia para o Desenvolvimento Distribudo de Software 2.4.2.1 Concluses Suporte Engenharia de Requisitos no Desenvolvimento Distribudo de Software xv
2.4.3
xvi 2.4.3.1 2.4.4 Concluses
SUMRIO
23 23 24 25 29 31 31 32 32 32 32 33 33 33 34 35 35 35 36 36 36 36 37 38 38 39 39 39 40 41
Efetividade das Tcnicas de Elicitao dos Requisitos na Engenharia de Requisitos Distribuda 2.4.4.1 Concluses Impacto dos Stakeholders Geogracamente Distribudos na Gerncia de Requisitos em organizaes Multi-Site 2.4.5.1 Concluses
2.4.5
Metodologia de Pesquisa 3.1 3.2 Introduco Objetivos 3.2.1 3.2.2 3.3 3.4 Geral Especcos
Procedimentos Entrevista Semi-Estruturada Exploratria (1) 3.4.0.1 3.4.0.2 Perl dos participantes Entrevista com gerentes de projeto de software oriundos de pesquisa Unidade de Anlise do Estudo de Caso
3.5 3.6
Estudo de Caso - Etapa 1 (2) 3.5.0.3 3.6.1 3.6.2 Anlise dos Resultados - Elaborao (3) Anlise Qualitativa Assistida por Computador Coleta de dados 3.6.2.1 3.6.2.2 3.6.2.3 3.6.2.4 3.6.3 Arquivamento de correios-eletrnicos Logs de Ferramenta de Instant Messaging Atas de Reunio Presencial
Gravao em udio das Reunies de Validao dos Requisitos 37
Instrumento de Anlise dos Dados Seleo de Ferramentas que Dem Suporte ao Processo Proposto
3.7
Proposta de um processo (4) 3.7.1
Anlise da Entrevista Semi-Estruturada 4.1 Entrevista Semi-Estruturada 4.1.1 Participantes da Entrevista Semi-Estruturada 4.1.1.1 4.1.1.2 Projeto 1 Projeto 2
SUMRIO
xvii 42 43 44 44 45 46 48 48 51 51 53 53 54 54 55 56 57 58 59 59 62 62 63 63 64 64 65 67 69 69 70
4.1.1.3 4.2 4.2.1 4.2.2
Projeto 3
Anlise das Entrevistas Processo de Desenvolvimento de Software Processo de Engenharia de Requisitos 4.2.2.1 4.2.2.2 4.2.2.3 Elicitao dos Requisitos Documentao dos Requisitos Validao dos Requisitos
4.3
Requisitos Extrados da Entrevista Semi-estruturada com os Gerentes de Projeto (F2)
Estudo de Caso 5.1 5.2 5.3 5.4 5.5 Descrio do Estudo de Caso Ambiente de Desenvolvimento Participantes do Estudo de Caso Categorizao dos Dados Prticas de Comunicao do Projeto 5.5.1 5.5.2 5.5.3 5.5.4 5.6 5.6.1 5.6.2 5.7 5.7.1 5.7.2 5.7.3 Skype Microsoft Messenger Correio-Eletrnico Lista de Correio-Eletrnico Groove Virtual Ofce Writely Elicitao de Requisitos 5.7.1.1 Prottipo em Papel Negociao dos Requisitos Artefatos de Entrada para a Documentao e Validao dos Requisitos 5.7.3.1 5.7.3.2 5.7.4 Observao 1: Sem o uso de Storyboard como Artefato de Entrada Observao 2: Com o uso de Storyboard como artefato de entrada Seleo da Ferramenta de Edio dos Artefatos Apresentao do Storyboard
Ferramentas Colaborativas de Edio Observadas no Estudo de Caso
Fases Observadas da Engenharia de Requisitos no Estudo de Caso
Documentao de Requisitos 5.7.4.1 5.7.4.2
xviii 5.7.4.3 5.7.5 5.7.5.1 5.7.5.2 5.7.5.3 5.7.5.4 5.7.5.5 5.7.5.6 5.8 6
SUMRIO
Acompanhamento da Documentao Planejamento da Inspeo Distribuir Documento Preparar para Inspeo - Inspeo Assncrona Reunio de Inspeo - Audio-Conferncia Correes da Reviso Revisar o documento
71 72 72 74 75 78 83 84 85 89 90 90 91 92 94 94 95 96 97 98 98 99 100 101 102 102 103 104 104 105 106 106 107 107
Validao dos Requisitos
Requisitos Relacionados Ao Estudo de Caso
Processo Proposto 6.1 6.2 Descrio do Processo Iterao: Elicitao de Requisitos 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.3 Obteno dos Requisitos Iniciais do Sistema Elicitao em Grupo Documentao dos Requisitos Iniciais do Sistema Desenvolvimento do Storyboard Reviso da Elicitao 6.2.5.1 6.2.6.1 6.3.1 6.3.2 6.3.3 6.4 Passos para Execuo Passos para Execuo Retrabalho Reviso de Elicitao
Iterao: Documentao de Requisitos Apresentar Storyboard 6.3.1.1 6.3.2.1 6.3.3.1 6.4.1 6.4.2 6.4.3 6.4.4 Passos para Execuo Passos para Execuo Alternativas Detalhamento dos Casos de Uso Acompanhamento da Documentao
Iterao: Validao dos Requisitos Planejamento de Inspeo Distribuio do Documento 6.4.2.1 6.4.3.1 Passos para Execuo Passos para Execuo Preparao: Inspeo Assncrona Reunio de Inspeo
SUMRIO
xix 108 109 109 110 110 111 111 112 112 113 113 114 115 115 116 116 116 117 117 118 118 118 119 119 120 121 121 123 124 125 125 127 129
6.5
6.6
6.4.4.1 Passos para Execuo 6.4.5 Correo da Inspeo 6.4.5.1 Passos para Execuo 6.4.6 Validao 6.4.6.1 Passos para Execuo Papis e Responsabilidades 6.5.1 Engenheiro de Requisitos 6.5.2 Designer de Interface 6.5.3 Engenheiro de Software 6.5.4 Gerente de Projeto 6.5.5 Stakeholder 6.5.6 Coordenador de Revises 6.5.7 Revisor Tcnico Artefatos do Processo 6.6.1 Base formal de conhecimento do problema 6.6.1.1 Consideraes 6.6.2 Prottipo em Papel 6.6.3 Registro de Reviso 6.6.3.1 Passos para Execuo 6.6.3.2 Formato do Artefato 6.6.4 Requisitos Iniciais 6.6.5 Requisitos do Sistema 6.6.5.1 Consideraes 6.6.6 Documento de Especicao dos Requisitos 6.6.6.1 Descrio dos Atores do Sistema 6.6.6.2 Descrio de Casos de Uso 6.6.6.3 Storyboard
Concluso 7.1 Trabalhos Futuros
A Entrevista Semi-Estruturada A.1 Entrevista com Gerentes de Projeto B Planilha de Coleta de Mtricas C Glossrio
Lista de Figuras
1.1 1.2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8
Principais razes envolvidas no DDS [Pri03] Demada por software x prossionais disponveis [DZ02] Nveis de interao contextual [MH01] Fases da Engenharia de Requisitos Baseado em [KS98] Processo de Inspeo dos Requisitos Baseado em [KS98] Processo para Engenharia de Requisitos Distribuda [Lop03] Efetividade das Tcnicas de Elicitao dos Requisitos em DDS [Llo01] Distribuio geogrca do grupo de stakeholders [DZ02] Fluxo de informao no projeto [DZ02] Modelo de impacto dos desaos e atividades afetadas da Engenharia de Requisitos devido a problemas com o DGS adaptado de Damian [DZ02] Desenho da Pesquisa Arquitetura do AMADeUs-MM [Sou05] rvore de Categoria do NVivo [QSR07] Prottipo em papel desenvolvido durante a elicitao em grupo Storyboard desenvolvido pelo designer de interface Processo de Elicitao dos Requisitos sem Uso do Storyboard Processo de Elicitao dos Requisitos com uso do storyboard Permisses do Artefato: colaboradores e visualizadores [Goo] Publicar Documento [Goo] Inserir comentrio no artefato [Goo]
3 4 9 11 14 18 24 26 27 29 32 52 55 63 64 65 67 75 76 77 85 91 92 99 104
3.1 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9
5.10 Comparar diferentes verses do artefato [Goo] 6.1 6.2 6.3 6.4 Estrutura Analtica do Processo de Desenvolvimento Iterao: Elicitao dos Requisitos Iterao: Documentao dos Requisitos Iterao: Validao dos Requisitos xxi
Lista de Tabelas
4.1 4.2 5.1 5.2 5.3
Projetos Pesquisados Legenda dos Entrevistados
40 44
Participantes Estudo de Caso 54 Mtricas do DER do mdulo desenvolvido na UD1 de 12-01-2006 a 02-02-2006 66 Mtricas do DER do mdulo desenvolvido na UD1 de 13-02-2006 a 24-02-2006 68
xxiii
C APTULO 1
Introduo
H uma dcada o nmero de empresas engajadas no desenvolvimento distribudo de software era pequeno, mas esse cenrio foi modicado. No ano de 2000, 203 das 500 maiores empresas americanas listadas pela US Fortune j utilizavam o offshore outsourcing [CA01], enviando parte da pesquisa e desenvolvimento para outros pases. Existem alguns fatores que impulsionaram o desenvolvimento distribudo entre grandes empresas de software, dentre eles: necessidade de utilizar recurso capacitado onde quer que ele esteja; vantagens de estar prximo de diferentes mercados, conhecendo consumidores e condies locais; formao rpida de organizaes virtuais e equipes virtuais para explorar as oportunidades do mercado; necessidade de diminuir o tempo de entrega do produto para o mercado, conseguido atravs de fusos horrios diferentes uma produo de 24 horas por dia [Pri03]. No processo de desenvolvimento de software, a engenharia de requisitos, uma das fases mais importantes, pois nesta etapa onde so denidas as funcionalidades e o escopo do software a ser desenvolvido [Zow02]. Segundo um relatrio do CHAOS [Int01], publicado pelo Standish Group [TSG05], os maiores problemas no desenvolvimento de software so relacionados com requisitos. Tendo em vista que as especicaes dos requisitos serviro como base para contratos e desenvolvimento do software em questo, ela deve ser clara e no ambgua [ABD+ 04]. Entretanto, cliente, analista e desenvolvedores freqentemente no possuem o mesmo nvel tcnico de conhecimento e tendem a descrever e entender os requisitos de formas diferentes [Byr94]. A Engenharia de Requisitos, a disciplina da engenharia de software que mais faz uso de comunicao entre os envolvidos do projeto [NE00]. No Desenvolvimento Distribudo de Software (DDS), as diculdades encontradas de comunicao, coordenao e cultura aumentam os problemas inerentes da Engenharia de Requisitos (ER) [DZO01]. Sendo assim, os problemas causados por ambigidade e falta de entendimento nos requisitos so intensicados [Lop03]. Segundo o SWEBOK, o desenvolvimento de prottipos muito utilizado para a validao dos requisitos do software em geral [ABD+ 04]. Visando melhorar o entendimento dos requisitos por parte das Unidades Distribudas de Desenvolvimento (UDS) e diminuir a duplicidade 1
CAPTULO 1 INTRODUO
dos requisitos gerados por eles, ser proposto um processo de Engenharia de Requisitos que melhore a documentao e validao dos requisitos no DDS.
1.1
Motivao
Nas ltimas dcadas a globalizao dos negcios impactou tambm a indstria de tecnologia da informao. As foras econmicas transformaram mercados nacionais em mercados globais [HM01]. Essas transformaes no alteraram apenas o marketing da distribuio, mas tambm as formas como os produtos so: criados, construdos, testados e liberados para os clientes nais [ODJ94]. O DDS por si s uma prtica de engenharia de software [HM01], analisando que na ltima dcada a indstria de TI cresceu bastante rumo a globalizao, diversas empresas tm dividido parte do desenvolvimento de software, criando unidades distribudas de desenvolvimento [HM01]. Surgindo a uma grande demanda por servios de outsourcing e conseqentemente um reaprendizado de como as atividades de Engenharia de Software (ES) so realizadas nesse contexto. Essa forma distribuda de desenvolvimento impacta profundamente em todo o processo de desenvolvimento das organizaes, afetando diretamente os meios de comunicaes, coordenao e integrao das atividades no ambiente [CA01] [HM01]. Segundo Nuseibeh [NE00] um dos principais problemas existentes na ER de ordem social. Pois estes no podem apenas serem repassados para mtodos tcnicos disponveis, alm disso a relativa imaturidade nos campos da ER em DDS sugere abordagens bastante eclticas na execuo dos processo de ER em DDS, na busca de tratar os problemas relativos a: distncia, comunicao e coordenao [Zow02]. Diversos fatores tm contribudo para que as empresas distribuam seu processo de desenvolvimento, dentre eles [Pri03] (Figura 1.1): 1. A necessidade de aumentar os recursos quando a disponibilidade de mo de obra estiver escassa. 2. Vantagens de negcio, relativo ao mercado local, incluindo conhecimento dos clientes e das condies locais, alm de melhorar as condies locais atravs de investimentos. 3. A rpida formao de corporaes virtuais e times virtuais visando explorar as oportunidades de mercado. 4. Presses relativas ao time-to-market, com o uso de diferente fuso-horrio , permitindo inclusive o desenvolvimento 24x7 [Car98] follow-the-sun.
1.1 MOTIVAO
Figura 1.1 Principais razes envolvidas no DDS [Pri03]
O mercado americano, responsvel por grande parte da demanda em software, teve esgotadas suas cotas de vistos de trabalho temporrio para rea de tecnologia antes do trmino do ano scal, gerando uma maior escassez por prossionais qualicados [Car98], logo sentiu a necessidade de dividir parte do desenvolvimento com outras localidades. Em termos grcos (Figura 1.2) percebe-se com bastante clareza que nos ltimos anos houve um acrscimo da necessidade por prossionais capacitados. Sendo assim, buscando reduzir custos ao evitar o deslocamento de funcionrios no momento de sua contratao. Muitas delas distriburam o seu desenvolvimento criando unidades de desenvolvimento especializadas, reduzindo custos, quantidade de prossionais com a mesma especialidade e aumentando o nvel de experincia dos mesmos com a execuo de atividades semelhantes [Lop03]. Em um estudo de caso foram identicados campos de estudo relevantes da ER em DDS [DZO01]. Neste artigo, os autores informam que foram consumidos 18 meses na fase de negociao dos requisitos no estudo de caso pesquisado. Um dos fatores fundamentais dessa demora foi a comunicao pobre entre os stakeholders mais relevantes.
0 Indivduos
ou organizaes que so os responsveis pelo sucesso do sistema. [NE00]
CAPTULO 1 INTRODUO
Figura 1.2 Demada por software x prossionais disponveis [DZ02]
1.2
Problema da Pesquisa
A questo que se formula nessa pesquisa, diante do quadro a motivao saber qual a estrutura das prticas de uma equipe de desenvolvimento distribudo de software quanto aos processos relacionados com a validao e documentao dos requisitos. A partir da resoluo desta pergunta, pretende-se: "Propor um processo de documentao e validao dos requisitos para ambientes de desenvolvimento distribudo de software a partir das prticas encontradas num estudo de caso". O caso analisado ocorreu dentro das atividades do projeto Agentes Micromundo e Anlise do Desenvolvimento no uso de Instrumentos Multimdia (AMADeUs-MM) [Sou05]. Este projeto possui um total de 16 integrantes em duas UDS divididos em duas cidades com 800 km de distncia. Devido s divergncias de horrios entre os integrantes, podemos classicar o ambiente de desenvolvimento do estudo de caso como de Distncia Nacional e nveis de disperso Temporal e Geogrca conforme o modelo de referncia de Prikladnicki [PAE04]. Por conta destas caractersticas esse projeto serviu como estudo de caso para a elaborao do processo de Engenharia de Requisitos proposto neste trabalho. 1.2.1 Contribuio
O objetivo principal desta pesquisa a denio de um processo de Engenharia de Requisitos para ambientes de desenvolvimento distribudo de software. Deseja-se que esse processo de
1.3 ORGANIZAO DA DISSERTAO
Engenharia de Requisitos, seja mais adequado possvel para a documentao e validao dos requisitos em ambientes distribudos de desenvolvimento. Para atingir nosso objetivo principal por intermdio de um estudo de caso [Yin05] chegamos a algumas contribuies intermedirias como : Anlise do uso de prottipos de baixa delidade, como artefato de entrada para a documentao e validao dos requisitos em ambientes distribudos de desenvolvimento. Os impactos existentes ao se tentar realizar a elicitao dos requisitos de forma distribuda. Testamos o uso de ferramentas colaborativas no intuito de diminuir o impacto das distncias geogrcas e temporais. Anlise do uso de ferramentas de Voz Sobre IP (VoIP) para realizar as atividades de validao dos requisitos dos requisitos em ambientes de DDS.
1.3
Organizao da Dissertao
Este documento est estruturado em 7 captulos. O presente captulo apresenta a motivao desse trabalho, nosso problema de pesquisa visando elaborar um processo de engenharia de requisitos para desenvolvimento distribudo de software e por m sua contribuio. No Captulo 2 introduzimos a necessidade do uso de processo de engenharia de requisitos no desenvolvimento de software, bem como a problemtica existente para a conduo do mesmo em ambientes DDS. Nesse mesmo captulo selecionamos e descrevemos trabalhos relacionados que contriburam para a concepo desse trabalho. No Captulo 3, denida a metodologia de pesquisa realizada para a realizao desse trabalho. Nessa metodologia esto previstas a realizao de uma entrevista semi-estruturada [Fli04] com gerentes de projeto que possuem alguma caracterstica de desenvolvimento distribudo de acordo com o modelo de referncia de Prikladnicki [Pri03]. Posteriormente foi realizada uma observao participante [Fli04] em um estudo de caso [Yin05]. No Captulo 4, so apresentadas a anlise das entrevistas realizadas e no Captulo 5, so apresentados os resultados da observao participante realizada no estudo de caso. Como resultado dessa pesquisa foram gerados requisitos (Seo 4.3 e Seo 5.8) que daro suporte a proposio do processo no Captulo 6. O processo de Engenharia de Requisitos proposto neste trabalho e as ferramentas utilizadas para a sua execuo esto descritos no Captulo 6.
CAPTULO 1 INTRODUO
As concluses, limitaes identicadas e as sugestes de trabalhos futuros caram no Captulo 7.
C APTULO 2
Engenharia de Requisitos no Desenvolvimento Distribudo
Neste captulo iremos abordar a Engenharia de Requisitos, descrevendo os principais conceitos existentes na rea e uma viso geral de processos de Engenharia de Requisitos. Logo aps, sero explanados: conceitos e motivaes do desenvolvimento distribudo de software. Ao nal teremos uma descrio dos trabalhos relacionados de Engenharia de Requisitos no desenvolvimento distribudo de software.
2.1
Desenvolvimento Distribudo de Software
H mais de uma dcada, visando diminuir custos e buscando recursos mais qualicados, muitas organizaes comearam a experimentar o desenvolvimento distribudo de software [HM01]. A partir da demanda da indstria o assunto passou a ser abordado em congressos internacionais [ICoGSE06], alm do surgimento de grupos de pesquisa bastante expressivos na rea [MUN06] [TSL06]. O DDS caracteriza-se pela distncia fsica e/ou temporal entre alguns stakeholders (cliente, usurio e desenvolvedores, por exemplo) envolvidos no processo de desenvolvimento [Pri03]. No Brasil esse tema tende a ser mais explorado, devido a grande quantidade de empresas que esto implantando unidades de desenvolvimento distribudo no pas.
2.1.1
Desaos do Desenvolvimento Distribudo de software
Nesta seo esto expostos os desaos encontrados na literatura no que se refere ao desenvolvimento de software quando realizado por equipes distribudas de desenvolvimento. Baseado em um modelo estatstico, Herbsleb [HMFG01], demonstrou que o DDS leva muito mais tempo de ser concludo do que o Desenvolvimento Centralizado de Software (DCS). Segundo o autor problemas de comunicao e coordenao, so os principais responsveis por esse atraso. 7
CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO
2.1.1.1
Comunicao
Com o crescimento do desenvolvimento distribudo de software os engenheiros, gerentes e executivos tm se confrontado com prossionais de diferentes nveis: tcnicos, sociais e culturais [HM01]. A resoluo dessas diferenas j bastante complicada localmente onde existe a comunicao face a face, pois as diferenas de vocabulrio, termos tcnicos e formas de abordagem social, dicultam a comunicao. Num ambiente distribudo de desenvolvimento esse problema torna-se ainda maior, pois os meios de comunicao como: correio-eletrnico, chats e ligaes telefnicas, no so to ricos quanto comunicao face a face [HM01] [DZ02] Figura 2.1. Na fase inicial do desenvolvimento de software, muita comunicao requerida, para o incio das denies do projeto [PSV94]. Nesse contexto existem duas formas complementares de comunicao, primeiramente, a formal, que a comunicao ocial que deve ser passada com bastante clareza. Principalmente em tarefas cruciais como atualizao de status de projeto, reorganizao, determinao de papis, etc. Uma comunicao confusa ou mal especicada, poder levar a equipe a perder tempo e gerar problemas de coordenao no projeto [HM01]. Em segundo plano, a comunicao informal um excelente canal para reportagem de tarefas, percepo de como andam as atividades perante o grupo. As "conversas de corredor", ajudam as pessoas a terem percepo do andamento do projeto, facilitando o trabalho em grupo e auxilia na resoluo de problemas tcnicos, melhorando a ecincia dos desenvolvedores [DZ02]. A partir do momento que a comunicao for mais presente entre os membros, e as ferramentas colaborativas possam prover comunicao informal sncrona haver um aumento na percepo do grupo virtual. Comeando ento a construir importantes relaes de conana na comunicao remota [DZ02]. Contudo a escolha do meio de comunicao para a realizao de determinadas tarefas exige bastante cuidado. Por exemplo, um gerente de DDS deve, regularmente, transmitir a viso de equipe para todos os grupos, de forma a contextualizar o time a respeito do andamento do projeto. Esse meio de comunicao dever prover nveis altos de motivao e emoo [CA01]. Existem casos em que a comunicao sncrona pode ser menos apropriada do que a assncrona. Como por exemplo numa ligao telefnica (sncrono) pode ocorrer problemas do tipo "Eu j te disse isso", enquanto que num correio eletrnico (assncrono) o escrito histrico servir como documentao do que fora relatado [CA01].
2.1 DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE
Figura 2.1 Nveis de interao contextual [MH01]
2.1.1.2
Integrao
Para integrar as equipes necessrio possuir um repositrio de artefatos do projeto contendo: Documento de Especicao dos Requisitos (DER), bugs encontrados, processos e termos utilizados. Esse repositrio deve ser mantido e compartilhado com rigor, pois diminui a distncia entre as UDS, auxilia no entendimento dos requisitos, e aumenta a percepo do andamento do projeto [DZ02]. Existem diversos estudos relacionados a ferramentas colaborativas de edio assncrona [AG98] [Bri06] para a ER. Estas ferramentas tornam-se um repositrio para requisitos, permitindo ainda o compartilhamento do DER com os demais stakeholders. Isso diminui a distncia entra as UDS [DZ02]. 2.1.1.3 Coordenao
No contexto de DDS necessrio que o processo de desenvolvimento do software seja nico, bem denido e conhecido pelas equipes distribudas. A coordenao de um projeto sendo executado com processos distintos pode ser mais complicada para o gerente de projeto [EF99]. Quando as equipes distribuem os processos em diversas localidades, a falta de sincronizao pode se tornar crtica. Pois um nico processo bem denido e treinado fornece um conjunto comum de expectativas aos elementos envolvidos, impondo rigor e disciplina equipe [CA01].
10
Para haver alinhamento no processo necessrio que haja rotina na comunicao pois a falta dela poder gerar surpresas advindas de diferentes locais, resultando num desalinhamento da equipe e ,conseqentemente, em retrabalho. Quando as equipes esto distribudas, o nvel de sincronizao torna-se particularmente crtico. Por exemplo, no caso em que um time est desenvolvendo testes unitrios diferentemente do que est sendo desenvolvido. A sincronizao nesse processo requer marcos bem denidos e critrios de entrada e sada bastante claros para toda a equipe [RP95]. Herbleb [HM01] defende que os avanos das ferramentas colaborativas agregada a multimdia venham melhorar o desenvolvimento distribudo de software. Estudos indicam que uma especicao de requisitos mal redigida impacta diretamente nas atividades a serem desenvolvidas de forma distribuda [HM01]. Apesar dos desenvolvedores resistirem elaborao de documentao, ela se faz necessria para aumentar a congruncia da equipe. Portanto no desenvolvimento distribudo, a documentao dos artefatos, bem como a sua atualizao e reviso por diferentes responsveis pelo software (Gerentes de Projeto, Analista de Sistemas, Engenheiro de Usabilidade e Clientes) faz-se necessria.
2.2
Engenharia de Requisitos
Os requisitos denem quais sero os servios que o sistema dever prover alm de um conjunto de restries existentes na operao do sistema [KS98]. Para Nuseibeh [NE00] a Engenharia de Requisitos o processo de descobrir o propsito do software, identicando os stakeholders com suas respectivas necessidades e documentando a anlise realizada para uma implementao subseqente. O contexto em que a ER est centrada na atividade de entendimento do comportamento humano [NE00], visando buscar solues para os problemas das pessoas. Assim, a ER usa mecanismos de sensibilidade para entender como as pessoas percebem o mundo e como suas aes interagem com a sociologia do ambiente [NE00]. Geralmente os requisitos so escritos em linguagem natural, ento uma comunicao clara extremamente importante para a especicao dos requisitos, pois evitam a ambigidade e aumentam o entendimento dos mesmos [NE00]. Logo so necessrios um conjunto de tcnicas empregadas para levantar, detalhar, documentar e validar os requisitos de um produto. O uso do termo "Engenharia"implica que tcnicas sistemticas e repetidas devem ser aplicadas para certicar que os requisitos de um sistema estejam completos, consistentes e relevantes [Som04]. O emprego correto da Engenharia de Requisitos um passo fundamental para o desenvolvimento de um bom produto, onde a satisfao do usurio deve ser o principal objetivo a ser atingido
2.3 PROCESSO DE ENGENHARIA DE REQUISITOS BASEADO EM DDS
11
[Did03].
2.3
Processo de Engenharia de Requisitos Baseado em DDS
Uma completa compreenso dos requisitos de software fundamental para um desenvolvimento de software bem sucedido. No importa quo bem projetado ou quo bem codicado seja um programa, se ele for mal analisado e especicado dicilmente atender s expectativas do usurio [Byr94]. Neste trabalho, detalharemos o processo1 de Engenharia de Requisitos, proposto por Kotonya e Sommervile em [KS98], o qual descreve as atividades de: elicitao, anlise, documentao e validao como sendo as etapas do processo de engenharia de requisitos, conforme apresentado na Figura 2.2.
Figura 2.2 Fases da Engenharia de Requisitos Baseado em [KS98]
Sabemos que difcil denir um plano seqencial de atividades que descrevam adequadamente o processo de Engenharia de Requisitos [Zow02]. Para Carmel [CA01] fundamental que o processo de desenvolvimento entre as equipes distribudas, seja um processo nico, pois a falta de sincronizao das atividades pode se tornar crtica. Um processo dene um conjunto de atividades que devem ser conhecidas por todos os membros da equipe, impondo rigor na equipe. Por ser realizado em ambientes DDS importante identicar as diferenas entre os meios de comunicao utilizado na execuo das atividades referentes ER. Por exemplo: O correio eletrnico apesar de facilitar a comunicao entre os stakeholders, diculta no gerenciamento
1 Um
processo um conjunto de atividades que transformam entradas em sadas.
12
das discusses e essa forma assncrona de tomada de deciso pode demandar bastante tempo para atingir o consenso [Zow02]. Para Zowghi [Zow02], os problemas existentes no DDS fazem com que seja necessrio criar um processo especco para a ER em DDS. Herbsleb, por sua vez, sugere uma soluo de processo concorrente de desenvolvimento de software nesse contexto, porm segundo ele a aplicao e implantao dos princpios de engenharia concorrente em ambientes de desenvolvimento distribudo se tornam difceis, com requisitos instveis ou volteis [HM01]. Herbsleb defende tambm que boas ferramentas colaborativas podem auxiliar na estabilidade dos requisitos havendo uma diminuio do tempo e espao entre as equipes distribudas [HM01]. O resultado principal de todo esse processo de engenharia de requisitos a produo de um DER, que o principal artefato produzido pela Engenharia de Requisitos. Ele deve descrever de forma clara e precisa cada um dos requisitos do software juntamente com suas interfaces externas. Um DER, em geral, serve como base para acordos formais entre clientes e fornecedores, com relao ao que o software dever prover [HP00].
2.3.1
Elicitao de Requisitos
A elicitao dos requisitos consiste em saber a origem dos requisitos e como o analista de sistemas poder colet-los. Elicitao de requisitos uma das atividades mais importantes na ER, sendo o primeiro passo na captura dos requisitos. Durante a coleta necessrio que sejam elaboradas as perguntas corretas, buscando encontrar os problemas a serem solucionados [NE00]. Num primeiro momento, construdo o entendimento do problema que o software pretende resolver. Para a captura, descobrimento e aquisio dos requisitos fundamental a existncia e interao entre stakeholders, equipe de desenvolvimento e clientes [ABD+ 04]. sabido que o conhecimento adquirido durante a elicitao dos requisitos tende a ser mais profundo que o conhecimento contido no DER [Lop03]. Portanto, no surgimento de dvidas relativas ao DER ocorre num grande volume de comunicao informal entre os integrantes. Atravs das tcnicas de elicitao em grupo obtm-se um maior entendimento e acordo dos requisitos elicitados. Nessas tcnicas esto inclusas: brainstorming, grupo-focal assim como workshops [NE00]. A partir dessas constataes a documentao dos requisitos por uma equipe distribuda a qual no participou das sesses de elicitao torna-se um desao.
13
2.3.2
Documentao de Requisitos
O documento de requisitos de software - s vezes chamado de DER ou especicao de requisitos de software - a declarao ocial do que exigido dos desenvolvedores do sistema. Ele deve incluir os requisitos para o cliente e/ou usurio e uma descrio detalhada dos requisitos do sistema. Em alguns casos, eles so integrados em uma nica descrio [Som04]. Para clientes, desenvolvedores e demais envolvidos no desenvolvimento do software um DER bem especicado deve prover os seguintes benefcios [Byr94]: 1. Estabelecer a concordncia no que o software se prope a fazer perante clientes e demais envolvidos no desenvolvimento do software. 2. Reduzir o esforo de desenvolvimento; 3. Subsdios para estimar custo e prazo; 4. Uma verso comum para todos os envolvidos no projeto, visando validao e vericao; 5. Facilidade de transferncia de desenvolvimento; 6. Servir de base para futuras melhorias. 7. Prover o suporte necessrio para a validao dos requisitos entre os stakeholders do sistema. 2.3.3 Validao de Requisitos
A validao dos requisitos, consiste em checar se o documento de requisitos est consistente, completo e claro [KS98]. Ela a ultima fase do processo de ER, isso signica dizer que quando os requisitos esto "validados"eles contemplam a descrio do sistema que ser implementado [KS98]. uma atividade complexa por dois motivos: o primeiro reside na diculdade de identicar todos os requisitos juntamente ao cliente; e o segundo de razo social, por conta da diculdade de atingir o consenso entre os diferentes responsveis pelo software, principalmente quando estes possuem objetivos conitantes [NE00]. Os conitos ainda pendentes entre os stakeholders devem ser resolvidos atravs da realizao de reunies de validao para que haja uma estabilidade nos requisitos validados [NE00]. O principal motivo da realizao da validao dos requisitos garantir que o analista do sistema compreendeu corretamente os requisitos ao assegurar que o mesmo esteja claro, completo e consistente [ABD+ 04]. Essa fase importante por envolver vrios integrantes do projeto com diferentes vises (engenheiro de requisitos, stakeholders, gerente de projeto) na busca por erros no documento de requisitos mitigando o esforo gasto em retrabalho nas etapas posteriores do projeto. Esse esforo se justica pelo fato de que em geral uma mudana nos requisitos,
14
impacta em modicao na implementao do sistema [Som04]. Durante a elicitao dos requisitos o foco da anlise nas necessidades dos stakeholders. Seria ideal que o documento de requisitos apenas inclusse requisitos aceitos pelos mesmos. Entretanto, inevitavelmente, alguns stakeholders descobrem problemas nos requisitos durante a validao necessitando voltar as atividades de elicitao dos requisitos [KS98]. 2.3.3.1 Inspeo de Requisitos
A inspeo dos requisitos a tcnica mais utilizada para realizar a validao dos requisitos [KS98]. Existe diversos trabalho que comprovam a efetividade da tcnica [GG93] [Wel93] , que vem sendo renada ao longo dos anos com o uso de sistemas colaborativos [MDTR93] [GHB03] para a sua realizao. Ela envolve a seleo de alguns integrantes do projeto que cam responsveis por ler, analisar os requisitos na busca por problemas, discuti-los e concordar com as aes a serem tomadas. Apesar de ser um meio onde h muita alocao de recursos (engenheiros de software, arquitetos, engenheiro de requisitos, gerente de projeto e etc), a realizao de inspeo dos requisitos do software logo no incio do desenvolvimento, considerada uma boa prtica [Wit00]. Com o uso desta tcnica, possvel remover os defeitos logo nas fases iniciais do processo de desenvolvimento [Wit00], reduzindo os custos gastos com retrabalho. A inspeo dos requisitos proposta neste trabalho tem o objetivo de: 1. assegurar o padro de qualidade dos artefatos; 2. evitar a ambigidade dos requisitos; 3. evitar o baixo nvel de detalhamento dos mesmos. Kotonya e Sommerville, basearam-se em Tom Gilb [GG93] para propor o seu processo de inspeo. A Figura 2.3 demonstra esse processo.
Figura 2.3 Processo de Inspeo dos Requisitos Baseado em [KS98]
15
As atividades do processo de inspeo so as seguintes: Planejar inspeo : Seleciona-se o time de inspeo, denindo data, horrio e local para a reunio. Distribuir documentos : Os documentos de requisitos e qualquer outro artefato relevante so distribudos para a equipe de inspeo. Preparar para a inspeo : Cada inspetor l o documento visando identicar conitos, omisses, inconsistncias, no seguimento dos padres do artefato e outro problemas. Reunio de inspeo : Os comentrios individuais e os problemas so discutidos e as aes so tomadas para resolver os problemas encontrados. Correes da inspeo : O coordenador de revises ir assegurar que todas as aes foram efetuadas. Revisar o documento : O documento revisado reetindo as aes acordadas. Nesse momento o artefato poder ser considerado validado. Caso contrrio ser necessrio a realizao de outra inspeo. Ao aplicar o modelo de processo de inspeo proposto por Kotonya e Sommerville (Figura 2.3) dentro do ambiente de DDS, a literatura aponta para a necessidade de usar um conjunto de ferramentas colaborativas para executar esse processo nesse ambiente [BV05], [Zow02], [CA01]. Atravs dessas ferramentas ser possvel, por exemplo, facilitar a distribuio dos documentos com o uso de um editor de texto colaborativo [Goo] e viabilizar reunies de inspeo por intermdio dos meios de comunicao sncronos. A seleo dos inspetores deve ser bastante criteriosa. ideal que o documento de requisitos possa ser revisto por uma equipe multidisciplinar, vindo de integrantes com diferentes habilidades [KS98]. Um dos problemas a serem enfrentados pelos inspetores o de entendimento dos requisitos, possivelmente a partir do uso dos storyboards 2 poderemos melhorar essa atividade. Contudo o conhecimento adquirido pelo autor durante a documentao muito maior do que a documentao por ele elaborada. Na falta desse conhecimento poder haver impacto na compreenso dos mesmos. Visando preencher essa lacuna prudente que entre os inspetores devam estar inclusos os participantes da fase de elicitao dos requisitos. Estes, devem saber o que precisa ser documentado, caso isso no seja possvel que ao menos um especialista do domnio esteja engajado nesse processo.
de interface de mdia-delidade que contm uma srie de desenhos ou imagens que representam como a interface utilizada para desempenhar determinada tarefa.
2 Prottipo
16
2.3.4
Prototipagem Durante a Engenharia de Requisitos
A prototipagem pode ser usada como uma tcnica de anlise e reduo de riscos. Um risco signicativo no desenvolvimento de software so os erros e as omisses dos requisitos. Geralmente os prottipos so utilizados para vericar a interpretao do analista de sistemas, assim como para elicitar novos requisitos. Possibilitando ao stakeholder fornecer feedback e sugestes de melhorias para a resoluo dos problemas encontrados no prottipo [ABD+ 04]. Combinada com outras tcnicas como por exemplo, podemos ter uma instncia de um prottipo o qual pode ser utilizado para provocar discusses em grupos de elicitao [NE00]. Os desentendimentos entre usurios e desenvolvedores so expostos nos prottipos, identicandose assim, defeitos e confuses nos requisitos elicitados e documentados. Atravs do seu desenvolvimento ser possvel auxiliar clientes e desenvolvedores no entendimento dos requisitos do sistema, sendo utilizada como artefato de entrada para o DER auxiliando no nvel de detalhe da especicao dos requisitos e conseqentemente reduzindo o risco de retrabalho [Som04]. O principal propsito dos prottipos desenvolvidos para as etapas de elicitao e validao dos requisitos ser demonstrar as funcionalidades do software, devendo ser desvinculado do acabamento do mesmo. Por essa razo existem recomendaes para que sejam utilizados prottipos de baixa delidade [ABD+ 04]. Segundo o padro IEEE-830 [Byr94], os prottipos so teis pelas seguintes razes: Os usurios podem ter uma viso mais amigvel visualizando um prottipo do que lendo um DER. Isso prov um rpido feedback. Os prottipos antecipam aspectos do comportamento do sistema. Isso produz no apenas respostas, mas tambm novos questionamentos, bastante importantes durante a fase de elicitao dos requisitos. Um DER baseado em prottipos tende a possuir menos mudanas durante o desenvolvimento, diminuindo o tempo gasto na Engenharia de Requisitos. Auxiliando na validao do DER. Segundo Kotonya [KS98] os prottipos so apenas utilizados para demonstrar os requisitos funcionais do sistema. Logo no podem ser utilizados para requisitos no funcionais do software como: usabilidade, performance, ecincia, segurana e demais requisitos no funcionais. Tcnicas como prototipagem, especicao e o uso de cenrios auxiliam na transcrio do problema no mundo real. Porm, isso no garante que os aspectos das necessidades dos stakeholders estejam cobertos [NE00], os prottipos podem ser:
17
Evolucionrios fornecer um sistema funcional aos usurios nais. Normalmente esse processo se inicia com os requisitos do usurios que so bem compreendidos e com os que tm maior prioridade [Som04].
Descartveis sua principal funo validar ou elicitar novos requisitos do sistema. Sendo preciso comear com aqueles que no so bem compreendidos, porque preciso saber mais sobre eles. Os prottipos descartveis tm uma durao muito curta, sendo possvel modic-los muito rapidamente durante o desenvolvimento, mas a facilidade de manuteno a longo prazo no exigida [Som04].
Os prottipos descartveis no precisam ser prottipos executveis de software para que sejam teis no processo de ER. Os modelos com base em papel, da interface com o usurio de sistema, se mostram bastante efetivos no entendimento dos requisitos [Som04]. Apesar do desenvolvimento de prottipos aumentar o custo gasto nas fases iniciais do sistema, eles podem evitar o uso de recursos no desenvolvimento de requisitos errados, logo esse custo justicado [NE00] [Som04]. Durante o desenvolvimento distribudo onde a fase de elicitao realizada em uma localidade e o detalhamento dos requisitos desenvolvida em outra o uso de prottipos com o intuito de evitar o desenvolvimento errneo dos requisitos essencial. Segundo Kotonya [KS98] se um prottipo foi desenvolvido para a elicitao dos requisitos, faz sentido que ele seja renado e usado no processo de validao dos requisitos. Porm a criao de prottipos apenas para a validao dos requisitos no compensador, pois perde-se todos os benefcios que o uso dos prottipos traria nas etapas inicias do processo de ER. O formato do prottipo deve facilitar a discusso do grupo e as intervenes do stakeholder, para que as tcnicas de brainstorming possam uir com mais naturalidade. A fase de elicitao se dar por concluda quando for realizado o renamento exaustivo do prottipo por todos os stakeholders, atingindo a estabilidade necessria para nalizar a fase de elicitao. A proposta desse trabalho realizar a documentao e validao dos requisitos em ambientes distribudos de desenvolvimento. Para isso consideramos essencial o uso dos prottipos desenvolvidos durante a elicitao dos requisitos como artefato de entrada para a documentao e validao dos requisitos em ambientes DDS.
18
2.4
2.4.1
Trabalhos Relacionados
Processo de Requisitos alinhado com o CMM
Lopes [Lop03] prope um processo de engenharia de requisitos alinhado com o Capability Maturity Model (CMM) visando reduzir as diculdades causadas pela distribuio da equipe durante a fase de requisitos. Sua pesquisa consiste em testar etapas de entendimento e adaptao do DER entre as equipes distribudas. O CMM tem o intuito de auxiliar as organizaes de software a atingirem a maturidade de seus processos de uma maneira evolucionria, podendo passar de processos caticos a processos maduros e disciplinados. No processo proposto, existe a distribuio da equipe de especicao e equipe de desenvolvimento. A equipe de especicao realiza reunies presenciais com o usurio e a equipe de desenvolvimento implementa o software baseado no DER denidos pela equipe de especicao. Esse processo tem um total de cinco etapas como mostrado na Figura 2.4 e descrito abaixo.
Figura 2.4 Processo para Engenharia de Requisitos Distribuda [Lop03]
2.4.1.1
Etapas do Processo
Como podemos ver na Figura 2.4 o processo proposto por Lopes [Lop03], consiste nas seguintes etapas: A) Envio do DER para a equipe de desenvolvimento; B) Anlise do DER pela equipe de desenvolvimento; C) Envio do DER para aprovao da equipe de especicao;
2.4 TRABALHOS RELACIONADOS
19
D) Validao do DER pela equipe de especicao; E) Verso nal do DER denida. Envio do DER para a equipe de desenvolvimento: Enquanto realiza as etapas de elicitao, anlise, negociao e especicao junto aos stakeholders, a equipe de especicao cria uma verso inicial do DER e envia para a equipe de desenvolvimento, no intuito de haver familiarizao com o artefato. Anlise do DER pela equipe de desenvolvimento: A anlise do DER pela equipe de desenvolvimento deixa a equipe de desenvolvimento engajada na especicao desde o incio da idealizao do software, permitindo um melhor entendimento dos motivos que geraram o requisito. Entretanto, com o surgimento de novas demandas, so realizados muitos contatos entre a equipe de especicao e os stakeholders, tornando o acompanhamento da evoluo dos requisitos por parte da equipe de desenvolvimento mais complexo. J que o conhecimento obtido durante o processo de criao do documento tende a ser mais profundo do que as informaes contidas no prprio documento. Ao receber o DER da equipe de especicao, necessrio que a equipe de desenvolvimento busque o entendimento da especicao e seu contexto. Durante esta etapa so feitas adaptaes no DER para reduzir eventuais fontes de problema. A atividade de reescrita permite que o conhecimento adquirido no seja perdido. Porm dvidas podem surgir e precisam ser esclarecidas com a equipe de especicao, causando um grande volume de comunicao entre as equipes. A comunicao entre as equipes visa obter: esclarecimentos e consenso quanto especicao em construo. Por vezes os esclarecimentos solicitados equipe de especicao podem demandar novos contatos com usurios e clientes aumentando a qualidade de especicao. Envio do DER para aprovao da equipe de especicao: Uma vez que o DER foi adaptado ou reescrito, o novo documento precisa ser aprovado. Ao trmino dessa etapa de anlise do DER por parte da equipe de desenvolvimento, o documento enviado para vericao pela equipe de especicao. Validao do DER pela equipe de especicao: A equipe de especicao deve assegurar que aps as mudanas o DER ainda represente as necessidades e caractersticas solicitadas pelos stakeholders. Com as diversas interaes realizadas durante a segunda etapa, permite que a equipe de especicao acompanhe o processo de adaptao do DER, reduzindo o esforo necessrio para a validao. Verso nal do DER denida: Aps aprovao pela equipe de especicao, a verso nal
20
do DER denida com aprovada. Esta verso ento utilizada pela equipe de desenvolvimento como base para a modelagem, codicao e testes do software. O modelo de qualidade de software CMM recomenda, em uma de suas reas chave, que os requisitos sejam acordados por todos os stakeholders. Para que este acordo seja obtido indispensvel a completa compreenso dos requisitos pelas partes envolvidas. Em ambientes de DDS isso envolve, muitas vezes, sobrepor barreiras de linguagem e cultura. 2.4.1.2 Concluses
Uma das grandes contribuies desse trabalho uma grande interao existente entre diferentes equipes (desenvolvimento e especicao). No nosso trabalho buscamos aumentar a interao entre as UDS na fase de documentao, isso permitiu que o artefato fosse revisado durante essa fase, e conseqentemente diminuir o esforo gasto durante a fase de validao. O autor reconhece que alm da distribuio entre as equipes de especicao e desenvolvimento, pode haver distribuio entre a equipe de especicao e os stakeholders, afetando ainda mais as etapas da Engenharia de Requisitos que envolvem estes grupos, como destacado por [DZ02]. 2.4.2 MuNDDoSS - Um Modelo de Referncia para o Desenvolvimento Distribudo de Software
Prikladnicki [Pri03], prope um modelo de referncia para a rea de DDS, contemplando as dimenses tcnicas e no-tcnicas alm dos fatores envolvidos em cada um delas. O autor tirou tais concluses baseado em dois estudos de caso realizados em um centro no Brasil, atravs de uma empresa global de desenvolvimento de software. Nesse trabalho, atravs do confronto entre a teoria e as descobertas empricas o autor pde apresentar oito lies apreendidas, que foram as bases de sustentao para o modelo de referncia proposto. Dentre essas oito, o autor identica como sendo "A Engenharia de Requisitos o maior desao no ponto de vista do processo de desenvolvimento de software"[Pri03]. Os entrevistados dessa pesquisa mencionaram que pelo fato de o projeto ser distribudo, os requisitos devem ser passados com o maior nvel de detalhe possvel, sem margem para falsas interpretaes. A Engenharia de Requisitos aplicada nesse contexto distribudo de desenvolvimento considerada um grande desao, na exata medida em que devem ser encontradas as melhores formas de: identicar, analisar, negociar, e documentar os requisitos. Atravs de ferramentas de apoio alm de tcnicas que permitam uma maior proximidade das equipes distribudas, juntamente
21
com clientes e usurios, sendo os dois ltimos responsveis por identicar os requisitos do projeto em um nvel mais alto. Praticamente todas as entrevistas realizadas com os gerentes de projetos e lderes tcnicos apontaram para diculdades nas atividades que envolvem a Engenharia de Requisitos. Em um dos projetos a instabilidade dos requisitos foi o maior problema, principalmente devido distncia entre as equipes, o que dicultava o entendimento dos requisitos e a convergncia de idias. Em todos os projetos, os requisitos foram identicados como um grande desao, envolvendo atividades desde a realizao de reunies at a formalizao (documentao) dos requisitos que eram denidos, a rastreabilidade e controle dos mesmos. 2.4.2.1 Concluses
O autor conclui que existem problemas constantes na execuo da Engenharia de Requisitos em ambientes de DDS. Eles foram encontrados desde a necessidade de identicar os requisitos do projeto, passando pela anlise, especicao, validao e gerncia. Buscamos, ento, neste trabalho atacar a sistematizao da validao dos requisitos. Contudo antes de validar os requisitos de forma distribuda, devemos document-lo de forma consistente para que ele possa ser validado.
2.4.3
Suporte Engenharia de Requisitos no Desenvolvimento Distribudo de Software
Brito [Bri06], props um processo de Engenharia de Requisitos distribuda e desenvolveu uma ferramenta open-source de ambiente de desenvolvimento de software (ADS) chamada de COoperative and DIstributed Process Support Environment (CODIPSE) a qual fornece suporte as equipes distribudas na execuo desse processo. Na ferramenta esto inclusos: um modelo de rastreamento originado desse processo o qual vincula diferentes tipos de informao, provenientes das ferramentas de groupware fazendo um gerenciamento de requisitos em que auxilia na compreenso do rationale3 . Registrando informaes relacionadas entre si, possibilitando responder a seguinte pergunta: quais informaes originaram determinada informao? Esse processo foi denido com base em dois outros processos existentes: o primeiro descreve um processo para web baseado no Rational Unied Process (RUP) [Did03] e o segundo descreve um processo de Engenharia de Requisitos para desenvolvimento distribudo [Lop03].
usado para identicar as motivaes, razes e/ou justicativas para um determinado requisito existir. Os artefatos armazenados so: reunies, correios-eletrnicos, resultados de pesquisas, entre tantos outros que possam contribuir para a sua denio. Ao longo do tempo, esse rastreamento auxiliar na construo de um histrico do projeto [Bri06].
3 Termo
22
Apesar do trabalho de Lopes [Lop03] tambm apresentar um processo para Engenharia de Requisitos Distribuda, ele no faz uso de tecnologias colaborativas, mesmo considerando a importncia de sua utilizao. Nessa proposta, os participantes esto totalmente distribudos e usam um ambiente adequado para trabalhar colaborativamente. importante ressaltar que embora exista uma distino clara entre as etapas da ER, algumas delas comumente ocorrem em paralelo [KS98]. Viso geral do processo de Engenharia de Requisitos proposto, ele considera a interao com trs bases de conhecimento: (1) formais contendo informaes sobre: o processo em execuo, clientes e usurios; (2) informais contendo dicas sobre a execuo do processo e informaes sobre cultura, idioma e histrico de interaes com os clientes; (3) informaes sobre o negcio, agrupando dados sobre o projeto atual tais como: documentos e artefatos gerados. Juntas essas bases auxiliam no fornecimento de informaes contextuais para os participantes. A proposta CODIPSE visa construir um ambiente de desenvolvimento de software centrado em processo ou Process-Centered Software Engineering Environment (PSEE) utilizando tecnologias de colaborao para auxiliar na denio e execuo de processos de software em equipes distribudas. Devido ao escopo ser muito abrangente a autora decidiu tratar apenas a disciplina de requisitos, pois ela encontrou na literatura poucas propostas que dem o suporte Engenharia de Requisitos de forma colaborativa dentro do desenvolvimento open source. Ela salienta ainda que os ambientes colaborativos de open source atuais do o suporte ao desenvolvimento de software distribudo mas apenas tratam da colaborao durante a edio de modelos de anlise do projeto e nas atividades de codicao [GMH00]. A autora estendeu o eGroupware [GRO06] devido facilidade de integrao e desenvolvimento de novas aplicaes na sua plataforma, o qual utiliza uma soluo baseada em templates (onde possvel construir a interface grca apenas descrevendo os campos e listagens). Reaproveitando um conjunto de aplicativos que favorece e estimula a cooperao entre equipes, tais como: calendrio compartilhado, base de conhecimento, fruns e wiki. A aplicao CODIPSE possui trs mdulos principais: Gerenciamento de Requisitos: agrupando funcionalidades para manuteno de projeto como viso/escopo, casos de uso, requisitos funcionais e no funcionais, glossrio e atores; Manuteno do Rationale: agrupa funcionalidade para criar links para as demais ferramentas de colaborao do ambiente. Os links podem ser criados em nvel de projeto, casos de uso ou requisitos, permitindo a completa manuteno do histrico do projeto; Exportao: esse mdulo responsvel pela gerao intermediria (em Extensible Markup Language (XML)) dos dados presentes em um determinado projeto. A partir dessa verso
23
possvel exportar as informaes para qualquer formato atravs de transformao The Extensible Stylesheet Language Family (XSL) . 2.4.3.1 Concluses
Esse trabalho est muito relacionado nas etapas iniciais da ER, inclusive o rastreamento proposto pelo mesmo abrange essas etapas iniciais. Nosso trabalho na ER de forma distribuda inicia na etapa de documentao dos requisitos e validao dos mesmos. Consideramos tambm que o uso das tecnologias colaborativas, essencial para a Engenharia de Requisitos realizada em ambientes distribudos de desenvolvimento. Um ambiente web, permite que todos os envolvidos no projeto possam ter um nico repositrio de artefatos e acess-los atravs de um navegador web. 2.4.4 Efetividade das Tcnicas de Elicitao dos Requisitos na Engenharia de Requisitos Distribuda
Lloyd [Llo01], realzou um estudo emprico de como as ferramentas de colaborativas podem ser utilizadas para elicitao dos requisitos de um sistema no desenvolvimento de software em equipes distribudas de desenvolvimento. Os participantes dessa pesquisa foram grupos distintos de estudantes de cincias da computao no total seis grupos de sete a nove membros sendo separando os clientes dos engenheiros. O DER foi produzido pelos engenheiros atravs de interao remota com os clientes. Todos os grupos caram distribudos e tinham como suporte ferramentas colaborativas que permitiram a colaborao sncrona e assncrona. Clientes e engenheiros nunca tiveram contato face a face, com o objetivo de realizar qualquer tipo de discusso ou negociao a respeito do projeto. A inteno foi observar a efetividade das tcnicas de elicitao no processo de renamento dos requisitos no ambiente distribudo de desenvolvimento. Ao trmino das iteraes foram analisadas a qualidade dos artefatos produzidos. A Engenharia de Requisitos foi auxiliada com o uso de um conjunto de ferramentas colaborativas, a saber: Centra Symposium : possibilitou as reunies virtuais em tempo real; MOOsburg : facilitou o compartilhamento de arquivos, conversas informais, correios-eletrnicos para realizao de discusso assncrona. Cada grupo de Engenharia de Requisitos conduziu uma srie de quatro reunies virtuais planejadas e agendadas com um grupo de clientes. As reunies de elicitao tinham no mximo
24
90 minutos de durao sendo realizadas por audio-conferncia atravs do Centra Symposium. Os engenheiros de requisitos no utilizaram nenhuma tcnica de elicitao de requisitos em particular. Eles foram treinados numa variedade de tcnicas (Figura 2.5) e durante a elicitao tiveram a liberdade de escolha da melhor tcnica para a situao. Neste estudo emprico o autor observou e examinou os artefatos armazenados nos espaos colaborativos criados no MOOSburg. Alm de arquivar e analisar toda a comunicao de correios-eletrnicos entre clientes e engenheiros de software. Mais detalhes sobre essa anlise sero encontrados na dissertao de mestrado [Llo01]. Os participantes estavam habilitados a usar o MOOsburg de qualquer computador atravs de um navegador web, sendo necessrio instalar um plugin apropriado. O MOOsburg possibilitou a comunicao sncrona e assncrona entre clientes e engenheiros de requisitos. J o Centra Symposium que possibilitava audio-conferncia atravs de Voz Sobre IP (VoIP), cou restrito ao campus da universidade. Os grupos obtiveram informaes dos requisitos adequados atravs de sesses virtuais planejadas, obtendo mais sucesso na escrita do DER.
Figura 2.5 Efetividade das Tcnicas de Elicitao dos Requisitos em DDS [Llo01]
Nesse grco da Figura 2.5 apesar dos diversos nveis de experincia dos participantes foram identicadas as tcnicas de elicitao de requisitos mais efetivas quando utilizadas no contexto de DDS. Porm a avaliao dos prottipos executveis gerados para elicitao deve ser desconsiderado, pois o autor informa que os engenheiros de requisitos no tiveram o devido treinamento no uso do mtodo. Todavia a prototipagem de baixa delidade chamada de storyboard, foi estudada e utilizada durante o experimento. 2.4.4.1 Concluses
Neste estudo emprico de Engenharia de Requisitos em ambientes distribudos de desenvolvimento, as atividades foram auxiliadas pelo uso de ferramentas de groupware com suporte
25
colaborao. Seis estudantes de Engenharia de Requisitos seguiram um processo bsico de elicitao, renamento e especicao de um sistema. O autor conclui que a Engenharia de Requisitos em ambientes distribudo de desenvolvimento, mais efetiva quando os stakeholders participam ativamente das atividades sncronas do processo de engenharia de requisitos. Ficando a cargo da audio-conferncia como o mecanismo mais rico de colaborao sncrona utilizado na pesquisa. Atravs da observao, o autor acredita que os grupos sentem-se atrados a usarem correio eletrnico e ferramentas de instant messaging, diminuindo as barreiras sociais causadas pela distncia. Nesse trabalho o autor testou um conjunto de ferramentas usando tcnicas de elicitao de requisitos, porm no sistematizou num processo de Engenharia de Requisitos para esses ambientes. O prprio autor reconhece que os meios mais adequados para realizar a elicitao so os meios sncronos e que o mecanismo de comunicao mais adequado o contato face a face. Consideramos que se conseguirmos elicitar os requisitos juntamente com o stakeholder de maneira presencial, teremos um mecanismo mais rico em contexto (Figura 2.1) e diminuiremos o esforo gasto nessa atividade. De acordo com as tcnicas listadas para a elicitao dos requisitos (Figura 2.5) selecionamos 3 das 5 mais efetivas (Brainstorming, Storyboarding, Casos de Uso). Apesar de considerarmos o gerenciamento de requisitos extremamente importante para a Engenharia de Requisitos [KS98], a anlise deste processo foge do escopo desse trabalho.
2.4.5
Impacto dos Stakeholders Geogracamente Distribudos na Gerncia de Requisitos em organizaes Multi-Site
Damian e Zowghi [DZ02] investigam os problemas da ER quando os stakeholders esto distribudos geogracamente numa organizao multi-site. Elee buscaram examinar a ER na prtica, entendendo o impacto da distncia em projetos onde os stakeholders denem os requisitos do software separados geogracamente. Algumas organizaes s vezes no podem se dar o luxo de realizar reunies de requisitos face a face. Como resultado, a distncia impactou na forma como os stakeholders opinam, questionam e decidem os requisitos. Ento, atravs de evidncias empricas, foi construdo um modelo de comunicao remota e gerncia do conhecimento. Mesmo com o uso desse modelo foram encontrados diversos problemas: diversidade cultural, diferenas de horrio. Esses problemas impactaram negativamente nas etapas subseqentes dos requisitos: negociao e validao. Essa pesquisa foi motivada pela seguinte pergunta: Qual o impacto da distncia geogr-
26
ca dos stakeholders nas atividades de Engenharia de Requisitos no ambiente distribudo de desenvolvimento?. A metodologia de pesquisa utilizada foi a grounded theory [Fli04] aplicada num estudo de caso [Yin05]. O autor levou sete meses em sites de desenvolvimento localizados em SydneyAU, coletando: dados, mtodos, inspeo de artefatos, observao das reunies de requisitos e entrevista semi-estruturada com vinte e quatro stakeholders (gerente de produto, engenheiro de produto, gerente de suporte ao cliente e engenheiro de software). A organizao estudada foi uma corporao de Desenvolvimento Global de Software (DGS) entre 4 continentes. A estratgia do produto ca de responsabilidade de uma equipe de Business Management (BM) localizada em 4 pontos nos Estados Unidos (vide Figura 2.6). A equipe de desenvolvimento est divida em trs na Austrlia e uma na Nova Zelndia. Os clientes esto agrupados em 5 seguimentos ao redor do mundo .
Figura 2.6 Distribuio geogrca do grupo de stakeholders [DZ02]
Reunies de udio conferncia so utilizadas para a comunicao sncrona, o que permite conectar o BM com as demais localidades na tomada de deciso (vide Figura 2.7). Os requisitos cavam armazenados num banco de dados no BM sendo fruto de informaes geradas por: usurios nais, clientes e funcionrios. Todos os sites provinham informaes que no futuro poderiam se tornar requisitos do sistema. Depois de centralizadas as informaes o BM prepara um documento inicial com os requisitos em alto nvel Marketing Requirements Specication (MRS) a serem priorizados e negociados com a equipe de desenvolvimento. Depois do entendimento comum, a seleo realizada e os requisitos passam a ser especicados pela equipe de desenvolvimento gerando o DER. Depois de pronto o DER enviado para o BM para aprovao. Nesse contexto, achou-se diversos campos para investigao das diculdades em conseguir
27
Figura 2.7 Fluxo de informao no projeto [DZ02]
uma colaborao efetiva dos stakeholders geogracamente distribudos. Durante a negociao dos requisitos, foram utilizadas um conjunto de ferramentas sncronas e assncronas de comunicao visando diminuir essa distncia. Canais de udio e vdeo foram usados na comunicao com entre desenvolvedores remotos e clientes para a captura de requisitos. O Microsoft Powerpoint [Mic06b] foi usado na construo de diagramas de contexto, juntamente com o NetMeeting para o compartilhamento das apresentaes do Microsoft Powerpoint [Mic06b] a distncia. Isso permitiu criar documentos eletrnicos colaborativamente melhorando as atividades colaborativas distribudas atravs do acesso em tempo real por sites remotos. A percepo dos participantes em Sydney aumentou com a captura de vdeo e as conferncias de audio. Junto a essas ferramenta colaborativas genricas, uma ferramenta especca de requisitos foi usadada RequisitePro [RAT05] da Rational. Os requisitos capturados so cadastrados no RequisitePro [RAT05] sendo renados pela equipe de desenvolvimento e ento um DER gerado . Tanto o time de desenvolvimento, quanto os demais membros do projeto podem acessar as verses atuais dos DER, isso inibe a ocorrncia de artefatos desatualizados sendo utilizados pelos demais integrantes. Apesar de todas as funcionalidades das ferramentas colaborativas existentes no estudo de caso, o correio eletrnico ainda a ferramenta assncrona predominante. Principalmente devido a diferena de tempo entre as unidades distribudas. Isso traz vantagens e desvantagens na gerncia dos requisitos, o correio eletrnico para a resoluo de ambigidades existentes no documentos de requisitos, foi um mecanismo muito pobre. Alm de ser um meio de baixo contexto para a comunicao, vrias vezes a equipe de especicao explicava os requisitos atravs de correio eletrnico porm posteriormente o problema ressurgia, seja por conta que um outro
28
stakeholder vinha com a mesma dvida, ou o e-mail foi respondido h muito tempo e caiu no esquecimento. Como vantagem, ca o fato de ser um mecanismo mais formal de comunicao pois por ser considerado um documento ele fornece mais segurana na informao. Durante a realizao do estudo de caso o autor revelou que a distncia impactou diretamente nas atividades relacionadas a negociao dos requisitos do sistema, sendo eles: Comunicao inadequada : A distncia introduz barreiras para a comunicao informal e face a face. Deixando a comunicao dependente de ferramentas colaborativas sncronas e assncronas. Gesto de conhecimento : A quantidade de requisitos vinda de mltiplas fontes dos sites remotos, no cou bem compartilhada entre os desenvolvedores. Diversidade cultural : Diferenas entre as lnguas e culturas afetaram a colaborao global. A linguagem do cliente impactou diretamente na atividade de elicitao de requisitos, essas barreiras afetaram a transferncia de conhecimento a respeito dos requisitos para os desenvolvedores. Diferena de tempo : A larga distribuio dos stakeholders introduz diferenas de fuso horrio cando difcil de ser resolvida. Assim canais de comunicao assncrona so mais predominantes. Reunies sncronas requerem o compromisso de algum site para ser resolvido. Em um estudo anterior desse mesmo estudo de caso [DZO01] os autores visualizaram diversos problemas na rea de ER em DDS Figura 2.8: Negociao : DER levou cerca de 6 meses de negociao at ser aprovado. O autor considera que devido a esse atraso a validao dos requisitos no foi realizada a contento. Reviso : esse processo consumiu bastante tempo do cliente. Desta forma foram realizadas revises no formais, geralmente mal gerenciadas e inecientes. Validao : no houve uma validao formal dos requisitos por parte do cliente. Eventuais comunicaes entre os clientes eram realizadas e melhorias nos requisitos foram propostas durante a evoluo do artefato. Os autores sentiram a necessidade de uma melhor coordenao dessa atividade. Prototipagem : O processo de prototipagem foi bastante em cascata, perdendo os benefcios que uma abordagem baseada em prototipagem poderia trazer, como a construo dos requisitos de forma iterativa e auxiliando nas fases de elicitao e validao dos requisitos. Damian, Zowgui e Offen [DZO01] defendem que esses problemas esto diretamente relacionados com o impacto dos problemas de comunicao e coordenao existentes no DDS. Porm como resultados parciais do estudo os autores concluem que a distncia impacta na colaborao entre grupos distribudos de desenvolvimento. Desta forma os autores sentem
29
Figura 2.8 Modelo de impacto dos desaos e atividades afetadas da Engenharia de Requisitos devido a problemas com o DGS adaptado de Damian [DZ02]
a necessidade de uma pesquisa em um processo de engenharia de requisitos especco para desenvolvimento distribudo de software. Pois eles acreditam que um nmero bastante signicativos de organizaes que utilizam desenvolvimento distribudo de software venham a ter os mesmos problemas descritos. 2.4.5.1 Concluses
Damian, Zowgui e Offen reconhecem que a negociao de requisitos desse estudo de caso foi bastante demorada levando cerca de 6 meses e que caberia como um estudo futuro estudar os fenmenos da validao dos requisitos nesse ambiente. A centralizao e priorizao dos requisitos realizadas nesse estudo pelo BM foi importante para a negociao atravs comunicao face a face do que deveria ser especicado. Melhorando na coordenao das atividades atravs da priorizao dos requisitos entre as unidades distribudas. Em nosso trabalho essa centralizao das informaes essencial para a tomada de decises do que ser desenvolvido. Foi a partir dessas concluses que resolvemos criar uma Unidade Principal de Desenvolvimento (UPD), que cou responsvel por elicitar os requisitos iniciais do sistema, delegando para as UDS em realizar o detalhamento dos mesmos. Encontramos tambm nesse trabalho o uso de ferramentas colaborativas na Engenharia de Requisitos distribuda. Os documentos foram criados de maneira colaborativa e em paralelo entre as unidades distribudas, sendo registrados no RequisitePro o documento de requisitos era organizado por essa ferramenta e mantido por controle de verso [RAT05]. Contudo, no s
30
colocar uma ferramenta colaborativa para a edio dos artefatos que a Engenharia de Requisitos funcionar em ambientes distribudos. Consideramos que necessrio aumentar a coordenao das atividades atravs do acompanhamento e revises dos artefatos produzidos com o intuito de compartilhar o conhecimento entre as UDS e melhorar a qualidade da especicao.
C APTULO 3
Metodologia de Pesquisa
3.1
Introduco
Nesse estudo emprico foi avaliado o processo de documentao e validao dos requisitos entre os participantes do estudo de caso, por intermdio de seus pers e papis dentro do projeto [Sou05]. O objetivo geral desta pesquisa foi identicar as vantagens e diculdades que o uso de storyboards promove quando adotado por equipes de desenvolvimento distribudo de software em atividades de documentao e validao dos requisitos. Os pesquisadores que adotam a abordagem da pesquisa qualitativa a fazem por sua exibilidade, sem regras rgidas, aplicveis a uma ampla gama de casos e formalizaes pr-denidas, possibilitando a construo de modelos abrangentes [Gom00]. Nesse estudo a pesquisa qualitativa est orientada a um estudo de caso, partindo da anlise das expresses e comportamento das pessoas. Na busca por entender os fenmenos sociais complexos, o estudo de caso permite uma investigao signicativa nas mudanas desses processos organizacionais [Yin05]. Por se tratar de um estudo emprico, utilizamos a pesquisa qualitativa por envolver uma grande variedade de tcnicas para levantamento de informaes (entrevistas, observaes, histrico, interaes, artefatos e ferramentas utilizadas) [Fli04]. O ambiente no qual este trabalho est relacionado pertence a projetos de pesquisa vinculados a uma fonte nanciadora de pesquisa 1 . Esses projetos acadmicos so frutos de dissertaes de mestrado e/ou doutorado, os quais necessitam de nanciamento para serem postos em prtica, dessa forma possvel disseminar o conhecimento adquirido alm de gerar novas solues para a sociedade. Eles possuem a peculiaridade de serem desenvolvidos dentro da universidade e terem alunos da prpria instituio como os principais colaboradores. Como agravante na execuo desses projetos pode ser citado a diferena de horrios de colaborao dos integrantes, impactando na realizao de atividades em grupos como o desenvolvimento de um software por exemplo.
1 CNPq
- Conselho Nacional de Desenvolvimento Cientco e Tecnolgico [CNdDCeT06]
31
32
CAPTULO 3 METODOLOGIA DE PESQUISA
3.2
Objetivos
Geral
3.2.1
Entender as necessidades de uma equipe de desenvolvimento de software que esteja distribuda de forma geogrca e temporal com vistas na anlise do processo de desenvolvimento (normas e prticas). Escolhendo a disciplina de requisitos para ser estudada e melhorada dentro desse contexto. 3.2.2 Especcos
Identicar os problemas recorrentes em projetos de desenvolvimento acadmicos que possuam caractersticas de DDS. Identicar as principais prticas individuais e de grupo que ocorrem durante a documentao e validao dos requisitos no estudo de caso. Modelar uma proposta de processo de engenharia de requisitos que venha a atender as necessidades desse estudo de caso.
3.3
Procedimentos
Os procedimentos da pesquisa esto representados na Figura 3.1. Durante a anlise dos textos, alguns foram extrados para demonstrar os fragmentos encontrados durante esta anlise. A nomenclatura utilizada nos fragmentos encontrado nos Captulos (5 e 4) contm o prexo FRAGMENTO mais um nmero seqencial identicando o mesmo.
Figura 3.1 Desenho da Pesquisa
3.4 ENTREVISTA SEMI-ESTRUTURADA EXPLORATRIA (1)
33
3.4
Entrevista Semi-Estruturada Exploratria (1)
O objetivo deste procedimento foi entender como as equipes de desenvolvimento de software que possuem alguma caracterstica em DDS trabalham. Como pr-requisitos aos projetos os quais os entrevistados estavam vinculados tinham de possuir caractersticas de desenvolvimento distribuda de software, seja por questo da distncia geogrca ou pela divergncia de horrios da equipe. Procurou-se encontrar dentro do contexto de estudo, questes recorrentes para extrair um problema relevante a ser estudado numa observao dentro de um estudo de caso. As entrevistas foram realizadas de maneira presencial, onde primeiramente fez-se perguntas no estruturadas e havendo uma maior estruturao no decorrer da entrevista. Esse mtodo tem como objetivo evitar que a referncia do entrevistador seja imposta sobre os pontos de vista do entrevistado [Fli04]. 3.4.0.1 Perl dos participantes
O pblico alvo da pesquisa foram gerentes de projeto de desenvolvimento de software fomentados por fontes nanciadoras de pesquisa [CNdDCeT06]. Logo no incio da entrevistas foram obtidas informaes sobre a formao acadmica, tempo de experincia na rea de desenvolvimento de software e nvel de distribuio do projeto, de modo auxiliar na visualizao do contexto da pesquisa uma tabela foi elaborada com o perl de cada participante. As entrevistas foram realizadas de forma presencial, com recursos de gravao, de modo a facilitar a transcrio dos dados coletados. 3.4.0.2 Entrevista com gerentes de projeto de software oriundos de pesquisa
Essa etapa da pesquisa foi baseada num conjunto de questes/guia vide Apndice A, onde nem todas as perguntas elaboradas foram utilizadas. Para a construo do questionrio foi realizada uma anlise dos pontos importantes da Engenharia de Software, extradas do SWEBOK [ABD+ 04] juntamente com as recomendaes prticas para a Engenharia de Requisitos sugeridas pela IEEE [Byr94]. A entrevista semi-estruturada realizada teve um total de 22 perguntas agrupadas em 5 sees, com os seguintes temas: integrantes da equipe, ambiente fsico, ambiente organizacional, ambiente tcnico e tarefas. Devido as diferenas existentes em cada projeto o entrevistador pde selecionar as questes de acordo com suas caractersticas.
34
3.5
Estudo de Caso - Etapa 1 (2)
Um estudo de caso deve ser utilizado quando o pesquisador quiser lidar com situaes contextuais - acreditando que elas possam ser pertinentes ao seu fenmeno de estudo. Se trata de um mtodo que abrange: lgica de planejamento, tcnicas de coleta de dados, abordagens especcas anlise dos mesmos [Yin05]. Existem trs tipos de estudo de caso: explanatrios, descritivos e exploratrios. A abordagem utilizada foi de carter exploratrio, pois manipulou-se o comportamento direto, preciso e sistematicamente. Portanto o estudo de caso foi uma anlise emprica que investigou um fenmeno contemporneo dentro de seu contexto, especialmente quando os limites entre o fenmeno e o contexto no estavam claramente denidos [Yin05]. O estudo de caso exploratrio deve ser precedido das seguintes armaes [Yin05]: 1. o que ser explorado; 2. o propsito da explorao; 3. os critrios atravs dos quais se julgar a explorao como bem-sucedida. Inicialmente foram exploradas as atividades referentes a documentao e validao dos requisitos, dentro do projeto Amadeus [Sou05], com o propsito de denir um processo de engenharia de requisitos que melhore a realizao dessa atividade no contexto de desenvolvimento distribudo de software. A justicativa de que um estudo de caso nico anlogo a um experimento nico, que muitas condies que servem para justicar um experimento nico, tambm justicam um estudo de caso nico. O estudo de caso pode representar um "projeto"tpico entre muitos projetos diferentes, partindo-se do princpio de que as lies aprendidas nesses casos fornecem muitas informaes sobre as experincias da pessoa ou instituio usual. Para a realizao dos estudos de caso so especialmente importantes cinco componentes de um projeto de pesquisa [Yin05]: 1. 2. 3. 4. 5. as questes de um estudo; suas proposies, se houver; sua(s) unidade(s) de anlise; a lgica que une os dados s proposies; os critrios para interpretar as constataes.
Atravs do estudo de caso foi possvel especicar proposies tericas no princpio da investigao. Mas no necessariamente, entrar em campo com rapidez na fase de coleta de dados, os contatos de campo relevantes dependeram da compreenso da teoria do que est sendo estudado. Nos estudos de caso o desenvolvimento da teoria como parte da fase de projeto
3.6 ANLISE DOS RESULTADOS - ELABORAO (3)
35
essencial, o propsito do estudo de caso poder ser: desenvolver ou testar essa teoria. A teoria forneceu um conjunto claro de preposies, bem como as circunstncias nas quais se acredita que essas preposies sejam verdadeiras. O caso nico serviu para determinar se as preposies de uma teoria esto corretas ou se algum outro conjunto alternativo de explanaes seja mais relevante [Yin05]. O caso nico pode representar uma importante contribuio para a base de conhecimento e a construo da teoria. Tal estudo poder auxiliar no direcionamento de investigaes futuras em toda uma rea de pesquisa [Yin05]. 3.5.0.3 Unidade de Anlise do Estudo de Caso
O mesmo estudo de caso pode envolver mais de uma unidade de anlise2 . Isso ocorre no caso nico quando se d ateno a uma subunidade3 denominando-se estudo de caso incorporado. Como o enfoque na rea de requisitos em desenvolvimento distribudo de software, a anlise incluiu resultados a respeito dos problemas recorrentes no desenvolvimento distribudo e que impactam na engenharia de requisitos como: comunicao, coordenao, diferena de tempo e integrao. As subunidades freqentemente podem acrescentar oportunidades signicativas, realando o valor das impresses em um caso nico. Porm no pode despender ateno demasiada s subunidades, pois os aspectos holsticos mais amplos do caso comeam a ser ignorados e o prprio estudo de caso tem sua orientao e natureza modicada [Yin05].
3.6
Anlise dos Resultados - Elaborao (3)
A anlise de resultados servir de base para o desenvolvimento do processo proposto. Dando o suporte necessrio para a seleo de um conjunto de ferramentas a serem incorporadas na execuo do processo. A anlise do resultado est descrita na Captulo 4. 3.6.1 Anlise Qualitativa Assistida por Computador
O NVIVO [QSR07] um software que permite a anlise qualitativa das informaes obtidas em modo texto. Software dessa natureza auxiliam o pesquisador na organizao dos registros da pesquisa e das interpretaes dos mesmos. A escolha de uma ferramenta dessa se d pela
2 Relacionado 3 Ocorre
maneira como se dene as questes iniciais da pesquisa [Yin05] quando dentro de um caso nico, se d ateno a uma subunidade ou vrias subunidades [Yin05]
36
diculdade de classicar e analisar os dados obtidos. O NVIVO [QSR07] foi utilizado para o melhor entendimento dos textos colhidos dos participantes do estudo de caso e da entrevista transcrita na fase inicial da pesquisa. Nessa anlise somente foram levadas em considerao as atividades referentes a Engenharia de Requisitos, foco principal desse trabalho. 3.6.2 Para a de coleta de dados zemos: Arquivamento de correios-eletrnicos; Arquivamento de logs de ferramenta de instant messaging (Microsoft MSN [Mic06a] Coleta das atas de reunio presencial; Gravao em udio das reunies de validao dos requisitos e uma transcrio a posteriori. 3.6.2.1 Arquivamento de correios-eletrnicos Coleta de dados
Essa etapa ocorreu durante quatro meses durante a elicitao, documentao e validao dos requisitos de dois mdulos do projeto Amadeus (2/12/2005 a 29/03/2006). Foram catalogados e analisados num total de 197 correios-eletrnicos, trocados entre os participantes. O DER do "Mdulo 1"foi desenvolvido na UPD, onde todos os participantes estavam na mesma distribuio geogrca, porm com divergncia de horrios. O DER do "Mdulo 2"foi desenvolvido na Unidade Distribuda 1 - Petrolina (UD1) 800 km de distncia da UPD. 3.6.2.2 Logs de Ferramenta de Instant Messaging
O pesquisador selecionou trechos das trocas de mensagens relativas a Engenharia de Requisitos realizadas dentro da ferramenta de instant messaging institucionalizada pelo projeto. Ao total foram catalogados 30 logs de conversas realizadas entre 2/12/2005 a 29/03/2006 num total de 3780 mensagens, realizadas entre diferentes integrantes do estudo de caso. 3.6.2.3 Atas de Reunio Presencial
Dentro do projeto existe uma reunio semanal realizada de maneira presencial entre os integrantes da unidade de desenvolvimento de Recife. Foram coletadas 13 atas entre os perodos
3.6 ANLISE DOS RESULTADOS - ELABORAO (3)
37
de 06/10/2005 a 16/01/2006, as quais puderam dar indcios de problemas. 3.6.2.4 Gravao em udio das Reunies de Validao dos Requisitos
Na fase de validao dos requisitos foram realizadas duas gravaes correspondentes a validao do "Mdulo 1"e "Mdulo 2". Esses dados foram transcritos e inseridos no NVIVO [QSR07]. Esses dados foram usados, como parte complementar para melhorar as atividades realizadas a distncia por meio das ferramentas colaborativas usadas durante a validao do DER. Validao do DER Mdulo 1 Na realizao dessa reunio apenas um integrante (gerente de projeto) no estava participando de forma presencial, o mesmo se encontrava em Garanhuns a 230 km da UPD. Os demais participantes (autor, stakeholder, analista de banco de dados e um arquiteto) estavam dividindo uma mesma mquina fazendo udioconferncia numa sala fechada. Validao do DER Mdulo 2 Na realizao dessa reunio dois integrantes se encontravam na UPD, um integrante estava na UD1 e o outro integrante (Gerente de Projeto) estava a 20 km da UPD. A reunio foi realizada atravs de udio conferncia onde todos os participantes conseguiam debater e validar o DER. 3.6.3 Instrumento de Anlise dos Dados
A interpretao de dados o cerne da pesquisa qualitativa. Tem como funo desenvolver a teoria, servindo ao mesmo tempo de base para a deciso sobre quais dados adicionais devem ser coletados [Fli04]. importante que seja realizada a codicao seletiva, para que seja elaborada a categorizao essencial sobre todas as categorias envolvidas [Fli04]. O pesquisador precisa decidir quais os fenmenos salientes e ponder-los de forma a ter como resultado uma categoria central juntamente com as categorias a ela relacionadas. O procedimento da interpretao dos dados, assim como a integrao de material adicional, encerrado quando atinge a "saturao terica", quando o avano da codicao no atinge mais novos conhecimentos [Fli04]. Para anlise dos textos provenientes da pesquisa (logs de ferramentas de chat, correioseletrnicos, artefatos) foi utilizada a codicao seletiva atravs de criao de categorias a
38
posteriori. As categorias foram criadas e organizadas de acordo com o contedo de cada texto. As respostas de cada participante foram analisadas e a partir da identicao das categorias, includas na rvore de categorias do NVIVO [QSR07], que possui a transcrio de cada questionrio e interao ocorrida. Admitindo-se que uma classicao, para ser adequada no pode ser feita arbitrariamente, a categorizao da rvore exposta na gura Figura 5.2 foi criada e reformulada vrias vezes, durante o processo de anlise de acordo com [Fli04]. Por m, com base na anlise do texto, foram vericados diculdades e necessidades ocorridas durante a fase de requisitos do estudo de caso e da entrevista inicial realizada.
3.7
Proposta de um processo (4)
Com base nas fases anteriores da pesquisa foi proposto um processo de engenharia de requisitos, fonte de estudo desta dissertaco, que desse o devido suporte as atividades de documentao e validao dos requisitos em ambientes DDS. Esse processo est melhor descrito no Captulo 6. 3.7.1 Seleo de Ferramentas que Dem Suporte ao Processo Proposto
Para a execuo do processo, foi necessrio ser analisado e selecionado um conjunto de ferramentas com caractersticas que dem o suporte necessrio ao processo. Neste trabalho as ferramentas selecionadas sero citadas.
C APTULO 4
Anlise da Entrevista Semi-Estruturada
Neste captulo so apresentados os resultados da Entrevista Semi-Estruturada como exposto na Figura 3.1. Detalhamos a entrevista semi-estruturada realizada, descrevendo os processos e prticas de desenvolvimento e de Engenharia de Requisitos utilizados pelos entrevistados. Ao nal realizada uma anlise nos dados com vistas para extrao de requisitos para o processo de Engenharia de Requisitos proposto nesse trabalho.
4.1
Entrevista Semi-Estruturada
De acordo com o desenho da pesquisa Figura 3.1, foi realizada uma entrevista semi-estruturada antes das observaes do fenmeno da pesquisa dentro do estudo de caso. Para extrair problemas importantes e recorrentes nessas equipes de desenvolvimento distribudo de software. Nas prximas sees sero apresentados os resultados e discusses provenientes dos relatrios gerados, atravs da anlise das entrevistas auxiliada pelo NVIVO [QSR07]. Esse procedimento visou identicar requisitos que orientem a proposta do processo de Engenharia de Requisitos, no que se refere a diminuir a distncia entre as equipes distribudas de desenvolvimento. Para a captura do requisito, cou estabelecido que ele deve ser importante para os trs projetos pesquisados vide Tabela 4.1. Cada requisito extrado das entrevistas ser citado como REQ-ENTREVISTAS, seguido por um nmero correspondente seqencia de sua apresentao.
4.1.1
Participantes da Entrevista Semi-Estruturada
Nesta seo sero apresentados os participantes da entrevista semi-estruturada realizada durante a pesquisa. Para manter a condencialidade de informao, os nomes dos projetos dessa pesquisa so ctcios. Sendo referenciados como descritos na Tabela 4.1. 39
40
CAPTULO 4 ANLISE DA ENTREVISTA SEMI-ESTRUTURADA
Tabela 4.1 Projetos Pesquisados

Equipes Objetivo No Participantes Carga Horria Durao Nvel de Distribuio Projeto 1 Extenso de um software de gesto de contedo 13 4 horas extensveis para execuo das atividades 6 meses equipe virtual Projeto 2 Jogos para aprendizagem 12 4 ou 6 horas 1 ano e meio stakeholders distribudos Projeto 3 Ambiente virtual de ensino 18 4 horas 3 anos multisite
4.1.1.1
Projeto 1
Comunidade de desenvolvimento de software a qual possui um processo de desenvolvimento criado dentro de uma disciplina de ES. Os integrantes trabalham de forma distribuda como numa comunidade de desenvolvimento de software livre contudo tm a obrigatoriedade de seguir a especicao de um cliente. O processo institucionalizado no possui uma abordagem de desenvolvimento distribudo, foi desenvolvido baseado no RUP [Sof05] juntamente com prticas de metodologias geis. Todas as fases do processo esto disponibilizadas e descritas no site da comunidade (REQENTREVISTAS-011 ), sendo do conhecimento de todos os integrantes. Essa comunidade conseguiu executar vrias disciplinas da engenharia de software de forma distribuda (arquitetura, desenvolvimento e testes), contudo eles sentiram diculdades em realizar a engenharia de requisitos de forma distribda, logo ela foi executada de maneira presencial. Nesse projeto a engenharia de requisitos foi realizada presencialmente com a participao efetiva do cliente durante a execuo do processo. O cliente participou atravs de comunicao face a face da anlise, documentao e validao do artefato. Aps a validao dos requisitos, realizada uma reunio presencial com o intuito de apresentar os requisitos para os demais integrantes. O projeto uma extenso de uma ferramenta de cdigo fonte aberto e que precisa atender as requisies e necessidades de um cliente. Por ser a extenso de um software j existente, ele possui um nvel de maturidade elevado com vrias linhas de cdigo j desenvolvidas. Desse modo a equipe no teve muita preocupao em desenvolver a arquitetura e modelagem de dados do software, apenas alterou a base de dados quando necessrio reetindo as alteraes no cdigo fonte. O andamento das atividades cou registrado de forma bastante transparente atravs do site
a descrio do processo em um site. Para que todos os integrantes do projeto tenham acesso com facilidade as etapas e procedimentos do processo institudo [Sof01].
1 Disponibilizar
4.1 ENTREVISTA SEMI-ESTRUTURADA
41
do projeto, sendo disponibilizadas as atividades da iterao corrente com seus respectivos status. A equipe as desenvolve em suas prprias casas, trabalhos ou universidades, reportando o cumprimento das mesmas. Como condio todos os integrantes tm o compromisso checar correios-eletrnicos constantemente alm de permanecerem disponveis no MSN Messenger [Mic06a], ou seja os meios de comunicao sncrono e assncrono tm de estar disponveis para que a execuo das atividades no sofra impacto de comunicao (REQ-ENTREVISTAS-02 2 ). Um agravante encontrado na execuo desse projeto, foi que o design e a navegabilidade da aplicao foi desenvolvido por uma equipe externa comunidade, no havendo um seguimento do processo proposto por parte dessa equipe (REQ-ENTREVISTAS-04 3 ). Isso foi identicado como um ponto de tenso e trouxe como conseqncia falta de sincronia na execuo das atividades. Como exemplo pode ser citada que aps a denio dos requisitos, parte da funcionalidade j estava desenvolvida e no entanto quando as mesmas eram disponibilizadas, divergindo do que foi desenvolvido e conseqentemente gerando retrabalho em todas as demais fases de desenvolvimento (especicao, codicao e testes). 4.1.1.2 Projeto 2
um projeto de desenvolvimento do prottipo de um jogo para o treinamento em gerncia de projetos. Faz parte da produo cientca de um aluno de doutorado da rea de IA aplicada a jogos e de um aluno de mestrado na rea de jogos de simulao para treinamento corporativo. Se trata de um projeto multidisciplinar com a participao de oito stakeholders de diferentes pers os quais auxiliam a equipe atravs de seus conhecimentos tcnicos. O produto nal estar disponvel na forma de cdigo fonte para a comunidade cientca, conforme especicado no edital ao qual foi submetido [RRG05]. Possui um processo de desenvolvimento baseado no RUP [Sof01], contudo adaptado para a realidade de jogos, com o ciclo de desenvolvimento mais em cascata do que incremental. A Engenharia de Requisitos no est bem denida, existindo a carncia de um especialista responsvel pela elicitao dos requisitos dentro do projeto. Sua anlise foi traada partindose do estudo de um pblico alvo do jogo e de um estudo do domnio da tecnologia utilizada que bastante recente e com poucos referenciais bibliogrcos. Outro agravante na execuo
2 Usar meios sncronos de comunicao. Os meios sncronos aumentam o nvel de comunicao informal no projeto, estudos indicam que o uso de comunicao informal aumenta o nvel de conana da equipe [HAB+ 02] [MH01] [Car98]. Alm de diminuir ocorrncia de conitos, em relao aos meios assncronos, gerados por malentendimentos da comunicao. 3 Institucionalizar um processo nico a ser seguido por todos os integrantes das equipes distribudas [CA01], buscando sincronizar a execuo das atividades atravs de artefatos de entrada e sada [HM01].
42
do projeto que faz parte da tese de doutorado de um dos integrantes e que est em fase de desenvolvimento, o que impacta diretamente na estabilidade dos requisitos especicados. Por se tratar de um projeto de pesquisa, h uma instabilidade muito grande nos requisitos do projeto. A inovao tecnolgica por parte da tecnologia, fez com que todos os integrantes se envolvessem com o projeto para denir o que seria possvel de ser implementado, havendo uma grande troca de conhecimento entre a equipe. Devido aos horrios distintos de colaborao dos participantes, fez-se necessrios utilizar ferramentas de comunicao sncrono e assncrono alm de um maior esforo gasto em planejamento para haver uma maior integrao do projeto. Para Carmel [CA01] quando as equipes distribudas trabalham em projetos de inovao os meios de comunicao informal tornam-se crticos e necessrios (REQ-ENTREVISTAS-02), pois auxiliam os desenvolvedores a informarem detalhes de suas atividades, alm de permitir a correo de eventuais erros e permitir o auxlio tcnico mtuo. As decises de projeto so tomadas atravs de reunies presenciais entre os integrantes, aqueles que no podem comparecer devido a divergncia de horrios acompanham o que cou decidido em reunio atravs de atas, disponibilizadas todos atravs de meios assncronos de comunicao (correio-eletrnico) (REQ-ENTREVISTAS-02). 4.1.1.3 Projeto 3
Tem a misso de desenvolver um ambiente virtual de ensino usando recursos multimdia. Possui a participao de diversas instituies [JP06], [FdCAeSdP06]. Sendo um trabalho pesquisado ao longo de quatro anos pelo Grupo de Cincias Cognitivas da UFPE [CCeTE07]. O processo de desenvolvimento adotado baseado em metodologias geis, onde todas as fases esto descritas no plano de projeto [MCG05]. A princpio foi elaborado com o propsito de atender a equipes presenciais de desenvolvimento onde de 6 a 8 pessoas compartilhariam de mesmo horrio. Porm na execuo do projeto, percebeu-se que no houve convergncia de horrios entre os integrantes. Alm disso, atravs da seleo de dois integrantes localizados em Petrolina, houve a formao de um ambiente de desenvolvimento distribudo de software. Sendo necessrio uma nova abordagem para o tratamento dessa equipe na execuo de suas atividades buscando diminuir as distncias existentes. Como a ER est presente nas etapas iniciais de qualquer projeto de desenvolvimento, ela foi executada em um contexto de DDS mesmo sabendo dos desaos em em executar a ER com equipes distribudas [Pri03] [Zow02] [DZO01]. Para que essa disciplina fosse desenvolvida nesse ambiente, foram testadas diferentes tcnicas e abordagens que serviram de subsdios para este trabalho.
4.2 ANLISE DAS ENTREVISTAS
43
No incio do projeto o primeiro mdulo do sistema foi elicitado atravs de trabalhos de pesquisa: graduaes [Net05], dissertaes [Ram05] [Alv06] [Alv05] e tese [Gom04]. Existindo um grande esforo do engenheiro de requisitos para elaborar os casos de uso a partir dos requisitos extrados dos trabalhos de pesquisa, alm da participao do gerente de projeto e stakeholder na validao do artefato. A participao do designer s veio ocorrer aps a fase de validao, por conta disso vrias dvidas discutidas durante a fase de elicitao comearam a ressurgir e apesar de todas as validaes ocorridas o designer encontrou erros e ambigidades ocasionando em retrabalho. O que pudemos vericar com bastante clareza nesse projeto, que por ser um projeto de pesquisa cientca com caractersticas de inovao tecnolgica, os integrantes desse projeto so alunos de graduao e ps-graduao que possuem suas obrigaes acadmicas com a prpria instituio, a maioria dos integrantes priorizam a prpria faculdade em detrimento ao projeto. Logo, a equipe trabalha de forma a minimizar a distncia geogrca e temporal da equipe, usando um conjunto de ferramentas colaborativas de comunicao no intuito de diminuir as barreiras de distncia e tempo entre os integrantes (REQ-ENTREVISTAS-02). Devido a diferena de horrio o uso dos meios assncronos de comunicao so bastante utilizados e o correio-eletrnico o principal meio de comunicao assncrona usado durante todo o processo. Pudemos vericar que o uso da lista de correios-eletrnicos bastante utilizada na contextualizao dos integrantes sobre decises tomadas (REQ-ENTREVISTAS-034 ). Essas abordagens e tcnicas que visaram diminuir a distncia entre a equipe so de fundamental importncia para a validade desse trabalho, consideramos que esse ambiente se encaixa na pesquisa que estamos realizando e o elegemos como nosso estudo de caso para ser melhor observado e analisado. Com vistas de propor melhorias para sua execuo.
4.2
Anlise das Entrevistas
Esta seo apresenta e discute os resultados obtidos a partir da anlise das entrevistas realizadas, referentes tanto anlise dos projetos quanto as prticas encontradas na execuo dos processos de desenvolvimento de software. A coluna Legenda da Tabela 4.2 servir como referncia aos participantes deste estudo de caso.
meios assncronos de comunicao. Os meios assncronos so mais formais que os sncronos e possuem a vantagem de poder enviar uma mensagem sem ser necessria a presena da contraparte [Car98] [HM01].
4 Usar
44
Tabela 4.2 Legenda dos Entrevistados

Legenda ENT1-PRJ-1 ENT2-PRJ-2 ENT3-PRJ-3 Projeto Projeto 1 Projeto 2 Projeto 3 Experincia (anos) 3 10 5
4.2.1
Processo de Desenvolvimento de Software
Para as equipes distribudas foi identicado tanto na literatura quanto nas entrevistas realizadas, que eles devem seguir um processo comum s equipes distribudas. Isso se deve ao fato de que quando as equipes distribuem o processo em diversas localidades, a falta de sincronizao pode se tornar crtica [Car98]. Quando as equipes esto distribudas, o nvel de sincronizao torna-se particularmente crtico. A sincronizao nesse processo requer marcos bem denidos e critrios de entrada e sada bastante claros para toda a equipe [HM01] (REQ-ENTREVISTAS-04). Os entrevistados acham fundamental haver um consenso e conhecimento a respeito dos papis e atividades existentes no processo, para tanto necessrio que essas informaes estejam facilmente disponibilizadas para os integrantes, como num site por exemplo (REQ-ENTREVISTAS-01). A atualizao dos artefatos ocorre constantemente, fundamental que os integrantes acessem e alterem num nico repositrio de documentos para que os mesmos se mantenham atuais e no haja conito de verso (REQ-ENTREVISTAS-06 5 ) [Kar98]. Para Carmel [CA01], ferramentas de gerncia de congurao so extremamente importantes para equipes distribudas, sua principal funo controlar a verso dos artefatos desenvolvidos.
4.2.2
Processo de Engenharia de Requisitos
Em todos os projetos, os entrevistados identicaram diculdades em executar as atividades de ER dentro do contexto de DDS. Dentre os entrevistados, um em especial (Projeto 1), j executou com sucesso projetos com equipes distribudas. Nesses projetos o processo de desenvolvimento institucionalizado no tratou a ER de forma distribuda, devido as diculdades encontradas durante a sua execuo, dessa forma eles preram realizar a ER de forma presencial (como podemos ver no [FRAGMENTO-1]) por conta da facilidade em conseguir convergir a equipe em reunies presenciais com os demais integrantes e/ou stakeholders quando necessrio, evitando o desgaste de realizar a ER de maneira distribuda.
um repositrio unicado de artefatos. A equipe deve trabalhar somente nesses repositrios para que no haja conitos de verses entre os mesmos [Kar98].
5 Disponibilizar
45
[FRAGMENTO-1][ENTREVISTA][ENT1-PRJ-1] 6 A equipe faz a anlise juntamente com o cliente, documenta e valida. Depois realizada uma reunio presencial com os participantes, para apresentar os requisitos desenvolvidos. Nessa seo dividimos as fases da Engenharia de Requisitos conforme o processo genrico de ER proposto por [KS98] na Figura 2.2. Achamos tambm que a fase de Negociao dos Requisitos, foge do escopo desse trabalho, por isso no foi realizada nenhuma anlise a respeito dessa fase. 4.2.2.1 Elicitao dos Requisitos
Foi identicado nos trs projetos que a distncia entre as equipes de especicao e design impactaram bastante nas atividades subseqentes da ER. Devido as diferenas tcnicas e culturais entre designer e engenheiro de requisitos, houve diculdade na comunicao entre essas duas equipes e conseqentemente impacto no incio de suas interaes. Neste trabalho os dados apontam para a importncia de se levar em considerao o design da aplicao durante as fases inicias da ER, no intuito de evitar retrabalho futuro ao conseguir um feedback mais rpido e constante do stakeholder (REQ-ENTREVISTAS-05 7 ). O entrevistado do Projeto 1 armou que em um projeto anterior houve a utilizao de storyboards desde o incio do projeto e atravs do uso dessa tcnica houve um maior entendimento dos requisitos (como podemos ver no [FRAGMENTO-2]). Para o entrevistado isso auxiliou na execuo das fases seguintes, enfatizando que a criao e manuteno de storyboards na Engenharia de Requisitos corrobora para o sucesso do projeto (REQ-ENTREVISTAS-07 8 ). Com a denio das telas, foi possvel ter mais detalhes da aplicao, o que facilitou nas demais disciplinas da ES: arquitetura, desenvolvimento e testes. [FRAGMENTO-2][ENTREVISTA][ENT1-PRJ-1] Num projeto anterior ns desenvolvemos tudo, neste segundo o design est sendo feito separado, ento a gente sente a necessidade de aps coletar os requisitos, possuir os storyboards em mos. Infelizmente, agora os storyboards esto sendo feitos tardiamente, impactando no andamento do projeto. Por exemplo, tem um
do fragmento, meio de coleta utilizado e legenda contendo a identicao do entrevistado design e usabilidade nas etapas da Engenharia de Requisitos. A partir dessa integrao ser possvel aumentar a estabilidade dos requisitos e consolidar o modelo navegacional do sistema. 8 Criar e manter os storyboards como artefato para a elicitao, documentao e validao dos requisitos.
7 Integrar 6 Identicador
46
storyboard sendo desenvolvido aps a primeira interao, quando os requisitos todos j foram coletados e a equipe de desenvolvimento j est implementando. Em um dos projetos entrevistados (Projeto 3) foi identicado um apelo muito forte para o desenvolvimento centrado no usurio, o stakeholder em questo possui uma grande preocupao com a usabilidade do software, buscando realizar testes de usabilidade com usurios antes do software ser realmente desenvolvido, essa prtica trs por conseqncia uma instabilidade nos requisitos previamente levantados (REQ-ENTREVISTAS-07, REQ-ENTREVISTAS05). Para esse projeto em especco (Projeto 3) o uso de tcnicas de prototipao em papel [Sny03] possibilitou que os testes de usabilidade fossem realizados mais interativamente com o usurio e de uma forma mais barata. Essa tcnica tambm permitiu que o stakeholder inuenciasse de maneira mais intuitiva na navegao e nas funcionalidades do software (REQENTREVISTAS-08 9 ) atravs de rabiscos no artefato, os quais eram posteriormente alterados pelo Designer de Interface. Identicamos que as ferramentas de comunicao sncrono e assncrono utilizados durante o processo impactavam nessa interao, fazendo-se necessrio reunies presenciais para a denio dos requisitos iniciais do sistema. [FRAGMENTO-3][ENTREVISTA][ENT3-PRJ-3] A elicitao uma etapa bastante crucial da Engenharia de Requisitos, pois no adianta documentarmos bem se elicitamos errado. Nesta fase a presena do stakeholder e/ou cliente fundamental e ela deve ser a mais presencial possvel, tanto a nvel de conforto do stakeholder, quanto em poder de elicitao dos requisitos. Algumas atividades de elicitaco at conseguimos realizar de maneira remota, mas quando necessrio: discutir, argumentar e negociar. preciso realizar uma reunio presencial. 4.2.2.2 Documentao dos Requisitos
Para esse trabalho consideramos que o nvel de detalhamento dos requisitos desejado precisa fornecer o suporte necessrio para que a equipe de desenvolvimento possa dar prosseguimento suas atividades. Ou seja, os requisitos devem prover os subsdios para as demais disciplinas da ES. Identicamos que o detalhamento de requisitos crucial para todas as demais fases do
os requisitos juntamente com o cliente de maneira mais prxima possvel. De modo a evitar ao mximo os problemas de comunicao. Para esse processo consideramos que a elicitao deve ser realizada de maneira presencial e no distribuda.
9 Elicitar
47
desenvolvimento do projeto. Como as equipes esto distribudas, necessrio que ela tenha o mximo de detalhe possvel e o mnimo de ambigidade, para que as equipes venham a minimizar a necessidade de comunicao entre elas. Identicamos nos projetos que quando os requisitos esto pouco detalhados, no existe informaes a respeito da navegabilidade do software ou do design da aplicao. [FRAGMENTO-4][ENTREVISTA][ENT1-PRJ-1] Por exemplo, uma coisa voc ser visitante e outra coisa voc ter acesso a uma rea restrita, essa rea restrita seria disponvel num link, ou a pgina principal j conteria login e senha para voc entrar na rea restrita?. Ento assim ai diferente, pode ser um detalhe, mais para requisitos isso no vai ter um detalhe, por que ter o que "rea restrita". Agora para teste no, tem todo o detalhamento do teste. Como vimos no [FRAGAMENTO-4] o nvel de detalhamento dos requisitos impacta principalmente na equipe de testes, que precisa desse artefato para criao dos casos de testes (REQ-ENTREVISTAS-09 10 ). Em uma outra armao ([FRAGMENTO-5]) o entrevistado reconhece que os requisitos especicados por eles no do o devido suporte para atividades como modelagem de dados (REQ-ENTREVISTAS-09) por exemplo. [FRAGMENTO-5][ENTREVISTA][ENT1-PRJ-1] Pois , nesse estudo de caso, a maioria das funcionalidades j existem, os requisitos estavam criados. As coisas que no estavam ento tinham que ser denidas e sim demonstrar como isso estaria disponvel no software. Uma das tenses encontradas foi a inferncia do engenheiro de requisitos na navegabilidade do sistema, afetando na usabilidade do mesmo a qual de responsabilidade do designer de interface. Logo as inferncias feitas pelo engenheiro de requisitos, tiveram de ser revistas e retrabalhadas, demandando novas alteraes no documento de requisitos (REQ-ENTREVISTAS05). Como o designer s tomou conhecimento do documento de requisitos e no participou do processo de elicitao, diversos conceitos que j haviam sido consumados ressurgiram, trazendo instabilidade aos requisitos j documentados (REQ-ENTREVISTAS-05), nesse momento o entrevistado reconhece que houve a necessidade de aliar o designer de interface com o engenheiro de requisitos (como podemos ver no [FRAGMENTO-6]). Buscando melhorar o detalhamento dos requisitos e diminuir a instabilidade dos requisitos, achamos importante denir
os requisitos de modo a dar o suporte as demais fases da engenharia de software: arquitetura, desenvolvimento e testes.
10 Detalhar
48
os requisitos de interface durante a fase elicitao, para que eles j fossem levados em considerao durante a documentao e desse o suporte necessrio para um maior entendimento da aplicao durante a validao dos requisitos. [FRAGMENTO-6][ENTREVISTA][ENT3-PRJ-3] A gente repassou o documento de requisitos para os designers, e da eles j comearam a desenvolver. A nica coisa que complicada, quando os requisitos so repassados para os desenvolvedores, ento o cdigo est sendo feito, os designers esto criando as telas, porm os requisitos no param nunca e tendem a ser renados. Deve-se ento manter a sincronia de forma distribuda entre esses trs pontos: requisitos, design e desenvolvimento. 4.2.2.3 Validao dos Requisitos
Apenas um dos entrevistados mencionou a respeito da validao dos requisitos, os demais projetos ainda no tinham passado por essa etapa do processo. Segundo o entrevistado a validao dos requisitos foi realizada de maneira presencial, enviando o artefato e esperando a assinatura do cliente. Aps a assinatura ocorre a reunio com a equipe de desenvolvimento para minimizar a ocorrncia de dvidas a respeito do DER.
4.3
Requisitos Extrados da Entrevista Semi-estruturada com os Gerentes de Projeto (F2)
Os requisitos obtidos durante as fases de anlise que compem o processo de pesquisa descrito neste trabalho indicam a necessidade de adoo de alguns novos procedimentos para a elaborao de um processo de Engenharia de Requisitos em ambientes distribudos de desenvolvimento. Como pudemos observar na Seo 4.1, a partir das informaes coletadas na entrevista semi-estruturada, pde levantar um conjunto de requisitos recorrentes e importantes para a Engenharia de Requisitos no ambiente de DDS. A seguir so apresentados os requisitos obtidos que foram utilizados para a especicao do processo de Engenharia de Requisitos. Estes requisitos podem ser utilizados como referenciais para a elaborao de outros processos de desenvolvimento de software. Referenciais estes que podero conduzir novas pesquisas, novas metodologias de aplicao e novas posturas a serem assumidas. Percebe-se tambm que esses requisitos j foram citados em trabalhos anteriores como
4.3 REQUISITOS EXTRADOS DA ENTREVISTA SEMI-ESTRUTURADA COM OS GERENTES DE PROJETO (F2) 49
boas prticas de engenharia de software, sua citao colocada ao nal para enfatizarmos a relevncia do mesmo e demonstrar a importncia da teoria quando aplicada na prtica. REQ-ENTREVISTAS-01 : Disponibilizar a descrio do processo em um site. Para que todos os integrantes do projeto tenham acesso com facilidade as etapas e procedimentos do processo institudo [Sof01]. REQ-ENTREVISTAS-02 : Usar meios sncronos de comunicao. Os meios sncronos aumentam o nvel de comunicao informal no projeto, estudos indicam que o uso de comunicao informal aumenta o nvel de conana da equipe [HAB+ 02] [MH01] [Car98]. Alm de diminuir ocorrncia de conitos, em relao aos meios assncronos, gerados por malentendimentos da comunicao. REQ-ENTREVISTAS-03 : Usar meios assncronos de comunicao. Os meios assncronos so mais formais que os sncronos e possuem a vantagem de poder enviar uma mensagem sem ser necessria a presena da contraparte [Car98] [HM01]. REQ-ENTREVISTAS-04 : Institucionalizar um processo nico a ser seguido por todos os integrantes das equipes distribudas [CA01], buscando sincronizar a execuo das atividades atravs de artefatos de entrada e sada [HM01]. REQ-ENTREVISTAS-05 : Integrar design e usabilidade nas etapas da Engenharia de Requisitos. A partir dessa integrao ser possvel aumentar a estabilidade dos requisitos e consolidar o modelo navegacional do sistema. REQ-ENTREVISTAS-06 : Disponibilizar um repositrio unicado de artefatos. A equipe deve trabalhar somente nesses repositrios para que no haja conitos de verses entre os mesmos [Kar98]. REQ-ENTREVISTAS-07 : Criar e manter os storyboards como artefato para a elicitao, documentao e validao dos requisitos. REQ-ENTREVISTAS-08 : Elicitar os requisitos juntamente com o cliente de maneira mais prxima possvel. De modo a evitar ao mximo os problemas de comunicao. Para esse processo consideramos que a elicitao deve ser realizada de maneira presencial e no distribuda. REQ-ENTREVISTAS-09 : Detalhar os requisitos de modo a dar o suporte as demais fases da engenharia de software: arquitetura, desenvolvimento e testes.
C APTULO 5
Estudo de Caso
O desenvolvimento da teoria no apenas orienta a fase de coleta de dados do estudo de caso, mas tambm permitir a generalizao dos dados do estudo de caso. Segundo YIN [Yin05] essa generalizao chamada de "generalizao analtica"podendo ser utilizada quando ela envolver um (caso nico) ou mais casos (caso mltiplo). Uma reclamao muito recorrente associada a estudos de caso a diculdade de generalizar de um caso a outro. Alguns analistas s vezes selecionam uma quantidade de casos "representativo". Porm muito provvel que um conjunto expressivo de casos consiga rebater satisfatoriamente essa reclamao [Yin05]. O estudo de caso est inserido num projeto de pesquisa, onde os requisitos iniciais do sistema esto descritos em trabalhos de graduao, mestrado ou doutorado de um grupo de estudo [CCeTE07]. Esses trabalhos servem como uma base formal de conhecimento para a especicao dos requisitos do sistema.
5.1
Descrio do Estudo de Caso
O projeto Agentes Micromundo e Anlise do Desenvolvimento no uso de Instrumentos Multimdia (AMADeUs-MM) [Sou05] serviu de estudo de caso para a elaborao do processo de Engenharia de Requisitos proposto nesse trabalho. Esse projeto tem por objetivo o desenvolvimento de um ambiente virtual de aprendizagem. O projeto est estruturado basicamente em cinco mdulos: Cadastro responsvel pelos cadastros bsicos do sistema, como, por exemplo, o de usurios. Gesto de Contedo contempla o processo de administrao dos contedos de aprendizagem disponibilizados no portal. Avaliao tratar das diferentes formas para a avaliao dos alunos de um curso [Ram05]. Percepo Social possui um conjunto de requisitos de usabilidade que tratam do conceito de transparncia social dos usurios do sistema [Alv06]. 51
52
CAPTULO 5 ESTUDO DE CASO
Middleware de Comunicao de Componentes Sncronos O componente de middleware [Alv05] responsvel por possibilitar a comunicao entre o servidor do portal AMADeUs-MM e as demais aplicaes clientes que possam ser integradas ao portal como por exemplo: jogos educacionais e mdias interativas [Sou05]. A arquitetura do AMADeUs-MM pode ser melhor compreendida visualizando-se a arquitetura da aplicao conforme exposto na Figura 5.1.
Figura 5.1 Arquitetura do AMADeUs-MM [Sou05]
A tcnica de observao participante [Fli04] realizada dentro do estudo de caso teve como objetivo identicar problemas na documentao e validao de requisitos ampliados por fatores relacionados ER em ambientes de desenvolvimento distribudos de software. Visando atingir este objetivo, foram observados nesse projeto de desenvolvimento de software: engenheiros de requisitos, desenvolvedores e stakeholders, na execuo de suas atividades. A observao foi realizada atravs de anlise dos dados colhidos de diferentes ferramentas de comunicao utilizadas no projeto AMADeUs-MM [Sou05] conforme especicado na Seo 3.6.2. A verso inicial do documento de requisitos desse estudo de caso foi elaborada a partir da seleo, priorizao e organizao de todos os requisitos extrados dos trabalhos cientcos realizados pelo grupo de estudo [CCeTE07], organizados em um nico artefato. Consideramos que essa fase pde ser enquadrada como: negociao dos requisitos [KS98], devido a sua diculdade [DESG00] esta foi tratada de maneira presencial no estudo de caso, por intermdio de comunicao face a face entre stakeholder, engenheiro de requisitos e designer de interface.
5.2 AMBIENTE DE DESENVOLVIMENTO
53
Para esse estudo de caso focamos nossa anlise nas fases de documentao e validao da ER realizada em um ambiente de desenvolvimento distribudo de software conforme nosso problema de pesquisa descrito na Seo 1.2.
5.2
Ambiente de Desenvolvimento
Devido s divergncias de horrios entre os integrantes, e a existncia de uma unidade distribuda de desenvolvimento com 800 km de distncia da unidade principal de desenvolvimento (Recife) (REQ-OBSERVACAO-01 1 . Podemos classicar o ambiente de desenvolvimento do estudo de caso em como de Distncia Nacional e nveis de disperso Temporal e Geogrca conforme o modelo de referncia de Prikladnicki [Pri03]. Na unidade principal de desenvolvimento situada em Recife-PE dentro da Universidade Federal de Pernambuco esto presentes: gerente de projeto, gerente de qualidade, designer de interface um engenheiro de requisitos e o stakeholder do projeto (REQ-OBSERVACAO-03 2 ). A unidade distribuda de desenvolvimento situada em Petrolina-PE possui um engenheiro de requisitos, um desenvolvedor e dois autores de trabalhos cientcos integrantes do grupo de estudo [CCeTE07] (REQ-OBSERVACAO-02 3 ).
5.3
Participantes do Estudo de Caso
Uma lio aprendida que a mudana do processo de Engenharia de Requisitos parte dos indivduos, ento vital tratar as pessoas com seus pers e especialidades. Logo, o envolvimento dos usurios de um processo uma fator bastante relevante para o seu sucesso. Se os indivduos tiverem motivao e entusiasmo em realizar as novas prticas, ento provavelmente essas prticas se tornaro permanentes [KVK+ 04]. A coluna Legenda da Tabela 5.1 servir como referncia aos participantes deste estudo de caso.
1 Diminuir as barreiras impostas pelas distncias geogrca e temporal das equipes de desenvolvimento distribudas. 2 Dividir os integrantes em papis de acordo com seus pers e responsabilidades. 3 Atender a equipes pequenas de desenvolvimento de software com 8 a 15 integrantes por equipe e apenas 1 stakeholder responsvel por validar e elicitar os requisitos.
54
Tabela 5.1 Participantes Estudo de Caso

Papel Gerente de Projeto Gerente de Qualidade Designer de Interface Stakeholder Engenheiro de Requisitos Voluntrio Engenheiro de Requisitos Engenheiro de Requisitos Especialista Gesto Contedo Especialista Avaliao Local Recife Recife Recife Recife Recife Recife Petrolina Petrolina Petrolina Petrolina Experincia (anos) 5 7 10 7 3 3 1 1 1 1 Legenda GPUPD GQUPD DIUPD STKUPD ERUPD VOUPD ER1UD1 ER2UD1 ESP1UD1 ESP2UD1
5.4
Categorizao dos Dados
Visando estruturar os dados extrados de diversas fontes e facilitar a codicao seletiva dos contedos usamos a ferramenta NVivo [QSR07], a qual possibilitou a criao e manipulao de um grande nmero de categorias. Dando o devido suporte para uma abordagem exploratria dos dados [Yin05]. Vimos na Seo 3.6.3 a importncia da codicao seletiva [Fli04]. Portanto, para anlise dos textos provenientes da pesquisa (logs de ferramentas de chat, correios-eletrnicos, artefatos) foi utilizada a codicao seletiva [Fli04] que gerou as categorias da pesquisa qualitativa. As categorias foram criadas, organizadas e includas na rvore de categorias do NVIVO [QSR07], este armazenou a transcrio de cada entrevista e as interao ocorridas durante o estudo de caso. A categorizao da rvore exposta na Figura 5.2 foi criada e reformulada vrias vezes de acordo com a grounded theory [Fli04].
5.5
Prticas de Comunicao do Projeto
A comunicao existente do projeto AMADeUs-MM pde ser realizada de forma presencial entre os integrantes de uma mesma unidade de desenvolvimento. Para a comunicao entre diferentes unidades de desenvolvimento, foram utilizadas diversas ferramentas de comunicao sncrona e assncrona com o intuito de diminuir as barreira da distncia ([HM01] [Kar98] [DESG00] [CA01]). Durante o perodo observado foram institucionalizados quatro meios de comunicao: correio eletrnico, lista de discusso, Skype [SL] (meio de comunicao baseado em VoIP) e Msn [Mic06a] como o instant messenger do grupo. Durante a execuo do projeto a ferramenta de
5.5 PRTICAS DE COMUNICAO DO PROJETO
55
Figura 5.2 rvore de Categoria do NVivo [QSR07]
instant messenger, serviu bastante para aumentar o uso de comunicao informal entre a equipe aumentando o esprito de equipe dos integrantes das unidades distribudas [CA01]. Nesse estudo de caso, a elicitao e negociao dos requisitos foi realizada atravs de reunies face a face na UPD. A UPD cou responsvel em delegar as atividade de detalhamento dos requisitos s demais unidades. Identicamos que logo no incio da execuo da atividade de detalhamento houve um grande uxo de comunicao entre a UPD e as UDS. Esse uxo bastante intenso por conta de resoluo de dvidas encontradas nas descries dos requisitos em "alto nvel". Agregado a isso, temos a troca de conhecimento tcnico entre as UDS, para isso fez-se uso de ferramentas de instant messaging [Mic06a] e VOiP [SL] para comunicao sncrona. Devido diferena de horrios algumas dvidas s puderam ser resolvidas atravs de meios assncronos como o correio eletrnico, o que impactou no tempo de entrega dos artefatos.
5.5.1
Skype
Skype [SL] um software gratuito capaz de fazer conexes sobre VoIP. O Skype foi concebido para permitir fazer chamadas gratuitas atravs da internet. Existem diversas verses para vrias plataformas (Windows, Linux, Macintosh) De acordo com o site do fabricante pudemos extrair as seguintes vantagens no uso do Skype [SL]:
56
Chamadas ilimitadas para outros utilizadores do Skype de qualquer parte do mundo; Boa qualidade de som; A lista de contatos do Skype mostra-lhe quando que os seus amigos esto online e disponveis para falar ou conversar. Um framework de segurana incorporando diversas protees a ataques contra os usurios. Permite audio conferncia para at 4 usurios Permite video-conferncia entre os usurios Desvantagens: Deveria prover mecanismo de gravao das conversas. Para reunies de validao dos requisitos os usurios sentiram a necessidade de grav-las. Atravs do Skype [SL] foi possvel ter acesso a um meio de comunicao mais rico em contexto Figura 2.1 a baixo custo. Com isso foi possvel haver uma melhor troca de conhecimento entre as unidades de desenvolvimento, aumentando a conana e melhorando a formao do esprito de equipe por parte das unidades distribudas. Foi por intermdio dessa ferramenta que foi possvel realizar as seguintes atividades: 1. Apresentao do Storyboard; 2. Acompanhamento da Documentao; 3. Reunio de Inspeo. 5.5.2 Microsoft Messenger
O uso de instant messaging no contexto de DDS muito comum, existindo inclusive relatos de casos de sucesso no uso dessa tecnologia. Segundo Herbleb [HAB+ 02], os instant messaging ajudam as equipes distribudas a entenderem o contexto do desenvolvimento aumentando o uso da comunicao informal, dois dos problemas que dicultam o desenvolvimento distribudo. Durante a execuo do estudo de caso, a ferramenta da Microsoft Messenger [Mic06a] foi utilizada. Um dos fatores fundamentais para sua adoo que todos os integrantes j possuam um usurio cadastrado e j tinham o hbito de usar a ferramenta. Vantagens: Quantidade de usurios disponveis;
5.5 PRTICAS DE COMUNICAO DO PROJETO
57
Mecanismos de percepo do status do usurio (ausente, ocupado, on-linee off-line); Transferncia de arquivos; Realizao de chat de modo texto com mais de um usurio; Armazenamento de log; Permite ligaes VoIP, contudo a qualidade do udio inferior a obtida pelo Skype. Desvantagens: Por ser um mecanismo de comunicao de baixo contexto (conforme a Figura 2.1), resolver conitos e explicar algumas dvidas levam mais tempo do que usando os meios de voz; Uso da ferramenta para ns pessoais, indivduo versus grupo de trabalho [HAB+ 02]. Herbleb props o desenvolvimento de uma nova rede de instant-messaging, somente para essa nalidade; No permite a realizao de udio conferncia. Para a coleta dos dados desse estudo de caso, essa ferramenta foi bastante importante, por conta da funcionalidade de gravao de logs, eles foram analisados, com o intuito de propor solues para esse trabalho. 5.5.3 Correio-Eletrnico
Na anlise de correios-eletrnicos desse estudo de caso conrmamos a armao de Carmel [CA01] de que os meios de comunicao assncronos promovem a coordenao das atividades. Como podemos ver no [FRAGMENTO-7], ele era muito utilizado principalmente para cobrana das atividades. [FRAGMENTO-7][CORREIO-ELETRONICO][GPUPD] 4 ER1UD1, estou acompanhando o documento de caso de uso da gesto de contedo e ele est a 4 dias parado. Ontem foi realizada reunio para justamente te auxiliar na realizao dessa tarefa. Logo gostaria de v-la caminhando. Atenciosamente. Como podemos ver tambm na Seo 5.7.5.1, atravs do correio eletrnico foi possvel auxiliar no planejamento da realizao das inspees (REQ-OBSERVACAO-18).
4 Correio
eletrnico do GPUPD cobrando a documentao dos casos de uso pela UDS.
58
5.5.4
Lista de Correio-Eletrnico
A lista de correio eletrnico foi o meio de comunicao assncrono utilizado principalmente para comunicar as decises tomadas no projeto ([FRAGMENTO-8]). Era atravs deste que as atas de reunio foram disponibilizadas para as demais unidades de desenvolvimento. (REQOBSERVACAO-06 5 ) Identicamos tambm que as cobranas a serem feitas para todos os integrantes do projeto foram realizadas nesta ferramenta ([FRAGMENTO-9]). [FRAGMENTO-8][LISTA-CORREIO-ELETRONICO][ER1UPD] 6 Ol pessoal, Esta semana, estarei trabalhando com ER2UD1 e ER1UD1 na confeco do Documento de Caso de Usos da Gesto de Contedo. Ontem, j reformulamos o template e comeamos e descrevemos alguns casos de uso. [FRAGMENTO-9][LISTA-CORREIO-ELETRONICO][ER1UPD] 7 Pessoal, Estou com atividade pendente do documento de casos de uso do modulo avaliao. Para mim as produes tcnicas cam mais produtivas em casa pois no sou constantemente parado como no CIn. Dessa forma estarei trabalhando na sexta-feira no documento de caso de uso em casa. Como trabalharei em casa, co comprometido em extrair ao menos 6 casos da dissertao do ESP2UD1. Um dos principias fatores que contribuem para a institucionalizao de um processo de desenvolvimento o envolvimento dos futuros gestores e usurios do processo desde o seu comeo [KVK+ 04]. Logo, a lista de correios-eletrnicos foi o mecanismo utilizado para cobrar o comprometimento com o seguimento do processo (REQ-OBSERVACAO-05 8 ) como podemos ver nos [FRAGMENTO-10][FRAGMENTO-11]. [FRAGMENTO-10][INSTANT-MESSAGING] 9 GPUPD - Olha, coloca na pauta tambm que os desenvolvedores tm de seguir o documento de caso de uso feito pelo ERUPD.
e disponibilizar as atas das reunies realizadas. Essas atas devero ser disponibilizadas atravs da lista de e-mails para que que todos tomem conhecimento do que foi decidido. 6 Correio eletrnico do ER1UPD contextualizando todos os integrantes de suas atividades. 7 Correio eletrnico do ER1UPD contextualizando a respeito de sua disponibilidade devido as atividades pendentes. 8 Processo unicado devendo ser seguido por todos os integrantes do projeto. 9 Fragmento de uma conversa em instant messaging contendo a necessidade de colocar na pauta de reunio o seguimento do processo
5 Criar
5.6 FERRAMENTAS COLABORATIVAS DE EDIO OBSERVADAS NO ESTUDO DE CASO
59
GPUPD - Pois eu vi que um desenvolvedor no estava seguindo o documento de caso de uso. GQUPD - ok [FRAGMENTO-11][LISTA-CORREIO-ELETRONICO][GQUPD] 10 Solicitamos aos bolsistas que ainda no leram o Plano de Projeto e/ou o Plano de Qualidade que o faam com certa urgncia, e em caso de dvida procurar pelos respectivos autores. So documentos bsicos para compreenso do processo de desenvolvimento do Projeto que contempla: preenchimento adequado (conforme orientao) da planilha de acompanhamento das atividades (TimeSheet); presena e pontualidade nas reunies com a equipe, principalmente na reunio semanal (todas as quintas, 14h); informar a Gerncia qualquer tipo de diculdade. Atravs desses indcios pudemos comprovar a armao de Carmel [CA01] de que os meios de comunicao assncronos so mais formais, e por conta disso h um maior comprometimento dos integrantes com o que foi acordado no uso desse meio. Conclumos ento que com o uso desses meios de comunicao assncronos podemos melhorar a coordenao e comprometimento das unidades distribudas.
5.6
Ferramentas Colaborativas de Edio Observadas no Estudo de Caso
Os artefatos caram disponveis em ferramentas colaborativas. Isto auxiliou na disponibilizao do artefato para os demais integrantes do projeto. 5.6.1 Groove Virtual Ofce
O Groove [GN06] um ambiente Peer-to-Peer (P2P) que possibilita que grupos de trabalho realizem suas atividades colaborativamente. Dando o suporte para ferramentas de agenda, para
envia um correio eletrnico para a a lista de correio eletrnico contendo o pedido de seguimento do processo ocorrida durante a reunio do projeto
10 GQUPD
60
marcar reunies, chat assncrono, editor de notas, frum de discusso e a mais utilizada compartilhamento de arquivos. Para o projeto, teve-se a promessa de ser uma ferramenta poderosa, que conseguiria integrar as duas unidades de desenvolvimento, com esses recursos. Em uma pesquisa (como veremos nas transcries a seguir) entre os integrantes do projeto pudemos identicar as seguintes vantagens e desvantagens no uso desta ferramenta. Vantagens: Backup Distribudo o backup no cava centralizado em uma mquina, cada cliente era tambm servidor de arquivos para os demais ([FRAGMENTO-12][FRAGMENTO-14]). Espao Fsico como o Groove um cliente P2P e os arquivos cam armazenados na mquina, o espao fsico do ambiente, depender do espao livre em disco. Porm um ambiente grande inibe os usurios a trabalharem em mquinas distintas. D para enviar uma quantidade enorme de documentos para novos membros ([FRAGMENTO12][FRAGMENTO-14]). Edio de Texto Colaborativa O groove permite a edio de textos colaborativa ([FRAGMENTO12]). Trabalho Distribudo se o ambiente estiver instalado e congurado permite que os integrantes colaborem entre si disponibilizando os arquivos para todos os integrantes do ambiente ([FRAGMENTO-12]). Desvantagens: Versionamento no h controle de verso automtico, isso feito atravs de arquivos renomeados ([FRAGMENTO-14][FRAGMENTO-16]). Segurana dos Artefatos se um usurio com poder de escrita apagar todos os arquivos, isso seria reetido na sincronizao do ambiente pelo cliente P2P. Acessibilidade o groove necessita de que um cliente esteja instalado na mquina. Um usurio cadastrado no ambiente e a sincronizao efetuada. Para cada novo usurio registrado no ambiente, necessrio fazer download de todo o ambiente, inibindo o uso para usurios de trabalharem em qualquer lugar com facilidade. Os integrantes do projeto preferem uma ferramenta colaborativa que no necessite de uma aplicao cliente conforme podemos ver nos fragmentos ([FRAGMENTO-13][FRAGMENTO-14][FRAGMENTO15]).
5.6 FERRAMENTAS COLABORATIVAS DE EDIO OBSERVADAS NO ESTUDO DE CASO
61
Difuso do Uso no Projeto Devido aos problemas de acessibilidade o groove foi uma ferramenta pouco utilizada dentro do projeto. Geralmente as pessoas levavam os artefatos para casa e adicionavam arquivos e sincronizavam no ambiente que tinham instalado em casa ([FRAGMENTO-14][FRAGMENTO-15]). [FRAGMENTO-12][LISTA-CORREIO-ELETRONICO][STKUPD] Acho o groove bom para termos acesso a um grande conjunto de documentos com rapidez. um backup distribudo e seguro. Se alguns usurios perderem no perdemos tudo. D para enviar uma quantidade enorme de documentos para novos membros. D para puxar o espao para outro micro com facilidade criando um outro local de trabalho. D para co-editar os textos de forma sncrona. [FRAGMENTO-13][LISTA-CORREIO-ELETRONICO][DIUPD] Por exemplo, perde feio para o Writely no sentido da portabilidade... No Writely, basta estar Online com um browser para ter acesso aos contedos. [FRAGMENTO-14][LISTA-CORREIO-ELETRONICO][DIUPD] Sei que complicado manter... Mas o interessante seria um servidor dedicado se encarregando de servir os contedos para qualquer um que acesse remotamente. Os arquivos sendo distribudos sobre demanda, porm manter localmente uma cpia de todos os arquivos atualmente complicado. [FRAGMENTO-15][LISTA-CORREIO-ELETRONICO][ERUPD] Nos dias de hoje, a gente almeja interagir com softwares geis e exveis, o GROOVE o inverso disso. Para conseguir logar todo um processo. Confesso que usei muito pouco este software, por isso no tenho muito o que comentar, mas d para apontar seu problema principal: diculdade de acesso O Groove teve baixa aceitabilidade no projeto por parte dos integrantes. Os indcios apontam que devido diculdade de acesso dos usurios, e a descentralizao dos arquivos no servidor. Com o andamento do projeto o groove cou relegado a armazenar referncias bibliogrcas, gravaes em udio de reunies, atas e pautas. E excludo denitamente das ferramentas essenciais para o desenvolvimento do projeto.
62
5.6.2
Writely
Editor de texto colaborativo e baseado na web que atualmente est em verso de testes, neste editor de texto online os documentos podem ser compartilhados, permitindo a co-autoria sncrona do documento. Possui ainda mecanismos de controle de verso e segurana para os documentos. Atravs desse estudo de caso pudemos identicar que muitas funcionalidades presentes no Writely [Goo] foram essenciais para a concluso desse trabalho. A insero de comentrios por parte dos autores foi uma funcionalidade que auxiliou bastante no melhoramento da documentao e validao dos DER. Pois os comentrios puderam ser inseridos de forma assncrona alm de carem situados na posio onde se encontrava a dvida ou a melhoria proposta. Vatangens: Controle de verses do documento, permitindo comparar diferentes verses; Tornar o documento pblico ou visvel apenas para um grupo de usurios. Disponibilizando uma URL para visualizao; Edio sncrona de texto com os diversos autores do documento. Adicionar comentrios ao texto, informando o autor. Desvantagens: Ausncia de corretor ortogrco e semntico; Por ainda estar em verso Beta, s vezes cdigos HTML se misturam ao texto, quebrando a formatao do documento; Ausncia de mecanismos de formatao automtica. Ausncia de um ndice automtico.
5.7
Fases Observadas da Engenharia de Requisitos no Estudo de Caso
A Engenharia de Requisitos aplicada nesse estudo de caso foi baseada nas fases clssicas de elicitao, negociao, documentao e validao dos requisitos proposto por Kotonya [KS98] Figura 2.2.
5.7 FASES OBSERVADAS DA ENGENHARIA DE REQUISITOS NO ESTUDO DE CASO
63
O estudo de caso foi observado e modicado durante essa etapa de observao, sendo testadas: ferramentas, tcnicas de Engenharia de Requisitos, e alteraes nos artefatos de entrada e sada das atividades durante a execuo do processo. 5.7.1 Elicitao de Requisitos
No desenvolvimento com equipes co-localizadas, a coleta de requisitos ocorre em reunies face a face, considerada a forma mais efetiva de comunicao [HG98]. Nesses encontros tornam mais fceis tambm as atividades de negociao e resoluo de conitos. Nesse estudo de caso nossa observao cou mais concentrada nas fases de documentao e validao dos requisitos. 5.7.1.1 Prottipo em Papel
Visando melhorar essa etapa, ela foi alterada com tcnicas de prototipao em papel, havendo elicitao presencial entre designer e engenheiro de requisitos. Esboos em papel so gerados nessas sees, para dar o suporte as atividades posteriores da documentao dos requisitos e desenvolvimento dos storyboards, os quais foram feitos em paralelo (REQ-ENTREVISTAS-01, REQ-ENTREVISTAS-03, REQ-ENTREVISTAS-04). Como podemos ver na Figura 5.3, o prottipo desenvolvido durante nas sees de elicitao possuem um baixo grau de detalhamento e permite que o stakeholder, engenheiro de requisitos possam exprimir opnies e chegarem num consenso do que dever ser renado na forma de um storyboard como na Figura 5.4.
Figura 5.3 Prottipo em papel desenvolvido durante a elicitao em grupo
Como podemos ver na Figura 5.4 o storyboard desenvolvido pelo designer muito mais rico em detalhes do que a verso em papel Figura 5.3 e por estar em formato eletrnico, facilita a distribuio do artefato para os demais envolvidos no desenvolvimento do software.
64
Figura 5.4 Storyboard desenvolvido pelo designer de interface
Defendemos nesse trabalho que o artefato de sada da elicitao dos requisitos desse processo deve ser um storyboard no nvel de detalhamento da Figura 5.4, pois como veremos na Seo 5.7.3.2 ele permite uma melhoria na qualidade do artefato gerado e diminui a ocorrncia de requisitos duplicados.
5.7.2
Negociao dos Requisitos
O processo de negociao de requisitos tenta resolver conitos entre usurios/clientes sem necessariamente comprometer a satisfao dos objetivos de cada um. As atividades de negociao identicam as principais necessidades de cada usurio e priorizam os requisitos identicados [KS98]. Durante a observao no estudo de caso no ocorreu nenhuma atividade de negociao dos requisitos. A negociao dos requisitos j tinha acontecido em um momento anterior e foi realizada de modo presencial, com a participao de todos os integrantes do projeto. Conforme dito na Seo 5.7.1 observao cou mais concentrada nas fases de documentao e validao dos requisitos.
5.7.3
Artefatos de Entrada para a Documentao e Validao dos Requisitos
Consideramos que o documento de casos de uso o DER do DSD-REQ-PROCESS. Levando em considerao que o DER um artefato de entrada para a fase de codicao, necessrio um alto nvel de detalhamento nos requisitos para um suporte efetivo durante a implementao [DZVP04] [Sof05] (REQ-ENTREVISTAS-02). Nessa seo foram realizadas duas observaes no estudo de caso com diferente artefatos de entrada. Em um primeiro momento, observamos o detalhamento dos requisitos em casos de uso a partir dos requisitos do sistema capturados durante a elicitao. Em um segundo momento
65
adicionamos storyboards como artefato de entrada dessa atividade. 5.7.3.1 Observao 1: Sem o uso de Storyboard como Artefato de Entrada
A arquitetura da aplicao permitiu o desenvolvimento de mdulos (Figura 5.1), logo a especicao de requisitos tambm cou dividida dessa forma. Um dos mdulos foi enviado para ser detalhando na UD1. Para essa observao buscamos analisar o processo exposto no diagrama de atividades da Figura 5.5. Como base de informao para a denio e documentao dos requisitos utilizamos duas bases de informao: Anlise de competidores do problema Inicialmente foram denidos quais os concorrentes em potencial seriam examinados. Posteriormente foi realizada uma anlise extraindo as vantagens e desvantagens, propondo solues relevantes para o problema a ser tratado; Base formal de conhecimento do problema Por se tratar de um projeto de pesquisa, as teses e dissertaes defendidas pelo grupo de pesquisa CCTE [CCeTE07] serviram como base para o desenvolvimento da soluo.
Figura 5.5 Processo de Elicitao dos Requisitos sem Uso do Storyboard
66
Parte do DER comeou a ser especicado na UD1 com um acompanhamento da UPD para que fossem seguidos os padres dos artefatos. O documento foi criado em 12/01/2006 e evoluiu at o dia 02/02/2006, antes de ser validado foi realizada uma anlise no documento em 07/02/2006, nesta anlise foi encontrada uma grande quantidade de requisitos duplicados e que no correspondiam ao mdulo em questo. Logo foi necessrio a realizao de uma auditoria de coleta de mtricas, buscando mensurar a qualidade do documento especicado. Como juzes foram escolhidos 3 participantes da UPD os quais possuam a melhor viso sistmica do projeto alm de conhecer tcnicas de especicao de casos de uso (tcnica de especicao utilizada no artefato) [Sof05] [ACB02]. Os mesmos preencheram planilhas de coletas de mtricas (Apndice B) baseada nos critrios de qualidade dos requisitos proposta pela IEEE 830 [Byr94].
Tabela 5.2 Mtricas do DER do mdulo desenvolvido na UD1 de 12-01-2006 a 02-02-2006
Esta viso pouco compartilhada entre as UDS fez com que fossem documentados requisitos divergentes. A falta de viso sistmica do projeto por parte dos integrantes da UD1 gerou duplicaes nos requisitos. Como resultado, vericamos que os casos de uso desenvolvidos tiveram um baixo nvel de detalhamento. O engenheiro de requisitos da UD1, no compreendeu os requisitos para a execuo dessa atividade. Nesses resultados identicamos que o uso de storyboards poderia prover mais detalhes para o detalhamento dos requisitos alm inibir a ocorrncia de requisitos duplicados.
67
5.7.3.2
Observao 2: Com o uso de Storyboard como artefato de entrada
Visando melhorar a documentao nas UDS, foram utilizadas tcnicas de prototipao em papel [Sny03] e um posterior detalhamento na forma de stroyboard, havendo elicitao presencial entre designer e engenheiro de requisitos (REQ-ENTREVISTAS-04) como descrito no diagrama de atividades da Figura 5.6. A principal mudana entre os dois processos observados (Figuras 5.6 e 5.5) se deu ao fato da centralizao da elicitao, sendo de responsabilidade exclusiva da UPD. O principal motivador para esta deciso foi o fato do stakeholder se encontrar na mesma UDS. Levando-se em considerao que a participao sncrona dos stakeholders impactam bastante na efetividade da elicitao [Llo01].
Figura 5.6 Processo de Elicitao dos Requisitos com uso do storyboard
68
Na prtica os storyboards foram detalhados e validados juntamente com o stakeholder, atravs de uma verso impressa do storyboard (REQ-OBSERVACAO-10 11 ). Por ser impressa o stakeholder teve a liberdade de rabiscar o artefato, renando o mesmo. Quando criados, os storyboards serviram de artefato de entrada para os analistas das UDS, esses anexaram as imagens ao DER e passaram a documentar o DER a partir dos Storyboards gerados (REQ-OBSERVACAO-11). O intuito dessa prtica no foi apenas auxiliar na documentao, mas tambm durante a validao do DER entre os stakeholders. As mtricas coletadas nessa pesquisa tiveram a participao dos mesmos atores e da mesma planilha de coleta de mtricas. Por ser referente ao mesmo mdulo, os autores detinham mais conhecimento dos requisitos referentes ao problema estudado.
Tabela 5.3 Mtricas do DER do mdulo desenvolvido na UD1 de 13-02-2006 a 24-02-2006
Nesses resultados identicamos que com o uso de storyboards pde-se obter mais detalhes para uma documentao mais consistente do DER, inibindo a duplicao dos requisitos e o detalhamento de requisitos que no correspondessem ao mdulo a ser especicado. De acordo com as mtricas apresentadas o uso dos storyboards para a documentao do DER no contexto de DDS, foi possvel observar um maior entendimento dos requisitos entre as equipes, como tambm serviu de suporte para um melhor detalhamento na especicao do DER (REQ-OBSERVACAO-11 12 ). Apesar de encontrarmos requisitos que no poderiam ir para a fase de implementao, consideramos que isso se deve ao tempo de experincia dos
11 Validar presencialmente os artefatos produzidos durante a fase de elicitao, de modo a mitigar a ocorrncia de erros nessa fase. Somente disponibilizar esses artefatos para as unidades distribudas quando estes estiverem validados. 12 Anexar os storyboards nos casos de uso para facilitar o entendimento dos requisitos e diminuir a ocorrncia de conito de verses. Atravs dos storyboards anexo, ser mais fcil realizar a validao dos requisitos, comparando as imagens com o que est documentado.
69
autores que de de aproximadamente 1 ano, com equipes mais experientes possivelmente teremos uma maior quantidade de requisitos que poderiam ir para a fase de implementao. Outra mtrica bastante relevante para essa pesquisa foi a diminuio dos casos de uso duplicados e que no correspondem ao mdulo a ser desenvolvido. Devido centralizao da elicitao dos requisitos, a qual gerava storyboards como artefato de entrada para a documentao, aumentou a coordenao do que deve ser documentado por cada UDS, permitindo que o engenheiro de requisitos que focado nas funcionalidades presentes nos storyboards. 5.7.4 Documentao de Requisitos
No perodo de observao da fase de documentao dos requisitos, esta sofreu modicaes que visavam diminuir a distncia entre as unidades distribudas. Estudos indicam que quando os requisitos no esto claramente denidos ou documentados, como nos casos em que os requisitos esto disponveis na forma de descries de "alto nvel"a respeito das funcionalidades do sistema, aumenta a ocorrncia de ambigidade nas funcionalidades requeridas e por conseqncia retrabalho [DZVP04]. A fase de documentao de requisitos, busca detalhar os requisitos do sistema encontrados durante a fase de elicitao. nessa fase em que h uma mitigao da ocorrncia de ambigidade e a partir desse detalhamento que o sistema ser implementado pelos desenvolvedores. Para esse estudo de caso foram observados o detalhamento dos requisitos funcionais em casos de uso, como sugere o RUP [Sof05]. 5.7.4.1 Seleo da Ferramenta de Edio dos Artefatos
O uso de ferramentas de edio de textos usadas para a elaborao dos artefatos da Engenharia de Requisitos. Alm dos mecanismos de distribuio dos mesmos devem ser um dos principais pontos a serem observados para adoo de um processo de Engenharia de Requisitos distribuda. Logo no incio da observao os artefatos foram produzidos com editores de texto monousurio e distribudos atravs de correio eletrnico ([FRAGMENTO-37]). Isso impactou na consistncia de verses e inviabilizou a documentao em paralelo por autores distribudos. [FRAGMENTO-37][LISTA-CORREIO-ELETRONICO][ER1UPD] 13 Estou enviando uma verso bem inicial, faltando ainda muitos casos de uso, para a gente discutir e validar pelo menos esses. Para depois eu prosseguir nos demais,
13 Correio
eletrnico do ERUD1 anexando o documento de requisitos em uma mensagem.
70
se pudermos conversar a tarde agradeceria. Para resolver esse problema de troca do artefato atravs de correio eletrnico, foi adotado o Groove Virtual Ofce [GN06], esse permitiu que as unidades distribudas tivessem um repositrio nico, possibilitando tambm a edio colaborativa (REQ-OBSERVACAO-07). Contudo cada usurio precisava ter esse software instalado e a obrigao de sincronizar os artefatos constantemente na mquina onde ele fora instalado (ver Seo 5.6.1). Os integrantes do projeto no possuam mquina cativa logo tiveram problemas na obteno dos artefatos do projeto. Outro ponto negativo encontrado no uso do Groove Virtual Ofce [GN06], foi a ausncia do controle de verso dos artefatos. [FRAGMENTO-16][LISTA-CORREIO-ELETRONICO][ER1UD1] Estamos enviando o documento de casos de uso corrigidos e de acordo com a dissertao do ESP1UD1. A ultima no tinha detalhamento, pois era a verso mais antiga da dissertao, no caso a que se encontra no Groove. Ao analisarmos o fragmento ([FRAGMENTO-16]), sentimos a necessidade de melhorar a disponibilizao dos artefatos e manter o controle de verso dos mesmos, a partir desse momento passamos a utilizar um editor de texto colaborativo baseado na web chamada Writely [Goo]. A edio de texto foi testada e aprovada entre os integrantes, pois com essa ferramenta houve um verdadeiro ganho de produtividade no processo promovendo: consistncia de verses, distribuio do artefato, co-autoria sncrona e visualizao da evoluo do DER (REQ-OBSERVACAO-07 14 ), (REQ-OBSERVACAO-09), (REQ-OBSERVACAO14), (REQ-OBSERVACAO-16 15 ). 5.7.4.2 Apresentao do Storyboard
Vimos na Seo 5.7.3 a importncia do uso do storyboard como artefato de entrada para a fase de documentao dos requisitos. Testamos ento o detalhamento em casos de uso [ACB02] a partir dos requisitos inicias do sistema capturados durante a elicitao juntamente com o storyboard desenvolvido nessa mesma fase pela UD1. Antes de realizarmos o detalhamento dos requisitos necessrio entend-los. Contudo, a quantidade de informaes adquirida durante as fases de elicitao e documentao de requisitos muito maior do que as descries existente nos artefatos produzidos [Lop03]. Por isso a
14 Utilizar ferramentas colaborativas que auxiliem a ER. Estudos indicam que essas ferramentas diminuem a distncia entre os integrantes sendo indicadas para ambientes de DDS [Bri06] [AG98] [Car98]. 15 Checar se foram realizadas as devidas correes de acordo com a reunio de inspeo. Devido as divergncias de horrio dos integrantes interessante que essa atividade seja realizada por intermdio dos meios assncronos (e-mail e ferramenta de edio colaborativa).
71
troca de conhecimento e experincia entre as unidades distribudas fator crucial para o sucesso da Engenharia de Requisitos em ambientes distribudos de desenvolvimento. Portanto sugerimos que a apresentao do storyboard seja realizada logo no incio da fase de documentao (detalhamento dos requisitos). Atravs do acompanhamento da evoluo do artefato atravs do Writely [Goo] e dos correioseletrnicos trocados entre os integrantes foi identicado que a delidade do storyboard impactou no entendimento do mesmo, causando atraso na elaborao do DER pela UD1. Buscando solucionar esse problema, o designer de interface apresentou o storyboard para a UD1, atravs do uso de ferramentas VoIP [SL]. Foram gastos nessa atividade 48 minutos, atravs desta foi possvel mitigar as dvidas do storyboard de forma sncrona aumentando o grau de conana em relao ao entendimento do artefato (REQ-OBSERVACAO-12 16 ). Ao trmino da apresentao foi gerada e disponibilizada uma ata de reunio, contendo as dvidas encontradas e suas respectivas respostas, servindo de documentao complementar ao storyboard. 5.7.4.3 Acompanhamento da Documentao
A atividade de acompanhamento da documentao, serviu tanto para a coordenao das atividades das unidades distribudas, quanto para repassar os conhecimentos adquiridos na UPD. Com o intuito de padronizar os artefatos gerados e facilitar a vida do engenheiro de requisitos das unidades distribudas foram elaborados e disponibilizados os templates de caso de uso [DZVP04] [Sof05] (REQ-OBSERVACAO-08 17 ). Atravs do uso de templates, houve uma melhora na coordenao de como e o que deveria ser documentado pelas UDS. Esse artefato foi desenvolvido no Writely [Goo] o que permitiu compartilh-lo com a UPD. Um dos engenheiros de requisitos da UPD foi adicionado como co-autor do artefato (ver vantagens do Writely na Seo 5.6.2) para que ele pudesse acompanhar sua evoluo (REQOBSERVACAO-04) e participar como um revisor/tutor inserindo comentrios com sugestes e correes ([FRAGMENTO-17]). Esse acompanhamento do artefato deve ser realizado por um participante da fase de elicitao (REQ-OBSERVACAO-13), pois ele ter o conhecimento adquirido nessa fase, podendo repassa-la para os integrantes das UDS. Com o uso das ferramentas de comunicao sncronas (instant messaging [Mic06a] e VoIP [SL]) o engenheiro de requisitos da UPD pde compartilhar seu conhecimento das tcnicas de
16 Apresentar o storyboard produzido para as unidades distribudas atravs de meios de comunicao sncrono que permita trfego de voz. Atravs desse meio de comunicao o designer poder explicar melhor o artefato e mitigar as dvidas encontradas de forma sncrona. 17 Denir templates para a documentao dos casos de uso.
72
detalhamento dos casos de uso [ACB02]. Isso foi fundamental para a difuso do conhecimento nas UDS (REQ-OBSERVACAO-13 18 ). Havendo consenso entre as UDS de como os casos de uso seriam descritos, sendo mitigados a ocorrncia de ambigidades, erros de formatao e de ortograa. Consideramos que atravs dessa atividade foi possvel melhorar a qualidade do artefato, pois antes mesmo da fase de validao, houve reviso do engenheiro de requisitos da UPD que participou ativamente da fase de elicitao dos requisitos [KS98]. [FRAGMENTO-17][LISTA-CORREIO-ELETRONICO][ER1UD1] ERUD1, alterei um pouco o documento, deixei uns comentrios para auxiliar nas suas atividades, tem um caso de uso que rez ele completamente, para deixar como exemplo, questes como utilizar os atores, ao invs de usurio, insero de uxos secundrios. trmino de caso de uso. Nomenclatura de o sistema exibe, etc. 5.7.5 Validao dos Requisitos
O propsito da validao dos requisitos nesse estudo de caso, foi o de garantir a qualidade do detalhamento de todos os requisitos funcionais existentes nos Storyboards e nos requisitos do sistema. Nesse estudo de caso consideramos que todos os requisitos funcionais foram capturados durante a fase de elicitao. Logo no estamos considerando o problema de garantir a cobertura de todos os requisitos durante a fase de validao [KS98]. Nesse estudo conseguimos realizar a fase de validao entre as UDS atravs de meios de comunicao sncronos e assncronos alm das funcionalidades de edio colaborativa fornecida pelo Writely [Goo]. As atividades descritas a seguir foram categorizadas baseadas no processo de inspeo/reviso proposto por Kotonya [KS98] conforme a Figura 2.3. Tendo como premissa de que a validao do documento de requisitos ser realizada em um ambiente distribudo de desenvolvimento, buscamos estudos que dessem suporte a inspeo nesse contexto [MDTR93] [GHB03]. 5.7.5.1 Planejamento da Inspeo
O planejamento de inspeo uma atividade realizada pelo coordenador de inspees. Ele ser responsvel por: denir data/horrio e local da reunio; selecionar e convidar os participantes; conrmar a disponibilidade dos artefatos a serem inspecionados (REQ-OBSERVACAO-17
18 O engenheiro de requisitos da unidade principal de desenvolvimento o qual participou das sees de elicitao,
dever fazer o acompanhamento da documentao desenvolvida pelas unidades distribudas.
73
19 ).
Nesse estudo de caso o papel de coordenador de inspees foi de responsabilidade do ERUPD. Esse integrante foi escolhido por quatro motivos: conhecimento dos padres e tcnicas da especicao dos requisitos, a importncia da presena de um inspetor que tenha participado ativamente da fase elicitao dos requisitos [KS98] (REQ-OBSERVACAO-19 20 ), conhecimento prvio dos requisitos do sistema, estar presente na unidade principal de desenvolvimento centralizando a coordenao das atividades entre as unidades distribudas. Nesse estudo de caso, foi identicado que a denio de data e local da reunio de inspeo era dependente do stakeholder. O coordenador de inspees informava a todos os integrantes atravs da lista de correio eletrnico a necessidade de realizao de uma inspeo. A partir do momento em que o stakeholder respondia o correio eletrnico informando os horrios e dias disponveis ([FRAGMENTO-18]) os demais integrantes comeavam a ajustar seus horrios de acordo com a disponibilidade [FRAGMENTO-19][FRAGMENTO-20]). Pelo fato de que o correio eletrnico um meio assncrono, o coordenador de inspees reforava o convite aos inspetores atravs de meios sncronos (instant messaging, VoIP ou face a face). Quando coordenador de inspees conseguia agrupar ao menos: autor, stakeholder, GPUPD, DIUPD e o prprio coordenador de inspeo, ento ele enviava um correio eletrnico conrmando a realizao da mesma (REQ-OBSERVACAO-18 21 ). Na presena de um integrante de unidade distribuda cava-se subentendido que o meio de comunicao para a realizao dessa reunio seria o VoIP atravs da ferramenta Skype [SL] (REQ-OBSERVACAO-15). Identicamos que essa ativdade de planejamento de inspeo pode ser melhorada, atravs do uso de calendrios colaborativos e/ou disponibilizao dos horrios de colaborao dos integrantes. Contudo essa anlise sai do escopo desse trabalho. [FRAGMENTO-18][LISTA-CORREIO-ELETRONICO][STKUPD] 22 Hoje a tarde estarei nas baias aps a reunio. Amanh pela manh tenho uma reunio do mdias, mas estarei por perto e podemos nos reunir no nal da manh. [FRAGMENTO-19][LISTA-CORREIO-ELETRONICO][DIUPD] 23
19 Usar meios de comunicao sncronos para vericar disponibilidade dos integrantes em participar de reunies
de validao/inspeo. 20 Buscar incluir nas reunies de validao/inspeo os participantes da fase de elicitao. 21 Usar meios de comunicao assncronos informando data e horrio da reunio de validao/inspeo. 22 Correio eletrnico enviado pelo ERUPD, informando sua disponibilidade para a realizao da inspeo. 23 Correio eletrnico enviado pelo STKUPD, informando que poderia reajustar o horrio disponvel.
74
Para mim, tera esta timo! Mas qualquer outro horrio que vier a ser marcado, eu poderei reajustar o meu horrio, sem problemas! [FRAGMENTO-20][LISTA-CORREIO-ELETRONICO][ERUPD] Marquem um horrio, eu ajusto o meu em funo da necessidade. 5.7.5.2 Distribuir Documento
A distribuio do artefato est presente no processo de inspeo proposto por Kotonya Figura 2.3 [KS98]. Consideramos que o uso de um editor de texto colaborativo como o Writely [Goo], poderemos melhorar a distribuio dos artefatos em ambientes distribudos de desenvolvimento. Conforme os motivos vistos na seo Seo 5.7.4.1 o Writely [Goo] foi selecionado como editor de texto no decorrer desse estudo de caso. Halling [GHB03] defende que os artefatos a serem inspecionados devem estar em formato eletrnico compartilhado atravs de ferramentas colaborativas. Nesse formato nos beneciaremos: maior ecincia em comunicar e disponibilizar as verses mais atuais dos artefatos e inibir a duplicao dos mesmos. Atravs de um editor de texto colaborativo a inspeo de requisitos fornecendo diversos meios para que as pessoas trabalhem individualmente ou em grupos, presencialmente ou geogracamente dispersas, de maneira sncrona ou assncrona. Atravs da disponibilizao dos artefatos on-line, possvel melhorar o trabalho colaborativo ou presencial. Os participantes podem colaborar de forma distribuda, alm de avaliar a contribuio dos demais participantes [RDJFN04]. Na distribuio dos artefatos foram utilizadas 2 funcionalidades do Writely [Goo]: 1. adicionar colaboradores (colaborators) e visualizadores (viewers) ver Figura 5.7. 2. publicar artefato ver Figura 5.8 [FRAGMENTO-21]. Os colaboradores visualizam a ltima verso do artefato e possuem o poder de alterar o documento. Os visualizadores tm acesso a ltima verso publicada do artefato. Em um primeiro momento tnhamos de distribuir os artefatos e permitir que os mesmos pudessem ser alterado pelos inspetores. Cada inspetor foi adicionado como colaborador (veja Figura 5.7), para que eles pudessem adicionar comentrios durante a preparao. Os demais integrantes tinham acesso somente a ltima verso publicada do documento, isso permitiu denir que a verso publicada deveria ser a ltima verso validada, evitando que os demais integrantes tivessem acesso a um artefato que estivesse ainda em fase de elaborao. Como vemos no correio eletrnico a seguir, o colaborador publica o artefato, informando a url com o endereo do mesmo [FRAGMENTO-21].
75
Figura 5.7 Permisses do Artefato: colaboradores e visualizadores [Goo]
[FRAGMENTO-21][WRITELY][ERUPD] 24 ERUPD (via Writely) <user-ah8kd6m3m9nc-Agm9s3gs@reply.writely.com> para mim 21 Mar verso atualizada... ***
ERUPD (xxxxxx.xxxxxx@gmail.com) would like to show you a web page: http://www.writely.com/Doc.as *** Replies to this message will be forwarded to ERUPD@gmail.com. 5.7.5.3 Preparar para Inspeo - Inspeo Assncrona
Durante a preparao, cada inspetor examina o artefato e adiciona comentrios a respeito dos defeitos encontrados. Essa atividade pode ser realizada de forma assncrona [MDTR93] [RDJFN04] [vGvDSV01]. No estudo de caso, essa forma de colaborao permitiu que os integrantes tivessem a liberdade de selecionar o horrio mais adequado para realizar a preparao
24 Correio
eletrnico enviado pelo ERUPD atravs do Writely, informando sobre a atualizao do artefato.
76
Figura 5.8 Publicar Documento [Goo]
isso foi importante por conta da divergncia de horrio. Se o inspetor no gastar tempo suciente com a preparao, ele achar poucos defeitos e tambm falhar ao tentar entender o contedo do artefato inspecionado [RDJFN04]. Um aspecto bastante importante da preparao da inspeo atravs de uma ferramenta colaborativa, a possibilidade do autor alterar o artefato. Nesse contexto, o inspetor poder inserir comentrios exatamente na localizao do defeito (ver Figura 5.9) (REQ-OBSERVACAO14 25 ), facilitando a coleta dos defeitos encontrados durante a reunio de inspeo (REQOBSERVACAO-15 26 ). Como estas contribuies so pblicas, h um reconhecimento da colaborao pelos demais inspetores [GHB03]. Em uma aplicao industrial, Perpich [PPP+ 97] encontrou que as inspees distribudas, com a preparao sendo conduzida atravs de uma ferramenta colaborativa (assncrona), foi mais efetiva do que a preparao tradicional (quando os inspetores no podem visualizar os defeitos encontrados pelos demais). Na preparao tradicional um inspetor gasta tempo encontrando defeitos que j foram encontrados por outros. Com o suporte colaborativo esse esforo pode ser reaproveitado na busca por defeitos que ainda no foram descobertos [RDJFN04]. Para a atividade de preparao individual, alguns inspetores ainda preferem ler verses impressas. Harjumaa e Tervonen [HT98] informam atravs de evidncias empricas que a leitura
25 A preparao para a inspeo, onde os revisores identicavam os erros, deve ser realizada em um ambiente colaborativo assncrono, onde os autores possam tecer seus comentrios [GHB03]. Um inspetor individual gasta tempo encontrando defeitos que j foram encontrados por outro inspetor, atravs do suporte colaborativo esse esforo pode ser gasto para encontrar defeitos que ainda no foram descobertos [RDJFN04]. 26 Deve ser realizada uma reunio de inspeo com o intuito de coletar os defeitos encontrados pelos revisores [SJLY00] [GHB03]. Devido a distribuio geogrca essa reunio dever ser realizada atravs de meios de comunicao sncrono que permitam trfego de voz [MDTR93].
77
de documentos eletrnicos menos efetiva do que o material impresso. Contudo, posteriormente os inspetores tero o trabalho de adicionar seus comentrios no artefato, alm de perderem as contribuies dos demais inspetores. Inspees baseadas em papel se tornam inecientes quando os inspetores encontram defeitos que j foram encontrados por outros inspetores. Nessa tcnica os defeitos encontrados durante a preparao s sero notados durante a reunio de reviso [RDJFN04]. Quando as contribuies dos inspetores tornam-se visveis ocorre um efeito emocional motivando os inspetores a serem mais consistentes em sua preparao. Genuchten [vGvDSV01] argumenta que quando as contribuies cam ocultas os inspetores os quais no se prepararam corretamente poderiam dizer, "Eu achei esse defeito tambm". Atravs de nossa anlise da atividade de preparao da inspeo sendo mediada por uma ferramenta colaborativa [Goo] pudemos concluir que: 1. Atravs do uso de documentos eletrnicos compartilhados, reduzimos o esforo gasto com comunicao 2. Comunicamos de forma eletrnica atravs de meios assncronos os defeitos encontrados reduzindo o uso de comunicao sncrona (meio menos formal de comunicao). 3. Disponibilizar o trabalho colaborativo ou presencial para atividades distribudas como a preparao. Os participantes puderam contribuir dentro de suas prprias casas e avaliar a contribuio dos demais trabalhando que trabalhavam de forma sncrona ou assncrona (ver Figura 5.9). Dessa forma conclumos que a atividade "Preparar para Reviso"do processo de inspeo (Figura 2.3) proposto por Kotonya [KS98] quando aplicada em ambientes de DDS, deve ser realizada de maneira assncrona, havendo compartilhamento do artefato por intermdio das ferramentas colaborativas.
Figura 5.9 Inserir comentrio no artefato [Goo]
78 5.7.5.4
Reunio de Inspeo - Audio-Conferncia
Seguindo o processo de inspeo proposto por Kotonya [KS98], aps a atividade de preparao realizada a reunio de inspeo. No processo de Kotonya [KS98] os participantes se renem presencialmente. Em nosso caso como alguns dos participantes estavam distribudos geogracamente, conseguimos realizar atravs do Skype [SL] uma udio conferncia com a presena de at 4 usurio (limitao da ferramenta). Por intermdio desse meio de comunicao sncrono, pudemos coletar e ltrar os defeitos encontrados. Esclarecendo os diferentes pontos de vista dos inspetores ([FRAGMENTO-22][FRAGMENTO-23]). [FRAGMENTO-22][REUNIAO-VALIDACAO-TRANSCRICAO]27 GPUPD - Eu botei o quantitativo de alunos. DIUPD - Ai tem que deixar claro que isso quando o cara esta na pagina do curso. GPUPD - . DIUPD - E ai no est claro. DIUPD - Como que a gente coloca isso ai ? GPUPD - No est claro para vocs no, eu achei claro. STKUPD - Acho que no est claro no, que isso ai depois que o cara clicou no curso. STKUPD - Deixa nas pr-condies. [FRAGMENTO-23][REUNIAO-VALIDACAO-TRANSCRICAO]28 STKUPD - Deixa o caso de uso como est. Simplesmente organize, acrescente essas sees. No tira nada. GPUPD - Certo, acrescentar uma pr-condio ? STKUPD - No, no. Rever todas as pr-condies mas colocar ele numa ordem lgica, numa ordem que corresponda ao cenrio em que ele est. No logado, logado e logado dentro do curso. Vimos na Seo 5.7.5.2 a importncia de distribuir os artefatos a serem inspecionados. Encontramos tambm durante a reunio de inspeo, indcios da necessidade de identicar a
27 Fragmento da transcrio da reunio de inspeo contendo indcios de coleta e ltragem dos requisitos encontrados. 28 Fragmento da transcrio da reunio de inspeo contendo indcios esclarecimento dos pontos de vista.
79
verso a ser inspecionada ([FRAGMENTO-24][FRAGMENTO-25]). A seo histrico de revises contm dois conjuntos de nmeros que so incrementados a cada atualizao, facilitando assim a identicao da ltima verso do artefato. [FRAGMENTO-24][REUNIAO-VALIDACAO-TRANSCRICAO]29 "DIUPD - GPUPD, o que temos aqui em aberto a verso 00.03 por ER1UD1." GPUPD - Estou vendo a verso 00.03." [FRAGMENTO-25][REUNIAO-VALIDACAO-TRANSCRICAO] "GPUPD - .. Na capa aqui, verso 00.03. DIUPD - No j to aqui no caso de uso 001. STKUPD - No rapaz, na capa a verso do documento. GPUPD - Ts no documento do writely para car com a mesma verso ? DIUPD - T. GPUPD - Vamos l, a ltima alterao foi em 17/02/06 para a 00.05 ? GPUPD - D uma olhada no revision history. DIUPD - essa mesmo." Durante o agrupamento dos defeitos o autor e o coordenador de revises agrupam a lista de defeitos para realizarem o retrabalho. Normalmente essa atividade conduzida por uma reunio de inspeo, essas reunies provem discusses abertas as quais no poderiam ser solucionadas individualmente. Land e Sauser [SJLY00] enfatizam a importncia das reunies de inspeo para a coleta dos defeitos e esclarecimento das descries dos mesmos. Eles reportam que as reunies possuem clara vantagem sobre os meios de deteco de defeitos individuais em relao a classicao de erros verdadeiros e os falso positivos. Falsos positivos so defeitos reportados, que no so erros de fato [GHB03]. Halling [GHB03] baseado em sua experincia em reunies de inspeo, argumenta que elas so pouco efetivas para a deteco de novos defeitos, contudo eles concordam que so ecazes na identicao de falsos positivos marcados durante a preparao individual. Dean notou que um dos aspectos inecientes de uma reunio de inspeo formal se deve ao fato de que quando um dos inspetores est argumentando a respeito do defeito, os demais esto geralmente distrados [RDJFN04]. Em nosso estudo de caso identicamos que devido a baixa qualidade do som, durante a realizao da audio-conferncia os inspetores no caram
29 Fragmento
da transcrio da reunio de inspeo contendo indcios de comparao do histrico de revises.
80
distrados, pelo contrrio estavam atentos ao que era dito pelos demais interlocutores. Mas devido a diculdade do meio de comunicao os inspetores se esforavam mais para entender e serem entendidos ([FRAGMENTO-38]). [FRAGMENTO-38][REUNIAO-VALIDACAO-TRANSCRICAO] 30 DIUPD - ERUD1, tu mexeu em alguma coisa daquilo que conversamos pela manh. GPUPD - Aqui tem alguns problemas. DIUPD - perai, GPUPD. GPUPD - <RUDO, SOM NO TRANSCRITO>. DIUPD - Perai GPUPD. GPUPD - Certo fale. DIUPD - fala ai ERUD1, aquilo que conversamos pela manh. Passa para o pessoal, pois se for necessrio eu complemento. ERUD1 - o que conversamos pela manh, foi a respeito da criao do curso, ser necessrio abrir a tela de edio sendo necessrio um terceiro passo ? DIUPD - Tem que alterar esse caso de uso, para car coerente com isso. GPUPD - Ahh t. GPUPD - Por que aqui quando inserimos o primeiro modulo, ele altera tambm os mdulos do curso. DIUPD - Repete GPUPD, que no entendi ERUD1 - Rever as pre-condies n? GPUPD - Por que nesse caso de uso o curso no esta criado ainda. E a prcondio estamos no mdulo de criao do curso, certo. E a ps-condio que o curso foi criado com sucesso. DIUPD - Realmente est errado. Identicamos que a ao de agentes externos como: queda de conexo, telefonemas e conversas paralelas ([FRAGMENTO-26][FRAGMENTO-39][FRAGMENTO-27]). Impactam negativamente na realizao da inspeo tirando a ateno dos demais inspetores. O uso de diferentes ferramentas alm da necessidade de uma conexo com a internet aumenta a quantidade de agentes externos que por vezes inviabilizam a realizao das inspees. [FRAGMENTO-26][REUNIAO-VALIDACAO-TRANSCRICAO] 31
30 Fragmento 31 Fragmento
da transcrio da reunio de inspeo contendo indcios de problemas de comunicao. da transcrio da reunio de inspeo contendo impactos de agentes externos
81
STKUPD - Pera, que deu pau aqui no computador de DIUPD. DIUPD - No, relaxe, besteira. STKUPD - O computador de DIUPD est dizendo que est em warning. [FRAGMENTO-39][REUNIAO-VALIDACAO-TRANSCRICAO] STKUPD - Oa como est o documento de gesto de contedo. GPUPD - Olha tentei conversar com o pessoal de Petrolina mas no os encontrei. STKUPD - , eles esto com um problema srio de conexo. [FRAGMENTO-27][REUNIAO-VALIDACAO-TRANSCRICAO] GPUPD - DIUPD. ERUPD - Espera um momento que ele est no telefone com a GQUPD. ERUD1 - Ai tem que ver com o DIUPD. DIUPD, bota especico para cada campo ? DIUPD - Oi pessoal foi mal, o GQUPD avisou por telefone que a conexo caiu. Perguntem novamente que eu no estava escutando. Em algumas oportunidades a qualidade de som chega a ser to sofrvel que impacta na realizao da reunio [FRAGMENTO-28]). Isso se deve ao fato de algum problema de conexo. Nesse momento necessrio uma remarcao de inspeo, desfazendo todo o planejamento anterior. [FRAGMENTO-28][REUNIAO-VALIDACAO-TRANSCRICAO] GQUPD - Est muito ruim de ouvir ERUD1. ERUD1 - O mesmo pra mim aqui. Vocs esto gaguejando muito. GPUPD - sei. GQUPD - Para mim todos haviam cado no estava escutando ningum. [FRAGMENTO-29][REUNIAO-VALIDACAO-TRANSCRICAO]32 GPUPD - Agora pela manh est invivel, que horrio vocs possuem ainda hoje ? ERUD1 - tivemos essa bronca com a reunio hoje. Pela tarde o ERUD1 ter prova. Pode ser amanh ? GPUPD - Tranqilo, enviem um correio eletrnico remarcando a reunio.
32 Fragmento
de uma conversa em instant messaging indicando a necessidade de remarcar a reunio
82
Quando existe um conjunto expressivo de integrantes numa mesma unidade distribuda, e eles discordam em alguns aspectos, eles sentem a necessidade de entrar em consenso em algumas decises sem a interferncia dos integrantes distribudos [FRAGMENTO-30]). Ocorre nesse ponto uma conversa paralela, at o consenso ser atingido. Ento a deciso repassada para os demais integrantes para que esses possam opinar em cima da deciso local. [FRAGMENTO-30][REUNIAO-VALIDACAO-TRANSCRICAO]33 GPUPD - Aqui tambm tem s um uxo 2 de quantidade de ... pendentes no curso. GPUPD - Tudo ok ai ? DIUPD - Repete, GPUPD? GPUPD - Pessoal, la em baixo, quantidade de duvidas pendentes no curso. Est tranquilo n ? DIUPD - Bom. A GQUPD fala de forma baixa, que no d para os inspetores que esto se comunicando atravs de VOiP entender o que esta sendo discutido. a discusso prossegue durante 1 minuto e 15 segundos com a participao do STKUPD, ERUPD e o DIUPD que estavam na mesma localizao geogrca. GPUPD - Pessoal falem mais alto que no d para entender no. DIUPD - Espera um momento. A discusso, prossegue at o consenso ser atingido e informar para os demais inspetores e que foi decidido. STKUPD - Quando ele entrar no curso que ele vai ver o quantitativo de duvida por aluno, associado ao nome do curso. GPUPD - Ahh entendi. ERUD1 - Ok. Encontramos nas transcries das reunies de inspeo do estudo de caso, fortes indcios de utilizao de uso das sees do artefato para realizar sua navegao [GHB03] ([FRAGMENTO31][FRAGMENTO-33][FRAGMENTO-34]). Isso reforou ainda mais o uso de um identicador nico para os casos de uso [Sof05]. A navegao por sees do artefato, foi o meio mais adequado para que os inspetores separados geogracamente pudessem se localizar no artefato. [FRAGMENTO-31][REUNIAO-VALIDACAO-TRANSCRICAO]34
33 Fragmento 34 Fragmento
da transcrio da reunio de inspeo contendo a busca por consenso em uma unidade distribuda. da transcrio da reunio de inspeo contendo indcios de navegaes pelas sees do artefato.
83
GPUPD - UC10. Adicionar atividade. GPUPD - Nesse passo 4: o professor salva, as descries dos casos de uso anteriores isso poderia ser melhor descrito. [FRAGMENTO-33][REUNIAO-VALIDACAO-TRANSCRICAO]35 GPUPD - UC11, exibir lista de participantes no curso. DIUPD - Opa, volte, que GQUPD tem observao no UC10. GQUPD - No 9 e no 10, voc poderia ver inclusive mensagens. [FRAGMENTO-34][REUNIAO-VALIDACAO-TRANSCRICAO] VOUPD - Essa colocao que estamos fazendo ai dentro do uxo principal, todas as pr-condies. Eu me preocupo se os engenheiros de software, no vo sentir algum tipo de diculdade. Porque as vezes parte do uxo principal, esta englobado nas pr-condies. E esto at citando uxo secundrio dentro deles. Que no estariam dentro do caso de uso principal. Deu para me entender ? GPUPD - Hum, entendi no. Me cita um exemplo. STKUPD - Ele esta querendo um exemplo. VOUPD - , no caso de uso anterior, o 10. Tinham por exemplo: pera visse estou me localizando no artefato, para achar uma coisa mais consistente. DIUPD - Pronto 10. VOUPD - No foi nesse no, foi o 8. Que ns inclumos inclusive uma prcondio adicional. Consideramos que esse evento foi bastante rico para esse trabalho. E que tanto o uso do editor de texto colaborativo (Writely [Goo]) quanto a ferramenta de VoIP utilizada Skype ([SL]), foram essenciais para a coleta desses resultados. 5.7.5.5 Correes da Reviso
De acordo com o processo de inspeo proposto por Kotonya [KS98], a correo da reviso realizada a partir dos defeitos identicados e registrados durante a reunio de inspeo. Tom Gilb [GG93] defende que os erros devem estar registrados num artefato a parte agrupando todos os defeitos encontrados.
35 Fragmento
da transcrio da reunio de inspeo contendo indcios de navegaes pelas sees do artefato.
84
Nesse estudo de caso sentimos a necessidade de registrar os erros coletados durante a reunio, contudo ao contrrio de um novo artefato, registramos os erros no prprio documento atravs da funcionalidade de insero de comentrios do Writely [Goo] ver Figura 5.9. Ao conclurem a fase de documentao, os autores disponibilizaram o artefato para os inspetores. Atravs da permisso de escrita, esses puderam inserir seus comentrios. Durante a reunio de inspeo os comentrios dos falsos positivos identicados (ver Seo 5.7.5.4)eram simplesmente removidos. Ento o autor se preocupou apenas com os comentrios existentes aps a reunio de inspeo. Como podemos ver no [FRAGMENTO-35] a necessidade de registrar os erros encontrados. [FRAGMENTO-35][REUNIAO-VALIDACAO-TRANSCRICAO] GPUPD - No mas se for para ser um wiki tem que adicionar um uxo secundrio aqui. DIUPD - Pronto ento adicionar um uxo secundrio. GPUPD - Alm disso deveria ser criado um novo caso de uso. STKUPD - Deixa isso registrado ai. DIUPD - T. Prximo. GPUPD - Ento est anotando ai tudinho n ? DIUPD - Estou. A partir dos comentrios existentes no artefato, o autor pde efetuar as correes de acordo com o que foi decidido durante a reunio. Consideramos que o editor de texto colaborativo [Goo] foi essencial para a realizao desta atividade nesse contexto. 5.7.5.6 Revisar o documento
Aps as correes das revises serem realizadas, o coordenador de revises dever revisar o documento com o intuito de vericar se todos os defeitos encontrados foram corrigidos. Caso ainda exista algum defeito a ser corrigido o coordenador de revises poder solicitar que o autor retrabalhe no artefato. Com o uso do Writely [Goo], o coordenador de revises, pde recuperar a verso do artefato que continha todos os comentrios inseridos durante a reunio de inspeo e compar-la coma ltima verso existente ver Figura 5.10 (REQ-OBSERVACAO-04 36 , REQ-OBSERVACAO36 O
repositrio deve dar subsdios para a recuperao de verses anteriores do documento.
5.8 REQUISITOS RELACIONADOS AO ESTUDO DE CASO
85
09 37 ). Logo os erros existentes nos comentrios puderam ser revistos e avaliados durante a reviso do documento.
Figura 5.10 Comparar diferentes verses do artefato [Goo]
Foi identicado que os pedidos de reviso no artefato so feitos atravs de meios assncronos ([FRAGMENTO-36]), devido as diferenas de horrio de colaborao dos integrantes. [FRAGMENTO-36][REUNIAO-VALIDACAO-TRANSCRICAO] 38 Oi DIUPD, Necessito de tua reviso no documento que est no Writely. Mandei o convite para voc. Atenciosamente, GQUPD. Conclumos que essa atividade de reviso pode ser realizada na maioria dos casos de forma assncrona. Havendo a necessidade de somente recorrer a meios sncronos caso o coordenador de revises entre em desacordo com o que foi documentado,precisando assim de um esclarecimento por parte dos autores.
5.8
Requisitos Relacionados Ao Estudo de Caso
Na anlise qualitativa da observao no estudo de caso foram obtidos os seguintes requisitos relativos ao ambiente de desenvolvimento estudado. REQ-OBSERVACAO-01 : Diminuir as barreiras impostas pelas distncias geogrca e temporal das equipes de desenvolvimento distribudas. REQ-OBSERVACAO-02 : Atender a equipes pequenas de desenvolvimento de software com 8 a 15 integrantes por equipe e apenas 1 stakeholder responsvel por validar e elicitar os requisitos.
37 Impor critrios de versionamento e histrico de revises para os artefatos, de modo possibilitar a visualizao da evoluo dos mesmos ao longo do tempo. 38 O autor faz o pedido de reviso no artefato, autorizando a reviso do documento.
86
REQ-OBSERVACAO-03 : Dividir os integrantes em papis de acordo com seus pers e responsabilidades. REQ-OBSERVACAO-04 : O repositrio deve dar subsdios para a recuperao de verses anteriores do documento. REQ-OBSERVACAO-05 : Processo unicado devendo ser seguido por todos os integrantes do projeto. REQ-OBSERVACAO-06 : Criar e disponibilizar as atas das reunies realizadas. Essas atas devero ser disponibilizadas atravs da lista de e-mails para que que todos tomem conhecimento do que foi decidido. REQ-OBSERVACAO-07 : Utilizar ferramentas colaborativas que auxiliem a ER. Estudos indicam que essas ferramentas diminuem a distncia entre os integrantes sendo indicadas para ambientes de DDS [Bri06] [AG98] [Car98]. REQ-OBSERVACAO-08 : Denir templates para a documentao dos casos de uso. REQ-OBSERVACAO-09 : Impor critrios de versionamento e histrico de revises para os artefatos, de modo possibilitar a visualizao da evoluo dos mesmos ao longo do tempo. REQ-OBSERVACAO-10 : Validar presencialmente os artefatos produzidos durante a fase de elicitao, de modo a mitigar a ocorrncia de erros nessa fase. Somente disponibilizar esses artefatos para as unidades distribudas quando estes estiverem validados. REQ-OBSERVACAO-11 : Anexar os storyboards nos casos de uso para facilitar o entendimento dos requisitos e diminuir a ocorrncia de conito de verses. Atravs dos storyboards anexo, ser mais fcil realizar a validao dos requisitos, comparando as imagens com o que est documentado. REQ-OBSERVACAO-12 : Apresentar o storyboard produzido para as unidades distribudas atravs de meios de comunicao sncrono que permita trfego de voz. Atravs desse meio de comunicao o designer poder explicar melhor o artefato e mitigar as dvidas encontradas de forma sncrona. REQ-OBSERVACAO-13 : O engenheiro de requisitos da unidade principal de desenvolvimento o qual participou das sees de elicitao, dever fazer o acompanhamento da documentao desenvolvida pelas unidades distribudas. REQ-OBSERVACAO-14 : A preparao para a inspeo, onde os revisores identicavam os erros, deve ser realizada em um ambiente colaborativo assncrono, onde os autores possam tecer seus comentrios [GHB03]. Um inspetor individual gasta tempo encontrando defeitos que j foram encontrados por outro inspetor, atravs do suporte colaborativo esse esforo pode ser gasto para encontrar defeitos que ainda no foram descobertos [RDJFN04]. REQ-OBSERVACAO-15 : Deve ser realizada uma reunio de inspeo com o intuito
5.8 REQUISITOS RELACIONADOS AO ESTUDO DE CASO
87
de coletar os defeitos encontrados pelos revisores [SJLY00] [GHB03]. Devido a distribuio geogrca essa reunio dever ser realizada atravs de meios de comunicao sncrono que permitam trfego de voz [MDTR93]. REQ-OBSERVACAO-16 : Checar se foram realizadas as devidas correes de acordo com a reunio de inspeo. Devido as divergncias de horrio dos integrantes interessante que essa atividade seja realizada por intermdio dos meios assncronos (e-mail e ferramenta de edio colaborativa). REQ-OBSERVACAO-17 : Usar meios de comunicao sncronos para vericar disponibilidade dos integrantes em participar de reunies de validao/inspeo. REQ-OBSERVACAO-18 : Usar meios de comunicao assncronos informando data e horrio da reunio de validao/inspeo. REQ-OBSERVACAO-19 : Buscar incluir nas reunies de validao/inspeo os participantes da fase de elicitao.
C APTULO 6
Processo Proposto
Diante da importncia que os Requisitos tm em todo o ciclo de vida de desenvolvimento de um software, este captulo apresenta um processo de Engenharia de Requisitos, baseado no RUP [Sof05], que contempla as necessidades do desenvolvimento distribudo. Vale salientar que embora o RUP [Sof05] seja um processo de larga utilizao na indstria e adaptvel a diferentes tipos de aplicaes, este captulo apresenta um processo para documentao e validao dos requisitos, mais efetivo que aquele abordado na Disciplina de Requisitos do RUP [Sof05]. Pois contempla solues para os desaos encontrados na Engenharia de Requisitos em ambientes distribudos de desenvolvimento apresentados na Seo 2.1.1. Para a elaborao desse processo foram utilizados estudos empricos atravs de tcnicas de pesquisa qualitativa com o uso de entrevista semi-estruturada [Fli04] e observao participativa em um estudo de caso [Yin05]. O resultado dessas avaliaes esto descritos na Seo 4.1. Como resultado dessa anlise foram extrados requisitos (Seo 4.3 e Seo 5.8) que deniram algumas caractersticas e problemas de ambientes distribudos de desenvolvimento, os quais requerem maior ateno em relao ao desenvolvimento presencial, como: uso de ferramentas colaborativas, meios de comunicao e coordenao das equipes distribudas. O processo proposto, chamado DSD-REQ-Process (Distributed Software Development Requirements Process), aborda o desenvolvimento iterativo, sendo guiado pela produo de artefatos e de ferramentas colaborativas. Com o desenvolvimento da proposta, procuramos criar um processo que fosse genrico o suciente para atender diversos domnios e tipos de aplicaes, mas que contemplasse necessidades do desenvolvimento distribudo como: diminuir a distncia entre as equipes, coordenao de atividades, reviso assncrona de artefatos, detalhamento dos requisitos baseado em storyboards, entre outros. Desta forma, podemos dizer que a principal contribuio deste processo fornecer um conjunto coerente de atividades e artefatos direcionados para a Engenharia de Requisitos em ambientes distribudos de desenvolvimento, mas que mantm a generacidade do RUP [Sof05], podendo ser aplicado em diferentes tipos de sistemas de software. Como procuramos propor um processo completo para ser customizado a toda e qualquer aplicao, importante que a equipe de desenvolvimento faa uma anlise inicial do processo 89
90
CAPTULO 6 PROCESSO PROPOSTO
como um todo e de acordo com suas necessidades avalie que atividades e artefatos que devem ser instanciados para o projeto. Esse proceso foi modelado a partir da ferramenta Eclipse Process Framework (EPF) [TEF07], essa ferramenta utilizada para autoria de processos. A partir dela possvel criar, customizar e publicar os processos de desenvolvimento. O EPF se utiliza de uma notao de descrio de processos pr-denida. Essa notao uma evoluo da verso 1.1 do Software Process Engineering Metamodel (SPEM) [OMG05] a qual atualmente est sendo evoluda para a verso 2.0.
6.1
Descrio do Processo
A proposta desse processo integrar unidades distribudas de desenvolvimento atravs de ferramentas colaborativas. Espera-se que as unidades de desenvolvimento possam interagir entre si atravs da execuo de um processo de ER distribuda. O principal objetivo desse processo minimizar o impacto da distncia dos integrantes, nas atividades de documentao e validao dos requisitos. O processo esta subdividido em duas fases: uma fase presencial onde so realizadas as atividades de elicitao e captura dos requisitos, juntamente com o cliente. E outra fase realizada no contexto de desenvolvimento distribudo, onde esto inclusas as atividades de documentao (detalhamento) e validao dos requisitos como podemos ver na Figura 6.1. O DSD-REQ-Process tem o intuito de integrar diferentes unidades distribudas de desenvolvimento. Para sua execuo, essencial que haja uma UPD que possa tomar as decises do projeto, convergindo requisitos e delegando as atividades para as demais unidades distribudas. Esse modelo de distribuio minimiza o esforo gasto com a coordenao das equipes distribudas [MBH+ 06].
6.2
Iterao: Elicitao de Requisitos
A captura de requisitos uma fase crtica no desenvolvimento de software visto que ela no lida apenas com os conhecimentos tcnicos, mas tambm com as questes organizacionais, gerenciais, econmicas e sociais. Sendo assim, j um consenso que a especicao de requisitos devem incluir, no apenas especicaes de software, mas tambm modelos de negcios e outros tipos de informaes que descrevam o contexto sobre o qual a aplicao ir operar [CAF00]. A elicitao dos requisitos consiste em identicar onde e como os requisitos do sistema se-
6.2 ITERAO: ELICITAO DE REQUISITOS
91
Figura 6.1 Estrutura Analtica do Processo de Desenvolvimento
ro coletados. Trata-se de uma atividade fundamentalmente humana [NE00], onde os stakeholders (fontes de informao) so identicados e relacionados com a equipe de desenvolvimento. O engenheiro de requisitos deve ser o mediador dessa relao, por ser um papel com mais habilidade em capturar os desejos do cliente e possuir o perl tcnico adequado para dialogar com a equipe de desenvolvimento [ABD+ 04]. Como podemos ver na Figura 6.1 a Elicitao dos Requisitos est presente na fase presencial do DSD-REQ-Process, pois consideramos que a iterao de Elicitao dos Requisitos deve ser conduzida atravs dos melhores meios de comunicao. Portanto o DSD-REQ-PROCESS impe que a elicitao de requisitos seja abordada de maneira presencial do processo de engenharia de requisitos devido a facilidade de possibilitar a comunicao face a face e ser esse o meio de comunicao mais rico em contexto (REQ-ENTREVISTAS-03) de acordo com Marquardt [MH01]. A seguir descrevemos as atividades relacionadas Iterao de Elicitao dos requisitos, bem como a descrio de seus uxos.
6.2.1
Obteno dos Requisitos Iniciais do Sistema
Essa atividade descreve como capturar os requisitos do sistema, denindo qual ser o problema a ser solucionado [NE00]. Identicar os principais stakeholders, o escopo e as fronteiras do sistema.
92
Figura 6.2 Iterao: Elicitao dos Requisitos
Ao capturar os requisitos do sistema deve-se manter em mente: 1. Os potenciais usurios do sistema e como mape-los em atores. 2. Normalmente os atores denem as fronteiras do sistema. 3. Identicar o escopo negativo do sistema. Papis Envolvidos: 1. Engenheiro de requisitos 2. Stakeholder 3. Designer de interface Artefatos de Entrada: 1. Base formal de conhecimento do problema (Seo 6.6.1) Artefatos de Sada: 1. Descrio dos atores do sistema (Seo 6.6.6.1). 6.2.2 Elicitao em Grupo
A elicitao de requisitos no uma atividade passiva, mesmo que o stakeholder esteja disponvel e disposto a cooperar (REQ-ENTREVISTAS-03), o engenheiro de requisitos ter trabalho em coletar as informaes corretas [Sof05]. A omisso de informao por parte dos stakeholders muito comum, impactando assim na descrio dos requisitos [KS98]. O DSD-
93
REQ-Process considera que com o uso de tcnicas de elicitao em grupo diminui a ocorrncia de informaes omitidas, devido a presena de diferentes pers (REQ-ENTREVISTAS-01, (REQ-ENTREVISTAS-03)) e, conseqentemente, vises dos requisitos que sero elicitados. Dentro do desenvolvimento distribudo de software, Lloyd [Llo01] testou tcnicas de elicitao de requisitos com um conjunto de ferramentas em ambientes distribudo de desenvolvimento. Ele concluiu que as tcnicas de elicitao assncrona como questionrios tendem a ser menos efetivas do que as sncronas como entrevistas, brainstorming ou elicitao dos requisitos intermediadas por prottipos Seo 2.5 (REQ-ENTREVISTAS-04, REQ-ENTREVISTAS05). No estudo de caso que originou este processo, identicamos uma grande instabilidade nos requisitos de interface, quando este era especicado por um engenheiro de requisitos e depois revisto pelo designer de interface Seo 6.6.2. Consideramos ento que para a realizao desta atividade necessria a presena do designer de interface, que juntamente ao engenheiro de requisitos, coletar as necessidades do cliente e usurios para elaborar a soluo, modelo navegacional e os requisitos de usabilidade (REQ-ENTREVISTAS-01, REQ-ENTREVISTAS-05). Segundo Neves,em [NV99], comeando com observaes empricas realizadas por prossionais das reas de design e cincia da computao, o processo de anlise dos requisitos deve identicar os objetivos e contedo do projeto, para que sejam identicadas as melhores alternativas e selecionada aquela que melhor satisfaa as expectativas dos usurios e clientes. O uso de prottipos para a fase de elicitao, se faz necessrio quando no existe um consenso sobre os requisitos por parte dos stakeholders (REQ-ENTREVISTAS-04) precisando de um feedback a respeito dos requisitos elicitados. A prototipagem tambm pode ser combinada com outras tcnicas, uma instncia de um prottipo pode ser usada para provocar discusses em grupos de elicitao [NE00] (REQ-ENTREVISTAS-03). Como mtodos de elicitao o DSD-REQ-PROCESS sugere a realizao de Brainstorming juntamente com a prototipao em papel [Sny03], de modo que o produto de cada seo seja um prottipo em papel juntamente com o conjunto de requisies propostas pelos stakeholders (REQ-ENTREVISTAS-08), para que esses artefatos sejam renados pelo designer de interface e engenheiro de requisitos para as prximas sees de elicitao. A partir dessas concluses, o DSD-REQ-PROCESS sugere que as tcnicas de elicitao sejam realizadas em grupo com a participao obrigatria dos seguintes papeis: stakeholder, engenheiro de requisitos e designer de interface (REQ-ENTREVISTAS-08). A participao do gerente de projetos se faz opcional, contudo se for identicado uma redenio de escopo este precisa ser noticado e convidado a participar da prxima sesso. O artefato de sada desta atividade um storyboard e o documento de requisitos que servi-
94
ro como artefato de entrada para a iterao de desenvolvimento distribudo. Papis Envolvidos: 1. Engenheiro de requisitos 2. Stakeholder 3. Designer de interface Artefatos de Entrada: 1. Descrio dos atores do sistema (Seo 6.6.6.1) Artefatos de Sada: 1. Requisitos iniciais (Seo 6.6.4) 2. Descrio dos atores do sistema (Seo 6.6.6.1) 3. Prottipo em papel (Seo 6.6.2) 6.2.3 Documentao dos Requisitos Iniciais do Sistema
Os requisitos denem quais sero os servios que o sistema dever prover alm de um conjunto de restries existentes na operao do sistema [KS98]. Os requisitos iniciais podem ser denidos como as aes fundamentais do sistema [Byr94]. O DSD-REQ-Process considera que os requisitos iniciais devem ser descritos nas fases iniciais da elicitao e devem possuir um alto nvel de abstrao, servindo para orientar as fases seguintes do processo de Engenharia de Requisitos. Eles podem ser descritos conforme a Low Ceremony Use Case (ver Seo 6.3.2) [ACB02]. Levando em considerao que o detalhamento dos requisito ser realizado na iterao de documentao Seo 6.3. Papel Responsvel: 1. Engenheiro de requisitos Artefatos de Entrada: 1. Descrio dos atores do sistema (Seo 6.6.6.1) 2. Prottipo em papel (Seo 6.6.2) Artefatos de Sada: 1. Requisitos iniciais (Seo 6.6.4) 2. Descrio dos atores do sistema (Seo 6.6.6.1) 6.2.4 Desenvolvimento do Storyboard
Ao desenvolver o storyboard, o designer de interface, deve utilizar como artefato de entrada os prottipos em papel elaborados durante a atividade de elicitao em grupo alm dos requisitos
95
iniciais desenvolvido em paralelo pelo engenheiro de requisitos. Antes do desenvolvimento do storyboard, o designer de interface deve ter o entendimento das funcionalidades descritas no documento de requisitos [Sny03]. O DSD-REQ-PROCESS considera que esse artefato rena tanto os requisitos iniciais quanto a interface, servindo de entrada para o detalhamento dos requisitos em casos de uso na fase de desenvolvimento distribudo (REQ-ENTREVISTAS-07). O propsito do storyboard possuir a aprovao da interface grca do sistema antes que ele seja documentado. O DSD-REQ-PROCESS considera tambm que este prottipo servir para as atividades de elicitao dos requisitos, atingindo uma maior estabilidade nos mesmos ao trmino desta fase [ABD+ 04]. Papel Responsvel: 1. Designer de interface Artefatos de Entrada: 1. 2. 3. 4. Descrio dos atores do sistema (Seo 6.6.6.1) Base formal de conhecimento do problema Requisitos inicais Prottipo em papel (Seo 6.6.2)
Artefatos de Sada: 1. Storyboard (Seo 6.6.6.3) 2. Descrio dos atores do sistema (Seo 6.6.6.1); 6.2.5 Reviso da Elicitao
O propsito dessa atividade encontrar inconformidades e inconsistncias nos artefatos produzidos durante a fase de elicitao (REQ-OBSERVACAO-10). Essa atividade responsvel por revisar presencialmente atravs de comunicao face a face os artefatos de sada (Requisitos do Sistema, Storyboard) da fase de elicitao. Os resultados da elicitao sero revisados por diferentes pers, e principalmente pelo stakeholder com o intuito de garantir que os storyboards e os requisitos inicias estejam de acordo com a necessidade do cliente. Devido facilidade de manipulao do storyboard em papel [Sny03], o DSD-REQ-Process considera que o storyboard a ser revisado esteja nesse formato, facilitando o trabalho dos revisores. Por estar em papel necessrio a existncia de um Registro de Reviso [GG93] [KS98], contendo a descrio do defeito e as aes a serem tomadas. Em relao aos requisitos iniciais do sistema, se estes estiverem descritos em algum editor de texto colaborativo, o registro de reviso pode ser substitudo pelas inseres de comentrios conforme o processo de inspeo
96
assncrona descrito na Seo 6.4.3. As revises de elicitao devem ser conduzidas num formato de reunio formal buscando encontrar pontos inconsistentes nos artefatos e que os autores possam defender seus pontos de vista alm de esclarecer as dvidas ainda existentes. O coordenador de revises deve conduzir uma reunio produtiva e gerencivel selecionando somente os participantes que possam contribuir para que os objetivos da reunio sejam atingidos. O RUP [Sof05] prope uma srie de diretrizes para a realizao da atividade de Reviso podendo ser separada por: fase, conjunto de artefato e papeis envolvidos. Por se tratar de dois artefatos (Requisitos do Sistema, Storyboard), uma nica reunio de reviso, pode se tornar cansativa para os participantes. Nesses casos o DSD-REQ-PROCESS, sugere a realizao de uma sesso para cada artefato, havendo a presena tanto do engenheiro de requisitos quanto do designer de interface. Papis Envolvidos: 1. 2. 3. 4. 5. Engenheiro de requisitos Revisor tcnico Stakeholder Designer de interface Gerente de projeto / coordenador da reviso
Artefatos de Entrada: 1. Descrio dos atores do sistema (Seo 6.6.6.1) 2. Storyboard (Seo 6.6.6.3) 3. Requisitos iniciais (Seo 6.6.4) Artefatos de Sada: 1. Registro de reviso Seo 6.6.3 6.2.5.1 Passos para Execuo
Contactar participantes : O coordenador de revises deve contactar os participantes da reviso e averigar a disponibilidade dos mesmos. Agendar horrio de reunio de reviso : A partir do horrio disponvel dos integrantes, o coordenador de revises dever informar a data e horrio de realizao da mesma. Disponibilizar artefatos para os revisores : O coordenador de revises, coletar com os autores a ltima verso dos artefatos e disponibilizar para os participantes. Realizar reviso : Caso todos os participantes se encontrem presentes na reunio a mesma
97
ser iniciada caso contrrio o coordenador de revises dever decidir se ir prosseguir remarcar.
Redigir registro de reviso : O coordenador de revises ir redigir os defeitos encontrados durante a reviso no Registro de Reviso.
6.2.6
Retrabalho Reviso de Elicitao
O propsito desta atividade corrigir os pontos levantados durante a reviso. Todos os defeitos encontrados estaro no registro de reviso, que servir como artefato de entrada para a execuo desta atividade. O Coordenador de Reviso ir disponibilizar o registro de reviso para os autores, estes por sua vez tero a obrigao de corrigi-los. Caso algum defeito encontrado necessite de uma nova elicitao, o autor dever comunicar o coordenador de revises para remarcar uma nova elicitao em grupo. Quando os defeitos encontrados estiverem todos corrigidos os autores devero disponibilizlo para o coordenador de revises, para que esse valide as correes. Aps a aprovao do coordenador de revises a fase de elicitao estar concluda, podendo haver a partir da a contribuio das unidades distribudas de desenvolvimento. Papis Envolvidos: 1. Engenheiro de requisitos 2. Revisor tcnico 3. Designer de interface Artefatos de Entrada: 1. 2. 3. 4. Registro de reviso Seo 6.6.3 Descrio dos atores do sistema (Seo 6.6.6.1). Storyboard (Seo 6.6.6.3); Requisitos iniciais (Seo 6.6.4);
Artefatos de Sada: 1. Descrio dos atores do sistema (Seo 6.6.6.1). 2. Storyboard (Seo 6.6.6.3); 3. Requisitos iniciais (Seo 6.6.4);
98
6.2.6.1
Passos para Execuo
Entender registros de reviso : Os autores devero entender todos os registros de reviso, caso exista alguma dvida esta dever ser retirada juntamente com o coordenador de revises. Corrigir os erros encontrados : Guiados pelo registro de reviso os autores devero corrigir os erros encontrados. Se necessrio, sugerir nova elicitao em grupo : Caso algum defeito encontrado interra na regra de negcio do sistema ou precise da opinio do stakeholder, uma nova elicitao em grupo dever ser realizada. Por se tratar de uma nova elicitao, o DSD-REQPROCESS voltar para a atividade de elicitao em grupo. Disponibilizar o artefato para o coordenador de revises : Aps corrigir os erros, os autores devero disponibiliz-lo ao coordenador de revises. Vericar as correes realizadas : O coordenador de revises ir vericar se as correes foram realizadas, caso algum dos erros encontrados no esteja complemente corrigido o coordenador de revises ir solicitar ao autor que os nalize. Disponibilizar o artefato para os integrantes : Se todos os erros encontrados no registro de revises estiverem corrigidos o coordenador de revises dever disponibilizar o artefato para os demais integrantes. Nesse momento, a fase de elicitao de requisitos estar nalizada.
6.3
Iterao: Documentao de Requisitos
Quanto mais examinamos um requisito, mais aprendemos com o mesmo sendo encontrados pequenos problemas a serem modicados. O mtodo de escrita de casos de uso deve ser exvel e eciente de modo a reduzir a quantidade de retrabalho. O RUP [Sof05] sugere uma abordagem interativa, com a evoluo gradativa dos casos de uso onde estes so revisados antes de serem detalhados. Levando em considerao que para entender o contexto da aplicao devem ser conhecidos: a relao entre os casos de uso e os diferentes atores do sistema; alm das fronteiras do sistema e suas respectivas transaes. Com o uso de storyboards as fronteiras do sistema estaro delimitadas (REQ-ENTREVISTAS-07), evitando assim que o engenheiro de requisitos das
6.3 ITERAO: DOCUMENTAO DE REQUISITOS
99
unidades distribudas, venham detalhar casos de uso no pertencentes a esse escopo. Alm do mais atravs do uso dos storyboards a relao entre atores e casos de uso ser mais facilmente compartilhada. Atravs da atividade de acompanhamento da documentao (Seo 6.3.3) pelo engenheiro de requisitos que participou das atividades de elicitao este poder identicar os casos de uso que no esto completos ou que no pertencem ao escopo do sistema mitigando a necessidade de retrabalho.
Figura 6.3 Iterao: Documentao dos Requisitos
6.3.1
Apresentar Storyboard
De acordo com as consideraes encontradas durante a anlise do estudo de caso na Seo 5.7.4.2, a apresentao do storyboard atravs de meios de comunicao sncrono (VoIP ou comunicao face a face) diminui o esforo gasto para o entendimento dos requisitos funcionais e mitiga as dvidas do artefato (REQ-OBSERVACAO-12). O propsito dessa atividade que o autor (designer interface), apresente o storyboard para
100
o engenheiro de requisitos responsvel por fazer o detalhamento dos casos de uso. Durante a apresentao, as dvidas encontradas sero respondidas atravs dos meios sncronos diminuindo a ocorrncia de desentendimentos. Com o uso dos meios sncronos, teremos um aumento da ocorrncia de comunicao informal entre as UDS, aumentando a conana e percepo do esprito de equipe entre os integrantes [HMFG01]. Tendo a premissa de que o storyboard no esteja completo, e que este artefato teve discusses e dvidas durante a sua apresentao, ao trmino dessa atividade um dos participantes dever elaborar e enviar um e-mail contendo as decises tomadas (REQ-OBSERVACAO-06), as dvidas encontradas e suas respectivas respostas. Esse e-mail servir como artefato complementar ao storyboard produzido, auxiliando na fase de documentao dos requisitos. Papis envolvidos: 1. Designer de interface 2. Engenheiro de requisitos 3. Engenheiro de software Ferramentas Utilizadas: 1. Editor de texto colaborativo [Goo] 2. udio-conferncia [SL] 3. Correio eletrnico Artefatos de Entrada: 1. Descrio dos atores do sistema (Seo 6.6.6.1) 2. Storyboard (Seo 6.6.6.3) 3. Requisitos iniciais (Seo 6.6.4) Artefatos de Sada: 1. Correio eletrnico contendo o resumo da reunio (Seo 6.3.1.1) 6.3.1.1 Passos para Execuo
Contactar os participantes : O propsito desse passo contactar os participantes com a nalidade de denir o horrio e local da apresentao. Caso a apresentao seja realizada em locais remotos deve ser denido tambm o meio de comunicao a ser utilizado. Disponibilizao do storyboard : O autor dever disponibilizar o artefato para os participantes, para que esses procurem entend-lo e anotar suas respectivas dvidas. Realizao da apresentao : Se os participantes estiverem na mesma UDS, o meio mais adequado a ser utilizado a comunicao face a face. Caso contrrio consideramos os meios
101
de comunicao VoIP como o Skype [SL] seja o meio mais adequado para a execuo dessa atividade nesse ambiente. Mitigar as dvidas encontradas : O autor do artefato dever responder todas as dvidas encontradas durante a apresentao, ou retrabalhar o artefato caso necessrio. Envio de correio eletrnico contendo o resumo da reunio : Dever ser enviado para todos os integrantes um e-mail contendo todas as decises tomadas e as respostas das dvidas encontradas durante a reunio de apresentao do storyboard. 6.3.2 Detalhamento dos Casos de Uso
Para Cockburn [ACB02], quando o desenvolvimento de software realizado por equipes distribudas, necessrio uma descrio mais rigorosa dos casos de uso (REQ-ENTREVISTAS09), sendo necessrio que os mesmos estejam bem estruturados. Os casos de uso diferem de projeto para projeto e de pessoa para pessoa, portanto para que haja uma maior padronizao entre as diferentes equipes necessrio o desenvolvimento e seguimento de templates de casos de uso (REQ-OBSERVACAO-08) , que servem como um guia do que dever ser documentado. Um caso de uso que funciona em uma situao pode ser totalmente descartado em outra devido as diferentes necessidades dos projetos. Visando aumentar a coordenao das atividades e diminuir a necessidade de comunicao informal entre as equipes distribudas, sugerimos a documentao dos requisitos na forma de High Ceremony Use Cases (ver Seo 6.6.6.2), como os storyboard estaro disponveis o engenheiro de requisitos deve documentar os casos de uso a partir dos deles (REQ-ENTREVISTAS-11). J a descrio dos requisitos iniciais do sistema (fase de eliticao), pode ser feita na forma de Low Ceremony Use Case (ver Seo 6.6.6.2), j que eles sero detalhados nas fases posteriores. Papis envolvidos: 1. Engenheiro de requisitos Ferramentas Utilizadas: 1. Editor de texto colaborativo [Goo] Artefatos de Entrada: 1. 2. 3. 4. Correio eletrnico contento o resumo da reunio (Seo 6.3.1.1) Descrio dos atores do sistema (Seo 6.6.6.1) Requisitos iniciais (Seo 6.6.4) Storyboard (Seo 6.6.6.3)
102 Artefatos de Sada:
1. Documento de especicao dos requisitos (Seo 6.6.6) 6.3.2.1 Passos para Execuo
Entender o storyboard : Os autores devem entender o storyboard antes de tentar extrair todos os uxos da aplicao (REQ-OBSERVACAO-11). Descrever os casos de uso a partir do storyboard : Documentar em um ou mais uxos os eventos dos casos de uso a partir do storyboard. Detalhar os casos de uso : Os casos de uso devem ser detalhados de modo a possibilitar o desenvolvimento do software a partir desse artefato. Uma prtica recomendada pelo RUP [Sof05] descrever cada caso de uso individualmente de maneira iterativa, iniciando a partir do uxo principal, identicando diversos uxos secundrios e de erros. O engenheiro de requisitos poder: avaliar, reorganizar ou at mesmo eliminar os casos de uso durante o detalhamento dos mesmos. O DSD-REQ-PROCESS sugere o uso de High Ceremony Use Cases por se tratar de um processo de desenvolvimento distribudo, onde devem ser mitigados o nvel de ambigidade dos requisitos. Os projetos de pesquisa que formaram a base formal de conhecimento, possuam os requisitos descritos na forma de Low Ceremony Use Cases, os quais foram evoludos e detalhados no formato de High Ceremony Use Cases. 6.3.3 Acompanhamento da Documentao
Essa atividade tem o propsito de melhorar a coordenao das equipes distribudas no que se refere a documentao elaborada pelas UDS, a partir desse acompanhamento ser possvel obter noo da evoluo dos artefatos alm de auxiliar tecnicamente na elaborao dos mesmos (REQ-OBSERVACAO-13). Cada artefato dever ter marcos de acompanhamento bem denidos para que a documentao esteja a contento e dentro do escopo de especicao at a data de inspeo formal na fase de validao dos requisitos. Atravs desse acompanhamento, os autores tero feedback (REQ-ENTREVISTAS-02) logo no incio da documentao do artefato, diminuindo o risco do desenvolvimento de um artefato inconsistente e/ou incompleto.
103
Caso a unidade de desenvolvimento distribuda tenha pouca experincia ou no esteja habituada com o artefato a ser produzido, o revisor tcnico da UPD servir como um tutor durante essa atividade de acompanhamento, havendo troca de experincia e conhecimento entre as UDS (REQ-ENTREVISTAS-02, REQ-ENTREVISTAS-03). Outro motivo para a realizao desta atividade garantir que o padro de documentao e o nvel de detalhamento do artefato exigido pelo projeto estejam sendo seguidos, padronizando os artefatos produzidos em diferentes localidades. Segundo Kotonya [KS98] a checagem dos padres de documentao pode ser realizada por um engenheiro de requisitos que no esteja envolvido com a especicao, ou seja eles podero no ter conhecimento dos detalhes dos requisitos do sistema. Logo, caso o engenheiro de requisitos da UPD esteja sobrecarregado, a checagem dos padres de documentao pode ser realizada por outro engenheiro de requisitos. Papis envolvidos: 1. Engenheiro de requisitos Ferramentas Utilizadas: 1. Editor de texto colaborativo [Goo] 2. udio-conferncia [SL] 3. Instant-messaging Artefatos de Entrada: 1. Documento de Especicao dos Requisitos (Seo 6.6.6) Artefatos de Sada: 1. Documento de Especicao dos Requisitos (Seo 6.6.6) 6.3.3.1 Alternativas
O uso de ferramentas colaborativas facilitar a interao entre as UDS [BV05], atravs de um editor de texto colaborativo ser possvel que dois autores venham a trabalhar no mesmo artefato remotamente, dentro do mesmo espao de tempo. Para o acompanhamento da evoluo do artefato, necessrio que a ferramenta d suporte ao controle de verso, para que o revisor tcnico possa comparar as diferentes verses do artefato. Com o uso de ferramentas de comunicao sncrona haver um aumento da percepo do esprito de equipe, aumentando a comunicao informal e a conana entre os integrantes [CA01]. Atravs dessas ferramentas o revisor tcnico conseguir entender as diculdades vivenciadas pelos engenheiros de requisitos das UDS e encontrar solues com os mesmos. recomendado que o revisor tcnico tenha o discernimento na escolha da ferramenta mais adequada para a ocasio, pequenas dvidas podem ser resolvidas atravs de ferramentas instant
104
messaging [HAB+ 02], contudo quando o rudo de comunicao comea a car crtico importante que sejam utilizados meios de comunicao mais ricos em contexto (Figura 2.1) como o de VoIP por exemplo, importante que as dvidas sejam mitigadas logo no incio, para reduzir o tempo gasto na elaborao do DER.
6.4
Iterao: Validao dos Requisitos
Atravs da realizao das revises no haver somente uma maior garantia da corretude e completude dos documentos de requisitos, ocorrer uma melhora no processo de elaborao dos documentos. Melhorando a capacitao dos engenheiros de requisitos das UDS com o aprendizado adquirido a partir da participao das inspees (REQ-ENTREVISTAS-02). As atividades descritas nesse processo foram baseadas no processo de inspeo/reviso proposto por Kotonya [KS98] conforme a Figura 2.3 e adaptado para o ambiente de desenvolvimento distribudo de software atravs da anlise realizada na Seo 5.7.5.
Figura 6.4 Iterao: Validao dos Requisitos
6.4.1
Planejamento de Inspeo
O planejamento de inspeo uma atividade realizada pelo coordenador de inspees. Ele ser responsvel por: denir data/horrio e local da reunio; selecionar e convidar os participantes;
6.4 ITERAO: VALIDAO DOS REQUISITOS
105
conrmar a disponibilidade dos artefatos a serem inspecionados (REQ-OBSERVACAO-07). Para a realizao dessa atividade temos a existncia de dois papis principais: o engenheiro de requisitos o qual o autor do artefato e o stakeholder por ser esse o papel que dever ter suas necessidades atendidas. Caso o stakeholder tenha problema de disponibilidade o horrio deste dever ser priorizado em detrimento dos demais. Logo, o coordenador de revises dever vericar atravs de meios sncronos (informais) quais os horrios em comum que esto disponveis (REQ-OBSERVACAO-17). Aps essa vericao, ele dever contactar atravs de meios de comunicao sncronos os Revisores Tcnicos mais adequados que podero participar da reunio de inspeo nos horrios pr-determinados (REQ-OBSERVACAO-19), ao atingir ao menos mais dois revisores, o coordenador de revises poder enviar um correio eletrnico para os participantes conrmando horrio e local da reunio de inspeo (REQ-OBSERVACAO18). Caso essa inspeo tenha a participao de algum integrante de outra UDS, ela estar sujeita a agentes externos como: conexo com a internet, meio de comunicao utilizado entre outros (REQ-OBSERVACAO-15), os quais podero inviabilizar a realizao dessa reunio. Caso isso ocorra um novo planejamento de inspeo dever ser realizado. Papel Responsvel: 1. Coordenador de revises Papis Envolvidos: 1. 2. 3. 4. Stakeholder Engenheiro de requisitos Designer de interface Gerente de projeto
Ferramentas Utilizadas: 1. Editor de texto colaborativo [Goo] 2. Instant messaging 3. Correio eletrnico 6.4.2 Distribuio do Documento
O propsito dessa tarefa disponibilizar o artefato para todos os revisores (REQ-OBSERVACAO07) e garantir que os mesmos inspecionem a verso correta (REQ-OBSERVACAO-09, REQENTREVISTAS-06). Atravs do uso de ferramentas colaborativas de edio [Goo], o coordenador de revises pde minimizar o esforo gasto com essa atividade (Seo 6.4.2.1) (REQ-ENTREVISTAS-
106 06). Papel Responsvel:
1. Coordenador de revises Papis Envolvidos (Revisores): 1. 2. 3. 4. Revisor tcnico Designer interface Engenheiro de requisitos Engenheiro de software
Ferramentas Utilizadas: 1. Editor de texto colaborativo [Goo] 2. Correio eletrnico 6.4.2.1 Passos para Execuo
Conrmar a verso a ser inspecionada : O Coordenador de Revises dever conrmar juntamente com o Engenheiro de Requisitos a verso a ser inspecionada. Aplicar registro de verso : O Coodenador de Revises ir denir um registro de verso de inspeo no artefato a ser inspecionado. Garantir o acesso ao repositrio : Checar se todos os revisores possuem acesso aos documentos a ser inspecionados. Permisso de escrita : Checar se todos os revisores possuem permisso de escrita, isso se faz necessrio caso o revisor venha adicionar comentrios no artefato. Disponibilizar verso do artefato : Enviar um correio eletrnico para todos os participantes contendo a verso do artefato a ser inspecionado. 6.4.3 Preparao: Inspeo Assncrona
A preparao uma das principais atividades do processo de inspeo, pois nada adianta a realizao de uma reunio de inspeo, sem a preparao dos revisores. O DSD-REQProcess prope que a preparao seja realizada numa ferramenta colaborativa de edio, dessa forma ser possvel haver um compartilhamento das contribuies de cada revisor (REQOBSERVACAO-14). Por ser uma atividade assncrona, possibilitar que os revisores selecionem o horrio mais adequado para realizar a preparao, isso se torna importante devido a
107
divergncia de horrio entre a colaborao e as prioridades das atividades principais de cada revisor. Papel Responsvel: 1. Revisor tcnico Papis Envolvidos (Revisores): 1. 2. 3. 4. Designer interface Engenheiro de requisitos Gerente de projeto Engenheiro de software 6.4.3.1 Passos para Execuo
Reservar horrio para a preparao : O revisor dever reservar um horrio exclusivo para realizar a preparao do artefato. Acessar artefato a ser inspecionado : O revisor acessar o artefato a ser inspecionado. Avaliar contribuio dos demais revisores : O revisor ir avaliar as contribuies dos demais revisores, buscando achar pontos relevantes para que ele possa contribuir. Comparar storyboard com os casos de uso : O revisor dever vericar se os uxos existentes no storyboard esto contemplados no detalhamento dos casos de uso (REQ-OBSERVACAO11). Seguimento do template : Os revisores devem vericar se o template foi seguido pelos autores (REQ-OBSERVACAO-08). Adicionar comentrios de reviso : Ao encontrar no conformidades ou erros nos documentos o revisor dever adicionar comentrios no local exato onde o defeito foi encontrado. 6.4.4 Reunio de Inspeo
O principal propsito dessa atividade agrupar os erros encontrados e eliminar a ocorrncia de falsos positivos [SJLY00] (REQ-OBSERVACAO-15). A reunio de inspeo possui clara vantagem sobre os meios de deteco individuais pois complementa o processo de reviso do artefato [SJLY00]. Atravs desta possvel que cada participante explique seus pontos de vista, buscando um consenso em relao as aes a serem tomadas.
108
Durante a execuo desta atividade necessrio um meio de comunicao mais prximo do face a face (Figura 2.1), devido a necessidade de argumentao e ocorrncia de discusses durante a realizao da reunio (REQ-OBSERVACAO-15). Devido a distribuio geogrca entre os participantes o meio de comunicao pode ser substitudo por uma udio-conferncia atravs de ferramentas de VoIP como o Skype [SL] (REQ-ENTREVISTAS-02). Papel Responsvel: 1. Coordenador de revises Papis Envolvidos (Revisores): Designer interface Engenheiro de requisitos Gerente de projeto Engenheiro de software Ferramentas Utilizadas: 1. Editor de texto colaborativo [Goo] 2. udio-conferncia [SL] 6.4.4.1 Passos para Execuo
Conectar na ferramenta de comunicao : Os revisores devem conectar-se na ferramenta de comunicao denida no horrio acordado durante o planejamento da inspeo (Seo 6.4.1). Histrico de reviso : Os revisores devem informar qual a verso a ser inspecionada no intuito de evitar o conito de verses. Leitura do artefato por sees : O coordenador de revises dever ler o documento atravs de suas sees facilitando a localizao dos demais revisores. Adicionar comentrios nos erros no encontrados : Ao inspecionar o artefato, algum erro poder ser encontrado no momento da reunio. Nesse momento o coordenador de revises poder adicionar o comentrio do defeito com o consentimento dos demais participantes.
109
Reescrever comentrios ambguos : Caso algum dos participantes no entenda o comentrio tecido, este dever ser reescrito para que ele seja entendido por todos os participantes. Remover comentrios desnecessrios ou falsos positivos : Caso algum comentrio seja invlido este dever ser removido para que o artefato no seja modicado nesse local. Aplicar registro de verso : Ao terminar a reunio de inspeo o coordenador de revises dever aplicar um registro de verso informando a verso de inspeo. 6.4.5 Correo da Inspeo
O propsito dessa atividade possibilitar que o autor faa a correo dos erros identicados durante a reunio de inspeo (REQ-OBSERVACAO-07). Inicialmente o autor dever entender os comentrios para depois corrigir o documento. Ao nal ele deve informar ao coordenador de revises sobre o trmino das correes. Considerando que temos apenas um nico responsvel por essa atividade, deve ser nalizada atravs de meios de comunicao assncronos, por melhorar a coordenao das atividades. Papel Responsvel: Engenheiro de requisitos Ferramentas Utilizadas: 1. Editor de texto colaborativo [Goo] 2. Correio eletrnico 6.4.5.1 Passos para Execuo
Acessar verso de inspeo : O engenheiro de requisitos acessa a verso inspecionada do artefato Seo 6.4.4.1. Entender os comentrios : O engenheiro de requisitos entende os comentrios tecidos durante a reunio. Efetuar as correes : O engenheiro de requisitos corrige o artefato de acordo com os comentrios. Comunicar atravs de meio assncrono o trmino das correes : O engenheiro de requisitos envia um correio eletrnico para o coordenador de revises informando que as correes foram efetuadas.
110
6.4.6
Validao
Por intermdio de um editor de texto colaborativo, o coordenador de revises pode recuperar a verso do artefato que contm todos os comentrios inseridos durante a reunio de inspeo e compar-la com a ltima verso existente (ver Figura 5.10) (REQ-OBSERVACAO-04, REQ-OBSERVACAO-09). Assim, os erros existentes nos comentrios podem ser revistos e avaliados durante a validao do documento. O coordenador de revises deve garantir que os defeitos encontrados foram corrigidos (REQ-OBSERVACAO-16). Caso exista algum defeito pendente ento ele deve solicitar que o engenheiro de requisitos retrabalhe no documento (REQ-ENTREVISTAS-03). Caso alguma dessas modicaes altere o escopo do sistema, necessrio que haja uma nova reunio de inspeo com a presena do stakeholder e do gerente de projeto. Se no ocorreu nenhuma dessas restries o artefato dever ser considerado validado e o coordenador de revises dever enviar um correio eletrnico para todos os integrantes com o endereo do documento (REQENTREVISTAS-03, REQ-OBSERVACAO-06). Papel Responsvel: 1. Coordenador de revises Ferramentas Utilizadas: 1. Editor de texto colaborativo [Goo] 2. Correio eletrnico 6.4.6.1 Passos para Execuo
Comparar ltima verso com a verso de inspeo : O coodenador de revises ir utilizar das funcionalidades de controle de verso para comparar a verso de inspeo com a ltima verso do documento. Identicar defeitos e as modicaes realizadas : O coodenador de revises atravs das funcionalidades de comparar documentos ir identicar se todas as modicaes realizadas condizem com os defeitos identicados, caso contrrio, o coordenador de revises pode solicitar que o engenheiro de requisitos retrabalhe no documento. Avaliar impacto das modicaes : O coordenador de revises dever avaliar se o impacto das modicaes esto de acordo com os comentrios. Alguns comentrios podem car passveis de serem resolvidos posteriormente, isso ocorre quando os revisores no tm subsdios para decidir as aes a serem tomadas. Logo as aes a serem decididas a posteriori, podem alterar o escopo do sistema. Nesses casos o coordenador de
6.5 PAPIS E RESPONSABILIDADES
111
revises dever identicar o impacto das modicaes, para decidir se dever validar o documento. Validar ou reinspecionar o artefato : Caso as modicaes alteram o escopo do sistema, o coordenador de revises deve optar por realizar uma nova inspeo no artefato, isso resultar em realizar todo o uxo do processo de inspeo a partir da atividade planejamento da inspeo (Seo 6.4.1). Isso se faz necessrio para que stakeholder e gerente de projeto avaliem e discutam os impactos das modicaes. Caso todos os erros encontrados tenham sido corrigidos e o escopo do sistema no tenha sido alterado, ento o coordenador de revises ir denir um registro de verso validada no documento. Disponibilizar para todos os integrantes a verso validada : Caso a verso tenha sido validada o coodenador de revises ir comunicar e disponibilizar para todos os integratentes o endereo do documento atravs do correio eletrnico.
6.5
Papis e Responsabilidades
Nesta seo descrevemos os papis previstos no processo, bem como a descrio de suas principais responsabilidades. O DSD-REQ-Process um processo baseado no RUP [Sof05]. Logo os papis abaixo descritos foram extrados dele. A descrio abaixo, se faz importante para um melhor entendimento das atividades realizadas em cada fase do DSD-REQ-Process (REQ-OBSERVACAO03). 6.5.1 Engenheiro de Requisitos
Esse papel responsvel por realizar as atividades da Engenharia de Requisitos (elicitao, anlise, negociao, documentao e validao dos requisitos) juntamente com o stakeholder. O engenheiro de requisitos possui duas tarefas principais nesse processo: 1. Elicitar os requisitos juntamente com o stakeholder, entendendo suas necessidades e documentando as mesmas. 2. Mitigar as dvidas a respeito dos requisitos junto equipe de desenvolvimento responsvel pela implementao da soluo. Habilidades Para desempenhar esse papel necessrio que o integrante tenha as seguintes habilidades: 1. Articular as necessidades do usurio com a possvel soluo do problema.
112
2. Facilitar a realizao de reunies e workshops. 3. Boa comunicao verbal e escrita 4. Conhecimento das regras de negocio e das tecnologias envolvidas no projeto. Abordagens de Atribuio Esse papel pode ser atribudo da seguinte maneira: Quando for difcil agrupar os requisitos do sistema interessante que um membro da equipe desempenhe esse papel de forma exclusiva. Em se tratando de equipes pequenas com poucos integrantes um membro da equipe pode desempenhar esse papel e testar o sistema para validar se o que foi desenvolvido est de acordo com o especicado. 6.5.2 Designer de Interface
O designer de interface coordena e dene a interface do usurio. Os designers de interface tambm esto envolvidos na Engenharia de Usabilidade e prototipao das interfaces a serem avaliadas com usurios [Sny03] [Sof05]. A maior preocupao desse papel determinar as especicaes mensurveis de usabilidade, validao de designs interativos com os usurios e redesign baseado nas anlises dos dados obtidos nas avaliaes de uma interface [Ber05]. Suas principais atividades so: 1. Denir as estruturas navegacionais necessitadas pelos diferentes usurios da aplicao, abrangendo usabilidade e design grco; 2. Identicar as necessidades tecnolgicas de interface, visando facilitar o desenvolvimento do projeto; 3. Realizar testes de interface com os usurios; 4. Revisar e prover o feedback da implantao realizada pelos desenvolvedores. 6.5.3 Engenheiro de Software
Esse papel responsvel por desenvolver o sistema. Os engenheiros de software devem utilizar como entrada o DER gerado pelos engenheiros de requisitos. de extrema importncia que os engenheiros de software entendam o DER para que o produto desenvolvido esteja de acordo com sua especicao. Habilidades Para desempenhar este papel necessrio que o integrante tenha o perl com as seguintes habilidades:
6.5 PAPIS E RESPONSABILIDADES
113
1. Denir e criar solues tcnicas atravs das tecnologias utilizadas no projeto. 2. Identicar e construir casos de teste que venham cobrir o comportamento requerido pelos componentes do sistema. 3. Comunicar e repassar a arquitetura da aplicao para os demais integrantes. Abordagens de Atribuio Mesmo em equipes pequenas, os indivduos devem trabalhar em grupo no desenvolvimento de solues tcnicas. Cada integrante pode executar tarefas especicas de acordo com suas habilidades, porm desejvel que as demais tecnologias utilizadas no projeto sejam do conhecimento de todos, para que haja uma maior troca de auxilio tcnico entre os integrantes.
6.5.4
Gerente de Projeto
Indivduo responsvel em gerenciar o projeto,planejando e conduzindo o projeto de desenvolvimento. de sua responsabilidade tambm a denio e negociao do escopo do projeto. Habilidades Para desempenhar esse papel necessrio que o integrante tenha o perl com as seguintes habilidades: 1. 2. 3. 4. 5. 6. Ser um bom facilitador, alm de possuir facilidade na comunicao verbal e escrita. Ter liderana e capacidade de integrar a equipe. Ter experincia do ciclo de vida do desenvolvimento de software. Ter boa apresentao, comunicao e poder de negociao. Capacidade de resolver conitos. Habilidade de informar as decises tomadas diminuindo a ansiedade e stress dos integrantes.
Abordagens de Atribuio Em projetos pequenos, o papel de gerente de projeto usualmente desempenhado por um nico integrante O gerente de projeto deve evitar tomar decises que sejam responsabilidade da equipe de desenvolvimento, como por exemplo decidir sobre a arquitetura do software. Deve ser assegurado que a presso relativa a tempo no impactem nas atividades de desenvolvimento e vice versa.
6.5.5
Stakeholder
Esse papel representa o grupo interessado pelo projeto. Pode ser desempenhado por qualquer um que venha a ser afetado pelo projeto direta ou indiretamente.
114
Para chegar a uma soluo ecaz de um problema complexo, deve-se envolver o grupo de pessoas que venham ter suas necessidades satisfeitas. Tipicamente, os diversos grupos de interesse (stakeholders) possuem diferentes perspectivas do problema alm de diferentes necessidades. Muitos stakeholders so usurios do sistema, outros so usurios indiretos que tero sua rotina inuenciada pela implantao do mesmo. O compreendimento das necessidades e interesses dos stakeholders so elementos chave para o desenvolvimento de uma soluo efetiva. Habilidade O papel de stakeholder requer o expertise no domnio a ser solucionado. Em alguns projetos, o papel de stakeholder deve ser desempenhado de maneira representativa com um numero de pessoas que sero diretamente afetados pelo projeto, mas que por alguma razo no podem expor suas necessidades diretamente. O stakeholder, deve ter a habilidade em elicitar, negociar e validar os requisitos documentados pelo engenheiro de requisito. 6.5.6 Coordenador de Revises
O coordenador de revises responsvel por facilitar as reunies de inspeo, e assegurar a sua execuo ao conduzir atravs dos padres estabelecidos. Suas responsabilidades incluem: 1. Assegurar que as revises foram conduzidas; 2. Designar revisores com o perl adequado para revisar o artefato; 3. Conduzir a reviso de maneira apropriada e eciente; 4. Assegurar que o retrabalho proposto pela reviso foi realizado. Para desempenhar esse papel, o coordenador de revises deve possuir perl gerencial alm de conhecer o papel dos demais integrantes para que possa escolher o revisor tcnico mais adequado. Habilidades importante que o indivduo que for realizar o papel de coordenador de revises, tenha a habilidade de facilitar a colaborao em grupos. O executor desse papel deve possuir conana e respeito pelos demais integrantes envolvidos no processo de reviso. As habilidades apropriadas para esse papel incluem: 1. Habilidade de planejamento e organizacional; 2. Diplomacia e habilidade de resoluo de conitos; 3. Facilitar a colaborao em grupo; 4. Possibilitar a colaborao produtiva do grupo. Abordagens de Atribuio O DSD-REQ-PROCESS sugere que esse papel seja atribudo da seguinte maneira: Em projetos pequenos, geralmente o gerente de projeto responsvel por desempenhar
6.6 ARTEFATOS DO PROCESSO
115
o papel de coordenador de revises. Intercalar o papel de coordenador de revises entre os integrantes do projeto uma abordagem comum, quando os integrantes possuem alto nvel de conana e respeito. Essa abordagem funciona particularmente quando os integrantes so experientes e nivelados tecnicamente.
6.5.7
Revisor Tcnico
O revisor tcnico responsvel por contribuir em reportar sugestes e defeitos dos artefatos a serem revisados. Os papis so organizados em grupos que possuem seu conjunto de atividades e responsabilidades, cada papel pode ser designado para um ou mais integrantes, onde cada integrante pode possuir um ou mais papis. Ao ser atribudo o papel de revisor tcnico, necessrio que o mesmo possua em seu perl as habilidades requeridas para executar a reviso do respectivo artefato. Habilidades O integrante que executar o papel de revisor tcnico precisa ter o seguinte perl e conhecimento: Conhecimento do domnio, ou ter o expertise apropriado em trabalhar no produto a ser revisado; Ter a responsabilidade sobre os outros artefatos produzidos quando o produto desse artefato reetir no desenvolvimento de outros; Ter a responsabilidade pelas tarefas subseqentes a partir do uso desse artefato. Abordagem de Atribuio O papel de revisor tcnico atribudo a um ou mais indivduos caso a caso, de acordo com o(s) artefato(s) produzido(s) e as habilidades tcnicas de cada integrante.
6.6
Artefatos do Processo
Aqui esto descritos os artefatos que sero produzidos durante a execuo do DSD-REQPROCESS.
116 6.6.1
Base formal de conhecimento do problema
A base formal de conhecimento do problema vem de trabalhos de graduao, dissertaes de mestrado e teses de doutorado escritas por estudantes do grupo de pesquisa CCTE [CCeTE07]. Neste cenrio necessrio analisar a base de conhecimentos formal que deu origem aos requisitos levantados, buscando prover maior consistncia e conhecimento cientco sobre os requisitos.
6.6.1.1
Consideraes
Normalmente os trabalhos da base formal de conhecimentos do problema possuem um conjunto de requisitos detalhados na forma de Low Ceremony Use Cases [ACB02], conforme a Seo 6.3.2.
6.6.2
Prottipo em Papel
Prottipo de interface de baixa-delidade, confeccionado durante a elicitao em grupo realizada em um dos sites de desenvolvimento de forma presencial com a participao stakeholder. A prototipao em papel pode ser considerado um mtodo de brainstorming, design, criao, teste e comunicao das interfaces do usurio. Essa tcnica independente de plataforma, podendo ser usada para diversos tipos de aplicao como: aplicaes web, desktop, etc. Qualquer coisa que possua interface humano-mquina um potencial candidato para o uso da tcnica de prototipao em papel [Sny03]. Um prottipo de baixa delidade evita a tentao de buscar a perfeico na aparncia das telas. Deve ser levado em considerao que esse artefato tem o propsito de elicitar as funcionalidades e a navegabilidade do software [ABD+ 04]. Esse esboo inicial da interface da aplicao, ser validado de forma presencial com a participao do stakeholder, engenheiro de requisitos e designer de interface. Ele ser confeccionado durante as sees de brainstorming, realizadas durante as atividades de elicitao dos requisitos. Logo ter a participao do engenheiro de requisitos e do designer de interface, que trabalharo conjuntamente no desenvolvimento dessa soluo. Este artefato ser descartado aps ser evoludo para o storyboard desenvolvido pelo designer de interface.
117
6.6.3
Registro de Reviso
O registro de reviso o artefato de sada da atividade reviso. Criado para capturar o resultado das revises realizadas no artefato. Sua funo principal capturar os resultados e as concluses da reviso alm de identicar as resolues que devero ser realizadas em cada item. Para as UDS, este artefato auxiliar nas correes a serem efetuadas, servindo como documentao de suporte para as mesmas. Na UPD, ser atravs deste que o coordenador de revises poder checar as sugestes propostas durante a reviso e vericar se as mudanas foram efetuadas. Caso o artefato precise ser modicado este voltar para a atividade de documentao dos requisitos e uma nova reviso devera ser realizada. 6.6.3.1 Passos para Execuo
Para a criao do registro de reviso, devem ser seguidos os seguintes passos: 1. Artefatos a serem revistos e objetivos da reviso Lista com os artefatos que sero revisados e uma descrio dos objetivos dessa reviso. 2. Participantes da reviso Lista dos indivduos que iro participar dessa reviso com seus respectivos papis. Por exemplo: coordenador de reviso, revisor tcnico, cliente, autor e etc. 3. Agendamento e local Incluir a data, horrio e local da reunio de reviso. Disponibilizar o artefato para todos os participantes. 4. Problemas identicados e recomendaes para resoluo Listar qualquer problema identicado durante a reviso. Os Revisores podem identicar: 1. 2. 3. 4. Problemas com o artefato que precisam ser corrigidos, Problemas com o projeto identicados na reviso, Problemas no produto os quais foram identicados na reviso do artefato. A equipe de reviso podem fazer recomendaes para a resoluo dos problemas.
5. Aes a serem tomadas Listar as aes a serem tomadas nos items identicados durante a reviso, cada item deve conter o identicador do revisor responsvel por identic-lo e sua respectiva ao. 6. Problemas a serem solucionados pelo gerente de projeto Os problemas que no sao passveis de resoluo pelos revisores, pois os mesmos no conseguiram entrar em acordo para a sua soluo, devem ser escalados para a interveno do gerente de projeto.
118
6.6.3.2
Formato do Artefato
Este artefato pode ser subdivido em duas sees: uma que contm os artefatos a serem revisados e seus respectivos revisores. Outra seo contendo uma lista dos tens levantados juntamente com a ao a ser tomada. A primeira seo pode ser representada num e-mail contendo: 1. 2. 3. 4. 5. Objetivos da reviso Participantes da reviso Hora e local Decises Aes a serem tomadas.
A segunda seo conter a lista dos tens levantados podendo ser substituda por comentrios a serem anexos no prprio artefato. O coordenador de revises poder comparar as duas verses do artefato e acompanhar sua evoluo assegurando que as alteraes foram efetuadas. 6.6.4 Requisitos Iniciais
Requisitos correspondem descrio dos servios que um sistema deve prover e s restries sobre as quais ele deve operar. Os requisitos inicias podem ser denidos como as acoes fundamentais do sistema, processando as entradas do usurios em sadas do sistema. Dentro do projeto os requisitos iniciais so descritos nas fases iniciais da elicitao, possuem um alto nvel de abstracao, servindo para orientar as fases seguintes do processo de engenharia de requisitos. Os projetos de pesquisa que formaram a base formal de conhecimento, estavam descritos na forma de Low Ceremony Use Cases (ver Seo 6.6.6.2) [ACB02], durante a fase de documentao eles foram evoludos e detalhados na forma de High Ceremony Use Cases [ACB02]. 6.6.5 Requisitos do Sistema
Esse artefato contm uma viso geral dos requisitos do sistema, incluindo os requisitos de qualidade que no esto descrito em casos de uso. Os requisitos do sistema so compostos pelos requisitos suportados e os casos de uso. Os casos de uso descrevem o comportamento dos requisitos funcionais do sistema e os requisitos suportados, descrevem o escopo, requisitos no funcionais e demais requisitos que no possam ser detalhados em casos de uso. Os requisitos do sistema podem ser organizados de acordo com o modelo FURPS+, que
119
um acrnimo de Functionality, Usability, Reliability, Performance, Supportability + Constraints (Funcionalidade, Usabilidade, Segurana, Performance, Suportabilidade e Escopo Negativo) [Gra92] como podemos ver na descrio: Usabilidade Os requisitos de usabilidade incluem os requisitos baseado nos fatores humanos, a interface com o usurio, problemas de acessibilidade, esttica e consistncia com a interface do usurio. Segurana Os requisitos de segurana incluem aspectos como: disponibilidade, preciso, frequncia de falhas, tolerncia a falhas ou recuperabilidade quando o sistema ocorre um erro crtico. Performance Requisitos de performance so relativos ao tempo de resposta do sistema no uso de recursos. Suportabilidade Os requisitos de suportabilidade incluem: testabilidade, adaptabilidade, manutenibilidade, compatibilidade, congurao, instalao, escalabilidade e assim por diante. + (Escopo Negativo) O "+"do acrnimo FURPS+ permite especicar o escopo negativo, como arquitetura, implementao, guidelines de interface, restries fsicas e restries legais: Os requisitos funcionais especicam aes que um sistema deve ser capaz de executar. Geralmente, isso melhor descrito em um modelo de caso de uso e em descries de casos de uso [ACB02]. Os requisitos funcionais especicam, portanto, o comportamento de entrada e sada de um sistema [Sof05]. 6.6.5.1 Consideraes
O DSD-REQ-PROCESS por se tratar de um processo de desenvolvimento distribudo, onde o nvel de ambigidade dos requisitos, devem ser mitigados os High Ceremony Use Cases [ACB02] so os mais indicados para esse contexto. 6.6.6 Documento de Especicao dos Requisitos
O Documento de Especicao dos Requisitos compreende a coleo de todos os requisitos pertecentes ao projeto. interessante que sejam denidos templates para que esse artefato ao ser elaborado seja seguido os padres denidos pela organizao, como sugerido pela [Byr94].
120
O DER dever acompanhar a evoluo do sistema, fornecendo o suporte as fases de desenvolvimento do projeto e as novas funcionalidades do sistema. A coleo de requisitos de um DER pode estar descrito em um nico documento ou agrupados num conjunto de artefatos. Para DSD-REQ-PROCESS consideramos que o DER ser composto por trs artefatos: Descrio dos Casos de Uso, Descrio dos Atores do Sistema e Storyboards. 6.6.6.1 Descrio dos Atores do Sistema
Esse artefato se faz presente nas atividades de elicitao do RUP [Sof05], dentro do estudo de caso o utilizamos mas no validamos sua importncia dentro do estudo de caso, ao nosso entender esse estudo foge do escopo desse trabalho. Para entender o propsito do sistema necessrio conhecer quem o utiliza, diferentes usurios so representados como atores. Um ator dene um conjunto coerente de papis que os usurios do sistema podem desempenhar ao interagir com ele. Uma instncia de ator pode ser desempenhada tanto por um indivduo quanto por um sistema externo. Um ator pode ser qualquer coisa ou qualquer um que venha trocar informaes com o sistema. Podendo ser um usurio , um dispositivo de hardware ou outro sistema. A diferena entre um ator como sendo um indivduo perante uma classe que o represente, que diversos usurios podem desempenhar o mesmo papel. Quando os usurios desempenharem o mesmo papel, no signica que eles tero o mesmo ator para represent-los. Nesses casos, cada usurio dever ter uma instncia de um ator, onde cada ator ter um nome, descrio e estar relacionado aos casos de uso do sistema. O engenheiro de requisitos o responsvel nal pelo gerenciamento de atores. Apesar do designer de interface atualizar as informaes detalhadas sobre cada ator, o engenheiro de requisitos responsvel por garantir que: Cada ator est associado aos casos de uso corretos. Cada ator parte dos relacionamentos de generalizao corretos. Cada ator dene um papel coeso e independente entre os demais atores. Um designer de interface responsvel pela integridade dos detalhes do ator humano, garantindo que: Cada ator captura as caractersticas necessrias exigidas para criar a interface do usurio.
121
Os casos de uso locais que descrevem o ator so legveis e consistentes com suas propriedades. 6.6.6.2 Descrio de Casos de Uso
O documento de caso de uso dene um conjunto de cenrios, onde cada cenrio uma seqncia de aes que o sistema executa por interveno dos atores no sistema. A guideline Detalhar Casos de Uso do RUP [Sof05], sugere que os mesmos sejam escritos de forma iterativa, iniciando do detalhamento do uxo principal at identicar os uxos alternativos e de erros. Os casos de uso devem ser detalhados at atingir o nvel de detalhamento requerido pelo projeto. Cockburn [ACB02], classica os casos de uso de duas formas: High Ceremony Use Cases possuem um nvel de detalhamento maior e mais bem estruturado. So indicados para grandes projetos com um nvel de complexidade maior. Tambm so utilizados em culturas de desenvolvimento que prezam por documentao. Low Ceremony Use Cases Outros projetos podem ser mais geis e menos formais. Os casos de uso do tipo Low Ceremony Use Cases so mais indicados para pequenos projetos e sistemas no crticos, sendo necessrio que os integrantes tenham o conhecimento do domnio do problema a ser desenvolvido. Caso os autores faam uso de templates, muitos dos campos disponveis para o detalhamento do caso de uso podem car em branco por exemplo. 6.6.6.3 Storyboard
Prottipo de interface de mdia-delidade utilizada como artefato de documentao. Um storyboard consiste numa srie de desenhos ou imagens que representam como a interface utilizada para desempenhar determinada tarefa. Para execuo desse processo desejvel que os storyboards tenham um nvel de detalhe que seja possvel incluir as representaes da interface do usurio, fornecendo o embasamento necessrio para a documentao do DER [Sny03]. Normalmente so utilizados para demonstrar todos os passos que o usurio ir desempenhar na execuo de determinada tarefa, oferecendo aos usurios a possibilidade de reviso da navegabilidade do sistema e identicar suas funcionalidades [Sny03]. Dentro da Engenharia de Requisitos o storyboard considerado um prottipo descartvel e segundo o [Byr94] os prottipos descartveis so teis pelas seguintes razes: 1. Os usurios podem ter uma viso mais amigvel a partir de um prottipo do que lendo um DER, isso propicia um feedback nas fases iniciais do projeto.
122
2. Os prottipos antecipam aspectos do comportamento do sistema. Produzindo no apenas respostas, mas tambm novos questionamentos auxiliando assim na validao do DER a posteriori. 3. Um DER baseado em prottipos tende a possuir menos mudanas durante o desenvolvimento, diminuindo a ocorrncia de retrabalho.
C APTULO 7
Concluso
Este trabalho teve por objetivo propor um processo de engenharia de requisitos para equipes distribudas, a partir da investigao qualitativa das prticas de uma equipe de DDS quanto aos processos relacionados a validao e documentao dos requisitos. Este trabalhou visou preencher uma lacuna existente na rea de DDS, especicamente em engenharia de requisitos, conforme apontado por Zowghi [DZO01]. Foi utilizado o paradigma de pesquisa qualitativa, em particular, tcnicas de grounded theory atravs da observao participante em um estudo de caso, para analisar a estrutura das prticas desempenhadas pelos participantes de projetos de desenvolvimento distribudo de software. A metodologia de pesquisa utilizada neste trabalho auxiliou na identicao das diculdades dos participantes na execuo das atividades sncronas e assncronas a medida em que contribuiu para a denio de qual meio de comunicao dever ser utilizado para cada atividade. Devemos destacar que os resultados desse estudo de caso foram corroborados pela literatura estudada, o que permitiu uma maior segurana na proposio do processo, isto tpico do tipo de pesquisa desenvolvida, exploratria e de base qualitativa. De acordo com as mtricas apresentadas (Seo 5.7.3), o uso dos storyboards como artefato de sada da elicitao e de entrada para a documentao do DER no contexto de DDS, apresentou-se como uma tcnica vivel para o compartilhamento dos requisitos entre as equipes distribudas servindo de suporte para um melhor detalhamento da especicao do DER. Por intermdio do uso de ferramentas de comunicao as quais permitem audio-conferncia [SL] obtivemos uma maior maturidade e evoluo no desenvolvimento distribudo desse estudo de caso aumentando a comunicao informal entre as equipes formando verdadeiros grupos de trabalho. Por se tratar do estudo de um caso nico, no possvel generalizar esse processo. Contudo, atravs da replicao deste estudo em outros projetos de software poderemos ren-lo e apliclo em outros contextos. 123
124
CAPTULO 7 CONCLUSO
7.1
Trabalhos Futuros
Durante o desenvolvimento do trabalho, vrias atividades foram percebidas. Contudo, devido limitao do escopo desse trabalho elas no puderam ser inseridas, mas reconhecemos como uma extenso da pesquisa desse trabalho em possveis trabalhos futuros: Tratar a gerncia dos requisitos no processo proposto. A importncia da gerncia dos requisitos reconhecida [KS98], porm se torna uma atividade bastante complexa quando executada em ambientes de desenvolvimento distribudo de software [DZ02]. Analisar o impacto da alteraes dos prottipos na fase de validao. Devido a limitaes de tempo e do perodo da observao, no analisamos o impacto da alterao dos artefatos durante a elicitao. Avaliar o uso de agendas colaborativas no processo proposto. Acreditamos que atravs destas ferramentas, iremos diminuir a necessidade de ferramentas de comunicao sncronas para a atividade de planejamento de reunio. Estudar mecanismos e tcnicas para realizar a elicitao em ambientes distribudos de desenvolvimento. Elaborar um ambiente colaborativo de inspeo dos requisitos a partir dos requisitos extrados desse trabalho.
A PNDICE A
Entrevista Semi-Estruturada
Esse documento contm um conjunto de perguntas a serem respondidas em entrevistas semiestruturadas, a pessoas envolvidas no desenvolvimento de softwares oriundos de pesquisa. A pretenso dessa pesquisa a prototipao de uma ferramenta com as necessidades e interesses dos usurios pesquisados. Logo ao nal da pesquisa, estaremos levantando os requisitos da ferramenta.
A.1
Integrantes da Equipe
Entrevista com Gerentes de Projeto
Qual o fator motivacional dos integrantes? Qual o grau de comprometimento no projeto? Quanto tempo gasto dirio no gerenciamento? Tarefas Quais as ferramentas que voc utiliza para o gerenciamento de projetos? O que poderia ser melhorado na gerncia de projeto? Como a cobrana em cima dos alunos? Existe integrao do software? E como ela feita? Como os requisitos foram coletados? Como eles so validados? Existe gerenciamento de requisitos? Como ele realizado? Como a fase de negociao dos requisitos? Como vocs negociam os requisitos, juntamente com o cliente? 125
126
APNDICE A ENTREVISTA SEMI-ESTRUTURADA
Vocs fazem prototipao dos casos de uso? Se sim, o quanto elas ajudam no entendimento do projeto para todos os envolvidos? Ambiente Tcnico Qual a metodologia de desenvolvimento utilizada? E como ela funciona? Existe gerncia de congurao? Em caso negativo, faz falta? Ambiente Fsico A forma de desenvolvimento presencial ou distribuda? Se distribudo como eles trabalham nesse ambiente? Ambiente Organizacional Os integrantes so funcionrios ou pesquisadores? Qual o seu papel dentro do projeto? A quem o projeto se destina? O projeto ser um produto, pesquisa? O que vocs pretendem fazer com o software desenvolvido? Qual o grau de coeso da equipe em relao a horrios? Como so as fases do projeto? Como a fase de entendimento dos requisitos? Como os desenvolvedores e stake holders entendem os requisitos? Que tipo de ferramenta seria interessante para reali-zar essa atividade?
A PNDICE B
Planilha de Coleta de Mtricas
A planilha de coleta de mtricas teve como objetivo de avaliar a qualidade dos requisitos produzidos pelas unidades distribudas. Ela foi elaborada a partir de caractersticas que um requisito bem descrito deve possuir conforme a IEEE 830 [Byr94]. A planilha de coleta de mtricas teve os seguintes atributos: 1. Qualidade da Escrita (a) Alta (b) Mdia (c) Baixa 2. Grau de Entendimento (a) Alta (b) Mdia (c) Baixa 3. Granularidade (a) Alta (b) Mdia (c) Baixa 4. Ambigidade (a) Muito (b) Mdia (c) Pouca 5. Duplicado (a) Sim (b) No 6. Referente ao Mdulo 127
128 (a) Sim (b) No
APNDICE B PLANILHA DE COLETA DE MTRICAS
7. til (pronto ir para produo) (a) Sim (b) No
A PNDICE C
Glossrio
ADS Ambiente de Desenvolvimento de Software BM Business Management CASE Computer-Aided Software Engineering CODIPSE COoperative and DIstributed Process Support Environment CMM Capability Maturity Model DCS Desenvolvimento Centralizado de Software DER Documento de Especicao dos Requisitos DDS Desenvolvimento Distribudo de Software DM Development Management DGS Desenvolvimento Global de Software EC Estudo de Caso EPF Eclipse Process Framework EPM Enterprise Project Manager ER Engenharia de Requisitos ES Engenharia de Software FCS Fatores Crticos de Sucesso MRS Marketing Requirements Specication LGPL GNU Lesser General Public License P2P peer-to-peer 129
130
APNDICE C GLOSSRIO
PSEE Process-Centered Software Engineering Environment OMG Object Management Group RUP Rational Unied Process SPEM Software Process Engineering Metamodel UDS Unidades Distribudas de Desenvolvimento UPD Unidades Principal de Desenvolvimento UD1 Unidades Distribudas 1 - Petrolina VoIP Voz Sobre IP XML Extensible Markup Language XSL The Extensible Stylesheet Language Family
Referncias Bibliogrcas
[ABD+ 04]
Alain Abran, Pierre Bourque, Robert Dupuis, James W. Moore, and Leonard L. Tripp. Guide to the Software Engineering Body of Knowledge - SWEBOK. IEEE Press, Piscataway, NJ, USA, 2004 version edition, 2004. Steve Adolph, Alistair Cockburn, and Paul Bramble. Patterns for Effective Use Cases. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2002. Vincenzo Ambriola and Vincenzo Gervasi. The case for cooperative requirement writing. In ECOOP Workshops, pages 477479, 1998. Enoque Calvino Melo Alves. Design de componentes educacionais sncronos. Masters thesis, Universidade Federal de Pernambuco, Julho 2005. Socorro Vnia Loureno Alves. Suporte percepo em groupware sncronos de aprendizagem. Masters thesis, Universidade Federal de Pernambuco, Fevereiro 2006. Cynthia Belleza Bernardino. Design interativo em processos geis de desenvolvimento de software. Trabalho de Graduao - Universidade Federal de Pernambuco, Maro 2005. Regiane Brito. Suporte engenharia de requisitos no desenvolvimento distribudo de software. Masters thesis, Universidade Federal de Pernambuco, Fevereiro 2006. Regiane Brito and Alexandre Vasconcelos. Suporte a engenharia de requisitos com equipes distribudas atravs de contexto. In Workshop Brasileiro de Tecnologias para Colaborao 2005, 2005. E. R. Byrne. IEEE Standard 830: Recommended practice for software requirements specications. In Proceedings: 1st International Conference on Requirements Engineering, page 58. IEEE Computer Society Press, 1994. 131
[ACB02]
[AG98]
[Alv05]
[Alv06]
[Ber05]
[Bri06]
[BV05]
[Byr94]
132 [CA01]
REFERNCIAS BIBLIOGRFICAS
Erran Carmel and Ritu Agarwal. Tactical approaches for alleviating distance in global software development. IEEE Software, 18(2):2229, /2001. Jaelson Castro, Fernanda M. R. Alencar, and Gilberto A. Cysneiros Filho. Closing the gap between organizational requirements and object oriented modeling. J. Braz. Comp. Soc., 7(1):516, 2000. Erran Carmel. Global Software Teams: Collaborating Across Borders and Time Zones. Prentice Hall, December 1998. Cincias Cognitivas e Tecnologia Educacional, 2007. http://www.cin.ufpe.br/ ccte/. Disponvel em
[CAF00]
[Car98]
[CCeTE07]
[CNdDCeT06] Conselho Nacional de Desenvolvimento Cientco e Tecnolgico, 2006. Disponvel em http://www.cnpq.br/. [DESG00] D. E. H. Damian, A. Eberlein, M. L. G. Shaw, and B. R. Gaines. Using different communication media in requirements negotiation. Software, IEEE, 17(3):2836, 2000. Ana Cludia Veras Beltro Didier. Wre-process: Um processo de engenharia de requisitos baseado no rup. Masters thesis, Universidade Federal de Pernambuco, Agosto 2003. Daniela E. Damian and Didar Zowghi. The impact of stakeholders? geographical distribution on managing requirements in a multi-site organization. In RE, pages 319330, 2002. Daniela Damian, Didar Zowghi, and Ray Offen. Field studies of requirements engineering in a multi-site software development organization: Research in progress. In Proc. Australian Workshop on Requirements Eng ., 2001. Daniela Damian, Didar Zowghi, Lakshminarayanan Vaidyanathasamy, and Yogendra Pal. An industrial case study of immediate benets of requirements engineering process improvement at the australian center for unisys software. Empirical Softw. Engg., 9(1-2):4575, 2004. Roberto Evaristo and Paul Fenema. A typology of project management: Emergence and evolution of new forms. International Journal of Project Management, 17(5):275281, 1999.
[Did03]
[DZ02]
[DZO01]
[DZVP04]
[EF99]
133
[FdCAeSdP06] Faculdade de Cincias Aplicadas e Sociais de Petrolina, 2006. Disponvel em http://www.facape.br/. [Fli04] Uwe Flick. Uma Introduo Pesquisa Qualitativa. Bookman, 2 edition, 2004. Tom Gilb and Dorothy Graham. Software Inspection. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1993. Paul Grunbacher, Michael Halling, and Stefan Bif. An empirical study on groupware support for software inspection meetings. ase, 00:4, 2003. John C. Grundy, Warwick B. Mugridge, and John G. Hosking. Constructing component-based software engineering environments: issues and experiences. volume 42, pages 103114, 2000. Groove Networks. Groove Virtual Ofce, 2006. http://www.groove.net/home/index.cfm. Disponvel em
[GG93]
[GHB03]
[GMH00]
[GN06]
[Gom00]
Alex Sandro Gomes. Educao a distncia via web - desenvolvimento de um modelo conceitual. Masters thesis, Universidade Federal do Rio Grande do Norte, 2000. Apuena Vieira Gomes. Uma Abordagem Centrada No Usurio Para Ferramentas De Suporte A Atividades Docentes Em Ambientes De Educao A Distncia. PhD thesis, Universidade Federal de Pernambuco, Maio 2004. Google. Writely. Disponvel em http://www.writely.com/. Robert B. Grady. Practical software metrics for project management and process improvement. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1992. eGroupware, 2006. Disponvel em http://www.egroupware.org. James D. Herbsleb, David L. Atkins, David G. Boyer, Mark Handel, and Thomas A. Finholt. Introducing instant messaging and chat in the workplace. In CHI 02: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 171178. ACM Press, 2002.
[Gom04]
[Goo] [Gra92]
[GRO06] [HAB+ 02]
134 [HG98]
D. Herlea and S. Greenberg. Using a groupware space for distributed requirements engineering. In Proc. of the Seventh IEEE International Workshop on Enabling Technologies, June 1998. James D. Herbsleb and Deependra Moitra. Guest editors introduction: Global software development. IEEE Software, 18(2), 2001. James D. Herbsleb, Audris Mockus, Thomas A. Finholt, and Rebecca E. Grinter. An empirical study of global software development: Distance and speed. In ICSE, pages 8190, 2001. Frank Houdek and Klaus Pohl. Analyzing requirements engineering processes: A case study. In DEXA Workshop, pages 983990, 2000. Lasse Harjumaa and Ilkka Tervonen. A www-based tool for software inspection. In HICSS 98: Proceedings of the Thirty-First Annual Hawaii International Conference on System Sciences-Volume 3, page 379, Washington, DC, USA, 1998. IEEE Computer Society. International Conference on Global Software Engineering, 2006. Disponvel em www.icgse.org//. The Standish Group International. Chaos report. Technical report, The Standish Group, 2001. Jynx Playware, 2006. Disponvel em http://www.jynx.com.br/. Dale Walter Karolak. Global Software Development : Managing Virtual Teams and Environments. Wiley-IEEE Computer Society Pr, December 1998. Gerald Kotonya and Ian Sommerville. Requirements Engineering : Processes and Techniques. Worldwide Series in Computer Science. John Wiley & Sons, September 1998. Marjo Kauppinena, Matti Vartiainenb, Jyrki Kontioa, Sari Kujalaa, and Reijo Sulonena. Implementing requirements engineering processes throughout organizations: success factors and challenges. Information and Software Technology, (17):937953, 2004. Wesley Lloyd. Tools and techniques for effective distributed requirements engineering: An empirical study. Masters thesis, Virginia Tech, July 2001.
[HM01]
[HMFG01]
[HP00]
[HT98]
[ICoGSE06]
[Int01]
[JP06] [Kar98]
[KS98]
[KVK+ 04]
[Llo01]
135
[Lop03]
Leandro Lopes. Um modelo de processo de engenharia de requisitos para ambientes de desenvolvimento distribudo de software. Masters thesis, Pontifcia Universidade Catlica Do Rio Grande Do Sul, October 2003. N. Mullick, M. Bass, Z. Houda, Paulish Paulish, and M. Cataldo. Siemens global studio project: Experiences adopting an integrated gsd infrastructure. In ICGSE 06: Proceedings of the IEEE International Conference on Global Software Engineering (ICGSE06), pages 203212, Washington, DC, USA, 2006. IEEE Computer Society. Leonardo Medeiros, Maria Cludia, and Alex Sandro Gomes. Amadeus Software Project Management Plan. CCTE, 01.00 edition, Agosto 2005. Vahid Mashayekhi, Janet M. Drake, Wei-Tek Tsai, and John Riedl. Distributed, collaborative software inspection. IEEE Softw., 10(5):6675, 1993. Michael Marquardt and Lisa Horvath. Global Teams: How Top Multinationals Span Boundaries and Cultures with High-Speed Teamwork. Davies-Black Publishing,U.S., December 2001. Microsoft. Msn Messenger, 2006. Disponvel em http://www.msn.com/. Microsoft. Powerpoint, 2006. Disponvel em http://www.microsoft.com/. MUNDDOS, 2006. Disponvel em http://www.inf.pucrs.br/munddos/. Bashar Nuseibeh and Steve M. Easterbrook. Requirements engineering: a roadmap. In ICSE - Future of SE Track, pages 3546, 2000. Milton Burgos Josu Neto. Transparncia social em ambientes colaborativos de ensino: Interao e percepo no ambiente ensinarnet. Trabalho de Graduao - Universidade Federal de Pernambuco, Novembro 2005. Andr Neves and Alexandre Vasconcelos. Model for alternative analysis. In 8th International Conference on Human-Computer Interaction, Munich, 1999. Mary OHara-Devereaux and Robert Johansen. GlobalWork: Bridging Distance, Culture and Time (The Jossey-Bass Management Series). Jossey-Bass, May 1994.
[MBH+ 06]
[MCG05]
[MDTR93]
[MH01]
[Mic06a] [Mic06b] [MUN06] [NE00]
[Net05]
[NV99]
[ODJ94]
136 [OMG05]
OMG. Software Process Engineering Metamodel Version 1.1, 2005. http://www.omg.org/technology/documents/formal/spem.htm. Rafael Prikladnicki, Jorge Luis Nicolas Audy, and J. Roberto Evaristo. A reference model for global software development. In Luis M. CamarinhaMatos, editor, Virtual Enterprises and Collaborative Networks, pages 369 378. Kluwer, 2004. J. M. Perpich, Dewayne E. Perry, Adam A. Porter, Lawrence G. Votta, and M. W. Wade. Anywhere, anytime code inspections: Using the web to remove inspection bottlenecks in large-scale software development. In International Conference on Software Engineering, pages 1421, 1997. Rafael Prikladnicki. Munddos - um modelo de referncia para desenvolvimento distribudo de software. Masters thesis, Pontifcia Universidade Catlica Do Rio Grande Do Sul, October 2003. Dewayne E. Perry, Nancy Staudenmayer, and Lawrence G. Votta. People, organizations, and process improvement. IEEE Softw., 11(4):3645, July 1994. QSR. Nvivo 2.0, 2007. Disponvel em http://www.qsrinternational.com/. Jorge Luis Cavalcanti Ramos. Avaliao de alunos em ambientes de ensino distncia via web. Masters thesis, Universidade Federal de Pernambuco, Dezembro 2005. RATIONAL. RequisitePro, 2005. Disponvel em http://www.ibm.com/. Thomas Lee Rodgers, Douglas L. Dean, and Jr. Jay F. Nunamaker. Increasing inspection efciency through group support systems. hicss, 01:10018b, 2004. Farshad Rai and Sam Perkins. Internationalizing software with concurrent engineering. IEEE Software, 12(5):3946, 1995. Danille Rousy, Geber Ramalho, and Marcelo Guedes. Simuladores para jogos de negcio usando atores sintticos: Uma aplicao de gerentes de projetos de desenvolvimento de software. FINEP - Financiadora de Estudos e Projetos, 2005.
[PAE04]
[PPP+ 97]
[Pri03]
[PSV94]
[QSR07] [Ram05]
[RAT05] [RDJFN04]
[RP95]
[RRG05]
137
[SJLY00]
Chris Sauer, D. Ross Jeffery, Lesley Land, and Philip Yetton. The effectiveness of software development technical reviews: A behaviorally motivated program of research. IEEE Trans. Softw. Eng., 26(1):114, 2000. Skype Limited. Skype 2.00. Disponvel em http://www.skype.com/. Carolyn Snyder. Paper Prototyping: The Fast and Easy Way to Design and Rene User Interfaces (The Morgan Kaufmann Series in Interactive Technologies). Morgan Kaufmann, April 2003. Rational Software. Rational Unied Process - Best Practices for Software Development Teams. IBM, tp026b, rev 11/01 edition, Nov 2001. Rational Software. Rational Unied Process. IBM, version 7.0.1.e edition, 2005. Ian Sommerville. Software Engineering. Addison Wesley, seventh edition, May 2004. Fernando Da Fonseca Souza. Ambientes multimdia de aprendizagem, desenvolvimento centrado no usurio e jogos multi-usurios. CNPq - Conselho Nacional de Desenvolvimento Cientco, 2005. The Eclipse Foundation. Eclipse Process Framework 1.0, 2007. Disponvel em http://www.eclipse.org/epf/. The Standish Group, 2005. Disponvel em http://www.standishgroup.com/. The SEGAL Lab, 2006. Disponvel em http://segal.cs.uvic.ca/. Michiel van Genuchten, Cor van Dijk, Henk Scholten, and Doug Vogel. Using group support systems for software inspections. IEEE Software, 18(3):6065, 2001. Edward F. Weller. Lessons from three years of inspection data. IEEE Softw., 10(5):3845, 1993. David H. Withers. Software engineering best practices applied to the modeling process. Simulation Conference Proceedings, 1(1):432439, 2000. Robert Yin. Estudo de Caso: Planejamento e Mtodos. Bookman, 2005.
[SL] [Sny03]
[Sof01]
[Sof05]
[Som04]
[Sou05]
[TEF07]
[TSG05] [TSL06] [vGvDSV01]
[Wel93]
[Wit00]
[Yin05]
138 [Zow02]
Didar Zowghi. Does global software development need a different requirements engineering process? In Procedings of International Workshop on Global Software Development, 2002.
A Este volume foi tipografado em LTEX na classe UFPEThesis (www.cin.ufpe.br/~paguso/ufpethesis).

Proposta de Processo de Documentação e Validação Dos Requisitos para Equipes de Desenvolvimento Distribuído de Software

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Proposta de Processo de Documentação e Validação Dos Requisitos para Equipes de Desenvolvimento Distribuído de Software

Caricato da

Copyright:

Formati disponibili

Universidade Federal de Pernambuco Centro de Informtica

Ps-graduao em Cincia da Computao

Universidade Federal de Pernambuco Centro de Informtica

Leonardo Melo de Medeiros

Alex Sandro Gomes Alexandre Vasconcelos

Recife 29 de agosto de 2007

Trabalhos Relacionados 2.4.1

xvi 2.4.3.1 2.4.4 Concluses

Gravao em udio das Reunies de Validao dos Requisitos 37

Proposta de um processo (4) 3.7.1

4.1.1.3 4.2 4.2.1 4.2.2

Requisitos Extrados da Entrevista Semi-estruturada com os Gerentes de Projeto (F2)

Ferramentas Colaborativas de Edio Observadas no Estudo de Caso

Fases Observadas da Engenharia de Requisitos no Estudo de Caso

Documentao de Requisitos 5.7.4.1 5.7.4.2

Validao dos Requisitos

Requisitos Relacionados Ao Estudo de Caso

Concluso 7.1 Trabalhos Futuros

4.1 4.2 5.1 5.2 5.3

Projetos Pesquisados Legenda dos Entrevistados

Figura 1.1 Principais razes envolvidas no DDS [Pri03]

ou organizaes que so os responsveis pelo sucesso do sistema. [NE00]

Figura 1.2 Demada por software x prossionais disponveis [DZ02]

1.3 ORGANIZAO DA DISSERTAO

As concluses, limitaes identicadas e as sugestes de trabalhos futuros caram no Captulo 7.

Engenharia de Requisitos no Desenvolvimento Distribudo

Desenvolvimento Distribudo de Software

Desaos do Desenvolvimento Distribudo de software

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

2.1 DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE

Figura 2.1 Nveis de interao contextual [MH01]

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

2.3 PROCESSO DE ENGENHARIA DE REQUISITOS BASEADO EM DDS

Processo de Engenharia de Requisitos Baseado em DDS

Figura 2.2 Fases da Engenharia de Requisitos Baseado em [KS98]

processo um conjunto de atividades que transformam entradas em sadas.

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

2.3 PROCESSO DE ENGENHARIA DE REQUISITOS BASEADO EM DDS

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

Figura 2.3 Processo de Inspeo dos Requisitos Baseado em [KS98]

2.3 PROCESSO DE ENGENHARIA DE REQUISITOS BASEADO EM DDS

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

Prototipagem Durante a Engenharia de Requisitos

2.3 PROCESSO DE ENGENHARIA DE REQUISITOS BASEADO EM DDS

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

Processo de Requisitos alinhado com o CMM

Figura 2.4 Processo para Engenharia de Requisitos Distribuda [Lop03]

2.4 TRABALHOS RELACIONADOS

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

2.4 TRABALHOS RELACIONADOS

Suporte Engenharia de Requisitos no Desenvolvimento Distribudo de Software

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

2.4 TRABALHOS RELACIONADOS

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

2.4 TRABALHOS RELACIONADOS

Impacto dos Stakeholders Geogracamente Distribudos na Gerncia de Requisitos em organizaes Multi-Site

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

Figura 2.6 Distribuio geogrca do grupo de stakeholders [DZ02]

2.4 TRABALHOS RELACIONADOS

Figura 2.7 Fluxo de informao no projeto [DZ02]

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO

2.4 TRABALHOS RELACIONADOS

CAPTULO 2 ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DISTRIBUDO