Melhores Praticas PDF

Univag Centro Universitrio
UNIVAG - Centro Universitrio - Av. Dom Orlando

Chaves, 2.655 - Bairro Cristo Rei
Vrzea Grande - Mato Grosso - Brasil - CEP 78118000 - Telefax: +55 (65) 3688-6000
E-mail: univag@univag.com.br
Melhores Praticas de EngSoft.

Auditoria de Sistemas
Computacionais - Sob a tica do
Desenvolvimento de Software.
MELHORES PRTICAS
DE ENGENHARIA DE
SOFTWARE
Abordagens comercialmente
aprovadas para desenvolvimento de software


NDICE
1.
Melhores Prticas _____________________________________________________ 4

1.1.
Desenvolva Iterativamente __________________________________________ 5
1.1.1.
O que o Desenvolvimento Iterativo? _____________________________ 5
1.1.2.
Por que Desenvolver Iterativamente?______________________________ 6
1.1.3.
Vantagens de uma Abordagem Iterativa ___________________________ 7
1.1.3.1.
Diminuio de riscos ______________________________________ 8
1.1.3.2.
Acomodao de mudanas __________________________________ 8
1.1.3.3.
Busca de melhor qualidade__________________________________ 9
1.1.3.4.
Aprendizado e melhoria ___________________________________ 10
1.1.3.5.
Aumento de reutilizao___________________________________ 10
1.2. Gerencie Requisitos ______________________________________________ 11
1.2.1.
O que o Gerenciamento de Requisitos?__________________________ 11
1.2.1.1.
Anlise do problema______________________________________ 12
1.2.1.2.
Noes bsicas sobre as necessidades dos envolvidos____________ 13
1.2.1.3.
Definio do sistema _____________________________________ 13
1.2.1.4.
Gerenciamento do escopo do projeto _________________________ 14
1.2.1.5.
Refinamento da definio do sistema_________________________ 14
1.2.1.6.
Gerenciamento dos requisitos variveis _______________________ 15
1.2.2.
Como o Desenvolvimento Baseado em Casos de Uso? _____________ 16
1.3.
Use Arquiteturas de Componentes ___________________________________ 18
1.3.1.
O que significa Arquitetura de Componentes?______________________ 18
1.3.2.
nfase Arquitetural___________________________________________ 18
1.3.3.
Desenvolvimento Baseado em Componentes ______________________ 21
1.4.
Modele Visualmente (UML) _______________________________________ 23
1.4.1.
O que Modelagem Visual? ___________________________________ 23
1.4.2.
Por que Modelamos? _________________________________________ 23
1.4.2.1.
Ajuda na compreenso de sistemas complexos _________________ 24
1.4.2.2.
Explorao e comparao de alternativas de design a um baixo custo 25
1.4.2.3.
Formao de uma base para implementao ___________________ 25
1.4.2.4.
Captura de requisitos com preciso __________________________ 26
1.4.2.5.
Comunicao de decises sem ambigidade ___________________ 26
1.5.
Verifique Qualidade Continuamente _________________________________ 27
1.5.1.
O que Significa Verificao da Qualidade Durante o Ciclo de Vida? ____ 27
1.5.2.
O que Qualidade?___________________________________________ 28
1.5.2.1.
Introduo______________________________________________ 28
1.5.2.2.
Definio de Qualidade ___________________________________ 29
1.5.2.3.
Quem Possui Qualidade? __________________________________ 29
1.5.2.4.
Conceitos Errneos Comuns sobre Qualidade __________________ 30
1.5.2.5.
A qualidade pode ser acrescentada ou "testada" em um produto ____ 31
1.5.2.6.
A qualidade uma nica dimenso, um atributo ou uma caracterstica e
significa o mesmo para todos _________________________________________ 31
1.5.2.7.
A qualidade acontece sozinha_______________________________ 32
2


1.5.2.8.
Gerenciamento de Qualidade no RUP ________________________
1.6.
Gerencie Mudanas ______________________________________________
1.6.1.
Coordenao de Atividades e de Artefatos ________________________
1.6.2.
Coordenao de Iteraes e de Releases __________________________
1.6.3.
Controle de Mudanas no Software ______________________________
Anexo I ________________________________________________________________
32
35
35
36
36
37


1. Melhores Prticas
O Rational Unified Process (RUP) mostra como possvel aplicar as

melhores prticas de engenharia de software e usar ferramentas para automatizar
o processo de engenharia de software.


1.1. Desenvolva Iterativamente
Para diminuir os riscos, desenvolva gradativamente de modo iterativo. Cada

iterao resulta em um release executvel.
1.1.1. O que o Desenvolvimento Iterativo?
Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que
consiste em vrias iteraes. Uma iterao incorpora um conjunto quase
seqencial de atividades em modelagem de negcios, requisitos, anlise e design,
implementao, teste e implantao, em vrias propores, dependendo do local
em que ela est localizada no ciclo de desenvolvimento. As iteraes nas fases de
iniciao e de elaborao se concentram nas atividades de gerenciamento,
requisitos e design. As iteraes na fase de construo se concentram no design,
na implementao e no teste. E as iteraes na fase de transio e concentram no
teste e na implantao. O gerenciamento das iteraes deve ser do tipo timebox1,
1
(1) [timebox
A abordagem ao gerenciamento da programao de uma iterao recomendada no RUP: tendo estabelecido

inicialmente o escopo e a programao de uma iterao, o gerente de projeto incentivado a gerenciar de
forma ativa esse escopo (e os recursos confirmados para a iterao), a fim de cumprir a data final planejada
para a iterao, em vez de adi-la para acomodar o escopo planejado originalmente, caso o desenvolvimento
leve mais tempo que o imaginado. No RUP, prefervel reduzir o escopo do que adicionar recursos para
gerenciar uma programao adiada. So duas as motivaes para essa abordagem: tornar os resultados de uma
iterao visveis para os envolvidos e avaliar a iterao, para que as lies aprendidas possam ser aplicadas a
iteraes posteriores. ]


isto , a programao de uma iterao deve ser considerada fixa e o escopo do

contedo da iterao gerenciado ativamente para atender a essa programao.
1.1.2. Por que Desenvolver Iterativamente?

provvel que um design inicial contenha falhas em relao a seus
principais requisitos. A descoberta tardia dos defeitos de design resulta em
saturaes caras e, em alguns casos, at mesmo no cancelamento do projeto.
Todos os projetos tm um conjunto de riscos envolvidos. Quanto mais cedo
voc puder verificar que evitou um risco no ciclo de vida, mais precisos sero seus
planos. Muitos riscos nem so descobertos at que voc tente integrar o sistema.
impossvel prever todos eles, por mais experiente que seja a equipe de
desenvolvimento.
Em um ciclo de vida em cascata, voc no poder verificar se ficou livre de

