Modelagem de Sistemas de Informacao - Janeiro 2007

8/18/2019 Modelagem de Sistemas de Informacao - Janeiro 2007

1/312

Modelagem deSistemas deInformação Da análise de requisitos aomodelo de interface

Geraldo Xexéo

Edição Jan/2007


2/312

1

Modelagem de Sistemas de Informação: Da Análise de Requisitos ao Modelo deInterface

Geraldo Xexéo.Versão Jan/2007Copyright © 2006,2007 Geraldo Xexéo.

Este documento está licenciado sob a Creative CommonsAtribuição - Uso Não-Comercial - Não a obras derivadas 2.0 Brasil.Para ver uma cópia dessa licença visite• http://creativecommons.org/licenses/by-nc-nd/2.0/br/

ou envie uma carta a Creative Commons, 543 Howard Street, 5th Floor,San Francisco, California, 94105, USA.

Todo o esforço foi feito para fornecer a mais completa e adequada informação.Contudo, o autor não assume responsabilidade pelos resultados e uso da informaçãofornecida.

e-mail de contato:[email protected]

A versão mais atualizada desse livro, e ainda material deapoio ao ensino, pode ser obtida em:http://ge.cos.ufrj.br


3/312

2

Capítulo I. Introdução

Este livro é sobre a Modelagem de Sistemas de Informação seguindo umaforma bastante atualizada da Análise Essencial, unificada com outros métodosimportantes no dia a dia do desenvolvedor de software, como o Modelo de Entidadese Relacionamentos.

Ele é fruto da experiência de 12 anos ensinando Análise de Sistemas paragraduação, primeiro na Universidade Estácio de Sá e depois na Universidade Federaldo Rio de Janeiro, já como professor Adjunto. O texto foi criado, alterado, cortado eaumentado de forma a atender as necessidades do curso, do mercado e dos alunos.Muito do conteúdo aqui apresentado é resultado direto de dúvidas e dos erros maiscomuns que os alunos apresentaram. A matéria também é resultado de 15 anos deatuação como consultor, envolvido direta ou indiretamente na análise eimplementação de sistemas em diferentes projetos, sobre temas variados comoadministração pública, gerência de satélites e controle de frota.

O livro foi construído com dois propósitos. O primeiro é apoiar um primeirocurso de modelagem de sistemas de informação, fundamentado na análise essencial,no nível de graduação ou extensão, visando formar um analista de sistemas. Osegundo é fornecer uma base de sustentação para o analista no seu dia a dia notrabalho. Não apresentamos um método único de análise ou especificação de sistemas,mas sim um conjunto de ferramentas, oulinguagens, que podem ser usadas tanto emconjunto como em separado, porém baseadas em uma filosofia comum. Este livro nãotrata de modelagem orientada a objeto, que é normalmente assunto de um segundocurso de modelagem de sistemas.

Algumas premissas foram importantes na construção do texto. Não é um textocom foco teórico, mas sim aplicado. Durante os 12 anos em que o curso já foi dado,todas as provas foram práticas, apresentando problemas para serem analisados e

modelados, e com consulta. Neste livro, seguindo a análise essencial, estamos interessados em sistemas de

informação que produzemrespostas planejadas , isto é, que executam ações pré- programadas em função de mudanças reconhecíveis e previsíveis no ambienteexterno. Chamamos essas mudanças no estado do ambiente deeventos essenciais . Não estamos interessados em respostasad-hoc, isto é, respostas que tem que ser praticamente inventadas caso a caso, mas sim em eventos que podem ser previstos e para os quais podemos programar respostas em um computador digital.

É importante deixar claro que a análise essencial, unificada com o modelo deentidades e relacionamento, é uma ferramenta de grande qualidade para odesenvolvimento de sistemas de informação.

Quando um cliente solicita um sistema de informação, pensa em automação dealgum processo, na modernização de um processo já automatizado ou na criação deum novo processo em sua empresa. O cliente então imagina um sistema que executaalgumas funções, gerencia alguns dados e fornece alguns relatórios. Esse sistemaimaginado pelo cliente, porém, raramente descreve de forma clara o que ele realmente precisa, ou que precisará no dia que o sistema ficar pronto. Cabe ao analista ajudar aocliente a descobrir como é o sistema realmente necessário.


4/312

3

O segundo capítulo faz uma pequena introdução aos Sistemas de Informação, principalmente aqueles que encontramos dentro de organizações. O terceiro capítulodiscute o desenvolvimento de software. Ambos os capítulos são introdutórios e têmcomo finalidade nivelar conhecimento, sendo que o ideal é que o aluno envolvidonesse estudo tenha feito antes desse curso cadeiras equivalentes a Sistemas deInformação e Introdução a Engenharia de Software.

O quarto capítulo discute o levantamento de requisitos do sistema. Apresentaao leitor dois conceitos importantes: ostakeholder , palavra que significa “aquele quetem algum interesse (aposta)”, e que traduzimos de forma liberal para interessado, euma classificação de tipos de requisitos de um sistema, onde se sobressaem osrequisitos funcionais e não funcionais. O capítulo também apresenta uma leveintrodução a métodos de elicitação de requisitos, discutindo os métodos tradicionais emais comuns, a entrevista e o JAD, detalhadamente.

O quinto capítulo apresenta a proposta inicial. O objetivo é permitir aodesenvolvedor compreender de forma geral o que será feito no projeto dedesenvolvimento, dando margem para a criação de uma proposta comercial. Nessecapítulo ainda tratamos o desenvolvimento de sistemas como uma atividade informal,a nível de negócios.

O sexto capítulo trata da modelagem de negócios, partindo de modelos de altograu de abstração, como o IDEF0, para modelos detalhados do comportamento daorganização, como EPC e regras de negócio. Esses métodos podem substituir na suatotalidade o uso de DFDs para modelar a encarnação de um sistema, sendo na práticamais adequados para o mapeamento do funcionamento real de uma organização.

O sétimo capítulo trata da modelagem conceitual de dados, baseado no modelode entidades e relacionamentos, necessidade primordial para uma boa análise desistemas. O oitavo capítulo trata da modelagem funcional essencial. Juntos, esses doismodelos definem o funcionamento esperado do novo sistema.

Esta edição apresenta a primeira versão de um capítulo sobre Casos de Uso (onono). Casos de Uso são provavelmente a forma mais indicada, hoje em dia, paralevantar requisitos funcionais de uma aplicação. Porém, o conhecimento da AnáliseEssencial ainda me parece importante para poder trabalhar com Casos de Uso, que sãomais informais. Por outro lado, já há alguns anos não vejo projetos usando DFDs, eresolvi definitivamente relega-los a um apêndice.

Esses modelos são completados com um modelo da interface do sistema, preferivelmente na forma de um protótipo, que é discutido no capitulo dez.

Finalmente o capítulo onze trata de formas de prever o esforço necessário paradesenvolver um sistema de software, usando como fator de determinação osdocumentos previamente gerados.

Além disso, apresentamos ao final alguns projetos para os alunos usarem nosexercícios.

Recomenda-se que os capítulos sejam apresentados na ordem em que estão nolivro.

Os capítulos de análise funcional e modelagem de dados já foram dados emdiferentes ordens, tanto um quanto o outro na frente, porém a análise de dadosindepende da análise funcional e o inverso não é verdade, o que recomenda que seja aordem adotada. Além disso, a modelagem de dados pode ser vista como uma forma de


5/312

4

detalhar, a nível do sistema, as regras de negócio, o que apresenta uma continuidadeao curso. O livro suporta bem um período de 15 semanas, com 4 horas por semana,incluindo aulas teóricas e exercícios, duas provas e um trabalho por equipe, de 3,4 ou5 alunos, que tem em média 15 eventos e 10 entidades, e que deve modelar de formacompleta um sistema, de acordo com todo material apresentado.

I.1 Atualiazações para 2007/1A versão 2007/1 contém as seguintes atualizações em relação à versão 2006/2.

1. O assunto IDEF0 foi fortemente alterado, melhorando seu texto,organização e as explicações. Também foram substituídas váriasfiguras e incluídas outras para melhor esclarecer a modelagem.

2. O assunto EPC foi fortemente alterado, melhorando seu texto,organização e as explicações. Também foram substituídas váriasfiguras e incluídas outras para melhor esclarecer a modelagem.

3. O capítulo Modelo de Interface teve todas as suas imagens corrigidas

para imagens originais do autor. Parte do texto não relevante foiretirada.4. O capítulo de Modelagem Funcional Essencial sofreu leves correções.5. O capítulo 4, Modelos e Abstrações, foi criado, retirando partes de

outros capítulos.6. Várias imagens foram revisadas ou trocadas em busca de um

documento livre de qualquer forma de direitos autorais externos aoautor.

7. Os eventos essências externos esperados, e não-esperados, passam aser chamados de agendados, e não-agendados. Essa mudança na

denominação foi gerada pela experiência de ensino, que mostrou que otermo agendado é mais bem entendido pelos alunos.


6/312

5

Capítulo II. Sistemas de Informação"A complex system that works is invariably found

to have evolved from a simple system that worked." John Gall

Sistemas de InformaçãoDados, Informação, ConhecimentoSI e a Organização

ERPCusto Total de Propriedade

Sistemas de Informação são utilizados em organizações para planejamento,monitoração, comunicação e controle das suas atividades, por meio da manipulação eguarda de informações.

Segundo o Dicionário Aurélio, a palavra sistema significa, entre outras coisas,um “Conjunto particular de instrumentos e convenções adotados com o fim de dar

uma informação”. Os instrumentos são as ferramentas, os mecanismos, concretos ouabstratos, que utilizamos para fazer funcionar os sistemas, tais como: programas decomputador, relatórios, formulários, etc. As convenções são as suas regras deutilização. Apesar de sistemas de informação não necessitarem de computadores paraexistir, hoje em dia é comum associar o termo imediatamente a uma implementaçãousando software, hardware e redes.

