CENTRO UNIVERSITRIO AUGUSTO MOTTA

CURSO DE PS-GRADUAO EM SIQT SISTEMA DE INFORMAO E QUALIDADE TOTAL TRABALHO DE CONCLUSO DE CURSO

Tecnologia da Informao e Biblioteconomia: a interdisciplinaridade durante o processo de desenvolvimento de softwares para gerenciamento de acervo bibliogrfico de bibliotecas e centros de documentao.
por

ALESSANDRA DE SOUZA ALMEIDA

Rio de Janeiro 17/12/2007

CENTRO UNIVERSITRIO AUGUSTO MOTTA

CURSO DE PS-GRADUAO EM SIQT SISTEMA DE INFORMAO E QUALIDADE TOTAL TRABALHO DE CONCLUSO DE CURSO

Tecnologia da Informao e Biblioteconomia: a interdisciplinaridade durante o processo de desenvolvimento de softwares para gerenciamento de acervo bibliogrfico de bibliotecas e centros de documentao.

Trabalho

acadmico

apresentado

ao

Curso de Ps-Graduao em Sistema de Informao e Qualidade Total da

UNISUAM, como parte dos requisitos para obteno do Ttulo de Especialista em Sistema de Informao e Qualidade Total. Por:

Alessandra de Souza Almeida

Professor Orientador: Jos Antonio Gameiro Salles

Professores Convidados: Silvio Eutmio de Barros Ana Paula Morgado Carneiro

Rio de Janeiro 17/12/2007 ii

ALESSANDRA DE SOUZA ALMEIDA

Tecnologia da Informao e Biblioteconomia: a interdisciplinaridade durante o processo de desenvolvimento de softwares para gerenciamento de acervo bibliogrfico de bibliotecas e centros de documentao.

Banca Examinadora composta para a defesa de Monografia para obteno do grau de especialista em Sistemas de Informao e Qualidade Total.

APROVADO em 17 de dezembro de 2007.

Professor Orientador: ________________________________________ Jos Antonio Gameiro Salles

Professor Convidado: ________________________________________ Slvio Eutmio de Barros

Professor Convidado: ________________________________________ Ana Paula Morgado Carneiro

Rio de Janeiro 17/12/2007 iii

 minha famlia, que muito importante na minha vida. E a todos vocs que participaram direta ou indiretamente no desenvolvimento desse trabalho.

iv

AGRADECIMENTOS

Agradeo primeiramente a Deus pelo dom da vida e por estar sempre presente, dando-me foras para seguir em frente nos momentos de maior dificuldade e cansao. Obrigada aos meus pais por estar sempre contribuindo na minha caminhada, dando-me sempre apoio e incentivo. E claro, Luciana e Mariana, a vocs desejo um muito, muito, muito obrigada por serem minhas irms e tambm amigas, por estarem sempre presente ajudando-me e dando-me apoio quando necessito. E a voc, minha dinda Gisele, no poderia esquecer-se de te agradecer pela sua amizade e, principalmente, pelo seu apoio nas horas mais complicadas. Agradeo aos meus amigos que esto sempre presentes na minha caminhada. Nazar pela fora, pelo companheirismo e pela sua amizade. Valeu Clarinha, minha afilhadinha, pela sua alegria e carisma. Obrigada Giselle pela amizade. Mesmo distantes sei que posso contar com vocs. Saudades!!! Um muito obrigado a todos os meus amigos de ps-graduao. Obrigado Ronaldo pela amizade e pelo apoio durante a execuo deste trabalho. Obrigada Cludia, Ftima, Mariana e Rosana por estarmos juntos desde o inicio da ps. Obrigada Kellen pela sua amizade, por poder contar com sua ajuda a todo o momento e pelas suas sugestes. Obrigada amiga, sem o seu apoio no teria finalizado esse trabalho. Agradeo tambm as catequistas que souberam me compreender quando me afastei da catequese para fazer a ps-graduao. Um agradecimento especial s bibliotecrias, Biba e Graa, e a todos os funcionrios da Biblioteca Defensor Pblico Mrio Jos Bagueira Leal que v

esto sempre contribuindo para o meu crescimento pessoal e, principalmente, profissional. As estagirias, Fernanda e Maria, que esto sempre dando apoio profissional. Agradeo a todos os professores do curso de Sistema de Informao e Qualidade Total e queles de outras reas que estiveram presente ao longo do curso. De um modo muito especial, ao meu professor e orientador Antonio Salles que me apoiou no na construo deste trabalho. Que Deus abenoe a todos que contriburam direta ou indiretamente em mais uma etapa da minha caminhada.

vi

As mudanas esto ocorrendo em toda parte, ao redor de ns, mas tambm em nosso interior, em nossa forma de representar o mundo. urgente que nos equipemos com ferramentas para poder pensar estas mudanas, avali-las, discut-las - em suma, participar ativamente da construo de nossos destinos. Carlos Irineu da Costa

vii

RESUMO

ALMEIDA,

Alessandra

de

Souza.

Tecnologia

da

Informao

Biblioteconomia: a interdisciplinaridade durante o processo de desenvolvimento de softwares para gerenciamento de acervo bibliogrfico de bibliotecas e centros de documentao. Orientador: Jos Antonio Gameiro Salles. Rio de Janeiro: UNISUAM, 2007.

Apresenta reflexes acerca da participao do bibliotecrio no desenvolvimento de software para gerenciamento de acervo bibliogrfico de bibliotecas e centros de documentao. Questiona como pode ser desenvolvido um trabalho interdisciplinar entre a Biblioteconomia e a Tecnologia da Informao (TI); qual o papel do bibliotecrio no desenvolvimento de sistema de informao e quais as consideraes que o bibliotecrio pode ou deve fazer para o desenvolvimento de um sistema (software) de qualidade. Ressalta alguns pontos a respeito da importncia do sistema gerenciamento de biblioteca e aponta o que a evoluo tecnolgica trouxe para a biblioteca. Aborda alguns conceitos bsicos como sistemas de gerenciamento de bibliotecas, software, engenharia de software e engenharia de requisitos. Analisa os principais processos no desenvolvimento de software e os principais participantes neste contexto. Identifica a

interdisciplinaridade entre Biblioteconomia a Tecnologia da informao. Ressalta a importncia dos bibliotecrios no processo de desenvolvimento do software para gerenciamento de bibliotecas. Palavras-chave: Engenharia de Software, Processo de desenvolvimento de software, Sistema de gerenciamento de bibliotecas, Informatizao de bibliotecas, Perfil do bibliotecrio, Analista de Sistemas.

viii

ABSTRACT

ALMEIDA,

Alessandra

de

Souza.

Tecnologia

da

Informao

Biblioteconomia: a interdisciplinaridade durante o processo de desenvolvimento de softwares para gerenciamento de acervo bibliogrfico de bibliotecas e centros de documentao. Orientador: Jos Antonio Gameiro Salles. Rio de Janeiro: UNISUAM, 2007.

It presents thoughts about the involvement of the librarian in the development of software for managing bibliographic collection of libraries and documentation centers. It questions how can be developed as a work interdisciplinary between the Library and the Information Technology (IT), which is the role of the librarian in the development of the information system and what the considerations that the librarian can or should do for the development of a system (software) quality. Highlights some points on the importance of the system of library management and suggests that the technological developments brought to the library. It addresses some basic concepts such as management systems libraries, software, engineering and software engineering requirements. It examines the main processes in software development and the main participants in this context. It identifies the interdisciplinary between the Library of Information Technology. Highlights the importance of librarians in the process of development of software for managing libraries. Key-Works: Software Engineering, Software development process, System of management of libraries. Library Information Processing, Librarian profile, Analyst of Systems

ix

LISTA DE FIGURAS

Figura 1: Nveis das atividades da biblioteca ..................................................... 11 Figura 2: Custo de modificao de um software ................................................ 26 Figura 3: Modelo em cascata ............................................................................. 32 Figura 4: Modelo Incremental ............................................................................. 34 Figura 5: Modelo de Prototipao ...................................................................... 36 Figura 6: Modelo Espiral ..................................................................................... 39 Figura 7: Tcnica da Quarta Gerao ................................................................ 41 Figura 8: Participantes no Desenvolvimento de Software .................................. 57 Figura 9: O papel do analista ............................................................................. 59 Figura 10: Caractersticas pessoais do analista ................................................. 60

LISTA DE TABELAS

Tabela 1: Resumo das opes de Sistemas de Gerenciamento de Biblioteca.... 22 Tabela 2: Documentao de Requisitos .............................................................. 54 Tabela 3: Como os usurios e desenvolvedores vem uns aos outros............... 62

xi

SUMRIO

Folha de aprovao......................................................................................... iii Dedicatria....................................................................................................... iv Agradecimentos ............................................................................................... v Epgrafe ........................................................................................................... vi Resumo ........................................................................................................... vii Abstract.......................................................................................................... viii 1 1.1 1.2 1.3 1.4 1.4.1 1.4.2 1.5 1.6 2 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 INTRODUO....................................................................................... 1 Justificativa .......................................................................................... 2 Problematizao .................................................................................. 3 Hiptese................................................................................................ 3 Objetivos .............................................................................................. 4 Objetivo Geral........................................................................................ 4 Objetivos Especficos............................................................................. 4 Metodologia.......................................................................................... 4 Organizao do Trabalho.................................................................... 5 AUTOMAO DE BIBLIOTECAS ........................................................ 6 Sistemas de gerenciamento de bibliotecas....................................... 9 A Biblioteca na Sociedade da Informao....................................... 11 Opes de Sistemas de Gerenciamento de Bibliotecas ................ 14 Aquisio de Sistema de Gerenciamento de Biblioteca....................... 15 Desenvolver o Sistema de Gerenciamento de Biblioteca com recursos prprios................................................................................................ 18 Terceirizar o desenvolvimento do Sistema de Gerenciamento de Biblioteca ............................................................................................. 20 DESENVOLVIMENTO DE SOFTWARE ............................................. 24 Qual o significado de software?....................................................... 25 Caractersticas de um Software........................................................ 25

3 3.1 3.2

3.3 3.4 3.5 3.6 3.7 3.7.1 3.7.2 3.7.3 3.7.4 3.7.5 4 4.1 4.2 4.3 4.4 4.4.1 4.4.2 4.5 4.6 5 5.1 5.2 5.3 5.4

Custo de Mudanas do Software...................................................... 26 Engenharia de Software .................................................................... 27 Princpios da Engenharia de Software............................................. 28 Processo de Construo de Software ............................................. 29 Modelos de Processo de Software................................................... 31 Modelo em cascata.............................................................................. 31 Modelo Incremental ............................................................................. 33 Prototipao......................................................................................... 35 Espiral.................................................................................................. 38 Tcnica da Quarta Gerao................................................................. 40 ENGENHARIA DE REQUISITOS........................................................ 43 O que so requisitos? ....................................................................... 43 Benefcios de analise de requisitos ................................................. 44 Funes para a realizao da Engenharia de Requisitos .............. 45 Classificao dos requisitos............................................................. 48 Requisitos Diretos (ou Requisitos funcionais)...................................... 48 Requisitos Indiretos (ou Requisitos no funcionais) ............................ 49 Levantamento de requisitos ............................................................. 49 Documentao de requisitos ............................................................ 51 ATORES NO CENRIO DE DESENVOLVIMENTO ........................... 56 O papel do analista ............................................................................ 58 O bibliotecrio e seu papel no desenvolvimento de software....... 60 Divergncias entre os profissionais para desenvolvimento do software .............................................................................................. 62 Interdisciplinaridade durante o processo de desenvolvimento de softwares para gerenciamento de acervo bibliogrfico de bibliotecas .......................................................................................... 65 CONSIDERAES FINAIS................................................................. 67 REFERNCIAS ................................................................................... 69 Obras citadas ..................................................................................... 69 Obras consultadas............................................................................. 71

6 7 7.1 7.2

xiii

INTRODUO O presente trabalho tem por finalidade apresentar algumas reflexes

sobre a influncia dos avanos tecnolgicos no funcionamento das bibliotecas e servios de informao, bem como o papel do bibliotecrio neste processo. A viso tradicional que temos relativo s bibliotecas a de que tais instituies so apenas locais em que se guardam livros. As atividades/servios desenvolvidas na biblioteca eram feitas de forma manual e, devido a isso, havia uma demora na recuperao da informao. Logo, para se obter uma informao sobre determinado assunto, o usurio tinha que ir biblioteca pessoalmente e procurar a informao necessitada utilizando-se de um catlogo manual um processo lento e falvel. Atualmente, utilizando-se de avanos tecnolgicos, tais como a automao, vemos a biblioteca de maneira mais abrangente: como todo espao (concreto, virtual ou hbrido) destinado a uma coleo de informaes de quaisquer tipos, sejam escritas em folhas de papel (monografias, enciclopdias, dicionrios, manuais, etc) ou ainda digitalizadas e armazenadas em outros tipos de suportes, tais como cds, fitas, VHS, DVD's e bancos de dados o que veio a proporcionar a eficcia do sistema. Dessa forma, a viso tradicional da biblioteca foi revista e trabalhada de acordo com as tecnologias disponveis, a fim de melhor atender o seu usurio e cumprir o seu principal papel: disseminar a informao com eficincia e eficcia. As informaes esto disponveis quase que em tempo real, e o usurio j tem acesso informao sem sair de casa, atravs dos catlogos on-line. As bibliotecas esto, a cada dia, tornando-se mais dependentes de seus sistemas de informao para gerar servios com qualidade para seus usurios.

2 Os avanos tecnolgicos tm provocado mudanas significativas dentro das bibliotecas: cada vez mais h investimentos em sistemas de informao e aquisio de bases de dados para acompanhar os avanos. A tecnologia da informao utilizada de forma estratgica e transformadora, para que se possa prestar os servios aos usurios com eficincia e eficcia. A modernizao das bibliotecas tem se baseado na escolha entre adquirir um sistema pronto ou construir em casa seu prprio sistema de gerenciamento. Em ambos os casos uma das responsabilidades do bibliotecrio a escolha da melhor soluo.

1.1

Justificativa A escolha do tema Tecnologia da Informao e Biblioteconomia: a

interdisciplinaridade durante o processo de desenvolvimento de softwares para gerenciamento de acervo bibliogrfico de bibliotecas e centros de

documentao surgiu do interesse pessoal em conhecer melhor o papel do profissional bibliotecrio frente ao processo de construo de um software de gerenciamento de bibliotecas. nesta perspectiva que me proponho investigar a

