Ubiquidade em Sistemas de Informao para a Sade

Snia Cristina Vermelho

UNICESUMAR
Av Guerdner, 1610, Maring,
Pr, Brazil
cristina.vermelho@gmail.com
+55 44 9923 1789

Alexandre Valle de Carvalho

INESC-Porto/FEUP
Rua Doutor Roberto Frias 378,
Porto, Portugal
alexandre.carvalho@inescporto.pt

+351 22 209 4199

ABSTRACT

The paper reports results of research in the area of software

engineering, focusing on the requirements elicitation phase.
The objective was to analyze the limits and contradictions
between the theoretical component of the requirements
gathering, the corresponding practice and implementation
in information systems. We collected data with two teams
developing systems using qualitative methods of social
research. We identified in the literature and professional
practice a weakness to integrate environmental, social and
cultural contexts in requirements elicitation activity. We
conclude that this weakness is due, among other factors, the
inadequacy of the methods used for modeling the system
which are overly focused on business and with little
concern for the broader application context.
Author Keywords

Specification requirements; Software Engineering;;

ACM Classification Keywords
D.2.1 [Requirements/Specifications]: Elicitation methods
INTRODUCTION

Can we really look to technology itself for a solution?

(Weiser & Brown, 1995, p.2).
Machines that fit the human environment, instead of
forcing humans to enter theirs, will make using a computer
as refreshing as taking a walk in the woods. (Weiser, 1991,
p. 104)
As premissas da computao ubqua para o campo dos
sistemas de informao na rea da sade ainda no esto
presentes no dia a dia da maioria das instituies, estejam
estas em pases desenvolvidos, em desenvolvimento ou
subdesenvolvidos (WHO, 2006).
Os investimentos em sistemas de informao de qualidade
na rea da sade so estratgicos para a maioria dos pases.
Tanto o controle dos gastos, quanto o entendimento do
perfil do processo sade-doena, so informaes preciosas.
Isso levou os organismos internacionais a criarem linhas de
ao permanentes para atuar sobre essa realidade (WHO,
2012).
Contudo, dificuldades para o desenvolvimento de
aplicaes que atendam as reais necessidades da populao,
dos governos e dos especialistas no setor so enormes e

Rui Barros
INESC-Porto
Rua Doutor Roberto Frias 378,
Porto, Portugal
rui.barros@inescporto.pt
+351 22 209 4199

encontradas em inmeros contextos (MURRAY et al,

2011). Predominam ainda empresas que desenvolvem
sistemas de informao para a sade com base em
metodologias que no conseguem superar os problemas em
relao s interfaces, estruturas de dados etc.
Sabemos que a aplicao dos conceitos da computao
ubqua visa criar ambientes informatizados em que os
usurios tenham familiaridade, facilidade e sintonia com o
ambiente. O que se espera que a tecnologia se adapte ao
ambiente, mantendo-o um lugar familiar, sintonizado com
os acontecimentos, preparado para situaes futura e cada
vez mais transparente ao usurio (Weiser & Brown, 1995).
Contudo, essas caractersticas ainda no foram incorporadas
em larga escala nas tecnologias da informao e da
comunicao para a rea da Sade. Numa anlise dos
documentos oficias da Organizao Mundial da Sade, os
investimentos e as estratgias esto alinhadas ainda ao
conceito de e-Health (WHO, 2012). A e-Health sem dvida
um grande avano para a populao, principalmente para
os pases carentes de infraestrutura de sade. Mas ainda
guarda certa distncia da proposta da computao ubqua.
Os problemas enfrentados na atualidade referem-se a
interoperabilidade, segurana de dados, aproveitamento dos
dados atuais, o uso dos dados coletados por pessoas fsicas,
clareza de informaes e "facilidade de uso". Segundo
entendimento dos organismos internacionais europeus, para
o horizonte de 2020, esses problemas precisam ser sanados
sem que se crie um excesso de regulao entre os pases e
sem colocar em primeiro plano as questes de ordem
econmica (EU, 2012).
Diante deste contexto, a pergunta de Weiser & Brown em
meados da dcada de 1990 ainda pertinente: pode a
tecnologia ser uma soluo? Sendo o setor da sade
estratgico para todos os pases, pois est relacionado ao
direito universal de garantia da vida, quais as dificuldades
para criar em escala tecnologias para o setor com base nos
fundamentos da tecnologia calma e da ubiquidade?
Por um lado, sabemos que a produo de artefatos a partir
da Revoluo Industrial traz como principal caracterstica o
fato de ser um processo reproduzvel (MARX, 1985;
BRAVERMAN, 1981; FAYOL, 1950; TAYLOR, 1948);
portanto requer a criao de mtodos de fabricao. Por
outro, independente da metodologia de desenvolvimento de

sistemas utilizada - mtodos tradicionais ou geis - a

questo diz respeito ao tipo de produto desenvolvido, ainda
que exista certa relao entre o mtodo e o produto.
Neste contexto, quais so os maiores entraves para que os
profissionais e as empresas se aproximem do paradigma da
computao ubqua? Se a ubiquidade uma qualidade que
se busca no desenvolvimento das novas aplicaes e
produtos, porque ela ainda restrita a alguns setores no
campo da informtica?
Questo dessa natureza nos motivou a investigar a teoria e a
prtica da engenharia de software. Nesta pesquisa, nosso
objetivo foi analisar o que prev/prope os documentos de
orientao prtica do engenheiro de software e a realidade
que este profissional enfrenta no mercado de trabalho.
Diante da abrangncia do processo, definimos o foco desta
investigao sobre a etapa de levantamento de requisitos.
Nossa hiptese de pesquisa que esta fase requer do
profissional outras habilidades alm do domnio das
ferramentas, linguagens e tcnicas de desenvolvimento, de
avaliao e de validao de sistemas, tais como so
propostas pelos documentos. A ampliao das habilidades e
a mudana de foco no processo de levantamento de
requisitos poderiam criar as condies para que a
computao ubqua fosse incorporada criao de sistemas
na rea da sade.
MTODO DA PESQUISA

