Prof. Vera Niedersberg Schuhmacher

Apresentação em tema: "Prof. Vera Niedersberg Schuhmacher"— Transcrição da apresentação:

1 Prof. Vera Niedersberg Schuhmacher
Análise de Sistemas I Prof. Vera Niedersberg Schuhmacher UNISUL

2 Introdução 1.1 Configuração de Software

3 1.2 Processo do Software Especificação
Conjunto de atividades e resultados que produzem o produto de software 1.2 Processo do Software Especificação Definir funcionalidades e restrições Desenvolvimento Produção do produto Validação Validar com o desejo do cliente Evolução Novas necessidades do cliente

4 1.3 Paradigma Genérico O Que ? Como ? Porque? Definição
Desenvolvimento Manutenção

5 Desenvolvimento de Software
Fase de Definição análise de sistema planejamento do projeto de software análise de requisitos Fase de Desenvolvimento projeto de software codificação teste de software Fase de Manutenção adaptação correção perfectiva

6 A problemática do projeto de software
COMO PROPOSTO COMO ESPECIFICADO COMO PROJETADO COMO IMPLEMENTADO COMO INSTALADO O QUE O USUÁRIO QUERIA Brittan 1980

7 1.4 Modelos e Abstrações Níveis de Abstração Dimensões do Modelo
Fases do Ciclo de Vida Conceitual Modelo Lógico (processos e dados) (classes e objetos) Análise de Requisitos Tecnológico Modelo Físico (Procedimentos , programas e bases de dados) (classes, objetos e métodos) Projeto Interno Software implementado Construção

8 II. Análise de Requisitos
Requisito de software – é uma descrição dos principais recursos de um produto de software, seu fluxo de informações, comportamento e atributos. O requisito de software fornece uma estrutura básica para o desenvolvimento de um produto de software. O grau de compreensibilidade, precisão e rigor da descrição fornecida por um documento de requisitos de software tende a ser diretamente proporcional ao grau de qualidade do produto resultante (Peters, 2000). O pensamento da análise de requisitos deve voltar-se principalmente ao problema, não as soluções (David, 1993). A análise de requisitos é o principal processo executor em um sistema de feedback que produz descrições dos recursos comportamentais e não comportamentais do software.

9 COMEÇA QUANDO: se reconhece um problema que necessita de solução surge uma idéia de um novo negócio ou sistema de informação E TERMINA QUANDO: tem-se a descrição completa do comportamento do software a ser construído (Especificação de Requisitos)

10 A análise de requisitos é um processo de descoberta e refinamento
ATORES: cliente e desenvolvedor PROBLEMA: grande propensão a mal entendidos - "atividade aparentemente simples torna-se complexa"

11 Durante o levantamento de requisitos voce vai se deparar com um grande volume de relatórios, formulários e documentos. Quais os que voce deve avaliar?  Detecte as pessoas chaves do processo, trabalhe usando amostragens da população. Escute com atenção a gerência da empresa e seus objetivos.

12 2.1 Resultados da Análise de Requisitos
Funcional – identifica as atividades do sistema (ações principais) Comportamental – descreve a seqüência e a possível sobreposição de funções do sistema em uma hierarquia de atividades de controle Não comportamental – inclui planejamento de engenharia humana e qualidade (atributos) 2.2 Principais Produtos resultantes do processo: Especificação de requisitos de software – descrição do sistema ( funções, comportamento, desempenho, interfaces e atributos de qualidade). Plano de garantia de qualidade – indicação de portabilidade, eficiência, confiabilidade, critérios de validação e verificação, custos critérios de aceitação.

13 Avaliação da Especificação
2.3 ATIVIDADES Análise do Problema Definição Requisitos Avaliação da Especificação

14 Análise do Problema “define o espaço de produto de um processo de software “(Davis, 1993). “Brainstorm” Entrevistas Identificação de restrições e possíveis soluções

15 Entrevista O uso da entrevista é feito pelo uso do formato “pergunta-resposta”. Usando esta técnica voce pode obter opiniões do usuário, descobrir o que o cliente pensa sobre o sistema atual, obter metas organizacionais/pessoais e levantar procedimentos informais. Quando voce realizar uma entrevista lembre-se: Tente estabelecer com o cliente um clima de confiança e entendimento; Mantenha-se sempre no controle da entrevista; Tente mostrar ao cliente sua importância dentro do sistema. Prepare-se antecipadamente para a entrevista.

16 Entrevista Lembre-se :
Inclua em sua lista de entrevistados pessoas chaves dentro do futuro sistema. Quando voce propuser uma entrevista marque a data e a hora com antecedência, com uma duração de no mínimo 45 minutos e no máximo duas horas. Elabore as questões e a estrutura da entrevista, durante a entrevista registre tudo o que for possível fazendo uso de anotações ou de um gravador.

17 Entrevista Ao formular as questões evite:
usar questões que levam o entrevistado a responder de uma forma específica ou tendenciosa. Um exemplo ruim: Voce também acredita que o a prioridade do desenvolvimento deva ser o faturamento como seu gerente afirmou? Melhor: O que você acha que deva ser implantado em primeiro plano?

18 Entrevista Evite fazer duas questões em uma, é confuso e a resposta pode não ser completa. Ainda é possível que o entrevistado acabe respondendo uma das questões apenas. Um exemplo ruim: em que situações voce cancela uma nota fiscal e quais os procedimentos que voce faz durante o cancelamento?

