UMA ABORDAGEM I TEGRADA DE DESE VOLVIME TO E …mestrado/diss/2010/leal.pdfy caminar a paso lento, muy lento..." Aos meus pais Gerv asio Leal e Noeli Lapasini, pelo amor incondicional,

GISLAINE CAMILA LAPASINI LEAL

UMA ABORDAGEM I�TEGRADA DE DESE�VOLVIME�TO E TESTE DE SOFTWARE PARA EQUIPES DISTRIBUÍDAS

MARINGÁ

2010



Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientadora: Profa. Dra. Elisa Hatsue Moriya

Huzita

MARINGÁ

2010

Dados Internacionais de Catalogação-na-Publicação (CIP) (Biblioteca Central - UEM, Maringá – PR., Brasil)

Leal, Gislaine Camila Lapasini

L435a Uma abordagem integrada de desenvolvimento e teste de

software para equipes distribuídas. / Gislaine Camila

Lapasini Leal. -- Maringá, 2010.

xvi, 169 f. : il., figs., tabs.

Orientadora : Prof.ª Dr.ª Elisa Hatsue Moriya Huzita.

Dissertação (mestrado) - Universidade Estadual de

Maringá, Programa de Pós-Graduação em Ciência da

Computação, 2010.

1. Software - Desenvolvimento distribuído - Processo. 2.

Software - Desenvolvimento distribuído - Teste. 3.

Desenvolvimento distribuído de software. I. Huzita, Elisa

Hatsue Moriya, orient. II. Universidade Estadual de

Maringá. Programa de Pós-Graduação em Ciência da

Computação. III. Título.

CDD 21.ed. 004.21



Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.

Aprovada em 05/07/2010.

BANCA EXAMINADORA

Profa. Dra. Elisa Hatsue Moriya Huzita Universidade Estadual de Maringá – DIN/UEM

Profa. Dra. Tania Fatima Calvi Tait Universidade Estadual de Maringá – DIN/UEM

Prof. Dr. Paulo Cézar Stadzisz Universidade Tecnológica Federal do Paraná – DAINF/UTFPR

Aos meus pais ...A pessoa especial da minha vida...A Fred Dutra (in memorian)...

i

ii

Agradecimentos

A pessoa especial que apareceu na minha vida e me fez entender que ”Me deberıas esperary caminar a paso lento, muy lento...”

Aos meus pais Gervasio Leal e Noeli Lapasini, pelo amor incondicional, o carinho e aforca...

A professora Dra. Elisa Hatsue Moriya Huzita, minha orientadora, pela paciencia e porter depositado confianca em meu trabalho mais uma vez...

Ao professor Dr. Marcio Eduardo Delamaro (ICMC/USP) pela paciencia, confianca eapoio...

Aos ”irmaos”de mestrado, Cesar Alberto da Silva e Ana Paula Chaves, por sempre estaremao meu lado...

Aos amigos de turma, Shido, Beto, Juliana, Clara e Huff por tudo que dividimos duranteessa jornada...

Ao pessoal do LabES pela recepcao e pelos ensinamentos durante minha estadia em SaoCarlos: Andre Abe (Vica), Gabriel (Ceara), Fabiano, Rodrigo, Vinıcius (Fofo), Katia,Rafael (Frotinha), Adriano (Delinha), Sandro (KLB) e Lucas...

A Marcia Samed pelas infindaveis conversas, conselhos, pelos cafes no fim da tarde, pelastristezas e alegrias que dividimos e, principalmente, pela amizade.

A Thelma Elita Colanzi pelo ombro amigo nos momentos dıficeis que passei, pelas con-tribuicoes no meu trabalho, pelos conselhos, pelas atividades desportivas e, principal-mente, pela amizade...

A Maria Vandete (Negavan) pela amizade, carinho e ensinamentos sobre aquilo querealmente tem valor na vida ...

Ao amigos da Engenharia de Producao, em especial: Heliana Marcia, Olıvia Oiko e EldaSalome...

iii

Aos professores do Departamento de Informatica que de diversas formas contribuıramcom esse trabalho, com a minha formacao academica e tambem pessoal...

A Maria Ines Davanco por sua dedicacao, carinho e simpatia...

A Capes (Coordenacao de Aperfeicoamento de Pessoal de Nıvel Superior), pelo apoiofinanceiro...

A Deus, por ter me dado forcas nos momentos de fraqueza, por colocar pessoas taoespeciais na minha vida. Enfim, por ter me proporcionado todos esses motivos paraagradecer...

iv

Resumo

O Desenvolvimento Distribuıdo de Software (DDS) e uma estrategia de desenvolvi-mento que atende as necessidades da globalizacao no que se refere a produtividade ereducao de custos. No entanto, ele acrescentou novos elementos ao processo de de-senvolvimento, tais como a distancia temporal, dispersao geograficae as diferencassocio-culturais, que amplificaram alguns dos desafios e, sobretudo, acrescentaramnovas exigencias no que diz respeito aos processos de comunicacao, coordenacaoe controle dos projetos. Entre essas novas demandas ha a necessidade de umprocesso de software que ofereca apoio adequado ao desenvolvimento distribuıdo desoftware. Este trabalho apresenta uma abordagem integrada de desenvolvimento eteste de software que aborda as peculiaridades de equipes distribuıdas. O objetivoda abordagem e oferecer suporte a estrategia de desenvolvimento, proporcionandouma melhor visibilidade de um projeto, melhorando a comunicacao entre as equipesde desenvolvimento e teste, minimizando a ambiguidade e a dificuldade em com-preender os artefatos e atividades. Esta abordagem integrada foi concebida fun-damentada em quatro pilares: (i) identificar as peculiaridades do DesenvolvimentoDistribuıdo de Software relacionadas a processos de desenvolvimento e de teste;(ii) definir os elementos necessarios para compor a abordagem integrada de desen-volvimento e teste para apoiar equipes distribuıdas; (iii) descrever e especificar osworkflows, artefatos e papeis da abordagem; e, (iv) representar a abordagem deforma adequada para possibilitar a comunicacao e entendimento efetivo da mesma.A abordagem foi avaliada, seguindo os princıpios da Engenharia Experimental, pormeio da conducao de um estudo de viabilidade.

v

vi

Abstract

The Distributed Software Development (DSD) is a development strategy that meetsthe globalizations needs in relation to productivity and cost reduction. However,it added new elements to the development process, such as the temporal distance,geographical dispersion and the socio-cultural differences, which amplified somechallenges and, especially, added new requirements in relation to the communica-tion process, coordination and control of projects. Among these new demands thereis the necessity of a software process that provides suited support to the distributedsoftware development. This work presents an integrated approach of softwaredevelopment and test that considers the peculiarities of distributed teams. Thegoal of the approach is to offer support to the strategy of development, providinga better visibility of a project, improving the communication between the devel-opment and test teams, minimizing the ambiguity and difficulty in understandingthe artifacts and activities. This integrated approach was conceived based on fourpillars: (i) to identify the peculiarities of Distributed Software Development relatedto development and test processes, (ii) to define the necessary elements to composethe integrated approach of development and test to support the distributed teams,(iii) to describe and specify the workflows, artifacts, and roles of the approach, and(iv) to represent appropriately the approach to enable the effective communicationand understanding of it. The approach was evaluated, using the ExperimentalEngineering principles, by conducting a feasibility study.

vii

viii

Sumario

Lista de Figuras xiii

Lista de Tabelas xvii

1 Introducao 11.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Contexto e Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Descricao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 Solucao Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Organizacao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Revisao Bibliografica 92.1 Desenvolvimento Distribuıdo de Software . . . . . . . . . . . . . . . . . . . 92.2 Processo de Desenvolvimento de Software . . . . . . . . . . . . . . . . . . . 11

2.2.1 Norma ISO/IEC 12207 . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Tecnicas de Modelagem de Processo de Software . . . . . . . . . . . . . . . 132.4 Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.2 Teste Baseado em Modelos . . . . . . . . . . . . . . . . . . . . . . . 192.4.3 Processo de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.4 Norma IEEE 829-1998 . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.5 Metodologia TOTEM (Testing of Object-Oriented Software Sys-

TEms with the UML) . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4.6 Perfil UML2.0 de Teste . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Engenharia Experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.6 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Trabalhos Relacionados 333.1 Processos de Desenvolvimento de Software . . . . . . . . . . . . . . . . . . 33

3.1.1 Rational Unified Process (RUP) . . . . . . . . . . . . . . . . . . . . 333.1.2 eXtreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . 343.1.3 Agile Unified Process (AUP) . . . . . . . . . . . . . . . . . . . . . . 363.1.4 Extended Workbench Model . . . . . . . . . . . . . . . . . . . . . . 363.1.5 Local Agile Game-based Process (LAGPRO) . . . . . . . . . . . . . 37

ix

3.2 Analise Comparativa dos Processos de Desenvolvimento . . . . . . . . . . . 373.3 Processos de Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.1 Teste no RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.2 SiTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.3 Processo CenPRA . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4 Analise Comparativa dos Processos de Teste . . . . . . . . . . . . . . . . . 433.5 Abordagem de Desenvolvimento e Teste de Software . . . . . . . . . . . . . 453.6 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4 Abordagem de Desenvolvimento e Teste de Software para Equipes Dis-tribuıdas 494.1 Visao Geral da Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Abordagem de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1 Disciplina Planejamento . . . . . . . . . . . . . . . . . . . . . . . . 544.2.2 Disciplina Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 604.2.3 Disciplina Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . 654.2.4 Disciplina Implementacao . . . . . . . . . . . . . . . . . . . . . . . 68

4.3 Abordagem de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.3.1 Disciplina Planejamento . . . . . . . . . . . . . . . . . . . . . . . . 724.3.2 Disciplina Preparacao . . . . . . . . . . . . . . . . . . . . . . . . . 754.3.3 Disciplina Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.3.4 Disciplina Execucao . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.4 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5 Exemplo de Aplicacao da Abordagem 895.1 Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.2 Disciplina Planejamento - Desenvolvimento . . . . . . . . . . . . . . . . . . 895.3 Disciplina Planejamento - Teste . . . . . . . . . . . . . . . . . . . . . . . . 935.4 Disciplina Requisitos - Desenvolvimento . . . . . . . . . . . . . . . . . . . 935.5 Disciplina Preparacao - Teste . . . . . . . . . . . . . . . . . . . . . . . . . 955.6 Disciplina Desenvolvimento - Desenvolvimento . . . . . . . . . . . . . . . . 965.7 Disciplina Projeto - Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.8 Disciplina Implementacao - Desenvolvimento . . . . . . . . . . . . . . . . . 1015.9 Disciplina Execucao - Teste . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.10 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6 Estudo de Viabilidade 1076.1 Definicao dos Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.1.1 Objetivo Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.1.2 Objetivo da Medicao . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.1.3 Objetivo do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.1.4 Questoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.2.1 Definicao das Hipoteses . . . . . . . . . . . . . . . . . . . . . . . . . 1086.2.2 Selecao do Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . 108

x

6.2.3 Selecao dos Participantes . . . . . . . . . . . . . . . . . . . . . . . . 1096.2.4 Projeto do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096.2.5 Instrumentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096.2.6 Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.3 Operacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116.3.1 Resultados do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.4 Analise e Interpretacao dos Dados . . . . . . . . . . . . . . . . . . . . . . . 1126.4.1 Validacao dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 1126.4.2 Estatıstica Descritiva e Analise . . . . . . . . . . . . . . . . . . . . 1136.4.3 Aplicacao do Teste Estatıstico . . . . . . . . . . . . . . . . . . . . . 1206.4.4 Verificacao das Hipoteses . . . . . . . . . . . . . . . . . . . . . . . . 124

6.5 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7 Conclusoes 1257.1 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267.2 Dificuldades e Limitacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1287.4 Publicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Referencias Bibliograficas 131

A Protocolo da Revisao Sistematica 139A.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139A.2 Formulacao da Pergunta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139A.3 Selecao das Fontes de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 140A.4 Selecao Preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140A.5 Selecao Final e Extracao dos Dados . . . . . . . . . . . . . . . . . . . . . . 141A.6 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

B Templates Abordagem de Desenvolvimento 143B.1 Plano de Desenvolvimento de Software . . . . . . . . . . . . . . . . . . . . 143B.2 Descricao Extendida Casos de Uso . . . . . . . . . . . . . . . . . . . . . . 143

C Templates Abordagem de Teste 147C.1 Plano de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147C.2 Especificacao de Projeto de Teste . . . . . . . . . . . . . . . . . . . . . . . 148C.3 Especificacao de Casos de Teste . . . . . . . . . . . . . . . . . . . . . . . . 149C.4 Especificacao de Procedimentos de Teste . . . . . . . . . . . . . . . . . . . 149C.5 Diario de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150C.6 Relatorio de Incidentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150C.7 Resumo de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

D Artefatos 153D.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153D.2 Descricao Textual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

xi

D.3 Especificacao dos Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . 154

E Documentacao do Estudo de Viabilidade 161E.1 Memorial Descritivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161E.2 Questionarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

E.2.1 Questionario 1 - Perfil do Entrevistado . . . . . . . . . . . . . . . . 167E.2.2 Questionario 2 - Estudo de Viabilidade . . . . . . . . . . . . . . . . 168

xii

Lista de Figuras

1.1 Metodologia proposta por Mafra (2006). . . . . . . . . . . . . . . . . . . . 41.2 Metodologia de trabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Processos da norma ISO/IEC 12207. . . . . . . . . . . . . . . . . . . . . . 132.2 Elementos estruturais de um processo (OMG, 2005). . . . . . . . . . . . . 152.3 Ciclo de vida de um processo (OMG, 2005). . . . . . . . . . . . . . . . . . 152.4 Diagrama de atividades dos passos da metologia TOTEM (Briand e Labiche,

2001). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5 Arquitetura de Teste (OMG, 2004). . . . . . . . . . . . . . . . . . . . . . . 262.6 Comportamento de teste (OMG, 2004). . . . . . . . . . . . . . . . . . . . . 282.7 Dados de teste (OMG, 2004). . . . . . . . . . . . . . . . . . . . . . . . . . 292.8 Temporizacao de teste (OMG, 2004). . . . . . . . . . . . . . . . . . . . . . 30

4.1 Diagrama de Atividades da Abordagem Integrada de Desenvolvimento eTeste de Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 Diagrama de Atividades da Abordagem de Desenvolvimento. . . . . . . . . 524.3 Diagrama de Pacotes da Abordagem de Desenvolvimento. . . . . . . . . . . 524.4 Diagrama de Pacotes da Disciplina Planejamento. . . . . . . . . . . . . . . 544.5 Diagrama de Pacotes da Definicao de Trabalho - Configurar o processo. . . 554.6 Diagrama de Casos de Uso - Definicao de Trabalho - Configurar o processo. 584.7 Diagrama de Classes - Definicao de Trabalho - Configurar o processo. . . . 594.8 Diagrama de Atividades - Definicao de Trabalho - Configurar o processo. . 604.9 Diagrama de Pacotes da Disciplina Requisitos. . . . . . . . . . . . . . . . . 614.10 Diagrama de Pacotes da Definicao de Trabalho - Definir uma visao do sistema. 614.11 Diagrama de Pacotes da Definicao de Trabalho - Traduzir a visao em modelos. 624.12 Diagrama de Casos de Uso - Definicao de Trabalho - Definir uma visao do

sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.13 Diagrama de Casos de Uso - Definicao de Trabalho - Traduzir a visao em

modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.14 Diagrama de Classes - Definicao de Trabalho - Definir uma visao do sistema. 644.15 Diagrama de Classes - Definicao de Trabalho - Traduzir visao em modelos. 644.16 Diagrama de Atividades - Definicao de Trabalho - Definir uma visao do

sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.17 Diagrama de Atividades - Definicao de Trabalho - Traduzir visao em modelos. 654.18 Diagrama de Pacotes da Disciplina Desenvolvimento. . . . . . . . . . . . . 65

xiii

4.19 Diagrama de Pacotes da Definicao de Trabalho - Especificar descrevendocomo implementar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.20 Diagrama de Casos de Uso - Definicao de Trabalho - Especificar descrevendocomo implementar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.21 Diagrama de Classes - Definicao de Trabalho - Especificar descrevendocomo implementar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.22 Diagrama de Atividades - Definicao de Trabalho - Especificar descrevendocomo implementar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.23 Diagrama de Pacotes da Disciplina Implementacao. . . . . . . . . . . . . . 684.24 Diagrama de Pacotes da Definicao de Trabalho - Implementar os metodos. 694.25 Diagrama de Casos de Uso - Definicao de Trabalho - Implementar as classes

e objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.26 Diagrama de Atividades - Definicao de Trabalho - Implementar as classes

e objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.27 Diagrama de Atividades da Abordagem de Teste. . . . . . . . . . . . . . . 704.28 Diagrama de Pacotes da Abordagem de Teste. . . . . . . . . . . . . . . . . 714.29 Diagrama de Pacotes da Disciplina Planejamento. . . . . . . . . . . . . . . 724.30 Diagrama de Pacotes da Definicao de Trabalho - Configurar o processo. . . 724.31 Diagrama de Casos de Uso - Definicao de Trabalho - Configurar o processo. 734.32 Diagrama de Classes - Definicao de Trabalho - Configurar o processo. . . . 744.33 Diagrama de Atividades - Definicao de Trabalho - Configurar o processo. . 744.34 Diagrama de Pacotes da Disciplina Preparacao. . . . . . . . . . . . . . . . 754.35 Diagrama de Pacotes da Definicao de Trabalho - Planejar atividades de teste. 764.36 Diagrama de Casos de Uso - Definicao de Trabalho - Planejar atividades

de teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.37 Diagrama de Classes - Definicao de Trabalho - Planejar atividades de teste. 784.38 Diagrama de Atividades - Definicao de Trabalho - Planejar atividades de

teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.39 Diagrama de Pacotes da Disciplina Projeto. . . . . . . . . . . . . . . . . . 804.40 Diagrama de Pacotes da Definicao de Trabalho - Detalhar aspectos tecnicos. 804.41 Diagrama de Casos de Uso - Definicao de Trabalho - Detalhar aspectos

tecnicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.42 Diagrama de Classes - Definicao de Trabalho - Detalhar aspectos tecnicos. 824.43 Diagrama de Atividades - Definicao de Trabalho - Detalhar aspectos tecnicos. 834.44 Diagrama de Pacotes da Disciplina Execucao. . . . . . . . . . . . . . . . . 834.45 Diagrama de Pacotes da Definicao de Trabalho - Executar e registrar testes. 844.46 Diagrama de Casos de Uso - Definicao de Trabalho - Executar e registrar

teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.47 Diagrama de Classes - Definicao de Trabalho - Executar e registrar teste. . 864.48 Diagrama de Atividades - Definicao de Trabalho - Executar e registrar teste. 87

5.1 Visao do Negocio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.2 Modelo de Objetos de Negocios. . . . . . . . . . . . . . . . . . . . . . . . . 945.3 Diagrama de Casos de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . 955.4 Descricao da Arquitetura. . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

xiv

5.5 Diagrama de Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.6 Diagrama de Comunicacao - Submissao de Artigos. . . . . . . . . . . . . . 985.7 Diagrama de Sequencia - Submissao de Artigos. . . . . . . . . . . . . . . . 985.8 Interface de Login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.9 Interface da Lista de Eventos. . . . . . . . . . . . . . . . . . . . . . . . . . 1025.10 Interface de Submissao de Artigo. . . . . . . . . . . . . . . . . . . . . . . . 1035.11 Interface do Revisor de Artigo. . . . . . . . . . . . . . . . . . . . . . . . . 1035.12 Interface de Revisao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.1 Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Disciplinas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.2 Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Atividades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.3 Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Artefatos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.4 Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6.5 Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Identificacao das Equipes. . . . . . . . . . . . . . . . . . . . . . 116

6.6 Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Nomenclatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.7 Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x OCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.8 Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Padronizacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.9 Grafico da Relacao Conhecimento em DDS x Conhecimento em Teste xAtividades de Teste ao longo das Disciplinas. . . . . . . . . . . . . . . . . . 120

E.1 Diagrama de Atividades da Abordagem Integrada de Desenvolvimento eTeste de Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

E.2 Diagrama de Pacotes da Disciplina Planejamento. . . . . . . . . . . . . . . 163E.3 Diagrama de Pacotes da Disciplina Planejamento. . . . . . . . . . . . . . . 163E.4 Diagrama de Pacotes da Disciplina Requisitos. . . . . . . . . . . . . . . . . 164E.5 Diagrama de Pacotes da Disciplina Preparacao. . . . . . . . . . . . . . . . 164E.6 Diagrama de Pacotes da Disciplina Desenvolvimento. . . . . . . . . . . . . 165E.7 Diagrama de Pacotes da Disciplina Projeto. . . . . . . . . . . . . . . . . . 166E.8 Diagrama de Pacotes da Disciplina Implementacao. . . . . . . . . . . . . . 166E.9 Diagrama de Pacotes da Disciplina Execucao. . . . . . . . . . . . . . . . . 167

xv

xvi

Lista de Tabelas

2.1 Elementos do SPEM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Analise Comparativa dos Processos . . . . . . . . . . . . . . . . . . . . . . 393.2 Analise Comparativa dos Processos de Teste . . . . . . . . . . . . . . . . . 44

4.1 Papeis na Abordagem de Desenvolvimento . . . . . . . . . . . . . . . . . . 534.2 Papeis na Abordagem de Teste . . . . . . . . . . . . . . . . . . . . . . . . 71

5.1 Plano Global de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 915.2 Plano Local de Desenvolvimento - Site Maringa . . . . . . . . . . . . . . . 925.3 Plano Local de Desenvolvimento - Belo Horizonte . . . . . . . . . . . . . . 925.4 Plano de Teste - versao inicial . . . . . . . . . . . . . . . . . . . . . . . . . 935.5 Plano de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.6 Especificacao de Projeto de Teste . . . . . . . . . . . . . . . . . . . . . . . 995.7 Especificacao de Casos de Teste . . . . . . . . . . . . . . . . . . . . . . . . 995.8 Especificacao de Procedimentos de Teste . . . . . . . . . . . . . . . . . . . 1005.9 Continuacao da Tabela Especificacao de Procedimentos de Teste . . . . . . 1015.10 Diario de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.11 Resumo do Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.1 Resultados do Estudo de Viabilidade . . . . . . . . . . . . . . . . . . . . . 1126.2 Estatıstica Descritiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136.3 Classificacao do Nıvel de Conhecimento do Participante . . . . . . . . . . . 1206.4 Nıvel Esperado que a abordagem contempla as necessidades do DDS. . . . 1216.5 Distribuicao do Grau que o Conjunto de Disciplinas atende as necessidades

do DDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.6 Distribuicao do Grau que o Conjunto de Atividades atende as necessidades

do DDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.7 Distribuicao do Grau que o Conjunto de Artefatos atende as necessidades

do DDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.8 Distribuicao do Grau que a Notacao UML pode amenizar problemas de

comunicacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.9 Distribuicao do Grau que a Identificacao das Equipes pode aumentar a

percepcao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.10 Distribuicao do Grau que a Abordagem Atende as necessidades do DDS. . 1236.11 Distribuicao do Grau que a OCL pode amenizar a ambiguidade. . . . . . . 123

xvii

6.12 Distribuicao do Grau que a Padronizacao de atividades e artefatos podeimpactar na qualidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.13 Distribuicao do Grau em que as atividades de teste ao longo das disciplinaspodem reduzir os problemas de integracao. . . . . . . . . . . . . . . . . . . 123

B.1 Plano de Desenvolvimento de Software Global . . . . . . . . . . . . . . . . 144B.2 Plano de Desenvolvimento de Software Local . . . . . . . . . . . . . . . . . 145B.3 Descricao de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

C.1 Plano de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148C.2 Especificacao de Projeto de Teste . . . . . . . . . . . . . . . . . . . . . . . 149C.3 Especificacao de Casos de Teste . . . . . . . . . . . . . . . . . . . . . . . . 149C.4 Especificacao de Procecimentos de Teste . . . . . . . . . . . . . . . . . . . 150C.5 Diario de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150C.6 Relatorio de Incidentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151C.7 Resumo de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

D.1 Gerenciar acesso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155D.2 Gerenciar evento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156D.3 Submeter artigo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157D.4 Distribuir artigo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157D.5 Revisar artigo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158D.6 Consolidar revisao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

xviii

Lista de Siglas

ADDS: Ambiente de Desenvolvimento Distribuıdo de SoftwareAUP: Agile Unified ProcessCIM: Computational Independent ModelCITM: Computational Independent Testing ModelsCMMI: Capability Maturity Model IntegrationDDS: Desenvolvimento Distribuıdo de SoftwareDiSEN: Distributed Software Engineering EnvironmentGSD: Global Software DevelopmentLAGPRO: Local Agile Game-based ProcessMDA: Model Driven ArchitectureMDD: Model Driven DevelopmentMDT: Model Driven TestOCL: Object Constraint LanguageOMG: Object Management GroupPIM: Platform Independent ModelPITM: Plataform Independent Testing ModelsPML: Process Modelling LanguagePSM: Platform Specific Model - PSMRUP: Rational Unified ProcessSPEM: Software Process Engineering Metamodel SpecificationSUT: System Under TestTBM: Teste Baseado em ModelosTDD: Test-Driven DevelopmentTDF: Tecnica de Descricao FormalTOTEM: Testing of Object-Oriented Software SysTEms with the UMLUML: Unified Modelling LanguageUPM: Unified Process ModelU2TP: UML 2.0 Testing ProfileXP: eXtreme Programming

xix

xx

Capıtulo

1

Introducao

1.1 Consideracoes Iniciais

O processo de software e definido como um conjunto ordenado de atividades para o

gerenciamento, desenvolvimento e manutencao de software, e deve estar alinhado com

as condicoes organizacionais (Fuggetta, 2000).

O Desenvolvimento Distribuıdo de Software (DDS) e uma abordagem para o desen-

volvimento dos projetos de software que vem ao encontro das necessidades da globalizacao,

que sao: aumento de produtividade, melhoria de qualidade e reducao de custos (Herbsleb

et al., 2000). Essa nova configuracao adicionou ao desenvolvimento de software desafios

relacionados as diferencas culturais, dispersoes geograficas, coordenacao e controle, co-

municacao e espırito de equipe, os quais intensificam alguns dos problemas enfrentados

durante o ciclo de vida do projeto.

No cenario atual, vivenciamos uma crescente necessidade de software com qualidade.

Diante disso, muitas formas de melhoria dos processos de desenvolvimento de software sao

utilizadas e diversos artefatos e ferramentas buscam melhorar o desenvolvimento, como a

utilizacao de metodos formais para descrever especificacoes, design e testes (Abdurazik,

2000). Analisando os trabalhos apresentados no Capıtulo 3 foi possıvel observar que os

processos de engenharia de software sao, geralmente, voltados para o desenvolvimento

de projetos coalocados, nao atendendo totalmente as necessidades do desenvolvimento

distribuıdo. E os processos que foram desenvolvidos especificamente para o contexto

de desenvolvimento distribuıdos nao contemplam os elementos basicos de um processo

1

2 1. Introducao

e as peculiaridades dessa abordagem. Assim, os desafios de comunicacao, coordenacao

e controle gerados pelo DDS, decorrentes das distancias fısica e temporal, demandam

processos de desenvolvimento de software que sejam adequados para serem utilizados por

equipes distribuıdas.

O objetivo deste trabalho e apresentar uma abordagem integrada de desenvolvimento

e teste de software que apoie o desenvolvimento distribuıdo de projetos, contemplando

as suas peculiaridades e, com isso, melhorar a comunicacao entre as equipes, minimizar

a ambiguidade nos artefatos e fornecer, aos envolvidos, visibilidade adequada em relacao

aos artefatos e atividades.

1.2 Contexto e Motivacao

Nos ultimos anos pode-se observar que algumas organizacoes descentralizaram suas ativi-

dades de desenvolvimento de software em busca de vantagens competitivas, tais como:

acesso a mao-de-obra qualificada, reducao de custos, avancos na infraestrutura e outros.

Essa distribuicao de atividades em um mesmo paıs ou ate mesmo em paıses diferentes,

caracterizam o DDS.

O principal objetivo dessa descentralizacao consiste em otimizar os recursos para

desenvolver produtos de maior qualidade e a um custo menor. No entanto, essa dispersao

adicionou novos desafios ao desenvolvimento relacionados a comunicacao, coordenacao e

controle, os quais podem afetar negativamente a produtividade e, por conseguinte, a qua-

lidade do software. Esses fatores influenciam a maneira pela qual o software e projetado,

desenvolvido, testado e entregue aos clientes, afetando assim os estagios correspondentes

do ciclo de vida do software. Segundo Damian e Lanubile (2004), para minimizar esses

efeitos e alcancar nıveis mais elevados de produtividade, sao necessarias novas tecnologias,

processos e metodos compatıveis com a abordagem de desenvolvimento distribuıdo.

Em Jimenez et al. (2009) e possıvel observar a evolucao dessa abordagem de desenvolvi-

mento em funcao do aumento de trabalhos disponıveis na literatura. Alem disso, nota-se

que os maiores esforcos estao centrados em processos organizacionais, os quais tratam

dos recursos humanos, gestao organizacional, alinhamento de infraestrutura e gestao de

projetos. Isto evidencia uma lacuna em relacao ao nıvel de projetos e aspectos tecnicos o

que requer novos processos e ferramentas.

Diante deste cenario, este trabalho apresenta a especificacao de uma abordagem in-

tegrada de desenvolvimento e teste de software compatıvel com as necessidades das equipes

distribuıdas.

1.3 Objetivos 3

1.2.1 Descricao do Problema

Os processos de engenharia de software possuem artefatos, responsabilidades e atividades

bem definidas, possibilitando adequacao as necessidades especıficas. No entanto, estes

processos sao, geralmente, voltados para o desenvolvimento de projetos coalocados, nao

considerando as peculiaridades de coordenacao, controle e comunicacao do desenvolvi-

mento com equipes geograficamente dispersas. Rocha et al. (2008) enfatizam a necessidade

de processos adequados a essa estrategia de desenvolvimento. De acordo com (Audy

e Prikladnicki, 2008), em um ambiente de desenvolvimento distribuıdo, e fundamental

um processo de desenvolvimento comum a equipe, visto que auxilia diretamente na

sincronizacao, fornecendo a todos os membros da equipe uma nomenclatura comum de

tarefas e atividades, e um conjunto comum de expectativas aos elementos envolvidos no

processo. Diante de tal cenario observou-se a necessidade de desenvolver uma abordagem

que forneca suporte adequado ao desenvolvimento distribuıdo.

1.2.2 Solucao Proposta

A abordagem integrada de desenvolvimento e teste de software, apresentada nesse tra-