Um exemplo típico de sistema de informação é um sistema de aluguel parauma vídeo-locadora. Entre suas várias finalidades, a principal é certamente controlar oaluguel das fitas, informando quem está com qual fita em um determinado momento(quando), e quanto deve pagar por isso. Além disso, o sistema permite outrasatividades, como a gerência do estoque de fitas (quais fitas existem), a monitoração

das fitas mais e menos alugadas (quantas vezes cada fita foi alugada), etc.Um Sistema de Informação é um conjunto de componentes

inter-relacionados que coleta dados no ambiente em queopera, usando recursos de sensoriamento e telecomunicações(entrada), analisa esses dados (processamento) e finalmente

apresenta o produto como informação útil (saída), sendoconstruído de forma a atender os interesses de uma

organização, de seus clientes internos e externos e de todosaqueles atingidos direta ou indiretamente pelo novo

produto 1.

Ao longo deste livro usaremos a palavra organização para representarempresas, órgãos públicos, entidades beneficentes, associações e qualquer outra formade instituição com objetivos definidos e que pode obter algum benefício com o uso desistemas de informação. Nisso incluímos um enorme espectro de interesses etamanhos, tanto um consultório dentário quanto uma multinacional de bebidas.

1 Xexéo, J.A. “Tese de Doutorado” XXX


7/312

6

Apesar de estarmos preocupados com o desenvolvimento de sistemas deinformação automatizados, implementados na forma de programas de computador,isso não é uma necessidade. Durante séculos as organizações usaram sistemas deinformação apenas com o uso de pessoas, papel e tinta. Apenas bem mais tarde,aparecem máquinas como máquinas de escrever e de somar. Não seria exageradodizer que a escrita e os números foram criados para suportar os primeiros sistemas deinformação, que tratavam, por exemplo, de colheitas e comércio Muitas das técnicasdeste livro podem, e devem, ser aplicadas para entender sistemas de informaçãomanuais.

Este capítulo apresenta uma breve descrição de como funciona, para queservem e quem usa os sistemas de informação dentro de uma organização.

Figura 1. Uma tela de um sist ema de informações real.

II.1 Dados, Informação, ConhecimentoAntes de entender o que é um Sistema de Informação, é preciso entender

melhor o que significa a palavraInformação . Novamente, vamos recorrer a dicionários para ter uma definição inicial.

Segundo o American Heritage, informação é o dado quando processado, guardado outransmitido. Já no dicionário Aurélio, informação, entre outros significados, pode ser“Conhecimento amplo e bem fundamentado, resultante da análise e combinação devários informes”, “Coleção de fatos ou de outros dados fornecidos à máquina, a fimde se objetivar um processamento” ou ainda “Segundo a teoria da informação, medidada redução da incerteza, sobre um determinado estado de coisas, por intermédio deuma mensagem”. Apesar de não estarmos diretamente envolvidos com a teoria dainformação, não podemos de deixar de notar a importância da definição que diz quea informação reduz a incerteza por meio de uma mensagem .

Estamos interessados em criar uma diferenciação entre dados, informação econhecimento, mesmo que as palavras possam ser consideradas sinônimas em muitoscontextos. Apesar de serem normalmente confundidas ou utilizadas de forma


8/312

7

intercambiável, elas podem ser mais bem entendidas e utilizadas se analisadas comorepresentando conceitos diferentes.

Dados são apenas os símbolos que usamos para representar a informação, oregistro de diferentes aspectos de um fato ou fenômeno. Os números que guardamosem um banco de dados são, como diz o nome, “dados”. Dados não são interpretados,eles existem, são adquiridos de alguma forma, via coleta, pesquisa ou criação,guardados de outra forma e, possivelmente, apresentados em uma terceira. Ocomputador é uma máquina que manipula dados.

Por outro lado, informação é o dado com significado, normalmente processado de forma a ser útil. Uma informação deve permitir responder perguntascomo “quando”, “quanto”, “quem”, “qual” e “onde”2 sobre alguma coisa.

Informação = Dado + Significado

É necessário fazer um mapeamento entre dados e informação. Essemapeamento pode ser simples ou complexo, dependendo de várias variáveisenvolvidas, que vão desde decisões arbitrárias tomadas pelo desenvolvedor até padrões internacionais. Por exemplo, em muitos sistemas é preciso ter a informaçãodo sexo de uma pessoa (masculino ou feminino). Para isso, guardados um número (1ou 0) ou uma letra (M ou F) que é o dado que faz a indicação da informação.

Conhecimento é a aplicação da informação. Podemos dizer que permiteresponder a pergunta “como”, pois envolve argumentos, explicações e justificativas.Entre as três palavras que estamos analisando, conhecimento é a que tem significadomais geral na língua portuguesa, podendo ser usada no dia a dia como sinônimo deinformação. Em informática, porém, normalmente chamamos de conhecimento algoque pode ser escrito na forma de regras (como em “se for maior de 18 anos, então pode tirar carteira de motorista”).

Além disso, ainda podemos analisar as palavras compreensão (ouentendimento) e sabedoria. A compreensão permite responder a pergunta “por que”,enquanto a sabedoria é um processo complexo e pessoal de compreensão e avaliaçãodo entendimento, que não pode ser compartilhado [B1].

Bellinger et. al. [B2] afirmam que com o aumento da compreensão e dacapacidade de fazer conexões entre partes (dados, informações, etc.), passamos dotrabalho direto com o dado em si para informação, então para o conhecimento efinalmente para a sabedoria.

2 What, where, when, who, How much


9/312

8

Figura 2. Entendimento das relações entre dados, informação,

conhecimento e sabedoria, segundo Bellinger et al.[B2]

II.2 Características dos Sistemas de InformaçãoÉ importante entender que sistemas de informação sãosistemas interativos e

reativos .Interativo significa que o sistema troca informações com o ambiente, em

especial com os agentes externos que fazem parte desse ambiente, pessoas e outrossistemas de computador. O sistema só faz sentido se é capaz dessa interação.

Reativo significa que o sistema funciona reagindo a mudanças no ambiente, eem especial, a mudanças provocadas pelos agentes externos.

Nossos sistemas também são sistemas derespostas planejadas . Isso significaque nossas respostas são determinadas e determinísticas, que podemos criar um programa que as produza. Também significa que todas as perguntas que podem serfeitas ao sistema podem, e são, identificadas previamente.

Escolhendo essas regras de modelagem, escolhemos um caminho para decidirquando o sistema vai funcionar: em vez de deixar isso incerto, como em muitosmétodos, nós determinamos que o sistema só funciona para responder um evento noambiente, causado por um agente externo, e que possua uma resposta planejada.

A metodologia de desenvolvimento apresentada neste livro é feita sob medida para sistemas interativos e reativos, de respostas planejadas. Nesse caso, somos aomesmo tempo restritivos, pois se o sistema não pode ser modelado dessa forma nãoserve para nossa metodologia, como ampliativos, pois a grande maioria dos sistemas pode ser modelada de forma natural com esses princípios.

II.3 Sistemas de Informação e a OrganizaçãoSistemas de informação atualmente servem em todas as áreas e níveis das

organizações, sendo considerados como ferramenta essencial para o sucesso de suasatividades. Isso nos permite classificá-los de acordo com a responsabilidade assumida por seus usuários dentro da organização em quatro tipos principais, como sugerido por Laudon [B3]:


10/312

9

• Sistemas de nível operacional , que tratam da execução, acompanhamento eregistro da operação diária da empresa, sendo geralmente sistemas fortementetransacionais. Exemplos são sistemas de vendas, folha de pagamento, etc.• Sistemas de nível de conhecimento , que suportam as pessoas que trabalham comdados e conhecimento dentro da organização. Exemplos simples de sistemas dessetipo são os processadores de texto e as planilhas eletrônicas.• Sistemas de nível gerencial , que utilizam dados da operação e outros dadosinseridos nesses sistemas para permitir a obtenção de informações que permitam agerência da empresa, suportando a tomada de decisões, o controle e o monitoramento.• Sistemas de nível estratégico , que são sistemas destinados a decisões de maisalto nível (efeito estratégico) e utilizam dados de todos os sistemas anteriores,normalmente de forma agregada e processada, sendo utilizados pela alta gerência.

Estratégico

Gerencial

Conhecimento

Operacional

Figura 3. Níveis dos si stemas de informação dentro de uma

organização

Ainda segundo Laudon, a cada nível de sistemas de informação podemosassociar um ou mais tipos de sistemas.• Sistemas de Suporte Executivo (SSE) , encontrados no nível estratégico, sãodestinados a apoiar a alta gerência em tarefas estratégicas, como o planejamento delongo prazo. Usam dados fortemente agregados, internos e externos a organização esão capazes de responder perguntas específicas ou ainda fazer projeções. Podem sercapazes de fazer simulações e ter uma interface interativa.• Sistemas de Apoio a Decisão (SAD) , encontrados no nível gerencial, sãoutilizados pelos vários níveis de gerência e utilizam como entrada dados em pequenovolume (agregações) ou ainda bases massivas de dados previamente preparadas para

permir atividades de análise de dados. Como resposta, devem fornecer relatóriosespecíficos, análises e decisões e respostas a perguntasad-hoc.• Sistemas de Informação Gerencial (SIG) , também encontrados no nívelgerencial, são utilizados pelos vários níveis de gerência. Utilizam grande volume dedados ou sumários de transações e modelos simples para obter relatórios sumários(agregados) e de exceções.• Sistemas de Trabalho com Conhecimento (STC) , encontrados no nível deconhecimento, utilizam projetos, especificações e bases de conhecimento em geral


11/312

10

para produzir modelos e gráficos. Normalmente são utilizados por profissionais comnível superior.• Sistemas de Escritório (SE) , encontrados no nível de conhecimento, tem comoobjetivo aumentar a produtividade na manipulação de dados em um escritório.Permitem a manipulação de documentos, correio eletrônico e agendas.

