Processo

Inserir Título
de Software
Aqui
Inserir Título Aqui
Métodos e Ferramentas Ágeis

Responsável pelo Conteúdo:

Prof. Me. Afonso Maria Luiz Pavão

Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
 Métodos e Ferramentas Ágeis

Fonte: iStock/Getty Images

Nesta unidade, trabalharemos os seguintes tópicos:
• Introdução;
• Scrum;
• XP – Extreme Programing;
• Test Driven Development;
• Agile Unified Process – AUP;
• Agile Model Driven Development – AMDD;
• Disciplined Agile Delivery – DAD;
• Enterprise Unified Process – EUP.

Objetivos
• Descrever métodos para processos ágeis.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o
último momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Métodos e Ferramentas Ágeis

Contextualização
Para começarmos nossos estudos, proponho a você a leitura do artigo The Impact
of an Agile Methodology on Software Development Costs, de Kristin Fergis.

Você poderá acessá-lo no link: https://goo.gl/LTo5Ct

A partir dessa leitura, pretendo a clarificação e a desmistificação sobre a utilização

dessa multidão de Processos Ágeis que você está aprendendo e porque eles são tão ne-
cessários nos dias de hoje.

Obviamente, tudo isso foi feito com objetivos claros de entregar ao Mercado um
software o mais rápido e correto possível e, também, de antecipar e mitigar riscos. Além
de isso ter custo baixo, significa software “barato”, e barato, aqui, significa custo justo;
não quer dizer software a “preço de banana”, com profissionais mal remunerados, sem
experiência, sem treinamento ou mentoria e largados a “Deus dará”.

Coisa que muitos RH de Empresas pelo nosso país têm realizado de forma irrespon-
sável, baseados apenas em custo e em comando de superiores despreparados, mesmo
nas áreas requisitantes, o que acaba gerando como resultado um alto turn-over, insatis-
fação profissional, má contratação, produtos de software de péssima qualidade e conde-
nados a um retrabalho sem fim e a um custo proibitivo.

Convido você a refletir e a entender a necessidade de levar a sério sua formação

como Profissional de TI e as responsabilidades que caem sob seus ombros no sentido de
produzir melhor e com qualidade, para que você atinja a excelência e seja um profissional
indispensável em qualquer Empresa que trabalhar.

6
Introdução
A abordagem de processo de desenvolvimento de software orientada a objeto é,
atualmente, a mais difundida no mundo. Isso ocorre por causa da relativa modalização,
segurança e reaproveitamento de código que essa abordagem permite.

Não obstante, vivemos a era da tecnologia em nuvem, mobile, web e Iot sendo
desenvolvidas de forma vertiginosa no mundo todo, e esse tipo de Abordagem Orien-
tada a Objetos se presta mais assertivamente à modalidade de problemas os quais se
pretende resolver quando falamos de desenvolvimento de software.

A diferença é muito clara e começa na própria forma de abordagem.

Veja a figura a seguir:

Programação Estruturada Programação Orientada a Objetos

Procedimentos Procedimentos
Dados Globais ...
Procedimentos
Procedimentos

Dados Globais Procedimentos Procedimentos

Dados Globais ...
...
Procedimentos

Procedimentos ...

Procedimentos
Dados Globais ...
Procedimentos

Figura 1 – Estruturada versus Orientação a Objetos

Fonte: Adaptado de devmedia.com/br

Dessa maneira, OO pode ser dividida em 4 grandes pilares, a saber:

• Abstração: processo de exposição da característica essencial de uma entidade
quando ela for necessária, ao mesmo tempo em que esconde outros detalhes irre-
levantes ao seu uso em determinado momento do processamento;
• Encapsulamento: quando escondemos os dados internos de seus módulos e todos
os outros detalhes e mecanismos de implementação de outros módulos. É também
uma forma de restringir o acesso a determinadas propriedades ou componentes;
• Herança: é uma prática de transmissão de propriedades, ou seja, uma classe pai;
tem propriedades e métodos que serão “herdados” pela classe filha ou subclasse
que, além da herança, pode ter propriedades e métodos adicionais;
• Polimorfismo: capacidade que um objeto possui de alterar seu comportamento em
tempo de execução.

O conceito de classe e objeto deve estar muito bem definido. Classe é um modelo
para criar objetos e estes são uma estrutura de dados específica, fornecendo valores
iniciais para as variáveis ou atributos, bem como inserções comportamentais.

