Fase de Elaboração: Fluxo de Requisitos

Slides:



Advertisements
Apresentações semelhantes
Análise e Projeto de Sistemas III
Advertisements

Os projetos.
Especificação de Requisitos
O Processo Praxis 3.0 Processos de Software 25/03/2017
Processo Lacen de Desenvolvimento de Software
Identificando requisitos
Prototipação de Software
Rational Unified Process(RUP)
Engenharia de Software
Faculdade de Ciências Sociais de Aplicadas de Petrolina – FACAPE
Qualidade de Software Aula 2
Processo Desenvolvimento de Software Tradicional
SISTEMA DE INFORMAÇÕES DESENVOLVIMENTO DE SISTEMAS
Professor: Rogério Lopes Disciplina: Engenharia de Software II Fortium Sistemas da Informação Engenharia de Software II.
Requisitos Funcionais e Não-Funcionais/ Documento de Requisitos
RUP: Fluxo de Análise e Projeto
TSDD Teste de segurança durante o desenvolvimento.
Visão Geral do Desenvolvimento de Sistemas e Papéis no Desenvolvimento de Software Marcely Dias
Classes e objetos Modelagem
Rational Unified Process
RUPinho Qualidade de Software
Prof.Alfredo Parteli Gomes
Planejamento e Gerenciamento de Projetos
Visão Geral PRO.NET.
Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
Processos de Desenvolvimento de Software – Parte 2
Especificação de Requisitos de Software - ERSw
Processo Praxis – Fase de Concepção
Análise e Projeto de Sistemas
IEEE Std IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)
Processos de Engenharia de Requisitos
Engenharia de Software
Qualidade de Software Aula 2 / 2014/1
Fase de Elaboração: Fluxo de Análise Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
REQUIREMENTS DEVELOPMENT DESENVOLVIMENTO DE REQUISITOS
Introdução e Fundamentos Engenharia de Requisitos
Modelos de Processo de Software
Fase de Concepção (Início, Planejamento)
PSBD II Projeto de Sistemas de Banco de Dados II
O Processo de desenvolvimento de software
Levantamento de Requisitos
Profa. Cintia Carvalho Oliveira
A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados: –Funcionalidade (finalidade do produto) –Usabilidade.
Levantamento de Requisitos
Bruno Silva Desenvolvido a partir de
O Processo Unificado (UP)
Engenharia de Software
Qualidade de Software Aula 4
RUP - Cap. 4 – Processo Centrado na Arquitetura
Qualidade no Desenvolvimento de Software Wolley W. Silva Baseado nas notas de aula dos professores Tatuo e Daisy.
Processos de Software.
Fase de Concepção Levantamento de Requisitos, Organização de Requisitos, Planejamento dos Ciclos Iterativos.
Gestão de projetos de Software GTI-16
FERRAMENTAS DE MARKETING
Processo de Desenvolvimento de Software – PDS
Engenharia de Software
Fase de Concepção (Início, Planejamento)
Análise de Requisitos Introdução Renata Araujo Ricardo Storino Núcleo de Computação Eletrônica Curso de Programação de Computadores Maio a Setembro/2000.
Análise e Projeto de Sistemas Orientado a Objetos Profa. Ana Karina Barbosa.
Processo e Qualidade.
Qualidade de Produtos de Software
Engenharia de Software Fluxo de Requisitos
Aula 02 de Eng. de Requisitos
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
RUP – Rational Unified Process Márcia Seabra Cabral Prof. Augusto Sampaio Centro de Informática - UFPE.
Engenharia de Software com o RUP - Workflow de Requisitos
ISO9001:2000 para Software Professor: Alexandre Vasconcelos Equipe: Amanda Pimentel Börje Karlsson Danielly Karine Erika Pessoa Jorge Cavalcanti Jose Edson.
Desenvolvimento de Software I
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

Fase de Elaboração: Fluxo de Requisitos Análise de Sistemas de Software Prof. Rodrigo Ribeiro

Princípios Finalidade do Fluxo de Requisitos Artefatos do PRAXIS Documentos PESw ERSw Modelos CRSw MASw

Especificação de Requisitos A ERSw deve incluir características de Funcionalidade Interfaces Externas Desempenho Restrições Linguagens, plataformas, etc... Outros Portabilidade Manutenibilidade Confiabilidade

Especificação de Requisitos Quem produz? Membros da equipe de desenvolvimento Usuários chaves indicados pelo cliente Porque um equipe mista? A equipe não conhece os processos de negócio do usuário Usuários não entendem de engenharia de software Usuários chaves conhecem o processo? Não, mas devem ser treinados para isso.

Especificação de Requisitos Evolução de requisitos Motivos Descoberta de defeitos nos requisitos originais Falta de detalhes nos requisitos originais Alterações incontornáveis nos requisitos originais Uma organização madura... Requisitos são controlados para estabelecer uma base gerencial e de engenharia de software. Todos os artefatos são consistentes entre si

Especificação de Requisitos Limites Não inclui decisões de desenho e implement. Exceção:restrições do cliente para uma linguagem Não inclui decisões gerenciais. Qualidade dos Requisitos Especificação de Requisitos deve ser... Correta Todo requisito presente realmente é um requisito Completa Todos os requisitos necessários estão presentes

