Análise-e-projeto-de-sistemas---notas-de (1)

Análise e projeto de sistemas

Notas de aula

Prof. José Luiz Rodrigues Junior

e-mail: jluizrj@uninove.br

“A mente que se abre para uma nova idéia, jamais retorna ao seu tamanho original !” Albert Einstein

Conteúdo

4.1 – Fases do desenvolvimento de sistemas ... 6

4.2 – Ciclos de vida ... 7

4.3 – Ciclo de vida em cascata: ... 7

4.4 – Ciclo de vida em Espiral: ... 8

4.5 – Prototipação: ... 9

4.5.1 – Prototipo de alta fidelidade: ... 11

4.5.2 – Prototipo de baixa fidelidade: ... 11

4.5.3 – Abordagem do desenvolvimento de protótipos: ... 11

4.6 – Modelo incremental: ... 12

5.1 ANÁLISE CUSTO-BENEFÍCIO ... 14

5.2 GERENCIAMENTO DE RISCOS ... 14

6 – Ferramentas da análise estruturada ... 15

6.1 - O Diagrama de Fluxo de Dados ... 16

6.2 – Elementos do diagrama de fluxo de dados: ... 17

6.3 – Níveis de abstração: ... 18

6.4 – Tipos de abstração: ... 20

6.4.1 Abstração procedimental ... 20

6.4.2 Abstração de dados ... 21

6.4.3 Abstração de controle ... 21

6.5 – Regras para confecção de DFD: ... 21

6.6 – Dicionário de dados: ... 22

6.6.1 Qualificação dos dados no Dicionário de dados ... 23

6.6.2 Notação para Dicionário de dados ... 23

Localização ... 25

6.6 – Árvore de decisão: ... 26

7 – Modularização dos sistemas... 26

7.1 COESÃO... 28

7.3 ACOPLAMENTO ... 29

8 – ESTRUTURA DO PROCESSO DE ANÁLISE ... 31

8.1 – Framework para desenvolvimento e sistemas ... 31

9 – LEVANTAMENTO DE REQUISITOS ... 32

9.1 JAD – JOINT APPLICATION DEVELOPMENT ... 32

9.2 ENTREVISTA ... 34

9.3 QUESTIONÁRIO ... 35

9.4 BRAINSTORMING ... 35

9.5 ETNOGRAFIA ... 36

9.6 Definições sobre requisito ... 36

9.7 O que é um requisito? ... 36 10 – Análise de requisitos ... 37 10.1 Reconhecimento do problema ... 38 10.2 Avaliação e síntese ... 38 10.3 Modelagem ... 38 10.4 Especificação ... 38 10.5 Revisão da especificação ... 38

10.6 Rastreabilidade dos requisitos ... 39

1 – Introdução

Escrever sobre análise de sistemas é mergulhar na história do computador, pois o desenvolvimento do software encontra-se intimamente ligado ao desenvolvimento do hardware. Basta imaginar que na sua aurora, por volta dos anos de 1950, os computadores eram máquinas monstruosas, que pesavam dezenas de toneladas e não passavam, na verdade, de enormes calculadoras, com menor poder de processamento que qualquer artefato, com essa finalidade, comprado nos dias atuais, por um valor irrisório. Nos primórdios da era do computador, falar em sistemas operacionais, sistemas aplicativos, internet, interfaces gráficas e outros termos que hoje parecem banais, beirava à ficção científica. Após a construção dos primeiros computadores comerciais, a informação, cada vez mais, deixou de ser processada por meios manuais e passou a ser obtida por meios automáticos. Embora, no princípio, as linguagens de programação não fossem tão poderosas como as existentes atualmente, elas já possuíam características que permitiam a sua estruturação e também dos sistemas que através dessas linguagens eram criados. Criar um sistema nesses tempos limitava-se a criar programas que interagiam para obter um resultado esperado. Não eram adotados critérios para que o sistema não fosse apenas eficaz, mas fosse também eficiente.

Até mesmo nos dias atuais, os sistemas muitas vezes não são confeccionados de forma eficiente. Seja por problemas técnicos, como por exemplo, a falta de software de apoio adequado, ou por problemas de falta de pessoal qualificado, o fato é que se deixa de lado a oportunidade de fazer a coisa certa (Eficácia) da forma certa (Eficiência).

Este documento é um resumo sobre técnicas para a análise de sistemas. Muito embora uma grande parte dos profissionais de informática prefira deixar de lado a fase do “pensar” e passar imediatamente para a fase do “fazer”, vale lembrar que o aluno deve encarar a disciplina de “análise e projeto de sistemas” como sendo a oportunidade de aprender a fazer certo um sistema e que, de acordo com os seus conhecimentos, ele estará apto a mudar, para melhor, a mentalidade ainda existente.

2 – Definições

Antes de iniciar as abordagens sobre análise de sistemas, deve-se conhecer o significado de alguns termos que são importantes ao entendimento do conteúdo da disciplina.

2.1 – DADOS

Pode-se definir DADO, em informática, como sendo a informação básica, primitiva, que existe e é imutável em sua forma, que possui existência independente de outros dados, que não agrega novo conhecimento e que pode

ser utilizado para a geração de informação. Exemplo:

DATA_DE_NASCIMENTO.

2.2 – INFORMAÇÃO

A informação é algo que agrega conhecimento novo a um assunto. Obtém-se a informação através dos dados, ou seja, das informações básicas existentes no sistema e processadas de maneira que o seu produto possa ser

utilizado. Exemplo: Existem os dados QUANTIDADE_VENDIDA e

VALOR_UNITÁRIO. Para obter a informação VALOR_TOTAL_DA_VENDA, basta multiplicar os dados existentes para produzir o novo conhecimento.

2.3 – PROGRAMA

Um programa é uma seqüência de instruções, existentes numa determinada linguagem, que após a sua compilação ou interpretação, são convertidas em linguagem de máquina (A única LINGUAGEM que um computador entende) com o objetivo de executar um processamento para alguma finalidade prática. Os programas, para um sistema, podem ser considerados como os membros que desempenham parte dos processos que esse sistema deve executar.

2.4 – SISTEMA

Conjunto de partes que interagem, visando um objetivo específico com alguma finalidade prática. Os sistemas, em informática, podem ser considerados como sendo um conjunto de programas interdependentes que se encontram englobados num universo para o desempenho de uma tarefa. Deve,

portanto, existir uma coesão entre esses programas, de modo que eles existam para cumprir finalidades específicas dentro desse universo. Todo sistema possui os seguintes elementos :

- ENTRADA : Consiste na alimentação dos dados que serão

processados.

- PROCESSAMENTO : São os meios pelos quais os dados de

entrada serão armazenados, modificados ou utilizados para a geração de informações.

- SAÍDA : Resultados obtidos através do processamento

- RETROAÇÃO : Existe quando uma informação de saída é utilizada

como nova entrada no sistema.

2.5 – PROCESSO

Série de fenômenos sucessivos com relação de causa e efeito; por exemplo, uma empresa é uma série de causas (matérias primas, recursos humanos, tecnologia, etc.) que geram um efeito (produtos).

2.5.1 – Processo de desenvolvimento de software:

Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. É estudado dentro da área de Engenharia de Software, sendo considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos de desenvolvimento.

2.6– ANÁLISE

Dissolução de um conjunto em suas partes. Sinônimo de exame, pesquisa e verificação.

