Capítulo 3 — análise de requisitos de software


O objetivo desse capítulo é permitir a localização dos conceitos de análise de requisitos de software e, principalmente, sobre análise de requisitos de softwares que prestam-se como apoio aos sistemas de informações gerenciais.

3.1 - Um breve histórico sobre desenvolvimento de softwares

Desde que o computador foi formalmente reconhecido como útil para o processamento de dados em organizações sociais, até meados da década de 70, o fator mais crítico era a sua baixa capacidade tanto na armazenagem quanto no processamento desses dados. A palavra de ordem entre os desenvolvedores de software era "eficiência dos programas" para que os resultados pudessem ser obtidos em tempo hábil. Havia na época uma dependência muito forte das organizações aos indivíduos que desenvolviam o software, uma vez que, por causa das artimanhas de programação (muitas vezes necessárias por causa da pouca disponibilidade de "memória" dos computadores), somente o próprio autor de um programa seria capaz de manuteni-lo e muitas vezes nem ele próprio.

Em meados da década de 60 (1966 com Wirth, Hoare, Böhm e Jacopini) o mundo da informática começava a viver uma de suas fases mais ricas em termos de produção de idéias para a formalização do desenvolvimento de software. O problema de hardware ainda permanecia, mas já vislumbrava-se um horizonte bastante promissor nessa área e muitos pensadores do meio acadêmico começaram a estabelecer uma nova ordem para o desenvolvimento de sistemas para computador. Nessa época começaram a ser lançados os fundamentos da programação estruturada que passaria a basear-se em três estruturas básicas de controle: a seqüência, a seleção e a repetição (inicialmente foram somente duas essas estruturas básicas). Em 1968 Edsger W. Dijkstra publicou um artigo intitulado "Go To Statement Considered Harmful" onde ele procurou argumentar sobre o uso indevido do comando "Go To" e as suas implicações. Esse artigo (publicado na edição de março de 1968 do periódico "Communications of the ACM") acabou por traduzir-se como a própria definição da programação estruturada no meio vulgar. Programação estruturada passou a ser encarada, de certa forma, como a programação sem o uso do comando "Go To".

A partir da década de 70 a palavra "estruturação" começou a ser empregada, difundida e expandida a outras fases do desenvolvimento de sistemas, não permanecendo, portanto, restrita somente à programação. As diversas fases do desenvolvimento de sistemas começaram a ser observadas do ponto de vista das estruturas de controle. Em 1972 D. L. Parnas publicou um artigo (Communications of the ACM) intitulado "On the Criteria to Be Used in Decomposing Systems into Modules" (sobre os critérios a serem usados na decomposição de sistemas em módulos). Esse artigo é uma evidência de que uma nova forma de se encarar os sistemas estava sendo empregada, a partir da formalização de critérios para a sua decomposição. Esses critérios foram utilizados dois anos depois (em 1974) por Stevens, Myers e Constantine numa publicação do "IBM Systems Journal" intitulada "Structured Design" (projeto estruturado). A partir daí os projetos de programas ganharam novos componentes e a estrutura básica de controle entre os módulos passou a ser a hierárquica. O objetivo final era a obtenção de um conjunto de unidades básicas, chamadas de "módulos funcionalmente coesos". A expressão "estruturado" passou a fazer parte, agora, também da etapa de projeto de um sistema. Conforme [Stevens,1988], dois benefícios principais eram esperados através desse modelo: a capacidade de manutenção tanto para implementar novas exigências quanto para recuperar um erro e a reutilização de módulos, do qual derivaria o benefício da redução no tempo para o desenvolvimento de programas futuros. Nas palavras de [Stevens,1988,p.223]: "Não há técnica de desenvolvimento que habilite uma pessoa a escrever e depurar um código mais rápido do que obter um código já existente". Serão feitas algumas considerações sobre esse comentário mais adiante, ainda nessa seção.

Em 1979 Tom DeMarco escreveu um livro "Structured Analysis and System Specification" (análise estruturada e especificação de sistemas) onde são formalizados alguns princípios e estabelecidas algumas técnicas que introduzem a atividade de análise de sistemas na "era estruturada". Nessa mesma época outros estudiosos do assunto, como Gane e Sarson, desenvolveram pesquisas e chegaram a conclusões que mais tarde se somariam às de Tom DeMarco. O modelo que caracterizava, por excelência, a análise estruturada era o "Diagrama de Fluxo de Dados" (DFD). Esse diagrama passou a representar em forma de rede os processos de um sistema e o fluxo dos dados dos processos entre si e com as entidades externas ao sistema.

