Você está na página 1de 40

30/07/2010

Metodologia para Engenharia de Software Especialização Lato Sensu Técnicas de Levantamento de Requisitos José Jorge

Metodologia para Engenharia de Software

Especialização Lato Sensu

para Engenharia de Software Especialização Lato Sensu Técnicas de Levantamento de Requisitos José Jorge Lima

Técnicas de Levantamento de Requisitos

José Jorge Lima Dias Júnior Nadja da Nóbrega Rodrigues

1

A Disciplina

Objetivo Geral

Apresentar os principais conceitos relacionados às disciplinas de Modelagem de Processos de Negócio e Engenharia de Requisitos, assim como suas técnicas, ferramentas e processos.

3

Os Docentes

Jorge Dias

Doutorando (UFPE) UFPB – Docente josejorgejr@gmail.com

Nadja Rodrigues

Mestre (UFPB) IFPB – Docente nadja.dnr@gmail.com

2

A Disciplina Objetivos Específicos Capacitar o aluno a entender o processo de desenvolvimento de software
A Disciplina
Objetivos Específicos
Capacitar
o
aluno
a
entender
o
processo
de
desenvolvimento
de
software
como
fator
crítico
de
sucesso.
Capacitar
o
aluno
a
aplicar
técnicas/ferramentas
de
modelagem de processo de negócio.
Capacitar o aluno a aplicar técnicas/ferramentas para
elicitação, validação, documentação e gerenciamento de
requisitos.
Capacitar
o
aluno
a
aplicar
técnicas/ferramentas
para
elaboração
de
casos
de
uso,
protótipos
e
regras
de
negócio/validação.
4

30/07/2010

A Disciplina A Disciplina Carga Horária Avaliação 32h Atividades desenvolvidas ao longo das aulas Projeto
A
Disciplina
A Disciplina
Carga Horária
Avaliação
32h
Atividades desenvolvidas ao longo das aulas
Projeto
Datas
17/07/2010
31/07/2010
07/08/2010
14/08/2010
5
6
A
Aula
Processos de Software
Processo de Software
RUP
Análise de Negócio
Requisitos
Processos de Software
7
8

30/07/2010

1. Qual a importância dos Processos de Software para o Desenvolvimento de Sistemas?

1. Qual a importância dos

Processos de Software

para o Desenvolvimento de Sistemas?

Alguns Problemas no Desenvolvimento de Software Alguns projetos são cancelados mesmo antes de começar O

Alguns Problemas no Desenvolvimento de Software

Alguns projetos são cancelados mesmo antes de começar

O tempo de desenvolvimento e o custo são bem maiores do que o estimado

Os sistemas não funcionam como planejado

A qualidade é baixa

A manutenção e a reutilização são difíceis e custosas

Os problemas são proporcionais à complexidade dos sistemas

Alguns Problemas no Desenvolvimento de Software Existem problemas no desenvolvimento de software?

Alguns Problemas no Desenvolvimento de Software

Existem problemas no desenvolvimento de software?

Engenharia de Software

Disciplina de engenharia relacionada a todos os aspectos de produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção, depois que entrar em operação;

30/07/2010

Engenharia de Software

Relacionada não só com os processos técnicos de desenvolvimento de software, mas também com atividades como o gerenciamento de projeto de software e o desenvolvimento de ferramentas, métodos e teorias que apóiem a produção de software;

Recomenda a aplicação de ferramentas e técnicas/métodos apropriados dependendo do problema a ser solucionado, das restrições de desenvolvimento e dos recursos disponíveis.

Algumas Atividades da Engenharia de Software Modelagem de Negócio Análise de Requisitos Análise e Projeto

Algumas Atividades da Engenharia de Software

Modelagem de Negócio Análise de Requisitos Análise e Projeto Implementação Testes Implantação/Distribuição Gerenciamento e Projetos Gerência de Configuração e Mudanças Manutenção

Métodos, Ferramentas e Procedimentos da Engenharia de Software Métodos de Engenharia de Software Detalhes de

Métodos, Ferramentas e Procedimentos da Engenharia de Software

Métodos de Engenharia de Software

Detalhes de “como fazer” para construir um software;

Ferramentas de Engenharia de Software

Criadas para apoiar de forma automatizada os métodos; Ex.: ferramentas CASE;

Procedimentos da Engenharia de Software

Elo entre métodos e ferramentas; Definem, por exemplo, a seqüência em que os métodos serão aplicados e os produtos a serem entregues;

Alguns Objetivos da Engenharia de Software Controle sobre o desenvolvimento de software dentro de custos

Alguns Objetivos da Engenharia de Software

Controle sobre o desenvolvimento de software dentro de custos, prazos e níveis de qualidade desejados;

Sistematização da produção, manutenção e evolução dos produtos;

Qualidade versus Produtividade

Aprimoramento da qualidade de software Aumento da produtividade

30/07/2010

Processo de Desenvolvimento de Software

A utilização de um processo de software têm sido apontada como um fator primordial para o sucesso de empresas de desenvolvimento de software.

O termo ciclo de vida evoluiu para processo.

O que é um processo de software?

17

Processo de Desenvolvimento de Software Requisitos do processo Requisitos do projeto e do produto Engenharia
Processo de Desenvolvimento de Software
Requisitos do processo
Requisitos do projeto
e do produto
Engenharia de
Gerência de
Engenharia de
Artefatos e
processos
projetos
software
Produto de
Processo de
Planejamento
Software
desenvolvimento
e Gerenciamento

Processo de

desenvolvimento

Processo de Desenvolvimento de Software

Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas para desenvolver um produto de software.

18

Processo de Desenvolvimento de Software

Conjunto de atividades e resultados associados que produz um produto de software;

São atividades comuns aos processos de software:

Especificação de software: definição do software a ser produzido; Desenvolvimento de software: o software é projetado e programado; Validação de software: o software é verificado para garantir que é o que o cliente deseja; Evolução de software: adaptação do software às mudanças de requisitos.

30/07/2010

Processo de Desenvolvimento de Software Enfim,o processo de desenvolvimento de software define quem faz o
Processo de Desenvolvimento de Software
Enfim,o processo de desenvolvimento de
software define quem faz o quê, quando e
como para atingir um certo objetivo.
21
Introdução ao RUP
23
Processo de Desenvolvimento de Software Algumas razões para a definição e utilização de um processo:
Processo de Desenvolvimento de Software
Algumas razões para a definição e utilização
de um processo:
Redução
dos
problemas
relacionados
a
treinamento,
revisões e suporte à ferramentas;
As experiências adquiridas nos projetos são incorporadas
ao processo padrão e contribuem para melhorias em todos
os processos definidos;
Economia de tempo e esforço na definição de novos
processos adequados a projetos.
22
O RUP
Rational Unified Process
Engenharia de Software
Processo?
Framework para gerar processos?
24