um risco at o final do ciclo.


Em um ciclo de vida iterativo, a seleo do incremento a ser desenvolvido

em uma iterao feita com base em uma lista dos principais riscos. Como a
iterao produz um executvel testado, voc poder verificar os riscos diminuirem.
1.1.3. Vantagens de uma Abordagem Iterativa

Geralmente, uma abordagem iterativa superior a uma abordagem linear ou
em cascata, por vrios motivos.
Os riscos so reduzidos mais cedo, pois os elementos so integrados

progressivamente.
As tticas e os requisitos variveis so acomodados.
A melhoria e o refinamento do produto so facilitados, resultando em um

produto mais robusto.
As organizaes podem aprender a partir dessa abordagem e melhorar

seus processos.
A capacidade de reutilizao aumenta.

Uma vez, um cliente disse: "Com a abordagem em cascata, tudo parece
bem at quase no final do projeto; s vezes, at a metade da integrao. A, tudo


desmorona. Com a abordagem iterativa, muito difcil esconder a verdade durante

muito tempo."
Geralmente, os gerentes de projeto resistem abordagem iterativa, pois
consideram-na um infindvel refinamento. No Rational Unified Process (RUP), a
abordagem interativa muito controlada; o nmero, a durao e o objetivo das
iteraes so planejados. As tarefas e as responsabilidades dos participantes so
definidas. So capturadas medidas de progresso objetivas. Ocorre algum
retrabalho de uma iterao para a outra, mas isso tambm cuidadosamente
controlado.
1.1.3.1.
Diminuio de riscos
Uma abordagem iterativa permite que voc diminua os riscos mais cedo,
pois muitos deles so descobertos somente durante a integrao. Durante a
iterao inicial, voc verifica todas as disciplinas, considerando muitos aspectos
do projeto: ferramentas, softwares desenvolvidos internamente e adquiridos
prontos para serem usados, habilidades das pessoas e assim por diante. Pode ser
que riscos aparentes demonstrem que no so riscos, e riscos novos e
inesperados aparecero.
A integrao no um "big bang" no final; os elementos so incorporados
progressivamente. Na realidade, a abordagem iterativa uma integrao quase
contnua. O que costumava ser um perodo longo, incerto e difcil, que levava at
40% do esforo total no final de um projeto, e o que dificultava a preciso do
planejamento dividido em seis a nove integraes menores, que iniciam com um
nmero muito menor de elementos a serem integrados.
1.1.3.2.
Acomodao de mudanas
A abordagem iterativa permite que voc considere os requisitos variveis, j

que eles normalmente sero alterados durante o processo.


As mudanas efetuadas nos requisitos e a forma lenta como eles so

levantados tm sido sempre as principais fontes de problemas para um projeto,
levando a liberao depois do prazo, programaes atrasadas, clientes
insatisfeitos e desenvolvedores frustrados. H vinte e cinco anos, Fred Brooks
escreveu: "Planeje jogar algo fora; voc ir, de qualquer maneira." Os usurios
mudaro de idia durante o processo. Essa a natureza humana. Forar os
usurios a aceitarem o sistema como o imaginaram originalmente est errado.
Eles mudam de idia porque o contexto est sendo alterado; eles aprendem mais
sobre o ambiente e a tecnologia e enxergam uma demonstrao intermediria do
produto durante o seu desenvolvimento.
Um ciclo de vida iterativo fornece o gerenciamento com um modo de fazer
mudanas tticas no produto. Por exemplo, para competir com os produtos
existentes, voc poder decidir lanar um produto com funcionalidade reduzida
mais cedo como reao a uma movimentao de um concorrente ou poder
adotar um outro fornecedor de uma determinada tecnologia.
A iterao tambm permite mudanas tecnolgicas durante o processo. Se
alguma tecnologia alterada ou se torna um padro conforme aparece uma nova,
o projeto poder aproveit-la. Particularmente, esse o caso de mudanas de
plataforma e de infra-estrutura de nvel inferior.
1.1.3.3.
Busca de melhor qualidade
Uma abordagem iterativa resulta em uma arquitetura mais robusta, pois os

erros so corrigidos aps vrias iteraes. As falhas iniciais so detectadas
conforme o produto amadurece, durante as iteraes iniciais. Os gargalos de
desempenho so descobertos e podem ser reduzidos, em vez de aparecerem na
vspera da liberao.
Desenvolver iterativamente, ao contrrio de executar testes uma vez ao final
do projeto, resulta em um produto totalmente testado. Houve muitas oportunidades


para testar as funes crticas aps vrias iteraes, e os prprios testes, alm
dos softwares de teste, tiveram tempo para amadurecer.
1.1.3.4.
Aprendizado e melhoria
Os desenvolvedores podem aprender durante o processo, e as vrias

capacidades e especialidades so empregadas mais completamente durante todo
o ciclo de vida.
Em vez de esperar muito tempo simplesmente fazendo planos e aprimorando
suas habilidades, os testadores comeam a testar cedo, a escrita tcnica comea
cedo e assim por diante. A necessidade de treinamento adicional ou de ajuda
externa pode ser detectada nas revises de avaliao das iteraes iniciais.
O prprio processo pode ser melhorado e refinado durante o seu
desenvolvimento. A avaliao ao final de uma iterao no considera apenas o
status do projeto de uma perspectiva de programao do produto, mas tambm
analisa o que precisa ser alterado na organizao e no processo para melhorar o
desempenho na prxima iterao.
1.1.3.5.
Aumento de reutilizao
Um ciclo de vida iterativo facilita a reutilizao. Identificar as partes comuns

quando esto parcialmente projetadas ou implementadas mais fcil que
identificar todas as semelhanas no incio.
difcil identificar e desenvolver partes reutilizveis. As revises de design
nas iteraes iniciais possibilitam que os arquitetos de software identifiquem
reutilizaes inesperadas e potenciais, e as iteraes subseqentes permitem que
eles desenvolvam e amaduream posteriormente esse cdigo comum.
O uso de uma abordagem iterativa facilita o aproveitamento dos produtos
desenvolvidos internamente e adquiridos prontos para serem usados. Voc ter
vrias iteraes para selecion-los, integr-los e confirmar que eles so
adequados arquitetura.
10


1.2. Gerencie Requisitos