• Sistemas Processamento de Transações (SPT), encontrados no níveloperacional, tratam eventos e transações e fornecem relatórios detalhados, listas esumários, utilizados pelos gerentes, além de documentos específicos para a transaçãoem que são utilizados.


12/312

11

Os SPT suportam não só a operação diária da empresa, mas também criam osdados que são mais tarde utilizados pelos outros tipos de sistemas.

II.3.1.1 Sistemas de Informações TípicosAtualmente já consideremos que vários sistemas de informações típicos de

uma empresa são necessidades básicas que podem ser atendidas de uma só vez. Esses

sistemas constroem o que é comumente chamado de ERPs – de Enterprise ResourcePlanning – ou Sistemas de Gestão Empresarial em português – mas que na prática nãosão sistemas de planejamento (ou de recursos), mas sim de controle e administraçãode uma empresa.

Entre as características encontradas em ERPs podemos citar a integração dasatividades da empresa e o uso de um banco de dados único. O líder mundial domercado é a SAP AG, com o produto SAP R/3. O custo de implantação de um ERPde grande porte pode chegar até 300 milhões de dólares. No Brasil, existem produtosmenos ambiciosos e mais baratos.

Os sistemas de ERP atuais contêm módulos representando os mais típicossistemas de informações necessários em uma empresa, tais como: Contabilidade

Fiscal, Contabilidade Gerencial, Orçamento e Execução Orçamentária, Ativo Fixo,Caixa e bancos, Fluxo de Caixa, Aplicações e Empréstimos, Contas a Receber, Contasa Pagar, Controle de Viagens, Controle de Inadimplência, Administração dos preçosde venda, Compras, Controle de fretes, Controle de contratos, Controle deinvestimentos, Cotações de vendas, Estoque, Exportação, Faturamento,Gerenciamento de armazéns, Importação, Obrigações fiscais, Pedidos, Previsão devendas, Recebimento, Gestão de informação de RH, Pagadoria, Treinamento, RHscorecard, Planejamento de RH, Planejamento de produção, Planejamento dacapacidade, Custos industriais, Controle de chão de fábrica, Controle da produção,Configurador de produtos, Planejamento de Manutenção, Acompanhamento deManutenção e ainda muitos outros...

II.4 Tipos de Projetos de Sistemas de InformaçãoExistem três tipos de projeto de sistemas de informação: manual, manual para

automático e re-automação [B4]. Os processos de re-automação ainda podem sedividir em recodificação, re-projeto e re-desenvolvimento, melhoria ou manutenção.

Todos esses tipos de projeto apresentam ao analista de sistemas o mesmodesafio: descobrir o que deve ser feito. Porém, cada tipo apresenta certas particularidades que facilitam ou dificultam esse trabalho de análise.

O trabalho do analista em sistemas manuais é mais relacionado àformalização, por meio de documentação e padrões, de processos já adotados, acriação de novos processos e a transformação de processos existentes tendo em vistaotimizá-los ou possibilitar que atendam novas necessidades da organização. Esses processos podem ser bastante complexos e convolutos em alguns casos, o que exigedo analista uma boa capacidade de compreensão e modelagem. Porém, como nãoserão transformados em programas de computador, o analista pode trabalhar comferramentais mais informais e mais próximas ao dia a dia do usuário.

Os projetos que apresentam maior dificuldade são os de passagem do processomanual para o automático. Isso acontece porque normalmente esses projetos exigemtodo o trabalho feito no tipo anterior, e, de forma adicional, a criação de um modelo


13/312

12

computacional e com certo grau de formalidade, que possa ser usado pelosdesenvolvedores. Não há, a princípio, uma guia que indique a adequação daautomação ou que novos resultados podem ser obtidos. O usuário, por não ter acesso asistemas de informação que executem a mesma atividade, tem pouco conhecimentosobre o que é possível fazer, ou não tem idéia de qual o custo de produzir certosresultados.

Já os projetos de re-desenvolvimento apresentam a vantagem de possuir uma base que pode ser utilizado como referência do que deve ser feito (repetido), do quenão deve ser mantido (eliminações) e das novas atividades necessárias. O usuário,acostumado e experiente com um sistema existente, pode fornecer informações maisadequadas sobre o que espera do novo sistema, ou da manutenção ou melhoria sendofeita.

II.4.1 Porque são feitos projetos de SIMuitos são os motivos que influenciam o início de um projeto de

desenvolvimento de um Sistemas de Informação. Em geral, usando um raciocínioeconômico, podemos dizer que um projeto é iniciado quandoo benefício do retornoesperado supera ocusto do projeto 3. O problema é que não é fácil converter essesvalores em números normalmente.

II.5 Custo Total de PropriedadeQuanto se analisa o custo de um sistema é normal falar de Custo Total de

Propriedade, conhecido pela sigla em inglês TCO (Total Cost of Ownership). O TCOde um produto é o custo total que ele implica para uma organização. Por exemplo, sedecidirmos trocar todo o parque computacional de uma empresa que usa Windows para Linux, mesmo que o custo do Linux seja zero, o TCO é bem alto, pois envolve o processo de troca, novos profissionais, treinamento, etc... Outro exemplo comum é oda compra de uma impressora. Seu TCO não envolve apenas o custo da impressora,

mas também o custo do material consumível, quando uma certa produção é prevista.Por isso é que grandes empresas compram menos impressoras, porém impressorasmaiores e mais caras, para baixar o TCO.

Para o software desenvolvido vale o mesmo conceito. Qual seu TCO? Envolveo preço pago pelo software mais tudo que vai ser pago para possibilitar a implantaçãoe utilização do produto (instalação, cursos de treinamento, manutenção mensal, etc...).

II.6 Benefícios do SistemaVários motivos podem ser analisados como benefícios esperados de um

projeto. O principal benefício que um sistema de informação pode oferecer é melhorarsignificativamente o negócio do usuário, aumentando seu lucro. Porém, essa não é aúnica motivação possível.

Uma motivação comum é modernização de um sistema. Com o tempo atecnologia de um sistema vai se tornando superada. Isso faz com que o risco e o custo

3 Na verdade, a compreensão econômica é mais complicada, mas essa explicação nos serve comomotivador adequado.


14/312

13

de manter o sistema funcionando naquela tecnologia aumentem, aumentandogradativamente o interesse de se transportar o sistema para uma nova plataforma.Simultaneamente, novas tecnologias apresentam novas oportunidades, comodesempenho superior ou facilidade de aprendizado, aumentando também com otempo o interesse nessa atualização. Chega um momento então que passa a valer a pena o investimento em modernização.

Outro motivo importante é a mudança de premissas básicas do negócio,causada pela atuação da firma no mercado. Essas mudanças tanto podem de dentro daempresa quanto podem ser provocadas por mudanças na legislação ou por ação dosconcorrentes. Por exemplo, há alguns anos atrás, no Brasil, foram feitas váriasmodificações nos sistemas financeiros das empresas para aceitar a mudança demoedas e o convívio com moedas diferentes simultaneamente. Em outro exemplo,com a invenção e grande aceitação dos sistemas de premiação por viagens ou pormilhas, as companhias aéreas tiveram que desenvolver sistemas específicos,interagindo com seus sistemas de passagens, para tratar do assunto. Muito comumtambém é a mudança de uma atividade da empresa, seja por um processo contínuo,como o de qualidade total, quanto por processos radicais como os de reengenharia e

downsizing.Os sistemas de informação também são importantes por oferecerem asempresas uma capacidade maior de competição. Com a informação correta e com os processos corretos de tratamento da informação uma empresa pode ter um diferencialde qualidade no mercado. Por outro lado, se todo um mercado já adotou um tipo desistema, ou se pelo menos um concorrente já o fez, a empresa que não tem um sistemaequivalente fica prejudicada na competição. Esse tipo de efeito foi visto quando ascompanhias aéreas passaram a vender passagens via Internet. No início era mais uma propaganda, depois passou a ser um diferencial positivo. Atualmente todas ascompanhias aéreas possuem formas de vender passagens diretamente via Internet.

Hoje em dia um grande motivador de novos projetos e a busca por melhor

tratamento da informação que já existe em sistemas de tipo operacional, como acriação de Sistemas de Suporte Executivo.

II.7 O Poder está com o usuárioUm dos acontecimentos mais marcantes da computação é a transferência do

poder daqueles que operavam as máquinas, os famosos e muitas vezes odiados CPDs – os Centros de Processamento de Dados – para o usuário final.

Para aqueles que só chegaram ao mundo da informática agora, ou para aquelesque nasceram após a revolução causada pelos microcomputadores, é muitas vezesdifícil de entender a complexidade e a mística que cercavam os grandescomputadores. Resfriados a água, mantidos em salas seguras, gastando espaço eenergia, esses computadores da década de 1970 tinham o poder computacional de umtelefone celular do início do século XXI. Eram esses computadores, porém, quemantinham os dados fluindo, as contas e salários sendo pagos, à custa de umavigilância permanente de seu funcionamento e do uso de recursos. Até hoje, muitosserviços críticos funcionam em versões modernizadas desses computadores,


15/312

14

geralmente a custos altos, mas com alto risco de transferência para outrastecnologias4.

Grande parte da transferência de poder aconteceu quando osmicrocomputadores chegaram em grande quantidade as empresas, permitindo que osusuários que não eram atendidos no prazo e na qualidade que esperavam tomassem arédea do processo de software, desenvolvendo seus próprios aplicativas, usando planilhas eletrônicas e sistemas simples de banco de dados (como dBase II e Access)e, muitas vezes, passando por cima da estrutura da própria organização e contratandosoluções terceirizadas, já que não precisavam do computador central para executa-las.

Isso alterou drasticamente a estrutura de poder das organizações, que eramfortemente dependentes dos dados processados de forma central, em grandesmáquinas, com software de ciclo de desenvolvimento muito longo. O processo demudança não poupou carreiras, sendo que algumas empresas simplesmente fecharamseus CPDs, terceirizando suas atividades e despedindo ou transferindo todos seusfuncionários.