7
7
UNIDADE
Métodos e Ferramentas Ágeis

A seguir, utilizarei uma metáfora sobre esse tema de forma direta.

Observe:

Figura 2 – Diferença entre Classe e Objeto

Fonte: Wikimedia Commons

class

car
methods attributes
refuel() getFuel fuel
setSpeed() getSpeed() maxspeed
drive()

Figura 3 – Abertura da Classe Carro. Utilizado na figura 2 para mostrar

exemplos de métodos e atributos citados na definição
Fonte: Wikimedia Commons

Para terminarmos nossa conceituação de Orientação a Objetos aplicadas a Métodos

Ágeis, precisamos entender o que é a Metodologia Ágil e por quais valores prima.

As Metodologias Ágeis de desenvolvimento surgiram após uma reunião de Engenheiros

de Softwares preocupados em desenvolver mais rapidamente e de forma mais precisa
com relação às necessidades dos usuários, focados em corrigir o necessário para que
acompanhasse as necessidades do negócios, mantendo a versão de produção atualizada.

O Manifesto Ágil coloca os seguintes valores para o desenvolvimento:

• Indivíduos e interações sobre processos e ferramentas;
• Software de trabalho, ao invés de documentação abrangente;
• Colaboração do cliente, ao invés de focar na negociação de contratos;
• Responder a mudança é mais importante do que um plano.

A seguir, estão expostos os Processos de Desenvolvimento OO Ágeis mais difundidos

no Brasil.

8
Scrum
• Desenvolvido por Sutherland e Schwaber, no princípio dos anos 1990;
• É uma Metodologia Ágil de Gerenciamento de Projetos;
• Equipes pequenas e auto-organizadas;
• Itens de trabalho ou desenvolvimento menores, gerenciais, que permitam iterações
numa linha de tempo chamadas de sprints;
• Os times possuem 3 papéis, o de proprietário do produto, o Scrum máster e os
desenvolvedores;
• Possui 4 tipos de reuniões: reunião para planejamento do sprint, reuniões diárias
em pé, reunião de revisão do sprint e reunião de retrospectiva do sprint.

The Agile: Scrum Framework at a glance

Inputs from
Customers, Team, Daily Standup
Managers, Execs Meeting
Scrum
Master 24 Hour
Sprint

1-4 Week
Product Owner The Team Sprint Sprint Review

1 Team selects
2 Task
3
Prioritized starting at atop Breakout
list of what as much as it
4 is required:
5 can commit Sprint end date and
features, Sprint team deliverable
6 bugs to fix... to deliver by Finished Work
7
end of Sprint Backlog do not change
8

Product Sprint
Backlog Planning
Meeting
Sprint
Retrospective

Figura 4 – Framework SCRUM

XP – Extreme Programing
• É uma Metodologia Ágil de Desenvolvimento de Software;
• Processo com o qual criar software de forma ágil e produtiva;
• Desenvolvido por Beck, Jeffries e Cunningham, por volta de 1995;
• Concentra-se nas práticas de Engenharia de Software necessárias para oferecer
software, com qualidade;
• Desenvolvimento orientado por teste;
• Refatoração;
• Programação em pares;
• Histórias de usuários (requisitos);
• Usar em casos de projetos com requisitos mutáveis, projetos com riscos muito altos
e equipes de desenvolvimento pequenas – até 10 pessoas.

9
9
UNIDADE
Métodos e Ferramentas Ágeis

Vamos conhecer XP processualmente, utilizando visões expandidas nas figuras a

seguir para descrever detalhadamente seu funcionamento:
Test Scenarios

Bugs
User Stories

System Release Latest Customer

Archotectural Metaphor Release Plan Version Acceptance Approval Small
Iteration
Spike Planninng Tests Releases
Uncertain Confident
Estimates Estimates

Spike Next Iteration

Figura 5 – Projeto utilizando XP

New User Story,
Project Velocity
Unfinished Tasks
Release
Plan User Stories
New
Project Iteration Functionality
Next Velocity Iteration Plan Latest
Development
Iteration Planninng Bugs Fixes Version
Failed Acceptance
Tests

Bugs
Next Iteration

Figura 6 – Visão detalhada de “ITERATION”em XP