30/07/2010

O RUP

O RUP

O RUP

Segue as boas práticas da Engenharia de Software

O RUP Segue as boas práticas da Engenharia de Software Desenvolvimento de Software Iterativo e Incremental

Desenvolvimento de Software Iterativo e Incremental Gerenciamento de Requisitos Uso de Arquitetura Baseada em Componentes Modelagem Visual Verificação Contínua da Qualidade Gerenciamento de Mudanças

27

O RUP

Segue as boas práticas da Engenharia de Software

Desenvolvimento de Software Iterativo e Incremental Gerenciamento de Requisitos Uso de Arquitetura Baseada em Componentes Modelagem Visual Verificação Contínua da Qualidade Gerenciamento de Mudanças

26

O RUP - Desenvolvimento de Software Iterativo e Incremental Como comer um elefante?

O RUP - Desenvolvimento de Software Iterativo e Incremental

Como comer um elefante?

O RUP - Desenvolvimento de Software Iterativo e Incremental Como comer um elefante?

30/07/2010

O RUP - Desenvolvimento de Software

Iterativo e Incremental

Resposta certa: um pedaço de cada vez!!!

O RUP - Desenvolvimento de Software

Iterativo e Incremental

Equívocos graves são evidenciadas no início do ciclo de vida, quando é possível reagir a eles;

Essa abordagem permite e incentiva feedback dos usuários, de modo a suscitar necessidades reais do sistema;

A equipe de desenvolvimento concentra-se nas questões que são mais críticas para o projeto e tenta tratar os riscos reais do projeto;

Testes iterativos e contínuos permitem uma avaliação objetiva do estado do projeto;

O RUP - Desenvolvimento de Software

Iterativo e Incremental

O RUP - Desenvolvimento de Software Iterativo e Incremental

O RUP - Desenvolvimento de Software

Iterativo e Incremental

Inconsistências entre requisitos, projetos e implementações são detectadas mais cedo;

A carga de trabalho da equipe é espalhado mais uniformemente ao longo do ciclo de vida do projeto;

A equipe pode aproveitar as lições aprendidas e, portanto, pode melhorar continuamente o processo;

Às partes interessadas no projeto podem ser dadas provas concretas de status do projeto ao longo do seu ciclo de vida.

30/07/2010

O RUP Segue as boas práticas da Engenharia de Software Desenvolvimento de Software Iterativo e
O
RUP
Segue as boas práticas da Engenharia de
Software
Desenvolvimento de Software Iterativo e
Incremental
Gerenciamento de Requisitos
Uso de Arquitetura Baseada em Componentes
Modelagem Visual
Verificação Contínua da Qualidade
Gerenciamento de Mudanças
33
O
RUP
Segue as boas práticas da Engenharia de
Software
Desenvolvimento de Software Iterativo e
Incremental
Gerenciamento de Requisitos
Uso de Arquitetura Baseada em Componentes
Modelagem Visual
Verificação Contínua da Qualidade
Gerenciamento de Mudanças
35

O RUP - Gerenciamento de Requisitos

Oferece uma abordagem sistematizada de controle de requisitos;

Comunicações são baseadas em requisitos definidos;

Requisitos podem ser priorizados, filtrados e localizados;

Permite uma avaliação objetiva das funcionalidade e demais características do sistema;

Incoerências são detectadas mais facilmente.

O RUP - Uso de Arquitetura Baseada em Componentes A arquitetura do sistema compreende o

O RUP - Uso de Arquitetura Baseada em Componentes

A arquitetura do sistema compreende o conjunto de decisões importantes sobre os seguintes elementos:

A organização de um sistema de software;

A seleção dos elementos estruturais e suas interfaces, através

da qual o sistema é composto; Seu comportamento, conforme especificado pelo colaborações entre esses elementos.

A arquitetura de software está preocupada não só com a estrutura e comportamento, mas também com o uso, funcionalidade, desempenho, robustez, reutilização, abrangência, economia, limitações tecnológicas, estéticas, dentre outros.

30/07/2010

O RUP Segue as boas práticas da Engenharia de Software Desenvolvimento de Software Iterativo e
O
RUP
Segue as boas práticas da Engenharia de
Software
Desenvolvimento de Software Iterativo e
Incremental
Gerenciamento de Requisitos
Uso de Arquitetura Baseada em Componentes
Modelagem Visual
Verificação Contínua da Qualidade
Gerenciamento de Mudanças
37
O
RUP
Segue as boas práticas da Engenharia de
Software
Desenvolvimento de Software Iterativo e
Incremental
Gerenciamento de Requisitos
Uso de Arquitetura Baseada em Componentes
Modelagem Visual
Verificação Contínua da Qualidade
Gerenciamento de Mudanças
39

O RUP - Modelagem Visual

Modelos ajudam a entender a realidade;

Melhora a comunicação entre os stakeholders;

Permite destacar detalhes importantes;

Auxilia na obtenção de uma visão geral do sistema;

Documenta decisões tomadas;

Auxilia na entrada de novos integrantes no projeto.

O RUP - Verificação Contínua da Qualidade A avaliação do estado do projeto é feita

O RUP - Verificação Contínua da Qualidade

A avaliação do estado do projeto é feita de forma objetiva, não subjetiva (resultados dos testes);

Esta avaliação objetiva expõe as inconsistências nos requisitos, projetos e implementações;

Testes e verificação estão focados nas áreas de maior risco, aumentando assim a qualidade e a eficácia das áreas;

Defeitos são identificados mais cedo, reduzindo radicalmente o custo de corrigi-los.

30/07/2010

O RUP

Segue as boas práticas da Engenharia de Software

Desenvolvimento de Software Iterativo e Incremental Gerenciamento de Requisitos Uso de Arquitetura Baseada em Componentes Modelagem Visual Verificação Contínua da Qualidade Gerenciamento de Mudanças

Baseada em Componentes Modelagem Visual Verificação Contínua da Qualidade Gerenciamento de Mudanças 41

41

O RUP

O RUP

O RUP - Controle de Mudanças

