AnÃ¡Lise de Sistemas-1

Análise de sistemas

Fernando Ribeiro Janeiro de 2016

Citeforma

Conteúdos

• Conceito de análise e de sistema de informação

• Modelos de entidades e relações

• Modelos físicos de dados

• Representação das fronteiras do sistema

• Representação do comportamento do sistema

• Representação da implementação do sistema

Fernando Ribeiro – janeiro de 2016

Sistema de informação

Conjunto de pessoas, tecnologias e processos organizados entre si de forma a reunir, armazenar, processar, distribuir e transmitir informação.

Um sistema de informação pode ser manual ou automatizado.


Vantagens de um Sistema de Informação

•A informação está melhor organizada, facilitando a sua recolha, o seu armazenamento, o seu processamento e a sua distribuição e transmissão.

•A informação está mais estável e melhor controlada.

•A informação está mais segura.


Vantagens de um Sistema de Informação

Numa empresa, estas vantagens resultam, normalmente:

•Na redução dos custos operacionais e administrativos.

•No aumento da produtividade.


Segurança de um Sistema de Informação

Consiste na proteção da informação contida no sistema, pois a informação tem um determinado valor para a pessoa ou organização que cria, mantém ou utiliza o Sistema de Informação.


Segurança de um Sistema de Informação

A segurança do Sistema de Informação depende da seguintes características da informação:

•Confidencialidade;

•Integridade;

•Autenticidade;

•Disponibilidade.


Confidencialidade

Garantia de que apenas as pessoas ou organizações autorizadas têm acesso à informação.


Integridade

Garantia de que a informação mantém todas as características originais e não foi adulterada.


Autenticidade

Garantia de que a origem da informação está correctamente identificada.


Disponibilidade

Garantia de que a informação estará sempre disponível para ser distribuída às pessoas e organizações autorizadas.


Implementação de um SI automatizado A implementação de um Sistema de informação passa pelas seguintes fases:

•Especificação (requisitos do sistema): Identificação do problema a resolver, recolha de informação, especificação dos requisitos do sistema;

•Desenho do sistema (características do sistema);

•Construção do sistema;

•Revisão do sistema;

•Manutenção do sistema (prolonga-se enquanto existir o sistema).


Fase de especificação

•Identificação do problema a resolver: definição exata do problema que o sistema de informação irá resolver, que resultados obterá, que informação processará, sempre de uma forma geral mas precisa.

•Recolha de informação: entrevistas com utilizadores, gestores do sistema, o dono do sistema, recolha de documentação relevante, regulamentos, standards, análise de sistemas existentes.

•Especificação de requisitos: produção de um documento de especificação completo, claro e abrangente e respetiva aceitação.


Progresso da fase de especificação


Levantamento de requisitos

Os requisitos do sistema são obtidos através de consultas aos futuros donos e gestores do sistema, aos futuros utilizadores, a documentação existente relevante para o sistema, e através dos conhecimento do domínio e estudos de mercado.

Este processo é também conhecido como aquisição de requisitos.


Análise e negociação de requisitos

Os requisitos são analisados em detalhe e as diferentes partes negociam para decidirem que requisitos serão aceites.

Este processo é necessário visto que é inevitável o aparecimento de conflitos entre requisitos de diferentes fontes, existência de informação incompleta ou incompatibilidade com o orçamento disponível para o desenvolvimento do sistema. Existe, no entanto, alguma flexibilidade na negociação de requisitos para que seja possível concordar acerca de conjunto de requisitos para o sistema.


Documentação de requisitos

Os requisitos acordados durante o processo de negociação são documentados com um nível de detalhe apropriado. Em geral, é necessário existir um documento de especificação de requisitos que seja compreendido por todas as partes. Isto significa que os requisitos devem ser detalhados utilizando linguagem natural e diagramas. Podem também ser produzidos documentos de sistema mais detalhados tais como modelos de sistema.


Validação de requisitos

Todos os requisitos obtidos nas atividades anteriores devem ser cuidadosamente verificados para apurar se estão completos e são consistentes. Este processo tem como finalidade detetar potenciais problemas no documento de especificação de requisitos antes que este seja utilizado como base para o desenvolvimento do sistema.

Também devem ser verificados os custos de implementação totais do sistema e comparados com o orçamento disponível.