Learn and
Unfinished Communicate
Tasks Pair Programming
Refactor Mercilessly
Iteration Move People Around
New
Too Much Share
Plan Tasks
To Do CRC Cards Functionali
100% Unit
Test Passed
Stand UP Collective
Meeting Next Tasks Code Own
Ownership
or Failed
Failed Acceptance Acceptance Test
Tests Acceptance
Tests Passed
Day by Day Bug Fixes
Figura 7 – Visão detalhada do subprocesso”Development”em XP

10
 CRC Move People 100%
Cards Around Unit Test
Simple
Design Passed
Complex Change We Need
Problem Pair Help
Failed Run Failed
Next Taks Pair Create Unit New Unit Acceptance
or Failed Up Test Pair Tests Continuous Test
a Unit
Acceptance Passed Programming New Integration
Test Test Unit Functionality
Test Acceptance
Simple Complex Test Passed
Code Code

Refactor
Mercilessly
Figura 8 – Visão detalhada do sub-processo de “COLLECTIVE CODE OWNERSHIP”

Assim, SCRUM e XP podem ser adotadas conjuntamente, pois algumas iniciativas

XP caem muito bem na Gestão de Projetos Scrum, como, por exemplo, no Repositório
Coletivo de Código, com as práticas de programação aos pares, desenvolvimento
orientado a testes e releases pequenos, entre outros.

Veja os pontos de potencialização do uso dos processos em conjunto, na figura a seguir:

Scrum
Daily Scrum
Team
Whole
Team
XP Sprint
Backlog
Collective
Ownership
Coding Burndown
Product TDD Standard Chart
Customer
Backlog Tests Pair
Programming Refactoring Sprint
Product Onsite Planning Planning
Owner Customer Game Meeting
Simple
Continuous Design
Integration Sustainable
Pace
XP Metaphor
Coach Sprint
Scrum Small
Master Releases Retrospective
Sprint
Review

Figura 9 – Equipes Scrum operando um híbrido Scrum-XP

A grande maioria das equipes Scrum está operando como um híbrido Scrum-XP, no
qual empregam pelo menos um subconjunto das práticas originadas no XP.

11
11
UNIDADE
Métodos e Ferramentas Ágeis

Test Driven Development

De acordo com David Winter (2016), TDD é a prática de escrever um teste para uma
peça de funcionalidade necessária, antes de escrever qualquer Código de Implementação:
este teste irá falhar quando for executado pela primeira vez e, em seguida, escrevemos
o Código para que ele passe.
• Desenvolvido em 2003 por Astels e Beck;
• Abordagem evolutiva para o desenvolvimento de software;
• Ciclos de desenvolvimento muito curtos suportado por testes;
• Escreve-se o Teste e o Código de Produção suficiente para fazer o teste;
• Foco em escrever um Código limpo e funcional.

Apresenta vantagens quando utilizado, como, por exemplo: reduz os erros no Código
de Produção e, consequentemente, na própria produção, melhora bastante a qualidade
do Código Escrito e fornece testes automatizados quando é necessário o Teste de
Regressão. Afinal, se você utilizar o Teste Manual, o tempo vai aumentar à medida que
o Projeto for ganhando volume, portanto, liberar ficará cada vez mais longo.

A sugestão para desenvolver o TDD de forma processual e repetitiva deve possuir os

seguintes passos durante o desenvolvimento:
• Pegar um caso de teste;
• Adicionar o teste;
• Verificar se há falhas;
• Escreva algum Código Produtivo;
• Executar testes;
• Corrigir a falha pela refaturação de código;
• Repetir.

Parece simples, mas lembre-se que primeiro você fez o teste, depois escreveu algum
Código de Produção para executar no mundo real e ver se tem falhas ou não e vai
refatorando esse Código até que ele fique limpo.

Todavia, há dificuldade para se a usar TDD, pois grande parte delas está no próprio
fato de que há a necessidade de mudança de cultura para quebrar a resistência da Equipe,
negociar muito bem o prazo de entrega com o cliente, já que, conforme dito, quanto
maior o software, maior a quantidade de testes, mais Teste de Integração entre outros
serão produzidos e, portanto, a liberação de versões vai ficar mais lenta.

Por fim, é importante perceber que os requisitos de baixo nível usados para gerar
o TDD são diretamente derivados dos Testes de Aceitação de alto nível. Portanto, os
Testes de Aceitação descrevem os objetivos comerciais de alto nível, enquanto o TDD
ajuda os desenvolvedores a programá-los como requisitos de negócios no software.

12
 É bom lembrar, também, que TDD é baseado em uma multidão de testes e, portanto,
automatizar é mandatório.

