Processo_Unificado

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

AULA 9- UP (Unified Process)
Modelagem de Sistemas
Importância no desenvolvimento de sistemas
Núcleo ou parte central no desenvolvimento de SW
Primeiras metodologias:
Análises estruturadas como base (metodologias estruturadas)
Procedimentos e funções
Metodologias atuais: 
OO
Crescimento desordenado de metodologias 
Impossibilidade de suprir as necessidades por completo dos usuários (guerra de métodos)
Booch (Grady Booch) – OOSE (Jacobson) – OMT (Rumbaugh) 	 UML
UML (Unified Modeling Language) 
Linguagem de modelagem de sistemas para criar e ler modelos
Uso de diagramas
Não é uma metodologia
Não informa quais modelos devem ser criados e nem quando eles devem ser criados
Responsabilidade: Processo de Desenvolvimento de Sistemas
Necessidade de interação da UML com uma metodologia única
UP (Unified Process)
Mesmos criadores da UML (Jacobson, Booch e Rumbaugh)
Guia para uso da UML
Elementos do Processo Unificado
Processos
Descrevem: 
	quem faz (papel)
	o que faz (artefato)
	como faz (atividade)
	quando (disciplina)
PAPEL
-Feito por um trabalhador (responsabilidades sobre atividades para geração de um artefato)
Ator: usa o sistema, podendo também participar do desenvolvimento , provendo informações sobre o cliente
Trabalhador: participa do desenvolvimento do sistema
ARTEFATO
-Documentos, relatórios, modelos ou códigos gerados ou manipulados 
ATIVIDADE – tarefa executada por um trabalhador (visa produzir ou modificar um artefato)
DISCIPLINA – sequência de atividades (coerentes) que produzem algum resultado 
FASES
CONCEPÇÃO
-Identificação das necessidades dos usuários finais e clientes
-Consenso sobre o produto 
-Estabelecimento do escopo do SW (projeto inicial do sistema)
-Estimativas gerais de prazos e custos (elaboração de estimativas gerais de fases e datas de entrega)
-Ênfase no planejamento e levantamento de requisitos
-Identificação prévia de riscos
-Análise de viabilidade 
-Retorno do investimento
-Maior alocação de analistas envolvidos na modelagem do negócio
-Elaboração de “Business Modeling” ou “Requirements” 
5
FASES
ELABORAÇÃO
-Refinamento do problema anterior
-Exame dos requisitos mais significativos 
-Estabelecimento de uma arquitetura funcional do sistema
-Avaliação mais detalhada visando minimizar os riscos
-Estabelecimento de uma baseline para uma arquitetura mais sólida do projeto
-Foco é a análise e projeto do sistema (captura e modelagem dos requisitos)
-Pode envolver a criação de um protótipo 
Ex.: uma aplicação web, a partir da qual as interações dos atores com cada caso de uso é detalhada, além das classes do sistema. 
6
FASES
CONSTRUÇÃO
-Esclarecer eventuais requisitos da fase anterior e concluir o desenvolvimento do sistema
-Usa como base a arquitetura definida na fase anterior
-Desenvolve o SW completo de forma iterativa e incremental (evolução de protótipo, adicionando valor)
-Implica em testes de SW antes de entrega aos usuários
-Deve se preocupar se o SW, HW, usuários e locais físicos estão prontos para a implementação do aplicativo
-A cada ciclo é necessário rever os requisitos de cada parte da aplicação (envolvimento com usuário pode ser necessário)  essência do desenvolvimento incremental
7
FASES
TRANSIÇÃO
-Marcada pela entrega do produto (versão beta)
-Avaliação do produto (facilidade de uso, documentação etc)
-Pode demandar novas iterações para construção de versões que:
	 ajustem o sistema
	 corrijam o sistema
	 concluam o sistema
-Pode ser simples ou complexa
Simples – correção de erros e pequenos ajustes
Complexas – adição de novas funcionalidades pode tornar a iteração semelhante a uma iteração na fase de construção, podendo exigir novos requisitos, análise , projeto, implementação e testes. 
8
Processo Unificado
Características:
Processo Orientado por Caso de Uso
-Utilização dos casos de uso como principal recurso para especificação do sistema
-Sequência de ações de um sistema 
-Objetiva atender às necessidades de cada usuário que interage com o sistema
-Modelos de análise, projeto e implementação são criados a partir dos casos de uso
-Evolução ou maturação dos casos de uso durante o ciclo de vida
-Casos de uso como base para arquitetura do sistema
-A preferência por casos de uso se dá em razão destes serem escritos sob a perspectiva dos usuários (linguagem natural, intuitivamente mais óbvia para o leitor)
Processo Unificado
Processo Centrado na Arquitetura
-Visão de todos os modelos (macro) do sistema
-Visão abrangente, sem detalhamentos
-Destaque de características mais importantes (abstração)
-O que é significante em um sistema? (sensatez, experiência, ponto de vista etc)
-ARQUITETURA (ligada à forma) // CASOS DE USO (funcionalidade)
Processo Iterativo e Incremental
-Divisão em partes menores (miniprojetos)
-Miniprojeto: iteração que resulta em um incremento
-Iterações sucessivas : criação de artefatos a partir de iterações passadas
 
 PROJETO PRONTO
			
	