A metodologia utilizada na pesquisa foi qualitativa tanto

para a anlise dos documentos, quanto para a pesquisa com
as equipes de desenvolvimento de sistemas.
Utilizamos a Anlise de Contedo (GIBBS, 2009) para
interpretar os documentos orientadores da prtica
profissional dos engenheiros de software. Para a pesquisa
de campo realizamos entrevista semiestruturada e o
tratamento dos dados foi feito com o software Atlas ti,
verso 7.0. O mtodo de anlise foi Anlise do Discurso
para criao das categorias analticas (GIBBS, 2009).
Os documentos utilizados foram o SWEBOK, verso de
2004 e o PMBOK Guide, 5 Edition os quais so
produzidos pelas instncias reguladores das atividades na
rea: ACM e a IEEE Computer Society.
Para anlise da prtica profissional, entrevistamos duas
equipes de desenvolvimento de sistemas de um laboratrio
de pesquisa e desenvolvimento de Portugal.
LIMITAES
DO
PROCESSO
LEVANTAMENTO DE REQUISITOS

FORMAL

DE

Sabemos que a profisso de engenheiro de software hoje

uma das mais requisitadas no mundo e sua principal
atribuio gerir o processo de desenvolvimento de
sistemas. As etapas e o processo de gesto esto definidos
basicamente
em
dois
documentos
reconhecidos
internacionalmente pelas duas maiores instituies do setor:
ACM Association for Computing Machinery e a IEEE
Computer Society. Os documentos so o PMBOK e o

SWEBOK. Estes documentos tm como objetivo orientar o

trabalho do engenheiro de software para garantir o
desenvolvimento de produtos com maior qualidade e menor
custo. Entretanto, ainda persistem problemas no cotidiano
das equipes de desenvolvimento, por exemplo, perda de
desempenho, aumento de custos do produto, alm do stress
entre os profissionais e os stakeholders.
O guia SWEBOK descreve o corpo de conhecimento que
deve ser ministrado no processo de formao dos
profissionais da engenharia de software, e serve ainda como
material para promover o avano da teoria e prtica neste
campo. A sua construo foi guiada pela experincia em
torno das disciplinas que deram sustentabilidade
construo terica e prtica desta rea de conhecimento.
O PMBOK, por seu turno, um documento orientador para
as boas prticas. Por boas prticas, o documento reconhece
que sejam aquelas aplicveis maioria dos projetos na
maior parte do tempo, ainda que no haja consenso sobre
seu valor e utilidade. Apresenta um corpo de
conhecimentos, habilidades, ferramentas e tcnicas que
podem aumentar as chances de sucesso para o
desenvolvimento de sistemas. Ainda fornece um
vocabulrio comum dentro da profisso de engenheiro de
software, em particular para o gerenciamento de projetos.
Este material permite ao profissional a utilizao e
aplicao de conceitos que so reconhecidos mundialmente.
O guia orienta para que no seja tomado como um manual,
pois no significa que o conhecimento descrito deva ser
aplicado na ntegra em todos os projetos e situaes, mas
dever adequado aos contedos e s situaes.
Segundo os documentos analisados, o processo de criao
de um sistema se divide em duas fases ou em dois campos
de atuao profissional: a) Software Engennering
Management e b) Software Engineering Process.
A primeira, Software Engennering Management, a fase
que realiza s primeiras etapas do processo de
desenvolvimento do sistema. Os documentos fazem uma
separao entre as atividades de gerenciamento e de
produo propriamente dita. O gerenciamento compreende
subreas que se articulam com as de produo. A segunda,
Software Engineering Process, se relaciona especificamente
com as atividades de desenvolvimento de sistemas,
incluindo a codificao.
Para conduzir as atividades do engenheiro, so definidos
alguns conceitos. Segundo os documentos, integrante da
atividade do engenheiro de software criar modelos de
sistemas, denominados de Conceptual Modeling. O
Conceptual Modeling , em ltima instncia, um modelo
da realidade. A funo do Conceptual Modeling () to
aid in understanding the problem, rather than to initiate
design of the solution. Hence, conceptual models comprise
models of entities from the problem domain configured to
reflect their real-world relationships and dependencies. (...)
The factors that influence the choice of model include the

nature of the problem. Some types of software demand that

certain aspects be analyzed particularly rigorously.
(Swebok, 2004, p. 2-6)
Para a criao do Modelo Conceitual necessrio a
realizao da etapa de Levantamento de Requisitos
(Requeriment Elicitation). O conceito de Requisito
(requirement) : A requirement is defined as a property
that must be exhibited in order to solve some real-world
problem. (Swebok, 2004, p. 1-3). Ou seja, uma
caracterstica, uma qualidade, um atributo do sistema.
Portanto, esta etapa consiste na identificao do problema,
ou seja, dos processos de trabalho, das pessoas e as
melhorias que o sistema poder trazer aos processos de
trabalho. Esta primeira atividade reconhecidamente uma
atividade humana, impossvel de ser automatizada, pois,
(...) is where the stakeholders are identified and
relationships established between the development team
and the customer. (Swebok, 2004, p. 2-1). fundamental
que se estabelea um bom canal de comunicao entre esses
grupos: engenheiros e os usurios.
Esta etapa, portanto, exigir dos profissionais habilidades e
tcnicas especficas. Diante dessas definies, a primeira
considerao que gostaramos de apontar para o prprio
conceito de requisito. Pela definio dada ao conceito,
encontramos similaridade com os conceitos de processos
de trabalho, ou simplesmente Trabalho, pois diz respeito
s atividades que so realizadas por funcionrios de uma
empresa para se atingir um determinado fim: produo de
um objeto, de um contedo, de um servio etc.
A categoria Trabalho possui longa tradio de pesquisa
nas cincias humanas e sociais, pois a compreenso dos
processos de trabalho permitiu compreender o modo de
produo das sociedades desde a antiguidade
(BRAVERMAN, 1981). O trabalho, enquanto atividade
humana, sempre ocupou lugar fundamental na constituio
de nossa subjetividade. Ele potencializa as aptides e
habilidades humanas, e ainda permite a criao de
ferramentas a partir da apropriao da natureza para a
produo de objetos e alimentos. Portanto, toda a sociedade
atual foi criada por meio do trabalho humano (Marx, 1985,
1989).
Desde meados do sculo XIX, a industrializao vem
transformando os processos de trabalho, retirando do
trabalhador parte das atividades e passando para as
mquinas, introduzindo elementos de controle externos ao
trabalhador. Com isso, o trabalhador passou a dividir com a
mquina o controle do processo. Em decorrncia o trabalho
passou a ser constitudo por uma combinao de trabalho
vivo (do trabalhador) e trabalho morto (materializado na
mquina). A consequncia dessa mudana que a atividade
de trabalho foi se esvaziando de significado e de
importncia para o trabalhador (CROCHIK, 1999;
HARVEY, 1994; MARX, 1985; MARCUSE, 1967).