Como ferramenta, há a possibilidade de se utilizar o JUnit – Java ou NUnit – .NET

para Métodos, mas ele não é completo. FEST-Swing para GUI Java.

Além disso, há ferramentas baseadas em scripts para serem utilizadas como Watir,
Quick Test e Canoo.
INITIAL
TEST

TEST-DRIVEN
DEVELOPMENT

REFACTOR CODE
CYCLE
Figura 10 – Ciclo TDD

Agile Unified Process – AUP

Conforme Alhir (2005):

AUP é uma estrutura de processo de Engenharia de Produto de software (abordagem

baseada em uso, arquitetura-centrada, iterativa, incremental, paralela, com abordagem
de risco, orientada a objetos e baseada em componentes).

“Um quadro composto por marcos e disciplinas maiores e menores”.

• É baseado no RUP da IBM;
• Desenvolvido por Booch, Rumbaugh e Jacobson;
• Possui as seguintes fases processuais:
»» Modelagem;
»» Implementação;
»» Teste;
»» Desdobramento/Desenvolvimento;
»» Gerenciamento de Configuração;
»» Gerenciamento de Projeto;
»» Ambiente de Desenvolvimento;
• Fornece infraestrutura para realizar Projetos de Engenharia de Software.

13
13
UNIDADE
Métodos e Ferramentas Ágeis

Logo a seguir, podemos contemplar o ciclo de vida AUP:

Justification

Orient Feed Forward Decide

(Orientation) (Explicit Guidance) (Decision)

Opportunities

Vision Risks Roadmap

Issues

Feed System Feed

Changes
Forward (Product) Forward

Integration/ Test
Architecture
Build/Release Implementation
Observe Act
Environment
(Observation) Feedback Interact (Action)
Initiate Execute Close
(Conception) (Innovation) (Cessation)

Figura 11 – Ciclo TDD

Vamos explicar esse ciclo de forma analítica, com o seguinte excerto:

O AUP define metas e objetivos em que colaborações são usadas para
alcançar resultados. Uma colaboração pode ser realizada por um único
indivíduo que possa interagir com os outros. Uma colaboração pode ser
uma oficina envolvendo múltiplos indivíduos que interagem uns com
os outros e podem interagir com outros fora da oficina. Os objetivos
são semelhantes às fases UP, onde são usadas como portões que
envolvem partes interessadas e usuários. Os objetivos são semelhantes
às iterações em tempo de caixa UP que envolvem usuários e resultam
em uma versão do produto.
Initiate (Concepção)
É estabelecer a visão do produto, o roteiro do projeto, a justificativa
de negócios e tecnologia e identificar riscos e oportunidades. Pode
haver um ou mais objetivos que devem ser alcançados para atingir
esse objetivo. As partes interessadas se concentram no problema, na
solução e nas restrições (oficinas de visão).
Os usuários se concentram em suas necessidades e características
do produto em um alto nível (workshops de requisitos). As partes
interessadas e os usuários se concentram no estabelecimento da
justificativa de negócios para o produto e o projeto. A equipe de
desenvolvimento de usuários e software se concentra no estabelecimento
da justificativa tecnológica para o produto e o projeto.
Equipe (equipe de desenvolvimento de software, partes interes-
sadas e usuários).
Se concentra em priorizar riscos e oportunidades.
A equipe se concentra em relacionar os recursos do produto com as
metas e objetivos de Execução (Inovação) no roteiro do projeto. A
equipe estabelece a infraestrutura de desenvolvimento.

14
 Execute (Inovação).
