PROCESSO PARA ESPECIFICAO DE REQUISITOS DE SOFTWARE ... ? vagner luiz gava processo para especificao

  • Published on
    19-Jan-2019

  • View
    212

  • Download
    0

Transcript

VAGNER LUIZ GAVA

PROCESSO PARA ESPECIFICAO DE REQUISITOS DE

SOFTWARE COM FOCO DE APLICAO EM TRABALHO

COOPERATIVO

SO PAULO

2009

VAGNER LUIZ GAVA

PROCESSO PARA ESPECIFICAO DE REQUISITOS DE

SOFTWARE COM FOCO DE APLICAO EM TRABALHO

COOPERATIVO

Tese apresentada Escola Politcnica da Universidade de So Paulo para obteno do ttulo de Doutor em Engenharia

SO PAULO

2009

VAGNER LUIZ GAVA

PROCESSO PARA ESPECIFICAO DE REQUISITOS DE

SOFTWARE COM FOCO DE APLICAO EM TRABALHO

COOPERATIVO

Tese apresentada Escola Politcnica da Universidade de So Paulo para obteno do ttulo de Doutor em Engenharia

rea de Concentrao:

Engenharia de Produo

Orientador: Prof. Livre-Docente

Mauro de Mesquita Spinola

SO PAULO

2009

Este exemplar foi revisado e alterado em relao verso original, sob responsabilidade nica do autor e com a anuncia de seu orientador. So Paulo, 14 de dezembro de 2009. Assinatura do autor ____________________________ Assinatura do orientador _______________________

FICHA CATALOGRFICA

Gava, Vagner Luiz

Processo para especificao de requisitos de software com foco de aplicao em trabalho cooperativo / V.L. Gava. -- ed.rev. -- So Paulo, 2009.

288 p.

Tese (Doutorado) - Escola Politcnica da Universidade de So Paulo. Departamento de Engenharia de Produo.

1. Engenharia de requisitos 2. Ergonomia no trabalho 3. Coo- perao I. Universidade de So Paulo. Escola Politcnica. Depar- tamento de Engenharia de Produo II. t.

DEDICATRIA

Dedico este trabalho a meus pais a minha

esposa e, em especial, a meus filhos.

Espero que um dia o esforo pela

elaborao desta pesquisa possa servir-lhes

de inspirao nos caminhos que decidirem

trilhar.

AGRADECIMENTOS

Ao Prof. Dr. Mauro de Mesquita Spinola, por todo o apoio, incentivo, aprendizado e

orientao no desenvolvimento desta pesquisa e dos artigos publicados.

Dra. Leda Leal Ferreira, pelos ensinamentos sobre Anlise Coletiva do Trabalho

em todas as oportunidades que me recebeu na FUNDACENTRO.

Dra. Uiara Montedo, por suas valiosas contribuies durante a qualificao.

Aos Professores Doutores Marcelo Pessa e Fernando Laurindo pelo apoio e

incentivo.

Ao pessoal do Grupo GTI e Elabsoft, pela solidariedade e aprendizado adquiridos,

em especial, Rodrigo pela parceria em nossas pesquisas e Ivelise e Lidia, pela

ateno e suporte dispensados.

Ao IPT, por proporcionar a oportunidade nica de realizar este estudo. Agradeo, em

particular, ao Dr. Walter Furlan pelo apoio neste ltimo ano.

A todos aqueles que, de forma direta ou indireta, contriburam para a consecuo

deste objetivo, meus sinceros agradecimentos.

Nenhum homem uma ilha; qualquer homem uma parte do todo. A morte de

qualquer homem me diminui, porque fao parte da humanidade; assim, nunca

procures saber por quem dobram os sinos: eles dobram por ti.

John Donne (1572-1631)

RESUMO

O trabalho dos usurios em sistemas de informao uma atividade social que envolve

grupos de pessoas que cooperam entre si para desempenhar as mais variadas funes. A

natureza da cooperao, por si s complexa e depende dos indivduos envolvidos, do

ambiente fsico e da organizao onde o trabalho se desenvolve. Os aspectos ligados ao

trabalho cooperativo dos usurios no so considerados no enfoque tradicional da

engenharia de software, uma vez que o usurio visto de modo independente do meio ou

grupo em que est inserido, com o modelo individual generalizado para o estudo do

comportamento coletivo envolvendo todos os usurios. O objetivo deste trabalho propor

um processo de requisitos de software para tratar as questes envolvendo o trabalho

cooperativo em sistemas de informao que apresentem coordenao distribuda nas aes

dos usurios e a comunicao entre eles ocorre, preponderantemente, de modo indireto por

meio dos dados inseridos no uso do software. Para tanto, a pesquisa faz uso de conceitos

da ergonomia, da cognio e da engenharia de software. Utiliza-se a pesquisa-ao como

metodologia de pesquisa em trs ciclos, aplicada durante o desenvolvimento de um sistema

de workflow corporativo em uma empresa de pesquisa tecnolgica. No primeiro ciclo, o

processo trata da definio dos requisitos do domnio do problema e das contribuies

individuais dos usurios. No segundo ciclo, as contribuies do grupo (suas aes e inter-

relaes) so consideradas com as contribuies individuais pela simulao da soluo

proposta. No terceiro ciclo, o processo trata do refinamento dos requisitos do trabalho

cooperativo, com o software em uso real no ambiente de trabalho. Os resultados obtidos no

final do ciclo 2 e incio do ciclo 3 durante a aplicao do processo em campo, mostraram a

necessidade de melhoria do processo. Esta evoluo necessria, visto que a incluso do

sistema informatizado altera o ambiente de trabalho dos usurios, passando da interao

face a face para a interao mediada pelo software. Os resultados obtidos evidenciaram que

o maior grau de conscincia dos usurios sobre como os inter-relacionamentos de suas

atividades so realizados contribuem para um decrscimo em seus erros individuais,

diminuindo o retrabalho de recodificao do software e acima de tudo o uso inadequado do

sistema, evitando a propagao das consequncias desses erros nos resultados finais do

trabalho em grupo.

Palavras-chave: Anlise Coletiva do Trabalho. Requisitos de Software. Modelos mentais.

Trabalho cooperativo apoiado por computador. Mente coletiva

ABSTRACT

Users' work in information systems is a social activity that involves people groups

cooperating to perform many different functions. The nature of cooperation itself is complex

and depends on the people involved, on the workplace environment and on the organization

in which the work develops. Aspects related to the users' cooperative work are not

considered in the traditional approach of software engineering, since the user is viewed

independently of his/her workplace environment or group, with the individual model

generalized to the study of collective behavior of all users. This work proposes a process for

software requirements to address issues involving cooperative work in information systems

that provide distributed coordination in the users' actions and the communication among

them occurs indirectly through the data entered while using the software. To achieve this

goal, this research uses ergonomics, cognition and software engineering concepts.

Research-action is used as a research methodology applied in three cycles during the

development of a corporate workflow system in a technological research company. In the

first cycle, the proposed process exposes the definition of the problem domain requirements

and the users' individual contributions. In the second cycle, the contributions of the group

(their actions and inter-relationships) are considered together with the individual contributions

through the simulation of the proposed solution. In the third cycle, the process deals with the

refinement of the cooperative work requirements with the software in actual use in the

workplace. The results at the end of cycle 2 and the beginning of cycle 3 during the process

application in the field show the need for process improvement. This is necessary because

the inclusion of a computer system changes the users workplace, from the face to face

interaction to the interaction mediated by the software. The results show that the highest

degree of users' awareness as the interrelationship of their activities are carried out

contributes to a decrease in their individual errors, reducing software recoding rework and

above all the inappropriate use of the system, avoiding the spread of the consequences of

these errors in the final results of the group work.

Keywords: Collective analysis at work. Software requirements. Mental models. Computer

supported cooperative work. Collective mind

LISTA DE ILUSTRAES

Figura I.1 - Representao grfica da pesquisa proposta ......................................... 28

Figura I.2 - Contextualizao da pesquisa ................................................................ 33

Figura II.1 - Modelos mentais .................................................................................... 49

Figura II.2 - Modelos de cooperao ......................................................................... 62

Figura II.3 - Diagrama dos 3Cs e awareness ............................................................ 64

Figura II.4 - Modelo em cascata ................................................................................ 75

Figura II.5 - Modelo Espiral de processo de software ............................................... 78

Figura II.6 - Desenvolvimento baseado em componentes ........................................ 81

Figura II.7 - Entradas e sadas do processo de Engenharia de Requisitos ............... 87

Figura II.8 - Subprocessos do processo de Engenharia de Requisitos ..................... 88

Figura II.9 - Notao do diagrama de fluxo de dados (DFD) ..................................... 94

Figura II.10 - Modelo de entidade e relacionamento (MER) ...................................... 95

Figura II.11 - Caso de uso ....................................................................................... 100

Figura III.1 - Ciclos da Pesquisa-ao ..................................................................... 115

Figura III.2 - Iterao dos ciclos da Pesquisa-ao ................................................. 120

Figura III.3 - Espiral dos ciclos da Pesquisa-ao ................................................... 122

Figura IV.1 - Macroprocesso para a identificao das caractersticas do trabalho

cooperativo Fonte: elaborado pelo autor .............................................. 130

Figura IV.2 - Modelo da teoria proposta .................................................................. 131

Figura IV.3 - Processo para anlise de viabilidade e aplicabilidade ........................ 132

Figura IV.4 - Processo para identificao das caractersticas individuais do trabalho

cooperativo ........................................................................................... 135

Figura IV.5 - Processo para simulao e identificao das caractersticas

cooperativas do trabalho....................................................................... 143

Figura IV.6 - Modelo para aplicao das sesses de ACT ...................................... 143

Figura IV.7 - Relao entre fases do processo e interfaces grficas das sesses de

ACT ...................................................................................................... 145

Figura IV.8 - Processo para o refinamento da identificao das caractersticas do

trabalho cooperativo ............................................................................. 149

Figura IV.9 - Modelo para a aplicao das sesses de ACT ................................... 150

Figura IV.10 - Passos da Pesquisa-ao e correspondentes atividades para os

processos de identificao e refinamento das caractersticas

cooperativas do trabalho....................................................................... 157

Figura V.1 - Fluxograma inicial e respectivas fases: processo no informatizado 167

Figura V.2 - Diagrama de contexto inicial do ciclo 1 ................................................ 170

Figura V.3 - Constituio do pedido ........................................................................ 172

Figura V.4 - Anlise crtica do contrato ................................................................... 172

Figura V.5 - Habilitao do pedido .......................................................................... 172

Figura V.6 - Realizao do trabalho ........................................................................ 172

Figura V.7 - Encerramento do processo .................................................................. 173

Figura V.8 - Diagrama de contexto final do ciclo 1 do software de atendimento

laboratorial ............................................................................................ 174

Figura V.9 - Fluxograma final do ciclo 1 .................................................................. 174

Figura V.10 - Solicitao do pedido ......................................................................... 175

Figura V.11 - Oramentao ................................................................................... 176

Figura V.12 - Registro de material ........................................................................... 176

Figura V.13 - Realizao do trabalho ...................................................................... 177

Figura V.14 - Entrega .............................................................................................. 177

Figura VI.1 - Passos da Pesquisa-ao e correspondentes atividades ................... 187

Figura VI.2 - Dinmica das iteraes do ciclo 2 ...................................................... 189

Figura VI.3 - Oramentao (reproduo do ciclo 1) ............................................... 191

Figura VI.4 - Fase de oramentao: interface em DHTML .................................... 192

Figura VI.5 - Diagrama simplificado de navegao da fase de oramentao: Inserir

servio do laboratrio ........................................................................... 193

Figura VI.6 - Reproduo do fluxograma final do ciclo 1 ......................................... 194

Figura VI.7 - Oramentao multilaboratorial .......................................................... 196

Figura VI.8 - Dados utilizados do sistema Custos e Preos .................................... 196

Figura VI.9 - Diagrama simplificado de navegao da fase de oramentao: inserir

oramento gerado por outro laboratrio ............................................... 197

Figura VI.10 - Fluxograma do processo aps a iterao 1 ...................................... 198

Figura VI.11 - Fluxograma do processo discutido na iterao 2 (segunda sesso) 199

Figura VI.12 - Diagrama de contexto, considerando a interface com o sistema de

numerao do documento tcnico ........................................................ 200

Figura VI.13 - Fluxograma final do processo, considerando o detalhamento desta

sesso .................................................................................................. 201

Figura VI.14 - Registro de material e distribuio de OS ........................................ 204

Figura VI.15 - Inspeo e execuo da OS ............................................................. 205

Figura VI.16 - Composio do documento tcnico .................................................. 206

Figura VI.17 - Coordenao individual e pgina principal do software .................... 208

Figura VI.18 - Coordenao individual e pgina principal do software .................... 209

Figura VI.19 - Coordenao com as atividades do grupo ....................................... 209

Figura VI.20 - Balano das atividades do grupo de trabalho ................................... 211

Figura VII.1 - Diagrama dos 3Cs e awareness adaptado ao ciclo 3 ........................ 225

Figura VII.2 - Coordenao individual e pgina principal do software - reproduo

.............................................................................................................. 226

Figura VII.3 - Coordenao com as atividades do grupo reproduo .................. 227

Figura VII.4 - Passos da Pesquisa-ao e correspondentes atividades (ciclo 3) .... 228

Figura VII.5 - Dinmica das iteraes do ciclo 3 ..................................................... 229

Figura VII.6 - Pgina principal e opes .................................................................. 239

Figura VII.7 - Troca de cliente/Alterao cadastral .................................................. 240

Figura VII.8 - Alterao cadastral ............................................................................ 241

Figura VII.9 - Inspeo e execuo da OS (servios associados ao material da fase)

.............................................................................................................. 242

Figura VII.10 - Inspeo e execuo da OS (servios associados aos demais

materiais) .............................................................................................. 243

Figura VII.11 - Viso geral ....................................................................................... 244

Figura VII.12 - Histrico de follow-up ...................................................................... 245

Figura VII.13 - Pgina principal: acesso transversal ............................................... 246

Figura VII.14 - Acesso transversal: pendncias ...................................................... 247

Figura VII.15 - Acesso transversal: escolha da fase ............................................... 247

Figura VII.16 - Composio do documento tcnico visualizado por meio do artefato

Acesso transversal ............................................................................... 248

Figura VII.17 - Histrico de andamento do pedido .................................................. 249

Figura VIII.1 - Variao da intensidade dos tipos de requisitos nos ciclos da PA ... 262

Figura VIII.2 - Variao esperada da intensidade dos tipos de requisitos nos ciclos

da PA, aps a aplicao das mudanas sugeridas .............................. 263

LISTA DE TABELAS

Tabela VII.1 - Avaliao qualitativa do trabalho cooperativo da sesso 1 ............... 250

Tabela VII.2 - Avaliao qualitativa do trabalho cooperativo da sesso 2 ............... 253

Tabela VII.3 - Avaliao qualitativa do trabalho cooperativo das sesses 1 e 2 ..... 257

LISTA DE QUADROS

Quadro I.1 - Quadro geral da pesquisa ..................................................................... 32

Quadro II.1 - Elementos de awareness para sistemas assncronos e desacoplados

................................................................................................................ 72

Quadro II.2 - Papis no processo de Engenharia de Requisitos ............................... 89

Quadro III.1 - Principais mtodos de pesquisa em Engenharia de Produo ........ 111

Quadro III.2 - Sntese dos passos e aes utilizadas .............................................. 116

Quadro III.3 - Delineamento da pesquisa ................................................................ 121

Quadro IV.1 - Anlise de viabilidade: questes a serem consideradas ................... 133

Quadro IV.2 - Identificao das caractersticas iniciais: questes a serem

consideradas ........................................................................................ 137

Quadro IV.3 - Simulao do prottipo em papel: questes a serem consideradas . 139

Quadro IV.4 - Avaliao sobre o trmino da prototipao em papel: questes a

serem consideradas ............................................................................. 140

Quadro IV.5 - Avaliao sobre trmino da prototipao no funcional: questes a

serem consideradas ............................................................................. 148

Quadro IV.6 - Elementos de awareness (reproduo do Quadro II.1) .................... 152

Quadro IV.7 - Avaliao qualitativa sobre a intensidade da mente coletiva nas

sesses de ACT ................................................................................... 154

Quadro IV.8 - Quadro metodolgico ........................................................................ 157

Quadro V.1 - Anlise da viabilidade: respostas ....................................................... 164

Quadro V.2 - Situaes de referncia e aes futuras provveis............................ 170

Quadro V.3 - Identificao das caractersticas iniciais: respostas ........................... 171

Quadro V.4 - Simulao do prottipo em papel: respostas ..................................... 178

Quadro V.5 - Avaliao sobre trmino da prototipao em papel: respostas .......... 183

Quadro VII.1 - Resumo das entrevistas realizadas no passo de anlise e

planejamento 1 ..................................................................................... 235

Quadro VII.2 - Elementos de awareness para sistemas assncronos e desacoplados

.............................................................................................................. 236

Quadro VII.3 - Artefatos desenvolvidos como resultados obtidos das entrevistas da

iterao 1 .............................................................................................. 237

Quadro VII.4 - Avaliao qualitativa do trabalho cooperativo nas sesses de ACT

.............................................................................................................. 239

Quadro VII.5 - Artefatos emergentes da sesso 2, elementos de awareness e aes

.............................................................................................................. 249

LISTA DE ABREVIATURAS E SIGLAS

ACT Anlise Coletiva do Trabalho

CASE Computer Aided Software Engineering

CMM Capability Maturity Model

CSCW Computer Supported Cooperative Work

DFD Diagrama de Fluxo de Dados

DHTML Dynamic Hyper Text Markup Language

DotNet Framework de ferramentas de desenvolvimento da Microsoft

ED Engenharia de Domnio

ELABSOFT Laboratrio de Desenvolvimento de Projetos e Processos de Software

do Departamento de Engenharia de Produo

ENEGEP Encontro Nacional da Engenharia de Produo

EP Engenharia de Produo

EPN Engenharia de Processos de Negcios

ER Engenharia de Requisitos

ERP Enterprise Resource Planning

ES Engenharia de Software

IDEF0 Integration Definition Language

JAD Joint Application Development

ISO International Organization for Standardization

MANWAPP Manuteno de servios via aplicaes WEB

MER Modelo de Entidade e Relacionamentos

MSF Microsoft Solution Framework

PA Pesquisa-Ao

PesqTec Empresa pblica de desenvolvimento de pesquisa tecnolgica

RUP Rational Unified Process

Sistema Sistema informatizado

TI Tecnologia da Informao

TIC Tecnologia da Informao e Comunicao

TQM Total Quality Management

UML Unified Modeling Language

WWW World Wide Web

SUMRIO

I INTRODUO ............................................................................................... 25

I.1 APRESENTAO E CONTEXTUALIZAO DO PROBLEMA .................. 25

I.2 QUESTES DA PESQUISA E OBJETIVO ................................................. 28

I.3 NECESSIDADES EMPRICAS PARA A CONDUO DA PESQUISA ...... 30

I.4 O ASPECTO METODOLGICO DA PESQUISA ....................................... 32

I.5 ESTRUTURA DO TRABALHO.................................................................... 34

II FUNDAMENTAO TERICA ...................................................................... 36

II.1 A DIMENSO COLETIVA DO TRABALHO E O TRABALHO

COOPERATIVO .......................................................................................... 36

II.1.1 Conceito de trabalho cooperativo ........................................................ 37

II.1.2 Dimenses do trabalho coletivo ........................................................... 39

II.1.3 Consideraes sobre a dimenso coletiva do trabalho ........................ 41

II.2 ANLISE COLETIVA DO TRABALHO ........................................................ 41

II.2.1 Introduo/conceituao ...................................................................... 42

II.2.2 As tcnicas da ACT ............................................................................. 43

II.2.3 Caractersticas da ACT e resultados ................................................... 44

II.2.4 Consideraes sobre a aplicao do mtodo da Anlise Coletiva do

Trabalho ............................................................................................... 47

II.3 MODELO MENTAL E INTERAO ............................................................ 48

II.3.1 Modelo mental e interao ................................................................... 48

II.3.2 A ergonomia das interfaces ................................................................. 51

II.3.3 Consideraes sobre modelo mental e interao e ergonomia das

interfaces ............................................................................................. 52

II.4 TEORIA DA MENTE COLETIVA ................................................................. 53

II.4.1 Aes ligadas teoria da mente coletiva em desenvolvimento dos

sistemas informatizados ...................................................................... 54

II.4.2 Processos sociais no desenvolvimento da mente coletiva .................. 58

II.4.3 Consideraes sobre a teoria da mente coletiva ................................. 60

II.5 CSCW, GROUPWARE, MODELO 3C E AWARENESS ............................. 61

II.5.1 CSCW e Groupware ............................................................................ 61

II.5.2 Modelo 3C ........................................................................................... 61

II.5.3 Awareness ........................................................................................... 63

II.5.4 Awareness e o modelo 3C ................................................................... 64

II.5.5 Elementos de awareness ..................................................................... 65

II.5.6 Consideraes sobre awareness ......................................................... 73

II.6 MODELOS E PROCESSOS DE SOFTWARE ............................................ 74

II.6.1 Conceitos e definies ......................................................................... 74

II.6.2 Modelo em cascata .............................................................................. 75

II.6.3 Modelo de desenvolvimento iterativo evolucionrio ............................. 77

II.6.4 Modelo de transformao formal ......................................................... 80

II.6.5 Modelo de desenvolvimento baseado em componentes ..................... 80

II.6.6 Processo de desenvolvimento de software .......................................... 81

II.6.7 Consideraes sobre modelos e processos de software ..................... 83

II.7 ENGENHARIA DE REQUISITOS (ER) ....................................................... 83

II.7.1 Conceitos e definies ......................................................................... 83

II.7.2 Elementos da Engenharia de Requisitos ............................................. 84

II.7.3 Processo de Engenharia de Requisitos ............................................... 87

II.7.4 Modelos de sistema ............................................................................. 92

II.7.5 Consideraes sobre Engenharia de Requisitos ................................. 98

II.8 TCNICAS UTILIZADAS NA DESCOBERTA DE REQUISITOS ................ 99

II.8.1 Cenrios .............................................................................................. 99

II.8.2 Entrevista ........................................................................................... 101

II.8.3 Storyboarding/Tcnicas de Prototipao ........................................... 101

II.8.4 Etnografia .......................................................................................... 107

II.8.5 Consideraes sobre tcnicas utilizadas na descoberta de requisitos

........................................................................................................... 109

III METODOLOGIA DE PESQUISA .................................................................. 110

III.1 INTRODUO .......................................................................................... 110

III.2 ESTRATGIA METODOLGICA: PESQUISA-AO .............................. 111

III.2.1 Conceituao geral da pesquisa-ao ............................................... 111

III.2.2 Ciclos da pesquisa-ao .................................................................... 114

III.3 CARACTERIZAO DA CONDUO DA PESQUISA-AO ................. 116

III.4 DELINEAMENTO DO PROJETO DE PESQUISA .................................... 119

III.4.1 Reviso bibliogrfica metodolgica e aplicada .................................. 123

III.4.2 Contexto e propsitos ........................................................................ 123

III.4.3 Conduo do primeiro ciclo da pesquisa-ao: processo para

especificao de requisitos de software com foco na identificao das

caractersticas individuais do trabalho cooperativo e das caractersticas

de domnio ......................................................................................... 124

III.4.4 Conduo do segundo ciclo da pesquisa-ao: processo para

especificao de requisitos de software com foco na identificao e

simulao das caractersticas cooperativas do trabalho .................... 125

III.4.5 Conduo do terceiro ciclo da pesquisa-ao: Processo para

especificao de requisitos de software com foco no refinamento das

caractersticas do trabalho cooperativo (em uso real); ...................... 125

III.4.6 Elaborao da tese com os resultados da pesquisa .......................... 126

IV PROCESSO PROPOSTO ............................................................................ 127

IV.1 CONTEXTO .............................................................................................. 127

IV.2 DESCRIO GERAL DO PROCESSO .................................................... 129

IV.3 ANLISE DE VIABILIDADE E DA APLICALIBIDADE DO PROCESSO ... 131

IV.3.1 Anlise de viabilidade ........................................................................ 132

IV.3.2 Verificao da aplicabilidade do processo ao sistema candidato ...... 133

IV.4 PROCESSO PARA ESPECIFICAO DE REQUISITOS DE SOFTWARE

COM FOCO NA IDENTIFICAO DAS CARACTERSTICAS INDIVIDUAIS

DO TRABALHO COOPERATIVO E DAS CARACTERSTICAS DE

DOMNIO .................................................................................................. 134

IV.4.1 Implementao/reviso do prottipo em papel .................................. 135

IV.4.2 Simulao do prottipo em papel ....................................................... 138

IV.4.3 Anlise dos dados- avaliao sobre o trmino da prototipao em

papel .................................................................................................. 140

IV.5 PROCESSO PARA ESPECIFICAO DE REQUISITOS DE SOFTWARE

COM FOCO NA IDENTIFICAO E SIMULAO DAS

CARACTERSTICAS COOPERATIVAS DO TRABALHO ......................... 141

IV.5.1 Implementao/reviso prottipo no funcional ................................. 144

IV.5.2 Apresentao do prottipo no funcional ........................................... 145

IV.5.3 Anlise dos dados - avaliao sobre o trmino da prototipao no

funcional ............................................................................................ 147

IV.6 PROCESSO PARA ESPECIFICAO DE REQUISITOS DE SOFTWARE

COM FOCO NO REFINAMENTO DAS CARACTERSTICAS DO

TRABALHO COOPERATIVO.................................................................... 149

IV.6.1 Implementao em cascata ............................................................... 150

IV.6.2 Apresentao do prottipo evolucionrio (funcional) ......................... 152

IV.6.3 Anlise dos dados - avaliao do trmino do prottipo evolutivo ...... 155

IV.7 PLANEJAMENTO DE EXECUO DO PROCESSO PROPOSTO EM

FUNO DOS CICLOS DA PESQUISA-AO ....................................... 156

V FASE PRELIMINAR E CICLO 1 DA PESQUISA-AO: PROCESSO PARA

ESPECIFICAO DE REQUISITOS DE SOFTWARE COM FOCO NA

IDENTIFICAO DAS CARACTERSTICAS INDIVIDUAIS DO TRABALHO

COOPERATIVO E DAS CARACTERSTICAS DE DOMNIO ...................... 160

V.1 CONTEXTO E PROPSITOS .................................................................. 160

V.1.1 Contexto emprico .............................................................................. 160

V.1.2 Contexto conceitual: anlise de viabilidade ....................................... 162

V.1.3 Contexto conceitual: verificao da aplicabilidade do processo ao

sistema candidato .............................................................................. 164

V.2 CICLO 1: PROCESSO PARA ESPECIFICAO DE REQUISITOS DE

SOFTWARE COM FOCO NA IDENTIFICAO DAS CARACTERSTICAS

INDIVIDUAIS DO TRABALHO COOPERATIVO ....................................... 165

V.2.1 Introduo .......................................................................................... 165

V.2.2 Implementao .................................................................................. 166

V.2.3 Levantamento e discusso dos dados ............................................... 178

V.2.4 Anlise e planejamento do ciclo 1 ...................................................... 182

V.2.5 Concluses do ciclo 1 (passo de monitoramento da PA) ................... 184

VI CICLO 2 DA PESQUISA-AO: PROCESSO PARA ESPECIFICAO DE

REQUISITOS DE SOFTWARE COM FOCO NA IDENTIFICAO E

SIMULAO DAS CARACTERSTICAS DO TRABALHO COOPERATIVO 185

VI.1 INTRODUO .......................................................................................... 185

VI.2 DINMICA DA ITERAO DO CICLO 2 .................................................. 186

VI.2.1 Dados do grupo e do ambiente das sesses ..................................... 186

VI.2.2 Dinmica geral das iteraes ............................................................. 187

VI.3 RESULTADOS (DETALHAMENTO DAS ITERAES) ........................... 190

VI.3.1 Iterao 1 ........................................................................................... 190

VI.3.2 Iterao 2 ........................................................................................... 194

VI.3.3 Iterao 3 ........................................................................................... 199

VI.3.4 Iterao 4 ........................................................................................... 203

VI.3.5 Iterao 5 ........................................................................................... 207

VI.3.6 Iterao 6 ........................................................................................... 211

VI.4 CONCLUSES DO CICLO 2 (PASSO DE MONITORAMENTO DA PA) . 219

VII CICLO 3 DA PESQUISA-AO: PROCESSO PARA ESPECIFICAO DE

REQUISITOS DE SOFTWARE COM FOCO NO REFINAMENTO DAS

CARACTERSTICAS DO TRABALHO COOPERATIVO (EM USO REAL) .. 222

VII.1 INTRODUO .......................................................................................... 222

VII.2 DINMICA DE ITERAO DO CICLO 3 .................................................. 223

VII.2.1 Dados do grupo e do ambiente das sesses ..................................... 223

VII.2.2 Modelo 3C e awareness para o ciclo 3 .............................................. 225

VII.2.3 Caractersticas gerais do sistema informatizado desta PA ................ 227

VII.2.4 Dinmica geral das iteraes ............................................................. 228

VII.3 RESULTADOS (DETALHAMENTO DAS ITERAES) ........................... 230

VII.3.1 Iterao 1 ........................................................................................... 230

VII.3.2 Iterao 2 ........................................................................................... 235

VII.3.3 Iterao 3 ........................................................................................... 251

VII.4 CONCLUSES DO CICLO 3 (PASSO DE MONITORAMENTO DA PA) . 254

VIII ANLISE FINAL ........................................................................................... 259

VIII.1 CONCLUSES ......................................................................................... 259

VIII.2 PROPOSTA DE ALTERAO DO PROCESSO ...................................... 262

VIII.3 CONTRIBUIES .................................................................................... 264

VIII.4 PROPOSTAS PARA FUTUROS TRABALHOS ........................................ 265

VIII.5 CONSIDERAES FINAIS ...................................................................... 265

IX REFERNCIAS ............................................................................................ 268

APNDICE A: PROCESSOS, MODELAGEM E WORKFLOW ............................ 278

APNDICE B: ERGONOMIA DAS INTERFACES (USABILIDADE) ..................... 285

25

I INTRODUO

Este captulo descreve qual o problema estudado pela pesquisa e seu respectivo

enquadramento dentro das reas da cincia. As principais questes, os objetivos e

os motivos que levaram realizao deste trabalho so apresentados.

A metodologia da pesquisa-ao aplicada em um projeto de workflow corporativo

de uma empresa de pesquisa tecnolgica brasileira.

I.1 APRESENTAO E CONTEXTUALIZAO DO PROBLEMA

O avano tecnolgico conseqncia das demandas sociais e dos setores

produtivos. Os problemas e desafios do mundo moderno apresentam dimenses e

complexidade tais que suas solues envolvem cada vez mais o trabalho em equipe,

em razo do aumento da concorrncia, da rpida evoluo da demanda, da

presente inovao dos produtos e da transformao das tecnologias.

Deste modo, as empresas abdicam dos modelos clssicos de organizao,

considerados mais eficazes em contextos mais estveis e de produo de massa,

passando para um modelo focado no contexto da cooperao, cujas decises

relativas concepo, fabricao e comercializao devem ser tomadas

(SALERNO, 1999). Assim, aposta-se no trabalho cooperativo como meio de

transformao conjunta dos indivduos, das coletividades e das organizaes, tendo

como objetivo o incremento da eficcia organizacional (TAVARES, 2002).

A definio de cooperao utilizada neste trabalho dada por Dejours (2005, p. 93):

Cooperao uma conduta coordenada, definida como a ao de participar

de uma obra comum. A cooperao supe um lugar onde, ao mesmo

tempo, convergem as contribuies singulares e cristalizam-se as relaes

de dependncia entre os sujeitos.

A dimenso coletiva do trabalho colocada no centro da mudana pelo discurso e

prtica empresarial, com a mudana de organizao do trabalho, de procedimentos

de fabricao, de prticas profissionais e, tambm, das mudanas nas competncias

dos trabalhadores.

26

Hoje, embora a maioria das metodologias utilizadas em desenvolvimento de

software preveja a participao e o envolvimento dos usurios em vrias fases de

seu processo de desenvolvimento, a questo do trabalho cooperativo necessrio

para executar as atividades que sero informatizadas, no considerada de modo

explcito desde o incio de seu projeto.

Uma das explicaes para esta situao que na abordagem tradicional de

desenvolvimento de software (para sistemas de computadores tradicionais ou

sistemas comerciais, fortemente orientados a dados), a hiptese mais

frequentemente utilizada a de que os modelos so centrados em um nico usurio

(tido como padro e independente do meio ou grupo no qual est inserido), sendo

generalizados para o estudo do comportamento cooperativo, envolvendo todos os

usurios.

Nesta pesquisa, sero utilizados dois conceitos recorrentes cujas definies logo no

incio deste trabalho so necessrias: sistema de informao (SI) e sistemas

informatizados (software).

O sistema de informao corresponde a um sistema informatizado ou manual que

abrange pessoas, mquinas e/ou mtodos organizados para coletar, processar,

guardar, transmitir e disseminar dados que representam informao para o usurio.

J o sistema informatizado ou software, corresponde parte do sistema de

informao que ser automatizada por meio da Tecnologia de Informao TI (neste

trabalho, o termo sistema equivalente a sistema informatizado).

Sommerville (2007) cita a importncia de utilizao de mtodos alternativos na fase

de descoberta dos requisitos de um sistema informatizado quando se trata

particularmente das seguintes situaes:

Os requisitos de software so derivados do modo como as pessoas trabalham

(trabalho real) mais do que aquilo que a definio dos processos recomenda

para o trabalho (trabalho prescrito);

Os requisitos de software so derivados da cooperao e percepo das

atividades de outras pessoas (grifo do autor).

Para estes casos em questo, o autor recomenda o uso de tcnicas de etnografia

(definida pelo autor como uma tcnica observacional que pode ser utilizada para se

entender os requisitos sociais e organizacionais, na qual o analista se integra e

27

interage no ambiente onde o sistema informatizado ser utilizado), com a aplicao

de tcnicas de cenrios (definidos como exemplos relacionados ao mundo real de

como os usurios podem interagir com o sistema de informao).

Pressman (2005) cita que, na fase de descoberta de requisitos (elicitao),

importante o uso de reunies colaborativas para definio dos requisitos, nas quais

a meta identificar o problema, propor diferentes abordagens e definir um conjunto

de requisitos consensuais. O autor no define mecanismos para estabelecer como o

trabalho cooperativo dever ser mapeado para o sistema informatizado que dar

suporte ao SI.

Por sua prpria natureza, o trabalho cooperativo depende da vontade das pessoas

trabalharem em conjunto, no pode ser prescrito (DANIELLOU e SIX, 2003), e a

introduo de sistemas informatizados transforma por completo o ambiente e a

atividade. Neste caso, o trabalho com o novo sistema ser diferente do atual e

mesmo que se faa uma anlise acurada do trabalho existente, no h garantias de

que seja possvel imaginar de modo completo sua utilizao futura.

Para que seja possvel tratar o paradoxo da concepo (DANIELLOU, 2007) - na

construo de um sistema informatizado que ir substituir parte de um SI, preciso

dispor desse sistema antecipado e para conceb-lo adequadamente necessrio

conhecer em primeiro lugar a atividade futura dever ser estabelecido um

processo que trata esta questo, levando em conta sobretudo o fato de que as

pessoas trabalham em conjunto para atender a uma srie de objetivos estabelecidos

e que os usurios tm inerentemente dificuldades para discutir como efetivamente

esta cooperao ocorre (SOMMERVILLE, 2007).

Esta pesquisa enquadra-se dentro dos campos de Engenharia de Software (subrea

da Engenharia de Requisitos) e da cincia denominada trabalho cooperativo apoiado

por computador (Computer Supported Cooperative Work - CSCW). O CSCW um

campo interdisciplinar, no qual os pesquisadores de vrias reas (cientistas sociais,

psiclogos, cientistas cognitivos, ergonomistas e profissionais de interao humano-

computador) contribuem com diferentes perspectivas e metodologias para aquisio

de conhecimento do trabalho em grupo e para sugestes de como o trabalho em

grupo pode ser suportado por meio do uso das tecnologias de redes de

28

computadores e respectivo hardware (denominado de groupware) (KOCH e

GROSS, 2006; GROSS; TRAUNMULLER, 1996).

A Figura I.1 mostra a contextualizao desta pesquisa, em que pode ser visto que

este trabalho d apoio Engenharia de Requisitos de Software (ER) por meio de um

processo para a especificao de requisitos de software, focando, pelo uso de

conhecimentos de outras reas da cincia, o componente do trabalho cooperativo do

Sistema de Informao (domnio do problema) que est sendo informatizado.

Figura I.1 - Representao grfica da pesquisa proposta

Fonte: elaborado pelo autor

I.2 QUESTES DA PESQUISA E OBJETIVO

Considerando a busca por meios que conduzam (s) resposta(s) ao problema

apresentado, do foco principal da pesquisa e aps a realizao da pesquisa

bibliogrfica, este trabalho procura responder seguinte questo principal:

Como considerar na especificao de requisitos de software a dimenso

cooperativa do trabalho em sistemas de informao?

Com a derivao das seguintes questes:

Como, pelas contribuies (individuais) dos stakeholders, estabelecer os

principais artefatos necessrios para a simulao do trabalho cooperativo por

29

meio do software que ser implementado? (No caso de sistemas

informatizados, stakeholders so todos os envolvidos no processo de

especificao e uso, por exemplo, clientes, colaboradores, investidores,

fornecedores, comunidade, etc. Artefatos so definidos em engenharia de

software como subprodutos de uma ou mais atividades dentro do contexto do

desenvolvimento de um software);

Quais so os instrumentos a serem elaborados para captar os requisitos de

software da dimenso cooperativa do trabalho de um SI durante a simulao

do sistema informatizado que lhe dar suporte?

Como estes instrumentos podem ser concatenados para captar os requisitos

de software do trabalho cooperativo durante a simulao do sistema

informatizado?

A soluo proposta pode ser aplicada para refinar os requisitos de software

do trabalho cooperativo durante o uso (em situao de trabalho) do sistema

informatizado?

Quais so os instrumentos a serem elaborados para refinar os requisitos de

software da dimenso cooperativa do trabalho de um SI durante o uso do

sistema informatizado que lhe dar suporte?

Como estes instrumentos podem ser concatenados para refinar os requisitos

de software do trabalho cooperativo durante o uso do sistema informatizado?

Como avaliar a evoluo da identificao dos requisitos de software do

trabalho cooperativo obtidos durante o uso do sistema informatizado pela

aplicao da soluo proposta?

Em funo do problema e das questes apresentadas, esta pesquisa tem como

objetivo principal:

Contribuir para o mapeamento das caractersticas do trabalho cooperativo de

um ambiente de produo em uma especificao de software por meio de um

processo para levantamento de requisitos.

E como objetivos especficos:

30

Com base na literatura, estudar e propor conceitos, tcnicas e mtodos que

devem ser aplicados Engenharia de Requisitos, levando em conta o

trabalho cooperativo em sistemas de informao;

Planejar, estruturar e executar uma pesquisa-ao voltada para desenvolver,

aplicar, avaliar e aperfeioar o processo proposto.

Assim, este trabalho pretende oferecer uma contribuio de cunho emprico,

associada a uma contribuio terica no sentido de um refinamento e/ou extenso

da teoria (I.4).

I.3 NECESSIDADES EMPRICAS PARA A CONDUO DA PESQUISA

A motivao inicial da pesquisa sobre o tema surgiu em 2004, com a participao do

autor no projeto Manwapp, do ElabSoft - Laboratrio de Desenvolvimento de

Projetos e Processos de Software do Departamento de Engenharia de Produo da

Escola Politcnica da Universidade de So Paulo, constitudo por um grupo de

especialistas em Tecnologia da Informao (TI).

Para Trindade (2006), o objetivo principal do ElabSoft constitui-se em levantar,

discutir, experimentar e gerir conhecimentos direta e indiretamente ligados

aplicabilidade da Engenharia de Software, visando potencializar a produtividade no

desenvolvimento de software por meio de processos otimizados, tanto de

manufatura como de organizao e gerenciamento da produo.

O projeto Manwapp teve o objetivo de gerenciar servios de campo (servios

terceirizados) ligados s reas de telecomunicaes e energia eltrica, entre outras.

Este gerenciamento se deu pelo acompanhamento da solicitao de chamadas

(servios) at o seu trmino, envolvendo a rea administrativa do cliente, infra-

estrutura, logstica e manuteno e o prestador de servios.

Este projeto usava a plataforma Internet como meio de integrao e acesso dos

usurios ao sistema, sendo apoiado tambm por tecnologias wireless. O Manwapp

foi desenvolvido, com a colaborao dos participantes do grupo, baseado na

utilizao de tcnicas de orientao a objetos e ferramentas CASE (Computer Aided

Software Engineering) apoiadas na UML (Unified Modeling Language), tanto no

projeto (design), como na programao do sistema, no modelo de arquitetura de trs

31

camadas: apresentao, negcios e persistncia, na tecnologia DotNet e processo

RUP (Rational Unified Process), alm de um conjunto de tcnicas e ferramentas de

implementao.

A partir de uma pesquisa realizada durante o desenvolvimento deste projeto, o autor

iniciou o estudo do presente trabalho que originou uma publicao no ENEGEP de

2004 - Proposta de processo de especificao de software a partir de tcnicas

baseadas em suas funcionalidades sob a ptica de seus usurios finais - que fazia

uso combinado de tcnicas de prototipao orientada por casos de uso e JAD e da

lista de eventos, utilizados desde a fase de elicitao de requisitos e reaproveitados

durante todo o ciclo de vida do processo de desenvolvimento de software (GAVA et

al., 2004).

O autor participou tambm de outros projetos para levantamento de requisitos na

empresa onde atua, percebendo a falta de um tratamento formal do trabalho

cooperativo em software que no tratado como groupware (ou seja, sistemas

informatizados comerciais) e as implicaes prticas de se considerar implicitamente

estas caractersticas, como por exemplo, de um maior retrabalho na fase de

codificao do produto, pois nesta fase que este tipo de software acaba

considerando implicitamente as caractersticas do trabalho cooperativo.

A oportunidade para aplicar os conceitos desta pesquisa surgiu em uma empresa

pblica de desenvolvimento de pesquisa tecnolgica, que ser denominada neste

trabalho como PesqTec. O projeto em foco corresponde a um workflow e tem como

objetivo seguir as vrias etapas de um processo de atendimento de solicitaes de

servios, desde a abertura de um pedido, passando por todas as fases de execuo

at sua finalizao, de modo a envolver o trabalho cooperativo dos participantes do

laboratrio (tcnicos, supervisores e secretrias).

Neste projeto, o autor como funcionrio regular da PesqTec, atuou em equipes

multidisciplinares, com competncias de analista de processos, analista de sistemas

e, sobretudo, pesquisador. Desta forma, aconteceu a continuidade emprica do

estudo, caracterizando a metodologia de pesquisa como pesquisa-ao e

consolidando-se o objetivo principal do presente trabalho.

32

I.4 O ASPECTO METODOLGICO DA PESQUISA

Marconi e Lakatos (2000) sintetizam os passos necessrios que devem estar

presentes nas investigaes cientficas:

Descobrimento do problema, que corresponde identificao da lacuna de

conhecimento ou da oportunidade de melhoria de forma clara e precisa;

Procura de conhecimentos ou instrumentos importantes, no sentido de buscar

mais informao ou identificar respostas e meios para solucionar o problema;

Investigao de como o problema est sendo tratado ou solucionado por

outras pessoas;

Esboo de soluo para o problema, de forma plausvel e vivel;

Implementao, teste e concluses sobre a soluo proposta.

Nesta pesquisa, ser utilizada a metodologia de pesquisa-ao descrita em

Coughlan e Coghlan (2002) e Thiollent (2004) aplicada em um projeto de workflow

corporativo em uma grande empresa de pesquisa tecnolgica no Brasil, mostrando

como considerar as questes cooperativas do trabalho em um projeto de

desenvolvimento de software e os resultados obtidos.

Nos dados do Quadro I.1 abaixo podem ser vistos os detalhes com relao

aplicao da pesquisa e na Figura I.2 a contextualizao de sua conduo.

Quadro I.1 - Quadro geral da pesquisa

Componente Pesquisa-ao

Unidade(s) de

interveno

Identificao:

Empresa de economia mista de pesquisas tecnolgicas de grande porte, que atua no setor pblico, com cerca de 1.600 pessoas na fora de trabalho, denominada neste trabalho como PesqTec.

Caractersticas gerais:

Ambiente multifuncional, multidisciplinar, multiplataforma, diversidade de clientes, produtos e servios oferecidos, diversidade de infra-estrutura de hardware e software.

Unidades de Interveno:

- Unidade de Interveno do ciclo1:

Grupo de analistas de negcio

- Unidade de Interveno do ciclo 2:

Representantes dos laboratrios e analistas de negcio

- Unidade de Interveno do ciclo 3:

Trabalhadores de dois laboratrios com caractersticas diferentes

33

Componente Pesquisa-ao

Envolvidos na pesquisa Pesquisadores, diretores, gerentes, analistas de negcio, representantes dos laboratrios (administrativos e tcnicos) e usurios

Interessados nos resultados

Organizaes produtoras de software e fbricas de software, por meio da alta direo, dos empresrios, diretores, gerentes, analistas, desenvolvedores, tcnicos e especialistas;

Pesquisadores das reas de melhoria de processos de desenvolvimento de software

Pesquisadores da rea de CSCW

Fonte: elaborado pelo autor

Figura I.2 - Contextualizao da pesquisa Fonte: elaborado pelo autor

CONTEXTO: Sistemas de informao comerciais e sua automao atravs de softwares

envolvendo mltiplos usurios trabalhando de forma cooperativa.

Premissa:

A definio da dimenso cooperativa do trabalho em softwares exige conhecimentos de outras reas, alm da informtica.

Proposio:

Definir um processo de requisitos de software orientado ao trabalho cooperativo de um SI.

Pesquisa-ao no desenvolvimento em um workflow corporativo em trs ciclos.

Implementao dos ciclos 1 e 2

Resultados obtidos da aplicao do processo nos ciclos 1 e 2

Evoluo do processo em funo dos resultados obtidos, com a aplicao de novos conceitos

Ciclo 3 da pesquisa-ao

Concluses Contribuies

Questo principal:

Como considerar na especificao de requisitos de softwares comerciais a dimenso cooperativa do trabalho em sistemas de informao?

34

Esta pesquisa pretende oferecer uma contribuio de cunho emprico, no sentido de

definir e estabelecer um processo para a especificao de requisitos de software

orientado ao trabalho cooperativo. O objetivo para o meio acadmico contribuir

como referncia para estudos relacionados ao uso de tcnicas de outras reas do

conhecimento aplicadas em engenharia de software para auxiliar no levantamento

de requisitos (de software) referentes ao trabalho cooperativo.

O mtodo o instrumento do pesquisador. Se ele escolher um instrumento

que no se adapte ao seu objeto, no conseguir fazer um bom trabalho.

apenas quando objeto e instrumento se ajustam que o resultado aparece. E

a fica difcil saber o que foi objeto ou instrumento. Surge apenas um novo

produto (FERREIRA, 1999, p. 98).

I.5 ESTRUTURA DO TRABALHO

Esta pesquisa est organizada em oito captulos, resumidos a seguir:

O Captulo I apresenta a proposta do trabalho, o contexto do problema, a motivao

do estudo, os objetivos a serem alcanados e sua estrutura da pesquisa.

O Captulo II trata da fundamentao terica por meio de assuntos envolvidos no

processo proposto: a dimenso coletiva do trabalho e o trabalho cooperativo, anlise

coletiva do trabalho, modelo mental e interao e ergonomia das interfaces, teoria

da mente coletiva, o modelo 3C da cooperao em sistemas CSCW (Computer

Supported Cooperative Work), awareness em trabalho cooperativo apoiado por

computador, modelos e processo de software, Engenharia de Requisitos e tcnicas

utilizadas no descobrimento de requisitos.

O Captulo III apresenta a metodologia de pesquisa, a estrutura e a lgica do

processo de pesquisa, focando o mtodo de pesquisa-ao.

O Captulo IV apresenta o macroprocesso proposto dividido em trs processos

componentes: para obteno das caractersticas individuais do trabalho cooperativo

(prottipo inicial do sistema), para a simulao das caractersticas do trabalho

cooperativo (prottipo no funcional) e para o refinamento destas caractersticas

(prottipo funcional).

35

O Captulo V trata da Fase Preliminar da pesquisa referente caracterizao da

empresa estudada e o ciclo 1 da pesquisa-ao, com foco no trabalho individual dos

usurios por meio da prototipao em papel.

O Captulo VI descreve o ciclo 2 da pesquisa-ao considerando, alm dos aspectos

do trabalho individual, as caractersticas do trabalho cooperativo mais ligadas ao

ambiente de trabalho dos usurios (suas aes e inter-relaes) .

O Captulo VII descreve o ciclo 3 da pesquisa-ao, que, alm de considerar os

aspectos dos dois ciclos anteriores, considera tambm o aspecto de como a

incluso do sistema informatizado altera o ambiente de trabalho dos usurios,

passando da iterao face a face para a iterao mediada pelo software que o

substitui (awareness).

O Captulo VIII faz a anlise final, concluses do trabalho, contribuies relevantes e

sugestes para trabalhos futuros.

No final, as referncias bibliogrficas que nortearam o estudo e os anexos

necessrios para complementar a fundamentao terica so apresentados.

36

II FUNDAMENTAO TERICA

A fundamentao terica foi efetuada ao longo do perodo de durao da pesquisa-

ao. O estudo serviu como embasamento para a construo dos modelos e do

processo que, por sua vez, serviram como guia para o monitoramento e conduo

da pesquisa-ao, assim como ao entendimento do complexo contexto do ambiente

pesquisado, culminando na associao do estudo emprico com o terico.

O estudo de um processo para especificao de requisitos de software orientado ao

trabalho cooperativo em sistemas de informao exige olhar este sistema por meio

de uma estratgia de anlise multidisciplinar (ergonomia, sociologia e engenharia de

software) que, ao ser abordado, leva descoberta gradual dos elementos do

processo, auxiliando a compreenso de como a dimenso coletiva do trabalho deve

ser considerada em seu desenvolvimento.

Nesta seo so definidos os principais aspectos tericos do processo proposto,

focando-se o trabalho cooperativo por meio de duas abordagens, primeiramente

considerando-se as interaes face a face entre usurios (pela conceituao de

trabalho coletivo, Anlise Coletiva do Trabalho e da teoria da mente coletiva) e

depois estas interaes so consideradas por intermdio do software produzido

(modelo 3C de cooperao e awareness em trabalho cooperativo apoiado por

computador).

Para finalizar, o prximo passo a considerao dos conceitos ligados ao modelo

mental, interao e interfaces que servem como suporte para a aplicao dos

conceitos acima descritos pela Engenharia de Software (modelos de processo de

software, Engenharia de Requisitos (ER) e tcnicas utilizadas na ER).

II.1 A DIMENSO COLETIVA DO TRABALHO E O TRABALHO

COOPERATIVO

A valorizao crescente do trabalho em grupo, conforme observado no item I.1 d

margem para a consequente valorizao de sua anlise. Esta tendncia mostra a

necessidade das empresas procurarem outros modelos de organizao alm dos

modelos tradicionais (taylorismo/fordismo), considerados eficazes em ambientes

37

mais estveis e de produo em massa, e as decises relativas concepo,

fabricao e comercializao passam a ser concebidas em um contexto de

cooperao (SALERNO, 1999).

Neste item, exploram-se com mais profundidade os conceitos envolvidos com o

trabalho coletivo/cooperativo, assim como as dimenses que o mesmo pode

assumir.

II.1.1 Conceito de trabalho cooperativo

Em geral, os modelos clssicos utilizados em anlises do trabalho no abordam

aspectos da dimenso coletiva do trabalho, em relao interdependncia existente

entre tarefas e/ou atividades de vrios operadores ou quanto importncia das

relaes sociais em uma equipe de trabalho (BARTHE, 2003).

A tarefa a prescrio do que deve ser feito por um operador, sendo definida pela

organizao com base em um objetivo (o estado final desejado) e pelas condies

para sua realizao (os procedimentos, os constrangimentos de tempo, os meios

disposio e pelas caractersticas do ambiente fsico, etc.). A atividade o que

feito, a estratgia de adaptao que o sujeito mobiliza para efetuar a tarefa, sendo

que o operador fixa para si um objetivo, a partir do objetivo da tarefa, para finalizar a

atividade (FALZON, 2007).

Uma vez que a dimenso coletiva do trabalho torna a situao mais flexvel, cada

vez mais complicada e menos determinista (para um dado observador) das inter-

relaes (interaes, retroaes, interferncias, etc.), a complexidade sistmica

aumenta, manifestando-se no fato que o todo possui qualidades e propriedades que

no se encontram no plano das partes consideradas isoladamente e, tambm, pelo

fato de que as partes possuem qualidades e propriedades que desaparecem sob o

aspecto das coaes organizacionais do SI (MORIN, 2002).

Uma nova ordem de complexidade aparece quando a existncia e a manuteno de

sua diversidade so inseparveis das inter-relaes com o ambiente, inter-relaes

(e que so ao mesmo tempo autnomas e dependentes) com as quais o SI tira do

exterior matria-energia e em um grau de complexidade superior: informao

(MORIN, 2002).

38

Para De Terssac e Maggi (2004), o trabalho cada vez menos considerado como

uma realidade j constituda, diante da qual o indivduo deve se submeter. O

trabalho torna-se uma ao coletiva por meio da qual os indivduos vo cooperar

para obter certo resultado, dentro de condies dadas. Esta ao se desenrola

tendo alguns constrangimentos, em razo do contexto estruturado pelos

dispositivos, regras e normas que iro definir o espao de ao e que podero ser

ou no questionados pelos indivduos.

A ergonomia passou a pesquisar e empregar noes ligadas ao trabalho coletivo,

como: cooperao, colaborao, coordenao e outras, fundamentais para essa

forma de trabalho. possvel encontrar na literatura diferentes definies e

abordagens para estas noes e, desta forma, considerou-se importante apresentar

algumas definies utilizadas nesta pesquisa.

Conforme citado no item I.1, a definio de cooperao utilizada neste trabalho

dada por Dejours (2005, p. 93):

Cooperao uma conduta coordenada, definida como a ao de participar

de uma obra comum. A cooperao supe um lugar onde, ao mesmo

tempo, convergem as contribuies singulares e cristalizam-se as relaes

de dependncia entre os sujeitos.

O autor salienta que a cooperao remete ao coletivo de trabalho e uma conduta

coordenada que possibilita desempenhos superiores e suplementares em relao

aos desempenhos individuais.

A cooperao no idealiza o operador humano, pois faz a integrao das diferenas

entre as pessoas, articulando os talentos especficos de cada trabalhador e

compensando as possveis falhas singulares. Segundo o autor, a qualidade do

trabalho, a confiabilidade e a segurana esto diretamente ligadas qualidade da

cooperao, podendo compensar as falhas da organizao do trabalho prescrito e

as restries dos desempenhos humanos.

O termo cooperao, quando se trata da questo do trabalho, pode ser definido de

uma forma mais ampla no sentido que duas ou mais pessoas cooperam quando se

empenham em uma tarefa conjunta em direo a um determinado objetivo. Para que

este objetivo seja alcanado, so necessrias aes de ambos (cada um dos

parceiros executa as aes), de modo que cooperar operar em comum, buscando

39

o ajuste por meio de novas operaes de correspondncia, reciprocidade ou

complementaridade (PIAGET, 1996).

Segundo Tavares (2002), a cooperao exige que os participantes estejam de

acordo com respeito a um conjunto de regras que deve ser observado no decorrer

da atividade. Acordo e regras no precisam ser o resultado de uma comunicao

formal nem mesmo de inteno explcita. Podem se desenvolver no decorrer da

prpria interao, por tradio, por experincia anterior com sucesso, tentativa e erro

ou processos evolutivos relacionais. A cooperao exige, portanto, que os agentes:

Identifiquem um objetivo comum;

Estejam engajados em aes para realizar esse objetivo comum;

Sejam aptos para reconhecer que os outros agentes esto engajados no

mesmo objetivo;

Enfim, que sejam aptos para evitar os conflitos ou para resolv-los.

O indivduo integrado a um SI no qual a distribuio de competncias, de tarefas, de

papis, necessita de processos integrantes (coordenao, comunicao,

organizao/cooperao). A dualidade entre o todo e as partes, entre unificao e

distribuio, entre homogeneidade e heterogeneidade raramente levada em conta

nos mtodos de anlise e concepo de sistemas informatizados (ERCEAU et al,

1994). Esta questo ser mais bem detalhada no item II.5, onde os processos

integrantes sero associados ao trabalho cooperativo de um grupo, focado por meio

de um software que o implementa.

II.1.2 Dimenses do trabalho coletivo

Para Gurin et al. (2001), existe uma srie de termos utilizados para descrever as

dimenses do trabalho coletivo:

Coordenao: neste caso pressupe que os operadores devem levar em

conta mutuamente o ordenamento de suas aes e respectivas decises,

tendo ou no objetivos imediatos diferentes;

Coao: corresponde a um caso de coordenao no qual os operadores

realizam aes paralelas, e que em dado momento devem convergir;

40

Cooperao: realizao conjunta de uma mesma tarefa, em um mesmo objeto

de trabalho, em uma relao de dependncia mtua. Nesta situao, as

diferentes pessoas envolvidas na ao obtm informao sobre o andamento

da ao das outras, de maneira a poder ajustar a maneira como trabalham

em tempo real;

Colaborao: o caso dos trabalhadores que, normalmente, no trabalham

no mesmo objeto, mas compartilham suas competncias para lidar com uma

situao particular, ou mesmo famlias de situaes.

A coordenao aparece ainda como um fato caracterstico das formas

organizacionais e constitui uma condio para a cooperao, em que a cooperao

aparece como um processo que vai alm da coordenao, englobando-a. Outro

elemento chave para a compreenso da cooperao corresponde noo de

objetivo, em que um grupo corresponde a uma reunio de agentes que

compartilham um mesmo objetivo (TAVARES, 2002).

Ainda segundo Gurin et al. (2001), necessrio que cada um dos participantes do

grupo tenha uma representao suficiente do trabalho que os outros efetuam, sendo

que duas condies so importantes:

Conhecer a organizao geral do seu trabalho e de seus colegas,

considerando suas diversas fases, assim como suas limitaes;

Ter informaes que possibilitem avaliar em um determinado momento como

o desdobramento de suas aes afetam os demais.

Outro aspecto inerente atividade coletiva diz respeito comunicao entre os

elementos do grupo, em q ue cada um dos participantes est comprometido com

uma ao, interpretando as informaes que lhe chegam baseadas em sua

focalizao naquele momento, tendo como apoio o conhecimento das aes dos

demais participantes do grupo. Considera-se que ocorre comunicao sempre que

h transmisso de informao entre uma pessoa e outra.

A comunicao pode ser explcita (palavras trocadas entre os elementos do grupo,

gestos, etc.) ou implcitas (por uma atividade especificamente realizada, ou por meio

de um som produzido por um determinado elemento do grupo, etc.).

41

A ergonomia direcionou suas anlises e no considera somente a ao individual e

a relao tarefa-atividade de um s operador, mas a ao coletiva e as relaes

entre tarefas, atividades e diversos operadores (MAGGI, 2005).

Assim, a efetiva organizao do trabalho, alm de exigir a coordenao de

experincias singulares e, sobretudo de cooperao, implica a vontade das pessoas

trabalhar em conjunto, de modo que a mesma no pode ser prescrita, exigindo uma

relao de confiana das pessoas na construo de normas e regras que

determinem a forma de executar o trabalho (DANIELLOU; SIX, 2003).

II.1.3 Consideraes sobre a dimenso coletiva do trabalho

Esta seo mostra a importncia de se considerar o trabalho coletivo e, mais

particularmente, o trabalho cooperativo, tanto nos sistemas de informao como nos

softwares desenvolvidos para dar suporte a este ambiente. So descritos os

conceitos a respeito da dimenso coletiva do trabalho e a contextualizao do

trabalho cooperativo.

Os conceitos aqui descritos sobre cooperao sero utilizados ao longo da

pesquisa, sendo refinados e adaptados na medida que mtodos e tcnicas relativas

ao trabalho cooperativo e ao levantamento dos requisitos de software neste

ambiente forem introduzidos durante seu andamento.

II.2 ANLISE COLETIVA DO TRABALHO

Nesta seo, foca-se o mtodo da Anlise Coletiva do Trabalho, no qual os

trabalhadores, em grupo, explicam s pessoas externas as relaes de trabalho de

suas prprias atividades.

Suas principais caractersticas so apresentadas, assim como as tcnicas utilizadas

em sua construo.

42

II.2.1 Introduo/conceituao

A Anlise Coletiva do Trabalho (ACT) um mtodo de anlise na qual trabalhadores

(usurios, no caso da informtica), em grupo, descrevem sua prpria atividade em

situao de trabalho para outros trabalhadores e a pessoas externas a relao de

trabalho (stakeholders, tambm, no caso da informtica). a fala dos trabalhadores

e a escuta dos pesquisadores que se encontram no centro do processo.

Mas existem etapas preliminares para a aplicao do mtodo. Primeiro, necessria

uma demanda, um problema concreto a ser enfrentado; nesta ocasio, feita uma

anlise das possibilidades de atend-la ou no por meio da ACT. A demanda

representa, assim, um compromisso na obteno de resultados por parte dos

trabalhadores (FERREIRA, 1993).

A ACT apoia-se nas seguintes premissas:

Trabalha-se com grupos de indivduos e no com indivduos isolados. No

decorrer do processo, os trabalhadores vo tomando conscincia das aes,

de toda percia necessria para realizar o trabalho e de toda dificuldade. Esta

conscincia adquire maior valor ainda, porque os outros colegas vo se

identificando com quem est falando e manifestando esta identificao, ou

ento, discordando, descobrindo-se, desse modo, os pontos comuns, no

permitindo tambm que se derive para problemas de ordem pessoal e

individual;

O objetivo dos trabalhadores explicar aos pesquisadores o que fazem no

trabalho. A pergunta condutora : o que voc faz uma questo positiva (ao

contrrio das questes sobre doenas, que esto na maioria das abordagens

em Medicina e Psicologia do Trabalho, que so negativas) e est sempre

sendo reapresentada pelos pesquisadores. Todos os participantes podem

fazer perguntas e ajudar a respond-las: o que voc precisa para fazer esta

pea? Quem que lhe passa o trabalho? O que acontece quando voc erra?

Como se faz determinada operao? Como reage seu colega de trabalho em

tal situao? etc.;

H, pelo menos, dois pesquisadores conduzindo a reunio. Durante todo o

decorrer da reunio, os pesquisadores esto sendo testados para verificar se

43

merecem a confiana dos trabalhadores, quer em termos de compreenso do

que est sendo dito (os trabalhadores tm o cuidado de converter seus

termos operacionais para uma linguagem compreensvel pelos

pesquisadores), quer pelo respeito de que no se pode ou no se quer dizer

claramente. fundamental que o resultado da anlise, em forma de relatrio,

antes de ser divulgado, seja avalizado pelos participantes;

Todos os participantes so voluntrios e conhecem a atividade que est

sendo analisada;

As reunies so feitas fora do local de trabalho;

O anonimato dos trabalhadores deve ser assegurado.

Este mtodo diferencia-se do Grupo Focal que, de acordo com Morgan (1997),

uma tcnica de pesquisa que coleta dados por meio das interaes grupais ao se

discutir um tpico especial sugerido pelo pesquisador, possuindo um carter mais

exploratrio e menos diretivo que a ACT, cujo fio condutor a atividade dos

trabalhadores descrita pelos prprios trabalhadores.

II.2.2 As tcnicas da ACT

Conforme cita Ferreira (1993), as tcnicas podem variar bastante, podendo haver

uma ou vrias reunies sucessivas, com durao de 90 minutos cada, que pode ser

gravada (desde que em comum acordo).

A estas reunies, existem etapas preliminares. Assim, preciso haver uma

solicitao externa, um problema a ser resolvido ou esclarecido, uma anlise da

solicitao. Neste ponto, ser possvel avaliar se esta demanda pode ser atendida

com a ACT e tambm se esclarecer como funciona o processo de reunies.

Outro aspecto para a aplicao da ACT que todos os participantes sejam

voluntrios, dando-lhes garantias de anonimato. Estas podem ajudar a criar um

clima de confiana que necessrio ao andamento correto do processo.

Uma regra fundamental que todos participantes entendam a atividade que est

sendo analisada. Os participantes podem fazer perguntas e ajudar a respond-las. O

44

dilogo que se estabelece, permite que a atividade v sendo descrita, explicada e

interpretada.

Para determinados grupos, aps uma apresentao geral e breve de cada um,

escolhe-se um pessoa que ir explicar mais detalhadamente a atividade. Em outros,

cada trabalhador poder falar mais detalhadamente. Dois pontos importantes so

reforados:

Deve ser dada uma explicao inicial sobre o objetivo do trabalho, por parte

dos pesquisadores. Novos assuntos podero ser desenvolvidos com o grupo,

mas devem ser motivo de novas negociaes;

Os pesquisadores devem entender detalhes sobre a atividade e procurar

faz-los de vrias formas, mesmo que demorem bastante tempo. No se

pode fingir que entendeu. Deve-se entender mesmo. Uma boa tcnica

corresponde a se descrever a atividade cronologicamente.

O trabalho termina com um relatrio escrito pelos pesquisadores que deve, antes de

sua divulgao, ser apresentado ao conhecimento dos participantes, para que possa

detectar erros de interpretao e precisem pontos que no ficaram esclarecidos

durante as reunies.

II.2.3 Caractersticas da ACT e resultados

Para a proposta de trabalho em questo, alguns resultados e caractersticas gerais

sobre ACT devem ser destacados:

Inverte-se o processo de saber. So os trabalhadores que sabem, os

pesquisadores no sabem. Todos tm algo prprio e nico para contar: sua

atividade real. Segundo a autora, esta inverso valoriza o trabalhador e cria

um clima altamente positivo;

Para se explicar o que se faz, deve-se antes refletir sobre o que se faz, o que

no um processo usual, fazendo com que se torne explcito e consciente

tudo o que se fazia de modo automtico: Para o sujeito falante, exprimir

tomar conscincia: no exprime somente para os outros, exprime para que

ele prprio saiba o que visa". Normalmente, no se pensa na atividade que se

45

faz, mas em seus resultados, a atividade em si que importante e ela

quem precisa ser explicada;

O processo facilita descobrir os pontos comuns na atividade dos

trabalhadores;

Permite analisar o trabalho sob diversas situaes: o do contedo do trabalho,

das exigncias da produo, das relaes com os colegas e chefias, do

ambiente de trabalho, etc.;

A ACT cria condies para reproduzir, fora do local de trabalho, uma espcie

de rplica condensada do que acontece dentro do local de trabalho;

O sujeito e a atividade esto absolutamente entrelaados, e como se o

pensamento sobre a atividade no se distinguisse do pensamento do prprio

sujeito. A ACT transforma a atividade em um tema de reflexo e cria

condies para que se pense sobre ela, como se fosse um objeto externo.

O resultado da ACT no possui s objetividade, mas tambm subjetividade

(os trabalhadores valoram o que descrevem: o que bom, ruim, do que

gostam, ou ento, o que perigoso);

O material resultante da ACT pode ser utilizado de diversas formas por vrias

reas de especializao.

Assim, de acordo com o exposto, tem-se uma ideia clara dos aspectos invisveis, ou

subjacentes a uma atividade, como a atividade cognitiva. Aparecem explicados em

detalhes, quais tipos de clculos so necessrios realizar, o que preciso saber de

cor, o que fica guardado na memria, que tipo de raciocnio feito quando ocorre

um incidente, que tipo de indicadores so utilizados para avaliar a qualidade de um

produto, o estado de funcionamento de um equipamento, etc.

comum os trabalhadores surpreenderem-se com o que fazem, como se o

processo os levasse a refletir sobre algo que at ento permanecesse inconsciente,

pois acontece um processo em que uma percepo intuitiva vai se transformando

em uma percepo mais reflexiva (FERREIRA, 1998).

Este mtodo usa a memria do trabalhador. Embora fale de sua atividade no

presente, como se a estivesse realizando enquanto a descreve, pode referir-se a

vrios acontecimentos do passado e compor uma histria que d sentido sua

46

atividade. Em geral, fala-se das diferenas de uma atividade e como ela acontece,

por exemplo, quando todos esto presentes ou quando uma colega falta, em perodo

de pico ou baixa produo, quando se novato ou experiente. Obtm-se uma

explicao do desenvolvimento temporal de determinada atividade, conhecendo-se

um pouco de sua histria.

Ocorre, tambm, uma condensao de informaes, em que em poucas horas

consegue-se uma quantidade de informaes dificilmente obtida por outros mtodos.

A autora compara a um filme j editado, em que s as cenas mais significativas

aparecem. Em algumas situaes, a informao est condensada: um processo que

na vida real dura anos, descrito em uma frase curta. Outras vezes, um gesto de

trabalho que dura apenas alguns segundos, pode demorar vrios minutos para ser

explicado, ocorrendo uma espcie de dilatao do tempo.

Com este mtodo, trabalha-se com grupos e no individualmente, e esta

caracterstica implica de vrias maneiras sobre seus resultados. O coletivo funciona

como um elemento que introduz uma nova dimenso compreenso das vivncias

de cada um. Em primeiro lugar, encorajando os trabalhadores a expressar-se. Como

eles so sempre maioria com relao aos pesquisadores, o fato diminui o problema

inicial da situao proposta, na qual o saber dos trabalhadores que predomina

sobre os pesquisadores.

Outra caracterstica que a presena de vrias pessoas falando de seu trabalho

facilita a comparao, e fica mais claro o que comum na atividade de cada um e o

que diferente. Consequentemente, os aspectos coletivos do trabalho so mais

bem abordados. Para explicar o que cada um faz, em geral, necessrio explicar o

que os outros fazem antes ou depois dele no processo produtivo, acima, ao lado ou

abaixo na escala hierrquica. Em geral, a fala dos trabalhadores marcada entre o

ns e eles, no qual ns so todos os que tm a mesma atividade. Eles so os

outros, aqueles que controlam o trabalho, os que no conhecem aquele trabalho.

Como resultado, as informaes obtidas na ACT permitem dois tipos de abordagens:

primeiramente, uma caracterizao geral da atividade de trabalho, na qual os

principais pontos se destacam e, em um segundo momento, na caracterizao bem

pormenorizada de determinados aspectos da atividade que normalmente passam

despercebidas por observadores externos, como por exemplo, a percia necessria

47

para se realizar uma determinada operao, os macetes empregados, etc.

(FERREIRA, 1999).

II.2.4 Consideraes sobre a aplicao do mtodo da Anlise Coletiva do

Trabalho

O mtodo da Anlise Coletiva do Trabalho tem como vantagem permitir explorar a

dinmica que est subentendida nos vnculos de cooperao entre os sujeitos, visto

que os trabalhadores (usurios, no caso de informtica) descrevem sua prpria

atividade em situao de trabalho para outros trabalhadores e para pessoas

externas relao de trabalho (stakeholders, tambm, no caso de informtica).

Em funo das caractersticas listadas no item II.2.3, este mtodo aplicado tanto

no ciclo 2 como no ciclo 3 da pesquisa-ao proposta, visando, inicialmente, a

simular o comportamento do futuro software no ambiente em que o mesmo ser

inserido e, posteriormente, com uma verso deste software em uso, refinar suas

caractersticas e seu uso (os detalhes de como a ACT ser aplicada nos ciclos 2 e 3

sero apresentados ao longo desta pesquisa).

importante ressaltar que embora originalmente o mtodo da Anlise Coletiva do

Trabalho tenha sido aplicado em reunies fora do ambiente de trabalho, com todos

os participantes voluntrios e com seu anonimato mantido, no contexto sob estudo,

estes cuidados metodolgicos tambm foram observados, com as reunies

realizadas em um ambiente fora do local de trabalho, mas dentro da empresa, assim

como o anonimato relativo a certas colocaes dos usurios nas reunies de ACT

tambm foram observados, quando se fez necessrio.

Por ltimo, a questo do termo demanda utilizada inicialmente no mtodo de ACT,

que representa uma solicitao externa (sendo na maioria das vezes oriunda dos

sindicatos dos trabalhadores ou dos prprios trabalhadores). Nesta pesquisa, foi

realizada por uma solicitao da alta direo da empresa PesqTec, correspondendo,

portanto, a uma demanda gerencial (ver item V.1.1).

Ao longo da aplicao das vrias sesses de ACT nos ciclos da pesquisa-ao, esta

demanda subdividida em um conjunto de regras de negcio que so abordadas

48

com o grupo nas respectivas reunies de ACT, sendo as mesmas previamente

acordadas com os participantes da reunio (ver itens VI.2 e VII.2).

II.3 MODELO MENTAL E INTERAO

Na interao com o mundo, as pessoas formam modelos de si e dos objetos que

interagem. Estes modelos so utilizados como suporte para a interao com o

sistema informatizado, tanto para aprendizado de seu uso como projeto, assim como

elementos de representao comum, constituindo-se em importante ferramenta

dentro do processo proposto.

II.3.1 Modelo mental e interao

As pessoas formam modelos mentais internos de si mesmas, dos objetos e

daspessoas com as quais interagem. Estes modelos fornecem meios para a

compreenso das interaes, sendo afetados fortemente, tanto pela natureza das

interaes como pelas experincias e conhecimentos anteriores. A despeito de no

serem completos e precisos, so modelos teis para orientar grande parte do

comportamento humano (NORMAN, 1986).

Assim, o conceito de modelo mental utilizado para definir uma representao

mental de um sistema fsico ou software, com um conjunto de associaes que

conectam estmulos aos resultados. uma estrutura elaborada e rica que reflete o

entendimento do projetista/usurio sobre as funes e comportamento do sistema,

permitindo decidir por antecipao as aes que devem ser executadas, sendo teis

para o aprendizado, soluo de problemas e para racionalizaes sobre o

comportamento do sistema (CARROL; OLSON ,1988).

Segundo Norman (2002), para o projeto de um sistema deve-se, primeiro, fazer com

que este siga uma conceituao consistente e coerente o modelo de projeto e

depois prover meios de modo que o usurio desenvolva um modelo mental deste

sistema o modelo mental do usurio consistente com o modelo de projeto.

A proposta de Norman (1986) e Norman (2002) prev trs modelos mentais: de

projeto, do usurio e imagem do sistema (Figura II.1):

49

De projeto (ou conceitual): a conceituao que o projetista tem em mente e

criado baseado nos requisitos dos usurios, suas capacidades,

conhecimentos e experincias, sendo til para projetar o sistema e ensinar a

us-lo. Esta conceituao deve considerar tambm a experincia dos

usurios, suas experincias e as facilidades e limitaes de seus mecanismos

de processamento de informaes (por exemplo, limites de memria de curta

durao);

Do usurio: so modelos que as pessoas tm de si prprias, dos outros, do

ambiente e das coisas com as quais interagem, sendo definido como o

resultado das aes dos usurios, baseadas em sua experincia e

decorrentes de outras aes em outros sistemas e tarefas. o modelo que o

usurio interioriza para explicar a operao do sistema e formado sobretudo

por meio da interpretao que feita das aes percebidas da parte visvel do

dispositivo ou do software;

O fsico ou imagem do sistema a estrutura concreta que foi construda

(inclusive a documentao, instrues, rtulos, etc.) e que nem sempre

guarda relao com o modelo mental, sendo de importncia crtica, pois o

projetista deve assegurar que tudo pertinente ao produto seja consistente

com a operao do modelo de projeto apropriado.

Imagem do sistema

(modelo fsico)

Modelo do usurioModelo de projeto

Projetista Usurio

Documentao

Sistema

Projeto e

aprendizado

Projeto

Figura II.1 - Modelos mentais

Fonte: adaptado de Norman (1986); Carrol e Olson (1988)

50

Deste modo, o modelo conceitual um meio para criar o mental e deve permitir ao

usurio interpretar o que est acontecendo por meio da interface e documentao

do sistema.

De acordo com Norman (1986), a maior facilidade da aprendizagem e da utilizao

dependem de um correto mapeamento entre o modelo mental e o conceitual. O

modelo mental no se forma com base no modelo do projeto, e o mesmo resulta do

modo como o usurio interpreta a imagem de sistema.

Assim, a tarefa do projetista construir uma imagem adequada do sistema,

compreendendo que todos os elementos com que o usurio interage ajudam a

formar esta imagem, como por exemplo: botes fsicos, teclados, monitores de

vdeo, documentao (manuais de instruo, helps, etc.), mensagens de erro,

entrada e sada de dados, facilidades de ajuda e os elementos da interface homem-

mquina.

Com base nestes conceitos, Carrol e Olson (1988) sugerem trs abordagens de

projeto:

Modelo conceitual preconcebido. a determinao do modelo conceitual aos

usurios pelos projetistas de modo a se iniciar o projeto com um modelo

preconcebido inicial e por meio de prototipao interativa buscar o modelo do

usurio, dentro de um nvel adequado de usabilidade;

Comunicao de um modelo ao usurio. Corresponde criao de cenrios

baseados nas principais tarefas dos usurios, de modo que, passo a passo, o

retorno do usurio sirva como elemento para refinar o projeto e construir

outras interaes. A dificuldade reside em no interromper o fluxo do

aprendizado e preservar o que j foi aprendido pelo usurio;

Foco na tarefa. O conhecimento deve ser representado formal e

posteriormente estudado, de modo a se transformar esta descrio na

interface. Esta abordagem no suficiente para descrever a interface

(imagem do sistema), pois uma mesma descrio de comando pode ter

representaes visuais diferentes.

Com relao ao aprendizado, o emprego de modelos conceituais durante o

treinamento oferece resultados melhores do que se fossem utilizadas apenas

instrues sobre procedimentos. Estes autores afirmam que aparentemente o

51

modelo organiza o conhecimento para evitar confuso e facilitar o entendimento do

sistema, e diversos estudos mostram que mais fcil incorporar do que induzir um

modelo.

Na aplicao do conceito de modelo mental a um grupo de usurios, uma das

principais metas corresponde em obter os objetivos que so comuns, conforme

discutido em II.1.2.

Dentro do contexto de uma dinmica coletiva que exige aes de cooperao, o

grau e a natureza da interao de um agente e seus engajamentos dependem

necessariamente de seus objetivos individuais, de suas interaes, de suas crenas

e dos modelos que tm de si mesmo, dos outros e de seu ambiente (ERCEAU et al.,

1994).

Para estes autores, o comportamento de um grupo no a soma dos

comportamentos individuais dos agentes do grupo, e a obteno de um estado

mental coletivo se d por meio de um engajamento partilhado entre os agentes, de

modo que grupo possa agir como um agente nico, descrito por um conjunto de

crenas, objetivos e intenes.

Wittorski (1997), tambm, cita a importncia de se criar as imagens operativas

comuns (definidas como a representao mental que uma pessoa tem de sua

tarefa), cdigos e linguagens comuns em sistema de trabalho cooperativo.

II.3.2 A ergonomia das interfaces

Conforme visto no item II.3.1, a imagem mental do usurio montada pela imagem

do sistema, e o principal elemento desta imagem corresponde interface com o

usurio. por meio da interface que a usabilidade percebida pelo usurio, que a

satisfao subjetiva ser alcanada. Para os usurios, a interface, praticamente,

constitui o sistema.

A interface o resultado da interao homem-computador e constituda de dois

elementos (HIX e HARTSON, 1993):

O desenvolvimento da interao. Neste momento, desenvolvida a

comunicao com o usurio em termos das aes do operador e do

funcionamento da interface, considerando-se os princpios da ergonomia,

52

orientaes, limitaes cognitivas dos usurios, projeto grfico, estilos de

interao e especificaes de usabilidade. O objetivo assegurar usabilidade,

funcionalidade, desempenho e satisfao do usurio;

O desenvolvimento do software que prov esta interao. Neste momento,

ser implementada a interao por meio de algoritmos, linguagens de

programao, estruturas de dados, e outras tcnicas da tecnologia da

informao. importante ressaltar que a maior parte dos esforos de

programao est no desenvolvimento desta interao, na qual este nmero

pode chegar at a 80% desse esforo (SILVA, 1997);

No desenvolvimento da componente interao da interface, pode-se utilizar uma

srie de estilos, sendo definidos como uma coleo de objetos e tcnicas que esto

disponveis aos projetistas da interface para o desenvolvimento da interao,

incluindo, a aparncia e o comportamento dos objetos da interao, vistos pelo

usurio.

Scapin (1986) descreveu um conjunto de critrios para analisar/projetar a relao

homem-sistema, consistentes com os estilos de interao (ver Apndice B). Este

modelo pode ser considerado como um guia aos projetistas para orientar a

construo de formas mais naturais e intuitivas de interao homem-computador,

por meio da melhor adequao s necessidades dos usurios, melhorias da eficcia

de utilizao e do aprendizado.

II.3.3 Consideraes sobre modelo mental e interao e ergonomia das

interfaces

Esta seo mostra que o modelo mental do usurio forma-se com base na imagem

do sistema, de modo que, para se desenvolver um software que atenda s

necessidades dos usurios, os projetistas devem construir uma imagem adequada

do sistema para o usurio, baseado no modo como os projetistas entendem o

sistema (modelo de projeto).

Nesta pesquisa, para se construir um software mais prximo possvel do modelo

mental do usurio foi utilizado o conceito de prototipao evolutiva (ver itens II.6.3 e

II.8.3), no qual desenvolvido um modelo inicial do sistema e por meio da

53

prototipao busca-se o modelo mental do usurio. Neste caso, ao contrrio da

aplicao de prototipao em desenvolvimento de software tradicional, o

desenvolvimento do prottipo, seja no funcional ou funcional (item II.8.3),

realizado durante a aplicao das sesses de ACT, para focar, tanto os requisitos

individuais como os requisitos do trabalho cooperativo (representao, item II.4.1).

Na medida que as sesses de ACT vo evoluindo, o modelo mental tambm evolui

por meio da evoluo da imagem do sistema, cujos conceitos da ergonomia das

interfaces e usabilidade so aplicados.

No ciclo 1, a imagem do sistema foi simulada pela prototipao em papel, cujas

aes e respostas com os usurios (interaes) eram apresentadas por meio de

uma primeira aproximao das interfaces desenhadas em folhas de papel.

No ciclo 2, a imagem do sistema (implementao fsica do software) foi realizada

(ver itens III.4.4 e IV.4.1), de modo a simular as respostas s aes (cliques em

botes, escolha de opes, etc.) dos usurios por intermdio de interfaces grficas

pr-programadas, isto , sem o cdigo (software) que implementa a interao,

considerando, tanto os requisitos individuais como parte dos requisitos do trabalho

cooperativo.

Finalmente, no ciclo 3, utilizando como base os resultados das interaes do ciclo 2,

a imagem do sistema (software) implementada totalmente, com as respostas

dinmicas s solicitaes dos usurios via interface grfica (neste caso, ocorre uma

transao, isto , a troca de dados dinmica com o banco de dados do software),

considerando, tambm, os requisitos associados contextualizao das atividades

individuais pela compreenso das atividades realizadas por outras pessoas.

II.4 TEORIA DA MENTE COLETIVA

A teoria proposta por Weick e Roberts (1993) ajuda o entendimento de como tratar

sistemas de informao que no esto sob um centro de organizao simples, ou

seja, sem uma distino clara entre comunicao e coordenao (ver modelo 3C

item II.5.2) mas sim distribudos no padro de comportamento (aes) dos usurios

(coordenao horizontal) (CROWSTON; KAMMERER,1998).

54

A principal proposta desta teoria corresponde ao fato que o desempenho global do

grupo facilitado quando os indivduos desenvolvem uma compreenso

compartilhada das atividades do grupo e de si mesmos.

A teoria da mente coletiva descrita como disposio para ouvir e cooperar na

medida que so estas aes que constroem o inter-relacionamento do grupo. Se

cada membro de um grupo tem o desejo e meios para agir de modo a promover os

objetivos e necessidades do grupo conscientemente, ento, o grupo exibe um

comportamento que pode ser descrito como coletivamente inteligente, mesmo sendo

os indivduos de fato inteligentes, no o grupo.

Vrias aes individuais e processos sociais de base so os pontos mais

importantes desta teoria para a construo e manuteno desta disposio

consciente e das capacidades que sero discutidas nos prximos itens.

II.4.1 Aes ligadas teoria da mente coletiva em desenvolvimento dos

sistemas informatizados

Existe um grupo de aes que s possvel, quando cada participante tem uma

representao que inclui as aes dos outros e suas relaes. As respectivas aes

convergem de modo relevante, dando suporte e suplementando umas s outras,

somente quando a situao conjunta representada em cada um e quando as

representaes so estruturalmente similares. S quando estas condies ocorrem,

os indivduos podem subordinar a si mesmos as necessidades da ao conjunta.

Estas representaes e aes reforam a existncia do grupo.

Segundo Weick e Roberts (1993), existem trs aes individuais que representam

as atividades do grupo, nas quais os atores em um sistema constroem suas aes

contribuindo para os resultados do grupo (contribuio), compreendendo que o

sistema consiste em aes conectadas por eles mesmos e por outros, de modo que

um indivduo construa modelos internos do grupo (representao) e do inter-

relacionamento de suas aes com o sistema, colocando os objetivos do grupo

acima de seus objetivos pessoais (subordinao).

Quando estas condies ocorrem, h um sistema social de forma definida que

comporta as aes dos indivduos. Tal sistema no reside nos indivduos tomados

55

em separado, a despeito do fato de que cada indivduo contribua para o mesmo nem

resida fora deles. Ele est presente nas inter-relaes entre as atividades dos

indivduos e focando no modo como este inter-relacionamento feito, revela o

processo mental coletivo que difere em graus de desenvolvimento.

Estas aes ocorrem em qualquer grupo. A questo para a teoria da mente coletiva

quo conscientemente estas aes so realizadas: cuidadosa, crtica, consistente,

decidida, atenta e deliberadamente, de modo alerta, com conscincia e

persistncia? Quanto mais extensas forem, o grupo mostrar maior capacidade

para exprimir a mente coletiva.

Uma maneira de se avaliar o desenvolvimento da mente coletiva corresponde ao

uso de uma tabela na qual as linhas so as pessoas, e as colunas so ou as aes

de contribuio, representao e subordinao, ou seus componentes de

comportamento (por exemplo: convergindo com, ajudando ou suplementando).

Inicialmente, as entradas das clulas podem ser simples (sim ou no). Sim, significa

que a pessoa executa a ao de modo consciente; no, que a ao feita de modo

menos consciente. Quanto mais sim na tabela mais a mente coletiva ser

desenvolvida.

A despeito de serem conceituadas separadamente, estas trs aes se sobrepem

e reforam umas as outras em algum grau. difcil imaginar contribuies

conscientes (heedful), vindas de indivduos motivados e talentosos com uma fraca

representao da estrutura e necessidades do grupo. De modo similar, um indivduo

no pode construir uma representao do grupo sem as contribuies dos demais,

nem pode se subordinar de modo conscientemente (heedfully), sem uma

representao precisa dos objetivos do grupo.

Um aumento na capacidade de inter-relacionamento consciente pode prevenir ou

corrigir falhas de compreenso em, pelo menos, trs modos:

Alongamentos de perodos de tempo podem ser conectados, na medida que

mais conhecimento trazido por meio do passado e elaborado dentro de

novas contribuies e representaes que remetem a um futuro mais

distante;

56

A compreenso pode ser melhorada se mais atividades forem conectadas,

tais como quando as inter-relaes alternam estgios mais adiantados e

atrasados da sequncia de tarefas;

A compreenso pode ser aumentada se mais nveis de experincia forem

conectados, como o caso dos usurios iniciantes que se inter-relacionam com

os mais velhos.

Quanto mais consciente for este processo espalhado por um nmero maior de

atividades e conexes, ocorrero menos erros. Abaixo esto descritas com mais

detalhes as trs aes ligadas mente coletiva:

Contribuio

Corresponde parcela de contribuio individual para o trabalho em grupo. Os

indivduos contribuem quando executam uma tarefa, como por exemplo: entrada de

algum tipo de dado no sistema (desde dados alfanumricos at o acionamento de

eventos), emisso de relatrios ou participar de um processo social que constri a

mente coletiva (item II.4.2).

Estas contribuies podem ser feitas de modo mais ou menos consciente, isto , de

modo a se aproximar das perspectivas do grupo conscientemente, tomando-se

decises de modo inteligente, coordenando suas contribuies com os demais

elementos do grupo e assim por diante.

importante que os elementos do grupo trabalhem para desenvolver uma

compreenso recproca de quem est fazendo o que e como as contribuies se

encaixam juntas, assim como deve haver uma nfase organizacional no

compartilhamento da informao entre os membros da equipe e por intermdio da

organizao por meio de pequenos e grandes encontros.

Os membros do grupo devem com frequncia reservar tempo com as outras partes

interessadas para explicar o que fazem e como fazem. Esta atividade libera os

indivduos para mais eficientemente direcionar seus esforos em seu trabalho

conjunto.

57

Representao

Representao o conjunto de contribuies do grupo para o sistema que

percebida em vrios graus por indivduo. Na medida que os indivduos fazem e

dizem coisas (exercem suas atividades), estas aes so interpretadas e

sintetizadas pelos demais que usam estas informaes para construrem seus

prprios modelos internos do grupo (modelo mental do grupo).

Por meio deste modelo, possvel que cada elemento do grupo entenda como se

encaixa no mesmo, como os demais iro proceder e como suas prprias aes

devero afetar os demais. Este modelo incorpora as ideias de cada elemento do

grupo a respeito de suas metas e como podem ser acompanhadas.

O ponto importante que os indivduos precisam desenvolver modelos sobre o que

os demais fazem e uma compreenso compartilhada do problema nos quais esto

trabalhando.

Por exemplo, importante determinar quais so as atividades de cada indivduo do

grupo e como execut-las, quem so os responsveis pelas demais atividades (dos

demais processos), como as mesmas se sobrepem, quem pode ser afetado por

erros em suas respectivas atividades, se h sobreposio de trabalho no

intencional, viso geral do processo, etc.

Subordinao

Subordinao envolve a confiana que um elemento do grupo possui sobre o

sistema. A subordinao individual ocorre quando se confia nos demais elementos

do grupo para suprir as informaes necessrias ao andamento de seu trabalho,

quando h obedincia aos superiores e quando as decises so tomadas baseadas

nos interesses do sistema, acima das necessidades individuais.

A representao que os indivduos tm do sistema ao qual se subordinam pode ser

mais ou menos precisa e os indivduos podem ou no escolher seus prprios

interesses sobre os do sistema. Para que a questo de subordinao seja

estabelecida, preciso que o modelo coletivo do processo esteja formado de modo

que fique clara a posio do indivduo dentro do mesmo e como sua contribuio

individual repercute no resultado final do trabalho.

58

Caso contrrio, a despeito dos indivduos realizarem seus servios da melhor forma

que acreditam contribuir, o fato de no conhecerem os objetivos gerais pode implicar

um resultado final no esperado.

II.4.2 Processos sociais no desenvolvimento da mente coletiva

Para Weick e Roberts (1993) processo social significa um conjunto de interaes

que esto ocorrendo no sistema de atividade social dos quais os participantes

continuamente extraem um senso de mudana de suas prprias inter-relaes e as

recolocam em ao no sistema. O processo de interao que est em progresso no

sistema recapitulado nas vidas individuais e continua a despeito da substituio de

um ou mais indivduos.

Uma vez que a teoria da mente coletiva est baseada no inter-relacionamento das

atividades sociais e dependente do maior ou menor grau de conscincia de como

estes inter-relacionamentos so feitos, os processos sociais tornam-se importantes

para a teoria.

A relao entre indivduo e grupo somente parte-todo e depende da recapitulao

da estrutura do todo na parte. As capacidades do sistema que so relevantes para o

funcionamento do todo, so construdas nas partes. Em cada uma destas

reconstrues, os processos sociais so os recursos dos quais o pensamento

individual, o eu e a ao so modelados.

Os padres de inter-relacionamento dos processos sociais podem ser internalizados

e recapitulados pelos indivduos com maior ou menor intensidade, conforme estes

se movem para dentro ou fora do sistema. Se o relacionamento consciente for

considerado e preservado, haver uma boa chance de que os novos usurios

aprendero este estilo de trabalho, incorporaro para si as definies do que

representam no sistema e reafirmaro e talvez aumentem este estilo de agir.

Assim, os autores citados sugerem trs tipos de processos sociais para servirem de

base para a construo da mente coletiva: socializao, conversao e

recapitulao:

59

Socializao

A teoria da mente coletiva sugere ser importante prestar ateno ao processo de

socializao dos novos membros. Pessoas unindo-se a um grupo sentem a

necessidade de saber como se encaixam no processo em execuo (isto , sua

contribuio e subordinao), precisam ser encorajadas e educadas para interagir

entre si para desenvolver um forte senso sobre como podem fazer seu trabalho no

ambiente (representao). Quanto mais rico for o ambiente social mais rico poder

ser esta compreenso.

A socializao de novos participantes , especialmente importante, pois no ato de

explanar a situao aos demais, os usurios mais experientes tm oportunidade

para refletir criticamente sobre a situao e mud-la, de modo efetivo socializando a

si prprios neste processo.

Embora o processo de socializao parea natural, comum os indivduos dentro de

uma empresa descobrirem por si mesmos o que devem fazer, mais do que serem

treinados ou socializados, ou ento, indivduos que se movem em distintos grupos

na mesma funo, perceberem uma nova viso do processo e de suas

responsabilidades dentro de cada um deles.

A socializao pode ser melhorada por meio de arranjos organizacionais, tais como

tutores ou mentores, por exemplo, pelo uso de empregados especficos para o

programa de cooperadores, de modo que os novos empregados j cheguem

conhecendo a organizao.

Conversao

Weick e Roberts (1993) acentuam a importncia da conversao. difcil obter a

mente coletiva se as pessoas no conversarem entre si de algum modo. Encontros,

eventos sociais, conversas de corredor e por meios eletrnicos ou conferncias so

todos meios nos quais os membros do grupo podem entrar em contato com o que os

demais esto fazendo ou pensando.

A conversao pode ser melhorada por meio de encontros peridicos do grupo.

60

Recapitulao

Os autores citados tambm reforam a importncia da recapitulao para manter a

mente coletiva forte e vivel, eventos importantes devem ser revisados (recontados)

e reanalizados e divididos com os novos usurios. A histria que define o que so e

como so feitas as atividades em uma organizao, deve ser continuamente

reforada, reinterpretada e atualizada.

Dos trs processos, este o mais difcil de detectar. A recapitulao pode ser

promovida pelo encorajamento de sesses de detalhamento onde os indivduos

recontam suas perspectivas dos recentes eventos. Estas sesses mostram-se de

valor como meio de socializar novos membros do grupo, mesmo que diretamente

no eduquem os ouvintes em como se comportar.

II.4.3 Consideraes sobre a teoria da mente coletiva

A teoria da mente coletiva mostra como caracterstica fundamental que os indivduos

precisam desenvolver modelos sobre o que os demais fazem e uma compreenso

compartilhada do problema nos quais esto trabalhando. O fato importante, pois, a

mente coletiva est localizada no processo de inter-relacionamento das aes

individuais.

Para Weick e Roberts (1993), existem trs aes individuais que representam as

atividades do grupo: contribuio, representao e subordinao e trs tipos de

processos sociais para servirem de base para a construo da mente coletiva:

socializao, conversao e recapitulao.

Para esta pesquisa, estes conceitos so importantes, pois so aplicados aos tipos

de sistemas informatizados estudados: sistemas que no esto sob um centro de

organizao simples, ou seja, sem uma distino clara entre comunicao e

coordenao mas sim distribudos no padro de comportamento dos usurios.

A teoria da mente coletiva aplicada nos segundo e terceiro ciclos da pesquisa-

ao para orientar a aplicao da ACT, assim como este conceito utilizado para

avaliar a evoluo das sesses de ACT no terceiro ciclo da PA.

A aplicao dos conceitos de modelo mental, utilizando como ncora o prottipo do

software em desenvolvimento em sesses de ACT, tem como objetivo principal

61

desenvolver modelos mentais sobre o que os usurios fazem e uma compreenso

compartilhada do problema nos quais esto trabalhando.

II.5 CSCW, GROUPWARE, MODELO 3C E AWARENESS

Neste trabalho, os conceitos de CSCW, groupware, modelo 3C e awareness so

utilizados sobretudo para mostrar como as interaes face a face de um ambiente

de trabalho cooperativo so especificadas de modo a serem mediadas por de uma

soluo informatizada que automatiza esse ambiente.

II.5.1 CSCW e Groupware

CSCW (Computer Supported Cooperative Work) a rea de estudo que investiga

como as pessoas trabalham em conjunto, empregando a tecnologia de

computadores. Tipicamente, as aplicaes CSCW incluem correio eletrnico,

videoconferncia, sistemas de chat, interaes entre mltiplos indivduos, aplicaes

compartilhadas de tempo real, sistemas de notificao e o suporte awareness

(item II.5.3).

Groupware uma tecnologia de apoio interao entre participantes de um grupo

de trabalho e normalmente considerada como sinnimo de CSCW. Esta tecnologia

tem sido bastante difundida para modelar sistemas distribudos, empregando mdias

digitais e redes de computadores (ASSIS, 2000).

II.5.2 Modelo 3C

O modelo 3C de cooperao usado nesta pesquisa derivado do artigo de Ellis et

al. (1991) e apoia-se na concepo de que para cooperar os membros de um grupo

(C) comunicam-se, (C) coordenam-se e (C) colaboram (3Cs), conforme pode ser

visto na Figura II.2, onde observa-se a ocorrncia de um ciclo, indicando que as

pessoas devem se comunicar para coordenar seu esforos de trabalho e colaborar

em torno de um objetivo.

62

Para cooperao, h a necessidade de comunicao, seja ela direta ou por meio de

informaes obtidas dentro do ambiente onde o trabalho ocorre. Em cada

relacionamento, h o estmulo fornecido pelas informaes de awareness (item

II.5.4) que possibilitam a ocorrncia do entendimento compartilhado em torno de um

objeto de colaborao. O objeto de colaborao constitui-se das metas e objetivos

estabelecidos para concluso de uma tarefa ou de todo o trabalho (ASSIS, 2000).

Coordenao

Comunicao

ColaboraoPossibilita

PressupeFornece elementos para

Figura II.2 - Modelos de cooperao

Fonte: Ellis et al. (1991) e Fuks et al. (2007)

Apesar da separao destas atividades para fins de anlise, a comunicao, a

coordenao e a colaborao no so realizadas de maneira estanque e isolada:

so feitas continuamente e iterativamente durante o trabalho em grupo (FUKS et al.,

2005). As tarefas originam-se dos compromissos negociados durante a

comunicao, so gerenciadas pela coordenao e realizadas durante a

colaborao.

A cooperao a operao conjunta dos membros do grupo em um espao

compartilhado, que executa as tarefas ao gerar e manipular objetos de colaborao

na realizao das tarefas. Ao colaborar, preciso renegociar e tomar decises sobre

situaes inesperadas, o que requer novas rodadas de comunicao e coordenao.

Antes de efetivamente executar uma tarefa, por exemplo, o grupo organiza-se e

articula-se. Nesta atividade, tambm h necessidades especficas de cooperao

que so distintas daquelas que ocorrem durante a execuo da tarefa. Os indivduos

que planejam, podem no ser os mesmos que executam, como normalmente ocorre

na linha de montagem, cujas atividades so planejadas e, posteriormente, cada

indivduo realiza sua tarefa sem interagir diretamente com os demais.

63

Na cooperao, o plano renegociado de modo dinmico, no sendo possvel

separar plenamente a coordenao da colaborao. Enquanto os indivduos

cooperam, eles aprendem e refinam os processos de trabalho, renegociando os

planos iniciais e intercalando ao e negociao (GEROSA, 2006).

II.5.3 Awareness

Neste trabalho de pesquisa, awareness definido como a conscincia sobre a

contextualizao das atividades individuais por meio da compreenso das atividades

realizadas por outras pessoas (mesmo quando no esto se comunicando

diretamente) referindo-se a ter conhecimento das atividades do grupo, saber o que

aconteceu, o que est acontecendo e/ou o que poder vir a acontecer, alm do

prprio conhecimento do que so este trabalho e o grupo. Resumindo: awareness

significa uma compreenso do estado total do sistema, incluindo atividades

passadas, situao atual e opes futuras (BRINCK; McDANIEL, 1997; PINHEIRO

et al., 2001).

Esta conscincia (awareness) essencial para a coordenao com outros

indivduos em tarefas cooperativas em que nem sempre ocorre comunicao direta,

podendo se referir inclusive a formas indiretas de comunicao, como por exemplo,

fazer dedues ou suposies sobre o que outra pessoa est argumentando com

base nas informaes que esto sendo transmitidas ou nos gestos que esto sendo

realizados no espao que compartilham.

Neste trabalho, a palavra awareness no ser traduzida, uma vez que o termo

comumente utilizado em Engenharia de Groupware: percepo possui significados

diferentes dentro de outras reas abordadas nesta pesquisa.

A situao mostra-se complicada nos sistemas informatizados distribudos (utilizados

por vrios usurios em ambientes distintos), nos quais os recursos para esse tipo de

informaes so pobres se comparados aos recursos do cenrio face a face, cujos

mecanismos de interao so diferentes dos usuais. Como consequncia, o trabalho

em conjunto por intermdio de um software, que se baseia em tecnologia digital e

distribuda, aparentemente, pode parecer ineficiente e desgastante em comparao

64

com o trabalho face a face. Ter este tipo de conscincia um fator importante no

fluxo e na naturalidade da cooperao (ASSIS, 2000).

II.5.4 Awareness e o modelo 3C

Para possibilitar a coordenao e a cooperao como um todo, so necessrias

informaes sobre o que est acontecendo e sobre o que as outras pessoas esto

fazendo. Por meio destas informaes, os participantes podem construir um

entendimento compartilhado em torno dos objetos de cooperao e dos objetivos

das tarefas ou de todo o trabalho (DOURISH; BELLOTI, 1992).

Ao ter conscincia das atividades dos companheiros e dos impactos que ocorrem no

conhecimento gerado pela cooperao, as pessoas tero informaes que auxiliaro

na sincronizao do trabalho, coordenando-se em torno de seus contextos

individuais (FUKS, ASSIS, 2001).

Uma das possveis representaes (instncias) de como se coloca o conceito de

awareness em relao aos mecanismos de comunicao, coordenao e

cooperao pode ser vista na Figura II.3, na qual se nota que o ponto inicial que

alimenta esse diagrama o objetivo do grupo, isto , a realizao do trabalho de

forma cooperativa (FUKS et al., 2007).

Coordenao

Comunicao

ColaboraoPossibilita

Pressupe

Fornece

elementos

para

Awareness

Gera Gera

Gera

Realiza-se comObjetivo:

Trabalho

cooperativo

Feedback

Figura II.3 - Diagrama dos 3Cs e awareness

Fonte: Assis (2000)

65

Ao se observar a figura acima, percebe-se que ela apresenta diversos estmulos de

entrada e um estmulo de sada. Isso significa que vrios eventos dos participantes

de um grupo sejam voluntrios ou no, devem ter um elemento de awareness que

gere feedback (retorno) para a coordenao dos membros do grupo de trabalho.

Deste modo, pode-se definir a figura como um diagrama de coordenao, em que

cada mecanismo gera novos elementos que devem se tornar perceptveis para

aumentar o entendimento compartilhado do grupo, facilitando a cooperao.

No exemplo da Figura II.3, pode ser ressaltado que a gerao de informaes

destinadas coordenao e colaborao no deve ser obrigatria, visto que o

feedback pode no ser desejado em todos os momentos do trabalho. J o evento de

comunicao ir proporcionar sempre algum grau de awareness, visto que o fluxo de

realizao do trabalho poderia ser interrompido e estagnar, sem a transmisso da

informao (ASSIS, 2000).

II.5.5 Elementos de awareness

Os sistemas informatizados que so desenvolvidos para ambientes cooperativos

devem prover elementos de awareness que disponibilizem de maneira adequada,

tanto as informaes necessrias cooperao como ao trabalho individual.

Ao conhecer o funcionamento dos mecanismos de comunicao, coordenao e

colaborao, sobretudo como eles devem ser usados para manter diferentes

elementos de awareness, podem ser criadas tcnicas e ferramentas que forneam

aos usurios as informaes apropriadas a respeito das metas, tarefas e dos outros

integrantes do ambiente.

Guiados pela conscincia sobre o que outras pessoas esto fazendo e o

conhecimento do que est acontecendo sua volta, os indivduos criam um

entendimento compartilhado e coordenam-se de forma que seus esforos individuais

agreguem valor ao trabalho do grupo. Ao se projetar um sistema informatizado com

estas caractersticas, deve-se levar em conta estes elementos, quais informaes

sero necessrias, como ger-las, reuni-las e distribu-las (GEROSA et al., 2003).

As informaes de awareness devem ser projetadas para se complementarem e

auxiliarem o trabalho individual no contexto da cooperao. Alguns exemplos so: o

66

objetivo comum, o papel de cada um dentro do contexto, o que fazer, como

proceder, qual o impacto das aes, at onde atuar, quem est por perto, o que o

companheiro pode fazer, o que as outras pessoas esto fazendo, a localizao, a

origem, a importncia, as relaes e a autoria dos objetos de cooperao (GEROSA

et al., 2003).

Para dar suporte s informaes sobre awareness, algumas consideraes

precisam ser consideradas: qual informao fornecer, como prov-la e como dar aos

indivduos o controle da informao (se pode ser visualizada, alterada, etc.). H

diversos tipos de elementos de awareness, classificados por finalidade, tempo,

escopo, abstrao, agregao, perspectiva, forma de fornecimento, personalizao,

entre outros (BRINCK; McDANIEL, 1997).

Estes elementos visam a responder basicamente s questes o que, quando, onde,

como e quem, cada uma identificando aspectos importantes para o fornecimento de

awareness dentro de ferramentas de groupware sncronas e assncronas.

Em ambientes sncronos, os membros do grupo esto trabalhando simultaneamente

(a interao sncrona descreve a situao em que mais de um usurio est

acessando concorrentemente a dados compartilhados), como em videoconferncias.

J em um ambiente assncrono, pode haver um intervalo de tempo entre a atuao

de um usurio e sua percepo por seus colegas, ou seja, os usurios no precisam

estar trabalhando simultaneamente para que o objetivo seja atingido.

Com isso, sistemas de groupware sncronos e assncronos diferem quanto s suas

necessidades por awareness, j que usurios obrigatoriamente trabalhando ao

mesmo tempo tero necessidades de awareness diferentes daqueles que no

precisam trabalhar simultaneamente. Dessa forma, torna-se importante, ao analisar

cada uma das cinco questes mencionadas acima, observar de qual ambiente se

trata (PINHEIRO et al., 2001).

O que

Refere-se a quais informaes devem ser fornecidas aos usurios, estando

intimamente ligadas a dois aspectos principais: as atividades e os papis. As

atividades so a base do trabalho cooperativo, uma vez que o objetivo a ser

alcanado geralmente dividido em atividades menores (ver Apndice A),

67

distribudas entre os membros do grupo. O conhecimento da distribuio das

atividades importante para o andamento do trabalho, tanto sncrono como

assncrono, pois representa saber as atividades dos colegas de trabalho.

Em um sistema assncrono, mais interessante ter uma viso ampla das atividades,

j que no h garantia sobre o momento em que uma tarefa ser realizada.

Os papis tambm so elementos importantes em um ambiente cooperativo, pois

representam a noo de hierarquia dentro do grupo, indicando as responsabilidades

e possibilidades dos membros sobre o trabalho.

Deste modo, os papis desempenhados fornecem uma boa indicao sobre o tipo

de informao de awareness necessria a seu desempenho. Por exemplo, as

informaes que so precisas para um participante, diferem das necessrias a um

coordenador. A coordenao fundamental em atividades cooperativas, e o

fornecimento de awareness especfico para a coordenao importante, tanto em

sistemas sncronos como assncronos (PINHEIRO et al., 2001).

Quando

Quando ocorrem os eventos geradores das informaes de awareness e quando se

d a apresentao destas informaes. As informaes de awareness so geradas

por eventos que ocorrem durante o trabalho do grupo e em funo de seu momento

de ocorrncia sero mais ou menos teis tomada de conscincia pelo indivduo e

pelo grupo.

Pode-se dividir a ocorrncia dos eventos em quatro momentos:

Passado: o passado inclui eventos que j ocorreram h algum tempo e cujos

resultados podem no ser mais vlidos;

Passado contnuo: para eventos que comearam no passado, mas que

continuam vlidos at agora, representando aqueles que, apesar de terem se

iniciado no passado, continuam valendo at o presente;

Presente: para eventos que esto ocorrendo neste momento;

Futura: representa as opes do grupo, os eventos que ainda podero

ocorrer, mas que precisam se tornar disponveis ao usurio. Por exemplo, o

caso de um alarme que avise quanto aproximao dos prazos para as

68

atividades, cuja chegada do prazo limite (evento gerador) s ocorrer no

futuro, mas o alarme, que fornece a informao de awareness desse evento,

ocorre antes.

Em ambientes assncronos, como h um possvel espao de tempo entre a atuao

dos colegas, vital manter o contexto sobre o que foi feito (eventos no passado) e

do que ainda est sendo feito (passado contnuo), para que os participantes possam

encaixar suas prprias atividades nas do grupo. A percepo de eventos futuros

representa uma opo interessante para manter os membros atentos aos possveis

rumos do trabalho.

A persistncia da informao (tempo de utilidade da informao) determinada pelo

interesse nos eventos ocorridos em um ou outro momento. At quando as

informaes de awareness so teis para o trabalho do grupo? Sero estas

informaes persistentes?

Em sistemas assncronos, como o interesse maior reside na percepo de eventos

no passado ou no passado contnuo, as informaes continuam teis ao grupo,

mesmo aps o momento de sua ocorrncia havendo a necessidade de uma alta

persistncia.

importante determinar um limite para este armazenamento, em que estas

informaes perdem sua utilidade. Eventos em um passado contnuo s so teis ao

grupo na medida que forem verdadeiros, podendo ser descartados, assim que

deixarem de ser.

Por outro lado, os eventos no passado so teis mesmo quando no forem mais

verdadeiros e devem ser mantidos, exigindo a definio de um critrio de

caducidade que inutiliza estas informaes. Este critrio pode ser um tempo de vida

fixo, o fornecimento das informaes para um ou mais membros, ou mesmo

combinaes de eventos.

Outra caracterstica importante refere-se ao momento da apresentao das

informaes de awareness. Em sistemas assncronos, h um intervalo de tempo

entre os eventos geradores e os demais membros para que possam perceb-los, de

modo que a informao apresentada normalmente em um momento posterior

ocorrncia dos eventos. Neste caso, adequado permitir ao prprio usurio decidir o

momento de receber tais informaes (PINHEIRO et al., 2001).

69

Onde

A atividade em grupo implica o trabalho sobre um conjunto de objetos dispostos

dentro de um espao de trabalho (workspace), compartilhado entre os membros. A

conscincia do que est ocorrendo neste espao compartilhado, chamada de

workspace awareness, que o conhecimento do que est acontecendo no

workspace compartilhado no momento atual, sendo um elemento natural dentro de

ambientes fsicos de trabalho.

Em ambientes assncronos, no h como garantir a presena dos colegas no

workspace em um intervalo de tempo, de modo que o foco de awareness localiza-se

nos objetos compartilhados por estes colegas, pois a comunicao entre os

membros ocorre por meio destes objetos, de sua manipulao e de seu histrico,

que mostram o que houve e est acontecendo dentro do trabalho em grupo, criando,

assim, o contexto para as atividades de cada membro. Em ambientes assncronos, o

artefato compartilhado essencialmente o nico espao compartilhado disponvel

aos participantes, constituindo-se em pea-chave na cooperao assncrona.

Independe do sistema ser sncrono ou assncrono, de inteira responsabilidade do

projetista desenvolver um ambiente capaz de dar suporte adequado, seja a

workspace awareness, seja a objetos compartilhados. Deste modo, necessrio

apresentar uma metfora adequada ao tipo de informao desejada. Assim, so

usadas, tanto as metforas de escritrio como as de sistema, e as metforas de

escritrio so ideais para sistemas sncronos e representam elementos do ambiente

de trabalho real, presentes no dia a dia dos participantes, como salas e mesas,

diminuindo a possibilidade de m interpretao.

As metforas de sistema relacionam o groupware com verses monousurias do

sistema, estas metforas afetam o modo como as informaes so capturadas pelos

participantes, havendo necessidade de enriquec-las adequadamente com as

informaes de awareness, de modo a permitir aos participantes uma conscincia

mais clara das atividades do grupo, enfatizando os aspectos de cooperao e

fornecendo aos usurios a sensao de estarem realmente trabalhando em grupo

(ver itens VIII.2 e VIII.5) (PINHEIRO et al., 2001).

70

Como

a interface do sistema, indicando como as informaes so apresentadas aos

usurios. A interface com o usurio a responsvel pelo fornecimento das

informaes de awareness. Para evitar a sobrecarga dos membros e permitir uma

rpida assimilao, estas informaes devem ser apresentadas de forma resumida.

Os usurios no podem se sentir sobrecarregados nem t-las omitidas.

Assim, para fazer o projeto de uma interface balanceada, deve-se trabalhar com

elementos de interface adequados, podendo ser cones ou cores associados a

informaes especficas, como papis e participantes, grficos representativos do

progresso do trabalho, ou ainda, uma combinao de elementos como estes. Deve-

se buscar que estes elementos apresentem as informaes de percepo de forma

resumida, sem sobrecarga nem perda de contedo significativo.

Para tanto, estes elementos devero fazer uma filtragem ou um agrupamento das

informaes, mostrando apenas aquilo que for mais til e interessante a cada

participante. Estes processos de filtragem e agrupamento podem utilizar vrios

critrios, desde o papel at preferncias pessoais de cada membro.

Uma possibilidade em ambientes assncronos a utilizao de interfaces

desacopladas, isto , que no sejam acopladas s interfaces dos demais colegas,

permitindo a cada membro adaptar a interface s suas necessidades individuais,

sem que os demais sejam notificados disto, mas no impedindo a interface de incluir

elementos de awareness.

Assim, o projetista de um groupware deve decidir entre beneficiar atividades

individuais ou priorizar a percepo das atividades coletivas. Em sistemas sncronos,

o trabalho feito pelo grupo simultaneamente, fazendo com que uma percepo

uniforme do workspace e dos objetos seja mais importante do que a flexibilidade

para o usurio isolado, sendo importante ter a oportunidade de ver onde seu colega

est trabalhando agora e o que est fazendo em detalhes.

Em ambientes assncronos, no necessrio utilizar interfaces conectadas umas s

outras, que foquem as aes dos colegas presentes, pois no h garantias de que

eles estaro trabalhando ao mesmo tempo. Uma possibilidade unir interfaces com

a ideia de mltiplas vises, fornecendo aos participantes a oportunidade de escolher

71

entre uma viso mais adequada sua atividade individual e outra que favorea sua

colaborao (PINHEIRO et al., 2001).

Quem

O conhecimento sobre quem est trabalhando e atento no momento importante

para o andamento das atividades no grupo, pois age como facilitador da

cooperao, medida que estimula a interao e a comunicao informal entre os

membros.

A noo de presena dos outros participantes fundamental em ambientes

sncronos, visto que invivel realizar uma tarefa simultaneamente com um grupo

de pessoas sem saber quem so estas pessoas. Nestes ambientes, os participantes

obrigatoriamente precisam estar conscientes da presena dos demais para que o

trabalho prossiga e obtenha resultados satisfatrios.

Tanto em ambientes sncronos como assncronos fornecer informaes sobre os

colegas importante para o fortalecimento da noo de grupo. O conhecimento cria

um senso maior de comunidade, na medida que os membros vo conhecendo

melhor seus colegas e o uso de mecanismos de comunicao refora a coeso

entre esses membros.

A noo da presena envolve tambm saber se algum est ou no atento ao

sistema, pois, estando os membros geograficamente distantes, a mera presena no

garante que o colega esteja realmente atento. De posse desse conhecimento,

possvel a um membro conversar, trocar ideias, pedir auxlio ou mesmo resolver

possveis conflitos por meio de ferramentas de comunicao, permitindo tornar as

relaes entre os participantes mais pessoais e interativas e menos formais.

J em ambientes assncronos, destaca-se o uso de ferramentas assncronas, como

email, quadro de avisos e notas que garantem aos membros a oportunidade de

manter uma comunicao informal com seus colegas (PINHEIRO et al., 2001).

72

Quadro de elementos de awareness para sistemas assncronos

Em todo ambiente, devem ser feitas estas perguntas, para identificar quais

elementos os usurios deveriam conhecer para ter conscincia da situao e

proporcionar o entendimento.

Os dados do Quadro II.1 mostram os elementos caracterizados por seu significado.

Com esses dados, projetistas podem analisar, por exemplo, como as situaes face

a face seriam traduzidas para um ambiente groupware. Isto no significa que o

projetista deva dar suporte a todos estes elementos igualmente na interface (ASSIS,

2000).

Quadro II.1 - Elementos de awareness para sistemas assncronos e desacoplados

Categoria Elemento Significado

O qu Atividades: Viso ampla das tarefas individuais e do grupo e de sua produo:

Aes O que fazer e o que os outros esto fazendo

Artefatos Em quais objetos esto trabalhando no momento

Produo Quais so os resultados preliminares do trabalho

Histrico de

aes

O que um indivduo esteve realizando

Papis: Diferenciao das informaes em funo do papel

Alcance At onde podem ou devem

Quando Eventos passados, passado

continuo e presentes:

Contexto sobre o que foi feito (eventos no passado) e do que ainda est sendo feito (passado contnuo),

Histrico de eventos

Quando um evento aconteceu

Eventos futuros Representam uma opo interessante para manter os membros atentos aos possveis rumos do trabalho.

Persistncia Alta: Definio de um critrio de caducidade, que inutiliza estas informaes.

Apresentao das informaes de awareness

Posterior (a critrio do usurio)

Onde Espao compartilhado

Objetos compartilhados pelo grupo. Atravs de sua manipulao mostra o que houve e est acontecendo dentro do trabalho em grupo.

Histrico de artefatos

Como um determinado artefato chegou quele estado

Histrico de localizao

Onde um indivduo esteve

Metforas de sistema

Relacionam o groupware com verses monousurias do sistema, havendo a necessidade de enriquec-la

73

Categoria Elemento Significado

adequadamente com as informaes de awareness.

Como Interface Interfaces desacopladas, mas no impedindo a interface de incluir elementos para awareness

Balanceamento de interface

Filtragem ou um agrupamento das informaes, mostrando apenas aquilo que for mais til

Quem Autoria Quem realizou um determinado evento

Histrico de presena

Quem esteve em um local do ambiente e quando

Ferramentas de comunicao

Essencialmente ferramentas assncronas (email, quadro de avisos e notas, etc.)

Fonte: adaptado de ASSIS (2000) e Pinheiro et al., 2001

II.5.6 Consideraes sobre awareness

Esta seo traz conceitos da Engenharia de Groupware utilizados em projetos de

software, voltados ao trabalho cooperativo em ambientes virtuais por meio do

conceito de awareness, apresentando diretrizes de como as situaes face a face de

um sistema de informao podem ser traduzidas para um software utilizado por

vrios usurios em ambientes distintos onde os recursos para esse tipo de

informaes so pobres, se comparados aos recursos do cenrio face a face, e os

mecanismos de interao so diferentes dos usuais.

Com relao pesquisa proposta, os aspectos abordados nesta seo so

utilizados em parte dos ciclo 2 e ciclo 3 da pesquisa-ao, uma vez que os mtodos

e tcnicas empregados durante os ciclos 1 e 2 da PA baseiam-se sobretudo em

interaes face a face.

No ciclo 2, os requisitos mais transacionais do trabalho cooperativo so focados por

meio do uso do modelo 3C. No ciclo 3, so focados os elementos de awareness

que, com o modelo 3C, permitem aos usurios construir um entendimento

compartilhado em torno dos objetos de cooperao e dos objetivos das tarefas, de

modo que possuam percepo das atividades dos companheiros e dos impactos

que ocorrem no conhecimento gerado pela cooperao. Os usurios tero

informaes que auxiliaro na sincronizao do trabalho, coordenando-se em torno

de seus contextos individuais.

74

II.6 MODELOS E PROCESSOS DE SOFTWARE

Esta seo descreve os principais modelos utilizados em engenharia de software,

passando do modelo cascata, at o modelo iterativo e evolucionrio. Em seguida,

so descritos os principais componentes do processo de desenvolvimento de

software.

Estes conceitos so empregados para possibilitar o entendimento de como sua

composio adapta-se ao processo proposto nesta pesquisa.

II.6.1 Conceitos e definies

Um processo de software um conjunto organizado de atividades e resultados

associados que transformam entradas em sadas e geram um produto de software

(ver Apndice A). O processo o fundamento da Engenharia de Software (disciplina

da engenharia relativa a todos os aspectos da produo de software, desde os

estgios iniciais de especificao do sistema at sua manuteno), possibilitando o

desenvolvimento racional do software pela efetiva utilizao da tecnologia de

engenharia em todos os aspectos de sua produo.

Um processo de desenvolvimento de software constitui, tambm, a base para o

controle gerencial de projetos de software e estabelece o contexto para aplicao de

mtodos na produo de artefatos (modelos, documentos, dados, relatrios,

formulrios, etc.) (KOTONYA; SOMMERVILLE, 1998; PRESSMAN, 2005).

Um modelo de processo de software (paradigmas de processo ou ciclo de vida)

uma descrio simplificada de um processo de software, uma abstrao til para

explicar as diferentes abordagens de desenvolvimento. Corresponde, enfim,

estrutura do processo, sem entrar em pormenores sobre o mesmo, podendo ser

estendido e adaptado para se criar processos de engenharia de software mais

especficos (SOMMERVILLE, 2007).

Nos prximos itens, sero descritos os principais modelos do processo de software:

modelo em cascata, desenvolvimento evolucionrio, transformao formal e

baseado em componentes, assim como um detalhamento dos processos de

software.

75

II.6.2 Modelo em cascata

O modelo em cascata, proposto por Royce (1987), tambm denominado modelo

sequencial linear, abordagem top-down ou ciclo de vida clssico, um dos

primeiros e mais importantes modelos, tornando-se uma espcie de gabarito para

muitos dos modelos modernos e ainda continua sendo amplamente usado

(PRESSMAN, 2005; SOMMERVILLE, 2007).

Este modelo foi proposto como contraposio abordagem composta apenas de

anlise e codificao (Figura II.4.a), que s se aplica, quando o esforo do

desenvolvimento pequeno, e o produto final operado por quem o construiu, no

qual apenas estes dois passos fracassam na produo de sistemas mais complexos,

sendo, ento, necessrias outras etapas complementares (Figura II.4.b) (ROYCE,

1987).

Requisitos de

sistema

Requisitos de

software

Anlise

Projeto do

cdigo

Codificao

Teste

Operao

Anlise

Cdigo

a) Etapas de implementao de um programa simples

b) Etapas de implementao de um programa complexo

Figura II.4 - Modelo em cascata Fonte: Royce (1987)

Seguindo um ciclo convencional de engenharia, sistemtico e controlado, o modelo

estabelece as seguintes etapas para o desenvolvimento de software:

Requisitos: funcionalidades, restries e objetivos so estabelecidos com o

cliente e os usurios do sistema informatizado;

Anlise: os requisitos definidos na etapa anterior so detalhados em termos

de funcionalidade, comportamento, desempenho e interface com usurio para

servir como especificao do software a ser construdo;

76

Projeto: a arquitetura geral do sistema informatizado estabelecida, sendo

descritas as abstraes fundamentais e as relaes entre elas;

Codificao: o projeto traduzido para uma linguagem de programao;

Teste: so realizados os testes para descobrir erros e verificar se os

requisitos foram atendidos;

Operao e Manuteno: o sistema informatizado entregue para ao cliente,

sendo instalado e colocado em operao. A manuteno envolve corrigir

erros no descobertos em estgios anteriores ou modificar o sistema

medida que o cliente requisita novas funcionalidades ou melhoria de

desempenho.

O princpio do modelo em cascata que as diferentes etapas seguem uma

sequencia: a sada de uma etapa flui para a etapa seguinte, o desenvolvimento s

prossegue quando uma etapa for concluda. O modelo original prev ciclos de

realimentao, mas as iteraes so estabelecidas apenas indiretamente, e a

maioria das organizaes trata o modelo como se fosse estritamente linear

(SOMMERVILLE, 2007).

Dentre as principais crticas ao modelo em cascata, Hanna (1995) destaca que

difcil estabelecer adequadamente todos os requisitos logo no comeo do projeto e

uma verso executvel s fica disponvel no trmino do projeto, assim um erro

grosseiro pode ser desastroso se for detectado apenas quando o sistema estiver em

execuo, uma vez que projetos reais raramente se orientam pelo fluxo sequencial

estabelecido.

Esta abordagem, possivelmente, foi emprestada das indstrias de fabricao de

linha de montagem, cujo ciclo de vida em cascata til, por exemplo, para montar

automveis em uma linha de montagem, mas, s depois que o prottipo do

automvel foi completamente corrigido (YOURDON, 1992).

O modelo em cascata adequado aos projetos de software em que os requisitos

so bem conhecidos e definidos desde o incio, e o processo de produo do

sistema pode ser sequencialmente estabelecido.

77

II.6.3 Modelo de desenvolvimento iterativo evolucionrio

Nesta abordagem, um sistema desenvolvido por meio de sucessivas verses.

Gera-se rapidamente um executvel com base nas especificaes iniciais. Em

seguida, deve-se refin-lo, apoiando-se nos retornos obtidos (feedback) do cliente

visando a produzir um sistema que satisfaa suas necessidades. O sistema , ento,

entregue ou, como alternativa, reimplementado, usando uma abordagem mais

estruturada para produzir um sistema mais robusto com maior capacidade de

manuteno.

H duas principais estratgias de desenvolvimento evolucionrio:

Prottipos descartveis. O objetivo de se construir prottipos descartveis

definir os requisitos que estejam mal compreendidos, objetivando desenvolver

uma boa especificao. Neste caso, a prototipao concentra-se em torno da

definio de requisitos que esto mal definidos;

Desenvolvimento exploratrio (modelo evolucionrio). O desenvolvimento

inicia-se com as partes do sistema que so bem definidas, evoluindo com o

acrscimo de novas caractersticas, medida que so requisitadas pelo

cliente.

Seguindo o modelo evolucionrio, tornou-se conhecido o modelo de

desenvolvimento em espiral (Figura II.5) proposto por Boehm (1988). Em vez de

uma sequncia linear de atividades, este processo representado como uma

espiral, em que cada volta representa uma fase do processo: a volta mais interna

relaciona-se viabilidade do sistema; a volta seguinte, definio dos requisitos; a

prxima volta, ao projeto; e, assim, por diante.

Cada volta da espiral, por sua vez, dividida em quatro setores:

Definio de objetivos: so definidos os objetivos de cada etapa do projeto,

sendo preparado um plano de gerenciamento, incluindo os riscos e

alternativas;

Avaliao e reduo de riscos: para cada risco identificado, realizada uma

anlise com tomada de providncias para diminuir o risco. Por exemplo, se h

risco dos requisitos serem inadequados, poder ser desenvolvido um

prottipo;

78

Desenvolvimento e validao: escolhe-se um modelo para o desenvolvimento

do sistema. Por exemplo, se os riscos na interface do usurio so

predominantes, um modelo apropriado de desenvolvimento poder ser um

prottipo evolutivo;

Planejamento: o projeto revisto para decidir se deve ser continuado. Se a

deciso for continuar, ento, ser planejada a prxima fase do projeto, dando

incio a uma nova volta na espiral.

Figura II.5 - Modelo Espiral de processo de software

Fonte: baseado em Boehm (1988)

A contribuio do modelo em espiral a explcita gerncia de projeto, considerando-

se os riscos (SOMMERVILLE, 2007). No h fases fixas, e este modelo faz uso de

outros, por exemplo, a prototipao pode ser usada para resolver dvidas relativas

aos requisitos, e esta fase pode ser seguida por um desenvolvimento convencional

em cascata.

Na abordagem incremental (desenvolvimento exploratrio), sugerida inicialmente por

Mills et al. (1980), os clientes identificam algumas funes e as ordenam-nas pela

79

relevncia, em seguida, so definidas uma srie de entregas, fornecendo um

subconjunto das funcionalidades do sistema na ordem estabelecida de prioridade. O

objetivo adiar algumas decises sobre o detalhamento de requisitos at que

clientes e usurios tenham alguma experincia com o sistema. Esta abordagem

encontra-se recentemente em evidncia com a programao extrema (BECK, 2004).

Em comparao com o desenvolvimento em cascata, o desenvolvimento

evolucionrio incremental tem a vantagem de desenvolver a especificao

gradativamente, conforme os usurios compreendam melhor o sistema, evitando

assim que erros grosseiros sejam identificados somente no final do processo.

Contudo, a partir da perspectiva da engenharia e do gerenciamento, so

identificados os seguintes problemas:

Os sistemas so frequentemente mal estruturados: a mudana constante

tende a corromper a estrutura do software, tornando-se cada vez mais difcil e

oneroso realizar modificaes;

O processo no visvel: os sistemas so desenvolvidos rapidamente, no

sendo produzidos documentos que reflitam cada verso, dificultando a

medio do progresso do desenvolvimento e, consequentemente, dificultando

a gerncia do projeto.

Segundo Sommerville (2007), para pequenos e mdios sistemas, a soluo

incremental a melhor escolha. J para sistemas complexos, grandes, de longa

durao e/ou desenvolvidos por equipes diferentes, a melhor soluo contempla o

uso de prototipao (descartvel ou no) para a definio dos requisitos que estejam

mal compreendidos, com uma implementao por meio de um modelo melhor

estruturado (modelo em cascata).

Neste trabalho, o termo prototipao incremental ou evolucionria usado e,

conforme Sommerville (2007), pode ser empregado como sinnimo de

desenvolvimento incremental, no qual o prottipo no descartado, mas evolui para

atingir os requisitos dos stakehoders.

80

II.6.4 Modelo de transformao formal

Nesta abordagem, o sistema especificado por meio de uma rigorosa notao

matemtica. Em seguida, so aplicados mtodos formais para transformar a

especificao em um programa. Ambiguidades e inconsistncias so descobertas e

corrigidas, no por meio de revises comuns, mas pela aplicao da anlise

matemtica. Estas transformaes preservam a correo, garantindo que o

programa produzido esteja livre de erros.

Esta abordagem adequada ao desenvolvimento de sistemas que tenham rigorosas

exigncias de segurana e confiabilidade, como os sistemas de aeronaves e

dispositivos mdicos. Contudo, fora dos domnios especializados, os processos com

base em transformao formal no so amplamente usados porque

(SOMMERVILLE, 2007; PRESSMAN, 2005):

Requerem percia especializada, com poucos desenvolvedores de software

com treinamento necessrio para aplicar mtodos formais;

O desenvolvimento dos modelos formais atualmente lento e dispendioso;

Em relao a outras abordagens, no oferecem vantagens significativas de

custo ou qualidade para a maioria dos sistemas;

So difceis usar os modelos, como um mecanismo de comunicao com

clientes, geralmente despreparados tecnicamente.

II.6.5 Modelo de desenvolvimento baseado em componentes

O desenvolvimento baseado em componentes uma estratgia recente e vem se

tornando cada vez mais usada (SOMMERVILLE, 2007).

A tcnica supe que partes do sistema j existem, e o desenvolvimento concentra-

se na integrao destas partes. O foco no reuso de componentes

(desenvolvimento com reuso), mas, eventualmente desenvolvendo novos

componentes (desenvolvimento para reuso). A Figura II.6 apresenta uma descrio

simplificada das atividades realizadas no desenvolvimento, baseado em

componentes.

81

Identifique os

componentes

adequados

Prxima iterao

Coloque os

novos

componentes

na biblioteca

Construa os

componentes

no disponveis

Extraia os

componentes

disponveis

Procure os

componentes

na biblioteca

Figura II.6 - Desenvolvimento baseado em componentes Fonte: baseado em Pressman (2005)

Seguindo esta abordagem, tornaram-se conhecidos processos como UML

Components (CHEESMAN e DANIELS, 2001) e Rational Unified Process

(KRUCHTEN; KROLL, 2003).

II.6.6 Processo de desenvolvimento de software

A despeito da existncia de vrios tipos de processos de software, algumas

atividades so comuns a todos:

Especificao: nesta atividade, devem ser definidas as funcionalidades do

software, bem como as restries em sua operao;

Projeto e implementao: correspondem produo do software para atender

especificao;

Validao: garante que o mesmo executa as funcionalidades definidas pelos

usurios;

Evoluo: o software deve evoluir para atender s necessidades em contnua

mudana dos usurios.

Os processos de desenvolvimento do software evoluem para explorar as

capacidades das pessoas na organizao e as caractersticas especficas dos

sistemas que sero desenvolvidos, de modo que, por exemplo, para sistemas

crticos necessrio um processo muito bem estruturado e, para sistemas de

negcio, cujas mudanas dos requisitos podem variar mais rapidamente, processos

mais geis e flexveis so mais efetivos (PRESSMAN, 2005; SOMMERVILLE, 2007).

82

Um ambiente de desenvolvimento de software inicia-se com uma slida definio do

processo que inclui atividades, usualmente, denominadas como fases, tarefas ou

passos, e o que ser produzido em cada uma dessas atividades. O processo

especifica a ordenao das atividades que podem ser sequenciais, concorrentes ou

paralelas, e todas reunidas definem a base da execuo do desenvolvimento

(PAULK et al. ,1994).

Expandindo as atividades acima descritas, Pfleeger e Atlee (2006) apresentam os

processos do desenvolvimento de software de maior interesse:

Requisitos: descrio das necessidades do usurio, transformao em

especificaes funcionais e no funcionais e determinao dos vrios

componentes do software a serem desenvolvidos: escopo, entidades

envolvidas, funcionalidades, padres de usabilidade e regras de aceitao;

Projeto: estruturao da forma com a qual o software estar resolvendo cada

uma das especificaes formuladas, contemplando o cdigo computacional, o

tratamento de dados e a interface homem-mquina;

Codificao: transformao das especificaes em linguagem computacional,

criando os artefatos especificados no projeto;

Testes: eliminao dos erros e falhas encontrados no cdigo e no conjunto do

software no qual cada artefato estar presente. Os testes envolvem as

atividades de validao (presena de todos os requisitos) e verificao

(funcionamento correto de cada componente);

Integrao: adequao de todos os novos artefatos no conjunto do software,

garantindo o perfeito funcionamento. Assim como a integrao do teste

envolve a validao e a verificao de todos os requisitos;

Instalao: disponibilizao do software no ambiente produtivo com o usurio;

Aceitao: manifestao do grau de satisfao do cliente com o software;

Manuteno: correo dos erros surgidos aps a entrega ao usurio.

83

II.6.7 Consideraes sobre modelos e processos de software

O desenvolvimento dos sistemas informatizados abordados nesta pesquisa requer

competncias e procedimentos especficos, tais como: conhecimento sobre

cooperao, mtodos de anlise do trabalho coletivo, tcnicas de Engenharia de

Requisitos, realizao de pesquisa-ao e avaliao diferenciada da interface com

usurio (que no mais entre usurio e sistema mas sim entre usurio e grupo).

Na literatura especfica desta rea, no proposto um modelo diferente dos j

conhecidos mas sim so elaboradas especificaes de processos conhecidos para

incorporar as prticas especficas para o desenvolvimento dos tipos de sistemas

informatizados.

No h um processo que possa ser considerado ideal e nem se pode demonstrar

que um processo sempre melhor que outro (PRESSMAN, 2005; SOMMERVILLE,

2007). Cada processo incorpora boas prticas que o fazem adequado para

determinados tipos de projetos. Nesta pesquisa, o processo proposto aborda a

atividade de anlise de requisitos e mostra-se adequado especificamente para o

desenvolvimento evolucionrio de sistemas, cuja coordenao distribuda pelas

aes dos usurios.

II.7 ENGENHARIA DE REQUISITOS (ER)

Nesta etapa da fundamentao, so abordados os principais conceitos tratados pela

Engenharia de Requisitos, o detalhamento do processo de especificao de

requisitos de software, do macroprocesso de desenvolvimento de software e os

modelos de sistema informatizados utilizados para documentar e analisar os

requisitos de sistema, constituindo-se em uma importante ponte de ligao entre a

anlise de requisitos e o projeto do software.

II.7.1 Conceitos e definies

A Engenharia de Requisitos (ER) uma subrea da Engenharia de Software, estuda

o processo de definio dos requisitos que o software dever atender.

84

Requisitos, para Sommerville et al. (1998), so descries de como o software deve

comportar-se, informaes do domnio da aplicao, restries sobre operao de

software ou especificaes de propriedade ou atributo de um software. Os requisitos

so definidos durante os estgios iniciais do desenvolvimento do software, como

uma especificao do que poder ser implementado. Os requisitos contm

invariavelmente uma mistura de informao do problema, declaraes de

comportamento e propriedades do software, condies do projeto e restries de

construo.

O processo de Engenharia de Requisitos, conforme Kotonya e Sommerville (1998),

um conjunto estruturado de atividades para conhecer requisitos, validar e mant-

los em um documento de requisitos. Estas atividades incluem elicitao, anlise,

negociao e validao de requisitos. Uma descrio completa inclui quais

atividades so destacadas e a estruturao ou escalonamento destas atividades,

quem o responsvel, as entradas e/ou sadas para/de e as ferramentas usadas

para suportar ER.

Esta sesso aborda os conceitos tradicionais da ER. A sesso II.5 traz a abordagem

do trabalho cooperativo em um sistema informatizado por meio dos conceitos do

modelo 3C (FUKS et al., 2007), awareness (ASSIS, 2000) e groupware.

II.7.2 Elementos da Engenharia de Requisitos

Alm dos requisitos em si, abaixo esto descritos os principais elementos

encontrados na Engenharia de Requisitos.

Ambiente ou Domnio da Aplicao

O ambiente ou domnio da aplicao onde ocorrem os fenmenos que

caracterizam os problemas referentes aos requisitos particulares do cliente

(JACKSON, 1995).

o primeiro elemento a ser conhecido e representado na anlise de requisitos,

observando o contexto nos quais os fenmenos esto presentes e interagem.

85

Problema

No contexto de elicitao de requisitos, o problema a razo principal para o

entendimento, especializao e domnio do conhecimento. Identificar o que o

problema, qual sua definio, quem o tem e qual sua essncia (sob o ponto de

quem o tem) caracteriza a complexidade do processo.

Segundo Jackson (1995), necessrio distinguir claramente um processo de

definio do problema (conhecimento dos requisitos) de um processo de soluo do

problema (aplicao de ferramentas de software como soluo). J que a fonte dos

problemas intrnseca no comportamento das pessoas, importante identificar qual

o desejo de ter resolvido o problema e se existe realmente o desejo de uma soluo.

Stakeholders

Stakeholders compreendem o conjunto de pessoas ou objetos que, direta ou

indiretamente, so afetados pela soluo do software a ser construdo (RYAN,

1998), e para quem o resultado do processo de desenvolvimento de software

constitui interesse.

Requisitos

Funcionais: devem descrever o que o sistema deve fazer, como deve reagir a

determinadas entradas e como deve se comportar em determinadas

situaes; portanto, referem-se s condies e exigncias de transformao

de entradas em sadas;

No funcionais: so restries dos servios ou funes oferecidas pelo

sistema. Incluem restries de tempo, restries no processo e padres

(SOUZA; CASTRO, 2004). Geralmente, so aplicados ao sistema como um

todo e podem ser classificados em: requisitos de processos, de produtos e

externos. Referem-se s especificaes tcnicas de padres e mtodos do

processo produtivo, da qualidade do produto e caractersticas desejveis e

das polticas aplicveis ao processo e ao produto gerado. Segundo Leite

(2002), os requisitos no funcionais podem ser expressos de duas maneiras:

independentes ou associados a um requisito no funcional;

86

Requisitos de domnio: estes requisitos so oriundos do domnio da aplicao

e refletem as caractersticas e restries deste domnio, podem ser funcionais

ou no funcionais. Usualmente, incluem terminologia especializada do

domnio da aplicao ou referncia aos conceitos desse domnio. Estes tipos

de requisitos so importantes, pois refletem os fundamentos do domnio da

aplicao, de modo que pode ser impossvel desenvolver o sistema de

informao, se os mesmos no forem satisfeitos;

Requisitos de usurios: devem descrever os requisitos funcionais e no

funcionais, de modo que sejam compreensveis pelos usurios sem

conhecimento tcnico detalhado. Devem apenas especificar o comportamento

externo do sistema, evitando o mximo possvel detalhes tcnicos sobre os

mesmos, focando nas facilidades-chave que sero fornecidas;

Requisitos de sistema: uma verso ampliada dos requisitos dos usurios

que so usados pelos desenvolvedores do sistema, como ponto de partida

para o projeto do sistema. Estes requisitos adicionam detalhes para explicar

como os requisitos de usurios podem ser atendidos pelo sistema e devem se

concentrar no comportamento externo do sistema e suas restries, sem se

preocupar no modo como o sistema ser implementado ou projetado.

Especificao de interfaces

Quase todo tipo de sistema informatizado deve operar com outros existentes que j

tenham sido implementados e instalados no ambiente. Caso estes sistemas devam

trabalhar em conjunto, as interfaces do sistema informatizado existente devem ser

especificadas, desde o incio do processo de definio de requisitos.

Na Figura II.7 abaixo, estes elementos podem ser vistos, considerando o processo

de engenharia de requisitos como um todo.

87

Especificao das

interfaces

Requisitos dos

stakeholders

Requisitos de

domnio

Processo de engenharia de

requisitos

Especificao dos

requisitos do

sistema

Modelos do

sistema

Figura II.7 - Entradas e sadas do processo de Engenharia de Requisitos Fonte: baseado em Kotonya e Sommerville (1998)

Modelos do sistema

Um conjunto de modelos, tais como fluxo de dados, modelo de objetos, modelo do

processo, modelo de dados, etc. que descrevem o sistema a partir de diferentes

pontos de vista (item II.7.4).

II.7.3 Processo de Engenharia de Requisitos

A Figura II.8 abaixo destaca os quatro subprocessos da Engenharia de Requisitos.

O estudo de viabilidade verifica se o sistema a ser desenvolvido til ao negcio. As

fases de elicitao e anlise tratam da descoberta dos requisitos, a especificao

converte estes requisitos em alguma forma padro e a fase de validao verifica se

os requisitos realmente definem o sistema que os stakeholders esperam

(SOMMERVILLE, 2007).

88

Figura II.8 - Subprocessos do processo de Engenharia de Requisitos Fonte: baseado em Kotonya e Sommerville (1998); Sommerville (2007)

Estudo de viabilidade

A entrada do estudo de viabilidade corresponde a um conjunto preliminar de

requisitos do negcio e corresponde a uma descrio resumida do sistema e de que

modo este dever dar apoio aos processos de negcio. O resultado do estudo de

viabilidade pode ser um relatrio que recomende se vale a pena seguir o processo

de levantamento de requisitos.

Neste estudo, vrias fontes devem ser consultadas, tais como gerentes de

departamentos onde o sistema ser utilizado, engenheiros de software com

familiaridade no sistema proposto, especialistas em tecnologia e usurios finais

desse sistema. Dependo do resultado deste estudo, podero ser propostas

mudanas em seu escopo, oramento e cronograma do sistema, alm de requisitos

complementares ao mesmo.

89

Elicitao e anlise de requisitos

Essencialmente, o subprocesso de elicitao de requisitos relacionado com a

descoberta dos requisitos do sistema e compreenso das necessidades dos

usurios. Assim, analistas e engenheiros de software trabalham com clientes e

usurios finais no domnio da aplicao para descobrir o problema a ser resolvido,

os servios do sistema, o desempenho necessrio, restries de hardware e outras

informaes. Nos dados do Quadro II.2, Kotonya e Sommerville (1998) apresentam

os papis essenciais para a execuo da atividade de elicitao de requisitos.

Quadro II.2 - Papis no processo de Engenharia de Requisitos

Papel Descrio

Especialista do domnio Responsvel por prover informaes sobre o domnio de aplicao e do problema especfico a ser resolvido naquele domnio

Usurio final Responsvel pelo uso do sistema aps a entrega

Engenheiro de Requisitos Responsvel por identificar e especificar os requisitos do sistema

Engenheiro de Software Responsvel por desenvolver o prottipo do sistema

Gerente de Projeto Responsvel pelo planejamento do projeto

Fonte: Kotonya e Sommerville (1998)

Observa-se que nenhuma definio fornece a real dimenso da dificuldade na

conduo da atividade. Tal dificuldade surge da natureza menos tcnica e mais

social da atividade de ER, como destacam Goguen e Linde (1993).

A forte influncia das questes sociais acaba por introduzir problemas nos requisitos

levantados, e estes problemas precisam ser identificados para que possam ser

tratados. Entre os problemas comuns enfrentados na atividade de elicitao,

Kotonya e Sommerville (1998) citam:

A forma dispersa como so encontrados os requisitos (em livros, manuais,

conhecimento de pessoas especficas, etc.);

A terminologia especfica do domnio da aplicao que precisa ser

compreendida para garantir o entendimento do problema no contexto do

domnio da aplicao;

A tarefa de auxiliar no levantamento de requisitos , via de regra, secundria

no contexto de trabalho dos stakeholders, constituindo uma barreira

90

execuo do trabalho de requisitos, culminando com o no envolvimento dos

stakeholders no processo de requisitos;

Questes organizacionais e fatores polticos que exercem grande influncia

sobre os requisitos, este fatores nem sempre so identificados pelos usurios

finais e podem passar despercebidos pelo engenheiro de requisitos.

Alm destes problemas, a possibilidade de automao altera a perspectiva dos

stakeholders sobre o prprio trabalho, fazendo com que no tenham uma correta

percepo sobre os requisitos do sistema (KRUCHTEN, 2003).

Segundo Sommerville (2007), a fase de elicitao de requisitos apresentada em

quatro atividades:

Descoberta dos requisitos: corresponde ao processo de reunir informaes

sobre o sistema proposto e o SI existente, extraindo os requisitos dos

usurios e do sistema destas informaes. As fontes de informao utilizadas

na descoberta de requisitos incluem documentao, stakeholders do sistema

e especificaes de sistemas similares. Vrias tcnicas so usadas para a

descoberta destes requisitos que so discutidas no item II.8. Somando-se aos

stakeholders de sistema, devem ser empregados os requisitos oriundos do

domnio da aplicao e de outros sistemas que interagem com o sistema que

est sendo especificado. Estas fontes de requisitos (stakeholders, domnio e

sistema) podem todas ser representadas por pontos de vista de sistema, pois

cada ponto de vista representa um subconjunto dos requisitos do sistema

(NUSEIBEH et al., 2003; SABETZADEH et al., 2010);

Classificao e organizao dos requisitos: esta atividade trabalha com

requisitos vindos de diferentes stakeholders distribudos em colees

desestruturadas, grupos relacionados e sobreposio entre requisitos,

organizando-os em famlias coerentes. A maneira mais comum de agrupar os

requisitos pela utilizao dos modelos da arquitetura do sistema para

identificar subsistemas e requisitos associados a cada subsistema;

Negociao e priorizao dos requisitos: quando mltiplos tipos de

stakeholders esto envolvidos, inevitavelmente, haver conflito nos requisitos.

Esta atividade relaciona-se com a priorizao dos requisitos, encontrando e

resolvendo conflitos por meio da negociao.

91

Documentao de requisitos: nesta atividade, os requisitos que foram

descobertos so documentados de modo que podero ser empregados na

ajuda de novas descobertas de requisitos.

Especificao de requisitos

A especificao de requisitos ou documento de requisitos tem por finalidade

formalizar os requisitos que sero utilizados como referncia para as outras fases do

ciclo de vida do software.

O documento de requisitos o meio empregado para descrever as restries quanto

s caractersticas do produto e quanto ao processo de desenvolvimento, a interface

com outras aplicaes, a informao a respeito do domnio da aplicao e

informaes de suporte ao conhecimento do problema, tais como: modelos, termos

especializados do negcio, recuperao e gerenciamento de informaes em

mudana.

A informao que deve ser includa na especificao, depende do tipo de software

que est sendo desenvolvido e da abordagem de desenvolvimento utilizada. Se uma

abordagem evolucionria adotada para o desenvolvimento do software, a

especificao de requisitos pode deixar fora muitos detalhes sobre os mesmos. O

objetivo ser definir os requisitos do usurio e os requisitos no funcionais de alto

nvel. Neste caso, os programadores e projetistas devem usar seu julgamento para

decidir como alcanar requisitos do sistema (SOMMERVILLE , 2007).

Validao

Aps a documentao dos requisitos ter sido produzida, inicia-se o processo de

validao, buscando verificar se os requisitos esto certos, ou seja, descritos de

forma apropriada, procurando eliminar os problemas dos requisitos incompletos,

ambiguidade, inconsistncia, facilidade de verificao por meio de testes e

verificao de validade entre requisitos. A validao dos requisitos sobrepe-se

descoberta e anlise, na medida que a mesma tambm se refere busca de

problemas nos requisitos.

Uma das tcnicas mais importantes utilizadas na validao corresponde reviso

dos requisitos, no qual so analisados sistematicamente por um grupo de revisores.

92

Na reviso, o grupo de desenvolvimento do sistema caminha com o cliente do

sistema por meio dos requisitos, explicando as implicaes de cada um deles. Os

revisores devem verificar cada requisito com respeito sua consistncia, assim

como observar se os requisitos esto completos (KOTONYA; SOMMERVILLE,

1998).

Gerenciamento

Embora no seja uma, permeia todas as fases da Engenharia de Requisitos, sendo

responsvel por controlar a evoluo dos requisitos de um sistema, seja pela

constatao de novas necessidades, seja pela comprovao das deficincias nos

requisitos registrados at o momento.

Sempre que os requisitos alocados forem alterados, os planos de software, os

artefatos e as atividades afetadas devem sofrer ajustes para continuarem

consistentes. Um aspecto importante que os requisitos sejam dinmicos e estejam

em uso durante todo o ciclo de vida, sendo a base para a modelagem do sistema.

Congelar os requisitos, aps a etapa de validao, invivel, j que os negcios no

so estveis. Como eles se adaptam s mudanas, os sistemas tambm devem se

adaptar. A capacidade de adaptao do processo do desenvolvimento hoje um

diferencial estratgico entre as empresas de software. Esta capacidade de

adaptao mrito em grande parte do processo do gerenciamento de requisitos.

II.7.4 Modelos de sistema

Os requisitos de usurio devem ser escritos na forma de texto em razo da

necessidade de serem entendidos por pessoas que no sejam especialistas

tcnicas. Entretanto, requisitos de sistema devem ser descritos de um modo mais

tcnico. Uma tcnica utilizada corresponde na documentao da especificao do

sistema, como um conjunto de modelos.

Estes so mais representaes grficas baseadas em conceitos computacionais,

tais como objetos e funes, descrevendo o processo de negcio, o problema a ser

resolvido e o sistema que ser desenvolvido, do que conceitos do domnio da

aplicao.

93

Assim, o processo de formulao, estruturao e modelagem dos requisitos pode

ser guiado pelos modelos do sistema que so uma abordagem sistematizada para

documentar e analisar os requisitos de sistema, sendo um importante elo de ligao

entre a anlise de requisitos e o projeto do software (SOMMERVILLE, 2007).

O aspecto mais importante de um modelo de sistema o de no considerar detalhes

da soluo, j que corresponde a uma abstrao de parte SI em estudo,

simplificando e colocando em evidncia seus aspectos mais importantes.

Tipos diferentes de modelos so caracterizados por distintos tipos de abstrao,

sendo importante ressaltar que no existe um nico modelo ideal. Por exemplo, um

modelo de fluxo de dados concentra-se no fluxo dos dados e em suas

transformaes funcionais, deixando de lado os detalhes de suas estruturas. J o

modelo de entidade e relacionamento de dados documenta as estruturas dos dados

em detrimento das funcionalidades (KOTONYA e SOMMERVILLE, 1998).

Nos prximos itens, sero descritos os principais modelos de sistema e respectivas

abstraes.

Modelo de fluxo de dados

Modelo de fluxo de dados corresponde a um modo intuitivo para mostrar como os

dados fluem por meio de uma sequncia dos passos de processamento (funes ou

transformaes) e fornecem uma abstrao orientada para funes, cujos dados so

transformados em cada uma dessas sequncias, antes de se mover para o prximo

estgio. Este modelo utiliza o diagrama de fluxo de dados (DFD) para representar

graficamente as entidades externas, processos, fluxo de dados e depsito de dados

e foi proposto originalmente por Demarco (1989).

Assim, o DFD composto por dados que se movem, sendo representado por setas

nomeadas pelos dados, pela transformao de dados em outros dados, mostrados

nos crculos (o nome deste crculo corresponde a uma funo/transformao), fontes

e destinos de dados, representados por retngulos (designados de terminadores) e

do depsito de dados, mostrado como linhas paralelas (Figura II.9).

As funes representadas pelos crculos so a base para a decomposio funcional

posterior, de modo que este tipo de modelo apresentado de um modo hierrquico,

cujo primeiro modelo (tambm chamado de diagrama de contexto) representa o

94

sistema como um todo e os prximos DFDs refinem o diagrama de contexto,

fornecendo mais detalhes em cada nvel do diagrama subsequente.

O diagrama de contexto ajuda na viso do sistema como uma caixa preta onde

feita uma anlise do tipo de dados que entram no sistema e suas respectivas fontes,

assim como dos dados que saem do sistema e seus destinos, permitindo definir as

fronteiras do sistema, de modo a facilitar que clientes e desenvolvedores possam

entrar em acordo com o escopo do sistema a ser desenvolvido (PRESSMAN, 2005).

Funo/

TransformaoTerminador 1 Terminador 2

Depsito de dados

Dados de entrada Dados de sada

Figura II.9 - Notao do diagrama de fluxo de dados (DFD) Fonte: baseado em Pressman (2005)

Modelo de dados semntico

Este modelo descreve em alto nvel de abstrao como os dados se relacionam em

um sistema; importante, pois permite evidenciar as estruturas dos dados, suas

propriedades e seus relacionamentos, independente do processamento que

ocorrer, permitindo responder questes como: quais so os dados necessrios

para o negcio? Como estes dados relacionam-se com os demais? Estes dados

pertencem a quem? Quem est autorizado a ter acesso aos mesmos?

Para viabilizar um modelo que permitisse fornecer informaes a respeito da

semntica dos dados, Chen (1990) props o modelo de entidade e relacionamentos

(MER), que identifica as entidades em um banco de dados, seus atributos e a

relao explcita entre eles.

Assim como outros modelos, o MER descrito por meio de uma notao grfica

para facilitar o entendimento (Figura II.10) e possui os seguintes elementos:

95

Entidade: representa uma coleo ou um conjunto de objetos (coisas) do

mundo real, cujos objetos individuais possuem as seguintes propriedades: s

podem ser identificados de uma nica forma, exercem um papel no sistema

em construo e podem ser descritos por um ou mais elementos dos dados

(atributos);

Relacionamento e cardinalidade: so as associaes entre as entidades dos

dados, representam uma ligao entre objetos do domnio; e seu

relacionamento representa um conjunto de conexes entre os objetos, de

modo que cada conexo represente uma associao entre zero ou mais

ocorrncias de um objeto e zero ou mais ocorrncias do outro objeto

(cardinalidade);

Entidade de relacionamento: corresponde a uma representao de um

relacionamento sobre a qual importante manter informaes na forma de

uma entidade.

Entidade 1 Entidade 2

Cardinalidade de

entradaCardinalidade de

sadaNome do

relacionamento

Atributo de

relacionamento

Figura II.10 - Modelo de entidade e relacionamento (MER) Fonte: baseado em Chen (1990)

Modelo de Objetos

O modelo orientado a objetos combina o uso dos dois modelos anteriores, sendo

mais prximo do modelo de dados semntico, tendo como diferena fundamental o

conceito de encapsulamento dos dados.

No centro deste modelo, esto as classes de objetos que representam uma

abstrao a respeito de um conjunto de objetos que identifique atributos e servios

(operaes) em comum. Cada objeto (ou instncia) desta classe possui os atributos

96

e servios desta classe e os modelos so desenvolvidos, utilizando como centro da

anlise os objetos da classe e seus relacionamentos.

Neste tipo de anlise, os objetos do mundo real devem ser representados por meio

de classes de objetos, criando-se diferentes tipos de classes e de como se

relacionam entre si, como os objetos so agregados para formar outras classes e

como os objetos relacionam-se entre si.

Vrios mtodos de anlise orientada a objetos foram propostos, sendo os principais:

projeto e modelagem orientado a objetos (RUMBAUGH et al., 1991), engenharia de

software orientada a objetos (JACOBSON et al., 1992) e anlise orientada a objetos

(BOOCH, 1994). Uma vez que estes mtodos possuam muitas similaridades, estes

trs autores decidiram integrar suas propostas para produzir um mtodo unificado

denominado UML (Unified Modeling Language) (UML, 2008).

Para certas classes de problemas, o modelo de objetos um modo natural de refletir

as entidades do mundo real que so manipuladas pelo sistema. Esta questo,

particularmente, verdadeira quando o sistema processa informaes a respeito

das entidades tangveis, tais como carros, avies ou livros, que tm atributos

claramente identificveis (por exemplo, sistema em tempo real). Em sistemas que

possuem entidades mais abstratas, tais como os comerciais, mais difcil modelar

suas classes de objetos, no possuindo necessariamente uma interface simples com

atributos e operaes independentes.

Embora este tipo de modelo facilite a transio entre a anlise de requisitos e a

programao, os usurios com frequncia consideram o modo pouco natural e

mostram dificuldade para entend-lo, preferindo adotar o modelo mais funcional de

processamento de dados.

Modelo de transio de estados

Este modelo descreve como um sistema responde a eventos internos ou externos,

foi proposto inicialmente por Ward e Mellor (1985). O modelo de transio de

estados mostra os estados e os eventos que causam mudanas de um estado para

outro, enfatizando o comportamento tempo-dependente do sistema.

97

O tipo de modelo no se preocupa com o fluxo de dados dentro do sistema, sendo

til para representao de sistemas em tempo real, uma vez que, em geral, so

guiados pelos estmulos do ambiente do sistema.

Assim, o modelo de transio de estados pressupe que o sistema seja um dos

possveis estados assumidos pelo mesmo, sendo seu maior problema que o nmero

de possveis estados aumenta rapidamente com a complexidade do sistema.

Modelo de contexto, processo e de fluxo de trabalho (workflow)

Logo nos estgios iniciais da descoberta de requisitos (elicitao), deve-se decidir

onde esto as fronteiras do sistema: deste modo, limitando os custos do sistema e o

tempo necessrio para anlise. Uma vez definida as interfaces do sistema deve-se

conhecer o contexto e as dependncias dos sistemas e seu ambiente. Para tanto, o

diagrama de contexto discutido no modelo de fluxo de dados pode ser utilizado.

Assim, aps definir o contexto, o modelo dever ser complementado com o modelo

de processo, que mostra as principais atividades envolvidas na execuo do fluxo de

trabalho. Modelar o processo consiste, basicamente, na representao grfica de

um modelo das relaes existentes entre: tarefas, pessoas, informaes e objetos

envolvidos, com o objetivo de explicitar a realidade estabelecida no ambiente

estudado (ver Apndice A; DAVENPORT, 1993).

Com o processo modelado e o sistema possuindo um nmero diferente de grupos

de usurios, cada um com diversas atribuies, fazendo uso das distintas interfaces

do usurio, muitas vezes, necessrio ir alm da anlise dos processos, aplicando

uma anlise de fluxo de trabalho (workflow). Esta tcnica permite a compreenso de

como o processo de trabalho completado, quando diferentes pessoas (e regras)

esto envolvidas.

Na medida que o fluxo de trabalho analisado, deve ser definida passo a passo

uma hierarquia de subatividades para cada atividade do fluxo principal,

acompanhada das respectivas interfaces do usurio (PRESSMAN, 2005).

98

II.7.5 Consideraes sobre Engenharia de Requisitos

Esta seo expe caractersticas gerais sobre a Engenharia de Requisitos,

contextualizando-a dentro da Engenharia de Software, mostrando seus principais

conceitos e definies, seus principais elementos, o processo para obteno de

requisitos de software e os principais modelos empregados para documentar a

especificao do sistema.

Mostra, tambm, que as dificuldades surgem sobretudo da natureza menos tcnica

e mais social da atividade de ER, com poucos esforos de aprofundar os

conhecimentos desenvolvidos na rea das cincias sociais (GOGUEN e LINDE,

1993), de modo que a forte influncia das questes sociais acaba por introduzir

problemas nos requisitos levantados.

Outro aspecto importante a ser destacado a possibilidade de automao, segundo

Kruchten (2003), que altera a perspectiva dos stakeholders sobre o prprio trabalho,

fazendo com que no tenham um correto entendimento sobre os requisitos do

sistema: deste modo, introduzindo o paradoxo apontado nos itens I.1 e II.8.3.

Nesta pesquisa, os modelos de contexto, de processo e de fluxo de trabalho

(workflow) foram usados para documentar o sistema, descrevendo o processo de

negcio, o problema a ser resolvido e o sistema que ser desenvolvido. Este modelo

de sistema foi escolhido, pois define em um nico modelo as interfaces do sistema,

seu contexto e as dependncias dos sistemas e seu ambiente.

Outra razo para a escolha deste modelo foi o fato de que seus componentes foram

utilizados como elementos de representao comum nas sesses de ACT realizadas

nos ciclos 2 e 3.

O processo de negcio (ver Apndice A) foi modelado por intermdio de um

fluxograma e apresentado nas sesses aos usurios, com uma hierarquia de

subatividades para cada atividade do fluxo principal, acompanhada das respectivas

interfaces de usurio, uma vez que diferentes pessoas, papis e regras estavam

envolvidos, sendo paulatinamente complementado na medida que as sesses

ocorriam (sobretudo nos ciclos 2 e 3 da pesquisa-ao).

99

II.8 TCNICAS UTILIZADAS NA DESCOBERTA DE REQUISITOS

O objetivo desta seo apresentar algumas das principais tcnicas de descoberta

de requisitos para a contextualizao do processo proposto nesta pesquisa. Assim,

nos prximos itens sero focadas as tcnicas de cenrios, entrevistas,

storyboard/prototipao e etnografia.

II.8.1 Cenrios

Em geral, os usurios preferem utilizar exemplos da vida real a descries abstratas,

sendo mais fcil compreender e criticar um cenrio que mostra como interagir com o

software do sistema. Os cenrios so descries de exemplos de sesses de

interao com o sistema e so referentes a um determinado tipo de interao entre o

usurio final e o sistema. Os usurios explicam o que esto fazendo, e as

informaes que necessitam do sistema para executar a tarefa descrita no cenrio.

Os cenrios podem ser descritos como histrias que explicam, como o sistema

utilizado, sendo teis, inicialmente, para agregar detalhes em uma descrio

resumida de requisitos. Uma vez possuindo uma ideia bsica de como o sistema

deve atender aos requisitos, desenvolvem-se os cenrios em torno desta soluo.

O cenrio inicia-se com um resumo de interao e durante o processo de

descoberta de requisitos (elicitao) novos detalhes so adicionados ao mesmo,

visando a criao de uma descrio completa da interao. Os cenrios podem ser

escritos de diferentes maneiras, mas devem incluir, pelo menos, as seguintes

informaes:

Uma descrio do que os usurios esperam quando o cenrio se inicia;

Uma descrio do fluxo normal de eventos no cenrio;

Uma descrio do que pode sair errado e como tratar este erro;

Informaes de outras atividades que podem estar acontecendo ao mesmo

tempo;

Uma descrio do estado do sistema, antes de iniciar o cenrio e aps seu

trmino.

100

Uma das tcnicas mais conhecidas que utiliza cenrios, o casos de uso

(PRESSMAN, 2005).

Casos de uso (use cases)

Casos de uso uma tcnica baseada em cenrios para obteno de requisitos e

que se tornou uma caracterstica fundamental da notao em UML, para descrever

modelos de sistemas orientados a objetos (KRUCHTEN, 2003).

Para criar um caso de uso, o analista deve primeiro identificar os diferentes tipos de

pessoas (ou dispositivos) envolvidos no sistema ou produto. Na verdade, esses

atores, representam papis que as pessoas (ou dispositivos) desempenham quando

o sistema opera.

Em essncia, um caso de uso conta uma histria sobre como um usurio final

(representando um dos diversos papis) interage com o sistema sob um conjunto

especfico de circunstncias. Esta histria pode ser um texto narrativo, um resumo

de tarefas ou interaes, uma descrio baseada em um modelo ou uma

representao grfica. Independente da forma, um caso de uso retrata um sistema

sob a tica do usurio.

A Figura II.11 abaixo representa um caso de uso, em que cada ator representado

por uma figura de traos e cada classe de interao definida por um nome na

elipse. Um conjunto de casos de uso representa todas as possveis interaes que

podem ser representadas nos requisitos de sistema.

Nome do caso de uso

Ator Dispositivo

Figura II.11 - Caso de uso Fonte: baseado em Leffingwell (2003)

A tcnica de cenrio e de casos de uso so efetivos para a elicitao de requisitos

sob o ponto de vista da interao, em que cada tipo de interao pode ser

representada como um caso de uso. Entretanto, em funo do foco recair sobre a

101

interao, esta tcnica no efetiva na descoberta de requisitos no funcionais e de

negcio do domnio da aplicao.

II.8.2 Entrevista

Entrevistas formais ou informais fazem parte da maioria dos processos de

engenharia de requisitos, em que so formuladas perguntas aos stakeholders sobre

o sistema que utilizam e o futuro sistema que ser desenvolvido. Os requisitos so

derivados das respostas a estas questes. H basicamente, segundo Kotonya e

Sommerville (1998), dois tipos de entrevista:

Entrevistas fechadas, nas quais os stakeholders respondem a um conjunto

pr-definido de perguntas;

Entrevistas abertas, em que no h agenda predefinida e discute-se, de modo

aberto, o que os stakeholders esperam do sistema.

Em geral, s a entrevista aberta no funciona adequadamente como tcnica de

requisitos, uma vez que a maioria das entrevistas necessita de algumas questes

para iniciar e mant-la centrada no sistema a ser desenvolvido.

De modo geral, um bom entrevistador deve possuir duas caractersticas:

Mente aberta para evitar ideias preconcebidas a respeito dos requisitos e

estar disposto a ouvir os stakeholders;

Dar ao entrevistado um ponto de partida para a entrevista, como por exemplo,

uma pergunta, uma proposta de requisito, um sistema existente ou uma

sugesto para um trabalho em conjunto em um prottipo. Em geral, os

entrevistados expressam-se melhor a respeito de um contexto definido do que

tema mais gerais.

II.8.3 Storyboarding/Tcnicas de Prototipao

Storyboarding

Storyboarding, basicamente, corresponde a qualquer tcnica que expressa o

comportamento do sistema, projeto ou inteno de implementao pela perspectiva

102

do usurio. No incio, foi usada no cinema e cartoons e representa um esboo das

personagens e da histria.

Esta tcnica permite acelerar de muitas maneiras o desenvolvimento conceitual de

um sistema. Storyboards podem ser empregadas para compreender a visualizao

dos dados e usabilidade, para definir e ajudar a compreender as regras de negcio

que sero implementadas, na definio de algoritmos, na demonstrao de

relatrios e outros tipos de sadas para uma reviso antecipada dos sistemas. Deste

modo, esta tcnica pode ser usada para virtualmente qualquer tipo de aplicao, na

qual a participao dos stakeholders seja um fator-chave.

Segundo Leffingwell e Widrig (2003), storyboards podem ser categorizadas em trs

tipos :

Passivo: so constitudos de quadros, fotos, esboos, etc. Neste caso so

apresentadas ao usurio as regras do sistema em sua sequncia, com uma

explanao do tipo Quando voc faz isto, acontece isto;

Ativo: corresponde a uma sequncia de figuras que mostram uma descrio

automatizada do modo como o sistema se comporta em um uso tpico ou em

um cenrio operacional, por exemplo, em uma apresentao automtica de

slides;

Interativo: permite ao usurio interagir com o sistema de um modo mais

realstico, exigindo sua participao. Pode ser uma simulao dos possveis

cenrios (prottipo no funcional), ou mesmo um prottipo funcional

simplificado do sistema.

Prototipao

No desenvolvimento de software, um prottipo corresponde a uma verso do

sistema que est disponvel logo nas primeiras fases de um processo de

desenvolvimento. A prototipao funcional, de acordo com Boar (1984), implementa

parte dos requisitos do sistema por meio da construo de um prottipo que executa

o comportamento real deste sistema (com a implementao de algoritmos e banco

de dados), podendo, inclusive, valer-se de ferramentas, especialmente, construdas

para a confeco desse tipo de prottipo (a prototipao funcional utilizada no ciclo

3 desta pesquisa).

103

Posteriormente, este prottipo descartado, passando-se para o efetivo

desenvolvimento do sistema pela sequncia tradicional (anlise, projeto,

implementao e testes), de posse de um conjunto de requisitos bem refinados.

Conforme apresentado no item II.6.3, neste trabalho empregado o termo de

prototipao incremental ou evolucionria, como sinnimo do desenvolvimento

incremental (o prottipo no descartado, mas evolui para atingir os requisitos dos

stakehoders).

J a prototipao no funcional (usada no ciclo 2 desta pesquisa) obtm o

comportamento dos stakeholders e do sistema por de interaes e iteraes com

estes, por meio de um conjunto de interfaces grficas simulando o comportamento

real do sistema (sem a implementao de algoritmos e banco de dados).

Uma tcnica de prototipao no funcional de fcil implementao e baixo custo a

prototipao em papel (RETTIG, 1994). A tcnica ( utilizada no ciclo1 desta

pesquisa) permite que os usurios executem atividades realsticas pela interao

com uma verso em papel da interface do software que manipulada por uma

pessoa que faz o papel de um computador e que no explica como a interface deve

funcionar, simulando as respostas do sistema.

Assim, escolhido um usurio representativo do perfil ou do grupo de trabalho do

processo de negcio que ser estudado. So definidas as atividades tpicas que

representam o que os usurios devem realizar e construdas as verses da interface

(esboos manuais ou impresses de telas), no sendo necessrio desenvolver uma

verso funcional destas interfaces.

Aps a criao do prottipo em papel, so realizados os testes. O usurio

colocado para fazer as interaes com o prottipo em papel, com um membro da

equipe de desenvolvedores atuando como computador. Por meio da figura de um

facilitador, o usurio instrudo a respeito das atividades a executar e suas reaes

e comentrios so anotados por uma ou mais pessoas da equipe de software.

Deste modo, possvel descobrir rapidamente quais partes da interface (e do

processo de negcio) funcionam bem ou no, podendo ser facilmente alteradas para

corrigir as deficincias apontadas pelos usurios (SNYDER, 2003).

104

O uso de storyboards interativos que, na realidade, so prottipos do sistema

(funcionais ou no) permite uma srie de vantagens (BOAR, 1984; LEFFINGWELL,

2003):

Reduo da distncia entre os participantes do projeto: a comunicao um

problema fundamental no desenvolvimento. Mesmo quando uma pessoa sabe

o que quer, sempre ocorrem mudanas quando estas necessidades

transformam-se em requisitos;

Aumento da participao e interesse dos atores: sistemas complexos que

envolvem vrias reas de uma empresa requerem um compromisso,

concordncia e consenso entre vrios atores para poderem operar

corretamente;

Sistemas por meio de exemplos: com o passar do tempo, pelo uso contnuo

desta tcnica, ser produzido uma srie de prottipos que podero ser

utilizados para demonstrar diferentes solues aos usurios, permitindo

estimular ideias, identificar estilos, mostrar o que possvel e permitir a

explicao de suas necessidades em termos de modificaes nos prottipos

existentes;

Permite medidas do tamanho das funcionalidades pela anlise de pontos de

funo: a partir da identificao das funes do tipo dado e das funes do

tipo transao e um esboo do modelo de dados do sistema possvel o

clculo dos pontos de funo, desde o incio do sistema e seu refinamento

durante os diversos ciclos de desenvolvimento (GAVA, 2004);

um veculo para a validao de requisitos;

Permite desde cedo o teste das interfaces.

Em termos de interface do usurio, segundo Pressman (2005), a prototipao o

nico modo prtico de se validar o que foi projetado.

Em um estudo de 39 projetos que utilizaram prototipao, Gorden e Bieman (1995)

citam os seguintes benefcios:

Reduo no esforo de desenvolvimento;

Um melhor atendimento das expectativas dos usurios;

Melhora na qualidade do projeto;

105

Melhora na usabilidade dos sistemas;

Melhora na facilidade de manuteno.

O uso de um prottipo aumenta o custo de um projeto em seus estgios iniciais de

desenvolvimento, mas o custo final do projeto pode no ser alterado, uma vez que,

com os requisitos melhores esclarecidos, os stakeholders demandam menos

modificaes no sistema.

A ergonomia e a concepo informtica na simulao e prototipao de

sistemas

Conforme refere Daniellou (2007), o paradoxo concepo (ver item I.1), quando se

olha a atividade futura, tratado na ergonomia de concepo como um meio de se

prever o espao das formas possveis desta atividade (margens de manobra),

avaliando em que medida as escolhas de concepo permitiro a implementao

dos modos operatrios compatveis com os critrios escolhidos (sade, eficcia

produtiva, desenvolvimento pessoal, trabalho coletivo, etc.)

Para agregar uma reflexo sobre a atividade futura preciso preparar as condies

de sua simulao, de modo que mesmo que no se possa observar a atividade

futura, devem ser procuradas as situaes existentes (situaes de referncia) cuja

anlise permitir esclarecer os objetivos e condies da futura atividade

(DANIELLOU, 2007).

No caso de uma modernizao, a anlise das situaes de referncia pode ser as

encontradas no comeo do projeto, tendo como objetivo na concepo de

programas de computador iterativos conhecer os objetivos do trabalho, os

procedimentos e identificar as informaes e dados tratados pelos usurios,

permitindo, tambm, identificar sua linguagem e sua terminologia. De acordo com

Bastien e Scapin (2007), no se trata de compreender o trabalho para reproduzi-lo,

de modo idntico, mas transform-lo, informatizando-o, de forma a otimiz-lo,

tornando-o menos custoso ao usurio.

Aps a avaliao das principais situaes de referncia, parte-se para determinar

quais as fontes de variabilidade observadas nestas situaes so capazes de

aparecer no futuro sistema, cuja formalizao da anlise passa por uma lista de

situaes de aes caractersticas futuras provveis (DANIELLOU, 2007).

106

Cada situao de ao caracterstica escolhida poder ser definida pelas atividade a

cumprir, pelos critrios de produo (qualidade, prazo, etc.), pelas categorias

profissionais envolvidas e pelos fatores capazes de influenciar o estado interno das

pessoas (por exemplo: trabalho noturno, exposio s intempries, etc.).

Para o autor citado, o uso das aes caractersticas provveis no futuro sistema

uma ferramenta essencial em ergonomia de concepo, na medida que permite

estabelecer uma ponte entre as atividades analisadas e a abordagem da atividade

futura (DANIELLOU, 2007).

Em especial, na concepo informtica, as ferramentas de prototipagem permitem

visualizar a aparncia e o funcionamento de sistemas a um baixo custo, em ciclos de

iterao rpida ao longo do processo, com a participao dos usurios antes das

etapas finais de concepo. Estes prottipos sucessivos do software oferecem uma

representao concreta para se comunicar com os usurios e os projetistas,

constituindo, tambm, um guia para a especificao de sucessivas verses

(BURKHARDT; SPERANDIO, 2007).

As solues de concepo podem assumir diversas formas, iniciando em prottipo

em papel, passando por etapas intermedirias como prottipos estticos ou

dinmicos at o produto final.

Para esta implementao, uma srie de condies devem ser estabelecidas

(DANIELLOU, 2007):

Condies de aceitabilidade social;

Escolha adequada dos participantes da simulao;

No uso de suportes materiais como prottipo, importante a participao dos

projetistas para comentar as informaes que nela figuram;

Desenvolver roteiros a partir das situaes de ao caractersticas provveis

previamente levantadas.

De acordo com Bastien e Scapin (2007), a concepo em geral ocorre em trs

etapas. Inicialmente, elaborado o modelo conceitual do programa, tratando-se de

um modelo de alto nvel do sistema, envolvendo basicamente as funcionalidades e a

arquitetura de dilogo, podendo tomar a forma de um croqui, ilustrando as principais

funcionalidades do sistema.

107

Na segunda etapa, o modelo conceitual detalhado e validado junto ao usurio,

tratando-se de prottipos detalhados, em que so realizadas as caixas de dilogos,

seus encadeamentos e a organizao dos menus.

Na terceira etapa, o sistema ser desenvolvido em detalhes, com base nos

desenvolvimentos anteriores, cujas interfaces com o usurio podero seguir guias

estilsticos.

A avaliao das solues propostas ir requerer a participao dos usurios (assim

como nas etapas anteriores), em que um ou mais usurios participam da execuo

das atividades representativas, podendo ser uma explorao livre das interfaces, por

meio das aes caractersticas.

Assim, as interfaces podem ser avaliadas em sistemas completamente

desenvolvidos ou nas etapas anteriores, para avaliar as escolhas de concepo

junto aos usurios.

Finalmente, a avaliao dever continuar em campo, pois podem ocorrer

dificuldades em condies de uso que no poderiam ter sido recriadas nos testes

realizados na fase de concepo (BASTIEN; SCAPIN, 2007).

II.8.4 Etnografia

Etnografia uma tcnica de observao que pode ser utilizada para compreender

requisitos sociais e organizacionais. Um analista fica imerso no ambiente de trabalho

no qual o sistema ser utilizado, observando o trabalho do dia a dia e tomando nota

das atividades nas quais os usurios esto envolvidos.

O valor desta tcnica corresponde em ajudar os analistas a descobrir requisitos

implcitos que refletem o processo real de trabalho, uma vez que os indivduos do

grupo desenvolvem melhorias em seu modo normal de trabalho, utilizando

ferramentas e documentos de um modo intuitivo, muitas vezes, sem perceber como

esto procedendo para tal.

Quando as atividades tornam-se rotineiras, as pessoas envolvidas com esse

trabalho podem passar a no ter conscincia de suas atividades, torna-se muito

difcil para elas articular o modo como o trabalho executado.

108

Esta tcnica , particularmente, importante em duas situaes (VILLER e

SOMMERVILLE, 2000; MARTIN e SOMMERVILLE, 2004):

Requisitos que so derivados do modo como os usurios realmente

trabalham (atividades) do que o trabalho prescrito;

Requisitos que so derivados da cooperao e conscincia das atividades de

outros usurios (awareness).

Os autores citados acima sugerem tambm que esta tcnica pode ser analisada a

partir de trs pontos de vista:

Ajuste do local de trabalho: descreve o contexto e a localizao fsica dos

objetos de trabalho e como os usurios utilizam-nos para executar suas

atividades;

Perspectivas sociais e organizacionais: mostram a experincia do dia a dia do

trabalho sob o ponto de vista de diferentes usurios (como o trabalho

realizado, como so tratadas as excees, etc.). Cada usurio v o trabalho

sob diferentes perspectivas, e este ponto de vista procura organizar e integrar

todos estas perspectivas;

Perspectiva do fluxo de trabalho: apresenta o trabalho com base em uma

srie de atividades, com as informaes fluindo de uma atividade para outra.

A etnografia pode ser combinada com a prototipao, de modo que, pelas suas

caractersticas, menos ciclos de prototipao sero necessrios.

Apesar de revelar detalhes crticos do processo que, normalmente, so perdidos

pelas outras tcnicas de descoberta de requisitos, pelo fato de se basear na viso

dos usurios finais, no apropriada para a descoberta de requisitos de domnio,

no permitindo identificar facilmente novas caractersticas que devem ser inseridas

no sistema.

Pela sua prpria natureza de aplicao, esta tcnica apresenta um tempo longo para

obteno de resultados, assim como alto custo.

Do mesmo modo que as demais tcnicas descritas, etnografia deve ser

complementada com outras tcnicas visando a obter os requisitos do sistema como

um todo.

109

II.8.5 Consideraes sobre tcnicas utilizadas na descoberta de requisitos

Conforme descrito no captulo IV, a parte prtica deste trabalho baseada em trs

ciclos de uma pesquisa-ao, de modo que em cada um destes ciclos so utilizadas

algumas das tcnicas descritas nesta seo.

No primeiro ciclo, so empregadas as tcnicas de entrevista, cenrio e de

prototipao em papel.

No segundo, utilizada a tcnica de prototipao no funcional descrita no item

II.8.3, obtendo-se o comportamento dos stakeholders e do sistema pelas interaes

e iteraes com estes, por meio do modelo de contexto, de processo e de fluxo de

trabalho, simulando o comportamento real do sistema (sem a implementao de

algoritmos e banco de dados), tendo como base o fluxograma do processo em

sesses de ACT (item IV.5).

No terceiro ciclo, empregada a tcnica de prototipao funcional evolutiva, em que,

uma vez implementada a primeira verso do software aps o trmino do ciclo 2, o

mesmo colocado em uso no ambiente real e, posteriormente, so realizadas novas

sesses de ACT para refinar esta verso funcional, conforme descrito com mais

detalhes no item IV.6.

110

III METODOLOGIA DE PESQUISA

Este captulo apresenta, fundamenta e detalha a metodologia de pesquisa utilizada,

baseada na adoo do mtodo de pesquisa-ao. Mostra, tambm, o delineamento

do projeto de pesquisa, considerando as decises estratgicas tomadas para seu

desenvolvimento, de modo a atender s questes endereadas em I.2.

III.1 INTRODUO

O papel da metodologia consiste em avaliar as condies de uso das tcnicas e

mtodos utilizados na pesquisa, orientando o investigador na estrutura de sua

pesquisa (Com que raciocnio trabalhar? Qual o papel das proposies? Como

chegar a uma certeza maior na elaborao dos resultados e interpretaes?)

(THIOLLENT, 2004).

Conforme citam Nakano e Fleury (1996), as abordagens de pesquisa orientadas

para a Engenharia de Produo so de cunho quantitativo quando se referem a

temas tcnicos das engenharias ou, de cunho qualitativo, quando o tema est

associado s cincias sociais.

Segundo Bryman (1989), a pesquisa qualitativa est na nfase dada ao objeto em

estudo, seja indivduo, organizao ou processo, sendo voltada mais compreenso

dos fatos e a pesquisa quantitativa impulsionada por um conjunto de questes

previamente definidas (extradas da teoria e literatura), sendo mais voltada

mensurao do fenmeno.

Nakano e Fleury (1996) realizaram um estudo a respeito dos principais mtodos de

pesquisa aplicados Engenharia de Produo, mostrando que apesar da aparente

simplicidade da classificao, nem sempre parece possvel uma distino to clara.

Na prtica da pesquisa, encontram-se diversas situaes em que h superposio

de conceitos. Os principais mtodos de pesquisa na Engenharia de Produo so

caracterizados nos dados do Quadro III.1, e os trs mtodos mais comuns de

pesquisa qualitativa so: o estudo de caso, a pesquisa-ao, e a pesquisa

participante.

111

Quadro III.1 - Principais mtodos de pesquisa em Engenharia de Produo

Mtodos de pesquisa

Descrio Abordagem principal

Instrumentos

Estudo de caso

Documenta e analisa a atividades de uma organizao ou de um pequeno grupo dentro dela. A unidade de anlise a organizao como um todo ou um departamento ou rea.

Qualitativa Entrevistas e outras fontes

Survey Coleta de dados por entrevista ou questionrio. A anlise dos dados exige tratamento estatstico.

Quantitativa Questionrios

Experimental Teste das hipteses de um experimento Controlado.

Quantitativa Experimentos

Pesquisa participante

Baseada em metodologia de observao participante.

Qualitativa Observao direta

Pesquisa-ao realizada juntamente com uma ao ou resoluo de um problema, onde os pesquisadores desempenham um papel ativo nessa resoluo.

Qualitativa Observao e participao direta

Fonte: Nakano e Flaury (1996)

III.2 ESTRATGIA METODOLGICA: PESQUISA-AO

III.2.1 Conceituao geral da pesquisa-ao

Para Yin (2003), um projeto de pesquisa a sequncia lgica que conecta os dados

empricos s questes de pesquisa iniciais do estudo e, em ltima anlise, suas

concluses. O autor relaciona cinco componentes do projeto de pesquisa:

A questo do estudo, ou seja, o ncleo da pesquisa. Envolve as perguntas

que devero ser respondidas depois de concludo o trabalho, em que surgiro

as concluses sobre a anlise realizada;

As proposies, que representam afirmaes tericas criadas inicialmente no

trabalho de pesquisa, a fim de agir como um guia na anlise do que est

sendo estudado;

As unidades de anlise devem guardar direta correlao com as perguntas

bsicas da pesquisa, j que so elas que indicam o objetivo do trabalho;

A lgica que une os dados s proposies. O autor sugere a estruturao dos

dados em um padro de adequao que facilite a anlise pontual e contribua

com a viso global do fenmeno;

112

Os critrios para se interpretar as descobertas. Segundo o autor no h

maneira adequada para o estabelecimento dos critrios para a interpretao

das descobertas, pois envolve a subjetividade para a anlise de cada caso.

Thiollent (2004) refere que a pesquisa participante e a pesquisa-ao so muito

semelhantes. Toda pesquisa-ao do tipo participativo, em que a participao das

pessoas implicadas nos problemas investigados absolutamente necessria. A

principal diferena entre ambas reside no fato de que a pesquisa participativa no

inclui necessariamente uma ao planejada.

Segundo o autor, pesquisa-ao corresponde a um tipo de pesquisa social com

base emprica que concebida e realizada em estreita associao com uma ao

ou com a resoluo de um problema coletivo e no qual os pesquisadores esto

envolvidos de modo cooperativo ou participativo. Deve seguir, pelo menos, quatro

grandes fases:

A fase exploratria: onde o pesquisador ou os pesquisadores investigam a

situao atual, detectam os principais problemas, atores e possveis aes de

melhoria;

A fase de pesquisa aprofundada: na qual a situao investigada com mais

detalhes por meio dos instrumentos de coleta de dados e de referncias

documentais e experincias similares;

A fase de ao: apresenta os resultados das pesquisas, define os objetivos

alcanveis e implementa as aes e/ou plano de aes apropriados;

A fase de avaliao: tem por objetivo observar, redirecionar o que realmente

acontece e resgatar o conhecimento produzido no decorrer do processo.

Esta diviso tem um propsito didtico para facilitar a compreenso das principais

atividades envolvidas neste tipo de pesquisa. Na prtica, as fases alternam-se e,

muitas vezes, so concorrentes e recorrentes, sobretudo as trs ltimas.

A caracterizao da pesquisa-ao complementada pelo mesmo autor, quando

afirma que esta envolve:

Ampla e explcita interao entre pesquisadores e pessoas implicadas na

situao investigada;

113

Ordenao de prioridade dos problemas a serem pesquisados e das solues

a serem encaminhadas sob forma de ao concreta;

A resoluo ou, pelo menos, esclarecimento dos problemas da situao

observada;

Um acoplamento das decises, das aes e de toda a atividade intencional

dos atores da situao;

Aumento do conhecimento dos pesquisadores e dos nveis de conscincia

das pessoas e grupos envolvidos.

Gummesson (2000) e Coughlan e Coghlan (2002) expandem este conceito

agregando uma srie de caractersticas que sero relacionadas com a presente

pesquisa em III.3:

O pesquisador executa uma ao (no mero observador);

A pesquisa-ao envolve dois objetivos: solucionar um problema e contribuir

para a cincia, nos quais alm do lado emprico, nunca deixa de colocar as

questes relativas aos quadros de referncia terica, sem os quais a

pesquisa emprica no faria sentido;

A pesquisa-ao interativa. H uma ampla e explcita interao entre

pesquisador e pessoas implicadas na situao investigada;

Desta interao, resulta a ordem da prioridade dos problemas a serem

pesquisados e das solues a serem encaminhadas sob forma de ao

concreta;

A pesquisa-ao objetiva desenvolver um entendimento completo do

problema. O pesquisador deve alternar entre o perfil formal tcnico e o perfil

informal, focado nas relaes interpessoais;

O planejamento de uma pesquisa-ao muito flexvel, sendo diferente de

outros tipos de pesquisa, pois no composto de uma srie de fases

rigidamente ordenadas e limitadas aos aspectos acadmicos e burocrticos

da maioria das pesquisas convencionais. Na pesquisa-ao, o planejamento

das aes realizado pelos atores sociais, podendo ser o pesquisador um

animador ou um participante ativo;

114

fundamentalmente relacionada mudana, aplicvel na compreenso,

planejamento e implementao de mudanas em empresas de negcios e

outras organizaes;

A pesquisa-ao pode incluir todos os tipos de coleta de dados (tcnicas

quantitativas e qualitativas);

Requer um pr-entendimento do ambiente organizacional, das condies da

estrutura e dinmica das operaes, das condies de negcio, dos

processos produtivos, do ambiente de trabalho, entre outros;

Deve ser conduzida em tempo real, embora em pesquisa-ao retrospectiva

tambm seja aceitvel. Deve ser um estudo de caso ao vivo escrito,

conforme se desenrola;

Seu paradigma exige critrios de qualidade especficos. Pesquisa-ao no

deve ser avaliada pelos critrios positivistas (como no caso de simulaes

matemticas, pesquisas experimentais, surveys, etc.);

Exige uma compreenso dos princpios ticos da organizao pesquisada. O

pesquisador deve compreender e respeitar valores e normas da organizao

envolvida na pesquisa.

Estas caractersticas devem ser consideradas desde o momento da concepo da

pesquisa, de modo que a pesquisa-ao compreenda trs fases principais: uma

preliminar, um ciclo de conduo e uma metafase (COUGHLAN; COGHLAN, 2002).

III.2.2 Ciclos da pesquisa-ao

Como pode ser visto na Figura III.1, o ciclo de conduo da pesquisa compreende a

seis passos principais, e a metafase est presente em cada um destes seis passos.

Durante a apresentao dos resultados, cada um dos passos ser contextualizado

dentro das respectivas fases.

A primeira fase (fase preliminar) corresponde a um entendimento sobre o contexto

no qual a pesquisa ser realizada, bem como o propsito da conduo do trabalho.

Essa fase envolve ainda o estabelecimento das justificativas para a ao requerida,

alm das justificativas para a pesquisa.

115

A segunda fase composta por seis passos e inicia-se com a coleta de dados

(diagnstico e/ou dados coletados quando a pesquisa encontra-se em regime),

feedback dos dados (para os envolvidos com a pesquisa), anlise desses dados

(com os envolvidos na pesquisa), planejamento da ao (definio da interveno a

ser feita), implementao da ao (colocar em prtica o que foi planejado) e

avaliao (verificar se os resultados da implementao surtiram ou no os efeitos

desejados), retornando para uma nova coleta de dados (se necessrio), encerrando

o ciclo (primeira iterao).

Monitoramento

Planejamento

da ao

Implementao

Avaliao

Coleta de

dados

Feedback

dos dados

Anlise dos

dados

Contexto e Propsito

Primeira fase: fase Preliminar

Segunda fase: ciclo de conduo

Terceira fase: monitoramento

Figura III.1 - Ciclos da Pesquisa-ao Fonte: baseado em Coughlan e Coghlan (2002)

O dados do Quadro III.2 mostram os principais meios utilizados para a execuo de

cada um destes ciclos, assim como uma breve descrio dos mesmos.

Os ciclos so constantes e sequenciais, sendo contnuos pelo perodo em que forem

necessrios, com a possibilidade da existncia de um ciclo mais abrangente (para a

pesquisa como um todo) e ciclos menores para as partes especficas do trabalho.

A terceira fase (monitoramento) compreende uma verificao de cada um dos seis

passos anteriores, de modo a verificar qual o aprendizado gerado na conduo da

pesquisa-ao, sendo seu monitoramento executado de diferentes modos, medida

que a pesquisa avana por meio dos passos da segunda fase.

Assim, do lado organizacional, pode ocorrer a criao de um grupo diretivo durante a

execuo da pesquisa-ao, com maior interesse em seus resultados prticos.

116

Quadro III.2 - Sntese dos passos e aes utilizadas

Passo Descrio Meios

Coleta de dados Dados so gerados por meio do envolvimento com o processo organizacional

Dados qualitativos: observao direta, discusses, entrevistas Dados quantitativos: relatrios, registros operacionais

Feedback dos dados Os dados so retornados para a organizao visando a disponibiliz-los para anlise

Relatrios elaborados pelo pesquisador, reunies de feedback

Anlise dos dados Anlise conjunta realizada pelo pesquisador e membros envolvidos (por exemplo, membros dos times de trabalho)

Ferramentas e critrios de anlise que necessitam estar relacionados aos propsitos da pesquisa e da interveno

Planejamento da ao

Atividade conjunta que estabelece o que vai ser feito e com que prazo

Responder questes do tipo: o que necessita ser alterado e em que parte da organizao? Qual o apoio necessrio? Como o comprometimento pode ser obtido? Como superar as resistncias?

Implementao da ao

A ao estabelecida ento implementada visando a promover as mudanas planejadas

Ferramentas estabelecidas para executar a implantao em colaborao com os envolvidos

Avaliao Reflexo dos resultados esperados ou no decorrentes da implementao da ao

Reviso do processo visando a avaliar os resultados, incluindo melhorias para o ciclo seguinte

Fonte: Miguel (2005)

Pelo lado do pesquisador, o mesmo deve estar interessado no somente na

operao do projeto, mas tambm no monitoramento do processo de aprendizagem,

que levar contribuio terica deste tipo de desenvolvimento emprico

(COUGHLAN; COGHLAN, 2002; MIGUEL, 2005).

III.3 CARACTERIZAO DA CONDUO DA PESQUISA-AO

Esta pesquisa pretende oferecer uma contribuio de cunho emprico, associada

contribuio terica no sentido da gerao de conhecimento dentro do domnio do

problema estudado.

Para elaborar o plano de pesquisa para este trabalho, primeiramente, foi necessrio

definir qual mtodo de pesquisa seria aplicado. Para isso, algumas caractersticas

do contexto da pesquisa foram consideradas, na qual em III.2.1 foram detalhadas as

principais caractersticas que uma pesquisa-ao deve conter, conforme Coughlan e

117

Coghlan (2002) e Gummesson (2000). A seguir, apresenta-se um paralelo entre

essas caractersticas e a presente pesquisa:

O pesquisador executa uma ao: pois o principal responsvel pela

conduo do projeto na empresa, com participao ativa nos processos de

conduo do mapeamento, definio e estabelecimento do sistema

informatizado utilizado nesta pesquisa;

A pesquisa-ao soluciona um problema e contribui para a cincia: o trabalho

envolve a soluo de um problema de ordem prtica que corresponde ao

desenvolvimento de um software para dar suporte ao processo de

atendimento dos servios correntes da empresa PesqTec. Paralelamente, sua

contribuio cientfica est ligada ao processo para especificao dos

requisitos de software com foco de aplicao no trabalho cooperativo em

sistemas de informao que apresentam coordenao distribuda nas aes

dos usurios, e a comunicao entre eles ocorre preponderantemente de

modo indireto por meio dos dados inseridos durante o uso do software;

A pesquisa-ao interativa e iterativa: a pesquisa desenvolvida interativa

pelo lado dos grupos de trabalho, bem como iterativa pelo lado da evoluo

do sistema implantado. Pelo lado dos grupos de trabalho, a pesquisa

desenvolvida obteve a contribuio e interao dos profissionais das reas da

organizao diretamente envolvidas no processo de desenvolvimento e

manuteno de sistemas. Assim como de diversos grupos de stakeholders

compondo grupos multidisciplinares de trabalho, por meio de aes

planejadas. Houve a utilizao do saber dos pesquisadores e especialistas e

das experincias concretas dos participantes, para soluo do problema,

assim como para captao dos dados compilados para a pesquisa. Pelo lado

da implantao do sistema, o uso da tcnica de prototipao em todas suas

fases tornou a participao dos todos os envolvidos do sistema tambm

iterativa;

Tem o objetivo de desenvolver um entendimento completo do problema: Em

termos empricos, este aspecto foi inerente prpria natureza do trabalho,

que correspondeu informatizao de um dos principais processos de

negcio da empresa (ressalta-se o papel do trabalho cooperativo nesta

118

situao), tornando-se necessria a devida compreenso do modo como este

processo estava ligado aos demais, pelas suas interfaces, assim como a

compreenso de outros processos de negcio da empresa. Proporcionou,

tambm, sob o ponto de vista terico, um estudo amplo da literatura, que

somente foi possvel pela conduo desta pesquisa-ao. O entendimento

completo do problema envolveu a compreenso do contexto no qual a

pesquisa foi conduzida e a ligao entre terico e emprico;

fundamentalmente relacionada mudana: a pesquisa foi motivada

diretamente pela necessidade da organizao PesqTec automatizar a forma

de atendimento aos clientes em servios correntes da empresa, passando de

um atendimento manual e desnormalizado (cada rea com seu processo de

atendimento), para um nico processo da empresa; desta forma, ampliando a

preocupao com melhoria de processos e produtos;

A pesquisa-ao pode incluir todos os tipos de coleta de dados: foram

adotadas, tanto tcnicas qualitativas como tcnicas quantitativas para coleta e

anlise dos dados. Os mtodos de coleta de dados usados foram efetuados

por meio de e-mails, investigao de documentos, observaes, dados de

palestras, questionrios, entrevistas e reunies com analistas, tcnicos,

especialistas, gerentes pesquisadores, usurios finais, tcnicos e chefes de

laboratrio. Tambm foram realizadas apresentaes internas para os

envolvidos diretamente com a pesquisa e s gerncias e direo da empresa.

Fez-se uso de gravaes de udio das sesses de anlise coletiva do

trabalho, assim como gravaes em vdeo de algumas dessas sesses e de

registros escritos do andamento do projeto;

Requer um pr-entendimento do ambiente organizacional: Durante a fase

preliminar para a conduo da pesquisa-ao, foram levantados os detalhes

do ambiente, nos quais o processo proposto nesta pesquisa seria aplicado,

com o delineamento do processo atual de atendimento aos servios

correntes, alm de um estudo sob o contexto organizacional da empresa. A

experincia do pesquisador em outros projetos equivalentes, tambm,

apresentou-se como um fator diferenciador na conduo da pesquisa-ao;

119

Deve ser conduzida em tempo real: a pesquisa-ao deste trabalho iniciou-se

em fevereiro de 2006 e seu trmino em janeiro de 2008, havendo o cuidado

de capturar os dados e eventos relevantes para a redao deste trabalho;

Requer critrios prprios de qualidade para sua avaliao. Foram

desenvolvidos critrios especficos para avaliao desta pesquisa (sobretudo

no que se refere medio da intensidade do trabalho cooperativo

apresentado pelos usurios com o uso do sistema), embora se tenha

consultado a literatura como referncia. Utilizou-se de apresentaes para a

direo geral da empresa, para o departamento da qualidade e demais partes

interessadas na avaliao do andamento do trabalho, alm de apresentaes

no meio acadmico de trs artigos nacionais: Gava et al. (2004), Gava et al.

(2007) e Gonalves et al. (2005) e dois internacionais: Gava et al. (2008) e

Gonalves et al. (2008).

Exige uma compreenso dos princpios ticos da organizao pesquisada. O

pesquisador, na posio de colaborador da empresa PesqTec, teve e tem a

preocupao e obrigao de respeitar as exigncias de tica e

confidencialidade da instituio e dos participantes das sesses de ACT no

que concerne aos resultados desta pesquisa.

Assim, pelo que foi exposto neste item, conclui-se que as caractersticas desejveis

para a conduo da pesquisa-ao foram estabelecidas nesta pesquisa.

III.4 DELINEAMENTO DO PROJETO DE PESQUISA

Visando a atender s questes e objetivos colocados em I.2, esta pesquisa utiliza o

mtodo de pesquisa-ao (ver item III.2.2) por meio dos ciclos de conduo (Figura

III.2) e do processo proposto (ver captulo IV) , com o seguinte planejamento:

1. Reviso bibliogrfica metodolgica e aplicada (referente aos conceitos de

trabalho cooperativo, Engenharia de Requisitos e temas relacionados);

2. Contexto e propsitos: elaborao do contexto especfico da PA;

120

3. Conduo do primeiro ciclo da pesquisa-ao: processo para especificao

de requisitos de software com foco na identificao das caractersticas

individuais do trabalho cooperativo e das caractersticas de domnio;

4. Conduo do segundo ciclo da pesquisa-ao: processo para especificao

de requisitos de software com foco na identificao e simulao das

caractersticas cooperativas do trabalho;

5. Conduo do terceiro ciclo da pesquisa-ao: processo para especificao de

requisitos de software com foco no refinamento das caractersticas do

trabalho cooperativo (em uso real);

6. Elaborao da tese com os resultados da pesquisa.

Monitoramento

Planejamento

da ao

Implementao

Avaliao

Coleta de

dados

Feedback

dos dados

Anlise dos

dados

Monitoramento

Planejamento

da ao

Implementao

Avaliao

Coleta de

dados

Feedback

dos dados

Anlise dos

dados

Ciclo 1 Ciclo 2

Figura III.2 - Iterao dos ciclos da Pesquisa-ao

Thiollent (2004) destaca que importante j no incio da pesquisa (fase

exploratria), identificar os principais atores envolvidos na pesquisa. Para este

projeto, os atores so:

Autor: responsvel pelo levantamento de requisitos e implementao do

software responsvel pela informatizao do sistema de informao, alvo

desta pesquisa;

Analistas de negcio: tcnicos das reas usurias do futuro software com

profundo conhecimento das regras de negcio a serem informatizadas e

envolvidos na contextualizao do projeto dentro da estratgia da

organizao e na apresentao dos principais direcionadores do trabalho em

um nvel macro durante o desenvolvimento do primeiro ciclo de conduo (ver

item V.2) ;

121

Diretoria executiva: patrocinadora do projeto, auxiliando com os custos, apoio

gerencial e oferecendo seu conhecimento e experincia sobre o assunto e

cultura da corporao (ver item V.1);

Equipe de supervisores de laboratrio: responsveis por apresentar detalhes

operacionais do SI e da futura soluo informatizada, durante o

desenvolvimento do segundo ciclo de conduo (ver captulo VI);

Usurios dos laboratrios: responsveis por apresentar detalhes operacionais

da soluo informatizada em condies reais (supervisores dos laboratrios,

tcnicos, secretrias e gerentes de centro de custo), durante o

desenvolvimento do terceiro ciclo de conduo (ver captulo VII);

Usurios gerenciais: responsveis por apresentar detalhes gerenciais do

sistema (responsveis pela rea de qualidade, assessores da diretoria

executiva, etc.) durante o desenvolvimento do segundo ciclo de conduo

(ver captulo VI).

No dados do Quadro III.3 abaixo encontra-se o delineamento geral da pesquisa.

Quadro III.3 - Delineamento da pesquisa

Aspecto analisado Conceitos e prticas / categorizao

Abordagem metodolgica Pesquisa-ao em trs ciclos (planejado)

Propsitos Definio de um processo para obteno dos requisitos de software orientado ao trabalho cooperativo em SI com coordenao distribuda

Objeto de anlise Empresa nacional de tecnologia

Unidade de anlise Processo de atendimento de servios correntes enfoque no trabalho cooperativo

Referencial terico para o processo de identificao das caractersticas individuais do trabalho cooperativo

Tcnicas de entrevista, prototipao em papel, tcnicas da Engenharia de Requisitos.

Referencial terico sobre a simulao e identificao das caractersticas cooperativas do trabalho

Tcnicas de entrevista, tcnicas da Engenharia de Requisitos, anlise coletiva do trabalho

Referencial terico sobre o refinamento da identificao das caractersticas do trabalho cooperativo

Tcnicas de entrevista, tcnicas de usabilidade, anlise coletiva do trabalho, teoria da mente coletiva e awareness.

Tipologia dos dados Basicamente qualitativos

Coleta dos dados Investigao documental, e-mails, observaes, dados de palestras, questionrios, entrevistas e reunies com analistas, tcnicos, especialistas, gerentes pesquisadores, usurios finais, tcnicos e chefes de laboratrio e anotaes em caderno de pesquisa e gravaes de udio.

122

Aspecto analisado Conceitos e prticas / categorizao

Anlise dos dados Interpretao de dados qualitativos, critrios prprios para avaliao de dados de questionrios (definido na parte prtica terceiro ciclo) e critrios para avaliao das sesses de ACT em funo do ciclo da pesquisa-ao.

Qualidade e validade da pesquisa

Apresentaes internas aos grupos de interessados (stakeholders), externas (pblicas) em seminrios e congressos e diferenciao entre a pesquisa-ao e um projeto de consultoria

Fonte: elaborado pelo autor

Em termos do planejamento para a conduo da pesquisa em campo, os ciclos

descritos por Coughlan e Coghlan (2002) sero implementados como uma

adaptao do modelo espiral (Figura III.3).

Figura III.3 - Espiral dos ciclos da Pesquisa-ao Fonte: elaborado pelo autor

O detalhamento dos ciclos da PA em funo do processo proposto est mais bem

explorado no item IV.7, Quadro IV.8 (quadro metodolgico).

Apresentadas as fases, os atores e o enquadramento do ciclo padro da PA com a

realidade que ser executada em campo, possvel detalhar melhor cada etapa do

plano:

123

III.4.1 Reviso bibliogrfica metodolgica e aplicada

Levantamento e reviso de livros, artigos e demais documentos sobre metodologias

de pesquisa, aspectos do trabalho coletivo, em particular, o trabalho cooperativo,

engenharia de software dentro da subrea denominada Engenharia de Requisitos e

a relao entre as caractersticas do trabalho cooperativo de sistemas de informao

e sua informatizao por meio de softwares transacionais pelo uso dos conceitos de

anlise coletiva do trabalho, da teoria da mente coletiva, modelos 3Cs e percepo.

III.4.2 Contexto e propsitos

Visando a um melhor entendimento do contexto empresarial no qual est inserida a

pesquisa-ao aplicada neste trabalho, feita uma breve descrio da empresa e do

sistema de informao tratado na pesquisa-ao. Posteriormente, no

desenvolvimento efetivo do trabalho que se d com a parte da pesquisa de campo,

as informaes deste item so mais bem detalhadas no captulo V.1.1 deste

trabalho.

A empresa onde aplicada a teoria desenvolvida nesta pesquisa, corresponde a

uma grande empresa nacional que desenvolve tecnologia, possuindo em torno de

1.500 colaboradores.

Vrios tipos de atendimento ao pblico so prestados, desde servios tecnolgicos

especializados (sob medida para um dado problema), at servios correntes (que

so considerados rotineiros dentro dos laboratrios).

O atendimento a uma solicitao de servios correntes pode ser realizado por meio

de um nico laboratrio; neste caso, sendo constitudo por um ou mais servios

oferecidos por este laboratrio, ou ento, por uma solicitao constituda por

servios envolvendo o trabalho cooperativo de mltiplos laboratrios da empresa

PesqTec.

O processo de atendimento realizado de modo independente por cada um destes

laboratrios, sem padronizao e sem conexo com o software corporativo (ERP)

desta empresa. Em muitos deles feito por meio de arquivos em papel, tornado o

processo fragmentado e de difcil controle, implicando uma subutilizao dos

124

recursos laboratoriais (humanos e materiais), alm de tornar as informaes ligadas

a este processo de difcil recuperao e consequente agregao.

Deste modo, face realidade apresentada, a diretoria da empresa em questo

aprovou o desenvolvimento de um software para dar suporte a este sistema de

informao, com o seguinte objetivo: uniformizar os mtodos de acompanhamento e

gerenciamento dos servios laboratoriais em toda a empresa, dando

homogeneidade e maior eficincia ao desenvolvimento e acompanhamento de

servios tcnicos correntes, desde o momento da solicitao de um servio, at seu

faturamento.

III.4.3 Conduo do primeiro ciclo da pesquisa-ao: processo para

especificao de requisitos de software com foco na identificao das

caractersticas individuais do trabalho cooperativo e das caractersticas

de domnio

Neste ciclo aplicada a primeira parte do macroprocesso proposto que corresponde

ao processo para identificao das caractersticas individuais do trabalho

cooperativo, tendo como principal objetivo a coleta e a definio dos requisitos

individuais dos usurios e dos requisitos de domnio para confeco do prottipo

descartvel (papel) do sistema.

Para este ciclo, procura-se responder seguinte questo de pesquisa:

Como, pelas contribuies individuais dos stakeholders, estabelecer os

principais artefatos necessrios para a simulao do trabalho cooperativo por

meio software que ser implementado (ciclo 2)?

O planejamento da conduo deste ciclo da pesquisa-ao em funo do processo

proposto descrito no item IV.4. Sugere-se a leitura do captulo IV para melhor

entendimento deste planejamento.

125

III.4.4 Conduo do segundo ciclo da pesquisa-ao: processo para

especificao de requisitos de software com foco na identificao e

simulao das caractersticas cooperativas do trabalho

Neste ciclo, aplicada a segunda parte do macroprocesso proposto no captulo IV e

correspondente ao processo para a simulao e identificao das caractersticas

cooperativas do trabalho, tendo como principal propsito a obteno das

caractersticas do trabalho cooperativo pela utilizao da tcnica de Anlise Coletiva

do Trabalho, modelo mental e interao e modelos e processos de software,

ancorados pelos artefatos gerados no primeiro ciclo, obtendo-se, assim, o prottipo

no funcional do sistema.

Para este ciclo, procura-se responder s seguintes questes de pesquisa:

Quais so os instrumentos a serem elaborados para captar os requisitos de

software da dimenso cooperativa do trabalho de um SI durante a simulao

do sistema informatizado que lhe dar suporte?

Como estes instrumentos podem ser concatenados para captar os requisitos

de software do trabalho cooperativo durante a simulao do sistema

informatizado?

A soluo proposta neste ciclo pode ser aplicada para refinar os requisitos de

software do trabalho cooperativo durante o uso do sistema informatizado

(ciclo 3)?

O planejamento da conduo deste ciclo da pesquisa-ao em funo do processo

proposto descrito no item IV.5. Sugere-se a leitura do captulo IV para melhor

entendimento deste planejamento.

III.4.5 Conduo do terceiro ciclo da pesquisa-ao: Processo para

especificao de requisitos de software com foco no refinamento das

caractersticas do trabalho cooperativo (em uso real);

Neste ciclo, aplicada a terceira parte do macroprocesso proposto que corresponde

ao processo para o refinamento da identificao das caractersticas do trabalho

cooperativo, cuja implementao real do sistema (prottipo funcional usado em

126

campo pelos usurios) utilizada para ancorar as sesses de Anlise Coletiva do

Trabalho, orientadas ainda pelos conceitos da teoria da mente coletiva e de

awareness para o refinamento da definio das caractersticas do trabalho

cooperativo.

Para este ciclo, procura-se responder s seguintes questes de pesquisa:

Quais so os instrumentos a serem elaborados para refinar os requisitos de

software da dimenso cooperativa do trabalho de um SI durante o uso do

sistema informatizado que lhe dar suporte?

Como estes instrumentos podem ser concatenados para refinar os requisitos

de software do trabalho cooperativo durante o uso do sistema informatizado?

Como avaliar a evoluo da identificao dos requisitos de software do

trabalho cooperativo obtidos neste ciclo pela aplicao da soluo proposta?

O processo proposto no ciclo 2 pode ser aplicado para refinar os requisitos do

trabalho cooperativo de um SI neste ciclo?

O planejamento da conduo deste ciclo da pesquisa-ao em funo do processo

proposto descrito no item IV.6. Sugere-se a leitura do captulo IV para melhor

entendimento deste planejamento.

III.4.6 Elaborao da tese com os resultados da pesquisa

Apesar dos dados e eventos relevantes levantados e experimentados ao longo do

projeto serem devidamente documentados, a elaborao da tese, como um

documento acadmico e como um relato do projeto de pesquisa, feita depois da

aplicao em campo do processo proposto pela conduo dos ciclos da pesquisa-

ao aqui relatados neste planejamento.

127

IV PROCESSO PROPOSTO

Neste captulo, descreve-se como o processo proposto nesta pesquisa foi aplicado.

Assim, o processo inicia-se com a identificao dos requisitos de domnio dos

stakeholders, das atividades dos usurios, assim como a definio dos principais

processos de negcio que sero automatizados.

Estes elementos so fornecidos para os usurios na forma de um conjunto de

artefatos para definio da usabilidade; concomitantemente com as funcionalidades

do sistema, tanto as referentes ao trabalho individual, como aquelas do trabalho

cooperativo por intermdio de um processo de prototipao incremental, passando

dos modelos em papel, ao modelo no funcional e, finalmente, prototipao

funcional.

Em todas estas etapas, o enfoque no trabalho cooperativo dado gradualmente, na

medida que estas caractersticas forem se aflorando, durante a aplicao do

processo proposto.

IV.1 CONTEXTO

Mtodos convencionais da descoberta de requisitos assumem que o usurio saiba

exatamente o que deseja do futuro sistema e conhea o sistema, de forma que, uma

vez implementado, absorva os impactos sobre a forma de trabalho. Estes mtodos

concentram-se nas funcionalidades do sistema em razo de considerar o contexto

em que operam.

Na realidade, qualquer sistema que envolve interveno humana tem caractersticas

de ser voltil, no previsvel e complexo. Impor hierarquia e rigor matemtico, para

reduzir esta complexidade pode distorcer o entendimento. Os elementos no

estruturados do sistema sociotcnico podem ser deixados de lado.

O esforo de representao dos requisitos, tambm, deve ser orientado no registro

de demanda de negcio e na identificao das regras do negcio. (KOTONYA;

SOMMERVILLE, 1998).

Pela prpria natureza dos requisitos e os relacionamentos entre eles, embora

tenham disponveis as mais variadas tcnicas, a gerao do documento de

128

requisitos poder conter informaes que reflitam conflitos, omisses,

inconsistncias e desatualizao dos mesmos.

Os sistemas informatizados no existem isoladamente, pois so usados no contexto

social e organizacional da empresa, e os requisitos do sistema so derivados e

sofrem restries oriundas desse ambiente. A necessidade de atender s carncias

impostas pelo contexto social e organizacional, frequentemente, crtica para o

sucesso dos sistemas de informao e, muitas vezes, motivo para que estes

sistemas no sejam utilizados aps sua implantao.

O problema da elicitao (descoberta dos requisitos do sistema e compreenso das

necessidades dos usurios) de requisitos no pode ser resolvido com uma

abordagem puramente tecnolgica, porque nesta fase o contexto social mais

crucial do que na fase de projeto e codificao. Outro aspecto que os stakeholders

sentem dificuldade de articular detalhes de seu trabalho, em razo da segunda

natureza que o mesmo representa. Eles podem compreender seu prprio trabalho,

mas podem no compreender bem sua relao com outros trabalhos da organizao

e, tambm, com outros participantes de seu grupo de trabalho (SOMMERVILLE,

2007).

A este fato, junta-se tambm que tambm na fase de teste/manuteno de sistemas

informatizados, aspectos ligados funcionalidade/usabilidade acabam sendo obtidos

por meio de tcnicas que envolvem os usurios de modo independente, sem levar

em conta suas funes e usos cooperativos.

Assim, de modo a tratar as questes acima descritas, e o paradoxo da concepo

descrito nos itens I.1e III.4.1, necessrio estabelecer um processo que trate a

questo, levando em conta sobretudo o fato de que as pessoas trabalham

cooperativamente para atender a uma srie de objetivos.

O processo proposto pode, ento, ser aplicado, tanto na concepo de novos

sistemas informatizados como na melhoria de sistemas j desenvolvidos. Estas

situaes sero exploradas nos prximos itens.

129

IV.2 DESCRIO GERAL DO PROCESSO

No desenvolvimento de software, assim como em outras reas, existem vrias

metodologias/tecnologias para se criar um produto.

Neste trabalho de pesquisa, o processo adotado segue o modelo espiral, conforme

descrito no item II.6.3, no qual, em vez de uma seqncia linear de atividades, o

modelo representado como uma espiral em que cada volta representa uma fase do

processo: a volta mais interna relaciona-se viabilidade do sistema; a volta

seguinte, definio dos requisitos; a prxima volta, ao projeto e, assim, por diante.

Por outro lado, visando a atender aos sistemas complexos, grandes, de longa

durao e/ou desenvolvidos por equipes diferentes, adotou-se uma soluo mista

que contempla o uso da prototipao evolutiva (ver item II.6.3) para definio dos

requisitos em sistemas sociotcnicos que estejam mal compreendidos, e do modelo

em cascata (item II.6.2) para implementao das alteraes no processo de

prototipao funcional (item II.8.3).

Na Figura IV.1, o diagrama simplificado do processo proposto nesta pesquisa pode

ser visto. A parte em destaque corresponde ao recorte que se pretende dar dentro

do processo de desenvolvimento dos sistemas de informao da engenharia de

software: a subrea que trata da engenharia de requisitos (item II.7).

Dentro deste recorte, os processos de anlise de viabilidade e aplicabilidade so

considerados para identificao das caractersticas individuais do trabalho

cooperativo, para identificao e simulao das caractersticas cooperativas do

trabalho e, finalmente, para refinamento da identificao das caractersticas do

trabalho cooperativo (que corresponde na realidade verso funcional do sistema).

Para identificao das caractersticas individuais do trabalho cooperativo (itens II.8.3

e IV.4) primeiro preciso a anlise da viabilidade do projeto, assim como a

verificao se o sistema um bom candidato para a aplicao do processo

proposto, ou seja, deve ser feito um recorte para verificar a aplicabilidade do

processo (descrita com mais detalhes em IV.3).

130

1. Anlise de

Viabilidade

2.Processo

aplicvel?

3. Identificao dos

requisitos individuais do

trabalho cooperativo

5.Refinamento dos

requisitos do trabalho

cooperativo (prottipo

funcional)

6. Outros tipos de

especificao/ projeto/

implemento

7. Vida til do projeto/

Manuteno

8. Mudanas

significativas

4. Identificao e

simulao dos requisitos

do trabalho cooperativo

(prottipo no funcional)

No

Sim

Sim

No2. Estudo de

aplicabilidade do

processo

Contexto e propsitos

Ciclo 1

Ciclo 2

Ciclo 3

Figura IV.1 - Macroprocesso para a identificao das caractersticas do trabalho cooperativo Fonte: elaborado pelo autor

Os artefatos desenvolvidos no processo para identificao das caractersticas

individuais do trabalho cooperativo (item IV.4) sero o ponto de partida para o

estudo das caractersticas do trabalho cooperativo em sistemas de informao (item

IV.5). Uma vez obtidos os requisitos necessrios, parte-se para a implementao do

sistema (prottipo funcional), onde, a partir do mesmo sero complementados os

requisitos cooperativos do sistema, sobretudo com foco nos conceitos de awareness

e mente coletiva (item IV.6).

131

Na Figura IV.2, podem ser vistos os aspectos tericos envolvidos no processo como

um todo.

PROCESSO PROPOSTO (teoria):

Anlise coletiva do trabalho

Mente coletiva

Modelo 3Cs e awareness

Tcnicas de prototipao evolucionria

Modelo mental e interao

Modelos e processos de software

Tcnicas de descoberta de requisitos

Engenharia de Requisitos

TESTE

Proposies

Feedback dos

dados

Experincia, formao,

insights Premissas

Dados de campo

Referncias

Conscincia sobre a contextualizao das atividades individuais por meio da compreenso das atividades

realizadas por outros usurios, diagramas de fluxo, interfaces grficas, funcionalidades, restries, dados do

domnio, aes e respostas, etc.

Figura IV.2 - Modelo da teoria proposta Fonte: elaborado pelo autor

Os prximos itens descrevem o processo proposto neste trabalho, que procura

mostrar como os conceitos apresentados no captulo II podem ser logicamente

encadeados para responder principal questo da pesquisa: como considerar na

especificao dos requisitos de software, a dimenso cooperativa do trabalho em

sistemas de informao?

IV.3 ANLISE DE VIABILIDADE E DA APLICALIBIDADE DO PROCESSO

Na Figura IV.4 abaixo, o diagrama do processo para identificao das caractersticas

individuais do trabalho cooperativo pode ser visto. Para cada passo desta figura,

ser feita uma descrio, um critrio de sada e os artefatos produzidos.

132

2. Estudo da

aplicabilidade do

processo

2.Processo

aplicvel?

6. Outros tipos de

especificao

No

1. Anlise de

Viabilidade

3. Prxima fase: identificao dos requisitos

individuais do trabalho cooperativo

(artefatos produzidos)

Contexto e propsitos

7. Vida til do projeto/

Manuteno

8. Mudanas

significativas

No

Ciclo3:refinamento dos

requisitos do trabalho

cooperativo

Sim

Sim

Figura IV.3 - Processo para anlise de viabilidade e aplicabilidade Fonte: elaborado pelo autor

IV.3.1 Anlise de viabilidade

Este passo permite verificar se de fato o sistema deve ser desenvolvido. A entrada

do processo corresponde a um resumo da descrio do sistema e como este

pretende apoiar aos processos de negcio.

Assim, devem ser levantados documentos como: identificao dos problemas

operacionais correntes, objetivos do negcio, oportunidades abertas e restries

mais importantes da aplicao, fronteiras deste sistema e pontos de interface com

outros sistemas de informao, viso geral das entradas, sadas, metas de custo,

benefcio e a posio da aplicao dentro do contexto da organizao, entre outros.

importante tambm avaliar o fluxo do processo a ser informatizado, especificando

suas principais fases e interaes com os demais sistemas existentes (suas

interfaces), buscando sua contextualizao frente aos demais fluxos de negcio da

empresa.

133

Nesta fase do processo, importante a verificao dos requisitos de domnio, ou

seja, os requisitos que vm do ambiente que suporta a aplicao (seu domnio)

refletindo suas caractersticas e restries e no necessidades especficas dos

usurios.

Algumas questes so importantes e podem ser resumidas nos dados do Quadro

IV.1 abaixo.

Quadro IV.1 - Anlise de viabilidade: questes a serem consideradas

Questes sobre a anlise de viabilidade O sistema contribui para os objetivos gerais da empresa?

O sistema pode ser desenvolvido com a tecnologia existente, dentro das restries de custos e prazos?

Este sistema deve ser integrado a outros j existentes?

Como a empresa resolve o problema se este sistema no for implantado?

Quais so os problemas com o processo corrente e como o novo sistema informatizado pode colaborar na soluo dos mesmos?

Quais so os ganhos diretos que este sistema pode fornecer para os objetivos de negcio?

As informaes devero ser transferidas de e para outros sistemas da organizao?

Este sistema necessita de tecnologia que no foi utilizada previamente na empresa?

Qual ser o benefcio econmico de uma soluo implementada com sucesso?

Quais problemas esta soluo resolve?

Qual o ambiente de negcio na qual a soluo ser utilizada?

Existem caractersticas especiais ou restries que afetam o modo como a novo sistema ser proposto?

Fonte: adaptado de Sommerville (2007)

IV.3.2 Verificao da aplicabilidade do processo ao sistema candidato

O objetivo deste passo verificar se a teoria proposta pode ser aplicada ao sistema,

ou se ser necessrio outro tipo de processo, para que a definio de requisitos seja

desenvolvida.

A prototipao, tal como definida no item II.8.3, pode ser aplicada a um conjunto de

sistemas candidatos que devem possuir as seguintes caractersticas (BOAR, 1984):

O sistema no exige grande quantidade de especificao algortmica. A

aplicao deve ser um problema estruturado com uma grande quantidade de

elementos de dados e relacionamento entre registros mas, uma pequena

quantia de processos algortmicos;

Os usurios devem estar dispostos e capazes a participar ativamente, assim

como o gerente do projeto;

134

O preparo da equipe envolvida com o uso da metodologia no pode significar

risco, assim como a questo da falta esprito da equipe do grupo que estiver

participando das sesses;

O sistema possui muita interao com os usurios por meio de transaes

com relatrios associados aos bancos de dados, no operando com muito

processamento em lote (batch);

O Sistema de Informao apresenta coordenao distribuda nas aes dos

usurios (coordenao horizontal) e a comunicao entre eles ocorre

preponderantemente de modo indireto pelos dados inseridos nos objetos de

colaborao durante o uso do software. O software que implementa o SI

assncrono e desacoplado (ver item II.5.5)

A sada para prximo passo ocorre quando a ponderao de todos os fatores

suficiente para decidir se o processo proposto o mais indicado para o problema em

questo.

IV.4 PROCESSO PARA ESPECIFICAO DE REQUISITOS DE

SOFTWARE COM FOCO NA IDENTIFICAO DAS

CARACTERSTICAS INDIVIDUAIS DO TRABALHO COOPERATIVO E

DAS CARACTERSTICAS DE DOMNIO

Na Figura IV.4 abaixo, o diagrama do processo para identificao das caractersticas

individuais do trabalho cooperativo pode ser visto.

Nesta fase do processo, so coletados vrios pontos de vista (tanto dos usurios,

como de outros sistemas) sobre o que o sistema deve realizar (requisitos funcionais)

e as restries que lhe so impostas (requisitos no funcionais) (PRESSMAN, 2005;

SOMMERVILLE, KOTONYA, 1998). Diferenas e at inconsistncias entre estes

pontos de vista ocorrero nesta fase, quando o sistema inicialmente especificado e

que acabaro sendo includas nesta fase do processo. Somente nas fases

posteriores ser possvel a equalizao dos vrios pontos de vista do sistema.

135

Nesta fase do processo, assim como na prxima (simulao e identificao), os

documentos dos requisitos apresentados aos usurios devero ser compreensveis

aos mesmos, sem detalhamento mais tcnico e evitando-se jarges.

4. Trmino do

Prot. em papel?

3. Simulao 4. Anlise dos dados

2.

Identificao das

caractersticas iniciais

implementao/reviso SimNo5. Prxima fase: identificao dos

requisitos do trabalho cooperativo

(artefatos produzidos)

1. Artefatos do processo

de anlise e

aplicabilidade

Ciclo 1

Figura IV.4 - Processo para identificao das caractersticas individuais do trabalho cooperativo

Fonte: elaborado pelo autor

O processo proposto foca sobretudo os usurios finais do sistema (SOMMERVILLE,

2007), de modo que os requisitos de domnio devem ser agregados documentao

que ser apresentada aos usurios na prxima fase.

IV.4.1 Implementao/reviso do prottipo em papel

Para este processo, a implementao foi dividida em duas partes: a identificao

das caractersticas iniciais do sistema, que corresponde situao de anlise dos

artefatos vindos da fase anterior (anlise de viabilidade e aplicabilidade) e

posteriores implementaes derivadas das iteraes do processo (Figura IV.4).

136

Identificao das caractersticas iniciais do sistema

Este passo tem como objetivo determinar a essncia do sistema, obtendo-se

suficientes informaes para incio da prototipao em papel, e os documentos do

passo IV.3.1, tambm, podem ser utilizados nesta fase.

Assim, as metas, os objetivos, as oportunidades de negcio e os problemas

associados a este sistema devem ser buscados, para que, deste modo, seja

possvel identificar as necessidades bsicas que correspondem ao ncleo principal

da aplicao.

Tanto nesta fase do processo proposto como na prxima (prototipao no

funcional) deve-se procurar, inicialmente, explorar com os stakeholders as

caractersticas do sistema que no esto claramente definidas.

importante mapear quais so as principais atividades dentro do processo atual

(manual situaes de referncia ver item II.8.3) e como estas atividades sero

realizadas pelo novo processo (informatizado - aes caractersticas ver item

II.8.3) que substituir o antigo. Esta atividade dever ser desenvolvida com os

usurios que forem designados para esta fase (conforme item III.4).

Os principais artefatos so o diagrama de contexto e o fluxograma inicial dos

processos, com suas principais fases e interfaces grficas.

Deve-se dar ateno aos fluxogramas dos processos que sero automatizados e

serviro como elemento de suporte nas sesses de Anlise Coletiva do Trabalho e

na prototipao em papel, assim como as interfaces com os sistemas existentes

(tanto de estrutura de dados como dos servios oferecidos por outros sistemas).

Optou-se pelo uso do fluxograma e no do IDEFo (Integrated Definition for Function

Modelling), pois segundo Estorilio (2003), esta representao prefervel, pela sua

simplicidade e forma de explicitao. Enquanto o IDEFo (ver Apndice A) apresenta

o processo de forma genrica e modelado em diversos cartazes, o fluxograma traz o

fluxo de trabalho em apenas um modelo, pela interligao das tarefas efetivas.

A definio logo nas primeiras etapas do projeto das interfaces grficas tambm

importante, pois as descries em texto e em forma de diagramas no so

suficientes para expressar esses tipos de requisitos.

137

Neste processo, assim como prximo, importante um melhor detalhamento dos

requisitos de domnio (performance, acesso, segurana, etc.), conforme discutido

nos itens IV.3.1 e II.7.2.

No dados do Quadro IV.2 encontram-se algumas questes que devem ser

exploradas nesta fase do processo.

Quadro IV.2 - Identificao das caractersticas iniciais: questes a serem consideradas

Questes sobre identificao das caractersticas iniciais O que precisa ser suportado pelo sistema e o que no deve ser suportado?

Quem usar esta aplicao (criar uma lista de stakeholders)?

O software faz parte integral do trabalho dos usurios, ou ser usado somente esporadicamente?

Quais as conseqncias se um usurio cometer um erro usando o sistema para a funcionalidade que est sendo discutida?

Existem usurios com pouca familiaridade no uso bsico de aplicaes informatizadas (inclusive uso em planilhas, navegadores, editores de texto, etc.)?

Os usurios conhecem o processo que estar sendo automatizado?

Qual o perfil por execuo das tarefas que os usurios podem ser divididos?

O que pode ser caracterizado como uma sada til que esta soluo pode fornecer?

Fonte: Adaptado de Kotonya e Sommerville (1998)

A sada para o prximo passo ocorre quando os participantes (da rea de sistemas)

desta fase so capazes de explicar aos demais a documentao do negcio com

razovel nvel de conhecimento.

Implementao/reviso do prottipo em papel

A prototipao em papel um modo barato e rpido de desenvolvimento do

prottipo (item II.8.3). Nesta situao, no preciso desenvolver o software

executvel e os prottipos no necessitam ser implementados com padres

profissionais grficos. Um conjunto de interfaces grficas de usurios desenhado

em funo em funo do fluxograma inicial de processo, descrevendo como o

sistema deve ser usado e quais retornos so importantes aos usurios

entrevistados.

O prottipo inicial deve ser detalhado o suficiente para iniciar as sesses de ACT e

iterao (prximas fases).

Neste ponto, mais importante apresentar as funcionalidades levantadas na fase

anterior de modo menos sofisticado do que detalhar os storyboards, relatrios e

dados (devem ser detalhados ao longo do processo de iterao do prottipo com os

usurios).

138

A viso do usurio deve ser considerada, levando-se em conta os principais

documentos levantados na fase anterior, permitindo que a prxima fase

(prototipao no funcional) inicie-se com um conjunto de artefatos de projeto que

uma excelente ancora para o processo.

Os principais artefatos de sada so: requisitos funcionais, interfaces grficas,

fluxogramas, modelo preliminar de dados (para fins de projeto) e diagrama de

contexto.

Nesta fase, importante a definio da arquitetura do sistema pelos

desenvolvedores, j que a interface e seu modo de interao com o usurio tm

dependncia com a tecnologia adotada, assim como pelo fato de que para a

implementao do prottipo funcional precisa-se de uma viso geral da tecnologia

que ser adotada.

A sada para o prximo passo ocorre quando os documentos necessrios para a

prxima fase contemplam as mudanas coletadas na simulao do prottipo em

papel.

IV.4.2 Simulao do prottipo em papel

Para a simulao, escolhido um usurio representativo do perfil ou do grupo de

trabalho do processo de negcio que ser estudado. So definidas as tarefas tpicas

que representam o que os usurios devem realizar e construdas as verses da

interface (esboos manuais ou impresses de telas), no sendo necessrio

desenvolver uma verso funcional destas interfaces.

Aps a criao do prottipo em papel, so realizados os testes em que o usurio

colocado para realizar as interaes com o prottipo em papel. Um membro da

equipe de desenvolvedores atua como computador, apresentando as interfaces

(respostas s suas aes no prottipo) que so solicitadas pelo usurio. Pode-se

utilizar a figura de um facilitador que instrui o usurio a respeito das tarefas a

executar, com suas reaes e comentrios anotados por uma ou mais pessoas da

equipe de software (ouvintes).

139

Deste modo, possvel descobrir rapidamente quais partes da interface e do

processo de negcio funcionam ou no, podendo ser facilmente alteradas para

corrigir as deficincias apontadas pelos usurios (SNYDER, 2003).

Na medida que cada processo do fluxograma apresentado aos diferentes usurios

(individualmente), novas informaes so agregadas e novas opes so

oferecidas, tanto no que se refere s novas atividades como ao refinamento das que

j foram exploradas.

Assim, o mtodo efetivo para avaliar as reaes iniciais relativas ao projeto das

interfaces, as informaes que os usurios necessitam do sistema e como poderiam

normalmente interagir com ele.

O propsito principal desta fase obter novos e revisados requisitos pelas

observaes e crticas feitas pelos usurios sobre o prottipo, como por exemplo, o

delineamento dos principais fluxos do processo de negcio que ser automatizado.

O outro objetivo definir um conjunto de objetos e suas aes para as principais

interfaces de usurios associadas ao processo de negcio e que permitam aos

mesmos executar as atividades por eles apresentadas.

Nas iteraes iniciais, deve-se concentrar na deteco dos desvios grosseiros dos

artefatos construdos na fase anterior (sobretudo nos fluxogramas e storyboards),

assim como obter aceitao individual dos participantes sobre o prottipo.

Posteriormente, passa-se para a fase de refinamento, preocupando-se mais com a

interface em si e descobrindo-se novas funcionalidades e interaes.

Nas entrevistas com os usurios durante a simulao, algumas perguntas devem ser

realizadas e que esto resumidas nos dados do Quadro IV.3 abaixo.

Quadro IV.3 - Simulao do prottipo em papel: questes a serem consideradas

Questes bsicas sobre a simulao em papel Qual o trabalho realizado pelos diferentes tipos de usurios e em que circunstncias?

Quais so as atividade e subatividades realizadas enquanto os usurios executam seu trabalho?

Qual a sequncia do trabalho realizado (workflow do processo em detalhes)?

Dentro dos processos, qual a hierarquia das atividades?

Fonte: Adaptado de Sommerville (2007) e Pressman (2005)

Os principais artefatos de sada so: interfaces grficas, fluxogramas refinados e

modelo de dados preliminar (para o caso de ser necessrio o uso de estimativas por

140

meio de pontos de funo, ou para um planejamento de informaes gerenciais)

(GAVA et al. , 2004).

IV.4.3 Anlise dos dados- avaliao sobre o trmino da prototipao em papel

O objetivo deste passo determinar se a essncia da aplicao foi obtida e o ciclo

foi concludo.

Esta fase do processo estar terminada quando:

A interface e demais documentos associados implementam as principais

atividades definidas pelos usurios de modo correto;

Em termos de usabilidade, a interface fcil de compreender e de usar;

A sada para o prximo passo ocorre quando se obtm a aprovao dos

usurios entrevistados na simulao;

Os usurios concordam que o fluxo geral do processo foi mapeado.

O dados do Quadro IV.4 abaixo apresentam questes complementares para

avaliao do trmino da prototipao em papel que devem ser respondidas pelos

projetistas do sistema.

Quadro IV.4 - Avaliao sobre o trmino da prototipao em papel: questes a serem consideradas

Questes bsicas sobre avaliao sobre trmino da prototipao em papel Cada requisito est consistente com o objetivo global do sistema?

Este requisito realmente necessrio, ou uma caracterstica adicional que pode no ser essencial aos objetivos do sistema?

Cada requisito est bem delimitado e claro?

Algum requisito conflita com algum outro?

O requisito pode ser testado depois de implementado?

Os artefatos desenvolvidos aqui representam corretamente estes requisitos, com relao ao seu comportamento, funcionalidade e dados?

Fonte: Adaptado de Sommerville (2007) e Pressman (2005)

Quando a prototipao em papel terminar, o planejamento para a prxima etapa do

processo (prototipao no funcional) ser feito, com a definio dos temas que

sero abordados e quais pessoas convidadas. Cada novo tema que ser explorado

com os usurios selecionados, ser estudado com mais detalhes pelos

pesquisadores que realizaro as sesses de ACT.

141

IV.5 PROCESSO PARA ESPECIFICAO DE REQUISITOS DE

SOFTWARE COM FOCO NA IDENTIFICAO E SIMULAO DAS

CARACTERSTICAS COOPERATIVAS DO TRABALHO

O objetivo final desta fase do processo proposto a obteno dos requisitos do

sistema e dos modelos do sistema (que o documento que os desenvolvedores de

software devem executar), isto , a verso expandida dos requisitos dos usurios

utilizada como ponto de partida para o projeto de sistema que o documento que os

desenvolvedores de software devem executar.

Em sistemas, em que uma soluo evolucionria adotada, este documento pode

ser mais simples, com o enfoque na definio dos requisitos do usurio e nos

requisitos funcionais de alto nvel (SOMMERVILLE, 2007).

Em termos ideais, os requisitos de sistema devem descrever de modo simples o

comportamento externo do sistema e suas restries operacionais, no sendo

relacionados com o modo como o sistema deve ser projetado e implementado.

Na prtica, esta situao no ocorre, pois em sistemas que utilizam prototipao,

pelo menos parte de algumas das caractersticas no funcionais do sistema devem

ser consideradas, j que parte do mesmo ser implementado (prototipao

incremental).

Esta etapa do processo proposto comea com os artefatos desenvolvidos durante o

processo anterior e sero utilizados como entrada na atividade de

implementao/reviso da Figura IV.5 abaixo. Para esta fase do processo, optou-se

pela tcnica de prototipao no funcional, por atender s seguintes caractersticas:

De acordo com o II.3, o modelo mental do usurio forma-se a partir do modo

como o usurio interpreta a imagem do sistema, sendo a interface o elemento

mais importante nessa situao;

De acordo com o II.3, a interface tambm o resultado da interao homem-

computador e pode ser separada em dois componentes independentes: um

deles o desenvolvimento da interao e o outro, o software que implementa

esta interao (Ciclo 3);

No desenvolvimento do componente da interao da interface, pode-se

utilizar uma srie de critrios de usabilidade (ver Apndice B), como evoluo

142

da prototipao em papel para o sistema, assim como guia durante todo o

processo de aplicao do processo proposto neste trabalho;

Estes prottipos sucessivos do software oferecem uma representao

concreta para se comunicar com os usurios e os projetistas, constituindo

tambm um guia para a especificao de sucessivas verses (BURKHARDT;

SPERANDIO, 2007).

Neste processo (item IV.5), o prottipo ser constitudo, de modo geral, por uma

srie de artefatos de software, como: fluxograma (ver item IV.4.1), diagrama de

contexto (ver item II.7.4), interfaces grficas representativas do fluxograma (ver item

IV.4.1), modelo de dados (para os desenvolvedores item II.7.4), alm da descrio

das funes representativas do sistema.

Este modelo dever ser sucessivamente refinado. Para tanto, sero realizadas

sesses de ACT com os usurios, utilizando-se como modelo fsico inicial do

sistema (ou imagem do sistema - item II.3) os artefatos desenvolvidos na fase

anterior e ganhando novos componentes nas interaes e iteraes nesta etapa do

processo proposto (Figura IV.6).

Para Daniellou (2007), uma srie de condies deve ser estabelecida para esta

simulao:

Condies de aceitabilidade social;

Escolha adequada dos participantes da simulao;

No uso de suportes materiais como prottipo importante a participao dos

projetistas para comentar as informaes que nela figuram;

Desenvolver roteiros com base nas situaes de ao caractersticas

provveis previamente levantadas.

A seguir, so descritas as fases do processo apresentado na figura abaixo.

143

1.Artefatos produzidos

no ciclo1

5. Trmino do

Prottipo?

3. Apresentao 4. Anlise dos dados

2. Implementao/

reviso

SimNo6. Artefatos produzidos

para o ciclo 3

Ciclo 2

Figura IV.5 - Processo para simulao e identificao das caractersticas cooperativas do trabalho

Fonte: elaborado pelo autor

DOCUMENTAO

SISTEMA

PROJETISTA USURIO(1)

Prototipao, modelos e processos de software, ER e ergonomia das

interfaces orientadas ao fluxo de trabalho

Imagem do sistema

(Modelo fsico)

Modelo conceitual

Modelo do usurio(1)

(Modelo Mental)

Anlise coletiva do trabalho

USURIO(2)

Modelo do usurio(2)

(Modelo Mental)

USURIO(n)

Modelo do usurio(n)

(Modelo Mental)

n

Figura IV.6 - Modelo para aplicao das sesses de ACT Fonte: adaptado de Norman (1986) e Carrol e Olson (1988)

144

IV.5.1 Implementao/reviso prottipo no funcional

A prototipao no funcional ser usada a fim de que seja possvel atingir o modelo

mental dos usurios, parte-se do modelo inicial desenvolvido no processo anterior e

ser o modelo de interao inicial do sistema (abordagem do modelo conceitual

preconcebido, conforme item II.3.1).

O prottipo inicial deve ser detalhado o suficiente, de modo que sirva para iniciar as

sesses de ACT e iterao (iterao no ciclo).

Nesta fase do prottipo, as alteraes foram implementadas e propostas pelos

usurios na sesso de ACT, assim como as alteraes ocorridas na atividade de

anlise dos dados.

Na primeira vez que o material para a apresentao for desenvolvido, os artefatos

vindos do processo anterior (ver item IV.4) sero convertidos em interfaces j

considerando a tecnologia sob qual a interface operar, assim como sero aplicadas

sobre as mesmas as regras de ergonomia das interfaces (ver Apndice B).

Assim como no processo anterior (ver item IV.4.1), como ferramenta grfica para

apresentar o fluxo do processo, foi empregado o fluxograma, por ser de mais fcil

compreenso ao usurio (ESTORILIO, 2003).

Deste modo, procurou-se empregar o workflow como ferramenta de suporte para a

anlise das atividades dos usurios, uma vez que diferentes usurios podem estar

envolvidos com diferentes papis, assim como para mapear a troca das informaes

entre as diversas fases do processo e entre usurios (PRESSMAN, 2005).

Conforme o autor citado, para cada fase definida no workflow, foi associada uma ou

mais interfaces (ver Figura IV.7 e Apndice A) e para cada uma destas interfaces foi

associada a hierarquia das atividades e respectivas interfaces.

Os principais artefatos de sada so: requisitos de sistema, interfaces e

funcionalidades associadas, fluxogramas e interfaces associadas, modelo de dados

e diagrama de navegao.

Nesta fase, importante o refinamento da arquitetura do sistema pelos

desenvolvedores, pelos mesmos motivos apontados nos itens II.7.4 e IV.4.1.

145

Sub-processo 1 Sub-processo 2 Sub-processo 3 Sub-processo n

- Atividades

- Procedimentos

- Subatividades

Interface grfica 1 Interface grfica 2 Interface grfica 3.1 Interface grfica 3.2 Interface grfica n

- Atividades

- Procedimentos

- Subatividades

- Atividades

- Procedimentos

- Subatividades

- Atividades

- Procedimentos

- Subatividades

- Atividades

- Procedimentos

- Subatividades

Figura IV.7 - Relao entre fases do processo e interfaces grficas das sesses de ACT Fonte: elaborado pelo autor

A sada para a prxima fase (item IV.5.2) ocorre quando os documentos necessrios

contemplam as mudanas coletadas na apresentao (iterao) anterior.

IV.5.2 Apresentao do prottipo no funcional

O uso dos artefatos (interfaces grficas, interaes, respostas programadas,

navegao entre as hierarquias dos formulrios definidos pelo fluxograma do

workflow) desenvolvidos durante a atividade de implementao/reviso do prottipo

no funcional serviro como guia para aplicao dos mtodos de Anlise Coletiva

do Trabalho (ACT).

Uma vez que se trata da concepo de um novo sistema, o uso de ACT

necessrio na medida que os usurios devem explicar o que fazem e, ao explicar

tambm ocorre reflexo sobre a atividade, fazendo com que se torne explcito e

consciente tudo que se fazia de modo automtico.

Assim, em linhas gerais, o processo proposto dever atender aos seguintes

aspectos:

H, pelo menos dois pesquisadores conduzindo a reunio por meio da

pergunta positiva o qu?;

O objetivo dos usurios explicar aos pesquisadores o que fazem no

trabalho;

146

Deve ser dada uma explicao inicial sobre o objetivo do trabalho, por parte

dos pesquisadores. Novos assuntos podero ser desenvolvidos com o grupo,

mas devem ser motivo de novas negociaes;

Verificar na descrio dos usurios o que comum, e o que diferente na

atividade, procurando avaliar os principais pontos que se destacam e uma

caracterizao mais detalhada de determinados aspectos da atividade do

usurio;

Procurar entender nas atividades dos usurios as relaes com as demais

atividades: explicar o que os outros fazem antes ou depois dele no processo

produtivo, acima, ao lado ou abaixo na escala hierrquica;

Os pesquisadores devem entender detalhes sobre a atividade e procurar

faz-la de vrias formas, mesmo que demore bastante tempo. Uma boa

tcnica corresponde a se descrever a atividade cronologicamente.

Alm das questes ligadas anlise coletiva do trabalho, as questes do item IV.4.2

(ver Quadro IV.3) podem ser utilizadas, visto que o componente individual do

trabalho cooperativo, tambm, deve evoluir durante a aplicao do processo

proposto nesta pesquisa.

Estas perguntas tm o objetivo de mapear as principais atividades no processo atual

(no informatizado), ou seja, definir as situaes de referncia (ver item II.8.3) e

avaliar como estas atividades sero realizadas por meio do novo processo,

definindo, deste modo, as aes caractersticas (ver item II.8.3).

Conforme cada fase do fluxograma apresentada aos diferentes usurios

(coletivamente), novas informaes so agregadas e novas opes so oferecidas,

tanto no que se refere s novas atividades como ao refinamento das que j foram

exploradas.

Assim como no ciclo 1, um dos propsitos desta fase obter novos e revisados

requisitos por meio das observaes e crticas feitas pelos usurios sobre o

prottipo, assim como definir um conjunto de objetos e suas aes aos principais

artefatos associadas ao processo de negcio e que permitam aos mesmos executar

as atividades por eles apresentadas.

147

Um aspecto importante desta tcnica reside no fato de que, visto pelo usurio, de

fato ocorre uma iterao com o sistema formado pelas interfaces, computador e

sistema (conjunto de possveis respostas predefinidas s solicitaes dos usurios).

Nesta fase do processo, ocorre tambm a reviso dos requisitos da fase anterior do

prottipo com a fase atual, em que verificado se o que foi discutido na reunio

anterior est implementado no material que est sendo discutido nesta sesso.

importante esta comunicao entre os desenvolvedores e usurios participantes da

sesso, para garantir a consistncia e garantir, tambm, que todos os requisitos

estejam contemplados nos documentos que sero utilizados para discusso.

A documentao de cada sesso pode ser feita de vrias formas, desde anotaes

especficas at o uso de gravaes de udio e vdeo.

O objetivo buscar diferenas entre o sistema simulado e o sistema que

efetivamente entrar em operao, partindo-se de uma verso inicial.

Nas iteraes iniciais, deve-se concentrar na deteco dos desvios dos artefatos

construdos na fase anterior (sobretudo nos fluxogramas e storyboards), pelo

entendimento de como o trabalho realizado cooperativamente por meio destes

artefatos, procurando-se obter a aceitao coletiva dos participantes sobre os

mesmos.

Posteriormente, passa-se fase de refinamento, preocupando-se mais com a

interface em si (usabilidade), descobrindo-se novas funcionalidades e interaes

entre seus elementos.

IV.5.3 Anlise dos dados - avaliao sobre o trmino da prototipao no

funcional

Deve-se definir como ser a sesso de ACT para a apresentao coletiva. Nesta

fase, define-se quais temas sero abordados na apresentao e quais pessoas

sero convidadas (estas devem conhecer os temas que sero explorados -

entrevistar individualmente cada participante, buscando entender o que eles fazem,

esclarecendo o que a tcnica e o que esperado de sua participao). Cada tema

que ser explorado com os usurios selecionados dever ser estudado com mais

detalhes pelos pesquisadores que realizaro as sesses de ACT.

148

Deve-se, tambm, preparar uma agenda para a sesso com os passos que devem

ser seguidos no contexto da iterao do processo, mostrando onde o grupo se

encontra e para onde est indo e o que deve ser alcanado. Os principais pontos

so: introduo, reviso da elaborao dos objetivos gerais, abordagem da sesso,

reviso de pendncias, reviso geral e avaliao da sesso.

Para a avaliao das atividades dos usurios, podem ser feitas as seguintes

perguntas de mbito geral ligadas ao processo e que esto descritas nos dados do

quadro abaixo.

Quadro IV.5 - Avaliao sobre trmino da prototipao no funcional: questes a serem consideradas

Questes para verificao do trmino da prototipao no funcional Cada requisito est consistente com o objetivo global do sistema?

Este requisito realmente necessrio ou uma caracterstica adicional que pode no ser essencial aos objetivos do sistema?

Cada requisito est bem delimitado e claro?

Algum requisito conflita com algum outro?

Todos os requisitos esto especificados em seu prprio nvel de detalhe, ou seja, existe algum requisito que est especificado com nvel tcnico inapropriado para este estgio do processo?

Os artefatos desenvolvidos aqui representam corretamente estes requisitos, com relao a seu comportamento, funcionalidade e dados?

Cada requisito possui uma fonte (quem o definiu)?

Cada requisito implementvel no ambiente tcnico que suportar o sistema?

A definio das interfaces ligadas aos processos e as respectivas hierarquias das atividades esto de acordo com as funes e comportamentos que foram coletados na ltima apresentao aos usurios?

Fonte: Adaptado de Sommerville (2007) e Pressman (2005)

O processo como um todo termina quando a essncia da aplicao foi obtida, de

modo que sucessivos refinamentos acabem trazendo melhorias marginais ao

processo, e as mudanas passem de anlise de funcionalidades e interaes da

interface para o detalhamento dos atributos da interface, sem afetar a usabilidade,

sinalizando que o prottipo est maduro. Assim, o processo estar terminado

quando:

A interface e demais documentos associados implementam as principais

atividades definidas pelos usurios de modo correto;

Em termos de usabilidade, a interface fcil de compreender e usar;

A sada para o prximo passo ocorre quando se obtm a aprovao dos

usurios participantes nas sesses de ACT;

Os usurios concordam que o fluxo geral do processo foi mapeado.

149

Outro aspecto ligado ao trmino deste processo o planejamento deve ser

realizado para a prxima etapa do processo (prototipao funcional) sobretudo no

que se refere ao cronograma de implementao da primeira verso funcional do

software.

IV.6 PROCESSO PARA ESPECIFICAO DE REQUISITOS DE

SOFTWARE COM FOCO NO REFINAMENTO DAS

CARACTERSTICAS DO TRABALHO COOPERATIVO

As atividades desta ltima fase do processo equivalem ao caso do processo

identificao e simulao, mas agora existe um sistema real que foi desenvolvido

utilizando os principais requisitos do processo anterior.

A fase do processo proposto comea com os artefatos desenvolvidos na fase

anterior e utilizados como entrada na atividade de implementao da Figura IV.8

abaixo. Com relao fase anterior, os requisitos definidos nesta fase sero

efetivamente implementados e no simulados em ao/resposta pr-programada.

1. Artefatos produzidos na

processo de identificao e

simulao

5. Trmino do

Prot. funcional?

3. Apresentao 4. Anlise dos dados

No

2. Implementao em

cascata (anlise/projeto/

implementao) Sim

p/ a vida til do projeto/

Manuteno

Ciclo 3

Figura IV.8 - Processo para o refinamento da identificao das caractersticas do trabalho cooperativo

Fonte: elaborado pelo autor

150

As sesses de ACT que sero realizadas com os usurios seguem as mesmas

diretrizes definidas no processo de prototipao no funcional, utilizando-se como

modelo fsico inicial (ou imagem do sistema, item II.3) o sistema implementado e

ganhando novos componentes durante as interaes e iteraes nesta fase do

processo proposto (Figura IV.9). Um aspecto importante que diferencia esta etapa

do processo com a anterior que estas sesses sero orientadas pelos conceitos

da teoria da mente coletiva e awareness.

A segunda iterao (apresentao) outro aspecto diferenciador e dever ser

realizada, aps o sistema ter sido suficientemente empregado no ambiente de

trabalho dos usurios.

DOCUMENTAO

SISTEMA

PROJETISTA USURIO(1)

Prototipao, modelos e processos de software, ER e ergonomia das

interfaces orientadas ao fluxo de trabalho

Imagem do sistema

(Modelo fsico)

Modelo conceitual

Modelo do usurio(1)

(Modelo Mental)

Anlise coletiva do trabalho, mente coletiva, modelo 3C e awareness e tcnicas de entrevista

USURIO(2)

Modelo do usurio(2)

(Modelo Mental)

USURIO(n)

Modelo do usurio(n)

(Modelo Mental)

n

Figura IV.9 - Modelo para a aplicao das sesses de ACT Fonte: adaptado de Norman (1986); Carrol e Olson (1988)

IV.6.1 Implementao em cascata

A prototipao evolucionria inicia seu primeiro ciclo nesta atividade, recebendo os

artefatos da fase anterior que serviro para o desenvolvimento de uma primeira

verso funcional do sistema que ser utilizada pelos usurios em seus postos de

trabalho.

151

Nesta fase, a implementao utiliza o modelo em cascata, cuja sada de uma etapa

flui para a etapa seguinte, e o desenvolvimento s prossegue quando uma etapa

tiver sido concluda. Para assumir esta opo, preciso que caso ocorra alguma

alterao dos requisitos aps a fase de apresentao (item IV.6.2) e anlise dos

dados (item IV.6.3), estes devero esperar o prximo ciclo para serem

implementados, ou seja, haver um congelamento dos requisitos atuais discutidos

com os usurios durante a iterao corrente.

Gonalves et al. (2005) do mais detalhes sobre a arquitetura utilizada nesta

atividade (no faz parte do escopo desta pesquisa).

Assim, uma vez que a arquitetura da aplicao j foi definida na fase anterior

(prototipao no funcional), sero implementados todos os formulrios DHTML e

seus elementos de interao, utilizando os conceitos de ergonomia das interfaces e

awareness (a partir da segunda iterao), assim como o sistema gerenciador de

banco de dados para implementao das transaes, eventos, relatrios e rotinas

associadas ao sistema que est sendo desenvolvido.

O desenvolvimento do sistema orientado ao fluxo do processo, em que, para cada

fase definida no workflow foi associada uma ou mais interfaces e para cada uma

destas interfaces foi associada a hierarquia de subatividades e respectivas

interfaces.

A sada para a prxima fase (item IV.6.2) ocorre quando os documentos necessrios

contemplam as mudanas coletadas na apresentao relativa ao ciclo de

desenvolvimento corrente.

Assim como no processo (ciclo 2) anterior (item IV.5) , para que seja possvel atingir

o modelo mental dos usurios, parte-se do modelo funcional desenvolvido nesta

atividade inicial e que ser o modelo de interao inicial do sistema.

Os principais artefatos de sada so: requisitos de domnio, fluxogramas e interfaces,

assim como funcionalidades associadas, modelo de dados implementado, diagrama

de navegao e artefatos associados ao conceito de awareness e mente coletiva.

Nos dados do quadro abaixo so reproduzidos os elementos de awareness (ver item

II.5.5) que so utilizados na implementao dos requisitos do trabalho cooperativo

levantados neste ciclo.

152

Quadro IV.6 - Elementos de awareness (reproduo do Quadro II.1)

Categoria Elemento Significado

O qu Atividades: Viso ampla das tarefas individuais, do grupo e de sua produo:

Aes O que fazer e o que os outros esto fazendo

Artefatos Em quais objetos esto trabalhando no momento

Produo Quais so os resultados preliminares do trabalho

Histrico de

aes

O que um indivduo esteve realizando

Papis: Diferenciao das informaes em funo do papel

Alcance At onde podem ou devem

Quando Eventos passados, passado

continuo e presentes:

Contexto sobre o que foi feito (eventos no passado) e do que ainda est sendo feito (passado contnuo),

Histrico de eventos

Quando um evento aconteceu

Eventos futuros Representam uma opo interessante para manter os membros atentos aos possveis rumos do trabalho.

Persistncia Alta: Definio de um critrio de caducidade, que inutiliza estas informaes.

Apresentao das informaes de awareness

Posterior (a critrio do usurio)

Onde Espao de trabalho:

Objetos compartilhados pelo grupo. Por meio de sua manipulao e de seu histrico que mostram o que houve e est acontecendo dentro do trabalho em grupo.

Histrico de artefatos

Como um determinado artefato chegou quele estado

Histrico de localizao

Onde um indivduo esteve

Metforas de sistema

Relacionam o groupware com verses monousurias do sistema, havendo necessidade de enriquec-la adequadamente com as informaes de awareness.

Como Interface Interfaces desacopladas, mas no impedindo a interface de incluir elementos para awareness

Balanceamento de interface

Filtragem ou um agrupamento das informaes, mostrando apenas aquilo que for mais til

Quem Autoria Quem realizou um determinado evento

Histrico de presena

Quem esteve em um local do ambiente e quando

Fonte: Adaptado de Assis (2000) e PINHEIRO et al. (2001)

IV.6.2 Apresentao do prottipo evolucionrio (funcional)

Assim como no caso de prototipao no funcional, os artefatos desenvolvidos na

fase de implementao em cascata (interfaces grficas, interaes, respostas

153

programadas, navegao entre as hierarquias dos formulrios e o fluxograma do

workflow) sero utilizados, como guia para aplicao da Anlise Coletiva do

Trabalho.

Para a realizao da primeira sesso de ACT (que ocorrer no segundo ciclo de

iterao), ser preciso que os usurios faam uso do sistema em situao real de

trabalho, aps receberem treinamento adequado na primeira verso funcional do

sistema (primeiro ciclo de iterao).

Em linhas gerais, os aspectos abordados nas sesses de ACT, alm das que foram

citadas no ciclo anterior (item IV.5.2), devem focar o uso real do sistema,

observando que alguns destes aspectos devem reforar as aes (contribuio,

representao e subordinao), processos sociais (socializao, conversao e

recapitulao) e da conscincia sobre a contextualizao das atividades individuais

por intermdio da compreenso das atividades realizadas por outras pessoas

(awareness):

Inverte-se o processo do saber. So os trabalhadores que sabem, os

pesquisadores no sabem. Todos tm um algo prprio e nico para contar:

sua atividade real (subordinao e contribuio);

Para se explicar o que se faz, deve-se antes refletir sobre o que se faz, o que

no um processo usual, fazendo com que se torne explcito e consciente

tudo o que se fazia de modo automtico, visto que a pessoa que se exprime,

tambm toma conscincia, no se exprime somente para as demais pessoas,

exprime para que ela mesma saiba o que visa. Normalmente, no se pensa

na atividade que se faz, mas em seus resultados, a atividade em si que

importante, e ela quem precisa ser explicada (subordinao, contribuio e

elementos de awareness);

Verificar na descrio dos trabalhadores o que comum, e o que diferente

na atividade, procurando avaliar os principais pontos se que destacam e uma

caracterizao mais detalhada de determinados aspectos da atividade do

usurio (representao, contribuio e elementos de awareness);

Procurar entender nas atividades dos usurios as relaes com as demais

atividades: explicar o que os outros fazem antes ou depois dele no processo

154

produtivo, acima, ao lado ou abaixo na escala hierrquica (representao e

elementos de awareness);

Durante a sesso, verificar a necessidade de introduo de elementos de

awareness, conforme os conceitos apresentados no item II.5.5 e do Quadro

IV.6, de modo a procurar obter a conscincia sobre a contextualizao das

atividades individuais por meio da compreenso das atividades realizadas por

outras pessoas e de que forma (elementos de interface grfica) o sistema

informatizado refletir estes elementos.

No incio de cada sesso, aplicado o questionrio do quadro abaixo que tem como

objetivo avaliar qualitativamente a evoluo das caractersticas cooperativas do

trabalho, detectando pontos para sua melhoria por meio da teoria da mente coletiva.

Quadro IV.7 - Avaliao qualitativa sobre a intensidade da mente coletiva nas sesses de ACT

Questes a respeito das aes/comportamento C: Contribuio, R: Representao S: Subordinao

Sesso (n)

Nmeros de No

Nmeros de Sim

Voc sabe em qual fase do processo pode atuar? (R)

Voc sabe quais so os dados mais importantes a serem inseridos? (C)

Estando na fase de sua responsabilidade, sabe quem deve ser o responsvel pela prxima fase? (C)

Voc sabe de que outras fases depende a sua? (R)

Quando insiro um dado errado em uma fase de minha responsabilidade, sei das consequncias no processo deste erro para as fases posteriores? (R)

Distingue qual sua posio atual no processo? (R)

Distingue quem so os responsveis pelas atividades que esto sendo desenvolvidas? (R)

Confia que as informaes que chegam at voc pelo sistema so as mais atualizadas? (S)

Voc utiliza o sistema para trocar informaes com outros usurios, sem a necessidade de outros meios?(S)

Voc toma decises por meio de informaes fornecidas pelo sistema? (S)

Voc sabe como acompanhar as metas do grupo? (R)

Voc sabe como as aes dos outros usurios esto relacionadas com as suas? (R)

Voc sabe como acompanhar o trabalho de outros membros do grupo? (R)

Voc sabe como recuperar as informaes que inseriu no sistema? (R)

Voc sabe como recuperar as informaes que outros membros do grupo inseriram no sistema? (R)

Questes a respeito do processo social So: Socializao, Co: Conversao Re: Recapitulao

Existe um programa de treinamento para novos usurios? (So)

Os usurios trocam experincia regularmente a respeito da utilizao do sistema? (Co)

Ocorrem encontros programados para a discusso do uso e dos resultados do sistema? (Re)

Porcentual do total de respostas:

Fonte: Elaborado pelo autor, baseado em Weik and Roberts (1993)

155

IV.6.3 Anlise dos dados - avaliao do trmino do prottipo evolutivo

Os dados oriundos da apresentao do prottipo em uso real so analisados com

relao s respostas s perguntas do Quadro IV.7, para obteno dos elementos de

awareness descritos no item II.5.5. Em funo dos resultados obtidos, os elementos

adequados so selecionados para implementao, e nova sesso de ACT dever

ser realizada, com os requisitos congelados durante os ciclos da pesquisa-ao.

Durante esta fase do processo, com o sistema em uso e antes das sesses,

preciso realizar entrevistas (ver item II.8.2) com os usurios que representam os

vrios papis no fluxo de trabalho, visando a obter as informaes necessrias para

construir/corrigir os artefatos de software em uso.

O planejamento tambm desenvolvido para o prximo ciclo (interao) do prottipo

funcional, por exemplo, definindo-se, dentro do possvel, quais temas sero

abordados e quais pessoas sero entrevistadas, alm de preparar uma agenda para

a sesso com os passos que devem ser seguidos no contexto da iterao do

processo. Cada novo tema que ser explorado com os usurios selecionados,

dever ser estudado com mais detalhes pelos pesquisadores que realizaro as

sesses de ACT.

O trmino do processo como um todo ocorre quando as novas implementaes

definidas na fase de apresentao implicarem um ganho marginal para o sistema, de

modo que a preocupao dos usurios recaia mais na esttica (sem afetar a

usabilidade do sistema) do que em suas funcionalidades e, tambm, que haja

concordncia dos usurios na sesso de ACT que o sistema j pode ser liberado

para uso, ficando eventuais mudanas proteladas para futuras manutenes no

sistema (ver Figura IV.1e Figura IV.3), mas sem necessidade de uma nova iterao.

Assim como na prototipao no funcional, ao trmino deste processo um relatrio

tambm deve ser escrito pelos pesquisadores e, antes de sua divulgao, deve ser

apresentado ao conhecimento dos participantes, para que se possa detectar erros

de interpretao e pontos que no ficaram esclarecidos nas reunies. Esta

confirmao, tambm, pode ser obtida pela concordncia dos usurios durante as

sesses de ACT, ou posterior confirmao nesta fase (anlise dos dados).

156

IV.7 PLANEJAMENTO DE EXECUO DO PROCESSO PROPOSTO EM

FUNO DOS CICLOS DA PESQUISA-AO

A Figura IV.10 abaixo mostra a relao entre os ciclos de conduo da pesquisa-

ao e as fases dos trs processos propostos (que correspondem ao

macroprocesso proposto - Figura IV.1). Os trs processos propostos correspondem

a trs ciclos de PA, e cada ciclo deste pode sofrer vrias iteraes (voltas sobre si

mesmo).

Assim, os ciclos de conduo descritos por Coughlan e Coghlan (2002) sofreram as

seguintes adaptaes para atingir aos objetivos deste trabalho:

Os ciclos de avaliao, coleta e feedback de dados correspondem a um nico

ciclo denominado de levantamento e discusso dos dados, equivalente fase

de apresentao (ciclos 2 e 3) ou simulao ( ciclo 1) do processo proposto;

Os ciclos de anlise dos dados e planejamento da ao correspondem a um

nico ciclo denominado anlise e planejamento, equivalente fase de anlise

e avaliao de trmino;

O ciclo de implementao da PA equivale fase de implementao do

processo proposto.

Antes do primeiro ciclo da pesquisa-ao, o estudo da viabilidade e a verificao da

aplicabilidade do processo sero realizados por meio do estudo do contexto e

propsitos (item III.4.2), sendo verificado se o sistema de informao pode ser

implementado em um software, e se o processo proposto pode ser aplicado.

Uma nova iterao em qualquer dos trs ciclos inicia-se no ciclo de implementao,

com a diferena que, no ciclo1, so os artefatos provenientes da fase preliminar da

PA que daro incio iterao; no ciclo 2, so os artefatos provenientes do passo de

anlise e planejamento do ciclo1 e, no ciclo 3, os artefatos provenientes do passo

de anlise e planejamento do ciclo 2 (Figura IV.10).

157

Monitoramento

Anlise e planejamentoANLISE (N);....;

ImplementaoIMPLEMENTAO (N)(N+1)

Levantamento e discusso

dos dadosAPRESENTAO (N);....;

Passos da pesquisa-ao

FASES DO PROTTIPO

Contexto e propsitosANLISE DE VIABILIDADE E

APLICABILIDADE Incio de um novo ciclo de interao (N), (N+ 1)

Trmino do ciclo de interao atual (N)

Figura IV.10 - Passos da Pesquisa-ao e correspondentes atividades para os processos de identificao e refinamento das caractersticas cooperativas do trabalho

Fonte: elaborado pelo autor

Nos dados do Quadro IV.8, pode ser vista a adaptao dos ciclos de

desenvolvimento da PA com o macroprocesso proposto e os conceitos utilizados em

cada um dos ciclos (quadro metodolgico).

Quadro IV.8 - Quadro metodolgico

CICLOS E FASE DA PESQUISA-AO

Fase preliminar : Contexto e propsitos

Fase Componente Descrio

Incio Fase preliminar Contexto conceitual: anlise de viabilidade e da aplicabilidade do processo (itens IV.3.1 e IV.3.2, respectivamente) Fundamentao terica para entendimento do contexto do problema, envolvendo as seguintes disciplinas relacionadas:

Engenharia de Requisitos

Tcnicas utilizadas na descoberta de requisitos

Contexto emprico: descrio do SI estudado nesta pesquisa

Ciclo 1: Processo para a Identificao dos requisitos individuais do trabalho cooperativo

Passo Componente Descrio

1 Implementao Fase do processo: identificao das caractersticas iniciais e implementao/reviso (item IV.4.1) Fundamentao terica:

Storyboarding e prototipao em papel;

Modelos e processo de software;

Elementos de Engenharia de Requisitos;

A ergonomia das interfaces.

158

2 Levantamento e discusso dos dados

Fase do processo: simulao do prottipo em papel (item IV.4.2). Fundamentao terica:

Storyboarding e prototipao em papel;

Modelo de desenvolvimento iterativo e evolucionrio;

Cenrios.

3 Anlise e planejamento

Fase do processo: anlise dos dados e trmino da prototipao em papel (item IV.4.3) Fundamentao terica:

Storyboarding e prototipao em papel;

Anlise Coletiva do Trabalho (planejamento prox. fase).

4 Monitoramento (concluses)

Analisar os resultados e lies aprendidas, relacionando o emprico ao terico trazendo ganhos de conhecimento.

Ciclo 2: Processo para identificao e simulao dos requisitos do trabalho cooperativo Passo Componente Descrio

1 Implementao Fase do processo: Implementao/reviso prottipo no funcional (item IV.5.1) Fundamentao terica:

Tcnicas de prototipao e ergonomia e concepo informtica;

Modelos e processo de software;

Elementos de Engenharia de Requisitos;

A ergonomia das interfaces.

2 Levantamento e discusso dos dados

Fase do processo: apresentao do prottipo no funcional (item IV.5.2). Fundamentao terica:

Tcnicas de prototipao e ergonomia e concepo informtica;

Modelo de desenvolvimento iterativo e evolucionrio;

Anlise Coletiva do Trabalho;

Cenrios;

Modelo mental e interao;

A dimenso coletiva do trabalho e o trabalho cooperativo.

3 Anlise e planejamento

Fase do processo: anlise dos dados e trmino da prototipao no funcional (item IV.5.3) Fundamentao terica:

Tcnicas de prototipao e ergonomia e concepo informtica;

Anlise Coletiva do Trabalho (planejamento);

A ergonomia das interfaces;

Engenharia de Requisitos.

4 Monitoramento (concluses)

Analisar os resultados e lies aprendidas, relacionando o emprico ao terico trazendo ganhos de conhecimento.

Ciclo 3: Processo para o refinamento dos requisitos do trabalho cooperativo Passo Componente Descrio

1 Implementao Fase do processo: implementao em cascata (item IV.6.1) Fundamentao terica:

Tcnicas de prototipao e ergonomia e concepo informtica;

Modelos e processo de software (modelo em cascata);

Elementos da Engenharia de Requisitos;

A ergonomia das interfaces;

Elementos de awareness.

2 Levantamento e discusso dos dados

Fase do processo: apresentao do prottipo evolucionrio (item IV.6.2IV.5.2). Fundamentao terica:

159

Tcnicas de prototipao e ergonomia e concepo informtica;

Modelo de desenvolvimento iterativo e evolucionrio;

Anlise Coletiva do Trabalho;

Modelo mental e interao;

A dimenso coletiva do trabalho e o trabalho cooperativo;

Teoria da mente coletiva;

CSCW, Groupware, modelo 3C e awareness

3 Anlise e planejamento

Fase do processo: anlise dos dados - avaliao sobre o trmino do prottipo evolutivo (item IV.6.3) Fundamentao terica:

Tcnicas de prototipao e ergonomia e concepo informtica;

Anlise Coletiva do Trabalho (planejamento);

A ergonomia das interfaces;

Engenharia de Requisitos;

Teoria da mente coletiva;

CSCW, Groupware, modelo 3C e awareness;

Tcnicas de entrevista.

4 Monitoramento (concluses)

Analisar os resultados e lies aprendidas, relacionando o emprico ao terico trazendo ganhos de conhecimento.

Fonte: Elaborado pelo autor

160

V FASE PRELIMINAR E CICLO 1 DA PESQUISA-AO:

PROCESSO PARA ESPECIFICAO DE REQUISITOS DE

SOFTWARE COM FOCO NA IDENTIFICAO DAS

CARACTERSTICAS INDIVIDUAIS DO TRABALHO

COOPERATIVO E DAS CARACTERSTICAS DE DOMNIO

A fase preliminar desta PA corresponde a um entendimento sobre o contexto no qual

a pesquisa ser realizada, o propsito da conduo do trabalho e a verificao da

viabilidade e aplicabilidade do processo proposto.

O ciclo 1 inicia-se com o levantamento do processo no informatizado e a definio

de um conjunto de artefatos para o incio da prototipao em papel, alm da

definio da situao de referncia do processo no informatizado e as respectivas

aes caractersticas futuras provveis do software que ser implementado.

Aps a realizao das iteraes deste ciclo, obtm-se os principais artefatos

relativos aos requisitos individuais do trabalho cooperativo que sero utilizados para

iniciar o ciclo 2 desta pesquisa.

V.1 CONTEXTO E PROPSITOS

V.1.1 Contexto emprico

Neste item, o ambiente onde foi realizada a pesquisa-ao contextualizado,

mostrando a necessidade da conduo do trabalho. O estabelecimento das

justificativas para a ao requerida, alm das justificativas para a pesquisa que so

apresentadas no item III.3 (caracterizao da conduo da PA).

A empresa onde foi realizada a pesquisa-ao corresponde a uma grande empresa

nacional que desenvolve tecnologia com aproximadamente 1.500 colaboradores

(PesqTec ), com atuao no mercado h mais de 115 anos.

A PesqTec tem como uma de suas misses prover apoio tecnolgico aos setores

produtivos, o que realizado tanto pela prestao de servios laboratoriais, como

pelo desenvolvimento de servios de consultoria tcnica, com atuao nas reas de

161

engenharia civil, metalurgia, madeiras, mecnica, eletricidade industrial, engenharia

naval e ocenica, transportes, qumica, geologia, couros e calados, biotecnologia,

tecnologia ambiental, normalizao e qualidade industrial, informao tecnolgica,

informtica, educao de nvel superior e treinamento.

Anualmente so produzidos mais de 42.349 (em 2008) documentos tcnicos, cuja

prestao de servios laboratoriais representa mais de 30% da receita prpria por

intermdio de seus 30 laboratrios.

Contudo, no existe um padro de gerenciamento e atendimento comum aos

laboratrios, apesar da existncia de uma srie de normas internas do sistema da

qualidade da PesqTec que orienta os aspectos gerais que devem ser estabelecidos

nas principais fases do atendimento de uma determinada solicitao (oramento,

etc.). Cada um destes laboratrios aplica estas normas de modo particular para as

solicitaes de seus clientes, uma vez que no h centralizao dos atendimentos.

Como consequncia da falta de padronizao, as informaes sobre o processo de

atendimento so geradas de modo independente por cada um dos laboratrios (em

muitos deles, o processo de atendimento feito por meio de arquivos em papel), as

informaes so fragmentadas e de difcil agregao, inclusive, para retorno da

situao de atendimento ao cliente.

O processo de atendimento corresponde a um workflow (ver Apndice A), passando

por vrias etapas, desde a abertura do pedido, at sua finalizao, de modo a

envolver o trabalho cooperativo dos participantes do laboratrio (tcnicos,

supervisores de laboratrio e secretrias), em especial, nos laboratrios que

oferecem vrios tipos de servios, complementares uns aos outros (um mesmo

pedido do cliente pode conter vrios destes servios de um mesmo laboratrio).

No incomum tambm a situao na qual um cliente solicita determinados tipos de

servios que envolvem a participao conjunta de vrios laboratrios, cada um

contribuindo com o servio para o qual possui especializao. Neste caso, os

laboratrios devem trabalhar cooperativamente para o atendimento, sob pena de um

atendimento inadequado ou incompleto para este tipo de solicitao.

Em funo da necessidade de padronizar e sistematizar o processo de atendimento

da prestao de servios que permite a integrao de todos os laboratrios, a

162

diretoria da empresa PesqTec aprovou o desenvolvimento de um software, com o

seguinte objetivo (ver item III.4.2):

Desenvolvimento de um software de acompanhamento e gerenciamento

laboratorial a ser disponibilizado na intranet da empresa abrangendo

todos os laboratrios e que tem como objetivo uniformizar os mtodos de

acompanhamento e gerenciamento de servios laboratoriais, dando

homogeneidade e maior eficincia ao desenvolvimento e

acompanhamento de servios tcnicos correntes, desde o momento da

solicitao de um servio, at o seu faturamento.

O sistema permite gerar oramentos, registrar amostras, obter nmero

de documentos tcnicos e gerar pedidos de faturamento de modo

totalmente integrado (instrumentos de controle e acompanhamento do

atendimento dos laboratrios). Tambm dever ser possvel fazer o

acompanhamento das atividades dirias dos laboratrios, assim como

fornecer informaes gerenciais sobre as principais atividades

executadas (indicadores de desempenho operacionais) (Programa

informatizado de gerenciamento laboratorial, 2005, p.3).

Assim, o processo de mudana para a aplicao da PA fica estabelecido, que a

automatizao do processo de atendimento aos clientes da empresa PesqTec

(conforme descrito acima, nos objetivos do projeto).

Por outro lado, o ambiente para a aplicao das aes na resoluo do problema

apresentado corresponde ao trabalho cooperativo dos funcionrios dos laboratrios

da empresa PesqTec, para o atendimento das solicitaes de seus clientes, por

meio do software desenvolvido, ambiente este que propiciou tambm condies

para a pesquisa acadmica apresentada neste trabalho (ver item I.2) e de todo o

processo de aprendizagem e monitoramento que acompanhou seu desenrolar,

conforme descrito nos prximos itens e captulos.

V.1.2 Contexto conceitual: anlise de viabilidade

Considerando-se o objetivo apresentado no item V.1.1, que mostra um resumo da

descrio do sistema e de como este pretende dar apoio aos processos de negcio,

da descrio da fase de anlise de viabilidade descrita no item IV.3.1 e das questes

do Quadro IV.1, a concepo e a implementao do software para automao do

163

processo de acompanhamento laboratorial mostram-se viveis em funo dos

seguintes itens:

Identificao dos problemas operacionais correntes: conforme apresentado no

item V.1.1, atualmente no possvel integrar as solicitaes dos servios

dos clientes intra e interlaboratorias, tanto em relao ao fluxo do

acompanhamento dos atendimentos, como em relao s informaes

gerenciais associadas aos mesmos;

Objetivos do negcio, oportunidades abertas: dado o objetivo descrito no item

V.1.1, este projeto d a oportunidade de pesquisar sobre o processo para

especificao de requisitos de software com foco de aplicao no trabalho

cooperativo em sistemas de informao com coordenao distribuda nas

aes dos usurios;

Restries mais importantes da aplicao: a aplicao (software)

implementada possui como restrio o fato de no gerar os documentos

fsicos do processo de atendimento, assim como de no realizar a execuo

fsica do servio (gerenciar o equipamento do laboratrio que executa o

servio);

Fronteiras deste sistema e pontos de interface com outros sistemas de

informao (viso geral das entradas, sadas): a anlise preliminar do

diagrama de contexto e dos principais dados trocados com outros sistemas

mostraram que no existem informaes crticas que no possam fluir entre

os sistemas em razo das questes tecnolgicas (ver Figura V.2);

Metas de custo benefcio e a posio da aplicao dentro do contexto da

organizao: a relao custo/benefcio foi avaliada pela diretoria da empresa

PesqTec, como positiva para os resultados pretendidos e a posio da

aplicao foi discutida no item V.1.1.

Com relao aos dados do Quadro IV.1, as seguintes ponderaes so realizadas

com relao s questes que ainda no foram consideradas (ver Quadro V.1

abaixo).

164

Quadro V.1 - Anlise da viabilidade: respostas

Respostas sobre a anlise de viabilidade P: O sistema pode ser desenvolvido com a tecnologia existente, dentro das restries de custos e prazos?

R: Sim, a tecnologia que ser utilizada permite acesso em uma navegador na intranet da empresa PesqTec dentro das restries de custos e preos especificadas no oramento do projeto.

P: Este sistema deve ser integrado a outros j existentes?

R: Sim, aos sistemas de Custos e Preos, ao ERP da empresa, ao sistema de definio de nmeros de documentos tcnicos e ao sistema unificado de colaboradores da empresa, sendo que nenhuma destas conexes inviabiliza o projeto.

P: Como a empresa resolve o problema se este sistema no for implantado?

R: Ficar com o sistema de informao atual, desconectado e fragmentado, com os problemas discutidos no item V.1.1

P: Quais so os problemas com o processo corrente e como o novo sistema informatizado pode colaborar na soluo dos mesmos?

R: Ver item V.1.1

P: Quais so os ganhos diretos que este sistema pode fornecer para os objetivos de negcio?

R: Menos erros no atendimento aos clientes, verificao em tempo real da posio do servio requisitado pelo cliente, controle de oramentos enviados, controle de material enviado para anlise, integrao com outros softwares da empresa, posio em tempo real do faturamento do laboratrio e dos servios mais executados, maior eficincia e eficcia no atendimento s solicitaes dos clientes atravs de uma melhor interao entre os trabalhadores dos laboratrios e entre laboratrios, etc.

P: As informaes devero ser transferidas de e para outros sistemas da organizao?

R: Sim, mas no representam problemas tcnicos em sua execuo

P: Este sistema necessita de tecnologia que no foi utilizada previamente na empresa?

R: A tecnologia de TI empregada na implementao do software conhecida dentro da empresa em questo e a tecnologia para levantamento das caractersticas do trabalho cooperativo para este tipo de SI corresponde aplicao prtica desta pesquisa.

Fonte: elaborado pelo autor

V.1.3 Contexto conceitual: verificao da aplicabilidade do processo ao

sistema candidato

Antes de se aplicar o processo proposto nesta pesquisa, primeiro importante

verificar a aplicabilidade deste processo. Para tanto, preciso avaliar as seguintes

condies (ver item IV.3.2):

O sistema informatizado no exige grande quantidade de especificao

algortmica: o software a ser desenvolvido possui uma grande quantidade de

elementos de dados e relacionamento entre registros, pois se trata de um

sistema comercial do tipo workflow administrativo (ver Apndice A), em que o

processamento realizado, na grande maioria das vezes, com baixo

contedo algortmico (prioritariamente com operaes de escrita, leitura e

atualizao de informaes no banco de dados);

165

Os usurios devem estar dispostos e capazes de participar ativamente, assim

como o gerente do projeto: o desenvolvimento deste software foi solicitado

pelas reas tcnicas da empresa PesqTec. As equipes de usurios dos

diversos laboratrios sempre se mostraram interessadas em participar das

sesses em razo da necessidade deste tipo de soluo para os laboratrios;

O sistema informatizado possui muita interao com os usurios por

intermdio de transaes, no operando com muito processamento em lote: o

software que foi desenvolvido no trabalha com processamento em lote

(batch), possuindo prioritariamente transaes associadas a banco de dados;

O Sistema de Informao apresenta coordenao distribuda nas aes dos

usurios e a comunicao entre eles ocorre preponderantemente de modo

indireto por meio dos dados inseridos durante o uso do software, sendo este

(software) assncrono e desacoplado (ver item II.5.5).

Deste modo, o software proposto para dar suporte ao processo de acompanhamento

laboratorial atende s condies, para que o processo proposto seja aplicado.

V.2 CICLO 1: PROCESSO PARA ESPECIFICAO DE REQUISITOS DE

SOFTWARE COM FOCO NA IDENTIFICAO DAS

CARACTERSTICAS INDIVIDUAIS DO TRABALHO COOPERATIVO

V.2.1 Introduo

Este ciclo corresponde ao ciclo tradicional do desenvolvimento de software, em que

so levantadas as necessidades dos usurios de modo individual, sem considerar

plenamente os requisitos do trabalho cooperativo (na ER tradicional, o modelo dos

requisitos para o indivduo e no ao trabalho cooperativo).

O principal objetivo obter os artefatos de software (diagrama de contexto, o

fluxograma inicial do processo e as interfaces grficas, respectivas) necessrios

para o segundo ciclo da PA, sem uma preocupao maior com seu detalhamento,

uma vez que estes sofrero uma natural evoluo ao longo da aplicao do

166

processo, com uma consequente evoluo dos requisitos individuais do trabalho

concomitantemente com as caractersticas do trabalho cooperativo.

Estes artefatos so implementados no ciclo 2 (somente as navegaes, sem o

cdigo), sendo utilizados como ponto de partida (referencial comum) nas sesses

de ACT. Deste modo, neste ciclo, no haver uma preocupao mais

pormenorizada no levantamento dos requisitos do trabalho cooperativo.

No necessrio apresentar todos os artefatos construdos, dada a quantidade de

informao e, tambm, pelo fato que haveria repetio de aplicao do processo

proposto. Assim, sero escolhidos alguns dos artefatos como exemplo de aplicao.

O processo definido no item IV.4 ser aplicado integramente neste ciclo, mas no

sero apresentados os resultados das iteraes intermedirias do ciclo,

evidenciando-se somente parte dos artefatos de entrada (identificao das

caractersticas iniciais do sistema item IV.4.1) e os respectivos artefatos de sada

obtidos durante a simulao individual (item IV.4.2), aps as devidas iteraes.

V.2.2 Implementao

Identificao das caractersticas iniciais do sistema

A primeira iterao no ciclo da PA ocorre na identificao das caractersticas iniciais

do sistema, posteriormente, durante a iterao do ciclo, ser necessrio voltar para

esta etapa, mas agora na implementao/reviso do prottipo em papel (ver Figura

IV.10).

O levantamento do processo atual de atendimento (no automatizado), antes da

implantao do software de atendimento s solicitaes de servios correntes dos

laboratrios da empresa PesqTec, foi realizado nos diversos laboratrios por um dos

laboratrios da empresa, no qual o pesquisador como funcionrio desta empresa

tambm participou.

O material deste levantamento foi usado como subsdio, para que a diretoria da

empresa PesqTec decidisse pela aprovao do projeto para o desenvolvimento

deste software. importante ressaltar que os processos atuais de acompanhamento

dos diversos laboratrios da empresa PesqTec, de modo geral, tm em comum as

167

mesmas fases, pois estes devem sempre atender a uma srie de normas impostas

pela rea de qualidade da empresa.

O fluxograma inicial resultante do levantamento utilizado na primeira iterao para a

prototipao em papel apresentado na Figura V.1 abaixo e foi baseado na

sequncia-padro do atendimento dos laboratrios.

Constituio do

pedido

Anlise crtica do

contrato (ACC)

Habilitao da

execuo

Realizao do

trabalho

(documento

tcnico)

Encerramento do

trabalho

Registro de material sem ACC

Nova ACC Correo do documento

tcnico

Figura V.1 - Fluxograma inicial e respectivas fases: processo no informatizado Fonte: sistema de acompanhamento (documento interno da PesqTec)

Abaixo encontra-se descrita, de modo resumido, cada uma das fases. importante

ressaltar tambm que nem todas as atividades descritas que foram levantadas do

processo real, sero automatizadas e que o processo atual do SI sofrer alteraes

para atender informatizao de parte do mesmo.

Constituio do pedido: ocorre a habilitao da demanda para que possa ser

atendida dentro dos critrios de qualidade do laboratrio. Este conjunto de

atividades pode ser considerado de mbito administrativo e, normalmente, est sob

responsabilidade da secretria do laboratrio.

Principais atividades: registro de solicitao do cliente, consulta/cadastro de

clientes e montagem e distribuio do processo;

Principais entradas: pedido do cliente (dados iniciais do cliente);

Principais sadas: registro do pedido, identificao do responsvel e processo,

requisitos iniciais do cliente e cadastro do cliente.

Anlise crtica do contrato: verifica-se se a solicitao do cliente pode ser atendida

com os recursos disponveis no laboratrio que composta, geralmente, por uma

anlise tcnica, seguida de uma anlise financeira e a confeco da proposta

168

oramentria. Em geral, estas atividades so consideradas de mbito gerencial e

esto sob responsabilidade ou do responsvel pela rea, cuja competncia

atender ao pedido ou de um tcnico designado e reconhecido competente para o

atendimento.

Principais atividades: anlise tcnica, anlise financeira, editorao e

assinatura da proposta oramentria.

Principais entradas: registro do pedido, requisitos iniciais da solicitao do

cliente e atendimentos anteriores para o mesmo cliente;

Principais sadas: projeto da soluo tcnica, definio do escopo de

atendimento, plano de trabalho, proposta comercial e autorizao para

atendimento.

Habilitao da execuo: nesta fase, esto reunidas todas as etapas tpicas

relacionadas ao acompanhamento da tramitao da proposta oramentria junto ao

cliente e que habilitam a execuo do trabalho contratado pelo pessoal tcnico. Este

conjunto de atividades pode ser considerado de mbito administrativo e,

normalmente, est sob responsabilidade da secretria do laboratrio.

Principais atividades: envio da proposta de atendimento, monitorao da

proposta e recebimento do material;

Principais entradas: proposta comercial editada eletronicamente e autorizao

para o atendimento;

Principais sadas: proposta oramentria, formalizao da aceitao da

proposta e disponibilizao do material para realizao do(s) servios(s)

contratado(s).

Realizao do trabalho: registram-se as informaes decorrentes da realizao do

trabalho propriamente dita. Este conjunto de atividades de natureza tcnica e,

normalmente, est sob responsabilidade do responsvel pelo laboratrio ou do

tcnico designado.

Principais atividades: programao para execuo, inspeo tcnica,

recuperao ou editorao das planilhas de clculo para o servio realizado,

169

preparao do servio, aquisio e anlise dos dados, editorao e reviso

do documento tcnico;

Principais entradas: contrato assinado, material em que o servio ser

realizado, plano de trabalho, insumos e dispositivos especiais;

Principais sadas: documento tcnico revisado.

Encerramento do processo: todas as etapas tpicas pertinentes ao

acompanhamento da tramitao do atendimento esto reunidas no contexto da

emisso do documento tcnico final e nas providncias para seu encerramento. Este

conjunto de atividades pode ser considerado administrativo e, normalmente, est

sob responsabilidade da secretria do laboratrio.

Principais atividades: impresso do documento, verificaes finais, expedio,

encerramento do atendimento e pesquisa de satisfao.

Principais entradas: documento tcnico revisado (pronto).

Principais sadas: documento tcnico assinado e entregue ao cliente e

quitao do contrato.

Nos dados do Quadro V.2 abaixo, esto descritas, em linhas gerais, as situaes de

referncia do sistema atual (processo no informatizado) e as caractersticas futuras

do processo (informatizado).

Nesta fase, os principais requisitos de domnio identificados so:

Interface apropriada para troca de dados com o ERP da empresa;

Aplicao de normas da qualidade da empresa PesqTec no desenvolvimento

do software;

O software deve ser desenvolvido em plataforma internet, com banco de

dados centralizado;

Conexo do software de acompanhamento com outros softwares legados (ver

Figura V.8).

170

Quadro V.2 - Situaes de referncia e aes futuras provveis

Caractersticas do processo no informatizado (situaes de referncia)

Caractersticas do processo informatizado (ao caractersticas futuras provveis)

Informaes capilarizadas nos laboratrios Informaes centralizadas em um nico repositrio

Processo de atendimento fragmentado, com as informaes de cada uma das fases do processo guardadas em mdias diferentes (em cadernos de registro, em meio magntico e em fichrios).

Informaes armazenadas e recuperadas com mesmo formato.

Obteno de informaes sobre o processo (status do atendimento, estatsticas, faturamento, oramentos aprovados, etc.) de difcil recuperao, principalmente quando referentes ao conjunto dos laboratrios (agregadas).

Informaes de fcil recuperao, tanto as agregadas (referentes ao laboratrio ou aos laboratrios como um todo), como as informaes transacionais (referentes ao andamento do atendimento).

Processos utilizam informaes locais dos laboratrios, sem integrao com as informaes centralizadas da empresa (clientes, usurios, preos, etc.).

Integrao com outros sistemas informatizados da empresa.

Laboratrios possuindo processos prprios de atendimento (desnormalizados), gerando duplicaes de informao e dificuldade de trabalhos entre laboratrios (inter-laboratorias).

Normalizao do atendimento.

As atividade coletivas dos trabalhadores dos laboratrios nem sempre produzem os resultados esperados, podendo provocar duplicaes de servio, atraso no atendimento de solicitaes, erros na gerao de documentos ao longo do processo, etc.

Atravs de recursos adequados, o software desenvolvido dar suporte mais apropriado ao trabalho cooperativo, melhorando a eficincia e eficcia dos resultados esperados.

Fonte: elaborado pelo autor

O diagrama de contexto inicial definido durante esta fase poder ser visto na Figura

V.2 baixo:

Software de

acompanhamento

laboratorialUsurio

(rea de

contabilidade e

finanas)

Solicitao de abertura de

pedido

Informaes sobre o

processo de atendimento

Informaes sobre

clientes

Informaes sobre o

pedido de faturamento

Figura V.2 - Diagrama de contexto inicial do ciclo 1 Fonte: Elaborado pelo autor

Para completar a avaliao das caractersticas iniciais do sistema, as questes do

Quadro IV.2 que ainda no foram avaliadas, so resumidas nos dados do Quadro

V.3 abaixo.

171

Quadro V.3 - Identificao das caractersticas iniciais: respostas

Respostas sobre a identificao das caractersticas iniciais P: O que precisa ser suportado pelo software e o que no deve ser suportado?

R: Em termos gerais, este software no realizar o servio em si (realizao fsica dos ensaios por meio do controle dos equipamentos), fazendo o gerenciamento lgico de sua execuo (se foi realizado, ou no, por quais motivos, etc.) (ver item V.2.3).

P: Quem usar esta aplicao (criar uma lista de stakeholders)?

R: Tcnicos, secretrias e responsveis pelo laboratrio, gerentes administrativos e diretores da empresa PesqTec.

P: O software faz parte integral do trabalho dos usurios, ou ser usado s esporadicamente?

R: Para tcnicos, secretrias e responsveis pelo laboratrio, ser usado integralmente e para gerentes administrativos e diretores ser usado de modo parcial

P: Quais as conseqncias se um usurio cometer um erro, usando o sistema para as funcionalidades que esto sendo discutidas?

R: Os principais erros (em termos de macroprocesso) so: atendimento ao cliente errado ou informaes sobre o cliente escolhidas erroneamente, escolha errada de servios solicitados, registro de material indevido, nmero de documento tcnico no apropriado com o tipo de documento e valor cobrado indevidamente.

P: Existem usurios com pouca familiaridade no uso bsico de aplicaes informatizadas (inclusive uso em planilhas, navegadores, editores de texto, etc.)?

R: No caso da empresa PesqTec, em razo do tipo de servio oferecido ao cliente e como a empresa j possui vrias outras aplicaes que so baseadas em navegadores, os usurios no possuem deficincia crnicas no uso das tecnologias escolhidas.

P: Os usurios conhecem o processo que estar sendo automatizado?

R: Sim, para aqueles que so dos laboratrios (tcnicos, secretrias e responsveis pelo laboratrio).

P: Qual o perfil por execuo das tarefas que os usurios podem ser divididos?

R: Ver descrio do processo da Figura V.1

P: O que pode ser caracterizado como uma sada til que esta soluo pode fornecer?

R: Oramento para o cliente, numerao nica de registro de material e de oramento, associao automtica de documento tcnico e respectiva identificao, faturamento integrado ao processo e identificao nica do usurio.

Fonte: elaborado pelo autor

Finalmente em funo do fluxograma apresentado na Figura V.1, as seguintes

interfaces associadas aos mesmos foram desenhadas, utilizadas para o incio da

simulao com os usurios escolhidos:

172

Atualizao da Etapa: - Constituio do pedido

Voltar Sair

Responsvel: Data:

Encaminhamento:

Prxima Etapa: Responsvel:

Servio:

Calibrao (CC): Ensaio corrente (RE):

Ensaio (RT): Outros (descrever):

Cliente: Contato: E-mail / http:Data de recebimento

do pedido:

Solicitao efetuada atravs de:

Tipo: Cdigo: Data: Complemento:

Tipo: Cdigo: Data: Complemento:

E / Ou

1

1 - telefone

- visita

- carta

Telefone:

- fax

-e-mail

- outros

Atualizao da Etapa: - Anlise crtica do contrato

Cliente:

Servio:

Registro das aes na etapa:

Encaminhamento:

Prxima Etapa: Responsvel:

Nome (fantasia): CNPJ / CPF:

Contato: Fone: E-mail:

Natureza: Item:

2. Confirmao da Solicitao:

Calibrao (CC):

Ensaio (RT):

Ensaio corrente (RE):

Outros (descrever): Item:

3. Programao da ACC:

Incio: trmino: XX/XX/XXXX XX/XX/XXXX

Nmero do Processo (pasta) e Identificao do Item (etiqueta): XXXX

1. Contato com Cliente:

Data: Meio: Local:XX/XX/XXXX 2

2 - fone

- e-mail

- reunio

- carta

Voltar Sair

Responsvel: Data:

Encerramento da ltima Etapa:

4. Vincular ao processo:

Enviar Notificao

Figura V.3 - Constituio do pedido Figura V.4 - Anlise crtica do contrato

Atualizao da Etapa: Habilitao da execuo

Cliente

Servio

Registro das aes na etapa:

Encaminhamento:

Prxima Etapa: Responsvel:

Nome (fantasia): CNPJ / CPF:

Contato: Fone: E-mail:

Natureza: Item:

Observaes (quanto a pessoa contatada ou motivo de cancelamento):

Atualizar cadastro

Cancelamento verificado

Nmero do Processo (pasta) e Identificao do Item (etiqueta): XXXX

Verificao do interesse em: XX/XX/XXXX

Aprovao realizada por: 2

Voltar Sair

Responsvel: Data:

Encerramento da ltima Etapa: XX/XX/XXXX

Cdigo do documento de aprovao: Data: XX/XX/XXXX

Enviar consultaConsultar cliente por: 1

Atualizao da Etapa: - Realizao do trabalho

Cliente:

Servio:

Registro das aes na etapa:

Encaminhamento:

Nome (fantasia): CNPJ / CPF:

Contato: Fone:

Natureza: Item:

Nmero do Processo (pasta) e Identificao do Item (etiqueta): XXXX

Recuperar mscara / modelo:

Documento: No :

Somente para supervisores:

Recuperar arquivo

Documento salvo como:

Documento tcnico revisado:

Prxima Etapa: Responsvel:

3

- certificado de calibrao

- relatrio de ensaio

- relatrio tcnico

- parecer tcnico

3

Voltar Sair

Responsvel: Data:

Encerramento da ltima Etapa: XX/XX/XXXX

Destinao do item: 4

4 - reteno

- reteno parcial

- expedio

- descarte

Solicitao de No de Documento Tcnico

Figura V.5 - Habilitao do pedido Figura V.6 - Realizao do trabalho

173

Atualizao da Etapa- Encerramento do processo

Cliente:

Servio:

Registro das aes na etapa:

Encaminhamento:

Prxima Etapa: Responsvel:

Nome (fantasia): CNPJ / CPF:

Contato: Fone:

Natureza: Item:

Nmero do Processo (pasta) e Identificao do Item (etiqueta): XXXX

Recuperar / Editar / Imprimir:

Documento TcnicoPedido de Faturamento

Etiqueta de Devoluo do Item Etiqueta de Descarte do Item

Voltar Sair

Responsvel: Data:

Encerramento da ltima Etapa: XX/XX/XXXX

TODOS

Figura V.7 - Encerramento do processo

Implementao/reviso do prottipo em papel

Nesta fase do processo a implementao da interface e dos documentos foram

realizados e apresentados aos usurios na fase de simulao e resultaram na

deciso em continuar a simulao na fase de anlise dos dados.

Com relao ao diagrama de contexto (ver item II.7.4 Modelo de contexto, de

processo e de fluxo de trabalho), aps as discusses com os usurios sobre as

possveis interfaces com outros sistemas existentes (abordados na fase de

simulao) o diagrama final, aps as vrias iteraes no ciclo da PA pode ser visto

na Figura V.8 abaixo:

174

Software de

acompanhamento

laboratorial

Usurio

(rea de

contabilidade e

finanas)

Solicitao de abertura de

pedido

C&P

(Sistema para definio

do custo/preo do servio

orado)

Informaes sobre o

processo de atendimento

Informaes sobre

clientes

Informaes sobre o

pedido de faturamento

Solicitao de preo

de um dado servio

Figura V.8 - Diagrama de contexto final do ciclo 1 do software de atendimento laboratorial Fonte: elaborado pelo autor

J o fluxograma final est apresentado na Figura V.9 abaixo, tambm resultado da

simulao com os usurios, levando-se em conta o diagrama de contexto e as

interfaces grficas associadas a cada uma das fases.

Solicitao do

pedidoOramentao

Registro do

material

Realizao do

trabalho

Encerramento

do trabalho

Enquanto no aprovado

Dados

iniciais

Enviado ao

cliente AprovadoDocumento

pronto

Enquanto no aprovado

Figura V.9 - Fluxograma final do ciclo 1

Fonte: elaborado pelo autor

As interfaces grficas referentes aos processos da Figura V.9 foram evoluindo na

medida que uma nova iterao com os usurios ocorria (o resultado final das

interfaces pode ser visto nas figuras abaixo). Ressalta-se o fato que, embora estas

interfaces no tenham sido desenvolvidas na tecnologia alvo na qual o software ser

desenvolvido, as mesmas foram desenhadas para possuir compatibilidade com a

tecnologia adotada, pois no ciclo 2 da pesquisa-ao estas interfaces sero

reescritas j na plataforma alvo que ser implementada no ciclo 3.

175

Outro aspecto importante a ser destacado corresponde ao fato de que os usurios

dos laboratrios utilizam o termo processo para designar cada uma das fases do

fluxograma da Figura V.9 e o termo atendimento para se referirem ao processo

composto por estas fases. Visando a manter a coerncia com os termos utilizados

pelos usurios, na implementao dos artefatos sero utilizados os termos

processo para cada fase do fluxograma da Figura V.9 (que corresponde ao

processo) e atendimento para o processo.

SOLICITAO DO CLIENTE

Incluso de cliente cadastrado:

Encaminhamento:

Prxima etapa: Responsvel:

Voltar Sair

Responsvel: Data:

IncluirEscolha o cliente: 1

Descrio do pedido:

Para cliente novo:

Nome: CNPJ:

Contato: Fone: Ramal:

Incluir

2 3 Enviar Processo

Lista de todos os

clientes cadastrados

no ERP

1 Ver f igura V.92Lista com todos os

participantes do laboratrio

que so usurios do sof tware

3

ClienteNome (fantasia): CNPJ / CPF:Contato: Fone: Ramal:

Figura V.10 - Solicitao do pedido

176

ORAMENTAO

Escolha os servios do oramento:

Voltar Sair

Responsvel: Data:

Selecionar4

Descrio do Oramento:

Prazo (dias): Validade (dias):

Enviar para: Cpias para:

Enviar

Lista dos servios escolhidos

Enviar oramento por email:

Quantidade Descrio Valor unitrio Total

Anlise quantitativa de metais 200,00

Anlise quantitativa por volumetria 150,00

Total:

1

1

200,00

150,00

350,00

Solicitamos o envio de material de acordo

com a norma XPTO de 2006

5Responsvel pelo oramento:

Salvar

Encaminhamento:

Prxima etapa: Responsvel:

2 3 Enviar Processo

Lista de todos os

servios que o

laboratrio oferece

4Lista com somente aqueles

que so responsveis pelo

oramento

5

ClienteNome (fantasia): CNPJ / CPF:Contato: Fone: Ramal:

Figura V.11 - Oramentao

REGISTRO DO MATERIAL

Aprovao do oramento do oramento:

Voltar Sair

Responsvel: Data:

Descrio do Oramento:

Quantidade: Descrio: Registrar

Servios orados

Registro do material:

Solicitamos o envio de material de acordo com a norma

XPTO de 2006

AprovarAprovao : 6 xx/xx/xxxxData:

N Quantidade Descrio

123 1 Liga especial (identificao do cliente - WE 2345)

Quantidade Descrio Valor unitrio Total

Anlise quantitativa de metais 200,00

Anlise quantitativa por volumetria 150,00

Total:

1

1

200,00

150,00

350,00

Materiais registrados

Encaminhamento:

Prxima etapa: Responsvel:

2 3 Enviar Processo

- Em espera

- Recusado

- Aprovado

6

ClienteNome (fantasia): CNPJ / CPF:Contato: Fone: Ramal:

Figura V.12 - Registro de material

177

REALIZAO DO TRABALHO

Aprovao do oramento do oramento:

Voltar Sair

Responsvel: Data:

Lista dos servios

N Quantidade Descrio

123 1 Liga especial (identificao do cliente - WE 2345)

Quantidade Descrio Valor unitrio Total

1 Anlise quantitativa de metais 200,00 200,00

1 Anlise quantitativa por volumetria 150,00 150,00

Total: 350,00

Materiais registrados

Observaes: Status : 7

Elaborado por : 3 Aprovado por : 3

Salvar

Encaminhamento:

Prxima etapa: Responsvel:

2 3 Enviar Processo

- Em andamento

- Cancelado

- Concludo

7

ClienteNome (fantasia): CNPJ / CPF:Contato: Fone: Ramal:

Figura V.13 - Realizao do trabalho

ENTREGA DO TRABALHO

Resumo do oramento:

Voltar Sair

Responsvel: Data:

Lista dos servios

Quantidade Descrio Valor unitrio Total

1 Anlise quantitativa de metais 200,00 200,00

1 Anlise quantitativa por volumetria 150,00 150,00

Total: 350,00

350,00Valor final (R$):

Gerar Pedido de Faturamento Encerrar Processo

Dados para finalizao do processo:

Nmero : Tipo de documento : 8

Encaminhamento:

Prxima etapa: Responsvel:

2 3 Enviar Processo

8 - certif icado de calibrao

- relatrio de ensaio

- relatrio tcnico

- parecer tcnico

ClienteNome (fantasia): CNPJ / CPF:Contato: Fone: Ramal:

Figura V.14 - Entrega

178

V.2.3 Levantamento e discusso dos dados

Os usurios que participaram deste processo (ciclo 1) foram dois analistas de

negcios com grande conhecimento do SI a ser informatizado (ver item III.4),

escolhidos de dois laboratrios com tipos de produtos complementares oferecidos

aos clientes, de modo a compor vrias das opes oferecidas pela empresa

PesqTec.

Neste ciclo, quatro iteraes foram realizadas com durao total de

aproximadamente 2 meses, com incio em fevereiro de 2006 e trmino em maro de

2006. Inicialmente, alm do fluxograma simplificado da Figura V.1, foi apresentado a

estes usurios para simulao do software, um conjunto de interfaces grficas

representativas do fluxograma, a descrio dos processos e o diagrama de contexto

(item V.2.2 - identificao das caractersticas iniciais do sistema).

A simulao das aes caractersticas futuras em funo das situaes de

referncia (Quadro V.2), foi realizada, utilizando a tcnica apresentada no item

IV.4.2, de modo que os artefatos acima descritos foram sucessivamente refinados

por meio de vrias iteraes, utilizando-se tambm como referncia as questes do

Quadro IV.3 e suas respectivas respostas nos dados do Quadro V.4 abaixo.

Quadro V.4 - Simulao do prottipo em papel: respostas

Questes bsicas sobre a simulao em papel P: Qual o trabalho realizado pelos diferentes tipos de usurios e em que circunstncias?

R: Ver descrio das fases deste item

P: Quais so as tarefas e sub-tarefas realizadas enquanto os usurios executam suas atividades?

R: De acordo com a descrio das fases deste item

P: Qual a seqncia do trabalho realizado workflow do processo em detalhes?

R: Ver Figura V.9

P: Dentro dos processos, qual a hierarquia das atividades?

R: A hierarquia ser tratada com detalhes no ciclo 2 da PA. Neste ciclo somente so listadas as principais sub-atividades.

Fonte: elaborado pelo autor

Ao se analisar em primeiro lugar a evoluo do diagrama de contexto inicial (Figura

V.2) e o digrama de contexto final (Figura V.8), pode-se notar a existncia de uma

nova entidade externa denominada de Custos e Preos. Esta entidade um

software responsvel pela anlise crtica do contrato (ACC), cujas atividades

179

(anlise tcnica, seguida de uma anlise financeira) sero realizadas fora do

software de acompanhamento laboratorial.

A razo para que a fase de ACC fosse realizada fora do sistema de

acompanhamento, foi sobretudo para que os estudos dos custos e preos dos

servios pudessem ser reaproveitados, assim como as anlises associadas,

deixando para o sistema de acompanhamento realizar as adaptaes especficas

necessrias a um dado oramento. Deste modo, a fase de anlise crtica do contrato

foi substituda pela fase de oramentao, fase esta que se utilizar das planilhas de

servios criadas no software de Custos e Preos.

A descrio resumida das fases do fluxograma da Figura V.9 realizada abaixo. As

atividades que no sero realizadas pelo software, so indicadas nesta descrio.

Solicitao do pedido (Constituio do pedido): ocorre a habilitao da demanda,

para que possa ser atendida dentro dos critrios de qualidade do laboratrio. Este

conjunto de atividades realizado, em geral, pela secretria do laboratrio, mas

pode tambm ser feito por qualquer participante do laboratrio.

Principais atividades: registro de solicitao do cliente, consulta/cadastro de

clientes e montagem e distribuio do processo fsico (no realizada pelo

software);

Principais entradas: pedido do cliente (dados iniciais do cliente);

Principais sadas: registro do pedido, identificao do responsvel desta fase

do processo, se houver necessidade um estudo no sistema de Custos e

Preos e cadastro do cliente.

Oramentao (Anlise crtica do contrato): realizada a confeco da proposta

oramentria composta das informaes referentes aos servios que so

pesquisados no sistema de Custos e Preos. A responsabilidade pelo oramento ou

um tcnico designado e reconhecido competente para o atendimento, ou do

responsvel pela rea cuja competncia atender ao pedido, mas o envio do

oramento pode ser realizado por qualquer participante do laboratrio.

Principais atividades: editorao, assinatura e envio da proposta

oramentria.

180

Principais entradas: registro do pedido, projeto da soluo tcnica e servios

anteriores para o mesmo cliente (oriundos do sistema de Custos e Preos);

Principais sadas: definio do escopo de atendimento, plano de trabalho (no

realizado pelo software), envio de proposta comercial.

Registro de material (Habilitao da execuo): nesta fase, ocorre o

acompanhamento da tramitao da proposta oramentria junto ao cliente, a

aprovao da mesma e o registro do material para incio da realizao dos servios.

Este conjunto de atividades pode ser realizado por qualquer participante do

laboratrio, sendo normalmente realizado pela secretria do laboratrio ou um

tcnico.

Principais atividades: monitorao e aprovao da proposta e recebimento do

material para execuo do servio;

Principais entradas: proposta comercial editada, autorizao para o

atendimento e chegada do material para registro;

Principais sadas: proposta oramentria aprovada (autorizao para

atendimento) e disponibilizao do material para realizao do(s) servios(s)

contratado(s).

Realizao do trabalho: As informaes decorrentes da realizao do trabalho

propriamente dito so registradas, assim como quem elaborou e aprovou o

documento tcnico relativo a este atendimento. O conjunto de atividades de

natureza tcnica e, normalmente, est sob responsabilidade do responsvel pelo

laboratrio, ou do tcnico designado, e na falta deste pode ser realizado por

qualquer participante do laboratrio.

Principais atividades: programao para execuo (no sistema de Custos e

Preos), inspeo tcnica do material recebido, recuperao ou editorao

das planilhas de clculo para o servio realizado (o software no faz a guarda

dos documentos fsicos do processo de atendimento), preparao do servio

(executado pelo tcnico, no realizado pelo software), aquisio e anlise dos

dados (o software proposto no atua no cho de fbrica, isto , na aquisio e

181

anlise dos dados) e editorao e reviso do documento tcnico (o software

no faz a guarda dos documentos fsicos do processo de atendimento);

Principais entradas: oramento aprovado, material em que ser realizado o

servio, plano de trabalho (no sistema de Custos e Preos) e insumos e

dispositivos especiais (material fsico do laboratrio);

Principais sadas: documento tcnico revisado (o documento fsico no

controlado pelo sistema) e informao sobre o trmino dos trabalhos e da

elaborao do documento tcnico.

Encerramento do processo: esto reunidas todas as etapas tpicas pertinentes ao

acompanhamento da tramitao do atendimento no contexto da emisso do

documento tcnico final e providncias para seu encerramento. Este conjunto de

atividades pode ser considerado administrativo e, normalmente, est sob

responsabilidade da secretria do laboratrio, mas pode ser realizado por qualquer

participante do laboratrio.

Principais atividades: definio do tipo de documento tcnico e respectivo

valor final, gerao do pedido de faturamento, impresso do documento e

verificaes finais (o software no faz a guarda dos documentos fsicos do

processo de atendimento) e encerramento do atendimento;

Principais entradas: informao sobre a execuo dos servios e sobre o

trmino da elaborao do documento tcnico e documento tcnico revisado (o

software no faz a guarda dos documentos fsicos do processo de

atendimento).

Principais sadas: documento tcnico assinado e entregue ao cliente (o

software no faz a guarda dos documentos fsicos do processo de

atendimento), realizao do faturamento e encerramento do processo de

atendimento.

As interfaces grficas finais definidas no item V.2.2 (Implementao/reviso do

prottipo em papel) refletem as descries das fases descritas acima, de modo que

possvel fazer o seguinte recorte relativo ao software que implementar parte

deste sistema em funo do processo no automatizado:

182

A fase de anlise crtica do contrato foi substituda pela fase de

oramentao. Inicialmente, a anlise crtica deveria ser desenvolvida no

prprio software de acompanhamento, mas, aps os refinamentos, optou-se

por desenvolver esta funcionalidade em outro sistema independente

denominado Custos e Preos;

O software de acompanhamento laboratorial no executa o controle dos

equipamentos dos laboratrios (fazer aquisio automtica de dados e

execuo do documento tcnico equivalente), conforme pode ser visto na

fase de realizao do trabalho, sendo utilizado sobretudo com a funo de

gerenciar o acompanhamento lgico de um processo de atendimento;

Toda a documentao fsica relacionada a um dado atendimento, ligada

sobretudo aos dados coletados durante a execuo dos servios e a

realizao do documento tcnico que contempla a anlise destes dados

(documentao denominada de processo de atendimento), ter um controle

lgico pelo sistema, mas o processo fsico no ser custodiado (guardado) no

banco de dados do software.

Finalmente, a anlise entre o fluxograma inicial (ver Figura V.1) e o final (ver Figura

V.9) mostra que sero necessrias travas lgicas, para que o processo de workflow

possa fluir entre as fases (o que no ocorre com o SI), como por exemplo, na fase

de registro de material, na qual o processo de atendimento s seguir adiante pela

implementao do workflow do processo pelo software se houver aprovao do

pedido pelo cliente e uma vez aprovado o processo no poder mais retornar para

as fases de oramentao e solicitao de pedido.

V.2.4 Anlise e planejamento do ciclo 1

Durante cada interao no ciclo 1, antes de uma nova volta no ciclo de iterao

verificado se os artefatos produzidos esto refinados o suficiente para seguirem

para o ciclo 2 da PA. Para tanto, de acordo com o item IV.4.3, esta fase estar

terminada quando na iterao atual (neste caso na quinta iterao) os dois usurios

que participaram da simulao concordarem que a :

183

A interface e demais documentos associados implementam as principais

atividades definidas pelos usurios de modo correto;

A sada para o prximo passo ocorre quando se obtm a aprovao dos

usurios entrevistados na simulao;

Os usurios concordam que o fluxo geral do processo foi mapeado.

Estas condies foram observadas aps a simulao da quinta iterao, e os

artefatos produzidos na iterao, na fase de implementao, no sofreram

alteraes.

Os dados do Quadro V.5 abaixo mostram as respostas s questes citadas no

Quadro IV.4 e que devem ser avaliadas pelos projetistas do software para definio

do trmino deste ciclo.

Quadro V.5 - Avaliao sobre trmino da prototipao em papel: respostas

Questes bsicas sobre avaliao sobre trmino da prototipao em papel P: Cada requisito est consistente com o objetivo global do sistema?

R: Neste caso, cada requisito desenvolvido neste ciclo atravs dos artefatos de software descritos est de acordo com o objetivo do software.

P: Este requisito realmente necessrio, ou uma caracterstica adicional que pode no ser essencial aos objetivos do sistema?

R: Esta questo sempre foi avaliada de modo recorrente em cada ciclo de iterao pelos projetistas.

P: Cada requisito est bem delimitado e claro?

R: Neste caso a avaliao sob a tica do projetista, depois da concordncia dos dois analistas de negcio. No final do ciclo os dois analistas validaram a descrio das fases do processo no item V.2.3.

P: Algum requisito conflita com algum outro?

R: Esta situao sempre foi recolocada junto aos dois analistas de negcio em cada iterao do ciclo.

P: O requisito pode ser testado depois de implementado?

R: Os requisitos foram avaliados pelos projetistas sempre sob a possibilidade da criao de testes durante a simulao com os usurios.

P: Os artefatos desenvolvidos aqui representam corretamente estes requisitos, com relao ao seu comportamento, funcionalidade e dados?

R: No ciclo 1 somente possvel verificar a questo da funcionalidade, sendo que o comportamento e dados devero ser avaliados em ciclos posteriores.

Fonte: elaborado pelo autor

Para o ciclo 2, so montadas sesses de ACT com usurios representativos dos

diversos laboratrios da empresa. Nesta pesquisa, foram convidados oito

pesquisadores, em geral, responsveis pelos laboratrios ou pela rea da qualidade,

para participarem das sesses, e os temas abordados foram apresentados ou

discutidos na sesso do ciclo anterior e, tambm, utilizados para familiaridade com

os mesmos pelos pesquisadores participantes das sesses de ACT (ver item VI.2).

184

V.2.5 Concluses do ciclo 1 (passo de monitoramento da PA)

Este ciclo teve como principal objetivo obter os artefatos de software necessrios

para sua utilizao no ciclo 2 da PA, pela aplicao dos conceitos de ER tradicional

em sistemas de informao. Os resultados obtidos respondem questo (ver item

III.4.3) :

Como, pelas contribuies individuais dos stakeholders, estabelecer os

principais artefatos necessrios para a simulao do trabalho cooperativo por

meio do software que ser implementado?

Os artefatos para este ciclo correspondem ao fluxograma final do processo (ver

Figura V.9), o diagrama de contexto final (ver Figura V.8), as interfaces grficas

(Figura V.10, Figura V.11, Figura V.11, Figura V.12, Figura V.13 e Figura V.14) e a

descrio dos processos (ver item V.2.3).

Com relao aos requisitos de sistema, a anlise dos artefatos construdos mostra

dois aspectos:

Todas as fases representadas pelas interfaces grficas implementam o

workflow por meio de duas listas, contendo as prximas fases possveis,

assim como para qual usurio estas podero ser enviadas;

O fluxograma final (ver Figura V.9) e a descrio das atividades realizadas

pelos dois usurios mostram que embora exista uma sequncia mais comum

para as fases do workflow, estas podem ter muitos caminhos alternativos,

assim como no existe uma coordenao centralizada para definir o

andamento deste fluxo, com a possibilidade de que praticamente todos os

usurios dos laboratrios possam ser responsveis pelas fases (coordenao

distribuda e horizontal, ver item VII.2.3).

185

VI CICLO 2 DA PESQUISA-AO: PROCESSO PARA

ESPECIFICAO DE REQUISITOS DE SOFTWARE COM FOCO

NA IDENTIFICAO E SIMULAO DAS CARACTERSTICAS DO

TRABALHO COOPERATIVO

Este ciclo tem como objetivo a obteno dos requisitos e modelos do sistema

utilizados como ponto de partida para o projeto do software, acentuando-se a

definio dos requisitos do usurio e dos requisitos funcionais de alto nvel (uma vez

que adotada uma soluo evolucionria), com foco sobretudo na evoluo dos

requisitos do trabalho cooperativo.

VI.1 INTRODUO

O processo proposto comea com a entrada dos artefatos que foram desenvolvidos

durante o processo anterior (ciclo 1 da PA) e que sero usados como base inicial na

atividade de implementao/reviso deste ciclo da PA.

Neste ciclo, sero implementados os diagramas de navegaes e interfaces

grficas, assim como os fluxogramas detalhados do processo e o diagrama de

contexto necessrios para serem utilizados como elemento de representao

comum entre os pesquisadores e os demais participantes das sesses.

Assim como foi considerado no ciclo, neste ciclo ser escolhida uma parte dos

artefatos desenvolvidos durante as iteraes, como exemplo de aplicao do

processo proposto, dada a quantidade de informao e, tambm, pelo fato de que

haveria repetio de aplicao do processo.

Conforme apresentado no item IV.5, optou-se pela tcnica de prototipao no

funcional, com o desenvolvimento de prottipos sucessivos do software, oferecendo

uma representao comum para se comunicar com os usurios e os projetistas

(utilizados como imagem do sistema - item II.3), constituindo tambm um guia para a

especificao de sucessivas verses. Os prottipos foram apresentados aos

usurios para discusso coletiva, utilizando-se a tcnica de ACT, partindo-se das

186

situaes de referncia do trabalho dos usurios pela prpria voz destes e

projetando-se as aes caractersticas do futuro sistema informatizado.

VI.2 DINMICA DA ITERAO DO CICLO 2

VI.2.1 Dados do grupo e do ambiente das sesses

Ao todo foram executadas seis iteraes neste ciclo da PA, com intervalo entre 3 a 4

semanas entre os passos de levantamento e a discusso dos dados (ou sesses),

com durao entre 1h30 a 2h30 cada sesso e 2 a 3 dias para o passo de

implementao, e em torno de 1 semana para o passo de anlise e planejamento.

Estas iteraes iniciaram-se em outubro de 2006 e terminaram em maro de 2007.

O nmero de participantes de cada sesso foi de seis a oito pessoas, sendo que

alm dos dois participantes do ciclo 1 (tcnicos de dois laboratrios com

conhecimentos da dinmica das regras do negcio dos demais laboratrios), foram

convidados outros quatro representantes de laboratrios (permitindo assim o relato

de cada segmento sobre o objeto da avaliao), assim como um representante da

diretoria e outro da qualidade da empresa PesqTec.

Todos possuam curso superior completo e estavam acostumados a utilizar

aplicaes WWW disponveis na intranet da empresa (portanto, com conhecimentos

homogneos com relao tecnologia e s regras de negcio).

Apesar do projeto ser institucional, todos os participantes convidados concordaram

prontamente em participar das reunies. As sesses foram todas realizadas dentro

da empresa, mas em ambiente isolado da situao de trabalho dos participantes (as

datas das reunies foram marcadas, sempre que possvel, com antecedncia

necessria visando justamente a esta possibilidade).

No ambiente onde as sesses foram realizadas, foram apresentadas aos

participantes partes do prottipo a serem discutidas na sesso corrente por meio de

um equipamento multimdia conectado a um microcomputador utilizado por um dos

pesquisadores para orientar a realizao das sesses e as observaes feitas pelos

participantes, alm de quadro para desenho.

187

As sesses sempre foram conduzidas por dois pesquisadores, e um deles foi

responsvel por anotar ou gravar (com o consentimento dos participantes) partes da

sesso, auxiliar o outro pesquisador na conduo do grupo, tomar nota das

principais impresses verbais e estar atento aparelhagem multimdia.

Ao outro pesquisador, coube a conduo da sesso, permitindo a discusso dos

vrios pontos de vista dos participantes, mas sempre atento aos objetivos da sesso

e da demanda como um todo, permitindo assim, maior diretividade da sesso

corrente. Este pesquisador, tambm, procurou promover a participao de todos,

evitando a disperso dos objetivos da discusso e a monopolizao de alguns

participantes sobre outros, alm de ouvir as diversas observaes sobre o assunto

que estava sendo apresentado.

VI.2.2 Dinmica geral das iteraes

A Figura VI.1 abaixo mostra a sequncia de iterao para este ciclo de PA .

Monitoramento

Anlise e planejamentoANLISE (N);....;

ImplementaoIMPLEMENTAO (N)(N+1)

Levantamento e discusso

dos dadosSESSO (N);....;

Passos da pesquisa-ao

FASES DO PROTTIPO: CICLO 2

Artefatos do ciclo1

Incio de um novo ciclo de interao (N), (N+ 1)

Trmino do ciclo de interao atual (N)

Figura VI.1 - Passos da Pesquisa-ao e correspondentes atividades Fonte: elaborado pelo autor

Procurou-se dividir cada sesso de apresentao em duas partes. Na primeira,

foram apresentados temas para detalhamento da validao e fechamento (temas

188

estes que foram discutidos na segunda parte da sesso da iterao anterior). Na

segunda parte da sesso corrente, novos assuntos foram discutidos (e foram, em

geral, listados na segunda parte da sesso da iterao anterior) sendo sugerido

tambm aos participantes que elegessem assuntos para discusso na segunda

metade da sesso da iterao seguinte e, assim, possibilitar que os artefatos

correspondentes fossem preparados ou, pelos menos, esboados para discusso do

grupo (Figura VI.2).

Tanto na primeira, como na segunda parte da sesso, os artefatos para esta

discusso foram implementados no passo de implementao da iterao corrente

(Figura VI.2), com a diferena que os artefatos da primeira parte foram detalhados

para validao, e os artefatos da segunda parte foram esboados, j que os

mesmos seriam ainda detalhados. Neste passo, tambm, foram detalhados alguns

artefatos para o projeto e codificao do software no ciclo 3 e que no sero

abordados neste trabalho. Gonalves et al. (2005) detalham alguns artefatos de

implementao do software.

Na iterao corrente, no passo de anlise e planejamento, foram realizadas

entrevistas individuais de detalhamento com um ou mais participantes da sesso

sobre o que foi discutido na segunda parte da sesso (ou na primeira, caso o

detalhamento fosse insuficiente). Estes artefatos, posteriormente, foram construdos

no passo de implementao no incio da prxima iterao (Figura VI.2). Desse

modo, a prxima sesso contaria com artefato(s) mais adequado(s) para validar o

que foi discutido na segunda parte da sesso anterior, assim como permitiria a

apresentao de novos assuntos em sua segunda parte.

No passo de anlise e planejamento, tambm, verificou-se a necessidade de se

realizar uma nova iterao ou se o ciclo poderia terminar (quando o grupo no era

mais capaz de produzir novidades em suas discusses foi sinal de que se conseguiu

mapear o tema para os quais a pesquisa foi dirigida).

189

Implementao

Anlise e

planejamento

Sesso N-1

Parte1

Discusso/

Validao

Parte 2

Novo

detalhamento/

Novos

assuntos

Implementao

Anlise e

planejamento

Sesso N

Parte1

Discusso/

Validao

Parte 2

Novo

detalhamento/

Novos

assuntos

Iterao N-1 Iterao N

Entrevistas individuais

(quando necessrias)Informaes p/

detalhamento dos

artefatos

Artefatos p/ validaoArtefatos p/ discusso/

detalhamento/novos assuntos

Figura VI.2 - Dinmica das iteraes do ciclo 2 Fonte: elaborado pelo autor

A primeira iterao serviu para apresentao dos participantes do grupo, dos

objetivos, da forma de discusso e os principais artefatos que foram desenvolvidos

no ciclo 1 e implementados na tecnologia utilizada (plataforma WWW), assim como

de uma discusso dos prximos passos.

A segunda iterao tratou da validao da navegao de algumas fases, em

particular, a oramentao, considerando o aspecto ligado ao ambiente

multilaboratorial, no abordado no ciclo 1, alem de discutir e detalhar o fluxograma

do processo de negcio, e discutir as demais fases (mais cooperativas). A terceira

validou o fluxograma e a distribuio de tarefas e responsabilidades, bem como

detalhou as fases restantes do processo de atendimento.

A quarta iterao validou as fases discutidas na terceira iterao, e tambm discutiu

a necessidade da criao de objetos para coordenao do trabalho cooperativo. A

quinta iterao validou os artefatos de coordenao e passou a discutir relatrios

especficos para o andamento do trabalho dos participantes dos grupos. Finalmente,

a ltima concluiu com a validao do ciclo 2, como um todo.

190

VI.3 RESULTADOS (DETALHAMENTO DAS ITERAES)

VI.3.1 Iterao 1

Na primeira iterao deste ciclo, no passo de implementao, no incio, os artefatos

produzidos no ciclo1 foram convertidos em linguagem DHTML, tais como: as

interfaces grficas e respectivas navegaes, o fluxograma do processo (respectivos

mapas de navegaes), bem como o diagrama de entidade-relacionamento do

banco de dados (para fins de projeto).

Em particular, na confeco das interfaces grficas e navegaes, foram

desenvolvidos formulrios DHTML, com menus, entradas do tipo texto com mltiplas

linhas ou entradas do tipo texto com um nico campo e botes do tipo radio ou

checkbox. Como elementos de interao, foram utilizados os botes de envio

(submit), ou cones especficos para navegao, assim como validaes DHTML em

parte dos campos de entrada de dados.

Para a segunda parte da sesso, tambm foi complementado o diagrama de

navegao da fase de oramentao, em razo de apresentar uma interface com o

software de Custos e Preos que no foi detalhada no ciclo 1 (ver item V.2.3).

Na primeira sesso, os participantes apresentaram-se, e os pesquisadores fizeram

esclarecimentos a respeito dos objetivos da pesquisa e apresentaram um conjunto

de regras para melhor encaminhamento das sesses:

Deixaram claro que todas as opinies interessavam e, portanto, no existiam

opinies certas ou erradas, ressaltaram a importncia das manifestaes

individuais contra ou a favor;

A durao prevista para a sesso;

A dinmica da sesso, conforme descrito em VI.2.2;

Dentro do possvel, s uma pessoa falaria por vez;

Evitar discusses paralelas, de modo que todos pudessem participar.

Antes que a primeira sesso fosse realizada, a documentao gerada no ciclo 1 foi

enviada aos participantes para que pudessem avaliar o material de referncia sobre

os requisitos do processo at ento levantados.

191

Na primeira parte da sesso, inicialmente os artefatos do ciclo 1 foram apresentados

aos participantes, em particular, as interfaces grficas j convertidas para o formato

DHTML (como exemplo, na Figura VI.3 encontra-se a fase de oramentao do ciclo

1 e na Figura VI.4 aps a converso) para seu conhecimento mais detalhado e

esclarecimentos de dvidas a seu respeito.

ORAMENTAO

Escolha os servios do oramento:

Voltar Sair

Responsvel: Data:

Selecionar4

Descrio do Oramento:

Prazo (dias): Validade (dias):

Enviar para: Cpias para:

Enviar

Lista dos servios escolhidos

Enviar oramento por email:

Quantidade Descrio Valor unitrio Total

Anlise quantitativa de metais 200,00

Anlise quantitativa por volumetria 150,00

Total:

1

1

200,00

150,00

350,00

Solicitamos o envio de material de acordo

com a norma XPTO de 2006

5Responsvel pelo oramento:

Salvar

Encaminhamento:

Prxima etapa: Responsvel:

2 3 Enviar Processo

Lista de todos os

servios que o

laboratrio oferece

4Lista com somente aqueles

que so responsveis pelo

oramento

5

ClienteNome (fantasia): CNPJ / CPF:Contato: Fone: Ramal:

Figura VI.3 - Oramentao (reproduo do ciclo 1)

A presena dos dois tcnicos que, tambm, participaram do primeiro ciclo foi

importante para ajudar esclarecer as dvidas iniciais a respeito das fronteiras entre o

SI e o sistema a ser informatizado, bem como com relao ao fluxograma inicial do

processo e suas respectivas interfaces.

192

Figura VI.4 - Fase de oramentao: interface em DHTML

Esta fase foi mais bem detalhada pelos participantes, sobretudo, durante a segunda

parte da sesso, visto que o envio do oramento de forma automtica por email era

uma antiga reivindicao dos laboratrios.

Por exemplo, a lista da opo Escolha os servios do oramento: da Figura VI.4-1

no mostrava todas as informaes necessrias para escolha do servio, de modo

que se decidiu pela construo de uma opo de navegao para interfacear

diretamente com o software de custos e preos (ver Figura VI.5). Outra situao

correspondeu opo: Encaminhamento do email (Figura VI.4-2), na qual ficou

claro que ela deveria ser aberta em novas subopes para compor adequadamente

as informaes do email enviado ao cliente (por exemplo, uma descrio mais

detalhada de cada servio, observaes sobre a quantidade do material a ser

enviado, etc.).

A Figura VI.5 abaixo corresponde ao diagrama simplificado de navegao,

considerando-se as novas navegaes discutidas na Figura VI.4.

193

OramentaoInserir servio

L E G E N D A S

OramentaoServio inserido

Servios j inclusosno oramento

Voltar inclui servio escolhido

V Voltar a pgina de origem

Sai do sistemaS

Pesquisa deservio no software de

Custos e Preos

Inclui novoServiocliente

Pesquisarservios

correntes

VV

Processo de oramentao

Pgina pai

Sub-fase de pesquisar e inserir servios

Pgina filho

S SV V

Oramento completo

V SSub-fase de detalhamento do email

Pgina filho

Compororamento

Figura VI.5 - Diagrama simplificado de navegao da fase de oramentao: Inserir servio do laboratrio

Durante a discusso da navegao desta fase, um importante aspecto emergente foi

levantado pelos participantes: o fato de um laboratrio poder compor um oramento

com oramentos realizados por outros laboratrios (multilaboratorial). Neste caso,

todos os demais laboratrios encaminhariam oramentos a este laboratrio que,

ento, os enviaria aos cliente, tornando-se o nico responsvel frente a este cliente.

A questo foi muito debatida na sesso, j que vrios responsveis por laboratrios

comentaram que, atualmente, no envio de um oramento desse tipo, cada

laboratrio envia o seu de modo independente ou o laboratrio responsvel envia

todos os demais oramentos com o dele, ficando difcil para o cliente analisar o

conjunto de oramentos recebidos, sobretudo, pela sua falta de padronizao.

Ficou claro, tambm, pelas observaes dos participantes, que o fluxo inicial

levantado (reproduzido na Figura VI.6 abaixo), no era representativo de todas as

situaes encontradas nos fluxos de atendimento dos laboratrios e que o mesmo

deveria ser revisado (ver Figura VI.10), pois a relao entre o material registrado e a

realizao do trabalho no era necessariamente um para um (a execuo de um ou

mais servios sobre um material poderia ser realizada por um ou mais usurios,

dependendo da especializao dos mesmos em executar determinados servios).

194

Solicitao do

pedidoOramentao

Registro do

material

Realizao do

trabalho

Encerramento

do trabalho

Enquanto no aprovado

Dados

iniciais

Enviado ao

cliente AprovadoDocumento

pronto

Enquanto no aprovado

Figura VI.6 - Reproduo do fluxograma final do ciclo 1

Aps o trmino da sesso, o detalhamento da navegao da oramentao e de

suas respectivas interfaces foram detalhados nos passos de anlise e planejamento

da PA com dois usurios designados na segunda parte da sesso. Considerou-se

alm das questes relativas Figura VI.4, tambm, a questo do oramento

multilaboratorial, assim como os dados importados do software de Custos e Preos.

Como prximos objetivos, o fluxo do processo tambm foi mais bem detalhado para

servir como elemento inicial na segunda parte da prxima sesso.

VI.3.2 Iterao 2

Em funo do que foi discutido pelos participantes na segunda parte da sesso

anterior (iterao 1) e dos detalhamentos realizados com os dois usurios

designados no passo da anlise e planejamento da iterao anterior, foram

construdas, no passo de implementao desta iterao, as principais interfaces

grficas da fase de oramentao e o respectivo diagrama de navegao,

associados a uma caracterstica emergente discutida na sesso anterior: o

oramento multilaboratorial.

Visando, tambm, a preparao para a segunda sesso, foi elaborada uma reviso

no fluxo de processo como um todo, j que devido participao de representantes

de laboratrios diferentes, algumas variaes importantes foram discutidas, a partir

do fluxo principal levantado no ciclo 1.

Na primeira parte da sesso desta iterao, foi apresentado aos representantes dos

laboratrios para discusso e validao o diagrama de navegao e as interfaces

195

associadas fase de oramentao. Na Figura VI.7 abaixo, pode ser vista a

interface grfica da fase de oramentao, j considerando a questo do oramento

multilaboratorial e as mudanas apresentadas na Figura VI.4 e na Figura VI.5.

Assim, a escolha dos servios do laboratrio (Figura VI.4-1) foi substituda pela

opo 1 da Figura VI.7 (pesquisar servios correntes do laboratrio), dando mais

flexibilidade ao usurio na escolha de um servio realizado pelo prprio laboratrio

(Figura VI.8), onde esta figura mostra que o usurio pode fazer uma escolha por

nome de servios (opo 1), excluir servios (opo 2) j includos (opo 3), ou ver

detalhes do oramento (opo 4 o servio no pde ser inserido, pois no tinha

preo final).

Com relao ao oramento multilaboratorial, a opo 2 da Figura VI.7 (pesquisar

oramento interno) permitiu ao usurio escolher um oramento interno enviado por

outro laboratrio (no caso do exemplo o laboratrio Teste 2 - diagrama de

navegao da Figura VI.9 ), cujo retorno corresponde opo 3 da Figura VI.7.

Por fim, a opo 4 da Figura VI.7 corresponde ao detalhamento de um oramento

mostrado na Figura VI.4-2.

196

Figura VI.7 - Oramentao multilaboratorial

Figura VI.8 - Dados utilizados do sistema Custos e Preos

197

Inserir serviointerno (Multi_lab)

L E G E N D A S

Oramento Interno inserido ou servio do

prprio laboratrio inserido

Oramentos internos j inclusos

no oramento

V Voltar a pgina de origem

Sai do sistemaS

Pesquisa deOramentos internos enviados por outros

laboratrios

Inclui novoOramento

interno

PesquisarOramento

internos

VV

Fases de oramentao

Pgina pai

Subfase de pesquisar e inserir oramentos gerados e

enviados por outros laboratrio para o laboratrio em questo

Pgina filho

S SV

Oramento completo

V SSubfase de detalhamento do email

Pgina filho

CompororamentoVoltar inclui servio escolhido

V

OBRI

Dados obrigatrios

Enviar para:

Referncia:

Validade oramento:

Prazo de entrega:

Responsvel:

OBRI

Figura VI.9 - Diagrama simplificado de navegao da fase de oramentao: inserir oramento gerado por outro laboratrio

A fase inicial da abertura de uma nova solicitao de pedido (fase de solicitao do

pedido), tambm, foi lembrada pelos participantes, j que um pedido deve ser aberto

pelo usurio, antes de ser orado. Assim, a cada pedido seria associado um nmero

nico de atendimento para toda empresa PesqTec com o formato 9999/99, sendo

XX os dois ltimos dgitos do ano (por exemplo, pedido 1234/09). Esta fase no ser

detalhada neste trabalho.

Na segunda parte da sesso, o novo fluxograma (Figura VI.10) foi apresentado e

desenvolvido no passo de implementao desta iterao e corresponde a uma

evoluo do fluxograma desenvolvido no final do ciclo 1 e apresentado na Figura

VI.6.

O fluxograma mostra que, na fase de registro de material, possvel que os usurios

no tenham especializao adequada para executar todos os servios orados, de

modo que, no limite, cada servio seja realizado por um executor diferente

(denominada OS). Como neste ponto ocorre uma diviso do fluxo, a fase do

registro material dever oferecer uma funcionalidade de distribuio das ordens de

servio (OS). Uma OS corresponde a uma determinada associao entre um ou

198

mais servios, um material e seu respectivo executante. Os usurios tambm

sugeriram a mudana do nome da fase de Realizao do trabalho para

Inspeo/execuo do servio.

Solicitao do

pedidoOramentao

Registro do

material e

Distribuio da

ordem de

servio (OS)

Inspeo e

execuo:

Servio 2

(executor 2)

Encerramento

do trabalho

Dados

iniciais

Enviado ao

cliente AprovadoDocumento

pronto

Inspeo e

execuo:

Servio 1

(executor 1)

Inspeo e

execuo:

Servio 3

(executor 3)

Encerramento

do trabalho

Encerramento

do trabalho

Documento

pronto

Documento

pronto

OS1

OS3

OS2

Enquanto no aprovado

Enquanto no aprovado

Figura VI.10 - Fluxograma do processo aps a iterao 1

Aps este detalhamento, alguns usurios perceberam que as ordens de servio

poderiam ser reagrupadas para formar um ou mais documentos tcnicos no

processo, assim como seria necessrio mudar parte das interfaces grficas j

discutidas para atender a estas novas regras do fluxo. Foram, ento, desenhadas no

quadro as alteraes que deveriam conter o fluxograma do processo, para que o

mesmo pudesse realizar a distribuio dos documentos tcnicos.

Nesta sesso, tambm, foram definidos dois usurios (aqueles que levantaram estas

questes) para detalhar melhor esta situao no passo de anlise e planejamento,

de modo a permitir sua implementao na iterao seguinte, para apresentao na

terceira sesso.

199

VI.3.3 Iterao 3

Inicialmente, no passo de implementao, foram desenvolvidos os artefatos

necessrios terceira sesso: o novo fluxograma do processo, assim como uma

primeira verso das interfaces grficas associadas a estas novas fases. Os artefatos

foram detalhados com as sugestes feitas pelos usurios na segunda parte da

sesso anterior e, posteriormente, complementados no passo de anlise e

planejamento durante a realizao da segunda iterao.

Na Figura VI.11 abaixo, pode ser visto o fluxograma do processo discutido na

iterao anterior, onde foi criada a nova fase no processo de atendimento

(Composio do documento tcnico) e novas opes de navegao do workflow em

funo do que foi discutido na segunda parte da sesso anterior.

Solicitao do

pedidoOramentao

Registro do

material e

Distribuio da

ordem de

servio (OS)

Inspeo e

execuo:

Servio 2

(executor 2)

Dados

iniciais

Enviado

ao

cliente Aprovado

Inspeo e

execuo:

Servio 1

(executor 1)

Inspeo e

execuo:

Servio 3

(executor 3)

Composio e

distribuio do

Documento

tcnico

Documento

pronto

Documento

pronto

OS1

OS3

OS2

Enquanto no aprovado

Enquanto no aprovado

Encerramento

do trabalho:

Documento

tcnico 1

Documento

pronto

Encerramento

do trabalho:

Documento

tcnico 2

Aprovado

Aprovado

(Distribuio)

Figura VI.11 - Fluxograma do processo discutido na iterao 2 (segunda sesso)

No detalhamento do fluxo das tarefas, alguns usurios perceberam que seria

necessrio separar a funcionalidade da aprovao do oramento que se encontrava

na fase do registro do material (ver Figura V.12) e criar uma nova fase entre a

oramentao e a fase de registro do material para possibilitar aos usurios fazer

um acompanhamento mais prximo das aprovaes dos oramentos, inclusive,

possibilitando o gerenciamento dos contatos com os clientes. Deste modo, os

participantes da sesso decidiram criar a fase de follow-up.

200

Outro aspecto referente ao workflow do processo levantado pelos usurios foi a

necessidade de uma nova conexo (interface) do sistema informatizado com um

outro sistema da empresa PesqTec para a obteno de uma numerao que os

documentos tcnicos deveriam possuir. Alguns usurios lembraram que no modo

no informatizado era comum ocorrer erros de associao entre o nmero do

documento, que solicitado manualmente em outro sistema e o documento tcnico

entregue ao cliente.

A criao de uma nova fase denominada elaborao do documento tcnico foi

proposta. Fase esta que estaria entre as de composio do documento tcnico e

encerramento do trabalho. Por sua vez, tambm, foi proposta pelos usurios a

mudana do nome da fase de encerramento para entrega do documento, por ser

esta mais apropriada com as atividades relacionadas mesma.

Na Figura VI.12, pode ser visto o diagrama de contexto considerando a nova

interface e na Figura V.13 o fluxograma completo do processo de atendimento,

considerando as duas novas fases discutidas nesta sesso.

Software de

acompanhamento

laboratorial

Usurio ERP

Solicitao de abertura de

pedido e dados sobre seu

andamento

Banco de dados dos

colaboradores da

empresa PesqTec

rea de acervo e

informao tecnolgica

da empresa PesqTec

Informaes sobre o

processo de atendimento

Solicitao de loginDados do colaborador

Informaes sobre

clientes

Informaes sobre o

pedido de faturamento

Solicitao de registro de

documento tcnico

C&P

(Sistema para definio

do custo/preo do servio

orado)

Solicitao de preo

de um dado servio

Figura VI.12 - Diagrama de contexto, considerando a interface com o sistema de numerao do documento tcnico

201

Solicitao

do pedidoOramentao

Registro do

material e

Distribuio da

ordem de

servio (OS)

Inspeo e

execuo:

Servio 2

OS2

(executor 2)

Inspeo e

execuo:

Servio 1

OS1

(executor 1)

Inspeo e

execuo:

Servio 3

OS3

(executor 3)

Composio e

distribuio do

Documento

tcnico

Elaborao

do documento

tcnico 2

Followup

Entrega:

Documento

tcnico 1

Entrega:

Documento

tcnico 2

Elaborao

do documento

tcnico 1

Aprovado

N doc.

tecn.1

N doc.

tecn.2

Figura VI.13 - Fluxograma final do processo, considerando o detalhamento desta sesso

Aps o detalhamento do fluxo, solicitou-se aos usurios como deveria ser a

distribuio das atividades e responsabilidades associadas a este fluxo de trabalho,

procurando associar s vrias especializaes de profissionais encontradas nos

laboratrios (tcnico executante do servio, secretrias, chefes de laboratrio e

pesquisadores) uma ou mais fases do processo discutido.

Percebeu-se que no seria possvel atribuir as atividades associadas a cada fase

aos tipos de profissionais encontrados nos laboratrios, sobretudo em razo da

heterogeneidade destes laboratrios, onde, dependendo de seu tamanho, um

mesmo profissional poderia assumir vrias das fases apresentadas e, tambm, pelo

fato de nenhuma das fases exigir um perfil tcnico para sua realizao, j que o

objetivo da automao era realizar o acompanhamento do atendimento e no

realizar automaticamente o servio em si (ver ciclo 1).

Deste modo, cada laboratrio poderia estabelecer quem iria trabalhar em

determinada fase, mas sem criar grupos especficos dentro do software para esta

finalidade, possuindo uma configurao prxima ao de grupos semiautnomos,

sobretudo pelo fato do grupo ser responsvel por atingir um determinado volume de

produo em um certo intervalo de tempo, dentro dos padres de qualidade

especificados, possuindo certa autonomia para troca de funes no processo

(SALERNO, 1999).

202

Em comum acordo, ficou estabelecido que cada novo pedido (solicitao de

oramento) teria um nico responsvel, este sim escolhido de uma lista mais restrita

de usurios e tambm, o pedido de faturamento s poderia ser realizado pelas

secretrias, em razo do conhecimento e permisso especficos em outros sistemas

(ERP) que estas possuam. Outro grupo de usurios que tambm surgiu nas

discusses foi o grupo administrador.

Assim, no haveria uma lista especfica de responsveis para cada fase, de modo

que todo usurio do sistema poderia acessar qualquer fase do mesmo, tornando o

fluxo do processo dependente do conhecimento que cada usurio tinha de seu

servio e do conhecimento do andamento do servio dos demais.

Na segunda parte da sesso, foram detalhadas as fases com funcionalidade mais

cooperativas do sistema. Primeiramente, foi apresentado o esboo da interface do

processo de registro de material que tambm passou a ter a funo de distribuio

das ordens de servio (ver Figura VI.14); e os usurios poderiam associar um

material registrado a um determinado executor para a realizao de um ou mais

servios orados para o cliente.

Posteriormente, detalhou-se tambm a fase de composio (Figura VI.16),

permitindo a associao das ordens de servio distribudas (fase de inspeo e

execuo) a um ou mais documentos tcnicos.

No final da sesso, surgiu uma questo emergente, aps a observao de alguns

usurios sobre como seria possvel coordenar a sequncia de execuo das fases

do workflow em um contexto, em que as mesmas poderiam ser acessadas, em tese,

por qualquer usurio do grupo. Percebeu-se, ento, que seria preciso criar algum

meio de coordenao das atividades do grupo em um ambiente autocoordenado,

isto , as aes do grupo deveriam levar sua prpria coordenao.

No passo de anlise e planejamento, foram detalhadas as novas fases surgidas na

validao do workflow (follow-up, registro de OS, composio de documento tcnico

e elaborao), assim como a confeco de um artefato para tratar a questo da

autocoordenao do grupo (por meio de entrevista individual com alguns usurios

que participaram da sesso corrente).

Nesta iterao, outros artefatos foram detalhados diretamente pela equipe de

desenvolvimento do software para serem apresentados aos usurios, considerados

203

como ferramentas do sistema informatizado: de administrao (definio de quem

acessa o sistema, do grupo de responsveis pelo oramento e do grupo de

administradores), de gerao de pedido de faturamento e de solicitao interna de

servio (equivalente a um pedido de faturamento, mas para um cliente interno).

VI.3.4 Iterao 4

No passo de implementao, os artefatos detalhados no passo de anlise e

planejamento da iterao anterior foram preparados como elementos de suporte

para a sesso desta iterao. Deste modo, a fase de registro de OS e a fase de

composio foram reestruturadas e as novas fases de follow-up e de elaborao

construdas. Um esboo de um artefato de coordenao tambm foi desenvolvido

para apresentao e discusso na segunda fase da sesso corrente.

Os artefatos definidos como ferramentas para execuo do fluxo, tambm, foram

implementados para apresentao e validao dos usurios, mas seu detalhamento

no ser realizado na sesso corrente pelas razes apresentadas no item VI.1,

cabendo a observao que estes artefatos no fazem parte do fluxo apresentado na

iterao 3, sendo seu acesso realizado por meio do artefato de coordenao

mostrado na Figura VI.17.

Seguindo a dinmica das iteraes apresentada no item VI.2.2, na primeira parte da

sesso foram validados os artefatos detalhados na segunda parte da sesso

anterior. S as fases de registro de OS e de composio sero discutidas nesta

iterao, uma vez que apresentam maior importncia para o trabalho cooperativo

dos laboratrios.

A Figura VI.14 corresponde fase de registro de material e distribuio de OS.

Inicialmente, registra-se o material e associa-se ao mesmo os servios e os

executores, como pode ser visto na Figura VI.14-1. Neste caso, possvel associar

at trs servios diferentes (servio teste 1, servio teste 2 e servio teste 3), cada

um deles, por sua vez, pode ser associado a qualquer usurio do laboratrio (grupo

de trabalho).

Uma vez feita as associaes, estas devem ser efetivadas pelo boto inserir, com

o resultado da ao mostrado na Figura VI.14-2, em que pode ser visto que existe

204

um material registrado no sistema (550) e associados ao mesmo trs servios e

usurios (Servio teste 1/ Nome do colaborador 1 OS1; Servio teste 2/Nome do

colaborador 2 OS2 e Servio teste 3 /Nome do colaborador 3 OS3 ) .

Quando o boto Distribuir OS for acionado, sero geradas trs ordens de servio

distintas para os trs usurios (ou seja, trs fases distintas de Inspeo/Execuo),

assim como ser gerada uma fase de composio de documento tcnico para o

usurio Nome colaborador 4 (acima do boto inserir na caixa: Aps execuo, a

composio do Doc.Tcnico ser feita por:).

Figura VI.14 - Registro de material e distribuio de OS

Na Figura VI.15, pode ser visto um artefato tpico da fase de inspeo e execuo

(uma das ordens de servio geradas na fase anterior) recebido pelo usurio NOME

COLABORADOR 3.

205

Nesta fase, o executante do servio em um dado material deve informar a situao

da inspeo (conforme/no conforme), assim como o estado da execuo (coluna

Status da execuo). Em particular, na Figura VI.15-1 pode-se notar que a situao

da inspeo conforme e a o Statusda execuo Concludo.

Quando o boto salvar for acionado, esta informao far parte do painel da fase

de Composio do documento tcnico mostrado na Figura VI.16-1, onde se pode

notar que a coluna Status para o NOME COLABORADOR 3 possui o valor

concludo.

Figura VI.15 - Inspeo e execuo da OS

A Figura VI.16-1 mostra um painel com todas as fases de Inspeo/execuo que

foram distribudas na fase de Registro e distribuio de OS, assim como possvel

verificar se estas j foram ou no concludas. A informao permite ao usurio (no

caso NOME COLABORADOR 4) verificar em uma nica figura um resumo sobre o

andamento das execues dos servios.

Utilizando-se os conceitos de ergonomia das interfaces (ver item II.3.2 e Apndice

B), em particular, o critrio de consistncia, procurou-se garantir que as

caractersticas da interface de Registro e distribuio de OS (cdigos,

procedimentos, denominaes, posies, etc.) fossem conservadas nesta fase, de

modo que a mesma foi dividida em duas, em que foi dada a possibilidade para o

usurio escolher quais ordens de servio poderiam compor o documento tcnico

(Figura VI.16-1) e depois permitir que este verificasse a composio escolhida e

206

fizesse sua distribuio (no caso criando as respectivas fases de Elaborao do

documento tcnico- Figura VI.16-2).

No exemplo em particular mostrado na Figura VI.16-1, j foram escolhidas duas

ordens de servio para fazer parte de um documento tcnico (esto marcadas como

inseridas na coluna Inserir), sendo este documento apresentado na Figura VI.16-2

para distribuio: (material 550 Servio teste 2 e material 550 Servio teste 3),

nome do documento: Documento tcnico 2 e que ser enviado para o NOME

COLABORADOR 6 na fase de Elaborao do Documento.

O outro documento tcnico ainda no foi composto na Figura VI.16-1, mostrando

que ser composto somente do material 550 associado ao servio teste 1, nome do

futuro documento: Documento tcnico 1 e ser enviado para o NOME

COLABORADOR 1.

Na Figura V.13 podem ser vistos por meio das linhas indicadas nesta figura, os

caminhos percorridos pelo fluxo de atendimento para as fases de registro de OS,

inspeo/execuo, composio e elaborao do documento tcnico utilizados neste

exemplo.

Figura VI.16 - Composio do documento tcnico

Na segunda parte da sesso, o objeto de coordenao necessrio foi apresentado,

para que um dado usurio conseguisse se coordenar dentro de suas atividades,

207

levando-se em conta o fato que o mesmo poderia possuir vrios pedidos abertos sob

sua responsabilidade. Assim, foi criado um artefato de coordenao no qual os

usurios poderiam visualizar todas as suas fases pendentes, alm de permitir o

acesso s mesmas para executar suas respectivas atividades (Figura VI.17).

Outro aspecto emergente que surgiu durante a discusso da coordenao das

atividades, foi o fato de que o usurio do grupo de trabalho tambm tinha

necessidade de saber o que os demais participantes do grupo estavam fazendo,

alm da situao de seu trabalho, para deste modo encaixar suas atividades com as

atividades dos demais participantes do grupo.

Para tanto, outro artefato foi proposto pelos participantes da sesso, de modo a

atender a esta necessidade (Figura VI.19), cujo objetivo foi mostrar todas as fases

pendentes de um determinado pedido, independente de quem era seu responsvel.

Assim, o usurio poderia saber como estava o andamento do pedido como um todo.

A necessidade de criao de relatrios tambm foi mostrada aos participantes, tanto

os gerencias para verificao de estatsticas do atendimento (nmero de oramentos

gerados, aprovados, valores faturados, nmero de documentos tcnicos gerados,

tipo de documentos gerados, etc.), como internos (como o caso do artefato para

verificao dos pedidos em andamento).

Por ltimo, no passo de anlise e planejamento foram identificados os detalhes dos

dois artefatos de coordenao para sua construo na quinta iterao por meio de

entrevistas individuais, assim como foram detalhados tambm alguns dos relatrios

internos e gerenciais.

VI.3.5 Iterao 5

Na penltima iterao, no passo de implementao, foram construdos os artefatos

de coordenao, e os relatrios internos e gerenciais detalhados no passo de

anlise da iterao anterior.

Na primeira parte da sesso, estes artefatos foram validados. Assim, na Figura VI.17

pode ser vista a proposta final da interface grfica referente ao artefato de

coordenao individual das atividades dos usurios, em que esto listadas todas as

pendncias de fases de processos abertas relacionadas somente ao usurio NOME

208

COLABORADOR 1. Conforme citado na segunda parte da sesso anterior, o

objetivo deste artefato permitir que o usurio verifique, dentro de suas pendncias,

qual(is) fase(s) do processo esto sob sua responsabilidade para que possa, deste

modo, coordenar suas aes (coordenao individual).

Figura VI.17 - Coordenao individual e pgina principal do software

Na validao sobre quais informaes deveriam constar deste artefato, assim como

formas de filtro, os usurios consideraram importante que as fases dos pedidos

deveriam ser mostradas por ordem direta e inversa em relao a seu nmero (Figura

VI.17-1).

Uma vez que para a coordenao individual de um usurio sempre seria necessrio

definir qual fase do processo este deveria escolher para dar andamento ao fluxo do

processo; outra questo emergente foi estabelecida: que este artefato seria a pgina

principal do sistema, de modo que, aps a concluso de qualquer atividade

relacionada a qualquer fase do processo, sempre haveria um retorno para este

artefato. Assim, outros aspectos deveriam ser contemplados por este artefato de

coordenao e que deveriam ser acessados pelos usurios independente da fase

em que o mesmo se encontrasse.

Na Figura VI.18, podem ser vistas as opes apresentadas aos participantes da

sesso, como por exemplo, um ponto de entrada para a solicitao de um novo

pedido (Figura VI.18-1), opo para pesquisar clientes (Figura VI.18-2), as

ferramentas do software (Figura VI.18-3), relatrios e relatrios internos (Figura

VI.18-4 e Figura VI.18-5, respectivamente).

209

Figura VI.18 - Coordenao individual e pgina principal do software

Na segunda parte da sesso anterior, outro aspecto levantado foi a necessidade

percebida pelos usurios de que somente as informaes sobre suas prprias aes

no seriam suficientes para esta coordenao, de modo que para se coordenar,

tambm, era necessrio usar mecanismos que lhes permitissem receber uma

indicao das atividades dos demais usurios do laboratrio.

Na Figura VI.19, este novo artefato de coordenao pode ser visto como: (relatrio

de) pedidos em andamento (que pode ser acessado na opo de Relatrios

internos da Figura VI.18-5). Como exemplo, foi usado o pedido 6/06 (Figura VI.19-

1) empregado nas iteraes anteriores. Percebe-se que este processo possui

algumas fases pendentes que no esto com o usurio NOME COLABORADOR1,

por exemplo, a fase de Composio do documento est com o NOME

COLABORADOR 4 (iterao 4) e umas fase de Elaborao do documento est

com o usurio NOME COLABORADOR 6.

Figura VI.19 - Coordenao com as atividades do grupo

210

Assim, estes dois artefatos possibilitariam que o usurio fosse capaz de entender a

situao de sua atividade, permitindo se encaixar no trabalho (processo de

atendimento), como um todo.

Na segunda parte da sesso, os relatrios gerencias detalhados na iterao anterior

foram apresentados. Para o trabalho cooperativo, seu objetivo era mostrar os

resultados agregados de todos os atendimentos do grupo.

Na Figura VI.20, pode ser visto um exemplo de relatrio discutido na iterao

anterior, mostrando em um quadro geral os principais indicadores que os

participantes da sesso consideraram importantes para avaliao das metas do

trabalho do grupo.

Alm dos indicadores de desempenho financeiro, outros foram sugeridos no sentido

de acompanhar a qualidade das atividades cooperativas, como por exemplo: nmero

de oramentos concludos na data ou em atraso, nmero de oramentos em

execuo atualmente, nmero de oramentos atrasados em execuo atualmente,

nmero de oramentos em aberto e nmero total de oramentos e followup sem

aprovao (ver Figura VI.20).

Na parte final da sesso, a possibilidade de haver somente mais uma sesso para

fechamento do ciclo 2 foi apresentada aos participantes, visto que os principais

requisitos funcionais j tinham sido especificados (o grupo no estava produzindo

mais novidades em suas discusses), onde j no passo de anlise e planejamento

da iterao anterior esta questo tinha sido diagnosticada.

211

Figura VI.20 - Balano das atividades do grupo de trabalho

No passo de anlise e planejamento desta iterao, foram revisados os artefatos

produzidos durante as cinco iteraes e enviados aos participantes para anlise e

validao final na prxima e ltima iterao.

VI.3.6 Iterao 6

Esta iterao foi realizada para o fechamento dos requisitos levantados nas cinco

iteraes anteriores.

212

No passo de implementao, foram realizadas algumas correes nos documentos

entregues aos usurios no passo da anlise da iterao anterior para facilitar a

validao dos artefatos na sesso desta iterao.

Assim, na sexta sesso foram validados os principais artefatos necessrios ao

projeto e implementao do sistema (sob a viso dos usurios): fluxograma geral do

processo (Figura V.13) e respectivas interfaces grficas (nas iteraes deste

trabalho foram apresentadas parte das interfaces, para os usurios foram mostradas

todas as interfaces relativas s fases analisadas) e navegaes, diagrama de

contexto (Figura VI.12) e descrio de cada uma das fases do processo a ser

informatizado.

A descrio resumida das fases do fluxograma da Figura V.13 realizada abaixo.

Solicitao do pedido (abertura do pedido)

Ocorre a habilitao da demanda para que possa ser atendida dentro dos critrios

de qualidade do laboratrio. Esta atividade pode ser realizada por qualquer membro

do laboratrio.

Principais atividades: registro de solicitao do cliente, cadastro de clientes

(quando o cliente ainda no cadastrado no ERP), definio se o pedido

multilaboratorial (ou oramento interno para outro laboratrio) e montagem da

solicitao;

Principais entradas: pedido do cliente (dados iniciais do cliente) e dados

iniciais do pedido, conforme fase de solicitao do pedido;

Principais sadas: registro do pedido e nmero para acompanhamento,

identificao do responsvel desta fase do processo e cadastro do cliente.

Oramentao:

A confeco da proposta oramentria realizada, sendo composta das

informaes referentes aos servios pesquisados no sistema de Custos e Preos, ou

ento, por meio da composio de oramentos internos enviados por outros

laboratrios.

213

A responsabilidade pelo oramento ou um tcnico designado e reconhecido como

competente para o atendimento, ou do responsvel pela rea cuja competncia

atender ao pedido, mas o envio do oramento pode ser realizado por qualquer

participante do laboratrio, podendo inclusive ser reenviado quantas vezes forem

necessrias.

Principais atividades: escolha dos servios pertencentes ao oramento no

software de Custos e Preos, ou ento, definio de um ou mais oramentos

internos (multilaboratoriais) que comporo o oramento. Ajuste do oramento

em funo da solicitao do cliente e respectiva composio (nmero de

materiais, taxa de urgncia e desconto, descrio detalhada dos servios,

etc.), assinatura e envio da proposta oramentria;

Principais entradas: registro do pedido (solicitao), projeto da soluo

tcnica e servios (oriundos do sistema de Custos e Preos) e oramentos

multilaboratorias (oriundos de outros laboratrios);

Principais sadas: definio do escopo de atendimento, envio de proposta

comercial (oramento) ou por meio de email, ou em formato impresso para

envio via fax.

Followup:

A verificao do interesse do cliente pelo oramento feita e pode, posteriormente

ser realizada uma renegociao do mesmo. A responsabilidade pela fase de

Followup pode ser de uma secretria designada para fazer o acompanhamento da

proposta, de um tcnico designado e reconhecido competente para a negociao,

ou do responsvel pela rea, cuja competncia atender e validar a renegociao.

Principais atividades: escolha do perodo de followup (prazo que define de

quanto em quanto tempo o oramento estar disponvel ao usurio para o

acompanhamento do interesse do cliente). Monitorao e aprovao ou

recusa do oramento, com os motivos. Renegociao dos servios contidos

no oramento (culminando at com a retirada de alguns destes servios) e

descrio do resumo de negociao ou acompanhamento (followup) para

histrico do acompanhamento;

214

Principais entradas: oramento enviado ao cliente, aprovao do cliente, ou

respectivos motivos para o caso de recusa, data de aprovao, informaes

de renegociao (nmero de amostras, taxas de desconto/urgncia) e

informaes sobre o acompanhamento do envio do oramento;

Principais sadas: oramento devidamente aprovado e respectivo histrico de

renegociaes/acompanhamentos.

Registro de material e distribuio da OS:

Nesta fase, ocorre o registro do material para incio da realizao dos servios, a

numerao do material sequencial, com seu valor de incio definido pelo

laboratrio.

Aps ser registrado, o material associado a um ou mais servios e seus

respectivos executores ( criada uma Ordem de Servio OS), assim como deve

ser definido o responsvel pela fase de composio de documento tcnico. Se o

pedido j foi aprovado pelo cliente, ento a(s) OS(s) sero distribudas os

respectivos executores, criando-se assim a(s) fase(s) de Inspeo/execuo, bem

como a fase de Composio de documento tcnico.

Este conjunto de atividades pode ser realizado por qualquer participante do

laboratrio, sendo normalmente executado pela secretria do laboratrio (registro)

ou um tcnico (registro e distribuio).

Principais atividades: registro do material recebido do cliente, associao do

material aos servios e executores, escolha do responsvel pela fase de

composio e distribuio das ordens de servios a seus respectivos

executores (fases de Composio do documento tcnico e

Inspeo/execuo respectivamente);

Principais entradas: oramento editado e aprovado, vindo da fase de Followup

e dados do material para registro;

Principais sadas: criao da(s) fase(s) de Inspeo/Execuo e da fase de

Composio do documento tcnico e disponibilizao do material para

realizao do(s) servios(s) contratado(s).

215

Inspeo/Execuo do trabalho:

As informaes decorrentes da inspeo do material so registradas e sob o qual

ser realizado o servio (conforme, no conforme), assim como a efetiva situao da

execuo dos servios associados a esse material (em andamento, suspenso,

concludo, cancelado).

O status da execuo ser visualizado na fase de Composio do documento

tcnico e s aps o mesmo estar registrado como concludo, poder ser composto

(criado) um documento tcnico.

As informaes tcnicas a respeito da execuo (por exemplo, as grandezas fsicas

medidas durante o servio) no sero registradas no software de acompanhamento,

dada sua caracterstica ligada questo de administrao do andamento do fluxo do

trabalho (conforme discutido no ciclo1, item V.2.3).

A realizao do servio de natureza tcnica e, normalmente, est sob

responsabilidade do responsvel pelo laboratrio, ou do tcnico designado, sendo

importante a correta informao da data de execuo do servio para avaliao dos

pontos crticos de atendimento. Mas, na falta destes, esta fase pode ser realizada

por qualquer participante do laboratrio.

Principais atividades: inspeo tcnica do material recebido, recuperao ou

editorao das planilhas de clculo para o servio realizado (atividade no

controlada pelo software de acompanhamento laboratorial), realizao dos

servios sobre o material e informe sobre a data e status (situao) da

execuo dos servios;

Principais entradas: material em que ser realizado o servio, os insumos, os

dispositivos especiais (material fsico do laboratrio) e a fase de

Inspeo/Execuo enviada ao responsvel pelo servio;

Principais sadas: liberao das informaes tcnicas relativas aos servios

executados (no controlados pelo software) e liberao da fase de

Inspeo/execuo para a composio do documento tcnico.

216

Composio e distribuio do documento tcnico:

Nesta fase, ocorre a associao das ordens de servios realizadas na fase de

Inspeo/Execuo e os documentos tcnicos das quais faro parte. Assim que o

responsvel pela fase de Inspeo/execuo altera o status para concludo, a sua

incluso (composio) liberada em um novo documento tcnico da empresa

PesqTec.

Esta fase foi implementada em termos de interface grfica, mantendo o mesmo

formata da fase de Registro de OS (para manter o mesmo modelo mental do

usurio).

Assim, aps ter sido feita a escolha dos servios associados aos materiais que faro

parte do documento tcnico, o usurio, tambm, dever escolher para quem ser

enviada (distribuda) a fase de Elaborao do documento tcnico. Aps serem feitas

as composies do documento, sua distribuio nos mesmos moldes da fase de

Registro de OS realizada e os documentos sero distribudos aos respectivos

executores, criando-se assim a(s) fase(s) de Elaborao do documento tcnico.

Em geral, este conjunto de atividades executado pela secretria ou pelo

responsvel pelo laboratrio (mas, pode tambm ser feito por qualquer participante

do laboratrio).

Principais atividades: associao entre servios executados nos materiais e o

documento tcnico e escolha do responsvel pela prxima fase (Elaborao

do documento). Distribuio dos documentos tcnicos a seus respectivos

executores na fase de Elaborao do documento;

Principais entradas: servios concludos na fase de Inspeo/execuo.

Composio do contedo do documento tcnico e definio do responsvel

pela sua elaborao (Fase de Elaborao do documento tcnico);

Principais sadas: criao da(s) fase(s) de Elaborao do documento tcnico.

Elaborao do documento:

Nesta fase, o documento tcnico confeccionado, assim como obtida uma

numerao sequencial nica para o documento de outro sistema informatizado da

empresa PesqTec (ver Figura VI.12).

217

Nesta fase, tambm, so registradas informaes a respeito da elaborao, como

por exemplo, o local para armazenamento do documento tcnico, a data de trmino

e os eventuais revisores.

possvel fazer um acompanhamento do processo de reviso do documento

tcnico, permitindo registrar, alm dos eventuais revisores, todas as alteraes

sofridas pelo mesmo por meio de um histrico de alteraes.

A elaborao do documento fsico deve ser realizada ou pelo tcnico designado, ou

pelo responsvel do laboratrio. Assim, esta fase preferencialmente utilizada pelos

executores do documento tcnico para registrar as alteraes sofridas pelo mesmo

durante sua reviso, mas pode tambm ser acessada pela secretria, para inserir

estas ou outras informaes relativas fase (local de armazenamento do

documento, solicitao, nmero de relatrio, etc.).

Principais atividades: definio do tipo de documento tcnico e de seu

respectivo nmero (acessvel por meio de outro sistema informatizado),

registro das alteraes decorrentes das revises no documento e escolha do

responsvel para envio fase de Entrega do documento.

Principais entradas: criao da fase de Elaborao do documento por

intermdio de sua distribuio na fase de Composio, solicitao de nmero

de documento e registro de suas respectivas revises e dados sobre seu

armazenamento (todo laboratrio deve ter uma cpia do documento gerado

para fins de auditoria)

Principais sadas: documento tcnico revisado e criao da fase de Entrega

do documento tcnico.

Entrega:

Esto reunidas todas as etapas tpicas relacionadas ao acompanhamento da

tramitao do atendimento no contexto da emisso do documento tcnico final e

providncias para seu encerramento.

Nesta fase, a entrega do documento tcnico realizada para seu envio ao cliente

(normalmente, via correio, mas tambm pode ser retirado na empresa PesqTec).

218

No entanto, antes de ser entregue ao cliente, devem ser fornecidos os dados do

documento relativos a seu faturamento e sobre seu modo de entrega, alm das

informaes referentes ao arquivamento da documentao final do processo (o

processo fsico, com as medidas realizadas, observaes, concluses, documentos

tcnicos intermedirios, etc.)

Nesta fase, o faturamento no ser realizado, visto que pode ser necessrio incluir

vrios documentos tcnicos em um nico faturamento. Deste modo, conforme

definido na quinta iterao, esta funcionalidade ser acessada no artefato de

coordenao individual do usurio (para usurios com permisso apropriada), na

aba de ferramentas (Figura VI.18-3).

O conjunto de atividades pode ser considerado administrativo e normalmente est

sob responsabilidade da secretria do laboratrio, mas pode ser realizado por

qualquer participante do laboratrio.

Principais atividades: definio do valor final do documento tcnico e outras

informaes relativas a seu faturamento (preparao para faturamento),

definio de informaes sobre o arquivamento final do processo de

atendimento e encerramento do fluxo relativo ao documento tcnico (Figura

V.13).

Principais entradas: fase de Elaborao concluda, inclusive, com o nmero

do documento tcnico. Informaes necessrias ao faturamento do

documento (preo final, tipo de envio, data de envio, etc.) e tambm sobre o

arquivamento do documento fsico relativo ao documento tcnico que est

sendo encerrado.

Principais sadas: encerramento do processo de atendimento relativo ao

documento tcnico (pr-requisito para que seja faturado) e envio fsico do

documento ao setor de expedio.

Aps os requisitos descritos acima serem validados pelos usurios em suas

respectivas iteraes (1 a 5), alm de sua confirmao nesta iterao (6), estes

artefatos, com os de implementao (ver item VI.2.2) sero utilizados para

implementao do primeiro prottipo funcional do software que apresentado no

ciclo 3 desta pesquisa.

219

VI.4 CONCLUSES DO CICLO 2 (PASSO DE MONITORAMENTO DA PA)

Visando a orientar as concluses deste captulo, procura-se responder s questes

relativas a este ciclo da PA (ver item III.4.4):

1. Quais so os instrumentos a serem elaborados para captar os requisitos de

software da dimenso cooperativa do trabalho de um SI durante a simulao

do sistema informatizado que lhe dar suporte?

Os instrumentos utilizados para captar a dimenso cooperativa do trabalho

correspondem s tcnicas, mtodos, conceitos e modelos e so listados a seguir:

Dimenses do trabalho coletivo (ver item II.1.2);

Anlise coletiva do trabalho (ver item II.2);

Modelo mental e interao (ver item II.3);

Prototipao funcional (ver item II.8.3);

Modelos do sistema (ver item II.7.2);

Processo de desenvolvimento de software (ver item II.7.2);

A ergonomia e concepo informtica na simulao e prototipao de

sistemas (ver item II.8.3);

Modelo de desenvolvimento iterativo evolucionrio (ver item II.6.3);

Processo de Engenharia de Requisitos (ver item II.7.2);

Entrevistas (ver item II.8.2);

O uso da Anlise Coletiva do Trabalho para orientar as iteraes do grupo em torno

da atividade coletiva atual e simulao da atividade futura realizada, dos elementos

comuns de comunicao, do conceito de modelo mental, dos conceitos da

ergonomia de concepo de anlise das situaes de referncia (aquelas

encontradas no comeo do projeto) e das aes caractersticas futuras provveis

permitiram uma evoluo dos artefatos desenvolvidos na prototipao realizada no

ciclo 2 de modo a coletar, alm dos requisitos do trabalho individual dos usurios, os

requisitos do trabalho cooperativo pelas questes emergentes abaixo resumidas.

220

Ao se usar como exemplo esta pesquisa-ao, surgiram vrias questes

emergentes que permitiram detalhar os requisitos do trabalho cooperativo para esta

situao:

Iterao 1: os usurios perceberam a necessidade de gerar oramentos

multilaboratoriais;

Iterao 2: necessidade de alterao do fluxograma do processo para atender

ao trabalho cooperativo;

Iterao 3: necessidade de alterao das atividades das fases, criao de

novas fases e descrio das atividades e responsabilidades (coordenao

distribuda nas aes dos usurios em um sistema horizontal, isto , sem

coordenao centralizada);

Iterao 4: necessidade de criao de artefatos de coordenao;

Iterao 5: necessidade de criao de artefatos especficos para acompanhar

as atividades do grupo.

2. Como estes instrumentos podem ser concatenados para captar os

requisitos de software do trabalho cooperativo durante a simulao do sistema

informatizado?

Os instrumentos acima descritos foram concatenados pelo uso do processo

apresentado no item IV.5 (Processo para a identificao e simulao de requisitos

de software do trabalho cooperativo) e implementados por meio do ciclo da PA deste

captulo.

A aplicao da dinmica das iteraes descritas no item VI.2.2, tambm, contribui

para melhor aproveitamento das sesses realizadas com os usurios, pela

construo a priori dos artefatos compartilhados, de seu detalhamento na iterao

anterior (passo de anlise e planejamento) e de sua construo no passo de

implementao da iterao corrente.

Neste ciclo, a aplicao do processo mostrou que nas sesses realizadas, uma nova

ideia gerada por alguns dos participantes era imediatamente testada, com base na

reao dos outros participantes, em apoio ou no.

221

Assim, quando algum expressava um desejo ou necessidade, outra reagia,

concordando ou discordando, e uma terceira ainda podia modificar a mesma ideia

para torn-la mais acessvel. Enfim, todo o grupo acabava emitindo uma opinio a

respeito. Com isso, ganhou-se tempo no projeto, atendendo s expectativas dos

usurios reais.

Os requisitos emergentes surgiram em razo do fato de que o processo empregado

trouxe tona aspectos que no seriam facilmente acessveis sem a interao do

grupo e que o processo de compartilhar e comparar ofereceu rara oportunidade de

compreenso por parte do pesquisador de como os participantes entendiam suas

similaridades e diferenas.

3. A soluo proposta neste ciclo pode ser aplicada para refinar os requisitos

de software do trabalho cooperativo durante o uso do sistema informatizado

(ciclo 3)?

Para responder a esta questo, preciso realizar o terceiro ciclo desta pesquisa-

ao.

222

VII CICLO 3 DA PESQUISA-AO: PROCESSO PARA

ESPECIFICAO DE REQUISITOS DE SOFTWARE COM FOCO

NO REFINAMENTO DAS CARACTERSTICAS DO TRABALHO

COOPERATIVO (EM USO REAL)

O objetivo deste ciclo o refinamento dos requisitos obtidos no ciclo 2 por meio do

sistema em uso, sobretudo os que privilegiam o trabalho cooperativo dos usurios

finais do sistema.

O modelo 3C apresentado, bem como sua relao com a pesquisa desenvolvida,

oferecendo elementos de awareness que facilitem a contextualizao das atividades

individuais pela compreenso das atividades realizadas pelos demais participantes

do grupo.

A partir da segunda iterao do ciclo, estes elementos so considerados e so

definidos quais artefatos de software devem ser desenvolvidos para complementar

os requisitos do trabalho cooperativo, sendo posteriormente avaliados pelos

usurios na terceira iterao deste ciclo.

VII.1 INTRODUO

Assim como nos dois ciclos anteriores, o processo proposto comea com a entrada

dos artefatos que foram desenvolvidos durante o ciclo anterior e que sero utilizados

como base inicial na atividade de implementao/reviso deste ciclo da PA.

A diferena deste ciclo com os anteriores que o sistema informatizado ser

efetivamente construdo, e os usurios finais substituiro parte do sistema de

informao em uso pela automatizao fornecida por este software.

Do mesmo modo, como foi considerado nos ciclos 1 e 2, neste ciclo sero

escolhidos uma parte dos artefatos desenvolvidos durante as iteraes, como

exemplo de aplicao do processo proposto, dada a quantidade de informao e,

tambm, pelo fato de que haveria repetio da aplicao do processo.

223

Apesar do sistema informatizado estar em uso quando estes dados foram

levantados, os exemplos ilustrados neste captulo (iteraes 2 e 3) so continuao

dos exemplos do ciclo 2 (para facilitar a compreenso), nos quais foram mantidos os

nomes dos usurios hipotticos. Os servios e os clientes utilizados como exemplo

no guardam relao com a empresa PesqTec.

Uma vez que o objetivo deste ciclo foi refinar as caractersticas do trabalho

cooperativo com o sistema em produo, partiu-se para a avaliao coletiva destas

caractersticas implementadas na segunda iterao do ciclo, utilizando-se como

elemento de representao comum o software em uso real para se comunicar com

os usurios finais e os projetistas (utilizados como imagem do sistema - item II.3).

Os prottipos funcionais foram apresentados aos usurios para discusso coletiva,

utilizando-se a tcnica de ACT, partindo-se das situaes de referncia do trabalho

dos usurios pela prpria voz destes e projetando-se as aes caractersticas

cooperativas ainda no implementadas no sistema informatizado, considerando

tambm os elementos de awareness e os conceitos da teoria da mente coletiva (ver

itens VII.3.2 e VII.3.3).

VII.2 DINMICA DE ITERAO DO CICLO 3

VII.2.1 Dados do grupo e do ambiente das sesses

Ao todo foram realizadas trs iteraes neste ciclo da PA, cuja primeira iterao

durou em torno de 3 meses e meio, a segunda 4 meses e a terceira em torno de 3

meses e meio. Estas sesses iniciaram-se em maro de 2007 e terminaram no incio

de janeiro de 2008.

Dois laboratrios foram escolhidos para a implantao do software. O nmero de

participantes no treinamento foi oito para um dos laboratrios e dez para o outro e

para as duas sesses foram doze pessoas (seis participantes por laboratrio), e dois

dos participantes tambm fizeram parte do grupo de usurios do ciclo 2. Todos os

participantes possuam curso superior completo ou curso tcnico e estavam

acostumados a utilizar aplicaes WWW disponveis na intranet da empresa

224

PesqTec (por serem participantes de laboratrio, possuam conhecimentos

homogneos com relao s regras de negcio).

Os integrantes das sesses 2 e 3 concordaram participar das reunies. O

treinamento, assim como as sesses foram todas realizadas dentro da empresa,

mas, em ambiente isolado da situao de trabalho dos participantes (as datas de

reunio foram marcadas, sempre que possvel com a antecedncia necessria

visando justamente a esta possibilidade).

No ambiente onde o treinamento foi realizado (iterao 1), fez-se uso de um

equipamento multimdia conectado a um microcomputador usado pelos

pesquisadores para orientar a realizao do treinamento e as observaes feitas

pelos participantes, alm do quadro para desenho, assim como cada participante

teve disponvel para si um microcomputador, onde podia acessar um ambiente-teste

com os vrios exemplos previstos para o treinamento.

As sesses das iteraes 2 e 3 foram conduzidas por dois pesquisadores; e um

deles foi responsvel por anotar ou gravar (com o consentimento dos participantes)

partes da sesso, auxiliar o outro pesquisador na conduo do grupo, tomar nota

das principais impresses verbais e estar atento aparelhagem multimdia.

Cada participante das sesses, tambm, teve disponvel para si um

microcomputador, onde podia reproduzir seu ambiente de trabalho por meio de uma

cpia atualizada da aplicao em uso em seu ambiente de trabalho (inclusive com

os ltimos dados de produo).

Assim como no ciclo 2, o outro pesquisador foi responsvel pela conduo da

sesso, permitindo a discusso dos vrios pontos de vista dos participantes, mas

sempre atento aos objetivos da sesso e da demanda como um todo, permitindo

assim maior diretividade da sesso corrente. Este pesquisador, tambm, buscou

promover a participao de todos, evitando a disperso dos objetivos da discusso e

a monopolizao de alguns participantes sobre outros, alm de ouvir as diversas

observaes sobre o assunto que estava sendo apresentado.

225

VII.2.2 Modelo 3C e awareness para o ciclo 3

O conhecimento dos mecanismos de comunicao, coordenao e colaborao,

principalmente como eles devem ser usados para manter diferentes elementos de

awareness permite criar tcnicas e ferramentas que forneam aos usurios as

informaes apropriadas sobre as metas, tarefas e sobre os outros integrantes do

ambiente.

A Figura VII.1 abaixo corresponde ao diagrama 3C utilizado nas iteraes 2 e 3

deste ciclo (ver item II.5.4), em que, para possibilitar a coordenao e a cooperao

como um todo, so necessrias informaes sobre o que est acontecendo e o que

as outras pessoas esto fazendo. Por meio destas informaes, os participantes

podem construir um entendimento compartilhado em torno dos objetos de

cooperao e dos objetivos das tarefas, ou de todo o trabalho.

Na Figura VII.1, nota-se que o ponto inicial que alimenta este diagrama, o objetivo

do grupo, isto , a realizao do trabalho de forma cooperativa.

Colaborao

Coordenao

ComunicaoPossibilita

Altera compromissosAwareness

Gera Gera

Gera

Realiza-se comObjetivo:

Trabalho cooperativo

Feedback

Fornece

elementos

para

Coordenao distribuda

nas aes dos usurios

Figura VII.1 - Diagrama dos 3Cs e awareness adaptado ao ciclo 3 Fonte: elaborado pelo autor

Esta figura apresenta diversos estmulos de entrada e um de sada. Isso significa

que vrios eventos dos participantes de um grupo sejam eles voluntrios ou no,

devem ter um elemento de awareness que gere feedback (retorno) para a

colaborao dos membros do grupo de trabalho.

226

No exemplo da Figura VII.1, pode ser ressaltado que a gerao de informaes

destinadas colaborao e comunicao no deve ser obrigatria, visto que o

feedback pode no ser desejado em todos os momentos do trabalho. J o evento de

coordenao ir proporcionar sempre algum grau de awareness, visto que o fluxo de

realizao do trabalho poderia ser interrompido e estagnar, sem transmisso da

informao.

Conforme descrito na iterao 5 do ciclo 2 (item VI.3.5), o usurio tem como ponto

de partida da aplicao um artefato de coordenao que mostra todas as suas

pendncias (ver Figura VII.2 reproduo da Figura VI.17). Por meio deste artefato

e da representao que o usurio possui do sistema (item II.4.1), que lhe permitem a

compreenso do estado total do mesmo (awareness), o usurio organiza suas

atividades e define qual objeto compartilhado de colaborao (neste caso

corresponde a uma das oito fases do processo) ir utilizar por meio da coluna Link,

concatenando sua ao frente aos demais usurios.

Figura VII.2 - Coordenao individual e pgina principal do software - reproduo

Quando colabora por intermdio de um destes objetos compartilhados (ver item

II.5.5), novas informaes so armazenadas no sistema, possibilitando a

comunicao entre os usurios pela alterao dos compromissos nos artefatos de

coordenao.

Assim, no existe uma distino clara entre coordenao e comunicao, e ambas

esto colapsadas (Figura VII.1), de modo que a comunicao ocorre sempre de

modo indireto e assncrono (ver item II.5.5), como conseqncia da colaborao, isto

, pelos dados que so inseridos no sistema.

227

Como no h um objeto explcito de comunicao, a coordenao feita pelo

entendimento da relao das aes dos usurios (Figura VII.2) e suas inter-relaes

com as aes dos demais usurios (Figura VII.3 reproduo da Figura VI.19).

Figura VII.3 - Coordenao com as atividades do grupo reproduo

VII.2.3 Caractersticas gerais do sistema informatizado desta PA

Em funo do que foi apresentado no item VII.2.2, o sistema desenvolvido nesta PA

possui como caractersticas:

Coordenao distribuda nas aes dos usurios (sem um centro definido de

coordenao item VII.2.2),

Comunicao entre os usurios realizada de modo indireto por meio dos

dados inseridos nos artefatos de colaborao (no existem ferramentas

especficas (hardware/software) para comunicao direta entre os usurios -

item VII.2.2),

Ambiente assncrono (os usurios no precisam estar trabalhando

simultaneamente, para que o objetivo seja atingido item II.5.5),

Interfaces grficas desacopladas (no so acopladas s interfaces dos

demais participantes do grupo- item II.5.5),

228

Embora as fases do processo estejam normalmente associadas a papis

especficos no grupo, as mesmas podem ser realizadas por qualquer

participante (item VII.3.1).

VII.2.4 Dinmica geral das iteraes

A Figura VII.4 abaixo mostra a sequncia de iterao para este ciclo de PA .

Monitoramento

Anlise e planejamentoANLISE (N);....;

ImplementaoIMPLEMENTAO (N)(N+1)

Levantamento e discusso

dos dadosSESSO (N);....;

Passos da pesquisa-ao

FASES DO PROTTIPO: CICLO 3

Artefatos do ciclo 2

Incio de um novo ciclo de interao (N), (N+ 1)

Trmino do ciclo de interao atual (N)

Figura VII.4 - Passos da Pesquisa-ao e correspondentes atividades (ciclo 3) Fonte: elaborado pelo autor

Em sua primeira verso funcional, sistema foi construdo no passo da

implementao 1 (ver item VII.2.1 e Figura VII.5), aps seu trmino, realiza-se o

treinamento dos usurios. Com o sistema em uso, constatou-se divergncias entre o

comportamento simulado no ciclo 2 e seu uso efetivo, de modo que durante o passo

de anlise e planejamento da iterao 1 foram escolhidos usurios representativos

do perfil das atividades de cada laboratrio para a realizao de entrevistas (ver item

II.8.2) para avaliao destas questes.

Como consequncia, no passo de implementao da iterao 2, foram

desenvolvidos artefatos visando a corrigir os problemas encontrados em campo.

Com estes artefatos desenvolvidos, mas no colocados em produo, foi realizada a

229

primeira sesso com parte dos usurios dos laboratrios, dividindo-se a sesso de

apresentao em duas partes.

Na primeira, foram discutidos alguns dos problemas levantados nas entrevistas,

empregando-se como guia um conjunto de questes para avaliao das

caractersticas do trabalho cooperativo (ver questionrio do Quadro IV.7 ).

Na segunda parte da sesso, foram usados como proposta para resolver os

problemas encontrados em campo os artefatos desenvolvidos durante o passo de

implementao da iterao corrente (resultantes da avaliao das entrevistas

durante o passo de anlise da iterao 1), servindo como elementos de

representao comum e dando suporte, tambm, discusso de novas questes

emergentes surgidas pelo uso do sistema.

No passo de anlise e planejamento, a avaliao do questionrio aplicado na

primeira parte da sesso foi realizada, decidindo-se pelo treinamento de dois

usurios (tutores) com a funo de manter o processo social em seus laboratrios.

Neste passo, tambm, verificou-se a necessidade de se realizar uma nova iterao

ou se o ciclo poderia terminar.

Implementao 2

Sesso 1

Parte1

Discusso

sobre uso

cooperativo do

sistema

Parte 2

Artefatos p/

validao

Novos

detalhamentos

Implementao 1

Treinamento

Anlise e planejamento 1

Entrevistas com usuriosAnlise e

planejamento 3

Iterao 1 Iterao 2 Iterao 3

Sesso 2

Parte1

Discusso

sobre uso

cooperativo do

sistema

Parte 2

Artefatos p/

validao

Novos

detalhamentos

Implementao 3

Anlise e

planejamento 2

Artefatos p/ discusso/

detalhamento/novos assuntos

Uso do sistema

Informaes p/

detalhamento dos

artefatos

Artefatos em uso

Figura VII.5 - Dinmica das iteraes do ciclo 3

Na terceira, iterao foram implementados (implementao 3 da Figura VII.5) os

artefatos emergentes discutidos na segunda parte da sesso da iterao anterior e

colocados em produo (para uso no sistema) e os artefatos desenvolvidos no

230

passo de implementao da segunda iterao, alm do treinamento dos tutores para

dar apoio aos usurios dos grupos de trabalho.

Aps o uso destes artefatos, foi realizada uma nova sesso com parte dos usurios

dos laboratrios e, assim como na sesso anterior foi dividida duas partes. Na

primeira, foi aplicado um conjunto de questes para avaliao das caractersticas do

trabalho cooperativo (ver questionrio do Quadro IV.7).

Na segunda parte da sesso, foram discutidos os resultados dos artefatos

desenvolvidos (utilizados como elementos de representao comum), assim como a

questo do tutor do grupo (ver item VII.3.2).

Na segunda parte da sesso, foi realizada tambm uma discusso geral sobre o uso

do sistema, com alguns novos artefatos sugeridos, mas que no precisariam ter sua

implementao realizada no curto prazo (ou seja, no haveria necessidade de se

realizar uma nova iterao), assim como a validao das alteraes realizadas nas

iteraes 2 e 3.

VII.3 RESULTADOS (DETALHAMENTO DAS ITERAES)

VII.3.1 Iterao 1

Esta iterao iniciou-se com a implementao do software para uso em ambiente de

trabalho, a partir dos requisitos e modelos de sistema discutidos no ciclo 2 (neste

ciclo, somente foram apresentados os artefatos relativos ao estudo desta pesquisa,

j que para a implementao do software so necessrios outros artefatos no

discutidos no ciclo 2 e que no fazem parte desta pesquisa).

Assim, o desenvolvimento do software passa da fase de anlise de requisitos fase

de projeto, codificao e testes de produto (de unidade e integrao), permitindo o

acompanhamento da evoluo dos requisitos do trabalho cooperativo ao longo da

construo do sistema (ciclo 3), sem entrar em detalhes sobre a construo desses

artefatos.

Gonalves et al. (2005) descrevem tais artefatos de projeto e implementao e sua

relao com os projetistas, nos quais um analista de banco de dados gera os

procedimentos armazenados (camada de dados), de acordo com as funcionalidades

231

levantadas com o projetista Web (camada de negcios). gerado, ento, um

prottipo funcional da aplicao. Para isto, o projetista Web recebe o cdigo HTML

das pginas, feito pelo Web designer e, usando programao em ASP (Active

Server Pages), faz a integrao funcional com o banco de dados, a partir dos

procedimentos armazenados, criados pelo analista de banco de dados.

No passo de levantamento e discusso dos dados, o treinamento dos usurios foi

realizado em duas turmas: uma para cada laboratrio. Antes do treinamento, foi

necessrio um estudo nos laboratrios com o objetivo de verificar quem eram os

provveis responsveis pelas fases do processo de atendimento (para preparar os

exemplos do treinamento) e a adequao do SI ao sistema informatizado a ser

implantado, com o planejamento da mudana do processo no automatizado para o

processo automatizado.

Durante a realizao do treinamento para cada um dos laboratrios, foram usados

exemplos desenvolvidos para esta finalidade por meio de prvia avaliao realizada

nos laboratrios. O objetivo dos exemplos de aplicao foi aproximar o modelo

mental de projeto (ciclo 2 desta PA) ao modelo mental do usurio (ver item II.3.1). A

estrutura do ambiente de treinamento descrita no item VII.2.1.

Aps o treinamento, o sistema foi colocado em produo e, durante os primeiros 2

meses de operao, verificou-se que o uso em ambiente real no estava

correspondendo plenamente ao esperado como foi simulado no ciclo 2. Estas

constataes foram observadas nos resultados do uso do sistema e pelo apoio aos

usurios (help desk):

Os pedidos de faturamento foram emitidos de forma incorreta acima da taxa

observada, antes da implantao do sistema, em funo sobretudo da

escolha indevida dos clientes do pedido, assim como da escolha incorreta do

contedo dos documentos tcnicos;

Utilizao de meios alternativos, como planilhas, para registrar informaes

fornecidas pelo sistema;

Dificuldade no gerenciamento dos oramentos, causando, em alguns casos,

atrasos na entrega dos servios ao cliente;

Dificuldade para concatenar as tarefas do prprio usurio com as dos demais

participantes do grupo, em especial, na fase de Inspeo/execuo;

232

Dificuldade de organizar suas pendncias dentro de um dado processo.

Em paralelo com a fase de implementao da primeira iterao, o autor participou de

uma pesquisa realizada em Web Sites de projetos da indstria de arquitetura,

engenharia e construo de edifcios com o objetivo de estudar os aspectos do

trabalho cooperativo no uso destes sites por meio dos conceitos da teoria da mente

coletiva (ver item II.4) (GONALVES et al., 2008).

Este estudo mostrou em relao s aes que:

No aspecto da contribuio, a falta de retorno (feedback) do site no permitia

aos usurios verificar o resultado de sua contribuio com relao aos demais

participantes;

A representao era dificultada por falta de ferramentas visuais no site;

A subordinao era baixa sobretudo em razo da imposio do uso do

software pelas empresas de construo.

Em relao aos processos sociais,

Eram necessrias reunies peridicas para manter a representao do

sistema;

Experincia anterior no processo no automatizado permitia aumentar a

representao para uso do software.

Assim, esta pesquisa evidenciou que, para melhorar o uso cooperativo do sistema,

era necessrio implementar ferramentas que permitissem melhorar as diferentes

formas de visualizao das informaes (usabilidade) no site, assim como para

manter os processos sociais era preciso o treinamento dos usurios e promover

encontros peridicos para conservar a representao.

Visando a entender melhor as razes pelas quais o uso em ambiente real no

estava correspondendo ao esperado e considerando-se os resultados da pesquisa

acima descrita, foram realizadas entrevistas com usurios encontrados nos

laboratrios: secretrias, tcnicos executantes dos servios, chefes de laboratrio e

pesquisadores (estes dois ltimos normalmente eram responsveis pelo oramento).

Antes da realizao das entrevistas, os objetivos e a forma de realizao das

mesmas foram apresentados aos usurios, sendo normalmente realizadas em local

de trabalho, consistindo na descrio dos usurios de suas atividades aps a

233

realizao das mesmas, porm no foram acompanhadas dos dados de

observao.

Procurou-se orientar os usurios, utilizando sua atividade efetiva como fio condutor e

quando necessrio, ajudando-os pela referncia a uma ocorrncia particular da

atividade por meio de exemplos de visualizao de algumas das interfaces grficas

utilizadas. Esta orientao foi facilitada na medida que o entrevistador possua pleno

conhecimento da sequncia do fluxo do processo automatizado.

Primeiro, foram entrevistadas duas secretrias (uma de cada laboratrio) e o que se

observou pela descrio de suas atividades, com relao aos erros observados no

pedido de faturamento, foi que no existia um mecanismo para informar possveis

alteraes cadastrais do cliente durante o processo de atendimento a um pedido,

nem a possibilidade de sua troca, caso fosse escolhido erroneamente no incio do

processo.

Outro aspecto descrito por uma das secretrias foi que em razo destes problemas,

a mesma possua uma planilha para registro dos valores faturados, pois alguns

faturamentos eram realizados por fora do sistema, isto , diretamente pela

ferramenta de pedido do faturamento do ERP (neste caso, o sistema no

contabilizava tal faturamento), alm do fato que, em atendimentos de curta durao

(3 a 4 dias teis), o processo informatizado no estava fluindo na mesma velocidade

da execuo fsica do servio, com um estrangulamento na fase de Composio do

documento.

Pela descrio destas usurias e por meio de um exemplo apresentado pelo

entrevistador, percebeu-se tambm que pelo fato delas terem para si a

responsabilidade de atuar em mais de uma fase, sua lista de pendncia (pgina

principal) estava sobrecarregada com muitos processos pendentes, j que todos

eram visualizados, dificultando a organizao das pendncias de um dado pedido

(processo).

Nestas entrevistas com as secretrias, realizou-se uma ltima avaliao que, em

alguns casos, os pedidos deveriam ser encerrados antes do faturamento do pedido

(por exemplo, pela desistncia do cliente aps a aprovao do oramento, pela

impossibilidade tcnica da realizao do servio, etc.)

234

Aps as entrevistas com as secretrias, foram entrevistados dois tcnicos

executantes de servios (um de cada laboratrio) e, pela descrio de suas

atividades no uso do software, percebeu-se que estes ficavam desorientados na

fase de Inspeo/execuo, sobretudo quando as ordens de servios distribudas na

fase de Distribuio de OS (ver item VI.3.4) deveriam ser realizadas por mais de um

tcnico (ou seja, os servios a serem realizados em um material deveriam ser

executados por mais de um tcnico), isto porque ao serem confrontados com a

interface de inspeo/execuo, estes tcnicos no conseguiam perceber para

quem deveriam enviar a fase (e o material respectivo), aps a realizao do servio

que lhes era atribudo.

Neste caso, para que pudesse saber como sua ao estava relacionada s de

outros colegas do grupo, seria necessrio que o tcnico fosse at a pgina principal,

na opo de Relatrios internos da Figura VI.18-5 e acessasse a opo de

Pedidos em andamento do grupo de trabalho e verificasse para quem deveria

enviar o material para realizao do servio.

E, por ltimo, um chefe de laboratrio e um pesquisador (cada um pertencente a

laboratrios distintos) foram entrevistados, em geral, estes usurios eram

responsveis pela composio do oramento (criao de um novo oramento) e do

envio ao cliente (fase de Oramentao), negociao (fase de Followup) e da

composio e distribuio do documento tcnico (fase de Composio do

documento tcnico).

Verificando-se as atividades executadas pelos mesmos por meio de sua descrio

sobre como operavam suas fases no processo e como gerenciavam seu trabalho,

percebeu-se que estes usurios tinham dificuldades para avaliar as entregas e a

execuo dos servios durante o processo de atendimento, pois precisavam

consultar vrios locais diferentes da aplicao para obter as informaes

necessrias a este gerenciamento.

Durante a entrevista de um destes usurios (responsvel pelo laboratrio), quando

estava descrevendo como operava a fase de Composio do documento tcnico,

pde-se confirmar a questo colocada na entrevista aos tcnicos e das secretrias,

pois muitas vezes, demorava-se muito tempo para poder compor e distribuir um

documento tcnico (ver Figura VI.16), uma vez que o tcnico no tinha informado na

235

fase de Inspeo/execuo sobre o status do pedido (em andamento, concludo,

suspenso e cancelado ver Figura VI.15).

Durante a descrio da fase de Followup pelo usurio pesquisador, percebeu-se

pelas suas observaes que sentia dificuldade para recuperar uma determinada

negociao com o cliente; e, em certas situaes, em que ocorria intensa

negociao, esta era registrada em documento externo ao sistema para futura

consulta (sobretudo no caso de auditoria do sistema interno da qualidade).

Nos dados do Quadro VII.1 abaixo, pode ser visto um resumo destas entrevistas.

Quadro VII.1 - Resumo das entrevistas realizadas no passo de anlise e planejamento 1

Entrevista Usurios Resumo

Grupo 1

Secretrias

Problemas no cadastro de cliente.

Fluidez do processo para prazos curtos de atendimento.

Lista de pendncias sobrecarregada de fases de processos.

Encerramento intempestivo.

Grupo 2

Tcnicos

Dificuldade para perceber para quem enviar a fase de Inspeo/execuo, no caso de mais de um servio ser realizado no material.

Grupo 3

Chefe de laboratrio e pesquisador

Dificuldade em avaliar as entregas e execuo dos servios durante o processo de atendimento.

Dificuldade para recuperar uma determinada negociao com o cliente.

Fonte: elaborado pelo autor

VII.3.2 Iterao 2

Implementao 2

No passo de implementao desta iterao, os artefatos que serviram como

elemento de representao comum durante a segunda parte da sesso foram

desenvolvidos. Para esta implementao, foram consideradas as entrevistas

realizadas no passo de anlise e planejamento da iterao 1.

Ao se analisar os resultados das entrevistas, percebeu-se que os usurios

entrevistados nem sempre tinham conhecimento das atividades do grupo (a

contextualizao das atividades individuais por meio da compreenso das atividades

realizadas por outras pessoas), ficando em algumas situaes sem saber o que

aconteceu, o que estava acontecendo e/ou o que poderia vir a acontecer, ou seja,

havia necessidade de considerar mais detalhadamente o awareness do sistema (ver

item II.5.5) .

236

Deste modo, a utilizao dos elementos de awareness foi importante para orientar a

construo dos artefatos no passo de implementao desta iterao. Outro fator que

reforou a necessidade de se considerar estes elementos, foi a pesquisa da qual

participou o autor desta tese (item VII.3.1) que mostrou a necessidade do uso de

ferramentas visuais para melhoria da representao do trabalho cooperativo em

Web Sites de projetos da indstria de arquitetura, engenharia e construo de

edifcios.

Do mesmo modo que os conceitos da teoria da mente coletiva foram usados na

pesquisa realizada nos Web Sites de projetos de construo civil para avaliao do

trabalho cooperativo, no presente estudo tambm foi utilizada esta teoria para

avaliar a evoluo do trabalho cooperativo nas iteraes 2 e 3 deste ciclo, uma vez

que o sistema empregado nesta PA tem como caracterstica importante o fato de

que sua coordenao distribuda nas aes dos usurios, ou seja, sem um centro

definido de coordenao (item VII.2.3), pois esta caracterstica importante para a

aplicao da teoria.

Assim, utilizando-se os dados do Quadro VII.2 sobre os elementos de awareness e

tendo como guia de orientao a teoria da mente coletiva, foram desenvolvidos os

artefatos do Quadro VII.3, em que podem ser vistos quais elementos de awareness

foram considerados na construo desses artefatos e as respectivas aes da teoria

da mente coletiva. Estes artefatos sero mais bem detalhados na segunda parte da

sesso desta iterao.

Quadro VII.2 - Elementos de awareness para sistemas assncronos e desacoplados

Categoria Elemento Significado

O qu Atividades: Viso ampla das tarefas individuais e do grupo e de sua produo:

Aes O que fazer e o que os outros esto fazendo

Artefatos Em quais objetos esto trabalhando no momento

Produo Quais so os resultados preliminares do trabalho

Histrico de

aes

O que um indivduo esteve realizando

Papis: Diferenciao das informaes em funo do papel

Alcance At onde podem ou devem

Quando Eventos passados, passado

continuo e

Contexto sobre o que foi feito (eventos no passado) e do que ainda est sendo feito (passado contnuo),

237

Categoria Elemento Significado

presentes:

Histrico de eventos

Quando um evento aconteceu

Eventos futuros Representam uma opo interessante para manter os membros atentos aos possveis rumos do trabalho.

Persistncia Alta: Definio de um critrio de caducidade, que inutiliza estas informaes.

Apresentao das informaes de awareness

Posterior (a critrio do usurio)

Onde Espao compartilhado

Objetos compartilhados pelo grupo. Por meio de sua manipulao, mostra o que houve e est acontecendo dentro do trabalho em grupo.

Histrico de artefatos

Como um determinado artefato chegou quele estado

Histrico de localizao

Onde um indivduo esteve

Metforas de sistema

Relacionam o groupware com verses monousurias do sistema, havendo a necessidade de enriquec-la adequadamente com as informaes de awareness.

Como Interface Interfaces desacopladas, mas no impedindo a interface de incluir elementos para awareness

Balanceamento de interface

Filtragem ou um agrupamento das informaes, mostrando apenas aquilo que for mais til

Quem Autoria Quem realizou um determinado evento

Histrico de presena

Quem esteve em um local do ambiente e quando

Ferramentas de comunicao

Essencialmente ferramentas assncronas (email, quadro de avisos e notas, etc.)

Fonte: reproduzido do Quadro II.1 Quadro VII.3 - Artefatos desenvolvidos como resultados obtidos das entrevistas da iterao 1

Artefato/Entrevista Elementos de awareness Aes

Troca de cliente/Alterao cadastral /Grupo 1

Onde (espao compartilhado)/Quem

(Ferramentas de comunicao)

Contribuio, subordinao

Filtros na pgina principal/Grupo 1 Como (balanceamento das interfaces)

Representao

Encerramento intempestivo do pedido/ Grupo1

Quando (persistncia) Representao

Relao das OSs distribudas na fase de Inspeo/execuo /

Grupo 2

O qu (artefatos) Representao

Viso geral dos pedidos/Grupo 3 O qu (produo) Representao

Histrico de negociaes com cliente/ Grupo 3

Onde (histrico de artefatos) Contribuio, subordinao

Fonte: elaborado pelo autor

238

Levantamento e discusso dos dados (sesso 1)

No incio da sesso 1, conforme descrito na iterao 1 do ciclo 2, os participantes

apresentaram-se e os pesquisadores deram esclarecimentos a respeito dos

objetivos da pesquisa e mostraram um conjunto de regras para melhor

encaminhamento das sesses:

Deixaram claro que todas as opinies interessavam e, portanto, no existiam

opinies certas ou erradas e ressaltaram a importncia das manifestaes

individuais contra ou a favor;

A durao prevista para a sesso;

A dinmica da sesso, conforme descrito no item VII.2.4;

Dentro do possvel, s uma pessoa falaria de cada vez;

Evitar discusses paralelas para que todos pudessem participar;

Inicialmente, na primeira parte da sesso, a cada usurio foi entregue um formulrio

com questes (ver Quadro VII.4) sobre o uso do sistema baseado na teoria da

mente coletiva (GAVA et al., 2008).

O formulrio apresenta tambm questes sobre os processos sociais (ver item II.4.2)

que esto em curso em todo sistema social a que pertence um grupo de trabalho

com particular importncia no sistema de informao em que foi realizada esta PA

(coordenao distribuda no padro de comportamento dos usurios), j que estes

processos so teis para manter a representao do sistema.

Os pesquisadores esclareceram as dvidas dos usurios e procuraram evitar vieses

nas explicaes, confirmando a cada questo o preenchimento das respostas por

parte dos usurios.

Aps o preenchimento dos formulrios pelos usurios, passou-se para a discusso e

validao dos artefatos desenvolvidos no passo de implementao 2. Para tanto,

primeiro foi apresentado qual problema o mesmo deveria resolver e a situao real

verificada em campo pelas entrevistas.

239

Quadro VII.4 - Avaliao qualitativa do trabalho cooperativo nas sesses de ACT

Questes a respeito das aes/comportamento C: Contribuio, R: Representao S: Subordinao

Sesso1

Nmeros de No

Nmeros de Sim

Voc sabe em qual fase do processo pode atuar? (R)

Voc sabe quais so os dados mais importantes a serem inseridos? (C)

Estando na fase de sua responsabilidade, sabe quem deve ser o responsvel pela prxima fase? (C)

Voc sabe de que outras fases depende a sua? (R)

Quando insiro um dado errado em uma fase de minha responsabilidade, sei das consequncias no processo deste erro para as fases posteriores? (R)

Distingue qual sua posio atual no processo? (R)

Distingue quem so os responsveis pelas atividades que esto sendo desenvolvidas? (R)

Confia que as informaes que chegam at voc pelo sistema so as mais atualizadas? (S)

Voc utiliza o sistema para trocar informaes com outros usurios, sem a necessidade de outros meios?(S)

Voc toma decises por meio das informaes fornecidas pelo sistema? (S)

Voc sabe como acompanhar as metas do grupo? (R)

Voc sabe como as aes dos outros usurios esto relacionadas com as suas? (R)

Voc sabe como acompanhar o trabalho de outros membros do grupo? (R)

Voc sabe como recuperar as informaes que inseriu no sistema? (R)

Voc sabe como recuperar as informaes que outros membros do grupo inseriram no sistema? (R)

Questes a respeito do processo social So: Socializao, Co: Conversao Re: Recapitulao

Existe um programa de treinamento para novos usurios? (So)

Os usurios trocam experincia regularmente a respeito da utilizao do sistema? (Co)

Ocorrem encontros programados para a discusso do uso e dos resultados do sistema? (Re)

Fonte: Elaborado pelo autor, baseado em WEIK and ROBERTS (1993)

Desse modo, os primeiros artefatos discutidos foram os referentes s entrevistas

com as secretrias (Grupo 1 do Quadro VII.1), iniciando-se com os artefatos

relativos Troca de cliente/Alterao cadastral. O acesso a esta opo realizado

pela pgina principal, como pode ser visto na Figura VII.6-2, j que poder ser

escolhido em qualquer fase do processo (ou atendimento no jargo dos usurios).

Figura VII.6 - Pgina principal e opes

240

Inicialmente o usurio faz uma pesquisa para procurar um pedido (Figura VII.7), no

qual lhe oferecida a opo de escolher entre editar um cliente ou editar/trocar

(nem sempre ser possvel trocar um cliente, dependendo do pedido j possuir ou

no um documento tcnico).

Figura VII.7 - Troca de cliente/Alterao cadastral

Aps esta escolha (Figura VII.7-2), o usurio pode editar um quadro de observao

(Figura VII.8-1) que ser transferida para um campo correspondente no formulrio

do pedido de faturamento. Deste modo, quando um usurio informar os dados

relativos a este campo em qualquer parte do processo, esta informao ser

repassada ao usurio responsvel pelo pedido de faturamento, como se fosse um

quadro de aviso relativo quele pedido.

Outro aspecto abordado foi o fato da lista de pendncias apresentar vrias fases de

processos distintos. Para esta situao na pgina principal, foi criado um filtro (ver

Figura VII.6-4) para o usurio escolher qual fase do processo (convm relembrar

que no jargo dos laboratrios os termos fase e processo utilizados nesta pesquisa

correspondem, respectivamente a processo e a atendimento) poderia ser

visualizada, diminuindo as fases pendentes e facilitando sua coordenao dentro de

suas pendncias (no exemplo em questo esto sendo listados apenas os

processos na fase de oramentao).

241

Figura VII.8 - Alterao cadastral

Na discusso desta opo, os usurios citaram a importncia de se realizar uma

ordenao por data (direta e reversa) de atualizao da fase (ver Figura VII.6-1)

visto que, muitas vezes, era mais importante acessar uma fase que teve atualizao

recente, a despeito de seu nmero de pedido ser menor (mais antiga), dificultando

sua localizao na lista.

Na sequncia foi apresentada a opo para o problema do trmino do processo em

qualquer fase (desistncia do cliente aps aprovao, problema com o material,

problemas no laboratrio, etc.). Para tanto, foi criado um artefato (acessado pela

pgina principal, ver Figura VII.6-3) para tratar a questo. Assim, ficou estabelecido

que s os responsveis pelo oramento poderiam encerrar um pedido, antes de seu

trmino normal (aps o faturamento). Este artefato no ser apresentado neste

trabalho pelos motivos descritos no item VII.1.

O prximo artefato apresentado para discusso na sesso foi relativo situao

descrita pelos tcnicos nas entrevistas (Grupo 2 do Quadro VII.1). Na Figura VII.9-1,

242

pode ser vista a fase de Inspeo/execuo, com a adio de uma opo para

ajudar a resolver o problema mencionado, no qual o usurio pode ver em sua fase

todas as distribuies realizadas e no apenas a ordem de servio que lhe diz

respeito.

Desse modo, seria possvel para o usurio perceber outros servios associados ao

material e que no estavam sob sua responsabilidade, permitindo o relacionamento

de suas aes com as dos demais participantes do grupo (no exemplo em questo,

o Servio teste 4 dever ser executado pelo NOME COLABORADOR 2, alm do

Servio teste 2 que o prprio NOME COLABORADOR 1 dever executar) .

Figura VII.9 - Inspeo e execuo da OS (servios associados ao material da fase)

Na discusso deste artefato, os usurios concluram que tambm seria importante

mostrar na fase, alm das ordens de servio relativas ao material associado quela

fase, todas as ordens de servios referentes aos materiais registrados (Figura VII.10-

1).

243

Figura VII.10 - Inspeo e execuo da OS (servios associados aos demais materiais)

As entrevistas do grupo 3 mostraram a necessidade de apresentar as informaes

do processo de atendimento de forma mais integrada, permitindo aos usurios fazer

uma previso de suas atividades, assim como a necessidade de manter o estado de

negociao na fase de Followup.

Para o primeiro caso (informaes integradas), foi apresentado o artefato da Figura

VII.11, acessado por meio da pgina principal, na aba relatrios internos, subitem

Viso-geral (Figura VII.6).

Por intermdio de um conjunto de filtros (Figura VII.11-1) relativos s diversas fases

do atendimento possvel verificar, por exemplo, a situao das ordens de servios

realizadas (Figura VII.11-4), a folga entre a data atual de pesquisa e a data de

entrega (Figura VII.11-5) e a data de entrega prevista (Figura VII.11-6).

244

Figura VII.11 - Viso geral

Durante a discusso coletiva deste artefato, os usurios tambm consideraram

importante visualizar uma cpia do oramento enviado ao cliente (link da Figura

VII.11-2), assim como um detalhamento das ordens de servio (link da Figura VII.11-

3), mostrando em outra janela de navegao todos os servios associados aos

respectivos materiais, responsveis pela execuo e situao da execuo (ver

Figura VI.16-1). Estas duas ltimas opes no sero apresentadas neste trabalho.

O artefato permite monitorar os pontos nos quais a fase de Composio do

documento pode impedir a fluidez do processo, centralizando em um nico local as

informaes distribudas nas fases do processo de atendimento relativas

distribuio e execuo das ordens de servio.

Na Figura VII.12-1, o registro de um histrico pode ser visto na negociao realizada

com um cliente na fase de Followup que corresponde ao ltimo artefato

apresentado aos usurios relativo ao grupo 3 de entrevistas. Durante esta

discusso, os usurios perceberam que a fase de Elaborao do documento tcnico,

tambm, deveria ter esta caracterstica de awareness (esta fase no ser mostrada

neste trabalho, j que seu histrico equivalente ao da fase de Followup).

245

Figura VII.12 - Histrico de follow-up

Aps a discusso sobre os artefatos desenvolvidos nas entrevistas da iterao 1,

foram citadas algumas questes sobre a dinmica do envio das fases dentro do

grupo de trabalho pelos usurios. Um aspecto emergente desta discusso foi a

necessidade de visualizar a fase que estava com outro usurio para dar seguimento

s atividades do prprio usurio, ou mesmo, a situao onde era necessrio assumir

a fase de outro usurio para dar andamento ao prprio trabalho e o trabalho do

grupo (por exemplo, na situao da ausncia do responsvel pela fase).

Para atender a esta necessidade, foi discutida uma soluo na qual um usurio

poderia visualizar uma fase que no estivesse sob sua responsabilidade, podendo

envi-la ainda a outro usurio ou assumi-la para si (acesso transversal ao processo,

isto , sem que o mesmo estivesse na pendncia do usurio).

246

Nas Figura VII.14 e Figura VII.15, podem ser vistas a soluo adotada aps sua

implementao na iterao 3. importante ressaltar que estes artefatos foram

implementados de fato no passo implementao 3 da iterao 3 e que para

elemento de representao comum foram adaptados trechos de outros artefatos

para simular parte da soluo, ou mesmo, ferramenta para desenho, uma vez que

durante esta discusso estes artefatos ainda no existiam, como os demais

apresentados at o momento.

O acesso ao mesmo realizado pela pgina principal, na aba de Acesso

transversal (Figura VII.13-1).

Figura VII.13 - Pgina principal: acesso transversal

Na Figura VII.14-1, as opes de filtro so mostradas e, nesse caso, foi inserido um

filtro por usurio e na Figura VII.14-2 encontra-se a lista de pendncias para o item

pesquisado (no caso, o nmero de pedido). Esta lista de pendncia equivalente

ao artefato de coordenao das atividades do grupo Pedidos em andamento (ver

Figura VI.19) e o objetivo permitir ao usurio perceber quais so todas as fases

pendentes daquele pedido, sem ter a necessidade de voltar pgina principal e

procurar esta opo na aba Relatrios internos.

247

Figura VII.14 - Acesso transversal: pendncias

Uma vez verificada as fases pendentes nesta lista, o usurio escolhe a fase que

deseja visualizar (Figura VII.15-1), acionando o boto Confirmar (Figura VII.15-2,

no caso em questo foi selecionada a fase Composio do documento que est

com o NOME COLABORADOR 4). Assim, o usurio poder visualizar/editar o

contedo desta fase (ver Figura VII.16) e se quiser poder, inclusive, envi-la a outro

usurio (no caso ser enviada para o NOME COLABORADOR 5, ver Figura VII.16-

1).

Figura VII.15 - Acesso transversal: escolha da fase

248

Figura VII.16 - Composio do documento tcnico visualizado por meio do artefato Acesso transversal

Na discusso sobre o acesso transversal, os participantes da sesso levantaram a

situao na qual se um usurio pudesse entrar e atualizar uma fase que no

estivesse em sua lista de pendncias (sob sua responsabilidade), o sistema deveria

registrar um histrico sobre o acesso a esta fase.

Assim, surgiu outro aspecto emergente da sesso que foi a necessidade de um

artefato para registrar quem era o responsvel pela fase, quem a acessou e para

quem a enviou. A discusso das caractersticas que este artefato deveria possuir

trouxe tona o fato de que o mesmo poderia contribuir como ferramenta auxiliar

para verificar a fluidez do processo, verificar se houve encerramento intempestivo e

aumentar a confiana (subordinao) no sistema, pois os usurios poderiam saber

quem acessou/alterou determinada fase.

A Figura VII.17 mostra como ficou este artefato aps sua implementao na iterao

3, na Figura VII.17-1 esto as opes de filtro que foram sugeridas durante a sesso

e na Figura VII.17-2 um exemplo de resultado para pesquisa por nmero de pedido,

mostrando a situao descrita na Figura VII.16-1, cuja fase estava com o usurio

249

NOME COLABORADOR 4 foi acessada pelo NOME COLABORADOR 1 e enviada

ao usurio NOME COLABORADOR 5.

Figura VII.17 - Histrico de andamento do pedido

Nos dados do Quadro VII.5, pode ser observada a relao entre os elementos de

awareness associados aos artefatos emergentes surgidos nesta sesso e as

respectivas aes da teoria da mente coletiva.

Quadro VII.5 - Artefatos emergentes da sesso 2, elementos de awareness e aes

Artefato/Entrevista Elementos de awareness Aes

Acesso transversal O que (aes, artefatos e produo)

Representao, contribuio e subordinao

Histrico de andamento de pedidos

O que (histrico de aes), Quando (histrico de

eventos) e Onde (histrico de localizao)

Representao, subordinao

Fonte: elaborado pelo autor

250

Anlise e planejamento 2

No passo de anlise e planejamento desta iterao, o resultado do questionrio

sobre o trabalho cooperativo aplicado aos usurios foi avaliado na primeira parte da

sesso (ver Tabela VII.1).

Tabela VII.1 - Avaliao qualitativa do trabalho cooperativo da sesso 1

Questes a respeito das aes/comportamento C: Contribuio, R: Representao S: Subordinao

Sesso1

Nmeros de No

Nmeros de Sim

Voc sabe em qual fase do processo pode atuar? (R) 3 9

Voc sabe quais so os dados mais importantes a serem inseridos? (C) 2 10

Estando na fase de sua responsabilidade, sabe quem deve ser o responsvel pela prxima fase? (C)

4 8

Voc sabe de que outras fases dependem a sua? (R) 5 7

Quando insiro um dado errado em uma fase de minha responsabilidade, sei das consequncias no processo deste erro para as fases posteriores? (R)

9 3

Distingue qual sua posio atual no processo? (R) 4 8

Distingue quem so os responsveis pelas atividades que esto sendo desenvolvidas? (R)

7 5

Confia que as informaes que chegam at voc pelo sistema so as mais atualizadas? (S)

5 7

Voc utiliza o sistema para trocar informaes com outros usurios, sem a necessidade de outros meios?(S)

7 5

Voc toma decises por meio de informaes fornecidas pelo sistema? (S) 7 5

Voc sabe como acompanhar as metas do grupo? (R) 8 4

Voc sabe como as aes dos outros usurios esto relacionadas com as suas? (R)

9 3

Voc sabe como acompanhar o trabalho de outros membros do grupo? (R) 8 4

Voc sabe como recuperar as informaes que inseriu no sistema? (R) 8 4

Voc sabe como recuperar as informaes que outros membros do grupo inseriram no sistema? (R)

10 2

Questes a respeito do processo social So: Socializao, Co: Conversao Re: Recapitulao

Existe um programa de treinamento para novos usurios? (So) 10 2

Os usurios trocam experincia regularmente a respeito da utilizao do sistema? (Co)

5 7

Ocorrem encontros programados para a discusso do uso e dos resultados do sistema? (Re)

10 2

Porcentual do total de respostas (mdia geral): 56% 44%

Fonte: Elaborado pelo autor, baseado em WEIK and ROBERTS (1993)

Em funo dos resultados qualitativos obtidos, nos quais s 44% das respostas

foram positivas a respeito do estabelecimento das aes e dos processos sociais,

decidiu-se pelo treinamento de dois usurios (tutores) com a funo de manter o

processo social em seus laboratrios.

Os usurios tinham como responsabilidade incentivar a discusso sobre o uso do

sistema, providenciar a integrao dos novos usurios, dar suporte local s dvidas

251

sobre o emprego do sistema e das novas funcionalidades e realizar reunies locais

para discusso e incentivo do relato de experincias no uso do sistema.

Os resultados gerais, tambm, mostraram que em torno da metade dos usurios no

possua uma representao adequada do processo automatizado, reforando o

resultado das entrevistas realizadas durante o passo de anlise e planejamento da

iterao 1, incentivando a construo dos artefatos emergentes discutidos durante

esta sesso na fase de implementao da prxima iterao.

VII.3.3 Iterao 3

Nesta iterao, no passo de implementao, foram construdos os seguintes

artefatos emergentes discutidos durante a iterao 2: Acesso transversal s fases e

Histrico de fases do pedido, alm de correes nos artefatos desenvolvidos durante

o passo de implementao 2 e apresentados durante a sesso da iterao 2.

Durante este passo, os tutores foram treinados no uso dos artefatos que entrariam

em produo para dar apoio aos usurios dos grupos de trabalho, sendo instrudos

no sentido de manter os processos sociais, conforme a teoria da mente coletiva:

socializao, conversao e recapitulao (ver item II.4.2).

Os artefatos dos passos de implementao 2 e 3 foram colocados em produo logo

aps sua implementao (contrariamente, ao que aconteceu nas iteraes 1 e 2),

pois, alm de j terem sido validados pelos usurios na sesso 1, tambm, teriam o

apoio dos tutores, logo aps serem colocados em produo.

Quando a sesso 2 foi realizada, os artefatos implementados j estavam em uso,

assim como o apoio dos tutores aos grupos. Na primeira parte desta sesso, os

pesquisadores fizeram os mesmos esclarecimentos da sesso 1 (ver item VII.3.2).

Do mesmo modo que ocorreu na sesso 1, inicialmente, foi entregue a cada usurio

um formulrio com questes (ver Quadro VII.4) para avaliao da evoluo do

trabalho cooperativo pelo uso do sistema (GAVA et al., 2008).

Nesta sesso, tambm, os pesquisadores esclareceram eventuais dvidas dos

usurios, procurando evitar vieses nas explicaes e confirmando a cada questo o

preenchimento da resposta por parte dos usurios.

252

Para facilitar a discusso coletiva, algumas situaes foram apresentadas relativas

ao processo automatizado e encontradas no dia a dia dos laboratrios (aps a

anlise feita pelos desenvolvedores dos dados associados s fases dos processos

no banco de dados e tambm consulta aos tutores).

Uma das situaes discutidas foi at que ponto os oramentos enviados e no

aprovados deveriam ficar no sistema, j que no processo no informatizado esta

situao, em geral, no precisava ser tratada. Aps as discusses ficou estabelecido

que o sistema deveria encerrar de modo automtico os pedidos cujos oramentos j

estavam vencidos aps um determinado nmero de dias (a ser definido pelo

responsvel da fase de Followup). A data final seria contada a partir da data de

envio do oramento e do prazo de validade do pedido, somado ao nmero de dias

definido na fase de Followup.

Para atender a esta questo, os usurios concordaram com o pesquisador que

estava conduzindo a sesso que seria necessrio desenvolver um mecanismo de

software (um programa que seria executado pelo sistema operacional todo noite

para desativar os oramentos no aprovados na situao descrita), mas este no

precisaria ser apresentado aos usurios em uma nova sesso.

Algumas dvidas sobre o melhor uso das ferramentas do software foram discutidas,

mas de um modo geral os problemas discutidos restringiram a dvidas de alguns

usurios sobre os aspectos especficos do sistema, mas que no implicavam em

alteraes do processo de atendimento.

No passo de anlise e planejamento 3, a necessidade de realizao de novas

sesses foi avaliada, assim como o resultado do questionrio sobre o trabalho

cooperativo aplicado aos usurios na primeira parte da sesso.

253

Tabela VII.2 - Avaliao qualitativa do trabalho cooperativo da sesso 2

Questes a respeito das aes/comportamento C: Contribuio, R: Representao S: Subordinao

Sesso2

Nmeros de No

Nmeros de Sim

Voc sabe em qual fase do processo pode atuar? (R) 0 12

Voc sabe quais so os dados mais importantes a serem inseridos? (C) 0 12

Estando na fase de sua responsabilidade, sabe quem deve ser o responsvel pela prxima fase? (C)

0 12

Voc sabe de que outras fases dependem a sua? (R) 0 12

Quando insiro um dado errado em uma fase de minha responsabilidade, sei das consequncias no processo deste erro para as fases posteriores? (R)

1 11

Distingue qual sua posio atual no processo? (R) 0 12

Distingue quem so os responsveis pelas atividades que esto sendo desenvolvidas? (R)

0 12

Confia que as informaes que chegam at voc pelo sistema so as mais atualizadas? (S)

5 7

Voc utiliza o sistema para trocar informaes com outros usurios, sem a necessidade de outros meios?(S)

4 8

Voc toma decises por meio das informaes fornecidas pelo sistema? (S) 5 7

Voc sabe como acompanhar as metas do grupo? (R) 2 10

Voc sabe como as aes dos outros usurios esto relacionadas com as suas? (R)

1 11

Voc sabe como acompanhar o trabalho de outros membros do grupo? (R) 2 10

Voc sabe como recuperar as informaes que inseriu no sistema? (R) 2 10

Voc sabe como recuperar as informaes que outros membros do grupo inseriram no sistema? (R)

2 10

Questes a respeito do processo social So: Socializao, Co: Conversao Re: Recapitulao

Existe um programa de treinamento para novos usurios? (So) 0 12

Os usurios trocam experincia regularmente a respeito da utilizao do sistema? (Co)

2 10

Ocorrem encontros programados para a discusso do uso e dos resultados do sistema? (Re)

1 11

Porcentual do total de respostas (mdia geral): 13% 87%

Fonte: Elaborado pelo autor, baseado em WEIK and ROBERTS (1993)

Nos dados da Tabela VII.2, encontram-se os resultados deste questionrio (GAVA et

al., 2008).

Verifica-se que houve um aumento da percepo dos usurios sobre o

estabelecimento das aes e dos processos sociais, de modo que em funo dos

resultados qualitativos obtidos nas duas sesses, houve uma evoluo de 44% (ver

Tabela VII.1) para 87% do nmero de respostas positivas.

A evoluo do nmero de respostas positivas, fruto da introduo dos novos

artefatos de awareness, com o maior grau de conscincia dos usurios de como os

inter-relacionamentos de suas atividades eram realizados, foi confirmado por meio

de um decrscimo nos erros individuais dos usurios e suas respectivas

consequncias nos resultados do trabalho em grupo.

254

Por exemplo, pelas medidas estabelecidas na iterao 2 (novos artefatos de

awareness e treinamento dos tutores), os erros individuais como escolha indevida de

cliente de um pedido, falta de aviso sobre mudanas cadastrais do mesmo na hora

de faturamento, falta de fluidez do processo, demora na informao sobre a

execuo de um servio, execuo de faturamento sem o uso do sistema, etc.

diminuram, tendo como consequncia uma melhoria nos resultados finais do

trabalho cooperativo, onde, por exemplo, os erros na emisso dos pedidos de

faturamento caram em 50% com relao mesma situao antes da informatizao

do processo.

Para a diminuio de erro na emisso de PF, tambm contribuiu o fato dos usurios

fazerem uma melhor amarrao entre o nmero dos documentos e o pedido de

faturamento em si, em razo do uso do software.

No caso da diminuio dos erros do pedido de faturamento, importante ressaltar

que esta reduo tem um limite, pois em muitos casos os prprios clientes informam

de modo incorreto os dados referentes sua empresa.

Outra melhoria foi na velocidade e qualidade na emisso/aprovao e negociao

dos oramentos, de modo que antes da implantao do sistema havia um gargalo

lgico na emisso destes (cerca de quatro por dia), passando para a emisso em

torno de 20 por dia com o sistema informatizado, mudando do gargalo lgico para o

fsico (impossibilidade de atendimento da demanda por falta de equipamento e

funcionrios especializados).

Finalmente, analisando-se os resultados obtidos na Tabela VII.2, bem como o fato

que, durante a sesso 2, o grupo no foi mais capaz de produzir novidades relativas

ao trabalho cooperativo em suas discusses, optou-se pelo trmino das sesses,

indicando que o processo de desenvolvimento do software e, tambm, de anlise de

requisitos entraram em uma fase de manuteno (ver Figura IV.8 e Figura IV.3).

VII.4 CONCLUSES DO CICLO 3 (PASSO DE MONITORAMENTO DA PA)

Assim como ocorreu no ciclo 2, as questes de pesquisa foram utilizadas para

orientar a discusso dos resultados obtidos (ver item III.4.5).

255

1. Quais so os instrumentos a serem elaborados para refinar os requisitos de

software da dimenso cooperativa do trabalho de um SI durante o uso do

sistema informatizado que lhe dar suporte?

Os instrumentos empregados para captar a dimenso cooperativa do trabalho

correspondem s tcnicas, mtodos, conceitos e modelos e so listados a seguir:

Dimenses do trabalho coletivo (ver item II.1.2);

Anlise coletiva do trabalho (ver item II.2);

Modelo mental e interao (ver item II.3);

Prototipao funcional (ver item II.8.3);

Modelos do sistema (ver item II.7.2);

Processo de desenvolvimento de software (ver item II.7.2);

A ergonomia e a concepo informtica na simulao e prototipao de

sistemas (ver item II.8.3);

Modelo de desenvolvimento iterativo evolucionrio (ver item II.6.3);

Processo de Engenharia de Requisitos (ver item II.7.2);

Entrevistas ( ver item II.8.2).

Com relao ao ciclo 2, novos instrumentos foram introduzidos visando ao

refinamento da especificao de requisitos do trabalho cooperativo durante o uso do

sistema:

Teoria da mente coletiva (ver item II.4);

Modelo 3C (ver item II.5.2);

Elementos de awareness (ver item II.5.5).

2. Como estes instrumentos podem ser concatenados para refinar os

requisitos de software do trabalho cooperativo durante o uso do sistema

informatizado?

Os elementos acima descritos foram concatenados empregando-se o processo

proposto no item IV.6 e aplicado por meio do ciclo da PA descrito neste captulo.

Assim, pela aplicao do processo estabelecido para este ciclo, foi possvel verificar

que um sistema informatizado (com as caractersticas descritas no item VII.2.3),

256

projetado visando a atender aos requisitos do trabalho cooperativo de um SI, deve

considerar a mudana das iteraes face a face dos usurios em um SI, a fim de

que haja um contato intermediado pelo sistema informatizado que apresenta um

ambiente menos rico para realizar as iteraes necessrias para que os objetivos do

trabalho cooperativo sejam alcanados.

Para tratar esta questo, elementos de awareness e do modelo 3C (ver item VII.2.2)

foram usados no passo de implementao da iterao 2, com o desenvolvimento de

uma srie de artefatos (ver Quadro VII.3). Alm destes, outros dois artefatos

emergentes de awareness surgiram na segunda parte desta sesso:

Acesso transversal: necessidade colocada pelo grupo para visualizar a fase

que estava com outro usurio para dar seguimento s atividades do prprio

usurio, ou mesmo, a situao que precisava assumir a fase de outro usurio,

para dar andamento ao prprio trabalho e ao do grupo;

Histrico de fases dos processos: necessidade de um artefato para registrar o

responsvel pela fase, quem a acessou e para quem foi enviada. A discusso

das caractersticas que este artefato deveria possuir, trouxe tona que o

mesmo poderia contribuir como ferramenta auxiliar para verificar a fluidez do

processo, verificar se houve encerramento intempestivo e aumentar a

confiana (subordinao) no sistema.

Outro aspecto importante foi que graas ao fato deste sistema informatizado ter sua

coordenao distribuda nas aes dos usurios (coordenao horizontal) e sendo

dependente do maior ou menor grau de conscincia de como estes inter-

relacionamentos so feitos, os usurios devem continuamente extrair um senso de

mudana de suas prprias inter-relaes e recolocarem-nas em ao no sistema de

informao, tornando-se importante manter os processos sociais de socializao,

conversao e recapitulao (ver item II.4.2).

Para atender a esta questo, dois tutores foram treinados no incio do passo de

implementao da iterao 3.

257

3. Como avaliar a evoluo da identificao dos requisitos de software do

trabalho cooperativo obtidos neste ciclo pela aplicao da soluo proposta?

Para avaliar qualitativamente a evoluo do trabalho cooperativo pelo uso sistema,

nas sesses 1 e 2 foi aplicado um questionrio com esta finalidade, utilizando os

conceitos da teoria da mente coletiva (ver Tabela VII.3 abaixo) (GAVA et al., 2008).

Tabela VII.3 - Avaliao qualitativa do trabalho cooperativo das sesses 1 e 2

Questes a respeito das aes/comportamento C: Contribuio, R: Representao S: Subordinao

Sesso1 Sesso 2

Nmeros de No

Nmeros de Sim

Nmeros de No

Nmeros de Sim

Voc sabe em qual fase do processo pode atuar? (R) 3 9 0 12

Voc sabe quais so os dados mais importantes a serem inseridos? (C)

2 10 0 12

Estando na fase de sua responsabilidade, sabe quem deve ser o responsvel pela prxima fase? (C)

4 8 0 12

Voc sabe de que outras fases depende a sua? (R) 5 7 0 12

Quando insiro um dado errado em uma fase de minha responsabilidade, sei das consequncias no processo deste erro para as fases posteriores? (R)

9 3 1 11

Distingue qual sua posio atual no processo? (R) 4 8 0 12

Distingue quem so os responsveis pelas atividades que esto sendo desenvolvidas? (R)

7 5 0 12

Confia que as informaes que chegam at voc pelo sistema so as mais atualizadas? (S)

5 7 5 7

Voc utiliza o sistema para trocar informaes com outros usurios, sem necessidade de outros meios?(S)

7 5 4 8

Voc toma decises por meio de informaes fornecidas pelo sistema? (S)

7 5 5 7

Voc sabe como acompanhar as metas do grupo? (R) 8 4 2 10

Voc sabe como as aes dos outros usurios esto relacionadas com as suas? (R)

9 3 1 11

Voc sabe como acompanhar o trabalho de outros membros do grupo? (R)

8 4 2 10

Voc sabe como recuperar as informaes que inseriu no sistema? (R)

8 4 2 10

Voc sabe como recuperar as informaes que outros membros do grupo inseriram no sistema? (R)

10 2 2 10

Questes a respeito do processo social So: Socializao, Co: Conversao Re:

Recapitulao

Existe um programa de treinamento para novos usurios? (So)

10 2 0 12

Os usurios trocam experincia regularmente sobre a utilizao do sistema? (Co)

5 7 2 10

Ocorrem encontros programados para a discusso do uso e dos resultados do sistema? (Re)

10 2 1 11

Porcentual do total de respostas: 56% 44% 13% 87%

Fonte: Elaborado pelo autor, baseado em Weik and Roberts (1993)

Houve um aumento da percepo dos usurios sobre o estabelecimento das aes

e dos processos sociais, de modo que em funo dos resultados qualitativos obtidos

258

nas duas sesses, ocorreu uma evoluo de 44% (ver Tabela VII.1) para 87% do

nmero de respostas positivas.

Esta evoluo do nmero de respostas positivas, fruto da introduo dos novos

artefatos de awareness, com o maior grau de conscincia dos usurios de como os

inter-relacionamentos de suas atividades eram realizados, foram confirmados por

meio de um decrscimo nos erros individuais dos usurios e suas respectivas

consequncias nos resultados do trabalho em grupo (ver item VII.3.3).

4. O processo proposto no ciclo 2 pode ser aplicado para refinar os requisitos

do trabalho cooperativo de um SI neste ciclo?

A questo foi citada no ciclo 2, conforme discutido na questo 3 desta seo, o

processo pode ser aplicado, mas deve levar em conta os conceitos de mente

coletiva, elementos de awareness e modelo 3C da engenharia de groupware. Alm

disso, com o sistema em uso, algumas adaptaes devem ser feitas ao processo

que foi aplicado no ciclo anterior:

Na primeira iterao, deve ser realizado o treinamento dos usurios (no lugar

da sesso) e na fase de anlise e planejamento desta iterao (com o

sistema em uso) deve ser realizada uma avaliao por meio de entrevistas

com os usurios representativos dos vrios perfis da aplicao sobre o uso do

sistema, utilizando-se os conceitos de awareness, modelo 3C e de mente

coletiva;

Durante os passos de implementao e apresentao (sesso) do ciclo 3, os

artefatos foram construdos, levando-se em conta os elementos de awareness

e a teoria da mente coletiva (com relao s aes) que foram apresentados

durante a respectiva sesso desta iterao para avaliao e validao dos

usurios;

O passo de implementao da iterao 3 (e outras iteraes que se fizerem

necessrias) foi realizado logo aps o passo de anlise e planejamento da

iterao 2 com o objetivo de construir os artefatos emergentes que surgiram

durante a sesso 2 e foram colocados em produo, logo aps sua

construo. Nesse passo, tambm, foram treinados os tutores responsveis

por manter os processos sociais nos laboratrios

259

VIII ANLISE FINAL

Neste captulo, as concluses finais deste trabalho so apresentadas, considerando

as questes de pesquisa, as premissas e as proposies formuladas, assim como

os resultados obtidos. A aplicabilidade, as contribuies e algumas questes para

futuros trabalhos so descritas com base no contedo desta pesquisa.

VIII.1 CONCLUSES

O objetivo principal deste trabalho apresentado no captulo I foi:

Contribuir, por meio de um processo para levantamento de requisitos de

software, para o entendimento de como as caractersticas do trabalho

cooperativo de um SI devem ser consideradas no desenvolvimento de um

software que d suporte a este SI.

Assim como seus objetivos especficos:

Estudar e propor, com base na literatura, conceitos, tcnicas e mtodos que

devem ser aplicados Engenharia de Requisitos, levando em conta o

trabalho cooperativo em sistemas de informao;

Planejar, estruturar e executar uma pesquisa-ao voltada para desenvolver,

aplicar, avaliar e aperfeioar o processo proposto.

Visando a atender ao objetivo principal da pesquisa, assim como a seus objetivos

especficos, este trabalho apresentou como propsito definir um processo de

requisitos de software orientado ao trabalho cooperativo de um SI. Ao longo da

aplicao deste processo, por intermdio da pesquisa-ao, foi possvel mostrar os

caminhos percorridos para analisar e melhorar o processo, focando o

acompanhamento da evoluo dos requisitos cooperativos pelas diversas fases de

construo do sistema informatizado.

Para discutir as concluses finais desta tese, convm retornar a questo principal,

inicialmente colocada no captulo I:

Como considerar, na especificao de requisitos de software, a dimenso

cooperativa do trabalho em sistemas de informao?

260

Durante a execuo dos ciclos 1, 2 e 3, as evidncias empricas relatadas levaram

s concluses parciais desta tese e que podem ser compiladas para responder

questo principal de pesquisa:

Os artefatos desenvolvidos durante o processo para identificao dos

requisitos individuais (ou tradicionais da ER clssica) do trabalho cooperativo

foram importantes para iniciar ao processo proposto,

A escolha e o uso dos artefatos, como o fluxograma do processo e sua

hierarquia de subatividades e respectivas interfaces grficas, com o diagrama

de contexto, utilizados como elementos comuns de comunicao contriburam

para a evoluo dos requisitos do trabalho cooperativo nos ciclos 2 e 3;

O uso da Anlise Coletiva do Trabalho para orientar as iteraes do grupo em

torno da atividade coletiva atual e a simulao da atividade futura realizada,

dos elementos comuns de comunicao, do conceito de modelo mental, dos

conceitos da ergonomia de concepo de anlise das situaes de referncia

e das aes caractersticas futuras provveis permitiram uma evoluo dos

artefatos desenvolvidos na prototipao realizada no ciclo 2 para coletar,

alm dos requisitos do trabalho individual dos usurios, os requisitos do

trabalho cooperativo;

Os requisitos emergentes surgiram em razo do fato de que o processo

empregado trouxe tona aspectos que no seriam facilmente acessveis sem

a interao do grupo e que o processo de compartilhar e comparar ofereceu

rara oportunidade de compreenso por parte do pesquisador de como os

participantes entendiam suas similaridades e diferenas;

A aplicao da dinmica das iteraes proposta neste trabalho, tambm,

contribuiu para melhor aproveitamento das sesses realizadas com os

usurios, de modo que a aplicao do processo mostrou que, nas sesses

realizadas, uma nova ideia gerada por algum dos participantes era

imediatamente testada, de forma que todo o grupo emitia opinio a respeito.

Com isso, ganhou-se tempo no projeto, atendendo s expectativas dos

usurios reais;

Por intermdio da aplicao do processo estabelecido para o ciclo 3, foi

possvel verificar que um sistema informatizado (com as caractersticas

261

descritas no item VII.2.3), projetado visando a atender aos requisitos do

trabalho cooperativo de um SI, deve considerar a mudana das iteraes

face a face dos usurios, para um contato intermediado por esse sistema

informatizado;

Para tratar esta questo, foram utilizados elementos de awareness, do

modelo 3C e da teoria da mente coletiva (ver item VII.2.2), durante o passo de

implementao da iterao 2 do ciclo 3;

Outro aspecto importante foi que em razo do fato do sistema informatizado

ter sua coordenao distribuda nas aes dos usurios (coordenao

horizontal), sendo dependente do maior ou menor grau da conscincia de

como estes inter-relacionamentos eram realizados, assim, os usurios

deveriam continuamente extrair um senso de mudana de suas prprias inter-

relaes e as recolocarem em ao no sistema de informao, tornado-se

importante manter os processos sociais de socializao, conversao e

recapitulao (ver item II.4.2). Para atender esta questo foi introduzida a

figura do tutor;

Foi proposta uma forma qualitativa para se avaliar a evoluo do trabalho

cooperativo realizado por intermdio do sistema informatizado durante o uso

do mesmo (ciclo 3), utilizando os conceitos da teoria da mente coletiva;

O aumento no grau de conscincia dos usurios de como os inter-

relacionamentos de suas atividades foram realizadas por meio da introduo

dos tutores e dos artefatos de awareness no ciclo 3, foi confirmado por um

decrscimo nos erros individuais dos usurios e de suas respectivas

consequncias nos resultados do trabalho em grupo.

Estas concluses parciais levaram s seguintes concluses gerais:

A anlise de requisitos tradicional produziu os artefatos de entrada do

processo proposto;

No ciclo 2, em razo da simulao do trabalho cooperativo por meio do

sistema informatizado, foram refinados os requisitos do trabalho individual e

levantados os requisitos mais transacionais do trabalho cooperativo, isto ,

262

mais ligados s aes e seus inter-relacionamentos dentro do SI. Os

requisitos de awareness foram pouco explorados;

Contrariamente ao ciclo 2, no ciclo 3 foram refinados com mais intensidade os

requisitos do trabalho cooperativo ligado ao awareness do sistema, isto , os

requisitos necessrios para compensar a falta de interao face a face dos

usurios pela introduo de uma perturbao neste ambiente: o sistema

informatizado;

Os resultados obtidos mostraram que o maior grau de conscincia dos

usurios de como os inter-relacionamentos de suas atividades eram

realizados, contribuiu para um decrscimo em seus erros individuais,

diminuindo o retrabalho de recodificao do software e, acima de tudo, o uso

inadequado do sistema, evitando a propagao das consequncias desses

erros nos resultados do trabalho em grupo.

Na figura abaixo (Figura VIII.1), as concluses acima descritas so apresentadas

graficamente para mostrar como os requisitos variaram durante a execuo dos

ciclos desta PA.

Ciclo 1 Ciclo 2 Ciclo 3

1. Requisitos

individuais

2. Requisitos do

inter-

relacionamento

3. Requisitos de

awereness

Execuo dos ciclos

Figura VIII.1 - Variao da intensidade dos tipos de requisitos nos ciclos da PA

VIII.2 PROPOSTA DE ALTERAO DO PROCESSO

O ciclo 3 mostra diferenas com relao ao ciclo 2, sobretudo porque durante a

simulao no levado em conta o ambiente mais restritivo para as iteraes entre

os usurios, proporcionado pelo sistema informatizado.

263

Assim, em funo dos resultados obtidos no ciclo 3, o processo para especificao

de requisitos de software (identificao e simulao das caractersticas do trabalho

cooperativo) pode sofrer algumas adaptaes no sentido de reduzir o nmero de

iteraes do ciclo 3, melhorar a qualidade das interaes com os usurios e diminuir

o tempo de projeto:

Na fase de implementao (ver item IV.5.1) do processo para a identificao e

simulao dos requisitos de software do trabalho cooperativo (ciclo 2, ver item

IV.5), os artefatos a serem construdos devem considerar tambm os

elementos de awareness, modelo 3C e da teoria da mente coletiva (com

relao s aes), ou seja, considerar tambm a fase de implementao do

processo de refinamento das caractersticas do trabalho cooperativo (ver item

IV.6.1). Esta alterao deve ser aplicada s iteraes do ciclo, quando os

usurios passarem a discutir nas sesses os requisitos ligados ao inter-

relacionamento das aes (Figura VIII.1);

Os tutores responsveis por manter os processos sociais podem ser treinados

no incio do ciclo 3, durante o treinamento dos usurios e no s na iterao

3 deste ciclo.

Aps a aplicao das mudanas sugeridas, espera-se que o ciclo 3 seja necessrio

apenas para acertos normais em razo do uso que no foi previsto no ciclo 2, mas,

sem a necessidade maior de se tratar os artefatos de awareness e dos inter-

relacionamentos das aes dos usurios (ver Figura VIII.2). Outra melhoria

esperada a diminuio do retrabalho de codificao de software com o sistema em

uso, uma vez que menos correes no ciclo 3 sero necessrias.

Ciclo 1 Ciclo 2 Ciclo 3

1. Requisitos

individuais

2. Requisitos do

inter-

relacionamento

3. Requisitos de

awereness

Execuo dos ciclos

Figura VIII.2 - Variao esperada da intensidade dos tipos de requisitos nos ciclos da PA, aps

a aplicao das mudanas sugeridas

264

VIII.3 CONTRIBUIES

A aplicao do processo proposto, por meio da pesquisa-ao apresentada durante

a parte prtica desta pesquisa, possibilitou a realizao das seguintes contribuies:

Desenvolvimento de um processo para levantamento de requisitos de

software com foco no trabalho cooperativo dos sistemas de informao

horizontais (coordenao distribuda nas aes dos usurios);

Proposta de um modelo de software hbrido entre o modelo incremental e a

prototipao descartvel clssica, com o aproveitamento dos artefatos

produzidos na prototipao no funcional, de modo que a fase de

implementao do processo s ocorra com os requisitos definidos,

contrariamente ao modelo incremental, facilitando a medio do progresso do

desenvolvimento e, consequentemente, do gerenciamento do projeto;

Utilizao, em Engenharia de Requisitos, de conhecimentos desenvolvidos

em outras reas, sobretudo pelo uso do mtodo de Anlise Coletiva do

Trabalho e da concepo informtica na simulao e prototipao de

sistemas, ambas da ergonomia, do conceito de modelo mental e da teoria da

mente coletiva;

Utilizao do modelo 3C e dos elementos de awareness da engenharia de

groupware para tratar de sistemas informatizados tradicionais, nos quais

estes conceitos, normalmente, no so considerados (ver itens VII.2.2 e

VII.2.3);

Proposta para avaliar a evoluo dos requisitos cooperativos implementados

em um software durante a prototipao funcional;

Proposta para melhorar os processos sociais por meio do treinamento e

utilizao dos tutores;

Aplicao do processo proposto, utilizando o mtodo de pesquisa-ao, o que

contribuiu para o aperfeioamento deste processo.

Estas contribuies permitem considerar, de modo explcito, as caractersticas do

trabalho cooperativo no desenvolvimento de sistemas informatizados que no so

considerados groupware.

265

VIII.4 PROPOSTAS PARA FUTUROS TRABALHOS

Ao longo do desenvolvimento deste estudo, outras oportunidades de pesquisas

complementares foram identificadas, mas no fizeram parte de seu escopo:

Realizao da pesquisa cientfica voltada experimentao do processo

descrito neste trabalho em outras organizaes com necessidade de sistemas

de informao que satisfaam as condies de aplicabilidade descritas nos

itens IV.3.2 e VII.2.3, o que permitir um reforo das concluses deste

trabalho, alm de avaliar a replicabilidade do mesmo;

Aplicao das mudanas propostas no item VIII.2 ao processo e realizao de

pesquisa nos mesmos moldes do item anterior, no sentido de verificar as

melhorias esperadas neste processo;

Realizao de pesquisa voltada para verificao da eficincia do processo

proposto, j que neste estudo a maior preocupao foi com sua eficcia;

Realizao de novos trabalhos de campo anlogos, utilizando outras tcnicas

de descoberta de requisitos, como por exemplo, a etnografia, alm das

tcnicas empregadas nesta pesquisa;

Aperfeioamento do mtodo proposto neste trabalho (ver itens IV.6.2, VII.3.2

e VII.3.3) para avaliao da evoluo do levantamento dos requisitos do

trabalho cooperativo ao longo do processo de desenvolvimento de um

sistema informatizado.

VIII.5 CONSIDERAES FINAIS

Esta pesquisa possui limitaes referentes aplicao e generalizao de seus

resultados. No caso da prototipao evolutiva (ver item II.8.3), este processo deve

ser aplicado a sistemas informatizados com as seguintes caractersticas:

O sistema deve ser um problema estruturado com uma grande quantidade de

elementos de dados e relacionamento entre registros mas, uma pequena

quantia de processos algortmicos (BOAR, 1984);

266

Os usurios devem estar dispostos e capazes a participar ativamente, assim

como o gerente do projeto (BOAR, 1984);

O preparo da equipe envolvida com o uso da metodologia no pode significar

risco, assim como a questo da falta esprito da equipe do grupo que estiver

participando das sesses (BOAR, 1984);

O sistema possui muita interao com os usurios por meio de transaes

com relatrios associados aos bancos de dados, no operando com muito

processamento em lote (batch) (BOAR, 1984);

O Sistema de Informao apresenta coordenao distribuda nas aes dos

usurios (coordenao horizontal) e a comunicao entre eles ocorre

preponderantemente de modo indireto pelos dados inseridos nos objetos de

colaborao durante o uso do software. O software que implementa o SI

assncrono e desacoplado (ver itens II.5.5 e VII.2.3).

Outro aspecto a ser considerado corresponde ao fato que a PA que deu suporte a

este trabalho foi realizada em uma situao onde foi priorizada a eficcia do

processo proposto, sendo executada em condies onde o fator tempo, embora

influente, no foi fundamental para a sua realizao. Assim, foi possvel realizar um

nmero timo de iteraes em cada processo do macro-processo proposto (ver item

IV.2).

Em condies mais restritivas de tempo, menos iteraes devero ser realizadas em

cada um dos processos propostos, em particular nos processos de simulao e

refinamento do trabalho cooperativo (ver itens IV.5 e IV.6 respectivamente). Visando

a futura generalizao do processo proposto, esta situao poder ser compensada

com uma dinmica de iteraes (ver itens VI.2 e VII.2) mais adequada para uma

determinada situao de projeto, alm da introduo das mudanas propostas no

item VIII.2.

Com relao Anlise Coletiva do Trabalho, a participao dos usurios nas

sesses foi facilitada por ser uma aplicao interna empresa. Visando tambm a

futura generalizao, no caso de uma aplicao onde os usurios estejam

geograficamente dispersos, uma alternativa poderia ser a participao de usurios

com perfis anlogos para as sesses, ou mesmo a realizao de sesses virtuais.

267

A partir das observaes acima descritas visando a generalizao do processo,

alm da realizao dos futuros trabalhos propostos (item VIII.4), espera-se que os

resultados obtidos refinem e melhorem o processo apresentado nesta pesquisa,

confirmando tambm a eficincia do mesmo, permitindo sua generalizao e

agregao Engenharia de Requisitos tradicional e tornando explcita a influncia

do trabalho cooperativo na especificao de software que no seja considerado

puramente groupware.

268

IX REFERNCIAS

ASSIS, R. L. Facilitando a percepo em ambientes virtuais de aprendizado atravs da tecnologia groupware. 2000. 148p. Dissertao (Mestrado) - Departamento de Informtica, Pontifcia Universidade Catlica, Rio de Janeiro, 2000.

BAL, J. Process Analysis tools for process improvement. The TQM Magazine, v. 10, n. 5, p. 342 354, 1998.

BARTHE, B. Elaboration, mise en oeuvre et apport classificatoire dun cadre danalyse des aspects collectifs du travail. In: XXXVIIIme Congrs de la SELF. Paris, p. 181-188, 2003.

BASTIEN, C.; SCAPIN, D. A concepo de programas de computador interativos centrada no usurio: etapas e mtodos. In: FALZON, P. (Ed.). Ergonomia. So Paulo: Edgard Blcher, 2007.

BOAR, B. H. Application prototyping. 1. ed. New York: John Wiley & Sons, 1984. 210 p.

BECK, K. Extreme Programming Explained: Embrace Change. Addison Wesley, 2004. 181 p.

BRINCK, T.; McDANIEL, S. E. Awareness in Collaborative Systems. Conference on Human Factors in Computing Systems, SIGCHI Bulletin, v. 29, n. 4, 1997.

BOEHM, B.W. A Spiral Model of Software Development and Enhancement. IEEE Computer, v. 21, n. 5, p. 61-72, 1988.

BOOCH, G. Object-Oriented Analysis and Design with Applications. 2. ed. California: Benjamin/Cummings Pub. Co., 1994. 578 p.

BRYMAN, A. Research methods and organization studies. London: Unwin Hyman Ltd, 1989. 300p.

BURKHARDT, J. M.; SPERANDIO, J. C. Ergonomia e concepo informtica. In: FALZON, P. (Ed.). Ergonomia. So Paulo: Edgard Blcher, 2007.

269

CARROL, J. M.; OLSON, J. R. Mental models in human-computer interaction, In: HELANDER, M.; LANDAUER, K. T.; PRABHU, V. P. (Ed.). Handbook of Human-Computer Interaction. 2. ed. Amsterdam: Elsevier Science Pub Co, 1988.

CHEN, P. A abordagem entidade-relacionamento para projeto lgico. So Paulo: Makron Books do Brasil, 1990. 80 p.

CHEESMAN, J.; DANIELS, J. UML Components: A Simple Process for Specifying Component-Based Software. EUA: Addison-Wesley, 2001. 208 p.

COUGHLAN, P.; COGHLAN, D. Action research for operational management. Internacional journal of operation & Production management, v. 22, n. 2, p. 220-240, 2002.

CROWSTON, K.; KAMMERER, E.E. Coordination and Collective Mind in Software Requirements Development. IBM Systems Journal, v. 37, n. 2, 1998.

CRUZ, T. Workflow II: A tecnologia que revolucionou processo. Rio de Janeiro: E-paper, 2004. 212 p.

DANIELLOU, F. A ergonomia em busca de seus princpios: debates epistemolgicos. 1. ed. So Paulo: Edgard Blcher, 2004. 244 p.

DANIELLOU, F. A ergonomia na conduo de projetos de concepo de sistemas de trabalho. In: FALZON, P. (Ed.). Ergonomia. So Paulo: Edgard Blcher, 2007.

DANIELLOU, F.; SIX, F. Les ergonomes, les prescripteurs et les prescritions. In: MARTIN, C.; BARADAT, D. (Ed.). Des pratiques en rflexion - Dix ans de dbats sur l'intervention ergonomique. Toulouse: Octars Editions, 2003.

DAVENPORT, T. H. Process innovation: reengineering work through information technology. Boston: Harvard Business School Press, 1993.

DEJOURS, C. O fator humano. 5. ed. Rio de Janeiro: Editora Fundao Getulio Vargas, 2005. 102 p.

DEMARCO, T. Anlise estruturada e especificao de sistemas. Rio de Janeiro: Editora Campus, 1989. 352 p.

270

DE TERSSAC, G.; MAGGI, B. O trabalho e a abordagem ergonmica. In: DANIELLOU, F. (Ed.), A Ergonomia em busca de seus princpios: debates epistemolgicos. So Paulo: Edgard Blcher, 2004.

DOURISH, P.; BELLOTI, V. Awareness and Coordination in Shared Workspaces. In: Proceedings of the ACM conference on Computer-supported cooperative work, Canad, 1992.

ERCEAU, J.; CHAUDRON, L.; FERBER, J.; BOURON, T. Systmes personne(s): patrimoines cognitifs et mondes multi-agents, coopration et prises de dcision collectives. In: Systmes coopratifs: de la modlisation la conception. Toulouse: Octars Editions, 1994.

ELLIS, C. A.; GIBBS, S. J.; REIN, G. L. Groupware - Some Issues and Experiences. Communications of the ACM, v. 34, n 1, p. 38-58, 1991.

ELLIS, C. A. An Evaluation Framework for Collaborative Systems. Colorado University: Technical Report CU-CS-901-00, February, 2000.

ESTORILIO, C. C. A. O trabalho dos engenheiros em situaes de projeto de produto: uma anlise de processo baseada na ergonomia. 2003. 301 p. Tese (Doutorado) - Departamento de Produo da Escola Politcnica, Universidade de So Paulo, So Paulo, 2003.

FALZON, P. Natureza, objetivos e conhecimentos da ergonomia. In: FALZON, P. (Ed.). Ergonomia. So Paulo: Edgard Blcher, 2007.

FERREIRA, L. L. Anlise coletiva do trabalho. Revista brasileira de sade ocupacional. So Paulo, v.21, n.78, p.7-19, abril/maio/junho. 1993.

FERREIRA, L. L. Anlise coletiva do trabalho: com a palavra, os trabalhadores.In: DUARTE, F.; FEITOSA (Org.). Linguagem & Trabalho. Rio de Janeiro: COPPE/UFRJ/Lucerna, 1998. p.82-92.

FERREIRA, L. L. Diferenas e semelhanas entre a anlise ergonmica do trabalho e a anlise coletiva do trabalho. In: IX Congresso Brasileiro de Ergonomia - ABERGO, 1999, Salvador, BA. Anais da Associao Brasileira de Ergonomia, ABERGO: Salvador, 1999.

271

FUKS, H.; ASSIS, R. L. Facilitating Perception on Virtual Learningware based Environments. The Journal of Systems and Information Technology, v.5, n.1, 2001.

FUKS, H.; RAPOSO, A. B.; GEROSA, M. A.; PIMENTEL, M.; FILIPPO, D.;LUCENA, C. J. P. Inter- e Intra-relaes entre Comunicao, Coordenao e Cooperao. Anais do IV Simpsio Brasileiro de Sistemas Colaborativos SBC: Rio de Janeiro - RJ, 2007.

FUKS, H.; RAPOSO, A. B.; GEROSA, M.A. & LUCENA, C. J. P. Applying the 3C Model to Groupware Development. International Journal of Cooperative Information Systems (IJCIS), v.14, n.2-3, Jun-Sep 2005.

GAVA, L. V.; ALMEIDA, P. A.; SPINOLA, M. Proposta de processo de especificao de software a partir de tcnicas baseadas em suas funcionalidades sob a ptica de seus usurios finais. In: XXIV ENEGEP - Encontro Nacional de Engenharia de Produo, 2004, Florianpolis. Anais do XXIV ENEGEP, 2004.

GAVA, L. V.; GONALVES, R. F.; SPINOLA, M. The use of Ergonomics techniques

and JAD for the collective work definition in information Systems. In: 4 CONTECSI- Congresso Internacional de Gesto de Tecnologia e Sistemas de Informao, 2007, So Paulo. Anais do 4 CONTECSI, So Paulo : FEA/USP, 2007. v. CD-ROM.

GAVA, L. V.; GONALVES, R. F.; SPINOLA, M. Cooperative Work Definition in Information Systems Development. In: SZNELWAR, L. I.; MASCIA, F. L.; MONTEDO, U. B. (Ed.). In: Human Factors in Organizational Design and Management IX. So Paulo: Edgard Blcher, 2008.

GEROSA, M. A. Desenvolvimento de Groupware Componentizado com Base no Modelo 3C de Colaborao. 2006. 275 p. Tese (Doutorado) - Departamento de Informtica, Pontifcia Universidade Catlica, Rio de Janeiro, 2006.

GEROSA, M. A.; FUKS, H.; LUCENA, C. J. P. Elementos de percepo como forma de facilitar a colaborao em cursos via Internet. XII Simpsio Brasileiro de Informtica na Educao SBIE 2001, Vitria, Esprito Santo. 2001.

GEROSA, M. A.; FUKS, H.; LUCENA, C. J. P. Suporte Percepo em Ambientes de Aprendizagem Colaborativa. Revista Brasileira de Informtica na Educao, v. 11, n. 2, Nov. 2003.

272

GONALVES, R. F.; GAVA, V. L.; PESSA, M. S. P.; SPINOLA, M. M. Uma proposta de processo de produo de aplicaes Web. Revista Produo, v. 15, n. 3, Set./Dez. 2005.

GONALVES, R. F.; GAVA, L. V.; FERREIRA, R. C.; PESSA, M. S. P. Ergonomic challenges in system information implantation for building design support: a Brazilian experience. In: SZNELWAR, L. I.; MASCIA, F. L.; MONTEDO, U. B. (Ed.). In: Human Factors in Organizational Design and Management IX. So Paulo: Edgard Blcher, 2008.

GOGUEN, J.; C. LINDE. Software Requirements Analysis and Specification in Europe: An Overview. First International Symposium on Requirements Engineering, IEEE Computer Society Press, p. 152-164, 1993.

GORDEN, V.S.; BIEMAN, J. M. Rapid prototyping: lessons learned. Software, IEEE. v. 12, n. 1, p. 8595. 1995.

GROSS, T.; TRAUNMULLER, R. Methodological Considerations on the Design of Computer Supported Cooperative Work. Cybernetics and Systems: An International Journal, v. 27, n. 3, p. 279-303, 1996.

GURIN, F.; LAVILLE A.; DANIELLOU, F.; DURAFFOURG J.; KERGUELEN A. Compreender o trabalho para transform-lo: a prtica da ergonomia. So Paulo: Edgard Blcher, 2001.

GUMMESSON, E. Qualitative Methods in Management Research. 2. ed. Thousand Oaks: Sage Publications, 2000.

HANNA, M. Farewell to Waterfalls. Software Magazine, p. 38-46, Maio. 1995.

HARRINGTON, J. Aperfeioando Processos Empresariais. So Paulo: Makron Books, 1993.

HIX, D,; HARTSON, H. R. Developing user interfaces: ensuring usability through product and process. New York: John Wiley & Sons, 1993.

IDEF. Integrated Definition Methods. Disponvel em: < http://www.idef.com/>. Acesso em: 02 ago 2008.

JACKSON, M. Software Requirements and Specifications: A Lexicon of Practice, Principles and Prejudices. USA: Addison-Wesley, 1995. 228 p.

273

JACOBSON, I.; CHRISTERSON, M; JONSSON, P.; GUNNAR, O. Object-Oriented Software Engineering: A Use Case Driven Approach. USA: Addison-Wesley, 1992.

KOCH, M.; GROSS, T. Computer-Supported Cooperative Work Concepts and Trends. Proc. 11th Conf. of the Association Information and Management (AIM), Luxembourg, 2006.

KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering (Processes and Techniques). 1. ed. England: John Wiley & Sons Ltd, 1998.

KRUCHTEN, P.; KROLL, P. The Rational Unified Process and Introduction. USA: Addison-Wesley, 2003.

LEFFINGWELL, D.; WIDRIG, D. Managing Software Requirements. A Use Case Approach. 2. Ed. Boston: Addison-Wesley, 2003.

LEITE, J. C. S. P. Como Registrar Requisitos de Software, livro da Qualidade 2002. Disponvel em < http://www-di.inf.puc-rio.br/~julio/Livro-qualidade-2002.pdf >. Acesso em: 02 fev 2007.

MAGGI, B. Do agir organizacional - um ponto de vista sobre o trabalho, o bem-estar, a aprendizagem. So Paulo: Edgard Blcher, 2005.

MARTIN, D.; SOMMERVILLE, I. Patterns of Cooperative Interaction: Linking Ethnomethodology and Design. ACM Transactions on Computer-Human Interaction, p. 5989. 2004.

MARCONI, M. A.; LAKATOS, E. V. Metodologia cientfica. 3. ed. So Paulo: Atlas, 2000.

MILLS, H.D., ONEILL, D. et al. The management of software engineering. IBM Systems Journal, v. 24, n. 2, p. 414477. 1980.

MIGUEL, P.A.C. Estruturao do desenvolvimento de produtos e implantao de um mtodo de suporte: interveno atravs da pesquisa-ao. 2005. 138 p. Tese (Livre Docncia) - Departamento de Produo da Escola Politcnica, Universidade de So Paulo, So Paulo, 2005.

MORGAN, D. L. Focus groups as qualitative research. London: Sage University Paper, 1997. v. 16.

274

MORIN, E. Cincia com conscincia. 6. ed. Rio de Janeiro: Bertrand Brasil, 2002.

NAKANO, D. N.; Fleury, A. C. C. Mtodos de Pesquisa na Engenharia de Produo. IN: XVI ENEGEP - Encontro Nacional de Engenharia de Produo, 1996, Piracicaba. Anais do XVI ENEGEP, 1996.

NORMAN, D. A. Cognitive engineering. In: NORMAN, D. A.; DRAPER, S. W (Ed.). User centered systems design new perspectives on Human-Computer Interaction. New Jersey: Laurence Erlbaum, 1986.

NORMAN, D. A. O design do dia-a-dia. Rio de Janeiro: Editora Rocco, 2002.

NUSEIBEH, B.; FINKELSTEIN A.; KRAMER, J. ViewPoints: meaningful relationships are difficult. International Conference on Software Engineering, Portland, Oregon, 2003.

PAULK, M. C.; WEBER, C. V.; CURTIS, B. The Capability Maturity Model: Guidelines for Improving the Software Process. USA: SEI, Addison-Wesley Longman Inc., 1994. 456 p.

Programa informatizado de gerenciamento laboratorial: PesqTec. [S.I.:s.n.]. 2005.

PIAGET, J. A construo do real na criana. So Paulo: tica, 1996.

PINHEIRO, M. K.; LIMA, J. V.; BORGWE, M. R. S. Awareness em Sistemas de Groupware. In: IV Jornadas Iberoamericano de Ingeniera de Requisitos y Ambientes de Software, 2001, Santo Domingo, Costa Rica. Proceedings of IV Jornadas Iberoamericano de Ingeniera de Requisitos y Ambientes de Software (IDEAS 2001), 2001.

PFLEEGER, S. L.; ATLEE, J.M. Software Engineering - Theory and Practice. USA: Prentice Hall, 2006.

PRESSMAN, R.S. Software Engineering: A Practitioners Approach. 6. ed. New York: McGraw-Hill, 2005. 880 p.

RETTIG, M. Prototyping for tiny fingers. Communications of the ACM, Vol. 37, No. 4, p. 2127. 1994.

275

ROYCE, W.W. Managing the development of large software systems: concepts and techniques. Proceedings of the 9th international conference on Software Engineering, Monterey, California, p. 328 338, 1987.

RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W. Object-Oriented Modelling and Design. USA: Prentice-Hall, 1991.

RYAN, K. Requirements Engineering - getting value for money. In: XII Simpsio Brasileiro de Engenharia de Software (SBES), 1998, Maring. Anais do XII SBES, 1999.

SCAPIN, D.L. Guide ergonomique de conception des interfaces Homme-Machine. Inria-00070083, v. 1, 1986. Disponvel em < http://hal.inria.fr/view_by_stamp.php?label=INRIA-RRRT&langue=fr&action_todo=view&id=inria-00070083&version=1>. Acesso em 10 dez. 2008.

SILVA, L. A. Qualidade em sistemas automatizados de informao: a ergonomia na criao da dimenso usabilidade. 1997. 239 p. Dissertao (Mestrado) - Departamento de Produo da Escola Politcnica, Universidade de So Paulo, So Paulo, 1997.

SABETZADEH, M.; FINKELSTEIN, A.; GOEDICKE, M. Viewpoints. In: LAPLANTE, P. (Ed.). In: Encyclopedia of Software Engineering. New York: Taylor and Francis, 2010.

SALERNO, M. S. Projeto de organizaes integradas e flexveis: processos, grupos e gesto democrtica via espaos de comunicao-negociao. So Paulo: Atlas, 1999.

SNYDER, C. Paper Prototyping. San Francisco: Elsevier Science, 2003. 378 p.

SOMMERVILLE, I. Software Engineering. 8. ed. Edinburgh: Pearson Education Limited, 2007.

SOMMERVILLE, I.; SAWYER, P.; VILLER, S. Viewpoint for Requirements Elicitation: a practical approach. ICRE98 Third International Conference on Requirements Engineering, ed. 1. USA : IEEE CSP, Los Alamitos, CA. Proceedings, p 74-81, 1998.

276

SOUZA, G. M.; CASTRO, J. F. B. Improving the Separation of Non-Functional Concerns in Requirements Artifacts. 12th IEEE International Requirements Engineering Conference, Japan, 2004.

TAVARES, J. C. Anlise do trabalho em grupos semi-autnomos por uma terceira via: investigao da cooperao com vistas na autonomia. 2002. 190 p. Tese (Doutorado) - Departamento de Produo da Escola Politcnica, Universidade de So Paulo, So Paulo, 2002.

THIOLLENT, M. Metodologia da pesquisa-ao. 13. ed. So Paulo: Cortez, 2004.

TRINDADE, A. L. P. Uma contribuio para o entendimento do papel da ensinagem na preservao do conhecimento em ambientes de Fbrica de Software. 2006. 295 p. Tese (Doutorado) - Departamento de Produo da Escola Politcnica, Universidade de So Paulo, So Paulo, 2006.

TUROFF, M.; HILTZZ, S. R. Computer Support for Group versus Individual Decisions. IEEE Transactions on Communications, v. 30, n. 1, p. 82-91, 1982.

UML. Unified Modelling Language. Disponvel em: . Acesso em: 14 ago. 2008.

VILLER, M.; SOMMERVILLE, I. Ethnographically informed analysis for software engineers. International Journal of Human-Computer Studies, v. 53, p. 169196. 2000.

YIN, R. K. Estudo de Caso - Planejamento e Mtodos. Porto Alegre: Bookman, 2003.

YOURDON, E. Analise estruturada moderna. Rio de Janeiro: Ed Campus, 1992.

WARD, P. T.; MELLOR, S. J. Structured development for real-time systems. New York; London: Yourdon, 1985.

WEICK, K. E.; ROBERTS K.H. Collective Mind in Organizations: Heedful Interrelating on Flight Decks. Administrative Science Quarterly, v. 38, 1993.

WfMC. Workflow Management Coalition. Disponvel em: . Acesso em: 15 de ago 2008.

277

WITTORSKI, R. Analyse du travail et production de comptences collectives. Paris : L'Harmattan, 1997.

278

APNDICE A: PROCESSOS, MODELAGEM E WORKFLOW

Este apndice trata de modo resumido sobre o que um workflow, processo de

negcio e modelagem de processos, mostrando o relacionamento entre estes

conceitos dentro de uma organizao.

1. Processos de negcio

Segundo a WfMC (Workflow Management Coalition), um processo um conjunto

coordenado de atividades (sequenciais ou paralelas) que so interligadas com o

objetivo de alcanar um meta comum, sendo a atividade conceituada como uma

descrio de um fragmento de trabalho que contribui para o cumprimento de um

processo (WfMC, 2008).

A Figura 1 do apndice A mostra, de forma esquemtica, um processo e sua diviso

em fases e todos os elementos que o compem com a finalidade de melhorar o

entendimento e o controle sobre o projeto de anlise e modelagem de processos de

negcio (CRUZ, 2004).

PROCESSO

SUBPROCESSO 2SUBPROCESSO 1 SUBPROCESSO 3

ATIVIDADE 1 ATIVIDADE 2

A B

1 2 1

Ocorrncias

Clientes internos

Papis funcionais

Procedimentos

Tarefas

Metas

Indicadores de desempenho

Regras de negcio

Excees

Anomalias

Tempos

Rotas

PROCEDIMENTOS

PASSOS OU SUB-ATIVIDADES

Figura 1 do apndice A - Processo, divises e elementos Fonte: baseado em CRUZ (2004)

279

Subprocesso

um conjunto de atividades correlacionadas que executa uma parte especfica do

processo, do qual recebe insumos e para o qual envia o produto do trabalho

realizado por todas as atividades que o compem.

Atividade

o conjunto de procedimentos que deve ser executado com o objetivo de produzir

um determinado resultado.

As atividades podem ser classificadas em:

Primrias: so as que tm participao direta na criao do bem ou servio,

que objeto do processo;

Secundrias: so aquelas que no esto diretamente envolvidas com a

produo do bem ou servio que a organizao responsvel. Este tipo de

atividade existe para permitir que as atividades principais sejam executadas;

Transversais: o conjunto de vrias especialidades, executadas em uma

nica operao com a finalidade de resolver problemas. As atividades

transversais compem processos de negcios transversais.

Procedimento

Trata-se do conjunto de informaes para indicar ao responsvel por uma atividade

como, quando e com quem um evento deve ser executado. Toda atividade contm,

pelo menos, um evento. Evento um acontecimento e por meio de sua realizao

torna-se possvel que cada atividade produza sua parte do produto, dentro do

processo.

Para a tecnologia workflow (ver item 3 deste apndice), o que de fato importante

o controle dos eventos, de modo que durante a definio de um processo a ser

implementado por um workflow, o mesmo realizado passo a passo, definindo-se

cada evento.

280

Assim, alguns aspectos so importantes na definio de um procedimento: o que d

incio atividade, de que forma ela deve ser executada e com quais ferramentas

devem ser executadas.

Para executar um evento, h o procedimento que, por sua vez, dividido em

passos.

Passo

a menor parte realizvel de um procedimento para reduzir um evento em

atividade. O passo a decomposio de um procedimento, e o conjunto de passos

ou subatividades compe os procedimentos inerentes a cada um dos eventos

existentes em cada atividade.

Esta decomposio, alm de permitir a execuo do evento, tambm ajuda a

racionalizar a atividade.

2. Modelagem de Processos de Negcios

Trata-se de uma atividade corporativa que produz modelos de recursos, de fluxos de

informao e das operaes dos negcios que ocorrem na empresa.

Um dos principais objetivos buscados na construo da especificao de uma

organizao melhor entend-la, procurando identificar problemas e buscar

solues que melhorem o desempenho organizacional, tal como aumentar a

velocidade das atividades, reduzir custos e melhorar a qualidade dos servios.

Os mtodos de modelagem a serem utilizados para representar os processos

organizacionais precisam relacionar a estrutura das informaes e dos processos

com os negcios e objetivos organizacionais.

Harrington (1993) define fluxograma, diagramao lgica ou fluxo como um mtodo

para descrever graficamente um processo existente ou um novo processo proposto,

usando smbolos simples, linhas e palavras, de forma a apresentar graficamente as

atividades e a seqncia no processo. Segundo o autor, bons fluxogramas destacam

as reas onde procedimentos confusos afetam a qualidade e a produtividade, alm

de facilitar as comunicaes entre as reas problemticas, em funo da capacidade

de esclarecer processos complexos.

281

Durante o mapeamento do processo, observa-se aumento da compreenso do

problema, e as respostas s perguntas tornam-se mais aparentes, o que possibilita a

correta modelagem desses processos.

Um processo pode ser modelado sob vrias perspectivas:

Viso funcional: representa as atividades a serem executadas;

Viso comportamental: relaciona como e quando as atividades so

conduzidos;

Viso organizacional: representa quem est conduzindo as atividades;

Viso informacional: preocupa-se com os detalhes relativos s informaes

tratadas na realizao das atividades, considerando-se tanto as informaes

criadas e trocadas como suas relaes de dependncia.

Um dos mtodos de representao bem conhecidos e empregados ao IDEF

(Integrated Definition for Function Modelling), considerando-se a simplicidade e

contribuio para fornecer os vrios tipos de prospectivas. Este mtodo foi

desenvolvido na dcada de 80 pela Fora Area Americana, concebido inicialmente

para suportar trs tipos de representaes, posteriormente foi implementado com

mais um tipo (IDEF, 2008):

IDEF0: modela o aspecto funcional do processo;

IDEF1: modela a cadeia de informaes circulantes;

IDEF2: modela dinmica do processo;

IDEF3: criado para implementar o IDEF0, sendo utilizado para modelar o fluxo

de desenvolvimento das atividades e pode ser considerado logicamente

equivalente a um fluxograma.

O IDEF0 baseia-se em um diagrama conhecido como ativigrama, composto por

caixas que representam as atividades (Figura 2 do apndice A). Estas caixas so

ligadas por linhas e dispostas de forma que a ordem de conduo das atividades

seja explicitada, da esquerda para a direita. As linhas da esquerda indicam as

entradas para a execuo da atividade ou fase, e as setas que saem pela direita das

caixas, as sadas. As setas que entram por cima das caixas, mostram as restries

para execuo das atividades e as setas que entram por baixo, representam os

mecanismos/recursos.

282

Figura 2 do apndice A - Ativigrama do IDEF0

Fonte: IDEF (2008)

Esta representao adequada para a representao esttica de processos. Por

meio do IDEF0 o fluxo de informaes existentes entre funes mapeado,

possibilitando uma viso gradativamente detalhada do processo. Este detalhamento

feito para cada funo ou atividade, por intermdio da estrutura hierrquica das

funes.

O IDEF0 desconsidera os inmeros caminhos e as variveis existentes nos

processos, no dando clareza a respeito do comportamento dinmico do sistema,

nem apresentando a dinmica dos fluxos, somente mostrando as dependncias

entre as atividades. Segundo Bal (1998), o fluxograma e o IDEF3 suportam, alm do

aspecto funcional, a viso informacional, mostrando as relaes de dependncia

entre as atividades.

Estes mtodos, tambm, podem ser adaptados para representar o aspecto

comportamental e organizacional do processo, de modo que as quatro vises do

processo podem ser atendidas (atividades executadas, como e quando so

conduzidas, quem as conduz e quais so as informaes tratadas durante a

realizao das atividades, incluindo suas relaes de dependncia).

283

3. Workflow

Workflow definido pela WfMC como a automao total ou parcial de um processo

de negcio, durante a qual documentos, informaes e atividades so passadas

entre os participantes do processo, conforme as regras definidas (WfMC, 2008).

No modelo workflow, focado o processo, pois este o meio pelo qual a informao

ser processada e dentro do qual, logicamente, ir viajar. Em workflow, as regras

associados aos subprocessos orientam a execuo de cada atividade, permitindo

um nvel de detalhamento que difcil encontrar em outros modelos, tornando o

processo ativo, isto , cada usurio ser solicitado a executar sua atividade, ao invs

de permitir que cada um faa o que deve ser feito apenas na hora que lhe for mais

conveniente.

Os tipos de workflow podem ser caracterizados de trs formas distintas, de modo

que a combinao entre este tipos de workflow e modelos de processos fazem com

que a implantao desta tecnologia seja flexvel e praticamente abranja a maior

parte das necessidades de automao dos fluxos de trabalho. (CRUZ, 2004):

Ad Hoc

Este tipo de workflow descreve processos simples em que difcil encontrar um

esquema para a coordenao e cooperao de atividades, nem h um padro fixo

para o fluxo de informaes entre as pessoas envolvidas.

Este tipo de workflow criado dinamicamente por um grupo de trabalho, cujos

participantes necessitem executar procedimentos individualizados para cada

documento processado dentro do processo de negcio. Geralmente, utiliza-se do e-

mail como plataforma.

Alguns exemplos: processos de escritrio, documentao de produtos e propostas

de vendas.

Transao/Produo

Um workflow de produo predefinido e priorizado, suportando assim um grande

volume no existem negociaes sobre quem far o trabalho ou como ele ser

tratado. Ele pode ser completamente predefinido ou seguir um procedimento geral,

284

com alguns passos adicionais includos quando forem necessrios (embora alguns

autores no concordem com a idia).

Os dados tratados por este tipo de workflow tm duas origens, sendo uma delas fora

do fluxo. Estes dados do incio ao fluxo, como por exemplo, a solicitao de um

pedido de um cliente. A origem interna est ligada ao banco de dados que suporta

as aplicaes ligadas ao sistema, por exemplo, uma consulta sobre a situao do

andamento do atendimento a um determinado cliente.

Alguns exemplos: processamento de requisio de seguros, processamento de

faturas bancrias e de carto de crdito e acompanhamento de realizaes de

servios aos clientes.

Administrativo

Este terceiro tipo um meio-termo entre um workflow Ad hoc e um de transao.

Envolve atividades fracamente estruturadas, repetitivas, previsveis e com regras

no muito complexas de coordenao de atividades.

Exemplos: processamento de ordens de compras, procedimentos de aprovao de

despesas e autorizao de frias e viagens.

285

APNDICE B: ERGONOMIA DAS INTERFACES (USABILIDADE)

Scapin (1986) descreveu um conjunto de critrios para analisar/projetar a relao

homem-sistema, consistentes com os estilos de interao. Este modelo pode ser

considerado como um guia aos projetistas para orientar a construo de formas

mais naturais e intuitivas de interao homem-computador, por meio da melhor

adequao s necessidades dos usurios, melhorias da eficcia de utilizao e de

aprendizado.

importante lembrar que a aplicao destes critrios subjetiva e necessita de

validao frente aos usurios. Abaixo esto listados, de modo resumido, estes

critrios:

Orientao

So os meios disponveis para recomendar, orientar, instruir e guiar o usurio por

intermdio da interao, permitindo a qualquer tempo saber onde se est em uma

sequncia de aes, quais aes possveis, suas consequncias, inclusive, com a

obteno de informaes adicionais, sendo subdividos em:

Prompting (ao que sugere ou indica ao usurio uma ao): meios

empregados para levar o usurio a aes especficas e ajud-lo a conhecer

alternativas existentes e informaes sobre o estado do sistema, ajudas e

como obt-las;

Agrupamento/distino: refere-se organizao visual dos elementos de

informao do dilogo, considerando as informaes de localizao, formato,

cor e outras caractersticas que podem indicar a relao entre diversos

elementos;

Feedback imediato: fornecer um resultado observvel, rpido e claro a toda

ao do usurio ou do sistema. Esta caracterstica estabelece a confiana e a

satisfao do usurio, reduzindo a possibilidade de distrao (evita que o

usurio tome alguma ao que venha a prejudicar o processo em execuo);

Legibilidade: facilitar a leitura das informaes, levando-se em conta as

caractersticas perceptivas dos usurios. Refere-se s caractersticas lexicais

286

de reapresentao das informaes (dimenso das letras, espaamento entre

assuntos, espaamento entre linhas, espaamento entre pargrafos, etc.).

Carga de trabalho

Este critrio relativo a todos os elementos de interface que afetam a carga

perceptiva ou cognitiva do usurio e a melhoria da efetividade do dilogo,

subdividido em:

Brevidade: garantir que as unidades elementares registradas ou memorizadas

(derivadas da quantidade de aes, leituras exigidas, digitao de dados e do

nmero de passos para se atingir um determinado objetivo) sejam as mais

reduzidas possveis, dividindo-as em:

o Conciso: assegurar que as entradas e sadas sejam as mais curtas

possveis.

o Aes mnimas: minimizar o nmero de aes necessrias para atingir

um objetivo ou executar uma tarefa, limitando os passos e

procedimentos ao mnimo possvel.

Densidade de informao: minimizar o nmero de elementos em uso, visando

a todo conjunto de informaes apresentadas aos usurios e no a cada

elemento separadamente, de modo que itens no relacionados s tarefas

devem ser removidos.

Controle explcito

O critrio refere-se ao processamento pelo sistema das aes explcitas dos

usurios e pelo controle que o mesmo possui sobre o processamento de suas aes

pelo sistema, subdividindo-se em:

Aes explcitas do usurio: o sistema deve executar apenas as aes

requeridas pelo usurio e quando forem requeridas;

Controle do usurio: a pluralidade de aes do usurio dever ser antecipada,

permitindo cancelar, interromper, suspender e continuar e desfazer o

processamento de uma ao qualquer. Todas as possveis aes dos

usurios devem ser previstas e opes adequadas devem ser oferecidas.

287

Adaptabilidade

Permite assegurar que o projeto do sistema seja capaz de reagir s necessidades

do contexto, de acordo com as necessidades e preferncias do usurio, de modo

que quanto maiores forem as chances do usurio encontrar uma ao que se adapte

s suas preferncias melhor ser o aprendizado. Este critrio subdivide-se em:

Flexibilidade: refere-se aos meios disponveis ao usurio para personalizar

partes da interface, a fim de permitir variaes da tarefa e de estratgias ou

hbitos de trabalho;

Experincia do usurio: oferecer os meios para considerar a experincia do

usurio; para iniciantes desejvel maior nvel de orientao e iniciativa do

sistema, e aos mais experientes, desejvel a existncia de atalhos.

Gesto de erros

Permitir que o usurio evite ou reduza erros, alm de permitir que sejam corrigidos

no momento em que aparecem:

Proteo contra erros: fornecer condies aos usurios para detectar e

prevenir erros na introduo de dados ou aes que podero causar

consequncias destrutivas tarefa;

Qualidade das mensagens de erros: garantir a pertinncia e a exatido da

informao oferecida ao usurio sobre a natureza dos erros (sintaxe, formato,

etc.) e aes necessrias correo;

Correo de erros: disponibilizar ao usurio os meios para correo de seus

erros.

Consistncia

Procurar garantir que as caractersticas da interface (cdigos, procedimentos,

denominaes, posies, etc.), sejam conservadas em contextos idnticos; aplica-se

tambm ao formato da sintaxe utilizada.

Ttulos, cones, links e outros objetos da interface so melhores reconhecidos,

lembrados, localizados e utilizados se o formato, localizao, sintaxe e

comportamento forem estveis de tela para tela. Deste modo, o comportamento do

288

sistema ser mais previsvel, o aprendizado e a generalizao sero facilitados e o

nmero de erros reduzido.

Interfaces consistentes formam um melhor modelo mental do sistema, implicando

maior influncia no desempenho a seus usurios.

A falta de consistncia pode ser um dos motivos de rejeio do sistema, pois pode

aumentar consideravelmente o tempo de pesquisa e a quantidade de aes.

Significao dos cdigos

Permite assegurar a identificao entre objetos ou informaes fornecidas pelo

sistema, qualificando o relacionamento entre um termo/sinal e sua referncia.

Nomes e cdigos so significativos aos usurios, quando ocorre uma forte

semntica entre eles e os itens ou aes aos quais se referem.

Compatibilidade

Permite assegurar a correspondncia entre as caractersticas do usurio (memria,

percepo, hbitos, conhecimentos, idade, competncia, etc.), as caractersticas da

tarefa e a organizao dos dados de entrada e dilogo.

A terminologia deve ser pautada na linguagem dos usurios e no no jargo da

informtica, utilizando as palavras com o sentido padro existente na comunidade

dos usurios.

Os usurios que aprendem a usar interfaces consistentes, formam um melhor

modelo mental do sistema.

Recommended

View more >