Marquioni
 
 
 
 
Você no Marquioni.com.br
Em breve, você poderá ser um articulista em nosso site. Cadastre-se!
 
Técnico vs. usuário: uma análise do processo comunicacional na Engenharia de Requisitos de Software
Clique aqui para mais informações de como adquirir o livro.
 
 
   
     
 
 
     
 

Selecionar idioma:

Requisitos de software instáveis – Uma análise conceitual de um problema prático
 
 
Autor Carlos Eduardo Marquioni, M.Sc., PMP
 

Resumo:

O presente trabalho formula um problema analítico passível de pesquisa comunicacional, a partir de um problema funcional associado à produção de software. Os profissionais envolvidos com a indústria de software afirmam que o usuário não sabe o que quer, em virtude de modificações com freqüência significativa dos requisitos definidos para o produto. O que se deseja aqui é analisar, do ponto de vista teórico, o que pode levar os usuários à solicitação destes requisitos instáveis. Em seguida, avalia-se, através de uma análise semiótica peirceana, a complexidade envolvida no processo de compreensão dos requisitos de software.

Palavras-chave: Indústria Cultural; alienação; semiótica; software; requisito.

 

 

1. INTRODUÇÃO

Para efeito de contextualização é importante entender o problema funcional que motivou este trabalho, para em seguida realizar uma avaliação teórica e analítica.
O usuário[3] não sabe o que quer. Esta afirmação vem sendo repetida pelos membros da comunidade de software[4] há anos, associada ao fato de os solicitantes de produtos de software não terem claramente definido o resultado que esperam de um sistema[5] quando de sua requisição. Em outras palavras, afirma-se que o indivíduo, ao solicitar um produto de software não teria consciência de qual seria o produto que espera receber como resultado desta solicitação. Esta falta de consciência provocaria mudanças de idéia freqüentes pelos solicitantes, em relação ao produto final desejado.
 
Para compreender melhor quão crítica é essa indefinição do usuário, é necessário entender como ocorre o procedimento de construção de um software, que em sua essência é bastante simples: quando um usuário deseja um software, ele procura um técnico (ou uma empresa fornecedora de software) e lhe conta uma história. Esta história corresponde à necessidade identificada por este usuário que motivou a solicitação do produto e que será decodificada por um técnico em uma linguagem de software através de várias abstrações. Inicialmente, são criados textos; na seqüência os textos são transcritos na forma de diagramas e, finalmente, surgem os programas que são entregues ao solicitante.
 
Ou seja, um técnico (ou às vezes um comitê de técnicos) realiza uma entrevista a um usuário e daí se origina o que é conhecido como requisito, que é a necessidade do usuário transcrita. Cabe questionar aqui porque um técnico que conversou com alguém que o procurou – para descobrir porque este alguém o procurou e documentou sua conversa – afirmaria que este mesmo alguém não sabe o que quer. Uma possibilidade para responder a este questionamento passa pelo fato que produtos de software não são tangíveis. Este caráter etéreo traz embutido em si uma série de características que usualmente se traduzem na dificuldade de comunicação, tanto entre o usuário e o corpo técnico quanto entre representantes do próprio corpo técnico, desde o momento em que o produto de software é concebido.
 
Embora a tecnologia associada ao hardware tenha avançado nas últimas décadas, os processos para estabelecimento de diálogo entre técnicos e não técnicos de informática não evoluíram com a mesma agilidade: existem esforços para documentar o produto de software de forma que sejam gerados artefatos ao mesmo tempo compreensíveis por leigos[6] e passíveis de utilização pela comunidade de software, segundo técnicas de mapeamento de uso comum desta comunidade, mas estes esforços não têm sido suficientes – embora existam ferramentas e técnicas para tal documentação, o diálogo em si não tem sido constituído a contento – em alguns casos, afirmou-se inclusive que a comunicação entre técnicos e não técnicos através de documentos ou diagramas de software não seria possível devido a
[...] muitas vezes ser impossível aos usuários o entenderem, por causa de seu tamanho e dos conceitos técnicos associados a ele. [...] Os usuários freqüentemente se esforçam para compreender estes documentos, porém acabam desistindo e dizendo para si próprios: ‘Bem, eu imagino que esse pessoal do computador saiba o que está fazendo’. Somente quando o sistema já concluído lhes é entregue é que eles podem tentar entendê-lo, porém qualquer ação neste momento é tardia (GANE; SARSON, 1990, p. 3).
 