balho, vem ao encontro das necessidades do desenvolvimento distribuıdo. Essa abordagem

objetiva oferecer suporte aos processos de comunicacao, coordenacao e controle fornecendo

uma nomenclatura comum aos envolvidos no que se refere as disciplinas, papeis, atividades

e artefatos. Alem disso, objetiva-se reduzir a ambiguidade e imprecisao dos artefatos com

o uso de uma especificacao mais rigorosa e oferecer visibilidade sobre as disciplinas em

execucao, os envolvidos e suas responsabilidades.

1.3 Objetivos

Para oferecer apoio ao desenvolvimento distribuıdo de software, melhorando a comu-

nicacao entre as equipes de desenvolvimento e teste e minimizando a ambiguidade nos

artefatos, o objetivo geral desta dissertacao e apresentar uma abordagem integrada de

desenvolvimento e teste de software para equipes distribuıdas. Como objetivos especıficos,

tem-se:

∙ identificar as peculiaridades do Desenvolvimento Distribuıdo de Software relacionadas

a processos de desenvolvimento e de teste;

∙ definir os elementos necessarios para compor a abordagem integrada de desenvolvi-

mento e teste para apoiar equipes distribuıdas;

4 1. Introducao

∙ descrever e especificar os workflows, artefatos e papeis da abordagem;

∙ representar a abordagem proposta de forma adequada para possibilitar a comu-

nicacao e entendimento efetivo da mesma.

1.4 Metodologia

A pesquisa conduzida neste trabalho se caracteriza como sendo de base qualitativa e

do tipo exploratoria, sendo uma adaptacao da metodologia proposta por Mafra (2006),

que extende o trabalho de Shull et al. (2001), como pode ser visto na Figura 1.1. Essa

metodologia objetiva possibilitar o desenvolvimento e a maturacao de tecnologias desde

sua concepcao academica ate sua insercao na industria, sendo composta por duas fases,

Definicao e Refinamento.

Durante a fase de Definicao sao conduzidas revisoes sistematicas para identificar

evidencias disponıveis na literatura e deste modo minimizar dificuldades e incertezas no

processo de definicao. Na fase de Refinamento, o foco e coletar evidencias, pontos fortes

e fracos sobre a aplicacao da tecnologia e, baseada nessas evidencias, propor alteracoes e

melhorias. Para isso, e proposta a conducao de estudos de viabilidade, estudos observa-

cionais e estudos de caso, tanto no contexto de um ciclo de vida completo da tecnologia,

como no contexto industrial (Shull et al., 2001).

Figura 1.1: Metodologia proposta por Mafra (2006).

A metodologia utilizada no desenvolvimento deste trabalho e composta por cinco fases,

conforme ilustrado na Figura 1.2. As tres primeiras fases correspondem a fase de Definicao

1.4 Metodologia 5

e a quarta fase a de Refinamento, apresentada por Mafra (2006). A seguir a metodologia

e descrita.

Na primeira fase foi realizada uma revisao inicial da literatura, que teve como objetivo

formar um referencial teorico consistente para a continuidade do estudo e visualizar

o estado da arte. Esta etapa envolveu estudos sobre desenvolvimento distribuıdo de

software, processos de desenvolvimento e teste de software e notacoes para modelagem de

processos.

Figura 1.2: Metodologia de trabalho.

A segunda fase consistiu na conducao de uma revisao sistematica, seguindo o modelo

de protocolo apresentado em (Biolchini et al., 2005). A revisao sistematica foi conduzida

para ampliar a cobertura da revisao de literatura inicial e o objetivo principal foi a iden-

ticacao de trabalhos que abordam processos de software utilizados no desenvolvimento com

equipes distribuıdas. Alem disso, a revisao tambem visou a identificacao das necessidades

dessa abordagem de desenvolvimento no que se refere ao processo de desenvolvimento. A

revisao sistematica possibilitou identificar os processos de desenvolvimento de software que

vem sendo utilizados com equipes distribuıdas. Os estudos selecionados foram, na maior

parte, referentes aos problemas (diversidade cultural, dispersoes geograficas, coordenacao

e comunicacao) encontrados quando da adocao de desenvolvimento distribuıdo, realcando

6 1. Introducao

a necessidade da definicao de um processo que contemple as caracterısticas dessa nova

abordagem de desenvolvimento.

Na terceira fase, Definicao da Abordagem, foi possıvel analisar e definir, com base

nas etapas anteriores, os elementos necessarios para uma abordagem integrada de desen-

volvimento e teste de software que contemple os aspectos relevantes em desenvolvimento

distribuıdo. Apos a identificacao, os elementos da abordagem foram descritos e especifi-

cados de acordo com a tecnica de modelagem definida.

A quarta fase, Avaliacao, consistiu na conducao de um estudo de viabilidade o qual

teve por objetivo criar um corpo de conhecimento sobre a aplicacao da tecnologia e nao

encontrar uma resposta definitiva. Nesse sentido, foi possıvel ao pesquisador avaliar se a

aplicacao da tecnologia e viavel, ou seja, se atende de forma adequada aos objetivos ini-

cialmente definidos, de forma a justificar (ou nao) a continuacao da pesquisa. Alem disso,

o corpo de conhecimento construıdo fornece subsıdios para o refinamento da tecnologia e a

geracao de novas hipoteses sobre sua aplicacao a serem investigadas em estudos posteriores

(Shull et al., 2001). As demais etapas do Refinamento nao foram contempladas no escopo

deste trabalho devido ao tempo disponıvel.

Por fim, a quinta fase, Redacao, consistiu em produzir este documento de dissertacao,

na escrita e submissao de artigos relacionados a este trabalho e na defesa da dissertacao.

1.5 Organizacao do Trabalho

Neste capıtulo foram descritos os objetivos deste trabalho, embasados nos problemas

encontrados durante o desenvolvimento distribuıdo de software no que se refere a pro-

cessos de desenvolvimento e teste de software. Alem disso, foi apresentado o contexto, a

motivacao e a metodologia que norteou o desenvolvimento do mesmo.

O restante deste trabalho encontra-se organizado da seguinte forma:

∙ Capıtulo 2: apresenta os conceitos relevantes que embasaram o desenvolvimento

deste trabalho, sendo eles: desenvolvimento distribuıdo de software, processo de

desenvolvimento, norma ISO/IEC 12207, tecnicas de modelagem de processos, teste

de software, teste baseado em modelos, processo de teste, norma IEEE 829-1998,

metodologia de geracao de casos de testes e perfil UML de teste.

∙ Capıtulo 3: descreve as caracterısticas dos processos de desenvolvimento e teste de

software que deram subsıdios para o desenvolvimento deste trabalho. Alem disso,

sao apresentados alguns criterios de comparacao e tais processos sao analisados

considerando as demandas do desenvolvimento com equipes distribuıdas.

1.5 Organizacao do Trabalho 7

∙ Capıtulo 4: a abordagem proposta e descrita em termos de disciplinas, atividades,

papeis e artefatos. Alem disso, e apresentada a modelagem seguindo o metadomod-

elo SPEM.

∙ Capıtulo 5: ilustra um exemplo de aplicacao da abordagem proposta em um projeto

de desenvolvimento de uma aplicacao web para gerenciar o processo de submissao

e avaliacao de artigos em eventos cientıficos.

∙ Capıtulo 6: apresenta o estudo viabilidade conduzido para coletar os pontos fortes

e fracos da abordagem proposta.

∙ Capıtulo 7: discute as contribuicoes e limitacoes do trabalho e apresenta os trabalhos

futuros.

8 1. Introducao

Capıtulo

2

Revisao Bibliografica

Neste capıtulo sao apresentados os conceitos relevantes que deram subsıdios para o de-

senvolvimento deste trabalho, sendo eles: Desenvolvimento Distribuıdo de Software, pro-

cessos de desenvolvimento, tecnicas de modelagem de processo de software, normas de

referencia, teste de software e engenharia experimental.

2.1 Desenvolvimento Distribuıdo de Software

A crescente globalizacao do ambiente de negocios e da economia, juntamente com o

avanco tecnologico, alta competitividade, aumento do tamanho das equipes, dificuldade

em reunir especialistas e aumento da complexidade do software, tem afetado, diretamente,

o desenvolvimento de software. Em busca de vantagem competitiva, diversas organizacoes

optaram por distribuir o processo de desenvolvimento de software caracterizando o De-

senvolvimento Distribuıdo de Software (DDS) (Huzita et al., 2008).

O DDS pode ser definido como o desenvolvimento de software que utiliza equipes em

varias localizacoes geograficas, com o envolvimento de pessoas de diferentes nacionalidades

e diferentes culturas organizacionais. Segundo Carmel (1999), os projetos de DDS con-

sistem de times trabalhando juntos para atingir objetivos comuns em um mesmo projeto,

porem dispersos geograficamente. Quando a distribuicao desses times atinge dimensoes

globais, o DDS e denominado Desenvolvimento Global de Software (GSD - Global Software

Development).

9

10 2. Revisao Bibliografica

Em um ambiente de DDS a distribuicao pode assumir algumas configuracoes, de acordo

com a distancia entre as equipes e as organizacoes envolvidas no projeto. Em relacao a

distribuicao geografica das unidades envolvidas em um projeto, quando elas se localizam

em mais de um paıs denomina-se distribuicao offshore, se todas se encontram no mesmo

paıs tem-se a distribuicao onshore. Considerando a relacao estabelecida entre as empresas,

tem-se o outsourcing, cenario em que a empresa delega o controle sobre uma ou mais

atividades para uma empresa externa a quem contratou o servico, e o insourcing, em

que as empresas criam os seus proprios centros de desenvolvimento de software. Dessas

configuracoes de distribuicao surgem quatro modelos de negocios, que sao:

∙ onshore insourcing ou demanda domestica interna: neste modelo de negocio existe

um departamento na propria empresa, ou uma subsidiaria no mesmo paıs (onshore),

que prove servico de desenvolvimento de software, atraves de projetos internos

(insourcing);

∙ onshore outsourcing ou outsourcing : este modelo de negocio indica a contratacao

de uma terceira empresa (outsourcing) para o desenvolvimento de determinados

servicos ou produtos de software para uma empresa. A empresa terceira esta

localizada no mesmo paıs da empresa contratante (onshore);

∙ offshore outsourcing ou offshoring : este modelo de negocio indica contratacao de

uma empresa terceira (outsourcing) para o desenvolvimento de determinados servicos

ou produtos de software, sendo que a empresa terceirizada esta, necessariamente,

localizada em um paıs diferente da contratante (offshore);

∙ offshore insourcing ou internal offshoring : este ultimo modelo de negocio indica a

criacao de uma subsidiaria da propria empresa para prover servicos de desenvolvi-

mento de software (insourcing). Esta subsidiaria esta necessariamente localizada

em um paıs diferente da matriz da empresa, ou empresa contratante (offshore).

Essa configuracao de desenvolvimeto de software, o DDS, acrescentou novos fatores ao

processo, tais como, distancia temporal, dispersao geografica, diferencas socio-culturais,

os quais amplificaram alguns dos desafios existentes na area de engenharia de software e

adicionaram novas demandas que desafiam os processos de comunicacao, coordenacao

e controle dos projetos (Layman et al., 2006). Diversos trabalhos ((Damian, 2002),

(Herbsleb et al., 2000), (Mockus e Herbsleb, 2001), (Sangwan et al., 2006)) descrevem tais

desafios, os quais podem ser relacionados a fatores tecnicos (problemas de conectividade

em rede e diferencas entre os ambientes de desenvolvimento e teste) e nao tecnicos

(confianca, comunicacao, conflitos e cultura).

2.2 Processo de Desenvolvimento de Software 11

De acordo com Mockus e Herbsleb (2001) e Damian (2002), os principais desafios

encontrados no DDS estao relacionados as diferencas culturais, dispersoes geograficas,

coordenacao e controle e comunicacao. A diversidade cultural implica dificuldades de

compreensao da linguagem natural utilizada nos documentos de requisitos e a convergencia

entre diferentes interesses (Layman et al., 2006). E as distancias geograficas agravam os

problemas de coordenacao e controle, de forma direta ou indireta, por meio dos efeitos

negativos que causam na comunicacao (Hargreaves e Damian, 2004).

A dispersao geografica dificulta a possibilidade de se estabelecer e manter relaciona-

mentos interpessoais, os quais sao essenciais para a construcao de um espırito de equipe.

Alem disso, enfrentam dificuldades para chegar a um consenso sobre as praticas de

comunicacao e processo de desenvolvimento que devem ser adotados no projeto.

A comunicacao e o fator de mediacao que afeta diretamente a coordenacao e o controle.

Ela representa a troca de informacoes nao ambıguas e completas, isto e, o emissor e o

receptor conseguem chegar a um entendimento comum. Segundo Herbsleb et al. (2000),

a comunicacao informal exerce um papel chave no sucesso das equipes distribuıdas, pois

e considerada o componente essencial de todas as praticas de colaboracao no processo de

desenvolvimento de software. A comunicacao ineficiente pode resultar em um baixo nıvel

de confianca entre as equipes e na perda da visibilidade sobre o andamento dos trabalhos

(Layman et al., 2006).

A coordenacao consiste no ato de integrar cada atividade com cada unidade organiza-

cional. A conducao da integracao, geralmente, requer comunicacao intensa e constante.

O controle e o processo de adesao aos objetivos, polıticas, padroes e nıveis de qualidade.

Mockus e Herbsleb (2001) relatam que as questoes de coordenacao e controle se tornam

um problema quando as equipes distribuıdas utilizam processos diferentes e ressaltam

a necessidade de um processo padrao. A Secao 2.2 descreve os conceitos de processo e

destaca sua importancia.

2.2 Processo de Desenvolvimento de Software

Um processo de software pode ser definido como um conjunto coerente de polıticas, estru-

turas organizacionais, tecnologias, procedimentos e artefatos necessarios para conceber,

desenvolver, implantar e manter um produto de software (Fuggetta, 2000). Envolve uma

serie de etapas constituıdas por um conjunto de atividades, metodos, praticas e tecnologias

que sao utilizadas desde o desenvolvimento ate a manutencao do software e produtos

relacionados.


Um processo pode ser imaturo e utilizar uma abordagem ad hoc para organizar o

trabalho, ou maduro, sendo caracterizado por um metodo padronizado e documentado,

que ja tenha sido utilizada em projetos similares ou, que seja, habitualmente, adotada em

uma organizacao.

Segundo Berger (2003), o uso de um processo padrao permite aos gerentes de projeto

definir planos em conformidade com os padroes de qualidade e procedimentos da orga-

nizacao. Uma equipe de desenvolvimento que trabalha sem um processo bem definido

acaba funcionando de maneira ad hoc, o que compromete o seu sucesso, criando uma

situacao insustentavel. Por outro lado, organizacoes maduras empregando um processo

bem definido podem desenvolver sistemas complexos de maneira consistente e previsıvel,

independente de quem o produziu (Kruchten, 2003).

Alem disso, o processo deve possibilitar a melhoria da qualidade de servico, de en-

genharia e de projeto; a diminuicao de custos por meio do aumento da previsibilidade

e capacidade de mitigar riscos, bem como a melhoria da eficiencia e produtividade da

organizacao.

2.2.1 Norma ISO/IEC 12207

A norma ISO/IEC 12207 propoe uma arquitetura de alto nıvel para o ciclo de vida de

software por meio da definicao de processos, atividades e tarefas que podem ser aplicadas

na aquisicao, no fornecimento, no desenvolvimento, na operacao e na manutencao de

software. Cada processo e composto por atividades, e cada uma destas possui um grupo

de tarefas associadas.

A ISO/IEC 12207 define 17 processos, os quais estao classificados em: processos

fundamentais, processos de apoio e processos organizacionais. Os processos estabelecidos

pela norma podem ser visualizados na Figura 2.1.

Os processos fundamentais compreendem os processos envolvidos na execucao do

desenvolvimento, operacao e manutencao do software durante o ciclo de vida, alem da

contratacao entre cliente e fornecedor. Os processos de apoio colaboram com o sucesso e

a qualidade do projeto de software. Os processos organizacionais sao empregados por uma

organizacao para estabelecer e implementar uma estrutura constituıda pelos processos do

ciclo de vida e pelo pessoal envolvido no desenvolvimento de software.

2.3 Tecnicas de Modelagem de Processo de Software 13

Figura 2.1: Processos da norma ISO/IEC 12207.

2.3 Tecnicas de Modelagem de Processo de Software

O modelo de um processo de software e a representacao formal dos elementos e carac-

terısticas envolvidos neste processo. Segundo Ben-Shaul e Kaiser (1994), um modelo de

processo deve especificar os pre-requisitos e consequencias de cada tarefa, bem como a

sincronizacao entre as mesmas.

A modelagem de um processo de software deve ser conduzida de modo a possibilitar o

entendimento e a padronizacao do processo. Humphrey e Kellner (1989) ressaltam que a

representacao do processo possibilita a comunicacao e o entendimento efetivo do processo,

facilita o reuso, apoia a evolucao, facilita o gerenciamento do processo e e importante na

avaliacao, evolucao e melhoria contınua do processo.

A estrutura de um modelo de processo de software e, geralmente, composta por quatro

elementos:

∙ Ator: representa as entidades que executam um processo ou assumem um papel

durante a execucao de uma tarefa;

∙ Papel: grupo de responsabilidades que executam uma atividade especıfica do pro-

cesso de software;

∙ Artefato: porcao representativa de informacao do produto que resulta de uma

atividade e pode ser utilizado posteriormente como materia-prima para gerar novos

artefatos;


∙ Atividade: consome artefatos (de entrada) e gera novos artefatos (de saıda).

A modelagem de processos de software iniciou-se com o uso de tecnicas de analise

de sistemas, como a utilizacao de diagramas do paradigma estruturado para representar

o processo. Posteriormente, surgiram as linguagens de modelagem de processos (PML -

Process Modelling Language), que agregam os diversos elementos (ator, papel, artefato e

atividade) utilizados nas formas de modelagem anteriores.

Uma PML e uma descricao computacional, que pode ser formal, semi-formal ou

informal, de um processo externo. Ela expressa os processos de producao do software

na forma de um modelo de processo.

Em 2000, a OMG (Object Management Group) apresentou o UPM (Unified Process

Model) como uma proposta de unificacao entre as diferentes metodologias para modelagem

de processos. A evolucao do UPM deu origem ao SPEM (Software Process Engineering

Metamodel Specification), um metamodelo proposto pela OMG para a descricao de um

processo concreto de desenvolvimento de software ou uma famılia relacionada de processos

de desenvolvimento de software. Sua notacao e baseada na UML e, por este motivo,

oferece para a modelagem de processo os mesmos diagramas que sao usados para modelar

software.

Os principais elementos estruturais do SPEM, para a descricao de um processo, e

seus relacionamentos sao mostrados na Figura 2.2. Um Produto de Trabalho, tambem

chamado de Artefato, e toda informacao produzida, consumida ou modificada por um

processo. Um Tipo de Produto de Trabalho descreve uma categoria para os artefatos. A

Definicao de Trabalho e um tipo de operacao que descreve o trabalho executado em um

processo. Atividade e a principal subclasse da Definicao de Trabalho e descreve uma parte

de trabalho executado por um Papel no Processo. Uma Atividade pode ser constituıda

por um conjunto de elementos atomicos, os Passos. O Executor no Processo define um

executor para um conjunto de Definicoes de Trabalho em um processo e apresenta uma

especializacao chamada Papel no Processo, que define responsabilidades sobre artefatos

especıficos e define os papeis que executam ou auxiliam em atividades especıficas.

Em um processo, as atividades com temas comuns podem ser agrupadas em Disci-

plinas. A OMG define alguns elementos que auxiliam na definicao de como o processo

sera executado. Na Figura 2.3 sao ilustrados os elementos que compoem o ciclo de vida

de um processo.

Sob a perspectiva da execucao, um processo e visto como uma colaboracao entre

papeis para alcancar determinada meta ou objetivo. Para guiar esta execucao, pode-se

considerar as restricoes para ser a ordem em que as atividades devem ser executadas,

chamadas de pre-condicoes. Fase e uma especializacao da Definicao de Trabalho tal que

2.3 Tecnicas de Modelagem de Processo de Software 15

Figura 2.2: Elementos estruturais de um processo (OMG, 2005).

Figura 2.3: Ciclo de vida de um processo (OMG, 2005).

sua pre-condicao define os criterios de entrada da fase. Os criterios de saıda da fase

sao suas metas, os chamados milestones. Ciclo de Vida e definido como uma sequencia

de Fases que buscam uma meta especıfica. Iteracao e uma Definicao de Trabalho com

milestones menores.

Alguns elementos do SPEM podem ser representados graficamente por meio de ıcones

(Tabela 2.1), outros existem apenas como metainformacao, nao possuindo uma repre-

sentacao grafica.


Tabela 2.1: Elementos do SPEM.Estereotipo Descricao NotacaoProduto de Trabalho Descricao de um pedaco de informacao gerada ou con-

sumida pelas atividades do processo, como por exemplo:modelos, planos, codigos executaveis, documentos, entreoutros.

Definicao de Trabalho Descreve a execucao, as operacoes desempenhadas e astransformacoes realizadas, por papeis, em um Produto deTrabalho. Alguns exemplos de Definicao de Trabalho sao:atividade, iteracao, fase e ciclo de vida.

Orientacao Apresenta informacoes adicionais, tais como: templates,tecnicas, procedimentos, padroes e exemplos.

Atividade Descreve ”o que”um Papel executa no Processo.

Papel no Processo Descreve os papeis, responsabilidades e competencias de umindivıduo que realiza Atividades dentro de um Processo.

Executor no Processo Descreve os proprietarios das Definicoes de Trabalho.Sao usados para Definicoes de Trabalho que nao podemassociar-se com os Papeis no Processo, tais como um Ciclode Vida ou uma Fase.

Disciplina Agrupamento de atividades comuns de um processo, comopor exemplo: requisitos, analise, projeto e gerenciamentode configuracao entre outras.

Fase Definicao de Trabalho de alto nıvel, limitada por ummilestone.

Processo Descricao completa do processo, em termos de Executoresdo Processo, Papeis no Processo, Definicoes de Trabalho,Produtos de Trabalho e Orientacoes associadas

Documento Tipo de Produto de Trabalho.

Modelo UML Tipo de Produto de Trabalho

2.4 Teste de Software 17

2.4 Teste de Software

O crescimento do uso de software e o aumento de complexidade, tamanho, heterogenei-

dade, autonomia, distribuicao fısica e dinamismo de sistemas computacionais afetam

diretamente a qualidade destes sistemas. Neste cenario, o teste de software adquire cada

vez mais importancia, pois tem como objetivo principal detectar a presenca de defeitos

o mais cedo possıvel, nao somente no codigo-fonte, mas tambem nos documentos de

requisitos e projeto. Visando atingir este objetivo, o teste deve ser planejado e projetado

de modo a definir formas de execucao do programa que tenha uma alta probabilidade de

revelar defeitos no software (Myers, 2001).

Como objetivo secundario o teste fornece uma boa indicacao de confiabilidade e alguns

indıcios da qualidade do software como um todo. A obtencao desta indicacao e possıvel

porque o teste, quando nao detecta a presenca de defeitos, demonstra que as funcoes

do software estao, aparentemente, funcionando de acordo com as especificacoes e que os

requisitos de desempenho foram, aparentemente, cumpridos.

A atividade de testes contribui para o aumento da qualidade do produto final. No

entanto, assim como diversas outras atividades do processo de desenvolvimento de soft-

ware, possui problemas que precisam ser evitados durante a sua realizacao para garantir

o seu sucesso. Mats (2001) destaca os cinco principais problemas associados aos testes

em software, sendo eles:

∙ atrasos no cronograma do projeto, impossibilitando a equipe de completar os testes

planejados devido a reducao de recursos e tempo;

∙ carencia na rastreabilidade de casos e procedimentos de teste entre diferentes versoes

do software, o que dificulta a reutilizacao;

∙ teste manual ou nao-padronizado, resultando em um grande esforco a cada inıcio de

uma nova atividade de teste;

∙ incerteza sobre o que esta sendo testado, devido a falta de definicao dos objetivos e

escopo para as atividades de teste;

∙ ausencia de criterios para a selecao do conjunto de casos e procedimentos de testes.

Segundo Juristo et al. (2004), teste de software e considerada uma das praticas mais

custosas do processo de desenvolvimento e desta forma, necessita um bom gerenciamento

a fim de evitar desperdıcios de recursos e atrasos no cronograma, dentre outras possi-

bilidades. Com isso, a realizacao de testes em software requer recursos adequados, e a


utilizacao efetiva desses recursos necessita de um bom planejamento e controle (McGregor

e Sykes, 2001).

2.4.1 Conceitos

Essa secao descreve os principais termos e expressoes utilizados na area de teste de

software, sendo eles (Delamaro et al., 2007):

∙ Criterio de teste: metodo ou diretriz que serve para direcionar a atividade de teste

e/ou tomar decisoes relativas ao teste. Um criterio de teste define um conjunto de

condicoes que devem ser utilizadas na atividade de teste;

∙ Sistema em teste (SUT - System Under Test): parte ou todo sistema, subsistema

ou componente em teste, que funciona como uma caixa-preta que somente pode

ser exercitada pela estrutura de teste por meio das operacoes disponıveis em sua

interface publica;

∙ Cenario de teste: colecao de casos de teste reunida com a configuracao de teste. Os

casos de teste sao executados com base no cenario de teste;

∙ Ambiente de teste: descricao do ambiente de hardware e software no qual os testes

sao executados e a descricao de qualquer software com que o sistema em teste

interage quando testado usando dispositivos de teste ou stubs, que sao esqueletos

ou implementacoes com proposito especial de um modulo de software;

∙ Conjunto de teste: colecao de um ou mais casos de teste de um sistema em teste. O

caso de teste e o conjunto de dados de entrada, condicoes de execucao e resultados

esperados elaborados para atingir um objetivo especıfico de teste, tal como exercitar

um fluxo do programa ou verificar a conformidade com um requisito especıfico;

∙ Objetivo de teste: conjunto de caracterısticas de um software a serem medidas em

condicoes especıficas pela comparacao do comportamento atual com o comporta-

mento requerido descrito na documentacao do software;

∙ Dado de teste: dado enviado ao sistema em teste. Frequentemente, corresponde

ao dado de entrada fornecido a interface publica do sistema em teste durante a

execucao do caso de teste;

∙ Oraculo de teste: mecanismo usado para gerar o resultado esperado de um caso de

teste. Este resultado e confrontado com o resultado real obtido pela execucao do


sistema em teste. O resultado observado e o dado que reflete a reacao do sistema em

teste a um dado de teste. Corresponde comumente ao dado de saıda (ou retorno)

de uma funcao em teste presente na interface publica de um sistema.

∙ Laudo de teste: registro da interacao resultante da execucao de um caso de teste.

Esta associado a um veredito que indica o grau de conformidade do sistema em teste

com o objetivo definido por um caso de teste. O veredito e a sentenca conferida ao

sistema em teste indicando a sua corretude ou nao.

Existem varias tecnicas de teste que podem ser utilizadas para a selecao de subcon-

juntos de dados de teste. Cada uma destas tecnicas possui caracterısticas proprias que

tornam sua aplicacao mais indicada a diferentes etapas de teste.

As tecnicas de teste sao agrupadas em classes de tecnicas similares, dependendo de

suas caracterısticas. As principais tecnicas de teste de software sao: teste estrutural, teste

funcional e teste baseado em erros. As aplicacoes dessas tecnicas detectam a presenca de

defeitos de categorias distintas, uma vez que elas contemplam diferentes perspectivas

do software. Deste modo, impoe-se a necessidade de se estabelecer uma estrategia de

teste que contemple as vantagens e os aspectos complementares de cada uma das classes,

levando a uma atividade de teste de boa qualidade, eficaz e de baixo custo.

O teste estrutural ou teste de caixa branca, estabelece os elementos requeridos com

base na implementacao, solicitando a execucao de partes e/ou componentes elementares

do programa. Essa tecnica verifica a estrutura interna do programa.

O teste funcional, conhecido como teste de caixa preta ou teste comportamental,

estabelece os elementos requeridos com base na especificacao, sem se preocupar com

os detalhes da implementacao. Por meio da realizacao do teste funcional, o software

ou o sistema e tratado como uma caixa preta. Ele e executado com determinadas

entradas e suas saıdas sao verificadas em relacao ao comportamento definido por meio da

especificacao de software. O testador deve estar preocupado somente com a funcionalidade

e com caracterısticas do software.

O teste baseado em erros utiliza informacoes sobre os tipos de erros mais frequentes

para derivar os requisitos de teste.

2.4.2 Teste Baseado em Modelos

O Teste Baseado em Modelos (TBM) e uma tecnica de teste funcional que utiliza in-

formacoes sobre o comportamento funcional do software para a realizacao do teste. Esse


comportamento e descrito por meio de um modelo, denominado modelo comportamental,

o qual e construıdo a partir dos requisitos funcionais do software.

Os modelos comportamentais determinam, basicamente, quais sao as possıveis acoes

durante a execucao de um software e quais sao as saıdas esperadas. Segundo Dalal et

al. (1999), o desenvolvimento de especificacoes na forma de modelos, mesmo se realizado

em fase avancada no processo de software, e um meio efetivo de: descobrir defeitos no

sistema, ja que muitos se tornam visıveis simplesmente pela propria modelagem; definir

rapidamente a base para os cenarios de uso do sistema; e preservar esse investimento para

versoes futuras ou sistemas similares.

Offutt et al. (2003), destacam que a modelagem e um meio muito economico para se

capturar o conhecimento sobre um sistema e depois reutiliza-lo a medida que o sistema

cresce. Um benefıcio em especificar os requisitos do sistema na forma de um modelo

comportamental e usar esse modelo no teste de software e que os casos de teste podem

ser criados no inıcio do processo de desenvolvimento do software e estarem prontos para

execucao antes que o programa esteja completamente implementado. Adicionalmente, o

testador geralmente encontrara inconsistencias e ambiguidades nos modelos quando os

testes forem gerados, permitindo que a especificacao seja melhorada antes do programa

ser escrito.

Nesse contexto, o TBM surge como uma abordagem aplicavel para controlar a quali-

dade do software, assim como reduzir os custos associados ao processo de testes, visto que

casos de teste podem ser gerados a partir da especificacao do software, paralelamente

ao seu desenvolvimento, utilizando procedimentos automaticos que podem ser menos

suscetıveis a erros. Ele pode gerar melhorias nas atividades de teste por meio da simpli-

ficacao do seu planejamento, da semi-automacao de suas atividades, e controle, a partir

da gerencia dos testes e possibilidade de re-execucao automatica apos modificacoes.

