Tópicos Avançados em Engenharia de

Software
Aula 1 – Manifesto Ágil
Você está iniciando o estudo da disciplina Tópicos Avançados em Engenharia de Software. Nela
você irá conhecer outras metodologias de desenvolvimento de sistemas e em qual a situação cada
uma delas será utilizada.

Nesta primeira aula será abordado sobre a situação atual do desenvolvimento de sistemas e a
criação do manifesto ágil

Ao final, você deverá ser capaz de identificar quais são os principais problemas existentes no
desenvolvimento de sistemas e o porque da criação do manifesto ágil.

Boa aula!

1.1 Desenvolvimento de Sistemas

Sommervile (2011) declara que nos dias atuais as empresas se encontram operando em um
ambiente global, necessitando de mudanças rápidas. Nesse contexto elas precisam responder a
novos mercados, novas oportunidades a mudanças no cenário econômico e ao surgimento de
novos produtos ou serviços. Os sistemas informatizados fazem parte de grande parte das
operações de negócios, assim o desenvolvimento de novos sistemas passa a ser uma necessidade
para garantir proveito nas novas oportunidades e atender às pressões competitivas.

O desenvolvimento rápido de soluções informatizadas passa a ser um fator crítico nas

organizações visando atender esse contexto. Portanto, o desenvolvimento de software passou a
ser um fator estratégico nas organizações, seja internamente ou através de terceirização.

Aí voltamos para dentro da empresa e nos perguntamos:

Como desenvolver sistemas?

Ambler (2004) declara que a situação atual do desenvolvimento de software encontra-se aquém
do ideal para as empresas. Os sistemas são construídos com atraso e constantemente não
atendem os orçamentos previstos, isso, quando são efetivamente entregues. Frequentemente não
conseguem atender os requisitos definidos pelos clientes e em algumas situações precisam ser
desenvolvidos novamente ou alterados.

Outro problema encontrado é a integração entre os sistemas existentes na organização, seus

bancos de dados, sem pensar que com o novo contexto dos negócios empresariais, sistemas cada
vez maiores são requisitados e seus requisitos mudam em função do ambiente em que eles estão
inseridos.

Quando lidamos com sistemas grandes, seu desenvolvimento pode levar anos, o que torna a sua
utilização inviável contando com o ambiente empresarial que relatamos anteriormente. Nesse
contexto o software ideal nunca fica pronto ou o sistema nunca é construído utilizando padrões de
desenvolvimento de software.
O que é uma metodologia de desenvolvimento?
Pressman (2002) relata que a Engenharia de Sistemas é um processo de modelagem onde a visão
do mundo real ou numa visão detalhado do que tem que ser construído, criando modelos para
representar a visão dos processos de negócios, seus comportamentos e seus pressupostos.
Tratam as entradas e a ligações dos processos permitindo ao engenheiro entender melhor a visão
dos processos de negócios.

O que tem metodologia padrão a ver com qualidade de desenvolvimento?

Pressman (2002) relata que a meta da engenharia do produto é traduzir o desejo do cliente em
um conjunto de características definidas para um determinado produto a ser construído. Nesse
contexto a modelagem da arquitetura do sistema deve considerar quatro componentes distintos: o
software, o hardware, os dados (e bases de dados) e o pessoal. A definição de uma metodologia
padrão facilita o entendimento das partes interessadas ou mesmo a manutenção do produto de
software, aumentando a possibilidade de criação de um produto de qualidade, em conformidade
com a visão apresentada pelo cliente. A utilização de uma metodologia padrão deve ter o foco no
objetivo principal do desenvolvimento de software que é a construção de sistemas de maneira
mais eficaz e eficiente possível, visando satisfazer as reais necessidades dos clientes e usuários.

Porque é difícil a adoção de metodologias padrão em empresas?

Ambler (2004) relata que processos prescritivos são atrativos para as gerências, onde eles
conseguem controlar o que está sendo feito, mas não para os desenvolvedores. Esses processos
estão baseados no paradigma comando controle, que coloca a gerência no controle do processo,
ou pelos menos faz com que eles achem isso.

No ambiente organizacional encontramos desenvolvedores de diferentes gerações e que convivem

com diversas metodologias, onde em algumas situações, não são as adotadas atualmente pela
empresa. Quando a organização adota uma dessas metodologias pode ocorrer resistência na
utilização das novas metodologias e a pergunta: Porque temos que trabalhar dessa forma? Porque
não construímos sistemas como fazíamos antigamente? Era muito melhor trabalhar daquela
forma?

Outro ponto a ser observado é que os desenvolvedores, na maioria das vezes, não gostam de
gerar a documentação exigida pelo processo e, dessa forma, quando necessário as mesmas são
geradas de qualquer forma, sem levar em consideração o processo nem as consequências futuras
na utilização dessa documentação gerada de forma incompleta.

Um ponto importante que deve ser trabalhado é que a utilização de uma metodologia padrão,
gerando documentação em todas as fases do desenvolvimento de software, tornará o processo
independente das pessoas, onde antigamente o conhecimento sobre o negócio e sistema estava
depositado nos desenvolvedores. Isso poderá gerar séria resistência ao processo, a partir do
momento que os desenvolvedores perceberem que perderão essa condição.

Quais são os pré-requisitos para adoção de metodologias padrão?

É necessário mostrar aos desenvolvedores quais os benefícios que eles irão obter com a adoção de
uma metodologia padrão. Entre esses benefícios está a unificação das visões da arquitetura do
sistema, a independência das pessoas no processo de desenvolvimento e a probabilidade de
geração de um produto de qualidade em conformidade com as reais necessidades do cliente e dos
usuários.
No modelo adotado antigamente, onde o conhecimento sobre os negócios e os sistemas estava
depositado nos desenvolvedores, a sua liberação para participar de eventos, congressos ou
mesmo tirar férias e folgas era complicada e às vezes impossível. Quando esse conhecimento
estiver na documentação do processo essa liberação será mais fácil, permitindo o crescimento
profissional desses desenvolvedores e mesmo melhorando a sua qualidade de vida.

Qual é o papel de ferramenta CASE no contexto das metodologias padrão?

Todos já ouviram o antigo ditado sobre os filhos do sapateiro: o sapateiro está tão ocupado
fabricando sapatos para os outros que seus filhos não têm sapatos próprios. Antes dos anos 1990,
muitos desenvolvedores de software eram “filhos de sapateiros”. Apesar de esses profissionais
técnicos construírem sistemas e produtos complexos que automatizavam o trabalho de outros,
eles próprios usavam muito pouca automação. (PRESSMAN, 2002, p. 807).

O termo CASE (Computer-Aided Software Engeneering) representa o auxílio de uma ferramenta

automatizada que auxiliará os gerentes e os profissionais de engenharia de software em toda a
atividade associada com o processo de software. Atualmente existem muitas ferramentas que
facilitam a vida dos desenvolvedores e simplificam o processo de construção de sistemas
informatizados.

A utilização de uma metodologia padrão é facilitado com a utilização de ferramentas CASE, uma
vez que as ferramentas criam uma série de procedimentos que devem ser seguidos pelos
desenvolvedores.

Em algumas situações, ferramentas CASE de alto nível permitem que a organização faça a
padronização dos artefatos e dos passos que devem ser seguidos pelos desenvolvedores, de tal
forma que não é permitido que determinadas atividades sejam ignoradas ou simplesmente deixem
de ser realizadas.

O que deve vir antes: metodologia padrão ou CASE? Por que?

Não existe uma fórmula definida para que cada empresa escolha entre a adoção de uma
ferramenta CASE ou estabeleça uma metodologia padrão. Cada empresa possui o seu próprio
contexto. E é esse cenário que definirá qual a melhor forma de trabalhar visando atender o
contexto necessário para o ambiente negocial.

Vai depender muito do segmento de negócios em que essa organização está inserida. Por
exemplo, o segmento bancário não tem como foco a venda de software e sim de produtos e
serviços bancários.

Então porque esse segmento deve se preocupar com o desenvolvimento de sistemas?

Vamos por partes, se o banco não contar com sistemas de última geração, atendendo diversos
canais de atendimento, dificilmente ele conseguirá fidelizar o cliente e se manter no mercado.
Portanto, a existência de sistemas informatizados é uma necessidade e uma realidade.

Aí levantamos outra situação, porque não terceirizar todo o desenvolvimento de sistemas e partir
para vender os produtos e serviços. Nesse contexto entra uma nova variável, o conhecimento
sobre o negócio, embutido nos sistemas. Esse conhecimento irá estar nas mãos das empresas
terceirizadas e não do banco. Isso passará a ser um problema, se a empresa terceirizada for
embora, esse conhecimento vai com ela. E os sistemas da empresa, quem irá mantê-los. Aí entra
a necessidade de existência de uma equipe interna de desenvolvimento de sistemas, que irá
concentrar todo esse conhecimento, tornando a organização independente das empresas
terceirizadas.

Se existe uma equipe interna, temos que ter um processo definido para esse grupo de
profissionais, visando padronizar a sua atuação. A adoção de ferramentas CASE fica condicionada
ao tamanho dessa equipe e a forma como o processo de desenvolvimento foi definido.

Outra razão para que a empresa se preocupe com a sua equipe de desenvolvimento de sistemas
são as regulamentações legais, que exigem que as empresas tenham uma documentação mínima
sobre os seus sistemas, dependendo do segmento em que a mesma se encontra. Por exemplo, o
sistema bancário é controlado de perto pelo Banco Central do Brasil, visando garantir que os
correntistas desses bancos não tenham nenhum prejuízo financeiro, caso ocorram problemas nos
sistemas informatizados dos bancos.

Muito bem, falamos muito sobre metodologia padrão, ferramentas CASE, processo de
desenvolvimento, mas ainda não entramos no ponto principal que é como desenvolver sistemas,
atendendo as reais necessidades das empresas.

Ficou claro que o desenvolvimento de sistemas está muito aquém daquilo que as empresas
esperam desses sistemas. Para atender esse contexto foi criado o Manifesto Ágil.

1.2 Manifesto Ágil

Ambler (2004) relata que para enfrentar os desafios encontrados pelos desenvolvedores foi criado
em fevereiro de 2001 um grupo inicial com 17 metodologias, formando o Agile Software
Development Alliance (ASDA), citado também como Agile Alliance.

Um dos aspectos desse grupo é que todos vieram de diferentes áreas de formação e ainda assim
são capazes de concordar em questões que normalmente metodologistas não concordam. O grupo
definiu um manifesto para encorajar melhores meios de desenvolver software. Esse manifesto é
composto por um conjunto de princípios que definem critérios para o desenvolvimento ágil de
software, como a Modelagem Ágil.

Ambler (2004) declara que o Manifesto Ágil é composto por quatro simples declarações de valores,
onde o importante é entender que ao mesmo tempo em que você deve valorizar conceitos, são
definidas preferências, não alternativas, dando enfoque em certas áreas, sem contudo eliminar
outras. Os valores do Manifesto Ágil são:

1. Indivíduos e interações valem mais que processos e ferramentas – Essa declaração

tem princípio que não adianta você ter ferramentas de última geração e um processo de
desenvolvimento muito bem definido. Se você não tiver pessoas preparadas e motivadas a
atuar no processo de desenvolvimento, de nada adiantará isso. No processo de
desenvolvimento temos programadores, testadores, gerentes de projeto, modeladores e
clientes. Se não ocorrer uma interação efetiva entre esses indivíduos, de nada adiantará a
existência de um processo bem definido e ferramentas de última geração.
2. Um software funcionando vale mais que documentação extensa – Essa declaração
está baseada na seguinte pergunta: Um usuário prefere um documento contendo 50 páginas
descrevendo o que o sistema pretende construir ou um software real? Com certeza, 99 de
cada 100 escolherão o software. O usuário entenderá muito mais um sistema funcionando do
 que uma série de diagramas que nem sempre dizem nada a eles. A documentação tem seu
lugar, desde que escrita de maneira correta e é um guia para se trabalhar. Entretanto, o
objetivo principal é criar softwares de forma rápida e não documentos. De outra forma, o
processo seria chamado de desenvolvimento de documentação e não desenvolvimento de
software.
3. A colaboração do cliente vale mais do que a negociação do contrato – Essa
declaração parte do princípio de que somente os clientes podem dizer o que querem,
diferentemente da forma como era trabalhada no passado, onde o Gerente de TI dizia ao
cliente, eu sei aquilo que você precisa e entregava a ele um sistema com a sua cara e não
como o cliente queria. Com certeza o cliente dificilmente acertará da primeira vez a
especificação do sistema e constantemente poderão mudar de ideia. O foco principal é
trabalhar com o cliente ao lado, por mais difícil que isso seja. A existência de um contrato é
importante para entender os direitos e obrigações de ambas as partes que deve ser um
alicerce para ambos. O importante é que ele não seja um entrave nem substituto da
comunicação entre as partes. Os desenvolvedores devem trabalhar próximos ao cliente,
esforçando ao máximo para descobrir aquilo que eles necessitam e buscar educa-los durante
este processo.
4. Responder a mudanças vale mais do que seguir um plano – Esta declaração parte do
princípio que as pessoas mudam as suas prioridades, à medida que o trabalho do sistema
progride, mudando a compreensão do cliente sobre o domínio do problema e sobre o que
está sendo construído. O ambiente negocial passa por mudanças, as tecnologias evoluem
com o tempo e nem sempre para melhor. Isso tudo gera mudanças na realidade do
desenvolvimento e consequentemente nos planos do projeto. Esse plano deve ser maleável e
se adaptar a essa realidade, caso contrário passará a se tornar rapidamente irrelevante.

Ambler (2004) relata que para ajudar as pessoas a compreenderem o desenvolvimento ágil de
software, os membros da Aliança Ágil refinaram as filosofias constantes de seu manifesto em doze
princípios aos quais as metodologias de desenvolvimento de software devem se adequar. Esses
princípios são:

 Nossa maior prioridade é satisfazer ao cliente mediante entregas de software de valor em

tempo hábil e continuamente.

 Receber bem as mudanças de requisitos, mesmo em uma fase mais avançada do

desenvolvimento. Os processos ágeis direcionam as mudanças para obter vantagens

competitivas para o cliente.
 Entregar software em funcionamento com frequência de algumas semanas a alguns meses,

de preferência na menor escala de tempo.

 As equipes de negócios e de desenvolvimento devem trabalhar juntas diariamente durante

todo o projeto.
 Construa projetos ao redor de indivíduos motivados. Dê-lhes o ambiente e o apoio que eles

precisam e confie neles para realizar o trabalho.

 O método mais eficiente de levar informações para uma equipe de desenvolvimento e fazê-

las circular é a conversa cara a cara.

  Ter o software funcionando é a principal medida de progresso.
 Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores,

desenvolvedores e usuários deveriam ser capazes de manter um ritmo constante

indefinidamente.
 Atenção contínua à excelência técnica e a um bom projeto aumentam a agilidade.
 Simplicidade – a arte de maximizar a quantidade de trabalho não realizado .
 As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas.
 Em intervalos regulares, a equipe deve refletir sobre como se tornar mas eficaz e então se

ajustar e adaptar o seu comportamento.

Ambler (2004) relata que quando se pensa a respeito desses princípios nos perguntamos:

 Esse é o modo como seus projetos são realmente executados?

 É desse modo que você pensa que seus projetos deveriam funcionar?

Olhando para eles, algumas pessoas podem dizer que são objetivos radicais e impossíveis de
serem aplicados na prática. Outros podem dizer que tem bom senso.

Eles representam alicerces que podem ser adotados para o desenvolvimento de software bem-
sucedido.

Algumas empresas utilizam esses princípios, dependendo das reais necessidades de seu
desenvolvimento de sistemas e das regulamentações legais que a mesma está subordinada.

Ambler (2004) relata que a Modelagem Ágil (MA) é uma metodologia para modelagem e
documentação eficaz de sistemas baseados em software.. Ela é um conjunto de práticas guiada
por princípios e valores para profissionais aplicarem em seu dia a dia, não sendo um processo
prescritivo. Não define procedimentos detalhados sobre como criar um determinado tipo de
modelo. Ela fornece conselhos sobre como modelar sistemas de forma eficiente. Ela não significa
que você deve criar menos modelagem do que antes. Como veremos em outras aulas, a
modelagem existe nos processos ágeis, tais como o SCRUM com as histórias de usuários ou
modelos CRC (Class Reponsability Collaborator).

Ambler (2004) relata que a Modelagem Ágil tem três objetivos:

 Definir e mostrar como praticar um conjunto de valores, princípios e práticas relativas a uma

modelagem eficaz e leve. A MA é uma catalisadora de melhorias que não são as técnicas de
modelagem em si, tal como os modelos de casos de uso, de classe, de dados ou de interface
com o usuário e sim como aplicá-las.
 Lidar com a questão de como aplicar técnicas de modelagem em projetos de software

adotando uma perspectiva ágil. Às vezes, é significativamente mais produtivo para o

desenvolvedor desenhar alguns balões e linhas e refletir sobre uma ideia ou comparar
algumas perspectivas diferentes de resolução de um problema do que simplesmente
começar a escrever códigos. É perigoso ser muito centrado na codificação. Em algumas
situações um esboço rápido pode evitar muita agitação na hora da codificação.
  Discutir as atividades de modelagem podem ser melhoradas adotando uma perspectiva