É evoluir a visão do produto, o roteiro do projeto e a justificativa de
negócios e tecnologia; identificar e enfrentar os riscos; e identificar
e aproveitar oportunidades enquanto arquiteta, desenvolvendo
(implementando e testando) e implantando (integrando, construindo e
liberando) o produto. Existem, geralmente, muitos objetivos, cada um
resultando na implantação do produto.
Estratégia (Definir).
A equipe considera possíveis mudanças no produto e no projeto e
suas ramificações, decide aceitar ou rejeitar as mudanças potenciais, e
incorpora as mudanças aceitas no produto e no projeto (workshops de
mudança de avaliação).
As partes interessadas e os usuários se concentram na evolução da
visão (oficinas de visão e requisitos).
A equipe se concentra na evolução da justificativa de negócios e
tecnologia para o produto e o projeto.
A equipe se concentra na evolução dos riscos e oportunidades e no
roteiro do projeto (oficinas de mapeamento rodoviário).
A equipe se concentra em tomar um pulso do produto e projetar em
metas e objetivos (oficinas de pulso).
Execute (Arquitete, Desenvolva (Implemente e Teste), Implique)
A equipe se concentra em aproveitar oportunidades ao enfrentar
os riscos na arquitetura, desenvolvimento (implementação e teste)
e implantação (integração, construção e liberação) do produto
(workshops de desenvolvimento de produtos).
A equipe aborda questões nas (oficinas de resolução de problemas).
A equipe identifica possíveis mudanças no produto e no projeto.
Close (Cessation)
É retirar o produto e fechar o projeto (oficinas de encerramento).
Pode haver um ou mais objetivos que devem ser alcançados para
atingir esse objetivo.
Visão
Fornece foco e direção geral, o roteiro fornece orientação específica
através de metas e metas de missão, e as colaborações estabelecem
intuição, confiança, unidade e coesão.
(ALHIR, s.d.)
INCEPTION ELEBORATION CONSTRUCITION TRANSITION
• Define project scope • Specify requirements • Model, build and test • System testing
• Estimate cost and in detail system • User testing
schedule • Identify architecture • Develop supporting • System rework
• Define risks • Validate architecture documentation • System deployment
• Develop business • Evolve project
cases environment
• Prepare project • Staff project team
environment

LIFECYCLE OBJETIVES (LCO)
• Scope concurrence
• Initial requirements
definition
• Plan concurrence
• Risk acceptance
• Process acceptance
• Business case
• Project plan
LIFECYCLE ARCHITECTURE (LCA)
• Vision stability
• Requirements stability
• Architecture stability
• Risk acceptance
• Cost and estimate
acceptance
• Realistic chance to
succeed
• Project plan
INITIAL OPERATING CAPACITY (LCA) PRODUCT RELEASE (PR)
• System stability • Business acceptance
• Requirements stability • Operations acceptance
• Prepared stakeholders • Suport acceptance
• Risk acceptance • Cost and estimate
• Cost and estimate acceptance
acceptance
• Project plan

Figura 12 – Fases e marcos do Ciclo de Vida AU

15
15
UNIDADE
Métodos e Ferramentas Ágeis

A seguir, descrevemos os princípios do AUP, segundo Ambler (2005):

• Sua Equipe sabe o que está fazendo;
• Simplicidade;
• Agilidade;
• Concentre-se em atividades de alto valor;
• Independência da ferramenta;
• Facilmente adaptável por meio de qualquer ferramenta comum de edição de HTML.

Portanto, deve-se tomar cuidado com a adoção AUP, não pela aplicação do método
em si, que é excelente, mas porque em seu time de projeto e desenvolvimento é man-
datório possuir pessoal sênior.

Agile Model Driven Development – AMDD

Trata-se de uma Abordagem Ágil para o desenvolvimento de software na qual modelos
extensivos são criados antes de o Código Fonte ser escrito.
• Abordagem é diferente das outras técnicas ágeis:
» Primeiro, nós modelamos;
» Segundo, geramos bastante codificação;
» Terceiro, geramos tantas iterações quantas forem necessárias;
» Os esforços de design estão espalhados entre suas atividades de Modelagem
e Codificação;
» Não há uma especificação do tipo de modelo a ser criado; ela é livre;
» Necessita de profissionais genéricos, ou seja, que possuam habilidades gerais em
todo o ciclo de vida AMDD, e que possam codificar e/ou modelar.

O processo AMDD pode ser mais bem entendido nas visualizações de Ambler (2005):

• Identify the high-level scope Initial Requirements Initial Architectural

• Identify initial “requirements stack” Modeling Modeling
• Identify an architectural vision (days) (days)

Iteration 0: Initial Modeling

• Work through specific issues on a JIT manner

Model Storming
• Stakeholders actively participate
(minutes)
• Requirements evolve throughout project Reviews
(optional)
All Iterations
(hours)
Implementation
• Develop working software in an evolutionary manner (Ideally Test Driven)
(hours)

Iteration 1: Development
Iteration 2: Development
Iteration n: Development

Figura 13 – Ciclo de vida do Desenvolvimento do Modelo Ágil (AMDD)

16
 Model A Bit
Model
Ahead
Storm
(optional)
Model Concrete
Feedback
Information Information

Prioritize Test First

Requirements Development
Working
Requirements Software Deploy
Internally

