Professional Documents
Culture Documents
Processo de
Desenvolvimento de
Software com
UML/RUP I
Belo Horizonte
2010
Presidente da FIEMG
Olavo Machado Jnior
Gestor do SENAI
Petrnio Machado Zica
Elaborao
Lucas Lemos Costa
Unidade Operacional
Centro Tecnolgico de Eletroeletrnica Csar Rodrigues - CETEL
Sumrio
APRESENTAO ....................................................................................................... 8
1 Problemas do desenvolvimento de software .......................................................... 10
1.1
2
APRESENTAO
Isto porque, nos embates dirios, instrutores e alunos, nas diversas oficinas e
laboratrios do SENAI, fazem com que as informaes, contidas nos materiais
didticos, tomem sentido e se concretizem em mltiplos conhecimentos.
O SENAI deseja, por meio dos diversos materiais didticos, aguar a sua
curiosidade, responder s suas demandas de informaes e construir links entre os
diversos conhecimentos, to importantes para sua formao continuada !
10
Um projeto vem logo aps uma boa anlise, em um projeto necessrio que os
requisitos da anlise sejam atendidos. Uma boa forma de entender oque anlise e
oque projeto pode ser explicado na seguinte frase: faa a coisa certa (anlise) e
faa certa a coisa (projeto).
11
Baixa qualidade
Desempenho inaceitvel
12
2.2 Causas
Tratar os sintomas diretamente, entretanto, no soluciona o problema, pois razes
mais profundas podem existir, principalmente na especificao dos requisitos,
desenho e implementao. As causas principais para estes sintomas so as
seguintes:
Arquiteturas frgeis.
Complexidade subestimada.
13
Testes insuficientes.
Crescimento descontrolado.
Inaptido da equipe.
Automao insuficiente.
14
muitas
vezes
confundido
com
de
modelo
de
processo.
Definio
Desenvolvimento
Operao
Retirada
15
do
sistema,
indicando
informaes
sobre
hardware,
software,
pessoal,
16
3.2.1Design
A atividade de design compreende todo o esforo de concepo e modelagem que
tm por objetivo descrever como o software ser implementado. O design inclui:
Design conceitual
17
3.2.2 Implementao
A implementao envolve as atividades de codificao, compilao, integrao e
testes. A codificao visa traduzir o design num programa, utilizando linguagens e
ferramentas adequadas. A codificao deve refletir a estrutura e o comportamento
18
Distribuio e entrega
Instalao e configurao
Utilizao
Manuteno
19
A distribuio e entrega pode ser feita diretamente pelo desenvolvedor (em caso de
software personalizado), ou em um pacote a ser vendido em prateleiras de lojas ou
para ser baixado pela Internet (em caso de software genricos).
20
21
22
No modelo cascata os requisitos no podem sofrer muitas alteraes, haja vista que
alteraes causam grande impacto. Para o cliente, esse modelo pouco visvel, pois
o produto s entregue quando est totalmente completo. Dispositivos no
removveis que guardam grandes quantidades de informao e podem ser
acessadas rapidamente.
23
24
Requisitos esto congelados: Essa uma falsa suposio por que os usurios
mudam, o problema muda, a tecnologia muda, o mercado muda e por que ns no
conseguimos capturar todos os requisitos com um nvel suficiente de detalhes e
preciso.
O desenho correto do sistema pode ser feito antes de implementar: Isto falso por
que a definio de correto envolve preciso, eficincia, confiabilidade, etc. E isto s
pode ser garantido com mtodos formais(ex. Modelos matemticos) ou atravs da
codificao. Como mtodos formais so raramente aplicados, a soluo provar
atravs de cdigo, o que nem sempre traz a confirmao do correto.
A escolha aps esses contras do modelo cascata, recai sobre o iterativo. Mas ele
tambm tem suas limitaes.
25
muito fcil dizer que se usa um processo XYZ interativo, mas que na verdade
aplicado com se fosse cascata. O processo em cascata mais intuitivo. Boa parte
dos times tem como gerente de projeto um analista de sistema, sem experincia em
Gesto de projetos. O modelo iterativo exigente nos aspectos de gesto.
Existe uma presso nas fbricas de software, para utilizarem o modelo em cascata.
Em geral, as fbricas de software recebem uma especificao 100% pronta e j
partem para a codificao. Uma maneira de suavizar esse problema negociar
previamente a reviso dos requisitos e trabalhar com entregas parciais.
26
5 Processo Unificado
O processo unificado (Unified Process UP) foi criado pelos trs amigos: Ivar
Jacobson, Grady Booch, e James Rumbaugh, em 1999 [JACOBSON, WINDLE] .
Neste curso voc ver uma verso simplificada do Unified Process, enfatizada
principalmente na especificao dos requisitos, anlise e desenho.
Iterativo;
Adaptvel;
Existem diferentes adaptaes para o Processo Unificado. Entre elas, podemos citar
o Rational Unified Process, verso comercial, de propriedade da IBM e o Enterprise
Unified Process, criado por um conjunto de consultores. O prprio Processo
27
Unificado tem uma disciplina ( ambiente ) onde uma das atividades justamente
adaptar o processo s necessidades do projeto.
O processo unificado requer trs caractersticas para que ele se torne efetivo.
Primeiro voc sempre deve conhecer o que voc acabou de fazer. Segundo voc
sempre sabe o que fazer a seguir. Terceiro voc tem um arcabouo no qual voc ir
incorporar o que voc aprendeu medida que so realizadas as interaes. Por
exemplo, se voc acabou de atualizar o modelo de casos de uso, voc precisar
rever os modelos da anlise para determinar se alguma alterao necessria.
5.1.1 Fases
O Processo Unificado organiza as iteraes em quatro grandes fases:
28
5.1.2 Iteraes
Fases so compostas por uma ou mais iteraes. Durante cada iterao, cada uma
das disciplinas poder ser abordada de forma diferente, com maior ou menor
ateno. No processo de iterao o desenvolvimento organizado em uma serie de
miniprojetos, de durao fixa (30 dias), o produto de cada iterao testado,
integrado e executado. Cada iterao inclui suas prprias atividades de anlise de
requisitos, projeto, implementao e teste.
Os benefcios do desenvolvimento iterativo dentro pro Processo Unificado so:
Progresso visvel desde o inicio.
Envolvimento do usurio e adaptaes fazendo com que o sistema atenda as
necessidades dos interessados no projeto.
Menor
complexidade
na
administrao,
pois
equipe
no
fica
sobrecarregada.
O aprendizado em uma iterao pode ser usada para melhorar um outro
processo de iterao.
5.1.3 Disciplinas
As atividades de trabalho do Processo Unificado so descritas atravs de disciplinas.
As disciplinas, anteriormente conhecidas como workflows no Processo Unificado,
so formadas por um conjunto de atividades em uma mesma rea de assunto e seus
respectivos artefatos.
29
30
6 Disciplinas
A seguir descreveremos as disciplinas definidas no Processo Unificado.
6.2 Requisitos
Levantamento e Anlise dos requisitos, atravs da escrita dos casos de uso e
identificao dos requisitos no-funcionais.
6.4 Implementao
No processo unificado, significa programao e construo do sistema, no
implantao.
6.5 Teste
Esta disciplina consome artefatos produzidos em outras e tem como objetivo verificar
e validar se o sistema est correto, segundo os requisitos, e com qualidade.
Implantao (Deployment): Refere-se s atividades de instalao e configurao
do sistema e capacitao dos usurios.
31
32
7 Artefatos
Artefatos so produtos de cada disciplina dentro de um processo de software. No
Processo Unificado, um artefato significa um produto do trabalho: diagramas UML,
cdigo fonte, grficos, esquema de banco de dados, diagramas, documentos
texto,etc.
33
34
Disciplina
Modelagem
negcio
Aspecto Geral
Aspecto Especfico
casos
de
uso
de negcio.
Analista
Descobre
Anlise e Desenho
um
negcio.
Requisitos
Detalha
de
sistemas Especificador
todos
de
os Requisitos (analista)
Detalha um conjunto.
Arquitetura de software
Projetista (analista)
Decide
quais
as Detalha
anlise
Implementao
no projeto.
de casos de uso.
Integrador
Desenvolvedor
Possui
Teste
plano
de Implementador
construo
que
como
classes
as
ou
operaes.
Gerente de Teste
Projetista de teste
os
testes
definidos
para a iterao.
35
Analista de Teste
Testador
Executa
Projetista de Teste
especfico.
um
teste
cria
automao.
Implantao
Gerente de implantao
Escritor
Tcnico
Gesto de Projeto
as
de
envolvidas
(pessoas, Cria
material
detalhado
computadores,
etc).
implantao.
Gerente de Projeto
Gerente de Projeto
geral.
Toma
rastreia
Ambiente
Engenheiro de Processo
Responsvel
Especialista
em
pelo Ferramenta
processo do projeto.
Cria as recomendaes
para usar uma ferramenta
especfica.
de
Alteraes
gerencia
solicitaes de alteraes.
36
Define
processos
de
gesto de alteraes.
37
10 Prticas do PU
Uma boa forma de por em prtica o Processo Unificado utilizar o desenvolvimento
iterativo com tempos curtos e para isto algumas boas prticas e conceitos sao
importantes.
38
10.3 Arquitetura
O Processo Unificado centrado na arquitetura, isto porque o PU trata os assuntos
de alto risco em iteraes iniciais, pois comear estabelecer uma arquitetura
geralmente um risco ou elemento crtico no projeto.
10.5Caso de Uso
Casos de uso sao histrias escritas de uso de um sistema. Sao mecanismos para
explorar e registar requisitos funcionais do sistema. O PU utiliza casos de uso como
forma de
escrever
39
Conceitos
Best practices (melhores prticas)
Fases de desenvolvimento
40
41
practices)
serem
executadas
durante
todo
processo
de
42
43
11.7.1 Concepo
Durante a fase inicial, voc estabelece o business case para o sistema e delimitar o
escopo do projeto. Para conseguir isso, voc deve identificar todas as entidades
44
45
11.7.2 Elaborao
O propsito desta fase analisar o domnio do problema, desenvolver o plano de
projeto, estabelecer a fundao arquitetural e eliminar os elementos de alto risco.
Os elementos de risco a serem analisados, nesta fase, so os riscos de
requerimentos, tecnolgicos (referentes a capacidade das ferramentas disponveis),
de habilidades (dos integrantes do projeto) e polticos.
Esta a fase mais crtica de todas, pois ao final desta fase a engenharia
considerada completa e os custos para modificao do sistema aumentam medida
que o projeto avana. Do ponto de vista administrativo, ao final desta fase que um
projeto deixa de ser uma operao de baixo risco e baixo custo para se tornar uma
operao de alto risco e alto custo.
O resultado da fase de elaborao a seguinte:
Um modelo de caso de uso (pelo menos 80% concludo) - todos os casos de
uso e atores foram identificados, e mais uso das descries de casos tem
sido desenvolvido.
46
47
11.7.3 Construo
Esta fase compreende a fase de modelagem e a fase de desenvolvimento em si,
aquela em que o sistema efetivamente programado. A fase de modelagem deve
utilizar alguma notao definida pela UML.
Os manuais do usurio.
Neste ponto, voc decide se o software est pronto para uso, sem expor o projeto
para riscos elevados. Esta verso freqentemente chamado de uma liberao
"beta".
Os critrios de avaliao para a fase de construo envolvem responder a estas
perguntas:
esta verso do produto estvel e maduro o suficiente para ser implantado
na comunidade de usurios?
Todos os envolvidos esto prontos para a transio para a comunidade de
usurios?
Os gastos de recursos reais versus despesas previstas ainda aceitveis?
Transio pode ter de ser adiada por um release se o projeto no atinja este marco.
48
11.7.4 Transio
A partir desta fase, o sistema j est pronto, comea a implantao do sistema para
o usurio (ou a comunidade de usurios do mesmo). Nesta fase deve ser utilizado o
lanamento de verses beta, operao paralela com o sistema legado, treinamento
dos usurios e mantenedores do sistema, etc.
dos
usurios. Normalmente.
Considervel
esforo
dispendido
no
Neste ponto do ciclo de vida, no entanto, feedback do usurio deve ser confinado
principalmente para ajuste de produtos, configurao, instalao e problemas de
usabilidade.
Os objetivos primrios da fase de transio incluem:
Suporte ao usurio
Atingir o consentimento dos envolvidos de que as baselines de implantao
so completos e coerentes com critrios da viso
Atingir baseline do produto final, rapidamente e com baixo custo como prtica.
Esta fase pode variar em ser muito simples ou muito complexa, dependendo do tipo
de produto. Por exemplo, uma nova verso de um produto de mesa existente pode
ser muito simples, enquanto que a substituio de controle de um software de
trfego areo sistema seria muito complexo.
49
Neste ponto, voc decide se os objetivos foram cumpridos, e se voc deve comear
um outro ciclo de desenvolvimento. Em alguns casos, esse marco pode coincidir
com o final da fase de iniciao para o prximo ciclo.
Os critrios bsicos de avaliao para a fase de transio envolvem as respostas
para estas perguntas:
O usurio est satisfeito?
Os gastos reais dos recursos contra despesas previstas ainda aceitvel?
11.8 Iteraes
Cada
fase
no
Rational
Unified
Process
podem
ser
subdivididas
em
50
11.1 Trabalhador
Um trabalhador define o comportamento e as responsabilidades de um indivduo ou
um grupo de indivduos que trabalham juntos como uma equipe. Voc poderia
considerar um trabalhador como um "chapu" que um indivduo pode usar no
projeto. Um indivduo pode usar muitos chapus diferentes.
papel
definindo
como
os
indivduos
devem
realizar
trabalho. As
11.2 Atividade
Uma atividade de um trabalhador especfico uma unidade de trabalho que um
indivduo em que o papel pode ser solicitado a executar. A atividade tem um
propsito claro, normalmente expressa em termos de criao ou atualizao de
alguns artefatos, como um modelo, uma classe, um plano.
51
11.3 Artefato
Um artefato um pedao de informao que produzido, modificado ou usado por
um processo. Artefatos so os tangveis produtos do projeto, algo utilizado no
projeto enquanto no chegava no produto final.
Artefatos so usados como entrada dos trabalhadores para realizar uma atividade, e
so o resultado ou sada de tais atividades. Em um projeto orientado a objeto termos
de design, como as atividades so operaes em um objeto ativo (o trabalhador), os
artefatos so os parmetros dessas atividades como:
Um modelo, como o Modelo de Casos de Uso ou o Modelo de Design
Um elemento do modelo, ou seja, um elemento dentro de um modelo, como
uma classe, um caso de uso ou de um subsistema
Um documento, como o Business Case ou Documento de Arquitetura de
Software
O cdigo-fonte
executveis
52
53
12 Requisitos
So um conjunto de caractersticas, condies e capacidades que o sistema deve
abranger e realizar. Ele tem o papel de descrever as funcionalidades que o sistema
deve ter, bom como o sistema deve fazer para atender a estas funcionalidades. O
conjunto de requisitos dinmico e envolve identificao contnua.
54
Este requisito deve atender a um comportamento na qual usurio espera que ele
faa traduzindo o que o sistema/produto precisa fazer para atender as
suas
55
so as polticas e procedimentos
56
seu
processo
de
desenvolvimento.
Por
exemplo:
requisitos
de
57
58
59
60
61
13 Problema
O grande desafio para se identificar e modelar requisitos de um sistema se deve ao
fato de que eles so dinmicos, e podem mudar durante um projeto. Softwares so
construdos todos os dias baseados em requisitos que freqentemente mudam. Mas
quais so as causas dessa mudana? Entre os fatores, podem ser citadas as
alteraes nos planos do cliente e ainda o fato de que a noo completa dos
requisitos s fica mais clara nas fases finais do projeto.
Um bom levantamento de requisitos traz muitos benefcios que tem impacto direto
na produtividade, teste, qualidade e organizao. Esses benefcios podem ser
aproveitados tanto durante o desenvolvimento quanto durante a manuteno do
sistema:
Uma boa especificao permite ao analista identificar conflitos entre os
requisitos do usurio no inicio, coletando respostas para as dvidas e
evitando que uma direo errada faa com que um produto errado seja
construdo.
Uma boa especificao ajuda a diminuir a curva de aprendizado para novos
integrantes do time de desenvolvimento.
A especificao de requisitos tambm facilita e acelera o processo de testes.
O testador pode aprender a usar o sistema e explorar suas funcionalidades
to rpido quanto novos integrantes.
Finalmente uma boa especificao uma rea segura de armazenamento da
propriedade intelectual da empresa.
62
operacionais
do
sistema,
administradores
do
sistema
administradores de rede,
63
Crie uma lista de stakeholders para cada ator como por exemplo:
64
Seu trabalho requer a interao com algum sistema externo no caso de uso
xyz?
O seu trabalho utiliza dados externos para a execuo do caso de uso xyz?
importante que essas informaes adicionais sejam bem guardadas, pois sero
muito teis no processo de desenvolvimento.
Existem trs questes fundamentais usadas para tentar solucionar esse problema:
Remoo: Informao no fornecida.
Distoro Informao modificada por criao ou engano.
Generalizao A criao de regras.
Agente de Reservas: Quando eu fao uma reserva, anoto o quarto que est sendo
reservado.
Problema: O agente esquece o fato que vrios quartos podem ser reservados.
65
Agente de Reservas: Uma reserva pode ser mantida sem a confirmao com o
carto de crdito. Mas cancelada se o cliente no confirm-la dentro de duas
semanas.
Problema: O Agente de Reservas forneceu uma informao incorreta ao
entrevistador sobre a poltica de cancelamento, pois o cancelamento dado dois
dias antes da data de chegada do hspede.
Soluo: Pergunte outros stakeholders para validao e esclarecimento.
66
67
15 Documento Viso
O Documento Viso desenvolvido aps a coleta e anlise dos requisitos
preliminares. O documento Viso contm a viso do dono sobre o sistema de
software. O propsito deste documento expor as necessidades e funcionalidades
gerais do sistema.
Seu foco est nas necessidades dos patrocinadores (stakeholders) no motivo da
existncia destas necessidades e tambm documenta os riscos e restries.
15.1 Introduo
O enunciado do problema um resumo sucinto do problema do negcio. Ele no
inclui todos os RFs ou casos de uso, mas pelo menos os principais.
68
Exemplo:
Exemplo:
Bay View B&B uma empresa hoteleira inaugurada em 1987, em Santa Cruz, CA,
por vrios scios, dentre eles, Peter e Mary Jane Parker. Em 2005, eles adquiriram
outra B&B em Sonoma, CA. Os negcios estavam indo bem quando Mary Jane e
Peter estavam de frias no Resort Sierra Madre em 2008, eles conversaram com o
scio majoritrio e descobriram que ele estava pronto para se aposentar. Esta era a
oportunidade que eles estavam esperando para expandir o negcio. Eles esto
atualmente trabalhando no fechamento deste acordo. O Sistema de Reserva de
Hotel est sendo proposto para fornecer uma integrao destes imveis.
69
15.4 Riscos
Esta seo do documento Viso registra todos os riscos que foram identificados nas
entrevistas com o dono do negcio. Descreva qualquer risco relativo com questes
tecnolgicas, problemas de equipe de desenvolvimento, problemas polticos, etc.
Exemplo:
70
15.5 Restries
Esta seo do documento Viso registra todas as restries que foram identificadas
em entrevistas com o dono do negcio.
Exemplo:
71
16. SRS
SRS (Especificao de Requisitos de Software ) controla a evoluo do sistema em
toda a fase de desenvolvimento do projeto. Quando novos recursos so adicionados
ou modificados no documento Viso, eles so elaborados dentro do SRS.
O documento SRS contm seis sees:
Introduo
Restries e suposies
Riscos
Requisitos Funcionais
Requisitos No Funcionais
Glossrio do projeto
O documento SRS deve ser detalhado sem perda de claridade ou foco.
16.1Introdo
O propsito da introduo do documento de descrever o objetivo e contexto do
documento e no o propsito da aplicao. A introduo deve ser muito breve e
direta ao ponto.
A seo introdutria inclui:
Objetivo
Escopo
Contexto do sistema
Principais Stakeholders
Acrnimos e abreviaes
Organizao do documento
Descrio de como as mudanas de requisitos sero tratatadas
Referncias
72
16.3 Riscos
Esta seo fornece uma lista completa dos riscos de projeto mais estratgia, para
minimizao do risco. O conjunto de riscos deve incluir todos os riscos listados no
documento viso, mas pode tambm incluir riscos adicionais identificados durante
entrevistas para coleta de requisitos.
Riscos Tecnolgicos.
Risco de Recursos e Habilidades
Riscos Polticos
73
16.4.1 atores
Fornece um resumo sucinto das habilidades do ator.
Por exemplo:
Esta pessoa gerencia reservas de clientes por telefone; assim sendo, Ela,
normalmente, o primeiro ponto de contato com o Gerenciamento de imveis da
Bay View.
Esta pessoa no precisa de grande escolaridade (o ensino mdio recomendado),
mas essa pessoa precisa ser familiar com o Sistema Operacional Windows e dever
ser bom digitador. Esta pessoa ser treinada nos imveis da Bay View.
16.4.3 Aplicaes
A seo Aplicaes fornece uma tabela de todas as aplicaes independentes que
formam o sistema.
Por exemplo:
74
16.4.4Requisitos detalhados
A seo de detalhamento de requisitos uma lista completa de Requisitos
Funcionais detalhados que compe cada caso de uso.
Cada Requisito Funcional possui um identificador baseado no cdigo do caso
de uso. O cdigo do caso de uso o cdigo de prioridade concatenada com o
nmero nico do caso de uso.
Cada Requisito Funcional possui uma descrio.
Por Exemplo:
75
do Caso de Uso.
Cada Requisito No-Funcional possui uma descrio.
Por exemplo:
16.6 Glossrio
O glossrio no documento SRS deve incluir:
Termos do Domnio
Sinnimos
Termos Tecnolgicos
Termos usados no desenvolvimento do software
16.7 Resumo
A Coleta ou Levantamento de Requisitos essencial a um projeto de software de
sucesso porque os requisitos especificam o comportamento do sistema a ser
implementado. Requisitos so adquiridos de vrias fontes com vimos, p.e entrevistas
com stakeholders so as principais ferramentas para coleta de requisitos.
O Documento SRS estende o Documento Viso e fornece requisitos detalhados.
76
77
78
79
Para cada classe, proucure atributos comuns. Por exemplo, toda empresa no Brasil
tem CNPJ, geralmente um aluno tem um nmero de mtricula, um livro tem ISBN,
etc. Atributos contm o estado ou caractersitcas de um objeto.
Existe um longo caminho para que se saa do modelo de domnio e atinja o cdigo.
Em projetos maiores, necessario criar um ou mais modelos mais prximos ao
cdigo, como os modelos de anlise de projeto, antes de atingi-lo. Porm, para
projetos mais simples, o modelo de domnio, poder ser suficiente. Existem vrios
software no mercado que geram cdigo a partir de um modelo de domnio.
80
81
82
83
84
REFERNCIAS BIBLIOGRFICAS
Larman, Craig. Utilizando UML e padres: Uma introduo a analise e ao projeto
orientados a objetos e ao Processo Unificado 2 . ed. Bookman,2004.
85