Introduo ao Processo Unificado (PU)

Prof. Anderson Cavalcanti UFRN-CT-DCA

Processo de Desenvolvimento
O conjunto de atividades de desenvolvimento, sua ordem temporal e a atribuio de responsabilidades (papis de desenvolvedores) definem um processo de desenvolvimento de software; Um processo de software a especificao do processo de transformar necessidades em software; Ciclo de Vida de um Processo:
Determina as fases do processo; Define atividades importantes e opcionais para cada fase.

Processo Unificado (PU)

O processo unificado (Unified Process UP, ou em portugus, PU) um processo de desenvolvimento de software; Existem outros processos alm do PU?
IBM/Rational (Baseado no PU)
RUP Rational Unified Process

Scott W. Ambler (Baseados no PU)

AUP Agile Unified Process EUP Enterprise Unified Process

Onde entra a UML?

O PU usa a UML como linguagem de modelagem; Qual a razo de utilizar linguagens grficas? Veja:
package br.dominio; public class Cliente { private int cod_cliente; private String nome; private String cpf; private Dependente[] dependente; } package br.dominio; public class Dependente { private int cod_dependente; private String nome; private String grauParenteco; }

Onde entra a UML?

A UML usada para facilitar o entendimento de aspectos complexos inerentes ao sistema computacionais; A UML uma famlia de notaes grficas que ajuda na descrio e no projeto de sistemas de software.

Caractersticas do PU
Dirigido por casos de uso:
Ter os casos de uso como entrada (fonte) para a maioria das atividades do processo;

Centrado na arquitetura:
Motivado a desenvolver o produto com base em uma arquitetura de software;

Iterativo e incremental:
Dividir o projeto em partes gerenciveis, de forma a incrementar as funcionalidades continuamente at o final da construo do produto.

Entendendo o PU: Casos de Uso?

O que so casos de uso?
Seqncia de aes que so executadas por um ou mais atores e pelo prprio sistema; Produz um ou mais resultados de valor para um ou mais atores.

Como o PU utiliza os casos de uso?

Os casos de uso servem de fora condutora do desenvolvimento; A expresso dirigido refere-se a utilizar os casos de uso como fonte de todo o trabalho no processo de desenvolvimento:
Desde a captao dos requisitos dos usurios aos testes de aceitao.

Entendendo o PU: Casos de Uso?

Por que casos de uso?
So expressos sob a perspectiva dos usurios do sistema; So expressos em lngua natural, intuitivamente bvios para o leitor; Oferecem uma habilidade consideravelmente maior para a compreenso dos reais requisitos do que documentos tpicos;

Entendendo o PU: Casos de Uso?

Por que casos de uso?
Oferecem uma habilidade para atingir um alto grau de rastreamento de requisitos dos outros artefatos que so construdos; Oferecem um meio simples de decompor os requisitos dos usurios em pedaos menores que permitam alocao de trabalho de sub-equipes.

Entendendo o PU: Arquitetura?

O que uma arquitetura?
Organizao fundamental do sistema como um todo; Entre aspectos importantes de uma arquitetura esto includos elementos estticos e dinmicos; Arquitetura tambm descreve questes de desempenho, escalabilidade, reuso, restries tecnolgicas (os requisitos no funcionais);

Entendendo o PU: Arquitetura?

A arquitetura do sistema em construo o alicerce fundamental sobre o qual construir o produto; A arquitetura deve ser vista e compreendida por todos da equipe; Arquitetura o mecanismo para chegar a um produto robusto, flexvel, expansvel e de custo vivel.

Entendendo o PU: Arquitetura?

Por que centrar o desenvolvimento na arquitetura?
Entender a viso global, simplificando o entendimento de sistemas complexos; Organizar o esforo de desenvolvimento, dividindo o software em pores discretas; Facilitar as possibilidades de reuso, facilitando o reuso de componentes dentro das pores discretas;

Entendendo o PU: Arquitetura?

Por que centrar o desenvolvimento na arquitetura?
Facilitar a evoluo do sistema, permitindo mudanas mais fceis dentro das pores principalmente quando no muda as responsabilidades; Dirigir os casos de uso, fornecendo condies de sempre adicionar mais casos de uso.