3 – O sistema na empresa

A informação, nos dias de hoje, é encarada como um produto de valor para a empresa. Uma organização que disponha de informações importantes para o seu segmento de negócio com exatidão, rapidez e qualidade estará numa situação privilegiada em relação aos seus concorrentes. Dessa forma, os sistemas que geram essas informações devem possuir características que permita reduzir custos, aumentar a produtividade e proporcionar qualidade para seus produtos e serviços.

Os principais objetivos de um sistema (Seja informatizado ou não) são os seguintes:

Geração de informações gerenciais;

Geração de informações para níveis operacionais e técnicos; Geração de informações orientadas para os setores de produção; Geração de informações que serão utilizadas entre diversos setores da organização.

A figura abaixo mostra os fluxos de informação que existem na e para a empresa.

ESTRATÉGICO

TÁTICO

OPERACIONAL MEIO AMBIENTE

Figura 1 – Fluxo de informações

- Nível Estratégico: Administração superior, diretoria da empresa. As decisões podem alterar os objetivos da empresa. Seu efeito é duradouro e pode comprometer a própria existência da empresa. Pode ser chamado também de planejamento estratégico;

- Nível Tático: Nível gerencial. São decisões que possuem efeito de médio prazo e produzem um impacto menor na organização.

- Nível Operacional: As decisões tomadas nesse nível são aquelas que contribuem para que a execução dos trabalhos da empresa sejam realizadas de forma eficaz e dentro de padrões aceitáveis.

4 – Ciclos de vida

Assim como os seres humanos possuem diversas etapas em sua vida (nascimento, crescimento, maturidade e morte), o software também possui etapas semelhantes. Talvez, a diferença principal resida no fato de que o ser humano ainda

não pode se dar ao luxo de projetar o seu próprio corpo. Um software, entretanto, pode ser projetado para ser mais eficiente, resistir mais e melhor às mudanças do ambiente que o rodeia, ser mais otimizado e versátil. Entretanto, para que isso seja possível, é necessário que se adote uma metodologia para o seu desenvolvimento, definindo as etapas que deverão ser seguidas, a forma de sua criação, implantação e manutenção.

Ciclo de vida do desenvolvimento de sistemas é o conjunto de etapas ou fases que existem para o desenvolvimento de sistemas aplicativos. Os ciclos de vida foram sendo influenciados pelo surgimento de novas linguagens de programação, por novas técnicas de modelagem de dados, pelas necessidades que dia a dia são modificadas e em função de novas tecnologias. O Desenvolvimento de sistemas é a tarefa dos profissionais da área de informática (analistas / programadores) que necessitam enxergar a realidade de seu cliente / usuário e transforma-la num modelo que seja adequado ao processamento eletrônico de dados.

Junto com a própria informática, a forma de desenvolvimento de sistemas foi sendo aprimorada e a ela foram agregadas novas técnicas e facilidades que compuseram várias metodologias.

De acordo com o dicionário Michaelis, temos as seguintes interpretações para método e metodologia, respectivamente:

“Método (lat methodu). Conjunto dos meios dispostos convenientemente para alcançar um fim e especialmente para chegar a um conhecimento científico ou comunicá-lo aos outros.” Ou simplesmente: “Maneira de fazer as coisas; modo de proceder”.

“Metodologia (Método + Logo + ia). Estudo científico dos métodos “. 4.1 – Fases do desenvolvimento de sistemas

Todo desenvolvimento de sistema, independente da metodologia aplicada, deve possuir as seguintes etapas:

1. Levantamento: tem por objetivo identificar as reais necessidades de

desenvolvimento ou manutenção de um determinado sistema, avaliando alternativas de projeto para a solução do problema.

2. Análise: tem como objetivo especificar (ou modificar) a arquitetura -

requisitos funcionais e de informação - do sistema a ser desenvolvido ou modificado.

3. Projeto: tem como objetivo definir ou modificar as características de

implementação do sistema a ser desenvolvido ou modificado.

4. Implementação: tem como objetivo construir ou modificar, integrar e

testar os diversos componentes que fazem parte do sistema.

5. Testes: tem como objetivo simular, em condições reais de operação,

a nova versão do sistema.

6. Implantação: tem como objetivo disponibilizar o novo sistema, ou

sua nova versão, para operação.

7. Manutenção: Pode ser evolutiva ou corretiva e tem como objetivo

adaptar novos requisitos ao sistema, sejam esses requisitos de ordem tecnológica ou da sua própria arquitetura.

4.2 – Ciclos de vida

A definição de um ciclo de vida, determina como essas etapas serão abordadas. A metodologia aplicada na abordagem de cada fase indica a

maleabilidade do processo de desenvolvimento:

4.3 – Ciclo de vida em cascata:

Também chamado de ciclo de vida clássico, foi a primeira forma de desenvolvimento de sistemas, surgiu no final dos anos 60 e início dos anos 70. O principal objetivo da informática naquela época, era automatizar os processos existentes. Dessa necessidade, surgiam sistemas isolados que atendiam às necessidades de automatização de áreas específicas.

Neste ciclo de vida, não é criado nenhum tipo de modelo, não são utilizadas técnicas de estruturação e praticamente não existe oportunidade para o usuário realizar alguma alteração em pontos específicos. Uma vez fechados os requisitos, eles são quase imutáveis. As atividades são realizadas em seqüência e não existem retornos entre as atividades. Toda a documentação, quando feita, é produzida após o término do projeto. O sistema é considerado como uma entidade monolítica, ou seja, não existe o conceito de segmentar o sistema em módulos e a partir dessa segmentação tratar cada módulo como um problema menor a ser resolvido.

Fica evidente que os projetos realizados com este ciclo de vida se caracterizam pela alta incidência de manutenção, pois estão sujeitos a poucas alterações durante o desenvolvimento.

Levantamento Manutenção Implantação Implementação (Codificação e Teste) Projeto Análise Dificuldades Analista Isolado Incerteza Insatisfação e Conflito com Clientes Reunião com

usuários

Figura 2 – Ciclo de vida em cascata

4.4 – Ciclo de vida em Espiral:

É um tipo de desenvolvimento de sistemas mais maleável e adaptável, se comparado ao ciclo de vida em cascata. Consiste em agregar funcionalidades ao sistema de forma evolutiva, apresentando resultados

parciais em relação à meta desejada (final do desenvolvimento do sistema) mas, os resultados que são apresentados são operacionais. Este tipo de ciclo de vida permite ainda, que sejam adaptados novos métodos ao longo do desenvolvimento do sistema.

4.5 – Prototipação:

Muitas vezes, o cliente define um conjunto de objetivos gerais para o software, mas não identifica requisitos de entrada, processamento e saída detalhados. Em outros casos, o desenvolvedor pode não ter certeza da eficiência de um algoritmo, da adaptabilidade de um sistema operacional ou da forma que a interação homem-máquina deve assumir. Nessas, e em muitas outras ocasiões, uma abordagem de prototipação à engenharia de software pode representar a melhor abordagem.

O modelo pode assumir uma das três formas:

 OPERACIONAIS: Quando aprovados pelo usuário, estão prontos para utilização (Geração de produtos acabados. Ex: Access)

 SEMI-OPERACIONAIS: Quando são necessárias poucas modificações no protótipo.

 NÃO OPERACIONAIS: Quando são voltados para análise de pontos específicos

