melhores praticas.pdf

Univag – Centro Universitário

UNIVAG - Centro Universitário - Av. Dom Orlando Chaves, 2.655 - Bairro Cristo Rei

Várzea Grande - Mato Grosso - Brasil - CEP 78118-000 - Telefax: +55 (65) 3688-6000

E-mail: [email protected]

Melhores Praticas de EngSoft. Auditoria de Sistemas

Computacionais - Sob a ótica do Desenvolvimento de Software.

MELHORES PRÁTICAS DE ENGENHARIA DE

SOFTWARE

Abordagens comercialmente aprovadas para desenvolvimento de software

1







ÍNDICE

1. Melhores Práticas _____________________________________________________ 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. Diminuição de riscos ______________________________________ 8 1.1.3.2. Acomodação de mudanças __________________________________ 8 1.1.3.3. Busca de melhor qualidade__________________________________ 9 1.1.3.4. Aprendizado e melhoria ___________________________________ 10 1.1.3.5. Aumento de reutilização___________________________________ 10

1.2. Gerencie Requisitos ______________________________________________ 11 1.2.1. O que é o Gerenciamento de Requisitos?__________________________ 11

1.2.1.1. Análise do problema______________________________________ 12 1.2.1.2. Noções básicas sobre as necessidades dos envolvidos____________ 13 1.2.1.3. Definição do sistema _____________________________________ 13 1.2.1.4. Gerenciamento do escopo do projeto _________________________ 14 1.2.1.5. Refinamento da definição do sistema_________________________ 14 1.2.1.6. Gerenciamento dos requisitos variáveis _______________________ 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 compreensão de sistemas complexos _________________ 24 1.4.2.2. Exploração e comparação de alternativas de design a um baixo custo 25 1.4.2.3. Formação de uma base para implementação ___________________ 25 1.4.2.4. Captura de requisitos com precisão __________________________ 26 1.4.2.5. Comunicação de decisões sem ambigüidade ___________________ 26

1.5. Verifique Qualidade Continuamente _________________________________ 27 1.5.1. O que Significa Verificação da Qualidade Durante o Ciclo de Vida? ____ 27 1.5.2. O que é Qualidade?___________________________________________ 28

1.5.2.1. Introdução______________________________________________ 28 1.5.2.2. Definição de Qualidade ___________________________________ 29 1.5.2.3. Quem Possui Qualidade? __________________________________ 29 1.5.2.4. Conceitos Errôneos 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 dimensão, um atributo ou uma característica 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 ________________________ 32

1.6. Gerencie Mudanças ______________________________________________ 35 1.6.1. Coordenação de Atividades e de Artefatos ________________________ 35 1.6.2. Coordenação de Iterações e de Releases __________________________ 36 1.6.3. Controle de Mudanças no Software ______________________________ 36

Anexo I ________________________________________________________________ 37

3







1. Melhores Práticas

O Rational Unified Process (RUP) mostra como é possível aplicar as

melhores práticas de engenharia de software e usar ferramentas para automatizar

o processo de engenharia de software.

4







1.1. Desenvolva Iterativamente

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

iteração resulta em um release executável.

1.1.1. O que é o Desenvolvimento Iterativo?

Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que

consiste em várias iterações. Uma iteração incorpora um conjunto quase

seqüencial de atividades em modelagem de negócios, requisitos, análise e design,

implementação, teste e implantação, em várias proporções, dependendo do local

em que ela está localizada no ciclo de desenvolvimento. As iterações nas fases de

iniciação e de elaboração se concentram nas atividades de gerenciamento,

requisitos e design. As iterações na fase de construção se concentram no design,

na implementação e no teste. E as iterações na fase de transição e concentram no

teste e na implantação. O gerenciamento das iterações deve ser do tipo timebox1, 1 (1) [timebox A abordagem ao gerenciamento da programação de uma iteração recomendada no RUP: tendo estabelecido inicialmente o escopo e a programação de uma iteração, o gerente de projeto é incentivado a gerenciar de forma ativa esse escopo (e os recursos confirmados para a iteração), a fim de cumprir a data final planejada para a iteração, em vez de adiá-la para acomodar o escopo planejado originalmente, caso o desenvolvimento leve mais tempo que o imaginado. No RUP, é preferível reduzir o escopo do que adicionar recursos para gerenciar uma programação adiada. São duas as motivações para essa abordagem: tornar os resultados de uma iteração visíveis para os envolvidos e avaliar a iteração, para que as lições aprendidas possam ser aplicadas a iterações posteriores. ]

5







isto é, a programação de uma iteração deve ser considerada fixa e o escopo do

conteúdo da iteração gerenciado ativamente para atender a essa programação.

1.1.2. Por que Desenvolver Iterativamente?

É provável que um design inicial contenha falhas em relação a seus

principais requisitos. A descoberta tardia dos defeitos de design resulta em

saturações caras e, em alguns casos, até mesmo no cancelamento do projeto.

Todos os projetos têm um conjunto de riscos envolvidos. Quanto mais cedo

você puder verificar que evitou um risco no ciclo de vida, mais precisos serão seus

planos. Muitos riscos nem são descobertos até que você tente integrar o sistema.

É impossível prever todos eles, por mais experiente que seja a equipe de

desenvolvimento.

Em um ciclo de vida em cascata, você não poderá verificar se ficou livre de

um risco até o final do ciclo.

6







Em um ciclo de vida iterativo, a seleção do incremento a ser desenvolvido

em uma iteração é feita com base em uma lista dos principais riscos. Como a

iteração produz um executável 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 vários motivos.

• Os riscos são reduzidos mais cedo, pois os elementos são integrados

progressivamente.

• As táticas e os requisitos variáveis são acomodados.

• A melhoria e o refinamento do produto são facilitados, resultando em um

produto mais robusto.

• As organizações podem aprender a partir dessa abordagem e melhorar

seus processos.

• A capacidade de reutilização 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 integração. Aí, tudo

7







desmorona. Com a abordagem iterativa, é muito difícil esconder a verdade durante

muito tempo."

Geralmente, os gerentes de projeto resistem à abordagem iterativa, pois

consideram-na um infindável refinamento. No Rational Unified Process (RUP), a

abordagem interativa é muito controlada; o número, a duração e o objetivo das

iterações são planejados. As tarefas e as responsabilidades dos participantes são

definidas. São capturadas medidas de progresso objetivas. Ocorre algum

retrabalho de uma iteração para a outra, mas isso também é cuidadosamente

controlado.

1.1.3.1. Diminuição de riscos

Uma abordagem iterativa permite que você diminua os riscos mais cedo,

pois muitos deles são descobertos somente durante a integração. Durante a

iteração 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 não são riscos, e riscos novos e

inesperados aparecerão.

A integração não é um "big bang" no final; os elementos são incorporados

progressivamente. Na realidade, a abordagem iterativa é uma integração quase

contínua. O que costumava ser um período longo, incerto e difícil, que levava até

40% do esforço total no final de um projeto, e o que dificultava a precisão do

planejamento é dividido em seis a nove integrações menores, que iniciam com um

número muito menor de elementos a serem integrados.

1.1.3.2. Acomodação de mudanças

A abordagem iterativa permite que você considere os requisitos variáveis, já

que eles normalmente serão alterados durante o processo.

8







As mudanças efetuadas nos requisitos e a forma lenta como eles são

levantados têm sido sempre as principais fontes de problemas para um projeto,

levando a liberação depois do prazo, programações atrasadas, clientes

insatisfeitos e desenvolvedores frustrados. Há vinte e cinco anos, Fred Brooks

escreveu: "Planeje jogar algo fora; você irá, de qualquer maneira." Os usuários

mudarão de idéia durante o processo. Essa é a natureza humana. Forçar os

usuários a aceitarem o sistema como o imaginaram originalmente está errado.

Eles mudam de idéia porque o contexto está sendo alterado; eles aprendem mais

sobre o ambiente e a tecnologia e enxergam uma demonstração intermediária do

produto durante o seu desenvolvimento.

Um ciclo de vida iterativo fornece o gerenciamento com um modo de fazer

mudanças táticas no produto. Por exemplo, para competir com os produtos

existentes, você poderá decidir lançar um produto com funcionalidade reduzida

mais cedo como reação a uma movimentação de um concorrente ou poderá

adotar um outro fornecedor de uma determinada tecnologia.

A iteração também permite mudanças tecnológicas durante o processo. Se

alguma tecnologia é alterada ou se torna um padrão conforme aparece uma nova,

o projeto poderá aproveitá-la. Particularmente, esse é o caso de mudanças de

plataforma e de infra-estrutura de nível inferior.

1.1.3.3. Busca de melhor qualidade

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

erros são corrigidos após várias iterações. As falhas iniciais são detectadas

conforme o produto amadurece, durante as iterações iniciais. Os gargalos de

desempenho são descobertos e podem ser reduzidos, em vez de aparecerem na

véspera da liberação.

Desenvolver iterativamente, ao contrário de executar testes uma vez ao final

do projeto, resulta em um produto totalmente testado. Houve muitas oportunidades

9







para testar as funções críticas após várias iterações, e os próprios testes, além

dos softwares de teste, tiveram tempo para amadurecer.

1.1.3.4. Aprendizado e melhoria

Os desenvolvedores podem aprender durante o processo, e as várias

capacidades e especialidades são empregadas mais completamente durante todo

o ciclo de vida.

Em vez de esperar muito tempo simplesmente fazendo planos e aprimorando

suas habilidades, os testadores começam a testar cedo, a escrita técnica começa

cedo e assim por diante. A necessidade de treinamento adicional ou de ajuda

externa pode ser detectada nas revisões de avaliação das iterações iniciais.

O próprio processo pode ser melhorado e refinado durante o seu

desenvolvimento. A avaliação ao final de uma iteração não considera apenas o

status do projeto de uma perspectiva de programação do produto, mas também

analisa o que precisa ser alterado na organização e no processo para melhorar o

desempenho na próxima iteração.

1.1.3.5. Aumento de reutilização

Um ciclo de vida iterativo facilita a reutilização. Identificar as partes comuns

quando estão parcialmente projetadas ou implementadas é mais fácil que

identificar todas as semelhanças no início.

É difícil identificar e desenvolver partes reutilizáveis. As revisões de design

nas iterações iniciais possibilitam que os arquitetos de software identifiquem

reutilizações inesperadas e potenciais, e as iterações subseqüentes permitem que

eles desenvolvam e amadureçam posteriormente esse código comum.

O uso de uma abordagem iterativa facilita o aproveitamento dos produtos

desenvolvidos internamente e adquiridos prontos para serem usados. Você terá

várias iterações para selecioná-los, integrá-los e confirmar que eles são

adequados à arquitetura.

10







1.2. Gerencie Requisitos

1.2.1. O que é o Gerenciamento de Requisitos?

O gerenciamento de requisitos é uma abordagem sistemática para localizar,

documentar, organizar e controlar os requisitos variáveis em um sistema.

Definimos um requisito como "uma condição ou uma capacidade com a

qual o sistema deverá estar em conformidade".

O gerenciamento de requisitos é definido formalmente como uma

abordagem sistemática a:

identificar, organizar e documentar os requisitos do sistema;

firmar e atualizar acordos entre o cliente e a equipe do projeto sobre

os requisitos variáveis do sistema.

As chaves para o gerenciamento eficaz de requisitos incluem manter uma

sentença clara dos requisitos, junto com os atributos aplicáveis e a rastreabilidade

para outros requisitos e outros artefatos do projeto.

A coleta de requisitos pode parecer uma tarefa bem precisa. Na realidade,

porém, os projetos enfrentam dificuldades pelos seguintes motivos:

Nem sempre os requisitos são óbvios e podem vir de várias fontes.

Os requisitos nem sempre são expressos em palavras de modo fácil

ou claro.

Existem diversos tipos de requisitos em diferentes níveis de detalhe.

O número de requisitos pode se tornar impossível de gerenciar se

eles não forem controlados.

Os requisitos estão relacionados uns com os outros, e também com

o produto liberado do processo de engenharia do software.

Os requisitos têm propriedades exclusivas ou valores de

propriedade. Por exemplo, eles não são necessariamente igualmente

importantes ou igualmente fáceis de se atender.

11







Há várias partes interessadas, o que significa que os requisitos

precisam ser gerenciados por grupos de pessoas de diferentes

funções.

Os requisitos são alterados.

Então, que habilidades você precisa desenvolver em sua organização para

ajudá-lo a gerenciar essas dificuldades? Aprendemos que as seguintes

habilidades são importantes para o gerenciamento:

Análise do problema;

Noções básicas sobre as necessidades dos envolvidos;

Definição do sistema;

Gerenciamento do escopo do projeto;

Refinamento da definição do sistema;

Gerenciamento dos requisitos variáveis.

1.2.1.1. Análise do problema

Essa análise é feita para o entendimento dos problemas e das

necessidades iniciais dos envolvidos e para que sejam propostas soluções de alto

nível. É um ato de raciocínio e de análise para localizar "o problema por trás do

problema". Durante a análise, são estabelecidos os problemas reais e quem são

os envolvidos. Do ponto de vista negócios, você também define as fronteiras da

solução e as restrições de negócios dessa solução. O caso de negócio do projeto

também 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 informações sobre este tópico.

12







1.2.1.2. Noções básicas sobre as necessidades dos envolvidos

Os requisitos chegam de várias fontes; por exemplo, clientes, parceiros,

usuários e especialistas em domínios. Você precisa saber determinar quais

deveriam ser as melhores fontes, como acessá-las e como levantar informações

nelas de modo eficaz. Os indivíduos que fornecem as principais fontes dessas

informações são denominados envolvidos no projeto.

Se você estiver desenvolvendo um sistema de informações que será usado

internamente em sua empresa, poderá incluir pessoas com experiência de usuário

e especialização em domínios na equipe de desenvolvimento. Muito

freqüentemente, você iniciará as discussões no nível de modelo de negócios e

não no nível de sistema. Se estiver desenvolvendo um produto que será vendido

para um mercado específico, você poderá usar amplamente a equipe de

marketing para entender melhor as necessidades dos clientes naquele mercado.

O levantamento de informações pode ocorrer através de técnicas como

entrevistas, discussão de idéias, protótipos conceituais, questionários e análise

competitiva. O resultado é uma lista de solicitações ou de necessidades descritas

em forma de texto e de gráficos e que recebem uma prioridade entre si.

1.2.1.3. Definição do sistema

Definir o sistema significa converter e organizar o entendimento das

necessidades dos envolvidos em uma descrição significativa do sistema a ser

criado. No início da definição do sistema, são tomadas decisões sobre o que

constitui um requisito, o formato da documentação, a formalidade da linguagem, o

grau de especificação dos requisitos (quantos e com qual detalhamento), a

prioridade das solicitações e o esforço estimado (duas avaliações muito diferentes,

geralmente determinadas por pessoas distintas em exercícios separados), os

riscos técnicos e de gerenciamento e o escopo inicial. Parte dessa atividade pode

incluir modelos de design e protótipos iniciais diretamente relacionados aos mais

13







importantes requisitos dos envolvidos. O resultado da definição é uma descrição

do sistema que usa as representações em linguagem natural e gráfica.

1.2.1.4. Gerenciamento do escopo do projeto

Para executar um projeto de modo eficiente, é necessário priorizar

cuidadosamente os requisitos com base nas informações recebidas de todos os

envolvidos e gerenciar esse escopo. Muitos projetos são prejudicados devido a

desenvolvedores ocupados em criar os chamados "Ovos de páscoa"

(características que o desenvolvedor acha interessantes e desafiadoras), em vez

de se concentrar desde o início em tarefas que diminuem um risco de projeto ou

estabilizam a arquitetura da aplicação. Certifique-se de resolver ou diminuir os

riscos em um projeto o mais cedo possível, 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 iteração com os envolvidos no projeto. Geralmente, isso exige

uma boa capacidade de gerenciamento das expectativas da saída do projeto em

suas diferentes fases. Também é necessário controlar as fontes dos requisitos, a

aparência dos produtos liberados do projeto e o próprio processo de

desenvolvimento.

1.2.1.5. Refinamento da definição do sistema

A definição detalhada do sistema precisa ser apresentada de maneira que

os envolvidos possam entendê-la, concordar com ela e sair dela. Ela precisa

abordar não apenas a funcionalidade, mas também a compatibilidade com os

requisitos legais ou reguladores, a usabilidade, a confiabilidade, o desempenho, a

capacidade de suporte e de manutenção. Um erro freqüente é acreditar que o que

você sente que é difícil criar precisa ter uma definição complexa. Isso cria

dificuldades para explicar a finalidade do projeto e do sistema. As pessoas podem

ficar impressionadas, mas não darão boas contribuições porque não entendem. É

necessário dar mais atenção ao entendimento do público para o qual os artefatos

14







estão sendo produzidos; geralmente, são necessários diferentes tipos de

descrição para públicos distintos.

Vimos que a metodologia de casos de uso, geralmente em combinação

com protótipos 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 definição detalhada do sistema é estabelecer como o

sistema deverá ser testado. Os planos de teste e as definições dos testes a serem

executados indicam os recursos do sistema que serão verificados.

1.2.1.6. Gerenciamento dos requisitos variáveis

Por mais que você tenha cuidado ao definir os requisitos, sempre haverá

itens que são alterados. O que torna complexo o gerenciamento dos requisitos

variáveis não é apenas o fato de que um requisito alterado significa a necessidade

de gastar tempo com a implementação de uma nova característica específica, mas

também que uma mudança em um requisito poderá ter impacto em outros. Você

precisa garantir que os requisitos receberão uma estrutura que aceite bem as

mudanças e usar links de rastreabilidade para representar as dependências entre

os requisitos e outros artefatos do ciclo de vida do desenvolvimento. O

gerenciamento de mudanças inclui atividades como: estabelecer uma baseline,

determinar as dependências importantes a serem rastreadas, estabelecer a

rastreabilidade entre itens relacionados e implementar o controle de mudanças.

15







1.2.2. Como o Desenvolvimento é Baseado em Casos de Uso?

Recomendamos a utilização dos casos de uso como método para a

organização 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 abrangência e consistência e também

fornece um melhor entendimento da importância de um requisito do ponto de vista

do usuário.

A partir de um modelo de sistema tradicional orientado a objetos,

geralmente é difícil definir como um sistema faz o que se espera que ele faça.

Essa dificuldade resulta da falta de um "thread vermelho" através do sistema

quando executa certas tarefas. No Rational Unified Process (RUP), os casos de

uso são essa linha, pois definem o comportamento de um sistema. Eles não fazem

parte da orientação a objetos tradicional, mas sua importância 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 são a base de todo o

processo de desenvolvimento.

Os casos de uso fazem parte de várias disciplinas.

O conceito de casos de uso pode ser usado para representar

processos de negócios, conforme definido na disciplina modelagem

de negócios. Essa variante de caso de uso é denominada "caso de

uso de negócios".

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 usuário.

Os casos de uso constituem um conceito fundamental importante

que precisa ser aceitável para o cliente, para os desenvolvedores e

para os testadores do sistema.

16







Em análise e design, os casos de uso são realizados em um modelo

de design. Você pode criar realizações de casos de uso, que

descrevem como os casos de uso são suportados pelo design no

que se refere à interação 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 necessários.

Durante a implementação, o modelo de design atua como a

especificação da implementação. Como os casos de uso são a base

do modelo de design, eles são implementados em relação às classes

de design de colaboração.

Durante o teste, os casos de uso fornecem os cenários necessários

que compõem a principal base para identificação funcional de

cenários de teste. Esses cenários de teste são usados para originar

casos de teste e scripts de teste; a funcionalidade do sistema é

verificada executando cenários de teste que experimentam cada

caso de uso.

Na disciplina Gerenciamento de Projeto, os casos de uso são usados

como base para planejar o desenvolvimento iterativo.

Na disciplina Implantação, os casos de uso formam uma base para o

que está descrito nos manuais do usuário. Eles também podem ser

usados para definir as unidades de pedido do produto. Por exemplo,

um cliente pode obter um sistema configurado com uma combinação

específica 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 são grupos de código coesos, na forma de código fonte ou

executável, com interfaces bem definidas e comportamentos que fornecem forte

encapsulamento do conteúdo e são, portanto, substituíveis. As arquiteturas

baseadas em componentes tendem a reduzir o tamanho efetivo e a complexidade

da solução e, portanto, são mais robustas e flexíveis.

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 são centralizadas na noção da arquitetura do sistema e em sistemas intensivos de software, arquitetura de

software. O foco principal das iterações iniciais do processo, principalmente na

fase de elaboração, é produzir e validar uma arquitetura de software2, que no ciclo

2 A arquitetura de software abrange:

• as decisões significativas sobre a organização de um sistema de software

18







de desenvolvimento inicial toma a forma de um protótipo arquitetural executável

que gradualmente evolui até se tornar o sistema final em iterações posteriores.

Arquitetura executável significa uma implementação parcial do sistema criada para

demonstrar funções e propriedades selecionadas do sistema, em particular

aquelas que satisfazem requisitos não funcionais. A finalidade da arquitetura

executável é diminuir os riscos relacionados a desempenho, taxa de transferência,

capacidade, confiabilidade, etc. para que a capacidade funcional completa do

sistema possa ser adicionada na fase de construção3 de uma forma segura, sem

perigo de quebra.

O RUP fornece uma maneira metódica e sistemática de projetar,

desenvolver e validar uma arquitetura. Oferecemos templates para descrição da

arquitetura, com os conceitos de várias visões arquiteturais, e para a captura de

estilo de arquitetura, regras de design e restrições. A disciplina Análise e Design

contém atividades específicas orientadas para identificar restrições arquiteturais e

para elementos significativos na arquitetura, além de diretrizes sobre como fazer

escolhas arquiteturais. O processo de gerenciamento mostra como o

planejamento das iterações iniciais considera o design de uma arquitetura e a

resolução dos principais riscos técnicos.

• a seleção dos elementos estruturais e das interfaces através das quais o

sistema é composto em conjunto com o comportamento, como especificado na colaboração entre esses elementos

• a composição dos elementos estruturais e comportamentais em subsistemas progressivamente maiores

• o estilo de arquitetura que guia essa organização, esses elementos e suas interfaces, suas colaborações e sua composição

A arquitetura de software não diz respeito apenas a estrutura e comportamento, mas também a uso, funcionalidade, desempenho, flexibilidade, reutilização, abrangência, restrições tecnológicas e econômicas, trocas e estética. 3 construção

É a terceira fase do Processo Unificado, na qual o software é trazido de uma baseline arquitetural executável para o ponto no qual está pronto para ser transferido para a comunidade de usuários.

19







A arquitetura é importante por vários 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

sucessão de pequenas decisões táticas independentes. Ele precisa ter uma

estrutura unificadora e coerente para organizar essas partes de modo sistemático

e fornecer regras precisas sobre como pode ser aumentado, sem que sua

complexidade cresça além da compreensão humana.

A arquitetura determina os meios para se obter melhor comunicação e

entendimento em todo o projeto, estabelecendo um conjunto de referências e um

vocabulário comuns, com os quais se discutem questões de design.

É uma base efetiva para reutilização em larga escala.

Ao articular claramente os principais componentes e as interfaces críticas

entre eles, uma arquitetura permite que você raciocine sobre a reutilização, tanto a

reutilização interna que é a identificação das partes comuns, como a reutilização

externa que é a incorporação de componentes desenvolvidos internamente e

adquiridos prontos para serem usados. No entanto, também permite a reutilização

em uma escala maior: a reutilização da própria arquitetura, no contexto de uma

linha de produtos que aborda funcionalidades diferentes em um domínio comum.

Ela fornece uma base para gerenciamento de projeto.

Planejamento e formação de equipe estão organizados de acordo com os

principais componentes. Decisões estruturais fundamentais são tomadas por uma

equipe pequena e coesa de arquitetura. Elas não são distribuídas. O

20







desenvolvimento é dividido entre um conjunto de equipes pequenas, cada uma

sendo responsável por uma ou várias partes do sistema.

1.3.3. Desenvolvimento Baseado em Componentes

Um componente de software pode ser definido como um pedaço não-trivial

de software, um módulo, um pacote ou um subsistema, sendo que todos

desempenham uma função clara, possuem uma fronteira clara e podem ser

integrados em uma arquitetura bem definida. É a realização física de uma

abstração do design.

Os componentes vêm 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.

Além disso, alguns desses componentes podem ser desenvolvidos

para serem reutilizáveis, especialmente os componentes que

fornecem soluções comuns para uma ampla variedade de problemas

comuns. Esses componentes reutilizáveis, que podem ser maiores

que apenas conjuntos de utilitários ou de bibliotecas de classes,

formam a base de reutilização dentro de uma organização,

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 indústria completa de componentes

desenvolvidos internamente e adquiridos prontos para serem usados

para vários domínios, 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 programação: de uma linha por

vez para a composição do software através 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 padrões e os

mecanismos fundamentais através dos quais eles interagem.

Conceitos como pacotes, subsistemas e camadas são utilizados

durante a disciplina Análise e Design para organizar componentes e

especificar interfaces.

Os testes são primeiramente organizados em componentes e, em

seguida, em conjuntos maiores de componentes integrados.

22







1.4. Modele Visualmente (UML)

A modelagem visual aumenta o nível de abstração

1.4.1. O que é Modelagem Visual?

A modelagem visual é o uso de notações de design gráficas e textuais,

semanticamente ricas, para capturar designs de software. Uma notação, como a

UML, permite que o nível de abstração seja aumentado, enquanto mantém sintaxe

e semântica rígidas. Dessa maneira, a comunicação na equipe de design melhora,

à medida que o design é formado e revisado, permitindo ao leitor raciocinar sobre

ele e fornecendo uma base não ambígua para a implementação.

1.4.2. Por que Modelamos?

Um modelo é uma visão simplificada de um sistema. Ele mostra os

elementos essenciais do sistema de uma perspectiva específica e oculta os

detalhes não essenciais. Os modelos podem ajudar das seguintes maneiras:

ajudando na compreensão de sistemas complexos;

explorando e comparando alternativas de design a um baixo custo;

formando uma base para implementação;

capturando requisitos com precisão;

comunicando decisões sem ambigüidade.

23







1.4.2.1. Ajuda na compreensão de sistemas complexos

A importância dos modelos aumenta à medida que os sistemas se tornam

mais complexos. Por exemplo, um canil pode ser construído sem um projeto. No

entanto, à medida que evoluímos para a construção de casas e, em seguida, para

arranha-céus, 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 comércio eletrônico com dezenas de milhares de linhas de

código-fonte, ou um sistema de controle de tráfego aéreo de centenas de milhares

de linhas de código, não pode mais ser facilmente entendido por uma única

pessoa. A construção de modelos permite a um desenvolvedor se concentrar na

visão geral, entender como os componentes interagem e identificar falhas fatais.

Alguns exemplos de modelos são:

Casos de Uso para especificar comportamento de forma não

ambígua;

Diagramas de Classes e Diagramas de Modelo de Dados para

capturar design;

Diagramas de Transição de Estado para modelar comportamento

dinâmico.

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. Exploração e comparação de alternativas de design a um baixo

custo

Modelos simples podem ser criados e modificados a um baixo custo para

explorar alternativas de design. Idéias inovadoras podem ser capturadas e

revisadas por outros desenvolvedores, antes de investir em um desenvolvimento

de código caro. Quando associada ao desenvolvimento iterativo, a modelagem

visual ajuda os desenvolvedores a avaliar mudanças de design e a comunicar

essas mudanças a toda a equipe de desenvolvimento.

1.4.2.3. Formação de uma base para implementação

Atualmente, muitos projetos empregam linguagens de programação

orientadas a objetos para obter sistemas reutilizáveis, tolerantes a mudanças e

estáveis. 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 implementação.

Com o suporte das ferramentas adequadas, um modelo de design pode ser

usado para gerar um conjunto inicial de código para implementação. Isso é

referido como "engenharia direta" ou "geração de código". Os modelos de design

também podem ser aprimorados para incluir informações suficientes para criar o

sistema.

A engenharia reversa também pode ser aplicada para gerar modelos de

design a partir de implementações existentes. Isso pode ser usado para avaliar

implementações existentes.

"A engenharia round-trip" combina as técnicas de engenharia direta e

reversa para garantir código e design consistentes. Combinada com um processo

iterativo e com as ferramentas certas, a engenharia round-trip permite que o

código e o design sejam sincronizados durante cada iteração.

25







1.4.2.4. Captura de requisitos com precisão

Antes de criar um sistema, é essencial capturar os requisitos. A

especificação dos requisitos usando um modelo preciso e não ambíguo ajuda a

garantir que todos os envolvidos possam entender e concordar com os

requisitos.

Um modelo que separa o comportamento externo do sistema da

implementação o ajuda a se concentrar no uso pretendido do sistema, sem ficar

perdido nos detalhes de implementação.

1.4.2.5. Comunicação de decisões sem ambigüidade

O RUP usa a Linguagem Unificada de Modelagem (UML), uma notação

consistente que pode ser aplicada à engenharia de sistemas e à engenharia de

negócios. Uma notação padrão serve aos seguintes papéis (consulte [BOO95]):

"Serve como uma linguagem para comunicar decisões que não são

óbvias ou que não podem ser deduzidas do próprio código."

"Fornece semântica rica o suficiente para capturar todas as decisões

estratégicas e táticas importantes."

"Oferece uma forma concreta o suficiente para que as pessoas

raciocinem e para que as ferramentas sejam manipuladas."

UML representa a convergência da melhor prática em modelagem de

software por toda a indústria de tecnologia de objetos. Para obter mais

informações sobre a UML, visite nosso site na Web em

http://www.rational.com/uml.

26







1.5. Verifique Qualidade Continuamente

A localização e a solução dos problemas de software ficam de 100 a 1.000

vezes mais caros, se realizados após a implantação. A verificação e o

gerenciamento da qualidade durante o ciclo de vida do projeto é essencial para

atingir os objetivos corretos no momento certo.

Tópicos

O que Significa Verificação da Qualidade Durante o Ciclo de Vida?

O que é Qualidade?

o Introdução

o Definição de Qualidade

o Quem Possui Qualidade?

o Concepções Errôneas Comuns sobre Qualidade

o Gerenciamento de Qualidade no RUP

1.5.1. O que Significa Verificação da Qualidade Durante o Ciclo de Vida?

É importante que a qualidade de todos os artefatos seja avaliada em vários

pontos no ciclo de vida do projeto, à medida que eles amadurecem. Os artefatos

devem ser avaliados à medida que as atividades que os produzem são concluídas

e na conclusão de cada iteração. Especificamente, à medida que o software

executável é produzido, ele deve ser submetido à demonstração e teste de

cenários importantes em cada iteração, o que fornecerá uma compreensão mais

27







real das trocas de design e da eliminação 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. Introdução

A qualidade é algo pelo qual nos esforçamos para obter nos produtos,

processos e serviços. Ainda assim, quando perguntados, "O que é Qualidade?",

todos possuem uma opinião diferente. As respostas mais comuns incluem uma ou

outra destas opções:

"Qualidade ... Não tenho certeza de como descrevê-la, mas saberei

quando vê-la."

"... atendimento de requisitos."

Talvez a referência mais freqüente à qualidade, relacionada

especificamente ao software, seja este comentário com relação à sua ausência:

"Como puderam lançar algo assim, com uma qualidade tão baixa!?"

Essas respostas comuns são significativas, mas oferecem muito pouco para

um exame rigoroso da qualidade e para melhorar sua execução. Todos esses

comentários ilustram a necessidade de definir a qualidade de maneira que ela

possa ser medida e alcançada.

A qualidade, no entanto, não é um atributo ou uma característica singular. É

multidimensional e pode ser possuída por um produto ou por um processo. A

qualidade do produto está concentrada na criação do produto certo, enquanto a

qualidade do processo está concentrada na criação correta do produto.

28







1.5.2.2. Definição de Qualidade

A definição de qualidade, no The American Heritage Dictionary of the

English Language, 3a edição, Houghton Mifflin Co.,© 1992, 1996, é:

Qualidade s.f.., pl. Qualidades. 1.a. Uma característica inerente ou

diferenciada; uma propriedade. b. Um traço pessoal, especialmente

um traço de caráter. 2. Caráter essencial; natureza. 3.a.

Superioridade de natureza. b. Grau ou classificação de excelência.

Como demonstrado por essa definição, a qualidade não é uma dimensão

única, mas várias. Para usar a definição 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 característica de ter demonstrado a realização da criação de um

produto que atende ou excede os requisitos acordados, conforme

avaliado por medidas e critérios acordados, e que é criado em um

processo acordado."

Obter qualidade não é simplesmente "atender a requisitos" ou produzir um

produto que atende às necessidades e expectativas dos usuários. Pelo contrário,

a qualidade também inclui a identificação das medidas e dos critérios para

demonstrar a obtenção da qualidade e a implementação 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 errôneo comum é que a qualidade pertence a um grupo ou é

responsabilidade dele. Geralmente, esse mito é perpetuado pela criação 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

missão 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 responsáveis pela qualidade dos produtos (ou

artefatos) que criam e pela implementação do processo no qual estão envolvidos.

Cada papel contribui para a obtenção da qualidade das seguintes maneiras:

Qualidade do produto—a contribuição para a obtenção geral da

qualidade em cada artefato que está sendo produzido.

Qualidade do processo—a obtenção da qualidade nas atividades do

processo em que eles estão envolvidos.

Todos compartilham a responsabilidade e a glória de obter um produto de

alta qualidade ou a vergonha de um produto de baixa qualidade. Mas somente

aqueles diretamente envolvidos em um componente específico do processo são

responsáveis pela glória ou vergonha da qualidade desses componentes do

processo (e dos artefatos). Alguém, no entanto, deve ter a responsabilidade de

gerenciar a qualidade, ou seja, fornecer a supervisão para garantir que a

qualidade esteja sendo gerenciada, medida e obtida. O papel responsável por

gerenciar a qualidade é o Gerente de Projeto.

1.5.2.4. Conceitos Errôneos Comuns sobre Qualidade

Existem muitos conceitos errôneos com relação à qualidade e os mais

comuns incluem:

A qualidade pode ser acrescentada ou "testada" em um produto;

A qualidade é uma única dimensão, um atributo ou uma

característica 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 não pode ser produzido se não houver

uma descrição do que ele é, do que precisa fazer, de quem o usa, de como ele é

usado e assim por diante, não será possível obter qualidade se ela não for

descrita, medida e fizer parte do processo de criação do produto.

1.5.2.6. A qualidade é uma única dimensão, um atributo ou uma

característica e significa o mesmo para todos

A qualidade não é uma única dimensão, um atributo ou uma característica.

A qualidade é medida de várias maneiras; as métricas e os critérios de qualidade

são estabelecidos para atender às necessidades do projeto, da organização e do

cliente.

A qualidade pode ser medida juntamente com várias dimensões; 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

concluídos

Variação — diferenças entre requisitos de formação de equipe,

orçamentos, programações reais e planejados e assim por diante

Confiabilidade — resistência à falha (queda do sistema, parada do

sistema, perdas de memória e assim por diante) durante a execução.

Função — o artefato implementa e executa os casos de uso

necessários, conforme pretendido

Desempenho — o artefato executa e responde de maneira aceitável

e em tempo hábil, e continua a executar de maneira aceitável,

quando submetido a características operacionais do mundo real,

como carga, stress e longos períodos de operação.

31







1.5.2.7. A qualidade acontece sozinha

A qualidade não 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 atribuição de

tarefas e responsabilidades dentro de uma organização de desenvolvimento.

Nossa meta é garantir a produção de software de alta qualidade que atenda às

necessidades dos usuários, dentro de uma programação e um orçamento

previsíveis. O RUP captura muitas das melhores práticas de desenvolvimento de

software moderno, de forma que possa ser adaptado para um largo espectro de

projetos e organizações. A disciplina Ambiente fornece orientações sobre a melhor

maneira de configurar o processo de acordo com as suas necessidades.

Os processos podem ser configurados e os critérios de qualidade para

aceitabilidade podem ser negociados, com base em vários fatores. Os fatores

mais comuns são:

Risco (incluindo responsabilidades)

Oportunidades de mercado

Requisitos de receita

Questões de programação ou formação de equipe

Orçamentos

As mudanças no processo e nos critérios de aceitabilidade devem ser

identificadas e acordadas no início do projeto.

1.5.2.8. Gerenciamento de Qualidade no RUP

O gerenciamento de qualidade é feito para estas finalidades:

Identificar indicadores adequados (métricas) com qualidade

aceitável;

Identificar medidas adequadas a serem usadas na avaliação da

qualidade;

Identificar e abordar adequadamente questões que afetam a

qualidade o mais cedo e eficaz possível.

32







O gerenciamento da qualidade é implementado em todas as disciplinas,

fluxos de trabalho, fases e iterações 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 esforços gastos

para gerenciar a qualidade em cada disciplina estão realçados na lista a seguir:

O gerenciamento de qualidade na disciplina Requisitos inclui a

análise do conjunto de artefatos de requisitos em busca de

consistência (entre padrões de artefatos e outros artefatos), de

clareza (comunica as informações claramente a todos os acionistas,

envolvidos e outros papéis) e de precisão (o nível adequado de

detalhe e precisão).

Na disciplina Análise e Design , o gerenciamento da qualidade inclui

a avaliação do conjunto de artefatos de design, incluindo a

consistência do modelo de design, sua conversão a partir de

artefatos de requisitos e sua conversão em artefatos de

implementação.

Na disciplina Implementação, o gerenciamento da qualidade inclui a

avaliação dos artefatos de implementação e a avaliação do código-

fonte ou dos artefatos executáveis, com relação 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 esforços gastos nessa

disciplina aborda as três finalidades de gerenciamento de qualidade

identificadas anteriormente.

A disciplina Ambiente , como a disciplina Teste, inclui muitos

esforços de abordagem das finalidades de gerenciamento da

qualidade. Aqui é possível encontrar orientações sobre como

configurar melhor o processo para atender às suas necessidades.

33







O gerenciamento da qualidade na disciplina Implantação inclui a

avaliação dos artefatos de implementação e de implantação e a

avaliação dos artefatos executáveis e de implantação, com relação

aos artefatos adequados de requisito, de design e de teste

necessários para fornecer o produto ao cliente.

A disciplina Gerenciamento de Projeto inclui uma visão geral de

vários esforços de gerenciamento da qualidade, incluindo as

revisões e as auditorias necessárias para avaliar a implementação, a

aderência e o andamento do processo de desenvolvimento.

34







1.6. Gerencie Mudanças

O gerenciamento de mudanças é mais do que simplesmente fazer check-in

e check-out nos arquivos. Ele inclui gerenciamento de espaços de trabalho,

desenvolvimento paralelo, integração e builds.

Um desafio importante quando você está desenvolvendo sistemas

intensivos de software é lidar com vários desenvolvedores, organizados em

diferentes equipes, possivelmente em diferentes locais, trabalhando juntos em

várias iterações, releases, produtos e plataformas. Na ausência de controle

disciplinado, o processo de desenvolvimento rapidamente se transforma em caos.

Tópicos

Coordenação de Atividades e de Artefatos;

Coordenação de Iterações e de Releases;

Controle de Mudanças no Software.

1.6.1. Coordenação de Atividades e de Artefatos

A coordenação das atividades e dos artefatos de desenvolvedores e de

equipes envolve o estabelecimento de procedimentos que podem ser repetidos

para o gerenciamento de mudanças no software e em outros artefatos de

desenvolvimento. Essa coordenação permite uma melhor alocação de recursos,

com base nas prioridades e nos riscos do projeto e ela gerencia ativamente o

trabalho dessas mudanças entre iterações. Juntamente com o desenvolvimento do

35







software iterativamente, essa prática permite que você monitore as mudanças

continuamente, para poder descobrir ativamente e solucionar problemas.

1.6.2. Coordenação de Iterações e de Releases

A coordenação de iterações e de releases envolve o estabelecimento e a

liberação de uma baseline testada na conclusão de cada iteração. A manutenção

da rastreabilidade entre os elementos de cada release e entre os elementos de

vários releases paralelos é essencial para avaliar e gerenciar ativamente o

impacto da mudança.

1.6.3. Controle de Mudanças no Software

O controle de mudanças no software oferece várias soluções para as

causas originais de problemas de desenvolvimento de software:

O fluxo de trabalho da mudança de requisitos é definido e pode ser

repetido.

As solicitações de mudança facilitam a comunicação clara.

Os espaços de trabalho isolados reduzem a interferência entre

membros da equipe que trabalham em paralelo.

As estatísticas de taxa de mudanças fornecem métricas satisfatórias

para avaliar objetivamente o status do projeto.

Os espaços de trabalho contêm todos os artefatos, o que facilita a

consistência.

A propagação da mudança pode ser avaliada e controlada.

As mudanças podem ser mantidas em um sistema robusto e

personalizável.

36







Anexo I

RUP: Visão Geral

A figura acima mostra a arquitetura geral do RUP.

O Rational Unified Process (também 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 organização de

desenvolvimento. Sua meta é garantir a produção de software de alta qualidade

que atenda às necessidades dos usuários dentro de cronograma e orçamentos

previsíveis.

O RUP tem duas dimensões:

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 lógica, por natureza.

A primeira dimensão representa o aspecto dinâmico do processo quando

ele é aprovado e é expressa em termos de fases4, iterações e marcos.

A segunda dimensão representa o aspecto estático do processo, como ele

é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho,

artefatos e papéis do processo.

O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas

iterações iniciais, dedicamos mais tempo aos requisitos. Já nas iterações

posteriores, gastamos mais tempo com implementação.

4 A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) é dividido em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

38

melhores praticas.pdf

Documents