Hoje em dia o próprio nome CPD é estigmatizado. Cabe agora ao setor de TI –tecnologia da informação –manter uma estrutura muito mais complexa que a anterior,unificando sistemas de várias gerações, em redes com grande quantidade decomputadores executando sistemas operacionais diferentes e aplicações diferentes.Ainda existem conflitos em o pessoal de TI e as outras partes da empresa, mas o fococada vez mais é melhorar o negócio e atender melhor os usuários.

II.8 Exercícios1) Escolha um tipo de negócio de pequeno porte, como uma agência de viagens, e

descubra (ou imagine) quais os principais sistemas de informação que elanecessita ou pode usar.

2) Classifique os sistemas anteriores quanto ao seu nível na organização.3) Classifique os sistemas anteriores quanto ao seu tipo.4) Imagine que esse negócio se torna um grande negócio, por exemplo, uma grande

cadeia de agências de viagens, e descubra (ou imagine) que novos sistemas podem ser necessários.

5) Que sistemas de informação fazem parte de seu dia a dia? Que papel você assumeao utilizar esses sistemas?

6) Que sistemas de informação você pode se lembrar que contém informaçõesimportantes sobre sua vida pessoal ou profissional?

7) Imagine uma empresa de plano de saúde que possui um sistema de níveloperacional que registra e permite a aprovação pela pessoa responsável de examese consultas. Que sistemas de informação de outros níveis podem ser feitos parautilizar essa informação? Que outros sistemas de informação podem fornecerinformação para o sistema de aprovação?

4 É importante perceber que computadores de grande porte ainda são bastante úteis em sistemasespeciais, principalmente aqueles que exigem atender simultaneamente uma grande quantidade deusuários, devido a possuírem uma arquitetura planejada com esse objetivo, ao contrários dos PCs, queforam planejados para atender um único usuário.


16/312

15

8) Defina, para um sistema de informação escolhido por você, as informaçõesnecessárias, que dados às descrevem e que conhecimento pode ser obtido a partirdelas.

9) Muitas lojas no Rio de Janeiro ainda utilizam sistemas de informação feitos emMS-DOS. Faça uma análise dos custos e benefícios para mudar um sistema dessetipo para Windows ou de mantê-lo como está. Qual a melhor opção atualmente?Qual a melhor opção nos próximos 2, 5 e 10 anos?

10) Que tipos de sistemas podem interessar a Livraria ABC?11) Que tipos de sistemas podem interessar a Empresa de Clipping ClipTudo?12) Uma empresa precisa comprar uma impressora nova. Existem duas opções

interessantes no mercado, como descritas na tabela abaixo. Qual impressoracomprar se a empresa prevê fazer 30.000 impressões com a impressora. E seforem 100.000? E se forem 146.668? E se forem 500.000?

Característica Impressora A Impressora B

Preço da impressora (sem tinta) R$ 300,00 R$ 5.000,00

Preço do cartucho de tinta R$ 80,00 R$ 250,00

Número de cópias por cartucho 1.000 5.000

Vida útil da impressora 120.000 800.000


17/312

16

Capítulo III. O Desenvolvimento de Software Análise: ... 3. Exame de cada parte de um todo,

tendo em vista conhecer sua natureza,suas proporções, suas funções, suas relações, etc.

Novo Dic. AurélioAnálise de SistemasAnalista de Sistemas

FerramentasCiclo de Vida

Equipe de Desenvolvimento

Desenvolver software é a atividade, de longo prazo, de criar um ou mais programas decomputador, um sistema, de forma a atender necessidades específicas de um cliente ou grupode clientes.

No desenvolvimento de software realizamos as atividades de descoberta dasnecessidades e de criação do produto de software propriamente dito. Podemos dividir asatividades do processo de desenvolvimento em alguns grandes grupos:

• Atividades de Análise, cuja finalidade é descobrir “o que” deve ser feito.• Atividades de Projeto, cuja finalidade é descobrir “como” o software deve ser feito.• Atividades de Implementação, cuja finalidade é produzir o produto de software de acordo

com as especificações produzidas nas fases anteriores.• Atividades de Controle de Qualidade, onde se incluem todas as atividades com objetivo

de garantir a qualidade do produto, como testes e verificações.


18/312

17

De acordo com o processo de desenvolvimento escolhido, cada uma dessas atividades pode ser dividida em várias outras sub-atividades ou tarefas. Elas podem ser executadas dediferentes formas, em diferentes ordens. Também é possível que as atividades de análise e projeto sejam feitas de forma implícita, por exemplo, quando desenvolvemos o softwareunicamente por meio de protótipos.

Dependendo do grau de formalidade do processo de desenvolvimento, que deve serescolhido em função de um grupo de variáveis, como a complexidade do projeto, prazo ecaracterísticas da equipe. Enquanto um produto para um único usuário pode ser feito pormeio de protótipos, sem nenhuma fase bem-definida, produtos muito grandes, como umsistema de informações para toda um empresa, necessitam ser realizados em passos muito bem planejados.

Esse livro trata de algumas metodologias usadas no processo desenvolvimento desoftware. Dependendo da fonte que utilizamos, esse processo pode envolver uma miríade deatividades. Na norma ISSO 12207 são citadas, por exemplo: análise de requisitos, projeto,codificação, integração, testes, instalação e aceitação. Outras referências podem apresentardivisões distintas dessas atividades, ou incluir atividades novas (como testes de integração etestes de unidades). Nesse livro estamos principalmente interessados em conhecerferramentas para realizar a análise de um sistema de informação.

III.1 A Dificuldade do ProblemaApesar de parecer uma atividade fácil, desenvolver sistemas de informação é na

verdade uma atividade muito difícil e que é muitas vezes fadada ao fracasso. Estudos doStandish Group conhecidos como CHAOS Report, envolvendo 8380 projetos de TI, indicamque, em 2004, 18% são um fracasso total, enquanto 53% tem algum problema de prazo, custoe funcionalidade. Apenas 29% dos processos são um sucesso.

29%18%

53%

Bem sucedidosCom ProblemasFracassados

Figura 4. Resultados do CHAOS Report 2004 sobre projetos de TI

(Standish Group, 2004)Desenvolver software é difícil porque normalmente estamos lidando com problemas

tão complexos que não os entendemos sem um grande esforço e, às vezes, sem tentar umasolução. Alguns autores chamam esses problemas dewicked problems, o que poderia sertraduzido para “problemas perversos”.

Estas taxas tão alta de fracasso se refletem principalmente em sistemas muito caros. Novamente, do CHAOS report, obtemos os seguintes dados, sobre a taxa de sucesso de projetos de TI de acordo com o custo do projeto:


19/312

18

0%

8%

15%

25%

33%

55%

0% 10% 20% 30% 40% 50% 60%

Maior que 10M$

Entre 6 e 10M$

Entre 3 e 5 M$

Entre 1.5 e 3M$

Entre 750K$ e 1.5M$

Menos de 750M$

Figura 5. Taxa de sucesso dos projetos, de acordo com o tamanho, em

dados de 1998 (Standish Group, 1998)Casos específicos não faltam para “contar a história” desses grandes fracassos:

• Sainsbury, US $526 milhões jogados fora em um software de gerência de cadeia desuprimentos

• Controle de Vôo Americano –US $ 2.6 bilhões jogados fora em um sistema que nãochegou a fase de produção.

• A Volkswagen do Brasil anunciou recall para cerca de 123 mil veículos dos modelosGol, Fox e Kombi, que precisarão reprogramar um software que controla ofuncionamento dos componentes eletrônicos do carro, inclusive do motor. Trata-se doterceiro maior recall já promovido pela montadora no Brasil.

• FBI: US$ 170 milhões jogados fora em um sistema para identificar terroristas que temque ser começado do início

• Ford: US$ 200 milhões acima dobudget em novo software de compra, que foiabandonado.

• McDonald’s: US$170 milhões abandonados em um projeto de software.

III.2 AnálisePor análise entendemos a tarefa de levantar e descrever os requisitos de um sistema,

definindo de que forma deve funcionar para atender as expectativas de todos que nele

possuem algum interesse. Normalmente se diz que a análise define “o que” o sistema devefazer sem especificar “como” fará. Durante a análise devem ser explicitadas que tarefas osistema deve executar e que dados deve manter em memória. Para isso, criamos um ou maismodelos do sistema, descrevendo-o com diferentes perspectivas e graus de detalhe.

É a partir da análise de desenvolvemos um sistema. Ela é, simultaneamente, umacordo entre os desenvolvedores e seus clientes e um mecanismo de comunicação entre osdesenvolvedores. Em ambos os casos, a análise define que serviços devem ser fornecidos


20/312


21/312

20

Incorporamos também, em nossa fase de análise, a modelagem por pontos de função,que nos permitirá definir um tamanho para nosso sistema.

III.2.2 Ferramentas da AnáliseA maior parte do trabalho de análise é feita da comunicação entre pessoas. Muito

dessa comunicação é feita na linguagem natal dessas pessoas, como o português. Um grande

problema dessa comunicação é que línguas como o Português e o Inglês permitem aconstrução de sentenças ambíguas. No desenvolvimento de sistemas temos que evitar ao máximo as ambigüidades. Para

isso, temos que restringir a linguagem utilizada de forma que uma sentença só tenha umainterpretação possível (ou mais provável). Para isso foram criadas várias linguagens, algumasgráficas, que tem o poder de restringir as interpretações possíveis do que queremos dizer.Veremos no decorrer desse livro uma visão geral de algumas dessas linguagens.

III.2.3 A TecnologiaA grande maioria dos autores advoga que não devemos levar em conta a tecnologia

que a ser empregada no desenvolvimento durante a análise de sistemas. A análise deve se preocupar com o “o que fazer” e nunca com o “como fazer”.