A seqüência de eventos para o paradigma de prototipação é ilustrado na figura abaixo.

Como todas as abordagens ao desenvolvimento de software, a prototipação inicia-se com a coleta dos requisitos. O desenvolvedor e o cliente reúnem-se e definem os objetivos globais para o software, identificam as exigências conhecidas e esboçam as áreas em que uma definição adicional é obrigatória. Ocorre então a elaboração de um "projeto rápido". O projeto rápido concentra-se na representação daqueles aspectos do software que serão visíveis ao usuário (isto é, abordagens de entrada e formatos de saída). O projeto rápido leva à construção de um protótipo que é avaliado pelo cliente/usuário e é usado para refinar os requisitos para o software a ser desenvolvido. Um processo de interação ocorre quando é feita uma "sintonia fina" do protótipo para satisfazer às necessidades do cliente, capacitando ao mesmo tempo, o desenvolvedor a compreender melhor aquilo que precisa ser feito.

Idealmente, o protótipo funciona como um mecanismo para identificar os requisitos de software. Se um protótipo de trabalho for construído, o desenvolvedor tentará usar fragmentos de programas existentes ou aplicará ferramentas (por exemplo, geradores de relatórios, gerenciadores de janelas) que possibilitem que programas sejam gerados mais rapidamente.

O protótipo pode servir como "o primeiro sistema”, mas essa pode ser uma visão idealizada. Como no ciclo de vida clássico, a prototipação como paradigma da engenharia de software pode ser problemática pelas seguintes razões:

O cliente vê aquilo que parece ser uma versão de trabalho do software,

desconhecendo que o protótipo se mantém unido de maneira frágil, sem saber que, na pressa de colocá-lo em funcionamento, não levamos em consideração a qualidade global do software e a manutenibilidade a longo prazo. Quando informamos que o produto precisa ser reconstruído, o cliente reclama e exige que alguns acertos sejam aplicados para tornar o protótipo um produto de trabalho. Muito freqüentemente, a gerência de desenvolvimento de software cede.

O desenvolvedor muitas vezes faz concessões de implementação a fim de colocar um protótipo em funcionamento rapidamente. Um sistema operacional ou linguagem de programação imprópria pode ser usada simplesmente porque está à disposição e é conhecida; um algoritmo ineficiente pode ser implementado simplesmente para demonstrar capacidade. Depois de

algum tempo o desenvolvedor pode familiarizar-se com essas opções e esquecer-se de todas as razões pelas quais elas são inadequadas. A opção menos que ideal se tornou, então, parte integrante do sistema.

Ainda que possam ocorrer problemas, a prototipação é um paradigma eficiente da engenharia de software. A chave é estipular, logo no começo, as regras do jogo, ou seja, o cliente e o desenvolvedor devem concordar que o protótipo seja construído para funcionar como um mecanismo de definição de requisitos. Ele será depois descartado (pelo menos em parte) e o software ideal será projetado, levando-se em conta a qualidade e a manutenibilidade.

4.5.1 – Prototipo de alta fidelidade:

Um protótipo de alta fidelidade permite uma visão suficientemente realista para testar idéias com o público-alvo antes de fazer um investimento significativo. Isto permite descobrir se os usuários serão capazes de entender como usar o produto. Os protótipos de alta-fidelidade, geralmente, são confeccionados por meio de softwares que permitem a confecção de protótipos semi-operacionais, mas que conseguem reproduzir, por exemplo, a navegação entre telas e diversos outros recursos operacionais.

4.5.2 – Prototipo de baixa fidelidade:

Um protótipo de baixa fidelidade é encarado como um rascunho sobre o que se deseja criar, ou seja, não é uma representação exata, mas uma ideia sobre o que se deseja.

4.5.3 – Abordagem do desenvolvimento de protótipos:

Os protótipos podem ser criados com o objetivo de desenvolver uma implementação inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por meio de muitas versões. Esse tipo de abordagem é conhecido como EVOLUCIONÁRIO. A especificação, desenvolvimento e validação são executados concorrentemente para gerar um retorno rápido.

Em outra abordagem, o protótipo é criado para esclarecer requisitos e produzir informações para os gerentes avaliarem o risco do projeto. Depois da avaliação, o protótipo é descartado, não sendo mais usado no desenvolvimento do sistema. Esse tipo de abordagem é conhecido como DESCARTÁVEL.

4.6 – Modelo incremental:

O modelo incremental combina elementos do modelo cascata (aplicado repetidamente) com a filosofia iterativa da prototipação. O objetivo é trabalhar junto do usuário para descobrir seus requisitos, de maneira incremental, até que o produto final seja obtido.

A versão inicial é frequentemente o núcleo do produto (a parte mais importante). O desenvolvimento começa com as partes do produto que são mais bem entendidas e a evolução acontece quando novas características são adicionadas à medida que são sugeridas pelo usuário.

O desenvolvimento incremental é importante quando é difícil, ou mesmo impossível, estabelecer a priori uma especificação detalhada dos requisitos. As primeiras versões podem ser implementadas com poucas pessoas e se o núcleo do produto for bem recebido, pessoas adicionais podem ser colocadas para a implementação da nova versão. As novas versões podem ser planejadas de modo que os riscos técnicos possam ser administrados.

Exemplos:

- O sistema pode exigir a disponibilidade de um hardware que está em desenvolvimento e cuja data de liberação é incerta;

- Pode-se planejar pequenas versões de modo a evitar o uso desse hardware;

O Modelo Incremental

Atividades

Paralelas

- O software com funcionalidade parcial pode ser liberada para o cliente.

O modelo incremental é mais indicado para sistemas pequenos onde os problemas de mudança podem ser contornados através da re-implementação do sistema todo, quando mudanças substanciais se tornam necessárias.

No modelo incremental os testes podem ser mais efetivos, pois é mais fácil testar cada versão do sistema do que o sistema todo no final.

5 – Estudo de viabilidade do sistema

O estudo de viabilidade faz parte do processo de engenharia de

requisitos que deve descrever o sistema de forma abrangente e como ele será

utilizado na organização. Após a entrega do relatório contendo essa análise, o

analista de sistemas deve ter respondido às seguintes perguntas:

1. O sistema contribui, de forma efetiva, para os objetivos da

organização?

2. O sistema proposto pode ser implementado com as

tecnologias atuais considerando-se os prazos e o custo

determinados?

3. O sistema proposto poderá ser integrado aos sistemas já

existentes na organização?

A coleta das informações que responderão a essas perguntas deve

ser feita junto às fontes primárias, ou seja, os envolvidos e interessados no

projeto (Stakeholders), que podem ser gerentes de departamentos em que o

sistema será utilizado, usuários dos processos que o sistema afetará, clientes

da organização, entre outros. Outras questões devem ser feitas a essas fontes:

1. Se o sistema proposto não for implementado, qual o impacto para

a organização?

2. Quais os problemas apresentados pelo sistema atual e como o

sistema proposto eliminaria ou diminuiria esses problemas?

3. Quais os benefícios que o sistema proposto trará para a

empresa?

4. Será possível o intercâmbio de dados entre o sistema proposto e

os sistemas existentes na organização?

5. O sistema proposto requer tecnologia que não tenha sido utilizada

anteriormente na organização?

Após a conclusão do estudo de viabilidade, o relatório obtido deverá

fornecer uma visão clara da situação e a recomendação para que o sistema

seja desenvolvido ou não.