Essas questes foram compreendidas pelas cincias

humanas e sociais h muito tempo. de consenso a
compreenso de que existe uma complexidade relacionada
ao trabalho em si, enquanto categoria terica. Isto coloca
dificuldades para se identificar as particularidades, as
relaes intrnsecas dos processos de trabalho, tanto
separadamente, quanto no processo de produo como um
todo. Portanto, identificar e definir os requisitos a serem
tratados no sistema de informao so tarefas
potencialmente complexas e permeadas por questes
subjetivas. difcil compreender o processo sem uma
anlise do contexto, das prticas e da cultura da
instituio/empresa em relao gesto e aos processos de
trabalho nos quais o sistema ir atuar. Uma das grandes
referncias tericas para sustentar essa argumentao so as
pesquisas realizadas por Michel de Certeau (1994), Carlo
Ginzburg (2002) e Michel Foucault (1979, 2005, 2005b)
entre outros. Na contramo de uma historiografia da
quantidade e dos personagens famosos, esses pesquisadores
trouxeram tona questes da ordem do cotidiano. Michel
Foucault desvendou o jogo de poder nas microssituaes
cotidianas, mostrando-nos que existe uma microfsica do
poder que foge do controle dos grandes mecanismos de
coero social. Carlo Ginzburg e Michel de Certeau, como
historiadores do cotidiano, contriburam para o
entendimento da sociedade naquilo que a constitui: as
prticas de pessoas comuns, destitudas do poder em todos
os locais, inclusive nos locais de trabalho.
Para nossa discusso, a produo terica de Michel de
Certeau reveste-se de grande importncia. Na obra que
publicou A inveno do cotidiano: as artes do fazer nos
mostrou que diferentemente do que as teorias sociais
clssicas entendiam (Marx, Durkheim e Weber) acerca do
comportamento social, nos locais de interao social, as
pessoas constroem modos de fazer as atividades cotidianas
que subvertem o prescrito (Certeau, 1994). Portanto,
podemos inicialmente apontar duas questes a serem
enfrentadas pelo engenheiro de software diante da tarefa de
realizar o Levantamento de Requisitos: a) Os requisitos, em
ltima instncia, dizem respeito aos processos de trabalho,
os quais guardam uma profunda relao com aspectos
subjetivos da vida do sujeito que o realiza, portanto,
podero existir naturalmente barreiras intransponveis para
compreender o modo de fazer das atividades realizadas
por essas pessoas; b) No cotidiano, entre aquilo que est
prescrito e o que realizado, existe uma distncia que
construda individualmente por cada sujeito em funo da
forma como ele apropria o espao, os objetos e a prpria
tarefa. Portanto, apreender como um processo de trabalho
realizado requer compreender as maneiras de fazer que cada
um foi criando ao longo do tempo. Isto significa que, para
cada pessoa que realiza determinada tarefa, o modo de
realiz-la ser diferente.
Os documentos analisados sugerem algumas formas de
levantamento de requisitos para conseguir identificar os
requisitos do sistema (Swebok, 2004). Os documentos

reconhecem que este processo difcil e que podem ocorrer

algumas situaes tais como: a) dificuldade em descrever
suas tarefas, esquecimento de informaes ou aes
importantes para o processo, ou numa situao pior, o
funcionrio no cooperar com o levantamento de requisitos.
Segundo a orientao do documento: It is particularly
important to understand that elicitation is not a passive
activity, and that, even if cooperative and articulate
stakeholders are available, the software engineer has to
work hard to elicit the right information. (Swebok, 2004,
p. 2-5).
So sugeridas as seguintes tcnicas de coletas de
informaes com os usurios: entrevistas, cenrios ou casos
de uso, prottipos, reunies de mediao e observao.
Sobre cada uma das tcnicas, o que os documentos
explicam o seguinte: a) Entrevista: o meio mais
tradicional, apresenta vantagens e limitaes dependendo
de como conduzida; os Cenrios de Uso: um meio
valioso porque permite a criao de contextos de uso com
questes para identificar como as tarefas so realizadas;
Prottipos so bons para clarificar requerimentos pouco
compreendidos, podem ser usados junto com cenrios de
uso e em geral so validados pelos clientes; Reunies
Facilitadoras: tem a funo de buscar coletivamente
descrever os requisitos do sistema, alm de possibilitar que
conflitos sejam resolvidos com todos. Contudo, requer um
profissional capacitado para atuar como facilitador e ser
bem pensada em termos de organizao e arranjo
(SWEBOK, 2004)
Os trs provveis problemas que o engenheiro poder
enfrentar na interao com o usurio: a) Dificuldade para
descrever a tarefa; b) No explicitar informaes
importantes e c) No se colocar disposto a cooperar,
reconhecidamente so extremamente complexos, pois so
questes de ordem subjetiva. As tcnicas propostas no so
suficientes para superar de maneira segura e profunda esses
problemas.
Vamos traar algumas consideraes sobre esses trs
problemas. Primeiro, pode ser que a dificuldade em
descrever a tarefa esteja relacionada ao fato do funcionrio
conhecer somente uma pequena parte do processo. Desde
que as empresas adotaram o modo de produo do sistema
capitalista, o trabalho passou a ser organizado no modelo
Taylorista/Fordista. Este modelo pressupe a diviso do
trabalho, ou seja, nenhum trabalhador tem o domnio do
processo inteiro, mas somente parte dele. Portanto, ao
descrever a atividade, fatalmente ele deixar de fora um
conjunto de variveis e de informaes que ele no
considera pertinente. S possvel dimensionar se uma
varivel ou atividade importante se tivermos conscincia
da sua funo. Essa conscincia do processo como um todo
contrria ao modo de produo capitalista, mesmo no
atual modelo produtivo baseado nas ilhas de produo.
Segundo, a dificuldade em descrever a tarefa pode estar
relacionada a outro fator: com a negao do trabalhador em