O próprio gerenciamento de um projeto foi incluído entre as "coisas" estruturadas, em 1988 por Edward Yourdon, que escreveu um livro intitulado "Managing de System Life Cycle" (administrando o ciclo de vida do sistema). Nesse âmbito (do gerenciamento de projetos), estruturação passou a designar o paralelismo das atividades de planejamento e de controle dos projetos.

Paralelamente a essa "revolução estruturada" (ou revolução da decomposição funcional) estavam sendo desenvolvidas pesquisas por uma outra dimensão dos sistemas para computador. Pensadores como Hoare, Codd, Bachman e Chen defendiam a idéia de que a saída para a melhoria na qualidade dos sistemas começava com a modelagem da informação. Esse processo (conhecido em alguns meios como Engenharia da Informação) teve um impulso bastante significativo na década de 70 com a formalização na IBM de uma linguagem conhecida como SQL (Structured Query Language — linguagem estruturada, para consulta) para manipulação de bancos de dados e em 1976 com a publicação por Peter Chen de um artigo intitulado "The Entity-Relationship Model, Toward a Unified View of Data" (o modelo entidade-relacionamento, rumo a uma visão unificada dos dados — Communications of the ACM), formalizando um modelo que representa a "malha de memória" do sistema.

Havia, ainda, uma terceira espécie de sistemas, cuja implementação era derivada de um modelo de análise diferente dos modelos funcional e da informação: tratavam-se dos softwares baseados nos modelos de estado orientados para circuitos digitais (conforme [DeMarco,1989]). O método de estados de dispositivos e transição entre estados, ganhou impulso entre as organizações que desenvolvem os chamados "softwares embarcados" em máquinas, elevadores, automóveis, aeronaves, etc., e são conhecidos, também, como "sistemas em tempo real" (sistemas operacionais e para controle de dispositivos).

A diferença fundamental entre os três modelos (o funcional, o da informação e o de estados) está na perspectiva inicial da análise e do projeto:

    a) funcional: parte da decomposição dos processos (funções) da organização em estudo, para daí serem derivadas as estruturas de dados necessárias para o estabelecimento do sincronismo entre essas funções;
    b) da informação: inicia o processo de análise identificando-se o modelo conceitual de dados (modelo que representa a visão dos usuários sobre as informações necessárias), que é decomposto nos conjuntos de dados do software (utilizando-se uma técnica conhecida como "normalização") e, a partir desses conjuntos de dados, são implementadas as operações que aplicam-se sobre eles;
    c) de estados: inicia o processo de análise na identificação dos possíveis estados que um determinado dispositivo pode assumir (aberto, fechado, ligado, etc.) para, daí, serem obtidos os processos que levariam esses dispositivos de um estado para outro e os eventos que fariam com que esses processos fossem disparados.
Em 1982, Tom DeMarco juntou essas três visões sobre sistemas. A idéia era a de representar os sistemas em perspectivas (ou em três dimensões) e isso trouxe um novo fôlego às técnicas e ferramentas criadas até então. Ao invés dos defensores de cada idéia competirem entre si, teve início um movimento de coesão de conhecimentos, que serve como base às ferramentas e metodologias atuais. Durante a década de 80 e no início da década de 90, esses conceitos foram ampliados (vide, por exemplo, [McMenamim,1984], [Ward,1987] e [Yourdon,1990]). Entretanto as dificuldades na manutenção dos modelos que eram gerados nas diversas fases do desenvolvimento e a falta de cultura com os modelos assíncronos malogrou a sua popularização, principalmente nas atividades de análise e projeto do sistema pela perspectiva das funções. Se o objetivo era o reaproveitamento máximo de funções já desenvolvidas (vide o comentário de [Stevens,1988] sobre "obter um código já existente", anteriormente), isso, apesar de teoricamente fundamentado, não mostrou-se muito produtivo, até mesmo quando da aplicação desses modelos em projetos considerados pequenos (com três ou quatro centenas de pontos de funções) pela dificuldade apresentada na localização de uma função específica (estima-se que os softwares de gestão empresarial de mercado tenham entre 50.000 e 150.000 pontos de função). Assim, uma forma mais eficiente de estruturação dessas funções mostrou-se necessária. Atualmente, essa forma tem sido apresentada como um conjunto de técnicas e disciplinas denominadas de "orientação por objetos".