Segundo El-Far e Whittaker (2001), as vantagens de utilizar teste baseado em mode-

los sao: comunicacao entre desenvolvedores e testadores; geracao automatica de testes;

atualizacao da suıte de testes. No que se refere a comunicacao, uma vez que existe um

modelo do comportamento da aplicacao, entao este pode ser utilizado como a base de

comunicacao entre testadores e desenvolvedores. Com o modelo do comportamento da

aplicacao, a geracao de casos de teste pode ser facilmente automatizada. E quanto a

atualizacao, uma vez alterado o modelo, facilmente pode ser feita a atualizacao da suıte

de teste. Como desvantagem, os autores destacam a necessidade de conhecimento da

notacao do modelo. O testador deve estar familiarizado com a notacao que sera utilizada,

o que culmina na demanda de tempo e investimento em treinamentos, alem do tempo que


deve ser reservado para a obtencao do modelo. Outra desvantagem e a dependencia da

existencia do modelo, uma vez que toda essa abordagem parte do modelo construıdo.

Utilizando o TBM a especificacao de testes pode ser realizada informalmente atraves

de linguagens naturais associadas ou nao a tabelas de estados ou diagramas de transicoes.

Essas especificacoes informais tendem a ser ambıguas e de difıcil analise. Para conferir

uma maior precisao e confiabilidade foram elaboradas as Tecnicas de Descricao Formal

(TDFs), que possuem um embasamento matematico que assegura a descricao de uma

maneira precisa, a qual pode ser submetida a analise e a validacao das propriedades

requeridas.

De acordo com Mantovan (2006), uma especificacao por meio de uma TDF deve apre-

sentar as seguintes propriedades: ser clara, concisa e sem ambiguidades; ser completa, sem

omitir nenhum detalhe; ser consistente; e, ser tratavel, o que significa que a especificacao

pode ser submetida a analise para verificacao e validacao de suas propriedades.

Na literatura sao encontradas diversas tecnicas de modelagem, formais e semi-formais,

que podem ser utilizadas com o Teste Baseado em Modelos, sendo elas: Maquina de

Estados Finitos, Statecharts, Redes de Petri, SDL, Estelle e UML. Tais tecnicas sao

descritas em ((Mantovan, 2006), (Cartaxo, 2006), (Fantinato, 2002)).

2.4.3 Processo de Teste

A concepcao tradicional do processo de teste, como sendo uma fase final e independente

do processo de desenvolvimento propriamente dito, tem se mostrado bastante ineficiente

devido aos altos custos associados com a correcao de erros encontrados e manutencao do

software. Tal fato contribuiu para a definicao de metodos e tecnicas sistematicas de teste

que fazem do processo de teste, um conjunto de tarefas a parte que pode ser aplicado ao

longo do processo de desenvolvimento (McGregor e Sykes, 2001).

Um processo de testes possui caracterısticas proprias em relacao ao processo de de-

senvolvimento dentro de um projeto de software. A aplicacao de testes desde a concepcao

ate a implantacao do sistema viabiliza a identificacao e correcao de defeitos tao logo eles

sejam percebidos, evitando assim, o acumulo e o provavel encadeamento dos mesmos.

Uma especificacao mal concebida pode originar um sistema com funcionalidades distintas

das esperadas pelo usuario ou, ate mesmo, ausentes. Uma analise mal elaborada pode

resultar numa arquitetura que nao permita atender determinados criterios de qualidade.

Um projeto mal construıdo pode comprometer a evolucao do software. Uma codificacao

mal feita pode ocasionar falhas de execucao. Tais problemas revelam a necessidade de


disciplina na conducao de testes de um software a fim de identificar, tao cedo quanto

possıvel, os defeitos nele existentes.

Em (Crespo et al., 2004) e ressaltada a necessidade de se utilizar uma metodologia

que possibilite a interacao das atividades de teste a partir do inıcio das especificacoes e

que se estenda durante a construcao do software ate a entrega do sistema. Com isso, e

possıvel obter melhorias drasticas na eficacia e eficiencia dos testes e, consequentemente,

aumentar a qualidade do software.

De acordo com McGregor e Sykes (2001), um processo de teste deve responder as

seguintes questoes:

∙ Quais partes do software serao testadas? Todos os componentes do software serao

testados ou somente partes crıticas e de alto risco?

∙ Como os testes serao realizados? Quais os criterios e tecnicas para realizacao dos

testes?

∙ Quem realizara os testes? Quem sera responsavel pelo planejamento dos testes? E

pela execucao dos testes?

∙ Quando os testes serao realizados? Em que momento do processo de desenvolvi-

mento os testes serao executados?

∙ Onde os testes serao realizados? Em qual ambiente e qual a configuracao do

ambiente os testes ocorrerao?

∙ Qual a quantidade de testes adequada? Como decidir o que testar e quando finalizar

os testes considerando os recursos limitados para a atividade?

O processo de teste deve basear-se em uma metodologia aderente ao processo de

desenvolvimento, em pessoal tecnico qualificado, em ambiente e ferramentas (McGregor

e Sykes, 2001).

O aperfeicoamento das atividades de teste, em termos de maior automacao, melhor

integracao e aproveitamento das praticas de desenvolvimento de software, deve contribuir

nao apenas para a melhoria da qualidade dos produtos, mas tambem para propiciar

condicoes que garantam que as organizacoes melhorem seus processos e os instanciem

de forma correta.


2.4.4 Norma IEEE 829-1998

Independentemente do processo de software utilizado durante o desenvolvimento, existem

artefatos diretamente relacionados a atividade de teste. A norma IEEE 829 [IEEE829-98]

agrupa diversas solucoes, apresenta algumas boas praticas na area e tem como proposta

descrever um conjunto basico de documentos de teste de software. Na norma sao definidos

oito documentos, sendo eles (Crespo et al., 2004):

∙ Plano de Teste: apresenta o planejamento para execucao do teste, incluindo a

abrangencia, abordagem, recursos e cronograma das atividades de teste. Identifica

os itens e as funcionalidades a serem testadas, as tarefas a serem realizadas e os

riscos associados com a atividade de teste;

∙ Especificacao de Projeto de Teste: refina a abordagem apresentada no Plano de

Teste e identifica as funcionalidades e caracterısticas a serem testadas pelo projeto

e por seus testes associados. Este documento tambem identifica os casos e os

procedimentos de teste, se existirem, e apresenta os criterios de aprovacao;

∙ Especificacao de Caso de Teste: define os casos de teste, incluindo dados de entrada,

resultados esperados, acoes e condicoes gerais para a execucao do teste;

∙ Especificacao de Procedimento de Teste: especifica os passos para executar um

conjunto de casos de teste;

∙ Diario de Teste: apresenta registros cronologicos dos detalhes relevantes relacionados

a execucao dos testes;

∙ Relatorio de Incidente de Teste: registra qualquer evento que ocorra durante a

atividade de teste e que requeira analise posterior;

∙ Relatorio-Resumo de Teste: sumariza os resultados das atividades de teste associa-

das com uma ou mais especificacoes de projeto de teste e prove avaliacoes baseadas

nesses resultados;

∙ Relatorio de Encaminhamento de Item de Teste: identifica os itens encaminhados

para teste no caso de equipes distintas serem responsaveis pelas tarefas de desen-

volvimento e de teste.


2.4.5 Metodologia TOTEM (Testing of Object-Oriented Software

SysTEms with the UML)

A metologia TOTEM tem por objetivo apoiar a derivacao dos requisitos de teste funcionais

a partir de artefatos UML. Os artefatos utilizados sao: diagramas e descricoes de casos

de uso, diagramas de interacao e diagramas de classe. Na Figura 2.4 e apresentado o

diagrama de atividades da metologia TOTEM.

Figura 2.4: Diagrama de atividades dos passos da metologia TOTEM (Briand e Labiche,2001).

No passo 1 os artefatos sao verificados para garantir que estes sao testaveis. Apos

essa verificacao, os requisitos de teste sao derivados a partir dos artefatos especificados,

percorrendo os passos de 2 a 5. No passo 6 os requisitos sao fundidos em um unico

conjunto de requisitos de teste, gerando o plano de teste. Por fim, sao executados os

passos 7 e 8 em que sao derivados os casos de teste e os codigos para os oraculos. Para

a geracao dos requisitos de teste sao utilizados os passos 2, 3 e 5, os quais sao descritos

como segue (Briand e Labiche, 2001):

∙ Derivacao das sequencias de casos de uso: os casos de uso possuem restricoes

e dependencias em relacao a sua execucao, o que significa que eles devem ser

executados em uma determinada ordem. A ordem de execucao e as dependencias


dos casos de uso podem ser visualizadas atraves do diagrama de atividades e da

descricao estendida do caso de uso. Para obter a sequencia dos casos de uso basta

percorrer os caminhos do diagrama de atividades.

∙ Derivacao dos requisitos de teste a partir do diagrama de sequencia: O diagrama

de sequencia e reescrito como uma expressao regular e as condicoes para que um

determinado caminho no diagrama de sequencia seja habilitado sao escritas em OCL

(Object Constraint Language). Essas condicoes sao obtidas a partir das condicoes

associadas aos caminhos do diagrama de sequencia. Em seguida, devem ser identi-

ficadas as sequencias das operacoes que serao executadas

∙ Derivacao das sequencias variantes: a partir das sequencias de casos de uso sao

geradas as sequencias variantes. Uma sequencia variante corresponde a um conjunto

de condicoes que devem ser satisfeitas para que cada sequencia do caso de uso possa

ser testada.

2.4.6 Perfil UML2.0 de Teste

A linguagem UML se desenvolveu como foco principalmente na definicao da estrutura de

sistemas e de seu comportamento. No entanto, com a evolucao de abordagens baseadas

em modelos, por exemplo arquitetura dirigida a modelos (MDA), surgiu a necessidade

de integracao de atividades de teste de conformidade. Essa integracao deveria permitir a

especificacao de modelos que capturassem as informacoes necessarias para realizar testes

do tipo caixa-preta em implementacoes do sistema.

Para integrar a atividade de teste e modelos de sistema, foi desenvolvido pela OMG o

Perfil UML 2.0 de Testes (U2TP - UML 2.0 Testing Profile), que define uma linguagem

para projetar, visualizar, especificar, analisar, construir e documentar os artefatos de teste

de sistemas (OMG, 2004).

O U2TP e uma linguagem de modelagem de testes que pode ser usada com tecnologias

de componentes e linguagens orientadas a objeto, aplicadas em diversos domınios de

aplicacao. Em sua concepcao foram utilizados dois princıpios de projeto: Integracao com

UML e Reuso.

A integracao com a UML refere-se ao fato de o perfil ser baseado no meta-modelo

UML, desse modo usa os mesmos princıpios e elementos dessa linguagem. O reuso esta

relacionado ao uso, onde possıvel, dos conceitos e elementos ja presentes em UML.

O perfil foi projetado para apoiar o teste de implementacoes de sistema de maneira efi-

ciente e tao automatizada quanto possıvel, tendo como foco o teste funcional caixa-preta.


O sistema sob teste (SUT) nao e especificado como parte dos diagramas descritos usando

U2TP: os elementos sao importados a partir do modelo completo. O SUT e acessado a

partir de suas interfaces publicas. No entanto, se o modelo de sistema define e oferece

acesso a interfaces de subsistemas e componentes internos, esses tambem podem ser

acessados em um teste: cada componente pode ser considerado um SUT menor, de escopo

mais restrito, o que possibilita a descricao usando U2TP de testes em todos os nıveis.

U2TP define apenas uma linguagem, e nao um metodo. Deste modo, os usuarios do

perfil ficam livres para definir metodologias proprias, adaptadas as suas necessidades e

domınios de aplicacao.

O perfil e organizado em diferentes grupos de conceitos. Cada um desses grupos

oferece elementos e relacoes a serem usadas na descricao de uma atividade de testes. A

arquitetura do Perfil UML 2.0 de Testes encontra-se estruturada em quatro grupos de

conceitos, sao eles: Arquitetura de Teste, Comportamento de Teste, Dados de Teste e

Temporizacao de Teste.

O grupo Arquitetura de Teste define os conceitos necessarios para descrever os com-

ponentes usados em uma atividade de teste e o relacionamento entre eles. Centra-se nos

aspectos estaticos usados durante a verificacao de um sistema, como a identificacao do

sistema sob testes (SUT), que prove operacoes atraves de interfaces publicas acessadas por

componentes de teste (test components), agrupados em contextos de teste (test contexts).

Define tambem um arbitro (arbiter), que determina o veredito final do teste, e um

escalonador (scheduler), que e responsavel por controlar a execucao. Os elementos UML

deste grupo sao representados na Figura 2.5 e descritos como segue:

Figura 2.5: Arquitetura de Teste (OMG, 2004).


∙ System under test (SUT): O sistema sob testes e ativado atraves de um conjunto de

interfaces publicas que expoe suas funcionalidades. Essas interfaces sao importadas a

partir do modelo completo do sistema. Como os componentes de teste se comunicam

com o alvo apenas atraves delas, nao existem outras maneiras de obter informacao do

SUT, caracterizando um teste tipo caixa-preta. Um SUT pode se apresentar atraves

de diferentes nıveis de abstracao, como um sistema completo, um subsistema ou,

ainda, um conjunto de componentes, como classes. A granularidade do SUT define

o nıvel de teste (unitario ou de integracao).

∙ Test Component : representa a implementacao de um caso de teste, e normalmente

uma classe que interage com o SUT ou com outros componentes. Ele executa

uma sequencia de acoes na forma de estımulos, ativando funcionalidades do alvo, e

de observacoes, recuperando informacoes. O componente pode realizar validacoes,

verificando os dados recebidos do SUT e atualizando o veredito do teste, bem como

registrar informacoes em logs.

∙ Arbiter : interface cuja implementacao tem como proposito determinar o veredito

final para o teste. Cada componente de teste informa a um arbitro central os seus

vereditos locais. O arbitro central determina a polıtica para o veredito final: por

exemplo, indicar o teste inteiro como falho se uma certa percentagem dos casos de

teste nao terminar com sucesso.

∙ Scheduler : interface cuja implementacao controla a execucao dos diferentes com-

ponentes de teste. Ele realiza a criacao e destruicao dos componentes, inicia sua

execucao e interage com o arbitro para informar o momento de calcular o veredito

final do teste.

∙ Test Context : estrutura usada para agrupar componentes de teste. Ela e uma classe

associada a um conjunto de componentes de teste, a uma instancia de arbitro, uma

instancia do SUT e uma instancia de um escalonador. Sua implementacao pode ser

tanto codigo executavel como scripts. Este elemento foi projetado para ser gerado

automaticamente por ferramentas, usando as descricoes dos demais elementos.

O segundo grupo, Comportamento de Teste, define os conceitos relacionados aos

aspectos dinamicos dos procedimentos, tais como: invocacao de acoes, determinacao de

vereditos e registros (logs). Neste grupo ha, tambem, elementos que associam casos de

uso a casos de teste. A Figura 2.6 ilustra os elementos deste grupo, os quais sao definidos

como segue:


Figura 2.6: Comportamento de teste (OMG, 2004).

∙ Veredict : enumeracao que contem ao menos os valores fail, inconclusive, pass e error,

que indicam o resultado da execucao de um teste. O valor pass indica que o SUT se

comportou como o previsto. Fail, por outro lado, indica que o comportamento do

SUT nao foi o esperado. Se a execucao do teste nao pode determinar um resultado,

o valor inconclusive e usado. O veredito error e usado para indicar que o sistema

de teste teve problemas.

∙ Validation Action: acao executada durante um teste que informa um resultado local

ao arbitro central.

∙ Default : artifıcio usado para simplificar os modelos de teste, permitindo construir

definicoes parciais de componentes de teste de maneira compacta. Uma especificacao

default, que pode ser apresentada como diagramas de sequencia ou de estado,

indica qual acao o sistema de teste deve tomar quando o SUT nao se comporta da

maneira esperada. Como essas especificacoes podem ser referenciadas por diferentes

componentes, os modelos se tornam mais compactos.

∙ Test Log : componente atraves do qual os contextos de teste podem criar rastros

de execucao e indicar informacoes de interesse. Esses registros tornam-se parte da

especificacao do sistema de teste.

O terceiro grupo de conceitos e o de Dados de Teste, que define a sintaxe e semantica

dos dados usados como entrada e saıda dos procedimentos de teste. Dados explıcitos e

classes de equivalencia formam conjuntos de dados (data sets); essas classes de equivalencia

especificam regras para formacao de dados de entrada ou saıda. Valores coringas (wild-

cards), em adicao aos ja presentes em UML padrao, sao oferecidos. Os elementos seletores

de dados (data selectors) sao usados para facilitar a criacao de estrategias de teste. Os

elementos que compoe este grupo sao mostrados na Figura 2.7 e uma breve descricao e

apresentada:


Figura 2.7: Dados de teste (OMG, 2004).

∙ Wildcards : valores literais usados para especificar de forma relaxada um dado

fornecido a um SUT ou recebido dele durante um teste.

∙ Data Partition: estabelece uma classe de equivalencia para valores a serem forneci-

dos a um SUT ou recebidos durante um teste. E usada como uma forma de

diferenciar, visivelmente, os dados, atribuindo a eles nomes como, por exemplo,

NumerosCPFValidos.

∙ Data Pool : mecanismo usado para associar conjuntos de dados a contextos de teste.

E uma classe que contem particoes de dados ou valores explıcitos e uma associacao

a um contexto de teste.

∙ Data Selector : operacoes que definem as estrategias usadas pelo sistema de teste

para fornecer e verificar os dados de entrada e saıda do SUT. Sao associados a uma

particao ou repositorio de dados.

∙ Coding Rules : strings usadas para referenciar padroes de codificacao e de protocolos

de transmissao de dados externos ao perfil de teste, como CORBA ou XML.

O grupo Temporizacao de Teste apresenta os conceitos de tempo usados para sin-

cronizacao entre sistemas e para verificacao de desempenho. Temporizadores (timers) sao

definidos, permitindo especificar limites de tempo para operacoes em um caso de teste.

O conceito de fuso horario (timezones) agrupa componentes de teste sob uma mesma

percepcao de tempo. Na Figura 2.8 sao representados os elementos UML deste grupo.


Figura 2.8: Temporizacao de teste (OMG, 2004).

O Perfil UML 2.0 de Testes possibilita projetar e descrever atividades de verificacao

e validacao de sistemas em uma linguagem padronizada, desenvolvida com foco em abor-

dagens MDA e em automacao.

2.5 Engenharia Experimental

No contexto da engenharia de software, os estudos empıricos tem adquirido importancia

ao longo do tempo. Eles podem ser definidos com uma forma de se obter informacoes

sobre um objeto de pesquisa. Desse modo, auxiliam na construcaao de conhecimento

com base em observacoes e evidencias empıricas. Parte da comunidade de pesquisa esta

voltando suas atencoes para um conjunto de tecnicas agregadas sobre a denominacao de

Engenharia de Software Experimental (Basili, 2006).

A Engenharia de Software Experimental tem como objetivo apontar indıcios sobre

hipoteses levantadas a respeito de determinados artefatos gerados durante o desenvolvi-

mento de software.

Um experimento e um tipo de estudo empırico realizado em um ambiente controlado,

passıvel de observacao e onde as hipoteses podem ser analisadas. Essa forma de estudo

esta focada em variaveis especıficas com um potencial estatıstico significativo, sendo a

forma mais efetiva para provisao de evidencia empırica e refinamento de conhecimento. Os

resultados obtidos sao analisados para identificar variaveis chaves e o relacionamento entre

elas. Essa analise pode ser apoiada por habilidade humana, experiencias, conhecimento

de domınio entre outros.

2.6 Consideracoes Finais 31

A realizacao de experimentos tem por objetivo avaliar, caracterizar, prever, controlar

e melhorar produtos, processos, recursos, modelos, teorias entre outros. Alem disso,

presume um relacionamento de causa e efeito . Um experimento e desdobrado em diversas

atividades, as quais possuem complexidade variavel.

Segundo (Wohlin et al., 2000), a experimentacao caracteriza-se por um processo que

tem um inıcio a partir da Definicao do experimento passando pelo Planejamento, Ex-

ecucao, Analise e Interpretacao, Apresentacao e Empacotamento.

Na fase de Definicao, o experimento e definido em termos dos objetivos e metas

do estudo. Desse modo, devem ser respondidas questoes relacionadas ao objeto do

estudo (o que sera estudado), proposito (intencao do estudo), foco de qualidade (aspecto

de qualidade a ser estudado), perspectiva (ponto de vista em que os resultados serao

interpretados) e contexto (ambiente no qual o experimento sera realizado).

A etapa Planejamento prepara como o estudo experimental sera conduzido, atraves

da definicao dos seguintes elementos: contexto, hipoteses, variaveis, participantes e pro-

jeto experimental, contendo instrumentacao e avaliacao da validade.

Apos o planejamento do estudo, tem-se a Execucao do mesmo com o proposito de se

coletar os dados para serem analisados. Essa etapa deve haver uma monitoracao por parte

do pesquisador para ter certeza que tudo seja feito de acordo com o planejado, qualquer

vies nessa etapa pode afetar a validade do estudo.

Na fase de Analise e Interpretacao as hipoteses elaboradas sao comparadas com os

dados obtidos atraves de ferramentas estatısticas adequadas. Os resultados gerados nesta

fase sao usados pelo experimentador na tentativa de rejeitar a hipotese nula e confirmar

a hipotese alternativa.

A etapa de Apresentacao e Empacotamento os resultados obtidos com o experi-

mento sao apresentados e empacotados, atraves de documentatacao (artigos de pesquisa),

ou ainda compondo uma base de conhecimento.

No planejamento de experimentos e importante considerar a necessidade de replicacao

ou complementacao do estudo a fim de ampliar a base de dados, a credibilidade e o

ındice de confiabilidade. A fase de apresentacao e empacotamento oferece suporte para a

replicacao, oportunidades de variacao e combinacao de resultados.

2.6 Consideracoes Finais

Os conceitos e tecnicas apresentados neste capıtulo oferecem o embasamento necessario

para a contextualizacao, fundamentacao e conducao de estudos experimentais deste tra-

balho.


O Capıtulo 3 discute os trabalhos relacionados e sua relevancia para o desenvolvi-

mento da Abordagem Integrada de Desenvolvimento e Teste de Software para Equipes

Distribuıdas.

Capıtulo

3

Trabalhos Relacionados

Este capıtulo apresenta os processos de desenvolvimento e teste de software que nortearam

o desenvolvimento deste trabalho e uma analise comparativa entre os mesmos.

3.1 Processos de Desenvolvimento de Software

Esta secao apresenta, sucintamente, os processos de desenvolvimento, identificando suas

atividades, artefatos e papeis, sendo eles: RUP (secao 3.1.1), eXtreme Programming (secao

3.1.2), Agile Unified Process (secao 3.1.3), Extended Workbench Model (secao 3.1.4) e Local

Agile Game-based Process (secao 3.1.5).

3.1.1 Rational Unified Process (RUP)

O RUP e um processo de desenvolvimento de software iterativo, incremental e adaptavel,

podendo ser customizado para diversos tipos e tamanhos de produtos e projetos de

software. Identifica cada ciclo de desenvolvimento do projeto em quatro fases, cada uma

com marcos de finalizacao definidos, os chamados milestones (Kruchten, 2003).

Os milestones indicam o progresso do projeto e sao usados como base para decisoes

para continuar, cancelar, ou mudar o rumo do projeto. O RUP apresenta quatro fases:

inıcio, que tem por objetivo determinar o escopo do desenvolvimento; elaboracao, que

refere-se ao planejamento das atividades e recursos necessario; construcao, relacionada a

implementacao do software; e transicao, que tem por objetivo disponibilizar o produto.

33

34 3. Trabalhos Relacionados

O RUP estrutura o projeto fazendo uma divisao bem definida de atividades (tarefas

e papeis) e apresenta uma colecao de artefatos, nos quais a comunicacao se baseia. O

processo e dividido em nove disciplinas: Gerencia de Projetos, Modelagem de Negocios,

Requisitos, Analise e Projeto, Implementacao, Teste, Instalacao, Configuracao e Controle

de Mudancas e Ambiente.

A disciplina de Gerencia de Projetos, desempenhada pelo Gerente de Configuracao e

Engenheiro de Processo, oferece suporte para equilibrar as metas em termos de custos e

prazos e gerenciar o risco para a entrega de um produto que satisfaca as necessidades do

cliente. A Modelagem de Negocio visa entender a estrutura e a dinamica da organizacao

na qual o software sera inserido e envolve os papeis de Analista de Processos de Negocios,

Projetista de Negocio e Revisor de Negocios.

Na disciplina de Requisitos as necessidades do sistema sao traduzidas na forma de casos

de uso, e os papeis envolvidos sao: Analista de Sistema, Especificador de Caso de Uso e

Projetista de Interface do Usuario. A Analise e Projeto e responsavel pela especificacao

da forma de implementacao dos requisitos, sendo desempenhada pelos papeis de Arquiteto

e Projetista.

A implementacao das classes e objetos na forma de componentes ocorre na disciplina

Implementacao, que e realizada pelos papeis de Implementador, Arquiteto e Revisor de

Codigo. A disciplina de Teste, desempenhada pelos papeis Projetista de Teste e Testador,

e responsavel por testar e verificar se o produto funciona como o esperado, documentando

falhas e problemas.

A disciplina Configuracao e Controle de Mudancas envolve o Gerente de Configuracao

e o Gerente de Controle de Mudancas e concentra-se na garantia da rastreabilidade das

versoes de um projeto. O suporte adequado a organizacao do projeto em ferramentas,

metodos e processos e provido pela disciplina Ambiente, que conta com os papeis de

Engenheiro de Processo, Escritor Tecnico, Analista de Sistema, Analista do Processo Em-

presarial, Projetista de Interface do Usuario, Projetista de Teste, Arquiteto, Especialista

de Ferramenta e Administrador de Sistema. Por fim, tem-se a disciplina de Distribuicao

que tem por objetivo distribuir, instalar, testar em campo e treinar os usuarios. Os

papeis envolvidos sao o Gerente de Distribuicao, Gerente de Projeto, Escritor Tecnico,

Desenvolvedor de Curso, Artista Grafico, Testador e Implementador.

3.1.2 eXtreme Programming (XP)

O XP e uma metodologia de desenvolvimento agil, com iteracoes curtas, que objetiva

tornar o projeto flexıvel, diminuindo o custo a possıveis mudancas e utiliza o codigo

3.1 Processos de Desenvolvimento de Software 35

gerado como um indicador de progresso do projeto. A metodologia XP e baseada em

quatro valores: comunicacao, simplicidade, feedback e coragem.

A comunicacao e o valor mais importante, pois a maioria dos problemas que ocorrem

nos projetos tem sua causa associada a falhas na comunicacao. Utilizando o XP espera-se

que a comunicacao seja qualitativamente alta e frequente. Os clientes comunicam requisi-

tos funcionais atraves de estorietas escritas que sao usados para guiar o desenvolvimento.

A comunicacao entre os desenvolvedores ocorre sempre que necessario e, diariamente, sao

realizadas reunioes que alinham a equipe ao andamento global do projeto.

O valor simplicidade refere-se ao fato de que os desenvolvedores devem objetivar a

construcao do sistema mais simples possıvel, que realize de forma eficaz o trabalho a que

se propoe. E, conforme novos requisitos sao adicionados no sistema, este e modificado o

quanto for necessario, mas o mınimo possıvel, implementando apenas o que e necessario

e realmente importa ser construıdo.

O feedback no XP ocorre em diversos aspectos na organizacao do trabalho. A

integracao constante do sistema fornece aos desenvolvedores informacao imediata sobre o

estado do sistema e cada execucao de testes oferece aos desenvolvedores feedback imediato

em relacao a possıveis inconsistencias no codigo. Obter o feedback mais cedo significa ter

mais tempo disponıvel para reagir.

O valor coragem passa pela mudanca de paradigma necessaria para adocao de uma

metodologia agil, mas atinge tambem o processo em todos os nıveis e tarefas. Significa

tomar as decisoes na hora em que elas precisam ser tomadas. Seguindo esse valor, se uma

funcionalidade nao esta funcionando, conserte-a. Se algum codigo nao parece estar bem

escrito, refatore-o.

O ciclo da metodologia XP e composto pelas seguintes etapas:

1. Exploracao: nessa etapa o cliente escreve cartoes de estorias, cada um contendo

uma funcionalidade desejada para o primeiro release.

2. Planejamento: definicao de prioridades entre as estorias junto com o cliente. Nesta

etapa e realizada a estimativa de esforco e o cronograma para cada uma das estorias

elaboradas anteriormente.

3. Iteracoes para Release: sao realizadas diversas iteracoes ate o primeiro release

ser completado. A primeira iteracao consiste na criacao do sistema com toda a

arquitetura, nas iteracoes seguintes sao adicionadas as funcionalidades de acordo

com as prioridades estabelecidas.


4. Validacao para Producao: esta etapa compreende a realizacao de testes extensivos

e verificacoes para validacao do software.

5. Manutencao: apos o primeiro release para producao, ha novas edicoes do sistema

com novas funcionalidades.

6. Morte: quando nao ha mais estorias a serem implementadas e o cliente esta satisfeito

com o codigo.

3.1.3 Agile Unified Process (AUP)

O AUP e uma versao simplificada do RUP, que utiliza tecnicas e conceitos de metodos

ageis para descrever de uma maneira simples e facil de compreender o desenvolvimento

de software.

No AUP sao realizadas sete disciplinas: Modelo, Implementacao, Teste, Implantacao,

Gerenciamento de Configuracao e Gerenciamento de Projetos. A disciplina Modelo com-

preende o ramo em que se insere a organizacao, o problema para o qual o software esta

sendo desenvolvido e a identificacao da solucao para resolve-lo. Na disciplina Imple-

mentacao os modelos sao tranformados em codigos executaveis.

O Teste e uma disciplina em que e realizada uma avaliacao objetiva com o intuito

de assegurar a qualidade, encontrar defeitos, validar se o sistema faz o que se propoe

e verificar se os requisitos sao atendidos. A Implantacao e responsavel pela entrega do

sistema.

Na disciplina Gerenciamento de Configuracao e realizado o gerenciamento do acesso

a todos os artefatos do projeto, incluindo o rastreamento das varias versoes, controle

e gerencia das alteracoes. A disciplina Gerenciamento de Projetos e responsavel por

direcionar as atividades que ocorrem no projeto, por exemplo: gestao de risco e gestao

de recursos humanos. E, Ambiente e a disciplina que objetiva assegurar que os processos,

a direcao do projeto e as ferramentas utilizadas estao acessıveis a toda a equipe de

desenvolvimento.

3.1.4 Extended Workbench Model