Estimate
Refactor Build
Requirements

Implement

Defects Feedback

Deployed Software
Usability
Acceptance
Testing
Testing
(optional)
User Test

Figura 14 – Processo de desenvolvimento de Software Ágil durante uma iteração de Desenvolvimento Ágil

Disciplined Agile Delivery – DAD

DAD é uma abordagem híbrida que amplia o Scrum, ou seja, deve ser utilizada como
potencializador, além de trazer Técnicas Ágeis relacionadas a XP, UP e até mesmo Kanban.

Dessa forma, ele hipertrofia o Scrum, tornando-o mais que simplesmente um Processo de
Gestão de Projetos, mas o colocando como um framework robusto, abarcando desde a con-
cepção, passando pela gestão e chegando à produção, aos testes e à entrada em produção.

Forças do DAD:
• É flexível e agrega outras técnicas ágeis;
• Não é prescritivo;
• Focado numa abordagem explícita de arquitetura;
• DevOps é mandatório;
• Aborda governança;
• Focado na solução como um todo, e não apenas no produto de software.

Os times DAD possuem as seguintes características:

• São experientes em negócios e desenvolvimento;
• São times pequenos e enxutos;
• Tem pessoas dedicadas exclusivamente ao projeto;
• Possuem um único Product Owner;
• Possuem um único líder do time;
• Possuem analistas generalistas, porém seniores;

17
17
UNIDADE
Métodos e Ferramentas Ágeis

• Podem ter especialistas, mas por motivos de restrição ou especificidade do Projeto;

• Possuem auto-organização e processo de governança.

Não há apenas um ciclo de vida único para DAD; conhece-se ao menos 4 versões.
Todavia, oferecemos para estudo a que possui DevOps, pois é a mais completa e é a que
vem sendo adota em Empresas em geral.

Ciclo de vida do sistema de alto nível DAD ampliando o ciclo de vida SCRUM: https://goo.gl/xVyWFL

Enterprise Unified Process – EUP

Metodologia de desenvolvimento de software que ajuda as Empresas a criar software
de forma estruturada e organizada:
• Desenvolvido por Ambler e Constantine, em 2000;
• Reformulado e incrementado por Ambler, Nalbone e Vizdos, em 2005;
• Foi desenhado para inserir no RUP a falta de suporte, a manutenção e também a
retirada de um Sistema do ar, ou seja, sua obsolescência;
• EUP leva em consideração vários ciclos de vida, e não apenas o dele. Isso significa
que se leva em conta os ciclos de TIC e da Organização como um todo;
• Desenvolve software pelo ponto de vista do cliente.

Trata-se de um Processo abrangente e complexo que leva em conta uma série de dis-
ciplinas que entendem RUP de forma a torná-lo muito mais completo, tentando manter
as características ágeis e, por isso, na Empresa em sua totalidade.
• Disciplinas de Projeto de Software:
» Modelagem de Negócios;
» Requisitos do Negócio;
» Análise;
» Projeto;
» Implementação;
» Teste;
» Desenvolvimento;
» Configuração e Gerenciamento de Mudanças;
» Gerenciamento de Projetos;
» Ambiente;
» Operações e Suporte.

18
• Disciplinas de Negócios
»» Modelagem de Negócios Empresariais;
»» Gestão de Portfólio;
»» Arquitetura Empresarial;
»» Reuso Estratégico;
»» Gestão de Pessoas;
»» Administração Empresarial;
»» Melhoria de Processos de Software.

Em sua concepção, o processo EUP possui 6 fases, a saber:

• Começo;
• Elaboração;
• Construção;
• Transição;
• Produção;
• Aposentadoria.

O Ciclo de Vida Aumentado para o Processo Unificado Empresarial: https://goo.gl/KiFHvB

Initiate Construct Deliver Maintain and Support

Define and
Text Text
Validate
Justify Model in the in the Release Suport
Initial
Small Large
Requirements

Identify
Generalize Program Defects and
Define Rework Assess Enhancements
Initial Define
Management Infrastructure
Documents

Assure Quality, Manage the Project, Train and Educate, Manage People, Manage Risk, Manage Reuse, Manage Metrics, Manage Deliverables, Manage Infrastructure

“Serial in the large, iterative in the small, delivering incremental releases over”

Figura 15 – O Ciclo de Vida do Processo de Software Orientado a Objetos.