Como estaremos seguindo os princípios da análise essencial, esta questão ficaráinicialmente ainda mais restrita, pois o modelo essencial não pode conter nenhuma referênciaà tecnologia, sob o risco de produzir requisitos falsos.

Isso não quer dizer que o analista não possua as informações sobre a tecnologia,apenas que não as usa enquanto faz o trabalho de análise. Na prática, estamos semprelimitados por escolhas como linguagens, sistemas gerenciadores de bancos de dados,arquiteturas de rede e de computador. O que devemos fazer é não deixar que essas limitaçõesinfluenciem nossas decisões sobre “o que” deve fazer o sistema5.

Da mesma forma, não queremos dizer que o analista deve ignorar essas questões aotrabalhar. Ele deve anotá-las, pensar em seus impactos, porém não deve trazê-las para o

modelo criado na análise.III.2.4 O Analista de Sistemas

O Analista de Sistemas é o responsável por levantar os requisitos do sistema etransformá-los em uma especificação do que deve ser feito, i.e., a Análise do Sistema. Paraisso, assume vários papéis [B4]: repórter, detetive, consultor, diagnosticador, investigador,organizador, solucionador de problemas, avaliador, simplificador, artista, escultor, arquiteto,auditor, especialista de organização e métodos, especialista do domínio da aplicação, gerente,etc. O porquê dessa longa relação de papéis é o fato de o analista realmente ter que assumi-los ao longo do processo. Ele entrevista pessoas em busca de fatos e detalhes, descobre fatosescondidos (intencionalmente ou não), muitas vezes por meio de inferências ou pistasencontradas, propõe soluções mais adequadas para problemas atuais e futuros, a partir dediagnósticos, planeja sistemas abstratos a partir de diagramas, e ainda muitas outrasatividades.

III.3 Ciclo de Vida e Processo de Desenvolvimento

5 Ou seja, essas decisões, muitas vezes tomadas antes de se iniciar a análise de um sistema, devem influenciar apenas aforma de funcionamento, não a razão desse funcionamento.


22/312


23/312


24/312

23

desejado. O usuário, então, utiliza esse protótipo e fornece ao desenvolvedor novasinformações que o levam a modificar o protótipo, de maneira a atender todas as necessidadesdo usuário.

É claramente um processo de desenvolvimento baseado em um ciclo de realimentaçãode informações, com alta participação do usuário.

Não existe uma fase formal de análise ou projeto. Isso pode causar problemas gravese difíceis de corrigir no produto final, dificultando de sobremaneira a manutenção dos produtos. Pouca ênfase é dada à documentação.

Atualmente quase todos os processos de desenvolvimento utilizam protótipos, masnão um ciclo de vida de prototipagem.

Usamos “protótipos descartáveis” quando o protótipo é usado apenas para levantaralguns ou todos os requisitos e depois abandonado, em troca de uma implementação maisorganizada. Um “protótipo operacional” é um software feito rapidamente para atender umademanda do usuário e que é usado, mais tarde, como modelo de especificação para uma novaimplementação do sistema.

Ë possível diferenciar “protótipos” de “mock-ups”. Um protótipo apresentaria ocomportamento correto, ou aproximadamente correto, e seria caracterizado principalmente pela falta de rigor na implementação. Ummock-up apresentaria apenas uma interface queserviria como prévia da interface final.

Escutaro

Cliente

Contrução ouRevisão do Protótipo

Avaliaçãodo Protótipo

Figura 8. O Processo de Proto tipagem

• Processos EvolucionáriosOs modelos de processo evolucionários reconhecem que sistemas complexos se

alteram com o tempo, usando a iteração do ciclo de desenvolvimento para acompanhar aevolução do sistema.o Processo Incremental


25/312

24

Pode ser visto como combinando o linear com a prototipagem. Tem o foco principalna entrega do produto. Para realizá-lo, repetimos a seqüência linear em vários calendáriosdefasados no tempo. Busca implementar funcionalidades essenciais o mais cedo possível.

Análise

Projeto

Codificação

Testes

AnáliseProjeto

Codificação

Testes

Análise

Projeto

Codificação

Testes

Análise

Projeto

Codificação

TestesTempo

Figura 9. O Ciclo de Vida Incremental

• Processo EspiralO Processo Espiral se caracteriza pelo desenvolvimento por uma série de produtosdesenvolvidos em seqüência, cada vez mais complexos e mais próximos do produto finaldesejado. Ele se diferencia do Processo incremental porque os produtos de cada ciclo não são“subsistemas” do sistema original, mas sim produtos específicos que atendem necessidadesespecíficas do projeto, como por exemplo, “teste de viabilidade” e “definição da interfacecom o usuário”.

Em cada ciclo da espiral, algumas atividades são realizadas em ordem seqüencial:comunicação com o cliente, planejamento, análise de riscos, engenharia, construção e,finalmente, avaliação dos resultados.

Do RUP foram derivados vários outros processos, sendo o RUP o mais conhecido

deles.

Comunicaçao como Cliente

Planejamento

Análise deRiscosEngenharia

Construção

Avaliação

Figura 10. O Processo em Espi ral, visão abstr ata

• Processo Win-WinO Processo Todos Ganham - Espiral (Win-Win Spiral) é a unificação de dois

trabalhos distintos de Barry Boehm. No primeiro, o Processo espiral, ele propõe que um processo de software seja feito de acordo com um ciclo de especificações cada vez maisdetalhadas que resultam em versões incrementais das capacidades operacionais desejadas.Cada ciclo envolve a elaboração dos objetivos, restrições e alternativas do produto, a


26/312

25

avaliação das alternativas e riscos, a elaboração da definição do produto e do processo e o planejamento do próximo ciclo. No segundo, a Teoria-W, ele propõe que todas as decisõestomadas em um processo gerencial devem gerar uma situação de “todos ganham”6.

As fases para esse Processo são• Identificar X• Identificar condições de ganho para cada X• Conciliar condições de Ganho• Estabelecer objetivos, restrições e alternativas.• Avaliar alternativas de produto e processo, resolver riscos.• Definir produto e processo, incluindo partições.• Validar produto e processo, incluindo partições.• Revisar e alcançar compromisso (commit)

6 Em contrapartida com o caso normal, onde um ganha e os outros perdem, ou, ainda pior, com os casos onde adecisão tomada é vista como uma situação onde todos perdem.


27/312

26

• Desenvolvimento AceleradoDevido a grande pressão pela produtividade que as empresas sofrem no processo de

desenvolvimento de software, constantemente são propostas novas técnicas com a finalidadede acelerar o processo de desenvolvimento. Entre elas podemos citar a própria prototipagem,Rapid Application Development (RAD), Adaptative Programming, Extreme Programming etoda uma gama de processos ágeis.

Figura 11. O processo espiral como definido originalmente por Boehm(1988)

o A Equipe de DesenvolvimentoA equipe de desenvolvimento é o conjunto de pessoas responsáveis por construir o

software. Dela fazem parte pessoas com diferentes habilidades. Em sistemas de informaçõestradicionais teremos gerentes de desenvolvimento, analistas, projetistas, programadores,administradores de banco de dados, etc. Em sistemas mais modernos, como sistemasmultimídia e websites, podemos ainda ter profissões novas como artistas e professores.

É importante verificar que as pessoas em uma equipe de desenvolvimento secomunicam de alguma forma. Seguindo a regra de quanto maior o projeto, maior o número

de pessoas, muito maior o número de formas em que essas pessoas podem se comunicar.A figura a seguir tenta demonstrar essa idéia. Como uma pessoa, não há nenhumacomunicação. Com duas pessoas, só há uma maneira delas se comunicarem. Com 3 pessoas,escolhendo apenas a comunicação entre duas pessoas, já existem 3 formas. Com 4 pessoas,são 6 formas, com 5 pessoas são 10 formas. Basicamente, com N pessoas, existem (N×(N-1))/2 formas delas se comunicarem duas a duas.

Em projetos enormes, se todos puderem falar com todos para fazer algo, a situaçãofica incontrolável.


28/312

27

Por isso, temos que organizar a equipe de desenvolvimento de alguma forma.

Figura 12. As linhas de comunicação entre as pessoas crescemrapidamente, segundo uma explosão combinatória.

Em uma equipe com organização democrática, todos podem se comunicar com todos.Esse tipo de equipe é razoável para projetos pequenos, com equipes de até 5 ou 6 pessoas,

onde a comunicação incentivará a descoberta. Normalmente essas equipes são encontradasem universidades e no desenvolvimento de pequenos projetos de alta tecnologia (um website, por exemplo).

Figura 13. Em uma equipe democrática todos falam com todos

A forma mais tradicional de organizar uma equipe é a forma hierárquica, baseada nasteorias clássicas de administração (que por sua vez, são baseadas na forma de organização doExército e da Igreja).

Na equipe hierárquica temos um ou mais níveis de gerência. Cabe a gerência controlaro funcionamento do projeto. Os níveis mais baixos são responsáveis pela execução do projeto.

A equipe hierárquica é boa para manter regras e padrões, sendo uma escolha boa para projetos repetidos e que exigem grande estrutura. Muitas empresas utilizam esse tipo deorganização, porém ele é considerado fraco para o desenvolvimento de software novo, pois aestrutura coíbe a criatividade.

Em relação ao uso dos profissionais, podemos indicar um defeito importante: o

profissional de desenvolvimento experiente é transformado em gerente e “tira a mão damassa”. Muitas vezes, inclusive, ele é transformado em um mau gerente...


29/312


30/312

29

13) Descreva de forma sucinta os seguintes processos descritos na literatura:1. RUP – Rational Unified Process2. XP – eXtreme Programming3. Adaptative Software Development

14) Descreva como são as equipes de desenvolvimento da empresa em que você trabalhae de uma grande empresa (como a Microsoft, por exemplo).

Trabalho em Grupo (Projeto de Cadeira)A turma deve se dividir em grupos de três a cinco pessoas, com quatro sendo o

tamanho ideal. Cada grupo deve escolher um projeto de um sistema de informação. Essaescolha deve se basear nos seguintes princípios e conselhos:

O sistema deve ser simples o bastante para que todos o entendamAlgum participante do grupo deve ter experiência com o sistema ou com um sistema

parecidoA melhor opção é escolher um aspecto do funcionamento de um negócio familiar que

algum membro do grupo tenha acesso. Exemplos típicos: estoque de uma loja, atendimentode um consultório, notas de um curso, pagamento de mensalidades de uma academia, etc.

Outra opção é um sistema que algum membro do grupo tenha desenvolvido (ou participado do desenvolvimento).

Não será aceito um sistema de locadora de vídeo, por ser um exemplo muito utilizadona literatura, permitindo plágio facilmente.

Na prática, um trabalho de cadeira deve conter de 10 a 20 eventos e mais de cincoentidades para ter “alguma graça”. Porém nesse ponto o aluno não sabe ainda o que é umevento ou uma entidade. O professor deve orientar os alunos para que o sistema façaaproximadamente 15 “coisas”, incluindo cadastros, relatórios e processamentos.

Os alunos muitas vezes misturam em suas “definições” mais de um sistema entre ossistemas de informação típicos. O professor deve orientar e explicar a diferença. Confusõescomuns incluem sistemas de vendas, estoque, compras e controle de produção.

Os alunos devem preparar uma descrição informal desse projeto. Esse tema seráutilizado no desenvolvimento de um projeto durante todo o curso.


31/312

30

Capítulo IV. Modelos Abstrações eFrameworks

Models are to be used, not believed.

H. Theil ̀ Principles of Econometrics'The human mind has first to construct forms, independently, before we can find them in things.

Albert Einstein (1879-1955)

Todas as técnicas estudadas nesse livro implicam na criação de um modelo,seja ele do domínio da aplicação, do negócio, do problema, do sistema que seráimplementado, inclusive modelos que fazem a relação entre modelos distintos.

Apesar de usarmos estes termos de forma coloquial, é importante responder as perguntas: o que é um modelo? O que é uma abstração?

Um modelo 7 é uma representação de algum objeto, conceito, conjunto deconceitos ou realidade. Modelos são criados para que nós possamos estudar,

normalmente segundo algum aspecto escolhido, o objeto modelado. Na grandemaioria das vezes, um modelo é uma versão simplificada ou abstrata do objetomodelado.

No nosso dia a dia nos deparamos constantemente com modelos. Um mapa é umodelo do território que descreve. Uma maquete de um prédio é um modelo. Umareceita de bolo é um modelo do processo para construir o bolo. Uma foto do modelo pode ser vista como modelo.

Um tipo especial de modelo é o protótipo. Um protótipo é um modeloexemplar, no sentido que fornecer um exemplo, onde as simplificações são muito pequenas ou não existem.

Um modelo deve ser simples o bastante para ser fácil de manipular e,simultaneamente, complexo o suficiente para resolver o problema em questão, deacordo com o ponto de vista desejado.

Abstração é o processo mental de separar um ou mais elementos de umatotalidade complexa de forma a facilitar a sua compreensão por meio de um modelo,eliminando (ou subtraindo) o resto.

Quanto mais simples o modelo, maior a abstração feita para produzi-lo. No nosso dia a dia utilizamos a abstração para poder trabalhar com toda a

informação que o mundo nos fornece. Voltando ao caso do mapa: ele é um modelo deuma região. Dependendo da informação que queremos, colocamos alguns símbolos etiramos outros do mapa. Um mapa também não pode ser “perfeito”, tem que

“abstrair” as informações que não são necessárias naquele instante, ou teria que ter omesmo tamanho da cidade.Podemos usar mapas com diversos graus de detalhe, ou seja, mais ou menos

abstratos. Um globo terrestre, por exemplo, é um mapa muito abstrato. Geralmentecom o objetivo de ensinar noções básicas de geografia. Já uma carta náutica é ummapa muito detalhado, que permite a navios ou barcos menores navegarem de forma

7 Um modelo também pode ser “um exemplo”.


32/312

31

segura em uma região. Ainda mais detalhada será a planta de uma casa ou prédio. Osníveis de detalhe são infinitos e são usados de acordo com a necessidade do problemaa ser resolvido.

4 7 7 5 m m

900mm

900mm

(a) Mapa Mundi8 (b) Guia de Localização (c) Planta baixadecorativa

Figura 16. Diferentes tipos de mapas, ou seja, modelos , cadaum com um nível diferente de abstração e dedicado a uma

utili zação distinta.

o Tipos de Abstrações No desenvolvimento de sistemas, utilizamos alguns processos de abstração

típicos:• Ocultação da Informação (ou abstração da caixa-preta)• Classificação,• Composição,• Generalização,• Identificação,• Simplificação pelo Caso Normal, e• Foco/Inibição.• Refinamento Sucessivo• Separação de Interesses

8 Esta imagem está em domínio público. Crédito: U.S. Geological Survey Department of theInterior/USGS


33/312

32

Ocultação da Informação (Caixa-preta)Pela abstração de Ocultação da Informação nós deixamos de nos preocupar

com o interior de uma coisa, só prestando atenção a seu comportamento observável.Podemos encontrar esse exemplo facilmente em muitas coisas do mundo real.

Quantas pessoas, por exemplo, sabem como funciona um telefone celular? Poucas,certamente. Porém quase todos sabem usá-lo, porque “abstraem” o seu funcionamentointerno (isso é, não pensam nisso) e colocam em foco apenas o comportamentoexterno.

Por isso chamamos também essa abstração de “abstração de caixa-preta”. Oconceito inverso (ou seja, abrir a caixa) é chamado de “caixa-branca”.

Classificação (é um membro de) No processo declassificação eliminamos parte da individualidade do objeto

ou sistema analisado e o consideramos como um exemplar de uma “classe padrão”.Quando fazemos isso, aceitamos que esse objeto, agora umainstância da classe,

divide com todas as outras instâncias da classe um conjunto de características. Na classificação o que estamos fazendo é imaginar uma idéia única que

descreve, de forma abstrata, todos os objetos de uma classe. Ao eliminar anecessidade de tratar cada objeto de forma única, simplificamos o problema emquestão.

Exemplos típicos de classificação:

Instâncias Classe

Flamengo, Fluminense, São Paulo Times de FutebolBrasil, Estados Unidos PaísPelé, Zidane, Romário Jogador de Futebol

Tabela 1. Exemplo de classificação

O processo reverso da classificação é ainstanciação . O conjunto de todas asinstâncias de uma classe é aextensão dessa classe.

A classificação é um mecanismo básico do raciocínio humano. Talvez seja oque nos permita tratar de toda informação que recebemos diariamente.

É importante notar que na vida real um objeto pode pertencer a várias classes.Uma pessoa pode ser um aluno, um professor, um policial, etc... Normalmente, emmodelos teóricos como os que vamos usar, tentamos com que um objeto pertença,diretamente, a só uma classe, de modo a facilitar a manipulação do modelo.

Composição ou Agregação (é feito de, é parte de) Nacomposição entendemos um objeto complexo formado de um conjunto de

outros objetos como um só objeto. É como vemos uma bicicleta ou um carro. Aoeliminar a necessidade de descrever as partes, simplificamos a compreensão do objetoanalisado.


34/312

33

Exemplos típicos de composição:

Partes Objeto

Pneus, motor, etc. CarroCapa, centenas de folhas, etc. LivroCabelo, pele, ossos, etc. Homem

Tabela 2. Partes-Objeto na relação de composição

O processo reverso da composição é adecomposição . Normalmente, em modelagem de dados, usamos o conceito de composição

para dizer que uma classe (como endereço) é uma característica de outra classe,descrevendo um entre seus atributos.

Generalização (é um, é como)Com ageneralização nós somos capazes de entender como uma classe pode

ser descrita por outra classe, mais geral. É importante ver a diferença entre aclassificação e a generalização: a primeira trata da relação entre objeto e classes,enquanto a segunda trata da relação entre classes.

Com a generalização podemos compreender uma relação muito comum entreclasses, que é a que permite que qualquer objeto de uma classe possa ser visto, de umaforma mais geral, como um objeto de outra classe. Utilizando judiciosamente ageneralização podemos simplificar a forma de tratar objetos de classes similares.

Exemplos típicos de generalização:

Classes Classe mais geral

Funcionário, Aluno, Professor PessoaAutomóvel, Avião, Navio Meio de Transporte

Computador, Rádio, Televisão Aparelhos EletrônicosTabela 3. Exemplo de generalização

O processo reverso da generalização é aespecialização .

Identificação (é identificado por)Com a identificação nós somos capazes de entender como caracterizar

unicamente um objeto. Um nome identifica uma pessoa, por exemplo. Ao identificarunicamente um objeto podemos separá-lo de outro objeto semelhante e atribuir aentidades específicas atributos e características que só pertencem a ela, e não pertencem a outros elementos daquela classe.

Há uma diferença entre instanciar e identificar. Uma instância deve possuiruma identificação e uma identificação se aplica a uma instância. A identificação permite a que duas instâncias sejam reconhecidas como distintas ou comorepresentações de um mesmo objeto (normalmente devendo ser reunidas em uma).

Simplificação pelo Caso Normal9

9 Não confundir com a operação de normalização relativa às formas normais.


35/312

34

Toda aplicação, ao funcionar, deve tratar de casos específicos que ocorremdurante o funcionamento normal. Porém, é bem mais fácil discutir o funcionamentonormal antes e depois os casos específicos. A abstração de “iniciar pelo modonormal” indica que devemos começar a trabalhar pelo modo comum ou normal defuncionamento, ou ainda melhor, o modo onde tudo ocorre da forma mais simples edepois ir inserindo mecanismos para tratar das variações possíveis.

Foco e InibiçãoUma das características importantes do ser humano é ser capaz de focar em

um detalhe, inibindo os outros detalhes ao redor, e assim processar, detalhe a detalhe,grande quantidade de informação.

Podemos ver essa forma de abstração acontecer no dia a dia, quando estamosolhando para um local e as áreas ao redor ficam “vigiadas”, mas não estamosrealmente prestando atenção nas mesmas.

Isso também acontece em um modelo de dados. Cada parte de um modelo focaem alguma informação que pretendemos registrar, e possui regiões ao redor que nosinformam outras informações adicionais, mas não precisamos olhar ao detalhe da

outra parte para entender aquela.Tecnicamente falando, foco e inibição são representados pela modularização e

divisão do sistema em partes estanques, com as características de alta coesão e baixoacoplamento.

Refinamento SucessivoA técnica de refinamento sucessivo indica que cada problema deve ser tratado

de uma forma mais geral para depois ser analisado de uma forma mais específicas,normalmente seguindo o conceito de “explodir” um problema anterior (mais geral) emsub-problemas mais específicos, sendo cada um desses sub-problemas “explodidos”também até chegarmos a um problema de solução simples.

O refinamento sucessivo é uma forma mais específica da abstração de Foco eInibição e faz parte de várias estratégias de abstração baseadas no conceito de dividir para conquistar

Separação de InteressesSeparação de Interesses é o processo de abstração onde tentamos descrever, ou

produzir, um conceito separando-o em conceitos distintos com a menor quantidade possível de interseção, baseado em algum aspecto específico do problema sendotratado. Esses conceitos normalmente são características ou comportamentos.

A Separação de Interesses é uma forma mais específica da abstração de Foco eInibição e faz parte de várias estratégias de abstração baseadas no conceito de dividir para conquistar.

o Trabalhando com as abstraçõesImagine que precisamos descrever comprar um carro. É óbvio que todo carro

possui quatro pneus, um motor, etc. Isso é uma classe bastante geral. Porém,desejamos ainda falar sobre um modelo específico: uma Ferrari Testarossa, porexemplo. Logo, acabamos de especializar nosso modelo, mas ainda não chegamos aonível de objeto. Quando vemos o carro específico, aí temos o objeto. Ele é


36/312

35

identificável como instância daquela classe porque apesar de dividir váriascaracterísticas em comum com outros objetos da classe, também tem algumascaracterísticas únicas, como o número de série do chassi. Finalmente, desejamostrocar a cor do assento do carro. Nesse instante, já estamos vendo uma parte do carro,decompondo-o em suas partes.

o Os modelos e as organizaçõesEm uma organização moderna, a quantidade de atividades realizadas é muito

grande. Quando pensamos em uma empresa ou um órgão público, ou em seusdepartamentos, o que primeiro vem a nossa mente é sua finalidade principal, porexemplo: vender comida, aprovar pedidos de aposentadoria, fabricar brinquedos, etc.Porém, para poder realizar sua atividade principal e manter a organização dentro dos parâmetros legais e capaz de responder prontamente a seus clientes, cada vez maisatividades são necessárias. Se bastava ao padeiro de antigamente conhecer seusclientes e seus dois ou três fornecedores, ao fabricante de pães atual é necessárioanalisar o mercado, compreender as manobras de seus concorrentes, atender asexigências de seus canais de distribuição e fornecedores, prestar contas ao governo e aacionistas, etc.

Para apoiar essas necessidades, são necessários muitos sistemas deinformação, e, quanto maior a quantidade de informação, maior a necessidade queesses sistemas sejam automatizados e integrados.

Para uma organização de grande porte, o conhecimento de seus sistemas deinformação é peça básica na competitividade. Assim, temos a motivação para não sóusar a tecnologia, mas também conhecer como essa tecnologia está sendo usada, paramelhor aproveitá-la.


37/312

36

Capítulo V. Usuários e Requisitos A hundred objective measurements didn't sum the worth of a garden;

only the delight of its users did that.Only the use made it mean something.

Lois McMaster Bujold, A Civil Campain, 1999StakeholdersRequisitos Funcionais

Requisitos Não FuncionaisDescrevendo Requisitos

Elicitação de RequisitosEntrevistas e JAD

A principal tarefa de um analista é descobrir o que o sistema deve fazer ecomo deve se comportar segundo as expectativas de seususuários e outrosinteressados. Usualmente, chamamos isso derequisitos 10. O problema é que, noinício do desenvolvimento, ninguém realmente sabe o que um sistema desejado deveexatamente fazer ao ficar pronto, inclusive o cliente. Além disso, com o tempo, osrequisitos mudam. Descobrir os requisitos de um sistema e manter-los atualizados sãotarefas investigativas, criativas e contínuas.

• Stakeholders e UsuáriosUsuários são todos aqueles que usam o sistema com algum objetivo. O nome

pode ser entendido de forma restrita, indicando apenas aqueles usuários finais, isto é,que realmente usam o sistema dentro do escopo do seu objetivo, ou de forma amplaindicando todos aqueles que usam o sistema ou algum de seus produtos, de algumaforma, o que inclui também os desenvolvedores.

Stakeholders são todos aqueles com algum interesse no sistema, afetando ousendo afetados por seus resultados. A palavra é uma composição dos termosstake,interesse ou aposta, eholder , possuidor. Fica claro que umstakeholderé uma pessoaque possui algum interesse no sistema, em especial um interesse que envolve algumrisco. Alguns autores brasileiros traduzem o termo como “interessados”, mas essetermo não tem todo o significado do termo em inglês, que adotaremos na falta de ummelhor em português. O grupo destakeholdersé bem maior que o grupo de usuários, pois envolve não só estes, mas também desenvolvedores, financiadores, e outros.

Um tipo destakeholder que é muitas vezes esquecido é formado por aquelas pessoas que são afetadas indiretamente pelo funcionamento do sistema, mesmo semsaber que ele existe ou está funcionando. Dizemos que essas pessoas estão “na sombra

do sistema”.Como exemplo, podemos citar o caso de um sistema hospitalar destinado a

indicar qual paciente deve tomar que remédio a que horas. Nesse sistema, enfermeirase médicos seriam usuários. Claramente, os pacientes, mesmo não sendo usuários, sãostakeholders, pois seu interesse no bom funcionamento do sistema é direto. Uma falha

10 Em inglês,requirement , o que levou alguns tradutores a usar o termo requerimentos, consideradoinadequado.


38/312

37

pode causar até mesmo a morte de um ou mais pacientes. A família e osacompanhantes do paciente, porém, estão na sombra do sistema, sendo afetadosapenas indiretamente.

Abordagens simplificadas permitem identificar imediatamente três tipos destakeholders: desenvolvedores, compradores e usuários. Uma investigação mais profunda pode achar muitos outros interessados, como: gerentes dos usuários finais,auditores, responsáveis pela operação, responsáveis pela manutenção, usuários desistemas que enviam ou recebem dados para o sistema específico, etc. É interessanteque seja feito um esforço para levantar todos osstakeholders de um sistema e mapear,de alguma forma, seus interesses e interações com o mesmo.

i. Interesses e ObjetivosUsuários possuem um ou maisobjetivos ao usar um sistema, i.e., ele usa o

sistema para obter uma resposta planejada. Usuários estakeholders têm interesses nosistema, isto é, eles esperam que o sistema afete o negócio de alguma forma.

Uma prática possível é definir uma tabela indicando que objetivos cadausuário e que interesse cadastakeholder tem no sistema. Isso pode ser feito de forma

preliminar nessa fase.

Objetivos e Interesses de Stakeholders

Agente ouInteressado

Objetivo Interesse Prioridade

Cliente Fazer pedido Receber oproduto pedido

1

Cliente Obter status dopedido

Prever o prazo dechegada do

pedido

2

Gerente Obter lista depedidos diária Saber a produçãodiária 1Tabela 4. Lista de objetivos e interesses

• Perspectivas dos UsuáriosQuando estamos fazendo a análise de um sistema, por meio de entrevistas ou

reuniões, interagimos com pessoas com visões e descrições diferentes do que é osistema. Um cuidado importante que devemos ter é quanto à posição da descrição queestá sendo feita em relação ao sistema.

Nossa metodologia está interessada em eventos que partem do ambiente, defora, para dentro do sistema. Assim, devemos descrever cada evento com essa perspectiva. Nossos clientes, porém, não têm sua perspectiva limitada pelo nossomodelo, afinal eles conhecem seu negócio e não precisam de um método como onosso, onde as limitações têm como objetivo clarificar a compreensão do sistema peloanalista.

Assim, muitas vezes um entrevistado descreve o sistema como se fosse umaentidade mágica, outros descrevem o sistema como se fizessem parte dele, outrosdescrevem apenas as saídas do sistema, etc.


39/312

38

Devemos estar preparados para isso e garantir uma modelagem condizentecom o modelo essencial que atenda todos os pedidos do usuário. Devemos tambémfazer, sutilmente, o usuário compreender a nossa forma, essencial, de descrever oseventos. Muitos usuários entendem facilmente o conceito de eventos quandotraduzidos para português mais simples, como “entrada de dados” e “entrada decomandos”.

As perspectivas básicas que encontramos em entrevistas e reuniões são asseguintes:

• Entrevistado onisciente : descreve o sistema como “o sistema”,indicando coisas que ele “deve fazer”. Vê tanto o sistema como os seususuários de uma perspectiva externa, aparentemente conhecendo osmecanismos tanto por dentro quanto por fora. Normalmente é a posição da alta gerência e de quem contratou o sistema. É comum quenão conheça os procedimentos internos do sistema como acontecemrealmente, mas apenas de forma geral ou como aconteciam no passado.Exige funcionalidade do sistema, principalmente para atender o nívelgerencial.

• Entrevistado usuário : descreve o sistema como se o estivesse usandodiretamente, muitas vezes já usando o sistema atual. Exige funções dosistema, principalmente para atender o seu nível de atuação (gerencialou operacional). Pode apresentar alguma desconfiança, pois o novosistema pode exigir novos conhecimentos. Conhece a entrada e a saídado sistema, mas não necessariamente os procedimentos internos.

