12. Eng de Software:Modelo Processo Unificado

Jamil Yahuza Felippe
Mind Map by , created over 5 years ago

Tecnologia da Informação e Comunicação Engenharia de Software Mind Map on 12. Eng de Software:Modelo Processo Unificado, created by Jamil Yahuza Felippe on 06/04/2014.

95
1
0
Jamil Yahuza Felippe
Created by Jamil Yahuza Felippe over 5 years ago
Quiz - Processos tradicionais
Adriana Gomes Alves
Aula Um Engenharia de Software III
Artur R
Modelagem de Software
FARLEY DE OLIVEIRA RANGEL
An Inspector Calls: Sheila Birling
Rattan Bhorjee
AS level Maths Equations to Remember
Gurdev Manchanda
Engenharia de Software
Gabriel Alexandre
Quiz - Processo de Software
Adriana Gomes Alves
Áreas de Conhecimento X Grupos de Processos
Rodrigo Ferreira
Requisitos
carlinhosarena
12. Eng de Software:Modelo Processo Unificado
1 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).
1.1 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.
1.1.1 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:
1.1.1.1 Estrutura dinâmica: representa a dimensão do tempo no processo.
1.1.1.1.1 A estrutura que representa o tempo é denominada: Fase
1.1.1.1.1.1 Fases
1.1.1.1.1.1.1 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
1.1.1.1.1.1.1.1 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.
1.1.1.2 Estrutura estática: descreve como elementos do processo são agrupados em disciplinas.
1.1.1.2.1 A estrutura que representa os elementos do processo são as: Disciplinas
1.1.1.2.1.1 É 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:
1.1.1.2.1.1.1 Modelagem de negócios:
1.1.1.2.1.1.1.1 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.
1.1.1.2.1.1.2 Requisitos:
1.1.1.2.1.1.2.1 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.
1.1.1.2.1.1.3 Análise e design:
1.1.1.2.1.1.3.1 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.
1.1.1.2.1.1.4 Implementação:
1.1.1.2.1.1.4.1 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.
1.1.1.2.1.1.5 Teste:
1.1.1.2.1.1.5.1 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.
1.1.1.2.1.1.6 Implantação:
1.1.1.2.1.1.6.1 Descrever as atividades associadas à verificação para que o produto esteja disponível ao usuário final.
1.1.1.2.1.1.7 Gerenciamento de configuração e mudança:
1.1.1.2.1.1.7.1 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.
1.1.1.2.1.1.8 Gerenciamento de projeto:
1.1.1.2.1.1.8.1 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.
1.1.1.2.1.1.9 Ambiente:
1.1.1.2.1.1.9.1 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.
1.1.2 O processo unificado organiza suas iterações em quatro fases principais:
1.1.2.1 Concepção ou iniciação:
1.1.2.1.1 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.
1.1.2.2 Elaboração:
1.1.2.2.1 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.
1.1.2.2.1.1 Estes servem como base de avaliação junto ao usuário e desenvolvedores para o planejamento da próxima iteração.
1.1.2.2.1.1.1 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.
1.1.2.3 Construção:
1.1.2.3.1 Visa à implementação iterativa dos elementos restantes de menor risco e mais fáceis, além da preparação para a implantação.
1.1.2.4 Transição:
1.1.2.4.1 Testes finais e implantação.
2 De uma maneira geral, podemos caracterizar o processo unificado da seguinte forma:
2.1 É um framework genérico de um processo de desenvolvimento;
2.2 É baseado em componentes;
2.3 Utiliza toda a definição da UML;
2.4 É dirigido pelos use cases, centrado na arquitetura, iterativo e incremental (conceitos-chave).
3 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.

Media attachments