1.2.1. O que o Gerenciamento de Requisitos?
O gerenciamento de requisitos uma abordagem sistemtica para localizar,
documentar, organizar e controlar os requisitos variveis em um sistema.
Definimos um requisito como "uma condio ou uma capacidade com a
qual o sistema dever estar em conformidade".
O gerenciamento de requisitos definido formalmente como uma
abordagem sistemtica a:
identificar, organizar e documentar os requisitos do sistema;
firmar e atualizar acordos entre o cliente e a equipe do projeto sobre
os requisitos variveis do sistema.
As chaves para o gerenciamento eficaz de requisitos incluem manter uma
sentena clara dos requisitos, junto com os atributos aplicveis e a rastreabilidade
para outros requisitos e outros artefatos do projeto.
A coleta de requisitos pode parecer uma tarefa bem precisa. Na realidade,
porm, os projetos enfrentam dificuldades pelos seguintes motivos:
Nem sempre os requisitos so bvios e podem vir de vrias fontes.
Os requisitos nem sempre so expressos em palavras de modo fcil
ou claro.
Existem diversos tipos de requisitos em diferentes nveis de detalhe.
O nmero de requisitos pode se tornar impossvel de gerenciar se
eles no forem controlados.
Os requisitos esto relacionados uns com os outros, e tambm com
o produto liberado do processo de engenharia do software.
Os
requisitos
tm
propriedades
exclusivas
ou
valores
de
propriedade. Por exemplo, eles no so necessariamente igualmente

importantes ou igualmente fceis de se atender.
11


H vrias partes interessadas, o que significa que os requisitos

precisam ser gerenciados por grupos de pessoas de diferentes
funes.
Os requisitos so alterados.
Ento, que habilidades voc precisa desenvolver em sua organizao para
ajud-lo a gerenciar essas dificuldades? Aprendemos que as seguintes
habilidades so importantes para o gerenciamento:
Anlise do problema;
Noes bsicas sobre as necessidades dos envolvidos;
Definio do sistema;
Gerenciamento do escopo do projeto;
Refinamento da definio do sistema;
Gerenciamento dos requisitos variveis.
1.2.1.1.
Anlise do problema
Essa anlise feita para o entendimento dos problemas e das

necessidades iniciais dos envolvidos e para que sejam propostas solues de alto
nvel. um ato de raciocnio e de anlise para localizar "o problema por trs do
problema". Durante a anlise, so estabelecidos os problemas reais e quem so
os envolvidos. Do ponto de vista negcios, voc tambm define as fronteiras da
soluo e as restries de negcios dessa soluo. O caso de negcio do projeto
tambm precisa ser analisado, para que haja um bom entendimento do retorno
esperado sobre o investimento feito no sistema que est sendo criado.
Consulte o Detalhamento do Fluxo de Trabalho: Analisar o Problema na
disciplina Requisitos para obter mais informaes sobre este tpico.
12
1.2.1.2.


Noes bsicas sobre as necessidades dos envolvidos
Os requisitos chegam de vrias fontes; por exemplo, clientes, parceiros,

usurios e especialistas em domnios. Voc precisa saber determinar quais
deveriam ser as melhores fontes, como acess-las e como levantar informaes
nelas de modo eficaz. Os indivduos que fornecem as principais fontes dessas
informaes so denominados envolvidos no projeto.
Se voc estiver desenvolvendo um sistema de informaes que ser usado
internamente em sua empresa, poder incluir pessoas com experincia de usurio
e
especializao
em
domnios
na
equipe
de
desenvolvimento.
Muito
freqentemente, voc iniciar as discusses no nvel de modelo de negcios e

no no nvel de sistema. Se estiver desenvolvendo um produto que ser vendido
para um mercado especfico, voc poder usar amplamente a equipe de
marketing para entender melhor as necessidades dos clientes naquele mercado.
O levantamento de informaes pode ocorrer atravs de tcnicas como
entrevistas, discusso de idias, prottipos conceituais, questionrios e anlise
competitiva. O resultado uma lista de solicitaes ou de necessidades descritas
em forma de texto e de grficos e que recebem uma prioridade entre si.
1.2.1.3.
Definio do sistema
Definir o sistema significa converter e organizar o entendimento das

necessidades dos envolvidos em uma descrio significativa do sistema a ser
criado. No incio da definio do sistema, so tomadas decises sobre o que
constitui um requisito, o formato da documentao, a formalidade da linguagem, o
grau de especificao dos requisitos (quantos e com qual detalhamento), a
prioridade das solicitaes e o esforo estimado (duas avaliaes muito diferentes,
geralmente determinadas por pessoas distintas em exerccios separados), os
riscos tcnicos e de gerenciamento e o escopo inicial. Parte dessa atividade pode
incluir modelos de design e prottipos iniciais diretamente relacionados aos mais
13


importantes requisitos dos envolvidos. O resultado da definio uma descrio

do sistema que usa as representaes em linguagem natural e grfica.
1.2.1.4.
Gerenciamento do escopo do projeto
Para executar um projeto de modo eficiente, necessrio priorizar

cuidadosamente os requisitos com base nas informaes recebidas de todos os
envolvidos e gerenciar esse escopo. Muitos projetos so prejudicados devido a
desenvolvedores
ocupados
em
criar
os
chamados
"Ovos
de
pscoa"
(caractersticas que o desenvolvedor acha interessantes e desafiadoras), em vez

de se concentrar desde o incio em tarefas que diminuem um risco de projeto ou
estabilizam a arquitetura da aplicao. Certifique-se de resolver ou diminuir os
riscos em um projeto o mais cedo possvel, desenvolvendo o sistema
gradativamente e escolhendo cuidadosamente os requisitos para cada incremento
que diminui os riscos conhecidos. Isso significa que voc precisa negociar o
escopo de cada iterao com os envolvidos no projeto. Geralmente, isso exige
uma boa capacidade de gerenciamento das expectativas da sada do projeto em
suas diferentes fases. Tambm necessrio controlar as fontes dos requisitos, a
aparncia dos produtos liberados do projeto e o prprio processo de
desenvolvimento.
1.2.1.5.
Refinamento da definio do sistema
A definio detalhada do sistema precisa ser apresentada de maneira que

os envolvidos possam entend-la, concordar com ela e sair dela. Ela precisa
abordar no apenas a funcionalidade, mas tambm a compatibilidade com os
requisitos legais ou reguladores, a usabilidade, a confiabilidade, o desempenho, a
capacidade de suporte e de manuteno. Um erro freqente acreditar que o que
voc sente que difcil criar precisa ter uma definio complexa. Isso cria
dificuldades para explicar a finalidade do projeto e do sistema. As pessoas podem
ficar impressionadas, mas no daro boas contribuies porque no entendem.
necessrio dar mais ateno ao entendimento do pblico para o qual os artefatos
14


esto sendo produzidos; geralmente, so necessrios diferentes tipos de