Fica claro que existe um problema de ordem prática aqui, que é aumentado quando se observa que os trabalhos realizados no sentido de tratar esses problemas têm focado principalmente nas características não funcionais[7] do software, particularmente usabilidade[8]. Sem dúvida questões relacionadas à facilidade de uso são relevantes; contudo, os aspectos da comunicação envolvem características preliminares a este design de interface, que são relacionadas à identificação e formalização das funcionalidades esperadas do produto, além do elo entre essas funcionalidades e tópicos ergonômicos tratados na interface. Em outras palavras, não adianta um design de interface ultra ergonômico se o produto elaborado não tratou características básicas anteriores que garantem que foi elaborado o produto correto.

2. O ASPECTO ANALÍTICO E TEÓRICO

2.1 ALIENAÇÃO E INDÚSTRIA CULTURAL

O fato da intangibilidade dos produtos de software apresentado corresponde a um caminho de análise. Contudo, primeiramente, cabe procurar o que poderiam ser as causas originais da instabilidade dos requisitos. Uma formulação inicial do problema pode ser realizada no sentido de questionar se as incertezas associadas ao desenvolvimento de software não estariam associadas a uma ideologia em seu significado forte, que é “uma distorção do conhecimento [grifo meu]” (Konder, 2002, p. 10).
 
Esta formulação pode ser realizada utilizando como referencial teórico o marxismo, principalmente através da obra A Ideologia Alemã (MARX; ENGELS, 2006), na qual os autores tratam da divisão do trabalho. A divisão do trabalho, que corresponde a uma fragmentação do processo produtivo, visava utilizar melhor a mão-de-obra disponível (sob a ótica do capitalismo), mas gerou um problema ao remover a visão do processo como um todo pelo indivíduo: a fragmentação do processo produtivo fragmentou também o conhecimento acerca do processo produtivo executado. Com a divisão do trabalho, o processo da vida real passa a ser “[...] uma ilusão ideológica. Os seres humanos que pertencem a sociedades profundamente divididas são levados a misturar e confundir o universal e o particular” (Konder, 2002, p. 32). A esta visão limitada do conjunto das atividades executadas pelos indivíduos foi atribuído o nome de alienação. Destaque-se que se trata de alienação em um sentido amplo, pois trata de uma distorção do saber pela fragmentação dos processos executados no cotidiano.
 
Analisando sob o contexto da indústria de software, esta alienação pode ser apontada como uma motivadora das mudanças freqüentes nos requisitos: uma vez que cada usuário observa apenas seu próprio universo, ele pode não ter visibilidade para priorizações ou avaliações integradas de como a solução poderia se comportar em um contexto mais amplo (a própria organização acaba perdendo com isso).
É possível ainda ampliar este estudo da origem do problema do usuário não saber o que quer a partir da teoria crítica e do conceito de indústria cultural criado pela escola de Frankfurt. A indústria cultural corresponde ao
[...] funcionamento dos meios de comunicação de massa e a indústria do entretenimento como um sistema que não só assegurou a sobrevivência do capitalismo como continua exercendo função essencial em sua preservação, reprodução e inovação [...] [através de] uma produção que, no conjunto, evita estimular a reflexão dos seus destinatários (id., p. 82).
 