O Extended Workbench Model tem sido amplamente utilizado na Siemens. Nessa abor-

dagem ha uma pequena equipe central que realiza o planejamento do projeto, defininindo

os papeis e responsabilidades dos times remotos, e as atividades no inıcio de cada fase,

por exemplo, analise de requisitos, projeto de arquitetura e plano de projeto. As equipes

distribuıdas sao responsaveis pelas atividades de desenvolvimento e teste (Paulish, 2007).

3.2 Analise Comparativa dos Processos de Desenvolvimento 37

Segundo Avritzer et al. (2007) no Extended Workbench Model tem-se como praticas

gerenciamento centralizado, desenvolvimento iterativo, diminuicao da comunicacao entre

times e especificacao formal dos requisitos. Com isso, os requisitos do sistema, arquitetura

e testes do sistema sao executados de modo centralizado, utilizando ciclos de iteracoes

curtos (cerca de 15 dias), a comunicacao entre os times e gerenciada pela equipe central e,

com o intuito de minimizar a comunicacao entre os times remotos realiza-se a especificacao

dos requisitos utilizando metodos formais.

O time central e responsavel por desempenhar os papeis de Engenheiro de Requisitos,

Arquiteto, Engenheiro de Integracao, Gerente de Infraestrutura e Administrador da ferra-

menta de colaboracao. As equipes remotas desempenham os papeis de Desenvolvedores,

Lıderes de Testes, Engenheiros de Requisitos, Arquiteto de Sistemas, Gerente de Quali-

dade, Gerente de Infraestrutura e Engenheiro de Processo e Documentacao (Urdangarim,

2008).

3.1.5 Local Agile Game-based Process (LAGPRO)

O LAGPRO e um processo para ser utilizado por equipes locais para reforcar a coor-

denacao e motivacao em um contexto de desenvolvimento distribuıdo de software. E um

processo iterativo, em que cada iteracao e dividida em fases, as quais tem duracao de duas

semanas.

A estrutura e os princıpios gerais do LAGPRO sao baseados no AUP, simplificando

suas disciplinas e fases. A disciplina Model, foi esbocada utilizando a construcao de

modelos simplificados no inıcio de cada nova iteracao e de modelos de revisoes ao final de

cada iteracao. A metodologia Test-Driven Development (TDD) foi utilizada na disciplina

implementacao, onde os times de testes definiam os testes unitarios automatizados e os

times de desenvolvimento implementavam as regras de negocio (Ribeiro et al., 2006).

O LAGPRO buscou introduzir motivacao em equipes utilizando elementos de jogos e

competicao. Segundo Ribeiro et al. (2006), as tentativas de execucao do processo falharam

devido a rejeicao por parte dos membros do time com relacao a caracterıstica competitiva.

3.2 Analise Comparativa dos Processos de Desenvolvi-

mento

Os processos RUP e XP foram escolhidos por serem amplamente utilizados, quer na

academia como na industria, sendo uma metodologia tradicional e uma agil, respectiva-


mente. Em (Rocha et al., 2008) e apresentado um relato de experiencia sobre a adaptacao

do RUP para pequenas equipes de desenvolvimento distribuıdo. O AUP foi selecionado

por ser uma simplificacao do RUP que utiliza conceitos de metodos ageis. E os demais,

o Extended Workbench Model e o LAGPRO, por serem utilizados no contexto de DDS,

conforme pode ser visto em (Ribeiro et al., 2006), (Paulish, 2007) e (Urdangarim, 2008).

A seguir sera apresentada a comparacao entre os processos de desenvolvimento de

software mencionados acima. Para tanto, foi identificado um conjunto de criterios de

comparacao baseando-se nas caracterısticas de desenvolvimento distribuıdo de software

identificadas em (Urdangarim, 2008) (criterios de A - G), nos elementos basicos de um

processo de software (criterios de H - J) e no tipo de metodologia (criterio K e L). Os

criterios a serem utilizados na comparacao visando identificar qual dos processos melhor

atende as necessidades dos projetos DDS, sao:

∙ (A) Diversidade: Identifica se o processo analisado oferece mecanismos para con-

trole, coordenacao e comunicacao das diferencas (cultural e idioma) entre as equipes

envolvidas no projeto.

∙ (B) Requisitos: Caracteriza se o processo analisado trata a especificacao formal

dos requisitos, que tem por objetivo amenizar os problemas de ambiguidades nos

artefatos e com isso, minimizar a comunicacao.

∙ (C) Centralizado: Identifica se o processo analisado apresenta uma centralizacao do

controle das atividades do projeto.

∙ (D) Descentralizado: Identifica se o processo analisado e caracterizado pela descen-

tralizacao do controle das atividades do projeto.

∙ (E) Acompanhamento: Identifica se o processo caracteriza-se por acompanhar,

periodicamente, a evolucao dos trabalhos dos times remotos.

∙ (F) Colaboracao: Caracteriza se o processo permite o uso de ferramentas de cola-

boracao entre os times como meio de compartilhamento de informacoes.

∙ (G) Confianca: Identifica se o processo e capaz de promover confianca entre os

membros dos diferentes times. A confianca pode ser alcancada oferecendo visibili-

dade adequada do projeto, por meio da divulgacao das informacoes e por meio de

mecanismos de percepcao.

∙ (H) Papeis: Identifica se o processo possui uma organizacao rıgida na definicao dos

papeis a serem desempenhados.

3.2 Analise Comparativa dos Processos de Desenvolvimento 39

∙ (I) Artefatos: Identifica se o processo apresenta a definicao dos artefatos requeridos

e gerados em cada fase.

∙ (J) Atividades: Identifica se o processo define as atividades que devem ser realizadas

em cada fase.

∙ (K) Metodologia tradicional: Caracteriza se o processo apresenta o enfoque de uma

metodologia tradicional de desenvolvimento de software.

∙ (L) Metodologia agil: Caracteriza se o processo apresenta o enfoque de metodologia

agil.

Segundo Urdangarim (2008), definir os criterios de analise e uma atividade que requer

um consideravel esforco intelectual e que, geralmente, da margem para questionamentos

que podem ir alem do escopo do trabalho em questao. Desse modo, com os criterios

expostos nao se espera esgotar as perspectivas de comparacao dos processos.

Na Tabela 3.1 os processos selecionados e descritos na Secao 3.1 sao comparados em

relacao aos criterios mencionados acima, cuja analise encontra-se na sequencia.

Tabela 3.1: Analise Comparativa dos ProcessosProcesso/Criterios A B C D E F G H I J K LRUP x x x x xXP x x x x x x x xAUP x x x x xExtended WorkbenchModel x x x x x x xLAGPRO x x x x x x x x x

Analisando a Tabela 3.1 acima, e possıvel observar que nenhum dos processos atende

todas as necessidades dos projetos desenvolvidos com equipes geograficamente distribuıdas.

Nao ha um processo que contemple os criterios relacionados ao DDS (criterios de

A - G) e apresente os elementos basicos (papeis, artefato e atividades). Desse modo,

percebe-se a inexistencia de um processo sistematico que contemple as caracterısticas

dessa nova configuracao de desenvolvimento. Para tanto, devem ser definidos as ativi-

dades, os artefatos e os papeis necessarios em cada etapa do desenvolvimento utilizando

a abordagem distribuıda.

O RUP, o XP e o AUP definem o conjunto mınimo de elementos que compoem um

processo. Entretanto, nao apresentam procedimentos para tratar as questoes relacionadas

aos problemas de DDS, que sao representadas pelos criterios de A a G.

O Extended Workbench e o LAGPRO, embora tenham sido definidos para serem uti-

lizados por projetos que sao desenvolvidos de modo distribuıdo, nao possuem mecanismos


para explicitar a diversidade, tratam apenas a especificacao formal dos requisitos. No

Extended Wokbench, tambem, nao sao contemplados os fatores relacionados a colaboracao

e confianca. Alem disso, nao foram encontrados relatos sobre os artefatos gerados. E, no

caso do LAGPRO, tambem, nao foram identificadas as atividades.

Desse modo, e possıvel evidenciar a necessidade de um processo que atenda essas novas

demandas geradas pela abordagem distribuıda e apresente a definicao dos elementos que

um processo deve contemplar.

O processo de desenvolvimento de software tem passado por intensas transformacoes

nos ultimos anos. E nesse contexto, novas abordagens de desenvolvimento tem surgido

objetivando que muitos dos problemas encontrados nos projetos anteriores nao sejam

repetidos. Dentre os problemas mais comuns aos projetos de software podem ser desta-

cados: altos custos para evolucao, inconsistencia entre documentacao e sistema final,

pouca ou quase que total falta de portabilidade e baixa confiabilidade. E sabido que o

sucesso de um projeto de desenvolvimento de software inicia-se no devido planejamento

e na escolha de uma metodologia compatıvel com as caracterısticas do mesmo, o que

reforca a necessidade de um processo de desenvolvimento que contemple de forma efetiva

as necessidades do DDS.

Audy e Prikladnicki (2008), destacam que em um ambiente de desenvolvimento dis-

tribuıdo, e fundamental um processo de desenvolvimento comum a equipe pois, uma

metodologia auxilia diretamente na sincronizacao, fornecendo a todos os membros da

equipe uma nomenclatura comum de tarefas e atividades, e um conjunto comum de

expectativas aos elementos envolvidos no processo.

Segundo Rocha et al. (2008), quando o contexto e Desenvolvimento Distribuıdo, o

cenario muda com relacao ao desenvolvimento de software tradicional, pois as variaveis e

os riscos aumentam. Entao, se nao houver uma metodologia adequada para o processo de

desenvolvimento, o projeto tera boas chances de nao corresponder ao planejamento inicial.

Em sua primeira percepcao sobre o uso e estudo de DDS, Rocha et al. (2008) ressaltam

a necessidade de processos mais adequados, pois, com base nas pesquisas realizadas, nao

foi facil a identificacao de modelos de referencia de processos para o ambiente DDS.

3.3 Processos de Teste de Software

Nesta secao sao descritos alguns processos de teste, identificando suas atividades, artefatos

e papeis, sendo eles: RUP (secao 3.3.1), SiTest (secao 3.3.2) e Processo do CenPRA (secao

3.3.3).

3.3 Processos de Teste de Software 41

3.3.1 Teste no RUP

No RUP o fluxo de teste e desempenhado por tres papeis: Projetista, Implementador e

Testador; e, composto por cinco atividades: Planejar, Projetar, Implementar, Executar

Teste de Integracao, Executar Teste de Sistema e Avaliar (Kruchten, 2003).

A atividade Planejar, realizada pelo Projetista, identifica e descreve o teste que sera im-

plementado e executado, e produz como artefato o plano de teste que contem informacoes

sobre o proposito e as metas do teste e identifica as estrategias e recursos a serem utilizadas

nas etapas subsequentes. Na atividade Projetar, o Projetista descreve e gera o modelo de

teste que inclui os casos e procedimentos de teste.

A atividade Implementar os procedimentos de teste sao implementados pelo Imple-

mentador produzindo o script de teste. Nas atividades Executar Teste de Integracao e

Executar Teste de Sistema, o Testador deve assegurar que os componentes do sistema

colaboram e funcionam como planejado, respectivamente. Durante a execucao dos testes

os dados sao capturados e o artefato Resultados de Teste e produzido.

A atividade Avaliar e realizada pelo Projetista e tem como objetivo entregar e avaliar

as medidas quantificaveis de teste para determinar a qualidade do sistema em teste e

do processo de teste. Nesta atividade e gerado um documento contendo um resumo dos

testes.

3.3.2 SiTest

A metodologia foi desenvolvida com base no modelo de qualidade CMMI (Capability

Maturity Model Integration) e encontra-se estruturada em cinco fases, as quais apresentam

atividades e artefatos (Silva et al., 2006).

Na fase inicial, a de Planejamento, sao realizadas as seguintes atividades: levanta-

mento dos requisitos necessarios para a realizacao dos testes; selecionar os modulos a

serem testados; levantamento dos riscos e ponssibilidades de mitigacao; identificacao dos

indicadores de desempenho; definicao da equipe de teste bem como suas competencias e

atividades; e elaboracao do cronograma inicial. Como artefatos desta fase sao produzidos

o plano de teste e o cronograma preliminar.

A etapa subsequente, Preparacao, e composta pelas atividades: determinacao da

sequencia dos componentes para integracao; levantamento da configuracao do ambiente

para os testes e controle das mudancas; estabelecimento do ambiente de testes de in-

tegracao, verificacao e validacao; instalacao e configuracao das ferramentas de teste; e,

elaboracao dos projetos de testes. Nesta fase sao gerados tres artefatos: o projeto de testes;

relatorio de equipe e suas respectivas atividades; e, ferramentas de testes disponıveis.


Na fase de Especificacao sao definidas as atividades da equipe de testes, os dados de

entrada e saıda sao determinados e os casos e roteiros de testes sao elaborados. Como

saıdas dessa fase tem-se a especificacao dos roteiros e casos de testes. Apos a Especificacao

tem-se a fase de Execucao a qual e composta pelas seguintes atividades: execucao dos

testes de unidade, integracao, sistemas e aceitacao; elaboracao da documentacao formal de

erros; analise dos resultados; e, solicitacao das correcoes e alteracoes. Durante a Execucao

sao produzidos o registro de teste e registro de consolidacao de testes, registro de defeitos

conhecidos, diarios de testes, relatorio de conformidades e nao-conformidades e o relatorio

de incidente de testes.

A ultima fase da metodologia e a Entrega. Essa etapa consiste nas seguintes atividades:

elaboracao do relatorio final de teste; elaboracao de um resumo sobre o processo de teste

e sua aplicacao no projeto; e, registro da base de conhecimento do processo. Como saıdas

dessa fase sao gerados os registros de testes, o resumo de testes e relatorio final de testes.

3.3.3 Processo CenPRA

O Processo de teste do CenPRA e baseado em artefatos de teste definidos na norma

IEEE Std 829-1998 e tem as suas atividades definidas e ordenadas de forma a permitir

que o teste seja eficiente e eficaz. O Processo de teste do CenPRA contem subprocessos

de teste e artefatos associados. Em cada subprocesso os papeis envolvidos sao: Gerente,

Executor, Cliente e Fornecedores. A seguir os subprocessos: Planejar, Projetar, Executar,

e Registrar sao descritos (Crespo et al., 2004).

O subprocesso Planejar envolve a realizacao das seguintes atividades: definir contexto

do teste, descrevendo resumidamente os itens e caracterısticas a serem testadas; caracteri-

zar os itens de teste; identificar funcionalidades e caracterısticas que devem ser testadas

para cada item de teste; estabelecer abordagens e criterios para medir a abrangencia dos

testes, determinar o termino, aprovacao ou reprovacao dos itens de teste, suspensao e

retomada dos testes e de rastreabilidade; definir os produtos a serem gerados; definir

atividades de teste; estabelecer requisitos de ambiente; estabelecer responsabilidades;

estabelecer equipe e treinamento necessarios; elaborar cronograma; identificar riscos e

estabelecer contingencias. O artefato produzido por este subprocesso e o Plano de Teste.

No subprocesso Projetar a abordagem de teste definida no planejamento e refinada.

As atividades que compoe esse subprocesso sao: detalhar as abordagens e criterios; especi-

ficar casos de teste estabelecendo as entradas requeridas para sua execucao; estabelecer

requisitos de ambiente de teste, tais como hardware, software e recursos humanos; definir

objetivo dos procedimentos de teste; e definir os passos dos procedimentos de teste. As

3.4 Analise Comparativa dos Processos de Teste 43

saıdas desse subprocesso sao a Especificacao de Projeto de Teste, Especificacao de Casos

de Teste e Especificacao de Procedimento de Teste.

O terceiro subprocesso e o Executar que corresponde a realizacao dos passos do

Procedimento de Teste. Este subprocesso e formado pelas seguintes atividades: executar

a sequencia de acoes previas necessarias para a execucao do teste; Executar as acoes

necessarias para iniciar a execucao do teste; registrar os resultados da execucao e das

medicoes do teste; e, executar as acoes para suspender, retomar, parar e encerrar os

testes.

O subprocesso Registrar tem como objetivos documentar cronologicamente os detalhes

relevantes relacionados com a execucao dos testes, registrar os eventos que ocorrem du-

rante a execucao e requerem analise e, descrever resumidamente os resultados e avaliacoes.

Para tanto sao realizadas as seguintes atividades: descricao do teste; registro das ativi-

dades e eventos; descricao dos incidentes de teste; determinacao do impacto do incidente;

descricao resumida dos itens de teste; descricao de desvios das especificacoes; descricao da

abrangencia; descricao resumida dos resultados; avaliacao dos itens de teste e descricao

resumida da atividade de teste. Os artefatos produzidos sao: Diario de Teste, contendo

a descricao do teste e registro de atividades e eventos; Relatorio de Incidentes com o

resumo e descricao do impacto do incidente; e, Relatorio-Resumo de Teste constituıdo

pelo Resumo dos Itens de Teste, Desvios das Especificacoes, Avaliacao da Abrangencia

do Teste, Resumo de Resultados, Avaliacao dos Itens de Teste e o Resumo de Atividades.

3.4 Analise Comparativa dos Processos de Teste

Na literatura nao foram encontrados, ate o momento da elaboracao dessa dissertacao,

relatos de processos de teste utilizados no Desenvolvimento Distribuıdo de Software. Como

ha relatos de uso do RUP, XP e AUP, e importante analisar como a fase de testes e vista

nesses processos. A SiTEST foi selecionada por ser uma metodologia de teste que apoia

o ciclo de vida do software e ser baseada no modelo de qualidade CMMI. E o processo do

CenPRA por ser amplamente utilizado (Crespo et al., 2004).

Os criterios utilizados na comparacao dos processos de teste sao:

∙ (A) Casos de Teste: Caracteriza se o processo analisado trata a especificacao formal

dos casos de teste.

∙ (B) Centralizado: Identifica se o processo analisado apresenta uma centralizacao do

controle das atividades de teste.


∙ (C) Descentralizado: Identifica se o processo analisado e caracterizado pela descen-

tralizacao do controle das atividades de teste.

∙ (D) Acompanhamento: Identifica se o processo caracteriza-se por acompanhar pe-

riodicamente a evolucao dos trabalhos dos times remotos.

∙ (E) Colaboracao: Caracteriza se o processo permite o uso de ferramentas de cola-

boracao entre os times como meio de compartilhamento de informacoes.

∙ (F) Confianca: Identifica se o processo e capaz de promover confianca entre os

membros dos diferentes times. A confianca pode ser alcancada oferecendo visibili-

dade adequada do projeto, por meio da divulgacao das informacoes e por meio de

mecanismos de percepcao.

∙ (G) Papeis: Identifica se o processo possui uma organizacao sistematica na definicao

dos papeis a serem desempenhados.

∙ (H) Artefatos: Identifica se o processo apresenta a definicao dos artefatos requeridos

e gerados em cada fase.

∙ (I) Atividades: Identifica se o processo define as atividades que devem ser realizadas

em cada fase.

∙ (J) Metodologia tradicional: Caracteriza se o processo apresenta o enfoque de uma

metodologia tradicional de desenvolvimento de software.

∙ (K) Metodologia agil: Caracteriza se o processo apresenta o enfoque de metodologia

agil.

Na Tabela 3.2 e apresentada a comparacao entre os processos de teste.

Tabela 3.2: Analise Comparativa dos Processos de Teste

Processo/Criterios A B C D E F G H I J K

RUP x x x x x x

SiTest x x x x x

CenPRA x x x x x

XP x x x x x

AUP x x x x x

No RUP sao especificados os papeis envolvidos, atividades e artefatos gerados na

Disciplina de Teste. No entanto, nao retrata a especificacao formal dos casos de teste

3.5 Abordagem de Desenvolvimento e Teste de Software 45

que e um fator importante quando o desenvolvimento e realizado de forma distribuıda

por amenizar os problemas de comunicacao decorrentes da ambiguidade e imprecisao dos

artefatos.

Na metodologia SiTest e no processo do CenPRA os testes sao realizadas ao longo do

ciclo de vida do software. Tanto SiTest quanto o processo do CenPRA definem atividades,

papeis e artefatos gerados em cada etapa. Entretanto, nao apresentam mecanismos para

tratar a especificacao formal dos casos de teste. Mesmo nao sendo encontrados relatos do

uso desses processos no contexto de DDS, e importante analisa-los pois estes integram as

atividades de desenvolvimento e teste de software.

O XP e o AUP utilizam a abordagem Test Driven Development (TDD), que e uma

pratica de desenvolvimento incremental, que se baseia na construcao de testes de regressao

automatizados para nortear as atividades de desenvolvimento (Urdangarim, 2008). Essas

metodologias definem as atividades, atores, artefatos e apresentam o enfoque agil. Entre-

tanto, essas abordagens, tambem, nao definem procedimentos para a especificacao formal

dos casos de teste.

A partir da analise da Tabela 3.2 e possıvel observar a inexistencia de um processo

que aborde a especificacao formal dos casos de teste, o que e de extrema relevancia no

contexto de DDS por amenizar os problemas de compreensao e ambiguidade ocasionados

pelas diferencas culturais e linguistıcas. Dos processos analisados, nenhum contempla

explicitamente o gerenciamento descentralizado, oferece mecanismos para acompanhar a

evolucao dos trabalhos dos times, promover a colaboracao e a confianca.

No contexto de DDS, o uso de uma notacao padrao facilita a comunicacao entre as

equipes pois, possibilita que todos os artefatos utilizados para testar um sistema possam

ser especificados e modelados, auxiliando na documentacao, entendimento e rastreabili-

dade dos artefatos.

3.5 Abordagem de Desenvolvimento e Teste de Software

Em Alves et al. (2008) e apresentada uma proposta de integracao dos processos de Desen-

volvimento Dirigido por Modelos (MDD) e Teste Dirigido por Modelos (MDT). O MDD

objetiva mudar o foco do desenvolvimento de software para os modelos, contribuindo para

aumentar a qualidade do software, facilitar a portabilidade e diminuir os custos inerentes

a evolucao. O MDT refere-se a geracao automatica de casos de teste a partir de modelos

abstratos, contribuindo para aumentar a efetividade, confiabilidade e produtividade em

processos de teste.


Segundo Alves et al. (2008), a integracao destes processos pode trazer diversos benefıcios,

tais como: reducao do custo de desenvolvimento; alcance de um alto nıvel de automacao

no desenvolvimento e geracao de casos de testes; facilidade para realizar alteracoes nos

requisitos, devido a rastreabilidade provida; e, menores custos de manutencao.

A abordagem proposta representa as aplicacoes utilizando Model Driven Archicte-

ture (MDA), com modelos independentes dos detalhes de implementacao (Computational

Independent Model - CIM e Platform Independent Model - PIM) e dependentes da lin-

guagem de programacao (Platform Specific Model - PSM). Os modelos independentes

de plataforma sao formalizados com UML 2.0 e OCL (Object Constraint Language) e

os dependentes utilizando Java. Para a modelagem do CIM e do PIM foram definidos

os modelos funcionais, estruturais e comportamentais. A geracao dos casos de testes e

realizada a partir dos modelos do CIM-PIM, dando origem ao CITM (Computational

Independent Testing Models), modelos que capturam os objetivos de teste e ao PITM

(Plataform Independent Testing Models), modelos que refletem os casos de teste abstratos.

A especificacao completa dos casos de teste selecionados e os objetivos de teste sao

gerados automaticamente. Por outro lado, a geracao dos dados de teste e semiautomatica

e realizada a partir dos diagramas de classe e de maquina de estados comportamentais.


Este capıtulo apresentou os trabalhos, que juntamente com os problemas existentes do

DDS, deram subsıdios para a elaboracao da abordagem integrada de desenvolvimento e

teste de software para equipes distribuıdas.

A partir das analises descritas nas Secoes 3.2 e 3.4 foram elencadas algumas carac-

terısticas desejaveis para a definicao de um processo de software que atenda as necessidades

do desenvolvimento distribuıdo, sendo elas:

∙ gerenciamento hıbrido (centralizado-descentralizado) em relacao ao controle das

atividades e definicao de um lıder para estimular a confianca e compromisso entre

os membros [(Mullick et al., 2006), (Avritzer et al., 2007) e (Avritzer et al., 2008)];

∙ encorajamento da comunicacao entre desenvolvimento e equipe de teste de inte-

gracao oferecendo artefatos com informacoes relevantes para as duas equipes (Vanzin

et al., 2005);


∙ especificacao formal de testes para amenizar os problemas de ambiguidade e reduzir a

necessidade de comunicacao [(Mullick et al., 2006), (Avritzer et al., 2007) e (Avritzer

et al., 2008)];

∙ uso de arquitetura baseada em componente para distribuicao do desenvolvimento

ou distribuicao por fases, por exemplo desenvolvimento e teste, para reduzir a

comunicacao entre as equipes (Lings et al., 2007);

∙ identificacao das equipes envolvidas, o que sera realizado em cada local e as respon-

sabilidades de cada membro, para auxiliar na percepcao (Lings et al., 2007);

∙ adocao de metodologias de especificacao de facil compreensao e que possuam semantica

para transmitir informacoes aos desenvolvedores, no caso a UML por ser conhecida

tanto no meio academico como industrial (Sengupta et al., 2006);

∙ integracao contınua incremental [(Vanzin et al., 2005) e (Paasivaara e Lassenius,

2004)];

∙ desenvolvimento iterativo e com entregas frequentes para fornecer uma maior vi-

sibilidade do projeto aos gerentes [(Paasivaara e Lassenius, 2004) e (Taylor et al.,

2006)];

∙ definicao infraestrutura que possibilite a colaboracao, controle da documentacao

e controle de versao dos artefatos [(Paasivaara e Lassenius, 2004) e (Taylor et al.,

2006)]; desenvolvimento e aplicacao de suıtes de teste; e, estabelecimento de metodo

para controle da documentacao [(Paasivaara e Lassenius, 2004) e (Taylor et al.,

2006)] ;

∙ definicao de um idioma para formalizacao do processo e interacao entre as equipes

(Vanzin et al., 2005).

No proximo capıtulo e apresentada a especificacao e modelagem da abordagem de

desenvolvimento e teste de software proposta para equipes distribuıdas.


Capıtulo

4

Abordagem de Desenvolvimento e

Teste de Software para Equipes

Distribuıdas

Este capıtulo apresenta os modelos utilizados para especificar a abordagem proposta,

seguindo o metamodelo SPEM, que oferece uma estrutura de modelagem de processos

baseada na UML.

Primeiramente, e descrita uma visao geral da abordagem, permitindo entender o

contexto para o qual a mesma oferece suporte. Em seguida, os elementos da abordagem

sao detalhados.

4.1 Visao Geral da Abordagem

Um processo consiste em um conjunto de tarefas ordenadas que envolvem atividades,

restricoes e recursos para alcancar a saıda desejada. Pode ser caracterizado por prescrever

todas as suas principais atividades, utilizar recursos, estar sujeito a restricoes, gerar

produtos intermediarios e finais (artefatos). Cada atividade apresenta criterios de entrada

e saıda e um conjunto de diretrizes que explicam os seus objetivos.

Conforme analise apresentada no Capıtulo 3 foi possıvel evidenciar que ha algu-

mas lacunas no desenvolvimento distribuıdo de software no que se refere ao processo

de desenvolvimento. Para tanto, devem ser definidas as atividades, os artefatos e os

49

50 4. Abordagem de Desenvolvimento e Teste de Software para Equipes Distribuıdas

papeis necessarios em cada etapa do desenvolvimento, considerando as peculiaridades do

desenvolvimento com equipes distribuıdas.

Se a atividade de teste for conduzida ao acaso, defeitos no projeto podem passar

despercebidos durante o teste. Portanto, uma estrategia sistematica deve ser estabele-

cida para o teste de software. Desse modo, apresenta-se uma abordagem integrada de

desenvolvimento e teste de software que tem por objetivo atender as caracterısticas das

equipes distribuıdas no que se refere a comunicacao e coordenacao, nao se restringindo a

domınios especıficos de aplicacao. Ou seja, as tecnicas definidas na abordagem podem ser

utilizadas em conjunto com tecnicas que atendam as necessidades do domınio da aplicacao,

por exemplo sistemas de tempo real, que demanda especificacoes formais que podem ser

utilizadas como complemento a abordagem proposta. A abordagem proposta considera o

processo de testes como um conjunto de tarefas a parte que pode ser aplicado ao longo

do processo de desenvolvimento, instanciado em paralelo.

Segundo a ISO/IEC 12207 a abordagem pode ser classificada como sendo um processo

fundamental relacionado ao desenvolvimento. No entanto, apresenta alguns elementos de

processos organizacionais e de apoio. Em relacao aos processos organizacionais contempla

aspectos de gerencia. E, no que se refere aos processos de apoio, engloba itens de

verificacao e validacao, os quais fornecem subsıdios para a qualidade do produto a ser

desenvolvido.

A abordagem de desenvolvimento utiliza a Unified Modeling Language (UML), que e

uma linguagem de modelagem que permite aos desenvolvedores visualizar os produtos de

seu trabalho em diagramas padronizados. O uso de especificacoes UML e atrativa por

possuir informacoes relevantes para testes e estar em uso na academia e na maioria das

empresas de tecnologia, de modo que nao ha custos extras associados ao treinamento e

integracao no processo de desenvolvimento de uma aplicacao (Hartmannm et al., 2004).

Na abordagem de teste e utilizado o Perfil UML 2.0 (U2TP), que define uma linguagem


de sistemas (OMG, 2005). A U2TP e uma linguagem de modelagem de testes que pode

ser usada com tecnologias de componentes e linguagens orientadas a objeto, aplicadas em

diversos domınios de aplicacao e auxilia na documentacao, entendimento e ratreabilidade

dos artefatos de teste. Em sua concepcao foram utilizados dois princıpios de projeto:

integracao com UML e reuso. A integracao com a UML refere-se ao fato do perfil ser

baseado no meta-modelo UML, desse modo usando os mesmos princıpios e elementos

dessa linguagem. O reuso esta relacionado a utilizacao, onde possıvel, dos conceitos e

elementos ja presentes em UML. Outra vantagem da U2TP e a definicao de um conjunto

de conceitos proprios a area de testes que podem ser representados e mapeados para

4.1 Visao Geral da Abordagem 51

diferentes ferramentas de testes, como por exemplo: JUnit (teste unitario) e TTCN-3

(teste de integracao e sistema). Os artefatos de teste especificados pela abordagem, sao

os recomendados pela norma IEEE 829, que descreve um conjunto basico de documentos

de teste de software (IEEE, 1998).

A visao geral da abordagem integrada, que mostra o fluxo de informacoes entre as

Disciplinas, e apresentada na Figura 4.1. Cabe ressaltar, que os artefatos gerados sao