descrio para pblicos distintos.
Vimos que a metodologia de casos de uso, geralmente em combinao
com prottipos visuais simples, uma maneira muito eficiente de comunicar a
finalidade e de definir os detalhes do sistema. Os casos de uso ajudam a inserir os
requisitos em um contexto; eles ilustram o modo como o sistema ser usado.
Outro componente da definio detalhada do sistema estabelecer como o
sistema dever ser testado. Os planos de teste e as definies dos testes a serem
executados indicam os recursos do sistema que sero verificados.
1.2.1.6.
Gerenciamento dos requisitos variveis
Por mais que voc tenha cuidado ao definir os requisitos, sempre haver
itens que so alterados. O que torna complexo o gerenciamento dos requisitos
variveis no apenas o fato de que um requisito alterado significa a necessidade
de gastar tempo com a implementao de uma nova caracterstica especfica, mas
tambm que uma mudana em um requisito poder ter impacto em outros. Voc
precisa garantir que os requisitos recebero uma estrutura que aceite bem as
mudanas e usar links de rastreabilidade para representar as dependncias entre
os requisitos e outros artefatos do ciclo de vida do desenvolvimento. O
gerenciamento de mudanas inclui atividades como: estabelecer uma baseline,
determinar as dependncias importantes a serem rastreadas, estabelecer a
rastreabilidade entre itens relacionados e implementar o controle de mudanas.
15


1.2.2. Como o Desenvolvimento Baseado em Casos de Uso?

Recomendamos a utilizao dos casos de uso como mtodo para a
organizao dos requisitos funcionais. Em vez de fazer uma lista de requisitos
com marcadores, organize-os de forma que ilustrem o modo como uma pessoa
poder usar o sistema. Isso permite maior abrangncia e consistncia e tambm
fornece um melhor entendimento da importncia de um requisito do ponto de vista
do usurio.
A partir de um modelo de sistema tradicional orientado a objetos,
geralmente difcil definir como um sistema faz o que se espera que ele faa.
Essa dificuldade resulta da falta de um "thread vermelho" atravs do sistema
quando executa certas tarefas. No Rational Unified Process (RUP), os casos de
uso so essa linha, pois definem o comportamento de um sistema. Eles no fazem
parte da orientao a objetos tradicional, mas sua importncia se tornou ainda
mais evidente. Isso mais enfatizado ainda pelo fato de que os casos de uso
fazem parte da Linguagem Unificada de Modelagem.
O RUP emprega uma "abordagem baseada em casos de uso", o que
significa que os casos de uso definidos para um sistema so a base de todo o
processo de desenvolvimento.
Os casos de uso fazem parte de vrias disciplinas.
O conceito de casos de uso pode ser usado para representar
processos de negcios, conforme definido na disciplina modelagem
de negcios. Essa variante de caso de uso denominada "caso de
uso de negcios".
O modelo de caso de uso um dos principais artefatos resultantes
da disciplina requisitos. Os casos de uso criam um modelo para
identificar o que o sistema precisa fazer do ponto de vista do usurio.
Os casos de uso constituem um conceito fundamental importante
que precisa ser aceitvel para o cliente, para os desenvolvedores e
para os testadores do sistema.
16


Em anlise e design, os casos de uso so realizados em um modelo

de design. Voc pode criar realizaes de casos de uso, que
descrevem como os casos de uso so suportados pelo design no
que se refere interao de objetos no modelo de design. Esse
modelo descreve, em termos de objetos de design, as diferentes
partes do sistema que dever ser implementado e como elas
precisam interagir para suportar os casos de uso necessrios.
Durante a implementao, o modelo de design atua como a
especificao da implementao. Como os casos de uso so a base
do modelo de design, eles so implementados em relao s classes
de design de colaborao.
Durante o teste, os casos de uso fornecem os cenrios necessrios
que compem a principal base para identificao funcional de
cenrios de teste. Esses cenrios de teste so usados para originar
casos de teste e scripts de teste; a funcionalidade do sistema
verificada executando cenrios de teste que experimentam cada
caso de uso.
Na disciplina Gerenciamento de Projeto, os casos de uso so usados
como base para planejar o desenvolvimento iterativo.
Na disciplina Implantao, os casos de uso formam uma base para o
que est descrito nos manuais do usurio. Eles tambm podem ser
usados para definir as unidades de pedido do produto. Por exemplo,
um cliente pode obter um sistema configurado com uma combinao
especfica de casos de uso.
17


1.3. Use Arquiteturas de Componentes
Arquitetura baseada em componentes com camadas
1.3.1. O que significa Arquitetura de Componentes?

Os componentes so grupos de cdigo coesos, na forma de cdigo fonte ou
executvel, com interfaces bem definidas e comportamentos que fornecem forte
encapsulamento do contedo e so, portanto, substituveis. As arquiteturas
baseadas em componentes tendem a reduzir o tamanho efetivo e a complexidade
da soluo e, portanto, so mais robustas e flexveis.
1.3.2. nfase Arquitetural

Os casos de uso orientam o Rational Unified Process (RUP) durante todo o
ciclo de vida, mas as atividades de design so centralizadas na noo da
arquitetura do sistema e em sistemas intensivos de software, arquitetura de
software. O foco principal das iteraes iniciais do processo, principalmente na
fase de elaborao, produzir e validar uma arquitetura de software2, que no ciclo
A arquitetura de software abrange:
as decises significativas sobre a organizao de um sistema de software

18


de desenvolvimento inicial toma a forma de um prottipo arquitetural executvel

que gradualmente evolui at se tornar o sistema final em iteraes posteriores.
Arquitetura executvel significa uma implementao parcial do sistema criada para
demonstrar funes e propriedades selecionadas do sistema, em particular
aquelas que satisfazem requisitos no funcionais. A finalidade da arquitetura
executvel diminuir os riscos relacionados a desempenho, taxa de transferncia,
capacidade, confiabilidade, etc. para que a capacidade funcional completa do
sistema possa ser adicionada na fase de construo3 de uma forma segura, sem
perigo de quebra.
O RUP fornece uma maneira metdica e sistemtica de projetar,
desenvolver e validar uma arquitetura. Oferecemos templates para descrio da
arquitetura, com os conceitos de vrias vises arquiteturais, e para a captura de
estilo de arquitetura, regras de design e restries. A disciplina Anlise e Design
contm atividades especficas orientadas para identificar restries arquiteturais e
para elementos significativos na arquitetura, alm de diretrizes sobre como fazer
escolhas
arquiteturais.
processo
de
gerenciamento
mostra
como
planejamento das iteraes iniciais considera o design de uma arquitetura e a

resoluo dos principais riscos tcnicos.
a seleo dos elementos estruturais e das interfaces atravs das quais o

sistema composto em conjunto com o comportamento, como especificado
na colaborao entre esses elementos
a composio dos elementos estruturais e comportamentais em subsistemas
progressivamente maiores
o estilo de arquitetura que guia essa organizao, esses elementos e suas
interfaces, suas colaboraes e sua composio
A arquitetura de software no diz respeito apenas a estrutura e comportamento, mas tambm a uso,
funcionalidade, desempenho, flexibilidade, reutilizao, abrangncia, restries tecnolgicas e econmicas,
trocas e esttica.
3
construo
a terceira fase do Processo Unificado, na qual o software trazido de uma
baseline arquitetural executvel para o ponto no qual est pronto para ser
transferido para a comunidade de usurios.
19


A arquitetura importante por vrios motivos:

Ela permite obter e manter controle intelectual do projeto,
gerenciar sua complexidade e manter a integridade do
sistema.
Um sistema complexo mais que a soma de suas partes; mais que uma
sucesso de pequenas decises tticas independentes. Ele precisa ter uma
estrutura unificadora e coerente para organizar essas partes de modo sistemtico
e fornecer regras precisas sobre como pode ser aumentado, sem que sua
complexidade cresa alm da compreenso humana.
A arquitetura determina os meios para se obter melhor comunicao e
entendimento em todo o projeto, estabelecendo um conjunto de referncias e um
vocabulrio comuns, com os quais se discutem questes de design.
uma base efetiva para reutilizao em larga escala.
Ao articular claramente os principais componentes e as interfaces crticas
entre eles, uma arquitetura permite que voc raciocine sobre a reutilizao, tanto a
reutilizao interna que a identificao das partes comuns, como a reutilizao
externa que a incorporao de componentes desenvolvidos internamente e
adquiridos prontos para serem usados. No entanto, tambm permite a reutilizao
em uma escala maior: a reutilizao da prpria arquitetura, no contexto de uma
linha de produtos que aborda funcionalidades diferentes em um domnio comum.
Ela fornece uma base para gerenciamento de projeto.
Planejamento e formao de equipe esto organizados de acordo com os
principais componentes. Decises estruturais fundamentais so tomadas por uma
equipe pequena e coesa de arquitetura. Elas no so distribudas. O
20


desenvolvimento dividido entre um conjunto de equipes pequenas, cada uma

sendo responsvel por uma ou vrias partes do sistema.
1.3.3. Desenvolvimento Baseado em Componentes
Um componente de software pode ser definido como um pedao no-trivial
de software, um mdulo, um pacote ou um subsistema, sendo que todos
desempenham uma funo clara, possuem uma fronteira clara e podem ser
integrados em uma arquitetura bem definida. a realizao fsica de uma
abstrao do design.
Os componentes vm de diferentes lugares:
Ao definir uma arquitetura muito modular, voc identifica, isola,
projeta, desenvolve e testa componentes bem formados. Esses
componentes podem ser testados individualmente e gradualmente
integrados para formar o sistema inteiro.
Alm disso, alguns desses componentes podem ser desenvolvidos
para serem reutilizveis, especialmente os componentes que
fornecem solues comuns para uma ampla variedade de problemas
comuns. Esses componentes reutilizveis, que podem ser maiores
que apenas conjuntos de utilitrios ou de bibliotecas de classes,
formam a base de reutilizao dentro de uma organizao,
aumentando a produtividade e a qualidade geral do software.
Mais recentemente, o advento das infra-estruturas de componentes
comercialmente bem-sucedidas, como CORBA, a Internet, ActiveX e
JavaBeans, desencadeou uma indstria completa de componentes
desenvolvidos internamente e adquiridos prontos para serem usados
para vrios domnios, permitindo comprar e integrar componentes,
em vez de desenvolv-los internamente.
O primeiro ponto na lista precedente explora os conceitos antigos de
modularidade e de encapsulamento, tornando ainda mais importantes os
21


conceitos subjacentes tecnologia orientada a objetos. Os ltimos dois pontos da

lista alteram o desenvolvimento de software da programao: de uma linha por
vez para a composio do software atravs da montagem de componentes.
O RUP suporta desenvolvimento baseado em componentes destas
maneiras:
A
abordagem
iterativa
permite
identificar
componentes
progressivamente e decidir quais desenvolver, quais reutilizar e

quais comprar.
O foco na arquitetura de software permite montar a estrutura, os
componentes e como eles se integram, incluindo os padres e os
mecanismos fundamentais atravs dos quais eles interagem.
Conceitos como pacotes, subsistemas e camadas so utilizados
durante a disciplina Anlise e Design para organizar componentes e
especificar interfaces.
Os testes so primeiramente organizados em componentes e, em
seguida, em conjuntos maiores de componentes integrados.
22


1.4. Modele Visualmente (UML)
A modelagem visual aumenta o nvel de abstrao
1.4.1. O que Modelagem Visual?

A modelagem visual o uso de notaes de design grficas e textuais,
semanticamente ricas, para capturar designs de software. Uma notao, como a
UML, permite que o nvel de abstrao seja aumentado, enquanto mantm sintaxe
e semntica rgidas. Dessa maneira, a comunicao na equipe de design melhora,
medida que o design formado e revisado, permitindo ao leitor raciocinar sobre
ele e fornecendo uma base no ambgua para a implementao.
1.4.2. Por que Modelamos?

Um modelo uma viso simplificada de um sistema. Ele mostra os
elementos essenciais do sistema de uma perspectiva especfica e oculta os
detalhes no essenciais. Os modelos podem ajudar das seguintes maneiras:
ajudando na compreenso de sistemas complexos;
explorando e comparando alternativas de design a um baixo custo;
formando uma base para implementao;
capturando requisitos com preciso;
comunicando decises sem ambigidade.
23
1.4.2.1.


Ajuda na compreenso de sistemas complexos
A importncia dos modelos aumenta medida que os sistemas se tornam

mais complexos. Por exemplo, um canil pode ser construdo sem um projeto. No
entanto, medida que evolumos para a construo de casas e, em seguida, para
arranha-cus, a necessidade de um projeto se torna evidente.
De maneira semelhante, um aplicativo pequeno, criado por uma nica
pessoa em alguns dias, pode ser facilmente compreendido em sua totalidade. No
entanto, um sistema de comrcio eletrnico com dezenas de milhares de linhas de
cdigo-fonte, ou um sistema de controle de trfego areo de centenas de milhares
de linhas de cdigo, no pode mais ser facilmente entendido por uma nica
pessoa. A construo de modelos permite a um desenvolvedor se concentrar na
viso geral, entender como os componentes interagem e identificar falhas fatais.
Alguns exemplos de modelos so:
Casos de Uso para especificar comportamento de forma no
ambgua;
Diagramas de Classes e Diagramas de Modelo de Dados para
capturar design;
Diagramas de Transio de Estado para modelar comportamento
dinmico.
A modelagem importante, pois ajuda a equipe a visualizar, construir e
documentar a estrutura e o comportamento do sistema, sem se perder na
complexidade.
24
1.4.2.2.
custo


Explorao e comparao de alternativas de design a um baixo
Modelos simples podem ser criados e modificados a um baixo custo para

explorar alternativas de design. Idias inovadoras podem ser capturadas e
revisadas por outros desenvolvedores, antes de investir em um desenvolvimento
de cdigo caro. Quando associada ao desenvolvimento iterativo, a modelagem
visual ajuda os desenvolvedores a avaliar mudanas de design e a comunicar
essas mudanas a toda a equipe de desenvolvimento.
1.4.2.3.
Formao de uma base para implementao
Atualmente, muitos projetos empregam linguagens de programao

orientadas a objetos para obter sistemas reutilizveis, tolerantes a mudanas e
estveis. Para obter essas vantagens, ainda mais importante usar tecnologia de
objetos em design. O Rational Unified Process (RUP) produz um modelo de
design orientado a objetos que a base para a implementao.
Com o suporte das ferramentas adequadas, um modelo de design pode ser
usado para gerar um conjunto inicial de cdigo para implementao. Isso
referido como "engenharia direta" ou "gerao de cdigo". Os modelos de design
tambm podem ser aprimorados para incluir informaes suficientes para criar o
sistema.
A engenharia reversa tambm pode ser aplicada para gerar modelos de
design a partir de implementaes existentes. Isso pode ser usado para avaliar
implementaes existentes.
"A engenharia round-trip" combina as tcnicas de engenharia direta e
reversa para garantir cdigo e design consistentes. Combinada com um processo
iterativo e com as ferramentas certas, a engenharia round-trip permite que o
cdigo e o design sejam sincronizados durante cada iterao.
25
1.4.2.4.


Captura de requisitos com preciso
Antes de criar um sistema, essencial capturar os requisitos.
especificao dos requisitos usando um modelo preciso e no ambguo ajuda a

garantir que todos os envolvidos possam entender e concordar com os
requisitos.
Um modelo que separa o comportamento externo do sistema da
implementao o ajuda a se concentrar no uso pretendido do sistema, sem ficar
perdido nos detalhes de implementao.
1.4.2.5.
Comunicao de decises sem ambigidade
O RUP usa a Linguagem Unificada de Modelagem (UML), uma notao

consistente que pode ser aplicada engenharia de sistemas e engenharia de
negcios. Uma notao padro serve aos seguintes papis (consulte [BOO95]):
"Serve como uma linguagem para comunicar decises que no so
bvias ou que no podem ser deduzidas do prprio cdigo."
"Fornece semntica rica o suficiente para capturar todas as decises
estratgicas e tticas importantes."
"Oferece uma forma concreta o suficiente para que as pessoas
raciocinem e para que as ferramentas sejam manipuladas."
UML representa a convergncia da melhor prtica em modelagem de
software por toda a indstria de tecnologia de objetos.
Para obter mais
informaes
na
sobre
UML,
visite
nosso
site
Web
em
http://www.rational.com/uml.
26


1.5. Verifique Qualidade Continuamente
A localizao e a soluo dos problemas de software ficam de 100 a 1.000

vezes mais caros, se realizados aps a implantao. A verificao e o
gerenciamento da qualidade durante o ciclo de vida do projeto essencial para
atingir os objetivos corretos no momento certo.
Tpicos
O que Significa Verificao da Qualidade Durante o Ciclo de Vida?
O que Qualidade?
o Introduo
o Definio de Qualidade
o Quem Possui Qualidade?
o Concepes Errneas Comuns sobre Qualidade
o Gerenciamento de Qualidade no RUP
1.5.1. O que Significa Verificao da Qualidade Durante o Ciclo de Vida?

importante que a qualidade de todos os artefatos seja avaliada em vrios
pontos no ciclo de vida do projeto, medida que eles amadurecem. Os artefatos
devem ser avaliados medida que as atividades que os produzem so concludas
e na concluso de cada iterao. Especificamente, medida que o software
executvel produzido, ele deve ser submetido demonstrao e teste de
cenrios importantes em cada iterao, o que fornecer uma compreenso mais
27


real das trocas de design e da eliminao antecipada de defeitos de arquitetura.

Isso contrasta com uma abordagem mais tradicional, que deixa o teste integrado
do software para mais tarde, no ciclo de vida do projeto.
1.5.2. O que Qualidade?

1.5.2.1.
Introduo
A qualidade algo pelo qual nos esforamos para obter nos produtos,
processos e servios. Ainda assim, quando perguntados, "O que Qualidade?",
todos possuem uma opinio diferente. As respostas mais comuns incluem uma ou
outra destas opes:
"Qualidade ... No tenho certeza de como descrev-la, mas saberei
quando v-la."
"... atendimento de requisitos."
Talvez
referncia
mais
freqente
qualidade,
relacionada
especificamente ao software, seja este comentrio com relao sua ausncia:

"Como puderam lanar algo assim, com uma qualidade to baixa!?"
Essas respostas comuns so significativas, mas oferecem muito pouco para
um exame rigoroso da qualidade e para melhorar sua execuo. Todos esses
comentrios ilustram a necessidade de definir a qualidade de maneira que ela
possa ser medida e alcanada.
A qualidade, no entanto, no um atributo ou uma caracterstica singular.
multidimensional e pode ser possuda por um produto ou por um processo. A
qualidade do produto est concentrada na criao do produto certo, enquanto a
qualidade do processo est concentrada na criao correta do produto.
28
1.5.2.2.


Definio de Qualidade
A definio de qualidade, no The American Heritage Dictionary of the

English Language, 3a edio, Houghton Mifflin Co., 1992, 1996, :
Qualidade s.f.., pl. Qualidades. 1.a. Uma caracterstica inerente ou
diferenciada; uma propriedade. b. Um trao pessoal, especialmente
um trao de carter. 2. Carter essencial; natureza. 3.a.
Superioridade de natureza. b. Grau ou classificao de excelncia.
Como demonstrado por essa definio, a qualidade no uma dimenso
nica, mas vrias. Para usar a definio e aplic-la ao desenvolvimento de
software, ela precisa ser refinada. Portanto, para as finalidades do Rational Unified
Process (RUP), a qualidade definida como:
"...a caracterstica de ter demonstrado a realizao da criao de um
produto que atende ou excede os requisitos acordados, conforme
avaliado por medidas e critrios acordados, e que criado em um
processo acordado."
Obter qualidade no simplesmente "atender a requisitos" ou produzir um
produto que atende s necessidades e expectativas dos usurios. Pelo contrrio,
a qualidade tambm inclui a identificao das medidas e dos critrios para
demonstrar a obteno da qualidade e a implementao de um processo para
garantir que o produto por ele criado tenha atingido o grau desejado de qualidade
e possa ser repetido e gerenciado.
1.5.2.3.
Quem Possui Qualidade?
Uma conceito errneo comum que a qualidade pertence a um grupo ou