O fluxo de trabalho de mudanças de requisitos é definido e repetível;

As solicitações de mudança facilitam a comunicação;

Estatísticas de taxas de mudança fornecem medidas objetivas para avaliar o andamento do projeto;

A propagação da mudança é avaliável e controlada.

O RUP

Características

Dividido em Fases/Disciplinas Envolve Atividades, Artefatos e Responsáveis Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos

44

30/07/2010

O RUP Características Dividido em Fases/Disciplinas Envolve Atividades, Artefatos e Responsáveis Iterativo e
O RUP
Características
Dividido em Fases/Disciplinas
Envolve Atividades, Artefatos e Responsáveis
Iterativo e Incremental
Dirigido por Casos de Uso
Centrado na Arquitetura
Tratamento de Riscos
45
O RUP – Dividido em Fases
Concepção
Objetivos da Fase de Concepção
Definir o escopo do software
Visão do Projeto
O que faz parte e o que não faz parte do produto
Definir os critérios de aceitação do produto final
Descobrir os casos de uso críticos
Estimar por alto o custo e o cronograma de todo
o projeto
Estimar em detalhes os custos e cronograma da fase
seguinte (Elaboração)
47
O RUP – Dividido em Fases Características Dividido em Fases Concepção Elaboração Construção Transição
O RUP – Dividido em Fases
Características
Dividido em Fases
Concepção
Elaboração
Construção
Transição
tempo
Marco da fase: escopo definido!
Concepção (define o escopo do projeto)
Elaboração (define os requisitos e a arquitetura)
Construção (desenvolve o sistema)
Transição (implanta o sistema)
46
O RUP – Dividido em Fases
Concepção
Objetivos da Fase de Concepção
Levantar os potenciais riscos
Preparar o ambiente de suporte do projeto
Definir e preparar os processos e ferramentas a serem utilizados
Definir e, eventualmente, demonstrar com protótipos ao
menos um candidato à arquitetura
Avaliar alternativas de projeto
Que componentes fazer, comprar ou reusar?
48

30/07/2010

Concepção
Concepção

O RUP – Dividido em Fases

Características

Dividido em Fases

Concepção Elaboração Construção Transição
Concepção
Elaboração
Construção
Transição

tempo

Marco da fase: arquitetura definida!

Concepção (define o escopo do projeto)

Elaboração (define os requisitos e a arquitetura)

Construção (desenvolve o sistema) Transição (implanta o sistema)

(define os requisitos e a arquitetura) Construção (desenvolve o sistema) Transição (implanta o sistema) 51

51

O RUP – Dividido em Fases

Concepção

Esforço para algumas disciplinas
Esforço para algumas disciplinas

50

O RUP – Dividido em Fases

Elaboração

Objetivos da Fase de Elaboração

Capturar a maioria dos requisitos Construir a arquitetura do sistema

Que demonstre a capacidade de esta arquitetura acomodar o resto do sistema

Produzir protótipos evolucionários ou descartáveis que eliminam riscos de

Requisitos ou projeto Reusabilidade de componentes Viabilidade técnica

52

30/07/2010

Elaboração
Elaboração

O RUP – Dividido em Fases

Características

Dividido em Fases

Concepção Elaboração Construção Transição
Concepção
Elaboração
Construção
Transição

tempo

Marco da fase: funcionalidades 100% implementadas!

Concepção (define o escopo do projeto)

Concepção (define o escopo do projeto)

Elaboração (define os requisitos e a arquitetura) Construção (desenvolve o sistema)

Transição (implanta o sistema)

55

O RUP – Dividido em Fases

Elaboração

Esforço para algumas disciplinas
Esforço para algumas disciplinas

54

O RUP – Dividido em Fases

Construção

Objetivos da Fase de Construção

Produzir a versão para testes

Ênfase na produção de software operacional

Envolve análise, projeto e implementação dos requisitos

Pelo

menos

80%

dos

casos

de

uso

foram

levantados

(identificados) e entendidos Destes, apenas 10-15% são arquiteturalmente relevantes e foram especificados (detalhados), analisados, projetados e implementados

A

Construção

finaliza

o

sistema,

atingindo

100%

das

funcionalidades implementadas

56

30/07/2010

Construção
Construção

O RUP – Dividido em Fases

Características

Dividido em Fases

Concepção Elaboração Construção Transição
Concepção
Elaboração
Construção
Transição

tempo

Marco da fase: sistema implantado!

Concepção (define o escopo do projeto)

Concepção (define o escopo do projeto)

Elaboração (define os requisitos e a arquitetura)

Construção (desenvolve o sistema) Transição (implanta o sistema)

59

O RUP – Dividido em Fases

Construção

Esforço para algumas disciplinas
Esforço para algumas disciplinas

58

O RUP – Dividido em Fases

Transição

Objetivos da Fase de Transição

Validar o sistema em relação às expectativas dos usuários Testes e operacionalização do software (geralmente, em paralelo com o sistema legado) Conversão de dados Treinamento de usuários Correção de erros, pequenas melhorias, pequenos ajustes

60

30/07/2010

Transição

Transição

O RUP – Dividido em Fases

O RUP – Dividido em Fases 63

63

O RUP – Dividido em Fases

Transição

Esforço para algumas disciplinas
Esforço para algumas disciplinas

62

2. Identifique e explique o relacionamento entre As Fases do RUP

2. Identifique e explique o relacionamento entre

As Fases do RUP

30/07/2010

O RUP – Dividido em Disciplinas

Modelagem do Negócio Requisitos Análise e Projeto Implementação Testes Implantação Gerência de Configuração Planejamento e Gerenciamento Ambiente

Modelagem de Negócio

Modelagem de Negócio

Modelagem de Negócio

Modelo de negócio: a representação de um conjunto de atividades – tanto internas (como planejamento)
Modelo de negócio: a representação de um
conjunto de atividades – tanto internas (como
planejamento) quanto externas (como
tomada de ação) – que são executadas para
transformar entradas em saídas, produzindo
trabalho (produto/serviço) nas organizações.

Modelagem de Negócio

Principais objetivos:

Entender o negócio (a estrutura e a dinâmica da organização na qual um sistema deve ser implantado);

Entender os problemas atuais da organização e identificar as possibilidades de melhoria;

Assegurar que os clientes, usuários e desenvolvedores tenham um entendimento comum da organização e dos seus negócio;

Documentar os processos de negócio e capturar a relação entre os seus conceitos;