interdisciplinaridade entre o profissional de tecnologia da informao e o bibliotecrio neste processo, observando se realmente o bibliotecrio tornou-se um bom interlocutor junto aos analistas para expressar suas necessidades, e obter destes os recursos tecnolgicos aplicados, para viabilizar o cumprimento de sua misso, que disponibilizar e facilitar aos usurios o acesso informao. Outro fator que me incentivou a avanar com este tema foi o fato de que na literatura sobre desenvolvimento e implantao de sistemas de

3 informao, existem poucas referncias com enfoque na participao do bibliotecrio.

1.2

Problematizao Esse novo paradigma de biblioteca vem levantar uma nova reflexo

sobre o papel do bibliotecrio: como pode ser desenvolvido um trabalho interdisciplinar entre a Biblioteconomia e a Tecnologia da Informao (TI)? Qual o papel do bibliotecrio no desenvolvimento de sistema de informao? Quais as consideraes que o bibliotecrio pode ou deve fazer para o desenvolvimento de um sistema (software) de qualidade?

1.3

Hiptese H pouca interao entre o profissional da informao (Bibliotecrio)

e o profissional de TI, devido dificuldade na comunicao entre esses profissionais durante o processo de desenvolvimento de um software. A ausncia de conhecimento especfico dos profissionais de TI no que diz respeito ao funcionamento da biblioteca, tais como os procedimentos de organizao e administrao, dificultam a compreenso das necessidades que os bibliotecrios demandam de um software. Em contra partida, h pouca instruo do bibliotecrio na rea da TI, principalmente no que diz respeito fundamentao matemtica e computacional, impedindo que o mesmo compartilhe da linguagem especfica do setor, inibindo sua participao de forma mais intensa em relao ao desenvolvimento do software.

4 1.4 Objetivos

1.4.1 Objetivo Geral Discutir a participao do bibliotecrio no desenvolvimento de software para gerenciamento de acervo bibliogrfico de bibliotecas e centros de documentao.

1.4.2 Objetivos Especficos Identificar os principais participantes no processo de

desenvolvimento dos sistemas e definir seus papis; Delinear os passos fundamentais deste processo; Identificar a necessidade da participao do bibliotecrio; Refletir o papel do bibliotecrio como patrocinador e como usurio do desenvolvimento do software; Identificar a interdisciplinaridade entre Biblioteconomia e

Tecnologia da informao;

1.5

Metodologia O presente trabalho ser desenvolvido atravs de pesquisa

bibliogrfica com a reviso da literatura adequada para o estudo. Para isto, ser feito um levantamento da produo cientfica tanto da rea de Sistema de Informao e Biblioteconomia, quanto nas reas afins, que

5 traam um panorama sobre desenvolvimento de software e a participao do Bibliotecrio neste contexto. Para finalizar, ser feita uma anlise terica, crtica e reflexiva do tema. Esta anlise ir se restringir ao estudo da interdisciplinaridade entre o analista e o bibliotecrio no processo de desenvolver softwares para biblioteca.

1.6

Organizao do Trabalho Para entender os objetivos propostos, o trabalho est estruturado da

seguinte maneira: Na primeira parte, aborda-se o significado e a importncia do sistema de biblioteca para o indivduo e para a sociedade. Procura demonstrar tambm, o que a evoluo tecnolgica trouxe para a biblioteca. Na segunda parte, realizou-se um levantamento bibliogrfico dos quesitos necessrios para a construo de um software. J a terceira parte, trata-se a interdisciplinaridade entre o bibliotecrio e o analista no processo de desenvolvimento de software. Ento iniciaremos nossa leitura.

AUTOMAO DE BIBLIOTECAS A chegada da informtica provocou profundas mudanas nos

servios prestados pelas Bibliotecas. A informatizao das bibliotecas um processo cada vez mais complexo devido s diversidades das informaes que nelas so tratadas e disponibilizadas para uso e acesso de todos. As bibliotecas esto prestando mais servios aos usurios. O processo de informatizao em uma biblioteca inicia-se quando a informtica vista como uma alternativa para melhorias de problemas ocorridos nos processos internos da biblioteca. Para que haja sucesso neste processo requer um planejamento cuidadoso e sistmico.
Assim, qualquer iniciativa de informatizao de uma biblioteca ou centro de documentao deve, primeiramente, identificar a cultura, misso, objetivos e programas de trabalho da organizao; as caractersticas essenciais da biblioteca com relao sua abrangncia temtica, servios e produtos oferecidos; os interesses e necessidades de informao dos usurios; a plataforma tecnolgica existente na instituio em termos de software e hardware, bem como sua capacidade de atualizao e ampliao, alm dos recursos humanos disponveis. (CRTE, 1999, p.242)

Silva (2005, p.45) reafirma colocando que a modernizao das bibliotecas est diretamente ligada a automao de rotinas e processos biblioteconmicos. Assim ela diz que:
Automatizar no apenas introduzir computadores e instalar um software de gerenciamento de acervo, e sim um planejamento sistemtico que envolve recursos humanos, treinamento de pessoal e pesquisa sistemtica de todos os processos administrativos da instituio.

Dessa forma, podemos dizer que o processo de automao consiste em uma elaborao de um projeto centrado nas necessidades reais e potencias dos usurios e de toda a estrutura da biblioteca.
[...] necessrio que sejam observados fatores relacionados com os recursos humanos, que influenciam no fracasso ou no xito do processo de automao, em decorrncia de dificuldades de relacionamento entre as partes envolvidas ou de atitudes perante a incorporao da automao (GUSMO; MANDES, 2000, p.225).

7 Quando se cogita de informatizao de bibliotecas, a associao inicial inevitvel se refere aos aspectos tecnolgicos de uso de programas de computador (software) e de equipamentos (hardware). Alm da considerao escolha e implantao de software e de hardware, um projeto de informatizao de biblioteca, de acordo com Silva (2005, p.45), tambm precisa levar em conta uma arquitetura baseada em cliente/servidor em uma rede interna, onde os diversos setores da biblioteca possam estabelecer laos de comunicao e gerenciamento remoto. Para que isto acontea necessria utilizao de recursos tecnolgicos e humanos para implantar um sistema de administrao de acervo; controle de emprstimos; consulta de documentos e todo o processo administrativo da biblioteca, tanto em ambiente de rede local quanto na internet, dentre outras tecnologias.
[...] se as bibliotecas e centros de documentao quiserem oferecer melhor servio aos usurios e cumprir sua misso, necessrio se torna acompanhar passo a passo o desenvolvimento da sociedade, entender com mais preciso os hbitos e os costumes dos usurios, adaptar as tecnologias s necessidades e quantidades de informao de que dispem, assim como utilizar um sistema informatizado que privilegie todas as etapas do ciclo documental [...]. A modernizao das bibliotecas est diretamente ligada automao de rotinas e servios, com o intuito de implantar uma infra-estrutura de comunicao para agilizar e ampliar o acesso informao pelo usurio, tornando-se necessrio haver uma ampla viso da tecnologia da informao e sua aplicao nas organizaes (CRTE, 1999, p.242)

Quando se fala em adaptar as tecnologias, pode-se entender que cada biblioteca tem as suas peculiaridades e muitas tm sistemas automatizados falhos por no terem planejado a escolha corretamente, ou caso tenha desenvolvido seu prprio sistema estes no contemplam todos os recursos necessrios para atender as necessidades da biblioteca. Assim, necessrio realizar adaptaes o que implicar em custos adicionais. A escolha ou o desenvolvimento de um sistema tem que recair sobre uma ferramenta que contemple os recursos hoje disponveis, sem se tornar obsoleto a mdio e longo prazos.

8 Lima (1999, p.311) prope trs tipos bsicos de softwares necessrios para automao de bibliotecas, sistemas de gerenciamento de banco de dados, sistemas de gerenciamento de bibliotecas e sistemas de gerenciamento de base de dados bibliogrficos.
Os sistemas de gerenciamento de bibliotecas so sistemas de bases de dados com uma finalidade especfica, projetados para controlar as atividades essenciais de uma biblioteca. [...] Gerenciadores de bases de dados bibliogrficas [...] so softwares que rodam em microcomputadores, destinados a uma clientela que inclui no apenas bibliotecrios, mas tambm usurios pessoais, principalmente professores e pesquisadores acadmicos. So programas que apresentam facilidades e vantagens na sua utilizao devido s suas interfaces amigveis. Alguns vm com formatos preestabelecidos para atender s necessidades bibliogrficas e facilitar a entrada de dados. J os Sistemas de Gerenciadores de Banco de Dados [...] so softwares de espectro comercial mais amplo, que suportam o armazenamento de grandes quantidades de informao. Possuem habilidades de recuperao segundo diferentes critrios de cruzamento, o que uma caracterstica importante para a maior parte das funes bibliotecrias (Lima,1999, p.311)

No exposto trabalho, ser enfocado os Sistemas de Gerenciamento de Bibliotecas. Esta escolha deu-se devido ao fato que podemos considerar a biblioteca, ela prpria, um sistema, onde todos os servios se interligam, pois
H bem pouco tempo, costumava-se usar o termo informtica para representar todo recurso que tivesse condies de manipular a informao de maneira automtica. Hoje, a capacidade dos recursos vai alm da manipulao automatizada de processos e de funes. Com essa mudana, passou-se a utilizar o termo tecnologia da informao para expressar os requisitos tecnolgicos que iro integrar as necessidades organizacionais e desenvolver mecanismos adequados para dar suporte tomada de deciso. (CNDIDO, 2000)

Em face disso, percebemos que a tecnologia da informao esta diretamente ligada ao processo de automao de biblioteca, pois englobam produtos de hardware e software, com a capacidade de coletar, armazenar, processar e acessar informaes para o controle e disseminao do conhecimento, ou sejam, conectam pessoas, funes e bibliotecas tanto dentro quanto entre bibliotecas.

9 2.1 Sistemas de gerenciamento de bibliotecas Os primeiros sistemas foram considerados adequados para as organizaes envolvidas com grande volume de transaes ou gerenciamento de informaes. Os primeiros sistemas baseavam-se em computadores denominados grande porte ou mainframe e em minicomputadores. Com a evoluo tecnolgica e facilidade de acesso

microinformtica, tanto em termos de equipamentos (hardware) quanto de programas (software), fez com que os sistemas se tornassem acessvel para qualquer biblioteca e unidades de informao. Na dcada de 90, podemos vislumbrar uma nova fase caracterizada pela disponibilidade de ferramentas hardware e software, com uma infinidade de recursos e possibilidades. Pacotes de softwares comerciais foram apresentados comunidade usuria. Conhecidos como Sistemas de Gerenciamento de Biblioteca, estes sistemas foram projetados para integrar e controlar as atividades essenciais de uma biblioteca pressupondo a utilizao de normas e padres internacionais que permitiriam a compatibilidade e o intercmbio de informaes. Os Sistemas de Gerenciamento de Biblioteca so sistemas de bases de dados de finalidade especfica, projetados para controlar atividades essenciais de uma biblioteca.
Todas as atividades de gerenciamento de bibliotecas esto voltadas para o controle do acervo. Os sistemas suportam a seleo, aquisio, etiquetagem, catalogao e controle de circulao do acervo das bibliotecas. Em muitas funes o computador atua fundamentalmente como uma fonte de informao sobre o estado do acervo e, por isso, conter registros que descrevam esse acervo e onde ele se encontra. Essas informaes podem estar disponveis em linha ou em listagens impressas, e servem para se saber, por exemplo, O que est no acervo? ou O que est emprestado e para quem? Um sistema informatizado s vezes controla realmente o acervo; por exemplo, utilizando um dispositivo de alerta, que aciona um sinal sonoro ou luminoso quando um livro reservado devolvido ao balco de emprstimo. (ROWLEY, 1994, p. 230)

10 Quanto mais atualizados forem os dados nos arquivos do computador, melhor ser o controle da operao.
Antes, o desenvolvimento de sistemas era fragmentado, com algumas bibliotecas primeiro desenvolvendo a catalogao enquanto outras se concentravam, por exemplo, na circulao. Os sistemas atuais so integrados, baseados em arquitetura de bases de dados relacionais. Neles os arquivos so interligados, de modo que excluses, acrscimos e outras mudanas num deles automaticamente ativam mudanas apropriadas nos arquivos com ele relacionados. (ROWLEY, 2002, p. 316)

Assim, um Sistema de Gerenciamento de Biblioteca compreende vrios mdulos. As funes desempenhadas por estes mdulos, de acordo com Rowley (2002, p. 318-336), so essencialmente: Aquisio para controlar os pedidos e as aquisies de novos materiais; Catalogao para a manuteno da base de catalogrficos; Catlogo em linha de acesso pblico e outras formas de catlogos oferece uma interface com a base de dados catalogrficos, de modo que os usurios possam fazer buscas nessa base de dados; Controle de circulao para controlar a circulao do acervo, envolvendo emprstimos, devolues, registros de leitores, reservas e multas; Controle de publicaes seriadas para controlar todos os processos que tm a ver com as publicaes seriadas, como, aquisio, catalogao, encadernao e circulao; Emprstimos entre bibliotecas para executar o processamento decorrente de pedidos de emprstimo de material pertencente a outros acervos; Informaes gerenciais contm dados que, se extrados, resumidos e analisados adequadamente, serviro de apoio ao processo decisrio administrativo; As cinco primeiras funes representam as atividades essenciais. dados

11 2.2 A Biblioteca na Sociedade da Informao Considerando que o acervo de uma biblioteca a base onde ser direcionado todos os servios que ela oferece, de grande importncia o bom entendimento das rotinas e instrumentos que so gerados para que a informao contida nos documentos diversos possa ser rpida e eficientemente localizada por aqueles que dela precisam fazer uso.
Uma biblioteca para atingir plenamente seus objetivos, necessita possuir um bom acervo, adequadamente tratado e facilmente acessvel a seus usurios. Para tanto, desenvolve atividades em trs nveis diferentes antes do acervo entrar na biblioteca (seleo e aquisio), durante o processamento do acervo na biblioteca (registro, catalogao, classificao, encadernao, preparo para emprstimo e arrumao nas estantes) e, depois, quando o acervo est disposio do leitor (circulao, referncia e emprstimo a domiclio). (CRUZ, 2000, p.13)

Os trs nveis das atividades, segundo Cruz (2000, p.94), est representado na figura abaixo:

Figura 1: Nveis das atividades da biblioteca (CRUZ, 2000)