Deve existir um documento formal aceitação dos requisitos assinado por todas as partes (por exemplo, pelo fornecedor e pelo cliente).


Exemplo de especificação de requisitos

Definição do problema: Implementar um sistema de venda automática de bilhetes de comboio nas estações da CP

Alcance do problema: 50 estações nas principais cidades do continente com venda de bilhetes, e um escritório em Lisboa com sistema de gestão.


Sistemas existentes: sistema manual

Documentação:

•Norma ISO 9001

•Normas do sistema Multibanco

•Lista de estações com localização e horário de passagem de cada comboio

•Tabela de preços para cada par origem/destino

•Lista de comboios com capacidade de passageiros



Requisitos funcionais da máquina de venda:

•Vende bilhetes com escolha de origem, destino e horário.

•Bilhete válido por 24 horas.

•Pagamento com notas de 5€, 10€, 20€ e moedas de 10, 20 e 50 cêntimos e moedas de 1€ e 2€

•Dá troco em dinheiro

•Pagamento com Multibanco

•Imprime talão de venda

•Imprime factura

•Mantém registo da capacidade de cada comboio e só vende os bilhetes possíveis



Requisitos funcionais da máquina de venda:

•Comunica todas as vendas ao servidor central através da rede existente

•Interface de utilizador em Português, Inglês e Espanhol

•Interface de utilizador para invisuais

Requisitos funcionais do sistema central:

•Consulta de vendas de bilhetes, por origem/destino, por estação, e total de valor vendido.

•Impressão de relatórios diários para a contabilidade



Requisitos de desempenho:

- 2 estações com 1000 passageiros/hora, 12 estações com 500 passageiros/hora, 26 estações com 100 passageiros/hora.

- venda de bilhetes funcional 24 horas/dia, 365 dias/ano.

Requisitos de segurança:

- cofre de alta segurança para o dinheiro com sistema de tintagem

- requisitos necessários ao sistema Multibanco

- sistema de autorização no servidor central

Requisitos de portabilidade:

- ponto de rede para cada máquina de venda



Restrições normativas:

Certificação de qualidade ISO 9001

Certificação Multibanco para pagamentos



Desenho do Sistema de Informação Consiste no desenho global do sistema a partir do documento de especificação de requisitos, ou seja, a definição da arquitectura do sistema. Inclui:

•Divisão do sistema em módulos

•Criação de diagramas dos módulos do sistema e de fluxo de dados

•Criação dos modelos de dados do sistema

•Especificação de interfaces do sistema

•Listagem de produtos de software a integrar no sistema

•Listagem de hardware necessário ao sistema


Desenho informal do sistema Sistema central Máquina de venda

Rede

Bilhetes vendidos

Dad

os

de

pag

amen

to

Sistema

Multibanco C

om

unic

ações

Com

unic

ações

Pagamentos

Impressão de

bilhetes

Impressão

de

relatórios

Venda de

bilhetes

Ba

se

de

da

do

s

Consulta de

vendas

Impressora Impressora

Cofre

Leitor de

cartões

Dispens

ador de

notas e

moedas


Construção do sistema

•Programação do software necessário e interfaces

•Integração do software produzido com o hardware, restantes produtos de software, rede, sistemas de backup, e outros.

•Criação de ambiente de teste (cópia do sistema completo ou parcial para teste do sistema)

•Criação de ambiente de produção (sistema final a colocar em produção)

•Criação de toda a documentação do sistema (manuais técnicos, manuais de utilizador, e outros)


Revisão do Sistema

•Verificação dos requisitos, apurando se o sistema construído cumpre todos os requisitos especificados;

•Realização de testes de sistema, verificando se todos os aspectos do sistema funcionam como esperado;

•Se forem detectadas falhas no sistema, voltar à fase de desenho, e posteriormente construção;

•Quando não houverem falhas detectadas no sistema, colocação do sistema em produção.


Manutenção do Sistema (Produção)

Depois de colocado o sistema em produção, entramos na fase de manutenção que pode continuar durante todo o tempo de vida útil do sistema, e inclui:

•Correcção de falhas não detectadas durante a revisão do sistema;

•Adição de novas funcionalidades entretanto apuradas.


Modelo de implementação do projecto

Tradicionalmente, controlar a implementação de um projecto de software é bastante difícil, sendo comum que um projecto termine não cumprindo as previsões feitas sobre:

-A sua duração

-O seu custo

-As suas funcionalidades

Como gerir um projecto em que constantemente os prazos não são cumpridos, os custos excedem o previsto e os requisitos não são satisfeitos?


Modelo de implementação do projecto

Para facilitar a gestão do projecto adoptamos um modelo de implementação.

O modelo é usado para estruturar, planear e controlar o processo de implementação do sistema de informação.

Cada modelo tem as suas características, mas todos se destinam a auxiliar o cumprimento dos objectivos do sistema de informação dentro do prazo e custo previsto.


Modelo em cascata

Modelo assumidamente com problemas, devido à falta de iteratividade entre as fases


Modelo em cascata

A fase seguinte só começa quando a anterior estiver completa: •Não existe sobreposição de fases; •Não se pode voltar a uma fase anterior; Existe pouca flexibilidade e não permite iterações, que são essenciais ao desenvolvimento de software, portanto é pouco útil de um ponto de vista prático. No entanto pode ser útil se sofrer algumas modificações.


Prototipação

É comum serem utilizados protótipos na construção de software com diferentes propósitos: • a construção de uma prova de conceito, ou simulação; • a implementação parcial do sistema ou; • para testar aspectos técnicos de um sistema. O processo de prototipação consiste basicamente em diversos ciclos iterativos. Um protótipo é construído a partir de requisitos iniciais. É realizada uma avaliação crítica do protótipo a qual considera os requisitos iniciais e requisitos que não foram mencionados inicialmente. Caso o protótipo não cumpra os requisitos pretendidos, são realizadas novas iterações produzindo novos protótipos. As iterações são finalizadas quando os requisitos forem atendidos.


Prototipação


Prototipação Incremental A abordagem incremental é um tipo de prototipação em que o desenvolvimento é feito por etapas, ou estágios. Normalmente os requisitos mais importantes são implementados primeiro e os restantes são acrescentados em novas versões. O desenvolvimento ocorre gradualmente e no fim de cada estágio é produzida uma versão funcional. Cada estágio utiliza o modelo em Cascata. A abordagem pode oferecer diversas vantagens: • redução de riscos • maior visibilidade sobre o processo de desenvolvimento • maior facilidade em estimar a duração do projeto. No entanto, é necessário grande esforço na atualização da documentação do utilizador e as dependências entre os diversos estágios podem ser difíceis de prever e planear.


Prototipação Evolutiva A abordagem evolutiva é um tipo de prototipação em que o desenvolvimento é feito por etapas, ou estágios, e cada estágio representa um refinamento do protótipo do estágio anterior. Os estágios vão-se sucedendo até que todos os objectivos sejam antingidos. Cada estágio utiliza o modelo em Cascata, e há uma sobreposição das fases da operação e manutenção do sistema anterior com o novo desenvolvimento. A abordagem é adequada principalmente quando: • é necessário alguma experiência do usuário para refinar e completar requisitos; • algumas partes da implementação podem depender da existência de tecnologia

ainda não disponível; • existem requisitos que não são bem conhecidos ou são muito mais difíceis de

serem implementados do que outros.


Modelo em V

O modelo em V representa uma melhoria do modelo em cascata, corrigindo o problema da falta de mecanismos de reacção a problemas surgidos ou melhoramentos necessários durante o desenvolvimento. Este modelo permite retornar a uma fase anterior em case de necessidade. As fases posteriores devem devolver informação às fases anteriores, quando os problemas são detectados, a fim de melhorar o programa. Como principal desvantagem encontramos a dificuldade em seguir o fluxo sequencial do modelo.


Modelo em V


Modelo em Espiral

O modelo em Espiral reúne características do modelo em Cascata e da Prototipação, introduzindo ainda o conceito de análise de risco. Cada volta da espiral (iniciando a partir do centro) representa uma nova iteração do processo de implementação. Estas iterações frequentes permitem que novas versões possam ser construídas progressivamente. Tipicamente, o modelo pode ser dividido em 4 etapas: 1. Identificação dos objectivos para a fase decorrente 2. Análise dos riscos e sua prevenção e controle 3. Desenvolvimento e verificação 4. Planeamento da fase seguinte Fernando Ribeiro – janeiro de 2016

Modelo em Espiral