explicitar o modo como ele construiu o processo de

trabalho, cujo modo pode estar em desconformidade com o
que a empresa prescreve. Esses aspectos, se no forem
compreendidos, pode levar ideia de que o funcionrio
deixou de dar informaes importantes (deliberadamente ou
no) ou ainda, que no quer cooperar.
Terceiro, esse problema da descrio da tarefa pode estar
relacionado - e provavelmente seja o motivo mais comum -,
com a ideia de que o trabalhador ser substitudo pela
mquina. No podemos negar de maneira alguma que
muitas empresas contratam o desenvolvimento de sistemas
com o objetivo de diminuir o nmero de funcionrios na
empresa. Diante de um histrico de dcadas em que a rea
vem atuando junto s empresas, diminuindo custos
operacionais, mas causando desemprego, seria ingenuidade
dos engenheiros acharem que hoje isso no seja
considerado pelo trabalhador no momento em que um
engenheiro de software questiona sobre como o trabalho
realizado. Os dados atuais indicam esse quadro na
atualidade (Figura 1). Fatalmente o receio do desemprego,
como j aconteceu com milhares de trabalhadores que
viram seus postos de trabalho desapareceram, est presente
todo o tempo.
Diante do exposto, voltemos aos documentos para analisar
a tcnica provavelmente mais apropriada para realizar a
atividade de levantamento de requisitos: a observao.
Certamente a mais prxima e mais profcua para uma
aproximao com o contexto, portanto, a que possibilita
uma maior compreenso do problema real. A observao
uma tcnica clssica das pesquisas no campo das cincias
sociais e humanas (ANDER-EGG, 1974; ASTI VERA,
1983; BARBIER, 1985; BARROS, & LEHFELD, 2000;
CERVO, 1983; DEMO, 1995; FARINA, 1979; LAKATOS,
& MARCONI, 1985; REA, 2000; SEVERINO, 2000;
THIOLLENT, 1988). Contudo, ela no recomendada em
funo de aspectos econmicos (sic!!): Observation. The
importance of software context within the organizational
environment has led to the adaptation of observational
techniques for requirements elicitation. Software engineers
learn about user tasks by immersing themselves in the
environment and observing how users interact with their
software and with each other. These techniques are
relatively expensive, but they are instructive because they
illustrate that many user tasks and business processes are
too subtle and complex for their actors to describe easily.
(SWEBOK, 2004, p. 2-6)
Com isso, consideramos que os documentos acabam por
realizar uma inverso de valores em relao deciso entre
qualidade e quantidade. importante avaliar qual a relao
custo-benefcio de um levantamento de requisitos
ineficiente e os custos para aplicao desta tcnica. Os
documentos fazem uma abordagem superficial dos
problemas que os engenheiros podem enfrentar e no
apresentam orientao condizente para superar essas
dificuldades. Levando em considerao que a realidade

bastante complexa, e os problemas de ordem econmica,

social e cultural interagem nestes contextos, importante o
engenheiro de software estar preparado para uma
compreenso da realidade. Os custos dos problemas
causados por um levantamento de requisitos inadequado
no so mensurados na economia, mas eles existem.
Este aspecto nos levou a analisar o rol de disciplinas
relacionadas formao do engenheiro de software. Exceto
aquelas de cunho estritamente instrumental, aparece no
Guide to the Software Engineering: body of Knowledge
(SWEBOK, 2004) a indicao de duas disciplinas/reas de
conhecimento que possuem aproximao com as questes
relacionadas dimenso social dos processos de trabalho:
Human-Computer Interaction e Social and Professional
Issues. Neste sentido, a formao fortemente disciplinar do
engenheiro de software pode ser um dos fatores que
contribui para ainda ocorrer a maioria dos problemas
relacionados ao processo de levantamento de requisitos.
No defendemos que ele se torne um socilogo ou
psiclogo, mas deve haver uma maior interao entre essas
reas seja na formao, seja na composio das equipes de
projeto.
Em pesquisa realizada por uma empresa norteamericana de
desenvolvimento de sistemas em 2007 com 500
profissionais de desenvolvimento de sistemas, foi mapeado
os 20 maiores erros relacionados profisso
(CONSTRUX, 2008). Dentro destes, vrios esto
relacionados ao processo de levantamento de requisitos:
Inadequate design , Insufficient planning , Unclear project
vision , Wasted time in the fuzzy front end , Confusing
estimates with targets, Omitting necessary tasks from
estimates, Shortchanged upstream activities, Lack of user
involvement, Requirements gold-plating, Trusting the map
more than the terrain.
O outro documento em anlise, o PMBOOK, detalha como
classificar e realizar a gesto dos interessados com
ferramentas de controle muito rgidas. As ferramentas
propostas
caracterizam-se
fundamentalmente
pela
identificao de pessoas, relaes e processos. Essa
identificao pode ficar limitada quilo que relatado pelos
stakeholders. Uma vez identificado esses componentes
(pessoas, relaes e processos) orienta-se para a elaborao
de diagramas. A orientao que dada para realizar a
transposio da estrutura de relaes e dos processos de
trabalho da realidade para um modelo do sistema no prev
que se observe, por exemplo, a estrutura de poder
intra/intergrupos das corporaes. Tambm no contempla
tcnicas que permita identificar as atividades num processo
de trabalho que so realizadas, mas no so registradas, as
quais so conhecidas como conhecimento tcito.
Pesquisas na Psicologia do Trabalho (Dejours, 2005) j
demonstrou que a ao que cada um desenvolve est
relacionada com o seu envolvimento e motivao com o
trabalho. O grau de interesse varia dependendo da posio
que ocupa. So variveis que interferem diretamente na