12 Independente de suas caractersticas fsicas, pertinncia do acervo ou especialidade, as Bibliotecas realizam tais atividades dentro de sua Estrutura Organizacional Administrativa. Tal estrutura varia de biblioteca para biblioteca, dependendo das peculiaridades de cada uma. A evoluo da tecnologia da informao tem atingido a rea da Cincia da Informao. Conseqentemente as bibliotecas vm evoluindo tecnologicamente para atender a demanda de usurios que cada vez mais exigente. Os profissionais da informao so fundamentais para fazer o elo entre os usurios e esse novo paradigma. Com isso, houve muitas modificaes no gerenciamento das bibliotecas, na utilizao delas e na maneira como alguns servios so prestados.
O usurio j no precisa ir at a biblioteca para obter informao sobre o acervo que est a sua disposio. Essa consulta pode ser feita via espao ciberntico acessando os catlogos em linha (on line), e as bases de dados disponveis. possvel, atravs do uso de um computador conectado a Internet, ter acesso informao a partir de uma sala de aula, de um escritrio e do domiclio do usurio. (SILVA, 2003, p113)

O uso da informtica na biblioteca veio como uma alternativa para essas instituies, uma vez que os recursos tecnolgicos agilizam o processo de tratamento e de gerenciamento de suas informaes, alm de permitir o intercmbio com fontes externas de informao e servios. As novas tecnologias da informao tm revolucionado as organizaes modernas, pela capacidade de armazenar, organizar e manipular um grande volume de informaes de forma coerente e segura, promovendo a inverso dos processos informacionais. Nesse novo contexto, nem o usurio nem o documento se deslocam, ao contrrio, a informao que se encontra em constante movimento As bibliotecas virtuais so um exemplo dessas mudanas. Elas podem ser acessadas e consultadas a longas distncias, no exigindo do cliente sua presena fsica no local onde est o acervo bibliogrfico. Essas

13 bibliotecas no tm paredes e atendem 24 horas. Permitindo um intercmbio muito mais fcil, troca de experincias, vitalizando e dinamizando o acervos. Contudo, o processo de introduo das novas tecnologias da informao no chegou em todas as bibliotecas brasileiras, e mesmo em algumas partes do mundo, mas elas chegaro trazendo mudanas nas funes tradicionais da biblioteca que so: reunir, organizar e difundir a memria cultural da humanidade. As inovaes tecnolgicas no podiam ficar de fora das bibliotecas. A informtica trouxe muitos benefcios, principalmente para os usurios e profissionais da biblioteca.
A informtica caracteriza-se na biblioteca, pelo uso do computador de programa especficos para o gerenciamento da informao, o acesso a redes acionais e internacionais, consulta bases de dados bibliogrficos e catlogos em linha (on line), maior cooperao e compartilhamento entre os servios bibliotecrios, o aumento de redes cooperativas de catalogao, melhores polticas de desenvolvimento de colees e mesmo o uso mais atento da normalizao e padronizao dos processos tcnicos da Biblioteconomia. (SILVA, 2003, p114)

A informtica tem se revelado uma ferramenta indispensvel para agilizar e racionalizar os processos de incorporao e recuperao da informao bibliogrfica. Trs reas de servios bibliotecrios so beneficiadas com a automao. So elas: os servios clientela, os servios de processos tcnicos e os servios de acesso informao. Na circulao e automao veio ajudar no sistema e controle e emprstimo e evoluo dos documentos e na elaborao e relatrios de livros em atraso. Na catalogao e automao incentivou, facilitou e viabilizou os servios de catalogao cooperativa, criando as redes de bancos de dados automatizadas, possibilitando a manuteno da uniformidade no tratamento

14 das informaes; catlogos em linha (on line); compartilhamento de recursos e ainda catlogos automatizados de autoridades e assuntos. No servio de referncia a automao facilitou a criao dos bancos e dados nacionais e internacionais acessados atravs de redes para a recuperao automtica da informao bibliogrfica; o emprstimo entre bibliotecas atravs do correio eletrnico (e-mail); o desenvolvimento de bibliotecas digitais e virtuais e muitas outras possibilidades de acesso informao.

2.3

Opes de Sistemas de Gerenciamento de Bibliotecas Antigamente a biblioteca que passava por um processo de implantar

um sistema informatizado no dispunha de outra opo seno a de desenvolver seu prprio sistema localmente, em conjunto, pela equipe da biblioteca e de processamento de dados da instituio. Hoje em dia isso constitui geralmente uma opo dispendiosa. Atualmente, existem no mercado diversos sistemas de

gerenciamento de biblioteca. Da as bibliotecas tm a seu dispor as seguintes opes quando se tratam de adquirir ou melhorar um sistema de gerenciamento: Adquirir um Sistema de Gerenciamento de Biblioteca existente no mercado; Desenvolver o Sistema de Gerenciamento de Biblioteca com recursos prprios; Terceirizar o desenvolvimento do Sistema de Gerenciamento de Biblioteca.

15 Todas estas alternativas exigem etapas ou fases diferentes a serem seguidas para a informatizao de uma biblioteca. Alm dessas diferentes etapas, devem ser observadas as vantagens e desvantagens de cada opo para saber qual delas mais vivel em relao ao custo e benefcios.

2.3.1 Aquisio de Sistema de Gerenciamento de Biblioteca A opo de adquirir um Sistema de Informao para Gerenciamento de Biblioteca existente no mercado acontece de duas formas. A primeira ser adquirir um Sistema de Informao genrico e flexvel e adapt-lo dentro de suas caractersticas, conforme os objetivos e necessidades da biblioteca. E a segunda forma ser adquirir um Sistema de Informao rgido, desde que seja plenamente satisfatrio Biblioteca. Segundo Rezende (2006, p. 257), no caso de uma biblioteca optar pela aquisio de um sistema, ou seja, de pacotes de software, ser necessrio que sejam seguidas as seguintes etapas metodolgicas: Levantamento de necessidade de informao e aplicaes a serem informatizadas; Desenvolvimento do modelo de informaes empresariais, relatando todas as informaes necessrias para que o sistema atenda especificao dos requisitos funcionais essenciais e desejados; Identificao dos possveis fornecedores; Solicitao de proposta dos fornecedores selecionados; Seleo do software mais adequado ao perfil da biblioteca atravs do estabelecimento de critrios de avaliao; Testes dos softwares selecionados; Escolha e implantao do pacote de software.

16 Rowley (2002, p. 84), avalia as vantagens e desvantagens de utilizar pacotes de software. As vantagens podem ser avaliadas como: 1. So econmicos, pois o custo do investimento inicial com sua criao e posterior manuteno se dilui entre diversos usurios. 2. O pacote fornecido como um conjunto de programas satisfatoriamente testados, e o fornecedor conta com um nmero suficiente de clientes que justifica a existncia de esquemas de manuteno adequados 3. O produtor provavelmente um especialista nesse tipo de programa- e deve, portanto, criar um produto de melhor qualidade com caractersticas teis cuja importncia talvez o usurio inexperiente no viesse a perceber. 4. Os pacotes so fornecidos com uma boa documentao, inclusive com especificao minuciosa do sistema, identificao dos requisitos de equipamento, especificaes sobre entradas, sadas e arquivos, alm de sincronizao dos sistemas manuais para os usurios. 5. Os pacotes so entregues pouco tempo depois de

encomendados e, assim, o sistema ser implementado mais rapidamente. 6. O fornecedor do pacote coloca disposio dos consumidores servios de suporte e orientao. 7. Os pacotes incorporam conhecimentos especializados que so de difcil obteno e que, de outra forma, no estariam disponveis para a instituio. 8. Os pacotes podem ser avaliados numa situao de usurios e comparados com outros. As desvantagens podem ser avaliadas como: 1. provvel que o pacote no se ajuste exatamente ao sistema atual ou aos requisitos do usurio. Sua aceitabilidade depende da

17 facilidade com que o pacote ou os requisitos sejam modificados a fim de que se chegue a uma soluo satisfatria. 2. O usurio depende da competncia e da confiabilidade do fornecedor de programas, tanto no que concerne ao pacote inicial quanto manuteno e suporte subseqentes. A qualidade do suporte pode variar durante o tempo de vida til do sistema. 3. Existe a possibilidade de o pacote de programas ser menos eficiente do que o outro desenvolvido sob medida, em termos de tempo de processamento do computador e utilizao do processador. Um bom pacote de software, alm de atender s necessidades da biblioteca, dever ser avaliado com relao ao desempenho dos seguintes itens: Funcionalidade, desempenho, segurana, capacidade de

expanso, flexibilidade, capacidade de modificao, suporte e assistncia tcnica, mtodo, facilidade de uso, facilidade de aprendizado, documentao, testabilidade, consumo de recursos compuitacionais, portabilidade, integrao e compatibilidade, qualidade do fornecedor, custo e condies de pagamento. Ainda no tocante aos possveis no atendimentos das necessidades de informaes requeridas, devem-se analisar criteriosamente os custos de implementaes, o tempo de desenvolvimento e os padres de qualidade dos servios.

18 2.3.2 Desenvolver o Sistema de Gerenciamento de Biblioteca com recursos prprios Acontece quando a biblioteca opta pela implementao de sistemas com o desenvolvimento de Sistemas de Informao com recursos prprios. Esses recursos dizem respeito aquisio de uma linguagem de programao de software, a criao de uma Unidade de Tecnologia da Informao prpria e a contratao de uma equipe tcnica profissional para desenvolv-lo, exatamente de acordo com os requisitos funcionais identificados. Segundo Rezende (2006, p. 255), para esta opo ser necessrio que sejam seguidas as seguintes etapas metodolgicas: Levantamento das necessidades de informao e aplicaes a serem informatizadas; Especificao dos requisitos funcionais essenciais e desejveis do sistema a ser desenvolvido e implementado; Constituio da equipe de desenvolvimento e elaborao de planos de trabalho; Anlise e projeto do sistema; Testes e revises das especificaes; Implantao do sistema. De acordo com Rezende (2006, p. 255), as vantagens de desenvolver seu prprio sistema so as seguintes: 1. Pode ter a garantia de que todos os pr-requisitos ou requisitos funcionais do sistema sejam atendidos. 2. Ter a manuteno e atualizao do sistema a qualquer momento, o que far com que o sistema acompanhe a dinmica da biblioteca. As desvantagens, de acordo com Rezende (2006, p. 255), so as seguintes:

19 1. Alto custo de manuteno da equipe especializada e dos sistemas. 2. Dificuldade de acompanhamento da evoluo tecnolgica na rea. 3. Dificuldade de substituio de membros da equipe de

desenvolvimento. A literatura aponta que a tendncia das bibliotecas de desenvolver isoladamente seus prprios programas tem diminudo devido dificuldade de os programas in house se comunicarem com outros formatos padronizados ou participarem de redes de intercmbio e, tambm, devido sua desvantagem diante do custo, uma vez que sai muito caro desenvolv-lo na prpria instituio ou encomend-lo a algum, muito embora um pacote sob medida, projetado especificamente para determinada aplicao, provavelmente sirva melhor a todas as necessidades dessa aplicao. Entretanto, ainda h algumas bibliotecas que desenvolvem

localmente seus prprios sistemas, pois

dispem dos recursos necessrios e teriam as condies para desenvolver um sistema para atender seus prprios requisitos. Os sistemas disponveis comercialmente so sempre uma soluo de meio-termo, mas, no obstante, um meio termo que atende satisfatoriamente a muitas bibliotecas. medida que esses sistemas se tornam mais e mais complexos e oferecem um maior nmero de opes, que permitem biblioteca ajust-los a suas prprias necessidades, a opo de desenvolvimento pela prpria instituio passa a se tornar apenas para aquelas que apresentem requisitos muito raros. (ROWLEY, 2002, p. 337)

importante lembrar que a escolha deve ter sempre a participao do bibliotecrio, que o profissional que lida diretamente com as necessidades dos usurios da biblioteca.

20 2.3.3 Terceirizar o desenvolvimento do Sistema de Gerenciamento de Biblioteca A empresa tambm pode optar pelo desenvolvimento do Sistema de Informao para Gerenciamento de Biblioteca por meio de contratao de uma equipe de especialistas externos. Rezende (2006, p. 255), aponta que neste caso ser necessrio cumprir as seguintes etapas: Levantamento de necessidade de informao e aplicaes a serem informatizadas; Desenvolvimento do modelo de informaes da biblioteca, relatando todas as informaes necessrias para que o sistema atenda especificao dos requisitos funcionais e desejados; Identificao e seleo das possveis empresas

desenvolvedoras; Solicitao da proposta mais adequada ao perfil da biblioteca pelo estabelecimento de critrios de avaliao; Testes e revises das especificaes; Implantao do sistema. Rezende (2006, p. 255), diz ainda que as vantagens de adotar esta opo pode ser avaliada como: 1. Evita a manuteno de uma equipe de profissionais. 2. Sistema poder acompanhar a dinmica da Biblioteca. 3. A empresa desenvolvedora do sistema ficar encarregada do acompanhamento da evoluo tecnolgica da rea. J as desvantagens podem ser avaliadas como: 1. Alto custo dos servios de profissionais especializados para o desenvolvimento. 2. Dificuldades no relacionamento com o desenvolvedor. 3. Dependncia da empresa desenvolvedora.

21 Ao optar-se pela terceirizao, deve haver um acordo claro sobre prazos e custos, considerando at mesmo as incertezas que o contratado possa ter sobre o tamanho e a complexidade do projeto, no momento inicial da preparao da proposta do contratante. Segundo Tonsing (2003, p.42), h questes que devem ser examinadas antes de se fechar um contrato: Existe um suporte adequado quanto ao auxlio dos clientes? Solicitaes de resoluo de problemas, em mdia, demoram quanto tempo? O fornecedor tem um histrico de iniciativas quanto a melhoria de seu produto? A tecnologia empregada pelo fornecedor est atualizada? Contudo, o que se espera da terceirizao que ela traga solues eficazes, visando agilidade e flexibilidade das bibliotecas. A partir dessa reflexo, podemos resumir as opes de Sistemas de Gerenciamento de Bibliotecas, destacando as principais vantagens e desvantagens de cada uma conforme a tabela abaixo:

Aquisio de Sistema So econmicos Pacotes satisfatoriamente testados Produtor um especialista nesse tipo de sistema

Desenvolver o Sistema

Terceirizar o desenvolvimento

Garantia de que todos os pr-requisitos ou requisitos funcionais do sistema sejam atendidos

Evita a manuteno de uma equipe de profissionais Sistema poder acompanhar a dinmica da Biblioteca