Exemplo de Arquitetura
Padro Arquitetural: Camadas
Organizar a estrutura lgica de larga escala de um sistema em camadas distintas de responsabilidades precisas e relacionadas.
Janelas Relatrios XHTML, Javascript, entre outros Trata as requisies da camada de viso

Observe que, neste padro de arquitetura, cada camada representada por um pacote, em linguagem UML.

Trata as requisies da camada de controle Implementa as regras de domnio

Trata as requisies da camada de domnio Persiste os objetos da camada de domnio (em um BD, por exemplo)

Entendendo o PU: Iterativo e Incremental

Iterao um mini-projeto que resulta em uma verso do sistema liberada internamente ou externamente; pressuposto que a cada mini-projeto posterior incrementa em funcionalidade o mini-projeto anterior.

Ciclo de Vida
O que ciclo de vida?
Apresenta um conjunto de perodos, desde nascimento at a sua morte; Cada perodo possui um conjunto de fases; A transio entre as fases marcada por algum evento.

Fases do PU
Concepo ou iniciao (Inception)
Viso aproximada, casos de negcio, escopo e estimativas vagas;

Elaborao (Elaboration)
Viso refinada, implementao iterativa da arquitetura central, resoluo dos altos riscos, identificao da maioria dos requisitos e estimativas mais realistas;

Construo (Construction)
Implementao iterativa dos elementos restantes de menor risco e mais fceis e preparao para a implementao;

Transio (Transition)
Testes beta e implantao.

Fluxo de Trabalho
O que fluxo de trabalho?
Cada fluxo indica um conjunto de atividades e vrios tipos de membros que as executam; No processo unificado existem 5 fluxos de trabalho: Requisito, anlise, projeto, implementao e teste; Os fluxos permeiam as 4 fases do processo unificado.

Fluxos de trabalho sinnimo de disciplinas (oriundo do RUP).

Fluxos de Trabalho do PU
Requisitos - Qual o objetivo?
Visa construir o modelo de casos de uso que captura os requisitos funcionais do sistema.

Anlise - Qual o objetivo?

Visa construir o modelo de anlise, que ajuda os desenvolvedores a refinar e estruturar os requisitos funcionais

Fluxos de Trabalho do PU
Projeto - Qual o objetivo?
Visa a construir o modelo de projeto, o qual descreve as realizaes fsicas dos casos de uso - abstrao de implementao; Visa tambm o modelo de instalao, que define a organizao fsica do sistema.

Fluxos de Trabalho do PU
Implementao - Qual o objetivo?
Visa a construir o modelo de implementao, que descreve como os elementos do modelo de projeto so empacotados em componentes de software.

Teste - Qual o objetivo?

Visa a construo do modelo de teste que descreve como os testes de integrao e de sistema exercitaro componentes executveis a partir do modelo de implementao.

Fases x Iteraes
Qual a relao entre fases e iteraes?
As fases contm iteraes seqenciais; O marco principal (fases) conseguido a partir de mini-projeto (iteraes).
Fase Iterao

Concepo

Elaborao

Construo

Transio

Marco de Referncia Ponto de trmino de uma Iterao no qual ocorre alguma deciso significativa.

Verso Um subconjunto estvel executvel do produto final.

Incremento Diferena entre as entregas de 2 etapas subseqentes.

Entrega Final O sistema entregue para uso.

Iteraes x Fluxos de Trabalho

Qual a relao entre iteraes e fluxos de trabalho?
As iteraes podem conter os 5 fluxos de trabalho; As iteraes do incio do processo normalmente ficam nos fluxos de requisitos e anlise; Estas iteraes podem chegar ao fluxo de projeto, mas raramente ao fluxo de implementao e teste; As iteraes do final do processo de desenvolvimento normalmente usualmente executam os fluxos de implementao e teste.

Iteraes e incrementos
Cada fase dividida em iteraes
Relembrando, iteraes so mini-projetos Uma iterao tpica, usa os 5 fluxos de trabalho O resultado da execuo dos fluxos um incremento

O que um incremento?
Incremento uma verso do sistema que contm funcionalidade adicionada ou melhorada em comparao com a anterior

Atividades de cada iterao

Planejar a iterao; Executar as disciplinas (fluxos de trabalho); Fazer anlise ao trmino da iterao; Descartar os riscos que o incremento tratou; Revisar o plano do projeto; Ir para a prxima iterao, se existir.