Derivar os requisitos de sistema necessários para sustentar a organização.

68

30/07/2010

Modelagem de Negócio
Modelagem de Negócio
Modelagem de Negócio

Modelagem

de Negócio

Requisitos

Requisitos
Requisitos Requisitos: são características funcionais (declarações de serviços que o sistema deve fornecer) e
Requisitos
Requisitos:
são
características
funcionais
(declarações de serviços que o sistema deve
fornecer) e não funcionais (restrições sobre
os serviços) que o sistema precisa
apresentar.

Requisitos

Principais objetivos:

Definir as características do sistema conforme observadas pelo cliente;

Estabelecer e manter concordância com os clientes e outras partes interessadas sobre o que o sistema deve fazer;

Produzir e gerenciar os requisitos do projeto;

Oferecer ao desenvolvedor um melhor entendimento dos requisitos

do

sistema;

Definir os limites do sistema (Delimitar o escopo);

Definir uma interface do sistema com o usuário, focando nas necessidades e objetivos dos usuários;

Fornecer uma base para planejar o conteúdo técnico das iterações

e

estimar o custo e o tempo para desenvolver o sistema;

Identificar as inconsistências entre os requisitos e os planos de projeto e produtos de trabalho.

72

30/07/2010

Requisitos
Requisitos
Requisitos

Requisitos

Análise e Projeto

Olho
Olho

Análise e o Projeto

Análise: foca nos requisitos funcionais do sistema, criando modelos conceituais, baseados em conceitos de negócio.
Análise: foca nos requisitos funcionais do
sistema, criando modelos conceituais,
baseados em conceitos de negócio.
Projeto: foca nos requisitos técnicos do
sistema, criando visões detalhadas,
baseadas na tecnologia que será utilizada.

Análise e Projeto

Principais objetivos:

Transformar os requisitos em modelos (abstrato - Análise e concreto - Projeto) do que o sistema vai ser;

Construir uma arquitetura robusta para o sistema;

Adaptar o projeto às limitações do ambiente de execução.

Com o andamento da análise, o sistema vai sendo modelado e esta modelagem amadurece até se transformar no projeto do sistema.

76

30/07/2010

Análise e Projeto
Análise e Projeto
Análise e Projeto

Análise e

Projeto

Implementação

Olho

Implementação Olho

Implementação

Implementação: processo de construção de versões operacionais do sistema ou de parte dele, de modo
Implementação: processo de construção de
versões operacionais do sistema ou de parte
dele, de modo a demonstrar suas
funcionalidades e características em geral.

Implementação

Principais objetivos:

Definir a organização do código fonte em termos de subsistemas e camadas;

Implementar o sistema (codificar) de acordo com os requisitos e o projeto elaborados;

Assegurar a qualidade do código produzido;

Implementar testes unitários para as funcionalidades desenvolvidas;

Implementar testes de requisitos não funcionais para componentes arquiteturais;

Integrar o sistema.

30/07/2010

Implementação
Implementação
Implementação

Implementação

Testes

Olho

Testes Olho
Testes Teste: avaliação da qualidade do produto, através de verificação e correção de problemas e
Testes
Teste: avaliação da qualidade do produto,
através
de
verificação
e
correção
de
problemas
e
de
interpretação
dos
requisitos.

Testes

Principais objetivos:

Verificar se todos os requisitos do sistema foram corretamente implementados;

Validar se o sistema foi construído como projetado;

Validar se os requisitos foram implementados apropriadamente;

Identificar e documentar falhas (defeitos e problemas) no software;

Assegurar a satisfação do cliente com o produto desenvolvido;

Reduzir custos de manutenção corretiva e retrabalho.

30/07/2010

Testes
Testes
Testes

Testes

Implantação

Implantação

Implantação

Implantação

Implantação: corresponde às atividades de planejamento, preparação e instalação de produtos de software no
Implantação: corresponde às atividades de
planejamento, preparação e instalação de
produtos de software no ambiente de
produção.

Implantação

Principais objetivos:

Descrever as atividades de planejamento, preparação e instalação e testes de produtos de software nos ambientes de desenvolvimento, homologação e produção;

Migrar dados legados para o novo sistema;

Treinar usuários e equipe de suporte/vendas.

30/07/2010

Implantação
Implantação
Implantação

Implantação

Gerência de Configuração

Gerência de Configuração

Gerência de Configuração

Gerência de Configuração: registra e mantém uma trilha das mudanças e da evolução dos artefatos
Gerência
de
Configuração:
registra
e
mantém uma trilha das mudanças e da
evolução dos artefatos produzidos pelo
projeto, que podem sofrer mudanças
decorrentes de correções de falhas, melhoria
de qualidade e inclusão de novos requisitos.

Gerência de Configuração

Objetivos

Coordenar os aspectos relacionados à gerência de configuração e mudanças;

Gerência de configuração:

 

Controla os artefatos produzidos no desenvolvimento do projeto;

Evita a ocorrência dos seguintes problemas: Atualizações simultâneas; Múltiplas versões;

Mantém a integridade e rastreabilidade da configuração através do ciclo de vida do sistema.

Gerência de mudanças:

Lida com a captação e gestão de mudanças solicitadas por stakeholders internos e externos;

Trata da análise do impacto potencial da mudança e com a acompanhamento do que acontece com a mudança até que ela seja concluída.

30/07/2010

Gerência de configuração
Gerência de configuração
Gerência de configuração

Gerência de

configuração

Planejamento e Gerenciamento

Planejamento e Gerenciamento

Planejamento e Gerenciamento

Planejamento e Gerenciamento: aplicação de conhecimentos, habilidades e técnicas na elaboração de atividades
Planejamento e Gerenciamento: aplicação de
conhecimentos, habilidades e técnicas na
elaboração de atividades relacionadas para
atingir um conjunto de objetivos pré-
definidos, num certo prazo, com um certo
custo e qualidade, através da mobilização de
recursos técnicos e humanos.

Planejamento e Gerenciamento

Objetivos

Fornecer framework para gerenciamento do projeto; Auxiliar as atividades de planejamento, execução, acompanhamento e monitoramento do projeto;

Auxiliar a criação de uma estrutura para gerenciar risco.

30/07/2010

Planejamento e Gerenciamento
Planejamento e Gerenciamento

Planejamento e

Gerenciamento

Planejamento e Gerenciamento

Ambiente

Ambiente

Ambiente