passıveis de refinamento nas Disciplinas posteriores.

Figura 4.1: Diagrama de Atividades da Abordagem Integrada de Desenvolvimento eTeste de Software.

A integracao das unidades, independente da granularidade da distribuicao (disciplina,

componente, caso de uso, classe ou metodo), deve ser sempre acompanhada, podendo

ocorrer dentro de cada Disciplina, como tambem, entre as Disciplinas.

Segundo Alves et al. (2008), a integracao dos processos de desenvolvimento e teste pode

trazer diversos benefıcios, dentre eles: reducao do custo de desenvolvimento; alcance de

um alto nıvel de automacao no desenvolvimento e geracao de casos de testes; facilidade

para realizar alteracoes nos requisitos, devido a rastreabilidade provida; e, menores custos

de manutencao.

As secoes seguintes apresentam os aspectos estruturais que organizam o conteudo

das abordagens de desenvolvimento e teste em termos de atividades, artefatos e papeis

envolvidos. Ressalta-se, ainda, que as abordagens de desenvolvimento e teste devem ser

instanciadas em paralelo.


4.2 Abordagem de Desenvolvimento

A Figura 4.2 ilustra a visao geral da abordagem de desenvolvimento, em que e possıvel

visualizar a ordem de execucao das Disciplinas.

Figura 4.2: Diagrama de Atividades da Abordagem de Desenvolvimento.

Outra forma de representar a abordagem e atraves do conjunto de elementos que a

compoem, como pode ser visto na Figura 4.3.

Figura 4.3: Diagrama de Pacotes da Abordagem de Desenvolvimento.

A Tabela 4.1 apresenta os papeis envolvidos, bem como sua descricao.

4.2 Abordagem de Desenvolvimento 53

Tabela 4.1: Papeis na Abordagem de DesenvolvimentoPapeis da Abordagem Descricao

Responsavel pelas atividades relativas ao planejamentoestrategico do projeto (Enami, 2006).

Gerencia as unidades distribuıdas, distribuindo e coor-denando as atividades. (Enami, 2006).

Lidera e coordena a modelagem de casos de uso em-presarial, delimita os processos de negocio que estaoenvolvidos. Conduz e coordena a obtencao de requisitos.

Detalha a especificacao dos requisitos do sistema.

Lidera e coordena as atividades do projeto. Estabelecea estrutura geral de cada visao de arquitetura.

Detalha a especificacao, descrevendo o fluxo de trabalhoe estrutura.

Desenvolve a programacao e realiza os testes de unidadede acordo com os padroes tecnicos e tecnologicos adota-dos para o projeto.

Pessoa ou entidade que solicita o desenvolvimento dosoftware.


Os papeis identificados podem participar de dois modos distintos:

∙ << perform >>: representa que um papel executa uma atividade efetivamente.

∙ << assist >>: indica que um papel auxilia outro no desempenho de suas ativi-

dades.

As Secoes seguintes descrevem cada uma das Disciplinas, sendo elas: Planejamento,

Requisitos, Desenvolvimento e Implementacao. Estas Disciplinas sao representadas sob

quatro perspectivas, as quais sao fornecidas pelos Diagramas de Pacotes, Diagrama de

Casos de Usos, Diagrama de Classes e Diagrama de Atividades.

4.2.1 Disciplina Planejamento

Objetivo

Essa disciplina e responsavel pela configuracao do processo de desenvolvimento e definicao

dos aspectos relacionados ao gerenciamento do projeto. A Figura 4.4 apresenta a Definicao

de Trabalho, mecanismo de divisao semantica para as atividades, que compoe a Disciplina.

Figura 4.4: Diagrama de Pacotes da Disciplina Planejamento.

A Definicao de Trabalho - Configurar o Processo - e detalhada no Diagrama de Pacotes

representado na Figura 4.5, em que e possıvel visualizar os elementos (papeis, atividades

e artefatos) que a constituem.


Figura 4.5: Diagrama de Pacotes da Definicao de Trabalho - Configurar o processo.

Atividades

A Disciplina Planejamento e constituıda pelas seguintes atividades:

∙ definir a configuracao do desenvolvimento (onshore insourcing, outsourcing, off-

shoring ou internal offshoring) a ser adotada para as disciplinas posteriores. De

acordo com L’Erario (2009a) e importante explorar, estrategicamente, as aliancas

entre organizacoes para obter vantagem competitiva a partir da produtividade dis-

tribuıda;

∙ identificar as equipes envolvidas no projeto, bem como seu lıder (Gerente de Projetos

Local) para estimular a confianca e compromisso entre os membros. Na formacao

das equipes deve-se considerar, alem do idioma, questoes de afinidade e habilidades

dos membros. Segundo Cibotto et al. (2009), sempre que possıvel, envolva no


projeto equipes que possuem o mesmo idioma nativo para amenizar os problemas de

comunicacao. Deve-se, tambem, estabelecer a equipe central, que sera responsavel

pela sincronizacao das atividades entre as diversas equipes;

∙ especificar a granularidade em que sera realizada a distribuicao (disciplina, compo-

nente, caso de uso, classe ou metodo). Para estabeler a estrategia de distribuicao

os Gerentes de Projeto Global e Local podem considerar alguns pontos, tais como:

1. uma arquitetura de software modular (baixo acomplamento e alta coesao)

pode ser utilizada para distribuicao dos esforcos entre as equipes pois, reduz a

complexidade e permite um desenvolvimento em paralelo simplificado (Audy e

Prikladnicki, 2008);

2. a proximidade de uma equipe do cliente pode ser considerada para a dis-

tribuicao da disciplina, no caso Requisitos.

3. as habilidades e competencias das equipes envolvidas (modelagem, teste, im-

plementacao).

Cabe ressaltar, que a estrategia de distribuicao adotada tem impacto direto sobre

a intensidade, frequencia e o tipo de coordenacao necessaria entre os participantes

do projeto (Sangwan et al., 2006)

∙ definir uma infraestrutura para comunicacao e colaboracao, tanto interna (equipes

envolvidas no projeto) quanto externa (clientes). Para que essa comunicacao ocorra

de forma adequada, e necessario que a infraestrutura seja definida corretamente.

Geralmente, sao necessarios diversos meios, tais como: viagens, telefone, e-mail,

videoconferencia, ferramentas de gerencia de projetos on-line, instant messengers e

wiki (Al-Asmari e Yu, 2006);

∙ definir um idioma para formalizacao do processo e interacao entre as equipes;

∙ definir infraestrutura para o controle de versao dos artefatos e da documentacao;

∙ definir um repositorio comum a todas as equipes envolvidas no projeto. Os Gerentes

de Projeto Global e Local devem definir os nıveis de acesso de cada integrante

com base nas atividades que estes desempenham e na responsabilidade que lhe e

conferida;

∙ distribuir as atividades entre as equipes envolvidas e seus membros. Weissleder

e Schlingloff (2008) apresentam duas estrategias que podem ser utilizadas para a


distribuicao das atividades: minimizar a colaboracao necessaria entre as equipes,

visto que isso minimiza os impactos negativos dos problemas de comunicacao e

colaboracao; e, minimizar a diferenca entre as equipes, reduzindo o deslocamento

de tempo (fuso-horario) que afeta a comunicacao sıncrona ou as diferencas culturais;

∙ comunicar o que sera realizado por cada equipe, bem como a responsabilidade de

cada membro, para que todos tenham consciencia do que esta acontecendo, das

dependencias, quem esta realizando determinada atividade e em que local ela esta

sendo executada. Audy e Prikladnicki (2008) destacam que essa consciencia e

importante, principalmente, sob a perspectiva da documentacao e do codigo fonte.

Segundo Carmel e Tija (2005), para aumentar a percepcao podem ser utilizadas

algumas tecnicas, tais como, o uso de repositorios comuns, sistemas para controle de

projetos, ambientes de desenvolvimento integrados, reunioes de status, cronograma

das equipes e descricao dos processos.

∙ treinar os envolvidos em relacao a abordagem.

Papeis

Nessa Disciplina ha o Gerente de Projetos Global, que e responsavel por configurar o

processo de desenvolvimento por meio da realizacao das atividades descritas na Secao

anterior e o Gerente de Projetos Local.

O relacionamento entre os papeis e atividades e ilustrado no Diagrama de Casos de

Uso da Figura 4.6, em que e possıvel observar que o Gerente de Projeto Global e auxiliado

pelos Gerentes de Projetos Local na estruturacao do processo.


Figura 4.6: Diagrama de Casos de Uso - Definicao de Trabalho - Configurar o processo.

Artefatos

Os artefatos gerados sao o plano de desenvolvimento de software global e local, que fornece

a linha basica de recursos e cronograma. Nesse artefato sao especificadas informacoes

sobre o escopo do projeto, restricoes, estrutura organizacional, papeis e responsabilidades,

recursos de hardware e software e prazos. O template desse artefato pode ser visto no

Apendice B.

O Diagrama de Classes da Figura 4.7 ilustra o relacionamento dos papeis e artefatos

envolvidos, definindo assim, os responsaveis pela geracao de cada artefato.


Figura 4.7: Diagrama de Classes - Definicao de Trabalho - Configurar o processo.

O fluxo de atividades da Definicao de Trabalho - Configurar o Processo - e representado

pelo Diagrama de Atividades da Figura 4.8, que permite visualizar a precedencia das

atividades, bem como, as que podem ser executadas simultaneamente.


Figura 4.8: Diagrama de Atividades - Definicao de Trabalho - Configurar o processo.

4.2.2 Disciplina Requisitos

Objetivo

Esta disciplina descreve como definir uma visao do sistema e traduzi-la em modelos.

Como metas, tem-se: estabelecer e manter contato com os stakeholders sobre o que o


sistema deve fazer, facilitar o entendimento do desenvolvedor sobre os requisitos atraves

dos modelos gerados e delimitar o escopo do sistema.

As Definicoes de Trabalho que compoem a Disciplina Requisitos sao ilustradas na

Figura 4.9.

Figura 4.9: Diagrama de Pacotes da Disciplina Requisitos.

A Definicao de Trabalho - Definir uma visao do sistema - e detalhada no Diagrama

de Pacotes representado na Figura 4.10, por meio da apresentacao dos papeis, artefatos e

atividades envolvidos.

Figura 4.10: Diagrama de Pacotes da Definicao de Trabalho - Definir uma visao dosistema.

Os elementos (papeis, artefatos e atividades) que compoem a Definicao de Trabalho -

Traduzir a visao em modelos - sao apresentados no Diagrama de Pacotes da Figura 4.11.


Figura 4.11: Diagrama de Pacotes da Definicao de Trabalho - Traduzir a visao emmodelos.

Atividades

A Disciplina Requisitos compreende a realizacao das seguintes atividades:

∙ descrever textualmente o sistema a ser desenvolvido;

∙ representar o modelo do negocio para entender a estrutura e a dinamica, os proble-

mas atuais e identificar potenciais melhorias, que ira gerar a arquitetura inicial do

software (Kruchten, 2003);

∙ elaborar o modelo de objetos de negocio atraves da identificacao dos itens conside-

rados importantes, os quais formam o vocabulario do sistema a ser modelado;

∙ modelar casos de uso. Um caso de uso representa uma funcionalidade do sistema

mostrando as interacoes entre ele e os atores externos. Alem disso, casos de uso sao

faceis de entender e tem uma estrutura simples. Por isso, eles sao uma boa fonte

para os requisitos de testes de sistemas (Guimaraes, 2005).

∙ detalhar as especificacoes dos casos de uso por meio de restricoes utilizando a Object

Constraint Language (OCL) que e uma linguagem de expressoes textuais precisas,

utilizada na descricao de restricoes em modelos orientados a objeto, como forma

de complementar a parte grafica dos modelos, para descrever restricoes, que nao

conseguem ser diagramaticamente representadas. Segundo (Rorato, 2007), a OCL e

uma linguagem formal baseada em modelos, que adota uma sintaxe simples, e que

utiliza sımbolos matematicos mais simples da teoria de conjuntos e logica, numa

proposta de ser precisa, porem de facil compreensao (escrita-leitura) por quem nao


possui conhecimento matematico aprofundado. Um dos mais importantes aspectos

de OCL e que se tornou parte do padrao Unified Modeling Language (UML). No

contexto de DDS, o uso de OCL permite reduzir a ambiguidade gerada nos artefatos

devido aos fatores culturais.

Papeis

Os papeis envolvidos nessa disciplina sao o Engenheiro de Negocios e o Especificador.

As Figuras 4.12 e 4.13 apresentam os Diagramas de Casos de Uso que ilustram os

relacionamentos entre os papeis e as atividades nas Definicoes de Trabalho, Definir uma

visao do sistema e Traduzir a visao em modelos, respectivamente.

Figura 4.12: Diagrama de Casos de Uso - Definicao de Trabalho - Definir uma visao dosistema.

Figura 4.13: Diagrama de Casos de Uso - Definicao de Trabalho - Traduzir a visao emmodelos.

Artefatos

Nesta disciplina e consumido o artefato plano de desenvolvimento e sao produzidas a

descricao textual do sistema, modelo do negocio (arquitetura inicial), o modelo de objetos

de negocio, os diagramas de casos de uso e a descricao extendida de caso de uso (vide

template no Apendice B).


As Figuras 4.14 e 4.15 mostram os relacionamentos entre os papeis e artefatos envolvi-

dos em cada uma das Definicoes de Trabalho.

Figura 4.14: Diagrama de Classes - Definicao de Trabalho - Definir uma visao dosistema.

Figura 4.15: Diagrama de Classes - Definicao de Trabalho - Traduzir visao em modelos.

Nas Figuras 4.16 e 4.17 sao apresentados os fluxos de atividades nas Definicoes de

Trabalho que compoem a Disciplina Requisitos.

Figura 4.16: Diagrama de Atividades - Definicao de Trabalho - Definir uma visao dosistema.


Figura 4.17: Diagrama de Atividades - Definicao de Trabalho - Traduzir visao emmodelos.

4.2.3 Disciplina Desenvolvimento

Objetivo

Essa disciplina objetiva traduzir os artefatos gerados na fase de Requisitos em uma

especificacao que descreve como implementar o sistema.

A Definicao de Trabalho que compoe a Disciplina Desenvolvimento e apresentada na

Figura 4.18.

Figura 4.18: Diagrama de Pacotes da Disciplina Desenvolvimento.

A Figura 4.19 apresenta o Diagrama de Pacotes da Definicao de Trabalho - Especificar

descrevendo como implementar.


Figura 4.19: Diagrama de Pacotes da Definicao de Trabalho - Especificar descrevendocomo implementar.

Atividades

A Disciplina Desenvolvimento e executada por meio da realizacao das seguintes atividades:

∙ modelar a visao estatica do sistema por meio da descricao de um conjunto de objetos

que compartilham os mesmos atributos, operacoes, relacionamentos e semantica;

∙ modelar a sequencia de mensagens entre os objetos;

∙ modelar comunicacao entre os objetos;

∙ refinar descricao da arquitetura apresentada pelo modelo do negocio;

Papeis

Os papeis envolvidos nessa disciplina sao o Arquiteto e o Projetista. O Diagrama de

Casos de Uso que ilustra os relacionamentos entre os papeis e as atividades da Definicao

de Trabalho - Especificar descrevendo como implementar - e apresentado na Figura 4.20.


Figura 4.20: Diagrama de Casos de Uso - Definicao de Trabalho - Especificar de-screvendo como implementar.

Artefatos

Essa disciplina consome os artefatos gerados na disciplina de Requisitos. E produz:

Diagrama de Sequencia, Diagrama de Comunicacao, Diagrama de Classes e Descricao

da Arquitetura.

A Figura 4.21 mostra o relacionamento entre os papeis e artefatos envolvidos.

Figura 4.21: Diagrama de Classes - Definicao de Trabalho - Especificar descrevendocomo implementar.

O fluxo de atividades da Definicao de Trabalho - Especificar descrevendo como imple-

mentar - e apresentado na Figura 4.26.


Figura 4.22: Diagrama de Atividades - Definicao de Trabalho - Especificar descrevendocomo implementar.

4.2.4 Disciplina Implementacao

Objetivo

A Disciplina Implementacao tem como metas a definicao da organizacao do codigo fonte,

a implementacao das classes e objetos e a integracao dos resultados alcancados pelas

diversas equipes em sistema executavel, se essa disciplina, tambem, for distribuıda.

A Figura 4.23 apresenta a Definicao de Trabalho que compoe a Disciplina Imple-

mentacao.

Figura 4.23: Diagrama de Pacotes da Disciplina Implementacao.

O Diagrama de Pacotes da Figura 4.24 mostra os papeis, atividades e artefatos en-

volvidos na Definicao de Trabalho - Implementar os metodos.


Figura 4.24: Diagrama de Pacotes da Definicao de Trabalho - Implementar os metodos.

Atividades

As atividades que compoem essa disciplina sao:

∙ traduzir os modelos gerados nas disciplinas anteriores em codigo fonte;

∙ realizar os testes de unidade;

Papeis

O Desenvolvedor e o papel que desempenha as atividades dessa Disciplina.

O Diagrama de Casos de Uso, apresentado na Figura 4.25, mostra os relacionamentos

entre os papeis e as atividades.

Figura 4.25: Diagrama de Casos de Uso - Definicao de Trabalho - Implementar as classese objetos.


Artefatos

Utiliza como entrada os artefatos da Disciplina de Desenvolvimento e produz o codigo-fonte.

A Figura 4.26 ilustra o fluxo de atividades da Definicao de Trabalho - Implementar as

classes e objetos.

Figura 4.26: Diagrama de Atividades - Definicao de Trabalho - Implementar as classese objetos.

4.3 Abordagem de Teste

O diagrama de atividades da Figura 4.27 mostra a ordem em que disciplinas sao execu-

tadas.

Figura 4.27: Diagrama de Atividades da Abordagem de Teste.

Na Figura 4.28 sao mostrados os elementos que compoem a abordagem de teste.

4.3 Abordagem de Teste 71

Figura 4.28: Diagrama de Pacotes da Abordagem de Teste.

Na abordagem, os papeis foram definidos com base na diretrizes do RUP. A Tabela

4.2 abaixo apresenta os papeis identicados e sua descricao.

Tabela 4.2: Papeis na Abordagem de TestePapeis da Abordagem Descricao

Gerencia as unidades distribuıdas, distribuindo e coor-denando s atividades. (Enami, 2006).

Responsavel pelo planejamento e projeto de testes.

Responsavel pela execucao dos testes, avaliacao daexecucao e dos resultados do testes.

As Secoes seguintes descrevem cada uma das Disciplinas que compoem a abordagem

de testes, sendo elas: Planejamento, Preparacao, Projeto e Execucao. Estas Disciplinas

sao representadas por meio de quatro diagramas: Diagramas de Pacotes, Diagrama de

Casos de Usos, Diagrama de Classes e Diagrama de Atividades.


4.3.1 Disciplina Planejamento

Objetivo

E a disciplina responsavel pela configuracao do processo de teste, trata da definicao dos

fatores relacionados a gerencia. A Figura 4.29 apresenta a Definicao de Trabalho que

compoe a Disciplina.

Figura 4.29: Diagrama de Pacotes da Disciplina Planejamento.

A Definicao de Trabalho - Configurar o Processo - e detalhada no Diagrama de Pacotes

da Figura 4.30.

Figura 4.30: Diagrama de Pacotes da Definicao de Trabalho - Configurar o processo.


Atividades

As atividades que compoem essa disciplina sao:

∙ definir a configuracao do teste (onshore insourcing, offshoring, outsourcing ou inter-

nal offshorring). Essa configuracao pode ser diferente da definida na abordagem de

desenvolvimento. Pode-se optar por terceirizar os testes de integracao, sistemas e de

aceitacao para empresas que sejam especialistas na area. Segundo (Bazman, 2007),

a terceirizacao da atividade de testes pode ser motivada pela reducao de custos,

velocidade, melhoria dos testes e aquisicao de instalacoes de ambientes de teste.

E como, benefıcios tem-se: retorno do investimento; melhoria da confiabilidade do

software; realizacao de uma maior gama de testes; contratacao de equipe de teste

eficiente e qualificada num curto perıodo de tempo; e, maior eficiencia. Em casos

de terceirizacao os artefatos definidos na abordagem deverao ser utilizados de modo

a garantir que as informacoes necessarias resultantes do teste serao entregues. Com

isto, minimiza-se a possibilidade de eventuais impactos negativos causados pela

terceirizacao e diferencas de cultural organizacional.

∙ estabelecer equipe de teste e treinamentos necessarios;

∙ definir os requisitos de ambiente (ferramentas, pessoas e hardware).

Papeis

Os papeis envolvidos sao o Gerente de Projetos Global e o Projetista de Testes. O

relacionamento entre os papeis e atividades e ilustrado no Diagrama de Casos de Uso da

Figura 4.31.

Figura 4.31: Diagrama de Casos de Uso - Definicao de Trabalho - Configurar o processo.


Artefatos

O artefato consumido nessa discplina e o Plano de Desenvolvimento de Software. E, o

artefato produzido e uma versao inicial do Plano de Testes.

A Figura 4.32 apresenta o Diagrama de Classes, em que e possıvel visualizar o rela-

cionamento dos papeis e artefatos envolvidos, definindo assim, os responsaveis pela geracao

de cada artefato.

Figura 4.32: Diagrama de Classes - Definicao de Trabalho - Configurar o processo.

O fluxo de atividades da Definicao de Trabalho - Configurar o processo - e representado

pelo Diagrama de Atividades da Figura 4.33, que permite visualizar a precedencia das

atividades.

Figura 4.33: Diagrama de Atividades - Definicao de Trabalho - Configurar o processo.


4.3.2 Disciplina Preparacao

Objetivo

O objetivo dessa disciplina e descrever o planejamento de todas as atividades envolvidas

no teste de um software. Na Figura 4.34 e apresentada a Definicao de Trabalho que

compoe a Disciplina.

Figura 4.34: Diagrama de Pacotes da Disciplina Preparacao.

A Definicao de Trabalho - Planejar atividades de teste - e detalhada no Diagrama de

Pacotes da Figura 4.35.


Figura 4.35: Diagrama de Pacotes da Definicao de Trabalho - Planejar atividades deteste.

Atividades

A Disciplina Preparacao e composta pelas seguintes atividades:

∙ definir o contexto do teste. Consiste em descrever, resumidamente, as funcionali-

dades e caracterısticas a serem testadas, identificando os objetivos e o escopo do

teste;

∙ caracterizar os itens de teste, levantando informacoes sobre os mesmos e descrevendo-os

de forma resumida;

∙ identificar funcionalidades e caracterısticas (por exemplo, numero de acessos con-

correntes e volume de dados em situacoes de pico) a serem testadas. As tecnicas

de teste baseado em risco constituem um bom indicativo na identificacao de fatores

de riscos associados aos requisitos do software. Essa tecnica pode ser utilizada para

priorizar, com base na probabilidade de ocorrencia e impacto, a maior cobertura

de teste em determinadas funcionalidades do sistema, uma vez que a atividade de

testes e custosa, o domınio de entradas e saıdas e diverso e ha muitas possibilidades

de caminhos a serem testados. Desse modo, pode-se priorizar esforcos e alocar


recursos para as funcionalidades que necessitam ser testadas cuidadosamente (Souza

e Gusmao, 2008);

∙ estabelecer abordagens e criterios. Esta atividade engloba a determinacao da abor-

dagem geral do teste, definicao das atividades, tecnicas e criterios para testar,

selecao de criterios adicionais de termino com base na cobertura e abrangencia,

determinacao dos criterios de aprovacao/reprovacao de cada item de teste e deter-

minacao dos criterios de suspensao e os requisitos para retomada de teste (Souza e

Gusmao, 2008). A partir dos diagramas de casos de uso, podem ser aplicados seis

criterios de teste (Carniello, 2003):

– criterios todas-as-comunicacoes, todas-as-inclusoes e todas-as-extensoes, que

requerem o exercıcio de todos os relacionamentos de cada tipo;

– criterios todas-as-comunicacoes-inclusoes-extensoes que requer o exercıcio de

todos os relacionamentos de um diagrama;

– criterios todos-os-estendidos-combinacoes e todos-os-extensores-combinacoes,

que requerem o exercıcio e o nao-exercıcio dos relacionamentos de extensao.

A especificacao detalhada dos casos de uso possibilita derivar casos de teste da

descricao de fluxo esperado, do fluxo alternativo e dos itens requeridos (Jacobson,

1992);

∙ estabelecer responsabilidades, determinando os responsaveis pelas atividades de

teste;

∙ elaborar cronograma. Consiste em definir os marcos de teste, estimar o tempo e

determinar os prazos para executar cada atividade e utilizar os recursos.

Papeis

O papel envolvido na execucao dessa disciplina e o de Projetista de Teste. O Diagrama

de Casos de Uso da Figura 4.36 mostra o relacionamento entre o papel e as atividades.


Figura 4.36: Diagrama de Casos de Uso - Definicao de Trabalho - Planejar atividadesde teste.

Artefatos

Essa disciplina utiliza como entrada os artefatos gerados na disciplina de Requisitos. E

gera como artefato uma atualizacao do Plano de Teste contendo o planejamento para

execucao do teste, incluindo a abrangencia, abordagem, recursos e cronograma das ativi-

dades de teste. Identifica os itens e as funcionalidades a serem testadas e as tarefas a

serem realizadas.


cionamento dos papeis e artefatos envolvidos.

Figura 4.37: Diagrama de Classes - Definicao de Trabalho - Planejar atividades de teste.

O fluxo de atividades da Definicao de Trabalho - Planejas atividades de teste - e

representado pelo Diagrama de Atividades da Figura 4.38, que permite visualizar a

precedencia das atividades.


Figura 4.38: Diagrama de Atividades - Definicao de Trabalho - Planejar atividades deteste.

4.3.3 Disciplina Projeto

Objetivo

A Disciplina de Projeto objetiva detalhar os aspectos tecnicos a serem adotados na

conducao das atividades de teste. A Figura 4.39 mostra o Diagrama de Pacotes em

que e possıvel visualizar a Definicao de Trabalho que compoe a Disciplina.


Figura 4.39: Diagrama de Pacotes da Disciplina Projeto.

Os elementos que compoem a Definicao de Trabalho - Detalhar Aspectos Tecnicos -

sao apresentados no Diagrama de Pacotes da Figura 4.40.

Figura 4.40: Diagrama de Pacotes da Definicao de Trabalho - Detalhar aspectostecnicos.


Atividades

As atividades que constituem essa disciplina sao:

∙ detalhar abordagens e criterios de teste;

∙ especificar casos de teste. As restricoes OCL realizadas nos metodos das classes

podem ser utilizadas como oraculo (Packevicius, 2007). O Diagrama de Sequencias

pode ser convertido em uma arvore de teste e cada caminho corresponde a um caso

de teste;

∙ estabelecer requisitos de ambiente de teste com base na infraestrutura necessaria;

∙ definir os passos dos procedimentos de teste.

Papeis

O papel envolvido e o Projetista de Teste. O Diagrama de Casos de Uso da Figura 4.41

ilustra o relacionamento entre o Projetista de Teste e as atividades dessa Disciplina.

Figura 4.41: Diagrama de Casos de Uso - Definicao de Trabalho - Detalhar aspectostecnicos.

Artefatos

Esta disciplina utiliza como entrada os gerados na disciplina de Desenvolvimento e os da

Disciplina de Preparacao. E produz como artefatos:

∙ Especificacao de Projeto de Teste: contem um refinamento da abordagem apre-

sentada no Plano de Teste e identifica as funcionalidades e caracterısticas a serem


testadas pelo projeto e por seus testes associados, identifica os casos e os procedi-

mentos de teste;

∙ Especificacao de Casos de Teste: define os casos de teste, incluindo dados de entrada,

resultados esperados, acoes e condicoes gerais para a execucao do teste;

∙ Especificacao de Procedimentos de Teste: especifica os passos para executar um

conjunto de casos de teste.

O Apendice C apresenta o template para cada um desses artefatos.


cionamento dos papeis e artefatos envolvidos.

Figura 4.42: Diagrama de Classes - Definicao de Trabalho - Detalhar aspectos tecnicos.

O fluxo de atividades da Definicao de Trabalho - Detalhar aspectos tecnicos - e

representado pelo Diagrama de Atividades da Figura 4.38, que permite visualizar a

precedencia das atividades.


Figura 4.43: Diagrama de Atividades - Definicao de Trabalho - Detalhar aspectostecnicos.

4.3.4 Disciplina Execucao

Objetivo

Esta disciplina tem por objetivo a execucao e registro das atividades de teste projetadas

nas disciplinas anteriores. A Definicao de Trabalho que compoe a Disciplina Execucao e

apresentada na Figura 4.44.

Figura 4.44: Diagrama de Pacotes da Disciplina Execucao.


A Figura 4.45 apresenta o Diagrama de Pacotes da Definicao de Trabalho - Executar

e registrar testes.

Figura 4.45: Diagrama de Pacotes da Definicao de Trabalho - Executar e registrar testes.

Atividades

A Disciplina Execucao constitui-se das seguintes atividades:

∙ preparar o procedimento de teste, que consiste na sequencia de passos e acoes

necessarias para a execucao de um conjunto de casos de teste relacionados (Crespo

e Jino, 2005);

∙ executar o procedimento de teste;

∙ elaborar o registro de teste com resultado da execucao do teste;


∙ suspender o teste;

∙ encerrar o teste;

∙ registrar as atividades e eventos;

∙ descrever os incidentes do teste, ou seja, qualquer evento que ocorra durante a

execucao do teste e que requeira investigacao, tais como: defeito no software ou

anomalia de funcionamento do ambiente;

∙ elaborar descricao resumida dos itens de teste;

∙ descrever os desvios das especificacoes, ou seja, as discrepancias dos itens de teste

em relacao as especificacoes;

∙ elaborar descricao resumida do resultado do teste;

∙ avaliar os itens de teste.

Papeis

O papel envolvido nessa disciplina e o de Testador.

O Diagrama de Casos de Uso que ilustra os relacionamentos entre o papel Testador

e as atividades da Definicao de Trabalho - Executar e registrar teste - e apresentado na

Figura 4.46.

Figura 4.46: Diagrama de Casos de Uso - Definicao de Trabalho - Executar e registrarteste.


Artefatos

Os artefatos consumidos por essa disciplina sao os gerados nas Disciplinas de Imple-

mentacao e Projeto, e sao produzidos os seguintes artefatos:

∙ Diario de Testes: apresenta registros cronologicos dos detalhes relevantes relaciona-

dos com a execucao dos testes;

∙ Relatorio de Incidentes: documenta qualquer evento que ocorra durante a atividade

