Fase de Concepção (Início, Planejamento)

Slides:



Advertisements
Apresentações semelhantes
Gerenciamento do Tempo do Projeto
Advertisements

Engenharia de Software
Um pouco mais de cardinalidade e Relacionamentos
Análise e Projeto Orientado a Objetos
Introdução a Algoritmos
Os projetos.
Gerenciamento do escopo
UML no CICLO de DESENVOLVIMENTO
APSOO Aula 03.
APSOO Aula 05.
Engenharia de Software
Rational Unified Process(RUP)
Gerenciamento de Projetos de Software Prof. Eduardo Meira Peres
Valéria Maria Lauande Março/2010
Faculdade de Ciências Sociais de Aplicadas de Petrolina – FACAPE
Prof. Aruanda Simões - Análise e Projeto OO Processo de Desenvolvimento n As grandes fases: –Planejamento e elaboração –Construção –Implantação Sistema.
Análise de Requisitos Use Case Renata Araujo Ricardo Storino
SISTEMA DE INFORMAÇÕES DESENVOLVIMENTO DE SISTEMAS
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
Introdução Visão Geral do Método.
Gabriel Silva Bornia Prof. Dr. Roberto Tom Price Orientador
TSDD Teste de segurança durante o desenvolvimento.
Análise de Sistemas Análise e Projeto Prof. Jeime Nunes Site:
Rational Unified Process
Prof.Alfredo Parteli Gomes
Fundamentos de Engenharia de SW
Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
Processos de Desenvolvimento de Software – Parte 2
Fase de Elaboração: Fluxo de Requisitos
Análise e Projeto de Sistemas Levantamento de Requisitos
Análise e Projeto de Sistemas
Engenharia de Requisitos
Oficina Mecânica TADS 2011.
Análise e Projeto de Sistemas
GESTÃO DE PROJETOS Aula 5 1.
Planejamento e Projeto de Testes
Caso de Uso - Definição Um caso de uso é uma descrição narrativa de uma seqüência de eventos que ocorre quando um ator (agente externo) usa um sistema.
Introdução e Fundamentos Engenharia de Requisitos
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
GESTÃO DE PROJETOS DE MANUTENÇÃO
Levantamento de Requisitos
O Processo Unificado (UP)
RUP - Cap. 5 – Processo Iterativo e Incremental
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Processo de Desenvolvimento de Software – PDS C Construção - PAS
Fase de Concepção Levantamento de Requisitos, Organização de Requisitos, Planejamento dos Ciclos Iterativos.
Fluxos secundários Só devem ser analisados e descritos após a descrição dos fluxos básicos. Fluxos alternativos situações especiais (desconto para um cliente)
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA TOCANTINS Campus Araguaína ANA PAULA LIMA.
Empresa de vendas de insumos para máquinas industriais
Fase de Concepção (Início, Planejamento)
Análise e Projeto de Sistemas
SISTEMA DE MONITORAMENTO DA TECNOLOGIA DA INFORMAÇÃO.
Gestão de Projetos - aula 5: organização - Profª. Vilma Tupinambá, MsC
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
Engenharia de Software
Dimitri de Almeida Malheiros Barbosa
Apresentação Leonardo Brussolo de Paula
Faculdade de Ciências Sociais de Aplicadas de Petrolina – FACAPE
Projeto: G-TV (Gestor de TV por Assinatura) CSTADS Aluno: Fellipe Weldson de Oliveira Ferreira Gerente: Eriko Brito Projeto Supervisionado de Análise e.
Estudo de Caso de Gerência de Riscos
1 Projeto Piloto Conclusão em Agenda Projeto Piloto –Descrição –Execução da aplicação –Implementação de requisitos funcionais e não- funcionais.
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso.
Levantamento de Requisitos – Simulação do Supermercado
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 Concepção (Início, Planejamento)

Objetivos Análise Preliminar Planejamento das Iterações Levantamento de Requisitos (parcial) Organização de Requisitos Modelo Conceitual Preliminar Planejamento das Iterações

Atividades Conhecer a empresa Levantar requisitos Organizar requisitos Esboçar o modelo conceitual do sistema Planejar o desenvolvimento Iterações Cronograma Recursos

Artefatos Sumário Executivo Documento de Requisitos Casos de Uso Modelo Conceitual

Sumário Executivo

Conhecimento da Empresa o que a empresa quer com o projeto? Por que ele está sendo proposto? Por que a empresa vai gastar dinheiro com o projeto? O projeto é realizável? A equipe de desenvolvimento tem condições de realizar este projeto? O cliente tem dinheiro para pagar o desenvolvimento? Há tempo disponível? Comprar ou desenvolver?

Sumário Executivo O quê? Onde? Por quê? Como? 3 páginas, no máximo Também chamado de Visão Geral do Sistema

Sumário Executivo documento de texto em formato livre

Documento de Requisitos

Levantamento de Requisitos Entrevistas Análise de Documentos Estudo Bibliográfico Comparativo

