Gerenciamento de Requisitos Gerenciamento de Requisitos
|
|
- Pedro Henrique Azevedo Salgado
- 8 Há anos
- Visualizações:
Transcrição
1 Gerenciamento de Requisitos
2 Objetivos da disciplina Descrever o processo de Gerenciamento e Engenharia de Requisitos para projetos Treinar alunos no Gerenciamento de Requisitos Apresentar estudos de caso Ferramentas Microsoft Office, Visio/Rational Rose, RequisitePro
3 Definição de requisito Requisitos de software podem ser definidos de várias maneiras, conforme encontrado na literatura especializada (Leffingwell & Widrig 2003): Uma condição ospecificação ou outra documeu capacidade de software requisitada por um usuário para resolver um problema e alcançar um resultado. Uma condição ou capacidade de um software que deve ser implementada por um sistema ou componente de sistema para satisfazer um contrato, padrão, entação formal. Condição necessária para alcançar certo fim; quesito Dicionário Houaiss
4
5 Problemas: Requisitos Definições Comunicação Eu disse monotrilhos Não disse!
6 Principal motivo de falhas em projetos Falta de qualidade em levantamentos e controle de requisitos!!!
7 Fontes de erro Gerenciamento de Requisitos 1. Falta de Especificação do Usuário 12.8% 2. Requisitos Incompletos 12.3% 3. Mudança de Requisitos 11.8% 4. Falta de Apoio Executivo 7.5% 5. Tecnologia Imatura 7.0% 6. Falta de Recursos 6.4% 7. Expectativas irreais 5.9% 8. Objetivos obscuros 5.3% 9. Tempo irreal 4.3% 10. Tecnologia nova 3.7% 11. Outros, e.g., Falta de planejamento 23.0% Standish Group, 00
8 Problemas encontrados referentes a requisitos Manter o foco no produto Gerenciar o escopo do projeto Ter visibilidade para acompanhamento da evolução dos requisitos Dificuldade em avaliar o impacto das mudanças Dificuldade de manter atualizados todos os documentos envolvidos, após a solicitação de mudanças
9 Requisitos Gerenciamento de Requisitos Devem endereçar uma Necessidade direta ou indireta dos envolvidos em um sistema Devem ser documentados e organizados de maneira que seu entendimento seja compartilhado entre os clientes e a equipe de projeto O processo de Gerenciamento de Requisitos deve ser norteado por práticas que garantam a qualidade desses requisitos
10 Características do Produto e Requisitos de Software Podemos afirmar que há um relacionamento direto entre os requisitos chamados de Características do Produto e os Requisitos de Software. Características do Produto: descrições simples e resumidas dos serviços ou capacidades do sistema Requisitos de Software: expressam essas características ou capacidades com muito mais detalhes.
11 Tipos de requisitos Categorização de requisitos pelo modelo FURPS+ Functionality (Funcionalidade) Usability (Usabilidade) Reliability (Confiabilidade) Performance (Desempenho) Supportability (Suportabilidade)
12 Tipos de requisitos O sinal + EM FURPS+ significa outros requisitos que são igualmente importantes: Restrições de projeto: especificam ou restringem o projeto de um sistema e podem estar expressos em um Guia de Projeto; Requisitos de Implementação: especificam ou restringem padrões, linguagens, ambientes e outros para a construção do sistema; Requisitos de Interface: especificam itens externos com os quais o sistema deve interagir; Requisitos Físicos: especificam ou restringem plataformas físicas (hardware, redes).
13 Categorias de requisitos Categoria Funcionalidade descreve os recursos funcionais que o sistema deve ter. São os chamados Requisitos Funcionais do software. As demais categorias (URPS) descrevem os Requisitos não Funcionais que são significantes para o sistema, do ponto de vista da arquitetura
14 Categorização de requisitos Atributos Mínimos: Os atributos listados a seguir relacionados a categorização são considerados obrigatórios para o gerenciamento de requisitos executado nos projetos. O Analista de Requisitos e o Coordenador de Projetos podem estabelecer outros atributos, de acordo com as necessidades específicas do projeto.
15 Categorização de requisitos Benefício: Indica o grau de benefício ou prioridade dos requisitos em relação às expectativas dos Fornecedores de Requisitos. Valor Crítico Importante Desejável Descrição Requisitos essenciais cujo fracasso em sua implementação significa que o sistema não irá atender as Necessidades dos interessados. Imprescindível que seja atendido pelo sistema, condição fundamental para o sucesso do projeto. Requisitos importantes para a eficácia ou eficiência do sistema. Sua não implementação afeta a satisfação do usuário e/ou o valor agregado do produto e o não atendimento não determinam o fracasso do projeto. Requisitos desejáveis, porém menos críticos, sendo usados menos freqüentemente. Não possui muito significado para a satisfação do usuário e pode deixar de ser atendida.
16 Categorização de requisitos Estabilidade: Indica o grau de maturidade e confiabilidade em relação ao entendimento e comprometimento de um requisito entre os envolvidos do projeto. Valor Descrição Alta Média Baixa Deve indicar requisitos que possuem alto grau de estabilidade. O entendimento pela Equipe de Projeto e pelos Fornecedores de Requisitos é evidente e a probabilidade de ocorrência de mudanças é baixa. Requisitos cuja probabilidade de ocorrência de mudanças é considerável. Alguns fatores que determinam esse valor são: requisitos ainda não entendidos completamente pela equipe de projeto ou com algumas pendências de definições por parte do Fornecedor do Requisito. Requisitos cuja mudança é certa, devido à baixa maturidade do mesmo. Requisitos altamente complexos, requisitos com muitas pendências de definição, requisitos com histórico de mudanças elevadas e requisitos com influências externas (Leis, outros sistemas) são alguns fatores que influenciam para esse valor.
17 Categorização de requisitos Situação: Indica a situação atual de um requisito. Valor Descrição Proposto Indica requisitos que foram solicitados pelos Fornecedores de Requisitos, mas ainda estão em análise pela Equipe de Projeto ou pelo Cliente. Aprovado Requisito aprovado e incorporado ao escopo do sistema. Cancelado Requisito que foi cancelado. Para ser cancelado o requisito pode estar Aprovado, e neste caso será retirado do escopo do sistema, ou pode estar simplesmente Proposto.
18 Categorização de requisitos Risco: Indica grau de risco de implementação de um determinado requisito na visão da Equipe de Projeto. Valor Descrição Alta Média Baixa Requisitos cujo risco de implementação é alto devido aos seguintes fatores: requisitos com baixa estabilidade, requisitos com alta complexidade, inovações tecnológicas e dependências externas e alto custo de implementação. Seguir os mesmos critérios anteriores, passível de análise dos níveis de influência exercidos pelos fatores. Idem
19 Categorização de requisitos Responsável: Indica o nome do responsável na Equipe de Projeto pelo requisito. Membro Equipe Valor da Descrição Estabelece o membro da equipe responsável no momento pelo requisito. Pode ser alterado durante o tempo.
20 Categorização de requisitos Observações: Atributo livre para registro de observações como pendências ou problemas que atualmente está ocorrendo com o requisito. Valor Texto Livre Descrição Importante recurso para que o Analista de Requisitos ou o Coordenador de Projetos registre pendências encontradas no desenvolvimento do requisito.
21 Representação de requisitos Podemos representar os requisitos como uma pirâmide, onde cada nível da pirâmide representa um nível de requisito e as bases são refinadas a partir da camada superior. Rastreabilidade Problema Domínio do Problema Necessidades Características Domínio da Solução Requisitos de Software
22 Representação de requisitos O Problema, representado pela nuvem na Figura 1, é o domínio do problema dos usuários e outros envolvidos, pessoas cujas necessidades devem ser atendidas para a construção do sistema. Geralmente, o domínio do problema envolve conhecimentos em áreas diversas, passando por simples Controles de Vendas até negócios complexos como cálculos financeiros ou sistemas de controle. Rastreabilidade Problema Domínio do Problema Necessidades Características Domínio da Solução Requisitos de Software
23 Rastreabilidade de requisitos A seta Rastreabilidade na Figura 1 mostra que os requisitos de mais alto nível podem originar outros Tipos de Requisitos, sendo que o Tipo Requisitos de Software fatalmente será subdividido em outros Tipos. Note que a Figura representa a rastreabilidade entre Tipos de Requisitos Os componentes também devem ser mantidos consistentes com os requisitos que o originam através do uso de uma identificação única. Esta identificação pode seguir o seguinte padrão: TIPSEQ, onde: TIP abreviação com três letras que representa o Tipo de Requisito, conforme planejado no Plano de Gerenciamento de Requisitos. SEQ número seqüencial.
24 Rastreabilidade entre tipos de requisitos Rastreabilidade Horizontal Rastreabilidade Vertical Requisito Funcional Requisito Funcional Fornecedor de Requisitos Necessidade Característica Requisito Funcional Requisitos não Funcional Casos de Teste Elementos de Projeto Casos de Teste
25 Tipos de rastreabilidade Existem dois tipos de rastreabilidade: Vertical e Horizontal Rastreabilidade Vertical: indica relacionamentos entre requisitos de tipos diferentes Rastreabilidade Horizontal: indica relacionamentos entre requisitos de mesmo tipo
26 Representação de requisitos Baseado no Problema, as Necessidades dos usuários e outros envolvidos são endereçadas (representados pelo topo da pirâmide) e deverão originar todos os outros requisitos. Características do Produto são um dos tipos de requisitos que representam o Domínio da Solução de Software Características do Produto indicam recursos e a capacidade que um sistema deve fornecer para atender as necessidades dos principais envolvidos
27 Representação de requisitos Necessidades e Características são fortemente relacionadas Necessidades indicam O QUE o sistema deve fornecer Características indicam COMO o sistema deverá se comportar para atender determinada Necessidade Na base da pirâmide encontram-se os Requisitos de Software, que representam as funcionalidades que o sistema de software deve fornecer
28 Definição para Gerenciamento de Requisitos Uma definição para Gerenciamento de Requisitos pode ser: Um enfoque sistemático para elicitar, organizar e documentar os requisitos de um sistema, e o processo que estabelece e mantém acordos entre o cliente e a equipe de projeto sobre as mudanças de requisitos do sistema.
29 Processo de Gerenciamento de Requisitos Determina quais os procedimentos devem ser seguidos nos projetos para o gerenciamento e a licitação de requisitos funcionais e não funcionais do sistema a ser desenvolvido. Define papel do analista de requisitos para execução das atividades de gerenciamento e engenharia de requisitos Define como planejar, executar e controlar requisitos Serve como guia para identificação, análise, documentação, organização, validação, e rastreamento dos requisitos de um sistema.
30 Analista de Requisitos Atividades: Planejar o gerenciamento de requisitos juntamente com o Coordenador de Projetos através da elaboração de um plano Realizar a análise do problema envolvido no projeto do sistema, com a elaboração dos documentos preliminares de requisitos, como o documento de visão
31 Processo de Gerenciamento de Requisitos Processo contínuo, repetido durante todo o ciclo de vida do projeto Focado no registro e rastreabilidade dos requisitos Determina quais os procedimentos devem ser seguidos nos projetos para o gerenciamento e a licitação de requisitos funcionais e não funcionais do sistema a ser desenvolvido. Define papel do analista de requisitos para execução das atividades de gerenciamento e engenharia de requisitos Define como planejar, executar e controlar requisitos Serve como guia para identificação, análise, documentação, organização, validação, e rastreamento dos requisitos de um sistema
32 Processo de Gerenciamento de Requisitos Planejar gerenciamento de requisitos Analisar o problema Definir sistema Refinar requisitos Aprovar requisitos Manter rastreabilidade
33 Planejar gerenciamento de requisitos Elaborar o Plano de Gerenciamento de Requisitos e o ambiente necessário para as atividades de gerenciamento, desenvolvimento e rastreabilidade de requisitos. Gerenciamento de Requisitos
34 Planejar gerenciamento de requisitos No planejamento de gerenciamento de requisitos é gerado o Plano de Gerenciamento de Requisitos que contém: Gerenciamento de Requisitos Estabelecimento de reuniões periódicas entre a equipe de projeto Apresentações formais dos requisitos para os clientes Validação de requisitos tecnológicos e metodológicos com as áreas competentes do cliente Realização de workshops envolvendo as várias frentes de levantamento de requisitos para identificar requisitos conflitantes Realização de workshops envolvendo os Analistas de Requisitos, Projetistas e Arquiteto de Software com o objetivo de validar diferentes aspectos de requisitos Sistematização do processo de revisões e inspeções
35 Critérios para validação e aceitação de requisitos Os requisitos devem ser: Claros: os requisitos devem estar escritos de maneira clara, qualquer integrante da equipe deve ser capaz de entender o requisito Completos: nenhum detalhe importante deve ser omitido, tais como dados de entrada e saída, regras de validação ou interação do usuário com o sistema Consistentes: um requisito não pode contradizer um outro requisito Únicos: evitar duplicidade de requisitos Viáveis: alguns requisitos de sistema não são requisitos de software, portanto não são implementáveis Testáveis: requisitos possíveis de serem testados quando implementados Rastreáveis: requisitos que derivam de algum outro requisito ou darão origem a outros requisitos
36 Ambiente de Requisitos O Ambiente de requisitos é composto por: Ferramenta de Gerenciamento e Desenvolvimento dos requisitos A configuração da ferramenta para suportar a estrutura de requisitos definida Customização dos templates para especificação dos requisitos
37 Identificação de Fornecedores de Requisitos Qualquer pessoa que é afetada em termos materiais pelo resultado do projeto, cujas necessidades devem ser atendidas pelo sistema que está sendo construído. O Ambiente de requisitos é composto por: Fornecedores de Requisitos: Cliente patrocinador Usuário Final Áreas Técnicas do Cliente (Qualidade, Produção, Banco de Dados, Tecnologias)
38 Identificação de Fornecedores de Requisitos Identificadas e registradas no documento Plano de Gerenciamento de Requisitos. São selecionados a partir dos seguintes critérios: Gestores do negócio Usuários finais, que são os fornecedores de requisitos preferenciais Pessoas com alçada para tomada de decisão Pessoas ou áreas que avaliarão e aprovarão os produtos gerados Patrocinador ou Cliente do Projeto
39 Estratégias para levantamento de requisitos O Analista de Requisitos e o Coordenador de Projetos devem definir estratégias para realizar o levantamento de requisitos e registrá-las no Plano de Gerenciamento de Requisitos. Estratégias diferenciadas podem ser úteis nas seguintes situações: Quando há Fornecedores de Requisitos dispersos geograficamente Quando há Fornecedores de Requisitos com pouca disponibilidade de tempo Quando há dificuldade no acesso a algum Fornecedor de Requisito importante
40 Identificar necessidades Tendo o problema mapeado e entendido por todos os envolvidos identificados, é hora de definir claramente as Necessidades dos Interessados. O Analista de Requisitos deve identificar o que é desejado no novo sistema para resolver os problemas.
41 Identificar restrições Toda restrição imposta para a solução deve ser cuidadosamente analisada e considerada como parte do planejamento do projeto. São exemplos de restrições: Econômicas: licenças de software, custos não cobertos pela métrica Tecnologia: novas tecnologias, ambiente físico, plataformas Sistemas: sistemas operacionais, compatibilidade com soluções existentes Ambiente: requisitos legais e estatutários Cronograma: prazos legais, indisponibilidade de recursos
42 Levantar Características do Produto Gerenciamento de Requisitos Neste subprocesso, o Analista de Requisitos deve iniciar o Domínio da Solução, e propor características ou capacidades que o produto ou sistema deve fornecer para atender as Necessidades dos Interessados. Esse tipo de requisito é chamado Característica do Produto e deve ser registrada no documento Visão
43 Levantar Características do Produto Gerenciamento de Requisitos Uma Característica do Produto pode ser definida como um serviço que o sistema deve fornecer para preencher uma ou mais Necessidades. Uma característica deve ser expressa em linguagem natural e consiste de uma frase curta e direta. O conjunto de características de um produto ou sistema deve servir para definir a solução, comunicar com usuários, gerenciar a complexidade e o escopo do sistema.
44 Levantar Características do Produto Gerenciamento de Requisitos Exemplos: O sistema deve ser compatível com Windows XP O sistema deve distinguir perfis de usuários O sistema deve ser capaz de anexar arquivos com tamanho de até 2MB O sistema deve ser capaz de enviar mensagens eletrônicas às pessoas convocadas para as reuniões. O sistema deve reportar o inventário de todos os itens, atualizados na data e hora da emissão. O sistema deve controlar acesso de usuários O sistema deve ser capaz de armazenar o histórico de operações
45 Requisitos de Software Requisitos Funcionais Requisitos Funcionais são aqueles que definem as funções ou ações que o sistema deve fornecer. Casos de uso Funções Regras de negócio Interfaces Internas Interfaces Externas
46 Requisitos de Software Requisitos Não Funcionais Requisitos não funcionais descrevem atributos do sistema ou do ambiente do sistema. São tipos de Requisitos não Funcionais: Usabilidade Confiabilidade Desempenho Suportabilidade Restrições de projeto Requisitos de Implementação Requisitos de Interface Requisitos Físicos
47 Especificar Requisitos Funcionais Nesta atividade, o Analista de Requisitos deve documentar os detalhes dos Requisitos Funcionais, especificando os seguintes itens: Pré-condições e pós-condições Fluxos de operação Entradas e saídas Interação do sistema com as Interfaces Externas e Usuários Interfaces internas Restrições de segurança e permissões Exceções Regras de negócio
48 Especificar Requisitos Não Funcionais Nesta atividade, o Analista de Requisitos deve documentar os detalhes dos Requisitos não Funcionais, especificando os seguintes itens: Exemplos Usabilidade: Existência de padrões especiais de Interface Homem-Máquina; Especificar requisitos que enfatizam o aumento da eficiência do usuário final, tais como ajuda on-line, suporte a idiomas, e outros. Confiabilidade O sistema deve prover facilidades de operação, como recuperação automática de erros.
49 Especificar Requisitos Não Funcionais Desempenho Descrever em que nível os requisitos estabelecidos pelo usuário influenciam o projeto, desenvolvimento, instalação e suporte da aplicação. Suportabilidade Existe processamento distribuído Existência de diferentes sistemas operacionais ou plataformas Especificar diferentes protocolos de comunicação
50 Especificar Requisitos Não Funcionais Restrições de projeto Aplicação com módulos que precisam ser reutilizadas em outros sistemas, causando esforços adicionais ao projeto Requisitos de Implementação Restringe o código ou a construção do sistema Requisitos de Interface Especificar características especiais para integração com outros sistemas Requisitos Físicos Esse tipo de requisito pode ser usado para representar requisitos de hardware, como as configurações físicas de rede obrigatórias
51 Especificar Cenário Operacional Cenário Operacional é uma representação de um fluxo de operação completo para os usuários finais, e pode abranger um conjunto de operações executadas seqüencialmente pelo usuário. Esse fluxo deve resultar em algo satisfatório e significante para o usuário. Nesta atividade, o Analista de Requisitos deve gerar, com base nas Especificações dos Requisitos Funcionais e no Visão, as Especificações de Cenários Operacionais.
52 Criar Protótipos Nesta atividade, o Analista de Requisitos deve construir, com base nas Especificações de Requisitos Funcionais, os Protótipos funcionais do sistema. Esses protótipos devem cobrir as principais funcionalidades do sistema, objetivando melhor entendimento pelos Fornecedores de Requisitos e equipe de projeto em relação aos Requisitos Funcionais do sistema. Prototipação é uma técnica muito importante para obter o entendimento dos requisitos funcionais do sistema. Quanto maior o grau de dinamismo de um protótipo, mais poderoso ele se torna para alcançar esse objetivo. No entanto, deve-se tomar cuidado para que os usuários entendam que o protótipo não materializa, neste momento, a solução final para o sistema.
53 Consolidar requisitos Neste processo o Analista de requisitos deve revisar os documentos: Visão, Especificações de Requisitos Funcionais, Especificações de Requisitos não Funcionais, Protótipos, Especificações de Cenários Operacionais, Matrizes de Rastreabilidade e Atributos de Requisitos nos seguintes aspectos: Inconsistências entre os Requisitos de Software e as Necessidades dos Interessados Inconsistências entre os Requisitos de Software e o Plano do Projeto Interfaces externas Interfaces internas
54 Consolidar requisitos Neste processo o Analista de requisitos deve revisar os documentos: Visão, Especificações de Requisitos Funcionais, Especificações de Requisitos não Funcionais, Protótipos, Especificações de Cenários Operacionais, Matrizes de Rastreabilidade e Atributos de Requisitos nos seguintes aspectos: Verificar requisitos que podem impactar em prazos e/ou custos Identificação e análise de riscos relacionados Validação dos requisitos em relação às necessidades dos Fornecedores de Requisitos
55 Análise dos requisitos A análise de requisitos deve assegurar que os Requisitos são: Completos: possuem todas as informações necessárias para o seu desenvolvimento Viáveis: a implementação é viável quanto às restrições da solução técnica Executáveis: contém todos os passos e regras que possibilitem a sua execução Verificáveis: é possível verificar se o que foi implementado corresponde com o Requisito especificado. Rastreáveis: estão representados as origens e associações entre os requisitos
56 Análise de restrições Toda restrição imposta para a solução é cuidadosamente analisada e considerada como parte do planejamento do projeto. Nessa atividade, importantes riscos podem ser identificados pelo Analista de Requisitos São exemplos de restrições: Econômicas: licenças de software, custos não cobertos pela métrica Tecnologia: novas tecnologias, ambiente físico, plataformas Sistemas: sistemas operacionais, compatibilidade com soluções existentes Ambiente: requisitos legais e estatutários Cronograma: prazos legais, indisponibilidade de recursos
57 Refinar requisitos O Objetivo deste Processo é especificar os requisitos identificados, Funcionais e não Funcionais, criar protótipos funcionais e consolidar os requisitos detalhados. O Analista de Requisitos especifica os requisitos funcionais e os não funcionais, atualiza os atributos de requisitos e matriz de rastreabilidade, especifica os cenários operacionais e cria os protótipos.
58 Refinar requisitos O Analista de Requisito, o Arquiteto de software, o Analista de Teste e o Coordenador de Projetos analisam o documento Visão, Especificações de Requisitos Funcionais, Especificações de Requisitos não Funcionais, Protótipos, Especificações de Cenários Operacionais, Matrizes de Rastreabilidade e Atributos de Requisitos nos seguintes aspectos: Inconsistências entre os Requisitos de Software e as Necessidades dos Interessados Inconsistências entre os Requisitos de Software e o Plano do Projeto Interfaces externas Interfaces internas
59 Aprovação dos requisitos Nesta atividade, o Analista de Requisitos e Coordenador de Projetos realizam a apresentação para os Fornecedores de Requisitos em uma reunião de validação. O Coordenador de Projetos deve garantir que as pessoas certas estejam presentes na validação, e que todos os artefatos necessários sejam enviados com antecedência. A apresentação deve ser mediada pelo Coordenador de Projetos, que cuida para que o foco da reunião se restrinja somente aos artefatos que são objeto de avaliação.
60 Manter rastreabilidade dos requisitos A finalidade de estabelecer rastreabilidade é ajudar a: Compreender a origem dos requisitos Gerenciar o escopo do projeto Gerenciar as mudanças nos requisitos Avaliar o impacto no projeto devido a mudanças nos requisitos Avaliar o impacto da falha de um teste nos requisitos (isto é, se o teste falhar, talvez o requisito não seja atendido) Verificar se todos os requisitos do sistema são desempenhados pela implementação Verificar se o aplicativo faz apenas o que era esperado que ele fizesse
61 Artefatos produzidos no Gerenciamento de requisitos Ata de Reunião Especificação de Caso de Uso Especificação de Cenários Operacionais Especificação de Requisitos Funcionais Especificação de Tela Especificação Suplementar Glossário
62 Artefatos produzidos no Gerenciamento de requisitos Lista de Requisitos Matriz de Rastreabilidade Modelo de Casos de Uso Plano de Gerenciamento de Requisitos Regras Negócio Roteiro de Teste Visão
63 Obrigado!
Gerenciamento da Integração (PMBoK 5ª ed.)
Gerenciamento da Integração (PMBoK 5ª ed.) O PMBoK diz que: O gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar
Leia maisCurso Superior de Tecnologia em Banco de Dados e Sistemas para Internet Disciplina: Projeto Integrador III Prof.: Fernando Hadad Zaidan
Faculdade INED Curso Superior de Tecnologia em Banco de Dados e Sistemas para Internet Disciplina: Projeto Integrador III Prof.: Fernando Hadad Zaidan Ago-2008 1 Gestão de requisitos 2 Bibliografia: PAULA
Leia maisProcessos de gerenciamento de projetos em um projeto
Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.
Leia maisMDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI
MDMS- Metodologia de Desenvolvimento e Manutenção de Sistemas da Superintendência de Tecnologia da Informação - STI Metodologia de Desenvolvimento e Manutenção de Sistemas da Histórico de Alterações Versão
Leia maisPorque estudar Gestão de Projetos?
Versão 2000 - Última Revisão 07/08/2006 Porque estudar Gestão de Projetos? Segundo o Standish Group, entidade americana de consultoria empresarial, através de um estudo chamado "Chaos Report", para projetos
Leia maisGerenciamento de Projetos Modulo II Clico de Vida e Organização
Gerenciamento de Projetos Modulo II Clico de Vida e Organização Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos
Leia maisIntrodução ao Modelo de Referência para melhoria do processo de software (MR mps) Projeto: mps Br melhoria de processo do software Brasileiro
Introdução ao Modelo de Referência para melhoria do processo de software (MR mps) Realidade das Empresas Brasileiras ISO/IEC 12207 ISO/IEC 15504 CMMI Softex Governo Universidades Modelo de Referência para
Leia maisGerenciamento de Projetos Modulo III Grupo de Processos
Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento
Leia maisNORMA NBR ISO 9001:2008
NORMA NBR ISO 9001:2008 Introdução 0.1 Generalidades Convém que a adoção de um sistema de gestão da qualidade seja uma decisão estratégica de uma organização. O projeto e a implementação de um sistema
Leia maisDESENVOLVENDO O SISTEMA
DESENVOLVENDO O SISTEMA Declaração da Necessidade O primeiro passo do processo de análise de sistema envolve a identificação da necessidade [Pressman-95]. Normalmente o analista reúne-se com o usuário
Leia maisAnálise de Sistemas. Contextualização. O Sucesso. Aula 4. Instrumentalização. Aula 4. Prof. Emerson Klisiewicz. Clientes satisfeitos
Análise de Sistemas Aula 4 Contextualização Prof. Emerson Klisiewicz Aula 4 Gerenciamento de Requisitos Refinamento de Requisitos Aprovação de Requisitos Matriz de Rastreabilidade O Sucesso Clientes satisfeitos
Leia maisLISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE
Questionamento a alta direção: 1. Quais os objetivos e metas da organização? 2. quais os principais Produtos e/ou serviços da organização? 3. Qual o escopo da certificação? 4. qual é a Visão e Missão?
Leia maisPolítica Gestão de Configuração e Mudança
Política Gestão de Configuração Histórico de Alteração Data Versão Descrição Autor 20/08/2011 1 Versão Inicial Danilo Costa Versão 1 Pág. 2 de 7 Índice 1. POLÍTICA 4 1.1 Aplicabilidade 4 2. CONCEITUAÇÃO
Leia maisRoteiro SENAC. Análise de Riscos. Planejamento do Gerenciamento de Riscos. Planejamento do Gerenciamento de Riscos
SENAC Pós-Graduação em Segurança da Informação: Análise de Riscos Parte 2 Leandro Loss, Dr. Eng. loss@gsigma.ufsc.br http://www.gsigma.ufsc.br/~loss Roteiro Introdução Conceitos básicos Riscos Tipos de
Leia maisDiretrizes de Qualidade de Projetos
Diretrizes de Qualidade de Projetos Versão 1.5 MAPA/SE/SPOA/CGTI, 2012 Página 1 Histórico de Revisão Data Versão Descrição Autor 15/01/2012 1.0 Criação do Artefato Pérsio Mairon 10/03/2012 1.1 Inclusão
Leia maisIntrodução. Gerência de Projetos de Software. Sumário. Sistemas de Informação para Processos Produtivos
Sumário Sistemas de Informação para Processos Produtivos 1. Gerência de 2. Agentes principais e seus papéis 3. Ciclo de vida do gerenciamento de projetos M. Sc. Luiz Alberto lasf.bel@gmail.com Módulo 6
Leia maisWhite-box test: Também conhecido como teste estrutural, tem por objetivo validar os dados derivados das funções do sistema.
22. Planejamento, Especificação e Execução dos Testes A implantação de um sistema de boa qualidade, dentro de um prazo específico, pode ser seriamente prejudicada caso uma etapa extremamente importante
Leia maisProcessos de Gerenciamento de Projetos. Planejamento e Controle de Projetos 5 TADS FSR. Processos
Processos de Gerenciamento de Projetos Planejamento e Controle de Projetos 5 TADS FSR Prof. Esp. André Luís Belini 2 Processos O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas
Leia maisPolítica de Gerenciamento de Risco Operacional
Política de Gerenciamento de Risco Operacional Departamento Controles Internos e Compliance Fevereiro/2011 Versão 4.0 Conteúdo 1. Introdução... 3 2. Definição de Risco Operacional... 3 3. Estrutura de
Leia maisMETODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS
METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS Versão 1 MDS Metodologia de Desenvolvimento de Sistemas 1 Presidente INCRA Rolf Hackbart Diretor de Gestão Estratégica DE - INCRA Roberto Kiel Coordenador Geral
Leia maisTópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software.
Engenharia de Software Aula 06 Tópicos da Aula Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 26 Março 2012 Funcionais e não funcionais De usuário e do Engenharia de Estudo
Leia maisRequisitos de Software
Requisitos de Software (Cap 6 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Requisitos funcionais e não funcionais
Leia maisMINISTÉRIO DA FAZENDA SECRETARIA EXECUTIVA
PROGRAMA DE MODERNIZAÇÃO INTEGRADA DO MINISTÉRIO DA FAZENDA - PMIMF MINISTÉRIO DA FAZENDA SECRETARIA EXECUTIVA ATORES DA REDE DE INOVAÇÃO 2 O MODELO CONTEMPLA: Premissas e diretrizes de implementação Modelo
Leia maisElicitação de requisitos e análise
Elicitação de requisitos e análise Esta atividade divide-se em dois esforços maiores: Elicitação dos requisitos em si Técnicas de elicitação Análise do que foi elicitado Processo de análise 1 Que é um
Leia maisEngenharia de Software na Prática Hélio Engholm Jr.
Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade
Leia maisGerenciamento de Requisitos
Gerenciamento de Requisitos Jaelson Castro 2013 1 Gerenciamento de requisitos Relaciona-se ao processo de gerenciar a mudança dos requisitos de um sistema As principais preocupações do gerenciamento de
Leia maisMetodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr
Metodologia de Desenvolvimento de Software Prof. M.Sc. Sílvio Bacalá Jr Objetivos Discutir aspectos de Engenharia de Software Aplicar um método de desenvolvimento para especificação e projeto de software
Leia maisO Processo de Engenharia de Requisitos
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA O Processo de Engenharia de Requisitos Engenharia de Software 2o.
Leia maisRequisitos do usuário, do sistema e do software [Sommerville, 2004]
Requisitos Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema Condição ou capacidade necessária que o software deve possuir para que
Leia maisADMINISTRAÇÃO I. Família Pai, mãe, filhos. Criar condições para a perpetuação da espécie
1 INTRODUÇÃO 1.1 ORGANIZAÇÃO E PROCESSOS A administração está diretamente ligada às organizações e aos processos existentes nas mesmas. Portanto, para a melhor compreensão da Administração e sua importância
Leia maisQUALIDADE DE SOFTWARE
QUALIDADE DE SOFTWARE - 02 Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão 1 A ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software.
Leia maisPOLÍTICA DE GESTÃO DE RISCO - PGR
POLÍTICA DE GESTÃO DE RISCO - PGR DATASUS Maio 2013 Arquivo: Política de Gestão de Riscos Modelo: DOC-PGR Pág.: 1/12 SUMÁRIO 1. APRESENTAÇÃO...3 1.1. Justificativa...3 1.2. Objetivo...3 1.3. Aplicabilidade...4
Leia maisIntrodução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização
Prof. Ricardo José Pfitscher Material elaborado com base em: José Luiz Mendes Gerson Volney Lagemann Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento
Leia maisGerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto
Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Organização do Projeto Os projetos e o gerenciamento
Leia maisO Banco Central do Brasil em 29/06/2006 editou a Resolução 3380, com vista a implementação da Estrutura de Gerenciamento do Risco Operacional.
1 POLÍTICA DE GERENCIAMENTO DO RISCO OPERACIONAL 1.1 Introdução O Banco Central do Brasil em 29/06/2006 editou a Resolução 3380, com vista a implementação da Estrutura de Gerenciamento do Risco Operacional.
Leia maisMetadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados
1. Introdução O governo é um dos maiores detentores de recursos da informação. Consequentemente, tem sido o responsável por assegurar que tais recursos estejam agregando valor para os cidadãos, as empresas,
Leia maisPMBOK 4ª Edição III. O padrão de gerenciamento de projetos de um projeto
PMBOK 4ª Edição III O padrão de gerenciamento de projetos de um projeto 1 PMBOK 4ª Edição III Processos de gerenciamento de projetos de um projeto 2 Processos de gerenciamento de projetos de um projeto
Leia maisEngenharia de Requisitos de Software
Engenharia de Requisitos de Software Marcelo Otone Aguiar, MSc, PMP PROJETOS 1 O que é Projeto Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. PMI
Leia maisAula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW
Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto
Leia maisCAPABILITY MATURITY MODEL FOR SOFTWARE. Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com
CAPABILITY MATURITY MODEL FOR SOFTWARE Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com 1. Introdução Após décadas de incontáveis promessas sobre como aumentar à produtividade e qualidade de software,
Leia maisTRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES
TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado
Leia maisEngenharia de Software III
Departamento de Informática Programa de Pós Graduação em Ciência da Computação Laboratório de Desenvolvimento Distribuído de Software Estágio de Docência Cronograma e Método de Avaliação Datas Atividades
Leia maisQuestionário de Avaliação de Maturidade Setorial: Modelo PRADO-MMGP
DARCI PRADO Questionário de Avaliação de Maturidade Setorial: Modelo PRADO-MMGP Versão 1.6.4 Setembro 2009 Extraído do Livro "Maturidade em Gerenciamento de Projetos" 2ª Edição (a publicar) Autor: Darci
Leia maisITIL v3 - Operação de Serviço - Parte 1
ITIL v3 - Operação de Serviço - Parte 1 É na Operação de Serviço que se coordena e realiza as atividades e processos necessários para fornecer e gerenciar serviços em níveis acordados com o usuário e clientes
Leia maisQualidade de Software
Qualidade de Software Projeto e Desenvolvimento de Sistemas Dr. Fábio Levy Siqueira levy.siqueira@gmail.com Aula 2: Garantia da Qualidade e Padrões Qualidade de software Quais são as atividades de Gestão
Leia maisGerenciamento de Projeto: Planejando os Riscos. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br
Gerenciamento de Projeto: Planejando os Riscos Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Introdução Planejar o Gerenciamento dos Riscos. Identificar os Riscos Realizar a Análise Qualitativa
Leia maisCHAMADA PÚBLICA SIMPLIFICADA Nº 15/2013 SELEÇÃO DE PROFISSIONAIS PARA O PROJETO REGISTRO DE IDENTIDADE CIVIL REPLANEJAMENTO E NOVO PROJETO PILOTO
CHAMADA PÚBLICA SIMPLIFICADA Nº 15/2013 SELEÇÃO DE PROFISSIONAIS PARA O PROJETO REGISTRO DE IDENTIDADE CIVIL REPLANEJAMENTO E NOVO PROJETO PILOTO 1. PROJETO SELECIONA PROFISSIONAIS PARA DIVERSOS PERFIS
Leia maisIntrodução. Escritório de projetos
Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é um documento formal que descreve normas,
Leia maisQuestionário de avaliação de Práticas X Resultados de projetos - Carlos Magno Xavier (magno@beware.com.br)
Obrigado por acessar esta pesquisa. Sei como é escasso o seu tempo, mas tenha a certeza que você estará contribuindo não somente para uma tese de doutorado, mas também para a melhoria das práticas da Comunidade
Leia maisResolução da lista de exercícios de casos de uso
Resolução da lista de exercícios de casos de uso 1. Explique quando são criados e utilizados os diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Na fase de concepção se
Leia maisConteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
Leia maisRegimento Interno do Sistema
Identificação: R.01 Revisão: 05 Folha: 1 / 14 Artigo 1 - Objetivo do documento 1.1. Este documento tem como objetivo regulamentar as atividades para credenciamento de uma planta de produção com o SELO
Leia maisEngenharia de Software II
Engenharia de Software II Aula 28 Revisão para a Prova 2 http://www.ic.uff.br/~bianca/engsoft2/ Aula 28-28/07/2006 1 Matéria para a Prova 2 Gestão de projetos de software Conceitos (Cap. 21) Métricas (Cap.
Leia maisProfessor: Curso: Disciplina: Aula 4-5-6
Professor: Curso: Disciplina: Aula 4-5-6 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Engenharia de Requisitos 03º semestre 1 Engenharia de Requisitos Prof. Marcos
Leia maisTechProf Documento de Arquitetura
TechProf Projeto SuporteProf Versão 1.0 15 de junho de 2016 Responsáveis: Adelson Santos de Melo Filho, Edvaldo Nicolau da Silva, Moisés Luis da Silva Histórico de Revisões Data Versão Descrição Autor
Leia mais3. Fase de Planejamento dos Ciclos de Construção do Software
3. Fase de Planejamento dos Ciclos de Construção do Software A tarefa de planejar os ciclos de construção do software pode partir de diretrizes básicas. Estas diretrizes visam orientar que os ciclos de
Leia maisCasos de uso Objetivo:
Casos de uso Objetivo: Auxiliar a comunicação entre os analistas e o cliente. Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. O cliente deve ver no diagrama de
Leia mais1.1. Estabelecer uma sistemática de avaliação individual de desempenho para os empregados da ABDI.
de 9. OBJETIVO.. Estabelecer uma sistemática de avaliação individual de desempenho para os empregados da ABDI.. APLICAÇÃO.. Este procedimento se aplica a todos os empregados da ABDI.. DEFINIÇÕES.. Avaliação
Leia maisAnálise e Projeto de Software
Análise e Projeto de Software 1 Mundo Real Modelagem Elicitação Análise Problemas Soluções Gap Semântico Mundo Computacional Elicitação de Requisitos Análise de Requisitos Modelagem dos Requisitos 2 Projeto
Leia maisPlanejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP
Planejamento - 7 Planejamento do Gerenciamento do Risco Identificação dos riscos 1 O que é risco? Evento que representa uma ameaça ou uma oportunidade em potencial Plano de gerenciamento do risco Especifica
Leia maisCONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES
CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás
Leia maisSistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com
Sistemas Operacionais Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Estruturas de Sistemas Operacionais Um sistema operacional fornece o ambiente no qual os programas são executados. Internamente,
Leia maisGOVERNANÇA DE TI: Um desafio para a Auditoria Interna. COSME LEANDRO DO PATROCÍNIO Banco Central do Brasil
GOVERNANÇA DE TI: Um desafio para a Auditoria Interna COSME LEANDRO DO PATROCÍNIO Banco Central do Brasil Programação da Apresentação Evolução da Auditoria Interna de TI no Banco Central; Governança de
Leia maisTRANSIÇÃO DAS CERTIFICAÇÕES DOS SISTEMAS DE GESTÃO DA QUALIDADE E SISTEMAS DE GESTÃO AMBIENTAL, PARA AS VERSÕES 2015 DAS NORMAS.
TRANSIÇÃO DAS CERTIFICAÇÕES DOS SISTEMAS DE GESTÃO DA QUALIDADE E SISTEMAS DE GESTÃO AMBIENTAL, PARA AS VERSÕES 2015 DAS NORMAS. As novas versões das normas ABNT NBR ISO 9001 e ABNT NBR ISO 14001 foram
Leia maisQualidade de Software
de Software Gerenciamento de de Software Dedica-se a assegurar que o nível requerido de qualidade seja atingido Em um produto de software Envolve a definição de padrões e procedimentos apropriados de qualidade
Leia maisMINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO DIRETORIA DE ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE AQUISIÇÕES
MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO DIRETORIA DE ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE AQUISIÇÕES BANCO INTERAMERICANO DE DESENVOLVIMENTO REPRESENTAÇÃO NO BRASIL SOLICITAÇÃO DE MANIFESTAÇÃO DE
Leia maissendo bastante acessível e compreendido pelos usuários que o utilizarem.
APLICATIVO WEB PARA O SETOR DE EXTENSÃO IFC VIDEIRA Claudiléia Gaio Bandt 1 ; Tiago Heineck 2 ; Patrick Kochan 3 ; Leila Lisiane Rossi 4 ; Angela Maria Crotti da Rosa 5 INTRODUÇÃO Este artigo descreve
Leia maisClassificação de Sistemas: Sistemas Empresariais
Universidade do Contestado Campus Concórdia Curso de Ciências Contábeis Prof.: Maico Petry Classificação de Sistemas: Sistemas Empresariais DISCIPLINA: Sistemas de Informação Gerencial O QI da empresa
Leia maisRequisitos. Sistemas de Informações
Requisitos Sistemas de Informações Definindo o Sucesso do Software Clientes satisfeitos Eles estão satisfeitos quando você: Atende às expectativas Entrega no prazo Entrega no orçamento O Sucesso começa
Leia maisENGENHARIA DE SOFTWARE I
ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis
Leia maisEXTRATO DA POLÍTICA DE GESTÃO DE RISCOS
1 OBJETIVO Fornecer as diretrizes para a Gestão de Riscos da Fibria, assim como conceituar, detalhar e documentar as atividades a ela relacionadas. 2 ABRANGÊNCIA Abrange todas as áreas da Fibria que, direta
Leia maisUm passo inicial para aplicação do gerenciamento de projetos em pequenas empresas
Instituto de Educação Tecnológica Pós-graduação Gestão de Projetos Aperfeiçoamento/GPPP1301 T132 09 de outubro de 2013 Um passo inicial para aplicação do gerenciamento de s em pequenas empresas Heinrich
Leia maisEspecialidade em Ativos Calibração Conformidade Metrológica
Especialidade em Ativos Calibração Conformidade Metrológica Metrologia é a Ciência da Medida Uma reputação de qualidade é um dos bens de mais alto valor de uma empresa. A grande importância de uma alta
Leia maisEngenharia de Software
Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São
Leia maisManual do. Almoxarifado
Manual do Almoxarifado Parnaíba 2013 APRESENTAÇÃO O Almoxarifado é o local destinado à guarda, localização, segurança e preservação do material adquirido, adequado à sua natureza, a fim de suprir as necessidades
Leia maisGuia de utilização da notação BPMN
1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação
Leia maisQualidade no levantamento de requisitos
Qualidade no levantamento de Trecho do Pequeno Príncipe: Antoine Saint-Exupéry, 1996. E ele repetiu-me então, brandamente, como uma coisa muito séria: - Por favor... desenha-me um carneiro... Quando o
Leia maisREQUISITOS DE SISTEMAS
REQUISITOS DE SISTEMAS MÓDULO 2 PROCESSOS DE NEGÓCIOS CONTEÚDO 1. PROCESSOS DE NEGÓCIO IDENTIFICAÇÃO CONCEITOS MODELAGEM (BPM e UML) PROCESSOS X REQUISITOS 1. PROCESSOS DE NEGÓCIO IDENTIFICAÇÃO CONCEITOS
Leia maisMódulo5. Módulo 5. Planejamento e realização de projeto de mapeamento e modelagem de processos, Responsabilidades, Atividades-chaves, Exercício
Módulo5 Módulo 5 Planejamento e realização de projeto de mapeamento e modelagem de processos, Responsabilidades, Atividades-chaves, Exercício Todos os direitos de cópia reservados. Não é permitida a distribuição
Leia maisGerenciamento de integração de projeto
Objetivos do Conteúdo Gerenciamento de integração de projeto Sergio Scheer / DCC / UFPR TC045 Gerenciamento de Projetos Prover capacitação para: - Identificar os processos de Gerenciamento de Projetos;
Leia maisESTRUTURA DE GERENCIAMENTO DO RISCO OPERACIONAL
ESTRUTURA DE GERENCIAMENTO DO RISCO OPERACIONAL 1. INTRODUÇÃO: O Banco Pottencial, considera a gestão de riscos como um instrumento essencial para maximização da eficiência no uso do capital e para escolha
Leia maisCAPÍTULO 25 COERÊNCIA REGULATÓRIA
CAPÍTULO 25 COERÊNCIA REGULATÓRIA Artigo 25.1: Definições Para efeito deste Capítulo: medida regulatória coberta significa a medida regulatória determinada por cada Parte a ser objeto deste Capítulo nos
Leia maisGRUPO HOSPITALAR CONCEIÇÃO HOSPITAL NOSSA SENHORA DA CONCEIÇÃO LABORATÓRIO DE ANÁLISES CLÍNICAS CONTROLE DE DOCUMENTOS E DADOS
1. Objetivo POP-L02 Página 1 de 12 Estabelecer as diretrizes para o controle de todos documentos e dados do Sistema de Gestão da Qualidade, de modo a garantir a rastreabilidade e padronização dos processos
Leia maisGerenciamento de Projetos Modulo VIII Riscos
Gerenciamento de Projetos Modulo VIII Riscos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento
Leia maisUNIP Ciência da Computação / Sistemas de Informação TED I - Orientações Gerais para Elaboração dos Documentos
I - Orientações Gerais para Elaboração dos Documentos A seguir, orientações fundamentais para a elaboração dos documentos do projeto, tendo em vista a complexidade inerente neste processo. Este roteiro
Leia maisFase de Análise de Requisitos. Engenharia de Software ANÁLISE DE REQUISITOS. Tipos de Requisitos. Tipos de requisitos. Tipos de requisitos
Engenharia de Software Fase de Análise de Requisitos Engenharia de Sistemas de Computador ANÁLISE DE REQUISITOS ANÁLISE DE REQUISITOS Projeto de Software 1 2 Tipos de Requisitos 3 4 Tipos de requisitos
Leia maisDesenvolvimento de uma Etapa
Desenvolvimento de uma Etapa A Fase Evolutiva do desenvolvimento de um sistema compreende uma sucessão de etapas de trabalho. Cada etapa configura-se na forma de um mini-ciclo que abrange as atividades
Leia maisMODELAGEM DE SISTEMAS
MODELAGEM DE SISTEMAS Diagramas de Casos de Uso Profa. Rosemary Melo Diagrama de Casos de Uso Modelagem de Sistemas Apresenta uma visão externa geral das funções ou serviços que o sistema deverá oferecer
Leia maisCopyright Proibida Reprodução. Prof. Éder Clementino dos Santos
NOÇÕES DE OHSAS 18001:2007 CONCEITOS ELEMENTARES SISTEMA DE GESTÃO DE SSO OHSAS 18001:2007? FERRAMENTA ELEMENTAR CICLO DE PDCA (OHSAS 18001:2007) 4.6 ANÁLISE CRÍTICA 4.3 PLANEJAMENTO A P C D 4.5 VERIFICAÇÃO
Leia maisCase SICREDI CA Clarity PPM. CA PPM Summit Brasil 2012
Case SICREDI CA Clarity PPM CA PPM Summit Brasil 2012 Agenda Conhecendo o Sicredi Seleção e Implantação de uma Solução de PPM O CA-Clarity PPM no Sicredi Roadmap 2012 Agenda Conhecendo o Sicredi Seleção
Leia maisProcessos de gerenciamento de riscos. Planejamento Identificação Análise Resposta Monitoramento
Gerência de Riscos Processos de gerenciamento de riscos Planejamento Identificação Análise Resposta Monitoramento Gerência de Riscos O Plano de Gerência de Riscos descreve como a identificação, a análise
Leia mais