de teste e que requeira analise posterior;

∙ Resumo de Tese: apresenta o resumo dos resultados das atividades de teste associa-

das com uma ou mais especificacoes de projeto de teste e prove avaliacoes baseadas

nesses resultados.

No Apendice C sao apresentados os templates dos artefatos descritos.

A Figura 4.47 mostra o relacionamento entre os papeis e artefatos envolvidos.

Figura 4.47: Diagrama de Classes - Definicao de Trabalho - Executar e registrar teste.

O fluxo de atividades da Definicao de Trabalho - Executar e registrar teste - e apre-

sentado na Figura 4.48.


Figura 4.48: Diagrama de Atividades - Definicao de Trabalho - Executar e registrarteste.


A abordagem abrange um conjunto de atividades que devem ocorrer ao longo do ciclo

de vida de um projeto e as caracterısticas essenciais de cada uma. Considera atividades

desde o modelo de negocios a ser adotado para atuar em DDS (empresas globais, parcerias

estrategicas, entre outros) ate a implementacao, fornecendo aos membros das equipes

uma linguagem comum para definicao das tarefas, atividades e marcos do projeto, o que

auxilia no processo de coordenacao. Alem disso, oferece mecanismos para a padronizacao

e reducao da imprecisao dos artefatos, o que reduz e facilita a comunicacao entre as

equipes.


Capıtulo

5

Exemplo de Aplicacao da Abordagem

Este capıtulo apresenta um exemplo de aplicacao da abordagem descrita no Capıtulo 4 e

serve como prova de conceito. Esse tipo de estudo e realizado por meio da descricao do

funcionamento da abordagem em um determinado exemplo, que pode ser real ou nao. A

prova de conceito caracteriza-se pela falta de formalizacao durante a realizacao do estudo,

o autor nao utiliza os conceitos de experimentacao, o que inviabiliza obter conclusoes

sobre a real viabilidade e funcionalidade da abordagem (Kitchenham et al., 2002).

5.1 Cenario

Para efeitos de instanciacao da abordagem foi considerado um projeto de desenvolvimento

de uma aplicacao web para gerenciar o processo de submissao e avaliacao de artigos em

eventos cientıficos. Devido a limitacoes de tempo, nao foi possıvel instanciar a abordagem

em um projeto real. Desse modo, optou-se pela realizacao de uma prova de conceito.

As sessoes seguintes descrevem o instaciamento da abordagem para o cenario proposto.

Sao apresentadas cada uma das disciplinas de desenvolvimento e teste.

5.2 Disciplina Planejamento - Desenvolvimento

Na execucao dessa disciplina foram definidos os aspectos relacionados ao gerenciamento

do projeto, em que foram alocadas duas equipes, uma localizada em Maringa-PR e a outra

em Belo Horizonte-MG. Na definicao da estrategia de distribuicao foram considerados os

89

90 5. Exemplo de Aplicacao da Abordagem

criterios de proximidade com o cliente e as habilidades e competencias dos membros das

equipes.

Devido a proximidade do cliente, nao houve a necessidade de definicao de uma in-

fraestrutura de apoio a comunicacao, sendo utilizadas reunioes presenciais. Para a co-

municacao entre as duas equipes foram utilizadas as seguintes ferramentas: Windows

Live Messenger, Skype, e-mail e o DotProject. Como nao ha diferenca de idioma entre as

equipes envolvidas, foi adotado o Portugues para interacao. A comunicacao da abordagem

a todos os membros das equipes envolvidas ocorreu por meio da documentacao.

A seguir (Tabelas 5.1, 5.2 e 5.3) sao apresentados o Plano Global e os Planos Locais

de Desenvolvimento de Software.

5.2 Disciplina Planejamento - Desenvolvimento 91

Tabela 5.1: Plano Global de Desenvolvimento

Identificacao do Projeto: MSPaper

Finalidade: Desenvolver uma aplicacao web para apoiar as atividades relacionadasa submissao e revisao de artigos de eventos cientıficos.

Escopo: Este documento descreve o plano geral a ser usado pelo projeto de desenvolvimentoda aplicacao MSPaper. Fornecendo a todos os membros das equipes envolvidas visibilidadeadequada sobre o projeto.

Restricoes: (i) Numero de envolvidos no projeto; (ii) Prazo;

Site Central: MaringaIdioma: Portugues Fuso-horario: Brasılia

Gerente de Projetos Global: Gislaine Camila Lapasini Leal

Idioma do Projeto: Portugues

Configuracao do Desenvolvimento: onshore insourcing

Estrategia de Distribuicao: Disciplina

Sites Envolvidos: Maringa e Belo Horizonte

Estrutura Organizacional: 2 analistas e 1 desenvolvedor.

Papeis e responsabilidades:Site Maringa:Requisitos (Desenvolvimento)Desenvolvimento (Desenvolvimento)Site Belo Horizonte:Implementacao (Desenvolvimento)

RecursosHardware:

(i) Computador pessoal dos participantes;(ii) Servidor para a ferramentade de Gerencia de ProjetosSoftware:

(i) DotProject - ferramenta para gestao do projeto(ii) Jude - ferramenta para modelagem UML;(iii) Netbeans 6.8 - ambiente de desenvolvimento;(iv) Postgresql - sistema de gerenciamento de banco de dados

Ferramentas de comunicacao: (i) DotProject; (ii) Windows Live Messenger;(iii) e-mail; (iv) Skype

Cronograma:Data de inıcio: 22/02/2010Data de termino: 20/03/2010


Tabela 5.2: Plano Local de Desenvolvimento - Site Maringa

Escopo: Este documento descreve o plano geral a ser usado pela equipe local no desenvolvimentoda aplicacao MSPaper.


Gerente de Projetos Local: Gislaine Camila Lapasini Leal

Disciplina:Requisitos (Desenvolvimento)Desenvolvimento (Desenvolvimento)

Papeis e responsabilidades:Gislaine Camila Lapasini LealGustavo Sato

RecursosHardware:

(i) Computador pessoal dos participantes;(ii) Servidor para a ferramentade Gerencia de ProjetosSoftware:

(i) DotProject - ferramenta para gestao do projeto(ii) Jude - ferramenta para modelagem UML;



Tabela 5.3: Plano Local de Desenvolvimento - Belo Horizonte

Escopo: Este documento descreve o plano geral a ser usado pela equipe local na implementacaoda aplicacao MSPaper.


Gerente de Projetos Local: Cesar Alberto da Silva

Disciplina:Implementacao (Desenvolvimento)

Papeis e responsabilidades:Cesar Alberto da SilvaDesenvolvedor: geracao de codigo e teste de unidade.

RecursosHardware:

(i) Computador pessoal dos participantes;Software:

(iii) Netbeans 6.8 - ambiente de desenvolvimento;(iv) Postgresql - sistema de gerenciamento de banco de dados(iv) JSFUnit - teste de unidade



5.3 Disciplina Planejamento - Teste 93

5.3 Disciplina Planejamento - Teste

Nessa disciplina foi definido o modelo de negocio da abordagem de teste, que e onshore

insourcing. A equipe responsavel por todos as disciplinas dessa abordagem esta localizada

em Maringa. Tambem, foram definidas as ferramentas e pessoas envolvidas na execucao.

Na Tabela 5.4 e apresentada a versao inicial do Plano de Teste.

Tabela 5.4: Plano de Teste - versao inicial



Configuracao do Teste: onshore insourcing

Estrategia de Distribuicao: Disciplinas

Sites Envolvidos: Maringa

Papeis e responsabilidades:Site Maringa:Planejamento (Teste)Preparacao (Teste)Projeto (Teste)Execucao (Teste)

RecursosHardware:

(i) Computador pessoal dos participantes;(ii) Servidor para a ferramentade Gerencia de Projetos

5.4 Disciplina Requisitos - Desenvolvimento

Na execucao dessa disciplina foi estabelecido contato com o stakeholder (Profa. Elisa H.

M. Huzita). Como a equipe responsavel por essa disciplina esta localizada na mesma

cidade do stakeholder, foram realizadas duas reunioes presenciais para coleta dos requi-

sitos. Os papeis de Engenheiro de Negocios e Especificador foram desempenhados pelo

mesmo ator. Com base nos dados obtidos pelo Engenheiro de Negocios, na entrevista, foi

elaborada a descricao textual do MSPaper, que pode ser vista no Apendice D. A partir

da descricao textual, foram gerados os demais artefatos, que sao apresentados a seguir.

Na Figura 5.1 e ilustrada a visao de negocios da gestao de eventos.


Figura 5.1: Visao do Negocio.

O modelo de objetos de negocio para o MSPaper e apresentado na Figura 5.2.

Figura 5.2: Modelo de Objetos de Negocios.

A visao estatica do MSPaper e representada atraves dos casos de uso, atores e rela-

cionamentos identificados, os quais sao ilustrados na Figura 5.3. No Apendice D e

apresentada a especificacao estendida dos casos de uso.

5.5 Disciplina Preparacao - Teste 95

Figura 5.3: Diagrama de Casos de Uso.

5.5 Disciplina Preparacao - Teste

Essa disciplina descreve o planejamento das atividades envolvidas no teste do MSPaper,

identificando as funcionalidades e caracterısticas a serem testadas e os responsaveis. A

Tabela 5.5 apresenta o Plano de Teste gerado.

Tabela 5.5: Plano de Teste


Finalidade: Desenvolver e aplicar testes.

Escopo: Este documento descreve o plano de testes ser usado pelo projeto de desenvolvimentoda aplicacao MSPaper. Fornecendo a todos os membros das equipes envolvidas visibilidadeadequada sobre o projeto.

Funcionalidades: Gerenciar evento; Submeter artigo e Revisar artigo.


Configuracao do Teste: onshore insourcing

Estrategia de Distribuicao: Disciplinas

Sites Envolvidos: Maringa - Gerente Local: Elisa Hatsue Moriya Huzita - Idioma: Portugues

Papeis e responsabilidades:Site Maringa:Planejamento (Teste) - elaborar o plano de testePreparacao (Teste) - refinar o plano de testeProjeto (Teste) - projetar os casos de testeExecucao (Teste) - executar os casos de teste

RecursosHardware:

(i) Computador pessoal dos participantes;(ii) Servidor para a ferramentade Gerencia de Projetos



5.6 Disciplina Desenvolvimento - Desenvolvimento

Nessa Disciplina os papeis de Arquiteto e Especificador foram desempenhados pelo mesmo

ator. Quanto a comunicacao, nao foram estabelecidos contatos presenciais. Esses contatos

foram realizados utilizando as ferramentas definidas na Disciplina de Planejamento.

A Descricao da Arquitetura para a aplicacao MSPaper e apresentada na Figura 5.4.

Figura 5.4: Descricao da Arquitetura.

No Diagrama de Classes da Figura 5.5 e possıvel visualizar a estrutura e a relacao

entre as classes da aplicacao.

5.6 Disciplina Desenvolvimento - Desenvolvimento 97

Figura 5.5: Diagrama de Classes.

A Figura 5.6 ilustra o Diagrama de Comunicacao - Submissao de Artigos - em que se

pode observar a interacao entre os objetos por meio das mensagens trocadas. Da mesma

forma, foram elaborados diagramas de comunicacao para gerenciar evento, distribuir

artigo, revisar e consolidar resultados.


Figura 5.6: Diagrama de Comunicacao - Submissao de Artigos.

A Figura 5.7 ilustra o Diagrama de Sequencia - Submissao de Artigos - em que se

pode observar como os objetos colaboram ao longo do tempo. Do mesmo modo, foram

elaborados diagramas de sequencia para gerenciar evento, distribuir artigo, revisar e

consolidar resultado.

Figura 5.7: Diagrama de Sequencia - Submissao de Artigos.

5.7 Disciplina Projeto - Teste 99

5.7 Disciplina Projeto - Teste

Nessa Disciplina foram detalhados os aspectos tecnicos relacionados a conducao das

atividades de teste. Desse modo, foram gerados tres artefatos: Especificacao de Projeto

de Teste (Tabela 5.6); Especificacao de Casos de Teste (Tabela 5.7) e Especificacao de

Procedimentos de Teste (Tabela 5.8).

Tabela 5.6: Especificacao de Projeto de Teste


Responsavel: Site Maringa - Gerente de Projetos: Elisa - Idioma: Portugues

Tecnicas de Teste: Caixa-preta

Criterios de Teste: Descricao do fluxo experado, alternativo e itens requeridos (pre e pos-condicoes)dos casos de uso e caminhos do diagrama de sequencia.

Criterios de Parada: Prazo do projeto.

Tabela 5.7: Especificacao de Casos de Teste



CT Pacote Descricao Dependencia1 Gerenciar evento Cadastrar evento e vincular Presidente do Comite Usuario2 Gerenciar evento Revisoes por artigo -3 Gerenciar evento Prazo de submissao -4 Gerenciar evento Data de devolucao das submissoes -5 Gerenciar evento Data de notificacao -6 Gerenciar evento Percentual de artigos aceitos -7 Submeter artigo Enviar artigo Evento8 Submeter artigo Formato do arquivo -9 Revisar artigo Artigos disponıves Evento Usuario10 Revisar artigo Revisao de artigo -11 Revisar artigo Relevancia -12 Revisar artigo Conteudo Tecnico -13 Revisar artigo Rigor Cientıfico -14 Revisar artigo Originalidade -15 Revisar artigo Qualidade da Escrita -16 Revisar artigo Avaliacao Global -


Tabela 5.8: Especificacao de Procedimentos de Teste



CT Roteiro Resultado Esperado1 1. Inserir evento.

2. Selecionar usuario Presidente Comite Cientıfico.3. Definir datas.4. Adicionar temas.5. Salvar dados. Persistencia dos dados.

2 1. Inserir numero de revisoes por artigo menor ou igual a 0.2. Salvar dados. Emitir mensagem solicitando valor

maior que zero. Nao persistir os dados.

3 1. Inserir prazo de submissao menor que a data atual.2. Salvar dados. Emitir mensagem informando que

o prazo de submissao deve ser posteriora data atual. Nao persistir os dados.

4 1. Inserir data de devolucao das correcoes menorque a data atual.2. Salvar dados. Emitir mensagem informando que o

prazo de devolucao deve ser posterior adata de submissao. Nao persistir os dados.

5 1. Inserir data de notificacao menor que a dataatual.2. Salvar dados. Emitir mensagem informando que o

a data de notificacao deve ser posterior adata atual. Nao persistir os dados.

6 1. Inserir data de notificacao menor que a datade devolucao das revisoes.2. Salvar dados. Emitir mensagem informando que o

a data de notificacao deve ser posterior adata de devolucao das revisoes. Naopersistir os dados.

7 1. Inserir percentual de artigos aceitos menor ouigual a zero.2. Salvar dados. Emitir mensagem informando que o

percentual deve ser maior que 0.Nao persistir os dados.

8 1. Selecionar o evento.2. Selecionar tema.3. Preencher palavras-chave.4. Inserir resumo.5. Adicionar coautor.6. Enviar arquivo formato ”.pdf”. Persistencia dos dados.

Upload do arquivo

9 1. Selecionar o evento.2. Selecionar tema.3. Preencher palavras-chave.4. Inserir resumo.5. Adicionar coautor.6. Enviar arquivo formato ”.doc”. Nao persistir os dados.

Solicitar aquivo em formato ”.pdf”.

5.8 Disciplina Implementacao - Desenvolvimento 101

Tabela 5.9: Continuacao da Tabela Especificacao de Procedimentos de Teste

10 1. Acessar area de artigos para revisao. Visualizar artigos dos eventos em que adata atual e menor que a data dedevolucao da correcao.

11 1. Inserir espacos em branco no campo revisao do artigo.2. Salvar dados. Emitir mensagem solicitando o

preenchimento do campo.Nao persistir os dados.

12 1. Inserir espacos em branco no campo relevancia.2. Salvar dados. Emitir mensagem solicitando o


13 1. Inserir espacos em branco no campo conteudo tecnico.2. Salvar dados. Emitir mensagem solicitando o


14 1. Inserir espacos em branco no campo rigor cientıfico.2. Salvar dados. Emitir mensagem solicitando o


15 1. Inserir espacos em branco no campo originalidade.2. Salvar dados. Emitir mensagem solicitando o


16 1. Inserir espacos em branco no campo qualidade da escrita.2. Salvar dados. Emitir mensagem solicitando o


17 1. Inserir espacos em branco no campo avaliacao global.2. Salvar dados. Emitir mensagem solicitando o


5.8 Disciplina Implementacao - Desenvolvimento

Essa Disciplina foi executada pela equipe de Belo Horizonte-MG, que tomando como base

os artefatos gerados nas Disciplinas anteriores e utilizando o ambiente de desenvolvimento

Netbeans 6.8 e o sistema de gerenciamento de banco de dados Postgresql, a aplicacao

MSPaper foi desenvolvida.


A Figura 5.8 mostra a interface de login para acesso ao MSPaper.

Figura 5.8: Interface de Login.

Na Figura 5.9 tem-se a interface em que o Presidente do Comite Cientıfico pode

visualizar os eventos nos quais e chair.

Figura 5.9: Interface da Lista de Eventos.

A interface para submissao de artigos e ilustrada na Figura 5.10.

5.8 Disciplina Implementacao - Desenvolvimento 103

Figura 5.10: Interface de Submissao de Artigo.

As Figuras 5.11 e 5.12 mostram a lista de artigos que o revisor possui para revisar e

a interface em que os dados da revisao sao registrados, respectivamente.

Figura 5.11: Interface do Revisor de Artigo.


Figura 5.12: Interface de Revisao.

5.9 Disciplina Execucao - Teste

Nessa disciplina foram executadas e registradas as atividades de teste. Devido ao escopo

reduzido do projeto nao houveram incidentes de teste.

Os artefatos Diario de Testes e Resumo de Teste sao apresentados nas Tabelas 5.10 e

5.11, respectivamente.

5.9 Disciplina Execucao - Teste 105

Tabela 5.10: Diario de Teste



Ambiente de execucao: Intel Core 2 Duo Processor T6400, 4GB SDRAM, 320GB HDD

CT Responsavel Resultado EventosnaoEsperado

Data

1 Camila Dados persistidos corretamente. - 22/03/2010

2 Camila Mensagem solicitando valor maior que 0. - 22/03/2010

3 Camila Mensagem informando que a data de submissao - 22/03/2010deve ser maior que a data atual.

4 Camila Mensagem informando que a data de devolucao - 22/03/2010deve ser maior que a data de submissao.

5 Camila Mensagem informando que a data de notificacao - 22/03/2010deve ser maior que a data atual.

6 Camila Mensagem informando que a data de notificacao - 22/03/2010deve ser posterior a data de devolucao das revisoes.

7 Camila Dados persistidos. Percentualmenor quezero.

22/03/2010

8 Camila Dados persistidos e arquivo carregado - 22/03/2010

9 Camila Dados persistidos. Uploadformato”.doc”

22/03/2010

10 Camila Visualizacao dos artigos que a data de 22/03/2010atual e menor que a data de devolucao da correcao.

11 Camila Dados nao persistidos. - 22/03/2010

12 Camila Dados nao persistidos - 22/03/2010







Tabela 5.11: Resumo do Teste



Inıcio dos Testes: 21/03/2010 Fim dos Testes: 22/03/2010

Numeros do Teste

Casos de Teste criados antes do inıcio dos testes 16

Casos de Teste criados durante os testes 1

Casos de Teste executados 17

Casos de Teste executados com sucesso 15

Casos de Teste executados com erro 2

Casos de Teste enviados para correcao 2

Percentuais do Teste

Casos de Teste executados 100%

Casos de Teste executados com sucesso 88%

Casos de Teste executados com incidencia de erro 0%

Casos de Teste corrigidos 100%


A prova de conceito apresentada ilustra como a abordagem descrita no Capıtulo 4 pode

ser instanciada, nao tendo como objetivo extrair conclusoes sobre a real viabilidade e

funcionalidade da abordagem. Algumas dificuldades encontradas e que inviabilizaram a

conducao de um estudo experimental foram:

∙ no ambito regional, ha dificuldade em encontrar empresas que utilizem essa con-

figuracao de desenvolvimento.

∙ os projetos desenvolvidos utilizando a estrategia distribuıda, geralmente, sao de

grande porte, o que demandaria um prazo maior para o acompanhamento do projeto.

∙ dificuldade de reunir equipes dispersas, mesmo no meio academico, que tenham

disponibilidade para participar do experimento.

A prova de conceito exposta apresenta limitacoes em relacao ao numero de participantes

e equipes envolvidas. Alem disso, as equipes utilizam o mesmo idioma, as diferencas

socioculturais sao pequenas e nao ha diferenca de fuso horario. No entanto, esta prova

de conceito nao tem o intuito de validar a abordagem proposta mas, sim elucidar o seu

funcionamento. O Capıtulo seguinte descreve o estudo de viabilidade realizado.

Capıtulo

6

Estudo de Viabilidade

Este capıtulo apresenta um estudo de viabilidade, tambem denominado de projetos quasi-

experimental, da abordagem descrita no Capıtulo 4. Esse estudo tem por objetivo coletar

evidencias, pontos fortes e fracos sobre a abordagem proposta.

A principal caracterıstica de um estudo de viabilidade e que os dados sao coletados

de acordo com algum projeto experimental, mas nao ha controle sobre todas as variaveis.

O objetivo nao e encontrar uma resposta definitiva, mas sim, construir um corpo de

conhecimento que aborda a plausibilidade da continuidade do estudo, gerar nova hipoteses

sobre a abordagem e sua utilidade (Shull et al., 2001).

6.1 Definicao dos Objetivos

Esta etapa discorre sobre os objetivos do estudo de viabilidade sobre tres perspectivas:

global, da medicao e do estudo.

6.1.1 Objetivo Global

Caracterizar a viabilidade da abordagem integrada de desenvolvimento e teste de software

para equipes distribuıdas.

6.1.2 Objetivo da Medicao

Investigar e caracterizar a abordagem com relacao a viabilidade para o contexto de DDS.

107

108 6. Estudo de Viabilidade

6.1.3 Objetivo do Estudo

Analisar a abordagem integrada de desenvolvimento e teste de software para equipes

distribuıdas.

Com o proposito de caracterizar

Com respeito a viabilidade das atividades, artefatos e papeis definidos pela abor-

dagem

Do ponto de vista do pesquisador

No contexto de pessoas envolvidas com o desenvolvimento distribuıdo de software.

6.1.4 Questoes

∙ Q1: As atividades presentes na abordagem sao suficientes para apoiar o DDS?

Metrica: A lista de atividades oferecidas pela abordagem.

∙ Q2: O artefatos presentes na abordagem sao suficientes para apoiar o DDS, servindo

como comunicacao entre as equipes de desenvolvimento e teste?

Metrica: A lista de artefatos especificados pela abordagem.

6.2 Planejamento

Esta etapa prepara como o estudo sera conduzido e compoe-se pelos seguintes passos:

formulacao da hipotese, selecao do contexto, selecao de variaveis, selecao de participantes

e projeto do estudo.

6.2.1 Definicao das Hipoteses

∙ H0: A abordagem integrada de desenvolvimento e teste de software nao contempla

todas as peculiaridades do desenvolvimento distribuıdo.

∙ H1: A abordagem integrada de desenvolvimento e teste de software contempla todas

as peculiaridades do desenvolvimento distribuıdo.

6.2.2 Selecao do Contexto

O estudo foi conduzido por meio de questionarios que foram enviados eletronicamente aos

participantes com conhecimento no domınio que abrange o estudo.

6.2 Planejamento 109

6.2.3 Selecao dos Participantes

Os participantes foram selecionados com base nos conhecimentos sobre desenvolvimento

distribuıdo de software e disponibilidade, ou seja, nao foram escolhidos de forma aleatoria.

O estudo foi conduzido no ambiente academico, que de acordo com (Shull et al., 2001)

e adequado para estudos de viabilidade. Embora os resultados nao possam ser aplicados

diretamente no meio industrial, permitem que novos conceitos sejam testados antes de

seu uso na industria.

6.2.4 Projeto do Estudo

Apos a tabulacao dos dados, sera realizada uma analise descritiva dos resultados e medidas

de dispersao. Em seguida sera aplicado o teste qui-quadrado para analisar os resultados.

Esse teste se destina a encontrar um valor de dispersao para duas variaveis nominais,

avaliando a associacao existente entre variaveis qualitativas. O princıpio basico deste

metodo e comparar proporcoes, isto e, as possıveis divergencias entre as frequencias

observadas e esperadas para um dado evento.

A escala de mensuracao adotada para as variaveis dependentes, relacionadas ao perfil

do entrevistado: 0 - Nenhum; 1 - Basico; 2 - Intermediario; 3 - Avancado.

A escala de mensuracao utilizada para as variaveis independentes, relacionadas ao

estudo de viabilidade: 0 - Nenhum; 1 - Baixo; 2 - Intermediario; 3 - Satisfatorio.

6.2.5 Instrumentacao

Com o objetivo de caracterizar cada participante foi utilizado o questionario Perfil do

Entrevistado, contendo questoes que estao relacionadas com as variaveis independentes,

por exemplo: experiencia com desenvolvimento de sistemas, conhecimento em desenvolvi-

mento distribuıdo de software, gerencia de projetos e teste de software.

Com o objetivo de avaliar a abordagem integrada foi utilizado o questionario Estudo

de Viabilidade, contendo as respostas, que correspondem as variaveis dependentes de cada

participante, por exemplo: grau em que o conjunto de disciplinas, atividades, artefatos

atende ao DDS. Foi elaborado um memorial descritivo apresentando o objetivo do estudo,

as principais caracaterısticas da abordagem e o Diagrama de Pacotes de cada uma das

disciplinas, em que e possıvel visualizar os papeis, atividades e artefatos envolvidos.

Os documentos utilizados na instrumentacao podem ser vistos no Apendice E.


6.2.6 Validade

Uma questao fundamental com relacao aos resultados do estudo e identificar quao validos

eles sao, pois estes devem ser generalizados. Ha quatro tipos de validade: interna, externa,

construtiva e conclusiva, as quais sao descritas a seguir (Travassos, 2002).

Validade Interna

Esse tipo de validade refere-se ao tratamento-resultado e seus riscos estao relacionados aos

participantes, que podem ficar cansados ou desanimados. Desse modo, reforca-se a neces-

sidade de uma instrumentacao preparada adequadamente para evitar mal entedimento, o

que pode afetar os resultados negativamente (Travassos, 2002).

No estudo em questao os participantes foram selecionados com base no conhecimento

sobre desenvolvimento distribuıdo de software. A validade interna e dependente do

numero de participantes, quanto maior o numero de participantes melhor sera a validade

interna.

Validade Externa

A validade externa e relacionada as condicoes que limitam a habilidade de generalizar

os resultados. Essa validade e dependente da capacidade do estudo refletir o mesmo

comportamento em outros grupos de participantes e profissionais da industria, ou seja,

em outros grupos alem daquele em que o estudo foi aplicado (Travassos, 2002).

Os dados do perfil dos indivıduos podem ser analisados para avaliar o nıvel de ex-

periencia e conhecimento em desenvolvimento distribuıdo de software. O maior problema

que pode ocorrer em relacao a validade externa e elevado numero de pessoas do meio

academico em relacao ao meio industrial.

Validade Construtiva

A validade construtiva considera os relacionamentos entre a teoria e a observacao, ou seja,

se o tratamento reflete bem a causa e o resultado reflete bem o efeito. Os problemas a

serem considerados referem-se ao fato dos participantes se basearem nas hipoteses e na

expectativa do pesquisador (Travassos, 2002).

Validade Conclusiva

Esse tipo de validade relaciona-se a habilidade de chegar a uma conclusao correta a

respeito dos relacionamentos entre o tratamento e os resultados do experimento. Para

6.3 Operacao 111

tanto sao considerados os seguintes elementos: teste estatıstico e o tamanho do conjunto

de participantes (Travassos, 2002).

A validade conclusiva mensura a relacao entre o tratamento e o resultado, determi-

nando a capacidade do estudo em gerar alguma conclusao. A obtencao de boas conclusoes

sera permitida por meio de uma boa definicao das variaveis independentes e dependentes

juntamente com as analises descritivas adequadas e o teste qui-quadrado.

6.3 Operacao

Um roteiro (memorial descritivo) explicando a abordagem, juntamente com os ques-

tionarios do perfil do entrevistado e estudo de viabilidade foram encaminhados para 16

pessoas.

O roteiro explica a finalidade do estudo, os objetivos da abordagem e apresenta o

Diagrama de Pacotes de cada Disciplina, que contem as atividades, os papeis envolvidos

e artefatos gerados.

6.3.1 Resultados do Estudo

A Tabela 6.1 apresenta os resultados obtidos para as variaveis independentes (A - C) e

dependentes (D- L), em que:

∙ (A): Conhecimento em Desenvolvimento Distribuıdo de Software.

∙ (B): Experiencia em Gerencia de Projetos.

∙ (C): Conhecimento em teste de software.

∙ (D): Conjunto de disciplinas e satisfatorio para o DDS.

∙ (E): Conjunto de atividades atende as necessidades do DDS.

∙ (F): Conjunto de artefatos atende as necessidades do DDS.

∙ (G): Uso de notacao (UML) oferece informacoes relevantes para as duas equipes

(desenvolvimento e teste) pode amenizar os problemas de comunicacao.

∙ (H): Identificacao das equipes, bem como de seus membros e responsabilidades

atraves dos Planos de Desenvolvimento Global, Plano de Desenvolvimento Local e

Plano de Testes.


∙ (I): Nomenclatura comum a todos os envolvidos no projeto possibilita entender a

dependencia das atividades e artefatos.

∙ (J): Uso de OCL (Object Constraint Language) para especificar restricoes.

∙ (K): Impacto da padronizacao dos artefatos e atividades na qualidade dos produtos

desenvolvidos.

∙ (L): Atividades de teste ao longo de todas as disciplinas.

Na Tabela 6.1 a escala de mensuracao adotada e: 0 - Nenhum; 1 - Baixo; 2 -

Intermediario; 3 - Satisfatorio.

Tabela 6.1: Resultados do Estudo de ViabilidadeN A B C D E F G H I J K L1 2 0 1 3 3 3 2 2 3 2 3 32 2 2 2 3 3 3 2 2 3 3 3 33 2 1 2 3 3 3 2 3 2 2 2 34 2 1 1 2 2 2 3 2 3 3 2 35 2 0 1 3 3 2 2 3 3 2 2 36 3 1 1 3 2 3 2 3 2 2 3 37 2 2 2 2 2 3 3 2 3 3 3 38 2 1 1 2 2 3 3 2 2 3 2 29 3 2 2 3 3 3 3 3 2 2 1 310 1 1 1 2 3 3 3 3 2 2 3 311 3 1 1 3 3 3 3 2 3 2 2 312 2 0 3 3 3 3 3 3 3 3 3 2