5.1 ANÁLISE CUSTO-BENEFÍCIO

A análise de custo benefício é um conjunto de técnicas que visam

gerar informações sobre a relevância prática da execução de um projeto

de desenvolvimento de software.

Todo projeto de desenvolvimento de software deve, como foi visto

anteriormente, atender às necessidades do cliente. Deve também,

atender aos interesses da organização onde esse sistema estará

inserido. Neste último quesito, é importante que o custo para a

implantação do sistema proposto seja racional e não exceda os custos

se o mesmo não for implantado.

Custos de Hardware são considerados como sendo de capital e são

diluídos ao longo da vida útil do sistema, ou seja, se houve a

necessidade de aquisição de equipamentos para que o SW funcione,

esses custos são contabilizados e vão sendo pagos à medida que o SW

funcione e cumpra a sua função. Os custos de instalação, entretanto,

são contabilizados quando ocorrem, ou seja, somente no momento de

sua necessiadade.

5.2 GERENCIAMENTO DE RISCOS

Um fator importante a ser considerado para a execução de um

projeto são os riscos que esse projeto pode sofrer. De maneira simples,

um risco é a probabilidade da ocorrência de um acontecimento adverso

e podem ser categorizados em três diferentes tipos:

1. Riscos relacionados ao projeto, quando afetam os recursos ou o

cronograma do projeto;

2. Riscos relacionados ao produto, que focam fatores que podem

influenciar negativamente na qualidade ou no desempenho do

produto;

3. Riscos para os negócios, que afetam a organização que está

desenvolvendo ou adquirindo um produto de software.

Dificilmente, todos os riscos podem ser identificados no início do

projeto. Trata-se, portanto, de uma tarefa iterativa, isto é, evolui ao longo

do desenvolvimento do projeto.

Para auxiliar no processo de identificação dos riscos, pode ser

utilizada uma lista destacando-se os tipos, tais como:

1. Riscos tecnológicos, que se apresentam no software ou no

hardware. Exemplo: Sistema gerenciador de banco de dados que

não suporta a quantidade de transações como era esperado;

2. Riscos referentes ao pessoal, que estão associados à equipe de

desenvolvimento. Exemplo: Não são encontradas pessoas com o

perfil requerido para o desenvolvimento do projeto;

3. Riscos organizacionais, que derivam do ambiente da própria

organização. Exemplo: Problemas financeiros que reduzem as

verbas para o desenvolvimento do projeto;

4. Riscos relativos às ferramentas, que são ocasionados pela falta

de ferramentas adequadas ao desenvolvimento do software.

Exemplo: Softwares de apoio não estão disponibilizados

(Ferramentas CASE), ou são ineficientes;

5. Riscos ocasionados pela mudança de requisitos, que ocorrem

devido

a

modificações

extensas

que

necessitam

ser

implementadas antes que o desenvolvimento do software chegue

ao seu fim. Exemplo: Alteração das regras de negócio devido a

modificações na política fiscal do governo.

6. Riscos quanto à estimativa, que são observados quando o tempo

ou o custo estimado para o desenvolvimento do sistema não é

suficiente. Exemplo: O tamanho do sistema não foi estimado de

forma adequada.

6 – Ferramentas da análise estruturada

A análise estruturada substitui a antiga especificação funcional por uma especificação estruturada, com as qualidades de ser:

- Gráfica e concisa: A especificação estruturada contém símbolos do sistema, em vez de explicações por escrito;

- Não redundante: Na especificação estruturada, uma informação é guardada (Gravada) uma única vez;

- Segmentada de cima para baixo (top-down): Como o sistema é dividido em partes tão independentes quanto possível, o usuário pode revê-lo em

segmentos pequenos e simples.

- Lógica, e não física: Usando a especificação estruturada, o usuário adquire um entendimento claro do sistema que está sendo especificado e o projetista pode criar um projeto estruturado mais rapidamente e mais acurado do que poderia fazer a partir da antiga especificação funcional.

Para que o desenvolvimento de um projeto de sistema seja considerado estruturado, além das qualidades acima descritas, um conjunto de ferramentas deve ser utilizado:

Diagrama entidade-relacionamento; Diagrama de fluxo de dados (DFD); Dicionário de dados;

Ferramentas para especificar processos: Português estruturado, árvore e tabelas de decisão;

Essas ferramentas não só permitem ao analista os meios de conseguir uma análise disciplinada e acurada, mas também compreendem o produto final da análise - a especificação estruturada.

6.1 - O Diagrama de Fluxo de Dados

É importante que todos os dados, não estruturados (atas, anotações etc.), coletados pelo analista sejam resumidos. Este resumo deve simplificar a comunicação entre usuário e equipe técnica. Entretanto este resumo não deve levar o analista a conclusões prematuras. O diagrama de fluxo de dados é uma representação gráfica que exprime este resumo. O diagrama não depende de questões como hardware, software, estrutura de dados, ou seja, o diagrama é lógico.

O diagrama de fluxo de dados é utilizado para particionar um sistema e, juntamente com o dicionário de dados é a principal ferramenta da análise estruturada e o principal componente da especificação estruturada. É devido a

essa ferramenta que a especificação estruturada tem as qualidades desejadas: gráfica, concisa, particionada e não-redundante. Um DFD é uma representação em rede de um sistema e mostra os componentes ativos do mesmo e as interfaces de dados entre eles. Nos DFDs deve-se simplificar a representação do sistema, para isso não deve existir a preocupação com informações de erro ou condições em desuso. A questão é descrever o que acontece e não como.

6.2 – Elementos do diagrama de fluxo de dados:

- Fluxo de dados: Representa a movimentação e a direção que os dados devem seguir, indicando se os mesmos são entrada ou saída do sistema.

- Depósito de dados: Trata-se de um repositório atemporal. É um local de “espera” dos dados. Pode representar um elemento do diagrama que tende a se tornar uma base de dados do sistema.

- Processo: A função do processo pode sofrer uma alteração na sua definição dependendo do nível de DFD em que está inserido. No DFD nível 0 (zero), ou DFD de contexto, ele representará o mais alto nível de abstração. Por esse motivo, existirá somente um símbolo de processo representando o sistema como um todo. Nos demais níveis, onde a abstração será mais baixa, ele poderá representar um programa ou um conjunto de programas (Rotinas).

Os processos, nos DFD, são apenas representações gráficas que, visualmente, facilitam a compreensão do que deve ser feito. Entretanto, não especificam “COMO” deve ser realizada a implementação do processo. Para essa finalidade, deve ser

confeccionado um documento, normalmente denominado

“Especificação funcional”, “Descrição funcional” ou ainda, “Especificação de requisito”, que tem a finalidade de, textualmente, identificar detalhadamente, como o processo deve ser realizado.

- Entidade externa: Identifica a origem do dado quando requerido pelo sistema e o destino do dado quando este é produzido pelo sistema. Pode representar: Uma pessoa, um conjunto de pessoas, uma empresa ou conjunto de empresas, um outro sistema (Interno ou externo à instituição).

(Rótulo) PROCESSO DEPÓSITO DE DADOS ENTIDADE EXTERNA FLUXO DE DADOS 6.3 – Níveis de abstração:

Entende-se por abstração a omissão dos detalhes. Pode-se,

entretanto, variar essa abstração no diagrama de fluxo de dados

partindo-se de uma abstração maior para uma abstração menor. Esse