Vantagens

Fornecidos com boa documentao

A manuteno e atualizao do sistema a qualquer momento

Empresa desenvolvedora acompanhar a evoluo tecnolgica da rea

Suporte e treinamento

22

Probabilidade de no se ajustar ao sistema atual ou requisitos do usurio O usurio fica dependente do fornecedor Possibilidade de o sistema ser menos eficiente do que o outro desenvolvido sob medida

Alto custo de manuteno Dificuldade de acompanhamento da evoluo tecnolgica na rea Dificuldade de substituio de membros da equipe de desenvolvimento

Alto custo dos servios de profissionais especializados Dificuldades no relacionamento com o desenvolvedor

Desvantagens

Dependncia da empresa desenvolvedora

Tabela 1: Resumo das opes de Sistemas de Gerenciamento de Biblioteca

Atualmente impossvel que uma biblioteca que queira atender as necessidades dos usurios com qualidade e eficincia, carea de um Sistema de Gerenciamento de Biblioteca. Estas tm se deparado basicamente com duas opes: comprar ou construir seu prprio sistema de gerenciamento. Enquanto que alguns autores, como o caso de Rowley, defendem a utilizao de sistemas prontos e discordam no desenvolvimento de novos sistemas caseiros, Dziekaniak (2004, p.38), defende que a compra de sistemas comercializados no pode ser vista como nica sada para automao de uma biblioteca. Dziekaniak (2004, p.39), diz que esta estrutura deve ser rompida, pois
Perde-se inmeras vezes quando se adquire um software fechado para gerenciamento de bibliotecas: quer quando o projeto no passou pela integrao do bibliotecrio em seu desenvolvimento, no suprindo suas necessidades, quer devido ausncia do envolvimento do profissional bibliotecrio com a pesquisa, transformando-o em um mero tcnico, destitudo do carter criativo e cientfico. Outro viez negativo no processo de aquisio de sistemas prontos vem do fato da instituio contratante ter de despender de um alto investimento para a aquisio porque a maioria dos sistemas existentes hoje no mercado, alm da licena de uso, o contratante paga taxas de manuteno mensais e, na maioria das vezes, paga inclusive pelas atualizaes sugeridas pelo prprio bibliotecrio usurio. E estas, ao serem acrescidas no sistema, alm de otimiz-lo, tambm englobam lucro para o desenvolvedor, posto que h sistemas em que novas verses com alteraes so comercializadas

23
e a empresa cessa de oferecer suporte s bibliotecas que no adquirem as novas verses, tornando estas totalmente dependentes tecnologicamente. Isto ocorre tambm porque a maioria dos sistemas comercializados atualmente no mercado brasileiro de software, disponibiliza somente a licena de uso do mesmo, no disponibilizando os cdigos-fonte destes, tornando a biblioteca contratante dependente do fornecedor para toda e qualquer atualizao ou mudana no sistema.

Assim entendemos que no existe apenas uma opo para a biblioteca modernizar-se; no h um modelo ideal a seguir e mesmo que a escolha seja a mais acertada poder no atender completamente todas as exigncias da biblioteca. Cada biblioteca deve avaliar o que melhor atende suas expectativas e suas peculiaridades, pois o que bom para uma biblioteca poder no ser para a outra. A partir das consideraes acima, podemos dar o enfoque neste trabalho nas empresas que, avaliando as vantagens e desvantagens em adquirir um sistema de gerenciamento de biblioteca oferecido pelo mercado, ainda do preferncia pelo desenvolvimento sob medida. Sejam empresas que apresentam requisitos muitos raros ou aquelas que preferem ter um sistema integrado que possibilita um fluxo de informaes nico, contnuo e consistente por toda a empresa, inclusive a biblioteca, sob uma nica base de dados. Esses sistemas controlam toda a empresa da produo s finanas, registrando e processando cada fato novo na engrenagem corporativa e distribuindo a informao de maneira clara e segura, em tempo real. Contudo, uma empresa que j possui um baixo custo na manuteno do seu sistema atual pode optar por implementar neste os diversos mdulos de um sistema que gerencia a biblioteca, visando melhorias no processo. At aqui foi visto como desenvolver um software, o que um sistema de gerenciamento de biblioteca e as melhorias que este trouxe para a disseminao e recuperao da informao. Agora precisamos entender quem so as pessoas que participam no processo de desenvolvimento.

DESENVOLVIMENTO DE SOFTWARE Do baco - considerado o primeiro dispositivo tecnolgico criado para

facilitar o trabalho do homem no processamento de informaes - aos processadores de ltima gerao existentes hoje, as novas tecnologias vm modificando substancialmente as relaes do homem com o mundo. Isto fica visvel quando nos deparamos com uma vasta rede guiada por softwares, chamada Internet, no qual evoluiu e transformou tudo, desde a pesquisa em bibliotecas ate a maneira de os consumidores comprarem e, at mesmo, os hbitos de marcar encontro entre as pessoas. Hoje, o software uma tecnologia muito importante no palco mundial, pois afeta praticamente todos os aspectos de nossas vidas e tornou-se difundido no comrcio, na nossa cultura e nas nossas atividades. O processo de desenvolvimento que tem apresentado maiores

complexidades.

Enquanto

anteriormente um software

poderia ser

desenvolvido por apenas uma pessoa, hoje em dia, so necessrias equipes e uma gerncia atuante para sua construo. Por outro lado, o software tem ganhado cada vez mais importncia na vida social e econmica de pessoas e organizaes. Por fim, o usurio tem deixado de ser uma figura passiva, aceitando e se adaptando s funcionalidades de um software para se tornar uma figura mais exigente. O sucesso de um software est em atender s necessidades do cliente.

25 3.1 Qual o significado de software? Quando pensamos em software, logo associamos o termo aos programas de computador. Assim registra o dicionrio1: software o conjunto de procedimentos, mtodos de programao e programas afins, que otimiza a performance de um computador. A resposta para o significado de um Software, segundo Pressman (2006, p. 4), pode ter diversas formas:
(1) instrues (programas de computador) que quando executadas, produzem a funo e o desempenho desejados; (2) estruturas de dados que possibilitam que os programas manipulem adequadamente a informao; e (3) documentos que descrevem a operao e o uso dos programas.

No entanto, devemos ter cuidado para no confundir um software exclusivamente como programas de computador; devemos compreender, segundo Sommerville (2003, p.5), que esta viso muito restritiva e que software no apenas um programa, mas tambm toda a documentao associada e aos dados de configurao necessrios para fazer com que esses programas operem corretamente. O software est a cada dia maior, com mais funcionalidades, mais complexos, abrangendo mais usurios e exigindo a participao de equipes em seu desenvolvimento.

3.2

Caractersticas de um Software Diferentemente do hardware, o software um elemento lgico e no

fsico, tendo como caractersticas diferenciadas:

FERREIRA, Aurlio Buarque de Holanda. Novo dicionrio da lngua portuguesa. 2. ed. rev. e aum. Rio de Janeiro: Nova Fronteira, 1986.

26 desenvolvido ou projetado por engenharia (e no manufaturado no sentido literal); Enquanto o hardware se desgasta, o software se deteriora com o tempo. No caso do hardware, este desgaste pode ser solucionado com a substituio de componentes e, no caso do software, esta substituio (na realidade a liberao de uma nova verso) acarreta no surgimento de novos erros que prejudicam a operao normal; A maioria dos softwares feita sob medida em vez de ser montada a partir de componentes j existentes.

3.3

Custo de Mudanas do Software O custo no desenvolvimento de um software pode variar de acordo as

modificaes que so introduzidas conforme pode ser mostrado na figura 2. Se as mudanas forem executadas na fase inicial (definio) pode ser realizadas sem causar grandes impactos. Porm, o custo para modificar um requisito na fase de manuteno chega a ser cem vezes maior do que na fase de definio de requisitos.

Figura 2: Custo de modificao de um software (PRESSMAN, 2006)

27 Quanto mais tardiamente o cliente rever as exigncias e recomendar solicitaes, maiores sero os impactos gerados no custo do produto, podendo at mesmo gerar custos adicionais ao projeto de software. Os custos so maiores depois que o software est construdo devido necessidade constante de alteraes em sua implementao para corrigir erros ou por no terem sido bem compreendidas s necessidades do usurio. Por isso, acredita-se que a fase mais crtica no processo de desenvolvimento corresponde sua fase de concepo. Um software bem concebido e projetado ter menos chances de apresentar erros ou de no satisfazer o usurio final. Alm disso, um bom projeto permite que mudanas possam ser incorporadas mais facilmente.

3.4

Engenharia de Software O ser humano sempre esteve procura de melhorias, sejam elas

tanto quantitativas quanto qualitativas. A engenharia de software veio facilitar parte dessa busca, tendo como objetivo melhorar a qualidade do software e aumentar a produtividade e satisfao profissional de engenheiro de software. Tudo relatado at aqui mostra a velocidade com que a informtica progride. Mas no para por a. Ainda h milhares de programas de computador para serem corrigidos, adaptados e aperfeioados medida que o tempo passa e o nus de realizar essas atividades de manuteno absorve mais pessoas e mais recursos que todo o trabalho aplicado na criao de novos softwares. Assim podemos definir a engenharia de software, segundo

Sommerville (2003, p.5) como: uma disciplina da engenharia que se ocupa de todos os aspectos da produo de software, desde os estgios iniciais de

28 especificao do sistema at a manuteno desse sistema, depois que ele entrou em operao

3.5

Princpios da Engenharia de Software Segundo Pressman (2006, p. 31), a Engenharia de Software utiliza

um conjunto de mtodos, tcnicas e procedimentos para analisar, projetar e gerenciar. Os mtodos proporcionam os detalhes de como fazer para construir o software. Envolvem um conjunto de tarefas que incluem: planejamento e estimativa do projeto, anlise de requisitos de software e de sistemas, projeto da estrutura de dados, arquitetura de programa e algoritmo de processamento, codificao, teste e manuteno. As ferramentas possibilitam a automatizao ou semi-automatizao dos mtodos. Atualmente, existem para sustentar cada um dos mtodos.
Quando as ferramentas so integradas de forma que a informao criada por uma ferramenta possa ser usada por outra, estabelecido um sistema de suporte ao desenvolvimento de software chamado engenharia de software auxiliada por computador (CASE ComputerAided Software Engineering). (PRESSMAN, 2006, p. 32)

Os

procedimentos

o conjunto de atividades

que visa o

desenvolvimento ou evoluo racional do software. Constituem o elo de ligao que mantm juntos mtodos e ferramentas. Os procedimentos definem a seqncia em que os mtodos so aplicados, os produtos que sero entregues, as atividades de controle de qualidade que permitem os gerentes de software avaliarem o progresso. Enfim, a Engenharia de Software vem se ocupar de todos os aspectos da produo de um software, utilizando-se de ferramentas, tcnicas,

29 procedimentos e paradigmas para melhorar a qualidade dos produtos de software.

3.6

Processo de Construo de Software Na computao, o desenvolvimento de software o ato de elaborar e

implementar um sistema computacional, isto , transformar a necessidade de um utilizador ou de um mercado em um produto de software. Tambm entendido como a aplicao dos processos da engenharia de software combinados com a pesquisa das necessidades do produto para desenvolver software. O processo de software pode ser entendido como uma seqncia de diferentes atividades executadas durante o desenvolvimento do software, buscando eliminar falhas e o desenvolvimento de um produto de qualidade. E, ao buscarmos um significado mais profundo notaremos que uma resposta para a pergunta: o que processo de software? assume, de acordo com a literatura especializada, uma srie de significados que ampliam a compreenso sobre o assunto. Segundo Tonsig (2003, p.56), um roteiro de trabalho, constitudo em geral de macro-etapas com objetivos funcionais na construo de um software, onde tambm possvel visualizar-se a interdependncia existente entre as macro-etapas. Sommerville (2003, p. 36) reafirma esta concepo dizendo que um conjunto de atividades e resultados associados que produzem um produto de software. A partir destas definies podemos considerar processo de software como um conjunto de atividades, mtodos, ferramentas e prticas que so utilizadas para construir um produto de software de qualidade. De acordo com Tonsig (2003, p.56-57), o desenvolvimento de um software compreende 03 grandes fases (macro-etapas) que so independentes do modelo de processo de software empregado:

30 Requisitos: O que exatamente se espera que seja feito? Qual a abrangncia do software? Nesta etapa importante que o analista trace bem os limites daquilo que ser desenvolvido, deve ser realizada uma intensa busca de informaes sobre quais processos sero executados e quais dados sero manipulados. Tudo deve ser questionado: Por que se faz aquilo daquela forma? Quais as restries que existem nos procedimentos e dados utilizados? Projeto/Desenvolvimento: propriamente dito o Na construo faz do software tcnicas

analista

especificaes

detalhando a soluo criada para atender ao usurio/cliente e os programadores codificam os programas em alguma linguagem de programao e os testam em sua individualidade e coletivamente. Uma vez que todo o sistema foi testado, libera-se para uso. Implantao/Manuteno: Pode haver resistncia na fase de implantao do software. A manuteno permanecer durante toda sua vida til e pode ocorrer motivada por 03 fatores: a correo de algum problema existente no software, sua adaptao decorrente de novas exigncias (internas ou externas da empresa) e algum melhoramento funcional que seja incorporado ao software. Em cada fase de um processo de software definido so executadas as atividades bsicas para que sejam atingidos os objetivos propostos. Essas atividades relacionadas a um processo de software esto diretamente vinculadas com a produo do software como produto final. Afim de especificar quais atividades devem ser executadas e em qual ordem temos diversos modelos de desenvolvimento de software. Tais modelos foram propostos ao longo dos anos como: Cascata, Incremental, Prototipao, Espiral, etc. Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta s situaes a analisar, porque s na altura em que enfrentamos o problema que podemos escolher o modelo. essencial, antes do desenvolvimento de um produto, preparar um

31 plano geral, ou seja, escolher um processo (modelo). Este pode ser personalizado, se adaptando ao tamanho, complexidade e/ou nvel de confiabilidade/segurana do projeto. Enfim, vale ressaltar que para muitos sistemas de grande porte, no existe apenas um processo (modelo) de software que possa ser utilizado. Processos diferentes podem ser utilizados para desenvolver diferentes partes do sistema.

3.7

Modelos de Processo de Software A seguir sero detalhados os principais paradigmas descritos na

literatura e utilizados pelo mercado.