“quase ágil” no desenvolvimento de software e equipes de projeto que adotaram uma

instanciação do Processo Unificado como o RUP ou EUP. Esses modelos são suficientemente
flexíveis para serem adotados de forma que, por um lado, sejam muito prescritivos, ou, por
outro, suficientemente ágeis para que a MA funcione com eles.

O que é Modelagem Ágil?

 Ela não é um processo completo de software.

 Seu foco está na geração de modelagem e documentação eficaz.
 Ela não inclui atividades de programação, embora lhe diga para testar seus modelos com

códigos.
 Ela não inclui atividades de teste, embora lhe diga para considerar a possibilidade de teste

enquanto modela.
 Ela não cobre as atividades de gerenciamento de projeto e as operações de suporte ao

sistema.
 Ela deve ser utilizada com outros processos, como o XP – eXtreming Programming, DSDM –

Dynamic System Development Model, UP – Unified Process ou mesmo com o próprio

processo preexistente.
 Alternativamente ela pode ser utilizada com as melhores características de um conjunto de

processos de software já existente para formar o seu próprio processo, dependendo das
características da organização e de seus negócios.

O que são modelos ágeis, gerados durante a Modelagem Ágil?

 Os modelos criados devem cumprir os seus propósitos, ou seja devem ter uma razão para

serem gerados. Um modelo não deve ser criado se ele não for utilizado em algum ponto do
desenvolvimento
 Devem ser compreensíveis
 Devem ser suficientemente precisos
 Devem ser suficientemente consistentes
 Devem ser suficientemente detalhados, ou seja, devem conter somente os detalhes

necessários ao desenvolvimento do software

 Devem proporcionam valor positivo no desenvolvimento de software
 E principalmente devem ser o mais simples possível

Outras considerações a respeito da Modelagem Ágil:

 É uma atitude, não um processo prescritivo

 É um suplemento dos métodos preexistentes, não uma metodologia completa
 É complementar aos processos de modelagem
 É uma maneira de trabalhar um conjunto de modo eficaz para alcançar os objetivos dos

clientes do projeto
 É eficaz e trata de eficácia
  É algo que funciona na prática, não é uma teoria acadêmica
 Não é uma bala de prata (“silver bullet”)
 Foi feita para o desenvolvedor médio, mas não é uma substituição de pessoas competentes
 Não é um ataque à documentação
 Não é um ataque às ferramentas CASE

Para Saber Mais

Leia o “Manifesto para o desenvolvimento ágil de software” e conheça melhor os princípios
defendidos pelo grupo.
Nesta aula você estudou sobre o Manifesto Ágil e a criação da Modelagem Ágil, principalmente,
sobre qual o seu foco no desenvolvimento de sistemas. Também visualizou que se trata de uma
importante ferramenta complementar ao desenvolvedor para atender as necessidades
emergenciais na construção de software nas organizações.
Não se trata de substituir a forma como os sistemas serão desenvolvidos e sim de uma
ferramenta adicional para atender as organizações.
Recomenda-se que grandes projetos se utilizem da metodologia tradicional de desenvolvimento e
a Modelagem Ágil seja utilizada para demandas rápidas de software, onde o ciclo de
desenvolvimento seja menor.
Na próxima aula iremos abordar como a Modelagem Ágil atua em conformidade com o UP.

Aula 2 – A Modelagem Ágil, Seus Valores e

Seus Princípios
Na aula anterior você estudou a respeito do Manifesto Ágil, da Modelagem Ágil, dos Modelos Ágeis
e dos problemas enfrentados pelo desenvolvimento de software nas organizações.
Nesta aula você continuará estudando sobre a Modelagem Ágil, seus Valores, seus Princípios
Básicos, seus Princípios Suplementares, sobre Requisitos, Projeto e Análise Ágil e como é feita a
Modelagem de Negócios na Modelagem Ágil.
Boa aula!
2.1 Valores da Modelagem Ágil
Ambler (2004) relata uma experiência onde um analista de requisitos está coletando informações
a respeito de um sistema a ser desenvolvido. O cliente relatava a forma como os negócios eram
realizados e o analista de requisitos não concordava com o mesmo pela forma como o negócio se
desenrolava. O analista de requisitos tinha visualizado uma maneira mais rápida e ágil de
formalizar as operações com os clientes. O cliente insistiu que queria que o sistema deveria ser
construído em conformidade com o que ele estava pedindo e o analista de requisitos insistia em
mudar o modelo de negócios. Após muita discussão, o analista cedeu e finalmente especificou o
que o cliente queria.

O analista de requisitos esqueceu de uma regra principal no momento de coletar os requisitos. A

fonte principal de fornecimento de requisitos é o cliente, independente do analista de requisitos
concordar ou não como o processo de negócios acontece. Outro ponto a ser considerado é a
humildade que deve existir, principalmente em um modelador ágil. A modelagem Ágil possui
alguns valores, são eles:

O que é comunicação?
Comunicação é o processo nos quais informações são trocadas entre indivíduos por meio de um
sistema comum de símbolos, sinais ou comportamento, segundo o Merriam Webester’s Collegiate
Dictionary 10th Edition.
É uma via de duas mãos, onde duas ou mais partes fornecem e obtêm informações como
resultado. Em algumas situações, é um requisito fundamental para o sucesso no desenvolvimento
de software. Uma das principais razões para modelar é ajudar a melhorar a comunicação. A
modelagem é uma das formas onde as ideias são comunicadas para as partes interessadas em um
projeto de software.

O que é Simplicidade?
A Modelagem Ágil prega a simplicidade dos projetos, onde a aplicação de padrões complexos cedo
demais, criar arquiteturas em excesso para que seu sistema para dar suporte a requisitos futuros
ainda não definidos e desenvolver uma estrutura complexa podem ser fatores contrários à
agilidade no desenvolvimento de software.

O ideal é se basear especificamente naquilo que será necessário para o momento, atuando de
forma simples e objetiva.

Retorno
Para se obter um retorno efetivo sobre o desenvolvimento de sistemas, os modelos devem ser
desenvolvidos em equipe, revisados com o seu público-alvo e somente após ter um feedback a
respeito é que o modelo deve ser implantado. É importante ainda a realização de um teste de
aceitação para verificar o retorno a respeito do que foi desenvolvido.

Coragem
Ambler (2004) relata que a modelagem ágil exige que você trabalhe com outras pessoas, acredite
nelas e em si próprio, e isso exige coragem. A MA requerer que as coisas sejam feitas de modo
mais simples possível e acredite que pode resolver os problemas futuros que ocorrerem. A
documentação de software somente deve ser gerada quando você precisar dela. Caso você esteja
gerando uma documentação que não será utilizada, porque gera-la? Só para fazer volume?

Humildade
Ambler (2004) relata que os melhores desenvolvedores de software devem ter a humildade de
reconhecer que não sabem tudo. Os modeladores ágeis devem entender que seus colegas e os
clientes possuem pontos fortes e sempre têm algo a acrescentar ao projeto. A humildade também
deve fazer parte da forma como você interage com as pessoas. O fato de denegrir as pessoas ou a
sua imagem não é um ato de humildade, é sim um ato de arrogância.

2.2 Princípios Básicos

Ambler (2004) informa que os Valores da Modelagem Ágil, combinados com os valores e princípios
da Agile Alliance, são usados para definir os princípios da Modelagem Ágil. Esses valores, embora
um pouco abstratos e de alto nível, devem servir para orientar o trabalho de desenvolvimento de
software. Alguns desses princípios são adotados pelo XP.

Os princípios básicos da MA são:

O software é o seu objetivo principal

Ambler (2004) relata que o objetivo principal deve ser o desenvolvimento de software com
qualidade e que satisfaçam as reais necessidades do cliente e de seus negócios. Qualquer
atividade que não contribua diretamente para a produção de um produto com qualidade deve ser
questionada e evitada, se não puder ser justificada. Isso deve incluir a documentação, modelos e
relatórios sobre a situação do projeto entre outros. Tenha coragem de focar aquilo que é
importante para a criação de um sistema para seus usuários.

Possibilitar o próximo trabalho é o seu objetivo secundário

Ambler (2004) relata que o seu projeto pode ser considerado um fracasso apesar de você ter
entregado um sistema funcionando para o cliente. Entre as necessidades do cliente deve estar a
entrega de um sistema sólido e passível de ser expandido futuramente. A sua expectativa deve
estar direcionada à produção de novos componentes para o sistema ou a manutenção do sistema
entregue.

Para tanto deve ser produzida uma documentação mínima, suficiente para dar continuidade nos
trabalhos. O seu foco deve estar em transferir as habilidades de seus desenvolvedores, motivar o
pessoal existente a permanecer e desenvolver a próxima versão do sistema.

Devem ser considerados fatores como a natureza dos desenvolvedores e do próximo trabalho. O
importante é desenvolver sistemas sem perder o foco nos futuros projetos.

Diminua a carga de trabalho

Ambler (2004) relata que a diminuição da carga significa criar documentação e modelos
suficientes e que a documentação e modelos devem ser mantidos atualizados.

Podem ser alteradas as quantidades de modelos a serem utilizados em cada projeto. Quanto mais
complexos os modelos ou documentos criados, mais difícil pode ser a sua manutenção.

Jim Highsmith, apud Ambler (2004), faz um questionamento sobre qual a carga ideal que um
viajante deve levar no deserto. Uma carga excessiva pode dificultar a locomoção. Da mesma
forma um mínimo de suprimentos pode inviabilizar a viagem. Será necessário contrabalançar o
ponto ideal de suprimentos para atravessar o deserto levando em consideração a quantidade de
água, suprimentos, etc..

Da mesma forma, no desenvolvimento de sistemas, você precisa de boa comunicação dentro da

equipe para efetivamente conseguir diminuir a carga. Se os desenvolvedores não conseguirem
entender os requisitos ou a sua visão da arquitetura, ou pelo menos não houver alguém que
entenda e possa responder os questionamentos no projeto você terá sérios problemas no projeto.

Diminuir a carga é ter coragem de acreditar que a documentação gerada, mesmo que mínima será
suficiente para ou projeto ou estar preparado para criá-los caso seja identificada essa
necessidade.

Adote a simplicidade
À medida que o projeto anda, um dos pressupostos é de que a solução mais simples é a melhor.
Na maior parte do tempo a solução mais simples funciona bem.

Ambler (2004) relata que a vantagem é que você não está gastando tempo com a implementação
de soluções difíceis. Outra vantagem é quando uma solução simples não funciona bem, você terá
tempo de trabalhar e gerar a solução difícil. Adotar a solução mais simples irá funcionar sempre?
Aprenda com as experiências vivenciadas, aproveitando as lições em desenvolvimentos futuros.
Encampe as mudanças
Aceite que as mudanças acontecem e elas tornam o desenvolvimento de software emocionante.
Os requisitos mudam com o tempo e os clientes podem mudar com o tempo, pessoas entram e
outras saem na área de negócios.

Os pontos de vista podem ser alterados, bem como os objetivos do negócio. O ambiente
tecnológico e de negócios podem sofrer modificações à medida que o projeto avança, os
modeladores ágeis tem a mudança como uma coisa normal.

A Agile Alliance aconselha o acolhimento das mudanças de requisitos mesmo em estágios

avançados de desenvolvimento, mesmo os modeladores reconhecendo o perigo iminente de
encampar as mudanças.

Podem ocorrer problemas no desenvolvimento com a pressuposição de que o que está sendo
desenvolvido irá ser modificado no futuro.

Mude incrementalmente
Como dissemos anteriormente a mudança faz parte do dia a dia de um desenvolvedor ágil. Para
encampar essas mudanças, você necessita usar uma estratégia incremental em seu próprio
trabalho de desenvolvimento. Elas devem ser feitas em pequenas partes do sistema. Você pode
executar uma grande alteração com a programação de pequenas mudanças incrementais.

Os princípios básicos da Agile Alliance dizem que você deve entregar software funcionando com a
frequência de semanas a alguns meses, de preferência com a frequência mais curta possível.

É inútil tentar desenvolver o modelo completo no início do projeto. É ideal desenvolver um modelo
completo pequeno no início ou um modelo de alto nível. É necessário ter a humildade que você
pode não acertar tudo na primeira vez, ou na enésima vez. Basta ter coragem para administrar e
buscar construir o software mais próximo possível da necessidade do cliente.

Modele com um propósito

Um modelo somente deve ser criado se você puder identificar o porquê e para quem você está
criando. Você não deve estar modelando apenas para satisfazer uma satisfação pessoal e sim para
satisfazer as necessidades do cliente.

Um modelo deve ser utilizado para entender melhor o que tem que ser feito ou realizar uma
modificação no futuro. O nível de detalhamento depende da necessidade de entendimento do
produto a ser criado ou mantido.

Os seguintes motivos não são válidos:

 Você está usando um processo prescritivo que lhe diz para fazê-lo, então você o faz sem

considerar se isso tem sentido em relação ao processo de desenvolvimento ágil.

 Alguém lhe pediu o modelo, entretanto não sabe explicar porque ele precisa dele.
 Você está gerando um modelo para uma pessoa que você quer evitar de conversar

diretamente com ela, portanto tem a opção de fazê-lo ou não.

Tenha mais de um modelo
Você tem diversos modelos disponíveis, onde cada pode ser utilizado em uma perspectiva
diferente. Você deve levar em consideração os pontos fortes e os pontos fracos de cada um dos
modelos. Cada modelo tem o seu contexto específico. Você tem que analisar a necessidade ou não
de criar cada um dos modelos, variando em função do tipo de solução que você irá implementar.

Você precisa de uma caixa de ferramentas intelectual

Da mesma forma que um carpinteiro possui uma caixa de ferramentas, um desenvolvedor deve
conhecer e ter a disposição diversas ferramentas no desenvolvimento de sistemas. Ele não irá
utilizar todas as ferramentas ao mesmo tempo, entretanto algumas ferramentas são úteis em
determinadas ocasiões. Cada ferramenta tem seus modelos específicos e podem ser utilizados em
ocasiões adequadas.

Um diagrama de sequência da UML para realizar um pedido

Fonte: Ambler (2004, p. 46).

 Um diagrama de fluxo de interface com o usuário

Fonte: Ambler (2004, p. 47).

Essas ferramentas podem ser representadas pelos conhecimentos dos desenvolvedores em

metodologias disponíveis para o desenvolvimento de sistemas, tais como as apresentadas nas
figuras acima. Esse conhecimento está inerente à experiência profissional de cada um dos
desenvolvedores.

Incentive o trabalho de qualidade

Ninguém gosta de trabalho de má qualidade, nem o cliente nem o desenvolvedor. O trabalho de
qualidade melhora a comunicação no projeto. Já um trabalho de má qualidade pode gerar
desmotivação da equipe e influencias as manutenções futuras do produto de software.

É importante que todos tenham a coragem de levantar e dizer que precisa de mais tempo para
realizar um bom trabalho. É necessário buscar utilizar o tempo de modo inteligente para gerar um
produto de qualidade e que corresponda às necessidades do cliente e às expectativas das pessoas
envolvidas no projeto

Maximize o retorno que seus cliente terão

O retorno é um dos cinco valores da Modelagem Ágil. Como citamos anteriormente o feedback é
um fator fundamental para corrigir erros e determinar decisões futuras. A proximidade com o
cliente é um fator positivo para se obter esse retorno.

A construção de sistemas com um ciclo mais curto é outro fator importante. Os problemas podem
ser corrigidos à tempo, principalmente quando os principais problemas estão situados no
entendimento dos requisitos ou nas fases iniciais do projeto. É necessário manter o foco e buscar
trabalhar de forma a ter um retorno rápido e efetivo para o cliente.

2.3 Princípios Suplementares

Ambler (2004) informa que os Princípios Suplementares definem conceitos que visam aumentar a
eficiência dos modeladores ágeis. Embora esses princípios sirvam de apoio aos Princípios Básicos
da MA, a sua adoção é opcional caso você seja realmente um modelador ágil. Eles devem estar
adequados à cultura organizacional para ser adotados.

Os Princípios Suplementares da Modelagem Ágil são:

O conteúdo é mais importante que a forma

A Modelagem Ágil não critica a utilização de uma Ferramenta CASE. Entretanto se um diagrama
pode ser desenhado de forma manual, porque utilizar a ferramenta?

O importante é que o desenvolvedor busque representar a forma do desenvolvimento do sistema,

não tendo que utilizar obrigatoriamente uma ferramenta para isso. O ideal é adequar a geração do
modelo à necessidade do projeto.

Todos podem aprender com todos

Os modeladores ágeis devem reconhecem que nunca sabem tudo sobre algo e que há sempre
uma oportunidade de se conhecer mais ou expandir o seu conhecimento sobre algum tema ou
assunto. Cada um é responsável para melhorar a sua caixa de ferramentas intelectual, buscando o
constante aprimoramento profissional.

Conheça seus modelos

O modelador ágil deve conhecer todos os modelos disponíveis, deve entender quais os pontos
fortes e fracos de cada um dos modelos disponíveis e reconhecer que os modelos podem facilitar a
comunicação do que se deve fazer no projeto. O importante é lembrar que a sua geração
demanda tempo de trabalho.