Conforme análise a seguir, é possível realizar uma extensão deste conceito[9], ampliando-o e adaptando-o para utilização no contexto da indústria de software para associar também a indústria cultural como motivadora das indefinições e conflitos entre requisitos que levariam à sua instabilidade.
 
Um aspecto para avaliar em relação a evitar a reflexão é chamado por Herbert Marcuse de “mecânica da submissão” (1998, p. 82). Segundo esta mecânica, os indivíduos quando se submetem aos domínios da indústria cultural, desaprendem a pensar. Para esclarecer, o autor apresenta um exemplo um pouco extenso, mas profundamente esclarecedor, no qual um viajante de carro faz uso de um guia de estradas com
[...] vários sinais e placas [que] dizem ao visitante o que fazer e pensar; até chamam a atenção para as belezas naturais ou marcos históricos. Outros pensaram pelo viajante e talvez para melhor. Espaços convenientes para estacionar foram construídos onde as mais amplas e mais surpreendentes vistas se desenrolam. Painéis gigantes lhe dizem onde parar e encontrar pausa revigorante. E tudo isso na realidade é para seu benefício, segurança e conforto; ele recebe o que quer. O comércio, a técnica, as necessidades humanas e a natureza se unem em um mecanismo racional e conveniente. Aquele que seguir as instruções será mais bem sucedido, subordinando sua espontaneidade à sabedoria anônima que ordenou tudo para ele [grifos meus] (id., p. 79).
 
Outro aspecto para análise a partir do conceito de indústria cultural é chamada por Marcuse de “impotência social do pensamento crítico [que teria várias influências, mas] a mais importante entre elas foi o crescimento do aparato industrial e seu controle que abrangeu todas as esferas da vida” (id., p. 86).
 
Sem dúvida estes conceitos possibilitam a realização de uma análise mais ampla das conseqüências do processo ideológico forte no problema prático apresentado, análise esta que aponta no sentido que o processo de alienação teria envolvido “[...] a sociedade inteira” (KONDER, 2002, p. 48), e não apenas o ambiente de negócios (o ambiente do usuário). Isto englobaria também os profissionais envolvidos com a produção de software e tornaria o cenário bastante crítico, já que quem tem a responsabilidade de decodificar as funções do ambiente de negócios também possuiria uma visão limitada dos fatos. Em outras palavras, os indivíduos que necessitam minimizar o problema da alienação, por necessitarem de uma visão geral do processo de negócio para construir o software, também são vítimas de alienação. O indivíduo seria alienado quando inserido no ambiente de trabalho, e manipulado quando fora dele (no exemplo de Marcuse, enquanto faz sua viagem de carro em férias). A conseqüência direta seria uma alienação total, plena e irrestrita que atingiria toda sociedade. Isto permite reformular a afirmação para tanto o usuário, quanto o técnico de software, não sabem o que querem e não sabem o que fazem.
 
Há um aspecto bastante peculiar que foi comentado acima, mas merece maior destaque, é que em relação à indústria cultural, os profissionais de software são vítimas, coniventes de certa forma e tentam ser adversários[10]. São vítimas segundo a argumentação apresentada; por outro lado, são também representantes (logo, coniventes) da indústria cultural uma vez que, por exemplo, o uso de softwares para criar desenhos animados[11] assistidos em momentos de lazer pode ser caracterizado como alienante segundo o conceito da teoria crítica; finalmente, lutam contra ela, no sentido que tentam recuperar o conhecimento fragmentado pelos usuários vítimas da alienação, sem o qual não é possível identificar os requisitos e construir o software. É neste último aspecto que prossegue esta análise.
 
2.2 ANÁLISE SEMIÓTICA
Avaliadas as prováveis causas originais para a instabilidade dos requisitos no item anterior, cabe uma reflexão quanto às formas de representação utilizadas pela indústria de software.
Uma vez que o conhecimento dos processos executados pelos usuários se perdeu ao longo de todos os anos do capitalismo, é básico dar o primeiro passo no sentido de recuperar tal conhecimento através da linguagem, pois “[...] é na linguagem que se revelam os movimentos da busca do conhecimento. [...] O real só existe para nós na medida em que o conhecemos e conseguimos, ainda que canhestramente, dizê-lo” (KONDER, 2002, p. 151). Os profissionais de software, que precisam deste conhecimento para desenvolver seu produto, poderiam também tornar público tal saber.
 