Requisito
Entendimento inicial do projeto
Análise
Identificação e especificação de casos de uso relevantes (o que o sistemadeve fazer?)
Projeto
Criação do projeto com base na arquitetura especificada (como os requisitosserão implementados?)
Implementação
Implementação do projeto
Teste
Realização de testes que satisfaçam os casos de uso
11
Processo Unificado
Descrição em duas dimensões
HORIZONTAL 
Ciclos e marcos do projeto 
Eixo temporal do projeto
VERTICAL
Atividades do projeto
Workflow entre as atividades 
Para cada iteração
-Identificação e especificação dos casos de uso relevantes
- Criação de projeto de acordo com a arquitetura escolhida
- Implementação de partes (componentes)
-Componentes satisfazem casos de uso? 
Sim: PRÓXIMA ITERAÇÃO
Não: REVISAR DECISÕES TOMADAS E PROPOR NOVA ABORDAGEM 
Vantagens do desenvolvimento por iterações: 
-Seleção dos elementos necessários para aquela iteração
-Administrar partes menores permite menor desvio de curso (variância de custos)
-Melhor controle de prazos (variância de prazos) 	 
13
Fases do Processo Unificado
Alocação de recursos e pessoas depende da demanda de cada fase do projeto
Exemplos de artefatos
FASES
ARTEFATOS
CRITÉRIOS DE SUCESSO
Concepção
Documento de visão ou declaração de escopo
Casos de uso iniciais
Businesscaseinicial
Avaliaçãoinicial de riscos
Plano preliminar de projeto
Glossário (terminologia-chave do domínio)
Concordância dosstakeholdersdo projeto
Entendimento dos requisitos
Estimativas de custos e prazos
Despesas atuais x planejadas
Elaboração
Casos de uso revisados
Plano de desenvolvimento de SW (gerenciamento, contratação, planejamento das fases , iterações e testes)
Avaliação atualizada dos riscos
Business case revisado
Descrição da arquitetura do SW
Estimativasde custos e cronogramas
Despesas atuais x planejadas
Construção
Planos individuais de iteração
Produto incremental
Plano de entrega do SW
Resultados dos casos de teste
Stakeholderpronto para transição
Despesas atuais x planejadas
Produto estável e pronto para serversionado
Transição
Versão final do produto
Documentação do produto
Análise das lições aprendidas
Aceite do cliente
Satisfação do usuário
Despesasatuais x planejadas
Exemplo
ATIVIDADE R1 – Reunião Inicial com o Cliente
Esta atividade representao primeiro contato com o cliente e visa levantar rapidamente uma noção do escopo inicial do projeto a ser realizado, coletando informações suficientes para planejar as sessões “JAD (JointApplicationDevelopment)PLAN”, as quais efetivamente levantarão os requisitos vagos do sistema. Esta atividade gera um artefato “R1-A1” (designação de responsabilidades) e “R1-A2”(ata da reunião inicial). O artefato R1-A1 identificará os principais papéis e suas respectivas responsabilidades para o andamento do projeto, enquanto o artefato R1-A2 deverá relatar a reunião, anotando as decisões tomadas,
as pendências encontradas e os responsáveis por acompanhá-las ou resolvê-las.
Artefatos necessários para esta atividade
Nenhum
Artefatos gerados por esta atividade
R1-A1 – designação de responsabilidades (atores)
R1-A2 – ata da reunião inicial
Comparação Processo Unificado X Cascata
CASCATA
Fases top-down em sequência
Objetivo: construir um complexo residencial (A1, A2 e A3) em 3 meses
Primeiro mês – estrutura para A1, A2 e A3
Segundo mês– engenharia para A1, A2 e A3
Terceiro mês– fachada para A1, A2 e A3
Comparação Processo Unificado X Cascata
UP
Interativo e incremental – identifica subsistemas e executa fases top down (estrutura, engenharia e fachada)
Objetivo: construir um complexo residencial (A1, A2 e A3) em 3 meses
Subsistemas – A1, A2 e A3
Primeiro mês– estrutura, engenharia e fachada para A1
Segundo mês– estrutura, engenharia e fachada para A2
Terceiro mês - estrutura, engenharia e fachada para A3
Exercício
Tente imaginar o desenvolvimento de um programa que objetive automatizar um sistema de locadora de veículos. A locadora deseja controlar melhor 3 grandes processos: a reserva do veículo, a retirada do veículo e a devolução do veículo. Esboce, de forma simples e objetiva, como você elencaria o desenvolvimento deste sistema com base nas 4 fases do processo unificado (concepção, elaboração, desenvolvimento e transição) ao longo do ciclo de desenvolvimento do projeto. 
Concepção
Elaboração
Desenvolvimento
Transição
Questionamentos sobre o Processo Unificado
-Baseado em ‘melhores práticas’ no desenvolvimento de SW
-Segundo Boehm: boas práticas podem burocratizar o processo de desenvolvimento
-Melhores práticas : dependem do contexto
Baseados em casos de uso
 - Casos de uso podem ser interpretados como sendo elementos completos para implementação de funcionalidades 
-Basear-se na compreensão dos requisitos a partir de canais escritos de comunicação pode ser problemático
Baseados na arquitetura
-Estabelece a arquitetura do SW antes de começar a implementação do mesmo
Foco na geração de artefatos (excesso de documentação gerada)
Questionamentos Gerais sobre o Processo de Desenvolvimento de SW
-Visão tecnicista
-Incapacidade de enxergar o fator humano
-Visão taylorista (trabalhador manual = homo economicus)
-Desenvolvedor  trabalhador do conhecimento
-Do que se origina um bom software? Boas práticas de programação, ferramentas CASE, boa escolha de uma linguagem de programação e BD etc? 
“Bom SW é resultado de pessoas, assim como é o caso de SWs ruins (..) já que SWs são criados por pessoas e usado por pessoas” 
(Larry Constantine: The Peopleware Papers, 2001)