AnáLise de Sistemas-1
-
Upload
costa-alfredo-alexandre -
Category
Documents
-
view
18 -
download
0
Transcript of 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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
Confidencialidade
Garantia de que apenas as pessoas ou organizações autorizadas têm acesso à informação.
Fernando Ribeiro – janeiro de 2016
Integridade
Garantia de que a informação mantém todas as características originais e não foi adulterada.
Fernando Ribeiro – janeiro de 2016
Autenticidade
Garantia de que a origem da informação está correctamente identificada.
Fernando Ribeiro – janeiro de 2016
Disponibilidade
Garantia de que a informação estará sempre disponível para ser distribuída às pessoas e organizações autorizadas.
Fernando Ribeiro – janeiro de 2016
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).
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
Progresso da fase de especificação
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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).
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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
Exemplo de especificação de requisitos
Fernando Ribeiro – janeiro de 2016
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
Exemplo de especificação de requisitos
Fernando Ribeiro – janeiro de 2016
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
Exemplo de especificação de requisitos
Fernando Ribeiro – janeiro de 2016
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
Exemplo de especificação de requisitos
Fernando Ribeiro – janeiro de 2016
Restrições normativas:
Certificação de qualidade ISO 9001
Certificação Multibanco para pagamentos
Exemplo de especificação de requisitos
Fernando Ribeiro – janeiro de 2016
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
Fernando Ribeiro – janeiro de 2016
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
Fernando Ribeiro – janeiro de 2016
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)
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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?
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
Modelo em cascata
Modelo assumidamente com problemas, devido à falta de iteratividade entre as fases
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
Prototipação
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
Modelo em V
Fernando Ribeiro – janeiro de 2016
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
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
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.
Fernando Ribeiro – janeiro de 2016
Scrum
Fernando Ribeiro – janeiro de 2016
Fernando Ribeiro – janeiro de 2016