Ambiente: define os processos, modelos de artefatos, guias (de atividades e artefatos) e ferramentas para
Ambiente: define os processos, modelos de
artefatos, guias (de atividades e artefatos) e
ferramentas para a empresa que está
desenvolvendo o sistema.

Ambiente

Objetivos

Criar e evoluir processos do projeto (atividades, artefatos e papéis);

Selecionar,

adquirir,

instalar

e

configurar

ferramentas;

Manutenção

da

infra-estrutura,

processos

de

backup e outras rotinas pertinentes.

30/07/2010

Ambiente
Ambiente
Ambiente

Ambiente

O RUP

Características

Dividido em Fases/Disciplinas Envolve Atividades, Artefatos e Responsáveis Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos

Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos 103

103

3. Identifique e explique o relacionamento entre As Disciplinas do RUP

3. Identifique e explique o relacionamento entre

As Disciplinas do RUP

O RUP – Envolve Atividades, Artefatos e Responsáveis Características Conjunto de atividades Bem definidas Com

O RUP – Envolve Atividades, Artefatos e Responsáveis

Características

Conjunto de atividades

Bem definidas Com responsáveis Com artefatos de entrada e saída Com dependências entre as mesmas e ordem de execução Com descrição sistemática de como devem ser realizadas

30/07/2010

O RUP – Envolve Atividades, Artefatos e Responsáveis Exemplos de atividades e artefatos

O RUP – Envolve Atividades, Artefatos e Responsáveis

Exemplos de atividades e artefatos

Modelagem de Negócio

Alguns exemplos de artefatos:

Lista dos processos de negócio;

Especificação textual/diagrama dos processos de negócio (cenário atual);

Especificação textual/diagrama dos processos de negócio (cenário futuro);

Glossário de negócio.

107

Modelagem de Negócio

Principais atividades:

Conhecer o negócio (cenário atual - nível macro): compreender de forma macro o funcionamento do negócio;

Identificar

processos

de

negócio

(cenário

atual):

identificar

todos

os

processos (importante para planejar as atividades de modelagem);

Especificar processos de negócio (cenário atual): documentar os processos (os participantes do negócio e suas funções; as atividades e os fluxos de trabalho; os sistemas envolvidos nos processos);

Apresentar

os

artefatos

da

modelagem

de

negócio

(cenário

atual):

apresentar e homologar, junto ao cliente/patrocinador, os resultados (artefatos gerados) do trabalho de modelagem de negócio realizado;

Apresentar proposta de melhorias nos processos de negócio (cenário futuro):

apresentar e homologar, junto ao cliente/patrocinador, uma proposta para realizar melhorias/reengenharia nos processos (de forma a apoiar estratégias de inovação ou criar oportunidades de negócio, ou simplesmente otimizar os processos atuais de negócio).

106

Requisitos

Principais atividades:

Desenvolver Plano de Gerência de Requisitos: especificar a forma de documentação dos requisitos, as diretrizes de rastreabilidade e a forma de gerenciamento dos requisitos do projeto;

Realizar estudo de viabilidade: responder se vale a pena ou não prosseguir com o desenvolvimento do sistema (avalia se o sistema contribui para os objetivos gerais da organização, se pode ser implementado com tecnologia atual e dentro das restrições de custo e prazo, se pode ser integrado a outros sistemas já implantados);

Elicitar

requisitos:

coletar

requisitos;

classificar

e

organizar

requisitos;

priorizar

e

negociar

requisitos;

detalhar

requisitos;

documentar requisitos;

 

Validar/revisar

requisitos:

verificar

se

os

requisitos

realmente

definem o sistema que o usuário deseja;

 

Gerenciar requisitos: compreender e controlar as mudanças dos requisitos.

108

30/07/2010

Requisitos

Alguns exemplos de artefatos:

 

Plano de Gerenciamento de Requisitos;

Documento de Definição de Requisitos (DDR);

Diagrama de Casos de Uso;

Especificações de Casos de Uso;

Regras de Negócio;

Regras de Validação;

Matriz de Rastreabilidade;

Glossário de Negócio.

 

109

Análise e Projeto

Alguns exemplos de artefatos:

 

Realização de caso de uso (de Análise);

Documento de arquitetura;

Mapeamento das classes de Análise em elementos de Projeto;

Diagrama de pacotes;

Realização de caso de uso (de Projeto);

Diagrama Entidade Relacionamento;

Mapeamento Objeto-relacional; Script de criação da base de dados.

 

111

Análise e Projeto

Principais atividades:

Definir

modelo

conceitual/arquitetura

candidata:

criar

esboço do modelo conceitual e do esqueleto de pelo

menos uma arquitetura preliminar do sistema (que pode evoluir ou ser descartada ao longo do projeto); organizar

o

sistema em camadas; identificar classes de análise;

Refinar modelo conceitual/arquitetura: fazer a transição da análise para projeto, descrever o sistema relacionado

aspectos de runtime (aspecto dinâmico do sistema) e implantação (aspecto estático do sistema);

a

Projetar banco de dados: projetar o banco de dados para contemplar os quesitos relacionados com a persistência dos objetos persistentes do caso de uso.

110

Implementação

Principais atividades:

Estruturar

o

modelo

de

implementação:

 

definir

a

organização do código fonte (organização em camadas, mecanismos de persistência, comunicação e GUI, por exemplo);

Codificar

componentes/casos

de

uso:

codificar

componentes/casos de uso necessários e realizar testes

unitários;

Integrar sistema: integrar componentes, dando origem a uma nova versão do sistema.

112

30/07/2010

Implementação

Alguns exemplos de artefatos:

 

Implementação dos componentes;

Testes unitários da implementação dos componentes;

Relatórios de testes unitários da implementação dos componentes;

Roteiros/relatórios de testes não-funcionais da implementação dos componentes;

Implementação dos casos de uso;

Testes unitários da implementação dos casos de uso;

Relatórios de testes unitários da implementação dos casos de uso;

Roteiro/relatórios testes não-funcionais da implementação dos casos de uso;

Plano de Integração.

 

113

Testes

 

Alguns exemplos de artefatos:

 

Plano de Teste;

Roteiros de Teste Funcionais;

Relatório de Testes Funcionais;

Relatório de Testes Não Funcionais;

Roteiros de Teste de Aceitação/Homologação;

Relatório de Teste de Aceitação/Homologação;

Roteiros de Teste de Desempenho;

Registros de bugs.

 

115

Testes

Principais atividades:

Planejar testes: planejar as atividades de teste do projeto (tipos de teste, previsão de quando e por quem os testes deverão ser executados);

Especificar, construir e executar testes: especificar e construir os cenários a serem testados de acordo com os requisitos funcionais e não funcionais do sistema e testá-los;

Testes de integração:

testam a integração de todos os componentes previstos

para a iteração/versão; Testes funcionais: encontram bugs na construção do software; Testes não funcionais: verificam a corretude dos requisitos não funcionais do sistema;

Testes de sistema: testam o sistema como um todo;

 

Testes

de

aceitação/homologação:

feitos

pelo

usuário

final,

realizam

a

aceitação do produto entregue;

provenientes das atividades de teste e resolvê-los;

114

Analisar

resultados

e

corrigir

defeitos:

analisar

defeitos

Implantação

Principais atividades:

Planejar implantação: definir as diretrizes usadas para planejar como será realizada a implantação do sistema e garantir que o usuário esteja ciente e comprometido com as atividades de implantação;

Desenvolver material de suporte: desenvolver os artefatos de apoio aos usuários no processo de instalação, aprendizagem, utilização, operação e sustentação do sistema (documentação, manuais, treinamentos, dentre outros);

Testar

sistema

no ambiente

de

desenvolvimento: testar

o

sistema

no

ambiente de desenvolvimento, para verificar se o sistema está pronto para ser implantado;

Gerar release: empacotar o sistema com todos os artefatos necessários para implantação;

Instalar e testar sistema no ambiente de produção: instalar e testar o sistema no ambiente de produção, para que possa ser utilizado pelo cliente;

116

30/07/2010

Implantação

Alguns exemplos de artefatos:

Plano de implantação;

Release;

Artefatos de instalação (script, ferramentas, arquivos, guias);

Documentação;

Material de apoio, como o manual do usuário, manuais de operação e manutenção;

Material de treinamento.

.

117

Gerência de Configuração

Alguns exemplos de artefatos:

Plano de gerenciamento de configuração e mudança;

Solicitações de mudança;

Registros de controle de mudança.

119

Gerência de Configuração

Principais atividades:

Planejar gerência de configuração e mudanças: plano de referência

para o controle sistemático da configuração e das mudanças realizadas no projeto; Configurar ambiente de gerência de configuração e mudanças:

preparar o ambiente (criar procedimentos, instalar ferramentas etc.), para que o processo de gerenciamento de configuração e mudanças possa ser desempenhado;

Criar/alterar e disponibilizar produtos de trabalho: acessar os artefatos do projeto, realizar mudanças e incorporá-las ao produto;

Monitorar gerência de configuração e mudanças: monitorar e reportar as configurações e mudanças no projeto, provendo trilhas de auditoria;

Gerenciar mudanças: processar (avaliar, analisar impacto e aprovar) as solicitações de mudança de modo padronizado; Gerenciar baselines: gerenciar versões dos artefatos que compõem o produto em dado momento.

118

Planejamento e Gerenciamento

Principais atividades:

Planejamento, executar, acompanhar e monitorar o projeto (escopo, tempo, custo, riscos, qualidade, recursos humanos, aquisições, comunicação).

30/07/2010

Planejamento e Gerenciamento

Alguns exemplos de artefatos:

Planos e documentos relacionados à execução, acompanhamento e monitoramento do projeto (escopo, tempo, custo, riscos, qualidade, recursos humanos, aquisições, comunicação).

Ambiente

Exemplo de artefato:

Modelo/processo de desenvolvimento (diretrizes/procedimentos, templates)

123

Ambiente

Principais atividades:

Preparar ambiente para o projeto: definir uma lista de ferramentas que podem ser utilizadas e templates de artefatos que serão necessários; Preparar diretrizes: preparar procedimentos para o desenvolvimento das atividades do projeto; Suportar ambiente: prover suporte para os usuários quanto às dificuldades pertinentes ao ambiente; Realizar atividades de manutenção: execução das rotinas relacionadas à infra-estrutura, como processos de backup e outras rotinas pertinentes

122

4. Identifique Os Artefatos gerados para o estudo de caso apresentado em sala

4. Identifique Os Artefatos gerados para o estudo de caso apresentado em sala

30/07/2010

O RUP – Envolve Atividades, Artefatos e Responsáveis Exemplos de responsáveis/papéis

O RUP – Envolve Atividades, Artefatos e Responsáveis

Exemplos de responsáveis/papéis

Modelagem de Negócio Analista de Negócio Lidera e coordena a modelagem de negócios, delineando e

Modelagem de Negócio

Analista de Negócio Lidera e coordena a modelagem de negócios, delineando e delimitando a organização que está sendo modelada; Por exemplo: estabelece o processo, visão de novos negócios, capta os objetivos de negócio, e determina que os atores de negócios e processos de negócios existem e como eles interagem.

Designer de Negócio Detalha a especificação de uma organização, descrevendo os processos de negócio; Determina os trabalhadores e entidades de negócios necessários para realizar um processo de negócios, e também como eles trabalham juntos para alcançar a realização. Define as responsabilidades, operações, atributos e relacionamentos de um ou vários trabalhadores de negócios e entidades empresariais.

Revisor de Negócio Revisa os artefatos de negócio.

O RUP – Envolve Atividades, Artefatos e Responsáveis Administrador do Sistema Gerente de Configuração Analista
O RUP – Envolve Atividades, Artefatos e
Responsáveis
Administrador do Sistema
Gerente de Configuração
Analista de Negócio
Gerente de Controle de
Mudanças
Analista de Sistemas
Gerente de Implantação
Analista de Teste
Gerente de Projeto
Arquiteto de Software
Gerente de Teste
Artista gráfico
Implementador (codificador)
Desenvolvedor do Curso
Integrador de sistemas
Designer
Redator Técnico
Designer de Banco de Dados
Revisor de Arquitetura
Designer de Interface do
Usuário
Revisor de Design
Designer de Negócio
Revisor de Negócio
Designer de Teste
Revisor de Projetos
Engenheiro de Processo
Revisor de Requisitos
Especialista em Ferramentas
Revisor do Código
Especificador de Requisitos
Testador
Requisitos Analista de Sistemas Lidera e coordena elicitação de requisitos e modelagem de casos de

Requisitos

Analista de Sistemas

Lidera e coordena elicitação de requisitos e modelagem de casos de uso, delimitando o sistema e descrevendo suas funcionalidade;

Especificador de Requisitos