Esta última reflexão se concentra no estudo da efetividade dos processos comunicacionais estabelecidos pelas notações utilizadas na fabricação de software ao longo dos anos, segundo a semiótica[12]. Esta escolha é justificada por duas razões. A primeira é que a semiótica possibilita avaliar o poder destas notações “como o código comum ao emissor e receptor tal como uma língua comum aos participantes do processo comunicativo” (SANTAELLA; NÖTH, 2004, p. 178): trata-se, portanto, de um estudo da “simetria comunicativa” (id., p. 177) proporcionada pelas representações de software. A segunda razão da escolha é o elo que pode ser estabelecido com as análises de alienação na ótica marxista e de manipulação da indústria cultural realizadas anteriormente, pois “o efeito de uma comunicação não depende só dos signos emitidos nem das intenções do emissor, mas também da situação, dos interesses e das necessidades do receptor e do seu meio-ambiente” (id., p. 178): ou seja, a alienação e a manipulação estão presentes no processo comunicativo.
 
Para esta análise semiótica, é necessário definir alguns conceitos.
Inicia-se pelo conceito de objeto, que “pode ser ‘uma coisa material do mundo’, do qual temos um conhecimento perceptivo’, mas também pode ser uma entidade meramente mental ou imaginária” (NÖTH, 1998, p. 67).
Já o “signo, ou representamen, é aquilo que, sob certo aspecto ou modo, representa algo para alguém. Dirige-se a alguém, isto é, cria na mente desta pessoa, um signo equivalente, ou talvez um signo mais desenvolvido” (PEIRCE, 2000, p. 46). É Lúcia Santaella quem une esses conceitos de forma bastante esclarecedora e diz que
[...] o signo é uma coisa que representa uma outra coisa: seu objeto. Ele só pode funcionar como signo se carregar esse poder de representar, substituir uma outra coisa diferente dele [grifo meu]. Ora, o signo não é o objeto. Ele apenas está no lugar do objeto. Portanto, ele só pode representar esse objeto de um certo modo e numa certa capacidade (SANTAELLA, 2005, p. 58).
 
Nöth complementa a fusão dos conceitos afirmando que o representamen corresponde ao “nome peirceano do ‘objeto perceptível’, que serve como signo para o receptor” (1998, p. 66).
Outro conceito necessário para esta análise semiótica preliminar é o de interpretante, que [...] não se refere ao intérprete do signo, mas a um processo relacional que se cria na mente do intérprete. A partir da relação de representação [representamen] que o signo mantém com seu objeto, produz-se na mente interpretadora um outro signo que traduz o significado do primeiro (é o interpretante do primeiro). Portanto, o significado de um signo é outro signo – seja este uma imagem mental ou palpável, uma ação ou mera reação gestual, uma palavra ou um mero sentimento de alegria, raiva... uma idéia ou seja lá o que for – porque esse seja lá o que for, que é criado na mente pelo signo, é um outro signo (tradução do primeiro) (SANTAELLA, 2005, p. 58).
Finalmente, é importante observar a clara distinção entre intérprete e interpretante, com destaque para o fato que [...] a ação do signo é a ação de determinar um interpretante, termo que não deve ser tomado como sinônimo de intérprete. Este seria apenas o meio através do qual o interpretante é produzido. Interpretante também não é sinônimo de interpretação, visto que esta diz respeito mais propriamente ao processo de produzir um interpretante. Deste modo, tal como viria a ser desenvolvido, mais tarde, na teoria dos signos, o interpretante deve ser rigorosamente compreendido como o efeito que o signo está apto a produzir [...] ou que efetivamente produz [...] numa mente interpretadora (SANTAELLA, 1992, p. 76).
 