conceito contempla a estrutura top-down, já mencionada.

O DFD nível zero é a representação da maior abstração possível

e inteligível do sistema que será confeccionado. Sua função é mostrar,

sem maiores detalhes, o relacionamento entre o sistema e as entidades

externas, através da conexão desses elementos pelos fluxos de dados.

Os DFDs de nível mais alto mostram uma abstração cada vez

menor, ou seja, a cada nível, os detalhes tornam-se cada vez mais

presentes.

T7 - SISTEMA DE SOLICITAÇÃO E CONTROLE DE VALES ALIMENTAÇÃO/REFEIÇÃO

Pedidos Informações sobre

órgãos Informações sobre funcionários

Relatório de recebimento mensal

SISTEMA DE DISTRIBUIÇÃO E SOLICITAÇÃO DE VALES ALIMENTAÇÃO/REFEIÇÃO - DFD NÍVEL 0

Ordem de execução Anual Informações Cadastrais fornecedores ÁREA DE BENEFÍCIOS SISTEMA T1 FORNECEDOR ÓRGÃO Ordem de execução Mensal Relatório de recebimento Anual P:0 Dados benefícios Ref./Alim. Relatório para conferência

No DFD acima, os elementos que recebem e/ou enviam informações do sistema encontram-se ligados a ele pelos fluxos de dados. As entidades externas, como o próprio nome indica, são elementos que se encontram “fora” do sistema mas mantêm contato com ele.

SISTEMA DE DISTRIBUIÇÃO E SOLICITAÇÃO DE VALES ALIMENTAÇÃO/REFEIÇÃO - DFD NÍVEL 1 Á REA DE BENEFÍCIO S EM IT IR RELA T O RIO T O DO S O S FUNC IO NA RIO S EM IT IR REL. FUNC IO NA RIO S NO V O S /REA LO CA DO S O rdem de execução A nual Informações cadastrais dos

fornecedores M A NUT ENÇ Ã O C A DA ST RO DE FO RNEC EDO RES (inc./Excl./A lt.) O rdem de execução mensal P 1 P 2 P 3 GERA Ç Ã O DE C A DA ST RO DE P EDIDO S A O FO RNEC EDO R P 4 FUNCIONARIOS 1 Informs. funcs. Ó RGÃ O S Relatorio de recebimento Informs. funcs. Informs. funcs. Relatorio de recebimento D ados Benefícios refeição/alimentação FORNECEDORES D ados do fornecedor Incluidos / alterados D ados do fornecedor ÓRGÃOS 2 3 D ados do órgão PEDIDOS 4 ENV IO DO A RQ UIV O DE P EDIDO S A O FO RNEC EDO R P 5 FO RNEC EDO R

P edidos para env io ao fornecedor D ados dos P edidos D ados do fornecedor D ados do pedido D epósitos alimentados pelo S istema T1 D ados do órgão D ados do órgão

Relatório para conferência

O DFD acima é uma “explosão” do DFD nível zero, ou seja, é como se o DFD nível zero tivesse sido aberto e pudesse ser visto o seu interior. Fazendo uma analogia, pode-se imaginar um relógio de pulso. O relógio em si, é um sistema que fornece o horário, data do dia e outras tantas funções. Pois bem, a visualização do relógio é o nível zero. Se houver a necessidade de saber como os ponteiros funcionam, haveria a necessidade de abrir o relógio e visualizar o seu interior. A visualização do interior do relógio é o nível 1. Se ainda houvesse a necessidade de se conhecer as informações que se instalam no CHIP (Relógios eletrônicos), haveria a necessidade de detalhar ainda mais, portanto, seria o nível 2.

No exemplo acima, existiria um nível 2 caso qualquer um dos processos existentes no nível 1 fosse explodido.

6.4 – Tipos de abstração:

6.4.1 Abstração procedimental



Ex.: A frase “ENTRE PELA PORTA” traduz uma

sequência de passos procedimentais (Caminhe

até a porta, aproxime-se, segure a maçaneta,

gire a maçaneta, etc...).

6.4.2 Abstração de dados

 Coleção de dados que descrevem um objeto de dados.



Ex.: “CONTRACHEQUE DE PAGAMENTO”

indica uma coleção de informações diferentes:

Nome da pessoa que está recebendo, quantia

recebida, impostos retidos, etc...

6.4.3 Abstração de controle

 Indica mecanismos de controle do programa sem

especificar detalhes internos.

 Sincronizador

de

tarefas:

Utilizado

para

coordenar atividades de um sistema operacional.

6.5 – Regras para confecção de DFD:

Algumas regras básicas devem ser seguidas para que as informações contidas no DFD sejam compreensíveis e válidas. São elas:

1. Não pode existir relacionamento, através de fluxo de dados, entre entidades externas.

ENTIDADE A Fluxo de dados ENTIDADE B

2. Não pode existir relacionamento entre entidade externa e depósito de dados.

ENTIDADE A

Fluxo de dados

DEPÓSITO A

DEPÓSITO A DEPÓSITO B

Fluxo de dados

4. O DFD nível zero deve mostrar somente os relacionamentos, através dos fluxos de dados, entre as entidades externas e o sistema, sendo este último composto por somente um símbolo de processo.

6.6 – Dicionário de dados:

Um Dicionário de Dados (do inglês Data Dictionary) é uma coleção de metadados* que contêm definições e representações de elementos de dados.

Dentro do contexto de SGBD, um dicionário de dados é um grupo de tabelas e visões, habilitadas apenas para leitura ou consulta, ou seja, é uma base de dados, propriamente dita, que entre outras coisas, mantém as seguintes informações:

- Definição precisa sobre elementos de dados; - Perfis de usuários, papéis e provilégios; - Descrição de objetos;

- Integridade dos dados e;

- Informações sobre a verificação dos dados.

Um dos benefícios de um dicionário de dados bem preparado é a consistência entre itens de dados através de diferentes tabelas. Por exemplo, diversas tabelas podem conter números de telefones; utilizando uma definição de um dicionário de dados bem feito, o formato do campo 'número de telefone' definido com "( )9999-9999" deverá ser obedecido em todas as tabelas que utilizarem esta informação.

Quando uma organização constrói um dicionário de dados de dimensão corporativa, o intuito deve ser o de padronizar precisamente definições semânticas a serem adotadas na empresa toda; portanto, ele deve incluir tanto definições semânticas como de representação para elementos de dados, sendo que os componentes semânticos focam na criação precisa do significado dos elementos de dados, e de outro lado, as definições de representação indicam como os elementos de dados são armazenados em uma estrutura de

computador de acordo com seu tipo, ou seja, se são dados do tipo inteiro, caracter ou formato de data.

Os dicionários de dados são mais precisos que glossários (termos e definições) porque costumam ter uma ou mais representações de como o dado é estruturado e podem envolver ontologias completas quando lógicas distintas sejam aplicadas a definições desses elementos de dados.

Os dicionários de dados são gerados, normalmente, separados do Modelo de Dados visto que estes últimos costumam incluir complexos relacionamentos entre elementos de dados.

Dicionários de dados descrevem, também, o significado dos fluxos de dados do sistema e composição dos pacotes de dados que trafegam dos processos para os depósitos de dados.

6.6.1 Qualificação dos dados no Dicionário de dados

Os dados que serão descritos no DD podem ser

ELEMENTARES ou COMPOSTOS. Um dado elementar é um