responsabilidade dele. Geralmente, esse mito perpetuado pela criao de um
grupo, algumas vezes denominado Garantia de Qualidade, outros nomes incluem
29


Teste, Controle de Qualidade e Engenharia de Qualidade, e dando a eles a

misso e a responsabilidade relacionada qualidade.
A qualidade , e deve ser, responsabilidade de todos. Obter qualidade deve
ser inerente a quase todas as atividades do processo, em vez de uma disciplina
separada, tornando, portanto, todos responsveis pela qualidade dos produtos (ou
artefatos) que criam e pela implementao do processo no qual esto envolvidos.
Cada papel contribui para a obteno da qualidade das seguintes maneiras:
Qualidade do produtoa contribuio para a obteno geral da
qualidade em cada artefato que est sendo produzido.
Qualidade do processoa obteno da qualidade nas atividades do
processo em que eles esto envolvidos.
Todos compartilham a responsabilidade e a glria de obter um produto de
alta qualidade ou a vergonha de um produto de baixa qualidade. Mas somente
aqueles diretamente envolvidos em um componente especfico do processo so
responsveis pela glria ou vergonha da qualidade desses componentes do
processo (e dos artefatos). Algum, no entanto, deve ter a responsabilidade de
gerenciar a qualidade, ou seja, fornecer a superviso para garantir que a
qualidade esteja sendo gerenciada, medida e obtida. O papel responsvel por
gerenciar a qualidade o Gerente de Projeto.
1.5.2.4.
Conceitos Errneos Comuns sobre Qualidade
Existem muitos conceitos errneos com relao qualidade e os mais

comuns incluem:
A qualidade pode ser acrescentada ou "testada" em um produto;
A qualidade uma nica dimenso, um atributo ou uma
caracterstica e significa o mesmo para todos;
A qualidade acontece sozinha.
30
1.5.2.5.


A qualidade pode ser acrescentada ou "testada" em um produto
Da mesma maneira que um produto no pode ser produzido se no houver

uma descrio do que ele , do que precisa fazer, de quem o usa, de como ele
usado e assim por diante, no ser possvel obter qualidade se ela no for
descrita, medida e fizer parte do processo de criao do produto.
1.5.2.6.
A qualidade uma nica dimenso, um atributo ou uma
caracterstica e significa o mesmo para todos
A qualidade no uma nica dimenso, um atributo ou uma caracterstica.
A qualidade medida de vrias maneiras; as mtricas e os critrios de qualidade
so estabelecidos para atender s necessidades do projeto, da organizao e do
cliente.
A qualidade pode ser medida juntamente com vrias dimenses; algumas
se aplicam qualidade do processo, outras qualidade do produto e algumas s
duas. A qualidade pode ser medida para:
Andamento como casos de uso demonstrados ou marcos
concludos
Variao diferenas entre requisitos de formao de equipe,
oramentos, programaes reais e planejados e assim por diante
Confiabilidade resistncia falha (queda do sistema, parada do
sistema, perdas de memria e assim por diante) durante a execuo.
Funo o artefato implementa e executa os casos de uso
necessrios, conforme pretendido
Desempenho o artefato executa e responde de maneira aceitvel
e em tempo hbil, e continua a executar de maneira aceitvel,
quando submetido a caractersticas operacionais do mundo real,
como carga, stress e longos perodos de operao.
31
1.5.2.7.


A qualidade acontece sozinha
A qualidade no pode acontecer sozinha. Para obter qualidade, um

processo precisa ser implementado, estar de acordo com a meta e ser medido. A
finalidade do RUP fornecer uma abordagem disciplinada para atribuio de
tarefas e responsabilidades dentro de uma organizao de desenvolvimento.
Nossa meta garantir a produo de software de alta qualidade que atenda s
necessidades dos usurios, dentro de uma programao e um oramento
previsveis. O RUP captura muitas das melhores prticas de desenvolvimento de
software moderno, de forma que possa ser adaptado para um largo espectro de
projetos e organizaes. A disciplina Ambiente fornece orientaes sobre a melhor
maneira de configurar o processo de acordo com as suas necessidades.
Os processos podem ser configurados e os critrios de qualidade para
aceitabilidade podem ser negociados, com base em vrios fatores. Os fatores
mais comuns so:
Risco (incluindo responsabilidades)
Oportunidades de mercado
Requisitos de receita
Questes de programao ou formao de equipe
Oramentos
As mudanas no processo e nos critrios de aceitabilidade devem ser
identificadas e acordadas no incio do projeto.
1.5.2.8.
Gerenciamento de Qualidade no RUP
O gerenciamento de qualidade feito para estas finalidades:

Identificar
indicadores
adequados
(mtricas)
com
qualidade
aceitvel;
Identificar medidas adequadas a serem usadas na avaliao da
qualidade;
Identificar e abordar adequadamente questes que afetam a
qualidade o mais cedo e eficaz possvel.
32


O gerenciamento da qualidade implementado em todas as disciplinas,

fluxos de trabalho, fases e iteraes do RUP. Em geral, o gerenciamento da
qualidade durante o ciclo de vida significa que voc implementa, mede e avalia
tanto a qualidade do processo como a do produto. Alguns dos esforos gastos
para gerenciar a qualidade em cada disciplina esto realados na lista a seguir:
O gerenciamento de qualidade na disciplina Requisitos inclui a
anlise do conjunto de artefatos de requisitos em busca de
consistncia (entre padres de artefatos e outros artefatos), de
clareza (comunica as informaes claramente a todos os acionistas,
envolvidos e outros papis) e de preciso (o nvel adequado de
detalhe e preciso).
Na disciplina Anlise e Design , o gerenciamento da qualidade inclui
a avaliao do conjunto de artefatos de design, incluindo a
consistncia do modelo de design, sua converso a partir de
artefatos
de
requisitos
sua
converso
em
artefatos
de
implementao.
Na disciplina Implementao, o gerenciamento da qualidade inclui a
avaliao dos artefatos de implementao e a avaliao do cdigofonte ou dos artefatos executveis, com relao aos artefatos de
requisitos, de design e de teste adequados.
A disciplina Teste altamente centralizada no gerenciamento da
qualidade, uma vez que a maioria dos esforos gastos nessa
disciplina aborda as trs finalidades de gerenciamento de qualidade
identificadas anteriormente.
A disciplina Ambiente , como a disciplina Teste, inclui muitos
esforos de abordagem das finalidades de gerenciamento da
qualidade. Aqui possvel encontrar orientaes sobre como
configurar melhor o processo para atender s suas necessidades.
33