Adaptação local
A utilização da Modelagem Ágil deve levar em consideração a cultura da organização ou do cliente.
A adaptação pode ser feita no nível individual ou do projeto. A Modelagem Ágil pode não funcionar
em todas as situações. Em algumas empresas, dependendo do contexto do negócio, pode não ser
realista adotar a Modelagem Ágil. Isso pode acontecer em função do tipo de negócio ou das
disposições legais sobre ele.

Comunicação aberta e honesta

As pessoas devem ter consciência que são livres e que estão liberadas para dar sugestões, nelas
incluindo ideias pertinentes ao uso de um ou mais modelos.
Isso requer comprometimento por parte de todos para gerar uma comunicação harmônica e
efetiva. As pessoas que ousam falar devem estar abertas a ouvir algo de alguém que não possam
gostar do que foi dito. Ao mesmo tempo deve existir a humildade por parte de todos para
abandonarem as suas ideias caso a opinião do outro seja mais válida para o projeto.

Trabalhe com o instinto das pessoas

É importante escutar os componentes do projeto quando for identificado que algo não vai
funcionar uma vez que existe possibilidade de eles estarem certos. À medida que os projetos são
concluídos, as experiências passadas criam um instinto para identificar o que vai dar certo ou não
e isso não deve ser ignorado.

Para Saber Mais

Leia o artigo “Modelagem ágil”, de Rodrigo Yoshima, para se aprofundar no tema.
Você finalizou a segunda aula sobre Modelagem Ágil, seus valores, seus princípios e orientações.
Agora já é capaz de responder quando devemos adotá-la e quando não devemos.
Na próxima aula você irá estudar a respeito de Requisitos Ágeis, Análise Ágil e Projeto Ágil,
vinculados à Modelagem Ágil.

Aula 3 - A Modelagem Ágil e o Processo

Unificado
Nas aulas anteriores você estudou a respeito do Manifesto Ágil, da Modelagem Ágil, dos Modelos
Ágeis e dos problemas enfrentados pelo desenvolvimento de software nas organizações. Foi
abordado ainda sobre os Valores, Princípios Fundamentais e Princípios Suplementares da
Modelagem Ágil.
Nesta aula você irá estudar os tópicos envolvendo a Modelagem Ágil e o seu relacionamento com o
UnifiedProcess – UP.
Boa aula!
3.1 Processo Unificado
No Processo Unificado, todos os trabalhos são organizados em disciplinas, incluindo a modelagem
e a sua execução acontece de forma iterativa e incremental. No EntrepriseUnifiedProcess – EUP as
cinco fases ocorrem de forma sequencial, à medida que o tempo for passando. Na incepção, o
foco está centralizado na iniciação do projeto. Quando o escopo estiver definido, a próxima etapa,
aelaboração,os requisitos são analisados e ocorreo desenvolvimento da arquitetura.
Na construção o foco está na codificação do sistema. A entrega do produto acontece na fase
de transição e uma vez que o produto entra em funcionamento entra-se na fase de produção.
 O Ciclo de vida do EUP

Fonte: (IBM, 2012)

Segundo Sommerville (2011), o RUP é um exemplo de modelo de processo moderno, derivado da

UML e do Processo Unificado, incluindo 4 fases distintas. Suas fases são equalizadas com as
atividades dos processos e estreitamente relacionadas ao negócio e não a assuntos técnicos, como
acontece com o modelo em cascata.

Na concepção ou iniciação o objetivo é estabelecer um business case para o sistema.

Na elaboração é a compreensão do problema dominante, estabelecendo um framework da
arquitetura para o sistema, desenvolvendo um plano e identificando os maiores riscos.
Na construção envolve o projeto, programação e testes do sistema, já na transição acontece a
transferência do sistema da comunidade de desenvolvimento para a comunidade de usuários e a
sua disponibilização em um ambiente real.
 O Ciclo de vida do RUP

Fonte: (IBM, 2012).

3.2 Processo Unificado e a Modelagem Ágil

Para continuar o relacionamento entre o Processo Unificado e a Modelagem Ágil é importante
saber como a modelagem acontece no Processo Unificado.

Na Modelagem de Negóciosé feita a modelagem no contexto do negócio, determinando o

escopo do sistema. Depois é realizada a engenharia nos requisitos do projeto, envolvendo a
identificação, modelagem e a documentação dos requisitos do sistema. O material mais
importante é o Modelo de Requisitos, também chamado de Especificação de Requisitos de
Software (SRS –Software RequirementsSpecification). Na Análise e Projeto é desenvolvida uma
arquitetura robusta para o sistema, tomando como base os requisitos, transformando-os em
projeto e garantindo que os temas estejam devidamente relacionados ao ambiente do projeto. Já
o Gerenciamento de Infraestrutura envolve atividades que não estão no projeto individual,
envolvendo a modelagem de requisitos empresariais e a modelagem da arquitetura empresarial.
A seguir serão apresentadas as práticas do Processo Unificado, segundo Ambler (2004), indicando
quais são as adaptações que podem ser realizadas para que esse processo trabalhe em conjunto
com a Modelagem Ágil.
 Organize uma participação ativa dos clientes – Quanto maior for a participação dos

clientes, menor será a necessidade de realização de revisões, apresentações ou outras

atividades que podem retardar a velocidade da equipe de desenvolvimento. Essa prática é
compatível entre o UP e a MA, uma vez que o UP não impede que isso aconteça.
 Aplique as convenções da modelagem – O UP a aplicação da modelagem utilizando

diversos diagramas da UML, incluindo diretrizes para a criação de muitos artefatos de

modelagem, baseando nas necessidades específicas. Para se tornar ágil nessa prática é
 necessário não deixar que esses diagramas se tornem uma camisa de força, combinando
diretrizes e padrões.
 Utilize padrões com moderação – As equipes UP são livres para adotar padrões de

modelagem. A adoção desses padrões deve ser realizada em conformidade com as

necessidades de cada um dos projetos utilizando a MA.
 Aplique artefatos corretos – Um dos pontos fortes do UP é que ele apresenta conselhos

para quando criar cada tipo de modelo. As versões mais recentes do RUP apresentam
conselhos para artefatos não-UMO, como modelo de dados e storyboards de interface com o
usuário, que podem ser muito utilizados para a MA.
 Promova a posse coletiva – Aqui precisarão ser feitas algumas adaptação no UP,

permitindo que qualquer pessoa no projeto acesse qualquer artefato que deseje e trabalhe
no mesmo, incluindo documentos e modelos. O UP concentra-se em temas de
gerenciamento de configuração que controlam o acesso dos desenvolvedores.
 Considere a testabilidade – O UP incluí uma disciplina de Teste em seu ciclo de vida,

fazendo que todos tenham isso em mente quando trabalham. Tem também muitas
oportunidades de revisar artefatos de modelagem, caso necessário.
 Crie diversos modelos em paralelo – O UP inclui esse conceito. Basta ver os diagramas

de atividades que mostram cada disciplina para ver que diversos artefatos podem ser
trabalhados em paralelo. As equipes UP devem mudar um pouco o foco para ler nas
entrelinhas dos diagramas de atividades das disciplinas e do ciclo de vida do UP e decidir
quando desempenhar diversas disciplinas simultaneamente, quando for o caso.
 Crie conteúdos simples – O modelador poderá decidir simplificar o conteúdo dos modelos,

entretanto os demais membros da equipe devem concordar com essa simplificação. Esse
pode ser um problema cultural, que muitas empresas podem encontrar dificuldades em
implantar.
 Mostre os modelos de modo simples – Essa prática segue a mesma linha da simplificação

dos conteúdos.
 Descarte os modelos temporários – Os modeladores UP tem a mesma liberdade de

descartar os modelos temporários, seguindo a mesma linha de Simplicidade da MA.

 Mostre os modelos publicamente – As equipes UP são livre para seguir essa prática,

seguindo o princípio de Comunicação Aberta e Honesta, liberando os artefatos para todos e

mostrando publicamente os modelos cruciais usados pela equipe do projeto.
 Formalize os modelos de contrato – O UP inclui o conceito de integração com os sistemas

externos, seja da organização ou fora da empresa. Essa interação pode ser especificada com
um ou mais casos de uso em então a realização de caso de uso correspondente se torna o
modelo de contrato formalizado.
 Itere em outro artefato – Uma descrição infeliz das atividades de modelagem UP como

processos quase seriais e a divisão dessas atividades em disciplinas separadas pode

atrapalhar o modo de pensar iterativo exigido pelos modeladores ágeis.
  Modele incrementalmente – As equipes UP podem melhorar um pouco o foco iterativo e

incremental, dando preferência a modelos menores e mais simples que possam levar mais
rapidamente à implementação e ao teste.
 Modele para comunicar – O importante é modelar sabendo quem é o público alvo dessa

modelagem e o que esse público requer. O UP inclui explicitamente esta prática.

 Modele para entender – Esta prática tem o mesmo objetivo do Modele para Comunicar,

onde só deve ser modelado aquilo que precisa ser entendido.

 Modele com outras pessoas – As equipes UP podem melhorar a comunicação, adotando

ferramentas de suporte à modelagem em equipe, como quadros e ferramentas colaborativas

de modelagem em vez de ferramentas de modelagem para um usuário único.
 Comprove com código – A recomendação é que se tenha, ao final de cada iteração, uma

versão do produto. A UP insiste em que no final da fase de Elaboração já se tenha um

protótipo em funcionamento para comprovar a arquitetura.
 Reuse os recursos já existentes – A reusabilidade já está implícita nas práticas da UP não

se limitando a software de fonte aberto ou ferramentas preexistentes.

 Atualiza apenas quando necessário – A atualização dos modelos e artefatos, para reduzir

dramaticamente o trabalho dispendido é uma prática adotada pela MA. Entretanto em

organizações, onde existe a rastreabilidade de requisitos e uma Gerência de Mudanças e
Configuração isso pode se tornar um problema. Para solucionar esse problema pode-se
manter uma matriz de rastreabilidade entre os artefatos quando isso trouxer um claro
benefício,
 Use as ferramentas mais simples – As equipes UP podem aumentar bastante a

produtividade expandindo seus horizontes para incluir ferramentas simples como quadros,
cartões de índices e notas autocolantes, além das ferramentas CASE, quando for o caso.

Para Saber Mais

Leia o artigo “Comparação entre metodologias ágeis e tradicionais para o desenvolvimento de
software”, de Michel dos Santos Soares, onde você verá um comparativo entre metodologias de
desenvolvimento de software.
Nesta aula você pôde perceber que a Modelagem Ágil pode ser conciliada com outro processo, a
partir de adaptações realizadas em suas práticas, melhorando a performance de suas equipes e
agilizando a entrega dos produtos de software para seus clientes. Com certeza, os clientes ficarão
muito satisfeitos com essa adaptação, pois poderão contar com as soluções num menor tempo.

Aula 4 - Modelagem de Negócios e Requisitos

Ágeis
Nas aulas anteriores você estudou a respeito do Manifesto Ágil, da Modelagem Ágil, dos Modelos
Ágeis e dos problemas enfrentados pelo desenvolvimento de software nas organizações. Estudou
ainda sobre os Valores, Princípios Fundamentais e Princípios Suplementares da Modelagem Ágil,
bem como a utilização da Modelagem Ágil com o Processo Unificado.
Nesta aula você estudará os tópicos envolvendo a Modelagem de Negócios, Requisitos, Análise e
Projeto Ágeis e o seu relacionamento com o UnifiedProcess – UP.
Boa aula!
4.1 Modelagem Ágil
Como se executa a modelagem de negócios em um projeto UP/MA?

Inicialmente realize uma sessão de modelagem para explorar os requisitos iniciais visando
construir uma visão comum do negócio com o cliente. Vai depender do tempo disponível e o nível
de detalhamento que for decidido que será utilizado para a modelagem.Pode envolver Requisitos
Ágeis e Análise e Projeto Ágeis. Quando não puder se chegar a uma visão comum, várias sessões
de modelagem devem ser realizadas.

Alguns artefatos podem ser gerados durante essa sessão. São eles:

Modelo de Casos de Uso de Negócio

Ele serve para melhorar a comunicação a partir do momento que todos entendem os diagramas
criados. Serve como ajuda para construir a harmonia com os clientes.

Todos aprendem a partir desse modelo sobre o negócio e sobre o desenvolvimento de software. A
figura abaixo mostra um exemplo desse diagrama.

Diagrama de casos de uso de alto nível.

Fonte: (AMBLER, 2004, p. 237).

ModeloSimples Objeto de Negócio

A disciplina de Modelagem de Negócios tem como um dos seus principais objetivos entender como
o negócio é realizado e uma maneira de fazer isso é realizando uma modelagem conceitual ou de
domínio. Uma das abordagens que podem ser utilizadas é a criação de um modelo simples de
objetos de negócios que permita visualizar a estrutura dos conceitos de negócios e identifique as
entidades mais importantes e os seus respectivos relacionamentos. Utilizando do princípio de
utilizar a ferramenta mais simples e a aplicação de um artefato correto e escolhendo técnicas mais
simples, os cartões CRC podem ser utilizados para realizar essa modelagem conceitual. A figura
abaixo mostra um exemplo desse cartão.

Cartões CRC para as Classes, Clientes e Pedidos

Fonte: (AMBLER, 2004, p. 239).

EspecificaçãoNegócio Suplementar Ágil

O artefato para a Especificação Negócios Suplementar Ágil junta os requisitos da modelagem de
negócios que parecem não se ajustar bem em outro lugar. Servem para capturar informações
para serem analisadas posteriormente. Servem para entender melhor os requisitos e capturar
informações suficientes que podem derivar regras de negócios, restrições, requisitos técnicos e até
possíveis requisitos futuros de sistema. A figura abaixo mostra um exemplo desse documento.
 Especificação de Negócios Suplementar Ágil

Fonte: (AMBLER, 2004, p. 241).

Visão de Negócio
O documento com a Visão do Negócio visa identificar uma visão comum do negócio dentro do
grupo, buscando chegar a um consenso com os clientes. O RUP sugere a criação de um
documento com a visão de negócio para registrar o resultado dos trabalhos nesta fase. O template
desse documento pode ser obtido a partir do RUP – Visão de Negócio.

O Índice Analítico, apresentado a seguir, permite uma visão dos tópicos que envolvem o
documento Visão de Negócio.

Índice Analítico (Visão do Negócio)

1. Introdução

1.1 Finalidade

1.2 Escopo

1.3 Definições, Acrônimos e Abreviações

1.4 Referências

1.5 Visão Geral

2. Posicionamento

2.1 Oportunidade de Negócios

2.2 Descrição do Problema

2.3 Sentença de Posição do Produto

3. Descrições dos Envolvidos e dos Clientes

3.1 Demografia do Mercado

3.2 Resumo dos Envolvidos

3.3 Resumo dos Clientes

3.4 Ambiente dos Clientes

3.5 Perfis dos Envolvidos

3.5.1 <Nome dos Envolvidos>

3.6 Perfis dos Clientes

3.6.1 <Nome dos Clientes>

3.7 Principais Necessidades dos Envolvidos ou dos Clientes

3.8 Alternativas e Concorrência

4. Objetivos da Modelagem de Negócios

4.1 <anObjective>

4.2 <anotherObjective>

5. Restrições

6. Intervalos de Qualidade

7. Precedência e Prioridade

8. Outros Requisitos

8.1 Padrões Aplicáveis

8.2 Requisitos do Sistema

8.3 Requisitos de Desempenho

8.4 Requisitos Ambientais

Apêndice A — Atributos de Objetivos

4.2 Requisitos Ágeis

Como executar a modelagem de requisitos em um projeto UP/MA?

O ideal seria a realização de uma ou mais sessões formais de modelagem dos requisitos do
projeto, visando identificar os requisitos iniciais do sistema e chegar a uma visão do mesmo. Essas
sessões permitiriam chegar ao escopo do sistema ou pelo menos ter uma versão do que se está
trabalhando no momento.

Um ponto importante é conseguir ter acesso imediato aos clientes, para que eles nos ajudem a
identificar e priorizar requisitos, gerandouma Especificação de Requisitos de Software, conhecida
como Modelo de Requisitos nas versões anteriores do RUP.

Partindo de uma abordagem UP/MA, seriam gerados os seguintes artefatos na disciplina de

Requisitos:

Modelode Contexto
Esse modelo visa mostrar como o sistema se ajusta no seu ambiente global. Para essa modelagem
podemos nos utilizar o Diagrama de Casos de uso. A utilização do tipo de artefato depende do
contexto do software, conforme a figura abaixo. Esse diagrama depende do contexto em que está
envolvido a organização e o sistema que está sendo especificado.

Diagrama de casos de uso de negócio

Fonte: (AMBLER, 2004,

p. 245).

Uma outra abordagem que pode ser utilizada é o desenvolvimento do modelo de contexto que
mostre como o sistema se ajusta em um determinado ambiente global, conforme as figuras
abaixo.
 Diagrama de Fluxo de Dados- DFD

Fonte: (AMBLER, 2004, p. 245).