forma como os grupos ou indivduos atuam e constroem os

processos de trabalho.
Por isso, pensamos que a orientao que os documentos
apresentam em particular as orientaes contidas no
PMBOOK, para a definio, execuo e gesto do
desenvolvimento de sistemas constitui um arsenal de
ferramentas com baixo potencial de utilizao por
desconsiderar a dimenso subjetiva da realidade.
O processo de desenvolvimento se baseia em "modelos". Os
modelos, em geral, excluem vrios aspectos para que se
possa defini-lo. A modelagem do mundo real uma tarefa
inalcanvel num grau capaz de apreender e articular toda a
complexidade dos contextos, nos tempos e espaos em que
as aes acontecem.
Pensamos que, quanto maior for a aproximao com o
contexto, incluindo as questes de ordem ambiental, social
e cultural, melhores sero as condies para compreender
os processos de trabalho. Isto pode influenciar
sobremaneira para diminuir o gap entre a operao que o
software realiza e a operao que acontece na realidade sem
a mediao do sistema. Com isso, compreendemos que
primordial para delimitar o domnio de um problema
compreend-lo na sua dinmica relacional e cultural. Para
avanar em direo computao ubqua, a percepo do
ambiente, das dinmicas relacionais e dos contextos mais
amplos, tornam-se condio sine qua non.
PESQUISA DE CAMPO

A pesquisa de campo foi realizada com duas equipes de

desenvolvimento de sistemas descritas a seguir.
Equipe 1 (ED01): composta por 4 membros fixos, trs
engenheiros de software e um engenheiro ambiental. Um
dos engenheiros de software e o engenheiro ambiental
trabalham juntos h 13 anos e mostraram ter entrosamento
nas atividades de trabalho. Os outros dois integraram-se ao
grupo recentemente. Utilizam Metodologias geis para
desenvolvimento de sistemas, em funo disso, o grupo
atua de maneira mais flexvel em relao gesto.
Equipe 2 (ED02): composta por 3 membros fixos, sendo
dois engenheiros de software e um bacharel em Cincias da
Informao. Os dois engenheiros atuam juntos h 13 anos e
o bacharel foi incorporado recentemente. Utilizam a
Metodologia Tradicional tendo por base as prerrogativas do
PMBOOK, com isso, os processos de trabalho so mais
formalizados.
Coleta de dados: realizado entrevistas com os dois grupos
de cerca de 1 hora cada um. Durante 60 dias, os grupos
foram observados para compreender a dinmica relacional e
o cotidiano do local de trabalho.
As observaes foram realizadas pelo pesquisador no local
de trabalho.
Tratamento dos dados: as entrevistas foram transcritas e
analisadas por meio do software Atlas.ti 7.0. Desta anlise

foram criadas as seguintes categorias: Levantamento de

Requisitos, Consequncia das aes, Formao acadmica,
Processo de Gesto, Mercado e Negcios. Criamos tambm
trs dimenses na anlise: Profissionais de TI, Organizao
e Fatores Externos. Essas dimenses indicam o grau de
aproximao que a categoria de anlise tem em relao a
atividade do Engenheiro de Software. Por exemplo, foi
agrupado na Dimenso Profissionais de TI aspectos
relacionados diretamente ao profissional, Dimenso
Organizao, aqueles que dizem respeito s empresas, e
Dimenso Fatores Externos, aqueles que no esto
diretamente relacionados empresa ou ao profissional. O
N. a quantidade de citaes encontradas ao longo das
entrevistas e que dizem respeito categoria. Por exemplo,
foram selecionados 35 trechos (N.) das entrevistas em que o
Profissional de TI (Dimenso) abordou o processo de
Levantamento de Requisitos (Categoria).
Categoria de Anlise

Dimenso

N.

Levantamento de Requisitos

Profissionais de TI

35

Consequncias das aes

Profissionais de TI

Formao acadmica

Profissionais de TI

12

Organizao

14

Fatores Externos

Processo de gesto
Mercado e Negcios

Tabela 1: Categorias de Anlise das entrevistas.

A seco seguinte apresenta e discute os resultados

Levantamento de Requisitos

Em termos de tcnica, a entrevista a mais utilizada, alm

de reunies que tambm foram citadas.
A percepo da funo do processo de levantamento de
requisitos foi colocada nos seguintes termos pelos
entrevistados: compreender o problema do cliente a ser
tratado, model-lo, apesar das dificuldades do processo. Em
relao a esse aspecto, as duas equipes foram concordantes:
(...) [a equipe atua] com eles no sentido de abraar os
contributos e necessidades atuais (ED01)
(...) A funo da equipe tentar ajudar o cliente a chegar numa
soluo. (ED02)

Contudo, a condio para que essa funo se realize

percebida como conflituosa e permeada por dificuldades,
tais como:
(...) o usurio entende muito bem do que ele faz, mas isso no
significa que ele conseguir repassar ao informata. (ED01)
(...) Existem situaes em que o que o usurio traz de
informao no suficiente (ED01)

A percepo a de que inevitavelmente acontecem

problemas nesta etapa. Os caminhos apontados para
diminu-los so diferentes: um grupo ampliou o formalismo
e o outro diminuiu. O primeiro argumentou que com grupos
grandes as abordagens so diferentes e quando tinham que

atuar em projetos de forma colaborativa, criava-se um

problema no levantamento de requisitos, para resolver,
definiram um mtodo e um formulrio para ser preenchido
nessa etapa.
(...) As templates so discutidas e preenchidas com o cliente,
em reunio explicado a eles o que ser feito em cada etapa
(ED02)

O segundo utiliza metodologias geis com frequncia e opta

pela prototipao, pois consideram que melhor para
ambos.
(...) mais fcil para o usurio validar uma interface (no
prottipo) do que uma documentao (ED01)

A colaborao dos usurios e a expectativa do cliente so