Detalha a totalidade ou parte da funcionalidade do sistema, descrevendo os aspectos dos requisitos de um ou vários casos de uso;

Arquiteto de Software

Envolvido principalmente nas primeiras iterações para, juntamente com o Analista de Sistemas e Especificador de Requisitos, garantir a integridade dos casos de uso significativos para a definição da arquitetura;

Designer de Interface

Modela a interface com o usuário, cria protótipos;

Revisor de Requisitos

Representa todos os tipos de pessoas que podem verificar se os requisitos são percebidos e interpretados corretamente pela equipe de desenvolvimento.

30/07/2010

Análise e Projeto Arquiteto de Software Lidera e coordena as atividades técnicas e artefatos ao

Análise e Projeto

Arquiteto de Software

Lidera e coordena as atividades técnicas e artefatos ao longo do projeto;

Estabelece a estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento de elementos, e as interfaces entre os principais grupos.

Designer

Define as responsabilidades, operações, atributos e relacionamentos de uma ou várias

classes e determina como devem ser ajustadas ao ambiente de implementação. Além disso, o designer pode ter responsabilidade por um ou mais pacotes de design ou subsistemas de design, incluindo as classes pertencentes aos pacotes ou subsistemas.

Designer de Banco de Dados

Responsável pelo banco de dados.

Revisor de Arquitetura

Especialista que analisa os artefatos de arquitetura.

Revisor de Design

Especialista que analisa os artefatos de projeto.

Testes

Gerente de Teste

Tem a responsabilidade global para o sucesso do esforço de teste;

Responsável pelo planejamento e gestão de recursos e resolução de problemas que impedem o esforço de teste;

Analista de Teste

Responsável por identificar e definir os testes necessários;

Monitora o progresso dos testes e resultados em cada ciclo de teste;

Avaliar a qualidade global a partir dos resultado das atividades de testes. Carrega a responsabilidade de representar adequadamente as necessidades das partes interessadas que não tenham direta ou regular representação sobre o projeto.

Designer de Teste

Responsável por definir a abordagem de teste e garantir a sua execução bem sucedida.

Identifica as técnicas apropriadas, ferramentas e diretrizes para implementar os testes necessários e orienta sobre os recursos exigidos para o esforço de teste.

Testador

Cria e executa os testes, avaliação sua execução,recupera os erros de avaliação dos resultados dos testes e registra pedidos de mudança.

Implementação Implementador (codificador) Desenvolve código e executa testes de unidade; Integrador de

Implementação

Implementador (codificador)

Desenvolve código e executa testes de unidade;

Integrador de sistemas

Integra o código, construindo as versões do sistema;

Arquiteto de software

Define a estrutura do modelo de implementação (camadas e subsistemas);

Revisor do código

Inspeciona o código para a qualidade e conformidade com o projeto padrão.

Implantação Gerente de Implantação Planeja e organiza a implantação. Responsável pelos testes e feedback, e

Implantação

Gerente de Implantação Planeja e organiza a implantação. Responsável pelos testes e feedback, e por

Gerente de Implantação Planeja e organiza a implantação. Responsável pelos testes e feedback, e por garantir que o produto está pronto para distribuição.

Gerente de Projeto Principal interface com o cliente, sendo responsável pela aprovação de implantação com base no feedback dos testes e avaliação de resultados; Responsável ainda pela aceitação da entrega por parte do cliente;

no feedback dos testes e avaliação de resultados; Responsável ainda pela aceitação da entrega por parte

Testador Executa os testes de aceitação e é responsável por garantir que o produto foi testado de forma adequada;

Implementador Cria scripts de instalação e artefatos relacionados que irão ajudar o usuário a instalar o produto final.

Redator Técnico Desenvolve materiais de suporte;

Desenvolvedor do Curso Produz material de treinamento;

Artista gráfico Responsável por criar a arte-final do produto.

30/07/2010

Gerência de Configuração Gerente de Configuração Responsável pelas atividades de gerência de configuração

Gerência de Configuração

Gerente de Configuração

Responsável pelas atividades de gerência de configuração (planejamento, configuração de ambiente e ferramentas, criação da estrutura de produtos no sistema, auditorias, dentre outras).

Gerente de Controle de Mudanças

Responsável pelas definição do processo de controle de mudanças e pela execução

das atividades de supervisão do controle de mudanças; Um momento de configuração de mudanças deverá ser composto por representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usuários;

Integrador

Aceita mudanças na integração e constrói o produto (gera baseline/release).

Qualquer função

Pode enviar uma solicitação de mudança.

As execuções das mudanças serão feitas de acordo com a natureza da mudança.

Ambiente

Engenheiro de processo Responsável pela adequação do processo ao projeto;

Analista de Negócio Desenvolve as orientações para a modelagem de negócios;

Analista de Sistemas Desenvolve orientações para modelagem de caso de uso;

Designer de Interface do Usuário Desenvolve orientações para a criação de interface de usuário.

Designer de Testes Desenvolve orientações para a criação de testes.

Arquiteto de software Desenvolve as diretrizes de design e orientações de programação.

Redator técnico Desenvolve guia de estilo para o manual do usuário.

Especialista em Ferramentas Seleciona e adquire ferramentas de apoio ao desenvolvimento. elacionadas.

Administrador do Sistema Mantém o ambiente de desenvolvimento de hardware e software do sistema; Excuta tarefas administrativas, como administração de contas, backups, e assim por diante.

Planejamento e Gerenciamento Gerente de Projetos Responsável pela geração dos manutenção dos artefatos de

Planejamento e Gerenciamento

Gerente de Projetos Responsável pela geração dos manutenção dos artefatos de Gerência de Projetos.

Revisor de Projetos Responsável pela revisão dos artefatos de Gerência de Projetos.

5. Identifique Os Papéis e Recursos utilizados para desenvolver o estudo de caso apresentado em

5. Identifique

Os Papéis e Recursos

utilizados para desenvolver o estudo de caso apresentado em sala

30/07/2010

O RUP

Características

Dividido em Fases/Disciplinas Envolve Atividades, Artefatos e Responsáveis Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos

Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos 137

137

O RUP – Iterativo e Incremental

Características

Iterativo e incremental

Ciclo de Vida Iterativo

Divide o projeto em partes menores

Mais fáceis de planejar

Mais fáceis de gerenciar Mais fácil de medir o progresso Aplicação do “modelo cascata” em várias iterações

As iterações iniciais atacam os riscos mais críticos

Todos começam a trabalhar mais cedo