19
19
UNIDADE
Métodos e Ferramentas Ágeis

Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
Ciclo de vida do sistema de alto nível DAD ampliando o ciclo de vida SCRUM.
https://goo.gl/pgzOFI
Ciclo TDD.
https://goo.gl/jVMwAc
Diferença entre Classe e Objeto
https://goo.gl/p5RjgJ
Equipes Scrum operando um híbrido Scrum-XP.
https://goo.gl/V2m45u
Estruturada versus Orientação a Objetos.
https://goo.gl/yVyh4F
Extreme programming: a gentle introduction.
https://goo.gl/cHsx
Fases e marcos do Ciclo de Vida AUP.
https://goo.gl/crWA8F
Framework SCRUM.
https://goo.gl/gcRTHD
Manifesto para desenvolvimento de software ágil.
https://goo.gl/ruvK
Processo de desenvolvimento de software ágil durante uma iteração de desenvolvimento ágil.
https://goo.gl/nuCvJ7
Projeto utilizando XP.
https://goo.gl/2f7QvR
TDD – Exemplo passo a passo.
https://goo.gl/YZQeFh
Visão detalhada de “ITERATION” em XP.
https://goo.gl/2f7QvR
Visão detalhada do sub-processo “DEVELOPMENT” em XP.
https://goo.gl/2f7QvR
Visão detalhada do sub-processo de “COLLECTIVE CODE OWNERSHIP”.
https://goo.gl/2f7QvR

20
 Sites
The Agile Unified Process (AUP)
ALHIR, Sinan Si. O Processo Unificado Agilizado (AUP).
https://goo.gl/jWlwV
The Agile Unified Process (AUP)
AMBLER, Scott W. O Processo Unificado Agilizado (AUP).
https://goo.gl/crWA8F
Examining enterprise unified process
AMIR, A. A Examining enterprise unified process.
https://goo.gl/k4M1Rb
9 Benefícios do Desenvolvimento Test Driven
WINTER, David. 9 Benefícios do Desenvolvimento Test Driven.
https://goo.gl/dWkoC2
Abertura da Classe Carro
https://goo.gl/dgPXFr
Ciclo de Vida Aumentado para o Processo Unificado Empresarial.
https://goo.gl/ipWCpr
Ciclo de vida do Desenvolvimento do Modelo Ágil.
https://goo.gl/nuCvJ7
Ciclo de Vida do Processo de Software Orientado a Objetos.
https://goo.gl/ipWCpr

Leitura
Agile Model Driven Development (AMDD)
AMBLER, Scott W. Agile Model Driven Development (AMDD).
https://goo.gl/k73wco
Agile Unified Process e a Aderência ao Modelo de Processo de Software Mps.Br Nível G.
FURLAN, Renata Cristina.
https://goo.gl/P0lgPy
The Impact of an Agile Methodology on Software Development Costs
FERGIS, Kristin. The Impact of an Agile Methodology on Software Development Costs.
https://goo.gl/LTo5Ct

21
21
UNIDADE
Métodos e Ferramentas Ágeis

Referências
ALHIR, Sinan Si. O Processo Unificado Agilizado (AUP). Disponível em: <http://
www.methodsandtools.com/archive/archive.php?id=21>. Acesso em: 25 jan. 2018;

FOGGETTI Cristiano, ORG. Gestão ágil de projetos. São Paulo: Pearson, 2015.
(e-book)

PAGE-JONES, Meilir. Fundamentos do desenho orientado a objetos com UML.

São Paulo: Makron Books, 2001. (e-book)

PFLEEGER, S. L. Engenharia de software - Teoria e prática. 2.ed. São Paulo:

Pearson/Prentice Hall, 2004. (e-book)

PRESSMAN, R. S. Engenharia de software. 7.ed. Rio de Janeiro: McGraw-Hill do

Brasil, 2011. (e-book)

SCHACH, S. R. Engenharia de software: os paradigmas clássico & orientado a

objetos. 7.ed. São Paulo: Bookman, 2009.

SHORE, James; WARDEN, Shane. A arte do desenvolvimento ágil. Rio de Janeiro:

Alta Books 2008.

SOMMERVILLE, I. Engenharia de software. 8.ed. São Paulo: Pearson, 2001.

(e-book)

WAZLAWICK, Raul Sidnei. Análise e design orientados a objetos para Sistemas de

Informação: modelagem com UML, OCL e IFML. 3.ed. Rio de Janeiro: Campus, 2015.

22