970877
Description
Mind Map by Jamil Yahuza Felippe, updated more than 1 year ago
|
Created by Jamil Yahuza Felippe
over 10 years ago
|
|
12. Eng de Software:Modelo Processo Unificado
- O processo unificado (PU)
(ou unified process — UP)
surgiu como um processo
para o desenvolvimento de
software visando à
construção de sistemas
orientados a objetos (o
RUP — Rational Unified
Process — é um
refinamento do processo
unificado).
- O PU utiliza uma abordagem
evolucionária paro o desenvolvimento de
software. O ciclo de vida iterativo é
baseado em refinamentos e incrementos
sucessivos, a fim de convergir para um
sistema adequado. Em cada iteração,
procura-se incrementar um pouco mais o
produto, baseando-se na experiência
obtida nas iterações anteriores e no
feedback do usuário. Cada iteração
pode ser considerada um miniprojeto de
duração fixa, sendo que cada um desses
inclui suas próprias atividades de análise
de requisitos, projeto, implementação e
testes.
- O PU foi modelado usando o Software
Process Engineering Model (SPEM),
que é um padrão para modelagem de
processos baseado em Unified
Modeling Language (UML). O processo
tem duas estruturas, ou duas
dimensões, a saber:
- Estrutura dinâmica:
representa a
dimensão do tempo
no processo.
- A estrutura que
representa o
tempo é
denominada:
Fase
- Fases
- Uma fase é definida como a
dimensão de tempo entre
duas maiores marcas (major
milestones) de processos,
durante a qual um conjunto
bem definido de objetivos é
encontrado
- As maiores marcas, por sua
vez, podem ser definidas
como eventos de grandes
sistemas organizados no
final de cada fase de
desenvolvimento para
fornecer visibilidade aos
seus problemas, sincronizar
o gerenciamento com as
perspectivas de engenharia e
verificar se os objetivos de
cada fase foram obtidos.
- As maiores marcas, por sua
vez, podem ser definidas
como eventos de grandes
sistemas organizados no
final de cada fase de
desenvolvimento para
fornecer visibilidade aos
seus problemas, sincronizar
o gerenciamento com as
perspectivas de engenharia e
verificar se os objetivos de
cada fase foram obtidos.
- Uma fase é definida como a
dimensão de tempo entre
duas maiores marcas (major
milestones) de processos,
durante a qual um conjunto
bem definido de objetivos é
encontrado
- Fases
- A estrutura que
representa o
tempo é
denominada:
Fase
- Estrutura estática:
descreve como
elementos do
processo são
agrupados em
disciplinas.
- A estrutura que
representa os
elementos do
processo são as:
Disciplinas
- É uma coleção de atividades
relacionadas que estão
ligadas à maior área de
interesse dentro do processo
em geral. Cada disciplina
possui, resumidamente, os
seguintes objetivos
específicos:
- Modelagem de negócios:
- Entender a estrutura e a dinâmica da organização para a
qual o produto será desenvolvido; Identificar problemas
correntes na organização e possíveis aperfeiçoamentos;
Assegurar que o cliente, o usuário final e os
desenvolvedores possuam a mesma compreensão da
empresa; Produzir os requisitos de sistemas necessários
para suportar os objetivos da organização.
- Entender a estrutura e a dinâmica da organização para a
qual o produto será desenvolvido; Identificar problemas
correntes na organização e possíveis aperfeiçoamentos;
Assegurar que o cliente, o usuário final e os
desenvolvedores possuam a mesma compreensão da
empresa; Produzir os requisitos de sistemas necessários
para suportar os objetivos da organização.
- Requisitos:
- estabelecer e manter o consentimento entre clientes e
stakeholders sobre o que o sistema deve fazer; fornecer uma
melhor compreensão dos requisitos aos desenvolvedores;
definir os limites do sistema; fornecer as bases para o
planejamento das iterações, estimativas de custo e tempo de
desenvolvimento; definir as interfaces do sistema baseado nas
necessidades e objetivos dos usuários.
- estabelecer e manter o consentimento entre clientes e
stakeholders sobre o que o sistema deve fazer; fornecer uma
melhor compreensão dos requisitos aos desenvolvedores;
definir os limites do sistema; fornecer as bases para o
planejamento das iterações, estimativas de custo e tempo de
desenvolvimento; definir as interfaces do sistema baseado nas
necessidades e objetivos dos usuários.
- Análise e design:
- Transformar os requisitos dentro de um projeto do que será o
sistema; Desenvolver uma arquitetura robusta para o sistema;
Adaptar o projeto para ajustá-lo ao ambiente de implementação.
- Transformar os requisitos dentro de um projeto do que será o
sistema; Desenvolver uma arquitetura robusta para o sistema;
Adaptar o projeto para ajustá-lo ao ambiente de implementação.
- Implementação:
- Preparar a organização do código em termos de implementação de subsistemas,
organizados em camadas; Implementar classes e objetos em termos de seus
componentes; Testar os componentes desenvolvidos como unidades; Integrar os resultados
obtidos por implementadores individuais (ou equipes) em um sistema executável.
- Preparar a organização do código em termos de implementação de subsistemas,
organizados em camadas; Implementar classes e objetos em termos de seus
componentes; Testar os componentes desenvolvidos como unidades; Integrar os resultados
obtidos por implementadores individuais (ou equipes) em um sistema executável.
- Teste:
- Verificar a interação entre os objetos; Verificar a integração de todos os componentes de software;
Verificar se todos os requisitos foram implementados corretamente; Verificar os defeitos e assegurar que
eles foram tratados antes da entrega do produto.
- Verificar a interação entre os objetos; Verificar a integração de todos os componentes de software;
Verificar se todos os requisitos foram implementados corretamente; Verificar os defeitos e assegurar que
eles foram tratados antes da entrega do produto.
- Implantação:
- Descrever as atividades associadas à verificação para que o
produto esteja disponível ao usuário final.
- Descrever as atividades associadas à verificação para que o
produto esteja disponível ao usuário final.
- Gerenciamento de configuração e mudança:
- Identificar itens de configuração; Restringir alterações para aqueles itens; Auditar
as alterações neles feitas; Definir e gerenciar as alterações daqueles itens.
- Identificar itens de configuração; Restringir alterações para aqueles itens; Auditar
as alterações neles feitas; Definir e gerenciar as alterações daqueles itens.
- Gerenciamento de projeto:
- Fornecer uma estrutura para o gerenciamento de projeto de software; Fornecer
um guia prático para planejamento, recrutamento, execução e monitoramento
de projeto; Fornecer uma estrutura para o gerenciamento de riscos.
- Fornecer uma estrutura para o gerenciamento de projeto de software; Fornecer
um guia prático para planejamento, recrutamento, execução e monitoramento
de projeto; Fornecer uma estrutura para o gerenciamento de riscos.
- Ambiente:
- Identificar as atividades necessárias para configurar o processo para o projeto;
descrever as atividades requeridas para desenvolver as guias mestras no suporte ao
projeto; Fornecer para a organização de desenvolvimento de software o ambiente
de processos e ferramentas que suportarão a equipe de desenvolvimento.
- Identificar as atividades necessárias para configurar o processo para o projeto;
descrever as atividades requeridas para desenvolver as guias mestras no suporte ao
projeto; Fornecer para a organização de desenvolvimento de software o ambiente
de processos e ferramentas que suportarão a equipe de desenvolvimento.
- Modelagem de negócios:
- É uma coleção de atividades
relacionadas que estão
ligadas à maior área de
interesse dentro do processo
em geral. Cada disciplina
possui, resumidamente, os
seguintes objetivos
específicos:
- A estrutura que
representa os
elementos do
processo são as:
Disciplinas
- Estrutura dinâmica:
representa a
dimensão do tempo
no processo.
- O processo unificado
organiza suas
iterações em quatro
fases principais:
- Concepção
ou
iniciação:
- O objetivo desta fase é
levantar, de forma genérica e
pouco precisa, o escopo do
projeto. Não deve existir aqui
a pretensão de especificar de
forma detalhada os
requisitos; a ideia é ter uma
visão inicial do problema,
estimar de forma vaga o
esforço e os prazos e
determinar se o projeto é
viável e merece uma análise
mais profunda.
- O objetivo desta fase é
levantar, de forma genérica e
pouco precisa, o escopo do
projeto. Não deve existir aqui
a pretensão de especificar de
forma detalhada os
requisitos; a ideia é ter uma
visão inicial do problema,
estimar de forma vaga o
esforço e os prazos e
determinar se o projeto é
viável e merece uma análise
mais profunda.
- Elaboração:
- Na fase de elaboração todos
(ou a grande maioria dos
requisitos) são levantados em
detalhes. Numa primeira
iteração, um ou dois requisitos
(os de maior risco e valor
arquitetural) são especificados
em detalhes.
- Estes servem como
base de avaliação
junto ao usuário e
desenvolvedores para
o planejamento da
próxima iteração.
- Ao fim dessa fase, deseja-se que
90% dos requisitos tenham sido
levantados em detalhes, que o
núcleo do sistema tenha sido
implementado com alta
qualidade, que os principais
riscos tenham sido tratados e que
haja condições para se fazer
estimativas mais realistas.
- Ao fim dessa fase, deseja-se que
90% dos requisitos tenham sido
levantados em detalhes, que o
núcleo do sistema tenha sido
implementado com alta
qualidade, que os principais
riscos tenham sido tratados e que
haja condições para se fazer
estimativas mais realistas.
- Estes servem como
base de avaliação
junto ao usuário e
desenvolvedores para
o planejamento da
próxima iteração.
- Na fase de elaboração todos
(ou a grande maioria dos
requisitos) são levantados em
detalhes. Numa primeira
iteração, um ou dois requisitos
(os de maior risco e valor
arquitetural) são especificados
em detalhes.
- Construção:
- Visa à implementação iterativa
dos elementos restantes de
menor risco e mais fáceis,
além da preparação para a
implantação.
- Visa à implementação iterativa
dos elementos restantes de
menor risco e mais fáceis,
além da preparação para a
implantação.
- Transição:
- Testes finais e implantação.
- Testes finais e implantação.
- Concepção
ou
iniciação:
- O PU foi modelado usando o Software
Process Engineering Model (SPEM),
que é um padrão para modelagem de
processos baseado em Unified
Modeling Language (UML). O processo
tem duas estruturas, ou duas
dimensões, a saber:
- O PU utiliza uma abordagem
evolucionária paro o desenvolvimento de
software. O ciclo de vida iterativo é
baseado em refinamentos e incrementos
sucessivos, a fim de convergir para um
sistema adequado. Em cada iteração,
procura-se incrementar um pouco mais o
produto, baseando-se na experiência
obtida nas iterações anteriores e no
feedback do usuário. Cada iteração
pode ser considerada um miniprojeto de
duração fixa, sendo que cada um desses
inclui suas próprias atividades de análise
de requisitos, projeto, implementação e
testes.
- De uma maneira geral, podemos caracterizar
o processo unificado da seguinte forma:
- É um framework genérico de
um processo de
desenvolvimento;
- É baseado em
componentes;
- Utiliza toda a
definição da UML;
- É dirigido pelos use cases, centrado
na arquitetura, iterativo e incremental
(conceitos-chave).
- É um framework genérico de
um processo de
desenvolvimento;
- O processo unificado foi criado para ser um processo ágil de
desenvolvimento e propõe uma abordagem realística para a
condução de um projeto. Ao contrário do modelo em cascata, em
que cada etapa do ciclo de vida deve ser realizada integral e
sequencialmente, no PU as atividades são repetidas quantas vezes
forem preciso, em ciclos organizados. Não há um plano detalhado
para todo um projeto. Há um plano de alto nível (chamado plano de
fases) que estima a data de término do projeto e outros marcos de
referência principais, mas ele não detalha os passos de
granularidade fina para se atingir tais marcos. Um plano detalhado
(chamado plano de iterações) somente planeja a iteração a ser feita
em seguida. O planejamento detalhado é feito de forma adaptativa,
de iteração para iteração.
Want to create your own Mind Maps for free with GoConqr? Learn more.