Requisitos Requisitos funcionais correspondem à listagem de todas as coisas que o sistema deve fazer Requisitos não funcionais são restrições que se coloca sobre como o sistema deve realizar seus requisitos funcionais

Requisitos Funcionais Requisitos funcionais evidentes são efetuados com conhecimento do usuário Requisitos funcionais ocultos são efetuados pelo sistema sem o conhecimento explícito do usuário

Requisitos Não Funcionais Obrigatórios Desejáveis

Requisitos Não Funcionais de interface de implementação de eficiência de tolerância a falhas etc.

Requisitos Não Funcionais Associados a requisitos funcionais Suplementares

Requisitos Não Funcionais Permanentes Transitórios

Requisitos Funcionais Código do requisito funcional (Ex.: F1, F2, F3, ...) Nome do requisito funcional (especificação curta) Descrição (especificação longa e detalhamento do requisito) Categoria funcional: evidente ou oculto

Requisitos Não Funcionais Código do requisito não funcional (Ex.: NF1.1, NF1.2, ... NF2.1, NF2.2, ...) Nome do requisito não funcional (especificação curta) Restrição: especificação (longa) do requisito não funcional Categoria: tipo de restrição: segurança, performance, compatibilidade, etc. Obrigatoriedade: se o requisito é desejável ou obrigatório Permanência: se o requisito é permanente ou transitório

Requisitos Funcionais e Não Funcionais Associados

Requisitos Suplementares

Desafios da Análise de Requisitos Como descobrir os requisitos Como comunicar os requisitos para as outras fases ou equipes do projeto Como lembrar dos requisitos durante o desenvolvimento e verificar se foram todos atendidos Como gerenciar a mudança

Organização dos Requisitos Casos de Uso Manutenção de Conceitos (Entidades) Consultas/Relatórios

Casos de Uso

Caso de Uso Um cenário de interação usuário-sistema Ordenação de um subconjunto de requisitos funcionais, e seus requisitos não-funcionais associados, relacionado com o caso de uso Pouco detalhado na fase de concepção Bastante detalhado na fase de elaboração (refinamento de casos de uso) Dado um requisito funcional, ele deve aparecer em pelo menos um caso de uso Critério de validação do caso de uso

Organizando Requisitos em Casos de Uso

Diagrama de Casos de Uso UML

Diagrama de Caso de Uso Em geral, na fase de concepção, um caso de uso não é decomposto Decomposição é detalhamento (fase de elaboração)

Granulosidade de um Caso de Uso Um caso de uso deve ser mono-sessão, ou seja, executado em uma única interação e não se estendendo ao longo de vários dias Um caso de uso deve ser interativo, com informações fluindo para dentro e para fora do sistema Um caso de uso deve produzir uma alteração consistente na informação armazenada Uma seqüência de consultas puras ao sistema não caracteriza um caso de uso Duração de um caso de uso: de alguns minutos a 1 hora (Larman)

Granulosidade de um Caso de Uso Algumas operações relativamente simples e elementares (de um único passo), como o registro de uma fita, ou de um pagamento, não devem ser consideradas como casos de uso por si só (um único passo)

Modelo Conceitual Preliminar

Modelo Conceitual A entrada para o modelo conceitual são os casos de uso Cada conceito ou entidade, assim como seus relacionamentos, deve aparecer direta ou indiretamente nas descrições dos casos de uso

Modelo Conceitual Preliminar

Modelo Conceitual Note que o modelo está incompleto Faltando contemplar o caso de uso Devolver Fitas

Manutenção de Conceitos ou Entidades

Cada conceito normalmente tem associadas operações de: inserção (I) alteração (A) exclusão (E) consulta (C)

Manutenção

Consultas / Relatórios

Organização de Requisitos em Consultas

Planejamento das Iterações

Planejamento do Desenvolvimento Alocar o desenvolvimento em ciclos iterativos de mesma duração Estimativa de Esforço

Estabelecendo Prioridades Casos de Uso Críticos Casos de Uso de Apoio Manutenção de Conceitos Consultas

Planejamento dos Ciclos Iterativos (Fase de Elaboração)

Cronograma de Execução Considerar Tempo total estimado para o projeto (em hora/pessoa) Tempo disponível (em semanas ou meses) Tamanho da equipe Estruturação da equipe

Planejamento com 4 equipes

Planejamento com 2 equipes

Observações Note que, associando requisitos não-funcionais a requisitos funcionais, a maior parte dos requisitos não-funcionais é implementada na fase de elaboração Fase de construção: requisitos suplementares Note também que, trabalhando com várias equipes, somente as atividades de implementação-testes são seqüênciais Atividades de análise-projeto podem ocorrer em paralelo

Projeto do Curso

Projeto Fase Início (Concepção, Planejamento) Documento constando de: Sumário Executivo Requisitos Funcionais e (Não-funcionais Associados) Requisitos suplementares Casos de uso Modelo Conceitual Manutenção de Entidades Consultas / Relatórios Planejamento das Iterações Prazo de entrega: 05/09