3.7.1 Modelo em cascata O modelo em cascata, tambm conhecido como ciclo de vida clssico ou linear, foi o primeiro modelo de desenvolvimento de software estudado pela engenharia de software e ainda hoje um dos mais difundidos e utilizados. Nesse modelo, o desenvolvimento de um software se d de forma seqencial, a partir da atividade de verificao da viabilidade do

desenvolvimento. Para cada etapa cumprida, segue-se a etapa imediatamente posterior, da a idia de cascata:

32

Figura 3: Modelo em cascata (PRESSMAN, 2002 e PFLEEGER, 2004)

Anlise de requisitos: consiste em levantar os requisitos dos usurios a fim de fazer uma primeira verificao de viabilidade; uma vez feita esta verificao, consiste em coletar, classificar e validar os requisitos de software necessrios a fim de garantir o atendimento s necessidades dos usurios; Anlise: consiste em detalhar os requisitos coletados na primeira etapa e garantir o perfeito entendimento das reais necessidades dos usurios. Projeto: consiste em projetar estruturas (projeto de banco de dados - relacional, orientado a objetos etc.), interfaces e funes; Codificao: atividade que consiste em transformar o projeto anteriormente elaborado em instrues da anlise, passadas de forma legvel para mquina. Testes: etapa que consiste em testes internos (programas) e externos (sistema). Tem como objetivo eliminar os erros lgicos internos ao software visando garantir um mnimo de segurana para que o programa rode sem problemas. Deve contar com a participao tanto do pessoal tcnico quanto dos usurios; Manuteno: aps a implantao do sistema inicia-se a etapa de manuteno; esta pode ser divida em trs tipos: evolutiva,

33 caracterizada originalmente por necessidades adicionais no software pela

especificado;

corretiva,

caracterizada

necessidade de correo de um erro, quer seja de projeto, anlise ou codificao; preventiva, caracterizada pela necessidade de adaptao do software a novos ambientes ou configuraes. Este modelo, segundo Pressman (2002, p. 27), nas duas ltimas dcadas, tem enfrentado uma srie de questionamentos sobre sua eficcia. Dentre os principais podem ser destacados: Os projetos reais raramente seguem o fluxo seqencial que este modelo prope, o que causa grande dificuldade e ansiedade em todos os envolvidos; Muitas vezes difcil para o cliente declarar todas as exigncias de forma explcita, o que requer muita habilidade dos profissionais; O cliente deve ter pacincia - o produto somente ser disponibilizado no final do ciclo, podendo no contemplar as exigncias dos usurios; Alto custo de correo de problemas quando identificados tardiamente (nas fases de manuteno, testes...); Manuteno: fase na qual o sistema passar a maior parte do tempo, muitas vezes em manutenes corretivas.

3.7.2 Modelo Incremental O Modelo Incremental foi desenvolvido atravs da combinao entre os modelos linear e prototipao. A fase de projeto existente no modelo cascata foi decomposta em projeto lgico e projeto fsico. Essa abordagem permite que as atividades do projeto possam ser subdivididas e que ocorram em paralelo. Parte do princpio que um determinado software no precisa ser

34 concludo na sua totalidade a fim de ser entregue para os usurios procura dividir o processo de desenvolvimento em partes, chamadas incrementos, funcionais, antecipando o contato dos usurios com o produto em elaborao:
Quando um modelo incremental usado, o primeiro incremento frequentemente chamado de ncleo do produto. Isto , os requisitos bsicos so satisfeitos, mas muitas caractersticas suplementares (algumas conhecidas, outras desconhecidas) deixam de ser elaboradas. O ncleo do produto usado pelo cliente (ou passa por reviso detalhada). Um plano desenvolvido para o prximo incremento como resultado do uso e/ou avaliao. O plano visa modificao do ncleo do produto para melhor satisfazer s necessidades do cliente e elaborao de caractersticas e funcionalidades adicionais. Esse processo repetido aps a realizao de cada incremento, at que o produto completo seja produzido. (PRESSMAN, 2002, p.32)

Logo,

em

cada

incremento

realizado

todo

ciclo

do

desenvolvimento de software, do planejamento aos testes do sistema j em funcionamento, bem como a especificao das interfaces e interdependncias de modo a garantir que um incremento necessite apenas de itens desenvolvidos em incrementos anteriores e no posteriores o que poderia causar inconvenientes nessa abordagem. Assim, cada etapa produz um sistema totalmente funcional, apesar de ainda no cobrir todos os requisitos.

Figura 4: Modelo Incremental (PRESSMAN, 2002)

uma abordagem utilizada por diversas empresas que produzem

35 software, com equipes numerosas de profissionais. importante garantir que os incrementos, em especial o primeiro, tenham boa aceitao por parte dos usurios a fim de garantir a continuidade dos demais; caso isso no seja possvel, problemas de retrabalho podem acarretar em atrasos e custos elevados para a concluso do software.

3.7.3 Prototipao um processo que capacita o desenvolvedor a criar um modelo do software que ser implementado. Diferentemente do modelo clssico, a prototipao requer uma participao bastante ativa do usurio, uma vez que sempre depender de sua avaliao para avanar para a prxima fase. O desenvolvimento feito obedecendo realizao das diferentes etapas de anlise de requisitos, o projeto, a codificao e os testes. No necessariamente estas etapas devem ser realizadas de modo muito explcito ou formal. A definio de todos os requisitos necessrios ao sistema pelo cliente ou usurio geralmente uma tarefa muito difcil. quase impossvel prever como o sistema ir afetar o funcionamento das prticas de trabalho, como ser a interao com outros sistemas e que operaes dos usurios devem ser automatizadas. Mas para poder testar os requisitos de uma forma mais eficiente, seria necessria a utilizao de um prottipo do sistema. Um prottipo uma verso inicial de um sistema de software, que utilizada para mostrar conceitos, experimentar opes de projeto e, em geral, para conhecer mais sobre os problemas e suas possveis solues. O desenvolvimento rpido de um prottipo essencial para que os custos sejam

36 controlados e os usurios possam fazer experincias com o prottipo no incio do processo de software. As etapas normalmente encontradas neste paradigma so:

Figura 5: Modelo de Prototipao (PRESSMAN, 2002)

Coleta e refinamento dos requisitos: desenvolvedores e usurios definem os objetivos globais para o software, identificam as exigncias conhecidas e esboam as reas em que uma definio adicional obrigatria; Projeto rpido: concentra-se na representao daqueles aspectos do software que sero visveis aos usurios (basicamente entradas de dados, sadas de dados e navegao); Construo do prottipo: construo utilizando ambientes de desenvolvimento rpido. Algumas vezes o prottipo consiste em telas e relatrios, outras em um aplicativo e outras ainda em esboo em papel; Avaliao do prottipo pelo cliente: avaliao do prottipo pelo usurio objetivando extrair crticas e sugestes; Refinamento do prottipo: etapa onde as crticas e sugestes do usurio so avaliadas e incorporadas ao prottipo; com isso, tanto usurios quanto os desenvolvedores passam a ter uma viso mais

37 clara das reais necessidades. Repete-se ento novo ciclo a partir do projeto rpido para a incorporao dessas novas necessidades; Engenharia do produto: uma vez definidos todos os produtos a serem gerados e dirimidas todas as dvidas com o prottipo, o sistema propriamente dito pode ser desenvolvido utilizando conceitos de engenharia de software. Na maioria dos projetos, o primeiro sistema construdo dificilmente ser usvel. Ele pode ser muito lento, muito grande, desajeitado em uso, ou todos os trs. A questo administrativa, no se deve construir um sistemapiloto e jog-lo fora. Isso ser feito. A nica questo se deve planejar antecipadamente a construo de algo que se vai jogar fora ou prometer entregar isso aos clientes. O prottipo pode ser oferecido ao cliente em diferentes formas: prottipo em papel; modelo executvel em PC retratando a interface homem-mquina capacitando o cliente a compreender a forma de interao com o software; prottipo de trabalho que implemente um subconjunto dos requisitos indicados; programa existente (pacote) que permita representar todas ou parte das funes desejadas para o software a construir. Vantagens da prototipao: modelo de desenvolvimento interessante para alguns sistemas de grande porte que representem um certo grau de dificuldade para exprimir rigorosamente os requisitos; possvel demonstrar a realizabilidade atravs da construo de um prottipo do sistema; possvel obter uma verso, mesmo simplificada do que ser o sistema, com um pequeno investimento inicial;

38 A experincia adquirida no desenvolvimento do prottipo vai ser de extrema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir o seu custo e resultando num sistema melhor concebido. Problemas da prototipao: Quando informamos que o produto precisa ser reconstrudo, o cliente exige que alguns acertos sejam aplicados para tornar o prottipo um produto; muito freqentemente, a gerncia de desenvolvimento de software cede. O desenvolvedor muitas vezes faz concesses de implementao a fim de colocar um prottipo em funcionamento rapidamente. Depois de algum tempo, o desenvolvedor pode familiarizar-se com essas opes e esquecer-se de todas as razes pelas quais elas so inadequadas - a opo menos ideal se tornou ento parte integrante do sistema. A fim de evitar esses problemas a recomendao de que as regras do jogo sejam negociadas com o usurio antes do incio do desenvolvimento do prottipo.

3.7.4 Espiral O modelo espiral nasceu para suprir de forma mais eficiente algumas deficincias do ciclo de vida clssico. Esse paradigma absorveu os aspectos positivos do ciclo de vida clssico e da prototipao, implementando um novo item chamado anlise dos riscos, que at ento ningum mencionara.

39

Figura 6: Modelo Espiral (PFLEEGER, 2004)

Os quatro quadrantes representam as seguintes etapas: Planejamento: determinao dos objetivos, alternativas e

restries para o desenvolvimento da verso atual do software; Anlise de riscos: anlise das alternativas e identificao, priorizao, acompanhamento e resoluo dos riscos; Engenharia: desenvolvimento do sistema e implementao de rotinas que sero utilizadas a cada refinamento. Avaliao do cliente: avaliao, por parte do cliente, dos resultados da engenharia. O modelo espiral inicia sua interao de dentro para fora, partindo do seu centro. Ao final de cada iterao ao redor da espiral, verses progressivamente mais completas do software so geradas. A incorporao da anlise de riscos a grande novidade e virtude deste modelo. Incorpora a necessidade de uma avaliao criteriosa dos riscos envolvidos com o projeto e a deciso de prosseguir, ou no, com o desenvolvimento do software. Esta deciso, que no modelo clssico muitas

40 vezes no visvel at que seja tarde de mais (muitas vezes apenas aps a etapa de codificao, quando o sistema comea a ser testado visando a implantao), tomada baseada nos levantamento e requisitos da atual fase de desenvolvimento. Uma preocupao constante manter o entendimento de todos os envolvidos de que a abordagem deste modelo evolutiva e requer a participao ativa e constante de todos. Um dos principais benefcios a entrega de produtos (ou verses do software) intermedirias que j possuem caractersticas interessantes aos usurios, j podendo ser utilizada (inclusive extremamente recomendvel que isto ocorra a fim de fornecer subsdios para o planejamento do prximo ciclo de desenvolvimento).

3.7.5 Tcnica da Quarta Gerao O paradigma de Tcnicas de Quarta Gerao2 da engenharia de software concentra-se na capacidade de se especificar software a uma mquina em um nvel que esteja prximo linguagem natural ou de se usar uma notao que comunique uma funo significativa. Entende-se por estas tcnicas um amplo conjunto de ferramentas de software (CASE) que tm uma caracterstica em comum: possibilitar ao desenvolvedor de software especificar alguma etapa do software em um nvel elevado e automatizar a gerao do cdigo-fonte para a implementao desta caracterstica; as ferramentas disponveis atualmente para este paradigma incluem, entre outras, as seguintes caractersticas: Linguagens no procedimentais para consultas e operaes em bancos de dados; Geradores de cdigo-fonte;

Esse paradigma tambm conhecido como ferramentas 4GT.

41 Geradores de interfaces, contemplando manipulao de dados, interao e definio de telas; Capacidade grfica de alto nvel; Esse paradigma se inicia com uma etapa de coleta de requisitos. Idealmente, o cliente descreveria os requisitos, e estes seriam diretamente traduzidos num prottipo operacional. Mas isso no idealmente possvel. O cliente pode no ter certeza daquilo que exigido, pode ser ambguo ao especificar fatos que so conhecidos e pode ser invivel especificar as informaes de maneira que uma ferramenta 4GT possa receber.

Figura 7: Tcnica da Quarta Gerao (PRESSMAN, 2002)

Para pequenas aplicaes, talvez seja possvel passar diretamente da etapa de coleta das exigncias para a implementao, utilizando uma linguagem de quarta gerao (4GL). Para transformar a implementao de uma 4GT num produto, o desenvolvedor deve realizar testes cuidadosos, desenvolver uma documentao significativa e executar todas as demais atividades de "transio" que tambm so exigidas em outros paradigmas da engenharia de software. Algumas crticas tm sido feitas ao uso deste paradigma:

42 Perda do conhecimento do processo de desenvolvimento como um todo, em funo da automatizao de algumas etapas; Gerao de cdigo no otimizado, o que pode causar problemas posteriores de performance e manuteno; rea de atuao das ferramentas de quarta gerao ainda restrita, notadamente circunscrita ao desenvolvimento de software comercial; vrias reas de aplicao de software no possuem ferramentas adequadas. As tcnicas de quarta gerao j se tornaram uma parte importante do desenvolvimento de software na rea de aplicao de sistemas de informao e a demanda de software continuar em ascenso, porm o software produzido com mtodos e paradigmas convencionais contribuir cada vez menos para todo o software desenvolvido. As tcnicas de quarta gerao preenchero a lacuna. Alm dos modelos j apresentados, existem diversos outros para o desenvolvimento de software.

ENGENHARIA DE REQUISITOS Quando observamos vrios modelos de processo para a construo

de um software, chamamos a ateno para algumas etapas fundamentais para que o desenvolvimento do software seja bem-sucedido. Cada modelo de processo abordado anteriormente inclui atividades que visam a identificao de requisitos. Assim sendo, a compreenso do objetivo e funcionamento do sistema comea com um exame de requisitos. Uma compreenso completa dos Requisitos do Software

fundamental para obter um software e um processo de desenvolvimento com alta qualidade

4.1

O que so requisitos? Os requisitos compreendem o que os clientes e usurios esperam que