Conforme [Coad,1992,p.4], "a programação baseada em objetos foi discutida pela primeira vez no final dos anos sessenta por aqueles que trabalhavam com a linguagem SIMULA. Nos anos setenta, ela era uma parte importante da linguagem Smaltalk desenvolvida na Xerox PARC". O conjunto total das técnicas orientadas para objetos tinham por objetivo, inicialmente, "auxiliar no gerenciamento da complexidade de grandes softwares de tempo real " [Booch,1986].

No início da década de 80, as previsões sobre as técnicas orientadas para objetos eram de que elas estariam para os anos 80 o que a programação estruturada representou para a década de 70 (T. Rensch 1982, apud [Booch,1986]) ("an passant", a diferença fundamental entre as técnicas estruturadas e as orientadas para objetos está na forma de decomposição das operações a serem executadas pelo software. Uma fundamenta-se na decomposição das funções dentro de uma unidade estruturada hierarquicamente, que é o programa, e outra baseia-se na distribuição das funções por objetos e classes de objetos, sobre os quais essas funções podem ser aplicadas). Isso de fato foi assim, mas não somente a programação orientada para objetos seguiu os passos da programação estruturada, do ponto de vista das semelhanças nas pesquisas sobre técnicas e na produção de software. Da mesma forma como a "estruturação" transformou-se num paradigma, afetando os processos de projeto, análise e gerenciamento do desenvolvimento de software, os "objetos" têm se transformado num paradigma desses mesmos processos. Entretanto, a aplicação desses princípios como uma panacéia, para todos os males relativos ao desenvolvimento de software (assim como foi a "estruturação"), independentemente do alerta de [Booch,1986]: "devemos chamar atenção sobre o fato de que o desenvolvimento orientado para objetos é um método que atinge o ciclo de vida apenas parcialmente. Ele está focado sobre os estágios de projeto e implementação, no desenvolvimento de software ... é imprescindível o acoplamento de métodos apropriados de requisitos e análise, ao desenvolvimento orientado para objetos" (grifos acrescentados), pode desviar ainda mais a atenção dos que buscam uma solução para o controle de projetos de software, a uma direção que pode não ser a mais adequada, hajam vistas, por exemplo, a um relatório da KPMG, divulgado em abril de 1997 (apud [Poulin,1998]). Nesse relatório dá-se contas de que:

Assim, se por um lado a evolução do conjunto de todas as técnicas permitiu uma melhoria na qualidade intrínseca dos produtos de software (por causa da evolução das técnicas e ferramentas de projeto e programação), por outro os problemas relacionados ao controle sobre os projetos de software e à aplicação desses softwares permaneceu.

Considerando-se estritamente os problemas relacionados à adequação do software às necessidades dos usuários, duas hipóteses poderiam ser estabelecidas: ou os requisitos dos usuários não são completa e adequadamente coletados, ou esses requisitos são distorcidos ao longo do ciclo de desenvolvimento do software. Para que isso seja melhor compreendido, será apresentado, a seguir, o ciclo de vida de desenvolvimento de um software, seguido das questões relativas à análise dos requisitos de software propriamente.

3.2 - Ciclo de vida do desenvolvimento de software

Na fig.3.2.a é representado um exemplo de ciclo de vida para desenvolvimento de um software. Como pode ser observado, os seguintes processos fazem parte desse ciclo:

fig.3.2.a — modelo de ciclo de vida para o desenvolvimento de software

3.3 - Compreendendo os requisitos dos usuários de software

Afinal, o que são requisitos de software? — Segundo [Dean,1994], "é qualquer coisa que restringe o sistema" e, conforme uma publicação do Software Productivity Consortium Inc. (S.P.C.I.), "Os requisitos definem o problema. Eles lhe dizem o que o software deverá fazer. Os demais passos do processo tradicional de desenvolvimento de software criam a solução" [SPCI,1996].

