UNIVERSIDADE DE SO PAULO

FACULDADE DE ECONOMIA, ADMINISTRAO E CONTABILIDADE

DEPARTAMENTO DE ADMINISTRAO

LUIZ ANTONIO ZANETI JUNIOR

SISTEMAS DE INFORMAO BASEADOS NA TECNOLOGIA WEB:

UM ESTUDO SOBRE SEU DESENVOLVIMENTO

ORIENTADOR: PROF. DR. ANTONIO GERALDO DA ROCHA VIDAL

So Paulo
2003

Reitor da Universidade de So Paulo

Prof. Dr. Adolpho Jos Melfi

Diretora da Faculdade de Economia, Administrao e Contabilidade

Profa. Dra. Maria Tereza Leme Fleury

Chefe do Departamento de Administrao

Prof. Dr. Eduardo Pinheiro Gondim de Vasconcellos

UNIVERSIDADE DE SO PAULO
FACULDADE DE ECONOMIA, ADMINISTRAO E CONTABILIDADE
DEPARTAMENTO DE ADMINISTRAO

LUIZ ANTONIO ZANETI JUNIOR

SISTEMAS DE INFORMAO BASEADOS NA TECNOLOGIA WEB:

UM ESTUDO SOBRE SEU DESENVOLVIMENTO

Dissertao apresentada Faculdade de

Economia, Administrao e Contabilidade da
Universidade de So Paulo para a obteno do
ttulo de Mestre em Administrao.
rea de Concentrao:
Mtodos Quantitativos e Informtica
Orientador:
Prof. Dr. Antonio Geraldo da Rocha Vidal

So Paulo
2003

FICHA CATALOGRFICA

Zaneti Junior., Luiz Antonio

Sistemas de informao baseados na tecnologia Web : um
estudo sobre seu desenvolvimento / Luiz Antonio Zaneti
Junior. -- So Paulo : FEA / USP, 2003.
189 p.
Dissertao Mestrado
Bibliografia.
1. Tecnologia da informao 2. Administrao Sistemas
de informao 3. World Wide Web (Sistemas de recuperao
da informao) I. Faculdade de Economia, Administrao e
Contabilidade da USP
CDD 658.4038

 minha me, pelo exemplo de

persistncia na realizao dos nossos
sonhos.
minha esposa, pelo incentivo nos
momentos mais difceis.

AGRADECIMENTOS

Ao meu orientador, Prof. Dr. Antonio Geraldo da Rocha Vidal, pelo apoio, incentivo,
compreenso e correta orientao.
A todos que concordaram em participar desta pesquisa, tornando possvel sua
concretizao.
minha me, Vera, e ao Ricardo Minei pelo cansativo trabalho de reviso ortogrfica.
Gostaria de salientar, com apreo, a contribuio do Ricardo Minei que, apesar das
dificuldades, gentilmente se ofereceu para revisar este trabalho.
minha prima, Eliane Pinto Alves Melchert, pela caprichosa elaborao das figuras.

SUMRIO
LISTA DE FIGURAS .................................................................................................... V
LISTA DE TABELAS ................................................................................................. VI
LISTA DE SIGLAS ....................................................................................................VII
RESUMO ................................................................................................................... VIII
ABSTRACT.................................................................................................................. IX
1. O PROBLEMA DE PESQUISA................................................................................1
1.1 INTRODUO ...........................................................................................................1
1.2 FORMULAO DO PROBLEMA ..................................................................................4
1.3 QUESTO PRINCIPAL DA PESQUISA ..........................................................................7
1.4 OBJETIVOS DA PESQUISA .........................................................................................7
1.5 ORGANIZAO DA PESQUISA ...................................................................................7
2. TECNOLOGIA WEB .................................................................................................9
2.1 HISTRICO DA INTERNET E DA WEB .........................................................................9
2.2 DEFINIO DE TECNOLOGIA WEB ............................................................................9
2.3 A TECNOLOGIA WEB COMO PLATAFORMA PARA DIVULGAO DE INFORMAES 10
2.4 A TECNOLOGIA WEB COMO PLATAFORMA DE ACESSO A SISTEMAS DE INFORMAO
.....................................................................................................................................11
2.5 A TECNOLOGIA WEB COMO UM SISTEMA HIPERMDIA ...........................................14
3. SISTEMAS DE INFORMAO ............................................................................17
3.1 DEFINIO DE SISTEMAS DE INFORMAO ............................................................17
3.2 A ORGANIZAO E OS SISTEMAS DE INFORMAO ...............................................17
3.3 FORMAS DE CLASSIFICAO DE SISTEMAS DE INFORMAO .................................19
3.4 OS SISTEMAS DE INFORMAO BASEADOS NA TECNOLOGIA WEB ..........................20
3.4.1 As geraes tecnolgicas dos Sistemas de Informao .................................20
3.4.2 Definio de Sistemas de Informao baseados na tecnologia Web.............21
3.4.3 Aplicaes de Sistemas de Informao baseados na tecnologia Web ...........24
4. DESENVOLVIMENTO DE SISTEMAS DE INFORMAO (DSI) .................27
4.1 DEFINIO DE DSI.................................................................................................27
4.2 PRINCIPAIS CONCEITOS RELACIONADOS AO DSI ....................................................29
4.2.1 Interessados ...................................................................................................29
4.2.2 Tarefas ...........................................................................................................29
4.2.3 Programa de trabalho....................................................................................30
4.2.4 Transaes .....................................................................................................30
4.2.5 Contexto .........................................................................................................30
4.2.6 Estrutura ........................................................................................................31

ii

4.2.7 Sadas .............................................................................................................31

4.3 ESTRATGIAS PARA O DSI .....................................................................................31
4.4 METODOLOGIAS DE DSI.........................................................................................34
4.4.1 Definio de Metodologia de DSI..................................................................34
4.4.2 Geraes de Metodologias de DSI.................................................................36
4.4.3 Classificao das Metodologias de DSI ........................................................38
4.5 MODELAGEM DE SI ................................................................................................43
4.5.1 Definio de Modelagem ...............................................................................43
4.5.2 Classificao das Formas de Modelagem de SI ............................................44
4.5.3 Linguagens para Modelagem de SI ...............................................................48
4.6 ENGENHARIA DE MTODOS....................................................................................49
4.7 QUALIDADE EM SOFTWARE....................................................................................50
5. DESENVOLVIMENTO DE SISTEMAS DE INFORMAO PARA A WEB
(SIW) ..............................................................................................................................52
5.1 CARACTERSTICAS DO DESENVOLVIMENTO DE SIW ..............................................52
5.2 METODOLOGIAS PARA DESENVOLVIMENTO DE SIW..............................................55
5.2.1 Hypertext Design Model............................................................................55
5.2.2 Relationship Management Methodology...................................................56
5.2.3 Object-Oriented Hypermedia Design Method...........................................57
5.2.4 Relationship Navigation Analysis..............................................................57
5.2.5 O Enfoque Hipermdia ...................................................................................58
5.3 CICLO DE VIDA DE SIW .........................................................................................59
5.4 FERRAMENTAS DE DESENVOLVIMENTO PARA WEB .................................................61
6. METODOLOGIA DE PESQUISA..........................................................................64
6.1 ESTUDO DE CASO ...................................................................................................64
6.2 TIPOS DE PROJETOS PARA ESTUDOS DE CASO ........................................................65
6.3 CARACTERIZAO DA PESQUISA............................................................................65
6.4 PROJETO DA PESQUISA ...........................................................................................66
6.5 PLANEJAMENTO DA PESQUISA ...............................................................................67
6.5.1 Tipos de Projeto para Pesquisa em DSI ........................................................68
6.5.2 Questo de Pesquisa ......................................................................................69
6.5.3 Proposies....................................................................................................69
6.5.4 Modelo Conceitual da Pesquisa ....................................................................71
6.5.4.1 Contexto ..................................................................................................74
6.5.4.2 Interessados.............................................................................................75
6.5.4.3 Tarefas.....................................................................................................75
6.5.4.4 Estrutura ..................................................................................................76
6.5.4.5 Sadas ......................................................................................................77
6.5.5 Unidade de Anlise ........................................................................................77
6.5.6 Escolha dos Casos .........................................................................................77
6.5.7 Coleta de Dados.............................................................................................78
6.5.8 Protocolo de Estudo de Casos .......................................................................79
7. APRESENTAO E ANLISE DOS CASOS ESTUDADOS ............................80
7.1 CASO EMPRESA DE SANEAMENTO PORTAL DE APLICAES DE NEGCIOS .....80

iii

7.1.1 Introduo......................................................................................................80
7.1.2 Descrio do Caso .........................................................................................80
7.1.2.1 Contexto ..................................................................................................80
7.1.2.2 Interessados.............................................................................................82
7.1.2.3 Tarefas.....................................................................................................83
7.1.2.4 Estrutura ..................................................................................................86
7.1.2.5 Sadas ......................................................................................................87
7.1.3 Comentrios ...................................................................................................88
7.2 CASO EMPRESA DE MDIA SISTEMA DE ASSINATURAS ....................................90
7.2.1 Introduo......................................................................................................90
7.2.2 Descrio do Caso .........................................................................................90
7.2.2.1 Contexto ..................................................................................................90
7.2.2.2 Interessados.............................................................................................92
7.2.2.3 Tarefas.....................................................................................................93
7.2.2.4 Estrutura ..................................................................................................98
7.2.2.5 Sadas ....................................................................................................100
7.2.3 Comentrios .................................................................................................100
7.3 CASO EMPRESA DE TI SISTEMA DE VENDA B2B ...........................................102
7.3.1 Introduo....................................................................................................102
7.3.2 Descrio do Caso .......................................................................................102
7.3.2.1 Contexto ................................................................................................102
7.3.2.2 Interessados...........................................................................................105
7.3.2.3 Tarefas...................................................................................................106
7.3.2.4 Estrutura ................................................................................................108
7.3.2.5 Sadas ....................................................................................................109
7.3.3 Comentrios .................................................................................................110
7.4 CASO EMPRESA DE CONSTRUO SISTEMA WEB DE AVALIAO .................111
7.4.1 Introduo....................................................................................................111
7.4.2 Descrio do Caso .......................................................................................111
7.4.2.1 Contexto ................................................................................................111
7.4.2.2 Interessados...........................................................................................112
7.4.2.3 Tarefas...................................................................................................114
7.4.2.4 Estrutura ................................................................................................116
7.4.2.5 Sadas ....................................................................................................117
7.4.3 Comentrios .................................................................................................118
7.5 CASO EMPRESA DE FAST-FOOD SISTEMA DE PEDIDOS VIA WEB ....................119
7.5.1 Introduo....................................................................................................119
7.5.2 Descrio do Caso .......................................................................................119
7.5.2.1 Contexto ................................................................................................119
7.5.2.2 Interessados...........................................................................................120
7.5.2.3 Tarefas...................................................................................................121
7.5.2.4 Estrutura ................................................................................................125
7.5.2.5 Sadas ....................................................................................................126
7.5.3 Comentrios .................................................................................................127
7.6 CASO CONGLOMERADO INDUSTRIAL SISTEMA WEB DE INFORMAES
GERENCIAIS .............................................................................................................129

iv

7.6.1 Introduo....................................................................................................129
7.6.2 Descrio do Caso .......................................................................................129
7.6.2.1 Contexto ................................................................................................129
7.6.2.2 Interessados...........................................................................................131
7.6.2.3 Tarefas...................................................................................................132
7.6.2.4 Estrutura ................................................................................................136
7.6.2.5 Sadas ....................................................................................................138
7.6.3 Comentrios .................................................................................................138
7.7 CASO BANCO SISTEMA PARA A RECEPO DE PROPOSTAS VINDAS DE WEB
SITES ........................................................................................................................140
7.7.1 Introduo....................................................................................................140
7.7.2 Descrio do Caso .......................................................................................141
7.7.2.1 Contexto ................................................................................................141
7.7.2.2 Interessados...........................................................................................143
7.7.2.3 Tarefas...................................................................................................144
7.7.2.4 Estrutura ................................................................................................147
7.7.2.5 Sadas ....................................................................................................148
7.8 CASO BANCO SISTEMA WEB PARA RECEPO DE PROPOSTAS DAS
CONCESSIONRIAS ...................................................................................................149
7.8.1 Introduo....................................................................................................149
7.8.2 Descrio do Caso .......................................................................................150
7.8.2.1 Contexto ................................................................................................150
7.8.2.2 Interessados...........................................................................................152
7.8.2.3 Tarefas...................................................................................................153
7.8.2.4 Estrutura ................................................................................................156
7.8.2.5 Sadas ....................................................................................................157
7.8.3 Comentrios .................................................................................................158
8. CONCLUSES .......................................................................................................160
8.1 INTRODUO .......................................................................................................160
8.2 ANLISE DAS PROPOSIES .................................................................................160
8.3 DISCUSSO DAS QUESTES DE PESQUISA ............................................................171
8.4 LIMITAES .........................................................................................................176
8.5 RECOMENDAES ................................................................................................177
9. ANEXOS ..................................................................................................................178
9.1 ANEXO I PR-QUESTIONRIO ............................................................................178
9.2 ANEXO II ROTEIRO DAS ENTREVISTAS ..............................................................181
10. REFERNCIAS BIBLIOGRFICAS................................................................184

LISTA DE FIGURAS
FIGURA 1 UMA ESTRUTURA SISTMICA PARA O CAMPO DE SI (BACON & FITZGERALD,
2001, P.53).................................................................................................................5
FIGURA 2 FUNCIONAMENTO DA TECNOLOGIA WEB PARA ACESSO A UM WEB SITE
TRADICIONAL .......................................................................................................11
FIGURA 3 UTILIZAO DA TECNOLOGIA WEB COMO PLATAFORMA DE ACESSO A OUTROS
SI .............................................................................................................................12
FIGURA 4 SISTEMA DE INFORMAO BASEADO NA TECNOLOGIA WEB .............................13
FIGURA 5 EVOLUO DA TECNOLOGIA WEB (TRAVIS, 2000, P. 133) ............................14
FIGURA 6 CLASSIFICAO DE SI CONFORME O PROPSITO (OBRIEN, 2001, P. 28).......19
FIGURA 7 CLASSIFICAO DOS SI DE APOIO S OPERAES CONFORME A FUNO
ORGANIZACIONAL AFETADA (OBRIEN, 2001, P. 173) ...........................................20
FIGURA 8 A INTERNET E AS ORGANIZAES (ADAPTADO DE KALAKOTA &
WHINSTON APUD OBRIEN, 2001, P. 12)............................................................25
FIGURA 9 DESENVOLVIMENTO DE SISTEMAS DE INFORMAO (HIRSCHHEIM, KLEIN
& LYYTINEM, 1995, P. 16)...................................................................................28
FIGURA 10 O CICLO DE VIDA DE UMA APLICAO WEB (FRATERNALLI, 1999, P. 229)
.................................................................................................................................60
FIGURA 11 MODELO CONCEITUAL DA PESQUISA .............................................................74

vi

LISTA DE TABELAS
TABELA 1 ESTRUTURA PARA CLASSIFICAO DE SI (GORRY & MORTON APUD
LUCAS, 1997, P.43) ...............................................................................................20
TABELA 2 ESTRUTURA PARA CLASSIFICAO DAS APLICAES HIPERMDIA (ADAPTADO
DE ISAKOWITZ, STOHR & BALASUBRAMANIAM, 1995, P. 36)...................23
TABELA 3 VANTAGENS E DESVANTAGENS DE CADA ENFOQUE DE DESENVOLVIMENTO
(AMBLER, 1998, P. 22)..........................................................................................33
TABELA 4 RESUMO DE SEIS ENFOQUES FUNCIONALISTAS (IIVARY, HIRSCHHEIM &
KLEIN, 2000-2001, P. 192) ....................................................................................43
TABELA 5 ESTRUTURA ISA DE SEIS COLUNAS (SOWA & ZACHMAN, 1992, P. 590)...47
TABELA 6 OS CINCO NVEIS DE MATURIDADE DO CMM (ADAPTADO DE AMBLER, 1998,
P. 58-59) ..................................................................................................................51
TABELA 7 ENFOQUE DAS METODOLOGIAS DE HIPERMDIA (ELABORADO PELO AUTOR)..59
TABELA 8 SITUAES RELEVANTES PARA DIFERENTES ESTRATGIAS DE PESQUISA (YIN,
1994, P. 6)................................................................................................................64
TABELA 9 TIPOS BSICOS DE DESIGN PARA ESTUDOS DE CASO (YIN, 1994, P. 39).........65
TABELA 10 UMA VISO RESUMIDA DOS SETE CONCEITOS CHAVE E SEUS VALORES
(SAMBAMURTHY & KIRSCH, 2000, P. 403).....................................................73
TABELA 11 COMPARAO ENTRE OS MODELOS UTILIZADOS NOS CASOS ESTUDADOS ....163

vii

LISTA DE SIGLAS
B2B Business to Business
B2C Business to Consumer
CASE Computer Aided System/Software Environment/Engineering
CISC Complex Instruction Set Computer
CMM Capability Maturity Model
CRM Customer Relationship Management
DSI Desenvolvimento de Sistemas de Informao
EDI Electronic Data Interchange
ERP Enterprise Resource Planning
HDM Hypertext Design Model
HDM2 Hypertext Design Model 2
HTML - Hypertext Markup Language
HTTP Hypertext Transfer Protocol
ISA Information Systems Architecture
OEM Organizao e Mtodos
OLAP On-line Analitical Processing
OML Object Modeling Language
OOHDM Object-oriented Hypermedia Design Model
OPEN Object-oriented Process, Environment and Notation
PDCA Plan, Do, Check and Action
RH Recursos Humanos
RISC Reduced Instruction Set Computer
RMDM Relationship Management Data Model
RMM Relationship Management Methodology
RNA Relationship Navigation Analysis
SAD Sistema de Apoio Deciso
SDLC System Development Life Cicle
SEI Software Engineering Institute
SGBD Sistema Gerenciador de Banco de Dados
SI Sistema de Informao
SIW Sistema de Informao baseado na Tecnologia Web
TI Tecnologia da Informao
UML Unified Modeling Language
URL Uniform Resource Locator
WBIS Web-based Information System
WIS Web Information System
WWW World Wide Web
XML - Extensible Markup Language

viii

RESUMO
A tecnologia Web foi criada como forma de divulgar o conhecimento cientfico, mas
tem sido utilizada tambm como mecanismo de acesso a vrios tipos de sistemas de
informao empresariais assim como de comunicao entre eles, gerando diversas
oportunidades de negcios para as organizaes.
Os sistemas de informao baseados na tecnologia Web (SIW) possuem caractersticas
que permitem supor que seu desenvolvimento apresenta diferenas com relao ao de
sistemas no Web.
O objetivo desta pesquisa foi levantar, atravs de um estudo exploratrio de mltiplos
casos, as questes relevantes ao desenvolvimento de sistemas de informao baseados
na tecnologia Web que apiam aplicaes de negcios nas organizaes. Para tanto,
procuramos identificar as principais dificuldades e facilidades, as alteraes sucedidas
nas tarefas e na estrutura do desenvolvimento, assim como analisar a adoo de tcnicas
e metodologias.
Esperamos ter contribudo para que as organizaes possam aprimorar o
desenvolvimento de SIW de forma a aproveitar ao mximo as oportunidades criadas
pela tecnologia Web.

ix

ABSTRACT
The Web technology was created to divulge the scientific knowledge, although it has
been used as a way to access several types of business information systems as well as to
facilitate the communication between them, generating many business opportunities for
the organizations.
Web-based information systems (WIS) have characteristics that allow us to assume
their development is different from non-Web information systems.
The objective of this research was to identify, through an exploratory multi-case study,
the main questions about business Web-based information systems development. We
have tried to identify the main difficulties and easiness, the changes occurred in
development tasks and structure, and to analyze techniques and methodologies
adoption.
We hope we had contributed to allow organizations be able to improve the WIS
development process in order to take the maximum advantage of the opportunities
generated by Web technology.

1. O problema de pesquisa
1.1 INTRODUO
Durante a dcada de 90 uma nova tecnologia da Internet foi criada: a tecnologia Web.
Ela surgiu com o objetivo de formar um repositrio do conhecimento humano
(BERNERS-LEE et al., 1994) e est baseada em mecanismos de armazenamento,
recuperao e visualizao de documentos eletrnicos.
A tecnologia Web funciona de forma relativamente simples: o repositrio formado
por documentos eletrnicos que ficam armazenados em servidores ligados rede
mundial de computadores, a Internet, e que podem ser recuperados e visualizados a
partir de qualquer computador conectado a ela. Tais documentos eletrnicos so
chamados de pginas Web e podem referenciar outros, formando assim a grande rede de
informaes que a World Wide Web, ou simplesmente Web.
Desde a sua criao at hoje, o nmero de usurios Web, assim como o de
computadores que armazenam seu contedo (servidores Web), cresceu
vertiginosamente. Em junho de 2002 o nmero de servidores Web j era de mais de
38.000.000 (NETCRAFT, 2002) e o de usurios da Web de mais de 770.000.000
(NETSIZER, 2002).
Embora a Web tenha comeado como um meio de divulgao de informaes
relacionadas principalmente ao ambiente acadmico, rapidamente as empresas passaram
a utiliz-la como um veculo para a divulgao de seus produtos e servios.
Ao longo do tempo, a tecnologia Web foi sendo modificada de forma a incorporar
novos recursos e novas funes. Uma grande evoluo aconteceu quando passou a
permitir que os usurios da Web pudessem no somente solicitar pginas com contedo
esttico, mas tambm enviar, junto com as solicitaes, informaes aos servidores, os
quais poderiam process-las e retornar de forma dinmica o resultado. Em outras
palavras, a tecnologia Web deixou de ser apenas um mecanismo de acesso a um grande
repositrio de documentos eletrnicos estticos e passou a funcionar como interface de
acesso a diversos sistemas de informao dinmicos.
Por permitir a universalizao do acesso informao, a tecnologia Web gera novas
oportunidades de negcios. Atividades que envolvem interao com os clientes e
fornecedores (por exemplo, compra, venda, atendimento ps-venda, suporte ao cliente,
recrutamento e divulgao dos produtos, servios e pedidos) podem ser transformadas
para aproveitar os benefcios da tecnologia. Alm disso, possvel comercializar os
espaos virtuais de forma similar ao que feito em outras mdias como jornais e
revistas.
A localizao das empresas em muitos casos torna-se menos importante, pois, de certa
forma, na Web todas as empresas esto mesma distncia dos consumidores. Por
outro lado, o espao virtual e a forma como a interface do sistema projetada tm sua
importncia ressaltada.

Algumas atividades podem ser feitas sem intermediao (YANES, 1998, p.42), como
o caso de alguns servios oferecidos por rgos governamentais. Por outro lado, novos
intermedirios podem ser criados (YANES, 1998, p.42), como, por exemplo, servios
de busca na rede ou de agregao de informaes.
Ao longo dos ltimos anos temos visto um grande impulso nos negcios eletrnicos,
principalmente do comrcio negcio-para-consumidor (B2C) e negcio-para-negcio
(B2B), e isso tem acontecido, em grande parte, devido s oportunidades da tecnologia
Web.
No incio, houve um grande crescimento de empresas, denominadas pontocom,
criadas principalmente para aproveitar as oportunidades geradas pela nova tecnologia.
Em princpio, elas no tm a necessidade de grandes instalaes e o investimento
necessrio recai principalmente na tecnologia. Porm, atualmente observa-se como uma
tendncia mais consistente a incorporao dos negcios eletrnicos atravs da
tecnologia Web pelas empresas tradicionais j estabelecidas no mercado, as quais
tendem a sofrer uma transformao.
A tecnologia Web tambm impulsionou o desenvolvimento de sistemas
interorganizacionais. Tais sistemas j existiam antes dela, entretanto, estavam baseados
em redes privadas de comunicao, onde o custo mais alto do que atravs da Internet.
Tais sistemas permitem a troca de informaes de negcios entre parceiros dentro de
uma cadeia produtiva. Sistemas colaborativos, onde os parceiros trocam informaes
sobre previso de demanda, estoques gerenciados pelo vendedor, aplicaes de
comrcio eletrnico entre empresas com transferncia eletrnica de pedidos e de fundos
podem utilizar as vantagens e facilidades da tecnologia Web.
Para descrever a evoluo da utilizao da Web, DONNELLY (2001, p. 7-12) props as
seguintes fases:
1. Presena na Web: a fase inicial, onde a maior parte do contedo disponvel na
Web consistia de white papers e material de pesquisa. Os usurios eram,
geralmente, pessoas ligadas ao ambiente acadmico, de pesquisa ou da rea de
computao e a principal motivao para utilizao da Web era o
compartilhamento de informaes. Nesta fase, poucas empresas
disponibilizavam contedo e, quando o faziam, forneciam apenas uma pgina,
chamada de home page, e talvez mais algumas pginas contendo informaes
para contato.
2. Tecnologia Web: vrias empresas haviam registrado seus Web Sites e o nmero
de usurios havia crescido significativamente. As empresas comearam a utilizar
a Web como ferramenta de propaganda e marketing. A preocupao principal
era criar uma vitrine virtual usando recursos sofisticados de tecnologia grfica

para prender a ateno dos usurios. Os tcnicos (desenvolvedores1 Web)

comearam a utilizar as novas linguagens de programao para a Web a fim de
implementar documentos eletrnicos ou pginas com alguns recursos interativos
e interfaces grficas mais robustas. Porm, tais Web Sites eram geralmente
criados por projetistas grficos com formao mais voltada para o ambiente de
publicao tradicional do que para o processo clssico de desenvolvimento de
sistemas.
3. Comrcio na Web: com a difuso das novas linguagens de programao para a
Web tornou-se possvel o uso de formulrios online atravs dos quais os usurios
podiam fornecer informaes para o Web Site. At ento, eles tinham um papel
passivo, mas isso comeava a mudar. As empresas passaram a desenvolver
solues de comrcio eletrnico baseado na Web. Entretanto, para que uma
compra eletrnica pudesse ser realizada o usurio deveria poder achar e
selecionar os produtos, fornecer os dados, consultar as condies de entrega e
confirmar a compra, ou seja, os Web Sites precisavam apoiar todas as etapas
necessrias para a realizao da transao de compra ou de qualquer outra
transao, aumentando a importncia do projeto da navegao e do fluxo das
tarefas.
4. Integrao com sistemas de apoio: atualmente, muitas empresas esto integrando
a interface Web com seus sistemas de apoio. Como exemplo dessa necessidade,
podemos citar a compra eletrnica. Para que o processo de compra satisfaa as
necessidades dos usurios preciso inform-los quais itens esto em estoque,
assim como a data prevista para a entrega, o que exige consultas aos outros
sistemas da empresa.
5. Intranets e Extranets: as empresas j percebem que a tecnologia Web tambm
pode ser utilizada em sistemas internos. Algumas caractersticas, como o fato de
no exigir instalaes ou configurao nas estaes de trabalho dos usurios
(computadores clientes), tendem a impulsionar a migrao de alguns sistemas de
informao da empresa para essa nova tecnologia. Tais sistemas, utilizados
principalmente pelos funcionrios, tm sido chamados de Intranets. De forma
anloga, a tecnologia Web tambm oferece diversas vantagens para o
desenvolvimento ou migrao de sistemas interorganizacionais, os quais podem,
por exemplo, ligar uma empresa sua cadeia de fornecedores atravs da Web,
tendo sido chamados de Extranets.
A tecnologia Web tem apresentado e deve causar um grande impacto nos sistemas de
informao das empresas, tanto na forma como esto sendo ou sero construdos como
na maneira como esto sendo ou sero utilizados. Os sistemas de informao baseados
1

Embora no exista na lngua portuguesa, a palavra desenvolvedor comumente utilizada (como

traduo de developer, da lngua inglesa) pelos envolvidos com a tecnologia da informao e representa
os profissionais de TI que desempenham atividades ligadas ao desenvolvimento de software, tais como
anlise, projeto, construo e teste. Como no h outra com tal significado, utilizaremos esta palavra ao
longo deste trabalho.

nessa tecnologia apresentam algumas caractersticas diferentes dos sistemas

desenvolvidos em outras tecnologias e, por isso, tm sido considerados por alguns
autores (ISAKOWITZ, BIEBER e VITALI, 1998; PRESS, 1999) como uma nova
gerao de sistemas de informao.

1.2 FORMULAO DO PROBLEMA

O campo de sistemas de informao bastante amplo e, numa tentativa de descrev-lo
melhor, BACON & FITZGERALD (2001, p.53) desenvolveram uma estrutura
conceitual agrupando suas reas e subreas. Nesta estrutura, os autores identificaram
cinco grandes reas e algumas dezenas de subreas. A Figura 1 descreve a estrutura
proposta:

Desenvolvimento, Aquisio e Suporte

de SI

Desenv. de sistemas
Manuteno
Uso e suporte
Aquisio de sist. e implementao
Gerenciamento de dados e
administrao
Arquitetura e infraestrutura
Metodologia
Gerenciamento de projetos
Parceria externa
Tipos de Sistema/Aplicao
Auxiliado por
O auxlio do

Automatizado
e habilitado
atravs da

Pessoas e Organizao

Gerenciamento de SI/TI
Estratgia de negcio e alinhamento
Investimento em SI e avaliao
Melhora do processo
Desenv. organizacional
Gerenciamento da mudana
Aspectos comportamentais
Treinamento e recursos humanos
tica e sociedade
Tipos de Uso/Indstria
Capacitado por

Informao para Trabalho do Conhecimento, Satisfao do

Cliente e Performance do Negcio

Capacita

Natureza do dado, informao e conhecimento

Uso da informao nas organizaes
Interface homem-computador
Relevncia, valor e custo da informao
Qualidade do dado
Gerenciamento do conhecimento e aprendizagem
organizacional
Semitica
Pesquisa em SI, teoria e estruturas
Automatiza e habilita

Tecnologia de Informao e
Comunicao
Perspectivas da tecnologia
Software
Base de dados/Warehouse
Hardware
Armazenamento (storage)
Telecomunicaes
Comrcio eletrnico
Internet e World Wide Web

Proporcionado
por

Proporciona
Gerenciamento de Operaes e Redes
Produo e Operaes
Sistemas de software e tcnicos
Gerenciamento de servios e Help
Desk
Gerenciamento da Rede e
Infraestrutura
Gerenciamento de Configurao
Gerenciamento de armazenamento
(storage)
Segurana e controle
Continuao do negcio

Figura 1 Uma Estrutura Sistmica para o Campo de SI (Bacon & Fitzgerald, 2001, p.53)

Neste trabalho estaremos nos concentrando na rea de Desenvolvimento, Aquisio e

Suporte de SI. Alm disso, por ser uma rea bastante ampla, estaremos focando o
estudo nas subreas de Desenvolvimento de Sistemas e Metodologia.
Gostaramos de ressaltar que, embora o termo desenvolvimento possa envolver diversas
questes, estaremos focando o estudo nos aspectos relacionados ao projeto e construo
dos sistemas assim como na adoo de metodologias e tcnicas de apoio.
A rea de Sistemas de Informao, especialmente de Desenvolvimento de Sistemas de
Informao (DSI), j vem sendo estudada h algumas dcadas. Vrias metodologias
para guiar o processo de desenvolvimento foram propostas. Os novos sistemas de
informao baseados na tecnologia Web apresentam, entretanto, caractersticas que
ainda no so bem atendidas pelas metodologias existentes (ISAKOWITZ, BIEBER &
VITALI, 1998).
As diferenas dessa nova gerao de sistemas de informao introduzem desafios
gerenciais e tcnicos (ISAKOWITZ, BIEBER & VITALI, 1998) e o seu sucesso
depender principalmente do sucesso no desenvolvimento (ISAKOWITZ, BIEBER &
VITALI, 1998). Os sistemas de informao baseados na tecnologia Web, ou
simplesmente Sistemas Web, envolvem recursos de hipertexto/hipermdia, informaes
estruturadas e no estruturadas, arquitetura de comunicao assncrona capaz de
suportar um grande nmero de acessos, questes de segurana (quando se utiliza
infraestrutura de comunicao pblica) e interligao com os sistemas existentes, dentre
outras questes ainda no completamente resolvidas pelas abordagens clssicas de
sistemas de informao.
Conforme citado, a tecnologia Web deixou de ser utilizada apenas como meio para a
divulgao de documentos eletrnicos para tornar-se a infraestrutura de apoio a
sistemas de informao organizacionais. Os sistemas esto se tornando cada vez mais
complexos, o que torna difcil gerenciar o processo de desenvolvimento utilizando
mtodos clssicos ou ad-hoc (PEARSON & PAYNTER, 1998).
Vrias metodologias para o desenvolvimento de sistemas baseados na Web tm sido
propostas (SCHARL, 1999; ROSSI, SCHWABE & LYARDET, 1999; ISAKOWITZ,
STHOR & BALASUBRAMANIAN, 1995; TROYER & LEUNE, 1998). Grande parte
dos estudos aborda o desenvolvimento de novas tcnicas, mtodos e metodologias, mas
poucos enfatizam a forma como o desenvolvimento tem sido feito nas empresas ou a
avaliao do seu resultado.
Considerando que a demanda pela construo de novos sistemas Web e sua interligao
com os sistemas j existentes tem sido grande e supondo que tender a crescer ainda
mais, acreditamos ser muito importante a realizao de estudos visando entender e
orientar como melhor conduzir o desenvolvimento de sistemas de informao baseados
nesta tecnologia.

Como h pouca pesquisa emprica no uso real das metodologias de desenvolvimento

de sistemas de informao (HIRSCHHEIM, IIVARY & KLEIN, 1997) e poucos
estudos tm analisado como tal processo tem ocorrido, acreditamos ser essa uma boa
oportunidade para produzir um estudo exploratrio sobre o desenvolvimento de
sistemas de informao baseados na tecnologia Web que possa trazer contribuies
relevantes para a aplicao da tecnologia nos negcios empresariais.

1.3 QUESTO PRINCIPAL DA PESQUISA

A fim de direcionarmos o estudo, colocaremos a seguinte questo:
COMO est ocorrendo nas organizaes o desenvolvimento de sistemas de
informao baseados na tecnologia Web?
Para responder a esta questo procuraremos responder s seguintes questes
secundrias:
QUAIS as principais dificuldades e facilidades relacionadas ao
desenvolvimento de novos sistemas tendo em vista a tecnologia Web?
QUAIS foram e POR QUE ocorreram as mudanas no DSI devido utilizao
da tecnologia Web?

1.4 OBJETIVOS DA PESQUISA

O objetivo desta pesquisa levantar as questes relevantes ao desenvolvimento de
sistemas de informao baseados na tecnologia Web para apoiar aplicaes de negcios
nas organizaes. Para tanto, procuraremos identificar as principais dificuldades e
facilidades no desenvolvimento, assim como analisar sua construo e a adoo de
tcnicas e metodologias.

1.5 ORGANIZAO DA PESQUISA

A dissertao foi dividida em seis captulos da seguinte forma:
CAPTULO 2: Tecnologia Web, onde so apresentadas e discutidas as caractersticas
dessa tecnologia.
CAPTULO 3: A Organizao e os Sistemas de Informao, onde so definidos os
sistemas de informao e discutidas algumas formas de classific-los.
CAPTULO 4: Desenvolvimento de Sistemas de Informao, onde so definidos os
principais conceitos envolvidos no processo e discutidas as estratgias de
desenvolvimento.
CAPTULO 5: Desenvolvimento de Sistemas de Informao para a Web, onde so
discutidas as questes relevantes ao processo de desenvolvimento de sistemas de
informao baseados na tecnologia Web.

CAPTULO 6: Metodologia de Pesquisa, onde a metodologia utilizada para a pesquisa

definida e justificada.
CAPTULO 7: Apresentao e Anlise dos Resultados, onde os casos so apresentados
e analisados os casos estudados.
CAPTULO 8: Concluses, onde so discutidas as proposies e as questes de
pesquisa.

2. Tecnologia Web
2.1 HISTRICO DA INTERNET E DA WEB
A Internet surgiu como resposta preocupao do governo americano, durante a guerra
fria, de como deveria ser a comunicao militar caso ocorresse uma guerra nuclear
(RUTHFIELD, 2001). Numa situao como essa, as tecnologias tradicionais no
funcionariam, pois um sistema centralizado poderia ser facilmente destrudo
(RUTHFIELD, 2001). Havia, portanto, a necessidade do desenvolvimento de novas
tecnologias.
Em 1972, um setor do departamento de defesa americano fez a primeira demonstrao
pblica da ARPANet, uma rede de computadores que foi a precursora da Internet
(LEINER, 1997, p.103) e, em 1983, a tecnologia da ARPANet foi substituda por uma
tecnologia chamada Transmission Control Protocol/Internet Protocol (TCP/IP), a qual
era mais adequada para redes com grandes quantidades de servidores (RUTHFIELD,
2001). Muitos consideram essa data com sendo o incio oficial da Internet
(RUTHFIELD, 2001).
Ao longo das ltimas dcadas, vrias tecnologias foram desenvolvidas na tentativa de
permitir a comunicao entre computadores. Entretanto, foi a Internet que atingiu este
objetivo com mais sucesso, tornando-se a maior rede de computadores do mundo.
Atualmente, provavelmente todas as plataformas tecnolgicas permitem a utilizao dos
padres da Internet.
A Internet interliga vrias redes e funciona de forma descentralizada, ou seja, no h
controle global no nvel das operaes (LEINER, 1997, p.104). Para pertencer Internet
cada integrante (computador servidor) arca basicamente com os custos de suas
operaes tornando-os relativamente baixos. Alm disso, nenhuma mudana interna
necessria para que uma rede seja conectada Internet.
A Internet pode ser considerada uma infraestrutura genrica de comunicao sobre a
qual novas aplicaes podem ser concebidas (LEINER, 1997, p.103). Ao longo do
tempo, vrios servios (como o e-mail, a transferncia de arquivos e o acesso remoto),
foram acrescentados aos padres da Internet. No final da dcada de 80 e incio da
dcada de 90 um novo servio foi criado: a World Wide Web.

2.2 DEFINIO DE TECNOLOGIA WEB

A World Wide Web, WWW ou simplesmente Web, foi desenvolvida para ser um pool
do conhecimento humano, que permitisse colaboradores em locais distantes
compartilhar idias e todos os aspectos de um projeto comum (BERNERS-LEE et. al.,
1994, p.76). Ela deveria permitir que documentos desenvolvidos separadamente
pudessem ser ligados facilmente e visualizados em um mesmo ambiente sem que isso
exigisse grandes mudanas nem que possveis mudanas precisassem ser feitas de
forma centralizada (BERNERS-LEE et. al.,1994, p.76).

10

A tecnologia Web pode ser definida como um sistema de padres que inclui:
(1) Padro de endereamento: todos os recursos da Web tm um endereo nico e
podem ser localizados de qualquer lugar, independente da plataforma onde o recurso
resida. Cada endereo chamado de URL (Uniform Resourse Locator).
(2) Padro de comunicao: a tecnologia Web utiliza um protocolo de comunicao, ou
seja, uma linguagem que permite a solicitao e obteno de recursos da Web. Este
protocolo, chamado HTTP (Hypertext Transfer Protocol), permite a busca de recursos
em diversos formatos e no somente de hipertexto como o nome sugere.
(3) Padres de estruturao das informaes: o padro inicial da tecnologia Web para
apresentao das informaes estava baseado em uma linguagem de marcao chamada
HTML (Hypertext Markup Language). Esta linguagem define principalmente elementos
para a visualizao de informaes. Entretanto, uma extenso da tecnologia Web foi a
definio da metalinguagem chamada XML (Extensible Markup Language) a qual
permite definir de forma extensvel como uma informao pode ser estruturada.
Neste trabalho, diferenciaremos o termo Web de tecnologia Web. Enquanto a tecnologia
Web ser definida como o conjunto de padres para a comunicao, endereamento e a
apresentao de informaes, a Web ser definida como o conjunto formado por todas
as informaes e servios (recursos computacionais) que podem ser recuperados ou
utilizados atravs da tecnologia Web.

2.3 A TECNOLOGIA WEB

INFORMAES

COMO

PLATAFORMA

PARA

DIVULGAO

DE

A tecnologia Web funciona utilizando o paradigma cliente-servidor. Neste modelo de

computao, o processamento dividido, conforme o nome sugere, entre clientes e
servidores. Os clientes solicitam servios os quais so executados pelos servidores.
Na Web, os clientes so softwares genricos, chamados de navegadores, que
proporcionam a interface com o usurio. Os navegadores entendem os padres da
tecnologia Web e so responsveis por transformar as solicitaes dos usurios em
pedidos aos servidores Web. Estes ltimos recuperam os recursos (pginas) solicitados e
os retornam aos clientes, que os interpretam, formatam e disponibilizam aos usurios.
Para recuperar uma pgina, os usurios digitam seu endereo (URL) e o navegador
encaminha a solicitao ao servidor Web. Portanto, para buscar uma pgina s preciso
saber o seu endereo. Alm disso, as pginas podem ser ligadas entre si, permitindo que
o usurio navegue atravs de vrias pginas. Cada pgina pode conter recursos, tais
como botes, figuras ou textos, os quais permitem que, quando acionados, uma nova
pgina seja solicitada. O navegador o responsvel por converter a ativao de um
recurso em uma solicitao de pgina.

11

Embora cada pgina Web possa ter ligaes para qualquer outra, comumente as pginas
so agrupadas em conjuntos que representam informaes correlatas e ficam
armazenados em um mesmo servidor Web. Tais conjuntos de pginas so chamados de
Web Sites.
Outra caracterstica da tecnologia Web que a comunicao entre o navegador e o
servidor Web foi concebida para funcionar sem a manuteno de conexes, ou seja,
aps o retorno de uma pgina, o servidor Web no guarda informao sobre quem
solicitou nem qual pgina foi retornada. Portanto, cada solicitao ao servidor
independente das demais.
A Figura 2 ilustra o funcionamento da tecnologia Web para acesso a um Web Site
tradicional.

Figura 2 Funcionamento da tecnologia Web para acesso a um Web Site tradicional

No modelo de funcionamento descrito acima, as pginas Web so documentos

eletrnicos estticos que permitem basicamente a divulgao de informaes. Para
disponibilizar novas pginas s preciso incluir o arquivo correspondente no sistema de
arquivos que ela j pode ser consultada de qualquer lugar com acesso Internet. Este
modelo de acesso simples informao e de escala global que fez com que a tecnologia
Web tivesse tanta aceitao (BIEBER et.al., 1997, p.31).

2.4 A TECNOLOGIA WEB COMO PLATAFORMA DE ACESSO A SISTEMAS DE

INFORMAO
Ao longo do tempo, novos recursos foram acrescentados tecnologia Web. Com eles
tornou-se possvel:
enviar, junto com uma solicitao, informaes ao servidor;
guardar estado entre duas chamadas ao servidor;
realizar processamentos simples no prprio navegador;

12

desviar uma solicitao para que possa ser processada em um aplicativo no servidor,
possibilitando a montagem dinmica de pginas Web; e,
efetuar comunicaes seguras entre os clientes (navegadores) e os servidores.
Os novos recursos permitem que a tecnologia Web seja utilizada como infraestrutura de
acesso a sistemas de informao. Dessa forma, os usurios interagem com os sistemas
atravs dos prprios navegadores Web, fornecendo informaes aos servidores, os quais
processam e geram as respostas (pginas Web) dinamicamente. Assim, a troca de
informaes entre usurios e Web bidirecional de forma similar ao que ocorre com os
sistemas de informao baseados nas tecnologias tradicionais.
A Figura 3 ilustra o funcionamento da tecnologia Web como plataforma para acesso a
sistemas de informao.

Figura 3 Utilizao da tecnologia Web como plataforma de acesso a outros SI

Uma limitao para a utilizao da tecnologia Web, conforme mostrado acima, que ela
faz a intermediao entre o navegador e o aplicativo, mas caso o aplicativo precise se
comunicar com outro sistema ele deve utilizar uma tecnologia tradicional. Para
contornar tal restrio, novas extenses da tecnologia foram recentemente
desenvolvidas, permitindo que seja usada tambm como infraestrutura de comunicao
entre sistemas.
A Figura 4 ilustra o funcionamento da tecnologia Web como plataforma de
comunicao entre sistemas.

13

Figura 4 Sistema de Informao baseado na tecnologia Web

Os sistemas de informao podem trocar informaes com quaisquer outros sistemas

disponveis na Web, permitindo, por exemplo, que algumas funes (ou mdulos) de
um sistema sejam desenvolvidas e processadas em uma organizao e outras funes
(ou mdulos) sejam desenvolvidas e processadas em outros lugares e por outras
organizaes. Em outras palavras, a tecnologia Web passa a ser a infraestrutura de
comunicao tanto entre pessoas e sistemas, como tambm entre os prprios sistemas.
Isto elimina diversas barreiras at ento existentes para a interligao entre sistemas de
informao e tambm entre organizaes.
Para descrever as dimenses da evoluo da tecnologia Web, TRAVIS (2000, p.133)
apresentou Figura 5, mostrada a seguir:

14

Figura 5 Evoluo da Tecnologia Web (TRAVIS, 2000, p. 133)

Ainda difcil prever todos os impactos que a tecnologia Web e suas extenses tero
sobre os sistemas de informao e sobre as organizaes de forma geral. Um aspecto a
ser considerado refere-se s fronteiras dos sistemas. Enquanto nas tecnologias anteriores
a fronteira de cada sistema estava bem delimitada, no ambiente Web um sistema tem a
possibilidade de utilizar mdulos espalhados por vrios lugares e ser gerenciados de
forma descentralizada, alm do fato de que cada mdulo tambm pode ser utilizado por
outros sistemas, inclusive de outras organizaes.
Esse ambiente novo permite que diversas questes sejam levantadas. Tais questes vo
desde como deve ser o gerenciamento desses sistemas distribudos atravs de vrias
organizaes at como comercializar um servio oferecido atravs da Web. Discutir tais
questes est fora do escopo deste trabalho. Podemos perceber, entretanto, que a
tecnologia Web est causando, e poder causar ainda mais, grandes mudanas na forma
como muitas organizaes funcionam e que a revoluo que a tecnologia Web ir causar
nas organizaes provavelmente est apenas comeando.

2.5 A TECNOLOGIA WEB COMO UM SISTEMA HIPERMDIA

Muitas pessoas associam hipermdia apenas World Wide Web (BIEBER et. al., 1997,
p.32). Entretanto, o conceito de hipermdia foi descrito pela primeira vez em 1945 e sua
terminologia foi definida nos anos 60 (BIEBER & ISAKOWITZ, 1995, p.28). A
hipermdia , portanto, bem mais antiga que a World Wide Web.
Dentro da rea de hipermdia alguns termos bastante utilizados so o hipertexto, a
multimdia e a hipermdia. Hipertexto pode ser entendido como uma rede de
componentes (blocos de texto) relacionados atravs de um conjunto de ligaes e
ancorados em componentes origem e destino (HARDMAN, BULTERMAN &
ROSSUM, 1994, p.52). Em outras palavras, um hipertexto composto de fragmentos
de informao e relacionamentos entre eles (STOTTS & FURUTA, 1989, p.4). Ele
proporciona uma estrutura de controle que apia um caminho elegante de navegao
atravs de dados (HARDMAN, BULTERMAN & ROSSUM, 1994, p.50).

15

A multimdia proporciona uma riqueza nos tipos de dados que facilita a flexibilidade
na expresso da informao (HARDMAN, BULTERMAN & ROSSUM, 1994, p.50),
ou seja, a multimdia permite que um bloco de informao seja composto por outras
mdias alm de texto, como som, vdeo e imagem.
A hipermdia , por outro lado, a extenso simples e natural de multimdia e hipertexto
(HARDMAN, BULTERMAN & ROSSUM, 1994, p.50), sendo a juno dos dois
conceitos. Assim, a hipermdia aplica conceitos de hipertexto a mltiplas mdias
(BIEBER et al., 1997, p.33)2.
Podemos diferenciar o conceito de sistema hipermdia do conceito de aplicao
hipermdia (ISAKOWITZ, STOHR & BALASUBRAMANIAM, 1995, p.35; BIEBER
et al., 1997, p.36). Um sistema hipermdia determina a estrutura interna de um ambiente
que oferece caractersticas de hipermdia e sobre o qual podem ser desenvolvidas
aplicaes hipermdia.
De forma geral, a hipermdia pode ser definida como a cincia dos relacionamentos.
Ela se preocupa em estruturar, apresentar e dar aos usurios acesso direto ao contedo e
s interconexes dentro do domnio de um problema (BIEBER & ISAKOWITZ, 1995,
p.28).
Um campo crescente de pesquisa o que procura adicionar caractersticas da hipermdia
aos sistemas de informao tradicionais, ou seja, adicionar funcionalidade hipermdia.
O enfoque da funcionalidade hipermdia foca na incorporao de caractersticas de
hipermdia em sistemas de software assim como para oferecer a seus usurios um
caminho associativo de acessar, analisar e organizar a informao (BIEBER et. al.,
1997, p.35). Como a hipermdia encoraja autores a estruturar informao como uma
rede associativa de ns e ligaes (BIEBER & ISAKOWITZ, 1995, p.33) ela permite
aos leitores acessar informao na ordem mais apropriada para seus propsitos
(BIEBER & ISAKOWITZ, 1995, p.33) aumentando a compreenso (BIEBER &
ISAKOWITZ, 1995, p.33). Em outras palavras, os benefcios de adicionar
funcionalidade hipermdia s aplicaes de sistemas de informao so que a
hipermdia proporciona acesso navegacional, contextual para ver informao e que
representa conhecimento em uma forma relativamente prxima das estruturas
cognitivas organizacionais que as pessoas usam. Assim, a hipermdia apia
entendimento (BIEBER et. al., 1997, p.35).
Este campo tem sido impulsionado pelo sucesso da tecnologia Web, uma vez que ela
pode ser considerada um sistema hipermdia (ANDERSON, 1997, p.157; NRNBERG
& ASHMAN, 1999; STERBYE & WIIL, 1996) sendo a World Wide Web o maior
sistema distribudo de hipermdia em uso (ANDERSON, 1997, p.157).

Neste trabalho, utilizaremos apenas o termo hipermdia, independente do fato da aplicao utilizar
vrias mdias ou apenas textos.

16

A hipermdia define uma srie de conceitos tais como ns, ligaes e estruturas de
navegao que, embora melhorem as aplicaes, trazem novos desafios e aumentam a
complexidade dos sistemas de informao. Assim, ao utilizar a tecnologia Web deve-se
considerar de que forma os conceitos de hipermdia sero estruturados e empregados.

17

3. Sistemas de Informao
3.1 DEFINIO DE SISTEMAS DE INFORMAO
Um sistema de informao (SI) pode ser definido em termos de duas perspectivas: uma
relacionada sua funo e outra sua estrutura (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p.11).
Da perspectiva estrutural, um SI consiste em uma coleo de pessoas, processos,
dados, modelos, tecnologia e linguagem parcialmente formalizada, formando uma
estrutura coesa que serve a algum propsito ou funo (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p.11).
Da perspectiva funcional, um SI uma mdia tecnologicamente implementada para o
propsito de gravar, armazenar e disseminar expresses lingsticas assim como apoio
ao desenvolvimento de inferncias (HIRSCHHEIM, KLEIN & LYYTINEM, 1995,
p.11). Ao executar estas funes bsicas, os sistemas de informao facilitam a criao
e a troca de significados que servem a propsitos socialmente definidos tais como
controle, entendimento e argumentao (por exemplo, formulao e justificativa de
reivindicaes) (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p.11).
Podemos notar que nas duas perspectivas de SI as pessoas esto includas dentro das
fronteiras, o que significa que os servios proporcionados por um sistema de
informao em parte dependem das capacidades e contribuies das pessoas
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p.11). Em outras palavras, as pessoas
tm um papel fundamental para permitir que os SI atinjam seus propsitos.

3.2 A ORGANIZAO E OS SISTEMAS DE INFORMAO

Os SI e a tecnologia da informao tm grande importncia nas organizaes atuais.
Eles podem alterar os processos empresariais de vrias formas. Algumas delas so:
Aumentando a capacidade das pessoas, atravs do fornecimento de informaes,
ferramentas e treinamento (ALTER, 1996);
Captando informao dos processos com o objetivo de compreenso
(DAVENPORT, 1994, p.60);
Apoiando o trabalho de gerenciamento (ALTER, 1996) e melhorando a anlise da
informao e tomada de deciso (DAVENPORT, 1994, p.60);
Eliminando desperdcios: eliminando papis desnecessrios, reutilizando o trabalho
(por exemplo, modelos de cartas), eliminando etapas de trabalho desnecessrias e
atrasos, eliminando variaes desnecessrias em procedimentos e sistemas e/ou
eliminando atividades contra-produtivas (ALTER, 1996);
Estruturando o trabalho de forma a promover as melhores prticas: melhorando a
manipulao de dados e o trabalho geral de escritrio, apoiando fluxo de trabalho e
permitindo que o trabalho ocorra ininterruptamente (24x7) (ALTER, 1996);

18

Substituindo ou reduzindo a mo de obra humana em um processo (DAVENPORT,

1994, p.60), seja automatizando as interfaces com os clientes, automatizando o
trabalho de projeto e/ou automatizando a manufatura (ALTER, 1996);
Integrando atravs de funes e de organizaes: ligando fornecedores e clientes
atravs da troca eletrnica de dados (EDI), apoiando o processo de planejamento
organizacional, colaborando no projeto de produtos e atravs de manufatura
integrada por computador (ALTER, 1996) e melhorando a coordenao entre tarefas
e processos (DAVENPORT, 1994, p.60);
Modificando a seqncia de processo ou possibilitando o paralelismo
(DAVENPORT, 1994, p.60);
Permitindo a monitorao rigorosa da situao e objetos do processo
(DAVENPORT, 1994, p.60);
Permitindo a coordenao de processos distncia (DAVENPORT, 1994, p.60);
Permitindo a eliminao de intermedirios em um processo (DAVENPORT, 1994,
p.60).
Os SI e a tecnologia da informao podem afetar a estrutura da organizao, sua
estratgia, suas receitas e despesas e os indivduos que trabalham nela (LUCAS, 1997,
p.67) alm de poder promover vrios graus de mudana organizacional. LAUDON &
LAUDON (1998, p.391) classificam os impactos da Tecnologia da Informao (TI) nas
organizaes em quatro tipos:
Automao: a forma mais comum de mudana organizacional, em que
procedimentos manuais so automatizados;
Racionalizao de procedimentos: padronizao de procedimentos operacionais,
eliminando gargalos bvios de forma que a automao possa tornar os
procedimentos operacionais mais eficientes;
Reengenharia do negcio: onde os processos so analisados, simplificados e
redesenhados. A Reengenharia envolve repensar radicalmente o fluxo do trabalho e
os processos de negcio usados para produzir produtos e servios com a idia de
reduzir radicalmente os custos do negcio;
Mudana de paradigma: radical re-concepo da natureza do negcio e a natureza
da organizao.
De acordo com os autores, o risco do impacto proporcional ao benefcio resultante.
Assim, o impacto da TI atravs da automao de processos o que apresenta menos
riscos, mas o que proporciona menos benefcios (LAUDON & LAUDON, 1998, p.391).
O risco aumenta em cada grau de mudana organizacional at a mudana de paradigma,
onde ele mais alto, assim como os possveis benefcios (LAUDON & LAUDON,
1998, p.391).
Embora possa habilitar praticamente todos os tipos de mudanas citados anteriormente,
a tecnologia Web apresenta grande potencial para habilitar a reengenharia e a mudana
de paradigma nos negcios, pois cria novas oportunidades, tais como comrcio
eletrnico do tipo negcio-para-consumidor (B2C), alterao nos negcios de

19

intermediao e criao de negcios virtuais sendo, portanto, uma tecnologia de

grande relevncia para as organizaes atuais.

3.3 FORMAS DE CLASSIFICAO DE SISTEMAS DE INFORMAO

A forma como os sistemas de informao so concebidos, desenvolvidos, implantados e
utilizados varia conforme suas caractersticas, no existindo uma receita universal
para abord-los. Assim, de grande utilidade a definio de critrios para sua
classificao. Como existem vrias formas para classificar os SI, neste trabalho
utilizaremos apenas algumas, mas que no so exaustivas nem incluem todos os tipos de
SI. Alm disso, muitos sistemas podem ser classificados em mais de um tipo. A
classificao , portanto, apenas um guia para o entendimento.
Uma forma de classificar os SI diz respeito ao seu escopo, ou seja, se ele envolve
apenas uma ou mais organizaes. Os sistemas que envolvem vrias organizaes, tais
como clientes e fornecedores, so chamados sistemas interorganizacionais.
Outra forma de classific-los atravs do papel que desempenham nas operaes e
administrao de um negcio. OBRIEN (2001, p. 28) props uma classificao sob tal
critrio, descrita na Figura 6.

Figura 6 Classificao de SI conforme o propsito (OBRIEN, 2001, p. 28)

Os SI que servem de apoio s operaes tambm podem ser classificados conforme a

funo organizacional apoiada e a Figura 7 ilustra alguns tipos propostos por OBRIEN
(2001, p. 173).

20

Figura 7 Classificao dos SI de apoio s operaes conforme a funo organizacional afetada

(OBRIEN, 2001, p. 173)

Uma outra forma de classificar os SI atravs do tipo de deciso que apiam e o nvel
hierrquico a que se destinam. A Tabela 1 mostra a matriz proposta por GORRY &
MORTON (apud LUCAS, 1997, p.43) para classific-los atravs de tais critrios:
Classificao

Controle operacional Controle gerencial

Estruturada

Processamento
de
pedidos; contas a
pagar
Controle de estoque;
planejamento
da
produo
Gerenciamento de Gerenciamento
caixa
pessoal

Semi-estruturada

No estruturada

Planejamento
estratgico
Oramentos;
Localizao
de
relatrios pessoais
plantas; mix de
modos de transporte
Anlise de varincia Introduo de novo
produto
de Planejamento
P&D

para

Tabela 1 Estrutura para classificao de SI (GORRY & MORTON apud LUCAS, 1997, p.43)

3.4 OS SISTEMAS DE INFORMAO BASEADOS NA TECNOLOGIA WEB

3.4.1 As geraes tecnolgicas dos Sistemas de Informao
Para PRESS (1999, p.13), se considerarmos os sistemas de processamento em lote, os
sistemas de compartilhamento de tempo e as aplicaes cliente-servidor como as trs
primeiras geraes de processamento de dados empresariais, a quarta gerao a dos

21

Sistemas de Informao baseados na Web ou SIW (Web-based Information Systems WIS) (ISAKOWITZ, T.; BIEBER, M.; VITALI, F.,1998, p.78-80) como tm sido
freqentemente chamados.
Cada gerao tecnolgica de sistemas de informao tem sido marcada por algumas
evolues da tecnologia da informao. A primeira surgiu com os computadores
voltados para o processamento de dados empresariais e foi marcada pela utilizao de
cartes perfurados para processamento off-line (PRESS, 1999, p.13).
Com a evoluo da tecnologia de terminais remotos conectados a sistemas que
utilizavam o compartilhamento de tempo, surgiu a segunda gerao de sistemas de
informao, onde o processamento era feito on-line (PRESS, 1999, p.13).
A popularizao dos microcomputadores e das redes de computadores permitiu o
surgimento da terceira gerao de sistemas de informao, a dos sistemas clienteservidor, onde o processamento era dividido entre microcomputadores clientes e
servidores conectados atravs da rede.
A universalizao do acesso s redes de computadores e a utilizao de sistemas de
padres abertos para a comunicao esto impulsionando o crescimento da chamada
quarta gerao dos sistemas de informao, a dos sistemas de informao baseados na
tecnologia Web. Vrias denominaes tm sido dadas a tais sistemas, tais como: Web
Sites, WBIS (Web-based Information Systems), WIS (Web Information Systems),
Sistemas Web, Aplicaes Web e Sistemas de Informao Web. Neste trabalho, chamlos-emos de Sistemas de Informao baseados na Tecnologia Web (SIW).

3.4.2 Definio de Sistemas de Informao baseados na tecnologia

Web
Os SIW apresentam algumas diferenas com relao aos sistemas tradicionais. Uma
delas diz respeito ao modo de acesso informao. Em aplicaes de bancos de dados
tradicionais, o modo de acesso obtido atravs de consultas, ou seja, o usurio formula
uma pergunta em alguma linguagem de consulta, descrevendo o dado que ele deseja
recuperar, e o sistema recupera e mostra o dado. O usurio pode ento processar este
dado de alguma forma, e eventualmente ordenar outra consulta para obter mais
informao. Em muitos casos, esta seqncia de etapas executada por um programa
aplicativo, no pelo ser humano (SCHWABE, ROSSI & GARRIDO, 1998, p. 3).
O modo de acesso informao nos SIW feito atravs da caracterstica intrnseca da
hipermdia que a navegao, ou seja, independente de como um usurio chegou a
uma pgina ele normalmente tem a opo de acesso s pginas ligadas pgina atual;
selecionando uma ligao especfica, ele far com que a pgina apontada pela ligao
seja exibida; este processo pode ser repetido indefinidamente (SCHWABE, ROSSI &
GARRIDO, 1998, p. 3).

22

Outra diferena com relao aos sistemas convencionais que enquanto estes
apresentam restries quanto ao acesso, os SIW utilizam o conceito de acesso universal.
Acesso universal significa que voc pe algo na Web e voc pode acess-lo de
qualquer lugar; no importa qual sistema de computador voc esteja rodando, ele
independente de onde voc est, que plataforma voc est rodando, ou qual sistema
operacional voc comprou (...) (BERNERS-LEE, 1996).
Tambm existem algumas diferenas entre os sistemas de informao baseados na
tecnologia Web e os Web Sites tradicionais. Enquanto tais Web Sites permitem apenas
que os usurios possam recuperar informaes, os SIW so projetados para que tambm
seja possvel alter-las, ou seja, nos SIW os usurios podem processar dados de negcio
interativamente (TAKAHASHI, 1998, p. 103).
Os Web Sites convencionais so projetados para usurios annimos, oferecendo
normalmente somente uma viso para todos (TAKAHASHI, 1998, p. 103). Em
contraste, os SIW buscam atender uma comunidade identificada de usurios, os quais
tm tarefas e requisitos especficos e, freqentemente, precisam de vises especficas
para atingir suas tarefas.
Os SIW apiam trabalho e, geralmente, so altamente integrados com outros sistemas
no Web, tais como bancos de dados e sistemas de processamento de transaes
(ISAKOWITZ, STOHR & BALASUBRAMANIAM,1995, p. 79).
A estrutura de navegao de um Web Site tradicional projetada principalmente para
facilitar a busca e o entendimento de informaes, enquanto a estrutura de navegao
dos SIW projetada para apoiar fluxo de trabalho especfico (TAKAHASHI, 1998, p.
103).
Outra diferena diz respeito estruturao da informao. A estrutura de uma
informao refere-se ao fato de poder identificar claramente os elementos que a
compem. Uma figura ou um texto formado por apenas uma grande frase podem ser
considerados como tipos de informao no estruturada. Se dividirmos o texto em
captulos, tpicos e pargrafos a informao passa a ter uma estrutura mais definida. No
extremo, podemos segmentar a informao em pedaos atmicos. Para exemplificar,
consideremos um cadastro de pessoas em um banco de dados onde cada pessoa um
registro do banco, e onde as informaes esto segmentadas em conceitos tais como
data de nascimento, primeiro nome, sobrenome, RG, local de nascimento e outros.
Neste caso, temos uma informao altamente estruturada.
Considerando esta definio para estrutura de informao, podemos dizer que os Web
Sites utilizam basicamente informao no estruturada ou semi-estruturada, enquanto os
SIW esto baseados principalmente em modelos de dados estruturados representando
relacionamentos entre pedaos de informao (TAKAHASHI, 1998, p. 103). A forma
como esto estruturados os elementos que compem uma pgina em um Web Site
convencional pouco relevante para sua recuperao, uma vez que ela esttica.

23

Assim, podemos dizer que em um Web Site convencional a informao pouco

estruturada e sua unidade bsica a pgina.
Os SIW, por outro lado, utilizam principalmente pginas montadas dinamicamente,
exigindo que os pedaos da informao sejam alocados, no momento de montagem,
a lugares pr-definidos dentro da pgina. Assim, tanto a pgina deve ter sua estrutura
bem definida como a informao que ser montada deve estar estruturada. Tipicamente,
esta informao vem de um sistema de banco de dados ou de algum outro sistema.
ISAKOWITZ, STOHR & BALASUBRAMANIAM (1995, p. 36) utilizaram duas
caractersticas para classificar as aplicaes hipermdia: a estrutura da informao e a
volatilidade da informao, gerando a Tabela 2.

Alta
Estrutura da
Informao
Baixa

Volatilidade da informao
Baixa
Alta
Por.Ex: Quiosques
Interface
para
Sistema
Gerenciador de Bancos de
Dados (SGBD), catlogo de
produtos
Trabalho literrio
Servio de notcias multimdia

Tabela 2 Estrutura para classificao das aplicaes hipermdia (Adaptado de ISAKOWITZ,

STOHR & BALASUBRAMANIAM, 1995, p. 36)

Tipicamente, a maior parte das funes nos SIW lida com alta estruturao e
volatilidade. Entretanto, um SIW pode conter tanto informaes de baixa volatilidade
quanto baixa estruturao.
Nos Web Sites tradicionais as ligaes entre as pginas apresentam, muitas vezes,
referncias a pginas que no existem mais, as chamadas ligaes quebradas. Nos
SIW a integridade das ligaes mais rigorosa, principalmente para as tarefas de
misso crtica (TAKAHASHI, 1998, p. 103).
THRING, HANNEMANN & HAAKE (1995, p. 57) distinguem dois tipos de
aplicaes hipermdia. O primeiro o das aplicaes direcionadas aos que desejam
navegar atravs de grandes espaos de informao, reunindo conhecimento ao longo do
caminho (THRING, HANNEMANN & HAAKE, 1995, p. 57). O outro o das
aplicaes mais direcionadas para a soluo de problemas, sendo bastante estruturadas e
talvez mais restritivas (THRING, HANNEMANN & HAAKE, 1995, p. 57). As
aplicaes do primeiro tipo aparecem como bancos de dados navegveis ou
hyperbases que podem ser livremente exploradas pelo leitor. Em contraste, aplicaes
do segundo tipo tomam a forma de documentos eletrnicos ou hiperdocumentos que
guiam intencionalmente os leitores atravs de um espao de informao, controlando
sua explorao ao longo da linha de uma estrutura pr-definida (THRING,
HANNEMANN & HAAKE, 1995, p. 57). Os Web Sites tradicionais geralmente so
aplicaes do primeiro tipo, enquanto os SIW so tipicamente do segundo.

24

SCHWABE, ROSSI & GARRIDO (1998, p. 2) descrevem um SIW como um sistema

hbrido que concebido para ser parte de uma equipe homem-mquina na soluo de
um problema. Segundo os autores, em um SIW parte da tarefa executada pelo
computador e parte pelo ser humano. A fronteira entre a parte executada pelo
computador e a parte executada pelo ser humano mvel: em um extremo ela coincide
com a dos sistemas tradicionais, onde o computador faz quase todo o processamento, e
no outro extremo ela coincide com os Web Sites convencionais, onde o computador
somente armazena informao e a apresenta ao ser humano, o qual faz a tarefa.
Segundo SCHWABE, ROSSI & GARRIDO (1998, p. 2) um SIW pode ser definido
como:
um conjunto de sites WWW sob a mesma administrao, armazenando
informao para ser usada criada, acessada e modificada por alguma
comunidade identificada de usurios.
Por restringir o SIW ao conjunto de Web Sites sob a mesma administrao, a definio
acima ajuda delimitar as fronteiras do sistema. Isto porque, comum em um SIW haver
referncias a pginas de outros Web Sites e, considerando que tais pginas ainda podem
referenciar outras, se todas fossem includas como parte do sistema seu escopo tenderia
a ser todo o contedo disponvel na Web.
Neste trabalho, consideraremos esta definio para SIW, apenas ressaltando que ela
inclui apenas o aspecto da tecnologia do sistema e que, conforme citado no item 3.1, os
sistemas de informao incluem tambm as pessoas, os processos, modelos e linguagem
parcialmente formalizada.

3.4.3 Aplicaes de Sistemas de Informao baseados na tecnologia

Web
Antes de classificarmos as aplicaes de SIW definiremos dois termos bastante
utilizados atualmente: Intranet e Extranet. Uma Intranet uma rede que utiliza os
padres da Internet, mas que est dentro dos limites de uma organizao, ou seja, uma
rede interna acessada por um grupo restrito de pessoas de uma nica organizao, que
possivelmente est ligada Internet e que tem mecanismos de proteo com relao aos
dados que entram e saem para a Internet.
Uma Extranet uma rede que interliga um grupo de pessoas pertencentes a vrias
organizaes (em geral parceiros de negcio) e que utiliza a prpria Internet como
infra-estrutura de comunicao. Ela exige identificao para utilizao de seus servios
e tem mecanismos de proteo com relao aos dados que entram e saem para a
Internet.
Do ponto de vista de uma organizao, a Internet todo o conjunto de servios que so
oferecidos fora do contexto das Intranets e Extranets que ela contm.

25

Na Figura 8, KALAKOTA & WHINSTON apud OBRIEN (2001, p.12) ilustram as

funes das Intranets e Extranets dentro das organizaes.

Figura 8 A Internet e as Organizaes (Adaptado de KALAKOTA & WHINSTON apud OBRIEN,

2001, p. 12)

Segundo ISAKOWITZ, BIEBER & VITALI (1998, p.78) as aplicaes de sistemas de

informao baseados na tecnologia Web podem ser classificadas em quatro grandes
tipos:
(1) Sistemas de apoio ao trabalho interno: tipicamente, utilizam uma Intranet como
infra-estrutura de comunicao. Substituem ou servem de interface de acesso a sistemas
de informao j existentes nas tecnologias tradicionais.
(2) Sites de presena na Web: ferramentas de marketing utilizadas para alcanar
consumidores fora da empresa.
(3) Sistemas de apoio ao Comrcio Eletrnico: sistemas que apiam interaes com os
consumidores como compras on-line. Tipicamente, comunicam-se com sistemas j
existentes em outras tecnologias, como sistemas de processamento de pedidos e
sistemas de controle de estoques.
(4) Sistemas de apoio ao Comrcio entre Empresas: sistemas que apiam interaes
com outras empresas. Tipicamente, utilizam uma Extranet como infra-estrutura de

26

comunicao e comunicam-se com outros sistemas j existentes em outras tecnologias,

como processamento de pedidos e sistemas de controle de estoques.
Uma outra forma de classificar as aplicaes de SIW considera a dinamicidade do
sistema. Podemos definir dinamicidade como o tempo de ligao entre o contedo da
base de informao e as pginas da aplicao entregues ao cliente, as quais podem ser
estticas quando as pginas so computadas no tempo da definio da aplicao e so
imutveis durante a utilizao da aplicao; ou dinmicas, quando as pginas so
criadas no momento desejado e com contedo fresco (FRATERNALI, 1999, p. 232).
A dinamicidade pode envolver somente o contedo (a navegao e a apresentao so
estticas) ou pode tambm escalar para a apresentao e a navegao (FRATERNALI,
1999, p. 232).
Em um extremo, a aplicao pode estar baseada em informaes, apresentao e
navegao estticos. Neste caso, a aplicao Web apenas recupera documentos estticos
e envia aos usurios conforme solicitado, no tendo nenhuma capacidade de
processamento com relao informao. Tipicamente, o nico tipo de processamento
feito a busca de palavras dentro dos documentos estticos, no sendo guardado
nenhum estado da aplicao. Uma aplicao deste tipo comporta-se como colees de
hiper-documentos que deram origem Web.
No outro extremo, a aplicao inteira pode utilizar mecanismos de processamento
dinmico, tanto para as informaes, quanto para a apresentao e navegao.
Tipicamente, as informaes esto embutidas em tecnologias de bancos de dados. Neste
caso, a aplicao Web processa cada solicitao de pgina e monta as respostas no
momento da solicitao, conforme os parmetros recebidos e o estado da aplicao.
Uma aplicao deste tipo se comporta como um sistema de informao clssico, como
por exemplo, uma aplicao empresarial voltada para negcios.
A maior parte das aplicaes de SIW fica entre estes dois extremos. Enquanto no incio
da Web as aplicaes do extremo de informao esttica tiveram um grande
crescimento, atualmente muitas aplicaes com informao, navegao e apresentao
dinmicas esto sendo desenvolvidas.

27

4. Desenvolvimento de Sistemas de Informao (DSI)

Um aspecto crtico dos sistemas de informao o seu desenvolvimento. O processo de
desenvolvimento de sistemas de informao (ou DSI) envolve alta tecnologia e lida com
um fenmeno complexo. Assim, os conceitos ligados a esse processo, as estratgias
possveis, as metodologias, as tcnicas e os modelos utilizados so de grande
importncia para o campo de sistemas de informao.
Neste captulo, discutiremos os principais conceitos ligados ao processo de DSI.

4.1 DEFINIO DE DSI

Segundo LAUDON & LAUDON (1998, p. 401), o desenvolvimento de sistemas referese a todas as atividades que levam soluo de um problema ou ao atendimento de uma
oportunidade de negcio atravs de um sistema de informao. Ele fundamentalmente
um tipo estruturado de resoluo de problemas (VESSEY & GLASS, 1998, p. 99;
LAUDON & LAUDON, 1998, p. 401).
Ao longo do desenvolvimento o problema transformado em uma soluo baseada em
computadores (VESSEY & GLASS, 1998, p. 99). Ele utiliza as tecnologias da
informao (computadores e telecomunicaes) para resolver e tratar problemas
relacionados ao gerenciamento e coordenao das organizaes modernas
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995).
O processo de desenvolvimento sempre comea com uma percepo informal e
subjetiva de uma necessidade e sempre termina com um modelo formal e objetivo de
computao (o software) (BLUM, 1994, p. 84).
Para HIRSCHHEIM, KLEIN & LYYTINEM (1995, p. 15) o desenvolvimento de
sistemas de informao um processo de mudana do que eles chamaram de sistema
objeto. Sistema objeto o fenmeno percebido pelos membros do grupo de
desenvolvimento, o qual pode ser visto como uma realidade independente do
observador ou como algo construdo socialmente atravs da percepo (sense-making) e
convenes institucionalizadas (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 15).
Ao longo do processo de mudana, os objetos, as propriedades e seus relacionamentos
no sistema objeto adquirem significado (HIRSCHHEIM, KLEIN & LYYTINEM, 1995,
p. 16).
Em geral, dependendo da percepo do grupo de pessoas envolvidas no processo, mais
de um sistema objeto pode ser identificado, pois as percepes dos membros de uma
equipe no necessariamente coincidem, levantando a questo de como lidar com vises
ambguas e at conflitantes (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 16)
desses sistemas objetos. Esta uma das razes pelas quais o DSI considerado um
processo complexo.

28

O processo de mudana caracterizado pela intencionalidade, intersubjetividade e

incerteza (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 16). Ele intencional, uma
vez que resultado de uma ao deliberada do grupo de desenvolvimento, ou seja,
uma mudana planejada. A intersubjetividade significa que o processo de mudana est
fundamentado no reconhecimento do fenmeno por mais de um participante e no
entendimento mtuo e coordenao das aes dos participantes (HIRSCHHEIM,
KLEIN & LYYTINEM, 1995, p. 16). Por fim, ele um processo incerto por apresentar
trs tipos de incerteza: a incerteza de recursos, ou seja, sobre a possibilidade de atingir
um estado final desejado; a incerteza de efeito, sobre o fato de o resultado apresentar ou
no as propriedades desejadas; e a incerteza do problema, que significa a dvida se o
sistema resolve o problema correto (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p.
16). Devido em grande parte a estas incertezas, o processo de mudana no
desenvolvimento no determinstico (HIRSCHHEIM, KLEIN & LYYTINEM, 1995,
p. 16).
Assim, o desenvolvimento de sistemas, segundo os autores, um processo de
mudana de sistema objeto em um conjunto de ambientes por um grupo de
desenvolvimento para atingir ou manter alguns objetivos (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p. 15). A Figura 9 ilustra o desenvolvimento de sistemas de
informao segundo tais autores:

Figura 9 Desenvolvimento de Sistemas de Informao (HIRSCHHEIM, KLEIN & LYYTINEM,

1995, p. 16)

SAMBAMURTHY & KIRSCH (2000) propuseram uma estrutura que descreve de

forma unificada os principais conceitos relacionados ao processo de DSI. Os autores
definiram desenvolvimento de sistemas da seguinte forma:
Processos de desenvolvimento de sistemas de informao nas organizaes so
as tarefas realizadas para construir um sistema de informao baseado em

29

computadores, e o gerenciamento deste esforo, por um grupo de interessados

com programas de trabalho, os quais se empenham em transaes ao longo do
tempo dentro de um contexto institucional aplicando estrutura ao seu trabalho
com um conjunto de ferramentas e metodologias, e que julgam as sadas dos
seus esforos.
Esta definio de DSI contm os mesmos conceitos da que foi proposta por
HIRSCHHEIM, KLEIN & LYYTINEM, entretanto ela inclui mais alguns sendo,
portanto, mais ampla. Neste trabalho consideraremos esta como sendo a definio de
DSI.

4.2 PRINCIPAIS CONCEITOS RELACIONADOS AO DSI

A seguir detalharemos um pouco mais cada um dos conceitos envolvidos no processo
de DSI que so: os interessados envolvidos, as tarefas desenvolvidas, o programa de
trabalho a ser cumprido, as transaes entre os interessados, o contexto em que o
processo ocorre, a estrutura utilizada e as sadas produzidas.

4.2.1 Interessados
Os interessados so as pessoas ou grupos com interesse na sada de um esforo de DSI
(SAMBAMURTHY & KIRSCH, 2000). Segundo HIRSCHHEIM, KLEIN &
LYYTINEM (1995, p. 17), o esforo de desenvolvimento realizado por um grupo
formalmente organizado e que tem similaridades com instituies sociais, ou seja, ele
pune e oferece recompensas, consiste de posies e regras preenchidas pelas pessoas e
assim por diante.

4.2.2 Tarefas
As tarefas representam todo o trabalho para construir um sistema (SAMBAMURTHY
& KIRSCH, 2000). So consideradas tarefas do desenvolvimento de sistemas a faixa
completa de atividades envolvidas no processo de construo (incluindo anlise e
projeto), implementao e manuteno de um SI (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p. 11). Estas atividades do DSI possuem um certo propsito e
podem ser tambm subdivididas em componentes menores (SAMBAMURTHY &
KIRSCH, 2000).
O processo de DSI envolve a anlise, o projeto, a implementao tcnica (construo), a
implementao organizacional (institucionalizao) e a evoluo subseqente
(manuteno para melhoria) (IIVARY, 1991, p. 250). H, entretanto, uma grande
variao com relao s atividades que devem ser executadas durante o processo de
DSI, sua seqncia, quando e por quem elas devem ser executadas, a documentao
produzida e em que grau elas devem ser descritas e formalizadas (HIRSCHHEIM,
KLEIN & LYYTINEM, 1995, p. 11).

30

A anlise o processo de coletar, organizar e analisar fatos sobre um SI especfico e o

ambiente em que ele opera (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 11), ou
seja, atravs dela que se define o problema que a organizao tentar resolver com o
SI (LAUDON & LAUDON, 1998, p. 400). Alm disso, ela permite determinar se uma
soluo vivel ou se pode ser atingida dados os recursos e restries da organizao
(LAUDON & LAUDON, 1998, p. 401).
O projeto de sistemas a concepo, gerao e formao de um novo sistema
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 11). Ele permite a criao de um
plano geral ou modelo para o sistema (LAUDON & LAUDON, 1998, p. 401) e
determina como os requisitos de informao determinados na atividade de anlise sero
atingidos (LAUDON & LAUDON, 1998, p. 401). O projeto pode ainda ser dividido em
lgico e fsico (LAUDON & LAUDON, 1998, p. 404). Enquanto o lgico define os
componentes de um SI e seus relacionamentos (LAUDON & LAUDON, 1998, p. 403),
o fsico a traduo do modelo lgico abstrato em uma especificao tcnica para o
novo sistema (LAUDON & LAUDON, 1998, p. 404).
As outras atividades do processo de desenvolvimento de sistemas devem traduzir as
especificaes de soluo estabelecidas durante a anlise e projeto em um sistema de
informao totalmente operacional (LAUDON & LAUDON, 1998, p. 405).

4.2.3 Programa de trabalho

Cada interessado no processo de DSI tem um programa de trabalho que o conjunto
de metas, objetivos ou expectativas relativas ao esforo de desenvolvimento
(SAMBAMURTHY & KIRSCH, 2000). Os objetivos de um projeto podem ser
estabelecidos de forma explcita ou implcita, podendo incluir at objetivos polticos
(SAMBAMURTHY & KIRSCH, 2000).

4.2.4 Transaes
As transaes so os meios formais e informais atravs dos quais os interessados
atingem seus programas de trabalho ou garantem que as tarefas sejam completadas
(SAMBAMURTHY & KIRSCH, 2000). Mais especificamente, as transaes referemse s diversas interaes entre os interessados ao longo do processo.

4.2.5 Contexto
O contexto representa o ambiente social e cultural em que o desenvolvimento de
sistemas est embutido. Ele tambm pode ser definido pelas ocorrncias ou incidentes
fora da equipe de projeto, mas que afetam o trabalho da equipe e o curso do projeto
(SAMBAMURTHY & KIRSCH, 2000).

31

4.2.6 Estrutura
A estrutura o conjunto de mecanismos informais e formais utilizados para justificar
as transaes (SAMBAMURTHY & KIRSCH, 2000). Formalmente, a estrutura
definida como as polticas e atividades ocorrendo dentro da organizao que
determinam ou restringem o comportamento dos membros da organizao
(SAMBAMURTHY & KIRSCH, 2000). No contexto do DSI, existem provavelmente
trs frontes de estrutura: as metodologias, as ferramentas de desenvolvimento, e as
polticas organizacionais (SAMBAMURTHY & KIRSCH, 2000).

4.2.7 Sadas
As sadas so os resultados realizados em qualquer ponto durante o processo de DSI
(SAMBAMURTHY & KIRSCH, 2000).

4.3 ESTRATGIAS PARA O DSI

As estratgias ou enfoques para o DSI descrevem de forma geral como as tcnicas
devem ser inter-relacionadas e usadas de forma a definir, construir, implementar,
apoiar e manter software (AMBLER, 1998, p. 7). Elas tambm so conhecidas como
ciclos de vida ou ciclos de vida do desenvolvimento de sistemas (SDLC System
Development Life Cicle).
AMBLER (1998, p. 7) discute cinco tipos de SDLC: desenvolvimento serial,
desenvolvimento iterativo, desenvolvimento incremental, desenvolvimento paralelo e
aleatrio.
O primeiro SDLC largamente aceito para o desenvolvimento de aplicaes foi o modelo
em cascata, o qual baseado no enfoque serial (AMBLER, 1998, p. 7). A idia bsica
que o desenvolvimento ocorre de forma serial atravs da vida do projeto, com os
esforos da equipe de desenvolvimento avanando de uma fase do projeto para outra
(AMBLER, 1998, p. 7).
Com a popularizao dos computadores pessoais na dcada de 80, novas abordagens
para o desenvolvimento de sistemas foram criadas. Como no havia mais a necessidade
de se trabalhar em mquinas de vrios milhes de dlares, o desenvolvimento no
precisava ser realizado apenas pelo departamento de processamento de dados, assim
como no deveria levar anos para que um sistema fosse entregue (AMBLER, 1998, p.
10). Ele poderia ser feito com o envolvimento direto dos usurios e, em alguns casos,
por eles mesmos (AMBLER, 1998, p. 10). Alm disso, as entregas no precisavam ser
completas nem totalmente operacionais (AMBLER, 1998, p. 10). Assim, os enfoques
evolutivos foram sendo cada vez mais utilizados.

32

Um dos enfoques evolutivos o desenvolvimento iterativo e o SLDC em espiral

talvez o mais conhecido (AMBLER, 1998, p. 10). Nele, os desenvolvedores constroem
sistemas primeiro fazendo um pouco de anlise, ento alguma prototipagem, ento
algum projeto, ento alguma codificao, e assim por diante at a aplicao estar
completa (AMBLER, 1998, p. 10). O sistema , portanto, construdo atravs de vrias
iteraes e cada entrega representa um prottipo do sistema mais refinado que o anterior
at se chegar a um prottipo totalmente operacional, que representa o prprio sistema.
Outro enfoque evolutivo o desenvolvimento incremental. A idia bsica que ao
invs de construir uma aplicao toda de uma vez, pode-se construir e entregar vrias
verses, cada uma com um conjunto especfico de funes (AMBLER, 1998, p. 14).
Cada verso efetivamente um mini-projeto com todos os componentes de
desenvolvimento que um projeto grande tem, a nica diferena que o escopo menor
(AMBLER, 1998, p. 14). Neste enfoque, as funes mais importantes so desenvolvidas
primeiro, permitindo que o sistema comece a ser utilizado bem mais rapidamente que
nos enfoques seqenciais.
O desenvolvimento paralelo outro tipo de enfoque evolutivo. Ele est baseado na idia
de que um projeto pode ter vrias frentes de trabalho ocorrendo simultaneamente
(AMBLER, 1998, p. 16).
O enfoque aleatrio ou hacking quando pouco ou nenhum esforo feito na anlise e
projeto antes da codificao comear (AMBLER, 1998, p. 18). Embora este enfoque
seja o mais problemtico, provavelmente o mais utilizado atualmente (AMBLER,
1998, p. 18).
As estratgias citadas anteriormente so excludentes e, muitas vezes, so utilizadas em
conjunto. A classificao representa apenas um mecanismo genrico para a descrio do
desenvolvimento servindo basicamente como referencial terico. A Tabela 3 resume as
vantagens e desvantagens de cada abordagem:

33

Enfoque
Desenvolvimento
serial

Desenvolvimento
incremental

Desenvolvimento
iterativo

Desenvolvimento
paralelo

Aleatrio
hacking

Vantagens
- define as fases bsicas do
desenvolvimento de sistemas,
assim como as entregas entre
elas
- freqentemente bom para
projetos grandes
- incorpora os princpios bem
aceitos de gerenciamento de
projetos
- permite detectar e reagir
rapidamente s mudanas no
ambiente
- fornece ampla oportunidade
para trabalhar prximo aos
usurios
- bom para pequenos projetos
- permite organizar grandes
projetos
em
componentes
menores, os quais so fceis de
gerenciar

possvel
oferecer
funcionalidade aos usurios mais
rapidamente
- permite detectar e consertar
erros mais cedo
a
aplicao
geral

freqentemente entregue mais

cedo com menos esforo/custo
envolvido
- encurta o calendrio para a
entrega da aplicao

ou - um caminho mais rpido para

obter cdigo a ser entregue
- programadores gostam deste
enfoque
- a percepo da gerncia de
que os programadores esto
sendo mais produtivos

Desvantagens
no
reflete
realmente
o
desenvolvimento
de
sistemas;
freqentemente precisa voltar e refazer o
trabalho
- pode levar a grandes sistemas
monolticos,
embora
no
necessariamente

- nem todas aplicaes podem ser

entregues em vrias verses; tudo ou
nada
desenvolvedores
experientes
freqentemente acham seu primeiro
projeto incremental difcil de aceitar

- pode ser difcil definir entregas para

um projeto
- enfoques de planejamento tradicionais
precisam ser modificados para o
desenvolvimento iterativo
- ele tem um nome ruim, pois aqueles
que desenvolvem de forma aleatria
(hackers) justificam suas aes com a
desculpa de que usam desenvolvimento
iterativo
- aumenta o tempo de esforo para a
entrega da aplicao devido ao aumento
das questes de gerenciamento de
configuraes
- produz aplicaes que so difceis para
manter e melhorar
- uso menos produtivo do tempo e dos
esforos de programao
- no momento da entrega, caractersticas
faltantes,
mal-entendidas
e/ou
desnecessrias so descobertas no
produto
- introduz grande nmero de defeitos os
quais so freqentemente difceis para
encontrar e consertar

Tabela 3 Vantagens e desvantagens de cada enfoque de desenvolvimento (AMBLER, 1998, p. 22)

34

4.4 METODOLOGIAS DE DSI

O desenvolvimento de sistemas , geralmente, visto como sendo uma atividade
intelectual complexa (VESSEY & GLASS, 1998, p. 100). Ele exige habilidades em
pelo menos duas disciplinas: o domnio do problema ou da aplicao, que a rea do
problema a ser resolvido, e o domnio da soluo que a rea de sistemas de
informao e de software (VESSEY & GLASS, 1998, p. 99).
Uma forma de lidar com essa complexidade atravs do emprego de mtodos
padronizados e previsveis para o desenvolvimento de sistemas (VESSEY & GLASS,
1998, p. 100). Assim, para atingir um melhor entendimento do processo de DSI, vrias
tentativas para descrev-lo e formaliz-lo tm sido feitas (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p. 11). Tais tentativas tm resultado no que so atualmente
chamadas de metodologias de desenvolvimento de sistemas de informao
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 11). A seguir, definiremos
metodologia de DSI e classificaremos as principais.

4.4.1 Definio de Metodologia de DSI

INTRONA & WHITLEY (apud WHITLEY, 1998, p. 68) definem metodologia como
um conjunto estruturado de tcnicas e ferramentas que so usadas para resolver um
problema especfico, no caso, o desenvolvimento de um sistema de informao.
HIRSCHHEIM, KLEIN & LYYTINEM (1995, p. 2) consideram que metodologia
qualquer prescrio orientada a processos de como deve ser o desenvolvimento de DSI.
Para os autores, as metodologias de DSI incluem uma coleo organizada de conceitos,
mtodos, crenas, valores e princpios normativos apoiados por recursos materiais
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 22). Portanto, alm dos conceitos e
mtodos, os autores tambm ressaltam a existncia de questes ligadas aos valores,
crenas e princpios que so permeados pelas metodologias, mas que muitas vezes no
so percebidas pelos envolvidos no processo de desenvolvimento.
As metodologias so normativas uma vez que organizam conjuntos de regras
comportamentais e tcnicas em um enfoque coerente que prescreve como resolver
problemas maiores do desenvolvimento (HIRSCHHEIM, KLEIN & LYYTINEM,
1995, p. 22). Elas formam uma coleo organizada, pois supem algum tipo de
coerncia e integrao entre suas partes ao invs de serem conjuntos aleatrios de regras
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 22). Elas incluem conceitos e
crenas que definem o contedo e o comportamento dos sistemas objeto (e suas
possveis mudanas) assim como seus valores os quais estabelecem quais propriedades
no sistema objeto so boas e desejveis (HIRSCHHEIM, KLEIN & LYYTINEM,
1995, p. 22). Elas tambm apontam para mtodos os quais especificam procedimentos
para realizar tarefas bem definidas (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p.
22), e princpios normativos os quais especificam expectativas comportamentais
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 22). Por fim, esto conectadas aos

35

recursos materiais, tais como instrumentos e ferramentas utilizadas no desenvolvimento

de sistemas de informao (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 22).
IIVARY, HIRSCHHEIM & KLEIN (2000, p. 186) definem metodologia com um
conjunto codificado de procedimentos orientados a um objetivo que visam guiar o
trabalho e cooperao das vrias partes envolvidas na construo de uma aplicao de
sistemas de informao. Tipicamente, estes procedimentos so suportados por um
conjunto preferido de tcnicas e ferramentas, e princpios subjacentes.
Uma metodologia de DSI uma instituio social envolvendo conhecimento e recursos
a qual condiciona e guia a percepo, anlise, sntese, avaliao e implementao das
mudanas do sistema objeto (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 15).
Para HIRSCHHEIM, KLEIN & LYYTINEM (1995, p. 21) a predisposio para
acreditar no poder das metodologias vem de Descartes o qual props que a verdade
mais uma questo de mtodo apropriado do que uma idia genial ou inspirao divina.
Por isso, uma questo bastante discutida tanto entre acadmicos quanto entre praticantes
do desenvolvimento de sistemas a de como o processo de DSI pode ser melhorado
atravs da aplicao de novas ferramentas, tcnicas, princpios e mtodos ou
metodologias (IIVARY, HIRSCHHEIM & KLEIN, 2000, p. 180).
Uma tcnica pode ser entendida como um caminho para atingir uma tarefa
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 11). Ela pode ser comparada a uma
receita que guia algum ao longo de uma tarefa especificando uma srie ordenada de
estgios de projeto. Um modelo de projeto formal oferece conceitos e notaes
convenientes para representar os resultados de cada etapa de projeto (NANARD &
NANARD, 1995, p. 50). Ela consiste de uma seqncia bem definida de operaes
elementares que mais ou menos garantem a obteno de certas sadas se executadas
corretamente (IIVARY, HIRSCHHEIM & KLEIN, 2000, p. 186).
Enquanto IIVARY, HIRSCHHEIM & KLEIN (2000, p. 186) consideram tcnica e
mtodo como sendo sinnimos, HIRSCHHEIM, KLEIN & LYYTINEM (1995, p. 11)
definem mtodo como uma descrio bem definida de uma tcnica. Portanto, enquanto
um mtodo sempre pode ser documentvel, uma tcnica, a qual conta com as
habilidades humanas, no pode.
Por fim, uma ferramenta pode ser definida como um objeto especfico empregado no
uso de um mtodo ou tcnica particular e que existe independente dos mtodos ou
tcnicas que a utilizam (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 11).
Neste trabalho, definiremos metodologia de DSI como sendo um conjunto de
procedimentos integrados que guiam o processo de DSI e que utilizam
preferencialmente um conjunto de tcnicas. No diferenciaremos tcnicas e mtodos.
Consideraremos as tcnicas como conjuntos de tarefas a serem seguidas em
determinada ordem para atingir certo resultado. Cada tcnica utiliza conceitos e
notaes convenientes e pode gerar modelos formais como resultado.

36

4.4.2 Geraes de Metodologias de DSI

Vrias metodologias de DSI tm sido criadas, podendo ser agrupadas em geraes, as
quais refletem a evoluo da tecnologia da informao, o papel que desempenham
dentro do processo de DSI e o amadurecimento da forma como so vistas. A seguir
discutiremos algumas dessas geraes de metodologias de DSI.
Nos primeiros sistemas de informao administrativos, construdos em meados da
dcada de 50, as tarefas de projeto envolviam apenas a programao e a especificao
das principais funes (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 29). Algumas
prticas sistemticas para o desenvolvimento foram criadas e, geralmente, eram muito
orientadas tecnologia (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 29). Tais
prticas surgiam das experincias de sucesso em projetos anteriores e muitas vezes no
eram nem documentadas (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 29). Nesta
poca, o DSI era considerado um processo tcnico realizado por pessoas tcnicas
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 29). HIRSCHHEIM, KLEIN &
LYYTINEM (1995, p. 29) definem o perodo de meados da dcada de 50 at meados da
dcada de 60 como a era pr-metodologia.
Durante a primeira gerao das metodologias de DSI surgiu a abordagem que envolvia
o desenvolvimento inteiro dos sistemas, desde o estgio inicial at sua implementao e
manuteno, a qual representava o SDLC baseado em srie (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p. 33). O desenvolvimento de sistemas ainda continuava a ser visto
como um processo tcnico a ser conduzido por especialistas tcnicos auxiliados por
solues tcnicas (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 33).
Vrios trabalhos foram propostos para as reas de requisitos de informao, modelagem
organizacional, anlise da informao e projeto de sistemas lgicos. Um dos
pesquisadores que mais contribuiu para a rea foi Langefors (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p. 30), o qual props a distino terica entre projeto lgico e
fsico, delineou os fundamentos para a modelagem de dados e o projeto lgico do
programa, alm de sugerir um enfoque recursivo para os problemas de projeto de
sistemas (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 30). Em 1969, um trabalho
bastante influente em desenvolvimento de sistemas apresentou propostas para
modelagem da interface e anlise de alto nvel. Ele apresentava uma estrutura para
sistemas de informao de mdulos genricos de processamento de informaes
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 30). Tais mdulos poderiam ser
compartilhados pelos maiores subsistemas de informao e em parte eles eram nicos
para cada subsistema de informao (HIRSCHHEIM, KLEIN & LYYTINEM, 1995,
p. 32). Nesta poca, tambm comeou a se perceber a importncia do planejamento de
sistemas de informao para a determinao dos requisitos e priorizao de projetos. O
desenvolvimento de SI passou a ser visto como uma evoluo planejada para toda a
organizao (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 32).

37

Nesta poca, uma outra frente para o desenvolvimento de metodologias veio da

engenharia de software. O termo engenharia de software ganhou popularidade na
dcada de 70 e atualmente usado para referenciar os mtodos bem estruturados e
ferramentas de projeto dos programas, implementao e teste sob as consideraes que
os requisitos de sistemas so dados (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p.
32).
Embora ajudasse o desenvolvedor a construir sistemas atravs de estruturas bem
definidas, a primeira gerao de metodologias de DSI falhou em lidar adequadamente
com dois problemas recorrentes: mudanas nos requisitos dos usurios e projetos de
sistemas que pudessem ser facilmente entendidos (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p. 33). Surgiram ento as chamadas metodologias estruturadas, as
quais faziam uma clara distino, na teoria e na prtica, entre projeto lgico e fsico,
assim como ofereciam mtodos para especificar o sistema tanto no nvel lgico como
no fsico (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 33). Alm disso,
facilitaram o tratamento de outras questes importantes de projeto as quais haviam se
tornado crticas, tais como interfaces amigveis com os usurios, e projetos
preocupados com a ergonomia (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 33).
Elas formaram a segunda gerao de metodologias de DSI.
No final da dcada de 70, com o aumento da competio entre as empresas os usurios
no podiam mais esperar dois ou trs anos para que seus sistemas pudessem ser
desenvolvidos, nem poderiam esperar tanto tempo para descobrir que o sistema
entregue no atendia suas necessidades e, ao mesmo tempo, as evolues tecnolgicas
passaram a permitir que a implementao de sistemas fossa mais rpida e produtiva
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 34). Assim, comearam a surgir os
enfoques evolucionrios, que marcaram a terceira gerao de metodologias de DSI. O
desenvolvimento ainda era percebido como um processo tcnico, mas que tinha
conseqncias sociais que deveriam ser consideradas (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p. 34).
As metodologias da segunda e terceira geraes apresentavam algumas deficincias. O
nvel de envolvimento dos usurios permitido pelos enfoques estruturados no era
considerado suficiente, pois os enfoques de desenvolvimento de sistemas tinham
tradicionalmente focado no sistema tcnico ao invs do sistema social. Isto levava a
sistemas de informao que poderiam ser tecnicamente elegantes, mas no eram ideais
do ponto de vista social ou do trabalho (HIRSCHHEIM, KLEIN & LYYTINEM,
1995, p. 34). Surgiram ento as metodologias da quarta gerao, denominadas
genericamente de scio-tcnicas e participativas, as quais usavam o
desenvolvimento de sistemas como um veculo para repensar o ambiente social do
trabalho no qual o novo sistema seria implementado (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p. 36). O desenvolvimento de sistemas passou a ser visto como um
processo tanto social quanto tcnico.
Aproximadamente ao mesmo tempo das metodologias da quarta gerao, outros
enfoques foram sendo desenvolvidos, principalmente para contornar limitaes dos

38

enfoques estruturados. Uma preocupao envolvia a questo da formulao do

problema, pois como as geraes anteriores a tratavam de maneira relativamente
simples, ou seja, principalmente adaptando o enfoque cientfico para a soluo de
problemas, os requisitos dos usurios no eram facilmente articulados (HIRSCHHEIM,
KLEIN & LYYTINEM, 1995, p. 29). Alguns projetos foram desenvolvidos com
abordagens visando contornar tais problemas e, embora tais projetos no possam ser
considerados metodologias, eles propuseram vrios mtodos e ferramentas que podem
ser usados no desenvolvimento de sistemas. Essa linha de desenvolvimento foi
considerada por HIRSCHHEIM, KLEIN & LYYTINEM (1995, p. 29) como a quinta
gerao de metodologias, a qual procurava obter um melhor entendimento mtuo (...)
entre os usurios e os desenvolvedores atravs da interao de um grupo para
interpretar seu ambiente e chegar a um significado compartilhado socialmente
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 29). O desenvolvimento de sistemas
passou a ser visto principalmente como um processo social.
A sexta gerao de metodologias surgiu paralelamente ao desenvolvimento da terceira e
como uma reao aos fundamentos ideolgicos e efeitos sociais negativos dos
enfoques da primeira e segunda geraes (HIRSCHHEIM, KLEIN & LYYTINEM,
1995, p. 38). De maneira similar quinta, ela tambm foi formada por projetos
inovadores que no representavam metodologias em si, mas que contriburam para o
campo de DSI. Tais projetos colocavam o controle do desenvolvimento nas mos da
fora de trabalho ao invs da administrao (HIRSCHHEIM, KLEIN & LYYTINEM,
1995, p. 38), pois sentiam os enfoques scio-tcnicos como instrumentos para
reduzir a resistncia do trabalhador aos sistemas, os quais serviam principalmente aos
interesses dos gerentes e proprietrios e ofereciam pouca melhora na posio dos
trabalhadores (HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 38). O DSI era visto
muito mais como um processo poltico do que tcnico (HIRSCHHEIM, KLEIN &
LYYTINEM, 1995, p. 38).
HIRSCHHEIM, KLEIN & LYYTINEM (1995, p. 39) propuseram a existncia da
stima gerao, mas no ofereceram exemplos de metodologias. Portanto, tal gerao
representa apenas uma compilao terica das vantagens das anteriores.
Muitas vezes, as abordagens incorporam, ou pelo menos consideram, as caractersticas
das anteriores, alm de influenci-las podendo resultar em revises nas metodologias.
Assim, as geraes discutidas devem ser entendidas apenas como uma separao
conceitual entre as vrias correntes de pensamento.

4.4.3 Classificao das Metodologias de DSI

JAYARATNA (apud IIVARY, HIRSCHHEIM & KLEIN, 2000, p. 180) levantou, em
1994, a existncia de mais de 1000 metodologias para o DSI e ROSSI &
BRINKKEMPER (1996, p. 209) chegaram a usar a expresso selva de metodologias
para descrever esse grande nmero de abordagens existentes.

39

Para que seja possvel comparar as metodologias, ressaltando semelhanas e diferenas,

preciso ter uma estrutura conceitual para classificao. Sem tal estrutura, fica difcil
identificar os aspectos essenciais de cada metodologia, assim como sua aplicao e
limites.
IIVARY, HIRSCHHEIM & KLEIN (2000-2001) propuseram uma estrutura para
classificao de metodologias de DSI. Os autores consideraram que muitas
metodologias utilizam recursos e tcnicas em comum e dificilmente surge alguma com
caractersticas totalmente novas. Segundo a estrutura, cada metodologia de DSI
meramente uma instncia de uma classe abstrata mais genrica (IIVARY,
HIRSCHHEIM & KLEIN, 2000-2001, p. 181). Tal classe apresenta aspectos bsicos
que so herdados por todas as metodologias pertencentes a ela. Este conceito, chamado
de enfoque, no o nvel mais alto de abstrao, sendo que a essncia mais abstrata
dos diferentes enfoques capturada pelos paradigmas (IIVARY, HIRSCHHEIM &
KLEIN, 2000-2001, p. 181). A estrutura foi ento definida como uma hierarquia
formada por quatro camadas: os paradigmas, os enfoques, as metodologias e as
tcnicas.
Um paradigma pode ser definido como sendo o mais fundamental conjunto de
suposies adotado por uma comunidade profissional que permite seus membros
compartilhar percepes similares e comprometer-se com prticas compartilhadas
comumente (HIRSCHHEIM & KLEIN, 1989, p. 1199). Ele consiste de suposies
sobre o conhecimento e como adquiri-lo, e sobre o mundo fsico e social
(HIRSCHHEIM & KLEIN, 1989, p. 1199). Um mesmo paradigma pode ser a base para
vrios enfoques de metodologias.
Os autores definiram quatro paradigmas possveis: funcionalismo, estruturalismo
radical, relativismo social e neo-humanismo. A maior parte das metodologias est
baseada no paradigma funcionalista, o qual aborda um fenmeno social, o DSI, atravs
de uma viso muito parecida com a das cincias naturais. Acredita-se que a realidade
nica e cabe ao analista de sistemas descobri-la (HIRSCHHEIM & KLEIN, 1989). O
paradigma social relativista procura explicao dentro do domnio da conscincia e
subjetividade individual (HIRSCHHEIM & KLEIN, 1989, p. 1201). O paradigma
estruturalista radical enfatiza a necessidade de ultrapassar ou transcender as limitaes
localizadas nos arranjos sociais e organizacionais existentes. Ele foca principalmente na
estrutura e anlise dos relacionamentos de poder econmico (HIRSCHHEIM &
KLEIN, 1989, p. 1201). Finalmente, o paradigma neo-humanista busca a mudana
radical, emancipao e potencialidade, e estressa o papel que diferentes foras sociais e
organizacionais desempenham no entendimento da mudana. Ele foca em todas as
formas de barreiras emancipao (HIRSCHHEIM & KLEIN, 1989, p. 1201).
O enfoque representa uma classe de metodologias que compartilham algumas
caractersticas essenciais. Tipicamente, um enfoque segue os fundamentos de um dos
quatro paradigmas. Com essa abordagem, pode-se reduzir centenas de metodologias a
algumas dezenas de enfoques caracterizados por suas caractersticas (IIVARY,
HIRSCHHEIM & KLEIN, 2000-2001, p. 181). O melhor conjunto de caractersticas

40

que define o enfoque de desenvolvimento de SI : (1) suas metas, que especificam o

propsito geral de um desenvolvimento de SI; (2) princpios diretores e crenas, os
quais formam uma filosofia comum do desenvolvimento de SI e garante que suas
instncias de metodologias de DSI formem partes coerentes; (3) conceitos
fundamentais, os quais definem o foco da unidade de anlise no desenvolvimento de SI;
e (4) princpios para o processo de DSI, os quais expressam os aspectos essenciais do
processo de desenvolvimento no enfoque (IIVARY, HIRSCHHEIM & KLEIN, 20002001, p. 186).
Baseado em pesquisas anteriores, IIVARY, HIRSCHHEIM & KLEIN (2000-2001, p.
192) selecionaram seis enfoques como sendo considerados os mais representativos do
paradigma dominante, o funcionalista. A Tabela 4 mostra um resumo destes enfoques.

Enfoque Estruturado

Proporcionar um enfoque que ajude a

produzir software de alta qualidade
(confivel e de fcil manuteno) de uma
forma produtiva

Separao do modelo essencial do modelo

de implementao; documentao detalhada
para tornar o processo de desenvolvimento
visvel; notaes grficas; modelos de
processos/ transformaes particionveis de
cima para baixo para esconder a
complexidade; especificao grfica sem
ambigidade e com redundncia mnima;
balanceamento de modelos com alta coeso
e baixo acoplamento.

Modelo essencial
Versus modelo de
implementao; transformao (processo);
fluxo de dados; depsito de dados;
terminador; mdulo; coeso; acoplamento.

Um processo passo a passo no nvel

detalhado de atividades de anlise e de
projeto; dependente da situao no nvel
estratgico (em cascata, prototipagem,
concorrente)

Enfoque

Meta

Princpios diretores e
crenas

Conceitos
Fundamentais

Princpios

Projeto incremental do esquema conceitual;

integrao de vises.

Universo de discurso; informao/banco de

dados; esquema conceitual; esquema interno;
esquema externo; entidade; atributo;
relacionamento.

Os dados formam uma base estvel para sistemas

de informao; separao de esquemas/modelos
conceituais e internos; o esquema conceitual a
teoria do universo do discurso; o esquema
conceitual forma o modelo essencial para um
sistema de informao; aplicaes so construdas
no topo do esquema conceitual; o
desenvolvimento de SI deveria ser baseado em
uma metodologia rigorosa como a engenharia.

Proporcionar um enfoque para o desenvolvimento

de sistemas de informao (bancos de dados) no
nvel empresarial que permita o desenvolvimento
coordenado de aplicaes de sistemas integrados
numa evoluo a longo prazo.

Modelagem da Informao

Desenvolvimento
evolucionrio
(adaptativo).

Deciso semi-estruturada;
banco de dados; modelo
da base; SAD especfico;
gerador de SAD.

O propsito de um SAD
apoiar ao invs de
substituir uma deciso; o
uso de um SAD
interativo; o uso de SAD
implica aprendizado; um
SAD evolui.

Proporcionar um enfoque
para o desenvolvimento de
sistemas que apiam,
principalmente, a tomada
de deciso semiestruturada.

Sistemas de Apoio
Deciso (SAD)

41

Enfoque Infolgico

Proporcionar um enfoque que ajude a garantir que as

necessidades dos sistemas de informao sejam
realmente desenvolvidas; sistemas que dem uma
contribuio positiva organizao; que usurios
entendam o sistema; e que o sistema seja de fcil
manuteno, portvel e eficiente.

Distino entre os problemas infolgicos e

datalgicos; um sistema de informao um
modelo do sistema objeto; o problema infolgico
deveria ser resolvido antes do problema
datalgico; o usurio deveria controlar o
desenvolvimento (especialmente no nvel
infolgico); nveis de modelagem e um sistema
integrado de linguagens de descrio permitem
efetiva participao do usurio.

Problema infolgico
versus problema
datalgico; sistema objeto; atividade; fluxo de
material; fluxo de informao; conjunto de
informaes/mensagens; relao de precedncia;
arquivo; consolidao de arquivo; consolidao do
processo.

Anlise da informao baseado em precedncia de

cima para baixo e anlise de componente; projeto de
baixo para cima.

Enfoque

Meta

Princpios
diretores e
crenas

Conceitos
Fundament
ais

Princpios

Desenvolvimento iterativo e incremental;

reutilizao.

Domnio do problema
versus domnio da
implementao; objeto e classe;
encapsulamento; ocultao de informao
(implementao); herana; polimorfismo;
comunicao entre objetos.

Anlise, projeto e implementao integrada

Proporcionar um enfoque que ajude a garantir

que os produtos so entregues ao usurio em
tempo e dentro do oramento; que os produtos
atendam os requisitos dos usurios; que as
solicitaes dos usurios para modificar o
sistema e/ou consertar erros sejam atendidas
no tempo adequado; que produtos mais
sofisticados sejam oferecidos para manter
vantagem competitiva; que mudanas em
padres e na tecnologia sejam mantidos
atualizados e que as equipes de projeto
sintam-se motivadas e com sucesso.

Enfoque Orientado a Objeto

Participao do usurio; projeto

scio-tecnico; evoluo.

Sistema tcnico; sistema social;

varincia; unidade de operao;
necessidades tcnicas;
necessidades sociais (satisfao
no trabalho).

Auto-projeto de um sistema de
trabalho; especificao crtica
mnima; processo de projeto
sem fim determinado; ajuste
entre os subsistemas tcnico e
social; otimizao de juno;
funes redundantes.

Proporcionar um enfoque para o

desenvolvimento de SI que
permita aos futuros usurios ter
um papel importante no projeto
do sistema, para prover
satisfao no trabalho em adio
aos objetivos mais tcnicos e
operacionais, e garantir que o
novo sistema esteja rodeado por
um sistema organizacional que
funcione adequadamente.

Enfoque Scio-Tcnico

42

43

Tabela 4 Resumo de Seis Enfoques Funcionalistas (IIVARY, HIRSCHHEIM & KLEIN, 2000-2001,
p. 192)

As metodologias so instncias das classes enfoque e so compostas por tcnicas

especficas. Alguns exemplos de metodologias so: Anlise e Projeto Orientados ao
Objeto, Anlise e Projeto Estruturados, Engenharia da Informao e Anlise Estruturada
Moderna (IIVARY, HIRSCHHEIM & KLEIN, 2000-2001, p. 190).
Cada tcnica pode ser utilizada por vrias metodologias. Alguns exemplos de tcnicas
so: diagrama de fluxo de dados, diagrama entidade relacionamento, diagrama de
transio de estados e diagrama de classes.

4.5 MODELAGEM DE SI
Os sistemas computacionais so formados por bits, bytes, nmeros e programas que os
manipulam. O mundo, por outro lado, pode ser visto como conjuntos de pessoas, locais,
atividades, processos e etc. Para que um sistema computacional faa alguma coisa til
preciso mapear os conceitos do mundo real nos bits e bytes dos computadores e uma
forma de fazer este mapeamento atravs de modelos.

4.5.1 Definio de Modelagem

Um modelo pode ser definido como uma abstrao da realidade (BOOCH,
RUMBAUGH & JACOBSON, 1998, p. 6). Quando aplicado a sistemas de informao,
ele funciona como uma planta a qual define de que forma os componentes se
relacionam e se comportam, ou seja, funciona como uma linguagem que pode ser usada
para um analista especificar uma dada aplicao.
Os modelos servem como mecanismo de comunicao entre os interessados no
desenvolvimento de um SI, como forma de simular o comportamento do sistema e/ou
como ferramenta para documentar seu funcionamento, sendo, portanto, utilizados para
diversos propsitos.
Vrias outras disciplinas utilizam modelos para representar os problemas a serem
resolvidos e as solues propostas. Quanto mais complexo for um problema, maior a
necessidade de utilizar modelos para sua representao. De forma geral, os modelos
permitem que possamos entender um sistema complexo, pois abstraem suas
caractersticas principais.
BOOCH, RUMBAUGH & JACOBSON (1998, p. 6) listam alguns princpios bsicos
da modelagem:
A escolha de quais modelos criar tem uma influncia profunda em como um
problema atacado e como uma soluo desenhada;

44

Cada modelo pode ser expresso com diferentes nveis de preciso, ou seja,
enquanto um modelo pode ser utilizado para representar as caractersticas de um
sistema como um todo, um outro pode representar em detalhes apenas uma parte;
Os melhores modelos so conectados realidade, pois embora a simplifiquem,
para que sejam teis no devem mascarar aspectos importantes do fenmeno;
Um nico modelo nunca suficiente. Todo sistema no trivial retratado de forma
melhor atravs de um pequeno conjunto de modelos quase independentes.
Algumas formas de modelagem em SI so: texto em forma livre, descries grficas,
notaes matemticas formais e notaes semiformais tais como o ingls estruturado
(HIRSCHHEIM, KLEIN & LYYTINEM, 1995, p. 20). Existem, portanto, inmeras
formas de representar sistemas de informao. A seguir, discutiremos uma estrutura
para classific-las.

4.5.2 Classificao das Formas de Modelagem de SI

ZACHMAN (1999, p. 461) props, em 1987, uma estrutura genrica para classificao
dos modelos de SI estendendo-a em 1992 (SOWA & ZACHMAN, 1992). Tal estrutura,
chamada de Arquitetura de Sistemas de Informao ou ISA (Information Systems
Architecture), permite analisar as diversas arquiteturas de um SI, ou seja, as diversas
formas de representar os componentes e as relaes entre eles em um SI. Em outras
palavras, ela proporciona uma taxonomia sistemtica de conceitos para relacionar
coisas no mundo para representaes no computador (SOWA & ZACHMAN, 1992, p.
590) oferecendo uma forma de ver o sistema de diversas perspectivas diferentes e
mostrando como todas esto relacionadas (SOWA & ZACHMAN, 1992, p. 590).
A estrutura ISA considera que:
Existem conjuntos de representaes arquiteturais produzidos pelo processo de
construo de um produto complexo de engenharia que descrevem as diferentes
perspectivas dos diversos participantes.
O mesmo produto pode ser descrito para diversos propsitos atravs de vrias
formas, resultando em diferentes tipos de descries.
A estrutura ISA faz uma analogia do desenvolvimento de um sistema de computador
construo de uma edificao, ou seja, compara as perspectivas para a descrio de
um SI quelas utilizadas por um arquiteto durante o projeto de um edifcio
(SOWA & ZACHMAN, 1992, p. 591). Tais perspectivas so as seguintes:
Escopo: corresponde ao sumrio executivo para o planejador ou investidor, o qual
quer uma estimativa do escopo do sistema, seu custo e a forma como deve ser
construdo (SOWA & ZACHMAN, 1992, p. 591). Fazendo uma analogia
construo de um edifcio essa perspectiva descreve em termos aproximados o
tamanho, a forma, os relacionamentos espaciais e o propsito bsico da estrutura
final.

45

Modelo do negcio/empresa: consiste do projeto do negcio, mostrando suas

entidades e processos e como interagem. Fazendo uma analogia construo de um
edifcio essa perspectiva descreve o desenho final do ponto de vista do proprietrio.
Modelo do sistema: modelo projetado por um analista de sistemas, o qual deve
determinar os elementos de dados e funes que representam as entidades e
processos do sistema. uma perspectiva tcnica do projeto. Fazendo uma analogia
construo de um edifcio essa perspectiva a traduo dos planos do arquiteto em
uma especificao detalhada para o projetista.
Modelo de tecnologia: representa a perspectiva do construtor, que deve considerar
as restries das ferramentas, da tecnologia e dos materiais. a descrio de como
construir o SI. Fazendo uma analogia construo de um edifcio essa perspectiva
o plano do construtor.
Componentes: especifica os detalhes das partes ou subsees. Correspondem s
especificaes detalhadas dadas aos programadores que devero codificar mdulos
individuais sem se preocupar com o contexto ou estrutura geral do sistema. Fazendo
uma analogia construo de um edifcio essa perspectiva descreve uma parte da
construo que poder, por exemplo, utilizar um padro de projeto.
As perspectivas podem ser agrupadas em trs tipos de representaes arquiteturais
fundamentais, um para cada interessado no sistema que, segundo o autor, so o
proprietrio, o projetista e o construtor (ZACHMAN, 1999, p. 459). O proprietrio tem
em mente um produto que servir a algum propsito. O arquiteto traduz esta percepo
de um produto na perspectiva do proprietrio. Em seguida, o arquiteto traduz esta
representao em um produto fsico, a perspectiva do projetista. O construtor ento
aplica as restries das leis da natureza e tecnologia disponvel para fazer com que o
produto possa ser produzido, a qual a perspectiva do construtor (ZACHMAN, 1999,
p. 459). Cada representao tem uma natureza diferente, no sendo somente uma viso
mais detalhada da anterior. Assim, o nvel de detalhe uma varivel independente e
varia dentro de qualquer representao arquitetural. A representao do projetista, por
exemplo, no um mero detalhamento da representao do proprietrio, pois ela difere
na essncia e independe do nvel de detalhe (ZACHMAN, 1999, p. 460).
Existem diferentes abstraes ou diferentes caminhos para representar o mundo real
(SOWA & ZACHMAN, 1992, p. 592). As perguntas o que?, como?, onde?,
quem?, quando? e por qu? representam um guia para definir as caractersticas
modeladas em cada tipo de abstrao. Assim, ao responder a pergunta o qu? deve-se
identificar as entidades ou dados que fazem parte do sistema e os relacionamentos entre
eles. A abstrao ligada pergunta como? identifica as funes do sistema e seus
argumentos. A abstrao relacionada pergunta onde? refere-se localizao dos
componentes do SI e identifica tanto os ns (localizaes) quanto as ligaes entre eles.
A abstrao relacionada pergunta quem? refere-se aos agentes envolvidos no
funcionamento do SI e a atividade desempenhada por cada um. O agente algum que
troca informaes com o SI, podendo ser uma pessoa ou mesmo um outro sistema. A
abstrao relacionada pergunta quando? refere-se ao momento em que cada coisa
ocorre no sistema e ao tempo de durao de cada uma. Por fim, a abstrao relacionada
pergunta por qu? diz respeito aos objetivos (metas) e estratgias (mtodos) do SI.

46

Cruzando as cinco perspectivas e os seis tipos de abstrao, tem-se a estrutura ISA. Ela
tem a forma de uma tabela onde as linhas so as perspectivas e as colunas as abstraes,
formando um conjunto de trinta clulas. Cada uma representa um aspecto do SI. Por
exemplo, as clulas da coluna Dado mostram, nas vrias perspectivas, a estrutura do
sistema tendo em vista suas entidades e relacionamentos. Assim, a clula Escopo-Dado
mostra as entidades relevantes para o negcio e o relacionamento entre elas. Por outro
lado, a clula Modelo de tecnologia-Dado mostra as entidades e seus relacionamentos
na tecnologia utilizada, podendo conter, por exemplo, modelos que representem a
estrutura dos dados na linguagem de programao do SI. A Tabela 5 ilustra a estrutura
ISA:

Tabela 5 Estrutura ISA de seis colunas (SOWA & ZACHMAN, 1992, p. 590)

Componentes

Modelo de
Tecnologia

Modelo do
Sistema

Modelo do
Negcio

Escopo

Dado
Entidade
Relacionamento

Funo
Funo
Argumento

Rede
N
Ligao

Pessoa
Agente
Trabalho

Tempo
Tempo
Ciclo

Motivao
Fins
Meios

47

48

A estrutura ISA no define quais modelos devem ser expressos em cada clula, nem
prope qualquer tipo de notao. Cada metodologia pode utilizar os mais convenientes
e a estrutura permite apenas uma classificao em termos de foco e objetivo. Assim, a
clula Modelo de Sistema-Dado pode ser preenchida tanto por um modelo relacional
quanto por um de classes de objetos.
Por outro lado, as metodologias propem modelos para apenas algumas clulas e
dificilmente utilizaro todas. Portanto, esta estrutura pode servir para avaliar as prprias
metodologias, uma vez que permite determinar quais aspectos de um SI esto sendo
enfatizados.

4.5.3 Linguagens para Modelagem de SI

A maioria das organizaes de software fazem pouca ou nenhuma modelagem formal
durante o desenvolvimento de sistemas (BOOCH, RUMBAUGH & JACOBSON, 1998,
p. 7). Geralmente, quanto mais simples um projeto, menos modelagem formal feita
(BOOCH, RUMBAUGH & JACOBSON, 1998, p. 7).
Por outro lado, mesmo nos projetos mais simples, os desenvolvedores fazem alguma
forma de modelagem, embora muito informal (BOOCH, RUMBAUGH & JACOBSON,
1998, p. 7). Eles podem, por exemplo, desenhar rascunhos em papel que tentem
representar parte de um sistema, ou simular o seu comportamento atravs de cenrios, e
tais atividades podem ser vistas como formas de modelagem (BOOCH, RUMBAUGH
& JACOBSON, 1998, p. 7). A prtica de modelagem informal muitas vezes
inadequada, pois os modelos produzidos so aleatrios e no proporcionam uma
linguagem comum que possa ser facilmente compartilhada com os outros interessados
no sistema (BOOCH, RUMBAUGH & JACOBSON, 1998, p. 7).
Assim como existem linguagens padronizadas em outras reas de conhecimento, tais
como a indstria da construo, a engenharia eltrica e a matemtica, a padronizao da
linguagem utilizada na representao de sistemas tambm pode oferecer benefcios s
organizaes envolvidas no processo de desenvolvimento (BOOCH, RUMBAUGH &
JACOBSON, 1998, p. 7).
Conforme citado anteriormente, existem diversas metodologias para o DSI e cada uma
prope conjuntos especficos de tcnicas, havendo pouca padronizao na linguagem
utilizada para a representao dos sistemas. Na dcada de 90, BOOCH, RUMBAUGH
& JACOBSON (1999) propuseram um padro para a linguagem de modelagem de
software atravs do qual praticamente todos os modelos poderiam utilizar a mesma
notao, independente do nvel de detalhes e do propsito. A linguagem, denominada
UML (Unified Modeling Language), estava baseada nos conceitos da orientao ao
objeto e propunha uma srie de artefatos de modelagem, assim como mecanismos para
sua extenso.

49

Em uma outra tentativa de criar uma linguagem padronizada o consrcio OPEN

(GRAHAM, HENDERSON-SELLERS & YOUNESSI, 1997) props a OML (Object
Modeling Language). A UML tem sido, entretanto, a mais citada pela literatura,
podendo talvez ser considerada um padro de fato para a modelagem de software.

4.6 ENGENHARIA DE MTODOS

Na discusso atual sobre metodologias de DSI possvel detectar duas tendncias
opostas (HIRSCHHEIM, IIVARY & KLEIN, 1997). A primeira reflete a crena de que
o interesse nas metodologias de DSI tem declinado, principalmente devido s
dificuldades da sua aplicao prtica. Para ilustrar essa corrente, HIRSCHHEIM,
IIVARY & KLEIN (1997) citaram alguns trabalhos sugerindo que: (1) o uso de
metodologias de DSI limitado na prtica (CHATZOGLUE & MACULAY apud
HIRSCHHEIM, IIVARY & KLEIN, 1997), e quando so usadas elas no so aplicadas
literalmente (WESTRUP apud HIRSCHHEIM, IIVARY & KLEIN, 1997); (2) grande
parte das metodologias so desenvolvidas dentro das empresas ou adaptadas (HARDY
et al. apud HIRSCHHEIM, IIVARY & KLEIN, 1997; WYNEKOOP & RUSSO apud
HIRSCHHEIM, IIVARY & KLEIN, 1997); (3) muitas pessoas acreditam que as
metodologias devem ser adaptadas projeto a projeto (WYNEKOOP & RUSSO apud
HIRSCHHEIM, IIVARY & KLEIN, 1997); e (4) as metodologias so mais teis para
os principiantes do que para os desenvolvedores experientes (ANDERSEN et al. apud
HIRSCHHEIM, IIVARY & KLEIN, 1997; HENDERSON-SELLERS apud
HIRSCHHEIM, IIVARY & KLEIN, 1997).
Ao mesmo tempo, h uma segunda tendncia que descreve o aumento do interesse nas
metodologias de DSI. Algumas razes para esse interesse so descritas por
HIRSCHHEIM, IIVARY & KLEIN (1997): (1) o interesse recente na orientao ao
objeto, impulsionando uma nova onda de metodologias de DSI; (2) o surgimento de
novas ferramentas CASE (Computer Aided System/Software Environment/Engineering)
com suas metodologias associadas; (3) o conceito, cada vez mais aceito, de que a
qualidade do software deve ser garantida desde o incio, exigindo algum tipo de
metodologia; e (4) o interesse na maturidade e melhora do processo de software, que
tem sido crescente desde a publicao do Capability Maturity Model (CMM).
Segundo NIDUMOLU & KNOTTS (1998) h uma crescente evidncia emprica que
sugere que o processo de desenvolvimento de sistemas deve ser adaptado de forma
especfica para a organizao, para o projeto, e outras contingncias situacionais. Essa
forma de ver as metodologias de DSI tem sido chamada de engenharia de mtodos. A
Engenharia de mtodos foca a relao entre as metodologias e tcnicas (apud IIVARY,
HIRSCHHEIM & KLEIN, 2000-2001, p. 191) permitindo montar metodologias
especficas para uma dada organizao/situao.
VESSEY & GLASS (98, p. 100) identificam dois enfoques para o desenvolvimento de
SI apoiado por mtodos. O primeiro baseado na metodologia e o segundo na tcnica.
Os autores argumentam que, como as metodologias so engessadas, o melhor enfoque
atravs de tcnicas, ou seja, da engenharia de mtodos. As metodologias so formadas

50

por colees de tcnicas relacionadas, mas nem todas tm a mesma utilidade, ou seja,
enquanto algumas auxiliam bastante o desenvolvimento em certas situaes, outras tm
apenas valor marginal. Assim, ao invs de empregar uma metodologia completa em
todos os casos melhor mont-la usando apenas as tcnicas mais teis para o tipo de
aplicao.
Acreditamos que, apesar das dificuldades listadas para sua aplicao, as metodologias
representam um importante instrumento de apoio ao processo de DSI. Alm disso, a
engenharia de mtodos constitui uma abordagem vlida para adaptar as metodologias de
acordo com as necessidades especficas de cada organizao e tipo de sistema a ser
desenvolvido.

4.7 QUALIDADE EM SOFTWARE

Devido importncia dos SI para os negcios, tem sido crescente a preocupao com a
qualidade do processo de DSI. Diversos modelos que permitem avaliar a capacidade de
desenvolvimento das organizaes foram propostos. Tais modelos permitem, atravs de
uma anlise detalhada da empresa, determinar o maior nvel de qualidade do projeto,
do processo e do produto que essa organizao capaz de produzir (COSTA, 2000, p.
29).
O mais antigo desses modelos o CMM (Capability Maturity Model), desenvolvido
pela SEI (Software Engineering Institute), organizao ligada universidade Carnegie
Mellon, o qual determina a maturidade das organizaes com relao ao processo de
desenvolvimento de softwares grandes e complexos (AMBLER, 1998, p. 56). So
consideradas imaturas aquelas que tm pouco conhecimento sobre seu processo de
desenvolvimento, e maduras as que o entendem e controlam. Tais instituies
conseguem julgar a qualidade dos seus produtos de software e os processos que os
produzem (AMBLER, 1998, p. 56).
O mrito do CMM no est em inventar novas tcnicas, mas sim integr-las num todo
coerente (COSTA, 2000, p. 29). O modelo prope cinco nveis de maturidade
possveis. Quanto mais alto, melhores e mais maduros so os processos (COSTA, 2000,
p. 30). A Tabela 6 descreve resumidamente cada um.

51

Nvel
1. Inicial

2. Repetitivo

3. Definido

4. Gerenciado

5. Otimizado

Descrio
O software aleatrio e ocasionalmente at catico. Poucos
processos so definidos, e o sucesso depende do esforo
individual.
So estabelecidos processos bsicos de gerenciamento para
rastrear custo, cronograma e funcionalidade. A disciplina de
processos serve para repetir sucessos anteriores com aplicaes
similares.
O processo de software tanto para o gerenciamento quanto para o
desenvolvimento de atividades documentado, padronizado e
integrado ao processo de software padro de toda a organizao.
Para desenvolver e manter o software, todos os projetos usam
uma verso aprovada e adaptada do processo de software padro
da organizao.
So coletadas mtricas detalhadas do processo de software e da
qualidade do produto. Tanto o processo de software quanto a
homologao de produtos so quantitativamente entendidos e
controlados.
A melhora contnua do processo habilitada pelo retorno
quantitativo do prprio processo de software e de idias
inovadoras e tecnologias.

Tabela 6 Os cinco nveis de maturidade do CMM (adaptado de AMBLER, 1998, p. 58-59)

52

5. Desenvolvimento de Sistemas de Informao para a

Web (SIW)
Os SIW apresentam um conjunto de caractersticas que os tornam radicalmente
diferentes das aplicaes anteriores da tecnologia da informao (FRATERNALI, 1999,
p. 228). Eles podem ser descritos como um hbrido entre uma aplicao hipermdia e
um SI (FRATERNALI, 1999, p. 228) e, conseqentemente, seu desenvolvimento
mescla caractersticas do desenvolvimento tradicional de sistemas e da autoria em
hipermdia. No prximo tpico detalharemos algumas destas caractersticas.

5.1 CARACTERSTICAS DO DESENVOLVIMENTO DE SIW

A hipermdia apresenta diversas funcionalidades que melhoram as aplicaes (BIEBER
& ISAKOWITZ, 1995, p.28). Entretanto, os projetos hipermdia diferem dos projetos
de desenvolvimento de software tradicional em vrias dimenses crticas
(ISAKOWITZ, STOHR & BALASUBRAMANIAM, 1995, p. 34). A hipermdia gera a
questo de como modelar as ligaes, utiliza o paradigma da navegao, lida com
mltiplos tipos e estruturas complexas de informao e apresenta interface com o
usurio mais rica. Alm disso, a hipermdia atualmente mais uma arte do que uma
cincia (ISAKOWITZ, STOHR & BALASUBRAMANIAM, 1995, p. 34).
Nas aplicaes hipermdia a informao acessada de uma maneira exploratria ao
invs de utilizar interfaces enlatadas, e o caminho no qual ela navegada e
apresentada de grande importncia (FRATERNALI, 1999, p. 228). Em contraste, os
sistemas de informao tradicionais utilizam o paradigma de dilogos pr-definidos,
baseados, por exemplo, em formulrios (FRATERNALI & PAOLINI, 2000, p. 323).
Assim, os usurios dos SIW tm muito mais controle da interao com o sistema em
comparao com os SI tradicionais (LOHSE & SPILLER, 1998).
Muitos SIW apresentam recursos de pesquisa atravs de mquinas de busca, o que torna
difcil para os projetistas antecipar um caminho de navegao do usurio atravs do
sistema (LOHSE & SPILLER, 1998). Por outro lado, a visualizao da informao e a
navegao devem ser feitas de maneira consistente e previsvel ao longo de todo o
sistema (BALASUBRAMANIAN & BASHIAN, 1998, p. 108).
Uma das preocupaes dentro de uma rede associativa de hipermdia que o usurio se
perca dentro do espao de navegao. Assim, dois conceitos que devem ser tratados ao
longo do projeto de hipermdia so: a desorientao e o overhead cognitivo.
Desorientao pode ser definida como a tendncia de algum perder o sentido de
localizao e direo em um documento no linear (CONKLIN apud BIEBER et al.,
1997, p. 33) enquanto overhead cognitivo pode ser visto como o o esforo adicional e
concentrao necessria para manter vrias tarefas ou trilhas de uma vez (CONKLIN
apud BIEBER et al., 1997, p. 33).
Por oferecer mais recursos de interface, os projetos de aplicaes hipermdia requerem
um alto nvel de qualidade grfica (FRATERNALI, 1999, p. 228). Por isso, muitas

53

vezes envolvem pessoas com conjuntos de habilidades diferentes, tais como autores,
bibliotecrios, projetistas de contedo, artistas, e msicos, alm dos profissionais de
tecnologia da informao (ISAKOWITZ, STOHR & BALASUBRAMANIAM, 1995,
p. 34). Isso provavelmente aumenta a necessidade da utilizao de uma linguagem para
a comunicao entre eles. Um outro problema que muitos desenvolvedores ainda tm
pouca experincia em incorporar a hipermdia nos seus projetos e implementaes
efetivamente (BIEBER & ISAKOWITZ, 1995, p.28).
Tipicamente, os SIW utilizam tanto dados estruturados (por exemplo, registros de
bancos de dados) quanto dados no estruturados (por exemplo, itens de multimdia)
(FRATERNALI, 1999, p. 228), requerendo o seu gerenciamento. Tais dados ficam
armazenados em sistemas diferentes, como bancos de dados, sistemas de arquivos e
dispositivos de armazenamento de multimdia e so distribudos ao longo de mltiplos
Web Sites (FRATERNALI, 1999, p. 227). Os SI tradicionais, por outro lado, tratam
basicamente de dados estruturados.
Como no h barreiras geogrficas limitando o alcance dos SIW, a entrega do contedo
e dos servios feita para o mundo todo e pode envolver o desenvolvimento em vrias
lnguas (LOHSE & SPILLER, 1998).
Uma vez que os SIW tm o potencial adicional de proporcionar ambientes de
computao entre companheiros de trabalho geograficamente distribudos
(TAKAHASHI, 1998, p. 103) comum oferecerem funes colaborativas, tais como
salas de discusso sncronas ou assncronas, apoio ao trabalho em grupo e outras.
Sistemas colaborativos j existiam em tecnologias anteriores, entretanto, tais funes
eram, geralmente, oferecidas por sistemas especficos para isso.
Historicamente, antes mesmo do advento da Web, aplicaes hipermdia como CDROMs e quiosques de informao tm sido construdas para o pblico em geral
(FRATERNALI & PAOLINI, 2000, p. 324). Entretanto, a arquitetura de uma aplicao
hipermdia tpica muito mais simples do que a de um SIW mdio, graas natureza
inerentemente esttica da informao projetada para a publicao off-line
(FRATERNALI & PAOLINI, 2000, p. 324). Os Web Sites tradicionais tambm
apresentam contedo menos voltil do que o dos SIW tpicos, sendo, portanto, menos
complexo o seu desenvolvimento.
Outro aspecto que diferencia o desenvolvimento de SIW do desenvolvimento de Web
Sites convencionais que, enquanto estes so projetados para serem folheados como
revistas, aqueles permitem que os usurios realizem trabalho (DENNIS, 1998, p. 112).
A interface nos SIW deve ser adaptada para cada usurio, ou seja, um mesmo contedo
pode ser visto de diferentes formas conforme o perfil de quem estiver utilizando o
sistema (BALASUBRAMANIAN & BASHIAN, 1998, p. 112). Alm da estrutura do
contedo, a navegao e os estilos de apresentao podem precisar ser adaptados
dinamicamente conforme o tipo de usurio (BALASUBRAMANIAN & BASHIAN,
1998, p. 108).

54

Os usurios interagem muito mais com o SIW do que com os Web Sites tradicionais
(DENNIS, 1998, p. 112). Enquanto em tais Web Sites os usurios assumem papis
pequenos, sua participao crtica nos SIW assim como nos SI no Web (DENNIS,
1998, p. 112).
Nos SIW os projetistas devem resolver questes de autoria de contedo, organizao e
entrega de grandes quantidades de informao desestruturada e em tempo atravs da
Web, alm de garantir que a informao a mais atualizada (BALASUBRAMANIAN
& BASHIAN, 1998, p. 108), ou seja, a criao de contedo e das ligaes no deve ser
feita desordenadamente, mas sim de forma gerenciada. Pessoas com perfil no tcnico
devem poder inserir informaes no sistema (BALASUBRAMANIAN & BASHIAN,
1998, p. 108). Nos Web Sites convencionais, por outro lado, a atualizao do contedo e
das ligaes feita diretamente nas pginas Web e seu volume e freqncia so,
geralmente, mais baixos.
Os SIW so caracterizados por apresentar um relacionamento direto do negcio com os
clientes (FRATERNALI, 1999, p. 227). Nos sistemas de comrcio eletrnico B2C, por
exemplo, os botes de ajuda em uma loja virtual substitui os conselhos amigveis dos
vendedores e os servios por ele oferecidos (LOHSE & SPILLER, 1998). O layout
familiar da loja fsica torna-se uma confuso de menus, ndices de produtos, e
caractersticas de busca (LOHSE & SPILLER, 1998). Menus limitados, navegao
projetada de forma pobre ou dificuldade em comparar mltiplos produtos na mesma tela
tm efeitos desfavorveis na compra eletrnica (LOHSE & SPILLER, 1998). Em outras
palavras, a promessa de comrcio eletrnico e compras on-line depende, em grande
parte, da interface e de como as pessoas interagem com o computador (LOHSE &
SPILLER, 1998). Tais SIW devem apoiar comportamento pr-ativo, por exemplo, para
recomendao e filtragem dos itens a serem vendidos (FRATERNALI, 1999, p. 228).
Alm disso, deve-se considerar que o acesso universal permite a utilizao dos SIW por
indivduos com habilidades limitadas no uso de aplicaes de computador
(FRATERNALI, 1999, p. 227). Portanto, embora a interface com o usurio seja um
fator importante em todos os desenvolvimentos de software, ela ressaltada nos SIW
que oferecem servios ao consumidor.
O desenvolvimento dos SIW deve, portanto, adotar os mesmos princpios
disciplinadores do desenvolvimento de sistemas que so requeridos para construir SI
no Web com sucesso (DENNIS, 1998, p. 112). Como os modelos de dados tais como
diagramas de fluxo de dados, diagramas entidade-relacionamento, e hierarquias
orientadas a objeto no podem representar as peculiaridades que o projeto das
aplicaes hipermdia englobam (BIEBER & ISAKOWITZ, 1995, p.28), h a
necessidade de criao de novas notaes, metodologias e ferramentas para apoiar o
desenvolvimento Web, as quais devem vir das reas de hipermdia, engenharia de
software, e banco de dados para obter o melhor das trs disciplinas, ou seja, o poder de
modelagem da hipermdia, a solidez arquitetural dos bancos de dados, e o enfoque
rigoroso de desenvolvimento da engenharia de software (FRATERNALI & PAOLINI,
2000, p. 325).

55

Nos prximos tpicos, discutiremos algumas propostas de metodologias para apoiar o

desenvolvimento de aplicaes de hipermdia e/ou Web.

5.2 METODOLOGIAS PARA DESENVOLVIMENTO DE SIW

Desde a dcada de 60 diversas pesquisas sobre hipermdia tm sido conduzidas
(BIEBER et al., 1997, p.32). Elas tm desenvolvido caractersticas, sistemas, linhas de
ao, estruturas e teoria focando na estruturao, apresentao e acesso a informaes
correlatas (BIEBER et al., 1997, p.32) e procurado estabelecer mtodos sistemticos e
estruturados para o projeto e construo de aplicaes hipermdia grandes e complexas.
A seguir, descreveremos as quatro metodologias que tm sido as mais citadas pela
literatura pesquisada e que foram as pioneiras para o desenvolvimento de aplicaes
hipermdia. As outras metodologias encontradas (TROYER & LEUNE, 1998;
TAKAHASHI & LIANG, 1997; SCHARL, 1999) so basicamente
extenses/adaptaes das quatro principais e no apresentam inovaes significativas
para a modelagem de hipermdia, no sendo, portanto, discutidas neste trabalho.

5.2.1 Hypertext Design Model

O primeiro modelo formal de projeto direcionado especificamente para aplicaes
hipermdia foi o Hypertext Design Model (HDM) (BIEBER, M.; ISAKOWITZ, 1995, p.
28). O HDM props os conceitos de autoria-no-grande e autoria-no-pequeno. Autoriano-grande permite a descrio de classes genricas de elementos de informao e
estruturas navegacionais de aplicaes complexas sem muita preocupao com os
detalhes de implementao (GARZOTTO, PAOLINI & SCHWABE, 1993, p. 1).
Autoria-no-pequeno refere-se ao desenvolvimento do contedo de cada pedao de
informao (GARZOTTO, PAOLINI & SCHWABE, 1993, p. 1).
O HDM introduziu a noo de esquema e de instncias do esquema de uma aplicao
hipermdia. At ento, o desenvolvimento de tais aplicaes era visto como algo
aleatrio e sem uma estrutura maior. O conceito de esquema foi trazido da rea de
bancos de dados e, com ele, o desenvolvimento das aplicaes hipermdia passou a ser
visto como algo planejado e baseado em modelos. Em seguida, foi proposta uma
extenso ao modelo denominada HDM2 (ISAKOWITZ, STOHR &
BALASUBRAMANIAM, 1995, p. 36).
O HDM e o HDM2 criaram uma srie de primitivas de modelagem. Algumas destas
primitivas foram trazidas do campo de bancos de dados e da prpria rea de hipermdia,
enquanto outras foram criadas especificamente para o desenvolvimento das aplicaes
hipermdia. Algumas das caractersticas dos modelos so: entidades e ligaes, que so
as unidades de informao e seus relacionamentos; a noo de perspectivas, que permite
que uma mesma informao seja vista de vrias formas; a identificao de diferentes
categorias de ligaes com diferentes papis representacionais; a distino entre
hyperbase e estruturas de acesso; e a possibilidade de integrar facilmente a estrutura de

56

uma aplicao hipertexto com suas semnticas de navegao (GARZOTTO, PAOLINI

& SCHWABE, 1993, p. 8).

5.2.2 Relationship Management Methodology

O HDM e o HDM2 descrevem esquemas de representao, mas oferecem pouca
informao sobre os processos para usar tais representaes no processo de projeto, ou
seja, eles no descrevem um projeto hipermdia e uma metodologia de
desenvolvimento (ISAKOWITZ, STOHR & BALASUBRAMANIAM, 1995, p. 3536). ISAKOWITZ, STOHR & BALASUBRAMANIAM (1995) propuseram ento uma
metodologia chamada de Relationship Management Methodology (RMM) e um modelo
de dados chamado de Relationship Management Data Model (RMDM).
O RMDM baseado nos modelos HDM e HDM2 e apresenta novas primitivas para a
modelagem
das
aplicaes
hipermdia
(ISAKOWITZ,
STOHR
&
BALASUBRAMANIAM, 1995, p. 35). As principais so agrupadas em trs classes que
so: (1) as primitivas Entidade-Relacionamento, as quais modelam como a informao
estruturada no domnio da aplicao e so semelhantes s primitivas dos modelos
Entidade-Relacionamento da rea de banco de dados; (2) as primitivas do domnio, as
quais modelam como a informao deve ser apresentada; e (3) as primitivas de acesso,
as quais modelam a navegao na aplicao (ISAKOWITZ, STOHR &
BALASUBRAMANIAM, 1995, p. 35). Mais tarde, o modelo RMDM foi estendido
para oferecer mais primitivas para a modelagem da apresentao (ISAKOWITZ,
KAMIS & KOUFARIS, 1998).
A metodologia RMM foca nas fases de projeto, desenvolvimento e construo do ciclo
de desenvolvimento do software (ISAKOWITZ, STOHR & BALASUBRAMANIAM,
1995, p. 38). A primeira etapa da metodologia representar o domnio de informao
da aplicao atravs de um diagrama Entidade-Relacionamento (E-R) e os
relacionamentos que aparecem no diagrama E-R representam as associaes entre as
instncias
das
entidades
de
informao
(ISAKOWITZ,
STOHR
&
BALASUBRAMANIAM, 1995, p. 39). A segunda, a qual nica para as aplicaes
hipermdia, determina como a informao nas entidades escolhidas ser apresentada aos
usurios e como eles tm acesso a ela (ISAKOWITZ, STOHR &
BALASUBRAMANIAM, 1995, p. 39). Ela envolve dividir uma entidade em partes e
organiz-las em uma rede associativa, permitindo modelar de que forma elas so
relacionadas entre si. A terceira permite definir os caminhos pelos quais ser possvel
habilitar a navegao na aplicao e utiliza as primitivas de acesso do RMDM para
model-los. A quarta etapa, chamada de projeto do protocolo de converso, permite
transformar cada elemento do diagrama RMDM para um objeto na plataforma destino
de hipermdia, o que, no caso da tecnologia Web, representa o conjunto de objetos
existentes na linguagem HTML. A quinta etapa, chamada de projeto de interface com o
usurio, envolve o projeto de layout de telas para todos os objetos que aparecem no
diagrama RMDM e obtidos na terceira etapa (ISAKOWITZ, STOHR &
BALASUBRAMANIAM, 1995, p. 43). A sexta etapa, chamada de projeto do

57

comportamento em tempo de execuo, determina em que pontos da aplicao o

contedo e a navegao devem ser estticos e onde devem ser dinmicos. A ltima
etapa consiste da construo e teste, feita de forma similar aos projetos de engenharia de
software tradicionais.

5.2.3 Object-Oriented Hypermedia Design Method

A metodologia Object-Oriented Hypermedia Design Method (OOHDM) (SCHWABE
& ROSSI, 1995; SCHWABE, ROSSI & GARRIDO, 1998; ROSSI, SCHWABE &
LYARDER, 1999) foi criada para utilizar, no desenvolvimento de aplicaes
hipermdia, os conceitos da orientao ao objeto. Ela adapta os conceitos apresentados
nos modelos HDM e HDM2 para o campo da orientao ao objeto.
A metodologia OOHDM prope um processo de quatro etapas para desenvolver
aplicaes hipermdia. Na primeira etapa, chamada de modelagem conceitual, o
domnio da aplicao construdo usando os princpios da orientao ao objeto e com
algumas primitivas de modelagem da HDM. Ela gera como resultado um esquema de
classes composto por subsistemas, classes do domnio do problema e seus
relacionamentos. Na segunda etapa, chamada de projeto de navegao, so construdos
modelos navegacionais. Na OOHDM, uma aplicao vista como uma viso da
navegao sobre um modelo conceitual (ROSSI, SCHWABE & LYARDER, 1999), ou
seja, ela considera que os objetos sobre os quais os usurios navegam no so objetos
conceituais, mas vises navegacionais sobre eles. Assim, aplicaes distintas podem
oferecer formas de navegao sobre os mesmos objetos conceituais. A metodologia
define um conjunto de classes especficas para definir tal navegao, tais como ns,
ligaes, ncoras e estruturas de acesso. Esta a maior diferena da OOHDM com
relao aos outros mtodos (ROSSI, SCHWABE & LYARDER, 1999). Na terceira
etapa, chamada de projeto da interface abstrata, so especificados quais objetos de
interface o usurio ir perceber e como a interface ir se comportar (ROSSI,
SCHWABE & LYARDER, 1999). A OOHDM diferencia, portanto, projeto de
navegao de projeto de interface, o que permite construir interfaces diferentes para a
mesma aplicao assim como atingir uma independncia de plataforma (ROSSI,
SCHWABE & LYARDER, 1999). A ltima etapa a de implementao, na qual os
objetos conceituais, de navegao e de interface so mapeados em um ambiente de
execuo especfico, o que pode envolver pginas Web, consultas a bancos de dados
relacionais e outros (ROSSI, SCHWABE & LYARDER, 1999).

5.2.4 Relationship Navigation Analysis

A tcnica Relationship Navigation Analysis (RNA) foi desenvolvida para analisar um
sistema ou domnio em termos de seus relacionamentos (YOO & BIEBER, 2000, p.
181). Tal anlise especialmente importante para aplicaes hipermdia de forma geral
e Web especificamente, as quais proporcionam um alto grau de apoio ligao e
navegao (YOO & BIEBER, 2000, p. 181).

58

Quando se faz a reengenharia de um sistema legado para o ambiente Web ou no

desenvolvimento de uma nova aplicao, um aspecto crucial do projeto identificar
relacionamentos e implement-los como ligaes (FIELDING, R. et al, 1998). A RNA
oferece aos analistas de sistemas uma tcnica sistemtica para determinar a estrutura
de relacionamentos de uma aplicao, ajudando-os a descobrir todas as potencialidades
dos relacionamentos teis nos domnios das aplicaes. Estes ltimos podem ser
implementados como ligaes. A RNA tambm ajuda a determinar estruturas de
navegao apropriadas no topo destas ligaes. A RNA melhora o entendimento que os
desenvolvedores de sistemas tm das aplicaes ampliando e aprofundando seu modelo
conceitual do domnio. Os desenvolvedores podem ento melhorar suas
implementaes pela incluso de ligaes, meta-informao e navegao adicionais
(YOO & BIEBER, 2000, p. 181). A RNA compreende as seguintes etapas:
Anlise dos interessados, a qual identifica as pessoas envolvidas de alguma forma
com a aplicao;
Anlise dos elementos, a qual identifica o que cada interessado poderia querer
encontrar na aplicao. Os elementos podem ser objetos do domnio do problema,
componentes de dados, agregaes de componentes, resultados de cada operao e
outros;
Analise dos relacionamentos, a qual identifica os relacionamentos de cada elemento.
A tcnica RNA prope uma taxonomia dos tipos de relacionamentos possveis;
Anlise da navegao, a qual identifica possveis estruturas navegacionais para cada
interessado;
Anlise de viabilidade da implementao, na qual os analistas e projetistas fazem
uma anlise informal de custo/benefcio para decidir quais relacionamentos seriam
teis e viveis o suficiente para serem includos na aplicao.
Embora a RNA no possa ser considerada uma metodologia, pois foca apenas na fase
inicial da anlise do desenvolvimento de SIW, ela bastante relevante para o
desenvolvimento, uma vez que permite tratar uma das questes mais importantes e
complexas do desenvolvimento de SIW que a das ligaes.

5.2.5 O Enfoque Hipermdia

As metodologias para modelagem das aplicaes hipermdia apresentam grande
influncia da rea de bancos de dados. Vrias delas apresentam, como uma de suas
etapas, a modelagem de dados de forma similar ao que feito em outras metodologias
para desenvolvimento de sistemas de informao tradicionais, tais como a construo de
diagramas E-R e diagramas de classes de objetos. Uma diferena, entretanto, que
apresentam primitivas de modelagem mais ricas. Isto porque, as aplicaes hipermdia
lidam, em mdia, com dados que apresentam estruturas mais complexas que nas
aplicaes tradicionais, sendo necessrio ter primitivas adequadas para atender tal
complexidade. Outra diferena que apresentam uma nfase grande na modelagem da

59

navegao das aplicaes, e, para apoiar tal aspecto, propem muitas vezes primitivas
especficas.
Embora as metodologias para o desenvolvimento de aplicaes hipermdia tenham sido
desenvolvidas antes do crescimento da Web e estivessem voltadas para o
desenvolvimento de aplicaes onde o contedo era esttico e off-line, algumas de suas
caractersticas, tais como suas primitivas de modelagem, indicam que talvez possam ser
usadas para o desenvolvimento de SIW.
As metodologias para o desenvolvimento de aplicaes hipermdia compartilham
alguns princpios, conceitos e crenas podendo ser vistas como pertencendo a um novo
enfoque segundo a estrutura para classificao de metodologias de DSI proposta por
IIVARY, HIRSCHHEIM & KLEIN (2000-2001). Assim, consideraremos neste
trabalho que tal conjunto de metodologias representa um novo enfoque para o
desenvolvimento de SIW. Na Tabela 7 esto resumidas as caractersticas deste enfoque.
Conceito
Metas

Descrio
Proporcionar um enfoque que ajude a produzir aplicaes
hipermdia de forma consistente e que permitam a navegao em
grandes volumes de informao.
Princpios diretores e Desenvolvimento baseado em modelos; Separao do projeto de
crenas
navegao do projeto de interface e do projeto de
implementao.
Conceitos
Autoria-no-grande, autoria-no-pequeno, entidades, perspectivas,
fundamentais
ligaes, esquema da aplicao, estruturas de acesso, espao
cognitivo, semntica de navegao, esquema da aplicao e
hiperbase.
Princpios
Projeto consistente de Navegao; modelo de hipermdia.
Tabela 7 Enfoque das Metodologias de Hipermdia (Elaborado pelo autor)

5.3 CICLO DE VIDA DE SIW

As aplicaes Web devem ser projetadas para a mudana, no somente do seu
contedo, mas tambm dos requisitos e arquiteturas (FRATERNALI, 2000, p. 324).
Embora ainda no haja consenso sobre um modelo geral do ciclo de vida de uma
aplicao Web, um esquema das atividades tpicas envolvidas na construo de uma
aplicao Web pode ser obtido interpolando os modelos de ciclo de vida dos SI
tradicionais e as propostas para projeto estruturado de hipermdia (FRATERNALI,
1999, p. 229). Um ciclo de vida possvel foi proposto por FRATERNALI (1999) e est
ser descrito na Figura 10. O autor ressalta, entretanto, que a aplicabilidade do modelo
depende do contexto especfico de desenvolvimento, incluindo a ferramenta de apoio
disponvel, as restries de tempo e financeiras, a complexidade da aplicao, e a
freqncia de mudana (FRATERNALI, 1999, p. 230).

60

Figura 10 O ciclo de vida de uma aplicao Web (FRATERNALLI, 1999, p. 229)

Na anlise de requisitos estabelecida a misso da aplicao, os possveis usurios so

identificados e definida a natureza da base de informaes (FRATERNALI, 1999, p.
229). Em adio s atividades comuns de requisitos e de estimativa de viabilidade, as
aplicaes Web projetadas para acesso universal requerem cuidado especial na
identificao dos requisitos de interao homem-computador, de forma a estabelecer o
modo de interao mais adequado para cada categoria de usurios esperada, e para cada
tipo de dispositivo de sada que os usurios esperam usar para se conectar a aplicao
(FRATERNALI, 1999, p. 229).
Na conceituao a aplicao representada atravs de um conjunto de modelos
abstratos que carregam os componentes principais de uma soluo visualizada
(FRATERNALI, 1999, p. 229). Uma diferena do contexto Web com relao s
mesmas atividades de projeto de SI que o foco das aplicaes Web est na captura de
objetos e relacionamentos como eles aparecero aos usurios, ao invs de como eles
sero representados no sistema de software (FRATERNALI, 1999, p. 229). Embora a
notao possa ser a mesma, por exemplo, atravs de modelos E-R, a diferena est na
interpretao dos relacionamentos. Enquanto na modelagem de bancos de dados tais
relacionamentos representam as associaes semnticas a serem armazenadas
permanentemente, na modelagem Web uma possibilidade de navegao geralmente
explicitada como um relacionamento (FRATERNALI, 1999, p. 229).
Na prototipagem e validao verses simplificadas so entregues aos usurios para
avaliao (FRATERNALI, 1999, p. 229). A importncia da prototipagem
particularmente enfatizada no contexto Web, da mesma forma que na hipermdia,
porque a complexidade intrnseca das interfaces requer uma avaliao oportuna da
juno efetiva da estrutura, navegao e apresentao (NIELSEN apud
FRATERNALI, 1999, p. 229).

61

No projeto, os esquemas conceituais so transformados em uma representao de

baixo nvel, prxima s necessidades de implementao, mas ainda independentes do
contedo real da base de informao (FRATERNALI, 1999, p. 230). Uma aplicao
Web caracterizada por trs maiores dimenses de projeto: (1) a estrutura descreve a
organizao da informao gerenciada pela aplicao, em termos dos pedaos de
contedo que constituem sua base de informao e dos seus relacionamentos
semnticos; (2) a navegao preocupa-se com a facilidade de acesso informao e
com a movimentao atravs do contedo da aplicao; (3) a apresentao afeta o
caminho no qual o contedo da aplicao e os comandos da navegao so apresentados
ao usurio (FRATERNALI, 1999, p. 230).
Na implementao o repositrio preenchido com o contedo fornecido pelos
especialistas do domnio da aplicao e/ou com dados de sistemas legados. As pginas
Web so construdas embutindo, em um estilo de apresentao apropriado, comandos
navegacionais ao contedo do repositrio (FRATERNALI, 1999, p. 230).
Por fim, avaliao e manuteno representam a correo e evoluo do sistema aps a
entrega, de forma anloga aos sistemas no Web (FRATERNALI, 1999, p. 230).

5.4 FERRAMENTAS DE DESENVOLVIMENTO PARA WEB

Para apoiar o desenvolvimento Web muitas ferramentas esto sendo oferecidas,
entretanto, o enfoque para desenvolvimento Web adotado pela maioria dos produtos
restringe o aumento da produtividade da implementao ou uma adaptao das
metodologias de desenvolvimento originadas em outros campos (tipicamente,
programao orientada a objeto e projeto de bancos de dados), os quais no consideram
as especificidades da Web como uma nova mdia de comunicao (FRATERNALI,
2000, p. 325).
FRATERNALI (1999, p. 233) agrupou as ferramentas de desenvolvimento para a Web
em seis categorias, as quais exibem caractersticas homogneas. As categorias
individuais so:
(1) Editores visuais e gerenciadores de site;
(2) Ferramentas de autoria de hipermdia habilitadas para a Web;
(3) Integradores Web-DBPL;
(4) Editores de formulrios Web, escritores de relatrios, e assistentes de publicao de
bancos de dados;
(5) Ferramentas multi-paradigma;
(6) Geradores de aplicao voltados para modelos.
Segundo o autor, "a ordem de apresentao das diferentes categorias reflete o crescente
nvel de suporte que as ferramentas oferecem, em cada categoria, para o
desenvolvimento das aplicaes Web (FRATERNALI, 1999, p. 233).

62

A primeira categoria contm ferramentas que evoluram diretamente dos editores de

pginas HTML, os quais no apoiavam diretamente o desenvolvimento de grandes
aplicaes baseadas em bancos de dados, mas que apresentavam alguns conceitos
inovadores tais como estilos de apresentao e projeto de Web Site de cima para baixo
(top-down). Elas oferecem ambientes que permitem o projeto visual de pginas Web,
evitando a complexidade de escrever diretamente cdigo em HTML, alm de mant-las
em um sistema de arquivos (FRATERNALI, 1999, p. 233). Tais ferramentas so uma
excelente soluo para aplicaes de tamanho pequeno e mdio, onde a publicao de
grandes bases de informao armazenadas em SGBD no uma questo maior
(FRATERNALI, 1999, p. 234).
A segunda categoria apresenta as mesmas limitaes da primeira com respeito ao apoio
ao desenvolvimento estruturado de grandes aplicaes (FRATERNALI, 1999, p. 233).
Elas surgiram de um domnio de aplicaes diferente, a publicao off-line de
hipermdia, mas que recentemente receberam recursos para a Web e integrao com
bancos de dados (FRATERNALI, 1999, p. 233). Tais ferramentas apresentam um
enfoque no convencional (com respeito prtica de engenharia de software) para o
projeto da aplicao e foco especfico na navegao e apresentao (FRATERNALI,
1999, p. 233). Por serem basicamente assistentes para a autoria e voltadas para o
desenvolvimento de aplicaes com vida longa, publicadas uma vez em CDROMs ou
quiosques de informao, elas oferecem apoio limitado modelagem da aplicao,
assim como ao teste e manuteno (FRATERNALI, 1999, p. 233).
A terceira categoria a primeira que explicitamente trata a integrao da Web e bancos
de dados para atingir um alto nvel de escalabilidade (FRATERNALI, 1999, p. 233).
Os produtos desta categoria permitem a produo dinmica de pginas Web com
informaes armazenadas em um banco de dados (FRATERNALI, 1999, p. 233).
Devido ao foco nas linguagens de programao tais produtos carecem de abstraes de
alto nvel para descrever aplicaes, e tambm no ajudam o desenvolvedor na
identificao da estrutura, navegao e apresentao de uma aplicao
(FRATERNALI, 1999, p. 233).
A quarta categoria trata principalmente da migrao das aplicaes cliente-servidor
baseadas em formulrios para a tecnologia Web. Estas ferramentas auxiliam em tarefas
como edio de formulrios, escrita de relatrios, e programao baseada em eventos;
elas tambm oferecem um nvel mais alto de suporte com relao terceira categoria,
mas ainda se concentram somente na fase de implementao (FRATERNALI, 1999, p.
233). Do ponto de vista da engenharia de software, produtos nesta categoria esto para
o desenvolvimento Web como as IDEs e ferramentas RAD estavam para a programao
das aplicaes tradicionais: instrumentos para aumentar (explodir) a produtividade
individual e em grupo na fase de implementao. As melhores ferramentas tambm
ajudam no processo de gerenciamento, teste, e manuteno (FRATERNALI, 1999, p.
233).
A quinta categoria contm um nmero de ferramentas cuja caracterstica comum a
integrao dos diferentes enfoques de desenvolvimento e tecnologias, trazidas das

63

quatro famlias de ferramentas anteriores (FRATERNALI, 1999, p. 233). Elas

apresentam recursos para a edio visual e produtos de gerenciamento de Web Site,
integradores Web-HTML e produtos cliente-servidor (FRATERNALI, 1999, p. 233),
mas no introduzem novos enfoques para o desenvolvimento Web (FRATERNALI,
1999, p. 233).
Finalmente, a sexta categoria inclui os produtos que proporcionam cobertura completa
de todas as atividades de desenvolvimento, da conceituao implementao,
utilizando as tcnicas estado-da-arte em engenharia de software (FRATERNALI,
1999, p. 233).

64

6. Metodologia de Pesquisa
6.1 ESTUDO DE CASO
Existem vrias maneiras de fazer pesquisa em cincias sociais, tais como experimentos,
pesquisas de campo, pesquisas histricas, anlise de dados histricos e estudo de caso
(YIN, 1994, p. 1). Cada estratgia representa um caminho para investigar um tpico
emprico seguindo um conjunto de procedimentos pr-especificados (YIN, 1994, p.
15) e tem vantagens e desvantagens, dependendo de trs condies (YIN, 1994, p. 1):
(a) o tipo de questo de pesquisa, (b) o controle que o investigador tem sobre eventos
comportamentais reais, e (c) o foco em fenmenos contemporneos ou histricos.
YIN (1994, p. 6) sugere as situaes em que cada estratgia de pesquisa mais
adequada:
Estratgia

Forma de questo Requer

controle
da pesquisa
sobre
eventos
comportamentais?
Como, por que
Sim
Experimento
Pesquisa de campo Quem, o que, onde, No
quanto, quantos
Anlise de dados Quem, o que, onde, No
histricos arquivos quanto, quantos
(ex.:
estudo
econmico)
Como, por que
No
Histrico
Como, por que
No
Estudo de caso

Foca em eventos
contemporneos?
Sim
Sim
sim/no

No
Sim

Tabela 8 Situaes relevantes para diferentes estratgias de pesquisa (Yin, 1994, p. 6)

A estratgia de estudo de caso , portanto, preferida quando questes como ou

porque so colocadas, quando o investigador tem pouco controle sobre os eventos, e
quando o foco est em um fenmeno contemporneo dentro de um contexto da vida
real (YIN, 1994, p. 1).
Tipicamente, os fenmenos estudados atravs do estudo de caso no apresentam
fronteiras bem definidas entre eles e seu contexto (YIN, 1994, p. 13). Assim, uma
caracterstica que diferencia o mtodo de estudo de caso justamente o fato de permitir
cobrir as questes contextuais. Os experimentos, por outro lado, divorciam o fenmeno
do seu contexto enquanto as pesquisas de campo, embora tentem lidar com fenmeno e
contexto, apresentam restries para a investigao do contexto (YIN, 1994, p. 13).
Adicionalmente, a estratgia de pesquisa de estudo de caso:
lida com a situao tecnicamente distintiva na qual haver mais variveis de interesse
do que pontos de dados, e como um resultado
confia em mltiplas fontes de evidncia, com os dados precisando convergir em uma
forma de triangulao, e como outro resultado

65

se beneficia do desenvolvimento anterior de proposies tericas para guiar a coleta e

anlise dos dados (YIN, 1994, p. 13).
O fenmeno a ser estudado neste trabalho contemporneo, no se tem controle sobre
os eventos, procura responder questes como e porque e as questes contextuais
so extremamente relevantes. Assim, acreditamos que o estudo de caso seja o mtodo
de pesquisa mais adequado.

6.2 TIPOS DE PROJETOS PARA ESTUDOS DE CASO

YIN (1994, p. 38-39) define quatro tipos bsicos de design de estudos de caso. A Tabela
9 ilustra esses tipos.
Caso nico
Holstico
(unidade
de Tipo 1
anlise
nica)
Embutido
(mltiplas Tipo 2
unidades de anlise)

Mltiplos Casos
Tipo 3

Tipo 4

Tabela 9 Tipos Bsicos de Design para Estudos de Caso (Yin, 1994, p. 39)

YIN (1994, p.38-39) cita as trs principais razes para realizar estudos de caso nico:
(1) quando o caso representa um caso crtico, onde possvel testar ou expandir a teoria
existente; (2) quando o caso representa um caso extremo ou nico; (3) quando o caso
permite que o investigador observe e analise um fenmeno previamente inacessvel para
investigao cientfica. Alm destas, o autor cita que existem outras situaes em que o
estudo de caso nico indicado.
Embora os casos a serem estudados possam ser classificados na primeira categoria, ou
seja, casos crticos que permitem expandir a teoria existente, optamos por estudar mais
de um caso de forma a permitir analisar em mais de um contexto o processo de
desenvolvimento de SIW. Por outro lado, como o objeto deste estudo de natureza
holstica, uma vez que queremos descrever o processo de desenvolvimento como um
todo, utilizaremos apenas uma unidade de anlise. Portanto, neste trabalho utilizaremos
o tipo 3 de design.

6.3 CARACTERIZAO DA PESQUISA

SELLTIZ (1959, p.50) agrupou os propsitos de pesquisa em quatro grandes grupos:
(1) para ganhar familiaridade com um fenmeno ou gerar novas idias sobre ele,
freqentemente para formular um problema de pesquisa mais preciso ou para
desenvolver hipteses; (2) para retratar de forma exata as caractersticas de um
indivduo, situao ou grupo (com ou sem hipteses iniciais especficas sobre a natureza
destas caractersticas); (3) para determinar a freqncia com que algo ocorre ou com o
qual associado a algo mais (geralmente, mas no sempre, com uma hiptese inicial
especfica); (4) para testar uma hiptese de relacionamento causal entre variveis.

66

Os estudos chamados de exploratrios tm o propsito descrito no primeiro dos grupos

acima. Embora os conceitos envolvidos no processo de desenvolvimento de sistemas e,
em particular, nos aspectos da sua construo tenham sido bem desenvolvidos em
estudos passados, o desenvolvimento de SIW um fenmeno recente e, portanto, a
teoria existente ainda se encontra em seus estgios iniciais. Este estudo explorou tal
fenmeno na tentativa de descobrir idias ao invs de testar uma teoria existente tendo,
portanto, carter exploratrio.
Este trabalho envolveu apenas dados qualitativos, pois permitem estudos mais
detalhados e em maior profundidade (PATTON, 1990, p. 13). Segundo MORSE (apud
CRESWELL, 1994, p. 146) as caractersticas de um problema de pesquisa qualitativa
so: (a) o conceito est imaturo devido a uma evidente falta de teoria e pesquisa
anterior; (b) a noo de que a teoria disponvel pode ser imprecisa, inapropriada,
incorreta ou enviesada; (c) existe uma necessidade para explorar e descrever o
fenmeno e para desenvolver a teoria; ou (d) a natureza do fenmeno pode no ser
adequada para medidas quantitativas.
Por outro lado, este trabalho teve o foco no processo de desenvolvimento de DSI ao
invs de suas sadas ou resultados obtidos. Segundo PATTON (1990, p. 95) a pesquisa
qualitativa apropriada para o estudo de processos porque: (1) a representao de
processos requer descrio detalhada; (2) a experincia do processo tipicamente varia
para pessoas diferentes; (3) o processo fluido e dinmico e (4) as percepes dos
participantes so uma considerao chave do processo. Assim, acreditamos que uma
abordagem qualitativa seja a mais adequada para este estudo.

6.4 PROJETO DA PESQUISA

Segundo Yin (1994, p.32-38), existem quatro critrios para julgar a qualidade de um
projeto de pesquisa em geral e de um estudo de caso em particular:
Validade do constructo: estabelecimento de medidas operacionais corretas para os
conceitos sendo estudados. Para aumentar a validade do constructo, deve-se analisar
mltiplas fontes de evidncia, estabelecer uma cadeia de evidncias e fazer com que os
informantes chave revisem o relatrio do estudo de caso.
Validade interna: estabelecimento de uma relao causal, onde se comprova que certas
condies levam a outras condies e onde se eliminam as relaes enganosas. um
problema relacionado somente a estudos explicativos ou causais.
Validade externa: estabelecimento do domnio para o qual as concluses do estudo
podem ser generalizadas. Como os casos em um estudo de caso no so tratados como
amostras, no se pode trabalhar com generalizao estatstica, mas atravs de
generalizao analtica, ou seja, para a teoria e no para um universo ou populao.

67

Confiabilidade: demonstrao de que as operaes de um estudo tais como os

procedimentos de coleta de dados podem ser repetidas, gerando os mesmos
resultados. A operacionalizao da pesquisa deve ser clara e detalhada para que outros
pesquisadores possam repetir o estudo e obter os mesmos resultados.
Neste trabalho, procuramos garantir a validade do constructo definindo as medidas
operacionais conforme sugerido na reviso da literatura, utilizamos mltiplas fontes de
evidncia entrevistando mais de uma pessoa envolvida no processo de desenvolvimento
e solicitamos que os entrevistados revisassem o relatrio aps o seu trmino. Como este
estudo tem carter exploratrio a questo da validade interna no se aplica. Com relao
validade externa, no fizemos generalizaes estatsticas para um universo ou
populao, mas generalizaes tericas atravs dos casos estudados. Por fim,
procuramos obter alta confiabilidade descrevendo detalhadamente os conceitos a serem
estudados e os procedimentos adotados ao longo da pesquisa.

6.5 PLANEJAMENTO DA PESQUISA

O planejamento da pesquisa (research design) a seqncia lgica que conecta o dado
emprico para as questes iniciais de pesquisa do estudo e finalmente, a suas
concluses. Coloquialmente, um planejamento de pesquisa um plano de ao para ir
daqui at l, onde aqui pode ser definido como o conjunto inicial de questes a serem
respondidas, e l algum conjunto de concluses (respostas) sobre estas questes. Entre
aqui e l pode ser encontrado um nmero de etapas maiores, incluindo a coleo e
anlise de dados relevantes (YIN, 1994, p. 19).
Para SELLTIZ (1959, p.50), o planejamento da pesquisa o arranjo das condies
para coleta e anlise dos dados de uma maneira que auxilia combinar relevncia para o
propsito da pesquisa com economia no procedimento.
YIN (1994, p. 20) define quatro aspectos a serem resolvidos no planejamento da
pesquisa: quais questes estudar, quais dados so relevantes, quais dados coletar, e
como analisar os resultados. O autor define cinco componentes de um plano de pesquisa
especialmente importantes (YIN, 1994, p. 20):
1. as questes de pesquisa,
2. suas proposies, se alguma,
3. sua(s) unidade(s) de anlise,
4. a lgica que liga os dados s proposies, e
5. o critrio para interpretar os achados.
Neste trabalho, foram colocadas trs questes de pesquisa, sendo uma principal e duas
secundrias. Para direcionar o estudo, foram propostas nove proposies. A unidade de
anlise foi definida. A lgica que liga os dados s proposies foi delineada atravs de
um modelo conceitual de pesquisa, onde os principais conceitos a serem estudados
foram explicitados e servindo como fundamento para a definio do roteiro para a

68

coleta dos dados. Atravs da anlise dos conceitos do modelo de pesquisa foi possvel
discutir as proposies propostas e interpretar os achados.

6.5.1 Tipos de Projeto para Pesquisa em DSI

SAMBAMURTHY & KIRSCH (2000) analisaram quarenta artigos, publicados nas
quatro principais revistas em SI, que examinavam empiricamente o processo de DSI nas
organizaes, e propuseram quatro formas (ou linhas de contribuio) para estud-lo.
A primeira linha de contribuio denominada orientada a fatores ou sem lgica de
processo inclui os estudos que no focam no processo de DSI em si, mas investigam os
fatores que afetam suas sadas. Os estudos nesta categoria examinam relacionamentos
entre antecedentes e sadas e tratam o prprio processo de DSI como uma caixa preta
(SAMBAMURTHY & KIRSCH, 2000, p.395).
A segunda linha de contribuio denominada processo como explicao inclui os
estudos que no observam nem abordam explicitamente o desenvolvimento de um
sistema, mas a lgica do processo utilizada para explicar os achados
(SAMBAMURTHY & KIRSCH, 2000, p.394). Em tais estudos os pesquisadores
desenvolvem uma histria orientada a processo de um modo indutivo para explicar
como os antecedentes exercem influncia nas variveis de sada (SAMBAMURTHY
& KIRSCH, 2000, p.395).
A terceira linha de contribuio denominada processo como uma categoria de
conceitos inclui os estudos que examinam o fenmeno do processo, mas em apenas um
ponto no tempo, ao invs de investigar como o fenmeno desenvolveu e mudou ao
longo do tempo (SAMBAMURTHY & KIRSCH, 2000, p.394). Nesta categoria, o
significado utilizado para processo dentro de DSI como um conjunto de conceitos
que representam aes individuais e organizacionais (SAMBAMURTHY & KIRSCH,
2000, p.398). Uma caracterstica que distingue esta categoria que os pesquisadores
explicitamente examinam as atividades do processo, as quais so diferentes dos
antecedentes e sadas do processo de desenvolvimento de sistemas
(SAMBAMURTHY & KIRSCH, 2000, p.398). Este uso mais freqente do
significado de processo dentro da pesquisa em DSI.
Finalmente, a quarta linha de contribuio denominada processo como uma seqncia
de eventos inclui os estudos que examinam a seqncia de eventos que compreendem
um esforo de DSI (SAMBAMURTHY & KIRSCH, 2000, p.394). Esses estudos
explicitamente incorporaram em seus projetos de pesquisa a noo de que os eventos
desenrolam-se e mudam ao longo do tempo (SAMBAMURTHY & KIRSCH, 2000,
p.394). Uma caracterstica distinta de tais estudos o foco nos eventos, os quais
representam instncias da ao social dentro do processo de desenvolvimento de SI
(HIRSCHHEIM et al. apud SAMBAMURTHY & KIRSCH, 2000, p.399).

69

Neste trabalho, o processo de desenvolvimento de SI foi estudado como uma categoria

de conceitos. Buscamos analisar o processo de DSI para SIW atravs da descrio de
alguns dos conceitos relacionados a ele. SAMBAMURTHY & KIRSCH (2000, p.398)
citam trs limitaes para este tipo de pesquisa. Primeiro, estudos descritivos sobre
conceitos dentro do processo de DSI no revelam os eventos ou cadeias de interaes
entre os atores humanos que levam a diferentes trajetrias de aprendizado,
comunicao, negociao, participao, envolvimento ou gerenciamento de conflitos
(SAMBAMURTHY & KIRSCH, 2000, p.398). Segundo os mesmos autores, estudos
que coletam dados relacionados a processo em um ponto no tempo no revelam o fluxo
que ocorre dentro do processo de DSI (SAMBAMURTHY & KIRSCH, 2000, p.398).
Finalmente, estudos que coletam dados relacionados a processos em dois pontos
diferentes ao longo do processo de DSI revelam se mudanas ocorreram nas variveis
medidas nos diferentes pontos no tempo (SAMBAMURTHY & KIRSCH, 2000,
p.398), mas no explicam como ocorreram.

6.5.2 Questo de Pesquisa

Este estudo procurou responder a seguinte questo:
COMO est ocorrendo nas organizaes o desenvolvimento de sistemas de
informao baseados na tecnologia Web?
Para responder a esta questo procuramos responder s seguintes questes secundrias:
QUAIS as principais dificuldades e facilidades relacionadas ao
desenvolvimento de novos sistemas tendo em vista a tecnologia Web?
QUAIS foram e POR QUE ocorreram as mudanas no DSI devido utilizao
da tecnologia Web?

6.5.3 Proposies
Cada proposio em um projeto de pesquisa direciona a ateno para alguma coisa que
deveria ser examinada dentro do escopo do estudo (YIN, 1994:21). Sem a definio de
proposies um investigador poderia tentar coletar tudo, o que impossvel de se
fazer (YIN, 1994:22).
Com base no referencial terico e nos objetivos deste trabalho, foram definidas as
seguintes proposies a serem verificadas:
Existem polticas organizacionais que garantem o controle da qualidade no
desenvolvimento de SIW.
Como tem sido crescente a preocupao com a qualidade do processo de
desenvolvimento de SI, acreditamos que as empresas estejam adotando polticas para
garanti-la atravs de modelos tais como o CMM.

70

O processo de desenvolvimento de SIW apoiado por metodologias ou tcnicas

de desenvolvimento, sejam elas j existentes ou desenvolvidas pela organizao.
Uma forma de lidar com a complexidade do desenvolvimento de SI atravs do
emprego de mtodos padronizados e previsveis (VESSEY & GLASS, 1998, p. 100).
Assim, acreditamos que as empresas estejam desenvolvendo SIW atravs do apoio de
metodologias ou tcnicas de desenvolvimento, sejam elas existentes e disponveis no
mercado ou desenvolvidas internamente pela organizao.
Os SIW so representados atravs de modelos formais que descrevem sua
estrutura e funcionamento.
Os modelos permitem abstrair aspectos dos SI permitindo reduzir sua complexidade e
apoiando o desenvolvimento. Acreditamos, portanto, que estejam sendo utilizados no
desenvolvimento de SIW.
O desenvolvimento de SIW baseia-se em abordagens evolutivas ao invs de
seqenciais.
A tecnologia Web torna mais fcil a entrega de novas verses dos sistemas, uma vez que
centraliza o processamento nos servidores Web e no exige que sejam feitas instalaes
nos computadores clientes. Com isso, acreditamos que um dos impactos de o emprego
de estratgias evolutivas ao invs de seqenciais para a construo SIW, uma vez que a
entrega de novas verses tem seu custo reduzido, permitindo que as funes possam ser
desenvolvidas e entregues em intervalos mais curtos e que no seja necessrio
desenvolver grandes conjuntos de funes antes de entreg-las.
O desenvolvimento conduzido principalmente por pessoas com perfil tcnico
em TI.
Embora as primeiras aplicaes que utilizavam a tecnologia Web estivessem voltadas
mais para a divulgao de informaes, onde as questes visuais tinham grande
importncia e o seu desenvolvimento era sido conduzido muitas vezes por profissionais
com perfil mais artstico, acreditamos que os SIW, por apresentarem caractersticas de
SI, sejam conduzidos principalmente por profissionais com perfil tcnico em TI.
As informaes no estruturadas (tais como textos, imagens, udio e vdeo) so
tratadas como informaes estruturadas ou semi-estruturadas, ou seja, existem
mecanismos estruturados para a recuperao de tais informaes e os SIW
baseiam-se mais em montagem dinmica de informao (pginas Web) do que
em informao esttica.
Conforme descrito no referencial terico, uma das formas de classificar as aplicaes de
SIW atravs de sua dinamicidade. Como os SIW so voltados principalmente para
apoio ao negcio, acreditamos que a forma de lidar com as informaes esto mais

71

prximas das estratgias dos SI tradicionais do que dos Web Sites estticos. Assim, os
SIW devem estar baseados principalmente em montagem dinmica de informaes.
Alm disso, como muitos SIW lidam com informaes no estruturadas, provavelmente
devem trat-las de forma estruturada ou semi-estruturada, permitindo utilizar
mecanismos de recuperao, tais como agregaes e consultas estruturadas, tipicamente
empregados nos SI tradicionais.
A validao do SIW pelos usurios feita, principalmente, atravs da
utilizao de prottipos.
O desenvolvimento prottipos na tecnologia Web relativamente simples se comparado
ao desenvolvimento do sistema final que implementa todas as regras de negcio, alm
de fornecer uma viso mais concreta do sistema para os usurios. Assim, acreditamos
que o principal mecanismo de comunicao com os usurios dos SIW seja atravs de
prottipos do sistema do que qualquer outra forma de modelagem.
O desenvolvimento de SIW utiliza conceitos de modelagem vindos da rea de
hipermdia (tais como modelos de navegao, autoria-no-grande, definio
explcita de estruturas de acesso, anlise de relacionamentos e primitivas mais
ricas para a modelagem de dados).
A tecnologia Web utiliza intrinsecamente recursos de hipermdia. Assim, acreditamos
que estejam sendo empregados no desenvolvimento de SIW como forma de melhorar
sua interao com os usurios.
Deve haver grande integrao do SIW com os sistemas existentes.
Conforme descrito no referencial terico, os SIW tipicamente comunicam-se com os
sistemas de informao existentes. Assim, acreditamos que j estejam sendo construdos
de forma integrada ao invs de serem implementados isoladamente, o que exigiria
bastante interveno manual para eventuais trocas de informaes entre eles.

6.5.4 Modelo Conceitual da Pesquisa

A construo de teoria confia em alguns poucos constructos que agrupam uma srie de
detalhes (MILES & HUBERMAN, 1994, p.18). Assim, categorias tais como clima
social, cena cultural e conflito de papis so os rtulos que ns colocamos nos
compartimentos intelectuais contendo muitos eventos discretos e comportamentos
(MILES & HUBERMAN, 1994, p.18). Os rtulos vm da teoria e da experincia, assim
como dos objetivos gerais do estudo visualizado (MILES & HUBERMAN, 1994, p.18).
Defini-los e nome-los para obter mais clareza sobre seus inter-relacionamentos conduz
ao modelo conceitual de uma pesquisa (MILES & HUBERMAN, 1994, p.18).
SAMBAMURTHY & KIRSCH (2000, p. 403) observaram as pesquisas anteriores
sobre processo de DSI e propuseram alguns conceitos chave do processo de

72

desenvolvimento, assim como os principais conjuntos de valores de cada um. A Tabela

10 resume tais conceitos e valores:

73

Conceito chave

Explicao

Tarefas

Trabalho
feito
para
construir um sistema de
informao

Interessados

Pessoas ou grupos de
pessoas envolvidos em um
esforo de DSI o quais tm
um interesse claro na sua
sada

Programa
trabalho

Transaes

Contexto

Estrutura

Sadas

de Motivos dos interessados ou

metas relacionadas ao
esforo
de
DSI.
O
programa de trabalho tem
um introdutor e um alvo
Meios formais e informais
especficos atravs dos
quais
os
interessados
atingem seus programas de
trabalho ou garantem que as
tarefas apropriadas sejam
completadas, e modo da
transao (formal versus
informal)
Fatores influenciais ou
gatilhos que ocorrem fora
da equipe do projeto,
afetando atividades atuais e
subseqentes
Mecanismos
estruturais
especficos
(polticas,
regras, regulamentaes ou
atividades)
que
so
invocados para justificar as
transaes, e modo (formal
versus
informal)
de
invocao da estrutura
Resultados de qualquer
ocorrncia

Conjunto de valores observados

pesquisas anteriores
Planejamento
Estudo de viabilidade
Anlise
Projeto
Codificao
Teste
Implementao
Gerente de projeto
Lder de projeto
Membros da equipe de projeto
Usurios
Gerncia snior
Vendedores
Consultores
Trmino dentro do tempo
Custos dentro do oramento
Satisfao do cliente
Aderncia a padres
Agenda poltica
Negociao
Comunicao
Influncia
Controle
Coordenao
Persuaso

em

Perda de recursos
Risco relacionado tecnologia
Necessidade do negcio

Metodologias (por exemplo Jackson,

Warnier-Orr, engenharia da informao)
Ferramentas de desenvolvimento (por
exemplo, CASE, geradores de cdigo,
ferramentas de teste, ferramentas de
gerenciamento de projetos)
Polticas organizacionais (por exemplo,
desenvolvimento de padres)
Positiva, negativa ou ambas

Tabela 10 Uma viso resumida dos sete conceitos chave e seus valores (SAMBAMURTHY &
KIRSCH, 2000, p. 403)

74

Baseados nos conceitos chave e conjuntos de valores propostos por SAMBAMURTHY

& KIRSCH (2000) e descritos na Tabela 10, construmos o modelo conceitual deste
trabalho, ou seja, os compartimentos intelectuais (ou variveis conceituais) a serem
estudados e como se inter-relacionam. A Figura 11 descreve tal modelo.

1. Contexto

2. Interessados

1.1.

Necessidades do negcio

2.1. Equipe de desenvolvimento

1.2.

Natureza do sistema

2.2. reas de negcio cliente

1.3.

Integrao com sistemas existentes

2.3. Principais usurios

3. Tarefas
3.1. Planejamento e estudo de viabilidade
3.2. Anlise
3.3. Projeto
3.4. Codificao
3.5. Teste
3.6. Implantao

4. Estrutura
4.1. Metodologias
4.2. Ferramentas de desenvolvimento
4.3. Polticas organizacionais

5. Sadas
5.1. Sistema
5.2. Documentao

Figura 11 Modelo Conceitual da Pesquisa

Como o processo de DSI complexo e envolve muitos conceitos chave, adaptamos o

modelo de SAMBAMURTHY & KIRSCH (2000) de forma a considerar, neste
trabalho, apenas os conceitos que descrevem de forma mais direta a construo dos
sistemas de informao para a Web. Assim, a nfase do trabalho est nos conceitos
Tarefas, Estrutura e Sadas. Por outro lado, como algumas informaes de
contexto permitem caracterizar o sistema e seu impacto na organizao que o utiliza,
podendo afetar a estrutura e as tarefas desempenhadas, tal conceito foi includo no
escopo da pesquisa. De forma anloga, o perfil dos interessados influencia as tarefas do
desenvolvimento, tendo sido includo no escopo da pesquisa.

6.5.4.1 Contexto
O conceito Contexto corresponde ao ambiente organizacional em que ocorreu o
desenvolvimento do SI. Foram considerados os seguintes aspectos do contexto:

75

As necessidades do negcio. A literatura sugere inmeras possibilidades de

utilizao de SI para alterao tanto dos processos empresariais quanto da estrutura
organizacional (ALTER, 1996; DAVENPORT, 1994; LUCAS, 1997; LAUDON &
LAUDON, 1998). O nvel do impacto dos SI nas organizaes determina, em
grande parte, o esforo a ser feito no desenvolvimento, podendo influenciar tanto a
estrutura quanto as tarefas desenvolvidas ao longo do desenvolvimento.
A natureza do sistema. Os SI podem ser classificados de vrias formas (OBRIEN,
2001; GORRY & MORTON apud LUCAS, 1997). Cada tipo de sistema pode
influenciar de forma distinta a estrutura e as tarefas desenvolvidas. possvel supor
que abordagens adequadas, por exemplo, para a construo de sistemas de apoio a
decises estruturadas e de controle operacional podem no ser adequadas para o
desenvolvimento de sistemas de apoio a decises no-estruturadas e voltadas para o
planejamento estratgico.
Integrao com os sistemas existentes. o conjunto das regras definidas, atividades
desenvolvidas e produtos gerados que permitiram a interligao do SIW com os
sistemas existentes.
Existem diversos outros aspectos relacionados ao contexto de DSI, tais como risco da
tecnologia e perda de recursos, conforme mostrado na Tabela 10. Tais aspectos no
sero, entretanto, analisados neste trabalho.

6.5.4.2 Interessados
Os interessados so as pessoas ou grupos com interesse na sada de um esforo de DSI
(SAMBAMURTHY & KIRSCH, 2000). Foram considerados os seguintes grupos de
interessados:
Equipe de desenvolvimento. Ela composta pelas pessoas diretamente envolvidas
na construo do sistema, tais como lder de projeto, analistas, projetistas,
programadores, designers, arquitetos de sistema e outros.
reas de negcio cliente. Representam os grupos que encomendaram e
patrocinaram o desenvolvimento do SI. Tais grupos so, geralmente, os maiores
beneficirios do sistema.
Principais usurios. So os representantes dos grupos dos usurios que efetivamente
utilizam o sistema.
possvel que uma mesma pessoa ou grupo assuma mais de um papel no processo de
DSI. Entretanto, para clareza conceitual diferenciaremos os papis desempenhados por
cada um.

6.5.4.3 Tarefas
As tarefas representam todas as atividades para a construo do SI. Foram consideradas
as seguintes tarefas:

76

Planejamento e estudo de viabilidade. Tais atividades podem ter sua importncia

ressaltada ou diminuda conforme o contexto e a estrutura do desenvolvimento.
provvel, por exemplo, que os SI que possibilitam um nvel grande de impacto na
organizao requeiram um planejamento mais detalhado do que aqueles cujo
impacto menor. Da mesma forma, sistemas desenvolvidos atravs de estratgias
evolutivas podem, eventualmente, estar baseados em um planejamento menos
detalhado.
Anlise. Define o problema a ser resolvido. uma atividade crucial para garantir
que o SI atenda as necessidades do negcio. Pode variar com relao ao grau de
formalidade com que feita, mas fundamental em qualquer projeto de DSI.
Projeto. Permite propor a soluo para o problema definido na atividade de anlise.
Atravs do projeto, o modelo arquitetural da soluo delineado. O projeto
representado, geralmente, atravs de diversos modelos. Nos SIW, um aspecto de
grande relevncia do projeto a definio da navegao ao longo do sistema.
Codificao. a converso do projeto em uma ou mais linguagens de programao.
Teste. Representa as tentativas de localizao de falhas no sistema. Tais falhas
podem ocorrer tanto na definio do problema (anlise) e no delineamento da
soluo (projeto), quanto na converso das especificaes para as linguagens de
programao.
Implantao. o conjunto de atividades que permite a utilizao do sistema. Inclui
a carga inicial dos dados, a converso dos dados de outros sistemas, o treinamento
dos usurios, a instalao e configurao dos componentes de software nos
computadores e a substituio do sistema antigo pelo novo.

6.5.4.4 Estrutura
A estrutura representa as polticas e atividades que guiam o desenvolvimento. Foram
considerados os seguintes aspectos da estrutura:
Metodologias. Conforme descrito na reviso da literatura, dificilmente uma
organizao adota uma metodologia de DSI sem nenhum tipo de adaptao ao
contexto. Esta varivel conceitual representa, portanto, a metodologia resultante
destas adaptaes, ou seja, o conjunto das tcnicas utilizadas, assim como sua
seqncia ao longo do desenvolvimento do sistema.
Ferramentas de desenvolvimento. o conjunto das ferramentas utilizadas ao longo
da construo do sistema e inclui as ferramentas de apoio anlise, projeto,
programao e teste.
Polticas organizacionais. o conjunto de polticas referentes ao DSI existentes na
organizao. Inclui as polticas para o controle da qualidade do processo de
desenvolvimento, a utilizao de metodologias e de ferramentas, a padronizao da
documentao gerada, a linguagem de modelagem utilizada, a codificao e o teste.

77

6.5.4.5 Sadas
As sadas so o conjunto de produtos gerados ao longo do DSI. Foram consideradas as
seguintes sadas:
Sistema. So os benefcios proporcionados aos usurios do sistema e dos grupos que
encomendaram e patrocinaram o sistema. preciso ressaltar, entretanto, que tais
benefcios so analisados sob o ponto de vista da equipe de desenvolvimento, ou
seja, so os benefcios gerados aos usurios e clientes conforme percebidos por ela.
Documentao. Conjunto de documentos gerados. Inclui a documentao tcnica, a
documentao de ajuda (help) aos usurios do sistema, a documentao de apoio ao
treinamento e a documentao dos procedimentos de instalao e operao do
sistema.

6.5.5 Unidade de Anlise

A unidade de anlise permite definir o que um caso no estudo. Neste estudo, ela
um projeto de desenvolvimento de um sistema de informao baseado na Web ou de um
mdulo do sistema.
Gostaramos de ressaltar que no trivial determinar o incio e o trmino de um projeto,
pois muitas vezes o desenvolvimento de SI est baseado em abordagens evolutivas,
tornando-o uma atividade contnua. Consideramos neste trabalho que um caso deve
envolver pelo menos um ciclo completo de desenvolvimento, incluindo desde as
primeiras atividades de definio do problema at a implantao do sistema. Em alguns
casos, analisamos mais de um ciclo completo de desenvolvimento. Em outros, embora
ainda no houvesse ocorrido a implantao, os sistemas j estavam sendo homologados
e eram ricos em informao (PATTON, 1990, p.169), tendo sido includos na
pesquisa.

6.5.6 Escolha dos Casos

Segundo PATTON (1990, p.169), a caracterstica que melhor captura a diferena entre
mtodos quantitativos e qualitativos a lgica que guia a seleo da amostra a ser
estudada. Enquanto nos mtodos quantitativos a lgica e o poder da amostragem
dependem da seleo de amostras aleatrias e estatisticamente representativas, as quais
permitiro a generalizao da amostra para a populao, nos mtodos qualitativos a
lgica e o poder da amostragem proposital est na seleo de casos ricos em informao
para estudo em profundidade. Casos ricos em informao so aqueles que permitem
grande aprendizado sobre as questes de importncia central ao propsito da pesquisa
(PATTON, 1990, p.169). Assim, os mtodos qualitativos tipicamente focam em
amostras relativamente pequenas, estudadas em profundidade e selecionadas de forma
proposital (PATTON, 1990, p.169).

78

H diferentes estratgias para selecionar, de forma proposital, casos ricos em

informao. PATTON (1990, p.169) identificou dezesseis estratgias distintas. Neste
trabalho utilizamos a amostragem por convenincia.
Conforme mencionado anteriormente, este estudo considerou mltiplos casos. A lgica
referente ao uso de estudos de mltiplos casos similar lgica para a execuo de
mltiplos experimentos (YIN, 1994, p.46). Cada caso deve ser cuidadosamente
selecionado para que ou (a) preveja resultados similares (uma replicao literal) ou (b)
produza resultados contrastantes, mas por razes previsveis (uma replicao terica)
(YIN, 1994, p.46). Alm disso, no estudo de mltiplos casos cada um deveria servir a
um propsito especfico dentro do escopo geral da pesquisa (YIN, 1994, p.45).
Para selecionar os casos, foram enviados e-mails para quarenta pessoas que haviam
participado ou estavam participando de um curso MBA em Informtica e Tecnologia
Internet da Fundao Instituto de Administrao, convidando-as a participar da
pesquisa. Onze pessoas aceitaram. Foi ento enviado por e-mail um pr-questionrio
(Anexo I) solicitando que descrevessem as caractersticas bsicas de um dos projetos
baseados na tecnologia Web desenvolvidos em suas respectivas empresas. Sete pessoas
retornaram o pr-questionrio e uma delas descreveu dois projetos. Todos os projetos
foram considerados ricos em informao e, portanto, includos na pesquisa.

6.5.7 Coleta de Dados

Segundo PATTON (1990:10) os mtodos qualitativos consistem de trs tipos de coleta
de dados: (1) entrevistas em profundidade, abertas; (2) observao direta; e (3)
documentos escritos. Neste trabalho os dados foram coletados atravs de entrevistas
em profundidade.
As entrevistas em profundidade so teis quando os informantes no podem ser
diretamente observados (CRESWELL, 1994:150) e fornecem informao indireta
filtrada atravs das vises dos entrevistadores (CRESWELL, 1994:150). Em outras
palavras, o propsito da entrevista descobrir o que est na mente de outras pessoas
(PATTON, 1990, p.278).
PATTON (1990, p.280) considera que existem trs enfoques possveis para entrevistas
em profundidade: (1) a entrevista como uma conversa informal; (2) o enfoque da
entrevista como um guia geral; e (3) a entrevista aberta padronizada. Neste trabalho a
coleta de dados foi feita utilizando o enfoque da entrevista como um guia geral. Neste
caso, so listados os aspectos e as questes a serem exploradas ao longo da entrevista
(PATTON, 1990, p.283). As questes no precisam ser abordadas em uma ordem
especfica e servem como uma lista de verificao para garantir que todos os aspectos
foram abordados e o entrevistador deve adaptar tanto as palavras utilizadas como a
seqncia das questes feitas aos respondentes conforme o contexto (PATTON, 1990,
p.283).

79

6.5.8 Protocolo de Estudo de Casos

Para YIN (1994, p. 63) um protocolo de estudo de caso mais do que um
instrumento, ele contm o instrumento, mas tambm contm os procedimentos e
regras gerais que deveriam ser seguidos no uso do instrumento (YIN, 1994, p. 63).
Alm disso, o protocolo a maior ttica para aumentar a confiabilidade da pesquisa de
estudo de caso (YIN, 1994, p. 63).
Na maior parte dos casos foi entrevistada mais de uma pessoa envolvida diretamente no
desenvolvimento. Entretanto, em alguns casos no foi possvel entrevistar mais de uma
pessoa, ou porque a equipe de desenvolvimento havia sido desfeita e no havia como
entrar em contato com seus participantes ou porque a equipe no estava mais no estado
de So Paulo na poca das entrevistas. Todas as entrevistas foram gravadas.
O roteiro das entrevistas est descrito no Anexo II.

80

7. Apresentao e Anlise dos Casos Estudados

Como algumas das empresas solicitaram que seus nomes no fossem divulgados,
optamos por omiti-los em todos os casos. Cada um ser referenciado ao longo deste
trabalho pelo tipo de negcio da organizao.

7.1 CASO EMPRESA

NEGCIOS

DE

SANEAMENTO PORTAL

DE

APLICAES

DE

7.1.1 Introduo
A empresa de Saneamento atua como concessionria de servios sanitrios para atender
s necessidades de saneamento ambiental.
A rea de informtica da companhia organizada em divises de sistemas e uma delas
a responsvel pelo desenvolvimento e suporte das aplicaes de negcios que so os
sistemas que apiam atividades relacionadas ao negcio da empresa. A rea funciona
como um centro de informaes e responsvel por divulgar os procedimentos de
operao dos sistemas, alm de atender a solicitaes de manuteno corretiva e
evolutiva.
As chamadas de suporte eram feitas atravs de meios tradicionais como telefone, fax
e e-mail e a divulgao de informaes era principalmente em papel. Como uma forma
de otimizar o processo, foi desenvolvido um sistema baseado na tecnologia Web
chamado de Portal de Aplicaes de Negcios ou PortalAN.
Em uma primeira etapa, que durou quatro meses, as principais funes do portal foram
desenvolvidas e implantadas. Uma nova funo para permitir o gerenciamento das
solicitaes de manutenes evolutivas e de sugestes de melhorias, chamada de Gesto
de Mudanas, foi desenvolvida e implementada quatro meses aps o trmino da
primeira etapa. Em seguida, novas funes foram e tm sido acrescentadas ao portal de
forma que ele evolua constantemente.
Foram entrevistados, em dezembro de 2002, trs tcnicos que participaram do projeto
como analistas e programadores.

7.1.2 Descrio do Caso

7.1.2.1 Contexto
Necessidades do negcio
A equipe de informtica poderia participar de um curso sobre a tecnologia Active Server
Page (ASP), que permite a construo de aplicativos Web, caso tivesse algum projeto
em que pudesse aplic-la. Como o gerente da diviso de aplicativos de negcios j

81

havia percebido inmeras possibilidades de uso da tecnologia Web em sua rea,

aprovou o treinamento da sua equipe e props o desenvolvimento do portal.
A abertura, pelos prprios usurios dos aplicativos de negcio, de solicitaes de
suporte diretamente atravs da Web e do acompanhamento do seu status, era uma
possibilidade de aplicao da tecnologia.
Uma outra possibilidade era disponibilizar, atravs da Web, treinamentos on-line para
os funcionrios da organizao.
Por outro lado, com a tecnologia Web, seria possvel centralizar diversas das
informaes fornecidas pela rea de informtica, tais como manuais de operao dos
sistemas, notcias sobre os negcios da empresa, documentos relacionados aos sistemas
e sobre os procedimentos comerciais, apresentaes de projetos e arquivos gerados
pelos aplicativos do mainframe.
Natureza do sistema
As principais funes do sistema so: permitir trazer (download) do servidor
documentos de diversos tipos, principalmente manuais, procedimentos de utilizao de
aplicativos da organizao, novas verses destes aplicativos e arquivos de dados
gerados pelos sistemas processados no computador de grande porte; abertura de
solicitaes de suporte de informtica; gesto do contedo do Web Site; e divulgao de
notcias categorizadas por assunto sobre o negcio da organizao.
Enquanto uma parte do sistema est disponvel a todos os funcionrios, outra est
apenas para quem estiver cadastrado. Uma das funes restritas a de divulgao de
notcias relacionadas ao negcio da companhia, as quais so classificadas por assunto e
existe um responsvel por gerenciar o contedo de cada um. Os funcionrios podem se
cadastrar no portal e selecionar os tipos de notcias que gostariam de receber, pois o
sistema faz a filtragem conforme o interesse. Assim, os usurios podem ser assinantes
do Portal, sendo o cadastramento aberto a todos os funcionrios.
A partir do PortalAN possvel utilizar um mdulo de treinamento on-line, que no
integrado, mas apenas acessado atravs do portal. Ele pode ser considerado um mdulo
parte, tendo sido desenvolvido atravs de um outro projeto, razo pela qual no o
incluiremos neste trabalho. De forma anloga, existem ligaes para outros Web Sites
como, por exemplo, um que permite emular o mainframe atravs da Web. Tais Web
Sites sero considerados neste trabalho como outros sistemas.
O sistema adota, predominantemente, a montagem dinmica de pginas. Embora utilize
algumas informaes no estruturadas, tais como os manuais e procedimentos de
utilizao dos aplicativos de negcio, os quais esto fora do banco de dados do portal,
todas as informaes tm algum tipo de estrutura dentro do sistema. Em outras palavras,
as informaes no estruturadas so tratadas de forma semi-estruturada, uma vez que
tm registros no banco de dados que as descrevem.

82

Atualmente, o sistema est na Intranet da organizao e utilizado apenas pelos

funcionrios. Entretanto, com o domnio da tecnologia Web j h a inteno, segundo
um dos entrevistados, de futuramente expandir as funes do PortalAN para uma
Extranet, onde seria disponibilizado o acesso a parceiros da empresa, tais como firmas
de advocacia, empresas especializadas em cobrana, empreiteiras e outras. Antes,
porm, preciso resolver principalmente as questes relacionadas segurana.
A inteno de expandir o portal talvez mostre que o desenvolvimento deste projeto
apenas uma das primeiras iniciativas de utilizao da tecnologia Web nos sistemas de
informao da empresa e que, provavelmente, diversas outras solues sero propostas
conforme a organizao v adquirindo conhecimento sobre a tecnologia Web.
Integrao
Embora o sistema disponibilize arquivos gerados pelos sistemas do computador de
grande porte no h integrao direta com tais sistemas. Dentro do portal existem
ligaes para pginas em outros sistemas, tais como o mdulo de treinamento
distncia e um outro que permite que o usurio utilize a interface Web para acesso aos
sistemas executados no computador de grande porte. Entretanto, apesar de utilizarem a
tecnologia Web tais mdulos esto fora do portal. No h, portanto, integrao deste
sistema com outros.
possvel perceber que as fronteiras dos sistemas muitas vezes no so facilmente
identificadas quando se utiliza a tecnologia Web. No PortalAN, por exemplo, embora os
Web Sites referenciados pelo portal, mas externos a ele, no tenham sido considerados
neste trabalho como sendo parte dele, na empresa de Saneamento esse conjunto de Web
Sites foi percebido como um nico sistema.

7.1.2.2 Interessados
Equipe de desenvolvimento
A equipe de desenvolvimento foi formada por seis tcnicos e um gerente de rea
internos, isto , da prpria empresa, e por um Web designer e um consultor externos.
O trabalho entre os membros da equipe de desenvolvimento foi organizado de forma
que todos pudessem participar de todo o processo, desde a concepo do sistema at sua
implementao. Foram feitas diversas reunies entre os analistas para definir quais
funes seriam disponibilizadas pelo SIW e de que forma elas seriam projetadas.
Antes de iniciar o projeto, a maior parte da equipe de desenvolvimento possua
experincia no mbito de sistemas de grande porte, sendo pouco conhecedora da
tecnologia Web. Nesta fase precedente, os analistas fizeram um curso voltado para o
desenvolvimento Web que, segundo os entrevistados, foi suficiente para conduzir o
projeto.

83

reas de negcio cliente

O projeto foi encomendado pelo prprio gerente da diviso de sistemas responsvel
pelo atendimento s solicitaes de suporte aos aplicativos de negcio da organizao.
Como os analistas haviam feito o curso sobre desenvolvimento para a Web e havia a
demanda para melhorar o processo de atendimento das solicitaes de suporte e de mais
um canal para divulgao de informaes, o projeto foi proposto ao superintendente de
informtica e, uma vez aprovado, a equipe foi montada e iniciado o desenvolvimento.
Ressalta-se que foi financiado pela prpria rea de informtica.
Principais usurios
Os principais usurios do PortalAN so os funcionrios da empresa que utilizam os
aplicativos de apoio ao negcio da empresa, ou seja, mais de mil pessoas. Alm disso,
qualquer funcionrio que deseje receber notcias divulgadas pelo sistema pode se
cadastrar e selecionar aquelas do seu interesse.
Praticamente no houve participao dos usurios do sistema, pois foi uma iniciativa
interna da rea de informtica e j havia um sistema anterior de gerenciamento das
solicitaes de suporte, o que ajudou a definir as funes necessrias do portal. Aps a
entrega do sistema que alguns usurios participaram na forma de comentrios e
sugestes, mas durante o desenvolvimento praticamente no houve envolvimento fora
da rea de informtica.

7.1.2.3 Tarefas
Planejamento e estudo de viabilidade
Por ser uma tecnologia nova e ainda desconhecida pelos membros da equipe, o projeto
foi visto como um piloto na utilizao da tecnologia e no foi feito um planejamento
mais detalhado do sistema, nem um estudo de viabilidade. O gerente da diviso de
sistemas apenas estimou os recursos necessrios para o desenvolvimento em termos de
prazo e equipe.
Anlise
O processo de anlise dos requisitos foi elaborado em conjunto por todos os membros
da equipe de desenvolvimento. Foram feitas vrias reunies onde eram definidas as
funes oferecidas pelo sistema. Conforme surgiam, as idias eram discutidas e, ao
longo do desenvolvimento, o escopo do projeto e suas principais funes foram sendo
definidos. O gerente tambm participou com sugestes sobre as funcionalidades que
deveriam ser incorporadas.

84

Os resultados dessas reunies no foram muito documentados. Provavelmente em razo

da participao ativa de todos os envolvidos e da anlise ter sido feita em conjunto, no
se sentiu a necessidade de registrar o andamento do desenvolvimento.
Projeto
O projeto foi feito de forma similar anlise, nas reunies entre os membros da equipe
as pginas Web eram propostas e discutidas em conjunto. Todos da equipe definiram a
navegao do sistema e dividiram as funes entre eles, de forma que cada um
detalhava o projeto de um conjunto de funes. Como as funes no tinham muita
dependncia entre si elas puderam ser projetadas e desenvolvidas em paralelo.
A navegao foi projetada de forma simples, onde cada opo do menu acionava uma
pgina Web especfica. Alm disso, embora a montagem das telas fosse dinmica com
os dados vindos do banco, a apresentao e as ligaes entre pginas Web eram
predominantemente estticas. Embora o sistema utilizasse informaes semiestruturadas que faziam referncias a blocos de informao no estruturada, tais como
os manuais dos aplicativos, no havia referncias entre tais blocos de informao dentro
do portal. Com isso, as dificuldades de projeto de navegao em grandes espaos de
informao, tpica de aplicaes hipermdia com muitas informaes semi-estruturadas
ou no estruturadas, no ocorreram neste projeto. A navegao no foi percebida pela
equipe de desenvolvimento como um aspecto problemtico do projeto, no sendo
preciso utilizar nenhum tipo de modelagem formal para represent-la.
A comunicao com o designer foi atravs de conversas em que os analistas explicavam
de forma genrica as funes e o designer propunha os formatos das pginas Web em
arquivos na linguagem HTML. Todos os analistas opinaram sobre o formato das
pginas do sistema e isto foi percebido como uma dificuldade para o andamento do
projeto, pois como todos decidiam sobre questes, por exemplo, de cor e fonte de letra,
as discusses acabavam caindo na rea pessoal, conforme descreveu um dos
entrevistados, e obter um consenso era mais difcil. Por outro lado, a prpria discusso
detalhada sobre a aparncia do sistema mostra que, embora fosse um sistema disponvel
somente para funcionrios da organizao, houve uma nfase maior no projeto da
interface do sistema do que tipicamente acontece em desenvolvimento de sistemas no
Web.
Apesar do sistema conter aproximadamente setenta tabelas, no houve representao
formal do modelo de dados. Conforme as pginas Web eram projetadas, as respectivas
tabelas eram acrescentadas ao banco de dados. Cada funo envolvia tabelas que
praticamente no eram usadas pelas outras funes e este paralelismo foi possvel
principalmente pelo fato do PortalAN agrupar diversas funes independentes entre si.
Codificao
A codificao foi dividida por conjunto de funes. Cada analista era responsvel por
implementar um conjunto de telas e todos da equipe participaram da codificao.

85

Para a codificao houve a participao de um consultor externo que j conhecia a

tecnologia Web. Sua participao foi descrita como sendo muito importante, pois j
conhecia a tecnologia e, segundo um dos entrevistados, construiu partes [do sistema]
de forma que a gente no imaginava fazer. Uma das contribuies do consultor foi
conceber um recurso de administrao que, baseado no conceito de objetos, permitia
administrar quase todas as tabelas com somente uma funo. Para o entrevistado, sem a
ajuda do consultor, a soluo que a equipe adotaria seria desenvolver uma funo para
cada tela, aumentando significativamente o trabalho de codificao.
Uma dificuldade citada foi que, pelo fato do desenvolvimento ser isolado e cada
membro da equipe ser responsvel por implementar apenas suas telas, algumas vezes,
no se sabia se a alterao em um ponto afetaria o que outra pessoa estava codificando.
Alm disso, como no havia controle de verses houve alguns problemas com relao
alterao simultnea de recursos.
Houve dificuldade com relao s ferramentas de desenvolvimento Web utilizadas, pois
como eram apenas editores de cdigo em HTML no ofereciam recursos de apoio ao
desenvolvimento.
Algumas dificuldades com relao utilizao da tecnologia foram levantadas, como
por exemplo, o controle que preciso fazer para tratar situaes em que o usurio entra
ou sai do sistema no meio de uma seqncia de telas, ou seja, no meio de uma operao,
pois a tecnologia Web no restringe automaticamente a navegao do usurio.
Teste
Foi montado um ambiente de testes e cada analista testava o conjunto de pginas que
havia desenvolvido. Depois que as funes estavam implementadas, o sistema tornou-se
disponvel para uso interno, para que outros erros fossem detectados. Assim, houve um
perodo em que o sistema operava somente dentro da rea de informtica, permitindo a
correo de grande parte dos erros antes de disponibilizar para os outros usurios.
Essa forma de organizar o teste, com cada analista testando apenas as funes que
implementou, possvel, principalmente, em sistemas como este, onde no h muita
dependncia entre as funes. O teste integrado, por outro lado, foi feito com o sistema
j sendo utilizado internamente pela rea de informtica. Conforme os erros eram
detectados j podiam ser corrigidos, garantindo que, quando o sistema ficasse
disponvel para os usurios de fora da rea de informtica, j tivesse uma certa
qualidade com relao a erros.
Atualmente, com o sistema disponvel para toda a organizao, as novas funes
implementadas so testadas pelo prprio analista que as desenvolveu e colocadas
diretamente no ambiente de produo. Embora com essa abordagem no se consiga
garantir a qualidade do cdigo em termos de erros de programao, ela se justifica pelo
fato do sistema no ser crtico para a empresa e eventuais erros no serem to relevantes

86

para o negcio. Assim, o desenvolvimento e a implantao de novas funes se torna

mais gil do que com uma abordagem mais rgida com relao ao teste.
Uma dificuldade com relao ao teste diz respeito s ferramentas de desenvolvimento
Web utilizadas no permitirem recursos que apiem a correo do cdigo. Outra
dificuldade relatada foi com relao utilizao da tecnologia Web que
esporadicamente gerava erros, como a expirao de pginas, no ambiente de produo.
Tais dificuldades foram contornadas conforme os tcnicos adquiriram conhecimento na
tecnologia Web. Isto mostra que houve, durante o projeto, pouco investimento em
ferramentas. Talvez isso tenha ocorrido pelo fato do projeto ser um piloto para testar
a viabilidade da tecnologia Web e do sistema no ser crtico para a organizao.
Implantao
O tempo de desenvolvimento do primeiro conjunto de funes do sistema foi de
aproximadamente quatro meses. Por um perodo de aproximadamente um ms, a rea
de informtica utilizou o PortalAN paralelamente ao sistema antigo de gerenciamento
de solicitaes de suporte. Aps disponibilizar o novo sistema para toda a empresa o
antigo foi desativado.
Em uma segunda etapa foram entregues funes para o gerenciamento das solicitaes
de manutenes evolutivas, que foram chamadas de Gesto de Mudanas. Ela s
comeou quando a primeira fase j estava implantada. Atualmente, novas funes esto
sendo incorporadas ao sistema e em etapas mais curtas.
No houve treinamento formal para os usurios, mas apenas a divulgao em eventos
internos. Embora boa parte dos usurios no tivesse contato anterior com a tecnologia
Web, eles consideraram fcil a utilizao do sistema.

7.1.2.4 Estrutura
Metodologia
No houve a utilizao de uma metodologia formal para apoiar o desenvolvimento do
PortalAN. A abordagem para o desenvolvimento foi mais iterativa, com os requisitos
sendo definidos ao longo do desenvolvimento e sem nenhuma forma de modelagem
formal do sistema. A nica forma de representao do sistema foi o prottipo das telas
feitos em pginas HTML estticas e que serviram como base para o projeto do sistema.
Em um sistema como este que no crtico para o negcio, que agrupa diversas funes
independentes entre si e que tem como um de seus objetivos testar uma nova
tecnologia, talvez a melhor abordagem seja esta mesmo, pois as funes implementadas
eram simples e no precisavam ser extensivamente representadas atravs de modelos
formais.

87

Os analistas consideraram que ter o projeto de interface antes melhor, conforme

descreveu um dos entrevistados. Entretanto, o modelo de dados no teve tanta nfase do
projeto e talvez tivesse sido melhor especificar de alguma forma tal modelo, uma vez
que o nmero de tabelas era relativamente grande e os dados talvez representassem a
parte mais importante do sistema.
Ferramentas
Cada analista utilizou o editor de sua preferncia, mas todos usaram basicamente
editores visuais de pginas HTML ou ferramentas de hipermdia habilitadas para o uso
na Web. O sistema utilizou tambm o sistema gerenciador de banco de dados Sql
Server, da Microsoft.
Polticas
No existe uma poltica explcita da organizao com relao ao desenvolvimento de
sistemas. Existem polticas de desenvolvimento para os sistemas executados no
computador de grande porte, mas para a Web ainda no.
A empresa est em um processo de definio de sua metodologia oficial. Existem
algumas iniciativas para a utilizao de metodologias de desenvolvimento, mas ainda
no so adotadas por toda a empresa. A rea que desenvolveu o PortalAN tem uma
metodologia que define alguns padres para gerao de documentos ao longo do
desenvolvimento de um sistema, tais como: solicitao de projeto, formao da equipe e
dos usurios, definio de funes, cronograma de atividades e aceite. No h
especificao de documentao tcnica, tais como modelos, a ser produzida ao longo do
processo. Tal metodologia utilizada apenas no desenvolvimento de sistemas no Web
e, portanto, no foi utilizada neste projeto.
Com relao ao desenvolvimento do SIW s foi preciso seguir algumas normas com
relao s cores que poderiam ser utilizadas. Isto talvez mostre que, conforme discutido
anteriormente, mesmo nos SIW internos organizao, h uma dedicao maior ao
projeto de interface do que em sistemas no Web.

7.1.2.5 Sadas
Sistema
O sistema Web permitiu uma melhora na comunicao interna, uma vez que
disponibilizou mais um canal para a divulgao de informaes.
Ele agilizou o atendimento das solicitaes de suporte, pois agora so cadastradas pelos
prprios usurios diminuindo a digitao na rea de informtica. O processo de suporte
tambm ficou mais transparente, pois os usurios podem acompanhar a situao de suas
solicitaes.

88

Por outro lado, o nmero de solicitaes tende a ser mais baixo, uma vez que os
usurios podem consultar os atendimentos feitos a outros usurios em listas de
perguntas mais freqentes, alm de ter acesso mais fcil a todos os manuais de
procedimentos de operao e de apoio aos aplicativos.
Por fim, ficou mais fcil para o gerente da rea definir critrios de atendimento dos
chamados, uma vez que o prprio sistema pode aloc-los aos membros da informtica
conforme o tipo de solicitao.
Documentao
Praticamente no houve documentao tcnica. Foram produzidos apenas alguns
documentos informais descrevendo as primeiras idias sobre o sistema, mas ficaram
desatualizados conforme o projeto avanou.
No foi feita documentao para os usurios, mas apenas um folheto genrico de duas
pginas que foi distribudo em palestras e serviu para a divulgao do portal. Isto
porque a interface foi considerada simples e auto-explicativa.

7.1.3 Comentrios
Embora a empresa tenha algumas iniciativas para padronizar mtodos de
desenvolvimento de sistemas, este projeto no utilizou nenhuma tcnica de modelagem
nem metodologia. Provavelmente no houve tal utilizao porque o projeto era piloto e
no se conhecia adequadamente a tecnologia Web. Por outro lado, o fato de no haver
modelagem de dados, uma atividade j estabelecida em desenvolvimento de sistemas,
mostra que houve pouca preocupao com a representao do sistema, tanto para apoiar
o desenvolvimento quanto para a futura manuteno.
Como no houve representao do sistema e a equipe era relativamente grande, para
evitar os problemas de comunicao entre seus membros as funes foram divididas de
forma a minimizar a dependncia entre eles, ou seja, cada um desenvolveu um conjunto
de funes que eram praticamente independentes das demais. Dessa forma, foi possvel
diminuir a necessidade de modelagem do sistema.
Praticamente no foram utilizados recursos de hipermdia. O projeto foi feito de forma
semelhante ao dos sistemas no Web, com itens de menus acionando seqncias de
telas, mas sem muita navegao entre elas. Alm disso, os dados no estruturados do
sistema foram tratados de forma estruturada ou semi-estruturada, confirmando o
referencial terico pesquisado.
Este caso mostrou uma empresa que est comeando a utilizar a tecnologia Web como
plataforma de acesso a seus sistemas e, para minimizar os riscos, desenvolveu um
sistema de baixo impacto organizacional, mas que atendia diversas demandas para
otimizao de processos internos. Com a aquisio de conhecimento externo, atravs de

89

treinamento e de consultores, a organizao tem conseguido utilizar essa nova

tecnologia com sucesso e, provavelmente, em um futuro prximo passar a utiliz-la em
outros projetos eventualmente de maior impacto organizacional.

90

7.2 CASO EMPRESA DE MDIA SISTEMA DE ASSINATURAS

7.2.1 Introduo
O negcio da empresa de Mdia a publicao de revistas e newsletters relacionados
rea de TI. Ela gera informaes aos negcios e as distribui atravs das mdias
impressas, Web e eventos.
Como no trabalha com assinaturas pagas a empresa precisa qualificar os leitores para
determinar quais publicaes cada um receber. Para isto, foi desenvolvido um sistema
que chamaremos neste trabalho de Sistema de Assinaturas.
O objetivo do sistema de assinaturas era permitir que novos leitores preenchessem o
formulrio de qualificao atravs da Web e que a anlise fosse feita automaticamente
pela organizao. Alm disso, os atuais assinantes tambm poderiam gerenciar seus
dados e seu relacionamento com empresa atravs da Web.
O projeto inicial era desenvolver um sistema CRM (Customer Relationship
Management) especfico para a organizao, que incorporasse todas as funes que
envolviam relacionamento com o cliente, inclusive aquelas relacionadas a assinaturas.
Entretanto, o projeto foi abortado e um sistema CRM pronto (pacote de software) foi
adquirido. Como este pacote no incorporava as funes necessrias para a gesto de
assinaturas, o sistema de assinaturas foi desenvolvido.
Considerando apenas o tempo para implementar as funes bsicas do sistema de
assinaturas o projeto durou trs meses e meio e encontrava-se, na poca da entrevista,
em fase de homologao. A previso era de que seria implantado em janeiro de 2003.
Foram entrevistados, em dezembro de 2002, o coordenador do projeto e um
programador. O programador foi responsvel por implementar as pginas Web e o
coordenador participou da anlise do sistema e do projeto do banco de dados, alm de
implementar as funes processadas no banco de dados. A entrevista foi realizada em
conjunto por solicitao dos entrevistados.

7.2.2 Descrio do Caso

7.2.2.1 Contexto
Necessidades do negcio
O sistema precisava ter uma certa inteligncia para personalizar as perguntas do
formulrio de qualificao conforme o cargo e o porte da empresa do assinante. Ele
deveria permitir tambm analisar o perfil do assinante de forma a sugerir assinaturas de
outros produtos da organizao alinhados com seu perfil.
Antes do sistema, o preenchimento dos formulrios era feito em papel e os
procedimentos para a qualificao dos leitores eram manuais. Alm disso, as bases de

91

dados de leitores eram descentralizadas por publicao. A empresa investiu na

informatizao de seus processos e realizou alguns projetos para o desenvolvimento e
aquisio de novas aplicaes. Dentro dessa iniciativa esteve a compra de um sistema
de gesto dos relacionamentos com os clientes, chamado de CRM (Customer
Relationship Management) e o desenvolvimento tanto do sistema de assinaturas quanto
de outras modalidades.
Antes de desenvolver o sistema de assinaturas, foi feito, tambm com interface Web, um
sistema que permitia o preenchimento dos formulrios para qualificao pelos prprios
leitores. Entretanto, os dados coletados no estavam estruturados de forma adequada, os
formulrios no tinham inteligncia para direcionar as questes conforme o contexto
e todo o procedimento aps o cadastramento dos formulrios era manual. O sistema de
assinaturas foi ento desenvolvido para atender estas deficincias. Embora tenha base
de dados prpria, integrado ao CRM permitindo que todos os processos relacionados
s assinaturas sejam feitos de forma automtica.
A tecnologia Web foi escolhida porque, somente atravs dela, os assinantes poderiam
utilizar o SIW, uma vez que esto fora da empresa. Alm disso, como os outros
sistemas da organizao j esto sendo desenvolvidos na plataforma Web seria tambm,
conforme citou um dos entrevistados, uma questo de conjuntura e praticidade no
desenvolvimento. Isto talvez mostre que a tecnologia Web j comea e ser um padro
no desenvolvimento de novos sistemas. Conforme sejam oferecidos mais recursos de
apoio ao desenvolvimento e ela se torne mais conhecida, acreditamos que a tendncia
que novos sistemas de informao sejam baseados nela.
Natureza do sistema
As principais funes do sistema so: cadastramento de novos assinantes feito pelo
prprio leitor atravs da Web, onde, dependendo do cargo do assinante e do porte da sua
empresa, o sistema permite direcionar o formulrio para que faa as perguntas mais
relevantes em cada situao; gerao de informaes de apoio ao trabalho de
telemarketing, conforme as informaes fornecidas pelo assinante, tais como sugerir
novas assinaturas e outras; renovao de assinaturas e gerenciamento do sistema.
O sistema implementa apenas montagem dinmica de pginas e no h a utilizao de
informaes no estruturadas. Ele tem funes de identificao dos usurios e trabalha
com mecanismos de criptografia das informaes, pois os leitores enviam CPF e/ou
CGC para o sistema.
Ademais, acessado por outras organizaes, mas que o utilizam no papel de clientes.
Em outras palavras, embora os clientes sejam principalmente empresas, as quais podem,
eventualmente, anunciar nas publicaes da empresa de Mdia, o foco do sistema no
B2C, uma vez que direcionado para os leitores e no para os anunciantes.
Atualmente, a tecnologia Web est sendo utilizada como infraestrutura para a
comunicao com os clientes da organizao, mas existe a inteno de, futuramente,

92

oferecer servios via Web para os anunciantes de suas publicaes, partindo assim para
o desenvolvimento de sistemas B2B. Deste modo, este projeto , provavelmente, um
dos primeiros de um conjunto de novos servios que sero disponibilizados atravs da
Web.
Integrao
O sistema de assinaturas foi desenvolvido de forma integrada ao CRM. Enquanto este
guarda todos os cadastros e histricos de relacionamento com clientes da organizao,
os outros sistemas, tais como o de assinaturas, atuam em paralelo e armazenam os dados
especficos para suas funes.
O banco de dados do sistema de assinaturas diferente do sistema CRM. Conforme os
leitores digitam os dados naquele sistema, parte deles (registro do leitor) vai
diretamente para o CRM e parte (informaes sobre a assinatura) para o banco do
sistema de assinaturas. Algumas respostas que esto ligadas mais empresa do que ao
assinante podem alimentar dados do CRM. Cabe ressaltar tambm que, se no houver
registro do leitor no CRM, no h como fazer a qualificao, ou seja, h uma grande
sinergia entre os dois sistemas.
Como resultado dessa integrao, fica mais difcil delimitar as fronteiras de cada
sistema, pois os dados so alocados diretamente nas duas bases e so tratados em
conjunto ao longo do processo de qualificao, alm de serem digitados atravs da
mesma interface. Por um lado, os sistemas foram desenvolvidos atravs de projetos
especficos e possuem bases de dados prprias, podendo ser percebidos como sistemas
distintos. Por outro lado, o fato das duas bases serem totalmente integradas tambm
permite considerar todo o conjunto de funes como pertencendo a apenas um sistema.
No caso dos sistemas desenvolvidos em outras tecnologias no Web, tais como os
pertencentes terceira gerao tecnolgica (PRESS, 1999, p.13), o prprio software do
aplicativo ajudava a definir quais funes eram implementadas e quais estavam fora do
escopo do sistema. Na tecnologia Web, por outro lado, como o sistema fica distribudo
em diversas pginas Web que podem fazer referncias entre si, suas fronteiras no so
facilmente delimitadas.

7.2.2.2 Interessados
Equipe de desenvolvimento
A equipe de desenvolvimento foi formada pelos dois entrevistados. O coordenador
centralizou as atividades de anlise e as atividades relacionadas ao banco de dados
enquanto o programador fez o projeto e a implementao da parte ligada tecnologia
Web. Antes do incio do projeto nenhum dos dois conhecia a tecnologia Web. A falta de
conhecimento na tecnologia no foi, entretanto, uma barreira para escolh-la como
infraestrutura do sistema de assinaturas.

93

reas de negcio cliente

Conforme descrito anteriormente, a base de dados da empresa era descentralizada por
publicao. A idia de unificar as bases de dados dos assinantes surgiu da rea de
informtica e foi apoiada pela rea de Marketing, que financiou o projeto. Os dados dos
clientes estavam distribudos em vrios bancos de dados, um de cada publicao, e
seriam centralizados em uma base nica e tratada pelo sistema CRM. Tal sistema, alm
das outras funes de gerenciamento do relacionamento com os clientes, iria
implementar as funes do sistema de assinaturas.
A rea de Marketing j havia percebido que tratar os clientes de forma descentralizada
trazia algumas dificuldades para o desempenho de suas atividades e, quando a rea de
informtica props o desenvolvimento de um sistema de CRM centralizando as bases, a
rea de Marketing apoiou e financiou a iniciativa.
Assim, neste caso, a necessidade de um novo sistema foi gerada principalmente pela
rea de informtica que era a que tinha mais contato com a tecnologia e, portanto, com
mais condies de perceber antecipadamente as possibilidades oferecidas pela TI. Uma
vez identificadas e divulgadas tais possibilidades, as outras reas da empresa
rapidamente geraram expectativas relacionadas aplicao das novas tecnologias.
Principais usurios
A rea de marketing de circulao responsvel por fazer uma triagem nas
qualificaes das assinaturas e quem emite o parecer final, principalmente para
leitores que no foram qualificados ou que foram classificados em uma faixa de
indeciso, a qual demanda anlise manual para decidir sobre a qualificao. A rea
comercial e de atendimento utiliza as funes gerenciais do sistema.
Por estar totalmente integrado ao CRM, praticamente todas as pessoas da empresa
utilizam, indiretamente, os dados gerados pelo sistema.
A participao no levantamento das necessidades foi feita em conjunto com a rea de
marketing que, conforme descreveu um dos entrevistados, teve participao ativa. A
rea comercial tambm participou do desenvolvimento, mas de forma menos atuante.

7.2.2.3 Tarefas
Planejamento e estudo de viabilidade
No foi feito estudo de viabilidade. Inicialmente, foi feita uma estimativa financeira
para verificar como financiar o projeto, mas no houve um planejamento mais
detalhado do sistema.
Ao longo do desenvolvimento, a empresa se reestruturou algumas vezes, passando de
uma estrutura por produto para uma organizada por mdia. Em seguida, mudou para

94

uma estrutura matricial. Alm disso, houve um aporte de capital externo e a organizao
tornou-se uma sociedade annima. Dessa forma, a estimativa inicial com relao ao
sistema foi sendo alterada a cada reestruturao organizacional.
Por outro lado, a estratgia da empresa com relao a seus sistemas de informao foi
alterada ao longo do tempo. Inicialmente, houve a tentativa de unificar todas as bases de
dados da organizao. Foi ento contratada uma outra empresa para desenvolver um
sistema CRM confeccionado especificamente para a empresa de Mdia. Entretanto, aps
um ano e meio a organizao avaliou que a contratada no estava conseguindo conduzir
o projeto da forma esperada. Com isso, foi comprado um sistema CRM pronto, mas que
no atendia todas as necessidades de informao, dentre elas a qualificao de
assinaturas. Ficou ento definido que o sistema CRM serviria como base central e que
os novos sistemas teriam bases de dados separadas, mas integradas a ele. Portanto, ao
longo do processo, o sistema de assinaturas sofreu alteraes tanto no seu escopo e
quanto na sua funcionalidade.
Embora tenham sido necessrios trs meses e meio para implementar as funes bsicas
do sistema na sua ltima verso, se for considerado desde a primeira at a verso final,
o desenvolvimento levou cerca de um ano e foi feito em paralelo com as outras
iniciativas de informatizao da organizao.
As alteraes sucedidas acarretaram diversas dificuldades. A situao foi comparada
por um dos entrevistados troca de pneu do carro com ele em movimento. Em outras
palavras, a arquitetura do sistema foi sendo modificada ao longo do tempo, dificultando
o planejamento.
Este projeto ilustra como a alterao dos objetivos e do escopo de um sistema pode
influenciar os outros sistemas de informao da organizao. Neste caso, se a
organizao contratada tivesse conseguido desenvolver o CRM da forma como a
empresa de Mdia esperava, provavelmente o sistema de assinaturas e os outros
sistemas de informao representariam apenas funes de um mesmo sistema, ao invs
de representar sistemas integrados, mas distintos.
Anlise
As necessidades e caractersticas do sistema de assinaturas foram sendo determinadas
simultaneamente implantao do CRM, conforme as deficincias deste sistema
tornavam-se conhecidas.
Nesse processo de definio dos requisitos do sistema houve intensa participao do
responsvel pelo sistema antigo de assinaturas, que era utilizado pela rea de Marketing
de Circulao. O usurio de Marketing detalhava as necessidades e o coordenador de
informtica j fazia a modelagem dos dados. No houve documentao formal como
resultado do processo de anlise.

95

As dificuldades encontradas na anlise estiveram relacionadas questo da definio

das necessidades do sistema. Foram citados como principais problemas as mudanas
freqentes ocorridas principalmente por definies inadequadas, decorrentes tanto do
fato do usurio no conseguir descrever sua real necessidade, como do coordenador,
apesar de conhecer bem o modelo de negcio da empresa, muitas vezes no entender
corretamente como o usurio trabalhava e/ou do que precisava. Assim, alteraes em
decises sobre as regras do negcio, tais como solicitar apenas nome dos leitores ou
cadastro completo com CPF/CGC, fizeram com que o sistema precisasse ser reprojetado algumas vezes.
Por outro lado, a validao da anlise foi feita atravs de prottipos operacionais das
pginas Web. Desta forma, eventuais problemas de especificao eram no eram
identificados durante a anlise, mas somente depois do projeto, implementao e teste
da funo.
Aparentemente, um dos problemas da anlise esteve relacionado comunicao entre o
analista e os usurios. Uma forma de tentar contornar, ou pelo menos minimizar, tais
rudos na comunicao seria explicitar, atravs de diagramas visuais e formais ou at
mesmo de descries em linguagem natural, os requisitos do sistema. Tais documentos
serviriam tambm para tentar definir de uma forma mais direta os objetivos e escopo do
projeto.
Projeto
O projeto foi feito em conjunto com a anlise. Aps discutir com os usurios os
requisitos do sistema o coordenador implementava as funes relacionadas ao banco de
dados e o programador desenhava e j implementava as telas. Aps validao do
coordenador sobre as novas funes implementadas, o prottipo operacional era
disponibilizado para os usurios para nova validao. A justificativa para validar o
projeto atravs desses prottipos operacionais foi que, com as ferramentas de
desenvolvimento atuais, o desenvolvimento era rpido, sendo melhor mostrar o
prottipo j operacional, pois os usurios conseguiriam experimentar o sistema. Essa
, realmente, uma das vantagens da utilizao de prottipos operacionais. Como
desvantagem est o custo de alterao quando um problema de anlise ou de projeto
detectado, pois isso s acontece aps a implementao e o teste terem sido realizados.
No houve, portanto, uma distino clara entre anlise e projeto, sendo que as
dificuldades do projeto foram similares s de anlise, ou seja, o re-trabalho. Ao longo
do desenvolvimento, vrias verses de telas operacionais foram mostradas aos usurios
para que validassem ou solicitassem ajustes quando necessrio. Muitas vezes, os
usurios solicitavam funes e pediam que fossem embutidas regras que de alguma
forma restringiam seu trabalho, mas que s percebiam isso na hora de validar os
prottipos. Neste momento eles solicitavam alteraes nas regras que eles mesmos
haviam definido.

96

Embora essa forma de projeto, atravs de prottipos operacionais, permita que os

usurios possam utilizar o prottipo em uma situao real, ela tem a desvantagem de
detectar eventuais problemas com a anlise e projeto apenas aps a implementao.
Assim, uma forma de melhorar o processo talvez fosse a utilizao de prottipos no
operacionais, ou seja, apenas telas sem acesso a dados para a validao dos usurios,
deixando a implementao para quando as telas do sistema estivessem mais estveis.
Talvez assim os problemas de re-trabalho fossem minimizados. Alm disso, deixaria
mais claro para os usurios qual seria o tempo necessrio para desenvolver a aparncia
das telas e para desenvolver o sistema que existe por trs delas, deixando mais
explcito que desenvolver as pginas Web do sistema no apenas uma questo de
desenhar telas como acontece com os Web Sites tradicionais, mas de desenvolver
sistemas.
A modelagem dos dados foi feita no prprio SGBD. Como o sistema foi desenvolvido
de forma integrada ao CRM, o qual tinha uma estrutura j definida, o modelo de dados
do CRM foi utilizado como base para modelar o sistema de assinaturas. Ou seja, foi
includo no banco de dados apenas o que no poderia ser includo ou que no estava
relacionado ao CRM. Assim, tudo o que podia ser colocado no CRM j era escrito
diretamente nele e no houve replicao de dados no sistema de assinaturas.
Embora o sistema de assinaturas seja utilizado principalmente por pessoas externas
organizao, no houve a participao de designer e a disposio das telas foi definida
pelo prprio programador. A navegao foi montada conforme o sistema foi sendo
desenvolvido. Como a navegao do sistema foi projetada de forma simples,
funcionando com a ativao de itens de menu, no foi utilizada nenhuma forma de
representao formal da estrutura de navegao do sistema.
Por fim, a percepo dos usurios com relao tecnologia Web e informtica de
forma geral, os levava a achar que as mudanas no sistema eram mais simples e mais
rpidas do que realmente eram, ou seja, conforme descreveu o entrevistado, eles
querem que as telas mudem de cima para baixo de forma imediata, sem perceber que
existe um sistema por trs. Tal percepo equivocada levava a expectativas irreais com
a relao ao esforo a ser despendido em qualquer alterao ou nova implementao do
sistema.
Codificao
As maiores dificuldades com relao codificao estavam relacionadas tecnologia
Web. Uma dificuldade encontrada foi que vrias caractersticas simples s vezes podiam
ser implementadas de vrias formas e a dificuldade estava em entender e decidir qual
era a melhor no contexto existente. A navegao entre pginas, por exemplo, diferente
nas aplicaes Web das aplicaes no Web. Para transferir informaes de uma pgina
Web para outra existem vrias possibilidades, tais como gravar dados temporrios no
banco de dados, guardar informaes no servidor Web, guardar informaes no
computador cliente, sendo que cada soluo tem vantagens e desvantagens.

97

Outra dificuldade estava relacionada a alguns recursos existentes nas tecnologias no

Web e que ainda no foram incorporados na tecnologia Web, como, por exemplo, a
definio de mscaras que restringissem a entrada de dados conforme certas regras.
Enquanto em outras tecnologias tal recurso era facilmente implementado, na tecnologia
Web a soluo era mais complexa.
As diferentes verses dos navegadores existentes fizeram com que a codificao fosse
mais trabalhosa, uma vez que eles eram de fabricantes distintos ou eram verses
distintas do mesmo fabricante e que no funcionavam da mesma maneira. Para resolver
este problema a empresa selecionou um fabricante, no caso a Microsoft, e implementou
o sistema de forma a funcionar apenas para a famlia de navegadores oferecidos por ele.
Algumas restries da tecnologia Web, como as questes das mscaras e dos
navegadores devem ser contornadas conforme a situao, pois so questes geradas
pelo fato de a tecnologia Web ser recente e ainda estar evoluindo. Assim, alguns
recursos encontrados em outras tecnologias no Web ainda esto sendo incorporados a
esta nova tecnologia.
Com relao diversidade de solues para um mesmo tipo de problema, tal como a
questo da navegao, talvez uma forma de facilitar a seleo da melhor soluo em
cada situao fosse a utilizao de conhecimento externo, por exemplo, atravs de
consultores ou de treinamento na tecnologia. De qualquer forma, o fato de oferecer
diversas alternativas para a soluo de um problema um efeito secundrio de uma
caracterstica positiva da tecnologia, a qual oferece diversas possibilidades de
implementao permitindo projetar os sistemas da forma mais adequada em cada
contexto.
Teste
Aps implementar e testar uma funo, os tcnicos a disponibilizavam aos usurios para
validao. Assim, os usurios alm de validar a funcionalidade do sistema tambm
participaram do teste.
Foi montado um ambiente de teste e outro de produo tanto para o banco de dados
quanto para as pginas Web. Esta forma de teste no utilizada em todas as aplicaes
Web da organizao. Em aplicaes de portais estticos, onde a estrutura do banco de
dados muda pouco em comparao com a estrutura do Web Site, a empresa monta um
ambiente de teste somente para as pginas Web e no para o banco de dados que, neste
caso, utilizado diretamente da produo.
Como o sistema de assinaturas utiliza montagem dinmica de pginas Web, com
informaes vindas do banco de dados, muitas alteraes devem ser feitas no banco de
dados ao longo do desenvolvimento. Assim, acreditamos essa abordagem de teste, onde
tanto as pginas Web quanto o banco de dados tm um ambiente de teste separado do de
produo, foi adequada neste caso.

98

Implantao
Conforme discutido anteriormente, no houve uma definio clara das fronteiras do
sistema de assinaturas, sendo que ficou obscuro at que ponto o projeto do sistema de
assinaturas era um outro projeto e at que ponto fazia parte das adaptaes necessrias
do CRM, podendo tanto ser visto como um projeto separado, mas interligado ao CRM,
quanto como mais um conjunto de funes de um mesmo sistema integrado. Desse
modo, a implantao, da mesma forma que as outras atividades do desenvolvimento,
deve ser analisada em conjunto com a implantao dos outros sistemas. A implantao
do sistema de assinaturas pode, inclusive, ser considerada como mais uma etapa na
unificao das bases de dados.
Em uma primeira etapa, os dados foram reestruturados e centralizados no CRM. Em
seguida, foi feita uma interface que permitisse coletar os formulrios para qualificao
atravs da Web, mas que ainda no armazenassem tais dados na estrutura nova. Foram
ento feitas rotinas que convertessem esses dados da estrutura antiga para a nova. O
sistema de assinaturas foi ento desenvolvido e, com ele, os dados j entravam no
sistema utilizando a nova estrutura centralizada. A ltima etapa, que a de utilizao do
sistema ainda no havia sido completada quando as entrevistas foram concedidas, mas
os dados j tinham sido trazidos para a nova estrutura e o sistema j se encontrava
pronto para ser implantado.
Como dificuldade da implantao foi citada a unificao dos bancos de dados, pois
muitos registros estavam duplicados. Nem todos os registros estavam ajustados na
poca em que as entrevistas foram realizadas, mas quando o sistema de assinaturas
comeasse a ser utilizado, como ele tinha mecanismos para detectar duplicidade,
esperava-se que a qualidade dos dados fosse melhorando conforme novos registros
fossem includos atravs dele.
natural que a centralizao dos dados seja uma dificuldade para a implantao do
sistema unificado, pois como os dados estavam replicados em vrias bases, muitos dos
registros apresentavam inconsistncias. Com relao implantao do sistema de
assinaturas, como ela tem sido feita em etapas, ou seja, antes de disponibilizar a verso
final do sistema uma verso intermediria foi desenvolvida, esperava-se que no
houvesse maiores problemas para a implantao final.

7.2.2.4 Estrutura
Metodologia
No houve a utilizao de nenhuma metodologia formal para apoiar o desenvolvimento
do sistema de assinaturas. A estratgia utilizada foi a iterativa com os requisitos sendo
definidos ao longo do desenvolvimento.
Praticamente no foram utilizadas tcnicas de modelagem formal, sendo que a nica
forma de modelagem do sistema foi o diagrama relacional que foi feito no prprio

99

SGBD. Embora alguns SGBD, como o que foi utilizado neste caso, ofeream recursos
para a modelagem visual das tabelas, eles no permitem que sejam colocadas
informaes do dicionrio de dados, o que normalmente oferecido por ferramentas
CASE.
Como este projeto envolvia diversos sistemas, como o de assinaturas e o CRM, a
utilizao de um CASE como ferramenta de apoio modelagem dos dados talvez
melhorasse a comunicao entre os envolvidos e permitisse manter uma documentao
mais rica. Como o nmero de tabelas, se for includo o CRM, estava em torno de 150 o
porte do sistema talvez justificasse a compra de uma ferramenta CASE.
Por fim, como as pginas Web dos prottipos que foram entregues aos usurios j eram
operacionais, no devem ser consideradas como uma forma de modelagem do sistema
uma vez que elas eram o prprio sistema. Isto porque, qualquer sistema pode ser
considerado um modelo ou abstrao da realidade. Quando mencionamos modelagem
do sistema estamos considerando abstraes ou modelos de um modelo da realidade
(sistema). Um prottipo operacional no uma abstrao do sistema, mas o prprio,
embora esse sistema seja um modelo da realidade.
Ferramentas
Foi utilizado o sistema gerenciador de banco de dados SQL Server 2000, da Microsoft.
Para extrair consultas a este sistema foi utilizado o Microsoft Access. A parte da
tecnologia Web foi desenvolvida utilizando o HomeSite, da Macromedia. Para
implementar a segunda etapa, que foi a do sistema de assinaturas integrado ao CRM, foi
usado o Visual Studio .NET, da Microsoft.
Com relao s ferramentas para desenvolvimento Web a empresa est usando uma
ferramenta moderna e que se enquadra na quarta categoria de ferramentas para o
desenvolvimento Web, segundo FRATERNALI (1999, p. 233), que inclui os editores de
formulrios Web, escritores de relatrios, e assistentes de publicao de bancos de
dados e que oferece vrios recursos de apoio ao desenvolvimento de sistemas de
informao baseados na tecnologia Web.
Polticas
A principal poltica de desenvolvimento a ser seguida no projeto era de que o sistema
deveria ser integrado o mximo possvel ao sistema CRM existente.
Alm da necessidade de integrao, na empresa praticamente no h polticas de
desenvolvimento de sistemas, nem padronizaes a serem seguidas, assim como no
existe nenhuma certificao em qualidade de software. Como a empresa relativamente
nova, ela ainda est estruturando seus sistemas de informao. Se, por um lado, mais
complexo estruturar os sistemas e definir as polticas para o seu desenvolvimento, por
outro, como no existem sistemas legados, a possibilidade de utilizao de tecnologias
modernas, como as verses mais recentes do SGBD e das ferramentas de apoio ao

100

desenvolvimento Web, aliado possibilidade de j construir seus sistemas de forma

integrada, ajudam a organizao a obter o mximo de retorno possvel da TI.

7.2.2.5 Sadas
Sistema
Com o sistema de assinaturas todo o processo de qualificao foi modificado. Quem
preenche os dados o leitor, diminuindo a carga de digitao da organizao. H
tambm a melhora na qualidade das informaes, pois o registro do cliente
automtico, sem nova digitao.
Por outro lado, antes do sistema de assinaturas, o telemarketing j analisava os dados
antes de entrarem no banco de dados. Com o novo sistema, h a necessidade de
verificar alguns dados digitados pelos leitores para garantir sua qualidade.
Como conseqncia da centralizao da base de dados, vrios cruzamentos entre eles
permitem oferecer novos servios aos clientes tais como sugerir novas assinaturas e/ou
convidar automaticamente para participar de eventos promovidos pela empresa. Embora
esse benefcio esteja mais ligado implantao do CRM do que do sistema de
assinaturas, como os dois sistemas so integrados o sistema de assinaturas tambm
contribui para tal benefcio uma vez que tais cruzamentos podem ser feitos on-line no
momento do cadastramento do assinante.
Os leitores tero mais controle dos seus dados na empresa e podero acompanhar mais
de perto as informaes sobre seu relacionamento com a organizao.
Documentao
No foi feita nenhuma documentao tcnica nem para os usurios. Neste caso, a
documentao para os usurios menos importante, pois o nmero de usurios internos
e o tamanho do sistema no justificam a elaborao de documentao de apoio. Quanto
aos usurios externos, as funes que eles utilizam j foram projetadas de forma que
no precisassem de apoio na interao com o sistema.

7.2.3 Comentrios
Este caso mostrou uma empresa em que os principais sistemas de informao para
apoio ao seu negcio ainda esto sendo construdos. Tais sistemas j esto sendo
desenvolvidos utilizando a tecnologia Web e as ferramentas desenvolvimento so
modernas. No h uma distino entre sistemas Web e no Web, pois os sistemas j tm
interface Web e no h sistemas legados.
Uma vantagem neste ambiente que os sistemas j utilizam a tecnologia Web. Por outro
lado, as necessidades de informao so tantas e a urgncia para atend-las tamanha

101

que a empresa acaba no conseguindo definir uma forma mais padronizada para o
desenvolvimento. O planejamento de sistemas acompanha o planejamento
organizacional e, como a prpria estrutura organizacional tem mudado, o
desenvolvimento dos sistemas tem sido feito de forma pouco controlada.
Como os sistemas ainda esto sendo construdos e a prpria empresa est se adaptando
ao seu crescimento, o planejamento dos sistemas se confunde s vezes com o prprio
planejamento organizacional.
A inteno da empresa de, futuramente, desenvolver sistemas que ofeream servios via
Web para os anunciantes de suas publicaes, talvez indique que a tecnologia Web
estar presente nos prximos desenvolvimentos de sistemas de informao na empresa e
que, possivelmente, se estabelea mesmo como o padro para o desenvolvimento de
quaisquer novos sistemas de informao.

102

7.3 CASO EMPRESA DE TI SISTEMA DE VENDA B2B

7.3.1 Introduo
A empresa de TI desenvolve e produz diversas tecnologias de informao da indstria,
alm de oferecer a seus clientes solues e servios que as utilizam.
A empresa tem um conjunto de clientes empresariais que fazem grandes compras
regularmente. A rea de vendas pela Internet sentiu a necessidade de oferecer para este
conjunto seleto de clientes mais um canal para a colocao dos pedidos de compra.
Desenvolveu ento um sistema, que chamaremos neste trabalho de Sistema Web de
Venda B2B.
Neste sistema, so oferecidos produtos e servios de todas as reas da organizao,
desde produtos de microinformtica e impressoras at servios tais como treinamento e
consultoria.
Ele no um sistema nico para todos os clientes, mas um modelo replicado para cada
um. Em outras palavras, tanto o Web Site quanto os arquivos de dados so replicados
para cada cliente autorizado a utilizar o sistema. Existe um ncleo que implementa as
funes bsicas de todos os Web Sites e que serve de ponto de partida para a
implementao final de cada um, ou seja, as adaptaes especficas para cada cliente
so feitas a partir deste ncleo. Os processos de trabalho aps a colocao dos pedidos
de compra so iguais ou semelhantes aos processos que ocorrem quando outros canais
so utilizados. Portanto, o sistema oferece basicamente uma interface Web para a
colocao de pedidos.
Foi entrevistado, em dezembro de 2002, o gerente do projeto. Os dois programadores
que participaram do projeto no estavam mais em So Paulo, no tendo sido possvel
entrevist-los.

7.3.2 Descrio do Caso

7.3.2.1 Contexto
Necessidades do negcio
O sistema de venda B2B da empresa j era feito por outros canais como telefone e fax,
mas havia a necessidade de melhorar o processo. Alm disso, a organizao queria
oferecer maior comodidade para seus clientes empresariais mais importantes permitindo
que pudessem colocar os pedidos de compras a qualquer momento.
A tecnologia Web foi escolhida como plataforma para este sistema no somente porque
oferecia mais um canal de vendas, mas principalmente porque a organizao focada
totalmente em Internet, conforme descreveu o entrevistado. Em outras palavras, as
vendas utilizando a tecnologia Web apoiariam sua imagem institucional.

103

Podemos perceber que embora a tecnologia Web oferea vantagens e habilite os

negcios atravs de um outro canal, no necessariamente a principal necessidade de um
negcio relacionada ao B2B aumentar as vendas, mas, como neste caso, pode ser
reforar a imagem de algum que se posiciona como uma empresa que utiliza
tecnologias modernas. Isso talvez mostre uma expectativa existente de que as empresas
que vendem solues tecnolgicas devam utilizar tais solues para atender suas
prprias demandas.
Natureza do sistema
As principais funes do sistema so: incluso dos pedidos de compras de produtos e
servios; e catlogo personalizado com os produtos/servios que o cliente compra
habitualmente e com as condies de venda personalizadas. O catlogo no oferece
muitos recursos para divulgao dos produtos/servios porque o cliente j os conhece e
compra regularmente.
Como o sistema composto por um conjunto de Web Sites especficos para cada
cliente, no h a necessidade gerenciamento de acesso dentro dele. O controle do acesso
feito pelo sistema operacional onde est o servidor Web. Em outras palavras, definemse quais usurios tm direitos de acesso s pginas Web e, quando algum solicita uma
pgina, o sistema operacional verifica se o usurio tem os direitos necessrios. Tal
abordagem funciona adequadamente quando h uma replicao de Web Sites conforme
foi feito no SIW. Com isso, foi possvel construir o sistema sem ter que implementar o
gerenciamento do acesso, o que deixou a aplicao mais simples e reduziu o tempo de
desenvolvimento.
Com relao montagem dinmica das pginas Web h um equilbrio entre a utilizao
de pginas Web estticas e pginas Web montadas dinamicamente com informaes
vindas de arquivos de dados. Entretanto, as pginas Web mais importantes do sistema,
que so as responsveis por montar o carrinho de compras, as de colocao do pedido
e as do catlogo, so dinmicas. Assim, embora o sistema esteja equilibrado em termos
de nmero de pginas Web estticas e dinmicas, as funes mais importantes utilizam
pginas Web montadas dinamicamente.
O sistema utilizado por outras organizaes que so os principais clientes da empresa
de TI, mas no utilizado por organizaes parceiras, pois h um outro sistema
especfico para elas.
O volume de pedidos varia conforme o cliente. As informaes do catlogo,
principalmente de preos, so atualizadas semanalmente ou quinzenalmente.
Provavelmente, como as alteraes nos dados so mais ou menos freqentes seria
invivel implementar a funo de catlogo com os preos atravs de pginas Web
estticas, pois o esforo para atualiz-las com a freqncia necessria seria proibitivo.
Em outras palavras, embora o sistema apresente uma estrutura replicada, tpica de Web

104

Sites estticos, como a volatilidade das informaes no baixa, o sistema utiliza

montagem dinmica de pginas Web nas suas principais funes.
Com relao ao armazenamento de dados o sistema apresenta uma estrutura simples
sem a utilizao de SGDB, mas de arquivos de dados no servidor Web, embora utilize
apenas informaes estruturadas. Tal soluo est de acordo com a arquitetura de Web
Sites replicados, onde as estruturas de dados, quando tratadas isoladamente por cliente,
podem ser consideradas mais simples em comparao com a complexidade de
estruturas genricas para todos os clientes. Alm disso, com as estruturas de dados
separadas h uma facilidade para personalizar dados por cliente agilizando o
desenvolvimento.
O ncleo bsico foi desenvolvido em dois meses por uma equipe da prpria empresa.
Entretanto, alm do tempo de desenvolvimento do ncleo, a cada novo cliente deve-se
fazer as adaptaes necessrias que podem levar de duas semanas a um ms. Como o
sistema na verdade um conjunto de Web Sites personalizados para cada cliente, esta
arquitetura permite que o desenvolvimento e implantao sejam mais rpidos. Por outro
lado, tal estratgia apresenta limitaes conforme cresce o nmero de clientes atendidos
e de Web Sites implantados.
Portanto, embora a estratgia adotada para este projeto permita agilizar a implantao,
esta uma abordagem mais simples que limita a expanso do sistema, uma vez que
qualquer nova funo ou alterao deve ser replicada para todos os Web Sites. Se fosse
desenvolvido um sistema de informao centralizado e com apenas um Web Site, a
modelagem de dados seria mais complexa, pois deveria acomodar as particularidades de
cada cliente, alm de ser necessrio implementar o gerenciamento de acessos e talvez
ter que utilizar um SGBD. Por outro lado, o nmero de clientes atendidos pelo sistema
poderia crescer mais rapidamente e com menos esforo.
Como a principal necessidade a ser atendida pelo sistema era a de melhorar a imagem
institucional, era preciso disponibiliz-lo para uso o mais rpido possvel, mesmo que
para isto fosse preciso adotar uma arquitetura inadequada do ponto de vista tcnico.
Integrao
O SIW no est integrado aos sistemas dos clientes. E os pedidos de compra devem ser
feitos apenas atravs da interface do sistema.
Ao chegar na empresa, o pedido precisa ser dividido de forma que cada item seja
encaminhado para a rea responsvel pelo seu processamento. As reas apresentam
nveis distintos de automao dos seus processos internos e o sistema est integrado de
forma diferente em cada uma. Enquanto para algumas reas o SIW envia arquivos que
so processados automaticamente por aplicativos no mainframe, para outras so
enviados e-mails descrevendo os pedidos.

105

As reas menos informatizadas so aquelas onde no se consegue automatizar todo o

processamento de pedidos, tais como treinamento, onde cada caso deve ser analisado
separadamente. Por outro lado, as reas que lidam com produtos como
microinformtica tm alto nvel de automao e seus sistemas esto integrados ao SIW.
No houve dificuldade para a integrao com outros sistemas, principalmente dessas
reas mais automatizadas, porque tais sistemas j se comunicavam com outros
aplicativos antes do SIW, sendo que as interfaces j estavam padronizadas e eram bem
documentadas.

7.3.2.2 Interessados
Equipe de desenvolvimento
No foram utilizados tcnicos externos empresa de TI no desenvolvimento. A equipe
foi formada pelo coordenador, que atuou como o lder da equipe, pelo gerente do
projeto, que concebeu o sistema, e dois programadores que implementaram o projeto. A
equipe pertencia prpria rea de vendas pela Internet e no houve participao de
usurios externos a essa rea.
O trabalho foi organizado de forma que o gerente do projeto definiu os requisitos e
projetou a soluo, um programador desenvolveu as pginas estticas e o outro
implementou as dinmicas. Entretanto, como o sistema era pequeno, no havia uma
distino muito clara entre as atividades dos dois programadores. Eles no encontraram
maiores dificuldades no uso da tecnologia Web, pois j a conheciam antes do incio do
projeto.

reas de negcio cliente

O sistema foi uma iniciativa da rea de vendas pela Internet e foi financiado por ela.
Como essa rea tem equipe voltada para o desenvolvimento de sistemas, ela foi
responsvel tanto pelas questes do negcio e suas regras quanto pelas questes
tcnicas do sistema.
Principais usurios
Os usurios do sistema so, alm dos clientes da organizao, todas as partes internas da
empresa chamadas de BRAND. Cada uma responsvel pelas vendas de uma linha
de produto e/ou servio.
A rea de vendas pela Internet foi a responsvel por validar o sistema. Como ela j
conhecia as necessidades dos clientes foi tambm responsvel por definir as funes
bsicas do SIW. Antes de cada nova implantao o ncleo bsico era validado pelos
clientes e eventuais adaptaes eram implementadas.

106

Esta estratgia para a validao do sistema parece ter sido adequada, uma vez que a
equipe j conhecia as necessidades dos usurios e, como a arquitetura era replicada, os
ajustes para personalizar o SIW podiam ser implementados rapidamente.

7.3.2.3 Tarefas
Planejamento e estudo de viabilidade
Como o projeto foi considerado pequeno no houve estudo de viabilidade. O
planejamento foi feito apenas com uma estimativa dos recursos, em termos de pessoal e
tempo de desenvolvimento, e passada para o vice-coordenador de TI para aprovao.
No foi citada nenhuma dificuldade no planejamento.
Acreditamos que para esta primeira verso do sistema, em que seria implementado em
uma arquitetura descentralizada e mais simples, no havia mesmo tanta necessidade de
planejamento.
Anlise
A anlise do ncleo bsico de funes do sistema foi feita baseada na experincia da
rea de vendas pela Internet. Alm dessa parte bsica, cada cliente solicitava adaptaes
ou incluso de novas funes na sua verso. Para determinar estas novas funes o
prprio ncleo bsico era utilizado como prottipo operacional e o responsvel pela
anlise era sempre algum da rea de relacionamento com o cliente da empresa de TI.
Com relao modelagem dos processos internos, como j havia diagramas
representando os processos existentes e como o novo sistema no os alterava
significativamente, foram produzidos apenas alguns desenhos que refletiam as
mudanas em tais processos. Tais documentos foram enviados para as reas
responsveis por processar os pedidos para que conhecessem as mudanas, mas no foi
solicitada validao.
Por j ter experincia no processo de venda pela Internet o gerente do projeto, o qual
concebeu o SIW, no encontrou dificuldades para realizar a anlise do ncleo do
sistema. Por outro lado, as adaptaes solicitadas pelos clientes puderam ser atendidas
sem maiores impactos por causa da estrutura replicada do SIW.
Para um sistema como esse onde a estrutura simples e a equipe de desenvolvimento j
conhece os requisitos do problema, validar a anlise atravs de prottipos operacionais
uma estratgia adequada, uma vez que o sistema pode ser desenvolvido rapidamente e
os usurios, aps experimentar o prottipo solicitam as adaptaes necessrias. Alm
disso, como a estrutura replicada permite que se tenha flexibilidade nas adaptaes, no
crtico fazer uma anlise inicial mais abrangente antes de iniciar o desenvolvimento.
Projeto

107

Pelo fato do SIW no utilizar um sistema gerenciador de banco de dados, a modelagem

de dados foi considerada desnecessria. As estruturas de dados foram dispostas em
arquivos cujos formatos foram definidos ao longo do desenvolvimento.
Para definio da navegao foram criados esboos das pginas Web em arquivos
HTML estticos. A estrutura da navegao foi baseada no Web Site pblico da empresa
de TI, ou seja, o oficial que contm as informaes institucionais e ligaes para os
diversos outros Web Sites da organizao.
No houve a participao de designer, pois foi seguido um manual que definia todas as
padronizaes visuais dos sistemas da organizao que utilizam a tecnologia Web. A
idia de padronizar questes visuais de interface em Web Sites interessante, pois
mesmo sem a ajuda de um profissional com perfil artstico a interface do sistema pde
ser projetada de forma adequada do ponto de vista artstico, alm de permitir
uniformizar a imagem institucional.
No houve uma distino clara entre anlise e projeto, uma vez que os prottipos
operacionais serviam tanto para validar as funes do sistema quanto para mostrar o
projeto. Esta forma de projeto se mostrou adequada para este sistema, considerando sua
complexidade e estrutura.
Codificao
Eventualmente, as adaptaes solicitadas por um cliente tambm eram adequadas para
outros. Devido arquitetura do sistema, as alteraes realizadas em um Web Site muitas
vezes devem ser reproduzidas nos outros. Embora isto no tenha sido citado pelo
entrevistado como um problema, este trabalho de replicao de cdigo pode ser visto
como um efeito colateral da arquitetura do sistema e representa um problema para a
codificao, pois a replicao do cdigo retarda tanto o desenvolvimento de novas
funes quanto a implementao de eventuais correes do sistema.
Teste
O teste era realizado em cada Web Site e ocorria de forma independente das demais
verses do SIW. Como o sistema era simples e a equipe j conhecia a tecnologia Web,
no foram citados problemas com relao ao teste. O fato precisar testar cada verso
no foi citado como uma dificuldade, mas acreditamos que, conforme cresa o nmero
de verses do sistema, assim como o nmero e a freqncia das alteraes,
provavelmente o teste passar a demandar um grande esforo da equipe de
desenvolvimento.
Implantao
Aps o desenvolvimento da estrutura bsica do sistema, foi escolhido um cliente como
piloto e feito acompanhamento para validar as funes. Como so feitas adaptaes a

108

cada nova implantao, a utilizao do piloto no to crtica, pois cada implantao

pode ser considerada um piloto das novas adaptaes.
Conforme discutido anteriormente, algumas das adaptaes solicitadas por um cliente
eram teis aos outros. Uma adaptao citada foi a possibilidade de centralizar o
endereo de faturamento e de entrega em apenas uma filial. Tal caracterstica precisou
ser replicada para todos os Web Sites do sistema. Como, atualmente, cerca de cem
clientes utilizam o sistema, uma nova adaptao requer a alterao em cem verses
diferentes do sistema.

7.3.2.4 Estrutura
Metodologia
Embora a empresa de TI adote uma metodologia para o desenvolvimento de sistemas de
informao, neste projeto ela no foi utilizada. A razo alegada foi a de que o sistema
era pequeno demais.
Podemos dizer que foram adotadas as estratgias: paralela e iterativa. Isto porque, alm
das verses serem desenvolvidas em paralelo, as novas funes tm sido acrescentadas
conforme so solicitadas pelos clientes, havendo pouca preocupao com a anlise e
projeto e validando o sistema atravs de prottipos operacionais. Portanto, apresenta
caractersticas da abordagem iterativa.
Tal estratgia se mostrou adequada, pois j se conhecia, antes do incio do projeto, os
requisitos do negcio sendo possvel iniciar logo o projeto do sistema. Como o objetivo
era utilizar, o quanto antes possvel, a tecnologia Web para disponibilizar um novo canal
de vendas empresariais foi adotada uma arquitetura simples para o projeto. Assim o
prottipo operacional pde ser desenvolvido rapidamente e a ser adaptado s
necessidades de cada cliente.
Quanto linguagem de modelagem foi usada apenas os esboos em arquivos HTML
estticos das pginas Web e os fluxogramas dos processos internos de processamento de
pedidos. Embora tais modelos tenham sido suficientes para o desenvolvimento do
sistema, talvez tivesse sido til representar o modelo de dados tambm. Embora o SIW
no utilize SGBD o modelo dos dados poderia servir de apoio manuteno do sistema
e seria til quando sua estrutura precisar ser alterada, por exemplo, mudando a
abordagem de Web Sites replicados para um sistema de informao nico.
Ferramentas
Para o desenvolvimento das pginas Web foi utilizado um editor de HTML no visual.
A programao foi feita em CGI e PEARL e no teve apoio de ferramenta de
desenvolvimento. O servidor est configurado com UNIX e o servidor Web o Apache.

109

Praticamente no houve a utilizao de ferramentas de apoio ao desenvolvimento.

Mesmo para um sistema deste porte, uma ferramenta que permitisse pelo menos edio
visual do HTML e depurao do cdigo traria agilidade para o desenvolvimento.
Polticas
Uma iniciativa interessante foi desenvolvimento da linha de guias e padres para todos
os Web Sites da organizao. O padro extenso e envolve cores, fontes, tipo de letra,
tamanho, cabealho, definies de tabelas, percentual de alguma cor que pode ser
utilizada nas pginas Web, e tem inclusive catlogo de figuras. Dessa forma, possvel
desenvolver aplicaes Web sem precisar necessariamente de designer e, ao mesmo
tempo, conseguir padronizar a imagem institucional da organizao nos seus diversos
Web Sites.
Os projetos de desenvolvimento de sistemas da empresa de TI devem seguir um
conjunto de padronizaes de cdigo, de sistemas, de documentao, de manuais, etc.
Entretanto, por esse projeto ser pequeno e utilizar a tecnologia na Web no foi
considerada necessria a utilizao de tais padres. Est previsto para 2003 que a rea
de vendas pela Internet comece a desenvolver os SIW conforme os padres internos,
tendo inclusive que responder para auditorias internas. Entretanto, por enquanto, no
existe poltica para a utilizao de tcnicas ou metodologias no desenvolvimento de
sistemas baseados na tecnologia Web.

7.3.2.5 Sadas
Sistema
O sistema Web de vendas B2B permitiu a utilizao de mais um canal de vendas,
agilizando o processo de venda empresarial. A principal mudana interna ocorreu no
setor de atendimento aos clientes para a recepo dos pedidos, pois, com o SIW, os
pedidos passaram a ser digitados diretamente pelos clientes. Dessa forma, os
vendedores puderam melhorar o atendimento aos clientes uma vez que as
intervenes passaram a ser necessrias somente nas situaes mais complexas,
conforme descreveu o entrevistado.
Os outros setores da empresa de TI tiveram impacto menor com o sistema, pois o
processo de venda dentro da organizao, assim como o processamento dos pedidos
continuou parecido com os processos definidos para os canais de venda tradicionais
(telefone, fax e venda direta).
A mudana externa, por outro lado, foi maior do que a interna, pois o fato de permitir
que as empresas comprassem via Web proporcionou um conforto maior aos clientes,
uma vez que no era mais necessrio ter algum da empresa de TI para atend-los e
permitindo que a colocao dos pedidos pudesse ser feita quando fosse mais
conveniente. Alm disso, segundo o entrevistado, os clientes eventualmente possam ter

110

uma reduo nos seus custos de compra, uma vez que o processo de compra empresarial
pode ser simplificado.
Documentao
Quase no foi gerada documentao tcnica. Foram produzidos apenas alguns
diagramas representando os processos internos que seriam alterados com o sistema.
No foi gerada documentao para os usurios, pois o sistema foi considerado simples e
intuitivo.

7.3.3 Comentrios
Este caso talvez mostre que a expectativa que se tem das empresas voltadas para a
tecnologia de informao de que estruturem seus relacionamentos externos,
principalmente com seus clientes, utilizando tecnologias modernas tais como a
tecnologia Web. No importa tanto, pelo menos inicialmente, se a tecnologia Web est
sendo empregada da forma mais otimizada, mas se est sendo utilizada. Essa percepo
guiou todo o desenvolvimento do SIW. A soluo foi baseada em uma arquitetura que
permitisse um desenvolvimento rpido e uma implantao com grande flexibilidade
para adaptao, embora, eventualmente, gere problemas para a manuteno e/ou
expanso do sistema.
Essa arquitetura distribuda em vrias verses, uma para cada cliente, talvez precise ser
repensada e o sistema re-projetado, quando o nmero de clientes crescer
excessivamente e as possibilidades de expanso, tais como comunicao com os
sistemas de compras dos clientes, tornarem-se difceis de ser implementadas. Alm
disso, as manutenes para incorporar novas funcionalidades podem se tornar
freqentes, esgotando a capacidade do sistema. Entretanto, at que tal situao ocorra, a
organizao j vai ter oferecido a seus clientes as vantagens de poder colocar pedidos de
compras atravs da Web, reforando ainda mais sua imagem de empresa voltada para a
Internet.

111

7.4 CASO EMPRESA DE CONSTRUO SISTEMA WEB DE AVALIAO

7.4.1 Introduo
O Grupo a que a empresa de Construo (ou Construtora) pertence atua nos principais
setores de desenvolvimento do pas, tais como Engenharia e Construo,
Empreendimentos Imobilirios, Telecomunicaes, Concesses de Energia e outros.
A avaliao de funcionrios e carreiras dentro do grupo era feita atravs de uma
metodologia de avaliao por competncias chamada sistema Hay. Todo o controle
estava centralizado na rea de Recursos Humanos (RH) e era feito atravs de planilhas
eletrnicas. A empresa queria descentralizar este controle de forma a tornar o processo
de avaliao transparente a todos os gestores do grupo. Foi ento desenvolvido um
sistema que chamaremos neste trabalho de Sistema Web de Avaliao.
O objetivo era fornecer aos gestores informaes sobre cargos e salrios dos
colaboradores e estaria disponvel na Intranet da empresa, mas ainda no havia sido
implantado na poca da entrevista, pois, apesar de j estar pronto e homologado, faltava
a autorizao do responsvel pela rea de RH para iniciar a sua utilizao.
O sistema de avaliao no envia dados para outros sistemas, mas apenas l
informaes de outros dois sistemas, que so o ERP e um sistema de RH, e as agrupa
antes de montar as consultas. Esse agrupamento no on-line e existe um mdulo
especfico para a carga peridica dos dados dos outros sistemas. Durante essa carga so
feitos os processamentos necessrios e os resultados so armazenados na prpria base
de dados do SIW de forma que, quando um usurio solicita algum relatrio, ele possa
ser montado instantaneamente. Portanto, o sistema serve basicamente como uma
interface Web para a montagem de relatrios.
Foram entrevistados, em dezembro de 2002, a coordenadora do projeto e o analista de
sistemas. A entrevista foi realizada em conjunto por solicitao dos entrevistados.

7.4.2 Descrio do Caso

7.4.2.1 Contexto
Necessidades do negcio
Antes do sistema de avaliao, os gestores solicitavam relatrios de anlise salarial para
o RH que os gerava manualmente atravs de um controle em planilhas eletrnicas no
padronizadas. Como o volume de solicitaes era grande o desenvolvimento do sistema
Web de avaliao foi uma forma de melhorar esse processo.
J era utilizado um sistema de Gesto de RH adquirido pronto (pacote de software),
que no atendia adequadamente as necessidades de acompanhamento de cargos e
salrios. O sistema de avaliao no substituiu o sistema utilizado, mas acrescentou

112

novos recursos ao RH atravs das consultas geradas. Cabe ressaltar que os sistemas
ERP e de Gesto de RH eram distintos, e o ERP no era utilizado para as atividades de
RH atendidas pelo outro sistema de Gesto.
A tecnologia Web foi escolhida principalmente pela possibilidade de fcil acesso ao
sistema.
Natureza do sistema
As principais funes so: mostrar as ltimas movimentaes salariais dos funcionrios
dentro da companhia; relacionar as informaes de cargos e salrios com os nveis
estabelecidos pelo sistema Hay, permitindo um acompanhamento na evoluo salarial
e da carreira do colaborador e podendo, inclusive, sugerir movimentaes tanto salariais
quanto de cargo dentro da organizao.
Todos os usurios so identificados por senha e o sistema gerencia o acesso s
informaes conforme o cargo do usurio. Ele utiliza predominantemente montagem
dinmica de pginas Web com as informaes trazidas do banco de dados. O sistema de
avaliao relativamente pequeno, com cerca de quinze tabelas e emprega apenas
informaes estruturadas. O desenvolvimento durou cinco meses, mas a equipe no
dedicou tempo integral ao projeto, pois freqentemente precisava executar outras
atividades.
O sistema utilizado por diversas empresas, embora todas pertenam ao grupo da
Construtora, e pode ser considerado uma Intranet.
Integrao
No houve problema para realizar a integrao, pois o analista de sistemas era o
responsvel tanto pelo sistema ERP quanto pelo de Gesto de RH e j os conhecia bem.
Por outro lado, como o sistema no exportava dados, mas apenas importava e
consolidava os dados externos, era de se esperar que a integrao no apresentasse
maiores problemas durante o desenvolvimento.

7.4.2.2 Interessados
Equipe de desenvolvimento
O desenvolvimento foi realizado sem a utilizao de pessoas externas organizao e a
equipe foi composta por um analista de sistemas, que foi o responsvel por toda as
especificao e projeto, e um programador, que, alm de desenvolver toda a parte que
envolvia a tecnologia Web, definiu o design da aplicao. A coordenadora do projeto
participou das etapas iniciais onde foi estabelecido o escopo e as principais funes do
projeto.

113

O trabalho foi organizado de forma que a coordenadora do projeto e o analista fossem

responsveis pelas especificaes do sistema. O analista detalhava o projeto e as regras
de negcio e implementava as funes do banco de dados, enquanto o programador era
responsvel por implementar a parte referente tecnologia Web.
O analista de sistemas no conhecia a tecnologia Web antes do incio do projeto, mas j
tinha experincia em desenvolvimento de sistemas de bancos de dados. O programador,
por outro lado, j conhecia a tecnologia Web antes do incio do projeto, mas tinha uma
experincia maior no desenvolvimento de Web Sites tradicionais do que no
desenvolvimento de sistemas de informao. Isso foi considerado um problema pelos
entrevistados, pois o programador desenvolvia com dificuldade as partes do sistema que
embutiam uma lgica mais complexa.
Esta situao talvez possa ser explicada pelo histrico da tecnologia Web. Como tal
tecnologia comeou a ser utilizada principalmente no desenvolvimento de Web Sites
com muitos recursos visuais e pouca lgica de programao, muitos profissionais que
conhecem a tecnologia Web tm experincia apenas em desenvolvimento de Web Sites
tradicionais e pouca em desenvolvimento de sistemas. Em outras palavras, muitas vezes
os desenvolvedores Web no tm a mesma lgica de programao que outros tipos de
programadores com outras experincias, conforme resumiu um dos entrevistados.
Embora j tivessem sido desenvolvidos outros projetos Web na organizao, esse foi o
que teve maior interao com uma base de dados e que implementava mais regras de
negcio. Os outros sistemas Web envolviam basicamente Web Sites quase totalmente
estticos com pouco acesso a bases de dados e voltados para a divulgao de
informaes.
reas de negcio cliente
A rea de RH, por ser a que mais tinha interesse em melhorar a forma de calcular as
regras para a avaliao dos colaboradores da empresa, foi quem encomendou e
financiou o desenvolvimento do sistema. Dois usurios, pertencentes ao setor de RH,
participaram da validao do SIW. A validao tinha como objetivo tanto validar
quanto testar o sistema.
Principais usurios
Os principais usurios do sistema so a rea de RH e todos os gestores do grupo da
Construtora. Embora os gestores tambm utilizem o sistema, eles no tiveram
representante para acompanhar e validar o desenvolvimento. A rea de RH participou
do planejamento e da validao do sistema.
O fato de apenas o RH acompanhar e validar e de no haver participao dos gestores,
talvez possa ser explicado porque os recursos oferecidos pelo sistema apiam as
funes operacionais do RH, ou seja, sem o sistema essa rea quem deve gerar,
atravs do conjunto de planilhas eletrnicas e do sistema de Gesto do RH, as consultas

114

solicitadas pelos gestores. Com o sistema Web de avaliao esse trabalho torna-se bem
menor e o RH pode focar mais nas atividades de anlise dos dados. Os gestores, por
outro lado, utilizaro o sistema apenas como um instrumento a mais de gesto, ou seja,
como apoio a decises, sem maior impacto nas suas tarefas operacionais. Assim,
provavelmente o interesse dos gestores no sistema no to imediato quando da rea de
RH.

7.4.2.3 Tarefas
Planejamento e estudo de viabilidade
Conforme descrito anteriormente, a identificao do problema partiu rea de RH, a qual
forneceu para a rea de informtica um documento formal detalhando suas necessidades
e descrevendo o escopo do projeto. A equipe e o cronograma para o desenvolvimento
foram definidos pela coordenadora do projeto.
Como o projeto era relativamente pequeno no houve a necessidade de um estudo de
viabilidade. O planejamento foi feito de forma mais detalhada do que a habitual na
empresa, principalmente devido ao estilo do representante do RH, o qual preferiu
documentar toda a proposta do projeto. Tal iniciativa foi importante para que o projeto
fosse desenvolvido de forma adequada e, segundo os entrevistados, em parte por causa
deste planejamento, no foram citadas dificuldades com relao definio do sistema.
Anlise
O documento fornecido pela rea de RH continha, alm do escopo, uma descrio
inicial dos requisitos do sistema, podendo ser considerado tanto um produto do
planejamento como da anlise. O detalhamento da anlise do sistema foi feito com base
nessa descrio inicial, mas no gerou documentao que descrevesse o resultado dessa
atividade.
A atividade de anlise foi realizada pelo analista de sistemas em conjunto com a
coordenadora e com o representante do RH. O desenvolvimento s comeou quando
todas as funes e regras de negcio j estavam detalhadas e aprovadas pela rea
usuria.
Pelas caractersticas do sistema Web de avaliao, acreditamos que a abordagem da
anlise foi adequada e, embora uma descrio mais formal fosse til como
documentao do sistema, o fato de detalhar as regras de negcio e as funes antes do
incio da construo do sistema pode ser considerado um aspecto positivo do
desenvolvimento, alm de permitir minimizar posterior re-trabalho.
Projeto
Como a rea de informtica j conhecia bem os processos de trabalho do RH no houve
dificuldade para detalhar o projeto, o qual foi feito pelo analista de sistemas, utilizando

115

principalmente prottipos das telas desenhados a mo. Somente aps a validao da

rea usuria que os prottipos foram passados para o programador para
implementao.
A navegao foi projetada de forma simples, basicamente com a opo de solicitar
consultas. Aps validar usurio e senha, o sistema filtra os dados que podem ser
acessados e j direciona para a tela de consulta, praticamente no havendo navegao.
Depois disso, possvel detalhar as informaes fornecidas pela consulta.
Como o sistema seria disponibilizado internamente e a navegao era simples, a questo
do formato da interface no foi considerada to importante. Alm disso, pelo fato do
programador ter experincia em desenvolvimento de pginas Web, no houve a
necessidade de algum com o papel mais artstico, tal como um designer.
O projeto do banco de dados foi feito com base nos sistemas existentes e nas regras para
a consolidao dos dados. No houve problema para a modelagem dos dados, pois a
equipe de informtica j conhecia o sistema de Gesto de RH, o ERP, assim como as
planilhas de clculo utilizadas pelo RH. Como apoio modelagem foi utilizada uma
ferramenta grfica que permite o desenvolvimento de diagramas relacionais.
A forma como o projeto de interface foi validado foi muito interessante e adequada,
pois o esforo para desenvolver os esboos de telas feitos a mo antes de iniciar o
desenvolvimento bem menor que o esforo para a sua implementao. Assim, embora
tenha havido re-trabalho aps algumas telas j estarem operacionais, este no foi
apontado como um problema. Isso talvez indique que uma validao inicial de
prottipos de telas pode ajudar a minimizar os problemas de comunicao entre os
usurios e a equipe de desenvolvimento. Alm disso, considerando que a interface do
sistema era simples, a utilizao de prottipos feitos a mo minimiza o esforo para sua
elaborao, agilizando o desenvolvimento.
Codificao
Como o programador no tinha experincia no desenvolvimento de sistemas de
informao, mas em Web Sites convencionais, houve dificuldade durante a codificao.
Conforme relatado por um dos entrevistados, o programador reconheceu que os
sistemas por ele desenvolvidos at ento no apresentavam as caractersticas do sistema
Web de avaliao, tais como diversidade de regras e de tratamentos de dados, e selees
de dados complexas.
Para agilizar o desenvolvimento, o analista de sistemas assumiu algumas atividades de
codificao e aumentou o nvel de detalhe do projeto, especificando as regras
minuciosamente, de forma a contornar algumas deficincias do programador.
A maior dificuldade na codificao foi conseqncia do perfil do programador, uma vez
que por conhecer melhor o desenvolvimento visual sua ateno estava mais voltada para

116

o formato de sada das pginas do que para a implementao correta das regras de
negcio.
Por outro lado, como o sistema utilizava informaes de duas bases distintas, era mais
difcil garantir a integridade dos dados, uma vez que freqentemente eram atualizados
em apenas uma das bases. Foi preciso desenvolver rotinas de controle que tratassem os
dados inconsistentes na prpria aplicao Web. Isso exigiu um grande esforo, sendo
considerado uma das dificuldades relacionadas codificao.
Teste
Aps implementar e testar um conjunto de funes o programador passava para o
analista para que fosse feito um novo teste. As funes eram colocadas para
homologao dos usurios do RH, tendo sido realizadas em vrias etapas. Como
existem trs ambientes de ERP (teste, homologao e produo) e dois para a aplicao
Web (teste e produo), os mesmos foram combinados de forma a testar nas seguintes
situaes: aplicao Web no ambiente de teste com banco de dados de teste; aplicao
Web no ambiente de teste e banco de dados em homologao; e aplicao Web em
ambiente de produo e banco de dados em produo. Assim, foi possvel garantir uma
boa qualidade do sistema homologado.
Como o programador no tinha muito conhecimento de banco de dados, freqentemente
entregava telas com problema na seleo dos dados. Tal fato foi descrito como uma das
principais dificuldades relacionadas ao teste.
Os erros causados pela falta de integridade entre as bases de dados foram, por outro
lado, os mais difceis de detectar, pois ocorriam em momentos em que um dado j havia
sido atualizado em uma base, mas no na outra. No ambiente de produo do ERP era
possvel simular tais inconsistncias porque o sistema era atualizado constantemente, o
que no acontecia nos ambientes de teste. Portanto, a maior parte destes erros s foi
detectada durante a homologao, sendo considerado uma das principais dificuldades
do teste.
Implantao
At o momento da realizao da pesquisa o sistema ainda no havia sido implantado. A
estratgia de implantao seria utilizar, inicialmente, apenas no RH e somente depois
seria disponibilizado aos gestores.

7.4.2.4 Estrutura
Metodologia
No houve utilizao de metodologia de desenvolvimento formal. O desenvolvimento
foi baseado principalmente na prototipagem de telas. Pelas caractersticas do projeto,
como porte pequeno e processos simples, a utilizao de metodologia no foi percebida

117

como sendo necessria. A estratgia de desenvolvimento apresenta caractersticas da

abordagem iterativa, onde o prottipo refinado at atender adequadamente as
necessidades dos usurios.
A nica forma de representar formalmente o sistema foi atravs de diagramas entidaderelacionamento. Para este projeto, onde o modelo de banco de dados era de grande
relevncia e a parte implementada na tecnologia Web no envolveu navegao
complexa, no houve a necessidade de diagramas para representao da navegao.
Alm disso, como no haveria impacto significativo nos processos de trabalho da
organizao, tambm no foi preciso model-los.
Ferramentas
Para desenvolver a parte do sistema que envolveu a tecnologia Web foi utilizada a
ferramenta Dreamweaver, da Macromedia, que voltada principalmente para o
desenvolvimento visual das pginas Web. O SGBD utilizado foi o SQL Server, mas as
regras de negcio foram implementadas na tecnologia Web ao invs de residirem no
banco de dados. Como ferramenta de modelagem foi utilizado o VISIO, que permite
vrias formas de diagramao, embora tenha sido utilizado neste projeto apenas para a
modelagem de dados.
A ferramenta de apoio ao desenvolvimento Web oferece recursos para montagem visual,
mas no apresenta suporte para o desenvolvimento de lgica de programao. Talvez a
utilizao de uma ferramenta com mais recursos de apoio programao agilizasse o
desenvolvimento.
Polticas
No h uma metodologia de desenvolvimento de sistemas padronizada para toda a
empresa. Mesmo a documentao mais formal, gerada durante o planejamento do
sistema, foi iniciativa do usurio da rea de RH, mas no poltica da organizao.
Como a Construtora utiliza vrios pacotes de software existem algumas normas para a
documentao dos sistemas e manuais de usurio, mas so descries macro e no
detalham a parte tcnica do sistema.
Para projetos maiores existem regras para estudo de viabilidade, planejamento, mas
como esse sistema era de porte menor no se justificou o uso de tais instrumentos.

7.4.2.5 Sadas
Sistema
A organizao contrata servios de diversas prestadoras. As prestadoras tm tabelas
distintas de salrios e formas distintas de clculos sobre carreiras. Assim, a automao
deste processo foi de grande importncia, uma vez que, com os procedimentos

118

executados de forma manual, a montagem dos relatrios para os gestores exigia grande
esforo do RH.
Embora ainda haja controvrsia, dentro da empresa, sobre a adequao da
descentralizao das informaes sobre cargos e salrios, o aumento da transparncia
dessas informaes pode ser considerado um benefcio gerado pelo sistema.
Por outro lado, um aspecto que talvez tenha sido at mais importante que os outros dois;
diz respeito introduo do sistema, foi necessria a padronizao dos procedimentos
de clculo, uma vez que o uso da tecnologia de banco de dados induz estruturao dos
dados. Antes do sistema, os clculos estavam distribudos em diversas planilhas e no
havia tal padronizao.
Por outro lado, o desenvolvimento do sistema Web de avaliao fomentou a
padronizao dos procedimentos de clculo, os quais estavam, antes do sistema,
distribudos em diversas planilhas. Tal padronizao foi considerada pelos entrevistados
como o principal benefcio do sistema.
Documentao
De documentao tcnica foi gerado apenas o modelo de dados. Um outro documento
produzido foi a descrio inicial do sistema e do seu escopo. Quanto documentao
para os usurios foi feito um manual explicando as telas do sistema.
Uma parte que talvez pudesse ter sido mais documentada, foi o conjunto de regras de
negcio implementadas na aplicao Web. Se tais regras tivessem sido definidas mais
formalmente, talvez fosse possvel criar condies para orientar o teste do sistema.
Alm disso, sem tal documentao, quando houver necessidade de alterar ou entender
qualquer regra, ser preciso analisar o cdigo da aplicao Web.

7.4.3 Comentrios
Este caso mostrou o desenvolvimento de um sistema que agrega informaes de outros
sistemas e as disponibiliza para um conjunto amplo de usurios. Como os outros
sistemas j estavam sendo utilizados, o de avaliao foi planejado de forma a importar
os dados necessrios e disponibilizar a montagem de consultas. A tecnologia Web foi
utilizada basicamente para facilitar o acesso ao sistema.
O fato de utilizar tecnologia Web no acarretou diferenas significativas na forma de
construir o sistema, pois no foram utilizados recursos de hipermdia, nem o sistema
lidava com informaes no estruturadas. As principais dificuldades citadas ao longo do
desenvolvimento no estiveram relacionadas a questes ligadas tecnologia Web, mas a
aspectos freqentemente encontrados no desenvolvimento de sistemas de informao
tradicionais.

119

7.5 CASO EMPRESA DE FAST-FOOD SISTEMA DE PEDIDOS VIA WEB

7.5.1 Introduo
A empresa de Fast-food abrange uma rede de restaurantes (tambm chamados de lojas),
alguns da prpria empresa e outros em regime de franquia.
Com o objetivo de oferecer um novo servio aos clientes, uma das lojas franqueadas
desenvolveu um servio de entrega em domiclio, o qual chamaremos neste trabalho de
Entrega, com pedidos feitos atravs de um CallCenter. Como os resultados foram
bastante positivos, a empresa de Fast-food resolveu estender o servio aos outros
restaurantes. Depois de implantar o Entrega em algumas lojas, a empresa decidiu
permitir que os pedidos tambm pudessem ser feitos atravs da Web. Foi ento
desenvolvido um sistema que chamaremos neste trabalho de Sistema de Pedidos via
Web.
Foi entrevistado, em janeiro de 2003, o coordenador do projeto. Como a equipe de
desenvolvimento no estava mais em So Paulo, no foi possvel entrevistar outros
integrantes.

7.5.2 Descrio do Caso

7.5.2.1 Contexto
Necessidades do negcio
A empresa de Fast-food tem uma rea de operaes, chamada neste trabalho de Novos
Segmentos, que desenvolve novas formas de atendimento ao cliente e que identificou,
por parte dos consumidores, uma procura por servios atravs da Web. Portanto, a
imagem institucional da empresa foi uma das principais razes que levou escolha da
tecnologia Web como plataforma tecnolgica do sistema. Por outro lado, a tecnologia
permite que os consumidores coloquem os pedidos diretamente na Web, oferecendo
maior comodidade e otimizando o Entrega.
O Entrega envolve todo o processamento dos pedidos feitos via CallCenter e via Web,
alm da logstica de entrega. Sob a tica do negcio, o sistema de pedidos via Web
representa apenas um conjunto de funes para a colocao dos pedidos que fazem
parte do Entrega. Do ponto de vista da tecnologia, o sistema de pedidos via Web
representa um novo sistema de informao, o qual funciona de forma integrada aos
outros sistemas que operacionalizam o Entrega.
Natureza do sistema
As principais funes do sistema so: cadastro de usurios com os respectivos
endereos; cadastro das regies atendidas pela empresa de Fast-food e quais lojas

120

atendem cada regio; catlogo de produtos; carrinho de compras; e acompanhamento

do status dos pedidos.
Todos os usurios do sistema so identificados, tanto os clientes quanto os usurios
administrativos. Para utilizar o sistema os consumidores precisam cadastrar-se,
recebendo um usurio e uma senha. No momento do cadastro o sistema solicita o CEP e
o nmero do local de entrega, para que seja possvel verificar se o local est dentro da
rea coberta pelo Entrega, assim como identificar a loja que dever atend-lo. Ao
identific-la, o sistema permite personalizar o catlogo de produtos, pois nem todos os
produtos podem estar disponveis em todas as lojas, alm de poder haver variao nos
preos conforme o restaurante.
A maioria das pginas Web do sistema montada dinamicamente atravs de uma base
de dados. Os pedidos so armazenados em um DataCenter, o qual armazena tambm os
pedidos feitos via CallCenter.
O sistema relativamente grande, com cerca de cem tabelas, e o desenvolvimento
durou aproximadamente sete meses. O sistema estava em homologao e seria
implantado como piloto em uma das lojas na poca que a entrevista foi realizada.
Integrao
O sistema de pedidos via Web est integrado de tal forma aos outros sistemas de apoio
ao Entrega que no h uma fronteira clara entre eles. Muitas vezes o entrevistado
mencionava questes relacionadas entrega em domiclio e no diferenciava o projeto
de pedidos via Web do restante do Entrega, evidenciando talvez que do ponto de vista
do negcio o sistema nico.
Existem outros sistemas da organizao que tambm so integrados ao sistema de
pedidos via Web. Para determinar os preos dos lanches em cada loja, por exemplo,
preciso comunicar-se com um outro sistema de informao que centraliza o
gerenciamento de preos, ou seja, o sistema de pedidos via Web no contm tabelas de
preos e, sempre que necessrio, busca on-line os dados desse outro sistema.
Outro exemplo que o sistema Web e o do CallCenter so integrados de tal forma que
possvel obter informaes pela Web de um pedido gerado via CallCenter, sendo o
inverso tambm verdadeiro. Tal integrao, conforme mencionado anteriormente,
tornou o sistema bastante complexo.

7.5.2.2 Interessados
Equipe de desenvolvimento
O projeto foi totalmente desenvolvido por uma empresa contratada e somente o
gerenciamento foi realizado pela empresa de Fast-food. A equipe de desenvolvimento
foi composta por um coordenador da empresa de Fast-food, e os profissionais da

121

empresa contratada, ou seja, um lder de equipe, dez analistas/programadores e dois

designers. Houve tambm a participao de um usurio que foi o dono do projeto,
chamado de owner pelo entrevistado.
O trabalho foi organizado de forma que todas as atividades de anlise, projeto e
implementao fossem efetuadas pela contratada, mas com grande interao com o
coordenador do projeto, o qual gerenciou toda a parte tcnica e foi o responsvel pela
validao das entregas da contratada.
Embora o coordenador no conhecesse a tecnologia Web antes do incio do projeto os
profissionais da empresa contratada j a conheciam.
reas de negcio cliente
O desenvolvimento do sistema foi proposto inicialmente pela rea de operaes, que
responsvel por todas as operaes dentro dos restaurantes. A necessidade surgiu da
tentativa de desenvolver uma nova forma de atender o consumidor. Aps ser aprovada,
a idia foi financiada pela rea de Novos Segmentos, a qual responsvel por tudo o
que novo, conforme descreveu o entrevistado, at o processo virar rotina. Essa rea
foi responsvel pelo desenvolvimento de todo o Entrega inclusive do sistema de pedidos
via Web.
Principais usurios
Os principais usurios so: os da administrao, que podem configurar o sistema; as
lojas, as quais precisam consultar os pedidos e gerenciar quais produtos que esto
disponveis em um determinado momento; e o CallCenter que pode consultar o status
de cada pedido.
A rea de Novos Segmentos participou ativamente do desenvolvimento. O owner do
projeto, que est alocado a essa rea, foi responsvel por definir as necessidades da
organizao e por aprovar as funes e caractersticas do sistema.

7.5.2.3 Tarefas
Planejamento e estudo de viabilidade
A empresa de Fast-food constatou que a entrega em domiclio havia gerado resultados
positivos no primeiro franqueado a implant-la. Foram feitas ento as adaptaes
necessrias para que o servio pudesse ser oferecido pelos outros restaurantes da
organizao e o Entrega, com os pedidos gerados via CallCenter, foi sendo
gradativamente implantado.
Uma dificuldade para implantar a entrega em domiclio foi adaptao dos processos
internos. Entretanto, quando o sistema de pedidos via Web comeou a ser desenvolvido,
os aspectos relacionados a essas mudanas internas j haviam sido resolvidos pelo

122

Entrega com pedidos gerados via CallCenter. Assim, o impacto organizacional

resultante do sistema de pedidos via Web era relativamente menor. Dessa forma, no foi
no foi considerado necessrio elaborar algum tipo de estudo de viabilidade antes do
desenvolvimento.
O planejamento inicial era implantar o Entrega em todas as lojas, com pedidos sendo
gerados via CallCenter, antes de habilitar a colocao de pedidos via Web. Entretanto,
por uma questo de oportunidade e de imagem institucional considerou-se importante
oferecer tambm a possibilidade de colocao de pedidos atravs da Web, mesmo antes
que todas as lojas estivessem cobertas pelo Entrega com pedidos gerados via
CallCenter. Assim, a rea de novos segmentos elaborou um planejamento o qual foi
aprovado pela vice-presidncia e operacionalizado pela rea de informtica.
Anlise
A anlise foi feita em conjunto com a empresa contratada. A empresa de Fast-food
descreveu as funes a serem desenvolvidas e a contratada props o cronograma de
atividades e o oramento. Esta ltima elaborou um documento descrevendo todas as
funes do sistema.
O representante da rea de novos segmentos especificava as funes de forma genrica
para o coordenador do projeto, o qual, baseado no seu conhecimento sobre os sistemas
da organizao, verificava o que j era atendido pelos outros sistemas e que, portanto,
estavam fora do escopo do projeto, alm de determinar a viabilidade de cada funo.
Isto porque, a empresa contratada no conhecia os sistemas de informao da empresa
de Fast-food e, muitas vezes, tendia a incluir no escopo do sistema de pedidos via Web
funes que j atendidas por outros sistemas da organizao.
Por no ser um profissional de TI, o owner algumas vezes no compreendia as
dificuldades relacionadas ao desenvolvimento de sistemas de informao e o impacto de
novas funes no custo e prazo do projeto. Ele tendia a incluir caractersticas no escopo
do projeto que o desvirtuavam de seu propsito e inviabilizavam seu desenvolvimento.
Coube ao coordenador ponderar o impacto de cada funo no desenvolvimento
procurando atender as necessidades de informao, mas garantindo a viabilidade de
implementao. Esta mediao foi considerada uma questo difcil de resolver ao longo
do desenvolvimento, sendo considerada uma das principais dificuldades de anlise.
Uma outra dificuldade foi convencer as reas externas de TI que o projeto se tratava
de um sistema de informao e no de um Web Site tradicional. No estava muito clara
a dificuldade existente para desenvolver o sistema de pedidos via Web e para integr-lo
ao mdulo do CallCenter. Assim, havia muitas expectativas com relao ao prazo e
custo de desenvolvimento que no podiam ser atendidas.
Projeto

123

O projeto do banco de dados foi produzido com base no sistema de CallCenter j

existente. Ele foi desenvolvido pela empresa contratada e validado pelo coordenador do
projeto. Como ferramenta de apoio modelagem foi utilizado um CASE.
Com relao ao projeto de interface, como muitas das pginas Web seriam utilizadas
pelos clientes, elas foram desenvolvidas utilizando recursos visuais acurados, alm de
apresentarem navegao simplificada. As telas que seriam utilizadas pelo CallCenter
eram mais administrativas e, portanto, sem tanto cuidado visual.
O mdulo utilizado pelos clientes foi projetado atravs de prottipos no operacionais
das pginas Web, feitos em Flash, que um tipo de formato para documentos com
sofisticados recursos visuais, tais como animaes. A navegao desta parte foi
representada no MyBoard, que uma forma de diagramao atravs de caixas, as quais
representam as pginas Web e que mostram as possibilidades de navegao do sistema.
Ela permite a representao atravs de recursos avanados como, por exemplo, a
definio de looping na navegao. Esse diagrama foi elaborado pela empresa
contratada e aprovado pelo owner do projeto. A empresa de Fast-food foi quem props
sua utilizao e orientou a contratada sobre como utilizar a ferramenta.
Para apoiar o projeto de interface houve a participao de dois designers. Eles
trabalhavam em uma empresa de publicidade contratada diretamente pela empresa
responsvel pelo desenvolvimento. O projeto do formato das pginas Web foi definido
com base em um documento, chamado de book, o qual determina os padres visuais a
serem seguidos pelos Web Sites da organizao.
Embora a navegao descrita nos diagramas do MyBoard tivesse sido aprovada pelo
owner, no momento da implantao foram solicitadas diversas alteraes, gerando retrabalho e atraso no cronograma de atividades e na entrega do produto final. Esta foi
considerada a principal com relao ao projeto.
O projeto deste sistema de pedidos via Web talvez tenha mostrado que a importncia da
interface do sistema, principalmente quando utilizado por clientes, influencia as
atividades de projeto. Para melhorar a qualidade do projeto da interface foram utilizados
recursos de modelagem atravs de tcnicas de representao formal da navegao, e do
desenvolvimento de prottipos, em ferramentas como o Flash, que permitem definir
com grande riqueza de detalhes o formato final da aplicao. Embora mesmo com a
utilizao de tais tcnicas ainda tenham ocorrido problemas de re-trabalho, tal
representao foi considerada til pelo coordenador do projeto e serviu como um apoio
na tentativa de melhorar o projeto final da interface do sistema. Por outro lado, o fato do
re-trabalho ter sido citado como um aspecto problemtico talvez indique que as
ferramentas de modelagem propostas no tenham sido suficientes para representar todos
os aspectos da interface do sistema e/ou que os modelos utilizados no tenham sido
adequadamente compreendidos pelo owner do projeto.
Codificao

124

Como o projeto envolveu muitas tecnologias e no havia pessoas que conhecessem

todas, foi preciso montar uma equipe de desenvolvimento relativamente grande, com
cada tcnico especializado em uma ou mais tecnologias. Conforme descreveu o
entrevistado, a grande dificuldade que devemos ter uma pessoa que conhea
JavaScript, outra que conhea PL/SQL, outra que conhea Flash.... Esse foi
considerado o principal problema com relao codificao.
Teste
Os testes do sistema foram realizados em uma rplica do ambiente de produo
chamada de laboratrio.
Como vrios outros sistemas de informao estavam sendo desenvolvidos
paralelamente ao sistema de pedidos via Web e eram bastante interdependentes, foi
criado um ambiente de testes, chamado de laboratrio, que simulava o ambiente de
produo e onde os testes foram realizados. No laboratrio foram testadas, no somente
as funes do sistema de pedidos via Web, mas tambm o seu impacto nos outros
sistemas de informao da organizao. Por ser considerada uma atividade de grande
importncia na empresa de Fast-food, o teste feito de forma planejada e extensiva.
A primeira parte do sistema, referente s funes do CallCenter, foi entregue em
conjunto e testada no laboratrio antes de ser transferida para a produo. Aps esta
primeira etapa, toda vez uma nova funo desenvolvida ou uma funo existente
alterada, deve-se utilizar o laboratrio antes de disponibiliz-la no ambiente de
produo.
Embora a empresa contratada fosse responsvel por testar os mdulos produzidos antes
de entreg-los empresa de Fast-food para que fossem testados no laboratrio, diversas
vezes eles foram entregues com erros considerados triviais pela contratante. Isto
aumentou o esforo de teste na empresa de Fast-food, uma vez que, freqentemente, os
mdulos eram rejeitados, sendo preciso test-los mais de uma vez at que fossem
aceitos. Foi preciso conversar com o lder da equipe na empresa contratada, para que ele
tentasse melhorar a qualidade do software entregue. Entretanto, os resultados dessa
reorganizao ainda no haviam sido percebidos pela empresa de Fast-food.
Este problema do teste talvez possa ser explicado porque os programadores tm o
compromisso de produzir e entregar os mdulos do software, mas muitas vezes no so
avaliados pela qualidade do software entregue. Como pouco provvel que eles
desenvolvam software livre de erros, torna-se difcil avaliar, sem o uso de mtricas
relacionadas qualidade, se o nmero de erros pode ser considerado normal ou se que o
teste no foi feito adequadamente.
Implantao
O Entrega via CallCenter j est sendo utilizado por diversas lojas e o sistema de
pedidos via Web est em fase de homologao. A implantao via CallCenter tem sido

125

feita gradativamente em uma ou algumas lojas de cada vez e ser feita assim at que
toda a rede de lojas esteja com o Entrega implantado. Provavelmente a implantao do
sistema de pedidos via Web ocorrer da mesma forma e poder acontecer em paralelo
com a implantao do sistema de pedidos via CallCenter.
A implantao do Entrega implica a reorganizao dos processos internos para o
atendimento em domiclio independente da colocao do pedido ter sido feita atravs de
CallCenter ou da Web. Assim, nas lojas em que o Entrega j funciona atravs de
CallCenter sero necessrias apenas as mudanas relacionadas ao sistema de pedidos
via Web e infraestrutura Web, enquanto que nas lojas que ainda no oferecem o
Entrega ser preciso tambm reestruturar os processos.
As atividades de atendimento via CallCenter, de entrega dos lanches e de infraestrutura
de segurana so desempenhadas por empresas contratadas. Alm disso, conforme
descrito anteriormente, o prprio desenvolvimento do sistema foi realizado por empresa
contratada. Gerenciar um ambiente como esse, onde vrias empresas esto envolvidas e
com cada uma especializada em um tipo de atividade, uma atividade complexa. Para
disponibilizar o Web Site, por exemplo, preciso ter o link entre o restaurante e a
central da organizao funcionando adequadamente, ter a segurana garantida, acessos
liberados, e outras questes resolvidas. Conforme descreveu o entrevistado, o problema
no tanto o aplicativo, porque ele j est pronto, mas para disponibilizar ele eu tenho
que ter os recursos por trs.
Esta questo da implantao reflete a complexidade para a utilizao de um novo
sistema que no apenas faz automao de processos existentes, mas apia a
reestruturao de alguns processos e at a remodelagem do negcio. Neste ambiente, o
aplicativo em si apenas mais uma questo, a qual provavelmente mais facilmente
resolvida do que o impacto organizacional resultante.

7.5.2.4 Estrutura
Metodologia
Foi utilizada linguagem formal para a modelagem do banco de dados e para a
representao da navegao do sistema, alm de terem sido desenvolvidos os prottipos
no operacionais das telas em Flash.
Com relao metodologia de desenvolvimento de sistemas, no h uma que seja
adotada em todos os projetos ou que seja padronizada pela organizao, pois, conforme
descreveu o entrevistado, a finalidade da empresa vender hambrguer e no
desenvolver sistemas de informao. Para este projeto a organizao apenas definiu o
formato dos documentos que deveriam ser entregues pela empresa contratada. Tais
documentos eram textos em linguagem natural que descreviam as propostas de
desenvolvimento e o detalhamento das funes do sistema.

126

Quanto estratgia utilizada, o desenvolvimento apresentou principalmente

caractersticas do enfoque em paralelo, pois diversos sistemas estavam sendo
desenvolvidos simultaneamente e, juntos, implementavam o servio de entrega em
domiclio.
Ferramentas
O sistema tem aproximadamente cem tabelas e para represent-las foi utilizada a
ferramenta CASE da Oracle, onde foram descritos diversos aspectos da especificao,
principalmente os aspectos relacionados modelagem de dados.
Para desenvolver as funes que so baseadas na tecnologia Web foram utilizadas vrias
tecnologias tais como Flash, DHTML, Java, alm de tecnologias no voltadas para a
Web, tais como Delphi e Visual Basic. Isto mostra que as tecnologias envolvidas no
desenvolvimento foram de vrios tipos, justificando a dificuldade relatada em manter e
gerenciar uma equipe que conhea todas estas tecnologias.
Polticas
No h poltica de desenvolvimento com relao adoo de metodologia. Entretanto, a
organizao tem algumas ferramentas de apoio modelagem tais como o CASE e a
ferramenta para modelagem de navegao, os quais auxiliam na utilizao das tcnicas
anlise e projeto.
Com relao a padronizaes, conforme mencionado anteriormente, existe um book
contendo os padres visuais a serem seguidos pelos Web Sites, tais como cores, figuras,
marcas e banner. Esta poltica talvez retrate o reconhecimento, por parte da
organizao, que os sistemas disponveis na Web esto diretamente relacionados e
apiam sua imagem institucional, sendo necessrio ter regras claras para o formato das
pginas Web de forma que aplicaes Web distintas tenham interfaces uniformes.

7.5.2.5 Sadas
Sistema
O impacto do Entrega na organizao foi grande, pois exigiu uma reorganizao dos
processos internos para garantir, por exemplo, que a qualidade do lanche atendesse os
padres da empresa de Fast-food. Outro exemplo de mudana nos processos internos foi
a criao de mecanismos para que o cliente pudesse fazer reclamaes, pois como os
pedidos e as entregas ocorreriam fora das instalaes da empresa de Fast-food, no
haveria mais a possibilidade de conversar diretamente com o gerente da loja na
ocorrncia de algum problema.
Quanto aos aspectos mais relacionados ao sistema de pedidos via Web, ele permite
diminuir o custo do atendimento via CallCenter, uma vez que os pedidos so colocados
diretamente pelo clientes. Foram tambm colocados no sistema indicadores de

127

qualidade da entrega, que servem como uma ferramenta de gesto e permitem que os
processos relacionados ao Entrega possam ser melhorados continuamente.
As vendas dos restaurantes que implantaram o Entrega com pedidos via CallCenter
aumentaram. A expectativa era de que quando estivesse disponvel o sistema de pedidos
via Web, as vendas aumentariam ainda mais.
Finalmente, o sistema Web permite reforar a imagem de que a organizao de
vanguarda, que utiliza a tecnologia de forma ampla e que oferece servios de alta
qualidade a seus clientes.
Documentao
As propostas de trabalho produzidas pela empresa contratada detalhavam as funes do
sistema e, de certa forma, serviram de documentao tcnica. Alm disso, grande parte
das decises de projeto foi documentada atravs da ferramenta CASE, onde so
descritos no apenas o modelo de dados, mas tambm da funcionalidade do sistema.
Com relao documentao para os usurios foram produzidos manuais para os
restaurantes (manual do restaurante), para o CallCenter (manual de atendimento) e para
a parte administrativa (manual administrativo). Para o consumidor no foi gerada
documentao, pois a parte que ele deve utilizar foi projetada para ser simples e
intuitiva.

7.5.3 Comentrios
O sistema de pedidos via Web analisado pode ser visto como mais um mdulo de um
sistema maior que o Entrega e que inclui no apenas a colocao de pedidos, mas toda
a parte de gerenciamento da entrega. O sistema de pedidos via Web e o sistema do
CallCenter, por exemplo, muitas vezes foram descritos de forma unificada, ou seja, para
o entrevistado no havia tanta diferena entre os dois, mesmo com seu o
desenvolvimento tendo sido feito de forma separada e atravs de projetos distintos. Isso
talvez confirme a noo de que os sistemas Web apresentam, muitas vezes, ampla
integrao com os sistemas j existentes.
Um outro aspecto interessante que uma das razes para o sistema ter sido
desenvolvido no foi tanto os benefcios da tecnologia, embora eles tenham sido
importantes, mas, principalmente, a imagem institucional. Isto porque, como o Entrega
j estava sendo implantado em vrias lojas atravs do sistema de CallCenter, uma
abordagem natural seria comear o atendimento via Web somente quando grande parte
das lojas j estivesse com o sistema de entrega em domiclio operando normalmente.
Seria uma forma de oferecer um novo servio minimizando os riscos das mudanas,
uma vez que tal servio gerava um grande impacto nos processos organizacionais. Esta
foi, inclusive, a sugesto da rea de informtica. Entretanto, por considerar a questo da
imagem importante para o negcio, optou-se por desenvolver estas duas iniciativas em

128

paralelo, o que apresentava mais riscos, mas permitia que a empresa fosse vista como
inovadora perante seus consumidores.
Finalmente, por apresentar um exemplo de utilizao da TI como apoio reestruturao
de processos, o impacto organizacional, aparentemente, foi grande e o desenvolvimento
e a implantao do sistema foi considerada apenas uma parte do problema, sendo, talvez
a menos complexa.

129

7.6 CASO CONGLOMERADO INDUSTRIAL

INFORMAES GERENCIAIS

SISTEMA WEB

DE

7.6.1 Introduo
O Conglomerado Industrial est presente em setores de base da economia que
demandam capital intensivo, alta escala de produo e constantes investimentos em
tecnologia.
A organizao usa, h alguns anos, um sistema ERP, da BAAN, que, embora atenda as
necessidades de apoio s suas operaes, apresenta uma srie de deficincias para a
extrao de informaes gerenciais, tanto no que diz respeito falta de relatrios quanto
pela demora para sua extrao. Em 1998 foi desenvolvido um Sistema de Informaes
Executivas (EIS - Executive Information System) como apoio rea comercial. Esse
sistema funcionava com interface Web, mas apresentava problemas de desempenho e
funcionalidade, pois os tipos de consultas possveis eram fixos, ou seja, os dados
poderiam ser agrupados de formas pr-definidas, tais como por segmento ou por regio.
Optou-se ento por desenvolver um novo sistema que chamaremos neste trabalho de
Sistema Web de Informaes Gerenciais.
O sistema Web de informaes gerenciais foi desenvolvido ao longo de 2001 e comeou
a ser utilizado em 2002. Ele est disponvel na Intranet da empresa e apresenta uma
modelagem multidimensional, a qual permite armazenar dados histricos do negcio
visando a elaborao de anlises de tendncias. Com o novo sistema, informaes que
demoravam em torno de cinco horas para serem processadas passaram a ser obtidas
quase que instantaneamente. Alm disso, as anlises passaram a ser feitas de forma
muito mais flexvel do que com o sistema anterior.
Para este trabalho, foi entrevistado apenas o coordenador da equipe, pois a equipe, que
era contratada, foi desfeita aps o desenvolvimento, no sendo possvel entrevistar seus
membros. A entrevista foi realizada em janeiro de 2003.

7.6.2 Descrio do Caso

7.6.2.1 Contexto
Necessidades do negcio
Os gerentes sentiam a ausncia de relatrios gerenciais no ERP e reclamavam da
demora nas emisses. O EIS, por outro lado, no era flexvel o suficiente para a
montagem das consultas. Eles queriam montar consultas que no fossem pr-definidas.
Com os dados modelados de forma multidimensional, o usurio poderia combinar as
dimenses da forma desejada para mont-las.
A tecnologia Web foi escolhida por vrias razes e uma delas foi o custo de
desenvolvimento. O sistema utilizou conjuntos de componentes que atendiam as

130

demandas por consultas sobre bases multidimensionais: um primeiro conjunto pertencia

originalmente ao software Office, da Microsoft, e o outro conjunto vinha embutido no
Sistema Gerenciador de Bancos de Dados SQL Server, tambm da Microsoft. Usadas
de forma integrada, tais tecnologias atendiam as necessidades da organizao. Como a
empresa j possua a licena do Office no haveria custo para a utilizao dos
componentes j disponveis, sendo preciso adquirir apenas o SQL Server.
Alm do custo, a possibilidade de utilizar componentes reduz os esforos de
desenvolvimento, uma vez que eles j embutem dentro de si a maior parte da
funcionalidade necessria ao sistema.
Por fim, outro fator que levou escolha da tecnologia Web foi a facilidade de acesso
proporcionada aos usurios, pois o sistema seria utilizado em vrios locais do Brasil.
Uma restrio relacionada utilizao dos componentes do Office da Microsoft que
eles s funcionavam no navegador da Microsoft, o que fez com que o sistema no
implementasse o conceito de acesso universal, propagado pela tecnologia Web.
Entretanto, neste caso, como estaria dentro da Intranet da organizao, a restrio
quanto ao navegador no foi considerada uma limitao relevante.
Natureza do sistema
Diariamente, os dados oriundos do ERP retratando as transaes dos ltimos 60 dias,
alm de dados trazidos de planilhas eletrnicas so recalculados na base
multidimensional do sistema. O processo semelhante ao conceito de DataWarehouse,
ou seja, dados de diversas fontes so consolidados em uma rea temporria e
armazenados em uma base multidimensional.
A principal funo do sistema gerar, sobre essa base multidimensional, consultas para
apoio deciso gerencial. As sadas podem utilizar recursos avanados tais como
gerao de grficos e exportao de dados para planilhas eletrnicas.
Existem vrias informaes disponveis no sistema. A rea de Marketing o utiliza para
acompanhar, por exemplo, quais as regies do Brasil esto vendendo mais e quais
produtos do estoque esto sendo movimentados com maior freqncia. A rea
comercial, maior usuria do sistema, acompanha, por exemplo, a carteira de clientes,
volume mensal de compras por cliente, faturamento e pedidos. A rea financeira utiliza
o sistema para acompanhar as contas a pagar, as contas a receber e funes que
disponibilizam um mini balancete. Assim, de forma geral, as consultas so utilizadas
principalmente para apoio a decises semi-estruturadas, tanto para controle operacional
quanto para controle gerencial, conforme classificao de GORRY & MORTON (apud
LUCAS, 1997, p.43).
Todos os usurios do sistema so identificados. Existem dois mecanismos de
identificao. Em um deles o controle atravs do acesso ao Web Site, ou seja, apenas
os usurios da rede de computadores interna que podem acessar o sistema. O outro
mecanismo atravs de funes contidas no sistema.

131

O sistema utiliza predominantemente montagem dinmica de pginas com dados vindos

da base multidimensional. As ligaes entre as pginas e grande parte da navegao so
geradas automaticamente pelos componentes utilizados.
Como as pginas Web do sistema so montadas utilizando apenas os dados da base
multidimensional, o mdulo da tecnologia Web lida somente com dados estruturados.
Integrao
O sistema no envia dados para outros sistemas, mas apenas recebe informaes do
ERP e de um conjunto de planilhas eletrnicas geradas pelos usurios. No houve
problemas com a integrao, pois o coordenador da equipe j conhecia bem a estrutura
do ERP, alm de ser bem documentada e de fcil entendimento, conforme descreveu o
entrevistado.

7.6.2.2 Interessados
Equipe de desenvolvimento
A equipe de TI da organizao bastante reduzida. Assim, foi contratada uma outra
empresa para o desenvolvimento deste sistema. Ela foi responsvel pelo
desenvolvimento de todas as pginas Web, pela modelagem relacional do banco de
dados e pelo desenvolvimento do ambiente OLAP para as consultas multidimensionais.
Cabe ressaltar que, apesar do desenvolvimento ter sido feito por uma empresa
contratada, ele foi feito dentro das instalaes do conglomerado Industrial.
A equipe era formada por um gerente de projeto, um coordenador da equipe, dois
analistas que ajudaram a especificar tanto o modelo de dados quanto os principais
cubos da base multidimensional, trs programadores que desenvolveram toda a parte
Web, um designer e um responsvel pela documentao do sistema, chamado de
documentador. Com exceo do gerente do projeto e do coordenador da equipe todos
os outros trabalhavam para a empresa contratada.
Houve tambm a participao de seis usurios, chamados replicadores. Destes, trs
eram de reas internas organizao, sendo um de cada rea, enquanto os outros trs
eram de outras empresas do conglomerado que tambm usariam o sistema. Eles
acompanharam o desenvolvimento, validaram as consultas e a modelagem relacionadas
sua rea, alm de replicaram seu conhecimento do sistema para outros funcionrios.
O trabalho foi organizado de forma que os dois analistas de sistemas fossem
responsveis pela modelagem do banco de dados e os trs programadores
desenvolvessem as pginas Web. As funes foram divididas por rea, por exemplo,
rea comercial e rea financeira. Assim, cada programador desenvolveu as consultas
referentes a uma rea. Dessa forma, no havia muita dependncia entre os mdulos
desenvolvidos por programadores distintos, minimizando a comunicao entre eles. O

132

coordenador da equipe tambm ajudou no desenvolvimento sendo envolvido mais na

parte das funes do sistema que eram usadas por todas as reas. O banco de dados no
foi dividido por rea, pois os dois analistas montavam os cubos e as estruturas
necessrias para as consultas de todas as reas. O responsvel pela documentao
recebia semanalmente as alteraes no projeto e atualizava a documentao tcnica.
Esta forma de organizar o trabalho permitiu que o desenvolvimento fosse feito de
maneira mais independente, ou seja, cada programador pde desenvolver funes que
tinham pouca ou nenhuma dependncia das outras funes, o que minimizava a
comunicao entre os programadores e permitia que o desenvolvimento fosse feito com
o maior paralelismo possvel. Isto foi possvel, principalmente, pelas caractersticas do
sistema. Como ele oferece consultas para diversas reas internas da organizao e os
dados de cada rea eram relativamente independentes das demais, foi natural e mais
adequado organizar as atividades entre os membros da equipe de forma a aproveitar a
possibilidade de desenvolvimento em paralelo.
Outra caracterstica interessante da equipe foi a utilizao de uma pessoa
exclusivamente responsvel pela documentao. Como grande parte da complexidade
do sistema estava justamente no banco de dados, manter o modelo e o dicionrio de
dados atualizados representou uma tima prtica de trabalho.
reas de negcio cliente
O sistema foi encomendado pela gerncia da rea comercial e a prpria rea de
informtica financiou o projeto. Cabe ressaltar que foi a rea de informtica que
mostrou as possibilidades da tecnologia existente. Assim, coube informtica
identificar que, com as novas tecnologias Web de componentes e de bancos de dados,
seria possvel desenvolver um sistema que oferecesse os recursos desejados, tal como
anlise sobre bases multidimensionais e grande facilidade de acesso, ainda no
conhecidos pelas outras reas.
Principais usurios
Os principais usurios do sistema so os coordenadores e gerentes das reas de
Marketing, Comercial e Financeira da organizao.
Cada rea acima alocou um usurio replicador para que descrevessem as necessidades
da rea e validasse as consultas do sistema. Assim, procurou-se estabelecer ao longo da
construo do sistema uma estrutura que permitisse grande participao das reas
usurias no projeto. Essa pode ser considerada uma boa estratgia para tentar diminuir a
incerteza do problema conforme definido por HIRSCHHEIM, KLEIN & LYYTINEM
(1995, p. 16).

7.6.2.3 Tarefas
Planejamento e estudo de viabilidade

133

Como forma de divulgar os recursos que um novo sistema de informaes gerenciais

poderia oferecer foi feito um workshop mostrando para as reas usurias as
possibilidades das novas ferramentas. Foi apresentado um prottipo do sistema baseado
em telas operacionais e dados fictcios. A estrutura no era a do banco de dados real e o
objetivo foi apenas apresentar claramente as possibilidades das novas ferramentas. No
prottipo foram sugeridos alguns indicadores que poderiam ser teis para cada rea.
Uma vez que a idia foi aceita pelas reas usurias, o gerente de informtica da
organizao definiu, junto com o gerente da empresa contratada, o cronograma de
atividades e as pessoas a serem alocadas no projeto.
O planejamento foi feito atravs de etapas curtas, nas quais eram definidas apenas as
consultas que poderiam ser construdas em poucos dias, no mximo em duas semanas.
Eram acertados prazos para as entregas e, depois de prontas as consultas de cada etapa,
novo planejamento era feito. A implantao comeou, entretanto, somente aps todas as
consultas estarem prontas. Apesar disso, conforme foram sendo desenvolvidas, eram
disponibilizadas para validao dos usurios.
O planejamento foi feito baseado em uma metodologia de desenvolvimento proposta
pela empresa contratada e, como resultado de cada nova etapa planejada, era produzido
um documento padro definido por tal metodologia.
Esta forma de planejamento interessante para este tipo de sistema, pois como ele apia
a tomada de decises semi-estruturadas, abordagens adaptativas so mais adequadas
(IIVARY, HIRSCHHEIM & KLEIN, 2000-2001, p. 192). Assim, ao invs de se definir
logo no incio todos os tipos de consultas desejadas, foram definidas apenas algumas
consultas. Quando essas estivessem prontas, provavelmente surgiriam idias de novas
consultas, caracterizando um ciclo evolutivo de aprimoramento do sistema, muitas
vezes eficaz.
Anlise
A definio dos requisitos foi sendo feita ao longo do desenvolvimento. Semanalmente,
o coordenador da equipe se reunia com as reas usurias para discutir o modelo de
dados e o projeto como um todo. Assim, novas funes eram definidas e as j
desenvolvidas eram validadas. Os indicadores sobre os negcios da organizao que
deveriam ser includos no projeto eram definidos atravs de prottipos operacionais, ou
seja, os programadores faziam o modelo de dados e os usurios validavam as
informaes antes que as pginas Web correspondentes fossem desenvolvidas.
A principal dificuldade encontrada foi a necessidade de re-trabalho ao longo do
desenvolvimento. Isto porque, embora os usurios tivessem aprovado o modelo de
dados, durante a validao eram solicitadas muitas alteraes, tais como a incluso de
indicadores, o que atrasou o desenvolvimento. Assim, o levantamento de requisitos e a
validao da implementao foram considerados as etapas mais difceis do

134

desenvolvimento. Um outro problema citado foi o de que alguns usurios replicadores,

por estarem mais envolvidos com suas atividades normais, acabaram participando
menos do que o desejado durante o projeto, atrasando todo o desenvolvimento.
Nesta forma de levantamento atravs de prottipos operacionais, os analistas
identificam os requisitos permitindo que os prprios usurios experimentem o sistema
e levantem os problemas e as necessidades no atendidas. uma abordagem tpica para
o desenvolvimento de sistemas de apoio deciso (SAD), onde o sistema evolui atravs
de adaptaes contnuas (IIVARY, HIRSCHHEIM & KLEIN, 2000-2001, p. 192).
Entretanto, uma das desvantagens desta forma de desenvolvimento justamente o retrabalho, uma vez que somente aps alguma parte do sistema estar pronta que se
consegue ter um retorno sobre sua adequao ao problema. Por outro lado, como o
modelo de dados foi validado com os usurios antes do incio do desenvolvimento dos
prottipos operacionais, era esperado que o re-trabalho fosse reduzido. Alm disso,
como a tecnologia permitiu a construo rpida da interface, ajudando tambm a
minimizar os custos gerados pelo re-trabalho, acreditamos que tal estratgia tenha sido
adequada.
Projeto
O projeto de banco de dados foi baseado nos dados que j existiam no sistema ERP e
em diversas planilhas utilizadas por cada rea da organizao. Com o modelo de banco
de dados pronto foi preciso desenvolver as vises de dados que permitiriam montar as
consultas gerenciais. A definio dessas vises foi feita em conjunto com a anlise do
sistema, ou seja, as vises eram montadas conforme os requisitos foram sendo
definidos. Em outras palavras, era feito um pouco de anlise e depois um pouco de
projeto e implementao, e o resultado era apresentado aos usurios que refinavam a
anlise, gerando novo projeto e implementao, e funcionando como ciclos de
refinamento do sistema. Com esta abordagem, embora exista bastante re-trabalho, o
resultado final atende as necessidades dos usurios.
Com relao ao projeto de navegao do sistema, como foram utilizados componentes
de acesso a bases multidimensionais, foi construdo um menu principal que direcionava
os usurios para as consultas. A partir da tela inicial de uma consulta, toda a navegao
era feita de forma automtica pelos componentes. S foram alterados os formatos das
pginas Web, os quais foram definidos pelo designer da equipe. A comunicao com o
designer se deu atravs de pginas Web estticas descritas em HTML, as quais eram
utilizadas como base para a codificao das pginas Web.
Dentre as dificuldades citadas, vale mencionar que os usurios faziam solicitaes
inviveis ou impossveis de serem implementadas. Assim, o papel do analista foi
fundamental para delimitar o escopo e a funes oferecidas pelo sistema.
Como o projeto foi realizado em conjunto com a anlise as dificuldades encontradas
foram similares s da anlise, ou seja, principalmente relativas ao re-trabalho decorrente
da estratgia de desenvolvimento adotada.

135

Codificao
O ponto crtico da codificao foi o funcionamento dos componentes para acesso a
bases multidimensionais. Para conseguir implement-los foi preciso o apoio de
consultores de uma empresa parceira da Microsoft, fornecedora dos componentes. A
grande dificuldade no foi faz-los funcionar, mas resolver questes relacionadas ao
desempenho.
Segundo o coordenador da equipe, com a utilizao de componentes a codificao de
cada pgina Web era feita de forma bem rpida e a montagem das consultas era simples.
Conforme descreveu o entrevistado, noventa por cento do tempo de codificao foi
alocado para funes relacionadas ao banco de dados ao invs de funes
implementadas na tecnologia Web.
O emprego de componentes de software reutilizveis reduziu bastante o esforo para o
desenvolvimento do sistema de informao. A utilizao de componentes comum em
outras tecnologias no Web e, conforme observado neste caso, alguns sistemas baseados
na tecnologia Web j esto comeando a empregar a mesma abordagem.
Teste
O teste foi descentralizado, ou seja, cada tcnico era responsvel por testar as funes
por ele desenvolvidas. Os usurios replicadores validavam os dados e o sistema.
Portanto, o teste era realizado inicialmente pelos programadores, funo por funo,
posteriormente validada pelos usurios. Como as funes no possuam muita
dependncia entre si no houve a necessidade de fazer testes integrados.
Quanto s dificuldades, foi mencionado que os programadores entregavam para
validao dos usurios funes contendo muitos erros. Embora tais usurios tivessem
especificado corretamente as frmulas de clculo, muitas pginas Web que eram
entregues para validao apresentavam erros simples, tais como implementaes
erradas destas frmulas. Alm disso, algumas vezes, as consultas eram entregues para
validao contendo os mesmos erros previamente detectados e j apontados pelos
usurios. Em outras palavras, uma consulta era recusada pelos usurios por conter erros,
mas em seguida era entregue novamente para validao sem que tais erros estivessem
corrigidos. Isso contribuiu para a baixa participao de alguns usurios e, conforme
descreveu o coordenador de equipe, algumas vezes os deixava desapontados com o
sistema. Por outro lado, o prazo para o desenvolvimento foi extremamente curto, no
sendo possvel alocar tempo adequado para o teste.
Para contornar esta situao, talvez fosse adequado centralizar os testes em uma nica
pessoa da equipe, de forma a evitar que funes contendo erros simples fossem
entregues aos usurios, isto , fazer uma espcie de pr-validao na rea de informtica
antes da entrega aos usurios. Provavelmente, esta pessoa no conseguiria identificar
todos os erros do sistema, mas ajudaria a melhorar a qualidade do cdigo, deixando os

136

usurios mais confiantes no sistema. Entretanto, para que isto fosse possvel, os prazos
teriam que ser ajustados para permitir uma dedicao maior ao teste.
Implantao
Foram migrados para a base de dados do novo sistema tanto os dados do ERP como os
do sistema de EIS. Na migrao no houve necessidade de fazer nenhuma rotina nova
porque as rotinas dirias do sistema j faziam a importao dos dados, sendo preciso
adapt-las para que carregassem todos os dados histricos, ao invs de utilizar apenas os
ltimos 60 dias. Assim, no houve problema durante a migrao.
Os usurios foram treinados em grupos, ou seja, periodicamente a rea de informtica
apresentava o sistema para um novo grupo de usurios, para os quais liberava o acesso
ao sistema. Os usurios replicadores tinham a misso de ajudar a treinar os novos
usurios.
Quando praticamente todas as consultas ficaram prontas a rea de informtica comeou
a disponibilizar algumas para os usurios. Essa liberao ocorreu gradativamente,
entregando apenas algumas consultas embora outras j estivessem prontas. Assim, a
cada semana havia um novo conjunto de consultas sendo liberado e em um ms todas as
consultas haviam sido entregues.

7.6.2.4 Estrutura
Metodologia
A empresa contratada seguiu uma estratgia conhecida como PDCA, de Planejar, Fazer,
Checar e Agir (Plan, Do, Check and Action), que prope ciclos iterativos de melhoria
contnua, onde cada iterao aumenta o conjunto de funes oferecidas pelo sistema.
Em outras palavras, a estratgia para o desenvolvimento foi o enfoque evolutivo
baseado em iteraes.
No foi utilizada uma metodologia formal de desenvolvimento de sistemas, e o sistema
foi representado principalmente atravs de modelos relacionais e multidimensionais dos
dados. Alm disso, conforme descrito anteriormente, a prototipagem de telas foi
largamente utilizada.
Podemos considerar que para um sistema de apoio deciso (SAD) baseado em um
repositrio de dados com informaes histricas e voltado para anlise de tendncias, a
questo principal do projeto o modelo de dados. A interface de acesso, neste caso, no
to complexa e muitas vezes padronizada. Como foram usados componentes que
implementavam a navegao e a montagem de consultas dentro da base, a interface foi
projetada de forma relativamente simples e sem a necessidade de representao atravs
de alguma tcnica de modelagem formal. Assim, a utilizao de prottipos operacionais
foi adequada. Portanto, como o modelo de banco de dados foi modelado e

137

documentado, acreditamos que as tcnicas usadas para modelar o sistema foram

suficientes para apoiar o desenvolvimento.
Ferramentas
O SGBD utilizado foi o SQL Server 2000, da Microsoft. Este banco foi o escolhido
principalmente por oferecer, alm das funes encontradas em outros SGBD, recursos
como servios de auxlio para a anlise dos dados e servios de transformao de dados,
usados para a extrao de dados de fontes externas e alimentao do repositrio do
sistema.
A linguagem utilizada para a montagem das pginas Web foi o ASP, da Microsoft, e as
pginas Web foram desenvolvidas utilizando uma ferramenta denominada
Dreamweaver, da Macromedia, que oferece recursos para edio visual e para
programao. Os componentes do Microsoft Office foram inseridos nestas pginas Web.
Como ferramenta CASE foi usado o Power Designer, da Sybase. Todo o sistema, que
contm aproximadamente 300 tabelas, 450 stored procedures e 85 mdulos para a
extrao e transformao de dados, foi representado nesta ferramenta.
Polticas
Algumas padronizaes de cdigo, tais como nomes de objetos do banco de dados,
foram sugeridas pela empresa contratada e seguidas ao longo do desenvolvimento. Com
relao ao formato das telas, no havia uma padronizao, mas foram usados recursos
de outros Web Sites da empresa, tais como cores, fontes, imagens e outros.
A organizao adota uma poltica de utilizar o mximo possvel de recursos externos
em projetos de desenvolvimento de sistemas. Ao trmino de um projeto a equipe
dissolvida e o sistema mantido por uma equipe do prprio conglomerado. Para que
esta equipe consiga manter e operar o sistema algumas pessoas geralmente participam
do desenvolvimento e, no caso deste projeto, essa pessoa foi o coordenador da equipe
de desenvolvimento. Alm disso, preciso que o sistema seja bem documentado ao
longo do desenvolvimento. Por isso havia o papel do documentador que manteve, ao
longo do projeto, toda a documentao do sistema atualizada.
Devido a essa questo do desenvolvimento ser feito sempre com a utilizao de
terceiros, h uma poltica para a documentao dos sistemas. Aps a entrega do projeto
e da documentao, disponvel na ferramenta CASE e em documentao impressa,
sempre que houver uma alterao no sistema, a documentao deve ser atualizada e
impressa novamente. Alm disso, existem normas para que sejam colocados
comentrios em pontos chave do cdigo. Para verificar se a documentao est dentro
das normas existe uma auditoria de sistemas.
No h poltica de controle de qualidade em software. Isto porque, conforme descrito
pelo entrevistado, o objetivo da empresa no desenvolver software e a informtica

138

apenas uma atividade de apoio ao negcio. Acreditamos, entretanto, que a qualidade

deste sistema de grande importncia para a organizao, uma vez que se fornecer
informao errada poder induzir a decises equivocadas.

7.6.2.5 Sadas
Sistema
Um grande impacto do sistema foi a agilidade proporcionada ao processo de obteno
de informaes para apoio tomada de deciso. Na poca em que os relatrios da rea
comercial eram gerados sobre a base de dados do ERP, a demora era em torno de uma
semana. Quando o EIS comeou a ser utilizado este tempo caiu para dois ou trs dias.
Com o novo sistema Web de informaes gerenciais a montagem passou a ser
instantnea.
Outro impacto do sistema diz respeito melhora na qualidade da informao. Isto
porque, como as consultas so mais rpidas os erros nos dados da base do ERP so
detectados e corrigidos mais rapidamente, melhorando a qualidade da informao tanto
no ERP quanto no SIG.
Por fim, o sistema alterou os processos de trabalho das reas que o utilizam. Segundo o
entrevistado, a rea comercial inteira depende dele atualmente. Antes do sistema,
vrias informaes dessa rea deveriam ser calculadas manualmente para tornar
possvel a montagem de ndices de apoio tomada de deciso. Com o sistema Web os
clculos so automticos, permitindo que tais informaes possam ser consultadas
diariamente.
Documentao
Como houve a participao de um responsvel especificamente pela documentao do
sistema, os aspectos tcnicos foram extensivamente documentados. Esta
documentao foi composta basicamente de modelo de dados e dicionrio de dados.
Com relao documentao para o usurio final, foi desenvolvida apenas uma
cartilha de apoio, pois os prprios usurios replicadores tiveram a funo de ensinar
os outros usurios.

7.6.3 Comentrios
A utilizao de componentes no desenvolvimento de sistemas de informao j uma
prtica freqente quando envolve tecnologias no Web, principalmente em ambientes de
microinformtica. Ela permite que o desenvolvimento seja mais focado na montagem
de software com componentes prontos para construo do sistema. Assim, a reutilizao
de cdigo grande, permitindo talvez aumentar a produtividade no desenvolvimento.
Este caso revelou que j se comea a empregar o uso de componentes em projetos

139

envolvendo a tecnologia Web. Caso esta tendncia se confirme, a expectativa de que

os custos para desenvolver sistemas baseados na tecnologia Web sejam reduzidos.
Um outro aspecto a ressaltar que, neste caso, a tecnologia Web permitia apenas a
extrao dos resultados, tendo impacto mnimo no desenvolvimento do sistema. A
complexidade do desenvolvimento estava na modelagem de dados, na extrao de
dados vindos de diversas fontes e na consolidao de tais dados em um repositrio
nico, ao invs de questes como utilizao de recursos de navegao e de hipermdia.
Por fim, embora a tecnologia Web tenha surgido com a idia de acesso universal,
podemos perceber que neste caso um fabricante de software, ou seja, a Microsoft, tem
desenvolvido componentes que no funcionam sob essa perspectiva. Caso essa
tendncia se estabelea, uma das grandes vantagens da tecnologia Web poder ser
perdida, ou seja, o acesso a sistemas baseados em tal tecnologia no poder ser feito de
qualquer lugar independente do computador, da plataforma ou do sistema operacional,
conforme descreveu BERNERS-LEE (1996). Por outro lado, existe a possibilidade do
software navegador da Microsoft estabelecer-se como padro de fato para a utilizao
da tecnologia Web. Caso isso ocorra, as restries com relao ao acesso universal
podero ser mnimas.

140

7.7 CASO BANCO SISTEMA PARA A RECEPO DE PROPOSTAS VINDAS

DE WEB SITES
O Banco tem desenvolvido iniciativas para a utilizao da tecnologia Web na
comunicao com empresas parceiras principalmente para recepcionar propostas de
financiamento. Dois projetos sero descritos estudo, e os respectivos sistemas de
informao sero chamados de Sistema para Recepo de Propostas vindas de Web
Sites e Sistema Web de Recepo de Propostas das Concessionrias.
Os projetos surgiram por razes diferentes e resultaram em aplicaes distintas, alm de
terem sido desenvolvidos separadamente. O primeiro projeto foi desenvolvido baseado
em uma arquitetura simples e com muita interveno manual, servindo principalmente
como piloto para a viabilizao da utilizao da tecnologia Web. Uma vez implantado,
novos recursos foram sendo incorporados de forma a tornar o sistema mais automtico.
O objetivo era permitir que Web Sites de parceiros pudessem oferecer funes onde os
prprios clientes cadastrassem e enviassem as propostas de financiamento.
Quando o segundo projeto foi iniciado, j se possua algum conhecimento da tecnologia
Web, devido principalmente experincia adquirida com o primeiro. Ele foi conduzido
de forma a permitir criar um padro para as novas solues de TI do banco que utilizam
a tecnologia Web. Enquanto um dos objetivos do primeiro projeto era garantir que a
tecnologia Web pudesse ser utilizada na comunicao com os parceiros do banco, um
dos objetivos do segundo projeto foi o de estudar as vrias possibilidades para
implementar tal comunicao e definir um padro para a empresa. O sistema produzido
neste segundo projeto substituiu um sistema j existente que permitia que as
concessionrias cadastrassem e enviem as propostas de financiamento para o banco.
Embora tais projetos tenham sido conduzidos separadamente eles exerceram influncia
entre si. Isto porque, conforme descrito acima, o segundo j partiu de um conhecimento
desenvolvido pelo primeiro e, por outro lado, a aplicao gerada pelo primeiro
incorporou caractersticas que foram descobertas ao longo do desenvolvimento do
segundo.
Nos prximos tpicos descreveremos detalhadamente a construo das duas aplicaes,
mas analisaremos os resultados de forma conjunta aps a anlise da segunda.
Para este trabalho foram entrevistados os coordenadores tanto do projeto do sistema de
recepo de propostas vindas dos Web Sites quanto do de recepo de propostas das
concessionrias. As entrevistas foram realizadas em dezembro de 2002.

7.7.1 Introduo
O banco estabeleceu um acordo comercial com um de seus parceiros para que as
propostas de financiamento pudessem ser enviadas para o banco atravs da Internet. Os
arquivos contendo os dados das propostas eram gerados por um Web Site da empresa

141

parceira e enviados para o banco atravs da Internet. Inicialmente, eram colocadas em

um diretrio no servidor e, periodicamente, um funcionrio do banco transferia
manualmente os arquivos para o mainframe que processava a anlise de crdito. O
formato dos arquivos foi definido pela organizao e era baseado em um j existente,
utilizado por outras aplicaes para a comunicao com o computador de grande porte
do banco.
Uma vez implantada essa forma de comunicao, a empresa estabeleceu acordos
comerciais com outros parceiros para que tambm pudessem, atravs de seus Web Sites,
enviar propostas de financiamento.
Quando os procedimentos de trabalho j estavam consolidados, o sistema foi melhorado
para permitir que a recepo dos arquivos e seu envio para o mainframe fossem feitos
sem interveno manual. Os sistemas dos parceiros passaram ento a funcionar de
forma on-line com o mainframe do banco.
Um requisito do sistema era minimizar a comunicao com o computador de grande
porte. Para tanto, foram embutidos controles que permitissem efetuar algumas
validaes nos dados dos arquivos, antes que fossem enviados para o mainframe e se
houvesse algum erro o arquivo seria recusado.
A primeira verso operacional do sistema, que funcionava com interveno manual,
durou cinco meses e um esforo de otimizao para que funcionasse on-line demandou
mais oito meses.

7.7.2 Descrio do Caso

7.7.2.1 Contexto
Necessidades do negcio
O banco identificou que o sistema permitiria que sua rea comercial ficaria em
melhores condies para negociar com os parceiros, uma vez que o servio oferecido
pelo sistema interessava a eles e ainda no estava sendo oferecido pela concorrncia.
O motivo inicial para desenvolver o sistema foi um parceiro, com fortes ligaes com a
empresa, estar desenvolvendo um Web Site e desejar oferecer funes para o
preenchimento das propostas de financiamento diretamente pelo cliente. Como era
importante que pudesse ser utilizado rapidamente, sua arquitetura foi planejada de
forma bem simples e com bastante interveno manual e somente depois de
funcionando que o sistema foi sendo otimizado.
Acreditamos que esta estratgia tenha sido adequada, uma vez que era mais importante
ter o sistema operando rapidamente, mesmo que de uma forma simples, do que oferecer
funes mais robustas e automticas, mas que s pudessem ser utilizadas meses depois.
Este caso talvez mostre que muitas vezes no desenvolvimento de sistemas de

142

informao, o tempo disponvel para implementar uma soluo est fortemente

relacionado ao tempo para atender uma necessidade do negcio, o que induz ao
desenvolvimento atravs de abordagens mais evolutivas, onde inicialmente so feitas
algumas funes mais importantes e somente depois so melhoradas e novas funes
acrescentadas.
A oportunidade de negcio descrita neste caso existia principalmente devido
tecnologia Web que permitia interligar, atravs de uma infra-estrutura de comunicao
de baixo custo, os sistemas de duas empresas distintas.
Natureza do sistema
As principais funes do sistema so: cadastro de Web Sites habilitados a enviar
propostas de financiamento; recepo de propostas de financiamento; pr-validao
para evitar o envio de dados inconsistentes; comunicao com o mainframe e retorno da
resposta da anlise de crdito para o Web Site, onde a proposta teve origem.
O sistema possui funes de gerenciamento de usurios e acessos e, para garantir o
sigilo sobre os dados, utilizou um protocolo para comunicao segura. A principal
questo da segurana no foi tanto manter sigilo sobre os dados dos clientes, mas sobre
as propostas de financiamento recusadas. Isto porque, como a concesso final do crdito
no feita on-line, mas no mundo real mediante documentao tradicional, conforme
descreveu um entrevistado, o risco de que um dado incorreto ou fraudulento passe pela
anlise de crdito no crtico. Por outro lado, quando uma proposta recusada deve-se
cuidar para que o cliente que a solicitou no seja identificado.
O mdulo do sistema que utiliza a tecnologia Web bem pequeno, consistindo apenas
das telas de cadastro dos parmetros para efetuar as pr-consistncias e da recepo das
propostas. O sistema utiliza montagem dinmica de pginas, embora a maior parte das
pginas Web seja esttica. Isto porque, como existem poucas pginas Web e sua funo
principal atualizar parmetros de configurao, no h tanta necessidade de
disponibilizar dados para os usurios e as telas so basicamente para coletar
informaes. Alm disso, pelos dados manipulados serem simples, o sistema no utiliza
SGBD, embora todas as informaes estejam estruturadas em arquivos com formatos
pr-definidos.
A tecnologia Web foi utilizada neste caso, somente como uma interface para permitir
que sistemas localizados fora da rede de computadores do banco pudessem comunicarse com o computador de grande porte, mas toda a lgica do sistema continuou no
mainframe.
Integrao
O sistema foi desenvolvido de forma integrada ao sistema de crdito no mainframe, o
qual trata as propostas de financiamento vindas da Web da mesma forma que as outras.
Alm disso, j havia outras aplicaes que enviavam arquivos com propostas de

143

financiamento para o mainframe e, portanto, o formato dos dados j era padronizado.

Assim, no houve dificuldade, do lado do mainframe, para permitir o recebimento das
propostas vindas da Web.
Por outro lado, a integrao foi uma das principais questes a serem resolvidas no
mdulo Web do sistema. Conforme descrito anteriormente, para atender as necessidades
do negcio foi implementada uma soluo com interveno manual e, somente em um
segundo momento que a integrao passou ser automtica atravs da utilizao de
uma ferramenta que permitisse a comunicao on-line entre pginas Web e mainframe.
O conhecimento necessrio para a utilizao dessa tecnologia foi adquirido,
principalmente, durante o projeto do sistema Web de recepo de propostas das
concessionrias, e permitiu que, como resultado, o sistema de propostas de
financiamento vindas da Web pudesse ser otimizado.

7.7.2.2 Interessados
Equipe de desenvolvimento
Houve a participao de trs empresas no desenvolvimento. Uma delas construiu a
aplicao, uma ofereceu suporte na ferramenta de publicao (Host Publisher) e uma,
que pertence ao grupo do banco, foi responsvel pela infra-estrutura. As trs empresas
sero chamadas, neste trabalho, respectivamente de empresa de desenvolvimento, de
hospedagem e de infra-estrutura.
Do banco participaram um coordenador e dois analistas de aplicao. O coordenador
definiu a arquitetura do sistema e os analistas detalharam os requisitos e validaram os
produtos gerados pela empresa de desenvolvimento. Conforme descreveu um
entrevistado, os analistas ajudaram bastante no desenvolvimento, uma vez que
conheciam a tecnologia Web e puderam orientar as empresas contratadas.
A empresa de desenvolvimento, que foi a responsvel por toda a codificao do
sistema, alocou um gerente de projetos, um analista de aplicao, um programador e um
responsvel pelo suporte a redes. A empresa de infra-estrutura utilizou um especialista
em infra-estrutura de redes e dois profissionais para instalao do servidor de aplicao.
A empresa de hospedagem, que ofereceu suporte na ferramenta de publicao, utilizou
um consultor e participou apenas no final do projeto.
A maioria dos profissionais j conhecia a tecnologia Web antes do incio do projeto.
Entretanto, um problema citado com relao aos profissionais da empresa de
desenvolvimento foi que, embora eles conhecessem a tecnologia Web, nem todos
tinham perfil snior e alguns apresentaram dificuldades durante o desenvolvimento.
reas de negcio cliente
O sistema foi encomendado pela rea comercial. Ela consultou inicialmente a rea de
crdito para verificar se era possvel analisar propostas vindas pela Internet. Uma

144

proposta inicial foi ento passada para a rea de informtica que foi a responsvel e
financiadora do projeto.
Principais usurios
A rea comercial no opera o sistema em si, mas o utiliza como argumento de
negociao com os parceiros. Por ter grande interesse no desenvolvimento deste
sistema, tal rea participou ativamente desde a concepo at o projeto.
Os principais usurios do sistema so da rea de crdito. Eles efetuam a anlise de
crdito diretamente no computador de grande porte e utilizam o mdulo Web apenas
para configurar os parmetros de controle do sistema, tais como o gerenciamento dos
Web Sites habilitados a enviar propostas.
Os Web Sites dos parceiros que utilizam a principal funo do sistema que
recepcionar as propostas de financiamento.

7.7.2.3 Tarefas
Planejamento e estudo de viabilidade
Como o projeto seria implementado por uma empresa contratada foi preciso especificar
em detalhes o escopo para poder iniciar uma licitao. As prprias propostas de
desenvolvimento que foram entregues pelas empresas participantes da licitao
serviram como base para definir o esforo necessrio para o desenvolvimento, em
termos de prazo, custo e equipe.
Essa uma forma interessante para planejar o desenvolvimento, pois com vrias
organizaes fazendo o planejamento possvel minimizar, pelo menos, a incerteza de
recursos, conforme definida por HIRSCHHEIM, KLEIN & LYYTINEM (1995, p. 16).
Anlise
Os requisitos do negcio foram definidos pela rea comercial e passados para a rea de
informtica. Como a parte principal do sistema que a lgica do negcio j era
processada e continuaria no mainframe, no houve necessidade de usar tcnicas de
levantamento de dados.
Para modelar o sistema foi utilizada a tcnica chamada de anlise essencial. Tal tcnica
representa principalmente os eventos que devem ser tratados pelo sistema e quais
processos devem trat-los, alm de definir de forma genrica os dados que so
armazenados. Antes do incio do desenvolvimento todas as funes do sistema estavam
definidas e no foram citados problemas com re-trabalho durante o desenvolvimento.
Projeto

145

Conforme mencionado anteriormente, os dados utilizados pelo mdulo Web do sistema

eram simples e no foi necessria a utilizao de SGBD. Por isso, no foi feito nenhum
modelo de dados e a estrutura dos dados foi sendo definida ao longo do
desenvolvimento. A parte mais complexa da estrutura de dados que estava no
mainframe no precisou ser alterada. Como as propostas vindas da Web recebiam um
cdigo especfico que as diferenciava das outras, a estrutura de dados utilizada era a
mesma para qualquer proposta.
A navegao do sistema tambm era simples, uma vez que no existia seqncia prdefinida de telas para realizar uma operao. Como a parte mais complexa da
navegao estava no mainframe, no houve necessidade de fazer um projeto de
navegao. Alm disso, optou-se por no utilizar designer no projeto.
Codificao
Como grande parte da lgica da aplicao no estava na parte que envolvia a tecnologia
Web, o ponto crtico foi implementar as consistncias de dados antes de envi-los para o
mainframe. Embora as regras de validao estivessem bem definidas pelo banco, uma
vez que j eram utilizadas em outras aplicaes, houve problemas durante a codificao,
pois os programadores da empresa contratada tinham experincia no desenvolvimento
de recursos visuais, tais como diagramao de pginas Web estticas, mas no em
sistemas de informao.
Outra dificuldade citada diz respeito s estimativas para o tempo de desenvolvimento
das funes, as quais eram muito imprecisas. Conforme descreveu um entrevistado
muitas vezes eles [os programadores] falam que fazem uma tela em quinze minutos,
mas impossvel. Eles no conseguem considerar a estrutura que est por trs quando
estimam o desenvolvimento. Uma provvel razo para isto diz respeito experincia
daqueles profissionais, que estava voltada para a construo de pginas Web com
muitos recursos visuais e pouca programao. Assim, as referncias mtricas com
relao ao tempo de desenvolvimento eram baseadas mais no desenvolvimento visual, o
qual relativamente rpido quando se usa a tecnologia Web, do que no
desenvolvimento de lgica de programao, que complexa e requer um
desenvolvimento relativamente mais lento.
Teste
O teste foi feito inicialmente pela empresa contratada, a qual testou todas funes antes
de entregar o sistema. Para tanto, foi criado um ambiente de teste na prpria empresa,
que simulava o mximo possvel o ambiente real, tendo inclusive conexo com o
mainframe da organizao. Um segundo teste foi feito, tambm em um ambiente de
teste, no prprio banco e validado pelos analistas de aplicao.
A maior dificuldade no teste decorreu dos problemas relacionados codificao, ou
seja, como a lgica para fazer a pr-anlise era relativamente complexa e os
programadores no estavam habituados a encadear uma srie de situaes para efetuar

146

as validaes, muitas funes foram entregues com erros e precisaram ser corrigidas
diversas vezes at que atendessem os requisitos. Assim, as atividades de codificao e
teste demoraram bem mais do que o planejado.
Implantao
O sistema teve duas grandes verses. Na primeira, a comunicao entre o Web Site e o
mainframe era feita de forma manual, atravs da transferncia de arquivos de dados,
tanto do lado do banco quanto do Web Site parceiro, ou seja, ao receber uma proposta
do Web Site o parceiro deveria envi-la manualmente para o banco e depois havia uma
outra interao manual para carreg-la no computador de grande porte.
O objetivo desta primeira verso foi aproveitar a oportunidade de negcio existente e,
ao mesmo tempo, testar a viabilidade da comunicao atravs da Internet. Ela serviu
principalmente para resolver questes relacionadas segurana das informaes, ao
tratamento no mainframe das propostas vindas atravs da Web e seu impacto nos
processos de trabalho dos analistas de crdito. Com essa estrutura simples, tanto do lado
do Web Site quanto do lado do banco, foi possvel oferecer rapidamente aos clientes o
cadastramento de propostas diretamente no Web Site da empresa parceira do banco.
A segunda verso procurou automatizar os procedimentos de forma que a comunicao
com o mainframe passasse a ser feita on-line. Conforme as propostas eram cadastradas
no Web Site j eram transferidas para o computador de grande porte do banco e uma
mensagem indicando o recebimento da proposta era enviada ao Web Site.
O sistema foi concebido para que operasse em vrios Web Sites sem a necessidade de
adaptaes, mas apenas de ajustes em alguns parmetros, os quais eram feitos atravs
do prprio sistema. Assim, conforme a rea comercial estabelecia acordos comerciais
com novos parceiros o sistema j podia ser utilizado.
Uma dificuldade na implantao foi sincronizar o trabalho das empresas contratadas.
Como uma empresa foi responsvel pelo desenvolvimento e outra pela configurao da
infraestrutura, foi preciso definir uma forma conjunta de trabalho. Em alguns momentos
houve divergncia sobre eventuais problemas no sistema, ou seja, enquanto a
responsvel pela infraestrutura acreditava que a aplicao continha erros, a responsvel
pelo desenvolvimento considerava que o problema era de infraestrutura. Para resolver
tais questes foi preciso, em vrios momentos, mediao do banco.
No concernente s dificuldades, foi mencionado que os sistemas baseados na tecnologia
Web tipicamente envolvem muitas tecnologias e que dificilmente algum profissional
conhea todas, sendo necessrio grande esforo de coordenao durante o
desenvolvimento de tais sistemas.
Um problema que ocorreu aps a implantao do sistema foi que o servio de
hospedagem foi realizado por uma das empresas contratadas e o Web Site da aplicao
foi transferido para um servidor da empresa contratada.

147

Um problema ocorrido durante a implantao do sistema foi configurar o servidor da

empresa de hospedagem para que pudesse processar o SIW desenvolvido. Como tal
empresa ainda no havia utilizado Web Sites que se comunicassem com o exterior
(sistemas fora da sua rede), mas apenas Web Sites que divulgavam informaes, foi
preciso configurar a infraestrutura, principalmente ligada segurana, o que foi
considerada uma atividade bastante complexa, sendo que o processo foi considerado
traumtico por um dos entrevistados.
Alm disso, em um certo momento a empresa de hospedagem trocou o tipo de servidor,
de RISC para CISC. Com isso, algumas funes da aplicao precisaram ser alteradas
para se adequar ao novo ambiente.
Este caso ilustra o fato de que algumas aplicaes que envolvem a tecnologia Web
apresentam uma grande complexidade tecnolgica. Alm disso, quando as atividades
so realizadas por empresas contratadas o gerenciamento torna-se ainda mais complexo,
sendo talvez o maior desafio para o desenvolvimento.

7.7.2.4 Estrutura
Metodologia
No ambiente de computao centralizada (mainframe), que responde por 90% do
processamento da organizao, existe uma metodologia para o desenvolvimento de
sistemas de informao e, conforme descreveu um entrevistado, j existe uma cultura
estabelecida. A tecnologia Web, por outro lado, ainda recente e no se definiu ainda
um padro para o desenvolvimento de sistemas que a utilizam.
Nenhuma metodologia formal de desenvolvimento de sistemas foi utilizada neste
projeto. Entretanto, a tcnica chamada de anlise essencial, que muitas vezes utilizada
no desenvolvimento de sistemas para o mainframe foi empregada durante a anlise
desse sistema.
Conforme descrito anteriormente, foi feita uma licitao para selecionar a consultoria
que seria responsvel pelo desenvolvimento. Como parte do processo de licitao estava
a descrio da metodologia adotada pela empresa. Todas as empresas de consultoria que
participaram do processo possuam metodologias para apoiar o desenvolvimento,
entretanto, utilizavam tcnicas de apoio para a parte visual e quase nenhum recurso para
auxiliar na especificao e no projeto da lgica do sistema. Tal fato mostra,
provavelmente, que algumas empresas ainda no perceberam que muitos dos sistemas
Web desenvolvidos atualmente apresentam caractersticas muito mais prximas das de
um sistema de informao tradicional do que dos primeiros Web Sites estticos. O
banco optou ento por no utilizar a metodologia proposta pela consultoria que venceu
a licitao. Assim, tanto a estratgia de desenvolvimento quanto os produtos que
deveriam ser entregues foram definidos pelo prprio banco.

148

Segundo o entrevistado, projetos que envolvem a tecnologia Web, embora apresentem

algumas particularidades, so acima de tudo projetos de sistemas de informao e
deveriam ser gerenciados da mesma forma que os de sistemas no Web. Por isso, foi
adotada uma abordagem parecida com a empregada no desenvolvimento dos sistemas
baseados em computao centralizada.
Como este caso refere-se a um sistema que serve basicamente de interface de acesso a
outro sistema, tendo estrutura bastante simples, acreditamos que a estratgia adotada
para o desenvolvimento tenha sido adequada.
Ferramentas
Como no havia na poca SGBD disponvel optou-se por armazenar os dados em
arquivos. Da mesma forma, o mdulo Web foi desenvolvido atravs das linguagens
PEARL e CGI, as quais tinham sido utilizadas em outros projetos e j estavam
disponveis. O servidor Web utilizado inicialmente foi o Internet Information Server da
Microsoft, que j vem acoplado ao sistema operacional e no tem custo adicional. Aps
a implantao o sistema passou a ser processado em um servidor Web Apache sobre o
sistema operacional Linux, que gratuito.
Para este projeto foi utilizada a tecnologia que o banco j dispunha. Isto porque, como o
projeto tinha como um dos objetivos principais testar a viabilidade da utilizao da
tecnologia Web para comunicao com as empresas parceiras, no se investiu em
ferramentas de apoio ao desenvolvimento, mas conforme descreveu o entrevistado, o
banco procurou enquadrar a necessidade do negcio dentro da tecnologia disponvel.
Polticas
A principal poltica do banco com relao ao desenvolvimento de sistemas de
informao a de que as atividades devem ser realizadas o mximo possvel por
empresas contratadas. Neste projeto, todo o processo de desenvolvimento foi feito fora
das instalaes do banco. Entretanto, para os prximos projetos, embora o
desenvolvimento continue a ser feito por empresas contratadas, h uma proposta para
traz-lo para dentro do banco.
Outra poltica seguida foi a de que o sistema deveria implementar uma parte da lgica
de validao de forma a evitar a recusa de dados causada por inconsistncias,
minimizando assim a comunicao com o mainframe. Essa poltica foi definida pela
rea de anlise de crdito e visava garantir que os dados vindos da Web atendessem um
determinado padro de qualidade. Entretanto, todas as validaes feitas no sistema Web
deveriam ser processadas novamente no mainframe, ou seja, o processamento do
mainframe no foi modificado em funo do sistema.

7.7.2.5 Sadas
Sistema

149

Um resultado do sistema foi mostrar, para as outras reas do banco, que a utilizao da
tecnologia Web na comunicao com parceiros vivel permitindo, assim, o incio de
outros projetos similares, tais como o sistema Web de recepo de propostas das
concessionrias.
Um outro resultado obtido foi permitir que a rea comercial pudesse negociar em
melhores condies os acordos comerciais com os parceiros, uma vez que o banco
oferece um canal rpido e de baixo custo para a comunicao com seus sistemas.
Um dos principais benefcios do sistema foi estabelecer a Web como um canal
importante de venda. Atualmente, 30% dos negcios so originados na Web e, em
funo disso, foi criada uma rea especfica de Ecommerce. Considerando o prazo de
um ano desde a concepo do sistema at a realizao das entrevistas para este trabalho,
podemos inferir que o potencial da tecnologia Web na comunicao com os parceiros
grande e que esta apenas uma das primeiras iniciativas para o emprego desta
tecnologia nos sistemas de informao do banco.
Documentao
Como documentao tcnica foram produzidas descries das regras de negcio
embutidas nos arquivos enviados para o mainframe e seus respectivos formatos. Isto
porque, embora os formatos dos dados sejam simples a lgica para a validao mais
complexa.
Como documentao de apoio aos usurios, foram descritos os procedimentos que
devem ser seguidos para a operao do sistema e de como devem ser tratadas as
contingncias. Se ocorrer, por exemplo, um certo erro em uma transao a
documentao descreve qual o roteiro para o tratamento do erro, indicando inclusive
os responsveis por cada atividade de contingncia. Tais documentos foram entregues
aos usurios das empresas parceiras.

7.8 CASO BANCO SISTEMA WEB PARA RECEPO DE PROPOSTAS DAS

CONCESSIONRIAS
7.8.1 Introduo
O banco j utilizava, h mais de cinco anos, um sistema para recepo de propostas de
financiamento vindas de concessionrias parceiras. Tal sistema foi desenvolvido em
outro pas e sua arquitetura era baseada no ambiente Windows utilizando infraestrutura
privada de comunicao. Ele permitia que as propostas fossem cadastradas nas prprias
concessionrias e enviadas automaticamente para o sistema de crdito do banco.
O sistema apresentava algumas limitaes. Seu custo de operao, considerando os
custos de comunicao e de instalao nas parceiras, era alto tornando o seu uso vivel
somente nas concessionrias que trabalhavam com um grande volume de propostas de

150

financiamento. Alm disso, por ter sido desenvolvido em outro pas, no atendia todas
as necessidades do ambiente brasileiro.
Para contornar essas deficincias foi desenvolvido o sistema que, conforme mencionado
anteriormente, chamaremos neste trabalho de Sistema Web para Recepo de
Propostas das Concessionrias. Tal sistema foi desenvolvido e implantado em dez
meses.
O sistema permite que as propostas sejam digitadas na prpria concessionria utilizando
a interface Web e, uma vez cadastradas, sejam enviadas automaticamente para o sistema
de anlise de crdito do banco.
Como no outro projeto, toda a lgica do sistema fica no computador de grande porte do
banco. Entretanto, h a utilizao de um SGBD para armazenar temporariamente os
dados cadastrados antes que sejam enviados. Isto porque, como a comunicao atravs
da Internet no confivel, a comunicao pode ser rompida durante a atividade de
preenchimento das propostas. Para que os dados j digitados no sejam perdidos o
sistema armazena em um banco de dados local e, aps o envio, so excludos do banco.
Em outras palavras, o banco de dados funciona como um repositrio temporrio dos
dados digitados antes do envio. Alm disso, de forma similar do sistema para a
recepo de propostas vindas de Web Sites, algumas validaes nos dados so feitas
antes do envio e depois so novamente processadas no sistema de anlise de crdito.
O banco de dados tem aproximadamente dez tabelas de apoio para efetuar as validaes
e oito para permitir o armazenamento temporrio.
Uma diferena com relao ao primeiro projeto que, conforme descrito anteriormente,
enquanto este procurava testar a tecnologia, o segundo procurou desenvolver um
padro para o desenvolvimento de sistemas baseados na tecnologia Web no banco.
Assim, foi despendido um grande esforo em pesquisa de ferramentas de apoio ao
desenvolvimento e operao de sistemas Web.

7.8.2 Descrio do Caso

7.8.2.1 Contexto
Necessidades do negcio
Oferecer s concessionrias parceiras um sistema que permita cadastrar e enviar as
propostas de financiamento tambm interessante para o banco, uma vez que transfere
para elas a atividade de digitao de propostas. Essa foi uma das razes que levaram a
adoo do sistema desenvolvido no outro pas. Entretanto, conforme descrito
anteriormente, por exigir um alto custo de operao no era vivel para grande parte das
concessionrias parceiras.

151

O custo do sistema Web menor, tanto por utilizar infraestrutura pblica de

comunicao, como por no precisar instalar o sistema em todas as concessionrias a
cada nova verso, pois o sistema fica centralizado no servidor Web.
Por outro lado, o sistema para recepo de propostas vindas de Web Sites j havia
mostrado que a utilizao da tecnologia Web na comunicao com empresas parceiras
era vivel. Isto fez com que surgisse a possibilidade de substituir o sistema existente por
um que utilizasse a tecnologia Web.
Natureza do sistema
As principais funes do sistema so: incluso de proposta de financiamento;
solicitao da anlise de crdito; consulta da resposta da anlise de crdito; impresso
de informaes (ficha cadastral, contratos e boleto bancrio); e gerenciamento do
pagamento de contratos.
Diferente do sistema descrito anteriormente que apenas disponibilizava funes
relacionadas ao envio de propostas de financiamento, este sistema oferece tambm uma
srie de outros servios. Isto porque, como foi desenvolvido com o objetivo de
substituir um sistema que j estava em operao, foi preciso oferecer, no mnimo, todas
as funes j implementadas. Recursos como impresso de boleto bancrio e
gerenciamento de contratos permitem que a concessionria possa utilizar o sistema do
banco no somente para cadastrar e enviar propostas de financiamento, mas tambm
como um sistema de apoio gesto, sendo que, algumas vezes, a concessionria nem
tem outro sistema informatizado para gerenciar as propostas de financiamento.
Como no outro projeto, o sistema utiliza comunicao segura e existem funes para o
gerenciamento de usurios e acessos. Neste caso, entretanto, a lgica que implementa o
gerenciamento de acesso est em um dos aplicativos processados no mainframe e no
na parte Web da aplicao.
O sistema utiliza apenas montagem dinmica de pginas Web trazendo os dados do
banco de dados do sistema. Alm disso, todas as informaes esto estruturadas no
banco de dados ou no mainframe e no h informaes no estruturadas.
A volatilidade das informaes que ficam no banco de dados baixa, enquanto que os
dados das propostas so altamente volteis. A volatilidade foi utilizada como um dos
critrios para definir quais os dados que deveriam ser replicados no SIW. Assim, dados
pouco volteis, como por exemplo, de concessionrias ou de veculos, so replicados no
banco de dados local e sincronizados diariamente com o mainframe. Por outro lado,
dados como o status das propostas, que so altamente volteis, ficaram armazenados
apenas no sistema do computador de grande porte.
Integrao

152

A integrao com o mainframe foi grande e toda a inteligncia continuou no sistema

de crdito do computador de grande porte, sendo que a tecnologia Web foi utilizada
basicamente como uma interface para acesso ao mainframe. A integrao Webmainframe foi a parte crtica do projeto, pois, diferente do primeiro, este iria substituir
um sistema que j operava de forma automtica. Assim, no era aceitvel que um novo
sistema fosse desenvolvido para operar forma manual.
O banco de dados do sistema Web teve a funo, alm de armazenar temporariamente
os dados digitados e ainda no enviados, de permitir a pr-validao dos dados. Para
tanto, as tabelas de apoio eram sincronizadas com as do mainframe toda noite e, como
foi usado um SGBD adequado, no houve dificuldade para implementar tal funo.
Atualmente, no h integrao com eventuais sistemas de informao das
concessionrias. Assim, se a concessionria possuir algum outro sistema preciso redigitar os dados no sistema do banco. A necessidade de agregao de novos servios de
integrao j percebida pela rea de informtica do banco, mas espera-se que sejam
desenvolvidos apenas aps a implantao do sistema em todas as concessionrias.

7.8.2.2 Interessados
Equipe de desenvolvimento
Houve a participao de uma outra empresa no desenvolvimento. O trabalho foi
organizado de forma que o banco fosse responsvel por definir as atividades que
deveriam ser realizadas pela contratada e quais seriam as entregas intermedirias do
projeto, tais como diagramas de anlise essencial do sistema, prottipo de telas, projeto
lgico e fsico do banco de dados.
A equipe de desenvolvimento foi formada por dois funcionrios do banco, sendo que
um atuou como o coordenador do projeto e o outro como analista de sistemas. Da
contratada participaram um coordenador, dois analistas de sistemas e quatro
programadores. Houve a participao tambm de quatro usurios das reas de anlise de
crdito, risco de crdito, O&M e comercial. Antes do incio do projeto a empresa
contratada j conhecia a tecnologia Web.
reas de negcio cliente
O sistema foi proposto e financiado pela prpria rea de informtica. Isto porque, como
j existia um sistema sendo utilizado e o novo sistema no ofereceria, pelo menos
inicialmente, novas funes, o impacto no negcio seria indireto. Ou seja, com a nova
tecnologia o custo de operao do sistema seria reduzido permitindo que novos
parceiros pudessem utiliz-lo, mas pouco mudaria nos processos de trabalho das reas
usurios no banco e das concessionrias. Assim, acreditamos que seja natural tal
iniciativa ter partido da rea que tem maior contato com a TI e com melhores condies
de identificar as potencialidades da tecnologia Web.

153

Principais usurios
Como no outro projeto, os analistas de crdito utilizam informaes geradas pelo
sistema, mas operam diretamente no mainframe e no na parte Web. Assim, as
concessionrias so as maiores usurias do sistema.
No foi necessria uma participao intensa dos usurios no projeto, pois as funes do
sistema j eram conhecidas pela rea de informtica, uma vez que j existiam no
sistema at ento utilizado. Alm disso, as melhorias que seriam incorporadas ao novo
sistema foram propostas pela rea de informtica, a qual tinha adquirido bastante
experincia sobre as necessidades das concessionrias devido s restries do sistema
anterior. Como conseqncia, a prpria rea de informtica que foi responsvel por
validar o sistema.

7.8.2.3 Tarefas
Planejamento e estudo de viabilidade
Antes do incio do desenvolvimento houve um estudo para verificar a viabilidade
tcnica da integrao Web-mainframe. Somente aps estudar as ferramentas disponveis
no mercado, selecionar a mais adequada e realizar testes para garantir que os requisitos
de performance definidos pelo banco estavam sendo atendidos que o projeto comeou.
Essa questo da integrao foi considerada chave, uma vez que se no fosse possvel
oferecer comunicao on-line com o mainframe o sistema no seria vivel. Segundo o
entrevistado, outros bancos utilizam ferramentas de comunicao assncrona entre Web
e mainframe, mas o banco acreditava que o usurio deveria utilizar o sistema como se
estivesse na frente de um terminal do mainframe, pois, em termos de crdito, todas as
medies na central de crdito so feitas em cima do tempo de resposta. Alm disso, o
computador de grande porte no estava sobrecarregado com relao capacidade de
processamento o que possibilitava a adoo de uma soluo sncrona.
A maior dificuldade do planejamento foi lidar com a incerteza com relao tecnologia
que envolvia a integrao Web-mainframe. Esse planejamento da arquitetura do sistema
levou o entrevistado a afirmar que hoje ns achamos que aquela teoria que diz que
voc deve demorar muito tempo planejando e pouco tempo desenvolvendo fato.
Uma vez selecionada a ferramenta, foi aberta uma licitao para definir a empresa que
iria desenvolver. Como no outro projeto, as prprias propostas de desenvolvimento
serviram de apoio ao planejamento, com relao a prazo, custo e equipe.
Anlise
No houve necessidade de utilizar tcnicas de levantamento dos requisitos com os
usurios, pois o sistema implementaria as mesmas funes do sistema anterior e as
alteraes necessrias j eram conhecidas pela rea de informtica.

154

Para definir os impactos nos processos internos houve a participao da rea de O&M
ao longo do desenvolvimento.
Para modelar o comportamento do sistema foi utilizada a tcnica de anlise essencial. O
banco orientou a empresa contratada sobre como modelar o sistema atravs desta
tcnica e ela elaborou os diagramas, cabendo ao banco somente a validao dos
modelos.
Projeto
Como parte do projeto do sistema foram feitas especificaes chamadas de Processos.
Esses processos descreviam a funcionalidade de cada mdulo do sistema e os
processamentos dentro dele, ou seja, no representavam processos de trabalho, mas
processos do sistema. Sua utilizao foi uma adaptao para a tecnologia Web do
desenvolvimento para o mainframe. A validao do projeto entregue pela empresa
contratada foi baseada nestas especificaes.
A modelagem de dados foi feita atravs da estrutura utilizada pelo sistema de crdito do
mainframe e o departamento de administrao de dados foi responsvel pela
documentao. Como o modelo de dados j estava praticamente pronto, no houve
dificuldade.
O projeto das pginas Web do sistema foi baseado no projeto de interface do sistema
anterior. A empresa contratada elaborou prottipos no operacionais das pginas Web
descritos em linguagem HTML, os quais foram validados pelo banco antes de serem
implementados. Conforme descreveu o entrevistado, essa facilidade para montar telas
estticas uma das vantagens de se utilizar a tecnologia Web em comparao com o
desenvolvimento de sistemas para o mainframe.
A navegao do sistema foi representada atravs dos prprios prottipos das pginas
Web e foi projetada de forma simples, com um menu que acionava as principais
funes, sendo parecida com a navegao de sistemas no Web. O aspecto crtico no
foi a navegao, mas a operao do sistema, pois o usurio precisava ter conhecimentos
bsicos de crdito para entender os recursos disponveis.
Embora um designer tenha participado do projeto da interface, o formato das pginas
Web no foi considerado importante uma vez que o sistema no precisava ter apelo
comercial.
A principal dificuldade no projeto foi definir como seriam implementados alguns
recursos como a impresso, atravs da tecnologia Web, de documentos assinados pelo
banco, como os contratos, pois havia a questo da segurana. O banco solicitou
empresa contratada que levantasse as opes de projeto, assim como as vantagens e
desvantagens de cada uma e o prprio banco definiu a mais adequada.

155

Esta forma de conduzir o projeto, onde quase todas as atividades so desenvolvidas por
outras empresas, inclusive as de aquisio de conhecimento na tecnologia, traz uma
srie de benefcios para a empresa contratante. O principal que permite centralizar o
esforo de projeto na deciso da melhor arquitetura do sistema e deixa atividades que
demandam mais esforo, como a obteno de know-how tecnolgico, para a empresa
contratada. Entretanto, um problema desta abordagem que, conforme relatou o
entrevistado, a contratante pode ficar sem o domnio da tecnologia, no sendo
possvel expressar sua opinio tcnica, mas s em termos de funcionalidade. Neste
projeto, o entrevistado relatou que apesar da empresa contratada ter resolvido as
questes tcnicas com perfeio, ele preferiria poder se envolver mais, evitando ficar
totalmente merc de uma soluo que vem de fora. Isto porque, embora a atividade
seja terceirizada a responsabilidade continua da rea de informtica do banco.
Codificao
Conforme mencionado anteriormente, a maior dificuldade na codificao foi conseguir
utilizar a tecnologia para a comunicao Web-mainframe. Uma vez conhecida, a
tecnologia funcionou adequadamente e a soluo adotada neste projeto foi implantada
tambm na automao do sistema para recepo de propostas vindas de Web Sites.
Uma outra questo relacionada codificao refere-se ao mesmo problema descrito
para a atividade de projeto e diz respeito dependncia do conhecimento da empresa
contratada. Ou seja, como a codificao tambm foi terceirizada e executada fora das
instalaes do banco, o ambiente de desenvolvimento foi montado apenas na empresa
contratada. Com isso, o banco ficou bastante dependente da empresa para efetuar
qualquer alterao no sistema. Atualmente, h uma proposta de trazer as atividades de
desenvolvimento para dentro das instalaes do banco, diminuindo dessa forma a
dependncia com relao empresa contratada.
Teste
O teste foi feito inicialmente pela empresa contratada, a qual testou todas funes antes
de entregar o sistema. Um segundo teste foi feito pelos usurios internos em um
ambiente de homologao no prprio banco. No foi citado nenhum problema
relacionado ao teste.
O aspecto considerado mais importante do teste foi a performance do sistema,
principalmente da ferramenta de comunicao Web-mainframe. Antes de adquirir a
ferramenta, foram especificados alguns requisitos de performance que serviram de base
para o teste e a aprovao do sistema. O segundo aspecto considerado mais relevante no
teste foi o da segurana dos dados na comunicao.
Implantao
A implantao e o treinamento dos usurios foram terceirizados. A rea de OEM
participou ativamente do processo e orientou a empresa responsvel na conduo dessas

156

tarefas. No treinamento foram abordadas tanto questes de informtica quanto de

crdito e isso foi considerada uma atividade importante, uma vez que o sistema tem
toda uma gesto de propostas, no simplesmente aprovado e recusado, conforme
descreveu o entrevistado.
O sistema foi projetado para ser mais um canal de comunicao com as concessionrias
e, como os dados esto apenas no sistema de crdito no mainframe, o SIW pode
funcionar em paralelo com o sistema antigo, ou seja, uma proposta pode ser enviada
pelo sistema antigo e consultada pelo novo, sendo que o inverso tambm vlido. O
sistema antigo ainda est instalado em algumas concessionrias como uma forma de
contingncia, mas a tendncia que seja desativado com o tempo.
Alm disso, como o projeto foi baseado em uma larga experincia anterior em
comunicao automtica com as concessionrias, o novo sistema representou, segundo
o entrevistado, um produto melhor em tudo e no teria como as concessionrias no
aceit-lo. Por isso, a implantao tem sido rpida. A cada implantao o banco
disponibiliza tcnicos para que digitem por um ms propostas reais atravs do sistema,
as quais so digitadas na prpria concessionria, simulando o ambiente de produo.
Isso permite que se teste a performance no ambiente real. Em dois meses de
implantao o sistema j estava sendo utilizado por 50% das concessionrias,
distribudas em todo o territrio nacional.
Uma dificuldade citada na implantao foi que, ao contrrio do esperado, a performance
do sistema no era adequada em qualquer tipo de conexo. Assim, o banco passou a
exigir das concessionrias a utilizao de banda larga na comunicao.

7.8.2.4 Estrutura
Metodologia
Como no sistema para recepo de propostas vindas da Web, no foi seguida nenhuma
metodologia formal para o desenvolvimento de sistemas. Da mesma forma, foram
utilizadas algumas tcnicas de anlise e projeto. A anlise essencial, a qual permite
identificar os eventos tratados pelo sistema e de que forma o tratamento, foi usada
para auxiliar na definio do seu comportamento.
Como auxlio atividade de projeto, foi empregada uma adaptao do desenvolvimento
para o mainframe onde foram descritas as funcionalidades dos mdulos da aplicao.
Isto mostra a preocupao em tornar o processo de desenvolvimento controlvel e
permitir que o banco possa avaliar e validar o projeto antes do seu desenvolvimento. Tal
prtica adequada ao desenvolvimento de sistemas, uma vez que permite identificar
falhas e corrigir possveis problemas no incio do projeto, onde o custo de alterao
menor.
De forma geral, como o projeto foi baseado em um sistema existente e os requisitos
eram conhecidos a priori, os modelos utilizados para representar o sistema

157

aparentemente foram adequados. Alm disso, a conduo do projeto esteve muito

vinculada ao domnio da tecnologia, ou seja, houve um grande esforo para definir
requisitos de qualidade e para garantir que a tecnologia disponvel pudesse atend-los.
Por isso, acreditamos que a forma de desenvolvimento tenha sido adequada para o tipo
de sistema construdo. Alm disso, como no outro projeto do banco, houve uma grande
influncia da cultura do desenvolvimento para sistemas processados em
computadores de grande porte na definio das tcnicas e formas de modelagem do
sistema ao longo do desenvolvimento.
Ferramentas
Foi usado o SGBD da Oracle e o servidor Web foi o Web Sphere, da IBM. A ferramenta
de integrao Web-mainframe foi o Host Publishing System, da Attachmate. No houve
o apoio de ferramentas para o desenvolvimento, mas apenas de apoio edio das
pginas Web com cdigo em JavaScript.
Polticas
Como no desenvolvimento do sistema para recepo de propostas vindas da Web, este
tambm seguiu as polticas de terceirizar o mximo possvel e de minimizar a
comunicao com o mainframe atravs de pr-validao dos dados.
Uma outra poltica seguida foi de tentar padronizar as solues que envolviam a
tecnologia Web. Assim, a seleo do conjunto de ferramentas tinha como premissa
servir tambm para os prximos projetos Web. Conforme descreveu o entrevistado, a
ferramenta que permite a integrao Web-mainframe j est sendo considerada oficial
do banco e se algum propuser um outro tipo de soluo para mainframe e Web vai ter
que provar que melhor que essa para substituir. No outro projeto a linguagem de
programao foi PEARL porque j estava em PEARL l e teve que mexer em PEARL
mesmo, enquanto neste projeto optou-se por uma linguagem que provavelmente vai
ser a linguagem oficial do banco para os prximos desenvolvimentos.

7.8.2.5 Sadas
Sistema
Como a tecnologia Web permite reduzir os custos de comunicao, no mais
necessrio restringir a utilizao do sistema apenas aos parceiros mais importantes.
Alm disso, o sistema modular em termos de funes, sendo possvel usar todos os
recursos disponveis ou apenas um subconjunto, o que permite uma melhor adaptao
conforme o porte e as necessidades de cada parceiro. Com o novo sistema, o banco
planeja eliminar totalmente a digitao interna de propostas e a utilizao do sistema
ser um pr-requisito para que uma concessionria torne-se parceira.
Com a reduo da digitao na rea de anlise de crdito, ser possvel centralizar os
recursos do setor na execuo da atividade principal que oferecer bons crditos.

158

Um outro resultado do sistema , conforme mencionado anteriormente, a padronizao

de ferramentas que envolvem tecnologia Web, ou seja, os produtos utilizados no
projeto, principalmente o de comunicao Web-mainframe, j so considerados como
ferramentas oficiais do banco e, provavelmente, sero utilizados em todos os
prximos projetos de sistemas de informao baseados na tecnologia Web.
Por outro lado, o sistema oferece uma srie de vantagens tambm para as
concessionrias. Ele permite melhorar a gesto das propostas, uma vez que automatiza
algumas atividades de controle. As concessionrias fazem, freqentemente, feiras de
automveis em diversos lugares e, com o sistema na Web, possvel utiliz-lo de
qualquer lugar. Antes era preciso levar o computador e configurar todo o ambiente de
comunicao, enquanto que atualmente basta ter uma conexo Internet. Alm disso,
como agora o tempo de resposta para uma anlise de crdito de quinze minutos a
consulta pode ser feita na hora. Como descreveu o entrevistado, enquanto o cliente
toma um caf voc pode fazer toda a aprovao de crdito resultando em agilidade e
credibilidade.
Documentao
Como documentao tcnica foram feitos os diagramas de contexto e os outros
diagramas da anlise essencial. Os mdulos do sistema foram todos documentados.
Alm disso, toda a conduo do projeto foi baseada em documentos. Quando havia
mais de uma possibilidade de projeto, a empresa contratada documentava as possveis
solues e o banco decidia qual era a mais adequada. Com isso, todas as escolhas
tecnolgicas ficaram documentadas.
Como no outro projeto, foram descritos para os usurios os procedimentos que devem
ser seguidos para a operao do sistema e como devem ser tratadas as contingncias.

7.8.3 Comentrios
Os dois projetos do banco descritos neste trabalho mostraram uma forma de construir e
implantar sistemas de informao baseados na tecnologia Web buscando minimizar os
riscos envolvidos na utilizao de uma tecnologia que inicialmente era pouco conhecida
e, ao mesmo tempo, atendendo as oportunidades do negcio geradas em funo da
prpria tecnologia.
O primeiro projeto tinha como um dos objetivos testar a tecnologia Web na
comunicao com parceiros. Diversas questes, tais como aspectos de integrao com o
mainframe, questes de segurana e desempenho precisaram ser resolvidas. Como
resultado, foi desenvolvido um sistema com arquitetura simples e algumas atividades
manuais, mas que utilizou apenas ferramentas e tecnologias j existentes, minimizando
os investimentos, e que pde ser implantado rapidamente. Em um segundo momento, o

159

sistema foi automatizado de forma a eliminar a interveno manual e foi aprimorado

para funcionar on-line com o mainframe.
O segundo projeto pde ser desenvolvido de uma forma mais planejada, tanto porque j
existia um sistema sendo utilizado e que atendia as necessidades das concessionrias,
quanto porque j se conhecia a tecnologia Web o suficiente para garantir que poderia ser
utilizada na comunicao com os parceiros do banco, reduzindo o risco relacionado
tecnologia.
Foi feita uma pesquisa ampla para selecionar as ferramentas e produtos voltados para a
tecnologia Web que serviriam no somente para um sistema, mas que poderiam ser
padronizados e utilizados nos prximos projetos de desenvolvimento de sistemas
baseados na tecnologia Web. Como o banco j tem diversas aplicaes processadas no
mainframe, para que se possa utilizar as vantagens da tecnologia Web sem que seja
preciso reconstruir tais aplicaes em outra plataforma fundamental saber como
implementar tal integrao.
Nestes projetos a tecnologia Web foi utilizada apenas como interface de acesso aos
sistemas existentes e toda a lgica de negcio neles permaneceu. Isto confirma a idia
de que os sistemas baseados na tecnologia Web devem, muitas vezes, ser desenvolvidos
de forma integrada aos sistemas legados. Por outro lado, mostra que j existem
ferramentas robustas o suficiente para permitir que tal integrao seja, pelo menos do
ponto de vista da infra-estrutura, relativamente simples.
Vrias possibilidades de melhoria dos sistemas j so visualizadas pelo banco. A
integrao com sistemas de parceiros, por exemplo, uma funo que pode ser
desenvolvida. Portanto, a utilizao da tecnologia Web est apenas comeando e
provavelmente as possibilidades desta nova tecnologia vai impulsionar a evoluo dos
sistemas e o desenvolvimento de novos.
Quanto forma como foi realizado o desenvolvimento, possvel perceber grande
influncia da cultura do desenvolvimento para grande porte. Tcnicas, como a anlise
essencial e a especificao detalhada dos mdulos da aplicao, foram trazidas deste
ambiente de desenvolvimento, o qual j existe h anos e tem processos de trabalho bem
mais estabelecidos que para a tecnologia Web.
Finalmente, cabe ressaltar a poltica de transferir grande parte das atividades de
desenvolvimento para empresas contratadas. Nestes projetos alm das atividades de
desenvolvimento, foram terceirizadas atividades de implantao, operao e de
aquisio de know-how na tecnologia e nas ferramentas de apoio existentes. Isto
permitiu que o banco pudesse centralizar seus esforos em atividades mais complexas
como as decises mais crticas do projeto.

160

8. Concluses
8.1 INTRODUO
Este trabalho procurou analisar a forma com que os Sistemas de Informao baseados
na Tecnologia Web, chamados de SIW ao longo do texto, tm sido projetados,
construdos e integrados a sistemas existentes. Este tipo de sistema de informao
apresenta caractersticas interessantes para as organizaes e gera, muitas vezes, novas
oportunidades de negcio.
Com base na bibliografia pesquisada, foi definido o conceito de SIW e proposto um
modelo conceitual para guiar o trabalho. Com base nestes conceitos foi realizado um
estudo exploratrio sobre o desenvolvimento de sistemas baseados na tecnologia Web.
Ao identificar as facilidades e dificuldades encontradas neste processo, esperamos
contribuir para que novos SIW possam ser construdos de forma mais adequada.
O modelo da pesquisa foi dividido em cinco conceitos principais. O conceito de
Contexto corresponde ao ambiente organizacional em que ocorreu o desenvolvimento
do SIW. Considera as necessidades de negcio que o sistema deveria atender, alm de
sua natureza e da integrao com outros sistemas j existentes.
O conceito de Interessados corresponde s pessoas ou grupos de pessoas com
interesse nos resultados do esforo de desenvolvimento do sistema. Considerou a equipe
de desenvolvimento e as reas de negcio cliente.
O conceito de Tarefas corresponde s atividades executadas para a construo do
SIW. Considerou o estudo de viabilidade, o planejamento, a anlise, o projeto, a
codificao, o teste e a implantao do sistema.
O conceito de Estrutura corresponde s polticas e atividades que guiam o
desenvolvimento do sistema. Considerou a metodologia, as polticas e as ferramentas de
apoio utilizadas ao longo do processo de desenvolvimento.
O conceito de Sadas corresponde ao resultado do desenvolvimento. Considerou os
produtos gerados e o impacto do sistema na organizao, principalmente as alteraes
nos procedimentos de trabalho e nos benefcios percebidos.
Para atingir os objetivos propostos, foi realizado um estudo de casos mltiplos, onde
foram analisados oito casos em sete empresas de diversos setores, nas quais havia sido
desenvolvido e implantado algum tipo de SIW.

8.2 ANLISE DAS PROPOSIES

Com base no referencial terico, para guiar a pesquisa foram formuladas nove
proposies que so analisadas a seguir:

161

Existem polticas organizacionais que garantem o controle da qualidade no

desenvolvimento de SIW.
Em nenhum dos casos estudados foi observada qualquer poltica organizacional
referente ao controle da qualidade no desenvolvimento de sistemas de informao
baseados na tecnologia Web. Nenhuma das empresas estudadas adotava padres de
certificao da qualidade no desenvolvimento de software tais como CMM. Este fato
pde ser observado no somente no desenvolvimento de sistemas baseados na
tecnologia Web, mas tambm no desenvolvimento de sistemas baseados em outras
tecnologias.
O processo de desenvolvimento de SIW apoiado por metodologias ou tcnicas
de desenvolvimento, sejam elas j existentes ou desenvolvidas pela organizao.
Nenhuma das empresas estudadas seguiu uma metodologia formal para o
desenvolvimento do SIW, seja uma metodologia j existente ou desenvolvida pela
prpria organizao. Uma caracterstica comum observada em todos os casos foi o
desenvolvimento do SIW baseado em algumas tcnicas de apoio, tais como anlise
essencial, modelagem relacional de dados, fluxogramas e prototipagem de telas.
Entretanto, a utilizao destas tcnicas no ocorreu de forma integrada, no podendo ser
considerado, portanto, o uso de uma metodologia.
Com relao ao paradigma de desenvolvimento adotado, todos os casos apresentaram
uma abordagem funcionalista, conforme definida por HIRSCHHEIM & KLEIN (1989),
ou seja, o sistema foi considerado de forma objetiva e sem a preocupao de analisar
os arranjos sociais e organizacionais existentes (HIRSCHHEIM & KLEIN, 1989). Os
enfoques adotados, entretanto, diferiram entre os casos.
Apesar de possurem metodologias oficiais para o desenvolvimento de sistemas de
informao, a empresa de TI e o Banco no as utilizaram no desenvolvimento dos
sistemas descritos neste trabalho. E, em ambas, ainda no foi definido de que forma
deve ocorrer o desenvolvimento de SIW.
A empresa de TI e o Banco adotaram um enfoque mais prximo do estruturado. Tal
enfoque mais evidente nos projetos do Banco, onde houve grande preocupao com a
modelagem da essncia do sistema em contraste com a modelagem fsica. Neste caso,
foi dada grande ateno s transformaes ou processos do sistema; alm da utilizao
de conceitos como o de mdulos. A empresa de TI, por outro lado, embora no tenha
definido tais conceitos de forma to explcita, utilizou algumas tcnicas encontradas no
enfoque estruturado, como modelagem de processos, com pouca nfase na modelagem
dos dados, o que nos leva a classificar o desenvolvimento como uma abordagem
estruturada. A utilizao desse enfoque talvez possa ser explicada pelo fato dessas duas
empresas terem muita experincia no desenvolvimento de sistemas para computadores
de grande porte, tendo uma cultura de mainframe j estabelecida. Uma outra
justificativa para a adoo do enfoque estruturado talvez seja que, nestes casos, o banco
de dados no teve tanta relevncia uma vez que nos projetos do Banco toda a lgica do

162

negcio foi mantida no mainframe e na empresa de TI os principais dados eram

enviados para outros sistemas no sendo nem mantidos no SIW. Isto deve ter
contribudo para que a ateno do desenvolvimento estivesse centrada na modelagem
das transformaes ao invs de nos dados dos sistemas.
Os casos estudados nas empresas de Fast-food, Construo, Mdia e Saneamento
adotaram um enfoque voltado para a modelagem da informao. Nos sistemas
analisados nestes casos, a modelagem de dados representou o aspecto mais importante
do desenvolvimento, e pouca ateno foi colocada nas transformaes ou processos.
J no caso do Conglomerado Industrial, o enfoque adotado estava mais alinhado com o
de Sistemas de Apoio Deciso (SAD), onde h pouca especificao de requisitos e o
desenvolvimento evolucionrio e adaptativo. Tal abordagem pode ser explicada pelo
prprio sistema analisado, que pode ser considerado efetivamente um SAD. Embora a
modelagem de dados tenha sido um aspecto importante, a questo chave foi a
construo dos cubos que representam vises do banco de dados para cada tipo de
anlise de informaes desejada. Assim, enquanto o modelo de dados foi desenvolvido
no incio e refletia as informaes vindas dos sistemas de apoio s operaes, os cubos
sobre os quais as consultas foram montadas, foram sendo definidos de forma evolutiva.
Conforme os usurios testavam as consultas, os requisitos eram definidos e o sistema
construdo, ou seja, o desenvolvimento apresentou caractersticas tpicas do enfoque de
sistemas de apoio deciso.
Os SIW so representados atravs de modelos formais que descrevem sua
estrutura e funcionamento.
A ISA, estrutura genrica para classificao dos modelos para representao de SI
proposta por SOWA & ZACHMAN (1992, p. 590), foi utilizada como base para a
anlise dos modelos que descrevem a estrutura e o funcionamento dos SIW utilizados
nos casos estudados. Cada modelo foi classificado em uma das perspectivas e dentro de
um dos tipos de abstrao propostos na ISA. A Tabela 11 resume, conforme a estrutura
ISA, os tipos de modelos utilizados em cada um dos SIW desenvolvidos.
S foram considerados como modelos os artefatos de projeto que abstraem algum
aspecto do sistema. Dessa forma, prottipos totalmente operacionais de telas no foram
classificados na estrutura ISA, uma vez que j correspondem aos prprios sistemas e
no somente a uma abstrao para efeito de projeto.

163

Escopo

Dado

Funo

Contrutora
(Especificao
dos dados)

Fast-food
(Descrio
das
principais
funes);
Banco 1 e 2 3
(Descrio
das
principais
funes)
Empresa de TI
(Diagrama
de
Fluxo
de
Processos)

Modelo
do
Negcio

Modelo
do
Sistema

Conglomerado
Industrial
(Especificao
dos
Indicadores)
Modelo
Mdia,
da
Construtora,
Tecnolog Fast-food,
ia
Conglomerado
Industrial
e
Banco
2
(Modelo
Relacional);
Conglomerado
Industrial
(Modelo
Multidimensio
nal)
Compone Conglomerado
nte
Industrial
(Dicionrio de
dados);
Banco 1 e 2
(Formato
de
Arquivos)

Rede

Construtora
(Descrio
das
regras de negcio)

Banco
(Descrio
Mdulos)

Tempo

Banco 1 e
2
(Eventos
da Anlise
Essencial)
Fast-food
(Diagram
a
da
navegao
)

2
dos

Pessoa

Motiv
ao

Banco 1 e 2
(Descrio dos
Procedimentos
de
Contingncia)
Saneamento,
Empresa de TI
e
Banco
2
(Pginas
Web
em HTML);
Construtora
(Esboo
em
papel
das
Pginas Web);
Fast-food
(Pginas
Web
em Flash)

Construtora
(Selees
de
dados
mais
complexas)

Tabela 11 Comparao entre os modelos utilizados nos casos estudados

Na maioria dos casos estudados foi utilizado o modelo de dados relacional e alguma
forma de prototipagem das pginas Web. A navegao, que teoricamente seria relevante
3

Banco 1 refere-se a modelos utilizados no desenvolvimento do Sistema para Recepo de Propostas

vindas de Web Sites e Banco 2 refere-se a modelos utilizados no desenvolvimento do Sistema Web para
Recepo de Propostas das Concessionrias.

164

no projeto dos SIW, s foi modelada no caso do Fast-food. Talvez isso possa ser
explicado pelo fato do Fast-food estar disponibilizando funes relativamente
complexas de compra atravs da Web, onde no se tinha controle sobre o perfil dos
usurios. No SIW dos demais casos estudados os usurios eram de empresas parceiras
ou internos organizao, sendo possvel trein-los e apoi-los. Somente no caso da
empresa de Mdia talvez fosse necessrio representar a navegao, uma vez que o
sistema estava disponvel aos clientes externos da empresa. Por outro lado, todos os
SIW dos casos estudados no utilizaram os recursos sofisticados de navegao,
limitando-a ao acesso a conjuntos de pginas Web acionadas por opes de menu,
praticamente sem interligaes entre elas, o que reduziu a complexidade da estrutura de
navegao.
Nos casos estudados houve pouca utilizao de modelos de sistemas. A maioria das
especificaes elaboradas correspondeu a descries em linguagem natural, menos
formais do que os diagramas e frmulas matemticas, tornando pouco provvel que esta
especificao seja consistente e sem ambigidades. Exceto para as clulas da primeira
linha (Escopo) da estrutura ISA, praticamente todas as outras perspectivas podem ser
representadas atravs de modelos formais que permitem uma preciso maior na
especificao.
Em vrios casos, a justificativa observada para a pouca utilizao de recursos e tcnicas
de modelagem foi a simplicidade do sistema ou o reduzido tempo disponvel para o
desenvolvimento. Justificativas fracas, uma vez que a questo da simplicidade do
sistema muito relativa e perigosa e a questo do tempo reduzido para o
desenvolvimento uma constante.
Uma possvel explicao para a pouca utilizao de modelagem formal pode estar
relacionada dificuldade dos profissionais envolvidos para modelar. Os principais
modelos utilizados para representar os sistemas foram o relacional e os prottipos de
telas, que podem ser diretamente traduzidos em cdigo de software. O modelo
relacional, por exemplo, permite gerar diretamente as tabelas no banco de dados. A
traduo direta a ponto de praticamente todas as ferramentas CASE do mercado
oferecerem funes automticas para isto. Por sua vez, o prottipo de telas representa
uma parte visvel do software, muitas vezes at levando os usurios a confundi-los com
o prprio sistema. Modelos como os gerados na anlise essencial ou como uma tcnica
que defina processos organizacionais, tais como os diagramas de processos, contm
elementos mais abstratos que no podem ser diretamente traduzidos para o
software. Ao nosso ver, a resistncia dos profissionais de TI em modelar est na
dificuldade em abstrair caractersticas do sistema que no apresentam relao direta
com o produto final do desenvolvimento, ou seja, com o cdigo do software. Entretanto,
para verificar se esta hiptese vlida torna-se necessrio o desenvolvimento de novos
estudos, pois tal anlise est alm do escopo deste trabalho.
Em nenhum dos casos estudados foi utilizada uma linguagem de modelagem
padronizada tal como UML ou OPEN. Alm das razes j apontadas para a pouca
utilizao de recursos de modelagem, esta constatao talvez possa tambm ser

165

explicada pelo fato dessas iniciativas de padronizao de linguagens de modelagem

serem recentes e ainda no serem dominadas pela maioria dos profissionais de TI.
O desenvolvimento de SIW baseia-se em abordagens evolutivas ao invs de
seqenciais.
Nem sempre evidente a abordagem utilizada no desenvolvimento dos sistemas de
informao. No h uma diviso muito clara, por exemplo, entre o desenvolvimento
aleatrio e o desenvolvimento iterativo, uma vez que nas duas estratgias h pouco
esforo alocado nas atividades de planejamento, anlise e projeto. Neste trabalho, para
classificar a estratgia do desenvolvimento entre iterativa e aleatria verificamos se
houve alguma atividade de definio antes do incio da codificao do sistema. Se sim,
ento a abordagem foi classificada como iterativa e, caso contrrio, como aleatria.
Por outro lado, os enfoques seqencial e incremental freqentemente se confundem,
uma vez que, mesmo os sistemas desenvolvidos de forma seqencial evoluem,
adquirindo novas funes, o que poderia ser visto como novas iteraes de um projeto
incremental. Neste trabalho, consideramos que o desenvolvimento foi incremental se
todas as fases pertenceram ao mesmo projeto. Em outras palavras, se o desenvolvimento
foi dividido de forma explcita em fases ento a estratgia foi classificada como
incremental. Se, ao contrrio, novas funes foram ou sero acrescentadas em novos
projetos, ento o desenvolvimento foi considerado seqencial.
O caso da empresa de Saneamento foi implementado em duas etapas principais, e
dentro de cada etapa o desenvolvimento foi realizado de forma iterativa, com as funes
sendo definidas, projetadas e implementadas ao longo do desenvolvimento. Como as
atividades foram distribudas em grupos relativamente independentes, podemos
considerar que neste caso as estratgias iterativa e paralela foram utilizadas em
conjunto.
No caso da empresa de TI foram mescladas as estratgias: paralela e iterativa. Aps
desenvolver o ncleo bsico, cada implementao exigia o desenvolvimento de novas
funes que eram definidas e implementadas atravs de caractersticas tpicas do
desenvolvimento iterativo. Alm disso, como o sistema era descentralizado, houve a
possibilidade de desenvolver cada verso em paralelo.
No caso da empresa de Mdia a estratgia utilizada pode ser considerada como iterativa.
Como no havia uma distino clara entre as fronteiras de cada sistema, uma vez que
foram construdos de forma integrada, e como os projetos de cada sistema no foram
conduzidos separadamente, torna-se difcil estabelecer at que ponto podem ser
considerados como um nico projeto com vrias partes em paralelo, uma para cada
subsistema, ou como vrios projetos conduzidos de forma integrada. Entretanto, de
forma geral, observamos que o desenvolvimento possua mais caractersticas de
desenvolvimento iterativo do que de desenvolvimento em paralelo.

166

No caso da empresa Construtora, embora tenha havido uma preocupao maior da

definio do escopo do projeto no seu incio, podemos considerar que a estratgia de
desenvolvimento adotada foi a iterativa, uma vez que as funes do sistema foram
refinadas ao longo do desenvolvimento at que o prottipo se tornasse totalmente
operacional.
No caso da empresa de Fast-food foi adotada a estratgia em paralelo. Para
classificarmos dessa forma, consideramos todo o projeto de Entrega, que inclui outros
sistemas, alm do sistema de pedidos via Web. Cada sistema foi desenvolvido em
paralelo e atravs de projetos separados.
No caso do conglomerado Industrial foi utilizada tanto a estratgia em paralelo como
iterativa. As funes do sistema foram agrupadas em conjuntos independentes que
puderam ser alocados a diferentes grupos de tcnicos trabalhando em paralelo. Por
outro lado, cada conjunto de funes foi desenvolvido atravs da abordagem iterativa
onde, aps a definio com os usurios, as consultas necessrias eram implementadas e
validadas, o que representa uma abordagem iterativa. Conforme descrito na anlise do
caso do conglomerado Industrial, a tecnologia de componentes utilizada facilitou a
adoo de tal estratgia.
A estratgia adotada no primeiro projeto do Banco pode ser classificada como
incremental, uma vez que o projeto foi explicitamente dividido em duas etapas, uma
para implementar as funes bsicas de forma rpida e outra para otimizar e
automatizar o sistema. O segundo projeto do Banco adotou uma abordagem seqencial,
pois foi desenvolvido para substituir um sistema existente. Desta forma, o
desenvolvimento seguiu todas as etapas tpicas do desenvolvimento seqencial.
Portanto, verificamos que em quase todos os casos estudados houve a utilizao de
estratgias evolutivas para o desenvolvimento dos SIW. Alm disso, na maior parte,
ocorreu uma combinao entre duas ou mais estratgias. Embora a utilizao de
modelos para especificar e representar os SIW tenha sido considerada pequena, em
nenhum dos casos a estratgia adotada pde ser considerada aleatria, uma vez que em
todos houve um esforo para analisar o problema e projetar o sistema antes da
codificao do software.
De acordo com o referencial terico pesquisado, as abordagens adotadas tenderam a ser
mais evolutivas do que seqenciais. Uma das razes apontadas relaciona-se ao fato da
tecnologia Web no exigir instalao de software nos computadores clientes dos
usurios. Este fato torna possvel o desenvolvimento e a operacionalizao de conjuntos
menores de funes com mais freqncia ao invs do desenvolvimento de sistemas
completos implantados de uma s vez. Embora tal justificativa seja vlida, alguns casos
estudados mostraram uma segunda razo para a utilizao de abordagens evolutivas.
Como a tecnologia Web estava sendo utilizada em forma de piloto em algumas das
empresas estudadas, o desenvolvimento dos SIW de forma evolutiva reduziu o risco
associado ao desconhecimento da tecnologia, ou, conforme definido por
HIRSCHHEIM, KLEIN & LYYTINEM (1995), a incerteza de recursos. O caso da

167

empresa de Saneamento, por exemplo, mostra que o Portal de Aplicaes serviu como
um projeto piloto para a utilizao da tecnologia Web na empresa. No Banco, por outro
lado, inicialmente foi disponibilizado um sistema com arquitetura simples e
desenvolvido com os recursos existentes. Posteriormente, em um segundo projeto,
quando a tecnologia Web j estava mais conhecida foram feitos maiores investimentos
no SIW.
O desenvolvimento conduzido principalmente por pessoas com perfil tcnico
em TI.
Confirmando o referencial terico pesquisado, em todos os casos estudados o
desenvolvimento foi conduzido por pessoas com o perfil tcnico em TI. Mesmo assim,
em dois dos casos estudados, uma das grandes dificuldades encontradas para o
desenvolvimento dos SIW foi a falta de experincia dos tcnicos que, embora
conhecessem a tecnologia Web e tivessem experincia no desenvolvimento de Web
Sites tradicionais, possuam pouca experincia em desenvolvimento de sistemas de
informao. Alm disso, no caso do Banco foi observado que quase todas as empresas
que participaram das licitaes propuseram metodologias de desenvolvimento que
abordavam apenas aspectos visuais da interface com os usurios, no incluindo outras
atividades de especificao e modelagem de sistemas que certamente seriam teis. Isto
talvez mostre que, embora os SIW estejam sendo reconhecidos como sistemas de
informao ainda h uma associao entre tecnologia Web e desenvolvimento de Web
Sites tradicionais, os quais possuem funcionamento basicamente esttico.
Por outro lado, nos casos das empresas de Saneamento, TI e Fast-food e do
conglomerado Industrial houve grande preocupao com a interface do sistema com os
usurios. Nas empresas de Saneamento e de Fast-food e no conglomerado Industrial
houve a participao de profissionais com perfil artstico (designer) ao longo do
desenvolvimento. Na empresa de TI, embora no tenha havido a participao de
designers no desenvolvimento, os aspectos visuais dos SIW seguiram as normas
contidas em um manual interno. O mesmo ocorreu na empresa de Fast-food, onde, alm
da aderncia ao manual de normas visuais, foi contratada uma empresa de design para
participar do desenvolvimento. Estas constataes esto de acordo com o referencial
terico pesquisado ao revelar que a interface com os usurios em sistemas baseados na
tecnologia Web possui importncia bem maior quando comparada aos sistemas no
Web.
As informaes no estruturadas (tais como textos, imagens, udio e vdeo) so
tratadas como informaes estruturadas ou semi-estruturadas, ou seja, existem
mecanismos estruturados para a recuperao de tais informaes e os SIW
baseiam-se mais em montagem dinmica de informao (pginas Web) do que
em informao esttica.
Em todos os casos estudados as principais pginas Web que compunham os SIW
analisados foram implementadas atravs de montagem dinmica de dados. Apesar de

168

alguns casos utilizarem pginas Web estticas, representavam uma minoria absoluta e
no implementavam as principais funes do SIW analisado.
O nico SIW analisado que tratava dados menos estruturados foi o do caso da empresa
de Saneamento. As notcias, que correspondiam a documentos com textos livres, foram
implementadas de forma estruturada, ou seja, em campos de banco de dados. Alm
disso, o Portal de Aplicaes de Negcios permitia o download de vrios tipos de
arquivos sem estrutura definida. Estas informaes foram tratadas de forma semiestruturada, ou seja, cada arquivo possua no banco de dados do portal atributos que
descreviam seu contedo e localizao fsica, permitindo a realizao de operaes
estruturadas, como buscas, sobre esses dados.
Os casos estudados reafirmaram a argumentao do referencial terico no sentido de
que os SIW, tipicamente, processam dados estruturados ou semi-estruturados. Esta
questo interessante principalmente devido ao histrico da tecnologia Web, onde os
primeiros Web Sites voltados para a divulgao de informaes acoplavam o dado e sua
estrutura em um mesmo elemento (as pginas Web). Nestas aplicaes iniciais, se um
dado precisasse ser alterado era necessrio manipular diretamente o arquivo da pgina
Web. Nos SIW, ao contrrio, h uma separao entre estrutura e dado. Este fato, em
conjunto com a possibilidade de montar dinamicamente as pginas Web, permite que os
SIW tratem seus dados de forma equivalente a um sistema de informao tradicional,
possibilitando realizar sobre tais dados operaes de busca, agregao, ou qualquer
outra que permita extrair novas informaes sobre os dados contidos no sistema.
A validao do SIW pelos usurios feita, principalmente, atravs da
utilizao de prottipos.
O uso de prottipos para representar um sistema de informao, operacional ou
gerencial, foi verificado em todos os SIW analisados. Alm disso, exceto no caso da
empresa de Saneamento, em que no houve validao do sistema pelos usurios, os
prottipos foram utilizados como principal instrumento de acompanhamento do
desenvolvimento por parte dos usurios e de validao dos resultados. Esta constatao
talvez possa ser explicada pelo fato do prottipo ser um modelo mais concreto, ou
seja, bem prximo do sistema e mais facilmente entendido pelos usurios do que um
modelo grfico.
Outros modelos grficos como, por exemplo, o modelo relacional de dados, os modelos
orientados a objetos e modelos de processos muitas vezes so pouco compreendidos
pelos usurios, fazendo com que no consigam visualizar e eventualmente criticar a
soluo projetada. Desta forma, parece que os prottipos tm sido considerados um
mecanismo mais eficaz de comunicao com os usurios.
O desenvolvimento de SIW utiliza conceitos de modelagem vindos da rea de
hipermdia (tais como modelos de navegao, autoria-no-grande, definio
explcita de estruturas de acesso, anlise de relacionamentos e primitivas mais
ricas para a modelagem de dados).

169

Os casos estudados implementaram, de forma geral, SIW com contedo sendo montado
dinamicamente. Entretanto, a apresentao das pginas Web foi implementada
predominantemente de forma esttica, onde estas so apresentadas da mesma forma,
independente do estado da aplicao, mudando apenas o contedo dos dados. Algum
processamento dinmico de apresentao foi encontrado nos menus de navegao dos
SIW, os quais tinham seus itens habilitados conforme o usurio conectado.
A navegao tambm foi implementada de forma predominantemente esttica. Assim,
na maior parte das pginas Web dos sistemas, os endereos das ligaes de cada pgina
eram determinados no momento de construo da pgina e no no momento da sua
montagem. A exceo foi o caso do conglomerado Industrial, onde os componentes
utilizados geravam as ligaes dinamicamente, conforme o estado da aplicao,
permitindo que os usurios tivessem acesso a diversas opes de navegao dentro de
cada consulta.
Os sistemas analisados foram desenvolvidos, de forma geral, implementando a
navegao atravs de opes de menu que permitiam o acionamento das pginas, mas
com poucos recursos de movimentao entre elas. Como conseqncia, a navegao
no foi percebida como um aspecto problemtico ou relevante ao longo do
desenvolvimento e, na maior parte dos casos, nenhuma forma de modelagem foi
utilizada. A empresa de Fast-food foi a nica que utilizou um modelo para representar a
navegao. Entretanto, a tcnica de modelagem utilizada representava apenas um
diagrama de estados da interface no definindo explicitamente as estruturas de acesso
do sistema. Embora tal modelo auxilie a projetar uma interface onde a comunicao
com o usurio seja simples e natural, no fornece apoio definio de interfaces que
implementam estruturas de navegao mais sofisticadas e dinmicas.
No caso do conglomerado Industrial a navegao dinmica foi implementada, mas no
houve necessidade de modelos para represent-la, pois estava embutida nos
componentes, os quais montavam as ligaes automaticamente. Alm dessa navegao
automtica, o sistema possua uma estrutura de menus de opes que permitia, de forma
similar aos outros casos, apenas o acesso a pginas Web para realizar as consultas,
inexistindo navegao entre elas.
Podemos considerar que, embora tenham sido desenvolvidos com a tecnologia Web, os
sistemas estudados implementaram poucas funcionalidades de hipermdia. Embora a
funcionalidade de hipermdia melhore a interface com os usurios, sua utilizao no
obrigatria, sendo possvel desenvolver SIW praticamente sem o uso de recursos de
hipermdia. Na concepo dos Web Sites tradicionais a funcionalidade de hipermdia
um aspecto chave, uma vez que permite atingir o objetivo principal da aplicao de
divulgar informaes de forma que os usurios possam facilmente entend-las. A partir
do momento que a tecnologia Web comeou a ser a plataforma para a construo de
sistemas de informao, o objetivo das aplicaes parece que voltou a se restringir ao
apoio aos processos de negcio e fluxos de trabalho. Em outras palavras, o uso de
funcionalidade hipermdia parece ser ortogonal tecnologia com a qual o sistema de

170

informao implementado, sendo possvel desenvolver tanto SIW sem recursos de

hipermdia quanto SI baseados em tecnologia no Web que implementam
funcionalidade hipermdia.
Nos casos estudados os projetos de SIW foram conduzidos, conforme previsto pelo
referencial terico pesquisado, principalmente por profissionais de TI com perfil
tcnico, sendo que em sua maioria j haviam desenvolvido sistemas de informao em
outras plataformas tecnolgicas. Assim, consideramos natural que tenham trazido
conceitos e padres de desenvolvimento de SI tradicionais e que no percebam a
necessidade ou as vantagens de se implementar recursos de hipermdia nos projetos
baseados na tecnologia Web. Talvez essa seja uma razo que contribua para explicar o
fato dos desenvolvimentos de SIW dos casos estudados terem sido realizados com
muito pouco uso de recursos de hipermdia disponveis na nova tecnologia.
Deve haver grande integrao do SIW com os sistemas existentes.
Nos casos das empresas de Mdia e Fast-food e do Banco os SIW foram construdos de
forma totalmente integrada a outros sistemas. Muitas de suas funes dependiam de
outros sistemas para serem executadas e a comunicao entre eles foi implementada online. No caso da empresa de Mdia, por exemplo, quando um assinante era cadastrado,
parte dos seus dados era registrada no SIW e parte em outro sistema. No caso da
empresa de Fast-food, o SIW consultava outro sistema para determinar os preos
praticados por cada restaurante, alm de alocar os pedidos para outro sistema de
gerenciamento da entrega. Nos projetos do Banco o SIW era basicamente uma interface
Web para o sistema de crdito processado no computador de grande porte.
Nos casos das empresas de Saneamento, Construo, conglomerado Industrial e de TI,
os SIW permitiam transferncia de dados (atravs de rotinas de processamento em lote)
de e para outros sistemas atravs comunicao off-line. Enquanto nos trs primeiros
casos o SIW importava os dados dos outros sistemas, o ltimo caso exportava os dados
coletados pelo SIW para outros sistemas de informao da empresa.
Portanto, todos os casos estudados esto de acordo com o referencial terico pesquisado
no que se refere a estarem sendo desenvolvidos com alguma forma de integrao com
os sistemas existentes na organizao.
interessante observar que nos trs casos onde houve maior integrao, no houve uma
delimitao clara entre as fronteiras do SIW e dos demais sistemas. De fato, o sistema
passou a ser naturalmente considerado como sendo formado pelo conjunto dos sistemas
j existentes e pelo SIW. Nos casos das empresas de Mdia e de Fast-food isto se
refletiu em todas as atividades do desenvolvimento, principalmente nas de
planejamento, uma vez que no estava claro o que deveria ser implementado no projeto
do SIW e o que pertenceria a outro sistema. No caso do Banco, como o sistema
existente centralizou toda a lgica do negcio, houve um impacto menor nas atividades
de desenvolvimento. Nos outros casos, como a troca de informaes utilizou

171

mecanismos tradicionais de troca de arquivos a integrao teve pouco impacto nas

atividades de desenvolvimento.
Finalmente, um aspecto relevante que pode ser observado no caso do Banco foi a
possibilidade de comunicao do SIW com os sistemas baseados em mainframe. De
acordo com o referencial terico, este aspecto abre inmeras possibilidades de
aplicaes em negcios por permitir acesso universal aos sistemas processados
atualmente em computadores de grande porte. Isto por permitir incorporar os novos
recursos oferecidos pela tecnologia Web e, ao mesmo tempo, minimizar o esforo de
alterao dos sistemas em operao. Em vrios setores, como por exemplo, o bancrio,
onde grande parte das aplicaes processada nesta plataforma, diversos novos servios
podero ser oferecidos a parceiros e clientes.

8.3 DISCUSSO DAS QUESTES DE PESQUISA

No incio deste trabalho propusemos a seguinte questo de pesquisa:
COMO est ocorrendo nas organizaes o desenvolvimento de sistemas de
informao baseados na tecnologia Web?
Para responder a esta questo propusemos as seguintes questes secundrias:
QUAIS as principais dificuldades e facilidades relacionadas ao
desenvolvimento de novos sistemas tendo em vista a tecnologia Web?
QUAIS foram e POR QUE ocorreram as mudanas no DSI devido utilizao
da tecnologia Web?
A seguir, discutiremos as respostas que puderam ser obtidas com a realizao da
pesquisa.
QUAIS as principais dificuldades e facilidades relacionadas
desenvolvimento de novos sistemas tendo em vista a tecnologia Web?

ao

Os SIW tipicamente envolvem muitas tecnologias. So utilizados vrios tipos de

linguagens e ferramentas, tais como as voltadas para o processamento nos navegadores,
para a gerao das pginas HTML e de animaes, para a implementao de bancos de
dados e das regras de negcio. Quando o sistema utilizado por mais de uma
organizao, outras tecnologias so envolvidas, tais como as voltadas para a
comunicao. Como conseqncia, h uma grande especializao dos profissionais TI,
pois dificilmente um mesmo profissional consegue conhecer profundamente todas as
tecnologias.
A especializao tambm ocorre nas empresas de consultoria em TI, ou seja, enquanto
algumas organizaes oferecem apenas servios de desenvolvimento, outras
disponibilizam apenas servios de infraestrutura ou de hospedagem de aplicaes. Esta

172

especializao dificulta principalmente a comunicao entre os envolvidos, assim como

o gerenciamento do esforo de desenvolvimento.
Provavelmente devido recente evoluo da tecnologia Web, muitas vezes os
profissionais que a conhecem no possuem experincia em desenvolvimento de
sistemas de informao, mas apenas em desenvolvimento de Web Sites para a
divulgao de informaes, sendo o inverso tambm verdadeiro. Provavelmente
tambm como conseqncia deste histrico da tecnologia Web, muitas vezes os usurios
no compreendem as diferenas entre Web Sites tradicionais e sistemas de informao
para a Web, o que os leva a estabelecer expectativas irreais com relao ao
desenvolvimento, dificultando em alguns casos sua construo. Finalmente, ainda
parece ser difcil contratar servios de desenvolvimento de SIW, uma vez que as
empresas de software tambm possuem, de forma exclusiva, mais experincia em
desenvolvimento de sistemas de informaes tradicionais, ou mais em desenvolvimento
de Web Sites estticos. Aparentemente, ainda h pouca experincia em desenvolvimento
de SIW.
Uma outra dificuldade que os fabricantes de navegadores e servidores Web tm
includo em seus softwares funcionalidades no definidas nos padres da tecnologia
Web. Dessa forma, algumas vezes, tem sido preciso desenvolver verses especficas dos
SIW para cada tipo de navegador, ou direcionar a implementao para apenas um tipo,
restringindo o acesso ao sistema. Acreditamos que uma das razes para isso que a
tecnologia Web ainda relativamente nova, imatura e est evoluindo rapidamente.
Acreditamos tambm que, com sua evoluo e maturidade, provavelmente haver a
convergncia para uma das implementaes dos padres Web e/ou novas ferramentas de
apoio ao desenvolvimento Web permitiro uma converso transparente entre
implementaes distintas, superando talvez as dificuldades para o pleno emprego do
conceito de acesso universal.
Com relao s facilidades oferecidas pela tecnologia Web, podemos citar a
prototipagem da interface com o usurio. Tal facilidade foi ressaltada principalmente
pelos profissionais com forte experincia em desenvolvimento de sistemas para
computadores de grande porte, uma vez que, em tal ambiente, o desenvolvimento de
prottipos de interface no to rpido quanto atravs da tecnologia Web.
Outro aspecto refere-se ao fato de que o desenvolvimento na tecnologia Web no
precisa necessariamente de ferramentas sofisticadas e pode ser feito, por exemplo,
atravs editores de texto simples e ferramentas abertas e livres (sem custo). Embora tal
abordagem provavelmente tenha implicaes na produtividade do DSI, ela permite que
sejam desenvolvidos SIW com investimento relativamente baixo em ferramentas de
apoio, talvez viabilizando projetos onde a disponibilidade de investimento pequena.
Um aspecto observado em um dos casos que representa uma facilidade da tecnologia a
disponibilidade de componentes de software para a Web. Tais componentes representam
uma evoluo para o desenvolvimento de software e focam a reutilizao de cdigo,
permitindo o aumento da produtividade e da qualidade no desenvolvimento.

173

Por fim, a disponibilidade de ferramentas que permitem a comunicao entre a

tecnologia Web e outros sistemas abrem diversas oportunidades de aplicao desta,
principalmente com relao ao desenvolvimento de novas interfaces para sistemas j
existentes.
QUAIS foram e POR QUE ocorreram as mudanas no DSI devido utilizao
da tecnologia Web?
Um fator que, em alguns casos, influenciou o desenvolvimento do SIW foi a
possibilidade de melhorar a imagem institucional da organizao, oferecendo aos
clientes e/ou parceiros sistemas baseados na tecnologia Web. Em alguns casos
estudados, tal aspecto levou implementao de solues menos robustas, mas que
pudessem ser desenvolvidas rapidamente e somente em uma segunda etapa que
ocorreu (ou ocorreria) uma maior preocupao com sua otimizao e qualidade. Isto
mostra que um efeito, aparentemente secundrio, da tecnologia permitir que pessoas
externas organizao possam utilizar o sistema, torn-lo um instrumento primordial
de comunicao e interao, influenciando fortemente a imagem organizacional perante
seus usurios (clientes e parceiros de negcio). Isto reflete no DSI tanto por fomentar o
desenvolvimento de novos sistemas baseados na tecnologia Web como por alterar
sistemas existentes para que ofeream novas funes. Em outras palavras, o fato de
muitos SIW serem utilizados por pessoas externas organizao tem influncia direta
nas decises de projeto ao longo do DSI e grande impacto nos negcios.
Como conseqncia da especializao de tarefas, em alguns casos estudados houve a
necessidade de contratar vrias empresas, cada uma voltada para um tipo de atividade.
Alm disso, devido diversidade de tecnologias envolvidas nos SIW, em alguns casos
foi preciso manter equipes de desenvolvimento maiores do que o normal, pois cada
profissional de TI era especialista em uma ou algumas tecnologias, no havendo tanta
liberdade para organizar o trabalho e dividir as tarefas entre os membros da equipe de
desenvolvimento.
Pode-se observar, atravs dos casos estudados, que os SIW so normalmente
concebidos de forma integrada com os sistemas existentes e com outros sistemas
desenvolvidos em paralelo. Isto exige que o desenvolvimento deva contemplar tarefas
voltadas para o entendimento dos outros sistemas de informao da organizao e de
organizaes parceiras de forma a permitir plena integrao.
Como decorrncia do aumento da importncia da interface dos SIW, em diversos casos
foram includos profissionais com perfil artstico na equipe de desenvolvimento, os
quais eram responsveis principalmente pela formatao visual das pginas Web. Em
alguns casos, tambm foram desenvolvidas polticas voltadas para a padronizao da
interface de todos os sistemas que utilizam a tecnologia Web.
Por ser uma tecnologia recente, as organizaes estudadas ainda no definiram como
deve ser o desenvolvimento de SIW. As metodologias existentes foram adaptadas ou

174

simplesmente no foi utilizada metodologia de desenvolvimento. Assim, o

desenvolvimento foi baseado principalmente em conjuntos de tcnicas utilizadas
isoladamente e que tentavam representar certos aspectos considerados importantes dos
SIW, mas no foi observada a existncia de um roteiro ou mtodo para o uso
sincronizado de tais tcnicas.
A principal tcnica utilizada foi a prototipagem atravs de pginas Web. Os prottipos
serviram no apenas para validar o projeto, mas tambm para validar a anlise do
sistema. A principal razo que, alm de serem desenvolvidos rapidamente com a
tecnologia Web, eles permitiam um melhor entendimento do sistema pelos usurios. Foi
observado tambm que o uso de prottipos serviu como mecanismo de comunicao
no somente com as pessoas de fora da rea de TI como entre os prprios profissionais
de TI.
Finalmente, o impacto da tecnologia Web no DSI no ocorreu da mesma forma em
todos os casos estudados. Isto porque, nos casos onde as regras de negcio e o
processamento so feitos por sistemas implementados em outras tecnologias, tais como
em SGBD ou em outros sistemas, o DSI alterou muito pouco e somente onde a
tecnologia Web teve grande importncia, em termos de esforo de desenvolvimento,
que se observaram as maiores alteraes no DSI.
COMO est ocorrendo nas organizaes o desenvolvimento de sistemas de
informao baseados na tecnologia Web?
Em alguns casos, o SIW desenvolvido foi visto como um projeto piloto da tecnologia
Web. Assim, algumas empresas ainda esto testando as possibilidades e as dificuldades
relacionadas tecnologia atravs de projetos menos crticos e de menor risco. Por outro
lado, em outros casos, o SIW foi utilizado para atender aspectos mais crticos do
negcio como comunicao com parceiros. Nestes casos, para diminuir o risco da
tecnologia, os SIW foram concebidos com arquitetura simples e sem implementar as
regras de negcio. Somente em um dos casos o SIW oferecia funes de maior risco
para o negcio e foi concebido com arquitetura mais complexa. Neste caso, a
implantao tem sido atravs de pilotos, onde a tecnologia pode ser testada em ambiente
real, antes de ser utilizada mais amplamente. Assim, acreditamos que a tecnologia Web
ainda est sendo testada nas organizaes e que somente aps estar disseminada e
que novos projetos mais crticos sero desenvolvidos.
A tecnologia Web foi utilizada em todos os casos como mecanismo de comunicao
entre os usurios e sistemas, mas em nenhum caso implementou comunicao entre
sistemas. Talvez seja conseqncia da tecnologia Web ainda estar, conforme descrito
anteriormente, em uma fase de teste nas empresas pesquisadas. Acreditamos que
haver uma nova etapa (ou iterao) no desenvolvimento de alguns SIW para permitir
integrar sistemas distintos atravs da prpria tecnologia Web.
Em todos os casos, os SIW foram desenvolvidos separando os dados da apresentao e
fazendo a ligao atravs de montagem dinmica das pginas Web. A apresentao e a

175

navegao foram implementadas predominantemente de forma esttica. Pouca

funcionalidade hipermdia foi embutida nos sistemas, restringindo a navegao e
tornando-a mais prxima da navegao em sistemas de informao tradicionais do que
de aplicaes hipermdia.
Em todos os casos houve integrao com os sistemas existentes, embora em alguns ela
tenha sido projetada inicialmente para operar com interveno manual e somente depois
ser automatizada.
O desenvolvimento foi conduzido por profissionais de TI com experincia no
desenvolvimento de sistemas de informao baseados em tecnologias no Web. Isto
confirma a previso terica de que o desenvolvimento dos SIW seria baseado em
equipes com formao tcnica em TI, ao invs de ser conduzido por equipes com
formao mais artstica ou jornalstica, como so, muitas vezes, as equipes que
desenvolvem Web Sites estticos. Por outro lado, embora as equipes tivessem perfil
predominantemente tcnico, alguns profissionais possuam mais experincia em
desenvolvimento visual do que em desenvolvimento de SI.
Em praticamente todos os casos estudados, as tarefas de planejamento, anlise e projeto
foram executadas de maneira informal, sem que fosse gerada documentao sobre seus
resultados. Em alguns casos, praticamente no houve planejamento e as atividades de
anlise e projeto foram realizadas e validadas em conjunto.
O prottipo da interface foi o principal instrumento de validao com os usurios. Em
alguns casos, a validao ocorreu apenas no final do desenvolvimento, durante a
homologao do sistema ou de um mdulo dele.
O desenvolvimento de SIW utilizou poucas tcnicas de modelagem. A anlise s foi
formalmente representada em um caso estudado e o projeto foi representado
principalmente atravs de modelos de dados e prottipos de pginas Web. No foi
utilizada nenhuma modelagem da navegao dos sistemas. Acreditamos que uma
provvel razo reside no fato dos modelos de dados e dos prottipos representarem
elementos diretamente conversveis em cdigo de software, enquanto que outras
tcnicas de modelagem, como a navegao e modelos de regras de negcio, exigem um
grau maior de abstrao. Por outro lado, como os SIW foram projetados com poucos
recursos de navegao, no foi considerado necessrio modelar tal aspecto dos sistemas
estudados.
Como foi elaborada pouca modelagem formal dos SIW, muitos aspectos dos sistemas
foram descritos atravs de linguagem natural, que pode ser inconsistente e permitir
ambigidade. Esforos na utilizao de tcnicas de modelagem mais formais, como a
UML, por exemplo, ainda precisam ser realizados, avaliados e validados.
Nos casos em que o desenvolvimento foi terceirizado houve maior preocupao com a
documentao do planejamento, da anlise e do projeto do sistema. Isto talvez possa ser
considerado um efeito secundrio da terceirizao. Por outro lado, os modelos serviram

176

mais como mecanismo de controle sobre as atividades desenvolvidas pela empresa

contratada do que para guiar o desenvolvimento.
Observamos nos casos estudados que o teste dos SIW foi, geralmente, realizado pelos
prprios tcnicos, no havendo equipe especfica para efetuar tal tarefa. Os usurios
responsveis por validar os sistemas muitas vezes desempenharam o papel de
testadores. Esta situao no foi definida de forma explcita, mas ocorreu pelo fato dos
tcnicos, muitas vezes, no testarem o sistema de forma extensiva.
Mesmo nas empresas que adotam alguma metodologia para o desenvolvimento de
sistemas em outras tecnologias, a metodologia no foi empregada no desenvolvimento
dos SIW. O desenvolvimento foi baseado em enfoques tradicionais de DSI,
principalmente na engenharia da informao e na anlise estruturada.
As ferramentas para o teste foram, em geral, pouco sofisticadas. Em muitos casos houve
a utilizao de editores de texto. Em alguns casos houve tambm a utilizao de
ferramenta CASE para auxiliar na modelagem dos dados. Entretanto, tal ferramenta no
apia o desenvolvimento da parte que envolve a tecnologia Web.
Em todos os casos no foram identificadas polticas para garantir a qualidade em
software, tanto para desenvolvimento envolvendo Web como em outras tecnologias.
Foram apenas identificadas iniciativas de padronizao das interfaces, o que pode ser
entendido como uma conseqncia do fato da importncia da interface nos SIW ser
maior do que era em outras tecnologias.
Em um dos casos, a tecnologia Web j est sendo considerada padro para o
desenvolvimento de novos sistemas de informao. Talvez isso seja um indcio de que a
tecnologia Web seja a principal plataforma para a construo dos novos sistemas de
informao que apiam atividades de negcios.
Mais da metade dos casos desenvolveu alguma forma de documentao para os
usurios. Entretanto, conforme mencionado anteriormente, pouca documentao tcnica
foi gerada.
Em todos os casos estudados o desenvolvimento de SIW foi considerado positivo e
trouxe diversos benefcios s organizaes. Embora isto possa refletir um vis da
pesquisa, decorrente do fato das entrevistas terem sido realizadas apenas com tcnicos
de TI envolvidos nos projetos, talvez possa indicar que o uso da tecnologia Web tem
trazido contribuies s empresas que compensam as dificuldades encontradas durante
o desenvolvimento dos SIW.

8.4 LIMITAES
O desenvolvimento de sistemas de informao um assunto amplo e envolve, conforme
discutimos neste trabalho, diversos conceitos. Uma das limitaes dessa pesquisa foi a
nfase em um conjunto restrito de aspectos tais como estrutura, tarefas e sadas do

177

desenvolvimento de sistemas de informao baseados na tecnologia Web em detrimento

de outros aspectos.
Por este ter sido um estudo de mltiplos casos, as concluses no podem ser
generalizadas, sendo preciso a elaborao de estudos com abordagens quantitativas para
que isto seja possvel.
Em alguns casos foi possvel entrevistar apenas uma pessoa, restringindo a validade de
constructo da pesquisa. Alm disso, somente foram entrevistadas pessoas da rea de TI
diminuindo a confiabilidade das concluses, em especial as relacionadas aos benefcios
percebidos.
Embora a pesquisa apresente as limitaes destacadas acima e, provavelmente, vrias
outras, acreditamos que foi possvel gerar relevantes contribuies para aprimorar e
facilitar a construo dos sistemas de informao baseados na tecnologia Web que
acreditamos serem o futuro das aplicaes de TI nas organizaes modernas.

8.5 RECOMENDAES
Nossas recomendaes e sugestes para continuidade a este trabalho so:
Elaborao de novos estudos sobre o tema, abordando isoladamente cada um dos
tipos de sistemas e verificando em profundidade as principais mudanas nos
aspectos do desenvolvimento geradas pela tecnologia Web;
Elaborao de novos estudos de casos para verificar se a tecnologia Web est sendo
usada como mecanismo de comunicao integrada entre sistemas e quais as
dificuldades e alteraes no desenvolvimento tm sido encontradas;
Desenvolvimento de pesquisas quantitativas para verificar se algumas das
constataes deste trabalho so representativas e podem ser generalizadas;
Desenvolvimento de estudos especficos sobre os impactos da terceirizao no
desenvolvimento de SIW.

178

9. Anexos
9.1 ANEXO I PR-QUESTIONRIO
Prezado Colega,
Na pesquisa que estamos realizando, consideramos SIW - Sistemas de
Informao para a Web as aplicaes de software que utilizam a tecnologia
Web (HTML, XML, HTTP, Java, ASP, ASP.NET, PHP etc.) como plataforma
para a interface usurio-sistema e implementao de regras de negcio ou
para a interface entre sistemas (por exemplo, atravs de Web Services,
XML, SOAP, etc.). Caso a sua empresa esteja envolvida em mais de um
projeto de Sistema de Informao para a Web, escolha o mais significativo
para responder as questes abaixo:
1. Descreva sucintamente os objetivos e as principais funes do sistema:

2. J existe algum mdulo operacional do sistema? Se sim, descreva

resumidamente as funes que j esto sendo utilizadas?

179

3. Houve participao de terceiros externos empresa no desenvolvimento?

Se sim, quais foram as principais atividades desenvolvidas por eles?

4. Quantas pessoas (usurios, analistas, programadores, designers...)

participaram da equipe de desenvolvimento?

5. Considerando todo o projeto, do levantamento das necessidades at a

implantao da primeira verso operacional, quanto tempo durou ou est
previsto durar todo o projeto?

6. Existe alguma forma de autenticao dos usurios no sistema? utilizada

alguma tecnologia para transmisso segura de informaes? Se sim, qual?

180

7. utilizado algum gerenciador de banco de dados para armazenar as

informaes do sistema? Se sim, qual o fabricante e qual o nmero
aproximado de tabelas ou arquivos que compem a base de dados do
sistema?

8. Em relao a sistemas legados (no Web), explique se o SIW escolhido

os substituir, se integrar a eles ou se ocorrero ambas as situaes?

9. Com relao montagem dinmica das pginas Web, marque a

alternativa que melhor descreve o sistema:
Ele utiliza apenas pginas Web estticas (por exemplo, arquivos HTML) e
no utiliza montagem dinmica;
Ele utiliza predominantemente pginas estticas, embora algumas pginas
sejam montadas dinamicamente;
Ele utiliza pginas estticas com a mesma freqncia com que utiliza
montagem dinmica;
Ele utiliza predominantemente montagem dinmica, embora algumas
pginas sejam estticas;
Ele utiliza apenas montagem dinmica de pginas.
Desde j agradecemos sua colaborao,
Um abrao,
Luiz Antonio Zaneti Junior
lzaneti@usp.br
Prof.
Antonio
Geraldo
vidal@usp.br

da

Rocha

Vidal

(orientador)

181

9.2 ANEXO II ROTEIRO DAS ENTREVISTAS

1. Contexto
1.1. Necessidades do negcio
1.1.1. Quais necessidades do negcio o sistema procurou atender?
1.1.2. Por que foi escolhida a plataforma Web?
1.1.3. Quais mudanas nos processos organizacionais o sistema proporcionou?
1.1.4. Quais departamentos ou setores da organizao utilizam o sistema?
1.1.5. O sistema utilizado por outras organizaes? Se sim, quais funes so
utilizadas?
1.2. Natureza do sistema
1.2.1. Que tipo de sistema foi desenvolvido? Quais as suas principais funes?
1.2.2. O sistema lida com informaes no estruturadas? Que tipo?
1.2.3. Que funes do sistema so processadas dinamicamente?
1.2.4. Com que freqncia as informaes das pginas Web so atualizadas (em
outras palavras, quo voltil a informao) ?
1.2.5. Existe alguma forma de identificao dos usurios do sistema? Se sim,
existem mecanismos para envio seguro de senhas? Quais?
1.3. Integrao com sistemas existentes
1.3.1. O sistema comunica-se com quais outros sistemas (internos ou
externos)? Que tipo de informao trocada? Como a comunicao
feita?
1.3.2. Foi desenvolvido algum mdulo especfico para a integrao com os
sistemas existentes?
1.3.3. Quais as principais dificuldades para interligar o sistema aos outros?
Como elas foram contornadas?
2. Interessados
2.1.Equipe de Desenvolvimento
2.1.1. Quantas pessoas participaram da equipe de desenvolvimento?
2.1.2. Quais eram as tarefas de cada um?
2.1.3. Qual o perfil de cada participante da equipe de desenvolvimento?
2.1.4. Os desenvolvedores conheciam a tecnologia Web antes do incio do
projeto?
2.2.reas de negcio clientes
2.2.1. Quem encomendou o sistema?
2.2.2. Quem patrocinou o desenvolvimento do sistema?
2.2.3. De que forma as reas clientes participaram do desenvolvimento?
2.3.Principais usurios
2.3.1. Quais so os principais usurios do desenvolvimento do sistema?
2.3.2. De que forma eles participaram do desenvolvimento do sistema?
2.3.3. Os usurios validaram o sistema ao longo do processo? De que forma?
3. Tarefas
3.1.Planejamento e estudo de viabilidade
3.1.1. Como foi feito o planejamento do desenvolvimento? Quem foi o
responsvel pelo planejamento?

182

3.1.2. Foi feito algum estudo de viabilidade antes do desenvolvimento? Se sim,

quem foi o responsvel? Quais foram os resultados deste estudo?
3.1.3. Quais foram as principais dificuldades relacionadas ao planejamento e
estudo de viabilidade?
3.2.Anlise
3.2.1. Como foi feita a anlise do sistema?
3.2.2. Quais tcnicas de anlise foram utilizadas?
3.2.3. Quem participou da anlise?
3.2.4. Houve alguma forma de validao da anlise? Se sim, quem foi o
responsvel?
3.2.5. Quais foram as principais dificuldades durante a anlise?
3.3.Projeto
3.3.1. Como foi feito o projeto do sistema? Quem participou do projeto do
sistema?
3.3.2. Como foi projetado o banco de dados do sistema? Quais foram os
resultados do projeto de banco de dados?
3.3.3. Como foi projetada a navegao do sistema? Quais foram os resultados
do projeto de navegao?
3.3.4. Quem foi o responsvel pelo projeto da navegao?
3.3.5. Como foi o projeto do layout das telas? Quem foi o responsvel por este
projeto? Quais foram os resultados?
3.3.6. Como foi a integrao entre os profissionais de design e os de sistemas?
3.3.7. Como foi o projeto das informaes no estruturadas (textos HTML
livres, vdeos, imagens, etc.)?
3.3.8. Como foi o projeto da integrao com outros sistemas?
3.3.9. Foi desenvolvido algum prottipo do sistema? Se sim, este prottipo era
funcional ou apenas representava as telas e navegao do sistema?
3.3.10. Foi utilizada alguma linguagem ou tcnica de modelagem padronizada,
como por exemplo, a UML?
3.3.11. Quais foram as principais dificuldades para o projeto do sistema?
3.4.Codificao
3.4.1. Como foi dividido o trabalho de codificao do sistema? Como as partes
foram integradas?
3.4.2. Quem participou da codificao?
3.4.3. Quais foram as principais dificuldades encontradas durante a
codificao? Como elas foram contornadas?
3.5.Teste
3.5.1. Como foi feito o teste do sistema? Quem foi o responsvel pelo teste do
sistema?
3.5.2. Quais foram as principais dificuldades relacionadas ao teste do sistema?
Como elas foram contornadas?
3.6.Implantao
3.6.1. Como foi o processo de implantao do novo sistema?
3.6.2. Como foi feita a migrao do sistema antigo pelo novo?
3.6.3. Com que freqncia (aproximadamente) novas funes foram
implantadas?

183

3.6.4. Foi feito algum treinamento formal dos usurios?

3.6.5. Quais foram as principais dificuldades relacionadas implementao do
sistema? Como elas foram contornadas?
3.6.6. Ocorreram problemas e/ou dificuldades no previstas? Quais? Como
foram tratadas? Houve necessidade de re-trabalho?
4. Estrutura
4.1.Metodologias
4.1.1. Foi utilizada alguma metodologia no desenvolvimento? Quais etapas da
metodologia?
4.1.2. O sistema foi desenvolvido em etapas, ou seja, houve alguma entrega
intermediria do sistema? Se sim, quais foram essas entregas?
4.2.Ferramentas de desenvolvimento
4.2.1. Quais ferramentas de desenvolvimento foram utilizadas?
Tipo
Descrio
Plataforma
CASE
Ambiente RAD
Linguagens
Banco de Dados
Gerador de cdigo
Ferramenta de Teste
Outras
ferramentas
utilizadas
4.2.2. Quais foram as principais dificuldades com relao tecnologia?
4.3.Polticas organizacionais
4.3.1. A sua organizao tem algum certificado de qualidade no
desenvolvimento de software (ISO, CMM...)? Se sim, em que nvel de
certificao ela est? Se no, existe alguma forma padronizada para
controle da qualidade do desenvolvimento?
4.3.2. Existe alguma poltica explcita para o desenvolvimento de sistemas de
informao na organizao?
4.3.3. A sua organizao utiliza alguma metodologia? Quais as etapas da
metodologia? A metodologia foi desenvolvida dentro da empresa? Se
sim, como foi o processo de desenvolvimento dessa metodologia?
5. Sadas
1.1. Sistema
5.1.1. Quais os principais benefcios gerados aos usurios do sistema?
5.1.2. Quais os principais benefcios gerados s reas de negcio?
1.2. Documentao
5.2.1. Que documentos tcnicos foram gerados?
5.2.2. Que documentao de apoio aos usurios foi desenvolvida?

184

10. Referncias Bibliogrficas

ALTER, S. L. Information systems: a management perspective. 2nd ed, Menlo Park:
Benjamin Cumings, 1996.
AMBLER, S. W. Process Patterns: Building Large-Scale Systems Using Object
Technology. Edinburgh Building: Cambridge University, 1998.
ANDERSON, K. M. Integrating Open Hypermedia Systems with the World Wide
Web. In: Conference on Hypertext and Hypermedia, 8th. Proceedings of the eighth
ACM conference on Hypertext. Southampton, UK: ACM, p.157-166, Apr., 1997.
BACON, C.J.; FITZGERALD, B. A Systemic Framework for the Field of
Information Systems. The DATA BASE for Advances in Information Systems, v.32,
n.2, p.46-67, Spring 2001.
BALASUBRAMANIAN, V.; BASHIAN, A. Document Management and Web
Technologies: Alice Marries the Mad Hatter. Communications of the ACM, New
York, v.41, n.7, p.107-115, July 1998.
BERNERS-LEE, T. et al. The World-Wide Web. Communications of the ACM, New
York, v.37, n.8, p.76-82, Aug. 1994.
BERNERS-LEE, T. The World Wide Web Past, Present and Future. Journal of
Digital information, [S.l.], v.1, n.1, 1996. ISSN: 1368-7506. Disponvel
em:<http://jodi.ecs.soton.ac.uk/Articles/v01/i01/BernersLee/>. Acesso em: 11/08/2002.
BIEBER, M.; VITALI, F. Toward Support for Hypermedia on the World Wide
Web. IEEE Computer, v.30, n.1, p.62-70, Jan. 1997.
BIEBER, M. et al. Fourth generation hypermedia: some missing links for the
World Wide Web. International Journal of Human-Computer Studies, v.47, n.1, p.3165, 1997. Disponvel em: <http://ijhcs.open.ac.uk/bieber/bieber.pdf>. Acesso em:
13/5/2001.
BIEBER, M.; ISAKOWITZ, T. (edit.) Designing Hypermedia Applications.
Communications of the ACM, New York, v.38, n.8, p.28-29, Aug. 1995.
BLUM, B. I. A Taxonomy of Software Development Methods. Communications of
the ACM, New York, v.37, n.11, p.82-94, Nov. 1994.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified Modeling Language
User Guide. Reading: Addison-Wesley, 1998.
COSTA, A. B. Implantao do Modelo CMM de Qualidade de Software no Brasil:
Estudos de Caso. 2000. Dissertao (Mestrado) Faculdade de Economia,

185

Administrao e Contabilidade, Departamento de Administrao, Universidade de So

Paulo, So Paulo.
CRESWELL, J. W. Research Design: Qualitative & Quantitative Approaches.
Thousand Oaks: Sage, 1994.
DAVENPORT, T. H. Reengenharia de Processos: Como inovar na empresa atravs
da tecnologia da informao. 5 ed. Rio de Janeiro: Campos, 1994. p.60.
DENNIS, A. R. Lessons from Three Years of Web Development. Communications
of the ACM, New York, v.41, n.7, p.112-113, July 1998.
DONNELLY, V. Designing Easy-to-use Websites: A Hands-on Approach to
Structuring Successful Websites. Harlow: Addison-Wesley, 2001. p.7-12.
FIELDING, R. et al. Web-Based Development of Complex Information Products.
Communications of the ACM, New York, v.41, n.8, p. 84-92, Aug. 1998.
FRATERNALI, P. Tools and Approaches for Developing Data-Intensive Web
Applications: A Survey. ACM Computing Surveys, New York, v.31, n.3, p.227-263,
Sep. 1999.
FRATERNALI, P.; PAOLINI, P. Model-Driven Development of Web Applications:
The Autweb System. ACM Transactions on Information Systems, New York, v.28,
n.4, p.323-382, Oct. 2000.
GARZOTTO, F.; MAINETTI, L.; PAOLINI, P. Hypermedia Design, Analysis, and
Evaluation Issues. Communications of the ACM, New York, v.38, n.8, p.73-86, Aug.
1995.
GARZOTTO, F.; PAOLINI, P.; SCHWABE, D. HDM A Model-Based Approach to
Hypertext Application Design. ACM Transactions on Information Systems, New
York, v.11, n.1, p.1-26, Jan. 1993.
GRAHAM, I.; HENDERSON-SELLERS, B.; YOUNESSI, H. The OPEN Process
Specification. Harlow: Addison-Wesley, 1997.
HARDMAN, L.; BULTERMAN, D. C. A.; ROSSUM, G. V. The Amsterdam
Hypermedia Model: Adding Time and Context to the Dexter Model.
Communications of the ACM, New York, v.37, n.2, p.50-62, Feb. 1994.
HIRSCHHEIM, R.; IIVARY, J.; KLEIN, H. K. A Comparison of Five Alternative
Approaches to Information Systems Development. Australian Journal of Information
Systems, v.5, n.1, Sep. 1997.

186

HIRSCHHEIM, R.; KLEIN, H. K. Four Paradigms of Information Systems

Development. Communications of the ACM, New York, v.32, n.10, p.1199-1216, Oct.
1989.
HIRSCHHEIM, R.; KLEIN, H. K.; LYYTINEM, K. Information Systems
Development And Data Modeling: Conceptual and Philosophical Foundations.
Cambridge: Cambridge University Press, 1995.
IIVARY, J. A paradigmatic analysis of contemporary schools of IS development.
European Journal of Information Systems, v.1, n.4, p.249-272, Aug. 1991.
IIVARY, J.; HIRSCHHEIM, R. Analyzing Information Systems Development: A
Comparison and Analysis of Eight IS Development Approaches. Information
Systems, v.21, n.7, p.551-575, 1996.
IIVARY, J.; HIRSCHHEIM, R.; KLEIN, H. K. A Dynamic Framework for
Classifying Information Systems Development Methodologies and Approaches.
Journal of Management Information Systems, v.17, n.3, p.179-218, Winter 2000-2001.
ISAKOWITZ, T.; BIEBER, M.; VITALI, F. (edit.). Web Information Systems.
Communications of the ACM, New York, v.41, n.7, p.78-80, July 1998.
ISAKOWITZ, T.; KAMIS, A.; KOUFARIS, M. Reconciling Top-Down and BottomUp Design Approaches in RMM. The DATA BASE for Advances in Information
Systems, v.29, n.4, p.58-67, Fall 1998.
ISAKOWITZ, T.; STOHR, E. A.; BALASUBRAMANIAM, P. RMM: A
Methodology for Structured Hypermedia Design. Communications of the ACM,
New York, v.38, n.8, p. 34-44, Aug. 1995.
LAUDON, K. C.; LAUDON, J. P. Management Information Systems: New
Approaches to Organization and Technology. 5th ed. Upper Saddle River: PrenticeHall, 1998.
LEINER, B. M. The Past and Future History of the Internet. Communications of the
ACM, New York, v.40, n.2, p.102-108, Feb. 1997.
LOHSE, G. L.; SPILLER, P. Electronic Shopping. Communications of the ACM, New
York, v.41, n.7, p.81-87, July 1998.
LUCAS, H. C. Information technology for management. 6th ed. New York:
McGraw-Hill, 1997.
MILES, M. B; HUBERMAN, A. M. Qualitative data analysis: an expanded
sourcebook. 2nd ed. Thousand Oaks: SAGE, 1994.

187

NANARD, J; NANARD, M. Hypertext Design Environments and the Hypertext

Design Process. Communications of the ACM, New York, v.38, n.8, p.49-56, Aug.
1995.
NETCRAFT Web Server Survey, The. Pesquisa disponibilizada pela Netcraft sobre
servidores
Web
utilizados
no
mundo.
2002.
Disponvel
em:
<http://www.netcraft.com/survey/>. Acesso em: 9 jul.2002.
NETSIZER Internet Growth Forecasting Tool. Ferramenta para estimar o tamanho da
Internet disponibilizada pela Telcordia Technologies. 2002. Disponvel em:
<http://www.netsizer.com/>. Acesso em: 9 de jul.2002.
NIDUMOLU, S. R.; KNOTTS, G. W. The Effects of Customizability and
Reusability on Perceived Process and Competitive Performance of Software Firms.
MIS Quarterly, v.22, iss.2. p.105-137, June 1998.
NRNBERG, P. J.; ASHMAN, H. What was the question? Reconciling open
hypermedia and World Wide Web research. In: Conference on Hypertext and
Hypermedia, 10th. Proceedings of the tenth ACM Conference on Hypertext and
hypermedia: returning to our diverse roots. Darmstadt Germany: ACM, p. 83-90, Feb.
1999.
OBRIEN, J. A. Sistemas de informao e as decises gerenciais na era da Internet.
So Paulo: Saraiva, 2001. Ttulo Original: Introduction to information systems.
STERBYE, K.; WIIL, U. K. The flag taxonomy of open hypermedia systems. In:
Conference on Hypertext and Hypermedia, 7th, 1996. Proceedings of the the seventh
ACM conference on Hypertext, Bethesda, MD USA: ACM, p.129-139, Mar. 1996.
PATTON, M. Q. Qualitative Evaluation and Research Methods. Newbury Park:
SAGE, 1990.
PEARSON, M.; PAYNTER, J. An Analysis of WWW-based Information Systems.
In: Uniforum New Zealand 98 Conference Proceendings, 1998, Wairakei, New
Zealand.
[S.I.]:
Uniforum
NZ,
1998,
p.163-181.
Disponvel
em:
<http://www.uniforum.org.nz/conferences/1998/papers/pearson.html>. Acesso em: 23
set. 2000.
PRESS, L. The Next Generation of Business Data Processing. Communications of
the ACM, New York, v.42, n.2, p.13-16, Feb. 1999.
ROSSI, M.; BRINKKEMPER, S. Complexity Metrics for Systems Development
Methods and Techniques. Information Systems, v.21, n.2, 1996.

188

ROSSI, G.; SCHWABE, D.; LYARDER, F. Web Application Models are mode than
Conceptual Models. In: Proceedings of ER99, 1999, Paris. [S.I]: ER Workshops 1999.
Disponvel em: <http://citeseer.nj.nec.com/rossi99web.html>. Acesso em: 9 jul. 2002.
RUTHFIELD, S. The Internets History and Development: From Wartime Tool to
the Fish-Cam. ACM Crossroads, New York, Jan.2001. Disponvel em:
<http://www.acm.org/crossroads/xrds2-1/inet-history.html>. Acesso em: 21 jan. 2002.
SAMBAMURTHY, V.; KIRSCH, L. J. An Integrative Framework of the
Information Systems Development Process. Decision Sciences, v.31, n.2, p.391-411,
Spring 2000.
SCHARL, A. A Conceptual, User-Centric Approach To Modeling Web
Information Systems. In: Australian World Wide Web Conference, 5th, 1999, Ballina,
Austrlia. Proceedings of the Fifth Australian World Wide Web Conference. [S.I.:s.n.],
Apr. 1999.
SELLTIZ, C. et.al. Research Methods in Social Relations. New York: Society for the
Psychological study of Social Issues, 1959.
SOWA, J. F.; ZACHMAN, J. A. Extending and formalizing the framework for
information systems architecture. IBM Systems Journal, v.31, n.3, p.590-616, 1992.
SCHWABE, D.; ROSSI, G. The Object-Oriented Hypermedia Design Model.
Communications of the ACM, New York, v.38, n.8, p.45-46, Aug. 1995.
SCHWABE, D.; ROSSI, G.; GARRIDO, A. Designing Web Information Systems.
Rio De Janeiro: PUC-RJ, p.1-19, 1998. ISSN 0103-9741.
STOTTS, P. D.; FURUTA, R. Petri-Net-Based Hypertext: Document Structure with
Browsing Semantics. ACM Transactions on Information Systems, New York, v.7, n.1,
p.3-29, Jan. 1989.
TAKAHASHI, K. Metalevel Links: More Power to Your Links. Communications of
the ACM, New York, v.41, n.7, p.103-105, July 1998.
TAKAHASHI, K.; LIANG, E. Analysis and Design of Web-based Information
Systems. In: Sixth International World Wide Web Conference, 6th, 1997, Santa Clara,
California, EUA. Proceedings of the Sixth International World Wide Web Conference,
[S.I.:s.n.],
Apr.
1997.
Disponvel
em:
<http://www.scope.gmd.de/info/www6/technical/paper245/paper245.html>. Acesso em:
9 jul.2002.
THRING, M.; HANNEMANN, J.; HAAKE, J. M. Hypermedia and Cognition:
Designing for Comprehension. Communications of the ACM, New York, v.38, n.8,
p.57-66, Aug. 1995.

189

TRAVIS, B. E. XML Soap Programming for BizTalk Servers. Redmond: Microsoft,

2000. p.133.
TROYER, O. M. F.; LEUNE, C. J. WSDM: a user centered design method for Web
sites. In: Computer Networks and ISDN systems, 7th, 1998, Brisbane, Austrlia.
Proceedings of the Seventh International World Wide Web Conference. [S.I.]: Elsevier,
Apr.
1998,
p.
85-94.
Disponvel
em:
<http://www7.scu.edu.au/programme/fullpapers/1853/com1853.htm>. Acesso em: 9 jul.
2002.
VESSEY, I.; GLASS, R. Strong Vs. Weak Approaches to Systems Development.
Communications of the ACM, New York, EUA, v.41, n.4, p.99-102, Apr. 1998.
WHITLEY, E. A. Method-ISM in Practice: Investigating the Relationship Between
Method and Understanding in Web Page Design. In: International Conference on
Information Systems, 19th, 1998, Helsinki, Finland. Proceedings of the International
Conference on Information Systems, Atlanta, Georgia: Association for Information
Systems, Dec. 1998, p.68-75. Disponvel em: <http://is.lse.ac.uk/wp/pdf/wp71.pdf>.
Acesso em 9 jul. 2002.
YANES, B. The Emerging Role of Electronic Marketplaces on the Internet.
Communications of the ACM, New York, EUA, v.41, n.8, p.35-42, Aug. 1998.
YIN, R. K. Case Study Research: Design and Methods. 2 ed. Thousand Oaks: Sage,
1994.
YOO, J.; BIEBER, M. Finding Linking Opportunities through Relationship-Based
Analisis. In: Conference on Hypertext and Hypermedia. Proceedings of the eleventh
ACM on Hypertext and hypermedia, San Antonio, Texas, USA, 2000, p. 181-189.
ZACHMAN, J. A. A framework for information systems architecture. IBM Systems
Journal, v.38, n.2 e 3, p.454-470, 1999. Reimpresso de: IBM Systems Journal, v.26, n.3,
1987.