6.4 Analise e Interpretacao dos Dados

A Analise e Interpretacao dos Dados divide-se em quatro etapas: Validacao dos Dados,

Estatıstica Descritiva e Analise, Aplicacao do Teste Estatıstico e Verificacao das Hipoteses.

A seguir essas etapas sao descritas.

6.4.1 Validacao dos Dados

No estudo foram utilizados 12 participantes, todos responderam ao questionario Perfil do

Entrevistado e Estudo de Viabilidade. Nao foram encontrados outliers nas respostas dos

questionarios.

6.4 Analise e Interpretacao dos Dados 113

6.4.2 Estatıstica Descritiva e Analise

A tabulacao e apresentacao de dados sao fundamentais ao bom julgamento estatıstico pois

permitem focar em caracterısticas relevantes a serem utilizadas na solucao de problemas.

Desse modo, as medidas de tendencia central, no caso mediana e moda, pois os valores

estao em escala ordinal, organizam a amostra destacando os acontecimentos (Montgomery

e Runger, 2009).

A mediana divide os dados em duas partes iguais. Se o numero de observacoes for

par, a mediana estara na metade da distancia entre os dois valores centrais. Se o numero

de observacoes for ımpar, a mediana sera o valor central. A moda e o valor da observacao

que ocorre com mais frequencia (Montgomery e Runger, 2009).

A Tabela 6.2 apresenta a estatıstica descritiva (mediana e a moda) dos dados coletados.

Tabela 6.2: Estatıstica DescritivaA B C D E F G H I J K L

Mediana 2 1 1 3 3 3 3 2,5 3 2 2,5 3Moda 2 1 1 3 3 3 3 2 3 2 3 3

Apos a tabulacao dos dados foram gerados graficos utilizando a ferramenta GNUPlot

4.0, que sao apresentados nas Figuras 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8 e 6.9. Esses graficos

ilustram a relacao entre o conhecimento dos participantes em Desenvolvimento Distribuıdo

de Software, Experiencia em Gerencia de Projetos/Conhecimento em teste de software,

e, a terceira coordenada, representa as caracterısticas da abordagem proposta que foram

analisadas: Disciplinas (Figura 6.1), Atividades (Figura 6.2), Artefatos (Figura 6.3, uso

de UML para amenizar os problemas de comunicacao (6.4), Identificacao das Equipes

para aumentar a percepcao (Figura 6.5), uso de OCL para amenizar a imprecisao dos

artefatos (Figura 6.7), padronizacao dos artefatos e atividades (Figura 6.8) e atividades

de teste (Figura 6.9).

Nas Figura 6.1, 6.2 e 6.3 pode-se observar que os participantes com conhecimento in-

termediario/avancado em DDS, experiencia basica/intermediaria em Gerencia de Projetos

avaliaram que as Disciplinas, Atividades e Artefatos propostos na abordagem contemplam

de modo intermediario/satisfatorio as necessidades do DDS. O vale apresentado representa

os participantes que nao possuem experiencia em Gerencia de Projetos.


Figura 6.1: Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Disciplinas.

Figura 6.2: Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Atividades.


Figura 6.3: Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Artefatos.

A Figura 6.4 mostra que os participantes com conhecimento intermediario/avancado

em DDS, indiferente da experiencia em Gerencia de Projetos avaliaram que a notacao

UML, atraves das informacoes oferecidas para as equipes de desenvolvimento e teste,

pode amenizar os problemas de comunicacao em grau intermediario/satisfatorio.


Figura 6.4: Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x UML.

Na Figura 6.5, o grafico evidencia dois picos, em relacao a identificacao das equipes e

seus membros como mecanismo para aumentar a percepcao de modo intermediario/satisfatorio.

Figura 6.5: Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Identificacao das Equipes.


Na Figura 6.6, e possıvel evidenciar um pico e um vale, os quais sao dados pela variacao

da experiencia em gerencia de projetos dos participantes. No entanto, observa-se que a

abordagem atende de modo intermediario/satisfatorio as necessidades do DDS por oferecer

uma nomenclatura comum a todos os envolvidos no projeto e possibilitar o entendimento

das dependencias entre as atividades e artefatos.

Figura 6.6: Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Nomenclatura.

O grafico da Figura 6.7 apresenta dois picos, os quais sao formados devido a variacao da

experiencia em gerencia de projetos. Mas, de modo geral a OCL foi avaliada como sendo

uma solucao intermediaria/satisfatoria para os problemas de imprecisao dos artefatos.


Figura 6.7: Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x OCL.

Na Figura 6.8, o grafico evidencia um vale e uma depressao. O vale representa os par-

ticipantes com conhecimento basico/intermediario em DDS e nenhuma/basica experiencia

em gerencia de projetos que avaliaram como intermediario o grau em que a padronizacao

dos artefatos e atividades podem impactar na qualidade dos produtos desenvolvidos.

A depressao demonstra que participantes com conhecimento intermediario em DDS e

experiencia intermediaria avaliaram que a padronizacao nao e determinante na qualidade

dos produtos.


Figura 6.8: Grafico da Relacao Conhecimento em DDS x Experiencia em Gerencia deProjetos x Padronizacao.

O grafico da Figura 6.9 apresenta uma depressao, que representa os participantes com

conhecimento avancado em teste de software e conhecimento intermediario em DDS que

avaliaram que as atividades de teste ao longo de todas as disciplinas de desenvolvimento

podem reduzir os problemas de integracao de modo intermediario. Ja os participantes

com conhecimento basico/intermediario em teste analisaram como sendo satisfatorio a

reducao dos problemas de integracao.


Figura 6.9: Grafico da Relacao Conhecimento em DDS x Conhecimento em Teste xAtividades de Teste ao longo das Disciplinas.

6.4.3 Aplicacao do Teste Estatıstico

Os participantes foram classificados em apenas um nıvel de conhecimento a partir das

variaveis de entrada, conforme pode ser visto na Tabela 6.3).

Tabela 6.3: Classificacao do Nıvel de Conhecimento do ParticipanteParticipante Nıvel de Conhecimento

1 12 23 24 15 16 17 28 19 210 111 112 1

As Variaveis Dependentes foram relacionadas com a Variavel Independente que mede

o conhecimento do participante atraves do teste estatıstico Qui-Quadrado. Como o

teste Qui-Quadrado considera a comparacao das distribuicoes, podemos comparar a dis-

tribuicao de respostas dos participantes com a distribuicao ideal.


A funcao densidade de probabilidade qui-quadrado e representada por x2v, em que v

designa o numero de graus de liberdade da x2. Se v observacoes de uma variavel sao

independentes, entao o numero de graus de liberdade e igual a v. Entretanto, um grau de

liberdade e perdido para cada restricao sobre as v observacoes (Montgomery e Runger,

2009).

A funcao distribuicao e dada por P (X2 >= X2v ) = �, em que � e a probabilidade de

somas dos quadrados iguais ou superiores ao valor correspondente tabelado. O nıvel de

significancia � e, geralmente, fixado em torno do valor 0,05. Quanto maior � , maior e o

risco de rejeitar hipoteses boas; inversamente, o risco de aceitar hipoteses falsas aumenta,

na medida que o valor de � diminue. Se o valor calculado da variavel aleatoria x2 for

maior do que o valor tabelado x2v, rejeitase a hipotese de que as variaveis sejam aleatorias,

entretanto, se ele for menor ou igual, a hipotese e aceita (Montgomery e Runger, 2009).

A Tabela 6.4 mostra o nıvel esperado em que a abordagem contempla as necessidades

do DDS segundo o conhecimento dos participantes.

Tabela 6.4: Nıvel Esperado que a abordagem contempla as necessidades do DDS.Nıvel Esperado

Nıvel de conhecimento 0 1 2 301 82 43

As Tabelas 6.5, 6.6 6.7, 6.8, 6.9, 6.10, 6.11, 6.12 e 6.13 apresentam a distribuicao dos

dados de acordo o nıvel de conhecimento dos participantes.

Tabela 6.5: Distribuicao do Grau que o Conjunto de Disciplinas atende as necessidadesdo DDS.

DisciplinasNıvel de conhecimento 0 1 2 3

01 3 52 1 33

O � adotado e de 0,05 e v e 9. Desse modo, o X2v calculado para os dados da Tabela

6.5 foi 6,125.


Tabela 6.6: Distribuicao do Grau que o Conjunto de Atividades atende as necessidadesdo DDS.

AtividadesNıvel de conhecimento 0 1 2 3

01 3 52 1 33

O X2v obtido para os dados da Tabela 6.6 foi 6,125.

Tabela 6.7: Distribuicao do Grau que o Conjunto de Artefatos atende as necessidadesdo DDS.

ArtefatosNıvel de conhecimento 0 1 2 3

01 2 62 43


Tabela 6.8: Distribuicao do Grau que a Notacao UML pode amenizar problemas decomunicacao.

Notacao UMLNıvel de conhecimento 0 1 2 3

01 3 52 2 23

Para os dados das Tabelas 6.8 e 6.9 o X2v calculado foi 4,5.

Tabela 6.9: Distribuicao do Grau que a Identificacao das Equipes pode aumentar apercepcao.

Identificacao das EquipesNıvel de conhecimento 0 1 2 3

01 4 42 2 23


Tabela 6.10: Distribuicao do Grau que a Abordagem Atende as necessidades do DDS.Nomenclatura

Nıvel de conhecimento 0 1 2 301 3 52 2 23


Tabela 6.11: Distribuicao do Grau que a OCL pode amenizar a ambiguidade.OCL

Nıvel de conhecimento 0 1 2 301 5 32 2 23


Tabela 6.12: Distribuicao do Grau que a Padronizacao de atividades e artefatos podeimpactar na qualidade.

PadronizacaoNıvel de conhecimento 0 1 2 3

01 4 42 1 1 23

O X2v calculado para os dados da Tabela 6.12 foi 6,125.

Tabela 6.13: Distribuicao do Grau em que as atividades de teste ao longo das disciplinaspodem reduzir os problemas de integracao.

Atividades de TesteNıvel de conhecimento 0 1 2 3

01 2 62 43

Para os dados da Tabela 6.13 o X2v calculado foi 0,04847.


6.4.4 Verificacao das Hipoteses

Pela tabela da distribuicao do qui-quadrado X2v = 7,815. Ao aplicar o teste qui-quadrado

todas as tabelas relacionadas as variaveis dependentes tiveram como resposta X2 >= X2v .

Desse modo, rejeita-se H1 em prol de H0. Com isso, podemos dizer que ”A abordagem

integrada de desenvolvimento e teste de software nao contempla todas as peculiaridades

do desenvolvimento distribuıdo”.

Como a amostra do estudo foi pequena tem-se os seguintes problemas relacionados a

validade:(1) A potencia do teste estatıstico qui-quadrado e baixa, o que afeta a validade

de conclusao; (2) Como o nıvel de conhecimento dos participantes e proximo, nao ha di-

versidade dos perfis, o que compromete a validade externa (generalizacao dos resultados).

Alem disso, observa-se que o estudo pode ter sido influenciado pela classificacao do

conhecimento em apenas um nıvel pois, a maioria dos participantes possuia conhecimento

intermediario ou avancado em DDS, mas apresentava nenhuma ou pouca experiencia em

gerencia de projetos e com conhecimento basico em teste de software. Assim, e possıvel

estratificar a analise utilizando cada um dos tipos de conhecimento do participante.


O teste Qui-Quadrado foi comprometido na generalizacao dos resultados devido ao re-

duzido numero de participantes, ou seja, para a aplicacao de um teste estatıstico, deveria

existir uma amostra maior do que a que foi utilizada. No entanto, a partir da analise dos

graficos apresentados na Secao 6.4.2, que correlacionam os conhecimentos do participante

com as caracterısticas analisadas da abordagem, pode-se evidenciar que as peculiaridades

do DDS sao contempladas em um nıvel intermediario/satisfatorio.

A conducao do estudo de viabilidade possibilitou levantar, junto aos participantes, os

seguintes pontos:

∙ inserir atividades que envolvam cooperacao e percepcao das equipes distruibuıdas

que estejam envolvidas em atividades conjuntas;

∙ englobar atividades de revisao das atividades e artefatos, o que afeta diretamente a

qualidade; e,

∙ gerar um artefato de conclusao de disciplina.

Capıtulo

7

Conclusoes

A crescente busca por maior competitividade tem levado as empresas a adotarem o DDS.

Tentando realizar desenvolvimento a baixo custo, empresas tem atravessado fronteiras,

formando um mercado global. A producao distribuıda pode ser motivada, tambem, por

questoes de qualidade, gerenciamento do controle de producao, domınio de tecnologias

empregadas, reducao da necessidade de grandes contratacoes imediatas ou para transferir

conhecimento a uma filial (L’Erario, 2009b).

Essa mudanca de paradigma tem causado impacto no marketing, na distribuicao e

na forma de concepcao, de producao, de projeto, de teste e de entrega do software aos

clientes (Sangwan et al., 2006). Segundo Damian e Lanubile (2004) para minimizar esses

efeitos e alcancar nıveis mais elevados de produtividade sao necessarias novas tecnologias,

processos e metodos compatıveis com a abordagem de desenvolvimento distribuıdo.

Diante deste cenario o objetivo deste trabalho foi apresentar uma abordagem integrada

de desenvolvimento e teste de software para apoiar o desenvolvimento com equipes dis-

tribuıdas. A abordagem foi desenvolvida com o intuito de oferecer suporte adequado

aos processos de comunicacao, coordenacao e controle fornecendo uma nomenclatura

comum aos envolvidos, melhorando a comunicacao entre as equipes atraves de artefatos

com informacoes relevantes tanto para desenvolvimento quanto para teste, oferecendo

visibilidade sobre as disciplinas em execucao, os envolvidos e suas responsabilidades.

A partir da analise dos processos realizada no Capıtulo 3, pode-se observar que mesmo

os processos que apresentam artefatos, responsabilidades e atividades bem definidas, possi-

bilitando adequacao as necessidades especıficas, eles nao contemplam as peculiaridades da

125

126 7. Conclusoes

estrategia de desenvolvimento distribuıdas. Alem disso, com base na analise dos trabalhos

relacionados pode-se extrair requisitos para a definicao de um processo compatıvel com

as caracterısticas do DDS.

Com base na lacuna identificada foi elaborada uma abordagem integrada de desen-

volvimento e teste de software. A abordagem abrange um conjunto de atividades que

devem ocorrer ao longo do ciclo de vida de um projeto e as caracterısticas essenciais de

cada uma. Considera atividades desde o modelo de negocios a ser adotado para atuar

em DDS (empresas globais, parcerias estrategicas, entre outros) ate a implementacao.

A modelagem da abordagem foi realizada utilizando a notacao SPEM com o intuito de

facilitar a comunicacao, o entendimento do processo, o reuso, apoiar a sua evolucao,

facilitar o gerenciamento e com vistas a melhoria contınua do processo.

7.1 Contribuicoes

Como contribuicoes desse trabalho pode-se destacar:

∙ a abordagem encontra-se estruturada em termos de papeis, artefatos e atividades

bem definidos, o que auxilia diretamente na sincronizacao, por oferecer a todos os

envolvidos uma nomenclatura comum. Isso possibilita uma melhor compreensao dos

termos do domınio de negocios e os marcos do projeto apesar de suas diferencas em

termos de cultura e estrutura organizacional, que podem ocorrer em um cenario de

DDS. Alem disso, ter um processo bem definido permite que o mesmo seja analisado

e como resultado dessa analise, ele possa sofrer evolucoes, sendo passıvel de melhoria

contınua;

∙ oferece suporte ao processo de desenvolvimento, planejamento e projeto de software

a medida que apresenta atividades e diretrizes tanto no nıvel estrategico (aspectos

de gerencia) como operacional (verificacao e validacao), os quais fornecem subsıdios

para a qualidade do software a ser desenvolvido;

∙ utiliza o gerenciamento hıbrido (centralizado-descentralizado) em relacao ao controle

das atividades e enfatiza a importancia da definicao do Gerente de Projeto Local,

bem como define suas atividades, para estimular a confianca e compromisso entre

os membros;

∙ apresenta atividades e diretrizes para a definicao do idioma a ser adotado na for-

malizacao do processo e comunicacao entre as equipes;

7.2 Dificuldades e Limitacoes 127

∙ formaliza a importancia do teste de software dentro de um projeto, tratando-o como

uma abordagem que deve ser instanciada em paralelo ao desenvolvimento e com

atividades desde a concepcao do software.

∙ integracao das abordagens de desenvolvimento e teste o que confere facilidade para

realizar alteracoes nos requisitos devido a rastreabilidade provida.

∙ oferece mecanismos para a padronizacao e reducao da imprecisao dos artefatos. Com

a padronizacao dos artefatos e possıvel reduzir a comunicacao entre as equipes e a

especificacao de templates e um fator primordial para facilitar a efetiva comunicacao

entre os membros das equipes.

∙ utiliza a notacao UML, que e de facil entendimento tanto para o meio academico

quanto industrial e possue semantica para transmitir informacoes aos desenvolve-

dores;

∙ utiliza especificacao formal de testes atraves do perfil U2TP para amenizar os

problemas de ambiguidade e reduzir a necessidade de comunicacao;

∙ oferece diretrizes para nortear o gerente de projetos (Local e Global) na distribuicao

das atividades;

∙ especifica atividades que tratam da definicao de infraestrutura para possibilitar a

colaboracao, controle da documentacao e controle de versao dos artefatos;

∙ auxilia na percepcao e conhecimento das atividades desenvolvidas, bem como o que

sera realizado em cada local e as responsabilidades de cada membro, por meio de

duas categorias de percepcao:

– percepcao de atividade: procura responder questoes, tais como: ”Quem esta

trabalhando em qual atividade?”, ”Quem foi o responsavel por determinada

tarefa e qual o resultado? ”Onde a atividade esta sendo executada?”

– percepcao de processo: relaciona-se a questoes do tipo: ”Como a tarefa daquele

pessoa se encaixa na minha? ”O que devo fazer agora?”

7.2 Dificuldades e Limitacoes

Durante a realizacao desta dissertacao foram encontradas algumas dificuldades e limitacoes,

sendo elas:

128 7. Conclusoes

∙ no ambito regional, ha dificuldade em encontrar empresas que utilizem essa con-

figuracao de desenvolvimento.

∙ os projetos desenvolvidos utilizando a estrategia distribuıda, geralmente, sao de

grande porte, o que demandaria um prazo maior para o acompanhamento do projeto.

∙ dificuldade de reunir equipes dispersas, mesmo no meio academico, que tenham

disponibilidade para participar do experimento.

7.3 Trabalhos Futuros

Com base nas limitacoes apresentadas e para dar continuidade as atividades realizadas

neste trabalho, foram identificadas algumas sugestoes de trabalhos futuros, os quais estao

alem do escopo desta dissertacao:

∙ replicar o estudo de viabilidade para ampliar a aquisicao de conhecimento sobre a

aplicacao do processo, a credibilidade e o ındice de confiabilidade do mesmo.

∙ refinar a abordagem proposta por meio da conducao dos seguintes estudos:

1. estudo de observacao: para adquirir uma compreensao refinada sobre a tec-

nologia e averigurar se a aplicacao pratica da abordagem faz sentido.

2. estudo de caso (ciclo de vida): para caracterizar a aplicacao da abordagem

no contexto de um ciclo de vida de desenvolvimento e avaliar o efeito de sua

aplicacao com o intuito de verificar se o abordagem e adequada no contexto de

um ciclo de vida.

3. estudo de caso (industria): para determinar a viabilidade pratica da aplicacao

do abordagem, aprimorar o entendimento dos pesquisadores resultando no refi-

namento da abordagem com o objetivo de analisar se a abordagem e adequada

no contexto industrial

∙ definir mecanismos para analisar as redes sociais formadas durante o projeto;

∙ definir metricas para avaliar a produtividade, a comunicacao e a qualidade dos

artefatos gerados;

∙ integrar a abordagem apresentada ao DiSEN Distributed Software Engineering Envi-

ronment, que e um ADDS (Ambiente de Desenvolvimento Distribuıdo de Software),

que visa disponibilizar ferramentas de apoio a comunicacao, a persistencia e a

7.4 Publicacoes 129

cooperacao para equipes de desenvolvimento geograficamente dispersas (Huzita et

al., 2007).

7.4 Publicacoes

No decorrer do mestrado foram publicados os seguintes artigos:

∙ LEAL, G. C. L. ; SILVA, C. A ; HUZITA, H. M. M. ; TAIT, T. F. C. . Towards

a Process to Information System Development with Distributed Teams. In: 12th

International Conference on Enterprise Information Systems, 2010, Funchal.

∙ LEAL, G. C. L. ; SILVA, C. A ; HUZITA, H. M. M. ; TAIT, T. F. C. . Uma Analise

Sociotecnica de Processos de Software sob a Perspectiva do Desenvolvimento com

Equipes Distribuıdas. In: VI Workshop, 2010, Belem. VI Workshop, 2010.

∙ LEAL, G. C. L. ; SILVA, C. A ; HUZITA, H. M. M.. Um Processo de Desen-

volvimento de Produto de Software para a Estrategia de Producao Distribuıda. In:

5th Americas International Conference on Production Research (ICPR Americas),

Bogota, Colombia, 2010.

∙ LEAL, G. C. L. ; SILVA, C. A ; DELAMARO, M. E. ; HUZITA, H. M. M. . A

Proposal an Integrated Approach of Software Development and Testing to Distributed

Teams. In: International Conference IADIS Information Systems 2010, 2010,

Porto.

∙ LEAL, G. C. L. ; SILVA, C. A ; HUZITA, H. M. M. . Towards a Distributed

Software Process. In: IADIS International Conference IADIS Information Systems

2010, 2010, Porto.

130 7. Conclusoes

Referencias Bibliograficas

Abdurazik, A. Evaluation of three specification-based testing criteria. In: ICECCS

’00: Proceedings of the 6th IEEE International Conference on Complex Computer

Systems, Washington, DC, USA: IEEE Computer Society, 2000, p. 179.

Al-Asmari, K.; Yu, L. Experiences in distributed software development with wiki.

In: Software Engineering Research and Practice, 2006, p. 389–293.

Alves, E. L. G.; Machado, P. D. L.; Ramalho, F. Uma abordagem integrada

para desenvolvimento e teste dirigido por modelos. In: 2nd Brazilian Workshop on

Systematic and Automated Software Testing, Campinas, SP, 2008, p. 74–83.

Audy, J.; Prikladnicki, R. Desenvolvimento distribuıdo de software: Desenvolvi-

mento de software com equipes distribuıdas. Rio de Janeiro, RJ: Elsevier, 2008.

Avritzer, A.; Hasling, W.; Paulish, D. Process investigations for the global studio

project version 3.0. In: ICGSE ’07: Proceedings of the International Conference on

Global Software Engineering, Washington, DC, USA: IEEE Computer Society, 2007, p.

247–251.

Avritzer, A.; Paulish, D.; Cai, Y. Coordination implications of software

architecture in a global software development project. In: WICSA ’08: Proceedings of

the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008),

Washington, DC, USA: IEEE Computer Society, 2008, p. 107–116.

Basili, V. R. The role of controlled experiments in software engineering research. In:

Empirical Software Engineering Issues, 2006, p. 33–37.

Bazman The benefits of outsourced testing. http://bazman.tripod.com/outsourced.html,

2007.

Ben-Shaul, I. Z.; Kaiser, G. E. A paradigm for decentralized process modeling

and its realization in the oz environment. In: ICSE ’94: Proceedings of the 16th

131

132 REFERENCIAS BIBLIOGRAFICAS

international conference on Software engineering, Los Alamitos, CA, USA: IEEE

Computer Society Press, 1994, p. 179–188.

Berger, P. M. Instanciacao de processos de software em ambientes configurados na

estacao taba. Dissertacao de Mestrado, COOPE, Universidade Federal do Rio de

Janeiro, Rio de Janeiro - Rio de Janeiro, 2003.

Biolchini, J.; Mian, P.; Natali, A.; Travassos, G. Systematic review in software

engineering: Relevance and utility. Relatorio Tecnico, COPPE/UFRJ, Rio de Janeiro,

RJ, 2005.

Briand, L. C.; Labiche, Y. A uml-based approach to system testing. In: Proceedings

of the 4th International Conference on The Unified Modeling Language, Modeling

Languages, Concepts, and Tools, London, UK: Springer-Verlag, 2001, p. 194–208.

Carmel, E. Global software teams: collaborating across borders and time zones. Upper

Saddle River, NJ, USA: Prentice Hall PTR, 1999.

Carmel, E.; Tija, P. Offshoring information technology: Sourcing and outsourcing

to a global workforce. New York: Cambridge University Press, 2005.

Carniello, A. Teste baseado na estrutura de casos de uso. Dissertacao de Mestrado,

Universidade Estadual de Campinas, Campinas, SP, 2003.

Cartaxo, E. G. Geracao de casos de teste funcional para aplicacoes de celulares.

Dissertacao de Mestrado, Universidade Federal de Campina Grande (UFCG), Campina

Grande - Paraıba, 2006.

Cibotto, R. A. G.; Pagno, R. T.; Tait, T. F. C.; Huzita, E. H. M. Uma

analise da dimensao socio-cultural no desenvolvimento distribuıdo de software. In:

V Workshop Um Olhar Sociotecnico sobre a Engenharia de Software WOSES, Ouro

Preto, Minas Gerais, 2009.

Crespo, A. N.; Jino, M. Processo de testde de software. Relatorio Tecnico, Centro

de Tecnologia da Informacao Renato Archer (CenPRA), 2005.

Crespo, A. N.; Silva, O. J.; Borges, C. A.; Salviano, C. F.; Argollo, M. T.;

Jino, M. Uma metodologia de teste de software no contexto de melhoria de processo.

In: III Simposio Brasileiro de Qualidade de Software SBQS, Brasılia-DF, 2004.

REFERENCIAS BIBLIOGRAFICAS 133

Dalal, S. R.; Jain, A.; Karunanithi, N.; Leaton, J. M.; Lott, C. M.; Patton,

G. C.; Horowitz, B. M. Model-based testing in practice. In: ICSE ’99:

Proceedings of the 21st international conference on Software engineering, New York,

NY, USA: ACM, 1999, p. 285–294.

Damian, D. Workshop on global software development. In: ICSE ’02: Proceedings

of the 24th International Conference on Software Engineering, New York, NY, USA:

ACM, 2002, p. 667–668.

Damian, D.; Lanubile, F. The 3rd international workshop on global software

development. In: ICSE ’04: Proceedings of the 26th International Conference

on Software Engineering, Washington, DC, USA: IEEE Computer Society, 2004, p.

756–757.

Delamaro, M. E.; Maldonado, J. C.; Jino, M. Introducao ao teste de software.

1 ed. Editora Campus, 2007.

El-Far, I. K.; Whittaker, J. A. Model-based software testing. 2001.

Enami, L. N. M. Um modelo de gerenciamento de projetos para um ambiente de

desenvolvimento distribuıdo de software. Dissertacao de Mestrado, Universidade

Estadual de Maringa (UEM), Maringa - Parana, 2006.

Fantinato, M. Geracao de casos de teste funcional para aplicacoes de celulares.

Dissertacao de Mestrado, Faculdade de Engenharia Eletrica e de Computacao -

Universidade Estadual de Campinas (FEEC/UNICAMP), Campinas - Sao Paulo, 2002.

Fuggetta, A. Software process: a roadmap. In: ICSE ’00: Proceedings of the

Conference on The Future of Software Engineering, New York, NY, USA: ACM, 2000,

p. 25–34.

Guimaraes, D. C. Ster: Uma estrategia de testes para sistemas reativos. Dissertacao

de Mestrado, Universidade Estadual de Campinas (Unicamp), Campinas - Sao Paulo,

2005.

Hargreaves, E.; Damian, D. Can global software teams learn from military teamwork

models? In: Proc. of 3rd Int. Workshop on Global Software Development, ICSE’04,

2004.


Hartmannm, J.; Vieira, M.; Ruder, A. Uml-based test generation and execution.

In: Proceedings of the 21st Workshop on Software Test, Analyses and Verification

(GI-FG TAV), Berlin, 2004.

Herbsleb, J. D.; Mockus, A.; Finholt, T. A.; Grinter, R. E. Distance,

dependencies, and delay in a global collaboration. In: CSCW ’00: Proceedings of

the 2000 ACM conference on Computer supported cooperative work, New York, NY,

USA: ACM, 2000, p. 319–328.

Humphrey, W. S.; Kellner, M. I. Software process modeling: principles of entity

process models. In: ICSE ’89: Proceedings of the 11th international conference on

Software engineering, New York, NY, USA: ACM, 1989, p. 331–342.

Huzita, E. H. M.; Silva, C. A.; Wiese, I. S.; Tait, T. F. C.; Quinaia, M.;

Schiavone, F. L. Um conjunto de solucoes para apoiar o desenvolvimento distribuıdo

de software. In: II Workshop de Desenvolvimento Distribuıdo de Software, Campinas,

SP, 2008, p. 101–110.

Huzita, E. H. M.; Tait, T. F. C.; Colanzi, T. E.; Quinaia, M. Um ambiente de

desenvolvimento distribuıdo de software - disen. In: I Workshop de Desenvolvimento

Distribuıdo de Software, Joao Pessoa, PB, 2007, p. 31–38.

IEEE Ieee standard for software test documentation. ANSI/IEEE Std 829-1998, 1998.

Jacobson, I. Object oriented software engineering. Addison-Wesley, 1992.

Jimenez, M.; Piattini, M.; Vizcaıno, A. Challenges and improvements in

distributed software development: A systematic review. Advances in Software

Engineering, v. vol. 2009, 2009.

Juristo, N.; Moreno, A. M.; Vegas, S. Reviewing 25 years of testing technique

experiments. Empirical Softw. Engg., v. 9, n. 1-2, p. 7–44, 2004.

Kitchenham, B. A. Procedures for undertaking systematic reviews. Relatorio Tecnico,

Computer Science Department, Keele University, 2004.

Kitchenham, B. A.; Pfleeger, S. L.; Pickard, L. M.; Jones, P. W.; Hoaglin,

D. C.; Emam, K. E.; Rosenberg, J. Preliminary guidelines for empirical research

in software engineering. IEEE Trans. Softw. Eng., v. 28, n. 8, p. 721–734, 2002.

Kruchten, P. The rational unified process: An introduction. Addison-Wesley, 2003.


Layman, L.; Williams, L.; Damian, D.; Bures, H. Essential communication

practices for extreme programming in a global software development team. Information

and Software Technology, v. 48, n. 9, p. 781–794, 2006.