Diagrama de Fluxo de Dados- DFD

Fonte: (AMBLER, 2004, p. 246).

Modelo de Casos de Uso

A evolução da especificação pode ocorrer a partir do Diagrama de Casos de Uso acima
apresentado, onde tínhamos na Modelagem de Negócios uma visão inicial do negócio. A partir
desse diagrama podem ser implementadas mais informações ou partir para a definição dos
cenários que cada caso de uso irá apresentar. Por exemplo, o caso de uso Fazer Pedido inclui
Buscar Itens. Poderia ser feito o detalhamento desse cenário, visando o aprofundamento desse
contexto. Partindo do principio que esse caso de uso deverá necessitar de uma interface a ser
aplicada em um browser, podemos trabalhar com notas autocolantes para identificar quais os
atributos que deverão constar nesse interface, conforme mostra a figura abaixo.

Protótipo de uma Interface com o usuário

Fonte: (AMBLER, 2004, p. 249).

StoryBoardde Casos de Uso

Esse artefato serve para mostrar como um caso de uso é suportado pela interface com o usuário
do sistema. Essa é uma atividade de análise ou mesmo de projeto, uma vez que você está
explorando como implementar um requisito. Um exemplo desse artefato é mostrado na figura
abaixo.
 Diagrama de Robustez para o caso de uso Fazer Pedido

Fonte: (AMBLER, 2004, p. 249).

Especificação Suplementar
É onde a grande maioria dos seus requisitos de sistema está documentada. Ela serve como
documento auxiliar paraos casos de uso incluindo regras de negócios, restrições, requisitos
técnicos e qualquer outro requisito não relacionado a casos de uso do sistema. O importante é que
os modeladores ágeis devemdiscutir todos os documentos criados.

Na realidade, a disciplina de Requisitos deve focalizar o software, não a documentação. O

importante é manter tudo simples e criar uma versão minimalista de cada artefato, proceda
iterativamente, mantenha tudo simples, procure usar ferramentas simples e trabalhe em equipe.

Para Saber Mais

Leia o artigo “A nova metodologia”, de Martin Fowler, onde o autor explora os motivos por trás
das metodologias ágeis.
Nesta aula você estudou sobre como realizar a modelagem de negócios e trabalhar com os
requisitos do sistema, utilizando o Processo Unificado conciliado com a Modelagem Ágil. Na
próxima aula estudará as disciplinas de Análise e Projeto Ágeis, visando complementar a
especificação de um sistema e depois estudará a implementação do mesmo no ambiente de
desenvolvimento.

Aula 5 - Análise e Projeto Ágeis

Na aula anterior foi feita a abordagem sobre Modelagem de Negócios e em Requisitos. Você
estudou o que é feito em cada uma das fases, quais os artefatos que podem ser gerados e a sua
utilidade na modelagem de um sistema utilizando o Processo Unificado conciliado com a
Modelagem Ágil.

Nesta aula você continuará estudando a especificação de um sistema, partindo para a Análise e
Projeto Ágeis.

Boa aula!

5.1 Análise e Projeto Ágeis

Como executar a análise e projeto em um projeto UP/MA?

O propósito da Análise e Projeto é o desenvolvimento de uma arquitetura robusta para o sistema,
gerando um projeto detalhado baseado nos requisitos, adaptando o projeto visando refletir a
realidade do ambiente de implementação. As entradas dessa disciplina são os artefatos gerados
durante a disciplina de requisitos e na modelagem de negócios.

A disciplina de Análise e Projeto em um projeto UP/MA deve considerar os temas a seguir.

5.1.1 Repensando Modelos de Análise e Projeto no UP

É importante criar uma linha básica para as versões dos modelos e manter pelo menos um pouco
de rastreabilidade entre elas. Nessa etapa é necessário decidir se será gerada uma matriz de
rastreabilidade, conforme mostra a figura abaixo ou se os demais artefatos existentes na
organização serão atualizados. É preciso lembrar que essa decisão atende as necessidades do
Gerenciamento de Mudanças e Configuração, entretanto a equipe se tornará mais lenta em função
da quantidade de artefatos que deverão ser atualizados. Essa é uma decisão empresarial, que
depende mais do contexto da empresa e da sua necessidade da implementação em curso.
 Rastreabilidade entre os artefatos mais importantes no PU.

Fonte: (AMBLER, 2004, p. 258).

5.1.2 Modelagem da Arquitetura

Normalmente, a equipes de desenvolvimento UP geram uma modelagem inicial da arquitetura
durante a fase de Incepção. Na Elaboração na disciplina de Análise e Projeto é definida a
arquitetura e nesta fase é desenvolvido um protótipo de arquitetura para mostrar como a
arquitetura funciona de fato.

Os modeladores ágeis comumente criam um ou mais diagramas de visão geral, também

nomeados de diagramas de navegação, apresentando uma visão geral do sistema, como um mapa
que mostra a organização de uma cidade, esses diagramas mostram a organização do sistema,
suas visões arquiteturais e as suas instanciações. Ambler (2004), apud Kruchten (1995) descreve
uma visão 4 + 1 da arquitetura do RUP adotada inicialmente e que depois se expandiu. As cinco
visões são:
 Visão Lógica – utilizada para modelar as características funcionais do sistema que é

fornecida ao usuário final.

 Visão do Processo – utilizada para modelar como o sistema satisfaz os requisitos não

funcionais, envolvendo, inclusive, a especificação de qual thread de controle executa cada

operação de cada classe identificada na visão lógica.
 Visão do Desenvolvimento – utilizada para modelar a organização dos módulos do

sistema, frequentemente organizado em camadas.

  Visão Física – utilizada para modelar como o sistema será distribuído, incluindo subvisões

para os vários ambientes existentes na organização.

 Visão de Cenários (caso de uso) – utilizado para modelar um subconjunto de cenários de

casos de uso ou casos de uso que são significativos para a arquitetura, mostrando como os
elementos se ajustam nas quatro primeira visões.

A figura abaixo permite visualizar um modelo de implantação da UML e seus diversos dispositivos.

Diagrama de Implantação da UML

Fonte: (AMBLER, 2004, p. 260)

A figura abaixo permite visualizar como poderíamos organizar o nosso código de negócio através
de um diagrama de componentes da UML.
 Diagrama de Implantação da UML

Fonte: (AMBLER, 2004, p. 261).

A figura seguinte permite visualizar a explicação de um desenvolvedor que uma interface para o
componente é definida em uma ou mais sessões de beans e que sua experiência levou a não
fornecer acesso direto a entidades beans. Uma sessão bean irá realizar a interação com as
entidades bean EJB, com outras sessões bean EJB, objetos Java normais ou com o banco de
dadosbackend (AMBLER, 2004).
Um breve esboço descrevendo uma estratégia de implementação de um componente de negócio

Fonte: (AMBLER, 2004, p. 261).

5.1.3 Criando Realizações de Casos de Uso

Uma realização de um caso de uso gera efetivamente uma coleção ou mais de modelos que
descreve a implementação de um único caso de uso. A realização é feita a partir da análise do
caso de uso, ligando a descrição dele à sua análise e projeto. O RUP associa cada caso de uso a
um caso de uso de sistema. Pensando nesse sentido estaremos realizando um caso de uso de
sistema.

A seguir apresentamos um diagrama de robustez e uma figura lógica do caso de uso Fazer Pedido.

Diagrama de Robustez

Fonte: (AMBLER, 2004, p. 265).

 Lógica do caso de uso Fazer Pedido

Fonte: (AMBLER, 2004, p. 264).

Uma vez que as classes foram identificadas, ficou fácil a elaboração de um diagrama de
sequência, conforme mostra a figura abaixo.

Diagrama de Sequência da UML do caso de uso Fazer Pedido

Fonte: (AMBLER, 2004, p. 266).

Em paralelo pode ainda ser desenvolvido um diagrama de classe em nível de análise.

 Diagrama de Classes da UML em nível de análise do caso de uso Fazer Pedido

Fonte: (AMBLER, 2004, p. 266).

5.1.4 Hora de Atualizar o Caso de Uso

É necessário avaliar se a lógica do caso de uso precisa ser revista, principalmente o caso de uso
constante que é um caso de uso fundamental do sistema. Nesse sentido o aprofundamento
daquilo que o caso de uso realiza precisa ser melhor detalhado, visando evitar falhas na realização
do negócio. Essa análise pode ser feita levando em consideração a interface do usuário, constante
da figura abaixo. Observe que existe inconsistência entre a lógica apresentada e a figura. Foi
observado que é necessário calcular os custos de manuseio e remessa. Então é hora de atualizar o
caso de uso, lembrando a prática Atualize apenas quando é necessário.
 Protótipo de Interface com o Usuário

Fonte:(AMBLER, 2004, p. 267).

5.1.5 Hora de Usar Ferramenta Case?

A decisão de utilização de uma Ferramenta Case na Modelagem Ágil depende da ferramenta e a
sua facilidade de uso. Em algumas situações, a geração de um modelo pode ser mais simples na
ferramenta CASE do que manualmente. A decisão da utilização ou não da ferramenta deve ficar
nas mãos da equipe de desenvolvimento.

5.1.6 Modelagem de Projeto de Classes

Segundo Ambler (2004), os diagramas de classes da UML são muito bons para modelar a
estrutura estática do software orientado a objetos ou para mostrar as classes e seus
relacionamentos. Eles não bons para modelar a natureza dinâmica ou para mostrar os objetos
colaborando entre si para executar responsabilidades. Aqui devemos pensar na prática Aplique o
Artefato Correto e pensar se esse é o melhor diagrama para representar o que queremos. Outra
prática é Modele com um Propósito e verificar se o nosso diagrama está sendo realmente
importante em algum ponto do desenvolvimento.

A figura seguinteapresenta o diagrama de classes de análise do caso de uso Fazer pedido,

elaborado com uma ferramenta CASE.
 Diagrama de Classe de Análise do caso de uso Fazer Pedido

Fonte:(AMBLER, 2004, p. 270).

5.1.7 Modelagem de Dados

Pensando em Análise e Projeto Ágeis UP/MA, é importante enfocar primeiro a implementação de
um componente, no nosso caso o ComponentePedido e o Item, seguindo os seguintes passos:

Pegar um conjunto de parâmetros que representam o critério de busca – Nesse contexto pode ser
utilizado o protótipo da interface do usuário.

Protótipo de Interface com o Usuário

Fonte: (AMBLER, 2004, p. 272).

Interpretar o critério – Avaliar os componentes da interface, simulando um critério de busca de
informação.

Formular um comando SQL SELECT que represente o critério de busca – A partir dos componentes
interpretados na interface, modelar as informações que devem ser armazenadas referente aos
componentes identificados gerando um modelo de dados.

Modelo de dados

Fonte: (AMBLER, 2004, p. 274).

Retorne o resultado de cada busca – Avaliar o resultado das instruções SQL geradas e avaliar o
modelo para verificar se ele atenderá todas as necessidades, representadas pelo protótipo da
interface com o usuário.

O próximo passo é a definição e especificação dos próximos casos de uso que compõem o sistema.
Com certeza, mudanças irão estar presentes durante o desenvolvimento desse sistema e devem
ser encarados com normalidade, levando em consideração o princípio Encampe as Mudanças. A
Modelagem Ágil tem como premissa principal que a mudança faz parte do processo e deve ser
encarada normalmente, o que não ocorre com muita naturalidade no desenvolvimento tradicional.

Para Saber Mais

Leia o artigo “Metodologias ágeis: um novo paradigma de desenvolvimento de software” , de
Renata Bastos Ferreira e Francisco de Paula Antunes Lima, onde os autores falam sobre a
utilização de novas metodologias de desenvolvimento de software por empresas de TI.
Com esta aula você terminou a sua jornada pelo desenvolvimento de sistemas com o Processo
Unificado conciliado com a Modelagem Ágil. Nas próximas aulas você irá explorar algumas
metodologias de desenvolvimento ágil que estão em conformidade com os valores e os princípios
estudados nas primeiras aulas sobre a Modelagem Ágil.

Aula 6 - Scrum
As abordagens das aulas anteriores se caracterizavam por estarem centradas nos valores,
princípios e a Modelagem Ágil em consonância com o Processo Unificado. A partir desta aula você
estudará as metodologias de Modelagem Ágil existentes no mercado e que podem ser utilizadas
nas empresas, dentre elas a Scrum, objeto de estudo desta aula.
Boa aula!
6.1 Scrum
Segundo Schwaber e Sutherland (2010), milhares de pessoas contribuíram para o Scrum,
destacando aquelas que contribuíram em seus primeiros dez anos. Primeiro havia o Jeff
Sutherland, trabalhando com o Jeff McKenna, e Ken Schwaber com Mike Smith e Chris Martin. O
Scrum foi formalmente apresentado e publicado no OOPSLA 1995. Durante os cinco anos
seguintes, Mike Beadle e Martine Devos fizeram contribuições significativas. E então todos os
outros, que sem a sua ajuda do Scrum não teria sido aprimorado no que é atualmente.
Scrum é baseado nas melhores práticas aceitas pelo mercado, utilizadas e provadas por décadas.
Ele é definido então em uma teoria de processos empíricos. Como Jim Coplien certa vez observou
para o Jeff, “todos irão gostar de Scrum; isso é o que já fazemos quando nos pressionam contra a
parede” (SCHWABER; SUTHERLAND, 2010).
Scrum é um framework que pode ser empregado conjugado com diversos processos e técnicas.
Seu papel é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que
você possa melhorá-las, enquanto provê um framework dentro do qual, produtos complexos
podem ser desenvolvidos. Ele funciona bem dentro de ambientes controlado.
Segundo Schwaber e Sutherland (2010), o Scrum, que é fundamentado na teoria de controle de
processos empíricos, emprega uma abordagem iterativa e incremental para otimizar a
previsibilidade e controlar riscos. Três pilares sustentam cada implementação de controle de
processos empíricos. Seus pilares são transparência, adaptação e inspeção.
 Transparência – garante que os aspectos do processo que afetam o resultado devem ser

visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem ser
transparentes, mas também o que está sendo observado deve ser conhecido. Ou seja,
quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser
equivalente à sua definição de pronto.
 Inspeção – se um ou mais aspectos do processo devem ser inspecionados com uma

frequência suficiente para verificar as variações inaceitáveis no processo para que possam
ser detectadas e tratadas. A frequência da inspeção deve considerar que qualquer processo
pode ser modificado pelo próprio ato da inspeção. O problema acontece quando a frequência
de inspeção necessária excede a tolerância do processo à inspeção. Felizmente, isso não
parece ser verdade no desenvolvimento de software. Os outros fatores são a habilidade e a
aplicação das pessoas na inspeção dos resultados do trabalho.
 Adaptação – Se um inspetor determinar, a partir de uma inspeção, que um ou mais

aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será
 inaceitável, ele deverá ajustar o processo ou o material que está sendo processado. Esse
ajuste deverá ser feito o mais rápido possível para minimizar os desvios posteriores.
Existem três pontos para inspeção e adaptação em Scrum: Reunião diária, Reuniões de revisão
de Sprint e de Planejamento da Sprint e, finalmente, Retrospectiva da Sprint. Esses pontos serão
detalhados nos próximos tópicos que compõem esta aula.
6.2 Conteúdo do Scrum
O Framework Scrum é formado por um conjunto formado por Times do Scrum com papéis
associados, eventos com duração fixa, artefatos e regras. Os times são formados visando à
otimização, flexibilidade e produtividade. Os times devem ser auto-organizáveis, multidisciplinares
e devem trabalhar em iterações.

Cada Time Scrum possui três papéis:

 Scrum Master – Responsável por garantir que o processo seja entendido e seguido. Ele é o

responsável pelo fornecimento dos requisitos do sistema.

 ProductOwner – Responsável por maximizar o valor do trabalho que o time faz.
 Time – Executa o trabalho propriamente dito. Consiste de desenvolvedores habilitados para

transformar os requisitos do ProductOwnerem um pedaço potencialmente entregável do

produto ao final da Sprint.

O Scrum emprega os eventos com duração fixa, chamados de TIME-BOXES, que são usados para
criar uma regularidade. Entre os elementos do Scrum que têm uma duração fixa citamos:

 Reunião de Planejamento da Sprint.

 Reunião de Planejamento da Release.
 A Sprint.
 Daily Scrum.
 Revisão da Sprint.
 Retrospectiva da Sprint.

O ponto central do Scrum é a Sprint, que deve ser representada por uma iteração de um mês ou
menos, de duração consistente de esforço de desenvolvimento. Ao final de uma Sprint espera-se
um incremento no produto final, que é potencialmente entregável. O início da próxima Sprint deve
ser logo após o término da Sprint encerrada.

O Scrum utiliza quatro artefatos principais. São eles:

 ProductBacklog – Trata-se de um documento que contém uma lista priorizada de tudo que

foi identificado como necessário no produto.

 Sprint Backlog – Trata-se de um documento contendo uma lista de tarefas que fazem parte

do ProductBacklog e que foram selecionadas para fazer parte de uma Sprint gerando uma
parte do produto solicitado pelo cliente.
 Burndownda Release – Trata-se de um documento que mede o Product Backlog restante