dado que não pode ser decomposto, ou seja, trata-se de um valor

sem possibilidade de ter o seu conteúdo seccionado, não existe

decomposição significativa no contexto do ambiente do usuário.

Já os dados compostos, são formados por vários elementos que

podem ser identificados individualmente.

6.6.2 Notação para Dicionário de dados

Segundo Yourdon, a notação utilizada para os dicionários

de dados é a que segue:

= é composto de;

+ e;

( ) opcional (pode estar presente ou ausente);

{ } iteração;

[ ] escolha uma das opções alternativas;

** comentário;

@ identificador (campo chave) de um depósito;

| separa opções alternativas na construção [ ].

Número = [0-9]

-

Indica que podem ser utilizados

os números de 0 a 9;

Sexo = [F | M]

-

Indica que deve ser escolhido “F”

ou “M”;

Telefone = Cod_Pais + Cod_Operadora + (DDD) +

(Numero-Assinante)

- Telefone é definido como um Cod_Pais e uma Operadora

e um DDD e um Numero_Assinante ou

- Telefone é definido como um Cod_Pais e uma Operadora

e um DDD ou

- Telefone é definido como um Cod-Pais e uma Operadora

e um DDD ou

- Telefone é definido como um Cod_Pais e um

Numero_Assinante.

DadoX =

{0}

DadoX é definido como, no mínimo 1 número zero e no

máximo muitos números zero.

DadoY = {0}

DadoY é definido como, no mínimo, nenhum número zero

e, no máximo, dez números zero.

DadoZ =

{0}

DadoZ é definido como, no mínimo, um número zero e, no

máximo, dez números zero.

DadoK=

{0}

DadoK é definido como possuindo sempre dez números

zero.

* Metadados, ou Metainformação, são dados capazes de descrever outros dados, ou seja, dizer do que se tratam, dar um significado real e plausível a um arquivo de dados,são a representação de um objeto digital.De acordo com a definição do W3C, metadados são informações localizadas na web, inteligíveis por um computador. Mais sinteticamente, podemos dizer que um metadado é um dado utilizado para descrever um dado primário.

NOME: NOME-DO-FUNCIONÁRIO Pseudônimo : NOMFUNC; NFUN Descrição : Nome do funcionário

Formato : Texto; 50 posições

Localização

Relatórios : IIFU01; IIRT01

Os Campos existentes no dicionário de dados podem variar, entretanto, os que foram apresentados acima constituem o mínimo desejável. Segue abaixo uma breve descrição de cada um:

NOME : Deve ser simples e que reflita o propósito a que ele se refere. PSEUDÔNIMO: O pseudônimo de um campo o identifica por um nome diferente daquele que foi considerado oficial (NOME). Este recurso é utilizado para que as regras de nomeação de determinadas linguagens sejam respeitadas.

DESCRIÇÃO: Descrição sucinta sobre a utilização do conteúdo do campo.

FORMATO: Tipo de conteúdo que o campo pode receber e tamanho. Este tipo de informação pode variar de acordo com o tipo de linguagem utilizada. Deve-se, portanto, identificar o formato de uma maneira genérica, que passe a idéia, sem recorrer a termos técnicos de uma linguagem específica.

TABELAS: Bases de dados onde o campo está presente. A modelagem de dados prevê que um determinado dado não deve possuir redundância dentro da organização. Dessa forma, o campo em questão

deve figurar em somente um local. Entretanto, caso o campo seja a chave de uma tabela, é possível que ele se encontre em outros locais como chave estrangeira.

TELAS: Neste item, caso o campo seja recebido ou exibido através de interface gráfica, devem ser informados os locais onde ele pode ser visualizado.

RELATÓRIOS: Analogamente à tela, um relatório também é um tipo de interface gráfica, embora não interativa. Caso o campo seja exibido em relatórios, estes devem ser mencionados neste item.

Outros itens podem ser acrescentados, tais como: Validade, Informações de grupo, Tipos de consistência, etc.

6.6 – Árvore de decisão:

Árvore de Decisão é uma técnica de utilizada para a tomada de decisão baseada na teoria dos grafos. As árvores de decisão são representações simples do conhecimento e, um meio eficiente de construir classificadores que predizem classes baseadas nos valores de atributos de um conjunto de dados.

As árvores de decisão consistem de nodos que representam os

atributos, de arcos, provenientes destes nodos e que recebem os valores possíveis para estes atributos, e de nodos folha, que representam as diferentes classes de um conjunto de treinamento.

Uma árvore de decisão tem a função de particionar recursivamente um

conjunto de treinamento, até que cada subconjunto obtido deste particionamento contenha casos de uma única classe. Para atingir esta meta, a técnica de árvores de decisão examina e compara a distribuição de classes durante a construção da árvore. O resultado obtido, após a construção de uma árvore de decisão, são dados organizados de maneira compacta, que são utilizados para classificar novos casos.

7 – Modularização dos sistemas

A abordagem de um problema, como no caso da confecção de um

sistema, deve obedecer a critérios que possibilitem a decomposição desse

problema em problemas menores. Quando uma decomposição é feita,

entretanto, geralmente devem ser seguidas determinadas regras para que essa

decomposição seja realizada de forma correta. Os problemas, quando

encarados por inteiro, de forma monolítica, tendem a se tornar muito mais

difíceis de resolver. Dividindo o problema em problemas menores, a resposta é

mais eficiente, o problema é mais bem entendido e muito mais fácil de resolver.

Uma analogia que podemos fazer é o de uma expressão numérica:

{9 + 8 + [49 + (36 / 2) - 3]}

No primeiro grau do ensino fundamental esse tipo de problema é

comum. Os alunos são orientados no sentido de que devem ser resolvidos

primeiramente os cálculos que se encontram entre os parênteses, logo após,

os cálculos que se encontram entre os colchetes e, finalmente, o cálculo que

se encontra entre as chaves.

O que foi feito, é uma segmentação do problema. Dessa forma,

passa a existir uma série de problemas menores que, quando resolvidos em

sua totalidade, apresentam o resultado final ao problema apresentado.

Na área de desenvolvimento de sistemas esse procedimento recebe

o nome de modularização, ou seja, dividir o sistema em módulos que

possuam elementos que necessitam trabalhar em conjunto para a realização

de uma função específica.

Figura 1 – Divisão de um sistema em módulos

De acordo com o que foi exposto, pode-se concluir que quanto mais

segmentado for o problema, mais fácil se torna a sua resolução, certo?

ERRADO!!!!!!

A decomposição de um sistema deve obedecer a determinadas

condições, sendo que as duas principais são conhecidas como COESÃO e

ACOPLAMENTO.

7.1 COESÃO

Medida que é interpretada como a força funcional de um módulo que

mantêm unidos os seus elementos. De forma simples, um módulo é composto

por diversos elementos que devem estar relacionados de uma determinada

forma para que a função do módulo seja desempenhada com sucesso. Essa

forma de relacionamento pode ser realizada das seguintes maneiras:

Figura 2 – Escala de coesão

FUNCIONAL:

Todos os elementos do módulo estão relacionados

SEQÜENCIAL:

Os dados de saída de um elemento do módulo

servem como entrada para o próximo elemento.

COMUNICACIONAL:

Os elementos do módulo referenciam os mesmos

dados de entrada e ou saída.

PROCEDIMENTAL:

Os elementos do módulo encontram-se juntos porque o