o sistema realize.
Os requisitos compem o conjunto de necessidades estabelecido pelo cliente/usurio do sistema que definem a estrutura e o comportamento do software que ser desenvolvido. Como itens de requisitos temos os dados, os processos, as restries existentes de acordo com o negcio, as pessoas envolvidas e o relacionamento entre todas essas coisas. Assume-se que os requisitos so as premissas que determinaro a capacidade necessria para que o software possa: Permitir que o usurio resolva problemas inerentes ao negcio da empresa, dentro de certo domnio. Atender as necessidades ou restries da organizao ou dos outros componentes do sistema. (TONSIG, 2003, p.92)

Quando

um

sistema

novo

construdo

para

um

cliente,

frequentemente, este sistema novo substituir um j existente ou o modo de realizar funes, ou ainda, o novo sistema ser um aprimoramento ou uma extenso de um sistema atual (manual ou automtico).
No importa se sua funcionalidade nova ou antiga, cada sistema tem um propsito, geralmente expresso em termos do que o sistema pode

44
fazer. Um requisito uma caracterstica do sistema ou descrio de algo que o sistema capaz de realizar, para atingir os seus objetivos. (PFLEEGER, 2004, p.111)

Durante a identificao dos requisitos, de acordo com Pfleeger, (2004, p. 113), til separar os requisitos em trs categorias:
1. Requisitos que devem ser totalmente satisfeitos. 2. Requisitos que so altamente desejveis, mas no necessrios. 3. Requisitos que so possveis, mas poderiam ser eliminados.

A relevncia para o uso da analise de requisitos por categorias se d pelo fato de que todas as partes entrem em entendimento sobre o que realmente necessrio e, til tambm, quando um projeto de desenvolvimento de software est restrito pelo tempo ou por recursos. O objetivo principal da especificao de requisitos desenvolver produtos de qualidade que satisfaam s reais necessidades dos clientes dentro do prazo e do oramento. A especificao de requisitos a tarefa mais importante na fase de anlise de um sistema. Entender aquilo que o cliente deseja ou o que o cliente acredita que precisa e as regras de uma instituio ou os processos da mesma no tarefa fcil. Havendo requisitos mal especificados haver retrabalho e atrasos no projeto e o que acarretar cliente insatisfeito devido ao sistema no corresponder ao produto solicitado inicialmente. Diante do exposto, devemos ter muito cuidado quando estamos na fase de elaborao dos requisitos para que o produto final no tenha custos adicionais e atraso na entrega do produto como foi descrito no item 3.3 deste captulo quando aborda sobre o custo do software.

4.2

Benefcios de analise de requisitos Os benefcios de analise de requisitos, segundo Tonsig (2003, p94)

so:

45
Entendimento comum entre desenvolvedores, clientes e usurio sobre o trabalho a ser feito e quais os critrios de aceitao do sistema. Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e equipamentos). Melhoria na qualidade do software que ser desenvolvido. Objetivo traado de maneira a gerar menor ndice de manuteno decorrente de erros de levantamento de informaes.

Para servir de base para um produto de boa qualidade, a prpria Especificao de Requisitos deve satisfazer uma srie de caractersticas de qualidade. De acordo com Tonsig (2003, p94), uma boa especificao dos requisitos deve ser:
Clara e no ambgua Completa Correta Consistente Concisa Confivel

4.3

Funes para a realizao da Engenharia de Requisitos As atividades da engenharia de requisitos vo desde a idia de

desenvolver um sistema de software at a modelagem conceitual do que se vai construir. O processo de Engenharia de Requisitos, de acordo com Pressman (2006, p.118), realizado por meio da execuo de sete funes distintas: Concepo = estabelecer um entendimento bsico do problema, o pessoal que quer uma soluo, a natureza da soluo desejada e da efetividade da comunicao e colaborao preliminares entre cliente e desenvolvedor. Assim, realizado uma srie de questes livres de contexto aos clientes/usurios. Levantamento = obter informaes sobre os objetivos do sistema, o que precisa ser conseguido, como o sistema se encaixa nas

46 necessidades do negocio e como o sistema ser usado no seu dia a dia. Essa tarefa muito difcil. H vrios problemas que nos ajudam a entender o porqu da dificuldade:
Problemas de escopo. o limite do sistema mal definido ou o cliente/usurio especifica detalhes tcnicos desnecessrios que podem confundir, em vez de esclarecer, os objetivos globais do sistema. Problemas de entendimento. Os clientes/usurios no esto completamente certos de que necessrio, tm pouca compreenso das capacidades e limitaes de seu ambiente computacional, no tm pleno entendimento do domnio do problema, tm dificuldade de informar as necessidades ao engenheiro de sistemas, omitem informaes que acreditam ser bvias, especificam requisitos conflitantes com as necessidades de outros clientes/usurios ou especificam requisitos que so ambguos ou impossveis de usar. Problemas de volatilidade. Os requisitos mudam ao longo do tempo. (CHRISTEL & KANG apud PRESSMAN, 2006, 118-119)

Para contornar esses problemas, a atividade de coleta dos requisitos deve ser abordada de um modo organizado. Elaborao = expandir e refinar, durante a elaborao, as informaes obtidas do cliente durante a concepo e o levantamento. Enfoca o desenvolvimento de um modelo tcnico refinado das funes, caractersticas e restries do software. O resultado final da elaborao um modelo de anlise que define o domnio do problema informacional, funcional e comportamental. Negociao = processo de negociao dos requisitos que foram solicitados alm do que pode ser conseguido e/ou requisitos conflitantes. Usa-se critrios onde requisitos so eliminados, combinados e/ou modificados de modo que cada parte alcance algum grau de satisfao Especificao = prover uma representao do software que possa ser revisada e aprovada pelo usurio.
Uma especificao pode ser um documento escrito, um modelo grfico, um modelo matemtico formal, uma coleo de cenrios de uso, um prottipo ou qualquer combinao desses elementos. [...] A especificao o produto de trabalho final produzido pelo engenheiro de requisitos. Ela serve como fundamento das atividades de engenharia de software subseqentes. Ela descreve a funo e o

47
desempenho de um sistema baseado em computador e as restries que governaro o seu desenvolvimento. (PRESSMAN, 2006, p.120)

Validao = um processo que trata da verificao dos requisitos quanto consistncia, preciso, contextualizao de requisitos levantados no processo de identificao e descoberta e de anlise e negociao de requisitos. A validao permite minimizar o tempo gasto na deteco de incoerncias e inconformidades devido sua alta eficincia na sua descoberta.
A validao de requisitos examina a especificao para garantir que todos os requisitos do software tenham sido declarados de modo no ambguo; que as inconsistncias, omisses e erros tenham sido detectados e corrigidos e que os produtos de trabalho estejam de acordo com as normas estabelecidas para o processo, o projeto e o produto. O principal mecanismo de validao de requisitos a reviso tcnica formal. A equipe de reviso que valida os requisitos inclui engenheiros de software, clientes, usurios e outros interessados que examinam a especificao procurando por erros de contedo ou de interpretao, reas em que esclarecimentos podem ser necessrios, informaes omissas, inconsistncias (um problema importante quando produtos ou sistemas de grande porte passam por engenharia), requisitos conflitantes ou requisitos irrealsticos (inatingveis). (PRESSMAN, 2006, p.120)

Gesto = procura manter sob controle o conjunto de requisitos de um produto, mesmo diante de algumas alteraes que so inevitveis no processo de construo de um software.
A gesto de requisitos um conjunto de atividades que ajudam a equipe de projeto a identificar, controlar e rastrear requisitos e modificaes de requisitos em qualquer poca, medida que projeto prossegue. (PRESSMAN, 2006, p.121)

Dessas acepes, podemos enfatizar que a Engenharia de Requisitos ocorre durante as atividades de comunicao com o cliente e modelagem que definimos para o processo genrico de software.

48 4.4 Classificao dos requisitos Os requisitos descrevem o comportamento de um sistema. Para ajudar a descrever os requisitos, podemos classific-los, de acordo com Tonsig (2003, p. 92), em dois grandes grupos: os requisitos diretos e os indiretos.

4.4.1 Requisitos Diretos (ou Requisitos funcionais) Os Requisitos Diretos (ou Requisitos funcionais) correspondem listagem de todas as coisas que o sistema deve fazer.
Os requisitos diretos, tambm chamados de requisitos funcionais, referem-se descrio das diversas funes que clientes e usurios querem ou precisam que o sistema oferea. Os requisitos diretos definem a funcionalidade desejada do software. Funcionalidade referese a comportamento, ou seja, funes, aes ou operaes que podero vir a ser realizadas pelo sistema, seja por meio comandos dos usurios ou pela ocorrncia de eventos internos ou externos ao sistema. [...] A especificao de um requisito direto deve prever o que se espera que o software faa (resultado), sem a preocupao de como ele internamente ser construdo para fazer aquilo. (TONSIG, 2003, p.92)

So exemplos de requisitos funcionais: O sistema dever manter registro de todos os materiais da biblioteca, incluindo livros, revistas, peridicos, vdeos, fitas de udio, relatrios, transparncias, discos e CD-ROM O sistema dever permitir que os usurios procurem por um artigo pelo ttulo, autor, ou por ISBN.

49 4.4.2 Requisitos Indiretos (ou Requisitos no funcionais) Os Requisitos indiretos (ou Requisitos no funcionais) so restries que se coloca sobre como o sistema deve realizar seus requisitos funcionais.
Os requisitos indiretos (ou no funcionais) referem-se s qualidades globais de um software, como a fcil manuteno que deve ser propiciada, a segurana, a facilidade de uso, o desempenho e o baixo custo. s vezes conciliar dois requisitos indiretos no tarefa fcil. (TONSIG, 2003, p.93)

So exemplos de requisitos no funcionais: A interface com o usurio do sistema dever ser executada usando um navegador Web. O sistema dever suportar pelo menos 20 transaes leves por segundo De maneira geral, a diferena entre requisitos funcionais e nofuncionais est no fato de os funcionais descreverem o que o sistema deve fazer e os no-funcionais fixam restries sobre como os requisitos funcionais sero implementados.

4.5

Levantamento de requisitos Nesta fase, os membros da equipe tcnica de desenvolvimento de

software trabalham com o cliente e os usurios finais do sistema para descobrir mais informaes sobre o domnio da aplicao.
Um dos objetivos da anlise de requisitos ultrapassar as barreiras de comunicao entre os clientes, usurios e analistas para os requisitos possam ser capturados e modelados corretamente. Conhecer com exatido o ambiente do usurio, sua forma de trabalho, a estrutura da organizao, os problemas e as necessidades a serem supridas pelo novo sistema fundamental para o processo de desenvolvimento do software. (TONSIG, 2003, p.94)

50 Para isto, fundamental criar um ambiente favorvel a coleta de requisitos. Segundo Tonsig (2003, p.94), dentre os recursos utilizados para tal, encontram-se: Aplicao de questionrio = meio rpido e barato, mas podem omitir fatos importantes que podero vir tona em momentos futuros; Verificao de documentos utilizados nos processos = atividade necessria e complementar que permite constatar os dados que so ou no utilizados nos processos (ex: documento com inmeros campos cujo preenchimento nunca aconteceu); Cenrios participativos = usado para minimizar os problemas de falta de uniformidade de um processo utiliza-se tcnicas de brain storm e JAD (Join Application Design); Entrevistas = so realizadas com os usurios para coleta de informaes e ajudam na obteno de informaes relevantes. A entrevista deve ser feita de forma objetiva, visando obter-se o mximo de informaes possveis sobre o assunto de interesse. Observao in loco = est aliada as entrevistas e uma atividade de estar junto ao usurio no ambiente onde ele desenvolve suas atividades, acompanhando-o durante algum tempo, em diferentes dias. Os analistas devem estar inseridos na rotina de trabalho da organizao tentando entender e descrever as principais

atividades que so realizadas. Na observao devem ser identificadas quais as atividades podem ser automatizadas, quem so os potenciais usurios, quais tarefas eles querem realizar com a ajuda do novo sistema, etc. A observao deve ser complementada com entrevistas especficas com os futuros usurios. O primeiro passo no desenvolvimento de um software saber exatamente o que o usurio/cliente espera que o software faa. Ento utiliza-se estes meios para realizar o levantamento de requisitos.

51
O analista de sistemas deve buscar todos os detalhes envolvidos com o software, os quais devero ser projetados; para isso, poder lanar mo de vrios recursos: entrevistas, coletas de documentos, observaes da realizao de processos e eventualmente at estagiar no local em que o software ser desenvolvido. (TONSIG, 2003, p.96)

Logo, podemos ver a anlise de requisitos como uma atividade de investigao.

4.6

Documentao de requisitos O resultado final da anlise e especificao de requisitos e das outras

atividades da fase de definio devem ser apresentados aos clientes para que eles possam valid-lo. Este documento oferece a concordncia entre clientes, analistas e desenvolvedores sobre o que deve ser desenvolvido. utilizando este documento que as atividades da fase de desenvolvimento (design e programao) sero validadas. Cada desenvolvedor utiliza um modelo especfico para elaborar este documento. A sua estrutura muitas vezes depende do mtodo que est sendo utilizado. Em linhas gerais este modelo deve ser basicamente textual, utilizando o mnimo de termos tcnicos, e ilustrados como modelos grficos que demonstrem mais claramente a viso que os analistas tiveram dos problemas e dos requisitos para o futuro sistema. Existem diversas abordagens para escrever uma Especificao de Requisitos de Software. Peters (2001) coloca que o Padro IEEE/ANSI 8301993 descreve uma estrutura genrica para o documento de Especificao de Requisitos de Software (ERS). E que este padro genrico e pretende ser aplicado em uma variada gama de documentos de requisitos. Peters (2001), em define uma estrutura de ERS derivada do padro da IEEE, com a seguinte estrutura:

52 ndice analtico 1 Introduo 1.1 Objetivo 1.2 Escopo (produtos de software a serem produzidos, capacidades, aplicaes, benefcios relevantes, objetivos e requisitos do sistema) 1.3 Definies, acrnimos e abreviaturas 1.4 Referncias (lista completa e, de preferncia anotada, dos documentos referenciados na ERS) 1.5 Viso geral (mapa do contedo e organizao da ERS) 2 Descrio geral 2.1 Perspectiva do produto 2.2 Funes do produto 2.3 Caractersticas do usurio 2.4 Restries (polticas regulamentares, limitaes de hardware, interfaces com outros aplicativos, operao paralela, funes de auditoria, funes de controle, requisito de linguagem de alto nvel, protocolos de handshake de sinal, requisitos de confiabilidade, criticabilidade do aplicativo, segurana e perfil de segurana) 2.5 Hipteses e dependncias 3 Requisitos especficos (interfaces externas, requisitos de processos e dados, requisitos de desempenho e qualidade, requisitos de banco de dados lgico, requisitos de projeto, atributos de sistema do software, organizao de requisitos especficos) 4 Rastreabilidade dos requisitos Apndices ndice remissivo

