ATPS Analise Estruturada

Anhanguera Educacional Unidade Taguatinga Facnet

Bacharelado em Sistemas de Informação.

I – Necessidades e Técnicas de comunicação. Estudo de viabilidade.

II – Requisitos de usuário e de sistemas. Prototipação, modelos e padrões.

Gustavo Dias – RA: 7423674445

Sergio Luis – RA: 7635735326

Habacuque Cavalcante – RA: 7474680209

Leandro Leal – RA

Professor Rafael Pantoja

Analise Estruturada de Sistemas

Taguatinga – DF

RESUMO CAPÍTULOS 1, 2 E 3 DO LIVRO DE TOM DEMARCO

ANÁLISE ESTRUTURADA E ESPECIFICAÇÃO DE SISTEMA

Inicialmente, o autor compara a Análise Estruturada com as instruções de montagem utilizadas para construção de um barco dobrável. Vale ressaltar, que essa análise é construída para ser realizada de forma manual. De acordo com DeMarco (1999) a Análise Estruturada é um novo tipo de Especificação Estruturada, sendo essa última, uma descrição de procedimentos automatizados.

Verifica-se ainda, que a Especificação Estruturada é gráfica e as instruções para linha de montagem, não passam de mero texto, de forma narrativa e unidimensional. Já a variante observada pela Especificação Estruturada é multidimensional. Partindo dessa premissa, o autor traça uma linha de definições que iram melhor explicar e exemplificar a terminologia utilizada na Análise Estruturada:

1.1 – Análise: Define-se como o estudo de um problema, que antecede uma tomada de ação/decisão. Para o desenvolvimento de sistemas computacionais, refere-se ao estudo de alguma área de trabalho ou de uma aplicação, o que quase sempre nos leva a especificação do sistema e mais tarde a sua implementação.

Na fase de análise de ciclo (considerada a mais importante) tem-se o documento de especificação. Este terminologia pode vir a variar dependendo da empresa: Especificação Funcional, Especificação de Projeto, Memorando de Análise Racional, Relatório de Necessidades, etc... Para evitar confusões futuras, vamos utilizar o termo “Documento Alvo”. Este “Documento” tem por objetivo estabelecer os objetivos do restante do projeto, por intermédio da satisfação de compromissos para obtenção de sucesso.

Para que a conclusão seja bem sucedida, alguns passos deverão ser observados:

1. Seleção de um alvo específico.

2. Documentação detalhada do alvo a ser atingido para futura verificação de sucesso.

3. Diagnósticos antecipados com parâmetros reais, bem como seus benefícios e escalonamentos.

4. Obtenção de conformidade para cada uma das áreas afetadas.

1.1.1 – Características da Análise

• Negociação difícil do documento alvo tendo em vista a diversidade de usuários em suas formas de trabalho;

• Sistemas maiores, enrolados que requer uma grande capacidade de negociação por parte do analista.

• Relações interpessoais hostis.

• Não há critério de precisão, a não ser o tempo esgotado para análise.

• Frustração ao mesmo tempo em que é instigante.

1.1.2 – O Contato com o Usuário: Aqui o Analista é visto como professor do usuário, o tradutor e o consultor. Os usuários devem manter uma parceria, de tal forma que consigam entender e aplicar o que foi sistematizado, e quais são as melhores estratégias a serem utilizadas para o desempenho desse sistema.

1.1.3 – Especificação: O documento mais importante nesse quesito, sem dúvida é o Documento Alvo. O analista deverá unir-se as áreas da empresa para que verifique-se um resultado positivo na construção daquele que será um modelo, uma escala perfeita a ser observada por todos.

1.1.4 – Análise de Viabilidade: Refere-se ao processo de teste contínuo para certificar-se que o sistema está trabalhando de acordo com as especificações implementadas dentro de um conjunto de restrições. Envolve a construção de modelos físicos experimentais e sua consequente avaliação.

1.1.5 – Estimativa: Importante para estimar custos das atividades futuras, como por exemplo, cargas de CPU, capacidade de armazenamento, distribuição de trabalho e outras;

1.1.7 – Natureza Defensiva da Análise: A preocupação dominante da análise não é obter sucesso, mas “evitar fracasso”. As ferramentas da Análise Estruturada são mecanismos utilizados para minimizar os riscos de uma análise infrutífera. Assemelha-se à educação infantil: Pode causar um imenso trauma, mas não garantir sucesso.

1.2 – Problemas de Análise

1. Problemas de Comunicação: dificuldade natural de se descrever procedimentos, falta de linguagem comum entre analista e usuário (falarem a mesma língua) e falta de método prévio que possa ser utilizado pelo sistema.

2. Natureza Variável dos Requisitos: Congelar o Documento Alvo é inviável, haja vista que este é somente uma aproximação do verdadeiro objetivo do projeto, nesse sentido deve-se manter a eventual realimentação do sistema.

3. Falta de Ferramentas Adequadas: A cada fase do projeto, deve-se cercar-se de ferramentas que garantam o sucesso do próximo nível da programação, ou seja, deve-se manter a mente aberta sob nossa capacidade de julgamento.

4. Problemas no Documento Alvo: O Documento Alvo muito complexo pode vir a ocasionar: redundância, excessivamente: prolixo, físico e provocar tédio ao ser lido e reescrito. Resolve-se dividindo o sistema em módulos para haver um desenvolvimento conveniente. Deve-se aprender a produzir centenas de mini especificações e organizá-las de tal forma que possam ser tratadas seletivamente.

5. Distribuição de Trabalho: Dividir