procedimento adotado para solucionar o problema colocou-os dentro de uma

mesma unidade do algoritmo.

LÓGICA:

Os elementos do módulo estão envolvidos em tarefas similares.

TEMPORAL:

Os elementos devem ser processados num mesmo período de

tempo.

COINCIDENTAL:

Os elementos não têm razão aparente para estarem juntos.

7.3 ACOPLAMENTO

O acoplamento pode ser definido como sendo o grau de

interdependência entre os módulos. Em termos simples, cada módulo, como

faz parte de um todo, não pode ser totalmente independente dos demais

módulos, porém, a dependência que existir, não pode ser de tamanha monta

que interfira significativamente nas atribuições do módulo. Caso isso ocorra,

deve-se estudar a possibilidade de construir um único módulo.

ACOPLAMENTO POR DADOS:

A comunicação entre os módulos é feita por

parâmetros, sendo cada parâmetro, composto por um dado elementar ou uma

base de dados.

ACLOPAMENTO POR IMAGEM:

A comunicação entre os módulos é feita

através de estruturas de dados.

ACOPLAMENTO POR CONTROLE:

Envolve a passagem de variável de

controle.

ACOPLAMENTO EXTERNO:

Os módulos são ligados de um ambiente externo

ao software.

ACOPLAMENTO COMUM:

Os módulos se referem à mesma área de dados

global.

ACOPLAMENTO POR CONTEÚDO:

Um módulo faz uso de dados ou

informações de controle, mantidos dentro dos limites de outro módulo.

Para entender melhor os conceitos de Coesão e Acoplamento,

pode-se recorrer a uma analogia: imaginemos um carro, por exemplo. Se

considerarmos o carro como um sistema, podemos chama-lo de VEÍCULO.

Pois bem, esse sistema, denominado VEÍCULO, é composto por diversos

elementos (Motor, Freios, Suspensão, Direção, Rodas, etc.), que poderíamos

chamar de Módulos. Cada um desses Módulos, por sua vez, também é

composto por diversos elementos (O motor é composto por Pistões, válvulas,

velas, etc.). Para que o módulo MOTOR funcione corretamente, todos os

elementos que o compõe devem trabalhar de forma coesa, uniforme e

harmônica. Isso é a COESÃO. Por sua vez, todos os módulos que compõem o

sistema VEÍCULO devem também trabalhar de forma interdependente, fazendo

com que o sistema realize o seu objetivo. Isso é o ACOPLAMENTO.

Para que um sistema funcione de forma perfeita, deve existir uma

ALTA COESÃO dos elementos de um módulo e um BAIXO ACOPLAMENTO

entre os módulos, ou seja, deve existir uma grande harmonia entre as peças

que compõem um módulo e uma baixa dependência de cada módulo em

relação aos demais.

8 – ESTRUTURA DO PROCESSO DE ANÁLISE

A confecção de um processo de análise é variável de empresa para empresa. Geralmente, nas grandes organizações, existe um setor especializado em metodologia que desenvolve um framework que determinará os artefatos que devem ser produzidos para o desenvolvimento de um sistema aplicativo. Esse método será então, o “modo de fazer” um sistema dentro dessa empresa.

Independente dos documentos que devam ser produzidos no processo existem determinadas etapas que são comuns a todo framework de desenvolvimento de sistemas:

- Solicitação e identificação do usuário; - Análise de requisitos; - Projeto lógico; - Projeto físico; - Implementação; - Implantação; - Manutenção.

8.1 – Framework para desenvolvimento e sistemas 1) Solicitação e identificação do usuário

a. Correspondência interna (Memorando, comunicado oficial, e-mail, solicitação de serviços, etc...)

b. Ata de reunião ou Relatório de reunião 2) Análise de requisitos

a. Histórico da empresa b. Missão da empresa c. Visão da empresa

d. Organograma (Localização da área de atuação do sistema) e. Numerologia

f. Funcionograma

g. Declaração de delimitação e objetivos h. Sistemograma atual

i. Sistemograma proposto

j. Cronograma (Gráfico de Gantt) k. Análise custo x benefício 3) Projeto lógico

a. Modelagem de dados (Nível conceitual e lógico) b. Dicionário de dados

c. DFD nível 0

d. DFD’s níveis mais detalhados

e. Quadro IPO – Português estruturado 4) Projeto físico

b. Fluxogramas

c. Definição de telas e relatórios d. Definição de programas 5) Implementação

a. Codificação dos programas b. Testes unitários

c. Testes de sistema

d. Treinamento dos usuários 6) Implantação

a. Migração

b. Alimentação das bases de dados 7) Manutenção

a. Evolutiva b. Corretiva c. Preventiva

9 – LEVANTAMENTO DE REQUISITOS

O levantamento de requisitos, isto é, a coleta dos requisitos necessários

para a confecção do sistema, pode ser efetuada de diversas formas. As mais

comuns são apresentadas abaixo:

9.1 JAD – JOINT APPLICATION DEVELOPMENT

Buscando uma solução para as deficiências encontradas na fase de

levantamento de informações, Chuck Morris, consultor da IBM, no

Canadá, idealizou este método que substitui as entrevistas individuais

por reuniões em grupo, onde participam os representantes do

cliente/usuário e os representantes da área de desenvolvimento de

sistemas.

Benefícios da técnica JAD

1. Maior produtividade – Aumento de 20 a 60% na produtividade, se

comparado a métodos tradicionais;

2. Qualidade superior

– A interação entre usuário e analista

proporciona um melhor entendimento do problema, fazendo com

que o produto final esteja o mais próximo possível das

necessidades reais;

3. Cooperação

– O trabalho em equipe promove o senso de

cooperação e a busca de soluções que sejam benéficas a todos

os envolvidos;

4. Menor custo de desenvolvimento e manutenção – A interpretação

correta para o desenvolvimento do sistema elimina a correção

posterior.

Decisões baseadas em consenso

Entende-se por consenso a concordância de cada membro do grupo

com a solução encontrada, mesmo que esta não seja a de sua

preferência, mas que é vista como a mais coerente para o benefício de

todos. As sessões de JAD são baseadas nessa premissa.

Sessões de JAD - Papéis

Facilitador

– Não avalia nem contribui com ideias. Deve

ser neutro e coordenar as sessões de forma imparcial e promover

a comunicação e negociação entre os membros do grupo.

Geralmente é uma pessoa com grande experiência na técnica;

Patrocinador

– É o cliente ou usuário principal do sistema

que será criado. Deve fornecer uma visão estratégica para os

participantes, fazendo-os entender a importância do projeto e

porque eles estão envolvidos;

Documentador

– Registra as conclusões do grupo. Pode

ou não contribuir com idéias para o projeto. Deve, a cada nova

sessão, fazer uma síntese da reunião anterior;

Observadores

– Pessoas interessadas em aprender a

técnica para utilização em seus projetos;

Indicador de assunto

– Garante que todos os pontos

inicialmente agendados, sejam cumpridos. Geralmente é um

representante do cliente que entende do assunto de negócio

tratado;

Representante dos usuários

– Representa os usuários

das áreas envolvidas. Suas observações são importantes, pois

refletem as necessidades de quem, efetivamente, trabalhará com

o sistema;

Especialista

– É uma pessoa que oferece detalhes sobre o

assunto. Deve ser versado nas regras de negócio que envolve as

soluções que podem ser encontradas.