Contudo, ressalta Peters (2001) que nem todas as partes do documento so necessrias para todos os documentos de requisitos. Cada organizao dever adaptar o padro de acordo com o tipo de sistema que desenvolve. Pressman (2005) citado por Tonsig (2003, p.102) apresenta o seguinte documento de especificao de requisitos de software: I. Introduo 1. Do que trata o sistema 2. Descrio geral do funcionamento do sistema 3. Restries de projeto do software

53 II. Descrio da Informao 1. Representao do fluxo de informao a. Fluxo de dados b. Fluxo de controle 2. Representao do contedo de informao 3. Descrio da interface com o sistema III Descrio Funcional 1. Diviso funcional em parties 2. Descrio funcional a. Narativas b. Restries/limitaes c. Exigncias de desempenho d. Restries de projeto e. Diagramas de apoio 3. Descrio do controle a. Especificao do controle b. Restries de projeto IV. Descrio Comportamental 1. Estados do Sistema 2. Eventos e aes V. Critrios de Validao 1. Limites de desempenho 2. Classes de testes 3. Reao esperada do software 4. Consideraes especiais VI. Bibliografia VII Apndice Uma proposta com formato mais sinttico proposta por Tonsig (2003, p.92), para a documentao de apenas as questes relativas aos requisitos:

54

EMPRESA DE SOFTWARE EXEMPLO S.A.

CLIENTE:

FUNCIONALIDADE REQUERIDA USURIO NO ID. DESCRIO STATUS ATUAL

DESCRIO DE PRREQUISITOS

LEVANTAMENTO REALIZADO POR:

DATA:

Tabela 2: Documentao de Requisitos

O documento apresentado pela tabela 2 rene uma srie de informaes a respeito de um determinado requisito do sistema que ser parte integrante de um novo sistema.
A reunio de todos os requisitos devidamente documentados e confirmados junto aos usurios/cliente dar condies para a inicializao da anlise do software a ser desenvolvido, a fim de que se possa projetar um sistema que atenda as expectativas do cliente. Propositadamente, no existem linhas grafadas que cortem as colunas existentes no documento proposto [tabela 2], uma vez que no uniforme o espao necessrio para documentar os requisitos, alguns exigiro maior espao que outros. (TONSIG, 2003, p.103)

As colunas existentes possuem a seguinte funcionalidade:

Usurio. Deve ser documentado o nome do usurio, ou usurios, junto dos quais se fez o levantamento do requisito, objeto da documentao. O nome do usurio no pode ser impessoal, como Departamento de Vendas. Deve-se identificar corretamente quem foi a pessoa que forneceu os dados relativos documentao, pois o requisito pode ser questionado quanto sua real necessidade, forma de execuo, postergao de desenvolvimento, excluso e realinhamento frente s novas estratgias de gesto da organizao. Funcionalidade requerida. Sugere-se que as funcionalidades sejam identificadas por um cdigo seqencialmente atribudo, o que pode facilitar referncias futuras ao requisito. importante que a descrio seja a mais detalhada possvel, de maneira a registrar detalhes ou particularidades do requisito, tais como eventuais frmulas, restries ou regras de negcio.

55

Status atual. Aponta a situao do requisito no contexto anterior ao desenvolvimento do sistema, documentando-se, por exemplo, se o requisito j existia ou no, se imprescindvel sua existncia ou se pode vir a ser uma funcionalidade futura, dependendo de outros requisitos que o anteceda. O contedo dessa coluna deve ser padronizado. Pode-se expressar todas as possveis situaes criando-se uma nomenclatura, na qual pode-se empregar letras, palavras, abreviaes ou cdigos. Descrio de pr-requisitos. Deve ser documentado os aspectos que constituem pr-requisito para a implementao da funcionalidade descrita. Tais pr-requisitos podem ser procedimentos que devam ser implantados, alteraes em procedimentos existentes, rotinas a serem desenvolvidas ou ainda outros requisitos a serem implementados. Nessa coluna tambm pode figurar aspectos como performance ou configurao esperada do ambiente tecnolgico onde o requisito estar, alm de fatores como interface e outras observaes de carter operacional. (TONSIG, 2003, p.103-104)

Dessas acepes, podemos ressaltar que cada desenvolvedor utiliza um modelo especfico para elaborar este documento. A sua estrutura muitas vezes depende do mtodo que est sendo utilizado. Em linhas gerais este modelo deve ser basicamente textual, utilizando o mnimo de termos tcnicos, e ilustrados como modelos grficos que demonstrem mais claramente a viso que os analistas tiveram dos problemas e dos requisitos para o futuro sistema.

ATORES NO CENRIO DE DESENVOLVIMENTO Um componente-chave do desenvolvimento de software a

comunicao entre os clientes e os desenvolvedores. Caso essa comunicao seja falha, o sistema tambm falhar. Os desenvolvedores devem entender o que o cliente quer e quais so as suas necessidades para desenvolverem solues adequadas. O desenvolvimento de um software requer o esforo de equipe. O nmero de pessoas trabalhando no desenvolvimento de software depende do tamanho e grau de complexidade do projeto. Segundo Pfleeger (2004, p. 11-12), os participantes de um projeto se situam em uma das trs categorias: clientes, usurios ou desenvolvedores. O cliente a empresa, organizao ou pessoa adquire uma cpia de um software, fornecida por um agente que ser chamado de desenvolvedor. O desenvolvedor a empresa, organizao ou pessoa responsvel por criar um plano de construo de mquina (software) que esteja dentro das condies estabelecidas pelo cliente. Esta categoria necessita de alguns gerentes para coordenar e orientar os programadores e a equipe que realiza os testes. O usurio a pessoa ou pessoas que utilizaro o sistema; aqueles que se sentaro em frente ao terminal para inserir dados ou ler os resultados. A relao bsica entre os trs tipos de participantes de um projeto de desenvolvimento de software:

57

Figura 8: Participantes no Desenvolvimento de Software (PFLEEGER, 2004)

O cliente, que controla os recursos financeiros, geralmente negocia e assina o contrato. Algumas vezes, o cliente no um usurio:
Por exemplo, suponha que a empresa Wittenberg Water Works assina um contrato com a Gentle System, Inc., para que esta construa um sistema de contabilidade para a primeira. O presidente da Wittenberg pode descrever, com exatido, aos representantes da Gentle System, quais as suas necessidades, e assinaro um contrato. Todavia, o presidente da Wittenberg no utiliza o sistema de contabilidade diretamente; os usurios sero os auxiliares de escritrios e contadores. (PFLEEGER, 2004, p.12)

Podemos compreender, no caso de uma biblioteca que o bibliotecrio ir executar o papel do cliente e usurio. Logo, importante que os desenvolvedores saibam exatamente quais so as necessidades dos dois grupos, clientes e usurios.

58 5.1 O papel do analista O papel do analista muito importante para o sucesso de um projeto, pois tem que traduzir as diversas perspectivas em uma especificao de requisitos e se comunicar com todos os participantes do processo de desenvolvimento de software da forma mais clara possvel. O analista conhecido por uma srie de apelidos: Analista de Sistemas Engenheiro de Sistemas Projetistas de Sistemas-Chefe Programador/Analista O analista o elo entre os usurios e o grupo tcnico de codificao dos programas (programadores)
Os usurios possuem algum problema (necessidade) com relao informao que, em geral, pode ser resolvido via utilizao do computador. Os programadores possuem um conhecimento para dizer ao computador como fazer as coisas, e o analista quem define o que deve ser feito. (TONSIG, 2003, p.88).

Para preencher o espao entre as vagas idias do usurio e as especificaes que guiaro o trabalho da equipe de desenvolvimento, o analista precisa inicialmente entender os objetivos do cliente em relao ao novo sistema e definir o requisitos funcionais e no funcionais que permitiro ao gerente do projeto estimar, aos desenvolvedores projetar e construir, e os testadores a testar o produto. Como relata Pressman (2006, p.235), o analista deve exibir os seguintes traos caractersticos: Compreender conceitos abstratos, reorganiz-los em divises lgicas e sintetizar "solues" baseadas em cada diviso. Absorver fatos pertinentes de fontes conflitantes ou confusas. Entender os ambientes do usurio/cliente.

59 Aplicar elementos do sistema de hardware e/ou software aos elementos do usurio/cliente. Comunicar bem nas formas escrita e verbal. Um ponto muito importante que envolve a atividade do analista o fato que ele vai estar constantemente se relacionando com o usurio/clientes, sendo estes uma das mais preciosas fontes de informao para o levantamento das informaes. A criao de um software envolve atividades multiplicinares, nas quais esto envolvidas pessoas com diferentes formaes, diferentes pontos de vista e diferentes interesses.

Figura 9: O papel do analista (PRESSMAN, 2006)

O analista tem que ser capaz de lidar, ao mesmo tempo, como cliente e o desenvolvedor, cada qual trazendo formaes, pontos de vista, vivncias, experincias e maturidade totalmente distintas. O analista executa ou coordena cada uma das tarefas associadas anlise de requisitos de software. Durante as tarefas de reconhecimento, ele comunica-se com o pessoal do usurio/cliente a fim de conhecer as caractersticas do ambiente existente. O analista convoca o pessoal de desenvolvimento durante as tarefas de avaliao e sntese, de forma que as caractersticas do software sejam corretamente definidas. O analista

60 geralmente o responsvel pelo desenvolvimento de uma Especificao de Requisitos de Software e participa de todas as revises. Por conta deste contexto, necessrio que o analista desenvolva algumas caractersticas pessoais:

Figura 10: Caractersticas pessoais do analista (TONSIG, 2003)

5.2

O bibliotecrio e seu papel no desenvolvimento de software O bibliotecrio o profissional mais qualificado da Instituio para

participar do processo de desenvolvimento de Sistema de Gerenciamento de Biblioteca junto aos profissionais de tecnologia da informao, pois ele: Conhece a rea da biblioteconomia Conhece a realidade da biblioteca Conhece as necessidades Conhece a terminologia

61 ele quem ir utilizar A participao do bibliotecrio no cenrio de desenvolvimento de software para biblioteca de fundamental importncia para dar rumo ao projeto de software mais adequado, de acordo com os objetivos dos usurios e da rea de biblioteconomia.
O quanto um projeto de software ser robusto, depender da anlise, modelagem e programao elaboradas para o desenvolvimento do sistema a ser criado. Para tanto, necessrio que o desenvolvedor entenda a respeito da tarefa que automatizar. No caso do bibliotecrio, seu conhecimento acerca da rea bastante importante para que se desenvolva um bom projeto de software, uma vez que todo projeto de anlise de sistema representa a abstrao da realidade, e seu objetivo sempre deveria ser a otimizao de procedimentos, metodologias, conceitos e tcnicas da rea a que se prope informatizar. (DZIEKANIAK, 2004, p41)

Para uma boa atuao do bibliotecrio (usurio), conveniente que participe ativamente em algumas fases do desenvolvimento: Definio dos requisitos: o bibliotecrio ir expressar as necessidades para o sistema desenvolver, ou seja, vai ser entrevistado, questionado, no sentido de fornecer os insumos bsicos para iniciar o projeto de construo ou manuteno de um software. Validao dos requisitos: o bibliotecrio nesta fase ir verificar se os requisitos vo estar de acordo com as necessidades da biblioteca. Validao do projeto: o bibliotecrio ir validar o projeto, verificando se este est apto a ser colocado em prtica. Teste e Validao: aqui o bibliotecrio ir verificar e validar o software gerado. O bibliotecrio vai estar na posio de usurio, fornecendo as informaes necessrias aos desenvolvedores, ou seja, o seu papel deve estar voltado para os requisitos, nos testes nas fases de elaborao e na validao final do software.

62

5.3

Divergncias entre os profissionais para desenvolvimento do software De acordo com Pfleeger (2004, p.142) usurios e desenvolvedores

podem ter conceitos prvios (certos ou errados) sobre quais so os valores do outro grupo e como ele atua:

Como os desenvolvedores vem os usurios Os usurios no sabem o que querem. Os usurios no conseguem articular o que querem. Os usurios tm muitas necessidades puramente polticas. Os usurios no querem tudo imediatamente. Os usurios no sabem priorizar as necessidades. Os usurios se recusam a se responsabilizar pelo sistema. Os usurios so incapazes de fornecer uma declarao aproveitvel sobre suas necessidades. Os usurios no esto comprometidos com os projetos de desenvolvimento de sistemas.

Como os usurios vem os desenvolvedores Os desenvolvedores no entendem as necessidades operacionais. Os desenvolvedores do muita nfase ao aspecto tcnico. Os desenvolvedores tentam nos dizer como fazer nosso trabalho. Os desenvolvedores no conseguem transformar as necessidades em um sistema bem sucedido. Os desenvolvedores dizem no o tempo todo. Os desenvolvedores esto sempre ultrapassando o oramento. Os desenvolvedores esto sempre atrasados. Os desenvolvedores pedem aos usurios que dediquem seu tempo e esforo, mesmo que em detrimento de suas responsabilidades principais. Os desenvolvedores definem padres no realistas para a definio dos requisitos. Os desenvolvedores so incapazes de responder rapidamente a legitimas necessidades das mudanas.

Os usurios no querem se comprometer

Os usurios no conseguem seguir o cronograma.

Tabela 3: Como os usurios e desenvolvedores vem uns aos outros (PFLEEGER, 2004)

Para Simonetto (1999, p.36) no desenvolvimento de software podemos analisar os problemas do ponto de vista do usurio em relao ao analista e do analista em relao ao usurio.

63 No ponto de vista do Usurio: No entende o profissional de TI, pois o acha muito tcnico Esta uma das principais alegaes feitas por usurios que participam de um projeto de desenvolvimento de software. Muitas vezes esta reclamao at procede. Porm, tambm pode ser utilizada como um modo de sonegar a informao, pois o usurio sabe muito bem o que o analista quer, e por no querer colaborar, faz esta argumentao. V o sistema sob seu ponto de vista Este aspecto problemtico na medida em que um item do sistema de suma importncia para um usurio e o analista ao desenvolver d menos importncia a outro item de um usurio, provocando assim o descontentamento de uma das partes. Nunca o analista ir agradar a todos os usurios. Imagina que o Analista saiba o que est fazendo A maioria dos usurios (bibliotecrios) se esfora para compreender os documentos de especificao, mas por um motivo ou outro acabam desistindo e ficam imaginando que o pessoal do desenvolvimento saiba o que est fazendo. Somente depois de pronto o sistema que estes usurios tentaro entend-lo. Qualquer reao neste momento pode levar a custos adicionais no projeto. No ponto de vista do Analista: O usurio no sabe o que quer Geralmente, os desenvolvedores com esta frase "jogam" parte da culpa do software no ter sado como o usurio queria. Esta frase utilizada pelos desenvolvedores para se "queixarem" dos usurios. A verdade que muitas vezes as perguntas feitas pelos analistas aos usurios no so