19 Questionário O questionário é uma técnica que permite o levantamento de informações a partir da coleta de informações de diferentes pessoas afetadas pelo sistema. Sempre que possível, use o vocabulário das pessoas que irão responder. Prefira o uso de perguntas curtas e simples. Certifique-se de que as questões estão tecnicamente precisas antes de incluí-las no questionário.

20 Observação Direta A observação direta pode ser utilizada como validação das entrevistas, identificação de documentos , esclarecimento do que está sendo feito no ambiente atual e a forma como ocorre. O analista observa sem intervir diretamente no processo. É importante planejar a observação e isto significa identificar o que deve ser observado, obter aprovação das gerências apropriadas, obter as funções e nomes das pessoas envolvidas nas ações que serão observadas. Se voce optar por esta técnica prepare os usuários com cuidado esclarecendo sobre a forma como o processo vai ocorrer.

21 Brainstorming No sentido exato da palavra brainstorming é uma tempestade de idéias. O uso da discussão em grupos onde a partir dos resultados das técnicas acima procura-se compreender corretamente documentos, respostas oferecidas pelos usuários, processos existentes são a base para que se chegue a uma boa especificação. Nesta etapa inicia-se a formatação de um documento que deve conter os requisitos necessários ao projeto dentro de um consenso entre desenvolvedores e cliente. Durante o levantamento dos requisitos é estabelecido o escopo do projeto e também as possíveis restrições que possam delinear algum tipo de risco no horizonte.

22 Análise De Problemas Ambiente Itens produzidos Funções Modos de operação Itens processados Itens consumidos Itens produzidos para satisfazer as necessidades do sistema Funções executadas por pessoas, por máquinas Funções necessárias para produzir o serviço ou item Métodos utilizados Forma de produzir o item Quando as operações acontecem Pessoas no sistema Pessoas afetadas Máquinas no sistema Máquinas afetadas Serviços necessários Outros itens afetados pelas operações do software

23 Análise do Problema PROBLEMAS: comunicação com usuário
organização das informações entendimento completo do problema

24 2.3.2. Definição dos Requisitos
B1) ELICITAÇÃO DE REQUISITOS A meta é o reconhecimento dos elementos básicos do problema, conforme percebidos pelo cliente. Avaliar os problemas na situação atual Para o novo sistema: - definir e elaborar todas as funções do sistema - identificar dados que o sistema produz e consome entender o comportamento do sistema - estabelecer características de interface - descobrir restrições do projeto

25 B1) ELICITAÇÃO DE REQUISITOS
Sintetizar uma ou mais soluções (dentro do alcance delineado no Plano de Projeto do Software) O processo de avaliação e síntese continua até que o analista e o cliente concordem que o software pode ser adequadamente especificado.É a maior área de esforço

26 B2. MODELAGEM Durante a atividade de avaliação e síntese devem ser criados modelos do sistema para se compreender melhor o fluxo de dados e de controle, o processamento funcional e a operação comportamental, além do conteúdo da informação. O modelo serve como fundamento para o projeto de software e como base para a criação de sua especificação

27 2.3.3 Especificações de Requisitos de Software
“é a descrição de um produto de sofware, programa ou conjunto de programa específico que executa uma série de funções do ambiente de destino “(Padrão IEEE 830,1993).

28 Questões da ERS Funcionalidade Interfaces Externas Desempenho Atributos Restrições Velocidade, disponibilidadem tempo de resposta, tempo de recuperação das funções do software O que o software deve fazer (descrição das funções) objetos de ERS, funções e estados Interação do software com seu ambiente, com as pessoas, com hardware do sistema, outros componentes de hardware e de software Portabilidade, rastrabilidade, fidedignidade, manutenibilidade, qualidade, estabilidade, segurança Padrões de qualidade, linguagem de codificação, limites de recursos, orçamento, ambiente....

29 2.3.4 Avaliar a Especificação
comparar a especificação com padrões de qualidade previamente estabelecidos validar a especificação com os usuários PROBLEMAS: inexistência de padrões dificuldade de realizar avaliações

30 Plano de Desenvolvimento do Software
elementos alocados ao software determinar domínio das informações e das funções, interfaces, restrições de projeto e critérios de validação construir protótipo para estabelecer os requisitos os requisitos são conhecidos? revisão administrativa Plano de Desenvolvimento do Software estabelecimento do alcance recursos, custo cronograma revisar e justificar recursos, custos e cronogramas Especificação dos Requisitos do Software início da fase de desenvolvimento revisão aceitável não sim técnica revisão do plano de projeto do software

31 Referências Rodrigues M. R., Material didático, 2001 Peters, J. , Pedrycz, W., Engenharia de Software, Editora Campus, 2002

32 Exercício – Clínica Veterinária
A – VISÃO GERAL DO SISTEMA O sistema para a Clínica Veterinária Animal & Cia trata do gerenciamento das consultas realizadas em animais domésticos (por exemplo, cães e gatos). A consulta pode ser de rotina, mas pode implicar em diagnósticos que envolvam outros serviços a serem prestados pelo veterinário, como injeções, vacinação, cirurgias, etc. Além disso, o animal pode precisar de medicamentos, que podem ser adquiridos na própria clínica. A clínica possui também diversos produtos para venda, como rações, brinquedos, casas de madeira, shampoos, escovas, bebedouros, etc. Esses produtos podem ser vendidos separadamente, ou integrados a uma consulta. Diversos relatórios devem ser gerados pelo sistema para permitir a gestão adequada da clínica, como o relatório de estoque de medicamentos e produtos, consultas feitas em um determinado animal, relatório de vendas de produtos, etc.