fatores crticos que apareceram de maneira bastante intensa
nas falas das equipes. O relacionamento entre as equipes de
desenvolvedores com os usurios permeado por tenses e
conflitos. Contudo reconhecem que isso pode variar em
funo da equipe, do perfil das pessoas e da situao. O que
nos levanta a possibilidade de futuras investigaes para
entender quais os contextos em que h maior
tensionamento.
No cotidiano do trabalho, o levantamento de requisitos
realizado por uma pessoa especfica: a engenheira
ambiental e a bacharel em cincias da informao. Os dados
so repassados aos demais membros dos grupos para a
definio do sistema. Contudo, vrias questes interessantes
foram expostas pelos profissionais: a) nem sempre os
resultados dessa atividade so utilizados nas etapas
seguintes, b) acontece de estar prevista nessa etapa, mas
no ser realizada e, c) adequao do perfil do profissional
para a atividade. Por exemplo, algumas falas das equipes:
(...) A fase est prevista, mas nem sempre ela feita, nem
sempre feita com contato com clientes. (ED01)
(...) levanta os requisitos, mas na hora de desenvolver, pe um
tapete e coloca os requisitos embaixo dele (ED01)

Aqui encontramos alguns aspectos a serem analisados: qual

a importncia real dessa etapa no cotidiano das equipes?
Ainda que o PMBOOK no seja um manual a ser seguido
rigidamente, nos pareceu que o grau de flexibilidade que as
equipes adotam bem maior do que se espera.
(...) Se um cliente mais chato, prudente aumentar o
formalismo como uma estratgia de proteo, mas se for uma
pessoa mais acessvel, tranquilo e postura mais aberta e
companheiro, com um entendimento melhor, pode-se relaxar e
diminuir com a formalidade. (ED01)

A justificativa de no serem engenheiros de software a

realizar a atividade para os dois grupos foi praticamente a
mesma:
(...) a bacharel mais aberta para o levantamento, o
informtico chega l, e j quer saber da soluo final, porque
j tem outras experincias em outros projetos, eles cortam no
incio a definio do usurio e a bacharel no (ED02)

Isso nos leva a pensar sobre o perfil do profissional, assunto

que trataremos adiante.
Consequncias das aes

As equipes reconhecem que essa etapa elaborada de

maneira inadequada pode trazer consequncias para todo o
processo: aumenta os riscos de inadequao do produto,
aumenta a tenso entre as partes e complexifica o processo
de gesto. Algumas falas neste sentido:
(...) [especificaes superficiais] E isso aumenta o risco, as
divergncias e torna o trabalho de gesto bem complicado de
fazer. (ED01)
(...) Os requisitos no foram passados corretamente para eles,
e da parte deles tambm no se preocuparam em tratar (...) por
isso acabaram por ter uma relao bastante conflituosa com o
cliente. (ED02)

A mudana de percurso ou de relacionamento com o cliente

nem sempre possvel, e na impossibilidade de alterar o
contexto, muitos projetos acabam por serem abandonados,
tal como j ocorreu na experincia de um dos grupos.
(...) Tiveram falhas na especificao e as empresas mudaram
as especificaes e o projeto acabou por ser abandonado e
ficou no papel (ED01)

Em relao ao gestor, a consequncia percebida de

ampliao da tenso interna e externa, pois o gestor acaba
por assumir mais riscos e responsabilidades:
(...) a equipe tinha feito uma especificao muito superficial
dos requisitos (...) quando h divergncia, o gestor define e
decide sobre isso (ED01)

Por outro lado, a percepo de que quando a anlise

feita de maneira mais ampla, acaba por trazer melhores
condies para o desenvolvimento do trabalho. Isso
possibilita perceber com maior rapidez com quem esto
lidando, compreender os processos e as dificuldades de
comunicao interna.

Formao acadmica

Para que a anlise de requisitos possa ser realizada de uma

forma mais ampla, acreditamos que o engenheiro de
software no possui habilitao condizente com os desafios
que enfrenta no mercado de trabalho. De facto,
consideramos que uma das variveis importantes e
condicionadoras do prprio processo diz respeito prpria
formao do engenheiro de software.
Em geral essa formao possui um perfil quase fundamental
ou mesmo exclusivamente, tcnico, conforme prev o
SWEBOOK. Isso acaba por diminuir as habilidades desse
profissional para lidar com ambientes complexos. Eles
mesmos reconhecem as prprias limitaes para atuar no
processo de levantamento de requisitos. Alguns exemplos:
(...) na formao desenvolvemos um pensamento estruturado
sobre os processos, e forma de funcionar. (ED01)

(...) Quem trabalha em sistemas de informao j tem o

esprito de sistematizar as coisas (ED01)
(...) Outro problema que pode ocorrer quem vai fazer o
levantamento de requisitos no entender do negcio, e tem
que entender as dores dele e tem que entender de
desenvolvimento de sistemas. (ED01)
(...) Para ns (da informtica) impensvel pegar uma
organizao inteira e tentar entender ela inteira (ED02)
(...) A aptido deles e mais para a soluo, mais focada.
(ED02)
(...) O que mais demanda o espirito criativo (ED01)
(...) Quando olha um requisito ele pensa como ele poder ser
implementado (ED01)

Ou seja, a formao tcnica est sendo ineficaz para esta

etapa em funo: a) excesso de pensamento sistemtico, b)
dificuldade para lidar com contextos complexos, c)
dificuldade de compreender o problema de pontos de vistas
distintos.
Processo de gesto

A principal funo do engenheiro de software fazer a