E qual seria o objetivo da análise de requisitos de software? — Conforme Leite (1987, apud [Zirbes,1996] ) "a Análise de Requisitos é um processo, onde o que deve ser feito é eliciado (expulsar, fazer sair) e modelado. Este processo envolve-se com diferentes visões e utiliza uma combinação de métodos, ferramentas e atores. O produto deste processo é um modelo, a partir do qual um documento denominado Requisitos do Sistema é produzido", para [Thayer,1996] engenharia de requisitos de software é a disciplina usada para capturar correta e completamente os requisitos de software e expectativas dos usuários do software e as técnicas e disciplinas da engenharia de requisitos de software têm como objetivo a elicitação de requisitos do macrossistema, para [Breitman,1998].

É importante salientar-se, para que não haja confusão de terminologias, que na bibliografia pesquisada, os termos "engenharia de requisitos" e "análise de requisitos" foram encontrados referindo-se ao mesmo conjunto geral de atividades e objetivos, indistintamente (isso pode ser verificado observando-se as referências citadas acima), ou seja, os objetivos entre as atividades da "engenharia de requisitos" e as da "análise de requisitos" são semelhantes. Para os efeitos desse trabalho optou-se pelo termo "análise de requisitos".

Assim, do que trata-se em análise de requisitos de software de informações? — Precisamente da identificação das necessidades dos usuários de informações e comunicação dessas necessidades aos processos de construção do software (projeto e produção).

3.3.1 - Conseqüências de erros na fase de análise dos requisitos de software

Como pode ser observado na fig.3.2.a, o processo de "Análise dos Requisitos de Usuários" é responsável pela identificação dos objetivos a serem atingidos pelo software. Os erros cometidos nessa fase serão transmitidos para as fases de projeto e produção do software na forma de requisitos inconsistentes. A estrutura do software, que é determinada na fase de projeto, pode ficar comprometida na medida em que os requisitos técnicos não forem consistentes. Para [Bender,1997], definir os requisitos é o primeiro, e mais crítico, passo em desenvolvimento de sistemas de software. Se a definição dos requisitos é pobre, o projeto resultante é desajeitado.

Segundo o S.P.C.I., "o impacto, se você não identificar um erro na fase de análise de requisitos e projeto do software, será de um custo 4x maior para eliminar esse erro na fase de testes e 100x maior para eliminá-lo na fase de manutenção do software" (vide fig.3.3.1.a) e "de fato, requisitos de software são o passo mais importante no processo ... e são conhecidos como o principal problema da indústria de software" [SPCI,1996]. [Thayer,1996] afirma que as especificações de requisitos incorretas ou incompletas, são a maior causa de erros de software.

fig.3.3.1.a — custo relativo para eliminar problemas (conforme a etapa)

Uma expressão de John Von Neumann, apud [Gause,1991,p.249], pode ser perfeitamente aplicada nesse ponto: "não faz sentido ser exato em relação a algo se você nem mesmo sabe o contexto do que está falando", resumindo a incoerência das soluções perfeitas para problemas irreais.

3.3.2 - Histórico de desenvolvimento e estágio atual sobre requisitos de software

Em 1980, Edward Yourdon, prefaciando o livro "The Practical Guide to Structured Systems Design" de Meilir Page-Jones [Jones,1980], escreveu o seguinte:

O projeto estruturado preocupa-se com a seleção e organização de módulos e suas interligações, de modo a conseguir a melhor solução para um problema bem formulado. Mas de onde vem essa boa formulação de problema? Como podemos ter certeza de que as necessidades do usuário foram apropriadamente especificadas? ... Infelizmente essas questões foram um tanto ignoradas ... Assim, a "ponte" entre a análise e o projeto tem sido motivo de confusão e trauma para muitos profissionais de processamento de dados. Pelas evidências nesse texto, sabe-se que já em 1980 havia sido identificado o problema da qualificação dos requisitos de software, tanto na sua interpretação (problema bem formulado) quanto na sua comunicação para a fase de projeto do software (ponte entre a análise e o projeto). O mesmo Edward Yourdon escreveu em 1990, em parceria com Peter Coad, um dos principais "best-sellers" atuais sobre análise de sistemas. Trata-se do livro "Object-Oriented Analysis". Nesse livro eles reafirmam o problema de uma década anterior, dizendo: "A transição da análise para o projeto tem sido uma fonte constante de frustração. Muitos trabalhos foram escritos; muito pouco progresso foi alcançado" [Coad,1992,p.23]. A intenção desse novo livro era a de resolver o problema e o desfecho parecia resumir-se a uma simples questão de uniformização na representação dos resultados das modelagens do problema (análise) e da solução (projeto). Como foi afirmado "Tudo é uma questão de usar a mesma representação básica na análise e no projeto" [Coad,1992,p.23]. As evidências, entretanto, indicam que esse problema permanece ainda hoje. Essas evidências são tanto pelas pesquisas que são desenvolvidas sobre o assunto, por exemplo: quanto pelos resultados das estatísticas que são realizadas sobre o assunto. Além do resultado apresentado anteriormente, do relatório da KPMG, pode ser citado como outro exemplo, o resultado de uma pesquisa de Alan Daves (apud [Rocha,1998]), onde é constatado que: 56% de todos os erros encontrados nos softwares são originados na fase de análise de requisitos e 75% desses erros são detectados somente depois das etapas de implementação e teste, ou seja, 42% dos erros são percebidos somente pelos usuários, por ocasião da implantação ou uso do software (só para relembrar, a pesquisa da KPMG chegou a um percentual de 45% de inadequação no uso). Segundo essa pesquisa, os erros de requisitos são distribuídos da seguinte forma: 3.3.2.1 — Qual é o "estado da prática", no Brasil?