Disponıvel em http://www.sciencedirect.com/science/article/

B6V0B-4JF8H93-2/2/625aa9c8d29f7c60b2a5a38425f9a41f

Leal, G. C. L.; Silva, C. A.; Huzita, E. H. M. Towards a distributed software

process. In: International Conference IADIS Information Systems 2010, Porto,

Portugal, 2010.

L’Erario, A. As aliancas estrategicas no desenvolvimento distribuıdo de software. In:

XXIX Encontro Nacional de Engenharia de Producao - A Engenharia de Producao e

o Desenvolvimento Sustentavel: Integrando Tecnologia e Gestao, Salvador, BA, 2009a,

p. 756–757.

L’Erario, A. M3ds: um modelo de dinamica de desenvolvimento distribuıdo do

software. Tese de Doutoramento, Escola Politecnica da Universidade de Sao Paulo,

Sao Paulo, SP, 2009b.

Lings, B.; Lundell, B.; Agerfalk, P. J.; Fitzgerald, B. A reference model for

successful distributed development of software systems. In: ICGSE ’07: Proceedings of

the International Conference on Global Software Engineering, Washington, DC, USA:

IEEE Computer Society, 2007, p. 130–139.

Mafra, S. N.; Barcelos, R. F. T. G. H. Aplicando uma metodologia baseada em

evidEncias na definicao de novas tecnologias de software. In: XX Simposio Brasileiro

de Engenharia de Software (SBES), Florianopolis, SC, 2006, p. 239–254.

Mantovan, U. Uma abordagem, baseada em framework e na tEcnica de descriCAo

formal estelle, para o desenvolvimento de sistemas de arquivos paralelos distribuIdos.

Dissertacao de Mestrado, Escola Politecnica, Universidade de Sao Paulo (POLI/USP),

Sao Paulo - Sao Paulo, 2006.

Mats, L. The top five software-testing problems and how to avoid them.

Http://pe2bz.philpem.me.uk/Misc/-Testing.pdf, 2001.

McGregor, J. D.; Sykes, D. A. A practical guide to testing object-oriented software.

Addison-Wesley, 2001.


Mockus, A.; Herbsleb, J. Challenges of global software development. In: METRICS

’01: Proceedings of the 7th International Symposium on Software Metrics, Washington,

DC, USA: IEEE Computer Society, 2001, p. 182.

Montgomery, D. C.; Runger, G. C. Estatıstica aplicada e probabilidade para

engenheiros. 4 ed. Norwell, MA, USA: LTC, 2009.

Mullick, N.; Bass, M.; Houda, Z.; Paulish, P.; Cataldo, M. Siemens global

studio project: Experiences adopting an integrated gsd infrastructure. In: Global

Software Engineering, 2006. ICGSE ’06. International Conference on, 2006, p. 203–212.

Myers, G. The art of software testing. John Willey, 2001.

Offutt, A. J.; Liu, S.; Abdurazik, A.; Ammann, P. Generating test data from

state-based specifications. Softw. Test., Verif. Reliab., v. 13, n. 1, p. 25–53, 2003.

Disponıvel em http://dblp.uni-trier.de/db/journals/stvr/stvr13.html#

OffuttLAA03

OMG Uml 2.0 testing profile specification. Relatorio Tecnico, 2004.

OMG Software process engineering metamodel specification. An Adopted Specification

of the Object Management Group, Inc.T, 2005.

Paasivaara, M.; Lassenius, C. Using iterative and incremental processes in global

software development. IEEE Seminar Digests, v. 2004, n. 912, p. 42–47, 2004.

Disponıvel em http://link.aip.org/link/abstract/IEESEM/v2004/i912/p42/s1

Packevicius, S.; Usaniov, A. B. E. Software testing using imprecise ocl constraints

as oracles. In: Proceedings of the 2007 international Conference on Computer Systems

and Technologies (CompSystech’07), New York, NY, USA: ACM, 2007, p. 1–6.

Paulish, D. J. Scalable distributed organizations for ultra-large-scale software. In:

ULS ’07: Proceedings of the International Workshop on Software Technologies for

Ultra-Large-Scale Systems, Washington, DC, USA: IEEE Computer Society, 2007, p. 4.

Ribeiro, M. B.; Czekster, R. M.; Webber, T. Improving productivity of local

software development teams in a global software development environment. In: Global

Software Engineering, 2006. ICGSE ’06. International Conference on, 2006, p. 253–254.

Rocha, R.; Arcoverde, D.; Brito, D.; Aroxa, B.; Costa, C.; Silva, F. Q. B.;

J., A.; Meira, S. R. L. Uma experiencia na adaptacao do rup em pequenas equipes


de desenvolvimento distribuıdo. In: II Workshop de Desenvolvimento Distribuıdo de

Software, Campinas, SP, 2008, p. 81–90.

Rorato, T. Em direcao a uma semantica da linguagem de descricao de reuso em

uml/ocl. Dissertacao de Mestrado, Pontifıcia Universidade Catolica do Rio Grande do

Sul, Porto Alegre - Rio Grande do Sul, 2007.

Sangwan, R.; Bass, M.; Mullick, N.; Paulish, D. J.; Kazmeier, J. Global

software development handbook (auerbach series on applied software engineering series).

Boston, MA, USA: Auerbach Publications, 2006.

Sengupta, B.; Chandra, S.; Sinha, V. A research agenda for distributed software

development. In: ICSE ’06: Proceedings of the 28th international conference on

Software engineering, New York, NY, USA: ACM, 2006, p. 731–740.

Shull, F.; Carver, J.; Travassos, G. H. An empirical methodology for introducing

software processes. SIGSOFT Softw. Eng. Notes, v. 26, n. 5, p. 288–296, 2001.

Silva, D.; Lopes, M. C. M.; Lopes, G. O. Sitest: Uma metodologia de teste

de software com base no modelo cmmi. In: III Simposio Brasileiro de Sistemas de

Informacao, Curitiba, PR, 2006, p. 11–11.

Souza, E. P. R.; Gusmao, C. M. G. Rbtprocess - modelo de processo de teste de

software baseado em riscos. In: 13 Workshop de Teses e Dissertacoes em Engenharia

de Software, Campinas, Sao Paulo, 2008.

Taylor, P. S.; Greer, D.; Sage, P.; Coleman, G.; McDaid, K.; Keenan, F.

Do agile gsd experience reports help the practitioner? In: GSD ’06: Proceedings of

the 2006 international workshop on Global software development for the practitioner,

New York, NY, USA: ACM, 2006, p. 87–93.

Travassos, G. H. Introducao a engenharia de software experimental. Re-

latorio Tecnico ES-590/02, Programa de Engenharia de Sistemas e Computacao,

COPPE/UFRJ, 2002.

Urdangarim, R. Uma investigacao sobre o uso de praticas extreme programming no

desenvolvimento global de software. Dissertacao de Mestrado, Pontifıcia Universidade

Catolica do Rio Grande do Sul, Porto Alegre - Rio Grande do Sul, 2008.


Vanzin, M.; Ribeiro, M.; Prikladnicki, R.; Ceccato, I.; Antunes, D. Global

software processes definition in a distributed environment. In: Software Engineering

Workshop, 2005. 29th Annual IEEE/NASA, IEEE Computer Society, 2005, p. 57–65.

Weissleder, S.; Schlingloff, B.-H. Quality of automatically generated test cases

based on ocl expressions. In: ICST ’08: Proceedings of the 2008 International

Conference on Software Testing, Verification, and Validation, Washington, DC, USA:

IEEE Computer Society, 2008, p. 517–520.

Wohlin, C.; Runeson, P.; Host, M.; Ohlsson, M. C.; Regnell, B.; Wesslen,

A. Experimentation in software engineering: an introduction. Norwell, MA, USA:

Kluwer Academic Publishers, 2000.

Apendice

A

Protocolo da Revisao Sistematica

A.1 Introducao

Uma revisao sistematica atua como um meio para identificar, avaliar e interpretar toda

pesquisa disponıvel e relevante sobre uma questao de pesquisa, um topico ou um fenomeno

de interesse. A conducao de uma revisao sistematica supostamente apresenta uma avaliacao

justa do topico de pesquisa, na medida que utiliza uma metodologia de revisao rigorosa,

confiavel e passıvel de auditagem (Kitchenham, 2004).

As principais razoes para se realizar uma revisao sistematica sao: (i) resumir a evidencia

existente a respeito de uma determinada tecnologia; (ii) identificar lacunas na pesquisa

atual a fim de sugerir areas para investigacoes futuras; e, (iii) fornecer um framework para

direcionar atividades novas de pesquisa.

Este documento apresenta o protocolo de revisao sistematica que foi conduzido para

identificar os estudos que abordam processos de software utilizados no desenvolvimento

com equipes distribuıdas e as necessidades dessa abordagem no que se refere ao processo

de desenvolvimento.

A.2 Formulacao da Pergunta

A questao primaria formulada no planejamento da revisao sistematica foi ”Quais sao

os processos de software utilizados no desenvolvimento distribuıdo?”. Como questao

139

140 A. Protocolo da Revisao Sistematica

secundaria tem-se: ”Quais as peculiaridades do desenvolvimento distribuıdo que devem

ser contempladas pelos processos de desenvolvimento?”.

Como criterios de inclusao que atendessem a questao primaria foram considerados os

trabalhos que fizessem referencia a processos ou adaptacoes de processos de software uti-

lizados com equipes distribuıdas. Para atender a questao secundaria foram considerados os

trabalhos que retratassem a necessidade dos processos de desenvolvimento contemplarem

as peculiaridades do desenvolvimento distribuıdo.

Os criterios de exclusao utilizados para a questao primaria foram: trabalhos que

nao abordassem de processos de desenvolvimento de software; nao estivessem redigidos

em ingles; nao correspondessem a trabalho de pesquisa; ou que nao era possıvel ter

acesso a versao completa do trabalho. Para responder a questao secundaria, nao foram

considerados os trabalhos que nao retratavam as caracterısticas da abordagem distribuıda

de desenvolvimento.

A.3 Selecao das Fontes de Pesquisa

As fontes consideradas para essa revisao foram bases de dados eletronicas indexadas

(IEEE, ACM e Springer). Dessas fontes, foram considerados apenas os trabalhos redigidos

em ingles. As palavras-chaves utilizadas foram: ”software process”, ”software devel-

opment”, ”virtual teams”, ”distributed teams”, ”global” e ”distributed”. Por meio da

combinacao desses termos foram elaboradas as strings de busca. Como as maquinas de

busca apresentam particularidades relacionadas a construcao de strings de busca, quando

necessario, foram realizadas adaptacoes.

As buscas foram feitas em bases de dados eletronicas indexadas por meio de strings

de busca. A execucao da busca foi realizada de forma incremental, sendo realizado um

incremento para cada fonte de busca. Nesta etapa foram recuperados um total de 49

trabalhos.

A.4 Selecao Preliminar

Nessa etapa foi realizada a leitura dos resumos dos trabalhos e, quando necessario,

algumas secoes do artigo como introducao ou conclusao. Nao foram estabelecidos criterios

especıficos de qualidade para determinar a validade dos artigos selecionados. Nesse estudo

inicial, o fato dos trabalhos serem procedentes de fontes reconhecidas bastariam para

aceitacao da validade.

A.5 Selecao Final e Extracao dos Dados 141

A.5 Selecao Final e Extracao dos Dados

Nessa etapa foi realizada a leitura completa dos trabalhos e os selecionados foram sin-

tetizados, extraindo dados para posterior analise e interpretacao dos estudos obtidos.

Segundo Biolchini et al. (2005), o foco principal dessa fase e sintetizar os estudos validos

de modo que, posteriormente, possam ser realizadas generalizacoes. Os dados extraıdos

foram:

∙ citacao do trabalho selecionado;

∙ fonte de busca em que o trabalho foi recuperado;

∙ processo identificado, em resposta a questao primaria da revisao sistematica;

∙ elementos descritos, apresenta os elementos componentes de um processo e as pe-

culiaridades da abordagem de desenvolvimento distribuıdo que foram identificadas

no trabalho selecionado. Essas particularidades sao referentes a definicao de:

1. mecanismos para explicitar as diferencas (cultural, fuso-horario e idioma) entre

as equipes envolvidas no projeto;

2. especificacao formal dos requisitos para amenizar os problemas de ambiguidade

e imprecisao dos artefatos;

3. estrategias para realizar a distribuicao do desenvolvimento;

4. criterios para suavizar a integracao dos modulos desenvolvidos em locais sepa-

rados, a fim de reduzir os erros de integracao.

A.6 Consideracoes Finais

Este documento apresentou o protocolo da revisao sistematica conduzida para verificar

os processos de desenvolvimento de software que vem sendo utilizados com equipes dis-

tribuıdas. Os estudos selecionados foram, na sua maior parte, referentes aos problemas

(diversidade cultural, dispersoes geograficas, coordenacao e comunicacao) encontrados

quando da adocao de desenvolvimento distribuıdo.

Os dados obtidos, com a revisao sistematica, forneceram subsıdios para a definicao

da abordagem proposta nesta dissertacao. Um detalhamento maior sobre a revisao

sistematica pode ser visto em Leal et al. (2010).

142 A. Protocolo da Revisao Sistematica

Apendice

B

Templates Abordagem de

Desenvolvimento

Esse documento apresenta templates para os artefatos gerados pela abordagem de desen-

volvimento proposta.

B.1 Plano de Desenvolvimento de Software

Esta secao apresenta um template para os artefatos Plano de Desenvolvimento Global e

Plano de Desenvolvimento Local, conforme pode ser visto nas Tabelas B.1 e B.2. Estes

artefatos sao gerados na Disciplina Planejamento.

B.2 Descricao Extendida Casos de Uso

A Tabela B.3 ilustra o template para a descricao de casos de uso, artefato gerado na

Disciplina Requisitos.

143

144 B. Templates Abordagem de Desenvolvimento

Tabela B.1: Plano de Desenvolvimento de Software Global

B.2 Descricao Extendida Casos de Uso 145

Tabela B.2: Plano de Desenvolvimento de Software Local

Tabela B.3: Descricao de Caso de Uso

Nome do Caso de Uso

Autor/Equipe

Data

Atores

Descricao

Pre-condicoes

Pos-condicoes

Fluxo de eventos

Fluxos Alternativos

146 B. Templates Abordagem de Desenvolvimento

Apendice

C

Templates Abordagem de Teste

Esse documento apresenta templates para os artefatos gerados pela abordagem de teste

proposta.

C.1 Plano de Testes

O template para o Plano de Testes e apresentado na Tabela C.1.

147

148 C. Templates Abordagem de Teste

Tabela C.1: Plano de Testes

C.2 Especificacao de Projeto de Teste

Na Tabela C.2 e ilustrado o template para a Especificacao de Projeto de Teste.

C.3 Especificacao de Casos de Teste 149

Tabela C.2: Especificacao de Projeto de Teste

C.3 Especificacao de Casos de Teste

O template para a Especificacao de Casos de Teste, artefato produzido na Disciplina de

Projeto, e mostrado na Tabela C.3

Tabela C.3: Especificacao de Casos de Teste

C.4 Especificacao de Procedimentos de Teste

A Tabela C.4 mostra o template para o artefato Especificacao de Procedimentos de Teste.


Tabela C.4: Especificacao de Procecimentos de Teste

C.5 Diario de Testes

O template para o Diario de Testes e apresentado na Tabela C.5.

Tabela C.5: Diario de Testes

C.6 Relatorio de Incidentes

O template para o Relatorio de Incidentes, artefato produzido na Disciplina de Execucao,

e mostrado na Tabela C.6

C.7 Resumo de Testes 151

Tabela C.6: Relatorio de Incidentes

C.7 Resumo de Testes

A Tabela C.7 ilustra o template do artefato Resumo de Testes.

Tabela C.7: Resumo de Testes


Apendice

D

Artefatos

D.1 Introducao

Este documento apresenta artefatos gerados durante a instanciacao da abordagem no

cenario proposto no Capıtulo 5, o qual e utilizado como prova de conceito para a abor-

dagem.

D.2 Descricao Textual

O MSPaper objetiva gerenciar o processo de submissao e avaliacao de artigos em even-

tos cientıficos, sob a perspectiva de quatro tipos de usuarios: (i) presidente do comite

cientıfico; (ii) revisores; (iii) autores; e, (iv) administrador. As funcionalidades a serem

desenvolvidas sao:

∙ Registro do evento - consiste em caracterizar o evento atraves da definicao de

questoes relacionadas a: temas que os artigos submetidos devem atender, numero de

revisoes por artigo, calendario do processo de selecao, incluindo: prazo de submissao,

prazo de devolucao das revisoes pelos revisores, data de notificacao da aceitacao ou

rejeicao, data limite para submissao da versao final dos artigos aceitos e percentual

de artigos a serem aceitos.

153

154 D. Artefatos

∙ Submissao de artigos - um dos autores submete o arquivo do artigo em formato

PDF. Nessa etapa sao identificados todos os autores, a area do artigo, as palavras

chaves e o resumo.

∙ Distribuicao dos artigos - o presidente do comite cientıfico e responsavel por con-

stituir o comite de programa com base nas especialidades de conhecimento. Apos

isso, deve liberar a distribuicao dos artigos para os autores da area relacionada.

∙ Revisao dos artigos - os revisores analisam os artigos submetidos segundo os criterios

de avaliacao, que sao: relevancia, conteudo tecnico e rigor cientıfico, originalidade,

qualidade da escrita e avaliacao global.

∙ Consolidacao dos resultados - o presidente do comite cientıfico acompanha as re-

visoes, verificando se todos as revisoes foram devolvidas e se houveram atrasos.

Alem disso, resolve os possıveis conflitos de avaliacao, define o numero de artigos

aceitos e encaminha a notificacao de aceitacao ou rejeicao aos autores.

∙ Controle de Acesso - consiste em definir os nıveis de acesso de acordo com o tipo de

usuario.

O administrador e responsavel pelas configuracoes relacionadas ao controle de acesso

dos usuarios. O presidente do comite cientıfico e o responsavel pelo registro do evento no

MSPaper, distribuicao dos artigos entre os revisores e a consolidacao dos resultados.

Os autores podem realizar a submissao de artigos e os revisores sao responsaveis pela

avaliacao dos artigos que lhes forem atribuıdos.

D.3 Especificacao dos Casos de Uso

Esta secao apresenta, para cada caso de uso do MSPaper, sua especificacao, contendo

descricao, fluxo de eventos, pre e pos-condicoes.

D.3 Especificacao dos Casos de Uso 155

Tabela D.1: Gerenciar acesso.

Nome do Caso de Uso Gerenciar acesso

Autor/Equipe Gislaine Camila/Maringa

Data 12/03/2010

Atores Administrador e PresidenteComiteCientıfico

Descricao Parte do sistema responsavel por gerenciar os nıveis de acessodos usuarios.

Pre-condicoes Usuario cadastrado no sistema.

Pos-condicoes O usuario logado no sistema ou nao.

Fluxo de eventos

1. O usuario informa os dados de login e senha.

2. A tela principal do MSPaper e aberta.

Tratamento de excecoes

1. Login e/ou senha invalidos.

(a) O sistema emite uma mensagem informando queos dados estao incorretos.

156 D. Artefatos

Tabela D.2: Gerenciar evento.

Nome do Caso de Uso Gerenciar evento


Data 12/03/2010

Atores Administrador e PresidenteComiteCientıfico

Descricao O ator Administrador cadastra o evento e vincula o usuarioPresidenteComiteCientıfico ao evento.

Pre-condicoes Usuario estar logado no sistema e ter permissao de Admin-istrador ou ter permissao de PresidenteComiteCientıfico.

Pos-condicoes Evento cadastrado.

Fluxo de eventos

1. O Administrador cadastra o evento e informa o usuarioque sera o Presidente do Comite Cientıfico.

2. O usuario PresidenteComiteCientıfico insere as demaisinformacoes e disponibiliza o evento para que os demaisusuarios possam visualizar.


1. Campo numero de revisoes por artigo esta vazio ou comvalor menor ou igual a zero.

(a) O sistema emite uma mensagem solicitando queseja informado um valor maior que zero.

2. O prazo de submissao e menor que a data atual.

(a) O sistema emite uma mensagem informando que oprazo de submissao deve ser posterior data atual.

3. A data de devolucao das submissoes e menor que a datade submissao.

(a) O sistema emite uma mensagem informando quea data de devolucao das revisoes deve ser maiorque a data de submissao.

4. A data de notificacao e menor que a data atual ou menorque a data de devolucao das revisoes.

(a) O sistema emite uma mensagem informando quea data de notificacao deve ser maior que a datade devolucao das revisoes.

5. O percentual de artigos aceitos esta vazio ou e menorou igual a zero.

(a) O sistema emite uma mensagem solicitando queseja informado um valor maior que zero.


Tabela D.3: Submeter artigo.

Nome do Caso de Uso Submeter artigo


Data 12/03/2010

Atores Autor

Descricao O autor realizara a submissao de um artigo, para isso ele deveinformar a qual tema do evento o artigo esta relacionado, osautores, tıtulo, resumo, palavras-chave e fazer o upload doarquivo com extensao PDF.

Pre-condicoes O usuario deve estar cadastrado no MSPaper e o prazo parasubmissao de artigos deve estar aberto.

Pos-condicoes A confirmacao de submissao e encaminhada para o e-mail dosautores e o status do artigo fica como ”Submetido”.

Fluxo de eventos

1. O autor informa os dados do artigo.

2. Sao realizadas as validacoes, se os dados sao validos elessao armazenados.


1. Area do artigo vazia.

(a) O sistema emite uma mensagem solicitando opreenchimento da area.

2. O arquivo nao esta no formato PDF.

(a) O sistema emite uma mensagem informando quea extensao do arquivo esta incorreta.

Tabela D.4: Distribuir artigo.

Nome do Caso de Uso Distribuir artigo


Data 12/03/2010

Atores PresidenteComiteCientıfico

Descricao O ator PresidenteComiteCientifico encaminha os artigos aosrevisores, considerando os temas selecionados.

Pre-condicoes O prazo para submissao de artigos ter encerrado.

Pos-condicoes E encaminhado um e-mail para os revisores e o status do artigose torna ”Em Revisao”.

Fluxo de eventos

1. O PresidenteComiteCientıfico disponibiliza os arquivosaos revisores para correcao.

2. O status do artigo e alterado para ”Em revisao”.

158 D. Artefatos

Tabela D.5: Revisar artigo.

Nome do Caso de Uso Revisar artigo


Data 12/03/2010

Atores Revisor

Descricao O Revisor avalia o artigo segundo os criterios: relevancia,conteudo tecnico e rigor cientıfico, originalidade, qualidade daescrita e avaliacao global.

Pre-condicoes O artigo estar com o status ”Em revisao”e dentro do prazoestabelecido para revisao.

Pos-condicoes A revisao e cadastrada e o status do artigo passa a ser”Aguardando Parecer”.

Fluxo de eventos

1. O revisor realiza a revisao para os artigos que estaodisponıveis para ele.

2. Finaliza a revisao liberando o resultado para o Presi-dentedoComite.


1. O campo Relevancia esta vazio.

(a) O sistema emite uma mensagem solicitando opreenchimento da relevancia.

2. O campo Conteudo Tecnico esta vazio.

(a) O sistema emite uma mensagem solicitando opreenchimento do campo.

3. O campo Rigor Cientıfico esta vazio.


4. O campo Originalidade esta vazio.


5. O campo Qualidade da Escrita esta vazio.


6. O campo Avaliacao Global esta vazio.



Tabela D.6: Consolidar revisao.

Nome do Caso de Uso Consolidar revisao


Data 13/03/2010

Atores PresidenteComiteCientıfico

Descricao O PresidenteComiteCientıfico realiza o acompanhamento dasrevisoes, resolve os conflitos de revisoes e encaminha a noti-ficacao da revisao aos autores.

Pre-condicoes A data ser posterior a data limite para envio das revisoes.

Pos-condicoes A notificacao das revisoes e encaminhada aos autores e tem-sea lista de artigos aceitos.

Fluxo de eventos

1. O PresidenteComiteCientıfico resolve os conflitos rela-cionados a revisoes que nao foram encaminhadas e aavaliacao.

2. Encaminha notificacao aos autores informando a datade submissao final para os artigos aceitos e os co-mentarios dos revisores.


1. Revisoes que nao foram devolvidas.

(a) O ator PresidenteComiteCientıfico solicita as re-visoes e estabelece um novo prazo ou encaminhapara outro revisor.

160 D. Artefatos

Apendice

E

Documentacao do Estudo de

Viabilidade

Esse documento apresenta o memorial descritivo da abordagem, o questionario do perfil

do participante e o questionario sobre a viabilidade da abordagem integrada de desen-

volvimento e teste de software para equipes distribuıdas.

E.1 Memorial Descritivo

Projeto de estudo de viabilidade

UMA ABORDAGEM INTEGRADA DE DESENVOLVIMENTO E TESTE

DE SOFTWARE PARA EQUIPES DISTRIBUIDAS

Dissertacao de Mestrado

Gislaine Camila Lapasini Leal

Objetivo: analisar a viabilidade da abordagem proposta para oferecer apoio ao

desenvolvimento distribuıdo de software com o proposito de adquirir conhecimento sobre

a aplicacao da mesma.

Abordagem: Com base em uma revisao de literatura e uma revisao sistematica foi

possıvel evidenciar que ha algumas lacunas no desenvolvimento distribuıdo de software

(DDS) no que se refere ao processo de desenvolvimento. Desse modo, foram definidas

161

162 E. Documentacao do Estudo de Viabilidade

as atividades, os artefatos e os papeis necessarios em cada etapa do desenvolvimento,

considerando as peculiaridades do desenvolvimento com equipes distribuıdas.

A abordagem proposta considera o processo de testes como um conjunto de tarefas

a parte que pode ser aplicado ao longo do processo de desenvolvimento. A abordagem

de desenvolvimento utiliza a (UML), por possuir informacoes relevantes para testes e

estar em uso na academia e na maioria das industrias de tecnologia, de modo que nao ha

custos extras associados ao treinamento e integracao no processo de desenvolvimento da

aplicacao.

Na abordagem de teste e utilizado o Perfil UML 2.0 (U2TP), que define uma linguagem


de sistemas. Os artefatos de teste especificados pela abordagem sao os recomendados pela

norma IEEE 829, que descreve um conjunto basico de documentos de teste de software.

A visao geral da abordagem integrada, que mostra o fluxo de informacoes entre

as Disciplinas, e apresentada na Figura E.1 . Os artefatos gerados sao possıveis de

refinamento nas Disciplinas posteriores.

Figura E.1: Diagrama de Atividades da Abordagem Integrada de Desenvolvimento eTeste de Software.

A seguir sao apresentados os elementos (papeis, artefatos e atividades) de cada uma

das Disciplinas.

Planejamento - Desenvolvimento

E.1 Memorial Descritivo 163

Figura E.2: Diagrama de Pacotes da Disciplina Planejamento.

Planejamento - Teste

Figura E.3: Diagrama de Pacotes da Disciplina Planejamento.

Requisitos - Desenvolvimento


Figura E.4: Diagrama de Pacotes da Disciplina Requisitos.

Preparacao - Teste

Figura E.5: Diagrama de Pacotes da Disciplina Preparacao.

Desenvolvimento - Desenvolvimento

E.1 Memorial Descritivo 165

Figura E.6: Diagrama de Pacotes da Disciplina Desenvolvimento.

Projeto - Teste


Figura E.7: Diagrama de Pacotes da Disciplina Projeto.

Implementacao - Desenvolvimento

Figura E.8: Diagrama de Pacotes da Disciplina Implementacao.

Execucao - Teste

E.2 Questionarios 167

Figura E.9: Diagrama de Pacotes da Disciplina Execucao.

E.2 Questionarios

Nesta Secao sao apresentados os questionarios utilizados na instrumentacao do estudo

conduzido.

E.2.1 Questionario 1 - Perfil do Entrevistado

Nome:

Instituicao:

1. Qual o seu grau de formacao?

( ) Graduado ( ) Especialista ( ) Mestrando ( ) Mestre ( ) Doutorando ( ) Doutor

2. Qual a sua experiencia com desenvolvimento de sistemas?


( ) Nunca desenvolvi ( ) Desenvolvi para uso pessoal

( ) Desenvolvi como partes de trabalho de curso ( projetos)

( ) Desenvolvi software em ambiente industrial ( anos)

3. Tem conhecimento em desenvolvimento distribuıdo de software?

( ) Nenhum ( ) Basico ( ) Intermediario ( ) Avancado

4. Qual a sua experiencia com desenvolvimento distribuıdo de software?

( ) Academica ( ) Industrial ( ) Ambas

5. Tem experiencia em gerencia de projetos?


6. Tem conhecimento em teste de software?


E.2.2 Questionario 2 - Estudo de Viabilidade

1. Em que grau o conjunto de disciplinas apresentado e satisfatorio para o desenvolvi-

mento distribuıdo?

( ) Nenhum ( ) Baixo ( ) Intermediario ( ) Satisfatorio

2. Em que grau as atividades apresentadas atendem as necessidades do desenvolvimento

distribuıdo?


3. Em que grau os artefatos apresentados atendem as necessidades do desenvolvimento

distribuıdo?


4. Em que grau o uso de uma notacao (UML) que oferece informacoes relevantes para as

duas equipes (desenvolvimento e teste) pode amenizar os problemas de comunicacao?


5. Em que grau a identificacao das equipes, bem como de seus membros e responsabili-

dades atraves dos Planos de Desenvolvimento Global, Plano de Desenvolvimento Local e

E.2 Questionarios 169

Plano de Testes podem aumentar a percepcao de um projeto?


6. A definicao da abordagem oferece uma nomenclatura comum a todos os envolvidos no

projeto e possibilita entender a dependencia das atividades e artefatos. Em que grau a

abordagem apresentada atende as necessidades do DDS?


7. Em que grau o uso OCL (Object Constraint Language) para especificar restricoes pode

reduzir os problemas de ambiguidade nos artefatos (diagrama de classes)?


8. Em que grau a padronizacao dos artefatos e atividades, definidos na abordagem

integrada, podem impactar na qualidade dos produtos desenvolvidos?


9. Em que grau as atividades de teste ao longo de todas as disciplinas de desenvolvimento

podem reduzir os problemas de integracao?


10. Voce visualiza atividades e artefatos adicionais que devem ser contempladas pela

abordagem? Se sim, quais?

( ) Sim ( ) Nao

Documents

UMA ABORDAGEM I TEGRADA DE DESE VOLVIME TO E …mestrado/diss/2010/leal.pdfy caminar a paso lento, muy lento..." Aos meus pais Gerv asio Leal e Noeli Lapasini, pelo amor incondicional,