Testes e integração são realizados desde o início

Riscos mais críticos são resolvidos mais cedo Maior feedback dos usuários

Geralmente resulta em uma versão executável do sistema

O RUP - Iterativo e Incremental

Cada fase é dividida em iterações:

Inception Elaboration Construction Transition Preliminary Architect. Architect. Devel Devel Devel Transition
Inception
Elaboration
Construction
Transition
Preliminary
Architect.
Architect.
Devel
Devel
Devel
Transition
Transition
iteration
iteration
iteration
iteration
iteration
iteration
iteration
iteration

Marcos: Releases

O RUP - Iterativo e Incremental

Iterações

Projetos simples

normalmente têm uma iteração por fase.

Projetos mais complexos

no seu primeiro ciclo de desenvolvimento normalmente apresentam:

1 iteração na Iniciação

2 iterações na Elaboração

2 iterações na Construção 1 iteração na Transição

Projetos grandes

em domínios desconhecidos, envolvendo novas tecnologias e muitos riscos:

2 iterações na Iniciação

3 iterações na Elaboração

3 iterações na Construção 2 iterações na Transição

30/07/2010

O RUP - Iterativo e Incremental

Exemplo

30/07/2010 O RUP - Iterativo e Incremental Exemplo 36
30/07/2010 O RUP - Iterativo e Incremental Exemplo 36
30/07/2010 O RUP - Iterativo e Incremental Exemplo 36

30/07/2010

Iterações
Iterações
Iterações

Iterações

O RUP - Dirigido por Casos de Uso Implementação Análise e Testes Requisitos Projeto Implantação
O RUP - Dirigido por Casos de Uso
Implementação
Análise e
Testes
Requisitos
Projeto
Implantação
Os casos
de uso conectam esses fluxos

O RUP

Características

Dividido em Fases/Disciplinas Envolve Atividades, Artefatos e Responsáveis Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos

Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos 146

146

O RUP - Dirigido por Casos de Uso

Características

Casos de Uso

Representam as funcionalidades do sistema

Ajudam na comunicação com os clientes

Mostram apenas o que o sistema faz, e não como

Servem como base para

Definir os requisitos do sistema Definição/planejamento das iterações Criação da arquitetura Definição dos casos de teste Documentação do usuário

30/07/2010

O RUP - Dirigido por Casos de Uso

Priorizar os casos de uso que impliquem em mais riscos ao projeto

Os casos de uso que implicam em riscos ao projeto devem ser atacados o quanto antes, preferencialmente nas primeiras iterações.

Priorizar os casos de uso que sejam relevantes para a Arquitetura do software

A definição de uma arquitetura robusta e capaz de acomodar todos os requisitos do sistema é primordial para o sucesso do projeto.

Priorizar os casos de uso mais urgentes para o cliente.

O RUP – Centrado na Arquitetura

Planejar/DefinirO RUP – Centrado na Arquitetura Representar/Projetar Construir/Desenvolver Inspecionar/Validar

Representar/ProjetarO RUP – Centrado na Arquitetura Planejar/Definir Construir/Desenvolver Inspecionar/Validar

Construir/DesenvolverO RUP – Centrado na Arquitetura Planejar/Definir Representar/Projetar Inspecionar/Validar

Inspecionar/ValidarO RUP – Centrado na Arquitetura Planejar/Definir Representar/Projetar Construir/Desenvolver

O RUP – Centrado na Arquitetura Planejar/Definir Representar/Projetar Construir/Desenvolver Inspecionar/Validar

O RUP

Características

Dividido em Fases/Disciplinas Envolve Atividades, Artefatos e Responsáveis Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos

Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos 150

150

O RUP – Centrado na Arquitetura

Características

Arquitetura de Software

A definição da arquitetura é imprescindível para o sucesso do

projeto Apresenta a visão geral do sistema em termos dos seus

subsistemas e como estes se relacionam Trata os requisitos não-funcionais (atributos de qualidade:

segurança, performance Identifica e mapeia:

)

e requisitos funcionais críticos

Componentes

Propriedades destes componentes

Relacionamentos entre os componentes

30/07/2010

O RUP

Características

Dividido em Fases/Disciplinas Envolve Atividades, Artefatos e Responsáveis Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos

Iterativo e Incremental Dirigido por Casos de Uso Centrado na Arquitetura Tratamento de Riscos 153

153

O RUP – Resumo

Fases

Iterações

Disciplinas

Atividades

Passos

entradas e saídas

guias (de ferramentas ou não), templates

Responsáveis (papel e perfil, não pessoa) Artefatos

O RUP – Tratamento de Riscos

Características Riscos são incertezas que podem conduzir a falhas em um projeto

Pessoas não são peças mecânicas intercambiáveis

Existem aspectos desconhecidos relativos ao software

Riscos diretos e indiretos

Diretos: o projeto tem maior controle sobre ele Indiretos: o projeto não tem controle sobre ele

A abordagem iterativa permite atenuar os riscos mais cedo

Atributos

Probabilidade

Severidade

Tratamento de riscos

Identificação

Quantificação

Desenvolvimento de Respostas Evitar Transferir Aceitar (Mitigar/ Contingenciar - plano B)

6. Elabore um esboço do relacionamento entre as Iterações, Casos de Uso, Arquitetura e Riscos

6. Elabore um esboço do relacionamento entre as

Iterações, Casos de Uso, Arquitetura e Riscos

para o estudo de caso apresentado em sala

30/07/2010

7. Trace um comparativo entre O RUP e Os Processos Ágeis

7. Trace um comparativo entre O RUP e

Os Processos Ágeis

Referências

Martins, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. Brasport, 3ª edição, 2006.

Pressman, R. S. Engenharia de Software, Mc-Graw-Hill, 6ª edição, 2006.

Sommerville, I. Engenharia de Software. Addison-Wesley, 8ª edição, 2007.

Scott, K. O Processo Unificado Explicado. Boookman, 2003.

Kruchten, P. Introdução ao RUP: Rational Unified Process. Ciência Moderna, 2003.

Stair, R. M.; Reynolds, G. W. Princípios de Sistemas de Informação. Thompson Learning, 6ª edição, 2006.

Laudon, K. C.; Laudon, J. P. Sistemas de Informação Gerenciais. Prentice-Hall, 5ª edição,

2004.

O’Brien, J. A. Sistemas de Informação e as Decisões Gerenciais na Era da Internet. Saraiva, 2ª edição, 2004.