gesto de equipes de desenvolvimento (Pressman, 2010).
Conforme documentos os analisados, o processo de gesto
j foi formalizado em etapas, atividades, variveis de
validao, critrios de qualidade pelos prprios
profissionais do setor.
Ou seja, a formalidade para o processo de gesto j existe.
Contudo, conforme identificmos na pesquisa, a gesto
tambm depende das pessoas e dos contextos. Independente
da metodologia utilizada pelo grupo, em algum momento o
processo de gesto cai em certa informalidade. Isso mostra
que existem problemas entre executar o que preconizado
pela literatura e responder s situaes do cotidiano:
mudana de diretoria, crise no setor, incluso de novos
produtos/processos, composio da equipe etc. Alguns
exemplos significativos dessa situao:
(...) Quem faz a parte de interface? O programador? A
prototipagem, normalmente para quem tiver pacincia, as
vezes no s pacincia, mas a necessidade, quem tiver
disponvel (ED01)
(...) as vezes acontece, do prottipo ser feito sem que a pessoa
tenha lido a documentao para a elaborao do prottipo
(ED01)
(...) com frequncia acontece de ser feita a documentao por
um membro da equipe, deixa disponvel para quem quiser,
mas a equipe possui afinidade tal que um produz a
documentao, mas na verdade ele acha que sabe como a
aplicao vai funcionar e no consulta a documentao para o
desenvolvimento (ED01)

E a questo no est relacionada metodologia adotada,

pois nos dois grupos com metodologias distintas tivemos algumas falas interessantes:

(...) Atua com metodologia mista entre gil e tradicional.

Depende da situao (ED01)
(...) tem que encontrar a metodologia mais adequada para as
situaes e as pessoas que esto atuando e o cliente (ED01)
(...) caso a caso. J atuaram em plataformas mais
colaborativa, e agora esto numa que adotaram. O que pesa
aqui a aprendizagem, o quanto vai custar esse processo de
adaptao da equipe para as ferramentas e ambientes diferente
(ED02)
(...) Possui um modelo que tem anos e tem funcionado, tem
problemas, mas funciona bem (ED01).

Entre o que ensinado nas universidades e o que exigido

no mercado existe uma distncia.
Tendemos a pensar que o pensamento formal dos
profissionais do setor, tem feito com que exista, de um lado,
uma grande preocupao em criar mecanismos de controle
em relao ao processo de desenvolvimento de sistemas
colocado na forma de certificaes e orientaes e, de
outro, uma informalidade na prtica. A distncia entre a
teoria e a prtica se mostrou bastante significativa nesta
pesquisa.
No se trata de avaliar o comprometimento ou a
competncia dos profissionais. Os problemas relacionados
ao levantamento de requisitos so diversos e
frequentemente de natureza multidisciplinar, mas
certamente as dinmicas internas dos grupos de
especificao e desenvolvimento so fatores de grande
impacto e que no tem como controlar por meio de
mtodos, tcnicas ou ferramentas computacionais. Alguns
apontamentos importantes neste sentido:
(...) Isso as vezes questo de estratgia, nem sempre por
no fazer, as vezes so opes assumidas, ns acabamos por
no ter a necessidade (de fazer o levantamento de requisitos),
quando o problema mais ou menos conhecido. (ED01)

Contudo, o que no dimensionado qual a extenso e

quais os prejuzos que essa distncia est trazendo para a
rea de informtica e para a sociedade. A teoria que o
profissional recebe em sua formao diferente da
realidade que ele encontra. Diante da necessidade de
sobrevivncia, aprende na vida prtica, com erros que
acarretam em problemas para a rea e para os clientes. Em
decorrncia, sem as condies adequadas para enfrentar a
realidade das empresas, acaba por falhar na principal
atividade do processo de desenvolvimento de sistemas:
entender o contexto e o problema real que ele deveria ter
plena condio de faz-lo.
Mercado e Negcios

O contexto do mercado e da economia mundial tambm

apareceu nas entrevistas como uma varivel que atua no
processo. Isso ficou explicito nas entrevistas em alguns
exemplos:
(...) Antes da crise existia uma relao diferente, tanto positiva
quanto negativamente. Alguns projetos pararam porque as

empresas perceberam que o contexto no estava pronto para

adquirir novos produtos, mas com a crise, definiram por parar
porque o mercado est em recesso. (ED02)
(...) As empresas j perceberam que quem conseguiu
responder a crise era quem estava melhor com a tecnologia.
As demais empresas j perceberam que tem que informatizar e
os gestores, sabem que precisam mudar, mas demora um
tempo para mudar (ED02)

Contudo, a informatizao e a profisso do engenheiro de

software ainda padecem da alguma imagem negativa
perante outros profissionais, que o setor dificilmente
perder: ser o responsvel pelo aumento do desemprego.
Em sntese, se a tecnologia poder resolver os problemas da
sociedade ainda uma incgnita. Pela pesquisa realizada
com as equipes e na anlise dos documentos, a realidade do
setor ainda est muito distante para incorporar os
fundamentos da computao ubqua e produzir tecnologias
calmas. Os conflitos e os problemas persistem mesmo aps
dcadas de avanos no setor.
Com isso, a sociedade que deveria ser a mais beneficiada
com o desenvolvimento tecnolgico, parece estar
margem: o que importa no deixar a mquina do mercado
parar, seja em relao criao de produtos (ainda que
esses no resolvam os problemas dos clientes) e a formao
de profissionais para o mercado de trabalho.
Neste contexto, as palavras de Max Weiser parecem soar
como promessas inalcanveis para a grande maioria dos
mortais.
CONCLUSION

O enorme acervo terico e prtico das pesquisas no campo

dos sistemas ubquos ainda guarda distanciamento da teoria
e da prtica da atuao dos profissionais de sistemas de
informao. Esse distanciamento traz consequncias sociais
e econmicas, pois milhes de pessoas ainda operam
sistemas de informao ineficientes, que geram um esforo
e sobretrabalho. O custo social e econmico deste
distanciamento entre sistemas ubquos e sistemas de
informao ainda no mensurvel. Porm um desafio
que dever ser enfrentado pelas prximas geraes.
ACKNOWLEDGMENTS

Esta pesquisa foi realizada no ps-doutoramento na

Unidade de Sistemas de Informao e de Computao
Grfica (INESC-Porto/USIG) cuja atuao est voltada para
a definio, prototipagem e concretizao de arquiteturas de
software para sistemas complexos. Ao mesmo tempo, a
Unidade especializa-se na gesto de conhecimento
especfica em projetos de software e suas organizaes,
promovendo a qualidade, teste, verificao e certificao de
software. Com estas atividades, a Unidade pretende
melhorar e inovar as atuais metodologias de
desenvolvimento de software.