Modelo em Espiral

O modelo em espiral apresenta algumas vantagens importantes: • Quanto mais tempo e recursos forem destinados ao projeto, ou

seja, quanto mais iterações forem feitas na espiral, menor serão os riscos do projeto não cumprir os requisitos, os prazos e o orçamento estabelecido.

• A verificação presente no final de cada iteração permitem um melhor controle do projeto.

No entanto, em projectos simples e de baixo risco a utilização do modelo em Espiral torna-se demasiado pesada e dispendiosa. Fernando Ribeiro – janeiro de 2016

Test Driven Development

Test Driven Development (ou Desenvolvimento Orientado aos Testes) é um modelo de desenvolvimento de software baseado em iterações curtas, em que o teste do software é usado como orientação do método de desenvolvimento. Inicialmente o programador escreve um caso de teste automatizado que se debruça sobre uma funcionalidade ou melhoria a implementar. Posteriormente é produzido código que possa ser validado pelo teste, implementando-se assim a funcionalidade desejada.


Test Driven Development

O modelo TDD segue normalmente esta sequência: 1. Adicionar um teste - Cada nova funcionalidade inicia-se com a criação de um teste. Para tal, o programador precisa conhecer as especificações e requisitos da funcionalidade. 2. Executar o teste - O novo teste deve falhar pois a funcionalidade ainda não foi desenvolvida. 3. Escrever código - Escrever o código necessário para que o teste não falhe. 4. Execute o teste automatizado com sucesso – O sucesso do teste indica que os requisitos estão a ser cumpridos. 5. Repetir para nova funcionalidade


Modelos Ágeis O desenvolvimento ágil de software (do inglês agile software development) é um conjunto de metodologias de desenvolvimento de software que tentam minimizar o risco de não cumprir prazos, orçamentos ou objectivos utilizando iterações muito curtas (tipicamente de uma a quatro semanas) ao fim das quais é produzida uma nova versão do software. Cada iteração é como um projecto de software em miniatura e inclui todas as tarefas necessárias para implementar a nova funcionalidade: planeamento, análise de requisitos, projecto, desenvolvimento, teste e documentação. O desenvolvimento ágil prefere as comunicações em tempo real, face a face, a documentos escritos. A maioria dos elementos da equipa deve estar agrupada na mesma sala.


Rapid Application Development

O modelo RAD (Desenvolvimento Rápido de Aplicações) é um modelo ágil de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 2 a 3 meses). Este modelo baseia-se na modularização do software e no reaproveitamento de módulos.


O modelo segue as fases seguintes: •Modelação de Negócio •Modelação dos Dados •Modelação do Processo •Geração da Aplicação, usando ferramentas automatizadas para facilitar a construção da aplicação e a reutilização de módulos. •Teste e Modificação

Rapid Application Development


eXtreme Programing

Programação extrema (XP) é um método ágil de desenvolvimento de software que utiliza equipes de trabalho pequenas e requisitos pouco definidos e em constante mudança. Para isso é criado um constante acompanhamento do projecto pelo cliente, que chega a participar no planeamento e teste, e são realizados vários pequenos ajustes durante o desenvolvimento de software. O método XP possui como princípios básicos o feedback rápido, a simplicidade de requisitos, a utilização de iterações curtas e incrementais e o constante controlo de qualidade.


Scrum O método Scrum é um método ágil de desenvolvimento de software, iterativo e incremental, que utiliza pequenas equipas e é baseado em alguns conceitos chave: •O ScrumMaster, pessoa responsável pelos processos de desenvolvimento. •O Dono do Produto, ou Product Owner, que representa o negócio e os utilizadores do produto. •A Equipe, ou Team, o pequeno grupo de pessoas que fazem a análise, implementação, teste, etc. •O backlog, conjunto de requisitos do produto priorizados pelo Product Owner. •O sprint, iteração de duração curta (um mês) que resulta sempre na produção de mais um incremento no projecto e que parte de um subconjunto do backlog (o sprint backlog). •O daily scrum, pequena reunião do início do dia em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e os impedimentos existentes.


Scrum


http://upload.wikimedia.org/wikipedia/commons/5/58/Scrum_process.svg

AnÃ¡Lise de Sistemas-1

Documents

Transcript of AnÃ¡Lise de Sistemas-1