• Entrevistado parte do sistema : descreve o sistema visto por dentro.Muitas vezes é quem vai ter o trabalho substituído, em todo ou em parte, pelo sistema, o que pode causar desconfiança e até mesmofranca hostilidade. Conhece os procedimentos na forma como sãorealizados e as exceções que podem acontecer.


40/312

39

Não podemos deixar de entender que alguns usuários fornecem uma perspectiva mista, principalmente quando envolvidos com diferentes partes dosistema.

Figura 17. Os tipos de entrevistados em relação ao sistema

Na prática do desenvolvimento de software, percebemos que na grandemaioria dos casos o usuário tem dificuldade de expressar suas necessidades. Isso podeacontecer por vários motivos, como o desconhecimento, o foco nas técnicas desolução (que são responsabilidade do analista e não do usuário), a dificuldade deencontrar uma linguagem comum com o desenvolvedor e muitos outros.

O que devemos notar é que apesar do analista ter que atender aos usuários, nãotem que atender exatamente ao que eles dizem, mas sim ao que realmente precisam. Otrabalho de análise é um trabalho investigativo, realizado junto com os usuários.Discutiremos esse assunto um pouco mais ao falar da elicitação de requisitos.

• O que é um RequisitoSegundo a norma IEEE Std 1220-1994,um requisito é uma sentença

identificando uma capacidade, uma característica física ou um fator dequalidade que limita um produto ou um processo .

Qualquer que seja o sistema, existem várias formas de entendê-lo.Similarmente, existem vários tipos de requisitos, que são aplicáveis ou não,dependendo da visão necessária naquele instante.

• Um requisito do usuário é algum comportamento ou característicaque o usuário deseja do software ou o sistema como um todo; o que ousuário quer. São escritos pelo próprio usuário ou levantados por umanalista de sistemas que consulta o usuário.


41/312

40

• Um requisito do sistema é algum comportamento ou característicaexigido do sistema como um todo, incluindo hardware e software. Ocomportamento desejado do sistema. São normalmente levantados porengenheiros ou analistas de sistemas, refinando os requisitos dosusuários e os transformando em termos de engenharia.

•

Um requisito do software é algum comportamento ou característicaque é exigido do software. São normalmente levantados por analistasde sistemas.O objetivo da análise é capturar todos os requisitos para osoftware sendo desenvolvido e apenas aqueles requisitos verdadeiros.

Exemplos de requisitos são:• O sistema deverá imprimir a nota fiscal de venda ao consumidor

referente à venda sendo registrada.• O sistema deverá permitir ao usuário calcular diferentes orçamentos

para uma mesma proposta, baseados em formas diferentes de pagamento.

• O sistema deverá avisar que a rede está fora do ar em 20±4 segundosapós a rede sair do ar.• O sistema deverá permitir agendar uma consulta, reservando a data e o

horário da sala e do profissional de acordo com as disponibilidades daclínica e o desejo do paciente.

i. Características de um Bom RequisitoUm requisito deve ter as seguintes características [B8]:

• Necessário , significando que, se retirado, haverá uma deficiência nosistema, isto é, ele não atenderá plenamente as expectativas do usuário.

o Em especial, não devem existir requisitos do tipo “seriainteressante ter”. Ou o requisito é necessário ou é dispensável.

o Deve ser levado em conta que cada requisito aumenta acomplexidade e o custo do projeto, logo, não podem serintroduzidos de forma espúria.

• Não-ambíguo , possuindo uma e apenas uma interpretação. Nesse casoé muito importante prestar atenção na linguagem sendo utilizada.

• Verificável , não sendo vago ou geral e sendo quantificado de umamaneira que permita a verificação de uma das seguintes formas:inspeção, análise, demonstração ou teste.

• Conciso , de forma que cada requisito defina apenas um requisito quedeve ser feito e apenas o que deve ser feito, de maneira clara e simples.

o Um requisito, para ser conciso, não inclui explicações,motivações, definições ou descrições do seu uso.

o Estes textos podem ser mantidos em outros documentos,apontados pelo requisito (de preferência sob o controle de umsistema de gerência de requisitos).


42/312

41

• Alcançável , ou seja, realizável a um custo definido por uma ou mais partes do sistema

• Completo , ou seja, não precisa ser explicado ou aumentado,garantindo capacidade suficiente do sistema.

• Consistente , não contradizendo ou mesmo duplicando outro requisitoe utilizando os termos da mesma forma que outros requisitos,

• Ordenável , por estabilidade ou importância (ou ambos).• Aceito, pelos usuários e desenvolvedores.

Além desses requisitos, quando um requisito for funcional, deverá ser tambémIndependente da Implementação , ou seja, o requisito define o que deve ser feito,mas não como.

ii. Efeitos de Requisitos ErradosA importância de obter requisitos corretos pode ser compreendida rapidamente

se imaginarmos que um requisito, quanto mais básico e importante ele é, mais partes

do sistema vai afetar.Basicamente, cada requisito do usuário vai gerar um ou mais requisitos dosistema, que vão, por sua vez, gerar outros requisitos mais detalhes. O efeito, com aevolução do projeto, é que cada requisito inicial representa não só um compromisso,mas um fator crítico em uma seqüência de decisões que são tomadas ao longo do projeto.

Assim, os erros de requisito afetam drasticamente todo o projeto. Dadosempíricos indicam que um problema nos requisitos, se detectado nas fases finais do projeto, pode custar 100 vezes mais para ser corrigido do que se for detectados na fasede elicitação de requisitos. Mesmo que essa detecção se faça mais cedo, em uma faseintermediária, esse custo ainda seria 10 vezes maior.

Um requisito que não caiba em uma das características de qualidade citadasserá propenso a defeitos e aumentará o risco do proejto. Se não for necessário,gastaremos esforços em sua definição e implementação que seriam mais bem gastostratando de outros requisitos. Além disso, cada requisito adicional aumenta o risco do projeto como um todo, ainda mais se a adição for dispensável. Se for ambíguo,corremos alto risco de implementá-lo errado, desagradando o cliente. Se não forverificável, não poderemos testar de maneira inequívoca se está corretamenteatendido, possibilitando discussões sobre sua realização. Se não for conciso, estamosaumentando a complexidade do documento de especificação, permitindointerpretações erradas. Se não for independente da implementação, corre o risco deestar erroneamente definido ou se tornar obsoleto, ou ainda errado, caso a tecnologiaevolua. Se não for alcançável, o projeto não terá como terminar adequadamente. Senão for completo, faltará ao projeto alguma coisa que o usuário necessita. Se não forconsistente, o projeto chegará a encruzilhadas ou talvez se torne impossível. Se nãofor ordenável, não saberemos em que momento realizá-lo, e, finalmente, se não foraceito tanto pelos usuários quanto pelos desenvolvedores, se tornará uma discussão permanente no projeto.

iii. Requisitos Mudam com o TempoTambém é importante perceber que os requisitos de um software mudam com

o tempo. Essas mudanças ocorrem porque o ambiente em que o software reside


43/312

42

também muda. Os países alteram suas leis, as organizações alteram suas práticas, atecnologia evolui, os usuários exigem novas funcionalidades até então não imaginadasou desnecessárias.

Caper Jones11, em 2005, afirmou que a taxa de mudanças de requisitos paraum software comercial chega a 3,5% ao mês, e para um software para Web, chega a4,0% ao mês. Considerando o tempo médio de execução desses e outros tipos projetos, ele chega a valores médios de 2,58% de mudanças ao mês, 14 meses emmédia de execução e 32,33% de mudança total nos requisitos. É importante notar, porém, que todas essas afirmações são baseadas em cálculos com Pontos de Função para manutenção, onde pequenas alterações podem causar grandes efeitos.

Esse fato tem efeitos em nossa prática. O primeiro é que devemos estar preparados para a mudança, pois ela vai acontecer. O segundo é que quanto maior otempo de duração do projeto, maior a quantidade de mudanças de requisitos, o queaumenta ainda mais o risco, que já é afetado pelo projeto ser longo e provavelmentecomplexo.

Assim, não só é importante conhecer os requisitos, mas também conhecer quala sua estabilidade. Requisitos pouco estáveis devem ser tratados de forma diferentedos requisitos mais estáveis12. Requisitos mais críticos devem ser tratados de formadiferente dos requisitos opcionais.

• Requisitos e NecessidadesRequisitos são originários de necessidades dos usuários estakeholders.

Enquanto os requisitos vivem no “mundo das soluções”, as necessidades vivem no“mundo dos problemas”. Os requisitos implementam as características observadas dosistema, que atendem as necessidades (Figura 18).

11 http://www.stsc.hill.af.mil/crosstalk/2005/04/0504Jones.html12 Mesmo que muitas vezes requisitos supostamente estáveis mudem, mas não há como nos prepararmos de forma economicamente viável para essa alteração.


44/312

43

Figura 18. Enquanto as necessidades surgem no mundo dosproblemas, características e requisitos definem a solução

desejada.

Um problema é uma diferença entre uma situação percebida e uma situaçãodesejada. Mais tarde vamos analisar vários tipos de problema. No momento, nos basta a noção que o problema incomoda o usuário (oustakeholder ) ao ponto deleconsiderar necessário investir alguma quantia de forma a evitar que o problemaaconteça.

É comum ouvirmos o ditado “Em time que está ganhando, não se mexe”.Quando somos chamados para desenvolver um sistema, devemos imaginarimediatamente que, se alguém deseja mexer em sua organização, então é porque nãoestá ganhando, pelo menos da maneira que supõe possível. Faz pouco sentidoimaginar que alguém iria fazer um investimento de risco, e sempre há risco

Modelagem de Sistemas de Informacao - Janeiro 2007

Documents

Transcript of Modelagem de Sistemas de Informacao - Janeiro 2007