64 entendidas e os usurios por no estarem familiarizados com a linguagem da informtica no querem se expor ao "pessoal da informtica". A impresso que fica ao desenvolvedor a de que o usurio no sabe realmente o que quer e ainda, isso se repete em cada rea envolvida com o software, quanto mais pessoas forem ouvidas, mais difcil se tornar alcanar um consenso nas decises. O usurio sonega informaes Na maioria das organizaes (as bibliotecas e os centros de documentao) o que h de mais precioso so as informaes. Algumas delas detidas por grupos de funcionrios e outras apenas por um funcionrio. Numa especificao de requisitos onde o analista ter que interagir com usurios deste tipo, certamente encontrar grandes dificuldades. Dificuldades, pois ele ir sentir-se ameaado pelo software a ser desenvolvido e que deixar a informao disponvel a mais pessoas e no s a ele. Uma maneira deste usurio defender-se do analista no colaborando para o desenvolvimento, seja atravs da ocultao das informaes ou, at mesmo, por informaes erradas que ele passa ao analista. Indisponibilidade do Usurio Analista Ao desenvolver um sistema, o mnimo que o analista espera do usurio que ele em determinados momentos esteja sua disposio para entrevistas, esclarecimentos sobre rotinas de trabalhos e outros tantos esclarecimentos. Muitas vezes o que acontece o usurio, por no querer colaborar com o desenvolvimento do sistema, alegar no ter tempo disponvel para o desenvolvedor do sistema. Certamente o analista no possui o dom da telepatia para adivinhar o que o usurio (bibliotecrio) teria para dizer e no disse. Muitas so as vezes, ento, que o analista por no poder contar com a participao do bibliotecrio procura solucionar o problema com mtodos j antes desenvolvidos por ele, e de que um modo ou outro poderiam se encaixar nesta determinada soluo. Esta maneira a conhecida "soluo caseira", que na maioria das vezes geram

65 especificaes imprecisas e incorretas, gerando assim sistemas que no atendem s reais necessidades do usurio.

5.4

Interdisciplinaridade durante o processo de desenvolvimento de softwares bibliotecas Diante das dificuldades encontradas na interdisciplinaridade entre para gerenciamento de acervo bibliogrfico de

estes profissionais, podemos nos questionar o que podemos fazer para gerar melhores resultados no processo de desenvolvimento de software com a participao mais efetiva (e produtiva) por parte do usurio final (bibliotecrio). Um ponto importante a conscientizao dos bibliotecrios de que um Software de Gerenciamento de Bibliotecas lhe traro grandes benefcios. O bibliotecrio de antigamente, muitas vezes, ainda no estava interagido com as novas tecnologias e acreditava que seria difcil lidar com estas novidades. Parte desta imagem negativa se deu pelo fato desses profissionais acreditarem que a Informtica pode falhar e no conseguirem recuperar a informao. E por isso, eles se sentiam ameaados quando colocam as tecnologias de algum modo no seu dia a dia. Atualmente, esta rea tem progredido em grandes escalas e as bibliotecas tm acompanhado esse progresso. Na fase de especificao dos requisitos dos softwares, as linguagens de especificaes so conhecidas pelo profissional de TI, mas no pelo bibliotecrio. Isso dificulta a comunicao entre os dois, implicando em uma menor interao entre os dois, o que certamente resultar em especificaes incompletas, imprecisas e incorretas. Umas das alternativas, segundo Simonetto (1999, p.38), seria a utilizao da linguagem natural na especificao dos requisitos, pois esta tem o propsito de permitir que os detalhes abordados no documento sejam compreendidos por ambas as partes,

66 cliente e desenvolvedor. O resultado final desta fase descreveria o sistema do ponto de vista do usurio final. Outro ponto importante de acordo com Simonetto (1999, p.38), que o desenvolvedor de software tem a caracterstica de enxergar o sistema sob o seu ponto de vista. Isto s vezes pode ser um grave problema j que ele no desenvolve o software para ele, e sim para usurios. Por isso seria interessante, o desenvolvedor passar para o outro lado, ou seja, o de ser usurio, que utiliza o sistema para fins operacionais e tomada de deciso. Com esta experincia, o desenvolvedor no desenvolvimento se utilizaria da sua experincia de usurio para chegar mais facilmente a soluo desejada.

CONSIDERAES FINAIS Este Trabalho de Concluso de Curso props mostrar a interao

entre bibliotecrio e analista no processo de desenvolvimento de sistema de informao. No decorrer do trabalho, procurou refletir como o avano tecnolgico tem influenciando profundamente bibliotecas e bibliotecrios. Com a

informatizao dos acervos, as bibliotecas denominadas tradicionais, (cujo acervo constitudo de documentos em formato convencional, isto , em suporte impresso), passaram a ser vistas nesta Era da Informao, como bibliotecas modernas ou automatizadas (onde o computador pea chave para as tarefas mecnicas). Porm, o surgimento da Internet (grande rede mundial de computadores), originou o que denominamos de Biblioteca Virtual, tambm conceituada como biblioteca de realidade virtual, sem paredes, sem estantes, que possibilita disseminar informaes atravs de um computador conectado em rede. A biblioteca vem mudando a sua concepo histrica de depsito de livros para instituio voltada para a disseminao de informaes. Com a evoluo tecnolgica, as bibliotecas permitem atender a demanda de usurios que cada vez mais exigente. Os profissionais da informao so fundamentais para fazer o elo entre os usurios e esse novo paradigma. O trabalho permitiu maior conhecimento de como pode ser desenvolvido um trabalho interdisciplinar entre a Biblioteconomia e a Tecnologia da Informao, o papel do bibliotecrio no desenvolvimento de sistema de informao e quais as consideraes que o bibliotecrio pode ou deve fazer para o desenvolvimento de um sistema (software) de qualidade. Ressaltou que o bibliotecrio exerce papel fundamental nas fases de anlise de requisitos e na fase de teste. Na primeira o bibliotecrio apresenta suas necessidades e na segunda ele avalia se foram satisfeitas atravs do software.

68 Por fim, penso que ns bibliotecrios precisamos procurar uma formao voltada para a rea tecnolgica e interagir com mais atitude no processo de desenvolvimento de sistemas junto ao profissional de TI.

7 7.1

REFERNCIAS Obras citadas

CNDIDO et al. Arquitetura tecnolgica de informaes e suas implicaes na forma de gesto e na competitividade das organizaes. Informao e sociedade: estudos v. 10, n. 1, p. 34-53. jul./dez. 2000. Disponvel em: http://www.ies.ufpb.br/ojs2/index.php/ies/article/view/341/263 Acesso em: 13 nov. 2007 CRTE, Adelaide Ramos e, ALMEIDA, Ida Muniz de, PELLEGRINI, Ana Emlia et al. Automao de bibliotecas e centros de documentao: o processo de avaliao e seleo de softwares. Ci. Inf., , v.28, n.3, p.241-256. set.-dez. 1999. Disponvel em: http://www.scielo.br/pdf/ci/v28n3/v28n3a2.pdf Acesso em: 15 out. 2007 CRUZ, Anamaria da Costa; MENDES, Maria Tereza Reis. A biblioteca: o tcnico e suas tarefas. Niteri: Intertexto, 2000. DZIEKANIAK, Gisele Vasconcelos. Participao do bibliotecrio na criao e planejamento de projetos de softwares: o envolvimento com a tecnologia da informao. Biblios, v.5, n. 17, p. 36-46, enero-marzo. 2004. Disponvel em: http://eprints.rclis.org/archive/00002291/01/2004_008.pdf Acesso em: 6 set. 2007 FERREIRA, Aurlio Buarque de Holanda. Novo dicionrio da lngua portuguesa. 2. ed. rev. e aum. Rio de Janeiro: Nova Fronteira, 1986 FONSECA, Edson Nery da. Introduo biblioteconomia. So Paulo: Pioneira, 1992. GUSMO, Alexandre Oliveira de Meira; MENDES, Almir de Melo. Impacto da automao sobre os funcionrios das bibliotecas da :Universidade Federal de Pernambuco. Informao e sociedade: estudos, Joo Pessoa, v. 10, n. 2, p. 223-242. jl./dez. 2000. LIMA, Gercina ngela Borm. Softwares para automao de bibliotecas e centros de documentao na literatura brasileira at 1998. Ci. Inf, v.28, n.3, p.310-321. set.-dez. 1999. Disponvel em: http://www.scielo.br/pdf/ci/v28n3/v28n3a9.pdf Acesso em: 15 out. 2007 PETERS, James F., Pedrycz, Witold. Engenharia de software: teoria e prtica. Rio de Janeiro: Campus, 2001. PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prtica. 2.ed. So Paulo: Prentice Hall, 2004.

70 PRESSMAN, Roger S. Engenharia de Software. 2.ed. So Paulo: Pearson Makron Books, 2006. _______. _______. So Paulo: Pearson Makron Books, 2002. _______. _______. So Paulo: Pearson Makron Books, 2006. REZENDE, Denis Alcides; ABREU, Aline Frana de. Tecnologias da Informao aplicada a Sistemas de Informao Empresariais: o papel estratgico da Informao e dos Sistemas de Informao nas empresas. 4.ed., rev. e ampl. So Paulo: Atlas, 2006. ROWLEY, Jennifer. A biblioteca eletrnica. Braslia: Briquet de Lemos, 2002. _______. Informtica para bibliotecas. Braslia: Briquet de Lemos, 1994. SILVA, Divina Aparecida da. Auxiliar de bibliotecas: tcnicas e prticas para formao profissional. 4.ed. Braslia: Thesaurus, 2003. SILVA, Roosewelt Lins. Modelo de automao em bibliotecas baseado na Filosofia Open Source: uma anlise social e tecnolgica. So Lus, 2004. Monografia (Graduao em biblioteconomia) Curso de Biblioteconomia, Universidade Federal do Maranho, 2005. SIMONETTO, Eugnio de Oliveira. O usurio final no desenvolvimento de software. Rev. CCEI URCAMP, v.3, n.4, p. 34-39, out. 1999. Disponvel em: http://urcamp.tche.br/site/ccei/revista/numero4.pdf Acesso em: 31 nov. 2007. SOMMERVILLE, Ian. Engenharia de Software. 6.ed. So Paulo: Pearson Addeson Wesley, 2003. STAIR, Ralph, M.; REYNOLDES, George W. Sistemas de informao: uma abordagem gerencial. 4.ed. Rio de Janeiro: LTC, 1999. TONSIG, Srgio Luiz. Engenharia de software: anlise e projeto de sistemas. So Paulo: Futura, 2003.

71 7.2 Obras consultadas

BOGO, Aylton. Desenvolvimento e implantao de um sistema informatizado para bibliotecas Relato de uma experincia prtica. Revista ACB: Biblioteconomia em Santa Catarina, v.2, n.2, p. 45-50 Disponvel em: http://dici.ibict.br/archive/00000894/. Acesso em: 07 nov. 2007. CAF, Lgia; SANTOS, Christophe dos; MACEDO, Flvia. Proposta de um mtodo para escolha de software de automao de bibliotecas. ICincia da Informao, v. 30, n. 2, p. 70-79, 2001. Disponvel em: http://www.ibict.br/cienciadainformacao/include/getdoc.php?id=521&article=232 &mode=pdf Acesso em: 15 out. 2007 CRTE, Adelaide Ramos e. Avaliao de softwares para bibliotecas e arquivos: uma viso do cenrio nacional. 2.ed. rev. e ampl. So Paulo: Polis, 2002. DIAS, Tnia Mara. Pergamum : sistema informatizado da biblioteca da PUC/PR. Ci. Inf v.27, n.3, p. 319-328, set./dez. 1998. Disponvel em: http://www.scielo.br/pdf/ci/v27n3/27n3a10.pdf Acesso em: 07 nov. 2007 FURNIVAL, Ariadne Cholo. A participao dos usurios no desenvolvimento de sistemas de informao. Ci. Inf v.25, n.2, p. 1-14. Disponvel em: http://www.ibict.br/cionline/viewarticle.php?id=478. Acesso em: 04 dez. 2007. MERTINS, Cristiane Fuhrmann. Desenvolvimento e gesto de requisitos de software: (Uma proposta de metodologia baseada no CMMI). Monografia (Graduao em Informtica - Habilitao em Anlise de Sistemas) Curso de Cincias Exatas e Tecnolgicas. Universidade do Vale do Rio dos Sinos UNISINOS. So Leopoldo, 2004. Disponvel em: http://www.inf.unisinos.br/alunos/arquivos/TC_Cristiane_Mertins.pdf Acesso em: 04 dez. 2007. PAULA FILHO, Wilson de Pdua. Engenharia de software: fundamentos, mtodos e padres. 2. ed. Rio de Janeiro: Livros Tcnicos e Cientficos Editora S. A., 2003. POMPILHO, S. Anlise essencial: guia prtico de anlise de sistemas. Rio de Janeiro: Cincia Moderna, 2002. REZENDE, Denis Alcides. Engenharia de software e informao. 3.ed. Rio de Janeiro: Brasport, 2005. sistema de

REZENDE, Denis Alcides; ABREU, Aline Frana de. Tecnologia da informao aplicada a sistemas de informao empresariais: o papel estratgico da informao e dos sistemas de informao nas empresas. 4. ed. rev. e ampl. So Paulo: Atlas, 2006.

72 VALENTIM, Marta Lgia Pomim. O moderno profissional da informao: formao e perspectiva profissional. Enc. Bibli: R. Bibliotecon. Ci.Inf., Florianpolis, n.9, jun.2000. Disponvel em: http://www.encontrosbibli.ufsc.br/regular.html Acesso em: 08 dez. 2007. MARCONDES, Carlos Herique. Automao das funes de biblioteca e pacotes de software: caractersticas e vocaes. R. Esc. Biblioteconomia UFMG. v.23, n.1, p.65-77, jan.-jun.1994.