A aplicação dos conceitos de semiótica à produção de software, segundo uma primeira análise simplificada, pode dar conta da complexidade envolvida na identificação dos requisitos. Uma avaliação conceitual do problema prático: quando um usuário procura um técnico de software (tipicamente um analista) para contar a história que motivou sua necessidade – por exemplo, um sistema de informação, como um sistema de contas a pagar – ele revela[13] um objeto. A partir deste momento a análise semiótica envolve vários estágios.
 
·Em um momento inicial, os requisitos são resultantes do trabalho de levantamento das necessidades junto ao solicitante do software. A comunicação se estabelece no momento em que o intérprete (o analista) forma o representamen, formalizado como requisito resultante da solicitação (em substituição à necessidade do usuário). Mas, segundo a lógica apresentada acima, estes requisitos são já um resultado de interpretação do analista, pois ocorreu uma substituição sígnica a partir da história contada durante o levantamento, que originou uma série de novos signos que foram, finalmente, formalizados como requisitos. Parece evidente que este interpretante varia de acordo com o conhecimento acumulado pelo analista ao longo de sua vida (seu repertório) e que este repertório acumulado não necessariamente possui referências ao tipo de negócio solicitado. Logo, o risco de interpretações incorretas é considerável;
·Em um segundo momento, o analista apresenta os requisitos para o usuário avaliar se a abstração elaborada reflete a necessidade original. Novamente há risco considerável de interpretações incorretas, pois há novas interpretações envolvidas: o interpretante seria a compreensão que o solicitante do software faz da abstração elaborada, para avaliar se sua solicitação foi entendida de forma correta pelo técnico. A complicação pode estar associada agora também à notação escolhida como representação do requisito. Caso o usuário não tenha domínio da representação (e este domínio será sempre relativo, pois o requisito pode estar documentado em linguagem natural, que pode gerar ambigüidades ou através de um diagrama técnico, cuja notação não esteja convencionada junto ao intérprete), ele pode interpretar incorretamente a abstração. De qualquer forma, neste estágio o intérprete é o usuário e, evidentemente, mais uma vez o interpretante pode variar (agora de acordo com o repertório deste usuário, que não necessariamente é técnico). Caso ele não aprove a abstração, o processo volta para o estágio anterior; caso ele aprove, o processo avança – seja para identificação de novos requisitos, se aplicável, ou para o terceiro momento, abaixo;
·Em um terceiro momento, quando o analista apresenta os requisitos para outro profissional de software[14], surgem novos interpretantes dos requisitos, seja para criar diagramas de software ou para proceder com a construção dos programas propriamente ditos. De qualquer forma, o intérprete volta a ser um técnico de software e o problema do repertório vem à tona novamente.
 
Tendo em vista a quantidade de interpretantes envolvidos nestas atividades, é possível se dar conta que o requisito é muito mais que uma abstração qualquer de uma necessidade (por mais trivial que seja essa necessidade), pois a comunicação clara se estabelece quando o intérprete entende o signo, enquanto uma comunicação pouco clara se estabelece quando o intérprete entende que não entendeu (total ou parcialmente) o signo que lhe foi apresentado[15]. Este entender ocorre para várias representações, com interpretantes diferentes, a partir de repertórios diferentes. Com o agravante que todos os intérpretes envolvidos foram alvo de alienação e manipulação – logo, os repertórios são limitados.

3. CONSIDERAÇÕES FINAIS

