Processos de Software [Compatibility Mode]

5/11/2018 Processos de Software [Compatibility Mode] - slidepdf.com

http://slidepdf.com/reader/full/processos-de-software-compatibility-mode 1/84

1/156



2/156

Tópicos



3/156

Software

11-- InstruçõesInstruções

quando executadas produzem a função e odesempenho desejados

22 -- EstruturasEstruturas dede DadosDadospossibilitam que os programas manipulemadequadamente a informação

33 -- DocumentosDocumentosdescrevem a operação e o uso dos programas



4/156

Características do Software

1. Desenvolvido ou projetado por engenharia,

não manufaturado no sentido clássico

2. Não se desgasta mas se deteriora

3. A maioria é feita sob medida em vez deser montada a partir de componentesexistentes



5/156

Curva de falhas para o Hardware

“desgaste”

“mortalidade infantil” índice de falhas

tempo



6/156

Curva de falhas do Software

índice de falhas

curva real curva real

mu ança mu ança

curva idealizada

tempo



7/156

Aplicações do Software

BB ÁÁSS IICC OO programas de apoio a outros programas

DD EE TTEE MM PP OO RR EE AALL monitora, analisa e controla eventos domundo real

CC OO MM EE RR CC IIAALL operações comerciais e tomadas dedecisões adm inistrativas

C IENT FICO E DEEE NN GG EE NN HH AARR IIAA a gor m os e processam en o e n m eros

EE MM BB UU TTIIDD OO controla produtos e sistemas de mercadosindustriais e de consum o

DD EE CC OO MM PP UU TT AADD OO RRPP EE SS SS OO AALL processam ento de textos, planilhaseletrônicas, diversões, etc.

DD EE IINN TTEE LLIIGG ÊÊ NN CC IIAAAARR TT IIFF IICC IIAALL

algoritmos não numéricos para resolver problemas que não sejam favoráveis à

computação ou à análise direta



8/156

Evolução do Software

(1950 - 1965)

O hardware sofreu contínuas mudanças O software era uma arte "secundária" para

a qual havia poucos métodos sistemáticos

O hardware era de propósito geral O software era específico para cada

aplicação

Não havia documentação



9/156


(1965 - 1975) Multiprogramação e sistemas multiusuários Técnicas interativas Sistemas de tempo real

’ Produto de software - software houses Bibliotecas de Software

Cresce no de sistemas baseado em computador Manutenção quase impossível

..... CRISE DE..... CRISE DE SOFTWARESOFTWARE



10/156


(1975 - hoje )

Sistemas distribuídos Redes locais e globais

- produtos inteligentes

Hardware de baixo custo

Impacto de consumo..... CRISE DE..... CRISE DE SOFTWARESOFTWARE (aflição crônica???) (aflição crônica???)



11/156


(Quarta era do software: atualidadeatualidade)

Tecnologias orientadas o objetos Sistemas especialistas e software de

Software de rede neural artificial

Computação Paralela

Internet

..... CRISE DE..... CRISE DE SOFTWARESOFTWARE (aflição crônica???) (aflição crônica???)



12/156

Crise de Software

Refere-se a um conjunto de problemasencontrados no desenvolvimento de software:

(1) As estimativas de prazo e de custo freqüentementeAs estimativas de prazo e de custo freqüentemente

são imprecisassão imprecisas

“Não dedicamos tempo para coletar dados sobre oprocesso de desenvolvimento de software”

“Sem nenhuma indicação sólida de produtividade,

não podemos avaliar com precisão a eficácia denovas ferramentas, métodos ou padrões”



13/156

Crise de Software

(2) A produtividade das pessoas da área de softwareA produtividade das pessoas da área de software

não tem acompanhado a demanda por seus serviçosnão tem acompanhado a demanda por seus serviços“Os projetos de desenvolvimento de software

normalmente são efetuados apenas com um vago”



14/156

Crise de Software

(3) A qualidade de software às vezes é menos queA qualidade de software às vezes é menos que

adequadaadequadaSó recentemente começam a surgir conceitosquantitativos sólidos de garantia de qualidade de

(4) O software existente é muito difícil de manterO software existente é muito difícil de manter

A tarefa de manutenção devora o orçamento

destinado ao softwareA facilidade de manutenção não foi enfatizadacomo um critério importante



15/156

Crise de Software

estimativas de prazo e de custo ↑↑

produtividade das pessoas ↓↓

software difícil de manter ↑↑



16/156

Causas dos problemas associados à

Crise de Software11.. própriopróprio carátercaráter dodo SoftwareSoftware

O software é um elemento de sistema lógicoe não físico (produto intangível)

Conseqüentemente, o sucesso é medido pela

qua a e e uma n ca ent a e e n o pe aqualidade de muitas entidadesmanufaturadas

O software não se desgasta, mas seO software não se desgasta, mas sedeteriora!!!deteriora!!!



17/156

2. falhas das pessoas responsáveis pelo2. falhas das pessoas responsáveis pelo

desenvolvimento de Softwaredesenvolvimento de SoftwareGerentes sem nenhum background emsoftware

Causas dos problemas associados à Crise de

Software

Os profissionais da área de software têmrecebido pouco treinamento formal em

novas técnicas para o desenvolvimento desoftware

Resistência a mudanças.



18/156

33.. mitosmitos dodo SoftwareSoftware

propagaram desinformação e confusão

44 dministrativos dministrativos

Causas dos problemas associados à Crise de

Software

44 cliente cliente

44 profissional profissional



19/156

Mitos do Software (administrativos)

Já temos um manual repleto de padrões e

procedimentos para a construção de software.Isso não oferecerá ao meu pessoal tudo o queeles precisam saber?

Realidade:

Será que o manual é usado? Os profissionais sabem que ele existe?

Ele reflete a prática moderna de desenvolvimento de software? Ele é completo?



20/156

Meu pessoal tem ferramentas de desenvolvimento

de software de última geração; afinal lhescompramos os mais novos computadores.


Realidade:

É preciso muito mais do que os mais recentescomputadores para se fazer um desenvolvimento de

software de alta qualidade.



21/156

Se nós estamos atrasados nos prazos, podemos

adicionar mais programadores e tirar oatraso.


Realidade:

O desenvolvimento de software não é um processomecânico igual à manufatura.

Acrescentar pessoas em um projeto torna-o ainda maisatrasado. Pessoas podem ser acrescentadas, mas

somente de uma forma planejada.



22/156

Uma declaração geral dos objetivos é

suficiente para se começar a escreverprogramas - podemos preencher osdetalhes mais tarde.

Mitos do Software (cliente)

Realidade:

Uma definição inicial ruim é a principal causa de fracassos dos

esforços de desenvolvimento de software.É fundamental uma descrição formal e detalhada do domínio da

informação, função, desempenho, interfaces, restrições de

projeto e critérios de validação.



23/156

Os requisitos de projeto modificam-secontinuamente, mas as mudanças podem serfacilmente acomodadas, porque o software éflexível.

Mitos do Software (cliente)

Realidade:

Uma mudança, quando solicitada tardiamente num projeto, pode ser maior do que mais do que uma ordem de magnitude

mais dispendiosa do que a mesma mudança solicitada nasfases iniciais.



24/156

FASES CUSTO DE MANUTENÇÃODEFINIÇÃO 1 x

DESENVOLVIMENTO 1.5 - 6x

magnitude das mudanças

MANUTENÇÃO 60 - 100x



25/156

Assim que escrevermos o programa e ocolocarmos em funcionamento nosso trabalho

estará completo.

Mitos do Software (profissional)

Realidade:

Os dados da indústria indicam que entre 50 e 70% de todo

esforço gasto num programa serão despendidos depois queele for entregue pela primeira vez ao cliente.



26/156

Enquanto não tiver o programa "funcionando",eu não terei realmente nenhuma maneira deavaliar sua qualidade.

Mitos do Software (profissional)

Realidade:

Um programa funcionando é somente uma parte de uma

Configuração de Software que inclui todos os itens deinformação produzidos durante a construção e manutenção do

software.



27/156

Preocupação: Sistematizar o processo decriação e manutenção de software.

Engenharia de Software

E h d f



28/156

Boehm: Engenharia de software envolve aaplicação prática de conhecimento científicopara o projeto e construção de programas decomputador e a documentação associada

- -


Definições

,

mantê-los.

E h d f



29/156

IEEE Standard Glossary of SoftwareEngineering terminology: Engenharia desoftware é uma abordagem sistemática parao desenvolvimento, operação, manutenção de


Definições

Software: programas de computador,

procedimentos, regras, documentaçãopossivelmente associada, e dados sobre suaoperação.

E h i d S f



30/156

Fairley: Engenharia de software é a

disciplina tecnologica e gerencial preocupadacom a produção sistemática e manutenção deprodutos de software que são desenvolvidos e


Definições

mo ca os no prazo es a e ec o e en rodas estimativas de custo.

E h i d S ft



31/156

abrange um conjunto de três elementos fundamentais:

Métodos, FerramentasMétodos, Ferramentas ee ProcedimentosProcedimentos


r nc pa s me as: me orar a qua a e eprodutos de software, aumentar aprodutividade do pessoal técnico e

aumentar a satisfação do cliente.

E h i d S ft



32/156

métodosmétodos: proporcionam os detalhes


e como azer para cons ru r osoftware

E h i d S ft



33/156

Planejamento e estimativa de projeto

Análise de requisitos de software e desistemas


Projeto da estrutura de dados Algoritmo de processamento

Codificação Teste

Manutenção

E h i d S ft



34/156

ferramentasferramentas: dão suporte automatizadoaos métodos.


ex stem atua mente erramentas para sustentarcada um dos métodos

quando as ferramentas são integradas é

estabelecido um sistema de suporte aodesenvolvimento de software chamado CASE -Computer Aided Software Engineering

En nh i d S ft



35/156

procedimentosprocedimentos: constituem o elo de

ligação entre os métodos eferramentas


seqüência em que os métodos serão aplicados produtos que se exige que sejam entregues

controles que ajudam assegurar a qualidade ecoordenar as alterações

marcos de referência que possibilitam

administrar o progresso do software.




36/156

conjunto de etapas etapas que envolve

métodosmétodos

ferramentasferramentas


procedimentosprocedimentos

Essas etapas são conhecidas como componentesde CICLO DE VIDA DE SOFTWARECICLO DE VIDA DE SOFTWARE

ouou Processo de SoftwareProcesso de Software



37/156

Processos de Software

Processos de Software São atividades envolvidas na produção deum sistema de software.

São representações abstratas desses

processos.



38/156


Todos os processos de software

incluem: Planejamento

Projeto Implementação de software

Validação de software Evolução de software



39/156


Planejamento Porque o sistema de informações deve serconstruído?;

Análise de viabilidade; Comitê de aprovação;

Gerenciamento de Projeto; Plano de projeto.



40/156


Análise Nessa fase responde a perguntas sobre: Quem usará o sistema ?;

O que o sistema fará ?;

Onde será usado ?; Quando será usado?; Estratégia de análise

Sistema no estado Sistema futuro

Proposta do Sistema



41/156


Projeto Decide como o sistema operará, em termosde infra-estrutura de hardware, software

e rede A interface do usuário, os formulários e osrelatórios que serão usados; Os programas, bancos de dados e arquivos

específicos que serão necessários.



42/156


Projeto Especificação do sistema

Coleção de resultados: projeto de arquitetura,ro eto de interface, es ecifica ão de banco de

dados e de arquivos e projeto de programa; Após essa fase a especificação de sistemas

será fornecida equipe de programação e

implementação; No final da fase do projeto:

é feito uma análise de viabilidade e do plano de

trabalho são reexaminados e revisados.

P d f



43/156


Implementação de software Fase durante a qual o sistema é realmenteconstruído;

cara parte do processo de desenvolvimento. Validação de software

Fase onde o software precisa ser validadopara garantir que ele faz o que o clientedeseja.

P d S f



44/156


Evolução do Software O software precisa evoluir para atender àsnecessidades mutáveis do cliente.

Modelos de Processo de Software



45/156


O processo de desenvolvimento de software

pode ser chamado de ciclo de vida do software , pois ele descreve a ‘ vida’ do

implementação, entrega, utilização emanutenção.




46/156


Modelos de Ciclo de Vida do Software

Modelo Cascata (Waterfall Development) ouModelo Queda D’água ou Modelo LinearSe üencial

Modelo em V Desenvolvimento em Paralelo Protótipo Desenvolvimento em Fases ou

Desenvolvimento Exploratório




47/156


Modelos de Ciclo de Vida do Software

Modelo Incremental Modelo Iterativo

Modelo Ágil Processo Racional Unificado (Rational

Unified Process –RUP)




48/156


O processo de desenvolvimento de

software, se não for controlado. ANÁLISE

DE REQUISITO

MANUTEN ÃO

PROJETO DOSISTEMA

IMPLEMENTAÇÃODO PROGRAMA

ENTREGA

TESTE DEUNIDADES

TESTE DO

SISTEMA

TESTE DEINTEGRAÇÃO

PROJETO DOPROGRAMA




49/156


O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE PODE AJUDAR A CONTROLAR A TRANSIÇÃO ENTRE AS ATIVIDADES E OS SUB-

, ,

MELHORAR A COMPREENSÃO DO SISTEMA




50/156


Modelo Cascata (Royce, 1970) ANÁLISE DE

REQUISITO

PROJETO DESISTEMA

Determina quais as funcionalidades que o software deve ter

Teste do desenvolvedor original e teste durante a integração do software

PROJETO DOPROGRAMA

CODIFICAÇÃO

TESTE DEUNIDADES E

DE INTEGRAÇÃO

TESTE DE

SISTE,MA

TESTE DE ACEITAÇÃO

OPERAÇÃO E MANUTENÇÃO

etermina como osoftware deverá prover as

funcionalidades

Determina como osoftware deverá ser

implementado

Construção dosoftware

Teste do software em um ambiente semelhante ao ambiente operacional

Teste para satisfazer ocliente

Atualização e evolução dosoftware para garantir usabilidade constante




51/156

Mo os roc sso Softwar

Modelo Cascata Características:

Os estágios são apresentados em seqüências;

antes do outro começar; Simplicidade – fácil de explicar ao cliente;




52/156

f

Modelo Cascata Vantagens:

Identifica os requisitos do sistema, antes de aro rama ão come ar;

Minimiza as alterações feitas nos requisitos, àmedida que o projeto prossegue.




53/156

Modelo Cascata Desvantagens:

Projetos reais dificilmente seguem o fluxose üencial ue o modelo ro õe;

É difícil estabelecer todos os requisitos logo noinicio, pois sempre existe uma incerteza natural; É necessário que o cliente tenha paciência pois

uma versão executável é possível somente emuma etapa avançada do desenvolvimento doprojeto.




54/156

Modelo Cascata Desvantagens:

Descobertas de erros e omissões nos requisitosori inais durante o ciclo de vida final o era ão

e manutenção) pode envolver a repetição dealguns ou de todos os estágios anteriores doprocesso;

Um sistema também pode exigir uma

significativa repetitiva de trabalho, porque oambiente de trabalho empresarial mudou desdede hora em que a fase de análise começou.

Modelos de Processo de



55/156

Software(aqui) Modelo em V (Ministério de Defesa da

Alemanha, 1992) É uma variação do Modelo em Cascata

OPERAÇÃO E

ANÁLISE DE

REQUISITO

PROJETO DESISTEMA

PROJETO DOPROGRAMA

CODIFICAÇÃO

TESTE DEUNIDADES E

DE INTEGRAÇÃO

TESTE DESISTE,MA

TESTE DE ACEITAÇÃO

Válida requisitos

Verifica o projeto




56/156

Modelo em V Características:

Os testes de unidade e de integração também podemser utilizados para verificar o projeto do programa;

sistema, assegurando que todos os aspectos do projetode sistema foram corretamente implementados; O teste de aceitação conduzido mais pelo cliente do

que o desenvolvedor, valida os requisitos associandouma etapa de teste com cada elemento daespecificação.




57/156

Modelo em V Características:

Caso seja encontrados problemas durante averifica ão e a valida ão, o lado es uerdo do V

pode ser executado novamente para corrigir emelhorar os requisitos, projeto e a codificaçãoantes da execução;




58/156

Modelo Cascata versus Modelo V O enfoque do modelo cascata está nosdocumentos e nos artefatos, o enfoque do

modelo V está na atividade e na corre ão O modelo V torna mais explicitas iteraçõese repetições do trabalho, oculta no modelo

cascata.




59/156

Desenvolvimento em ParaleloPLANEJAMENTO

ANÁLISE

Sub ro eto 1

PROJETO

PROJETO

IMPLEMENTAÇÃO

IMPLEMENTAÇÃO

SISTEMA

PROJETO

PROJETO

IMPLEMENTAÇÃO

IMPLEMENTAÇÃO

Subprojeto 3

Subprojeto 2




60/156

Desenvolvimento em Paralelo Características:

Ele não executa o projeto e a implementação emse üência;

Executa um projeto geral para o sistema inteiroe, em seguida, o divide em uma série desubprojetos distintos que podem ser projetadose implementados em paralelo;

Integração das partes separadas, e o sistema éentregue.




61/156

Desenvolvimento em Paralelo Vantagens:

Reduz o tempo de planejamento necessário paraentre ar um sistema;

Menos chances de alterações que ocorrem noambiente de trabalho da empresa causarem umarepetição de trabalho.




62/156

Desenvolvimento em Paralelo Desvantagens:

Às vezes os subprojetos não são complementeinde endentes;

As decisões de projeto tomadas em umsubprojeto podem afetar outro, e o final doprojeto talvez exija significativos esforços deintegração.




63/156

ProtótipoPLANEJAMENTO

ANÁLISE

PROJETO

IMPLEMENTAÇÃO

PROTÓTIPO DOSISTEMA

IMPLEMENTAÇÃO

SISTEMA




64/156

Protótipo Características:

Análise, projeto e implementação são realizadossimultaneamente;

Comentários dos usuários serão usados parareanalisar, reprojetar e reimplementar gerando

o segundo protótipo;

O ciclo continua até que o analista, usuário e oresponsável concordem que o protótipo fornecefuncionalidade suficiente para ser usado naempresa.




65/156

Protótipo Vantagens:

Fornece muito rapidamente um sistema com oqual os usuários podem interagir;

os ra que a equ pe e pro e o es a

trabalhando; Ajuda a refinar mais rapidamente os requisitos

reais

Os usuários em vez de entender umaespecificação no papel, os usuários podeminteragir com o protótipo para entender melhoro que ele pode ou não fazer ;




66/156

Protótipo Desvantagens;