ao longo do tempo de um plano de Release.

 Burndown da Sprint – Trata-se de um documento que mede os itens do Backlog da Sprint

restantes ao longo do tempo de uma Sprint.

6.3 Papéis do Scrum
Segundo Schwaber e Sutherland (2010, p. 6), o time de Scrum é composto pelo ScrumMaster,
pelo ProductOwner e pelo time. Os membros do time de Scrum são chamados “porcos”. O
ProductOwner é o “porco” do ProductBacklog. O time é o “porco” do trabalho da Sprint. O
ScrumMaster é o “porco” do processo do Scrum. Qualquer outra pessoa é chamada de “galinha”.
“Galinhas” não podem dizer aos “porcos” como eles devem fazer seu trabalho. Galinhas e porcos
vêm da seguinte história:

Uma galinha e um porco estão juntos quando a galinha diz:

“Vamos abrir um restaurante!”
O porco reflete e então diz:
“Como seria o nome desse restaurante?”
A galinha diz: “Presunto com Ovos!”
O porco diz:
“Não, obrigado, eu estaria comprometido, mas você estaria apenas envolvida!”
6.3.1 Scrum Master
O ScrumMaster é responsável porgarantir que o Time de Scrumesteja aderindo aos valores
doScrum, às práticas e às regras. OScrumMaster ajuda o Time deScrum e a organização a
adotaremo Scrum. O ScrumMaster educa oTime de Scrum treinando-o elevando-o a ser mais
produtivo e adesenvolver produtos de maiorqualidade. O ScrumMaster ajuda o Time de Scrum a
entender e usar auto-organização e multidisciplinaridade. O ScrumMaster também ajuda o Time
de Scrum a fazer o seu melhor em um ambiente organizacional que pode ainda não ser otimizado
para o desenvolvimento de produtos complexos. Quando o ScrumMaster ajuda a realizar essas
mudanças, isso é chamado de “remoção de impedimentos”. O papel de ScrumMaster é o de líder-
servidor para o Time de Scrum. (SCHWABER; SUTHERLAND, 2010, p. 6-7)

6.3.2 ProductOwner
O ProductOwner é a única pessoa responsável pelo gerenciamento do Product Backlog e por
garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém o Product Backlog e garante
que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que
todos sabem em que se irá trabalhar.
O Product Owner é uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou
influenciem essa pessoa, masquem quiser mudar a prioridade de um item, terá que convencer o
ProductOwner. Empresas que adotam Scrum podem perceber que isso influencia seus métodos
para definir prioridades e requisitos ao longo do tempo.
Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar suas
decisões. Ninguém tem a permissão de dizer ao Time para trabalhar em um outro conjunto de
prioridades, e os Times não podem dar ouvidos a ninguém que diga o contrário. As decisões do
Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa visibilidade
requer que o Product Owner faça seu melhor, o que faz o papel de Product Owner exigente e
recompensador ao mesmo tempo. (SCHWABER; SUTHERLAND, 2010, p. 7-8)

6.3.3 Time
Desenvolvedores que transformam o Product Backlog em incrementos de funcionalidades
potencialmente entregáveis em cada Sprint. São interdisciplinares e devem possuir todo
conhecimento necessário para criar um incremento no trabalho. Membros que se recusam
programar por serem arquitetos ou designers não se adaptam bem aos times. Todos contribuem,
mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas. São auto-
organizáveis. Ninguém diz ao time como transformar Product Backlog em incrementos de
funcionalidades entregáveis. Nem mesmo o Scrum Master.
O tamanho ótimo para um time é de cinco a nove pessoas. Menos que isso gera menor interação e
consequentemente menor ganho de produtividade. E mais que isso poderá encontrar limitações de
conhecimento e há a necessidade de muita coordenação. Há times bem-sucedidos que excederam
esses limites. Product Owner e Scrum Master não estão incluídos na conta, a menos que também
sejam “porcos”. Deve-se tomar cuidado ao mudar a composição do time.

6.4 Time-Boxes
Os time-boxes (caixas de tempo) no Scrum são eventos com duração fixa e são os seguintes:
6.4.1 Reunião de Planejamento da Release
Tem como propósito o estabelecimento de um plano e metas que o Time Scrum e a organização
possam entender e comunicar. Responde às questões: “Como podemos transformar a visão em
um produto vencedor da melhor maneira possível? Como podemos alcançar ou exceder a
satisfação do cliente e o Retorno sobre Investimentos desejados?” (SCHWABER; SUTHERLAND,
2010, p. 9). Estabelece a meta da versão, maiores prioridades do Sprint Backlog, principais riscos
e as características gerais e funcionalidades que estarão contidas na versão; além da data de
entrega e custos prováveis, se nada mudar. Geralmente não requer mais do que 15 a 20% do
tempo que uma organização costumava utilizar para produzir um plano de versão para entrega
tradicional. P orém, consome mais esforços, pois o planejamento é realizado em cada reunião de
Revisão de Sprint e de Planejamento de Sprint da mesma forma como também é realizado no
planejamento diário. Requer estimar e priorizar o Sprint Backlog para versão.

6.4.2 Sprint
É uma iteração com duração fixa. Sprints consistem na Reunião de Planejamento da Sprint, o
desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. Ocorrem sucessivamente sem
intervalos entre elas. Scrum Master deve garantir que não haverá nenhuma mudança que afete a
meta daquele Sprint. A composição do time e metas de qualidade devem permanecer constantes
durante a Sprint.

Podem ser canceladas antes do prazo fixado. Somente o ProductOwner, influenciado ou não pelos
stakeholders, Time ou Scrum Master, tem autoridade para cancelar a Sprint. A Sprint pode ser
cancelada pela gerência se a meta se tornar obsoleta pelas condições de mercado ou tecnologia.
Porém, raramente isso ocorre devido à curta duração das Sprints. Quando a Sprint é cancelada,
todos os itens do Sprint Backlog completados e feitos são revisados e aceitos se representarem
um incremento entregável. Os demais itens do Sprint Backlog são devolvidos com suas
estimativas iniciais. Qualquer trabalho realizado nesses itens é tomado como perdido. Todos têm
que se reagrupar em outra Reunião de Planejamento da Sprint para iniciar uma nova Sprint.
Cancelamentos consomem recursos e são traumáticos para o Time e não são muito comuns
(SCHWABER; SUTHERLAND, 2010).

6.4.3 Reunião de Planejamento da Sprint

É quando uma iteração do desenvolvimento (Sprint) é planejada e é fixada em oito horas de
duração para uma Sprint de um mês. Para Sprints mais curtas, a alocação deve ser proporcional
ao tamanho da Sprint. Consiste de duas partes:

 Primeira Parte – Evento com duração fixa em quatro horas onde “o quê será feito na Sprint”

é decidido. O Product Owner apresenta ao time o que é mais prioritário. Entradas para essa
reunião: Sprint Backlog, incremento mais recente ao produto, a capacidade do time,
histórico de desempenho do time. Somente o time decide o quanto do Backlog ele deve
 selecionar. Selecionado o Sprint Backlog, a meta da Sprint é delineada. A meta define um
objetivo que será alcançado por meio da implementação do Sprint Backlog. É uma descrição
que fornece orientações ao time sobre a razão pela qual está desenvolvendo o incremento. A
Meta da Sprint é um subconjunto da meta de Versão para Entrega. Dá ao time alguma
margem com relação à funcionalidade.
 Segunda Parte – Outro evento com duração fixa de quatro horas onde o time entende como

desenvolverá essa funcionalidade em incremento de um produto durante a Sprint. O time

trata a questão do “Como”. O time define como transformará o Sprint Backlog selecionado
em incremento pronto. O time começa a projetar o trabalho. Enquanto isso, o time identifica
tarefas, pedaços detalhados do trabalho necessário para converter o Sprint Backlog em
software funcional. As tarefas devem ser decompostas para que possam ser feitas em um
dia. Essa lista de tarefas é chamada de Backlog da Sprint. Se o Time concluir que tem
trabalho demais ou de menos, ele pode renegociar o Sprint Backlog selecionado com o
ProductOwner o qual também poderá esclarecer o Sprint Backlog e ajudar a efetuar trocas
(SCHWABER; SUTHERLAND, 2010).
6.4.4 Revisão da Sprint
Sprints de um mês recomenda-se duração fixa de quatro horas. Sprints de durações mais curtas,
alocar proporcionalmente a quantidade de horas (exemplo, para duas semanas a reunião ser de
duas horas). Na Revisão da Sprint, o Time de Scrum e as partes interessadas colaboram sobre o
que acabou de ser feito. As mudanças no Product Backlog feitas durante a Sprint, eles colaboram
sobre quais são as próximas coisas que podem ser feitas. A reunião informal, com a apresentação
da funcionalidade, que tem a intenção de promover a colaboração e sobre o que fazer em seguida.
Inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o que não foi
feito. O time discute sobre o que correu bem durante a Sprint e quais problemas foram
enfrentados, além de como esses problemas foram resolvidos. O time demonstra o trabalho que
está pronto e responde a questionamentos. O Product Owner discute o Product Backlog da
maneira como esse se encontra. Ele faz projeções de datas de conclusão prováveis a partir de
várias hipóteses de velocidade. Em seguida, o grupo inteiro colabora sobre o que foi visto e o que
isso significa com relação ao que fazer em seguida. A Revisão da Sprint fornece entradas valiosas
para as reuniões de Planejamento de Sprints seguintes (SCHWABER; SUTHERLAND, 2010).
6.4.5 Retrospectiva da Sprint
Reunião executada pelo Time Scrum entre a Revisão da Sprint e a próxima reunião de
Planejamento. Scrum Master estimula a revisão do modelo de trabalho adotado e das práticas de
processo do Scrum, processo de desenvolvimento de forma a otimizá-lo para a próxima Sprint. A
finalidade é a inspecionar como ocorreu o relacionamento entre as pessoas, processos e
ferramentas. Identificar e priorizar itens que correram bem e os que poderiam ser feitos ainda
melhores. Composição do time, métodos de comunicação, preparativos para reuniões, etc. No final
da Retrospectiva, o Time Scrum deve ter identificado medidas de melhorias a ser implementadas
na próxima Sprint (Adaptação para a inspeção empírica). (SCHWABER; SUTHERLAND, 2010)

6.4.6 Daily Scrum

Cada time se encontra para uma reunião de 15 minutos. Sempre feita no mesmo horário e no
mesmo local durante as Sprints. Cada membro explica:

 O que realizou desde a última reunião diária.

 O que ele vai fazer antes da próxima reunião diária.
  Quais obstáculos estão em seu caminho.

Melhora a comunicação, eliminam outras reuniões, identificam e removem impedimentos no

desenvolvimento, ressaltam e promovem a tomada de decisão. Melhoram o nível de conhecimento
do time a cerca do projeto. Scrum Master garante que o time realize essa reunião, ensina o time a
manter a curta duração, reforçando regras e garantindo a brevidade das intervenções. Reforça a
regra das “galinhas”. O time é responsável pela condução da reunião. As três perguntas
inspecionam o progresso e a direção da Meta da Sprint. A intenção é otimizar a probabilidade de
que o time alcance sua Meta. Essa é uma reunião fundamental de inspeção e adaptação do Scrum
(SCHWABER; SUTHERLAND, 2010).

6.5 Artefatos do Scrum

Os artefatos do Scrum incluem:

6.5.1 Product Backlog e Release Burndown

Lista os requisitos para o produto que o time está desenvolvendo. O Product Owner é responsável
por seu conteúdo, disponibilidade e priorização. Mostra os requisitos inicialmente conhecidos e
melhor entendidos evoluindo de acordo com o seu ambiente de uso. É dinâmico e determinante
para o sucesso ou fracasso do produto. Lista de todas as características, funções, tecnologias,
melhorias e correções de defeitos para versões futuras. Itens de Sprint Backlog possuem
descrição, prioridade e estimativa. Geralmente são representados como Estórias de Usuário.
Ordenado por lista de prioridades. Mudanças nos requisitos de negócios, condições de mercado,
tecnologia e equipe refletem mudanças no Sprint Backlog.

Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser detalhados. As
estimativas dos itens de Sprint Backlog são inicialmente calculadas durante o Planejamento da
Versão para entrega e, posteriormente, à medida que forem sendo criados. Durante a preparação
do documento, os itens são revistos e revisados. No entanto, podem ser atualizados a qualquer
momento. O time é responsável por todas estimativas. O Product Owner pode auxiliar o time além
de manter o Sprint Backlog e o Burndown do Backlog da Versão sempre atualizados e publicados
todo o tempo (SCHWABER; SUTHERLAND, 2010). O gráfico de Release Burndown registra a soma
das estimativas dos esforços restantes do Sprint Backlog ao longo do tempo.
 Gráfico de Release Burndown

Fonte: http://msdn.microsoft.com/pt-br/library/ff731579.aspx

6.5.2 Sprint Backlog e Sprint Burndown

Tarefas que o time executa para transformar itens do Sprint Backlog em um incremento “pronto”.
Muitas delas são elaboradas na Reunião de Planejamento da Sprint. É todo trabalho que o time
identifica como necessário para alcançar a Meta da Sprint. Os itens do Sprint Backlog são
decompostos suficientemente para que mudanças no progresso possam ser entendidas na Reunião
Diária. O time modifica o Sprint Backlog no decorrer da Sprint bem como podem surgir Sprint
Backlog durante a Sprint. Á medida que novo trabalho surge, o Time o adiciona no Sprint Backlog.
E á medida que se trabalha nas tarefas ou que elas são finalizadas as horas estimadas de trabalho
restante para cada tarefa são atualizadas. Tarefas desnecessárias são removidas. Somente o time
pode modificar o Sprint Backlog bem como seu conteúdo e estimativas. É um retrato em tempo
real altamente visível do trabalho que o time planeja efetuar durante a Sprint.

O Sprint Burndown é um gráfico da quantidade restante de trabalho do Sprint Backlog em uma

determinada Sprint ao longo do tempo da Sprint. A quantidade restante para um Sprint e a soma
do trabalho restante para tudo no SprintBacklog. Mostre o trabalho restante ao longo do tempo. O
time pode gerenciar o progresso em completar o trabalho de uma Sprint.
 Gráfico de Sprint Burndown
Fonte: http://www.mountaingoatsoftware.com/scrum/sprint-backlog

Visão Geral do Scrum

Fonte: http://w
ww.mountaingoatsoftware.com/scrum/figures

Para Saber Mais

Leia o artigo “Uma análise do método ágil Scrum conforme abordagem nas áreas de processo
gerenciamento e desenvolvimento de requisitos do CMMI”, de Alexandre Lazaretti Zanatta e
Patrícia Vilain, onde os autores fazem uma análise do método Scrum.

Nesta aula você estudou o Scrum e conseguiu identificar a forma de trabalho dessa Metodologia
Ágil. Tão logo tenha oportunidade experimente colocá-la em prática na primeira oportunidade que
tiver no desenvolvimento de um sistema.

Na próxima aula você estudará o XP – eXtreming Programing, outra forma de desenvolvimento

ágil.

Aula 7 - XP (eXtreming Programming)

Na aula anterior você estudou o Scrum. Nessa aula estudará sobre o XP – eXtreming
Programming. Ela é uma das formas de desenvolvimento rápido de soluções de software e está
em conformidade com os conceitos apresentados nas primeiras aulas de Modelagem Ágil. Espera-
se que ao final desta aula você consiga identificar os principais componentes dessa metodologia e
a sua aplicabilidade no desenvolvimento de sistemas.
Boa aula!
7.1 XP – eXtremming Programing
O XP – eXtremming Programing tem atraído a atenção de muitos desenvolvedores. Ela surgiu em
meados de 1990, quando Kent Beck procurou formas mais simples e eficientes de desenvolver
software. Ele procurou o que tornava o desenvolvimento uma coisa simples e ao mesmo tempo
avaliou o que dificultava o desenvolvimento de software. Em março de 1996 ele iniciou um projeto
com novos conceitos que resultaram na metodologia XP.
Beck (2004, p. xi) relata que “XP é uma metodologia leve para times de tamanho pequeno a
médio, que desenvolve software em relação a requisitos vagos que se modificam rapidamente”. A
XP leva princípios e práticas do senso comum a níveis extremos:
 Se revisar o código é bom, o código será revisado o tempo inteiro (programação em pares).
 Se testar é bom, vamos testar toda hora (testes de unidade), até mesmo com os clientes

(testes funcionais).
 Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa (refatoração).
 Se simplicidade é bom, sempre deixaremos o sistema com os projetos mais simples possível

que suporte a funcionalidade atual (a coisa mais simples que possa funcionar).
 Se a arquitetura é importante, todos irão definir e refinar a arquitetura o tempo inteiro

(metáfora).
 Se integrar é bom, vamos integrar a maior quantidade de vezes possível (integração

continua).
 Se iterações curtas é bom, vamos deixar as iterações realmente curtas( o jogo do

planejamento). (BECK, 2004)