Figura 1 – Exemplo de sala preparada para sessão de JAD

Dentre as técnicas adotadas pelos desenvolvedores para o

levantamento de requisitos, uma das mais utilizadas é a ENTREVISTA.

Geralmente, essa técnica é utilizada para obter informações sobre como

o sistema atual (Seja informatizado ou manual) se comporta e o que o

cliente/usuário espera do novo sistema. É uma identificação estratégica

sobre o novo sistema. Deve-se, entretanto, tomar algumas precauções

em relação à sua condução:

a) Definir os objetivos e informá-los ao entrevistado;

b) Selecionar usuário adequado aos objetivos;

c) Preparar um roteiro da entrevista com antecedência;

d) Não se desviar dos objetivos;

e) Separar opiniões de fatos;

f) Não prolongar a entrevista;

g) Aceitar sugestões, mas sem o comprometimento de

incorporá-las;

9.3 QUESTIONÁRIO

A escolha desta técnica é indicada quando o grupo de usuários

que possuam contribuição potencial para o projeto encontre-se

geograficamente disperso, sendo impossível a entrevista ou sessões de

JAD.

Vários podem ser os formatos para os questionários, como por

exemplo: Múltipla escolha, lista de verificação ou questões com lacunas

para preenchimento. Qualquer que seja o formato, as questões devem

ser elaboradas de forma simples e clara, não deixando espaço para

interpretações equivocadas ou com duplo sentido.

Deve-se ter o cuidado de, através de uma carta explicativa,

geralmente enviada por um alto executivo, salientar a importância das

respostas dentro de um tempo pré-determinado.

Deve-se ainda, ter o cuidado de agrupar as questões pelo seu

formato (Dissertativa, múltipla escolha, etc.) e pelo seu conteúdo,

direcionando-as a quem realmente tenha o conhecimento necessário

para respondê-las.

9.4 BRAINSTORMING

Brainstorming consiste em uma ou várias reuniões para permitir

às pessoas envolvidas com o projeto exporem as suas ideias. Para que

haja sucesso na adoção desta técnica, alguns cuidados devem ser

observados:

1. Seleção dos participantes: Devem ser selecionadas as pessoas

que possam contribuir de forma direta com os objetivos para a

solução do problema e possuam conhecimentos relevantes sobre

o negócio;

2. Explicar a técnica e as regras a serem seguidas: Deve-se

eleger um líder para a condução das sessões que definirá as

regras e explicará os conceitos básicos da técnica;

3. Incentivo à produção de ideias: Os participantes devem ser

incentivados a participar expondo suas ideias por mais absurdas

que possam parecer. Geralmente, ideias que em um primeiro

momento pareçam disparatadas, podem ser lapidadas para algo

concreto.

9.5 ETNOGRAFIA

A etnografia é uma técnica de observação que pode ser utilizada

para entender a política organizacional assim como a cultura de

trabalho. Para adotar esta técnica, o analista de sistemas se insere no

ambiente de trabalho para o qual o sistema será desenvolvido

observando e anotando como as tarefas relacionadas ao negócio são

conduzidas. Espera-se com a etnografia descobrir a forma adequada às

pessoas de conduzir os processos e não o padrão formal.

A etnografia é eficaz na descoberta de dois tipos de requisitos:

1. Os requisitos que identificam como as pessoas trabalham

efetivamente, em contraponto à maneira pelas quais as definições

de processo dizem como elas deveriam trabalhar;

2. Os requisitos necessários para a integração das atividades.

“Característica, condição ou capacidade necessitada por um usuário ou

cliente para resolver um problema ou atingir um objetivo” (Dorfman and

Thayer – 1990);

“condição ou capacidade que o sistema precisa estar em conformidade”

(RUP);

“uma característica, propriedade ou comportamento de um sistema”

(UML);

Requisito atendido = Conformidade, mas nem sempre atende a

expectativa do cliente;

A especificação dos requisitos representa “um acordo” entre seu cliente

e a equipe de projeto, e baliza expectativas;

Requisitos especificam O QUE o sistema deve fazer e não COMO o

sistema faz;

9.7 O que é um requisito?

De acordo com SOMMERVILLE, o termo requisito, na indústria de

software não é utilizado de forma consistente, mas, de maneira geral, um

requisito pode ser definido como uma funcionalidade ou uma restrição que o

sistema deve contemplar. Para que um sistema possa ser desenvolvido de

forma a atender plenamente as necessidades de todos os envolvidos, podem

ser categorizados em:

a) Requisitos funcionais, que estabelecem as funcionalidades do

sistema em razão das necessidades do cliente. É importante

salientar que os requisitos funcionais não devem apenas refletir o

que o software deve fazer, mas, também, o que ele não fará.

Exemplos de requisitos funcionais: Cadastramento de clientes,

Venda de produtos, Cálculo de salários, Emissão de relatórios

gerenciais.

b) Requisitos não funcionais, que se apresentam na forma de

características que todo software deve ter, como por exemplo, um

desempenho condizente com a função que executa.

Exemplos de requisitos não funcionais: Velocidade de execução

do sistema (Performance), Facilidade de manutenção dos

programas (Manutenibilidade), Emissão de informações válidas e

precisas (Acurácia).

c) Requisitos de domínio, são aqueles que estão associados às

regras de negócio e fazem parte de um domínio específico.

Exemplos de requisitos de domínio: Fórmula de cálculo da

dedução do IR retido na fonte, Fórmula de cálculo das horas

extras do funcionário.

Talvez, a fase mais importante para o desenvolvimento de um sistema,

seja a análise dos requisitos. Não importa o esmero do projeto ou a boa

qualidade da programação se aquilo que o cliente deseja não for

disponibilizado.

A tarefa da análise de requisitos é um processo que envolve descoberta,

refinamento, modelagem e especificações que traduzem as necessidades do

cliente em artefatos que serão utilizados pelos desenvolvedores para criar uma

solução adequada ao problema.

10 – Análise de requisitos

Segundo PRESSMAN, a análise de requisitos pode ser dividida em

cinco partes, ou cinco áreas de esforço:

1) Reconhecimento do problema;

2) Avaliação e síntese;

3) Modelagem;

4) Especificação, e;

5) Revisão da especificação.

Esta área de esforço tem o objetivo de identificar as reais

necessidades do cliente e traduzir essas necessidades em requisitos

que podem ser utilizados para o desenvolvimento do sistema;

10.2 Avaliação e síntese

A avaliação dos requisitos é uma etapa onde os requisitos que

foram inicialmente coletados sejam estudados de forma mais profunda,

identificando a sua real necessidade e colaboração para a solução do

problema. Nesta etapa também será analisada a necessidade de

decompor um requisito ou de agrupamento de vários requisitos para

atender a solução de forma racional;

10.3 Modelagem

A modelagem de um requisito se traduz na forma como esse

requisito pode ser implementado considerando-se os recursos

tecnológicos disponíveis, o momento em que deverá ser implementado e

a sua prioridade;

10.4 Especificação

Esta etapa consiste em traduzir para uma linguagem técnica as

características do requisito, isto é, o analista comporá um documento

que será destinado aos programadores para que estes, através do seu

conhecimento das linguagens de programação, implementem o requisito

para o sistema;

10.5 Revisão da especificação

Nesta etapa, os revisores procuram garantir que a especificação

esteja completa, consistente e precisa. Deve ser considerado o seguinte: