MODELOS DE PROCESSOS DE SOFTWARE 2

Prévia do material em texto

Modelos de Processos 
de Software
Material Teórico
Responsável pelo Conteúdo:
Prof. Me. Artur Marques
Revisão Textual:
Prof.ª Dr.ª Luciene Oliveira da Costa Granadeiro
Processos de Software Tradicionais – Parte B
• Processo Iterativo;
• Processo Evolucionário;
• Processo Unificado: RUP.
• Conhecer a evolução dos processos de software rumo ao desenvolvimento ágil.
OBJETIVO DE APRENDIZADO
Processos de Software
Tradicionais – Parte B
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas:
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você tam-
bém encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão sua 
interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Processos de Software Tradicionais – Parte B
Processo Iterativo
O desenvolvimento iterativo é, em suma, uma maneira de dividir o processo de 
desenvolvimento de software de um aplicativo maior em pedaços menores. Por-
tanto, depois que a fase inicial de planejamento é concluída, várias outras etapas 
são repetidas, criando ciclos. À medida que cada ciclo é concluído, o software é 
aprimorado e iterado.
Cada uma das iterações inclui todos os processos de desenvolvimento de software: 
a aquisição e análise de requisitos, a preparação de especificações, a própria imple-
mentação, o teste e o lançamento. No entanto, em uma única iteração, apenas um 
componente ou versão separado é desenvolvido, mas não o projeto inteiro.
A próxima iteração resulta em uma nova funcionalidade ou em uma funciona-
lidade existente aprimorada do produto. O conjunto completo de requisitos corri-
gidos pelos limites do projeto é implementado após a conclusão da iteração final.
É um processo de desenvolvimento que ajuda na descoberta de erros cedo. 
Quando os problemas são detectados no final do processo, isso gera despesas 
substanciais. Esse modelo de ciclo de vida iterativo não requer uma especificação 
completa dos requisitos para iniciar. Primeiro, uma parte da funcionalidade é de-
senvolvida e ela se torna a base usada para determinar outros requisitos.
A versão atual pode não ser perfeita, mas o principal é que funciona. Quando 
entendemos nosso objetivo final, nós nos esforçamos para que todos os nossos 
passos sejam bem-sucedidos e cada versão funcione.
Por se tratar de um SDLC, o processo iterativo possui fases bem determinadas, 
vamos conhecê-las:
• Fase 1: é um estágio de planejamento, usado para mapear detalhes específi-
cos, incluindo requisitos de hardware ou software, além de preparar os demais 
estágios que seguirão;
• Fase 2: é um estágio de análise, que é executada para estabelecer os modelos de 
banco de dados e a lógica de negócios que serão necessárias. O estágio de design 
também ocorre aqui, em que são estabelecidos requisitos técnicos necessários 
para atender a quaisquer necessidades determinadas no estágio de análise;
• Fase 3: é onde começam os processos de implementação e codificação. Qual-
quer documentação de especificação, planejamento e design é implementada 
e codificada neste momento;
• Fase 4: quando fazemos os testes após a iteração de compilação atual ser 
codificada e implementada. Esses procedimentos de teste estão em vigor para 
identificar quaisquer problemas ou bugs que apareceram;
• Fase 5: encerradas as fases 1, 2, 3 e 4, é necessária uma avaliação completa 
de todo o desenvolvimento até aqui. A equipe e os clientes ou outras partes 
são capazes de examinar o projeto e oferecer feedback sobre o que precisa ou 
pode mudar.
8
9
Então, seguindo as 5 fases, dizemos que a iteração mais recente foi feita, bem 
como foram feitos quaisquer feedback de avaliação, dessa maneira, são retornados 
ao estágio de planejamento e desenvolvimento (fase 1) para que o processo se 
repita novamente até que a entrega final seja realizada e o projeto, então, encerre-
-se. O modelo iterativo é adequado para organizações ágeis, especialmente para 
aquelas com equipes menores e mais ágeis. Ele é facilmente adaptável, com itera-
ções frequentes e constantes fluindo regularmente, a adaptabilidade rápida é outro 
benefício, permitindo que as empresas se adaptem às necessidades do projeto ou 
cliente rapidamente.
Conforme a Lvivity (2019), os pontos fortes e fracos mais importantes que obte-
mos utilizando o processo iterativo são:
Pontos Fortes:
• Início rápido do projeto. Você inicia seu projeto em um tempo mais 
curto, mesmo que ele não tenha funcionalidade completa e até mesmo 
quando já estamos ganhando dinheiro com ele.
• Redução de risco. Os problemas são identificados e resolvidos durante 
as iterações.
• Flexibilidade para modificações. Se, em um determinado estágio, você 
entender que uma função específica se tornou uma prioridade, poderá 
começar a implementá-la na próxima iteração sem aguardar a conclu-
são de todo o projeto.
• Lançamento regular de novas versões. Usando a abordagem de de-
senvolvimento iterativo, novas versões são lançadas regularmente e o 
projeto está constantemente avançando.
• Feedback eficiente. As equipes de desenvolvimento se comunicam ati-
vamente com os clientes, criando um produto que atenda às suas neces-
sidades e objetivos de negócios.
• Lançamento imediato do MVP. Esse modelo permite levar o produto 
ao mercado e iniciar seu uso muito mais cedo do que no caso de um 
modelo em cascata.
• Maior qualidade. Uma abordagem iterativa permite criar uma arquitetura 
mais robusta, pois todos os erros são corrigidos durante várias iterações.
Pontos Fracos:
• Sem orçamento fixo ou prazos: Com uma abordagem iterativa, espe-
cialmente no caso de um projeto complexo, os prazos e um orçamento 
dependem dos recursos funcionais e podem sofrer alterações ao longo 
do processo de desenvolvimento.
• Forte envolvimento do cliente no processo. Os clientes precisam par-
ticipar ativamente do trabalho no projeto, discutir e aprovar modifica-
ções no projeto. Alguns clientes podem se sentir desconfortáveis com 
isso, e o modelo habitual de desenvolvimento em cascata provavelmen-
te funcionará melhor para eles.
9
UNIDADE Processos de Software Tradicionais – Parte B
• Possíveis problemas com a arquitetura. Sem requisitos rígidos e um pla-
no global bem desenvolvido, a arquitetura do produto de software pode 
sofrer e, para trazê-la de volta a uma condição razoável, você pode 
precisar de recursos adicionais. (LVIVITY, 2019, p. 3)
Waterfal I
Elaboração
Construção
Transição
Iniciação IterativoHora
Risco
Figura 1 – Ciclo de vida Iterativo. “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 diminuíram”
Processo Evolucionário
É uma combinação do modelo iterativo e incremental. Alguns requisitos iniciais 
e a previsão da arquitetura precisam ser feitos. É melhor para produtos de software 
que tenham seus conjuntos de recursos redefinidos durante o desenvolvimento por 
causa do feedback do usuário e de outros fatores. O modelo de desenvolvimento evo-
lucionário divide o ciclo de desenvolvimento em modelos menores e incrementais em 
cascata, nos quais os usuários podem obter acesso ao produto no final de cada ciclo.
O modelo evolutivo sugere a divisão do trabalho em partes menores, priorizan-
do e entregando essas partes ao cliente, uma a uma. A principal vantagem é que 
a confiança do cliente aumenta à medida que ele recebe constantemente bens ou 
serviços quantificáveis desde o início do projeto para verificar e validar seus requi-
sitos. O modelo permite alterar os requisitos, bem como todo o trabalho dividido 
em partes.
Como todo SDLC, não o utilizamos em qualquer lugar para qualquer projeto, 
mas em casos de grandes projetos em que encontraremos módulos para implemen-
tação incremental, ou usamos quando o cliente deseja começar a usar os principais 
recursos, em vez de esperar pelo software completo ser feito. Usamos para o 
desenvolvimento de software orientado a objetos, porque o sistema pode ser facil-
mente dividido em unidades em termos de objetos.
Ambler (2019) coloca da seguinte forma, “o desenvolvimento evolucionário 
é uma abordagem iterativa e incremental para o desenvolvimento de software.” 
E acrescenta:
10
11
Em vez de criar um artefato abrangente, como uma especificação de 
requisitos, que você revise e aceite antes de criar um modelo de design
abrangente (e assim por diante), evolua os artefatos críticos de desenvol-
vimento ao longo do tempo de maneira iterativa. Em vez de criar e, em 
seguida, entregar seu sistema em uma única versão “big bang”, você o 
entrega gradualmente ao longo do tempo. (AMBLER, 2019, p. 2) 
O ciclo evolucionário segue as seguintes leis:
• Le i da mudança contínua: es ta lei declara que qualquer sistema de software
que represente alguma realidade do mundo real passa por mudanças contínuas 
ou se torna progressivamente menos útil nesse ambiente;
• Lei da complexidade crescente: à medida que um programa em evolução 
muda, sua estrutura se torna mais complexa, a menos que sejam feitos esforços 
efetivos para evitar esse fenômeno;
• Le i de conservação da estabilidade da organização: ao longo da vida de 
um programa, a taxa de desenvolvimento desse programa é aproximadamente 
constante e independente do recurso dedicado ao desenvolvimento do sistema;
• Le i de conservação da familiaridade: esta lei afirma que, durante a vida ativa 
do programa, as alterações feitas na liberação sucessiva são quase constantes.
Conforme escritos de Teófilo (2012), o desenvolvimento evolucionário baseia-se 
na ideia de desenvolvimento de uma implementação inicial, expondo o resultado 
aos comentários do usuário e refinando esses comentários por meio de várias ver-
sões até que seja desenvolvido um sistema adequado.
DesenvolvimentoEsboço
Especi�cação
Validação
Atividades
Simultâneas
Versões
intermediárias
Versão inicial
Versão �nal
Figura 2 – Mapa Geral da abordagem Evolutiva
Existem dois tipos fundamentais de desenvolvimento evolucionário:
• Des envolvimento Exploratório: é um método experimental de desenvolvi-
mento de sistemas baseado em pesquisa usado para desenvolver e projetar 
um sistema ou produto de computador. O modelo exploratório é b aseado no 
11
UNIDADE Processos de Software Tradicionais – Parte B
planejamento e na revisão de possíveis cenários e abordagens até que, o que 
parece ser ideal seja selecionado. É um tipo de modelo de prototipagem, mas 
é muito mais aberto e menos formal do que outros sistemas. Como tal, nem 
sempre é rentável e existe o risco de que os resultados do modelo exploratório 
sejam inferiores ao ideal. Vamos enumerar algumas etapas:
 » Um ponto de partida é determinado para o trabalho. Todas as informações 
disponíveis são reunidas na tentativa de ter uma ideia do que o novo sistema 
deverá fazer e como isso pode ser feito;
 » Um sistema rudimentar de primeira geração é montado, com base nas infor-
mações coletadas e nas ideias formuladas na primeira etapa;
 » O sistema de primeira geração é testado para ver como funciona, o que pode 
e o que não pode fazer e o que pode ser feito para melhorá-lo;
 » Um sistema de segunda geração é desenvolvido a partir do primeiro, com 
base nas melhorias propostas na etapa anterior;
 » O sistema de segunda geração é testado, como foi o primeiro. Seu desempe-
nho é avaliado e possíveis melhorias, determinadas;
 » O processo é repetido quantas vezes forem necessárias para obter a satisfa-
ção do usuário, ou até que seja decidido que o projeto não é viável;
 » A manutenção de rotina é realizada continuamente para evitar falhas em 
larga escala e minimizar o tempo de inatividade.
 Então, em linhas gerais, apesar de ele se assemelhar ao modelo de prototi-
pagem, ele começa em um ponto de partida mais nebuloso e prossegue de 
maneira menos formal. Esse processo não é particularmente econômico e, às 
vezes, resulta em sistemas abaixo do nível almejado, portanto, deve ser usado 
apenas quando não existir uma alternativa viável;
• Prototipação Throwaway: a prototipagem descartável é um método de de-
senvolvimento que emprega mecanismos técnicos para reduzir o risco em um 
projeto. Para algumas empresas, em praticamente qualquer empreendimento 
técnico que você possa imaginar, há muita pressão para continuar o desenvol-
vimento do primeiro protótipo ou rascunho de um projeto. Para clientes, isso 
geralmente ocorre devido à tentativa de economizar custos e reutilizar aquilo 
que obviamente levou à próxima etapa de um projeto específico. Com a proto-
tipagem descartável, você decide conscientemente criar um conjunto específico 
de funcionalidades para um aplicativo ou, de fato, desenvolver todo o protótipo 
do aplicativo em um esforço para explorar completamente o que está tentando 
realizar em termos de objetivos e menos sobre a totalidade das funcionalidades.
 Então, percebemos que o protótipo descartável é barato e rápido, projetado 
para modelar uma ideia ou recurso. Eles são comumente usados nas fases 
iniciais do design, quando muitas ideias ainda estão sendo consideradas. Por-
tanto, é mais apropriada na fase de aquisição do projeto, onde os protóti-
pos demonstram a viabilidade de novos conceitos e convencem os possíveis 
12
13
patrocinadores a financiar os projetos de desenvolvimento propostos. Nessa 
situação, os recursos disponíveis são limitados e a capacidade de transmitir os 
benefícios de uma nova abordagem com uma demonstração de custo muito 
baixo é essencial para criar um projeto.
Nesse ponto o
protótipo é descartado
Fase de desenvolvimento
do sistema atual
Estabelecer as
especi�cações
Desenvolver
o protótipo
Desenhar e
implementar
o sistama
Validar o 
sistema
Avaliar o
protótipo
Especi�car o
sistema
Figura 3 – Modelo de prototipagem descartável
Vantagens da prototipagem descartável:
• Economizar tempo e dinheiro;
• Promover a consistência do design da interface do usuário;
• Permitir o envolvimento precoce do cliente;
• Apresentar maneiras concretas de mostrar e acreditar em gerenciamento para 
gerenciamento, em vez de apenas dizer ao administrador;
• Os profissionais de marketing e planejadores devem garantir que as necessida-
des dos clientes sejam atendidas.
Desvantagens da prototipagem descartável:
• Há confusão do usuário para protótipos e sistemas concluídos;
• Tempo de desenvolvimento do protótipo é excessivo;
• Normalmente, ele não geracódigo reutilizável;
• O processo de desenvolvimento fica mais lento quando colocado sob controle 
formal de configuração;
• Não há um ponto de parada claro.
Em suma, o objetivo da prototipagem descartável é garantir que os requisitos 
do sistema sejam validados e compreendidos claramente. O pr otótipo descartável 
NÃO é considerado parte do sistema final. Simplesmente exis te para ajudar a en-
tender e reduzir o risco de requisitos mal definidos. O sistema completo está sendo 
desenvolvido juntamente com os protótipos e incorpora as alterações necessárias. 
13
UNIDADE Processos de Software Tradicionais – Parte B
A vantagem dessa abordagem é a velocidade com que o protótipo é montado. Ele 
também concentra o usuário em apenas um aspecto do sistema, mantendo seus 
comentários precisos.
Processo Unificado: RUP
A partir do uso de elementos de outros modelos de desenvolvimento de software 
iterativos, a estrutura do RUP foi criada inicialmente pela Rational Software 
Corporation, adquirida pela IBM em 2003.
Não é um modelo de desenvolvimento concreto, mas pretende ser adaptável e 
adaptado às necessidades específicas do projeto, equipe ou organização.
Trata-se de uma metodologia de desenvolvimento de software ágil, que divide o 
ciclo de vida do projeto SDLC em quatro fases:
1. Início;
2. Elaboração;
3. Construção;
4. Transição.
Conforme os escritos de Powell-Morse (2017), o objetivo geral do RUP leva em 
conta a implementação de abordagens comercialmente comprovadas para o desen-
volvimento de software num SDLC, e comenta sobre as 4 fases da seguinte forma:
Fase de Iniciação: Durante a iniciação, a ideia básica e a estrutura do 
projeto são determinadas. A equipe se sentará e determinará se vale a 
pena prosseguir com o projeto, com base no objetivo proposto do pro-
jeto, nos custos estimados (monetário e tempo) e quais recursos serão 
necessários para concluir o projeto assim que o OK for dado. A conclusão 
da fase de iniciação é o , que consiste nos seguintes critérios de avaliação: 
ciclo de vida, grandes marcos (entregas) do projeto, grau de concorrência 
das partes interessadas na definição do escopo e, claro, nas estimativas 
de custo, cronograma e, por fim, o entendimento de requisitos, conforme 
evidenciado pela fidelidade dos casos de uso principais. 
Fase de Elaboração: O objetivo dessa fase é analisar os requisitos e a 
arquitetura necessária do sistema. O sucesso desta fase é particularmente 
crítico, pois o marco final dessa fase significa a transição do projeto de 
baixo risco para alto risco, uma vez que o desenvolvimento e a codificação 
reais ocorrerão na fase seguinte. Que perguntas esperamos responder:
A visão do produto é estável?
A arquitetura é estável?
A demonstração executável mostra que os principais elementos de risco 
foram abordados e resolvidos com credibilidade?
14
15
O plano para a fase de construção é suficientemente detalhado e preciso? 
É feito backup com uma base crível de estimativas?
Todas as partes interessadas concordam que a visão atual pode ser alcan-
çada se o plano atual for executado para desenvolver o sistema completo, 
no contexto da arquitetura atual?
A despesa real de recursos versus a despesa planejada é aceitável?
Fase de construção: É quando ocorre a codificação e a implementação 
de todos os recursos do aplicativo. Este período também é onde as inte-
grações com outros serviços ou software existente devem ocorrer. O final 
dessa fase é medido pela conclusão do se deve fazer. 
As respostas para as perguntas abaixo deverão estar claras:
A versão deste produto é estável e madura o suficiente para ser implanta-
da na comunidade de usuários?
Todas as partes interessadas estão prontas para a transição para a comu-
nidade de usuários?
As despesas reais de recursos versus as despesas planejadas ainda 
são aceitáveis?
Fase de transição: É quando o produto acabado é finalmente liberado e 
entregue aos clientes. No entanto, é mais do que apenas o processo de 
implantação; ele também deve lidar com todo o suporte pós-lançamento, 
correções de bugs, patches e assim por diante. As perguntas a serem 
respondidas nessa fase são:
O usuário está satisfeito?
As despesas reais com recursos versus as despesas planejadas ainda 
são aceitáveis? (POWELL-MORSE, 2017, p. 4)
MGP
MDS
Construção04 Elaboração03
Iniciação02
Proposta de projeto01
Transição05
RUP
Figura 4
Ciclo de vida RUP. DATASUS, 2019, p. 1. “[...] o ciclo de vida do software
do RUP é dividido em 4 fases sequenciais, cada uma concluída por um mar-
co principal, ou seja, cada fase é basicamente um intervalo de tempo entre 
dois marcos principais. A cada final de fase, uma avaliação é executada para 
15
UNIDADE Processos de Software Tradicionais – Parte B
determinar se os objetivos da fase foram alcançados. Uma avaliação satis-
fatória permite que o projeto passe para a próxima fase. Cada fase possui 
suas próprias metas, seu próprio estilo de iteração e geralmente customiza 
suas tarefas e produtos de trabalho de forma diferente[...]”; disponível em: 
<https://bit.ly/31tRHSw> acessado em: 03/12/2019.
Iniciação
Inicial Elab.nº 1
Elab.
nº 2
Const.
nº 1
Const.
nº 2
Const.
nº 3
Trans.
nº 1
Trans.
nº 2
Elaboração Construção Transição
Fases
Iterações
DISCIPLINAS
Modelagem de Negócios
Requisitos
Análise e Design
Implementação
Teste
Implantação
Geren. de
Con�guração e Mudança
Gerenciamento de Projeto
Ambiente
Figura 5 – O ciclo de vida do RUP
Basicamente, podemos criar grupos de disciplinas no RUP respeitando suas 
afinidades e entregas, a saber:
• Análise e Design;
• Modelagem de Negócios;
• Gerenciamento de Configuração e Mudança;
• Desdobramento, desenvolvimento;
• Meio Ambiente;
• Implementação;
• Gerenciamento de Projetos;
• Exigências;
• Teste.
Vamos comentar um pouco sobre cada uma delas em nível de esclarecimento:
Análise e design: possui como objetivos, transformar os requisitos em 
um design do futuro sistema. E desenvolver uma arquitetura robusta para 
o sistema. Leva em consideração a adaptação do design para corres-
ponder ao ambiente de implementação, projetando-o para desempenho. 
Se relaciona com outros elementos como por exemplo: A disciplina Re-
quisitos fornece a entrada principal para Análise e Design. A disciplina 
16
17
Implementação implementa o design. A disciplina Teste, testa o sistema 
projetado durante a Análise e o Design. A disciplina Ambiente desenvol-
ve e mantém os artefatos de suporte usados durante a Análise e o Design. 
A disciplina Gerenciamento do Projeto planeja o projeto e cada iteração 
descrita em um Plano de Iteração.
Modelagem de Negócios: Os objetivos da modelagem de negócios são: 
Compreender os problemas atuais na organização-alvo e identificar po-
tenciais de melhoria.
Avaliar o impacto da mudança organizacional. Garantir que clientes, usu-
ários, desenvolvedores e outras partes tenham um entendimento comum 
da organização. Derivar os requisitos de sistema de software necessários 
para apoiar a organização de destino. Entender como um sistema de 
software a ser implantado se encaixa na organização. Um organograma 
não é suficiente para entender como uma empresa funciona. Também 
precisamos de uma visão dinâmica dos negócios. Um modelo de negó-
cios fornece uma visão estática da estrutura da organização e uma visão 
dinâmica dos processos dentro da organização. Como produto dessa fase 
os seguintes artefatos são construídos: Visão de Negócios, Documento de 
arquitetura de negócios, Especificação de negócios suplementar, Regras 
de Negócios (como um documento e / ou como elementos no Modelo de 
Análise de Negócios) e Glossário de Negócios.
Gerenciamento de configuração e mudança: é essencial para contro-
lar os inúmeros produtos de trabalho produzidos por muitas pessoas que 
trabalham em um projeto comum. O controle ajuda a evitar confusão dis-
pendiosa e garante que os Produtos de Trabalho resultantes não entrem 
em conflito.
Desdobramento e desenvolvimento: descreve três modosde implanta-
ção do produto, a instalação personalizada, a oferta de produtos “shrink
wrap” e o acesso ao software pela internet.
Meio ambiente: organiza os elementos do método que fornecem o am-
biente de desenvolvimento de software que suporta a equipe de desen-
volvimento, incluindo processos e ferramentas. O principal objetivo é 
fornecer à organização de desenvolvimento de software, processos e fer-
ramentas, que apoiarão a equipe de desenvolvimento.
Implementação: explica como desenvolver, organizar, testar a unidade e 
integrar os componentes implementados com base nas especificações do 
projeto. Possui como objetivos: definir a organização do código, em termos 
de subsistemas de implementação organizados em camadas; implementar 
os elementos de design em termos de elementos de implementação (arqui-
vos de origem, binários, programas executáveis e outros); testar os com-
ponentes desenvolvidos como unidades e integrar os resultados produzidos 
por implementadores (ou equipes) individuais em um sistema executável.
Gerenciamento de projetos: se concentra no planejamento do projeto, 
gerenciamento de riscos, monitoramento de progresso e métricas. O foco 
aqui é facilitar a tarefa, fornecendo algum contexto para o Gerenciamento 
de Projetos. Não é uma receita para o sucesso, mas apresenta uma aborda-
gem para gerenciar o projeto que aumentará acentuadamente as chances 
de fornecer software bem-sucedido. Os principais objetivos são: Fornecer 
17
UNIDADE Processos de Software Tradicionais – Parte B
uma estrutura para gerenciar projetos de uso intensivo de software; forne-
cer diretrizes práticas para o planejamento, pessoal, execução e monitora-
mento de projetos e fornecer uma estrutura para gerenciar riscos.
Exigências: explica como obter solicitações das partes interessadas e 
transformá-las em um conjunto de requisitos de produtos de trabalho que 
definem o escopo do sistema a ser construído e fornecem requisitos deta-
lhados para o que o sistema deve fazer. Possui como objetivos: Estabele-
cer e manter acordo com os clientes e outras partes interessadas sobre o 
que o sistema deve fazer. Fornecer aos desenvolvedores do sistema uma 
melhor compreensão dos requisitos do sistema. Definir os limites do (de-
limitar) o sistema. Fornecer uma base para o planejamento do conteúdo 
técnico das iterações. Fornecer uma base para estimar o custo e o tempo 
para desenvolver o sistema. Definir uma interface de usuário para o siste-
ma, com foco nas necessidades e objetivos dos usuários.
Teste: fornece orientação sobre como avaliar e avaliar a qualidade do 
produto. A disciplina Teste atua como um provedor de serviços para as 
outras disciplinas em muitos aspectos. O teste se concentra principal-
mente na avaliação ou avaliação da Qualidade do Produto, que é realiza-
da através dessas práticas principais: Encontre e documente defeitos na 
qualidade do software. Aconselhar sobre a qualidade percebida do sof-
tware. Valide e prove as suposições feitas nas especificações de projeto 
e requisitos por meio de demonstração concreta. Valide se o produto de 
software funciona como projetado. Valide se os requisitos foram imple-
mentados adequadamente. (RICHARDSON, 2006, p. 1, 2)
RUP funciona muito melhor quando seguimos 6 práticas a saber:
• Desenvolvimento de software de forma iterativa: abordar os elementos de 
alto risco em todas as etapas dos projetos. Isso permite obter uma compre-
ensão crescente do problema e fazer as alterações necessárias até chegar à 
solução mais razoável;
• Gerenciamento de requisitos: descreve como organizar e acompanhar os 
requisitos de funcionalidade, documentos, mudança de etapas no processo, 
decisões e necessidades de negócios;
• Utilizar arquitetura de sistemas baseada em componentes: estruturar a 
arquitetura do sistema em componentes reutilizáveis não apenas no projeto em 
questão, mas também em projetos futuros. Foco é o reúso de componentes;
• Modelamento visual do software: mostra como criar um modelo visual de 
um software para capturar a estrutura e o comportamento da arquitetura e 
dos componentes;
• Verificação da qualidade do software: permite avaliar e controlar a qualida-
de de todas as atividades durante o desenvolvimento do software;
• Controle de alterações no software: dá a capacidade de controlar, rastrear e 
monitorar alterações que favorece o desenvolvimento constante e bem-sucedido 
do software. Também ajuda a criar um espaço de trabalho seguro, une e motiva 
a equipe, fazendo com que funcionem como um time de alta performance.
18
19
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
RUP — Processo Unificado da Rational: visando a produção de software com MAIS QUALIDADE
https://youtu.be/LLAqBv9YY2k
Engenharia de Software - Modelo Incremental
BAGATINI, D.
https://youtu.be/-SVZ9eBqIyY
Engenharia de Software - Modelo Incremental
BAGATINI, D.
https://youtu.be/-SVZ9eBqIyY
Engenharia de software – Modelos de Processo Evolucionário
REINOSO, L. F. 
https://youtu.be/Ud4_yiiWQaU
Prototipação
FATTO CONSULTORIA E SISTEMAS.
https://youtu.be/L81RtZzzGkI
19
UNIDADE Processos de Software Tradicionais – Parte B
Referências
AMBLER, S. W. Desenvolvimento evolutivo de software: como as atividades 
de dados se encaixam. 2019. Disponível em: <http://www.agiledata.org/essays/
evolutionaryDevelopment.html> Acessado em: 03/12/2019.
LVIVITY. Modelo Iterativo no Desenvolvimento de Software: Prós e Con-
tras. 2019. Disponível em: <https://lvivity.com/iterative-model>. Acessado em: 
03/12/2019.
POWELL-MORSE, A. Rational Unified Process: O que é e como você o utiliza? 
2017. P. 4. Disponível em: <https://airbrake.io/blog/sdlc/rational-unified-process 
acessado em 03/12/2019>.
RICHARDSON, M. Agrupamento de Disciplinas: Disciplinas do RUP. 2006. 
P. 1 e 2. Disponível em: <http://www.michael-richardson.com/processes/rup_ 
classic/core.base_rup/disciplines/rup_test_discipline_9DFAFB2F.html>. Acessado 
em 03/12/2019.
TEÓFILO, D. Processos de Software. 2012. Disponível em: <https://danielteofilo.
wordpress.com/2012/01/08/processos-de-software/>. Acessado em: 11/12/2019
20