We thank all the volunteers, and all publications support

and staff, who wrote and provided helpful comments on
previous versions of this document. As well the authors
gratefully acknowledge the grant from Santander Bank, for
the sponsored the search. Thank UNICESUMAR for
releasing me to the research in Portugal. And a special
thanks to the INESC-Porto for the welcome and the staff
always very valuable guidance of Alexandre Carvalho and
Rui Barros.

15.
THIOLLENT, Michel. 4 ed. Metodologia da
pesquisa ao. So Paulo: Cortez: Autores Associados,
1988.

REFERENCES

17.
WHO - World Health Organization. National
eHealth Strategy Toolkit. Geneve, Switzerland: WHO
Press. 2012. Disponvel em: www.who.int. Acesso em:
15.07.2013.

1. IEEE Institute of Electrical and Electronics Engineers.

SWEBOK Guide to the Software Engineering: body of
Knowledge,
2004
Version.
Disponvel
em:
http://computer.org
2. PMI Project Management Institute. PMBOK Guide; a
Guide to the Project Management Body of Knowledge.
5 edio. 2013. Disponvel em: www.PMI.org.
3. ANDER-EGG, Ezequiel. 4 ed. Introducion a las
tcnicas de investigacin social. Buenos Aires:
Humanitas, 1974.

16.
CONSTRUX. Software Developments Classic
Mistakes
2008.
Disponvel
em:
http://www.construx.com/uploadedFiles/Construx/Const
rux_Content/Resources/Documents/Software
%20Development's%20Classic%20Mistakes
%202008.pdf. Acesso em: 27.11.2013.

18.
BRAVERMAN, Harry. Trabalho e capital
monopolista: a degradao do trabalho no sculo XX. 3
ed. Rio de Janeiro: Zahar, 1981.
19.
FAYOL, Henry. Administrao industrial e geral.
So Paulo: Atlas, 1950.

4. ASTI VERA, Armando. Metodologia da pesquisa

cientfica. Porto Alegre: Globo, 1983.

20.
MARX, Karl. Maquinaria e Grande Indstria. In:O
Capital: crtica da economia poltica. v. 1, Livro
Primeiro, Tomo 2, Captulo XIII. 2 ed. So Paulo: Nova
Cultural, 1985.

5. BARBIER, Ren. A pesquisa-ao na instituio

educativa. Rio de Janeiro: Jorge Zahar, 1985.

21.
TAYLOR, Frederick Winslow. Princpios da
Administrao Cientfica. So Paulo: Atlas, 1948.

6. BARROS, Aidil & LEHFELD, Neide. Fundamentos da

metodologia cientfica. So Paulo: Makron Books, 2000.

22.
WHO - World Health Organization. Building
FOUNDATIONS eHealth: Report of the WHO Global
Observatory for eHealth. WHO Press. 2006. Disponvel
em: www.who.int. Acesso em: 05.10.2013.

7. BARROS, Aidil J. da Silveira & LEHFELD, Neide Ap

de Souza. 2 ed. Fundamentos de metodologia. So
Paulo: Makron Books, 2000.
8. CERVO, Amado Luiz. 3 ed. Metodologia cientfica.
So Paulo: Mc Graw-Hill, 1983.
9. DEMO, Pedro. 2 ed. Introduo a metodologia
cientfica. So Paulo: Atlas, 1987.
10.
DEMO, Pedro. 3 ed. Metodologia cientfica em
cincias sociais. So Paulo: Atlas, 1995.
11.
FARINA, Rafael. Metodologa: normas para la
tcnica del trabajo cientfico. Guatemala: Instituto
Salesiano, 1979.
12.
LAKATOS, Eva Maria & MARCONI, Marina de
Andrade. Fundamentos da metodologia cientfica. So
Paulo: Atlas, 1985.
13.
REA, Louis M. Metodologia da pesquisa: do
planejamento a execuo. So Paulo: Pioneira, 2000.
14.
SEVERINO, Antonio Joaquim. 21
ed.
Metodologia do trabalho cientfico. So Paulo: Cortez,
2000.

23.
GIBBS, G. Anlise de dados qualitativos. Porto
Alegre: ArtMed, 2009.
24.
EC - European Commission. Communication from
the commission to the European Parliament, the
Council, the European Economic and Social Committee
and the Committee of the Regions: ehealth action plan
2012-2020 - innovative healthcare for the 21st century.
Bruxelas, 2012.
25.
MARX, K. e F. Engels. A Ideologia Alem. So
Paulo: Hucitec, 1989.
26.
HARVEY, David. A Condio Ps-moderna: uma
pesquisa sobre as Origens da Mudana Cultural. 4 ed.
So Paulo: Loyola, 1994.
27.
MARCUSE, Herbert. Ideologia da Sociedade
Industrial. Rio de Janeiro: Zahar, 1967.
28.
CERTEAU, Michel de. A inveno do cotidiano:
1. artes de fazer. Petrpolis, Rio de Janeiro, Vozes, 1994.
29.
FOUCAULT, Michel. Microfsica do poder. Rio de
Janeiro: Graal, 2005a.

30.
FOUCAULT, Michel. A arqueologia do saber. Rio
de Janeiro: Forense Universitria, 2005b.

Inquisio. 3 ed. So Paulo: Companhia das letras,

2002.

31.
FOUCAULT, Michel. Microfsica do poder.
Machado. Rio de Janeiro: Edies Graal, 1979.

34.
DEJOURS, C. O fator humano. Rio de Janeiro:
Editora FGV, 2005.

32.
BRAVERMAN, Harry. Trabalho e capital
monopolista: a degradao do trabalho no sculo XX. 3
ed. Rio de Janeiro: Zahar, 1981.

35.
PRESSMAN, R. S. Software Engineering: A
Practitioner's Approach, 7 ed. So Paulo: McGraw Hill,
2010.

33.
GINZBURG, C. O Queijo e os Vermes: o
quotidiano e as ideias de um moleiro perseguido pela