Especificação de Requisitos Qualidade Especificação de Requisitos deve ser... Precisa Todo requisito deve ter uma única interpretação Consistente Não existe conflitos entre requisitos especificados Priorizada Existe uma ordem de prioridade dos requisitos Verificável Todos os requisitos devem verificável Modificável A mudança da estrutura e estilo dos requisitos é simples. Rastreável Permite a fácil identificação de antecedentes e conseqüências dos requisitos

Atividades Determinação de Contexto Definição do escopo Levantamento dos processos de negócio Resultado: PESw Definição do escopo Delimita problemas a serem resolvidos Resultado: ERSw-1 (Introdução) Definição dos requisitos Versão inicial dos requisitos funcionais e não funcionais Resultado: ERSw-2 (Descrição geral do produto) Detalhamento de requisitos de interface externa Aspectos de GUI considerados como requisitos Resultado: ERSw-3.1 (Requisitos de interface externa)

Atividades Detalhamento de requisitos funcionais Descrição completa dos casos de uso Resultado: ERSw-3.2 (Requisitos funcionais) MASw-VCU(Visão de casos de uso) Detalhamento de requisitos não funcionais Detalhamento de desempenho entre outros Resultado: ERSw-3.3(Requisitos não funcionais) Classificação de requisitos Determinação de prioridades Resultado: CRSw (Casos de uso, requisitos não funcionais) Revisão de requisitos Resultado: RRERSw

Detalhes das Atividades Determinação de contexto e escopo Uso de UML, BPMN, etc... Definição de requisitos Uso de diagramas e casos de uso Definição de requisitos de interface ERSw deve conter esboços das interfaces do produto Diagramas de Estado Definição de requisitos funcionais Casos de uso Diagramas de seqüência e de atividades

Detalhes das Atividades Detalhamento de requisitos não funcionais O que pode ser considerado? Desempenho, qualidades técnicas do produto Requisitos não funcionais Devem ser enunciados de forma precisa Devem ser quantificáveis. Dados persistentes Levantamento inicial de um diagrama de classes persistentes.

Detalhes das Atividades Detalhamento de requisitos não funcionais Atributos de qualidade Norma ISSO 9126 Define Atributos de funcionalidade Acurácia, segurança, interoperabilidade Manutenibilidade Analisabilidade, Modificabilidade, Estabilidade, Testabilidade Portabilidade Confiabilidade Desempenho

Detalhes das Atividades Classificação de requisitos (CRSw) Listagem formada por... ID Deve ser único no projeto Caso de uso Tipo Fluxo principal, alternativo, subfluxo ou relatório Prioridade Essencial, desejável ou opcional Estabilidade Baixa, média ou alta Aplicável a requisitos funcionais e não funcionais Última Atividade: Revisão dos requisitos.

Técnicas Protótipos Tipos No contexto do PRAXIS... Objetivos Protótipos descartável Protótipos evolucionários No contexto do PRAXIS... Somente protótipos descartáveis... Protótipos evolucionários: liberações Objetivos Alternativas de interface de usuário Problemas de comunicação com outros produtos Validação de requisitos

Técnicas Protótipos descartáveis Riscos Benefícios Cliente achar que protótipos são produtos finais Desejo de reaproveitamento de desenvolvedores Benefícios Redução de riscos na construção dos produtos Aumento da estabilidade dos requisitos

Técnicas Oficinas de requisitos Conceito Quem participa Vantagens Reuniões estruturadas para definição de requisitos Quem participa Desenvolvedores e usuários chaves Vantagens Comprometimento sobre requisitos Redução do prazo para levantamento de requisitos Eliminar requisitos de valor questionável Eliminar ambigüidades. Produzir um esboço das interfaces do usuário.

Técnicas Oficinas de Requisitos Tarefas Detalhamento Personalização, Sessões, Fechamento Detalhamento Personalização Organização da equipe da oficina Orientação dos participantes quanto à técnica Determinação de particularidades do projeto Preparação de materiais e instalações para as sessões Tempo de duração: 1 a 10 dias.

Técnicas Oficinas de requisitos Detalhamento Sessões Fechamento Definição de alto nível dos requisitos Delimitação do escopo do produto Levantamento de casos de uso do produto Detalhamento inicial dos casos de uso do produto Levantamento de requisitos de GUI e interface com outros softwares. Fechamento Documentação dos resultados das seções Versão inicial da ERSw Versão inicial da MASw

Técnicas Oficinas de requisitos Relacionamento com Clientes Problemas Não participação dos usuários chave Participação de pessoas não comprometidas Número excessivo de pessoas Valores recomendados: 8 – 15 pessoas Relacionamento com Clientes Participação de clientes é fundamental Alguns problemas Falta de entendimento da importância da engenharia de software Existência de múltiplos contatos do cliente

Técnicas Relacionamento com clientes Problemas Causados pelo fornecedor Promessas de prazo impossíveis Custos artificialmente baixos Falta de competência Baixa qualidade do produto Causados pelo cliente Exigência de prazos impossíveis Exigência de novos ou alterações de requisitos