7.2 XP e suas Práticas
Beck (2004) conta uma história sobre aprender a dirigir. Ele estava na Rodovia Interestadual 5,
perto de Chico na Califórnia, em um trecho nivelado e reto que se perde no horizonte. Ele estava
no banco do passageiro quando a sua mãe fez com que ele segurasse o volante. Ela o deixou
sentir que o movimento na direção faria com que o carro se movimentasse à esquerda ou à
direita, dependendo do movimento. Então ela afirmou a ele que é assim que se dirige. Nesse
momento ele começou a divagar um pouquinho...

De repente quando voltou a prestar a atenção o carro entrou no acostamento. Aí a sua mãe
suavemente colocou o carro de novo na estrada. Ela relata que ela realmente o ensinou a dirigir:
“Dirigir não é fazer o carro andar na direção certa. Dirigir é prestar a atenção constantemente,
fazendo uma pequena correção para um lado, outra pequena correção para o outro”.

Ele declara que esse é o paradigma da XP onde mesmo que as coisas pareçam estar bem, você
não deve tirar os olhos da estrada. A mudança é uma certeza e você deve estar preparado para ir
um pouco para um lado ou um pouco para o outro. Em algumas situações talvez seja necessário ir
em uma direção totalmente diferente. Essa é a vida do programador.

O XP começa com quatro valores: Comunicação, Feedback, Simplicidade, e Coragem.

Analisando esses quatro valores percebe-se que se tratam dos mesmos valores que aprendemos
nas primeiras aulas, ligados à Modelagem Ágil.A seguir são apresentadas as práticas aplicadas no
XP:
O Jogo do Planejamento
Beck (2004) relata que é necessário determinar o escopo da próxima versão combinando
estimativas técnicas com prioridades do negócio. Quando acontecer algum problema que se
oponha ao planejamento, faça a atualização do planejamento.

O desenvolvimento do software deve sempre pensar em um diálogo evolutivo entre o possível e o

desejável. A natureza do diálogo é tal que altera aquilo que parece ser impossível e o que parece
ser desejável.As pessoas envolvidas nas áreas de negócios devem tomar decisões envolvendo o
escopo, as prioridades, a composição das versões e as datas da entrega.As pessoas da área
técnica devem decidir sobre as estimativas, as consequências, o processo de desenvolvimento e o
cronograma detalhado do projeto.

Entregas Frequentes
As entregas devem levar em consideração os requisitos que têm maior valor para o negócio e
devem ser entregues no menor tempo possível. Deve ser considerado ainda que a entrega
somente faz sentido se ela for tratada como um todo, não adianta implementar somente meia
função para tornar o ciclo de entrega mais curso, nesse contexto não importa se será necessário
planejar um dois meses para cada ciclo de entrega (BECK, 2004).

Metáfora
Uma metáfora no XP representa o que chamamos na engenharia de software como arquitetura.
Cada projeto de software deve ser guiado por uma única metáfora abrangente, em algumas
situações é simplória, como o cálculo de pensão alimentícia é como uma planilha de cálculos. A
metáfora apenas ajuda os envolvidos no projeto a entenderem os elementos básicos do sistema e
seus relacionamentos (BECK, 2004).

Projeto Simples
Um projeto correto de software é aquela que executa todos os testes, não tem lógica duplicada,
expressa todas as intenções importantes para os programadores e tem o menor número possível
de classe e métodos. Cada parte do projeto deve justificar a sua existência e conter somente o
essencial.

Esse é um conselho que se opões ao que se ouve: “Implemente para hoje, projete para o
amanhã”. Caso você acreditar que o futuro é incerto e que você tem a possibilidade de mudar de
idéia sem grandes gastos, acrescentar funcionalidades baseando-se em especulações é loucura.
Somente faça acréscimos daquilo que você precisar (BECK, 2004).

Testes
Qualquer aspecto ou função do programa que não tenha um teste automatizado simplesmente não
existe. Os testes de unidade são escritos pelos programadores para que as operações do
programa estejam confiáveis. Os testes de funcionalidade são escritos pelos clientes para que ele
possa confiar que as operações dos programas estão sendo feitas de modo correto. Um programa
se torna mais confiável com o tempo a partir de seus resultados.

Não é necessário escrever um teste para cada método que for programado, apenas para os
métodos de produção que possam vir a falhar (BECK, 2004).

Refatoração
Os programadores sempre se perguntam se existe uma maneira de implementar uma função de
um programa a partir da alteração de um programa existente, fazendo que a adição dessa nova
função seja simples. Depois da adição eles se perguntam se há uma forma de simplificar o
programa, mantendo ainda todos os testes funcionando. Esse procedimento é chamado de
refatoração (refactoring).

Isso pode significar que em algumas situações será necessário um esforço maior para acrescentar
uma função. Entretanto, trabalhando dessa forma, você poderá garantir que a adição de uma
próxima função será realizada com um esforço aceitável e todas as demais também Entretanto,
você não conseguirá a refatoração com especulações, você irá refatorar realmente aquilo que for
preciso. Em situações de código duplicado será possível a refatoração (BECK, 2004).

Programação em Pares
Todo código deve ser construído por duas pessoas em uma única máquina. Nesse contexto
existem dois papéis em cada par. Um dos componentes deve assumir o teclado e o mouse o outro
terá o papel de pensar mais estrategicamente se a abordagem como um todo irá funcionar, se
outros casos de testes podem não funcionas ou se existe uma maneira de simplificar todo o
sistema para que um problema simplesmente desapareça.

Nesse contesto, um par que trabalha junto pela manhã, à tarde pode vir a formar novo par com
outro e assim por diante. A programação em pares é dinâmica. É recomendável que sempre esteja
uma pessoa experiente com uma menos experiente, mas isso não é uma restrição e sim uma
situação desejável. Na realidade, qualquer pessoa do time deverá servir com o parceiro (BECK,
2004).

Propriedade Coletiva
Antigamente, todos poderiam alterar todos os códigos. Isso fazia com que os códigos se
tornassem complexos e extensos, gerando várias inconsistências. Para controlar essa situação,
surgiu a propriedade individual, onde os programadores se tornavam proprietário de determinados
códigos e se algum programador identificasse que era necessária alguma alteração no código, o
mesmo deveria conversar com o proprietário do código e convencê-lo de que aquela
implementação era necessário. Isso poderia ser urgente e algumas vezes o proprietário do código
não estava disponível para conversar.

No XP, todas as pessoas são responsáveis por todo o sistema. Nem todas as pessoas conhecem
todas as partes bem, mas todos sabem um pouco sobre algumas partes do sistema. Se um par
que está trabalhando em uma determinada implementação percebe uma oportunidade de
melhoria no código, eles devem ir em frente e melhorá-lo, se isso for facilitar as suas vidas (BECK,
2004).

Integração Contínua
Um código deve ser integrado e testado após algumas horas de codificação, sendo no máximo um
dia. O ideal é que tenha uma máquina dedicada, onde possa ser feita a integração. Nesse contexto
um par se encaminha para essa máquina com os produtos gerados e testa os módulos até que os
testes estejam 100% completos. Isso faz com que cada par reconheça o que está acertando e o
que está errando uma vez que se alguma coisa não está funcionando, o problema é da dupla,
posto que o par anterior deixou tudo funcionando corretamente. Daí resta a sensação de que
aquilo que foi feita talvez não seja o correto e em algumas situações pode ser que seja necessário
jogar tudo fora e começar novamente (BECK, 2004).
Semana de 40 horas
Nesse contexto, a regra do XP é simples – você não pode trabalhar uma segunda semana com
horas extras. Uma semana é aceitável que você trabalhe algumas horas extras. No caso da
seguinte você já tem um problema que não poderá ser resolvido somente com horas extras.

As pessoas devem estar dispostas e animadas a cada manhã e cansadas e satisfeitas todas as
noites. Numa sexta-feira estar cansado e satisfeito o suficiente pra se sentir bem com dois dias
para aproveitar com alguma coisa que não seja o trabalho. Isso permitirá que na segunda-feira as
pessoas estejam novamente dispostas e animadas.

Na realidade cada pessoa tem seus limites. Uns conseguem se manter concentradas por 35 horas,
outras com 45 horas. Traduzir uma semana em precisamente 40 horas não é importante.
Ninguém consegue aguentar 60 horas por semana durante muitas semanas. Todos têm os seus
limites (BECK, 2004).

Cliente Presente
O XP recomenda que um cliente real deve estar presente no Time, ficando disponível para
responder questões, resolver disputas e definir prioridades de menor escala. O cliente real é
aquele que realmente conhece o negócio e aquele que irá usar efetivamente o sistema.Nesse
contexto existe uma restrição que muitas vezes esse cliente real é também considerado prioritário
na área negociável e não consegue a liberação por essa razão.Os gerentes deverão optar em ter
um sistema que realmente atenda os seus negócios no menor tempo possível ou não, caso o
cliente real não possa ser liberado (BECK, 2004).

Padrões de Codificação
Tendo em vista a prática de codificação em pares e a troca constantes dos pares, é fundamental
que se adote um padrão, que deve exigir a menor quantidade de trabalho possível, seja
consistente com a regra de não existência de código duplicado, enfatizando a comunicação e que
deve ser aditado voluntariamente por todo o time (BECK, 2004).

7.3 Papéis no XP
Beck (2004, p. 137) diz que certos papéis precisam estar preenchidos para que um time eXtremo
funcione. Ele relata ainda que um “time esportivo funciona melhor quando são definidos papéis
pelos quais alguém é responsável. No futebol existe o goleiro, o zagueiro, o atacante, etc., no
basquete o armador, o pivô, o ala e outros”.

A seguir relatamos os papéis existentes no XP.

Programador
O programador é o coração do XP. O programador será o responsável pela estimativa de prazos
para os módulos a serem desenvolvidos. Eles devem trabalhar em pares para desenvolver e
implementar os códigos em produção. Serão responsáveis pelas correções dos erros e pelo
refatoramento dos códigos.Eles não devem criar ou alterar funcionalidades nem serem os
responsáveis pela elaboração dos testes de aceitação.

Cliente
Representa a outra parte importante do XP, da mesma forma que o programador sabe como
programar, o cliente sabe o que programar, não em princípio, mas o que ele está tão disposto a
aprender quanto o programador.Ser um cliente XP não é fácil, será necessário habilidades de
aprender como escrever boas histórias e é uma atitude que fará você ter sucesso.Ele deve ser o
responsável por definir prioridades, os testes de aceitação, validar os testes de aceitação e tirar
todas as dúvidas relacionadas ao negócio.Ele não deve ser o responsável pela implementação de
código e nem pela definição do tempo que uma tarefa levará para ser implementada.

Testador
O testador terá o papel de ajudar o cliente a escolher e escrever testes. Um testador XP não é
uma pessoa separada que se dedica a fazer o sistema falhar e a humilhar o programador, porém
ele deve executar os testes regularmente.Grande parte da responsabilidade pela realização dos
testes pertence ao programador XP.

Rastreador
O rastreador é considerado a consciência do time. Será dele a responsabilidade de dar
o feedback a respeito do que ocorre no desenvolvimento e sobre as estimativas. Por exemplo, as
últimas estimativas estavam 50% abaixo do que realmente foi gasto.Ele deve ser o historiador do
time, mantendo os registros dos testes funcionais, registro de defeitos e quem assumiu a
responsabilidade por cada um deles entre outros.

Treinador
O treinador é responsável pelo processo como um todo. Será responsável por chamar a atenção
das pessoas quando essas estiverem se desviando dos objetivos. Deve permanecer calmo quando
todos os outros estão em pânico.

Consultor
A ênfase na simplicidade reduz a necessidade de existência de especialistas no time. Quando o
time precisa de um especialista técnico, aí entra a figura do consultor. Provavelmente um
consultor não esteja acostumado ao trabalho eXtremo. Em algumas situações pode encarar a
maneira de trabalhar do time com um certo ceticismo. O time deve ser extremamente claro
quanto ao problema que necessita ser resolvido. O que não deve acontecer é que o consultor
resolva o problema sozinho. Será necessário compartilhar a solução, pois o time poderá necessitar
dessa informação técnica em problemas futuros.

O Chefão
Um chefão verá que o que o time mais quer é coragem, confiança e insistência ocasional para que
eles façam o que dizem fazer. Talvez no princípio seja difícil trabalhar com o time. Eles, com
certeza pedirão atenção neles frequentemente (BECK, 2004).

Nesta aula você estudou sobre o XP – eXtreming Programming e a sua aplicabilidade no

desenvolvimento de sistemas. Na próxima aula você estudará mais uma Metodologia Ágil, o DSDM
– Dynamic System Development Method.

Aula 8 - DSDM (Dynamic System

Development Method)
Na aula anterior você estudou sobre a metodologia XP – eXtremming Programming. Nela você
pode observar uma metodologia para construção rápida de código, que pode ser utilizada
conjuntamente com outras metodologias. Nesta aula você estudará mais uma metodologia ágil, o
DSDM – Dynamic System Development Method. Ao final desta aula espera-seque você conheça
essa metodologia e saiba como aplicá-la em projetos de desenvolvimento de sistemas.
Boa aula!
8.1 DSDM
O DSDM – Dynamic System DevelopmentMethod foi desenvolvido no Reino Unido na década de
1990 por uma associação de especialistas e vendedores da área de engenharia de software com o
objetivo de "desenvolver e promover em conjunto um quadro RAD independente", aliado às suas
melhores práticas e experiências.

O DSDM Consortium é uma organização sem fins lucrativos e independente, responsável pela
propriedade e administraçãodo DSDM. A primeira versão do DSDM foi finalizada em janeiro de
1995 e publicada em Fevereiro de 1995. Em julho de 2006, foi publicadae disponibilizada para uso
a versão 4.2.

O DSDM – Dynamic System DynamicMethod, que traduzindo para o português podemos chamá-lo
de Metodologia de Desenvolvimento Sistema Dinâmico, é uma metodologia de desenvolvimento
rápido de aplicação que utiliza o princípio de ser iterativo e incremental contando com a
participação constante do usuário.

Seu objetivo segue a mesma linha da Metodologia Ágil, entregar os projetos no prazo e dentro dos
orçamentos previstos, contando com a participação efetiva dos usuários, com uma equipe que
tenha alto poder de decisão e que tenha condições de ajustar às mudanças ao longo de sua
caminhada.

Como uma extensão do desenvolvimento rápido de aplicativos, DSDM é aplicável a projetos que
tenham prazos e orçamentos apertados. O DSDM incentiva o desenvolvimento rápido de aplicado,
entretanto exige disciplina na sua aplicação uma vez que caso isso não aconteça, os riscos do
projeto podem ser aumentados.

O DSDM pode ser integrado e complementado com outras metodologias, como o Rational Unified
Process – RUP, eXtreme Programming – XP. Ele é um método ágil que tem semelhança no
processo e conceito com o Scrum. Ele emprega uma abordagem iterativa e incremental visando a
otimização, a previsibilidade e o controle os riscos do projeto.
8.2 Princípios do DSDM
O DSDM, segundo o DSDM CONSORTIUM (2008), está baseado em oito princípios:
1. Tenha foco nas necessidades do negócio (Focus onthe business need)
2. Entregue a tempo (Deliveron time)
3. Use a Colaboração (Colaborate)
4. Nunca comprometa a qualidade (Never compromisse quality)
5. Construa gradativamente a partir de bases sólidas (Build incrementallyfromfirmfoundations)
6. Desenvolva iterativamente (Developiteratively)
7. Comunique de forma clara e contínua (Communicatecontinuoslyandclearly)
8. Demonstre controle (Demonstratecontrol)
8.3 Ciclo de Vida do Projeto
Para que o desenvolvimento de software utilizando o DSDM tenha sucesso, são necessários alguns
pré-requisitos. Um dos pontos fundamentais é a interatividade da equipe do projeto com os
usuários finais e com a alta gerência. Um outro ponto é a decomposição do produto em partes
menores, possibilitando a abordagem iterativa. A seguir apresentamos a figura com o Ciclo de
Vida do Projeto e suas partes.

Figura 8.1 – Ciclo de Vida do Projeto do DSDM

Fonte: (CDSDM CONSORTIUM, 2008, p. 30).

 Pré-projeto (Pré-project) – Nele são identificados os produtos candidatos, o patrocinador

do projeto e o comprometimentocom o projeto é garantido. A resposta dessas questões

nesta fase evita problemas em fases posteriores do desenvolvimento.
 Análise de Viabilidade (Feasibility) – Nessa fase é realizada uma analise do tipo do

projeto, determinando se o desenvolvimento utilizando o DSDM é viável. São gerados

relatórios de viabilidade, protótipo de viabilidade, plano de detalhamento global incluindo o
plano de desenvolvimento e controle de risco.
 Fundações (Foundations) – Nessa etapa é realizada a análise do negócio, suas

características essenciais e as tecnologias a serem empregadas. Aqui também é feita a

análise da capacidade de se montar grupos de trabalho, onde devem existir clientes
experientes que possam fornecer maiores detalhes a respeito do sistema e que definam as
prioridades de desenvolvimento.
 Exploração (Exploration) – Nessa fase é realizada a análise do negócio, suas características

essenciais e as tecnologias a serem empregadas. Aqui também é feita a análise da

capacidade de se montar grupos de trabalho, onde devem existir clientes experientes que
possam fornecer maiores detalhes a respeito do sistema e que definam as prioridades de
desenvolvimento.
 Engenharia (Engineering) – Nessa etapa é realizada a análise visando identificas as

características do modelo funcional, geração do protótipo funcional, determinando as

funcionalidades que serão implementadas, os requisitos funcionais e não funcionais e traçada
uma estratégia de implantação baseando nas iterações passadas, criando uma agenda com
datas de realização dos requisitos elicitados.
 Desenvolvimento (Deployment) – Nessa fase é feito o desenvolvimento do sistema,

levando em consideração os requisitos elicitados na fase de engenharia. São gerados

protótipos para teste do usuário, revisão dos protótipos realizando correções nos erros
 encontrados e novamente testar o produto, gerando uma documentação para o usuário.
Uma vez que o produto estiver aprovado pelo usuário, a parte do sistema será implantada
em produção. É necessário treinar o usuário para utilizar o sistema. Podem ser feitas
revisões dos impactos do sistema nos negócios, ficando evidenciado o que deve ser tratado
nas próximas iterações do desenvolvimento.
 Pós-projeto (Post-project) – Esta é a fase que deve garantir que o sistema esteja

funcionando de forma eficaz e eficiente. Para isso são realizadas manutenções, melhorias e
correções de acordo com os princípios DSDM. A manutenção pode ser vista como contínuo
desenvolvimento com base na natureza iterativa e incremental do DSDM. Ocorre o
refinamento do projeto, a partir do momento que novas iterações são realizadas,
implementando mudanças solicitadas pelos clientes, agregado a novas funcionalidades.
8.4 Papéis no DSDM
No DSDM existe a definição prévia do papel de cada membro no projeto antes do início das
atividades do projeto, com suas respectivas responsabilidades. Os papéis existentes no DSDM são:

É o patrocinador do projeto, ou seja aquela que solicitou a

Patrocinador (Business Sponsor) solução a ser desenvolvida. Deve responder pelos casos de
negócios do sistema.

É o responsável por iniciar o projeto, verificando se os

requisitos essenciais foram definidos, conhecendo tanto o
Visionário de Negócios (Business Visionary)
negócio quanto o projeto e supervisionando e mantendo os
processos de desenvolvimento nos prazos estimados.

É a pessoa responsável pelo gerenciamento do projeto

Gerente de Projeto (Project Manager)
destinado ao desenvolvimento do sistema.

É o responsável pelo controle de qualidade técnica do projeto

Coordenador Técnico (TechnicalCo-ordinator)
e do desenho da arquitetura do projeto.

Mantém a harmonia da equipe no projeto. Responsável pela

motivação do grupo e pela aplicação das regras previstas no
Líder de Time (Team Leader)
DSDM e das responsabilidades atribuídas a cada um dos
membros do time.

É o responsável em participar das reuniões de revisão,

provendo a equipe de cenários de negócios e colaborando no
Embaixador de Negócios (Business Embassador) dia a dia da equipe fornecendo todas as informações a
respeito do negócio e a sua visão em relação ao que está
sendo construído.

Trazendo conhecimento de outras áreas, garantindo que a

equipe tenha recebido quantidade suficiente de feedback do
Analista de Negócios (Business Analyst)
usuário no processo de desenvolvimento e sobre os negócios
envolvidos no projeto.

É o responsável pelo desenvolvimento de artefatos de código

Desenvolvedor de Soluções (SolutionDeveloper)
e protótipos baseados em modelos e requisitos.

É o responsável pela realização do testes de diversos tipos,

Testador de Soluções (SolutionTester)
incluindos comentários na documentação.

É o responsável por levar as idéias dos usuários diariamente

Conselheiro de Negócios (Business Advisor)
para a equipe de projeto.

Facilitador (Workshop Facilitator) É o canal de comunicação entre as equipes.

Responsável por treinar e fornecer informações relevantes

Treinador (AternCoach)
para os integrantes do projeto.

Papéis Especialistas (Specialist Roles) São papéis específicos envolvidos em um projeto de

 desenvolvimento de sistemas, tais como Arquiteto de
negócios, Gestor de Qualidade, Integrador de Sistema, etc.

8.5 Técnicas do DSDM

Abaixo são apresentadas algumas técnicas presentes no DSDM que podem ser utilizadas no
desenvolvimento de sistemas.

 Timeboxing – É uma técnica utilizada pelo DSDM para estimar prazo, custo e a qualidade

desejada. No timeboxing são feitas divisões no projeto onde prazos e orçamentos

determinados. Para cada divisão escolhida os requisitos são priorizados. Devido ao prazo e
custos serem fixos, as variáveis remanescentes são originadasdos requisitos, de forma que
se o prazo ou custo se esgotarem, os requisitos de baixa prioridade são omitidos. De acordo
com o Princípio de Pareto80% do projeto vem de 20% dos requisitos do sistema. Sendo
assim,são implementados os requisitos mais importantes,tornando mais fácil o
atendimentodas necessidades do negócio.
 MoSCoW – No DSDM o método MoSCoW é utilizado para priorizar requisitos:
 MUST (obrigatório) – os que são necessários para o negócio.
 SHOULD (deveria) – são bastante considerados, entretanto não impactam no projeto.
 COULD (poderia) – a inclusão indefere no negócio do projeto.
 WOULD (seria) – A inclusão dele é caso houver tempo disponível.
 Prototipagem – É o momento em que protótipos são construídos no início do projeto,

permitindo descobrir falhas no sistema de forma que o usuário possa testá-lo. Essa é uma
característica forte do DSDM.
 Testes – No DSDM os testes são realizados a cada iteração criando um sistema de boa

qualidade, onde o grupo escolhe a melhor forma de realizar o gerenciamento dos testes.
 Grupos de Trabalho – É uma das técnicas do DSDM que permite que os envolvidos em

diferentes grupos discutam em grupo os requisitos, a funcionalidade e o seu entendimento.

 Modelagem – É uma técnica utilizada para visualização gráfica de aspectos específicos do

sistema ou de uma parte de negócio para um melhor entendimento.

 Gerenciamento de Configuração – O próprio dinamismo do DSDM já proporciona, já

existindo algo para controlar ao mesmo tempo durante o processo de desenvolvimento,

gerando produtos com rapidez estritamente controlados.
8.6 Fatores Críticos de Sucesso
A seguir apresentamos alguns fatores críticos para o sucesso de um projeto utilizando o
framework DSDM.

 É importante a aceitação por todos os envolvidos no projeto da aplicação dessa metodologia.

Isso pode influenciar o resultado final do projeto.

 É necessário garantir a participação do usuário final nas diversos estágios do projeto.
 È importante contar com profissionais experientes e capacitados, de forma que exista um

membro responsável para tomar certas decisões evitando que a gerência o faça.
 Escolha a melhor tecnologia, incluindo ambiente de desenvolvimento, ferramentas de

gerenciamento, etc.
  É necessária a definição do suporte necessário, gerando documentação.

Para Saber Mais

Leia o artigo “DSDM – Dynamic Systems DevelopmentMethodology”, de Daniel Dinis Teixeira e
colegas, onde os autores exploram a DSDM e apresentam uma análise de caso.

O DSDM é um framework já consolidado no mercado, pois possui uma abordagem iterativa e

incremental visando o controle de riscos e otimizando as previsões. É um framework que possui
em seus pilares conceitos importantes. Entretanto esse framework não é muito popular no Brasil.

Na próxima aula você estudará mais um modelo de Modelagem Ágil, o FDD – Feature Driven
Development.

Aula 9 - FDD (Feature Driven Development)

Na aula anterior você estudou a metodologia ágil DSDM – Dynamic Software Development
Method, onde foi possível verificar como esse framework trabalha. Nesta aula você estudará mais
uma metodologia ágil, o FDD – Feature Driven Development, que traduzindo para o português
representa Desenvolvimento Dirigido à Funcionalidade.
Boa aula!
9.1 FDD
O FDD (Feature Driven Development) teve origem em 1997, num projeto para o United Overseas
Bank, em Singapura, e foi criado a partir da experiência de Peter Coad em modelagem orientadas
a objeto e de gerenciamento de projetos de Jeff de Luca.
Em 2003, David Anderson, um especialista em interface com o usuário, publicou o Agile
Management for Software Engineering: Using the Theory of Constraints for Business Results, onde
oferece uma análise profunda do FDD, além de ser um material inédito sobre o tema.

O FDD (Desenvolvimento Guiado por Funcionalidades) é uma metodologia ágil direcionada

aodesenvolvimento e gerenciamento de software. Ela combina as melhores práticas do
gerenciamento ágil de projetos com uma abordagem completa voltada para a engenharia de
software orientada por objetos.

Esse é um método específico para o desenvolvimento de aplicações críticas de negócios,

baseando-se em processos bem definidos e que podem ser repetidos em outros projetos.
Concentra a sua abordagem nas fases que compõem o projeto e a construção, dando ênfase na
modelagem, utilizando um ciclo de vida iterativo agregado a atividades de gerenciamento de
projetos.

9.2 Princípios e Características

Os princípios bases adotados pelo FDD são:

 Necessidade da automatizaçãoda geração de software para projetos em grande escala.

 Existe a necessidade de um processo simples e bem definido.
 Cada integrante da equipe de desenvolvimento deve ter uma visão lógica e óbvia das etapas

de um processo.
 A existência de bons processos na retaguarda permite que a equipe se dedique ao alcance

dos resultados.
  São indicados ciclos de vida mais curtos para cada iteração no desenvolvimento de sistemas.

A ênfase na qualidade em todo o processo e um monitoramento do progresso direto, intuitivo,

acurado e direto é uma característica da FDD. Entregas software funcional frequentemente é a
principal finalidade dessa metodologia. A seguir apresentamos mais algumas características da
FDD.

 Geração de artefatos para a documentação e especificação dos requisitos.

 As características do produto a ser desenvolvido são agrupadas, priorizadas e distribuídas

aos responsáveis pelo o seu desenvolvimento.

 As iterações devem duram no máximo duas semanas.
 Essa metodologia esta posicionada numa situação intermediária entre a abordagem

tradicional e as metodologias ágeis.

 É fundamental o envolvimento do cliente nos processos de planejamento e desenvolvimento

de software.
 A metodologia não tem o foco específico na programação ou no modelo e sim aproveitar,

com bom senso utilizar o que existe de melhor nos dois mundos.
 O time da FDD deve estar entre 16 e 20 membros, podendo ser composta de equipes bem

maiores.
 A cada duas semanas espera-se que seja entregue produtos úteis, tangíveis e funcionais.
 Existe um planejamento detalhado e um guia utilizado para a medição do produto a ser

desenvolvido.
 Possuí rastreabilidade e relatórios com incrível precisão.
 Realiza um monitoramento detalhado dentro do projeto, contando com resumos de alto nível

para clientes e gerentes.

 Realiza trabalho significativo desde o início, antes de tornar-se altamente iterativa.
 Fornece informação de estado e progresso de forma simples e compreensível.
 Permite que a interação com outras metodologias.
 Suporta desenvolvimento ágil com rápidas adaptações às mudanças de requisitos e

necessidades do mercado.
9.3 Práticas
Utiliza oito técnicas que são conhecidas como “boas práticas” para o desenvolvimento de sistemas.

 Modelagem de domínio de objetos (Domain Object Modeling) – São representados por

diagramas de classes e de sequência com seus respectivos objetos do sistema e seus

relacionamentos, mesmo que apresentados de modo simplificado, permitindo validar as
soluções possíveis e o refinamento das funcionalidades especificadas. A equipe participa da
criação dos modelos de objetos, eliminando divergência porventura ocorridas no
entendimento das funcionalidades. As divergências de modelagem e implementação elimina
as divergências que possam vir a ocorrer.
 Desenvolvendo por Funcionalidade (Developing by feature) – O desenvolvimento e

entrega por funcionalidade busca garantir que o projeto produza aquilo que os clientes
 necessitam, uma vez o o desenvolvimento é direcionado a partir dos requisitos funcionais
que agregam valor ao negócio e particionados em partes menores.
 Propriedade de Classe (Individual class ownership) – Cada programados é responsável por

uma ou mais classes e o grupo de classes fica a cargo do programador. A adoção dessa
estratégia gera nos desenvolvedores o aumento do senso de responsabilidade sobre os
códigos produzidos e minimiza problemas quando se trabalha com muitos desenvolvedores
realizando modificações ao mesmo tempo nos códigos.
 Equipes por Funcionalidade (Featureteams) – A montagem das equipes devem ser feitas

a partir de cada iteração e os participantes assumem a responsabilidade sobre as classes

envolvidas, como se fossem donos das mesmas. Como o trabalho pode ser realizado por
múltiplas equipes em paralelo, uma das formas de evitar problemas é permitir a mudança
nos donos das classes, no transcorrer do projeto.
 Inspeções (Inspection) – Alguns estudos mostram que as inspeções aumentam a qualidade

do código produzido, além de promover a transferência de conhecimento, estimulando a

padronização e inibindo a inclusão de código de baixa qualidade, uma vez que os
desenvolvedores têm conhecimento de que aquilo que foi feito será inspecionado.
 Versões com Regularidade (Regular Builds) – A construção de versões a partir da

integração constante de código permite resolver e identificar problemas com a integração

dos módulos, fornecendo subsídios seguros quanto à evolução do projeto.
 Gerenciamento de Configurações (Configuration Manager) – O controle de versão dos

artefatos que compõem o projeto deve ser verificada de acordo com as características do
projeto.
 Papéis – Cargos e responsabilidades – No FDD existem vários papéis que os membros

da equipe podem assumir. O mesmo papel pode ser assumido por vários membros e cada
membro pode assumir vários papéis simultaneamente.Dentro de cada categoria os papéis
podem ser atribuídos a vários participantes para multiplicar uma função ou compartilhar
responsabilidades.
9.4 Papéis
Os papéis são divididos em três grupos:

 Papéis-chave – São os responsáveis pelo desenvolvimento da aplicação, por isso são os

papéis-chave. São eles:

 Gerente de projeto (Project Manager) – Responsável financeiro e administrativo do

projeto. No FDD a última palavra é dada por ele.

 Arquiteto chefe (Chief architect) – Elabora o projeto geral do software a ser

desenvolvido, tomando decisões finais em relação ao projeto técnico.

 Gerente de desenvolvimento (Development Manager) – Responsável por gerenciar as

atividades diárias do projeto resolvendo problemas que poderão ocorrer com a equipe.
 Programador chefe (Chief programmer) – Programador com maior experiência.

Participa na análise de requisitos e nos projetos de software.

  Proprietário de classe (Class owner) – Subordinado ao programador chefe, tendo como

tarefas projetar, codificar, testar e documentar. Responsável pelo desenvolvimento das

classes atribuídas a ele.
 Especialista do domínio (Domain experts) – Pode ser um usuário, analista de negócios,

cliente ou qualquer pessoa que conheça bem o domínio do problema. Sua tarefa é
informar as funcionalidades que deverão ser atendidas pelo software e entender como
os requisitos estão sendo desenvolvidos.
 Gerente do domínio (Domain manager) – Conduz os peritos de domínio a resolver as

diferenças de opinião relativa aos requisitos do sistema.

 Papéis de apoio – São os responsáveis por criar programas que auxiliem os outros

desenvolvedores a construir o produto final. São eles:

 Gerente de versão (Release manager) – Responsável por controlar o progresso no

desenvolvimento através de constantes revisões em conjunto com o programador

chefe. Informa suas atividades ao gerente de projeto.
 Guru de linguagem (Languagelawyer/language guru) – Membro da equipe responsável

por possuir um conhecimento completo de uma linguagem de programação específica

ou tecnologia.
 Engenheiro de construção (Build engineer) – Pessoa responsável pelas tarefas de

administração do sistema de controle de versão e a publicação da documentação,

durante a atividade de construção.
 “Ferramenteiro” (Toolsmith) – Responsável por construir ferramentas de suporte para o

desenvolvimento, testes e conversão de dados no projeto. Também pode trabalhar com

modelagem e manutenção de banco de dados e websites para propósitos específicos no
projeto.
 Administrador de sistemas (System Administrator) – Configura, administra e

diagnostica os servidores, estações de trabalho e desenvolvimento e testar os

ambientes usados pela equipe do projeto.
 Papéis Opcionais – São testadores, implantadores e escritores técnicos.
 Testadores (Testers) – Verifica se o sistema que está sendo construído satisfará aos

requisitos do sistema.
 Instaladores (Deployers) – Responsáveis por converter dados existentes ao formato

requerido pelo novo sistema e participar no desenvolvimento de novos lançamentos.

 Escritores técnicos (Technicalwrites) – Responsável pela documentação do usuário.
9.5 Processos
Os processos propostos por FDD consistem em cinco etapas que cobrem as fases de modelagem e
implementação de software, conforme a Figura 9.1 a seguir:
 Figura 9.1 – Processos do FDD.

Fonte: (HEPTAGON, 2012).

As três primeiras são feitas no início do projeto instituindo um planejamento de nível médio, as
duas últimas são repetidas iterativamente para construir o planejado.

Os cinco processos FDD são bem definidos e detalhados e são realizados de forma integrada:

 Desenvolver um Modelo Abrangente (DMA) – É uma atividade inicial que abrange todo