Definitivamente, o problema prático analisado sob uma ótica mais conceitual aponta para outros caminhos que simplesmente o usuário não saber o que quer. É fundamental que seja estabelecido um roteiro básico, a partir do qual seja possível no futuro se constituir uma sugestão de representação de software que minimize as possibilidades de interpretação incorretas. Uma vez que a comunicação realizada via software aumenta continuamente, pode ser caracterizado um problema comunicacional em escala. Se antes da popularização da Internet isto não ficava muito evidente pois esses produtos não se apresentavam claramente a todos que os utilizavam (embora já houvesse uso intenso de sistemas), a ampla utilização da Rede não apenas mostrou um universo de possibilidades de comunicação através de software, como tornou quase impossível conceber o cotidiano sem esses produtos.


[1] Artigo apresentado no 4º CONTECSI (Congresso Internacional de Gestão de Tecnologia e Sistemas de Informação), realizado na FEA/USP em Maio/2007.
[2] marquioni@marquioni.com.br – Mestre em Comunicação e Linguagens (UTP/2008) e Bacharel em Análise de Sistemas (PUC-Campinas/1994).
[3] Sob a ótica deste trabalho podem ser considerados dois tipos principais de usuário. O primeiro deles é aquele que, durante o desenvolvimento do software, supostamente detém o conhecimento acerca do processo que será objeto de automação. O segundo tipo de usuário simplesmente utiliza um sistema já pronto, sem necessariamente ter envolvimento durante a concepção do sistema. Este segundo tipo de usuário normalmente é referenciado pela indústria de software como usuário final. A preocupação principal deste artigo é em relação ao primeiro tipo de usuários. É importante destacar que embora haja um número relativamente reduzido de usuários envolvidos no desenvolvimento de um software em seus estágios iniciais, o uso intenso deste tipo de produto pela sociedade faz com que o produto concluído acabe atingindo um número de usuários finais elevado.
[4] Entenda como membro da comunidade de software qualquer indivíduo que exerça atividades técnicas relacionadas com a produção de software – isto envolve programadores, analistas, testadores, etc.
[5] Sistema deve ser entendido aqui no sentido de sistema de software. Esta ressalva é importante para evitar confusão com a definição de sistema da Engenharia de Sistemas, que “cobre o desenvolvimento de sistemas totais, que podem ou não incluir software” (CHRISSIS; KONRAD; SHRUM, 2003, p. 7) – como exemplos de sistemas totais podem ser citados o sistema digestivo, ou o sistema de distribuição logística de numerário para os caixas eletrônicos de um banco qualquer – no caso deste sistema de distribuição pode haver software, por exemplo para registrar a escala dos profissionais envolvidos, ou determinação de horários a cumprir, etc.
[6] Chris Gane e Trish Sarson afirmaram, ainda no final da década de 1970, que seria necessário “preparar uma especificação funcional que seja bem entendida e tenha total acordo dos usuários” (GANE; SARSON, 1990, p. 6).
[7] Características não funcionais se referem aos requisitos não funcionais, que, como relatam Kotonya e Sommerville “[...] não estão relacionados especificamente com a funcionalidade de um sistema. Eles endereçam restrições ao produto em desenvolvimento, ao processo utilizado para este desenvolvimento e especificam restrições externas que o produto deve atender [...] [; envolve particularmente aspectos relacionados a] segurança, facilidade de uso [usabilidade], [...] e desempenho” (KOTONYA; SOMMERVILLE, 1998, p. 187). Original: “[...] are not specifically concerned with the funcionality of a system. They place restrictions on the product being developed and the development process, and they specify external constraints that the product must meet [...] security, usability, [...] and performance”.
[8] Usabilidade é definida como “a capacidade que um sistema interativo oferece a um usuário, em um determinado contexto de operação, para a realização de tarefas, de maneira eficaz, eficiente e agradável” (ISO 9241).
[9] É relevante evidenciar que se trata de uma extensão do conceito, uma vez que ele foi inicialmente formulado em um contexto no qual Adorno e Horkheimer constatam que “o declínio da religião não levou ao caos cultural, como se temia, pois o cinema, o rádio e as revistas se constituíram num sucedâneo para ela” (DUARTE, 2002, p. 38) – ou seja, o conceito foi formulado para realizar uma análise que envolvia o cinema e a música.
[10] Vale esclarecer que este trabalho não pretende apontar uma alternativa às teorias marxistas ou neomarxistas, no sentido de sugerir soluções para o problema da alienação ou da manipulação. O que se espera é apenas utilizar estas teorias como hipóteses para a instabilidade dos requisitos e apontar alternativas que auxiliem a minimizar estes problemas em uma situação localizada: a identificação, formalização e validação das necessidades de usuários durante o desenvolvimento de software. Estas alternativas passam necessariamente por reflexões quanto ao potencial de comunicação das notações utilizadas no desenvolvimento de software para identificação, documentação e validação dos requisitos do produto.
[11] Como exemplos podem ser citados os desenhos “O Espanta Tubarões”, “Shrek” ou “Madagascar” do Estúdio Pixar.
[12] Esta análise utilizará como principal referência o modelo triádico do signo, apresentado na obra Semiótica de Charles S. Peirce, apoiado por estudos dos textos de Peirce realizados por Lúcia Santaella e Winfried Nöth, conforme bibliografia apresentada abaixo.
[13] Revelar o objeto neste caso corresponde a dizer que o usuário faz acessível seu projeto, sua vontade de trabalho.
[14] Tipicamente há envolvimento de vários profissionais técnicos durante o desenvolvimento, pois cada um tem sua própria especialidade.
[15] Destaque-se que só esta segunda situação já seria relevante. Ocorre que normalmente os envolvidos sequer percebem que a comunicação estabelecida foi pouco clara.
 
 