O gerenciamento da qualidade na disciplina Implantao inclui a

avaliao dos artefatos de implementao e de implantao e a
avaliao dos artefatos executveis e de implantao, com relao
aos artefatos adequados de requisito, de design e de teste
necessrios para fornecer o produto ao cliente.
A disciplina Gerenciamento de Projeto inclui uma viso geral de
vrios esforos de gerenciamento da qualidade, incluindo as
revises e as auditorias necessrias para avaliar a implementao, a
aderncia e o andamento do processo de desenvolvimento.
34


1.6. Gerencie Mudanas
O gerenciamento de mudanas mais do que simplesmente fazer check-in

e check-out nos arquivos. Ele inclui gerenciamento de espaos de trabalho,
desenvolvimento paralelo, integrao e builds.
Um desafio importante quando voc est desenvolvendo sistemas
intensivos de software lidar com vrios desenvolvedores, organizados em
diferentes equipes, possivelmente em diferentes locais, trabalhando juntos em
vrias iteraes, releases, produtos e plataformas. Na ausncia de controle
disciplinado, o processo de desenvolvimento rapidamente se transforma em caos.
Tpicos
Coordenao de Atividades e de Artefatos;
Coordenao de Iteraes e de Releases;
Controle de Mudanas no Software.
1.6.1. Coordenao de Atividades e de Artefatos
A coordenao das atividades e dos artefatos de desenvolvedores e de
equipes envolve o estabelecimento de procedimentos que podem ser repetidos
para o gerenciamento de mudanas no software e em outros artefatos de
desenvolvimento. Essa coordenao permite uma melhor alocao de recursos,
com base nas prioridades e nos riscos do projeto e ela gerencia ativamente o
trabalho dessas mudanas entre iteraes. Juntamente com o desenvolvimento do
35


software iterativamente, essa prtica permite que voc monitore as mudanas

continuamente, para poder descobrir ativamente e solucionar problemas.
1.6.2. Coordenao de Iteraes e de Releases

A coordenao de iteraes e de releases envolve o estabelecimento e a
liberao de uma baseline testada na concluso de cada iterao. A manuteno
da rastreabilidade entre os elementos de cada release e entre os elementos de
vrios releases paralelos essencial para avaliar e gerenciar ativamente o
impacto da mudana.
1.6.3. Controle de Mudanas no Software

O controle de mudanas no software oferece vrias solues para as
causas originais de problemas de desenvolvimento de software:
O fluxo de trabalho da mudana de requisitos definido e pode ser
repetido.
As solicitaes de mudana facilitam a comunicao clara.
Os espaos de trabalho isolados reduzem a interferncia entre
membros da equipe que trabalham em paralelo.
As estatsticas de taxa de mudanas fornecem mtricas satisfatrias
para avaliar objetivamente o status do projeto.
Os espaos de trabalho contm todos os artefatos, o que facilita a
consistncia.
A propagao da mudana pode ser avaliada e controlada.
As mudanas podem ser mantidas em um sistema robusto e
personalizvel.
36


Anexo I
RUP: Viso Geral
A figura acima mostra a arquitetura geral do RUP.

O Rational Unified Process (tambm chamado de processo RUP) um
processo de engenharia de software. Ele oferece uma abordagem baseada em
disciplinas para atribuir tarefas e responsabilidades dentro de uma organizao de
desenvolvimento. Sua meta garantir a produo de software de alta qualidade
que atenda s necessidades dos usurios dentro de cronograma e oramentos
previsveis.
O RUP tem duas dimenses:
37


o eixo horizontal representa o tempo e mostra os aspectos do ciclo

de vida do processo medida que se desenvolve.
o eixo vertical representa as disciplinas, que agrupam as atividades
de maneira lgica, por natureza.
A primeira dimenso representa o aspecto dinmico do processo quando
ele aprovado e expressa em termos de fases4, iteraes e marcos.
A segunda dimenso representa o aspecto esttico do processo, como ele
descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho,
artefatos e papis do processo.
O grfico mostra como a nfase varia atravs do tempo. Por exemplo, nas
iteraes iniciais, dedicamos mais tempo aos requisitos. J nas iteraes
posteriores, gastamos mais tempo com implementao.
A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do Rational Unified Process
(RUP) dividido em quatro fases seqenciais, cada uma concluda por um marco principal, ou seja, cada fase
basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase executada uma
avaliao para determinar se os objetivos da fase foram alcanados. Uma avaliao satisfatria permite que o
projeto passe para a prxima fase.
38

Melhores Praticas PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Melhores Praticas PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

Melhores Prticas _____________________________________________________ 4

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

O Rational Unified Process (RUP) mostra como possvel aplicar as

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

1.1. Desenvolva Iterativamente

Para diminuir os riscos, desenvolva gradativamente de modo iterativo. Cada

A abordagem ao gerenciamento da programao de uma iterao recomendada no RUP: tendo estabelecido

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

isto , a programao de uma iterao deve ser considerada fixa e o escopo do

1.1.2. Por que Desenvolver Iterativamente?

Em um ciclo de vida em cascata, voc no poder verificar se ficou livre de

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

Em um ciclo de vida iterativo, a seleo do incremento a ser desenvolvido

1.1.3. Vantagens de uma Abordagem Iterativa

Os riscos so reduzidos mais cedo, pois os elementos so integrados

As tticas e os requisitos variveis so acomodados.

A melhoria e o refinamento do produto so facilitados, resultando em um

As organizaes podem aprender a partir dessa abordagem e melhorar

A capacidade de reutilizao aumenta.

bem at quase no final do projeto; s vezes, at a metade da integrao. A, tudo

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

desmorona. Com a abordagem iterativa, muito difcil esconder a verdade durante

A abordagem iterativa permite que voc considere os requisitos variveis, j

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

As mudanas efetuadas nos requisitos e a forma lenta como eles so

Busca de melhor qualidade

Uma abordagem iterativa resulta em uma arquitetura mais robusta, pois os

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

Os desenvolvedores podem aprender durante o processo, e as vrias

Um ciclo de vida iterativo facilita a reutilizao. Identificar as partes comuns

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

1.2. Gerencie Requisitos

propriedade. Por exemplo, eles no so necessariamente igualmente

Univag Centro Universitrio

UNIVAG - Centro Universitrio - Av. Dom Orlando

Melhores Praticas de EngSoft.

H vrias partes interessadas, o que significa que os requisitos

Essa anlise feita para o entendimento dos problemas e das