o projeto, na qual se realiza um estudo dirigido sobre o escopo do sistema e de seu

contexto, bem como outros mais detalhados sobre o domínio do negócio para cada área a
ser modelada.As atividades são realizadas em reuniões de domínio, executadas
sequencialmente com a participação dos especialistas de negócio, programadores-chefes e
arquiteto-chefe; eventualmente a participação do gerente do projeto. Essas reuniões devem
ser realizadas em ambiente isolado e confortável de forma a não torná-las excessivamente
cansativas.
 Construir a Lista de Funcionalidades (CLF) – É uma atividade inicial que abrange todo o

projeto, para identificar as funcionalidades que satisfaçam aos requisitos, formando assim a
lista categorizada de funcionalidades, decompondo funcionalmente o domínio (negócio) em
áreas de negócio, atividades de negócio e funcionalidades.
 Planejamento por Funcionalidade (PPF) – É uma atividade inicial que abrange todo o

projeto, para produzir o plano de desenvolvimento. Planejam a ordem a partir das

dependências, cargas de trabalho de time e complexidade da funcionalidade.
 Detalhar por Funcionalidade (DPF) –É uma atividade executada para cada

funcionalidade, para produzir o pacote de projeto (design) para ela. Seleciona as

funcionalidades e identificam os donos das classes e produz o(s) diagrama(s) de sequência
para a(s) funcionalidade(s) atribuída(s), e refina o modelo de objetos.
  Construir por funcionalidade (CPF) – É uma atividade executada para cada

funcionalidade, para produzir uma função com valor para o cliente (funcionalidade).
 Os donos das classes implementam.
 O código passa por testes e inspeção.
 O código é promovido à versão atual (build).
9.6 Informações Suplementares do FDD
A seguir são apresentadas outras informações importantes a respeito do FDD.

 Indicação do FDD – É definido como sendo mais apropriado a projetos iniciais, à

atualização de código existente, à criação de uma segunda versão, ou ainda à substituição

de um sistema inteiro em partes. Diferentemente de outros métodos ágeis, o FDD possui
características específicas para desenvolver sistemas críticos.
 Quando não usar FDD – Prevê boas práticas apenas para o desenvolvimento de software,

diferentemente de metodologias que sugerem padrões também para fora do processo de

desenvolvimento. Necessidades tais como escolha de tecnologias e ferramentas, definição de
interface de usuário, testes de sistema e de carga, obtenção de patrocínio para o projeto,
gerenciamento de recursos, conversão de dados, etc., não são cobertas pela FDD.
 Vantagens
 É um método ágil e altamente adaptativo, que produz resultados requentes, tangíveis e

funcionais.
 Oferece vantagens dos métodos prescritivos (rigorosos), pois implementa o conceito

importante de planejamento, mas sem os exageros de documentação e controle.

 Oferece vantagens dos métodos extremamente ágeis, onde a preocupação maior é com

a produção de código, mas toma o cuidado de planejar o suficiente e controlar o

andamento do projeto.
 É orientada às necessidades dos clientes, gerentes e desenvolvedores.
 Desvantagens – Ainda existem questionamentos sobre a eficácia doFDD e controvérsias

sobre o tamanho mínimo de um time FDD.

 FDD e outras metodologias – O Scrum e o FDD são complementares em muitos aspectos:

 Podemos utilizar o Scrum para o Gerenciamento e o FDD para as práticas de

Engenharia de Software.
 Pode ser feita uma combinação de Scrum, XP e FDD. O Scrum para o gerenciamento, o

FDD para os requisitos de software e o XP para o desenvolvimento de software.

Para Saber Mais

Leia o artigo “Uma análise das metodologias ágeis FDD e Scrum sob a perspectiva do Modelo de
Qualidade MPS.BR”, de Silva, Hoentsch e Silva, onde os autores abordam o uso de FDD e Scrum
para o MPS.BR.

Nesta aula você estudou sobre a metodologia FDD e a sua aplicabilidade no desenvolvimento de
sistemas. Na próxima aula você estudará mais três metodologias ágeis. Até lá!
Aula 10 - Outras Metodologias
Nas aulas anteriores você navegou sobre diversas Metodologias Ágeis para desenvolvimento de
sistemas. Esta é aúltima aula e nela você estudará superficialmente sobre mais três metodologias
ágeis, o ASD – Agile Software Development, a Integração Contínua e o Crystal Clear.
Ao final desta aula espera-se que você tenha conhecido mais três metodologias ágeis e a forma
como aplicá-las no desenvolvimento de sistemas.
Boa aula!
10.1 ASD – Agile Software Development
Jim Highsmith trabalhou vários anos com metodologias prescritivas e chegou à conclusão que não
eram eficientes para empresas modernas, cujo ambiente de desenvolvimento é extenso e
imprevisível. Em ambiente com essas características fica mais propício para a colaboração para
lidar com as adversidades, tendo em vista que a inovação éa nova boa prática.

Segundo a sua metodologia de adaptabilidade, o desvio é incentivado como prática de soluções,

ao contrário da metodologia tradicional que o desvio é visto como enganos que devem ser
corrigidos imediatamente. Dessa forma, o aprendizado é o foco de tudo, fazendo com que os
planos e designs mudem à medida que o projeto avança.

Por esse motivo Highsmith enfatiza em lidar com a parte mais complicada do desenvolvimento
adaptativo, que é o processo de colaboração e aprendizado dentro do projeto.
10.1.1 ASD –Características
 Iterativo e incremental
 Sistemas grandes e complexos
 Arcabouço para evitar o caos
 Cliente sempre presente
 Desenvolvimento de aplicações em conjunto (Joint Application Development – JAD)
10.1.2 Ciclo de Vida
 Especular (Speculate)
 Fixa prazos e objetivos.
 Define um plano baseado em componentes.
 Colaborar (Collaborate)
 Construção concorrente de vários componentes.
 Aprender (Learn)
 Repetitivas revisões de qualidade e foco na demonstração das funcionalidades

desenvolvidas (Learning loop).

 Presença do cliente e especialistas do domínio.
 Os ciclos duram de 4 a 8 semanas
10.1.3 Propriedades do ASD
 Orientado a missões (Misson-driven)
 Atividades são justificadas através de uma missão, que pode mudar ao longo do

projeto.
 Baseado em componentes (Component-based)
 Construir o sistema em pequenos pedaços
 Iterativo (Iterative)
  Desenvolvimento em cascata (Waterfall) só funciona em ambientes bem definidos e

compreendidos. O ASD possui foco em refazer do que fazer corretamente já na

primeira vez
 Prazos pré-fixados (Time-boxed)
 Força os participantes do projeto a definir severamente decisões do projeto logo cedo.
 Tolerância a mudanças (Change-tolerant)
 As mudanças são frequentes
 É sempre melhor estar pronto a adaptá-las do que controlá-las
 Constante avaliação de quais componentes podem mudar
 Orientado a riscos (Risk driver)
 Itens de alto risco são desenvolvidos primeiro
10.1.4 Cargos e Responsabilidades
Este método não descreve cargos em detalhes. Eles são:

 Executivo responsável (ExecutiveSponsor)

 Participantes de uma sessão (workshop) do desenvolvimento de aplicações em

conjunto (JAD)
 Facilitador (Facilitator)
 Liderar e planejar as sessões
 Escriba (Scribe)
 Efetuar anotações
 Cliente (Customer)
 Sempre presente
 Gerente de Projetos (Project Manager)
 Desenvolvedores (Developers)
10.2 Crystal Clear
Segundo Fowler (2005), Alistair Cockburn tem se envolvido com esta metodologia desde o início
dos anos 90. A sua abordagem não é igual à maioria dos demais metodologistas. Em vez de
construir agrega a experiência pessoal com a procura ativa de entrevistas em projetos visando
verificar o seu funcionamento. Ele ainda não está preocupado em alterar os seus pontos de vista
partindodas suas descobertas.

A família Crystalsl compartilha uma orientação humana com o XP, mas a sua centralidade nas
pessoas é realizada de forma diferente. Segundo Fowler (2005), Alistair parte da consideração de
que as pessoas não têm preferência em seguir um processo disciplinado. O XP é baseado em uma
alta disciplina e a metodologia Crystal explora uma metodologia menos rígidae que apesar dessa
flexibilidade ainda pode ter sucesso, conscientemente trocando a produtividade pela facilidade de
execução do projeto. Apesar da metodologia Crystal sermenos produtiva que o XP, mais pessoas
poderão segui-la, devido à sua maior flexibilidade.

Fowler (2005) relata ainda que a metodologia coloca bastante peso nas revisões de cada iteração,
encorajando as pessoas a evoluírem os produtos gerados. Ela parte do pressuposto que o
desenvolvimento iterativo está lá para identificaros problemas mais cedo possível, e permitir então
às pessoas corrigi-los. Isto coloca uma ênfase muito grande nas pessoas e nomonitoramentodo
seu processo afinando-o à medida que desenvolvem.
Métodos da família

 Crystal Clear
 Crystal Yellow
 Crystal Orange
 Crystal Red

Qual usar?
A escolha de qual método aplicar vai de acordo com cada projeto, dependendo do seu tamanho e
sua criticidade.

Crystal Clear
A metodologia Crystal Clear é um dos tipos da metodologia Crystal. Cada projeto é moldado em
função do processo utilizado para atender os projetos, levando em consideração três fatores: a
criticidade do projeto, a prioridade do projeto e a carga de comunicação.
Método Crystal Clear
O método Crystal Clear é destinado a projetos em que a equipe é composta por, no máximo, seis
pessoas e seu risco é classificado como D(baixo custo). Cada incremento gerado no projeto,
executado sob esse método, tem duração de dois a três meses. Asespecificações e o projeto são
feitos informalmente, através de esboços e anotações.

Princípios
Segundo Siqueira (2003), os princípios do Crystal Clear são:
 Comunicação interativa face a face é o canal mais barato e rápido para intercâmbio de

informações.
 O excesso de peso do método é custoso.
 Times maiores precisam de métodos mais pesados.
 A maior cerimônia é apropriada para projetos com maior criticidade.
 Aumentando a retroalimentação (feedback) e comunicação é reduzida a necessidade de itens

intermediários entregues.
 Disciplina, habilidade e entendimento contra processo, formalidade e documentação.
 Pode-se perder eficiência em atividades que não são o gargalo do processo.
Siqueira (2003) relata ainda que o interessante dos métodos Crystal é que esse método não
possuí aparência de métodos não ágeis. Apesar de terem seus princípios e seus valores
claramente alinhados ao manifesto ágil, eles apresentam elementos(papéis, documentação,
artefatos, etc.) que são normalmente podem ser vistos em métodos, talcomo o Processo
Unificado. Essa característica permite que os métodos Crystal possam ser mais facilmente
utilizados por uma equipeque adota o XP.

Características
Políticas: As políticas adotadas no método Crystal Clear compreendem a entrega incremental a
cada dois ou três meses, participação direto do cliente, testes automatizados, participação de dois
usuários para validação dos incrementos e revisão dos processos através de workshops, o
processo é rastreado por pontos que consistem em entrega de versões ou decisões importantes.
Artefatos: os artefatos adotados são os planos de liberação de incrementos e do sistema para
validação e entrega, cronograma para a verificação dos usuários e entrega, esboço do projeto e da
interface do sistema bem como notas necessárias, código executável, casos de teste, casos de uso
e descrição das funcionalidades e código de migração caso necessário.

10.3 Integração Contínua

Segundo Fowler (2006), a Integração Contínua é uma prática de desenvolvimento de software
utilizado para que os membros de uma equipe de desenvolvedores possam integrar diariamente o
seu trabalho, podendo ser que essa integração pode acontecer mais de uma vez no dia. Uma build
automatizada, incluindo testes é executada a cada integração, visando detectar erros o mais
rápido possível. Essa integração pode reduzir significativamente a probabilidade de erros e
permite que uma equipe desenvolva software de forma coesa e com mais rapidez.

Vantagens
 Problemas de integração são detectados no mesmo dia em que são criados.
 Aviso rápido de código quebrado ou incompatível.
 Testes unitários para todas as alterações são executados imediatamente.
 Disponibilidade constante da versão “atual” para testes.
 O Impacto imediato da integração de código incompleto ou com erros é os desenvolvedores

aprenderem a trabalhar incremental mente com ciclos menores de feedback.

A principal vantagem da integração continua esta no feedback rápido a cada commit no
repositório, o build é feito automaticamente, com todos os testes sendo executados de forma
automática e falhas sendo detectadas. Se algum commit não compilar ou quebrar qualquer um
dos testes, a equipe toma conhecimento instantaneamente para então corrigir o problema o mais
rápido possível.

Cenário típico
Um cenário típico de integração continua geralmente inclui os seguintes passos:

 1° Passo – Uma vez que um desenvolvedor tem realizado todas as modificações

relacionadas ao atribuído tarefa, ela corre uma construção privada (que integra as mudanças
de o resto da equipe) e depois comete suas mudanças para o controle de versão repositório.
 2° Passo – Logo após um commit ocorre, o servidor de CI detecta que as mudanças no

repositório de controle de versão, de modo que o servidor de CI recupera a cópia mais

recente do código do repositório e, em seguida, executa um build script, que integra o
software.
 3° Passo – O servidor de CI gera comentários por e-mail construir resultados a

especificados os membros do projeto.

 4° Passo – O servidor de CI continua a captar mudanças no repositório de controle de

versão.

Repositório de controle de versão

É o responsável por fornecer um local centralizado para armazenamento dos arquivos de um
projeto, e também controlar as versões desses arquivos.
Num ambiente onde diversas pessoas trabalham em um projeto, o destino final de tudo o que é
produzido é direcionado para um único repositório. Quando ocorre o armazenamento do trabalho
de um desenvolvedor no repositório, ocorre o que se dá o nome de integração do que é produzido
com os demais módulos que se encontram nesse repositório.Guardar versões é como ter um botão
de "desfazer" à nossa disposição. Quando cometemos um erro em um arquivo e o colocamos
acidentalmente no repositório, o repositório nos permite recuperar a versão anterior.

CI Server
O servidor de CI monitora periodicamente o repositório de controle de versão a fim de verificar
mudanças no repositório, recuperaos arquivos de origeme executa buildscript ouscripts. Além
disso, os servidores CI geralmente fornecem um painel conveniente, onde resultados da
construçãosão publicados.Embora seja recomendado, um servidor CI não é necessário pararealizar
a integraçãocontínua.Você pode escrevero seuspróprios scripts personalizados.

Existem várias ferramentas que podem ser utilizadas para esta tarefa. Entre as mais utilizadas
temos a Cruise Control, Hudson e BuildBot – todas são open-source. Existem ferramentas menos
complexas, tais como Make, Rake, Ant e Maven e Buildoutque podem ser utilizadas pra gerar
builds de forma mais simples. Essas últimas ferramentas se comparadas com as primeiras
ferramentas citadas, possuem mais funcionalidades podendo até enviar e-mails, realizar o
agendamento builds e até permitem comandar diferentes máquinas para que as builds sejam
executadas.

Build Script
Um conjunto de atividades realizadas para gerar, testar, inspecionar e implantar software.

Problemas da Integração Contínua

 Aumento da sobrecarga na manutenção do sistema.
 Muitas mudanças.
 Muitas falhas de builds.
 Custos adicionais de hardware e software.
 Desenvolvedores precisam ter desempenho nestas atividades.

Riscos
 Falta de desenvolvimento.
 Baixa qualidade de software.
 Falta de visibilidade no projeto.
 Atraso para descobrir defeitos.

Valores da Integração Continua

 Reduzir os riscos.
 Reduzir os processos manuais repetitivos.
 Gerar software implantado a qualquer momento e em qualquer lugar.
 Permitir uma melhor visibilidade do projeto.
 Estabelecer uma maior confiança no produto de software daequipe de desenvolvimento.
Processo de Integração Contínua
Em cada atividade realizada no projeto são realizados os seguintes passos:

 Identificar – Identificar um processo que requer automação. O processo pode ser nas áreas

de compilação, teste, inspeção, desenvolvimento, integração de banco de dados, e assim por

diante.
 Construir – A criação de um script de construção (Build) faz a automação repetível e

consistente.
 Compartilhar – Ao utilizar um sistema de controle de versão, como Subversion, tornasse

possível que outras pessoas também usem esses scripts /programas.

 Fazer continuamente – Deve-se certificar que o processo está executado com todas as

mudanças aplicadas, utilizando um servidor de CI ou fazendo a integração manualmente.

Para Saber Mais

Leia o artigo “Integração contínua”, de Martin Fowler, e conheça as principais características da
Integração Contínua, segundo o autor.

Com esta aula você encerrou seus estudos sobre as metodologias ágeis para desenvolvimento
rápido de software. Nada impede que você se aprofunde mais nessas metodologias acrescentando
mais conhecimentos na sua “Caixa de Ferramentas Pessoal”. Esperamos que você possa aplicar
as três novas metodologias apresentadas nessa aula no desenvolvimento de sistemas.

Algumas dessas metodologias não são amplamente aplicadas e divulgadas no Brasil, entretanto
isso não impede que as mesmas venham a fazer parte do rol de metodologias num futuro
próximo.