Referências

CHRISSIS, Mary Beth; KONRAD, Mike; SHRUM, Sandy. CMMI Guidelines for process integration and produc improvement. Boston: Addison-Wesley, 2003.
DUARTE, Rodrigo. Adorno/Horkheimer & A dialética do esclarecimento. Rio de Janeiro: Jorge Zahar Editor, 2002.
GANE, Chris; SARSON, Trish. Análise Estruturada de Sistemas. Rio de Janeiro: LTC – Livros Técnicos e Científicos Editora S.A., 1990.
ISO. International Standard ISO 9241 Part 1: Ergonomic requirements for office work with visual display terminals General Introduction. s/l (US), 1993.
KONDER, Leandro. A Questão da Ideologia. São Paulo: Companhia das Letras, 2002.
KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements Engineering – Processes and Techniques.New York: John Wiley & Sons Inc, 1998.
MARCUSE, Herbert. Algumas implicações sociais da tecnologia moderna. In: _____.Tecnologia, Guerra e Fascismo. São Paulo: Editora da UNESP, 1998.
MARX, Karl; ENGELS, Friedrich. A ideologia Alemã: A contraposição entre as cosmovisões materialista e idealista. São Paulo: Editora Martin Claret, 2006.
NÖTH, Winfried. Panorama da Semiótica: De Platão a Peirce. São Paulo: Annablume Editora, 1998.
PEIRCE, Charles S. Semiótica. São Paulo: Editora Perspectiva, 2000.
SANTAELLA, Lúcia. A assinatura das coisas: Peirce e a Literatura. Rio de Janeiro: Imago Editora, 1992.
SANTAELLA, Lúcia; NÖTH, Winfried. Comunicação e Semiótica. São Paulo: Hacker, 2004.

SANTAELLA, Lúcia. O que é semiótica. São Paulo: Brasiliense, 2005.

 

 

Congressos

Artigo apresentado no 4º CONTECSI (Congresso Internacional de Gestão de Tecnologia e Sistemas de Informação), realizado na FEA/USP em Maio/2007.

 
 
 
 
Selecionar idioma:
 
Artigos  |  Seja um Articulista  |  Cadastre-se  |  Links  |  RSS  |  Administrar
pH Design Desenvolvido por pH Design | Copyright © 2008