Em meados de 1996, o Ministério da Ciência e da Tecnologia (MCT) publicou uma pesquisa intitulada "Qualidade no Setor de Software Brasileiro - 1995" [MCT,1996]. Entre as questões analisadas na pesquisa, uma versava sobre técnicas de engenharia de software adotada e, entre as técnicas, uma referia-se à análise de requisitos. Das empresas que responderam ao questionário, apenas 47,4% disseram fazer uso dessas técnicas.

Em agosto de 1998 foi divulgado um novo relatório, dessa vez de uma pesquisa referente ao ano de 1997, nos mesmos moldes da pesquisa feita em 1995. Nessa nova pesquisa, apenas 35,5% disseram fazer uso das técnicas de análise de requisitos [MCT,1998]. Presumindo-se que as respostas ao questionário do MCT foram totalmente fiéis e levando-se em conta a margem de erro , cerca de 37% das empresas brasileiras produtoras de software, em 1997, ainda não utilizavam um método formal de análise de requisitos e, por conseqüência, também não utilizavam nenhum método formal para a transição entre o processo de análise dos requisitos e o processo de projeto do software.

3.4 - Alguns métodos populares para análise de requisitos

Serão apresentados, a seguir, alguns dos principais modelos de análise de requisitos para sistemas de informações, que têm sido apresentados ao mundo, pelas últimas três décadas.

3.4.1 — Análise Estruturada de Sistemas

O modelo de análise estruturada foi formalizado na década de 70 e popularizado principalmente por [GANE,1983] e [DeMARCO,1989]. Fundamentada no princípio da decomposição funcional, ele tem como objetivo a modelagem da organização em estudo utilizando-se, para esse fim, de um conjunto de ferramentas, sendo o Diagrama de Fluxo de Dados (DFD) e o Dicionário de Dados (DD) as principais delas.

O método de decomposição recomendado, conforme [DeMARCO,1989], é baseado na busca pela menor taxa de transferência de dados entre os sub-processos dos processos que estão sendo analisados, o que levaria, por conseqüência, a um modelo da organização decomposta em módulos funcionalmente coesos, ou seja, módulos que têm uma única função.

A principal crítica à análise estruturada é a não replicabilidade dos requisitos resultantes da análise, caso fosse feito um experimento em que diversos analistas fossem incumbidos de analisarem o mesmo sistema. Isso porque o processo de decomposição utilizado depende da abordagem de cada analista particularmente (dos seus pressupostos e de suas experiências anteriores ao projeto em questão) e das coincidências de informações oriundas das pessoas que compõem a organização social sob análise.

3.4.2 — Análise Essencial de Sistemas

Definida em 1984 por Stephen M. McMenamim e John F. Palmer ([McMenamim,1984]) a abordagem da análise essencial de sistemas utiliza-se das mesmas ferramentas de modelagem da análise estruturada, mas os mecanismos são diferentes. Ao invés de uma decomposição do mais geral para o mais específico ("top-down") o método prevê que sejam identificados, inicialmente, os eventos externos aos quais espera-se que a organização social em questão responda, sendo derivadas então as ações (ou funcões) em resposta a esses eventos e, posteriormente, os eventos gerados internamente e também as respectivas ações. A expressão "essencial" deve-se ao fato de que não serão consideradas quaisquer restrições tecnológicas, ou seja, como se a tecnologia disponível fosse perfeita o suficiente para suportar quaisquer questões relacionadas à captura ou mixagem dos dados, permitindo que seja possível concentrar-se somente sobre as questões essenciais do sistema sob análise.

3.4.3 — Engenharia da Informação

Os conceitos fundamentais da engenharia da Informação foram estabelecidos em 1981 por James Martin e Clive Finkelstein e, para Martin (apud [Neto,1988,p.2]), "A Engenharia da Informação é um conjunto integrado de técnicas formais pelas quais modelos de empresa, modelos de dados e modelos de processos são construídos a partir de uma base de conhecimentos de grande alcance, para criar e manter sistemas de processamento de dados".

O modelo da engenharia da informação é mais abrangente que os de análise estruturada e essencial, apresentados anteriormente, abrangendo, além das atividades de análise, as atividades de projeto e implementação do software. A análise propriamente está presente em duas das fases desse modelo: a fase do planejamento estratégico da informação e a fase da análise das áreas de negócios da empresa.

O planejamento estratégico da informação é responsável pela identificação das informações necessárias à consecução dos objetivos estabelecidos no planejamento estratégico empresarial. Nesse sentido, a engenharia da informação leva vantagens, quando comparado aos outros modelos de análise (como as estruturada e essencial), na medida em que possui como ponto de partida um conjunto bem definido de objetivos organizacionais, não limitando-se apenas à automação de operações burocráticas, que podem nem estar contribuindo para os objetivos da empresa. Também é responsável pelo desenvolvimento do modelo corporativo de dados (que, mixados, geram as informações táticas e estratégicas) e do modelo funcional da organização sob análise.

A análise das áreas de negócios refere-se à decomposição do modelo corporativo de dados em dados operacionais e à decomposição funcional dos setores da organização que respondem diretamente pelos resultados esperados e que geram os dados necessários à estratégia empresarial estabelecida. Aparte do quesito da decomposição do modelo de dados corporativos, o modelo a ser adotado para a decomposição funcional não é definido de forma diferenciada das técnicas existentes, podendo optar-se por uma técnica como a análise estruturada, por exemplo. Nesse sentido, a engenharia da informação torna-se como que um arcabouço, dentro do qual os modelos de análise funcional encontram uma forma mais definida (por causa das restrições estratégicas) de aplicação, tornando os seus resultados menos aleatórios.

3.4.4 — Análise de requisitos baseada em Protótipos

Existem métodos de requisitos conhecidos como "métodos de protótipos", que tentam cumprir o papel de antecipar a evidenciação de erros de requisitos, para antes da implementação do software numa linguagem alvo (conforme [Gane,1988]).

Segundo [Yourdon,1989], esses métodos podem ser aplicados a projetos considerados "bons candidatos", tendo como característica principal o fato de resultarem em softwares essencialmente "on-line" (em-linha), quer-se dizer, softwares que não têm processamentos em lote, como cálculos de necessidades de materiais, atualizações integradas de recepção de materiais, etc.. Isso ocorre porque esses métodos conseguem representar apenas a parte do software com a qual o usuário terá contato direto e isso pode garantir a qualidade do ponto de vista da adequação (caso a hipótese do cliente venha a confirmar-se), mas não da funcionalidade.

A principal crítica aos métodos de protótipo, quando foram criados, era o fato de que os requisitos dos clientes não eram documentados e, pelo fato de as linguagens de prototipação serem apenas linguagens de simulação (não serem linguagens de programação propriamente), quando definitivamente chegava o momento do software ser programado, os requisitos haviam se degenerado, restando apenas o desenho de telas e relatórios. Esse aspecto desmotivou o uso de protótipos, no início. Entretanto, na primeira metade da década de 1990 começaram a ser implementadas ferramentas de desenvolvimento de software baseadas naquilo que comercialmente ficou conhecido como RAD ("Rapid Aplication Development" — Desenvolvimento Rápido de Aplicativos), buscando-se a redução dessa deficiência, uma vez que a linguagem de protótipos passou a ser a própria linguagem de programação definitiva.

Atualmente a tecnologia RAD tem sido amplamente divulgada e aplicada (exemplos de linguagens que utilizam essa tecnologia são a "Delphi" e a "C++Builder", ambas da empresa Inprise (antiga Borland)) e o que tem-se observado é que, para softwares com meia dúzia de funções, um modelo de análise de requisitos baseado em protótipos e em tecnologia RAD é útil, desde que o projeto seja, nas palavras de [Yourdon,1989], um "bom candidato". Entretanto, se por um lado o modelo resultante desses métodos, suportados pela tecnologia RAD, elimina a necessidade de os requisitos serem formalmente documentados, foi criado um novo problema que é a dificuldade na manutenção do software. Conforme [Yourdon,1989,p.64]:

Se o protótipo é na verdade jogado fora e substituído pelo sistema de produção, há um perigo real de que o protótipo possa acabar sem haver um registro permanente dos requisitos do usuário. Isso provavelmente tornará a manutenção e modificação cada vez mais difícil com o passar do tempo (dez anos após o sistema ser montado, será difícil para os programadores de manutenção incorporarem uma mudança, pois ninguém, incluindo os usuários de "segunda-geração" que agora trabalham com o sistema, se lembrará do que ele pretendia fazer a princípio). 3.4.5 — Análise Orientada a Objetos

Um dos primeiros livros sobre análise orientada para objetos foi escrito por Sally Shlaer e Stephen J. Mellor, em 1988 (traduzido para o português em 1990, conforme [Shlaer,1990]) e trata-se de uma abordagem de análise "interessante" do ponto de vista científico, na medida em que por um lado não é uma técnica de análise, no sentido restrito da decomposição que busca aprender alguma coisa, e por outro lado vem transformando-se em fenômeno de um mercado ansioso por técnicas que lhe dêem uma solução na captura de requisitos, principalmente para o desenvolvimento de aplicações de gerenciamento e gestão. Sobre essas aplicações (como é o caso dos ERP’s) [Furlan,1998,p.4] fala que "Esses softwares em si são um grande alvo da tecnologia de objetos uma vez que a modularização em nível de componentes em lugar da modularização em nível de subsistemas pode proporcionar um ajuste mais adequado na implementação do produto nas empresas clientes". O grifo em "implementação" foi acrescentado para demonstrar que o texto deixa transparecer que esse autor concorda que as ferramentas da orientação a objetos aplicam-se às atividades de "implementação", ou seja, nas atividades que seguem o processo de análise de requisitos (projeto e produção do software), como na concepção original de [Booch,1986], apresentada anteriormente. Entretanto, a que deve-se a afirmação, na mesma publicação de [Furlan,1998,p.12], de que "Um aspecto importante da teoria dos objetos é a sua característica intrínseca de analisar o mundo como ele é, permitindo organizar resultados de maneira mais fácil e natural" (grifo acrescentado) e por que, para autores como Rumbaugh (apud [Furlan,1998,p.15]), a orientação a objetos é "uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos do mundo real"? (grifo acrescentado). Ao longo da presente pesquisa observou-se que o termo "análise de sistemas", em alguns casos (possivelmente aplicável a [Furlan,1998,p.12]) também representa as atividades relacionadas ao projeto do software. Entretanto, quando relacionado à orientação aos objetos, aparentemente, essa questão torna-se crônica. Observe-se o comentário de [Hay,1998]:

As livrarias em todo o mundo estão cheias de livros concernentes à "análise orientada para objetos". Será possível que o mundo da "orientação para objetos" mudou completamente a natureza da análise de sistemas? Se dermos ouvidos aos seus aficcionados, isto deverá ser aceito como verdadeiro ... entretanto Grady Booch afirma que a análise deverá focar o ambiente, não a forma ... ele afirma que a análise orientada para objetos trata, na verdade, sobre projeto de sistemas. E como explicar o comentário de [Furlan,1998,p.98]? Diz ele: "A criação de um modelo de objetos é, freqüentemente, resultado da consolidação de diversos projetos de escopo funcional. Criar modelos é um trabalho altamente criativo, e não há uma solução final ou uma resposta correta que possa ser verificada ao final do trabalho" (os grifos foram acrescentados). Partindo-se do pressuposto desse ponto de vista, o presente trabalho não teria mais razão de ser. De qualquer forma, para que essa questão possa ser melhor compreendida, passemos a observá-la sob a luz de [Shlaer,1990,p.6]: Muitos projetos produzem, como seu primeiro produto importante, uma relação formal dos requerimentos do sistema. Os requerimentos são revistos então por um comitê de especialistas dos vários departamentos da organização. Todavia, devido ao fato de a relação dos requerimentos conter material de tantas áreas diferentes, cada membro do comitê se julga responsável pela qualidade de somente uma parte das especificações. A responsabilidade de entender a relação em seu todo e em profundidade, juntamente com todas as hipóteses e conceituação em que se baseia, tipicamente não cabe a ninguém. Como resultado, é quase inevitável que o documento dos requerimentos seja considerado mais tarde incompleto e/ou incongruente. É provável que, assim que estas falhas começarem a surgir, a credibilidade dos requerimentos fique tão prejudicada que o documento chegue a não ser levado em conta pelos que desenvolvem o sistema. O trabalho em que isto acontecer terá pouca serventia e, mais adiante: Em nossa opinião, é conveniente iniciar o projeto de desenvolvimento do software com a construção de um modelo de informação do problema da aplicação. Depois disso, quando apropriado para o problema, podem ser aplicados os outros passos da análise (diagrama de fluxo de dados, diagramas de transição de estados, trabalhos de requerimentos formais e similares) (grifo acrescentado). O que deve ser observado é que pressuposto fundamental da teoria de objetos, sobre a qual está fundamentado [Shlaer,1990] e [Furlan,1998], está em que, modeladas as informações dos objetos que fazem parte do ambiente do problema em estudo, todas as respostas, relacionadas ao problema, ficarão naturalmente disponíveis. Aparentemente isso faz sentido, entretanto não se pode deixar de dar atenção ao alerta de [Senge,1990,p.70]: "... existe uma característica fundamental dos sistemas humanos complexos: causa e efeito não estão próximos no tempo e no espaço". Diante disso, não é coerente presumir-se que é possível a modelagem das informações do ambiente do problema (onde normalmente os efeitos são evidentes), sem conhecer-se as causas do problema, causas essas que delimitam a verdadeira extensão do ambiente do problema, que podem ir além das fronteiras físicas da organização social sob análise. A questão das dificuldades com os documentos de requerimentos, apresentada em [Shlaer,1990] é bem real, entretanto a modelagem dos objetos do presumível ambiente do problema não é suficiente. Para [Senge,1990,p.79] "A verdadeira alavancagem na maioria dos problemas administrativos está em entender a complexidade de dinâmica, e não a complexidade de detalhes. Infelizmente as "análises de sistemas" enfocam quase sempre a complexidade de detalhes", podendo essa complexidade de detalhes ser ilustrada, justamente, pelo resultado de um modelo de análise orientado para objetos: a decomposição da organização por objetos, ao invés da decomposição pelas relações dinâmicas, que ocorrem nos eventos entre os elementos dentro dessa organização e fora dela, com outras organizações com as quais ela relaciona-se.

Observando-se a comentário de [Furlan,1998, pag.7]: "A tarefa mais difícil é a de modelar os processos existentes sem a interferência das pessoas, organogramas e cultura estabelecida" tem-se uma noção do porquê que os analistas de sistemas têm tantas dificuldades para identificar o essencial no estudo para o desenvolvimento dos sistemas de informação: a ausência de foco no relacionamento, buscando estudar as organizações sociais "sem a interferência das pessoas ... e culturas estabelecidas", como se isso fosse possível, uma vez que os sistemas sociais não possuem uma anatomia, ou uma estrutura aparte de seu funcionamento, conforme foi visto anteriormente a partir de [Katz,1974], o que, naturalmente, pressupõe a presença das pessoas com suas culturas. O que não se pode fazer é esquecer-se que os modelos de objetos nasceram para a análise e implementação de sistemas embarcados, que controlam realmente objetos como máquinas de fotocópia, aviões, barbeadores, etc., e que possuem uma anatomia bem definida, independente da interferência de variáveis sociais.

3.5 - CONCLUSÃO DO CAPÍTULO

Nesse capítulo foram apresentados alguns modelos de análise de requisitos e os problemas que esses modelos têm enfrentado, tanto problemas objetivos (como as conseqüências de uma análise mal feita) quanto problemas inerentes aos modelos propriamente. No próximo capítulo será apresentada uma proposta que busca atingir justamente esses dois focos (que complementam-se entre si): reduzir os problemas dos modelos atuais de análise e, por conseqüência, minimizar os problemas com sistemas de informações nas organizações sociais.