Artefatos
O que so artefatos? Artefato qualquer poro significativa de informao interna ou externa que desempenhe um papel no desenvolvimento do sistema; Existem artefatos tcnicos e genricos
Exemplo de artefatos genricos: anlise econmica, plano de projeto, riscos.

Trabalhadores
O que so trabalhadores?
Trabalhador um papel que um indivduo pode desempenhar no projeto em um dado momento;

Diferena entre trabalhador e Ator

Atores utilizam o sistema e podem participar do desenvolvimento, normalmente fornecendo informaes sobre o cliente; Trabalhadores somente participam do desenvolvimento do sistema.

Atividades
O que so atividades?
Atividades so tarefas que um trabalhador executa a fim de produzir ou modificar um artefato; Para executar uma determinada atividade o trabalhador faz uso de artefatos.

Disciplinas
O que so disciplinas?
Determina um conjunto coerente de atividades a serem executadas para cumprir objetivos; A disciplina especificada por um fluxo de atividades, determinando os artefatos de entrada e sada de cada atividade deste fluxo bem como os respectivos nveis de detalhe de cada artefato.

PU Fase de Concepo

PU: Concepo
Deve ser curta Devem ser exploradas as seguintes questes: Qual a viso e o caso de negcio para o projeto?
Ele vivel? Devemos comprar ou construir? Estimativa aproximada de custo: da ordem de 10 mil, 100 mil ou de milhes? Devemos continuar ou parar?

PU: Concepo
Devem ser explorados alguns requisitos do sistema para responder algumas dessas questes; Concepo em uma frase:
Conceber o escopo do produto, a viso e o caso de negcio

Artefatos a Serem Iniciados

Outros artefatos podem ser construdos, no entanto, dentro do escopo desta disciplina, apenas a Viso e Caso de Negcio e o Modelo de Caso de Uso sero utilizados.

Artefatos a Serem Iniciados

Com exceo do Modelo de Casos de Uso, nenhum desses artefatos necessita ser implementado, a no ser que contribuam de fato com o desenvolvimento; Como estamos na concepo, o contedo da investigao e dos artefatos deve ser leve; Modelos de Documento esto disponveis em http://www.dca.ufrn.br/~anderson/

Compreenso dos Requisitos

Requisitos = so as capacidades e condies s quais o sistema em termos mais amplos, o projeto deve atender Desafio: encontrar, comunicar e lembrar o que realmente necessrio Gerncia de Requisitos

Tipos de requisitos (FURPS+)

Funcionais
Caractersticas, capacidade e segurana

Usabilidade
Fatores humanos, recursos de ajuda e documentao

Confiabilidade
Freqncia de falhas, capacidade de recuperao e previsibilidade

Tipos de requisitos (FURPS+)

Desempenho
Tempos de resposta, fluxo de vazo (throughput), preciso, disponibilidade e uso de recursos

Facilidade de Suporte
Facilidade de adaptao e de manuteno, internacionalizao e configurabilidade

Tipos de requisitos (FURPS+)

Implementao
Limitaes de recursos, linguagens e ferramentas, hardware, etc.

Interface
Restries impostas pelas interfaces com sistemas externos

Tipos de requisitos (FURPS+)

Operaes
Gerenciamento do sistema no ambiente operacional

Empacotamento Questes Legais

Licenas de uso, etc.

Explorao dos Requisitos

Caracterizados de forma macro como funcionais (comportamentais) e no funcionais (todos os outros) Requisitos funcionais so explorados:
No Modelo de Casos de Uso Na lista de caractersticas do sistema do artefato de Viso

Os outros requisitos podem ser registrados:

Nos Casos de Uso com os quais eles se relacionam No artefato de Especificaes Suplementares

Referncias
JACOBSON, I.; BOOCH, G. and RUMBAUGH, J. The Unified Software Development Process. Readding, MA.: Addison-Wesley, 1999, ALLEIXO, F. Notas de aula da disciplina de Anlise e Projeto Orientado a Objeto, CEFET/RN, 2007. SCOTT, K. O Processo Unificado Explicado. Ed. Bookman, 2003; MINORA, L. Notas de Aula de Eng. de Software I, CEFET/RN, 2006.