Usuário não sabe que o software que ele vê, nãoconsiderou a ualidade lobal e amanutenibilidade a longo prazo (não aceita aidéia de que a versão final vai ser construída, eforça a utilização do protótipo como produtofinal;

desenvolvedor freqüentemente faz umaimplementação comprometida (utilizando o queestá disponível) em razão do tempo




67/156

Desenvolvimento em Fases: Incrementos e IteraçõesPLANEJAMENTO

ANÁLISE

PROJETO

ANÁLISE

IMPLEMENTAÇÃO

SISTEMAVERSÃO 1

PROJETO

IMPLEMENTAÇÃO

ANÁLISE

SISTEMAVERSÃO 2

PROJETO

IMPLEMENTAÇÃO

ANÁLISE

SISTEMAVERSÃO 3




68/156

Desenvolvimento em Fases Características:

A fase de análise identifica o conceito desistema lobal,e a e ui e de ro eto, os usuáriose o responsável categorizam o sistema em váriasversões;

Os requisitos mais importantes e fundamentaissão reunidos na primeira versão na primeira

versão do problema; Combina novas idéias e questões que surgem da

experiência dos usuários com a versão 1.




69/156

Desenvolvimento em Fases Vantagens:

Coloca rapidamente um sistema útil na mão dosusuários;

Agrega valor mas rápido que se o sistema fosseentregue após a conclusão; Os usuários começam a trabalhar com o sistema

mais cedo, é mais provável que identifiquem

requisitos adicionais importantes mais cedo doque em situações de projeto estruturado.




70/156

Desenvolvimento em Fases Desvantagens:

Os usuários começam a trabalhar com sistemasue estão intencionalmente incom letos;

É crítico identificar os recursos maisimportantes e úteis e incluí-los na primeiraversão.




71/156

Modelo Incremental (Mills et al., 1980)

DEFINIR ESBOÇODOS REQUISITOS

ATRIBUIR REQUISITOS DO SISTEMA

PROJETAR ARQUITETURADO SISTEMA

DESENVOLVER INCREMENTO DO SISTEMA

INTEGRAR INCREMENTO

VALIDAR INCREMENTO

VALIDAR SISTEMA

VALIDAR SISTEMA

DESENVOLVER INCREMENTO DO SISTEMA




72/156

Desenvolvimento Incremental




73/156

Modelo Incremental Características:

É uma das abordagem do desenvolvimento em fases; Não existe a necessidade de utilizar o mesmo processo

para o desenvolvimento de cada incremento; Quando as especificações estão bem definidas, o

modelo cascata pode ser utilizado para aqueleincremento, mas quando a especificação for maldefinida, poderá ser utilizado um modelo dedesenvolvimento evolucionário.

Uma recente evolução dessa abordagem incremental,chamada de ‘programação extrema’.




74/156

Modelo Iterativo Características:

É uma das abordagens de desenvolvimento emfases

Entrega um sistema completo desde o começo eentão muda a funcionalidade de cada subsistemaa cada nova versão




75/156

Modelo Espiral (Boehm 1988)Planejamento Análise dos riscos

Análise dos riscos baseadanos requisitos iniciais

Coleta inicial dos requisitose planejamento do projeto

Engenharia

Análise dos riscos baseadana reação do cliente

Na direção de um sistemaconcluído

Protótipo de software inicialProtótipo no nível seguinte

Prot. construído pela Eng.

Avaliação do cliente

Planejamento baseadonos comentários docliente

Avaliação do cliente




76/156

Modelo Espiral Características: 1. Planejamento: determinação dos objetivos,

lternativas e restri ões.

São definidos os objetivos específicos para essa fase doprojeto.São identificadas as restrições para o processo e oproduto e é preparado um plano de gerenciamento detalhado.São identificados os riscos do projeto e, dependendo dosriscos, poderão ser planejado estratégias alternativas.

/




77/156

Modelo Espiral Características: 2. Análise de riscos: análise de alternativas e

identifica ão/resolu ão dos riscos.

Para cada um dos riscos de projeto identificados, é realizadauma análise detalhada e são tomadas providências parareduzir esses riscos. Por exemplo, se houver um risco de osrequisitos serem inadequados, poderá ser desenvolvidos umprotótipo.

78/156




78/156

Modelo Espiral Características:

3. Engenharia: desenvolvimento do produto no “nívelseguinte”. ,

desenvolvimento para o sistema. Por exemplo, se foremdominantes os riscos relacionados à interface com o usuário,um modelo apropriado de desenvolvimento pode ser aprototipação evolucionária. Se os riscos de segurança forem aprincipal consideração, o desenvolvimento com base em

transformações formais poderá ser o mais apropriado e assimpor diante. O modelo cascata poderá ser o modelo dedesenvolvimento mais apropriado se o risco principalidentificado for o da integração de sistemas.

79/156




79/156

Modelo Espiral Características: 4. Avaliação feita pelo cliente: avaliação dos

resultados da en enharia.

O projeto é revisto e é tomada uma decisão sobrecontinuar com o próximo loop da espiral. Se a decisãofor continuar, serão traçados os planos para a próximafase do projeto.

80/156




80/156

Modelo Ágil

PLANEJAMENTO

ANÁLISE

PROJETO

IMPLEMENTAÇÃO

SISTEMA

81/156




81/156

Modelo Ágil Programação Extrema

Características: Usa codificação simples;

Teste contínuo; Executado por dois desenvolvedores; Funcionalidade do sistema cresce ao longo do tempo; Refactoring – que é um modo disciplinado de reestruturar o

código para mantê-lo simples; Recomendado para pequenos grupos de desenvolvimentos; Trabalha muito bem com tecnologias orientadas a objetos.

82/156




82/156

Processo Racional Unificado (RUP)PLANEJAMENTO

CASOS DE USOS

PROJETO

ANÁLISE

ITERAÇÃO 3

IMPLEMENTAÇÃO

ITERÃÇÃO 1

PROJETO

IMPLEMENTAÇÃO

ANÁLISE

ITERAÇÃO 2

PROJETO

IMPLEMENTAÇÃO

ANÁLISE

83/156




83/156

Processo Racional Unificado Todos os projetos RUP devem seguir quatro

fases. 1. Concepção Faz uma avaliação inicial de um projeto. Normalmente, na

concepção, você decide se vai comprometer fundos para

realizar uma fase de elaboração 2. Elaboração

Identifica os casos de uso principais do projeto e elabora osoftware em iterações para reorganizar a arquitetura do

sistema. Ao final da elaboração você deve ter uma boa idéiados requisitos e um esqueleto funcional do sistema, que atuecomo semente de desenvolvimento. Em particular, você deveter encontrado resolvido os principais riscos do projeto.

84/156




Processo Racional Unificado

Todos os projetos RUP devem seguir quatrofases 3 Constru ão

Continua o processo, desenvolvendo funcionalidadesuficiente para o lançamento.

4. Transição Inclui várias atividades de último estágio que você nãofaz de forma interativa. Isso pode incluir a

distribuição para o centro de dados, treinamento dosusuários e coisas parecidas.

Documents

Processos de Software [Compatibility Mode]