Ministério da Educação

Secretaria de Educação Profissional e Tecnológica

Instituto Federal de Educação, Ciência e Tecnologia de São Paulo
Campus Presidente Epitácio

Análise de Sistemas II

Metodologias Crystal e
Metodologia DSDM(Dynamic Systems
Development Method)

Professora Andrea Padovan Jubileu

Alunos: Hellen, Jakybalis, Thaynára e Osmar.

Maio 2016
 Introdução

O que é uma Metodologia?

- Conjunto de padrões de processos, ferramentas
e técnicas adotadas para construção de
Software.
O desenvolvimento de softwares pode se tornar
uma tarefa extremamente complexa e demorada,
dependendo das funcionalidades do programa. As
metodologias podem auxiliar neste processo aonde
são aplicadas ao tipo e tamanho do projeto.
Com o grande crescimento de mudanças nas
tecnologias houve-se a necessidade de
desenvolver softwares bem mais complexos em
menos tempo. Surgiram, então, as metodologias
ágeis.

2
 Introdução

O foco deste trabalho será a Metodologia Crystal

e a metodologia DSDM (Metodologia de Sistemas
Dinâmicos).

3
Metodologia Crystal
ou
Família de
Metodogias Crystal.

4
 Um pouco de História:
• Desenvolvido por Alister Cokburn um dos
idealizadores do movimento Desenvolvimento Ágil de
Softwares;
• No ano de 2000;
• Voltada para a gestão de pessoas;
• Seu foco é a interação, comunidade, habilidades,
talentos e comunicações assim acreditando que
estes princípios são os que tem efeito no
desempenho;
• Os membros da equipe tem conjunto diferente de
talentos e habilidades, ou seja a exclusividade de
processos sobre medida para as equipes.

5
 Valores comuns:

Possui valores comuns a outras metodologias ágeis:

- Entrega frequente;
- Comunicação eficaz;
- Equipes com especialistas;
- Papéis pré-definidos.

6
 Metodologia Crystal

É uma família de metodologias com um código

genético em comum, que podem ser adaptados de
acordo com o projeto ou número integrantes da
equipe.
É importante ressaltar que não há uma metodologia
Crystal, e sim existem diferentes tipos de
metodologias Crystal para diferentes tipos de projeto.

7
 Metodologia Crystal:

Os projetos possuem um ciclo de desenvolvimento

incremental(modelo incremental). E com liberações
variando de 1 à 4 meses. A cada iteração são feitos
reflexões de possíveis melhorias. Cada organização
avalia o projeto por duas visões, números de pessoas
e criticidade do sistema.

8
 Código Genético

O código genético da família Crystal baseia-se em:

• Jogo Econômico cooperativo;
• Prioridades;
• Propriedades;
• Princípios;
• Estratégias e técnicas.

9
Jogo Econômico Cooperativo:

10
 Jogo Econômico Cooperativo:

• O desenvolvimento de software é uma “série” de

jogos.

• Possui dois objetivos, entrega de software funcional e

preparação para a próxima etapa.

• O jogo nunca se repete;

• O modelo de jogo econômico-cooperativo leva as

pessoas a pensarem sobre seu trabalho em um
projeto de uma forma muito específica.

11
Prioridades:

12
 Prioridades:

• Segurança no resultado do projeto(entrega do

software);

• Eficiência no desenvolvimento;

• Habilidades das convenções(o time precisa aceitar o

processo).

13
Prioridades:

14
Propriedades:

15
 Propriedades:
• Entrega frequente:
-Os desenvolvedores mantêm o foco;
-A equipe se mantêm através das realizações;
-O Cliente recebe o feedback constante.

• Comunicação face-a-face(comunicação osmótica):

-Surge entre a equipe;
-A maneira mais barata e rápida de trocar
informações.

16
 Propriedades:

• Fácil acesso ao especialista:

- Permite realizar testes e entregas frequentes;
- Facilita a tomada de decisões.

• Segurança pessoal:
- Dizer livremente o que esta incomodando;
- Descobrir e trabalhar fraquezas.

17
Princípios:

18
 Princípios:

• Mais feedback reduz a necessidade de entregas

intermediárias:
- Considera-se feedback entrega de software
funcionando.

• Excesso de metodologia é custo:

- Evitar burocracia desnecessária;
- Redução de custo com o tempo, ferramentas, etc.

19
 Princípios:
• Diferentes projetos precisam de metodologias
distintas:
- Dois fatores influenciam na escolha: Número de
pessoas na equipe e criticidade no Sistema.

20
Estratégias e Técnicas

21
 Estratégias e Técnicas:

A Crystal ela não requer de qualquer estratégia ou

técnica porem é aconselhável utilizar algumas:
• Estratégias:
-Exploratório 360º: Analisar o projeto em todas as
dimensões, checando por exemplo a viabilidade, valor
do negócio, tecnologia.
-Vença cedo: é uma estratégia de gerenciamento
de projetos, que trabalha com a entrega de algo de valor
no início do projeto.
-Esqueleto andante: implantar uma pequena
funcionalidade no sistema do início ao fim, validando a
arquitetura e obtendo o feedback do cliente, e encontrar
problemas mais cedo.

22
 Estratégias e Técnicas:

-Rearquitetura Incremental: a partir do esqueleto

humano, com a evolução da tecnologia e as mudanças
dos requisitos a arquitetura tem que evoluir com o longo
do tempo.
-Radiadores de informação: Deixa as
informações do projeto em um lugar visível,
possibilitando a equipe tirar todas as dúvidas.
• Técnicas:
-Metodologia de formação: coleta de informações
sobre as experiências anteriores, utilizando-as nas
convenções iniciais.
-Oficina de Reflexão: faz uma pausa após cada
entrega do projeto; para refletir sobre o trabalho
realizado, e se for necessário realiza alterações
para a próxima entrega.
23
 Estratégias e Técnicas:

-Reuniões Diárias: Difundir informações pela

equipe, não utilizada para discutir problemas e sim
identificá-los.
-Programação lada-a-lado.
-Burn charts(Tipo de gráfico): maneira de dar
visibilidade de como está o andamento do projeto,
através de relatórios contendo gráficos.

24
Metodologias:

25
Parâmetros conforme o tamanho:
Cada Método Crystal é caracterizado por uma cor, de
acordo com o número de envolvidos.
• Crystal Clear: é uma metodologia leve, para equipes
de dois a oito pessoas, podendo chegar até doze em
casos especiais;
• Yellow: para equipes por volta de sete a vinte
membros;
• Orange: e a variante Orange Web são apropriados
para equipes de vinte e um a oitenta participantes;
• Red: para equipes com mais de duzentos
participantes. Cada um dos métodos com graus de
gerenciamento e de comunicação ajustados de
acordo com o tamanho da equipe.

26
Parâmetros conforme o tamanho:
Quanto mais escura a cor mais complexo e crítico
será o projeto:

27
Parâmetros conforme o tamanho:

28
Parâmetros conforme nível crítico do
projeto:
O Crystal utiliza algumas letras para representar
potenciais perdas causados por uma falha no sistema
de desenvolvimento de software.
• C de Confort (Conforto), casos em que a falha do
sistema ocasiona a perda de credibilidade do usuário
devido ele não atender.
• D de Discretionary money (Dinheiro disponível para
uso conforme necessário, cujo uso depende de
decisão de alguém com poder de decisão). Casos
em que a falha do sistema ocasiona na perda de
dinheiro, mas de valor inexpressivo.
• E de Essencial money (Dinheiro essencial –
dinheiro indispensável, absolutamente necessário)
casos em que a falha do sistema ocasiona a perda
de um quantia indispensável, grandes valores.

29
Parâmetros conforme nível crítico do
projeto:

• L de Life (vida) casos em que a falha do sistema

ocasiona a perda de Vidas, tendo como referência
um software de piloto automático onde sua falha
poderia derrubar um avião e matar seus tripulantes.

30
Crystal Clear:

31
 Crystal Clear:

Utiliza um ciclo de projeto dividido em três partes.

1ª Parte-Mapeamento de Atividades:
Constituída por 4 passos:
I-Construir o núcleo da equipe:
A equipe possuindo os seguintes papéis.
-Ter um patrocinador do projeto;
-Chefe de designer: deve ser um especialista e
ter um conhecimento do projeto,
-Ambassador user: desenvolvedor especialista
que a equipe pode consultar quando precisar.
II- Utilizar a técnica 360º;
III-Definir como a metodologia será aplicada,
IV-Construir o plano inicial do projeto.

32
 Crystal Clear:

2ª Parte: Uma série de 2 ou mais ciclos de

entrega:
Ciclo de entrega:
I-Fazer uma reavaliação dos planos de entrega;
II-Fazer interações com o código testado;
III-Entrega real para o usuário

3ª Parte: Reflexão sobre a entrega:

Tem se um reflexão sobre o projeto, o processo e
deixar claro o que funcionou ou não. Assim chega-
se ao final do projeto.

33
 Conclusão:

Pontos Positivos:
-Entregas frequentes das etapas do projeto,
reduzindo o retrabalho;
-Reduz possíveis falhas de entrega pois o usuário
está envolvido diretamente no projeto;
-Maior controle por parte da gestão, que conhece
o que está sendo construído durante a fase de
desenvolvimento e não somente ao final;
-Proporciona menos especulação e mais
visibilidade que vão sendo executadas.
-Possibilita ser muito adaptada de acordo com o
projeto.

34
 Conclusão:

Pontos Negativos:
-A metodologia não foi desenvolvida para trabalhar
com projetos longos.

35
Dynamic Systems Development
Methodology (DSDM)

Dynamic Systems
Development
Methodology
DSDM
36
 Dynamic Systems Development
Methodology (DSDM)

• DSDM é uma metodologia de desenvolvimento

de software originalmente baseada em
"Desenvolvimento Rápido de Aplicação" (RAD).
• Origem: Criado na Inglaterra, na década de 90,
por uma organização sem fins lucrativos que
reuniu membros de várias empresas. (British
Airways, Min. da Defesa, Vodafone), e evoluindo
até os dias atuais.
• Objetivo: entregar softwares no tempo e com
custo estimados através do controle e ajuste de
requisitos ao longo do desenvolvimento.
37
Modelo Tradicional x Modelo DSDM

38
 DSDM – Princípios

Existem 9 princípios essenciais no DSDM.

• Envolvimento: o envolvimento do usuário é
o ponto principal para eficiência e eficácia do
projeto. Onde usuários e desenvolvedores
dividem o mesmo espaço, as decisões
podem ser feitas com mais precisão.
• Autonomia: o time deve estar empenhado
em tomar decisões que sejam importantes
ao progresso do projeto sem que necessitem
de aprovação dos superiores.

39
 DSDM – Princípios

• Entregas: o foco na entrega frequente de

produtos, assumindo que entregar algo
bom logo é melhor que entregar algo
perfeito somente no fim. Iniciando a
entrega do produto desde os primeiros
estágios do projeto, o produto pode ser
testado e revisado e a evidência do teste e
revisão da documentação pode ser
utilizados na próxima iteração ou fase.

40
 DSDM – Princípios

• Eficácia: o critério principal para ser

considerado “aceitável" é entregar um
sistema que demonstre realmente auxiliar
nas necessidades e negócio atuais, com
menos foco na quantidade de
funcionalidades implementadas.
• Feedback: o desenvolvimento é iterativo e
incremental controlado por feedbacks de
usuários, a fim de tornar a solução mais
eficaz ao negócio.

41
 DSDM – Princípios

• Reversibilidade: todas as alterações feitas

no desenvolvimento são reversíveis.
• Previsibilidade: o escopo e requisitos de
alto nível (principais) devem ser definidos
antes que o projeto se inicie.
• Testes contínuos: O teste é integrado por
todo ciclo de vida do projeto.
• Comunicação: é necessária excelente
comunicação e cooperação de todos os
envolvidos, para obter maior eficácia e
eficiência no projeto.
42
 Técnicas utilizadas no DSDM

• O DSDM utiliza uma filosofia do princípio de

Pareto, adaptada à engenharia de software,
onde se diz que “80% de uma aplicação
pode ser entregue em 20% do tempo que
levaria para entregar a aplicação
completa” entendendo que nenhum
sistema é completamente construído na
primeira tentativa.

43
 Técnicas utilizadas no DSDM

O Timeboxing, ou encapsulamento do tempo,

é uma das principais técnicas utilizadas nos
projetos baseados na metodologia DSDM.
A principal idéia por de trás do Timeboxing é
dividir o projeto em partes (projetos menores),
cada uma, como o projeto todo, com um
orçamento e data de entrega fixos. Para cada
parte, é selecionada um número de requisitos
que são escalonados por prioridade, de
acordo com o princípio chamado MoSCoW.

44
Técnicas utilizadas no DSDM

Todos os princípios e técnicas utilizadas no

projeto como um todo, também aplicam-se
às suas partes, como o tempo e o custo
previamente estipulados e fixos e o princípio
de Pareto (80% 20%), desta forma cada
parte é desenvolvida só até o ponto em que
esteja funcional o suficiente, para poder ser
utilizada pela equipe responsável pela
próxima etapa.

45
 MoSCoW

MoSCoW é um acrônimo que representa:

MUST have this.

SHOULD have this if at all possible.
COULD have this if it does not affect anything
else.
WON'T have this time but WOULD like in the
future.

46
 MoSCow

Traduzindo:

TEM de ter isto.

DEVE ter isto se for possível por completo.
PODE ter isto se não afetar o resto.
NÃO VAI ter isto agora, mas SERIA bom ter
no futuro.

47
 Pré - projeto
O DSDM consiste em 3 fases principais:
• Pré-projeto
• Ciclo de vida
• Pós-projeto

• Pré-projeto
Nesta fase tratam-se das questões iniciais,
tais como, orçamento condições para
assinatura do contrato, para evitar futuros
problemas em estágios mais críticos do
projeto.
48
 Ciclo de Vida

Ciclo de vida: esta fase é divida em 5 estágios.

• Análise de viabilidade.
• Análise de negócio.
• Iteração do modelo funcional.
• Iteração de design e desenvolvimento.
• Implantação.

49
 Ciclo de Vida
• Análise de viabilidade:
Este estágio avalia se o projeto pode ser feito
utilizando-se o DSDM, dados os recursos e
tempo disponíveis. Cria-se um esboço global
para o resto do projeto e um Registro de
Risco, só então o projeto é declarado, ou não,
como viável.
• Análise de negócio:
Neste estágio, examina-se o processo de
financiamento, os usuários envolvidos e as
suas necessidades, determinando as
funcionalidades que serão implementadas.
50
 Ciclo de Vida
Neste estágio de análise de negócio
recomenda-se que os diferentes stakeholders
sejam reunidos por meio de Workshops e
discutam o sistema proposto, suas conclusões
juntamente com a lista de requisitos, permitem
que sejam identificadas as funcionalidades do
sistema que devem ser entregues
prioritariamente. Estas prioridades são
definidas para o projeto como um todo, bem
como para suas partes, utilizando-se o
princípio MoSCoW e o Registro de Risco é
atualizado.

51
 Ciclo de Vida
• Iteração do modelo funcional:
Fase em que se realiza a análise e produção
de protótipos funcionais. Os protótipos são
entregues aos usuários que o testam e
avaliam, a lista de requisitos é atualizada
sendo apagados os itens já implementados e
repensados as prioridades dos requisitos
restantes, eventualmente novos requisitos
podem ser adicionados.

52
 Ciclo de Vida

• Iteração de design e desenvolvimento:

Pode ser realizada em paralelo com a
iteração do modelo funcional. Nesta iteração
faz-se a integração dos componentes
funcionais da etapa anterior e cria-se um
produto-protótipo, construído de maneira a
satisfazer com segurança as necessidades
do usuário. Devendo ser entregue aos
usuários finais para testes em uso diário.

53
 Ciclo de Vida
• Implantação:
Nesta fase após a aprovação dos usuários
finais, são definidas as linhas mestras para a
implementação e uso operacional do
sistema, inicia-se a fase de treinamento dos
usuários, é feita e entregue a documentação
do produto e ocorre uma revisão final da
mesma, comparam-se os resultados obtidos
com os requisitos identificados, e avalia-se o
impacto do sistema implementado no
negócio do cliente.

54
 Ciclo de Vida

Dependendo disto, o projeto passará para a

fase seguinte, o Pós-Projeto ou voltará a
uma das fases anteriores, em se chegando
ao final do estágio de implantação, o
sistema deverá estar entregue, instalado e
pronto para o uso de todos os usuários finais,
devendo a documentação de utilização do
sistema ser detalhada.
Passando então o projeto para sua fase final,
o Pós-Projeto.

55
 Pós-Projeto

A fase de Pós-Projeto assegura um sistema

de atuação eficiente. Isto é conseguido
através de manutenções, melhorias e ajustes
de acordo com os princípios da DSDM. A
manutenção pode ser vista como um contínuo
desenvolvimento, e até mesmo a iniciação de
novos projetos, para atualizar o sistema
existente, é possível.

56
 Conclusão

Apesar da utilização de uma metodologia ágil

não ser aconselhada para todos os tipos de
projeto, a DSDM é uma ótima e segura base
para equipes de desenvolvimento que têm
em mãos projetos com necessidade de
execução rápida e com requisitos flexíveis. A
partir da metodologia DSDM, é possível
construir um trabalho que agrade ao cliente,
graças ao cumprimento dos prazos e
orçamentos pré-estabelecidos.

57
 Conclusão

Agradando também à equipe de

desenvolvimento que terá em mãos um
projeto organizado e com a obrigação de
cumprir apenas os requisitos necessários à
execução do sistema, e ainda agradar aos
usuários finais, que terão a oportunidade de
interagir com todo o desenvolvimento do
sistema, através das frequentes fases de
testes.

58
 Bibliografia
• Crystal:
UNIFESSPA. Metodologia Ágil de Desenvolvimento Crystal.
Disponível em:
<https://www.passeidireto.com/arquivo/1961104/metodologia-agil-de-
desenvolvimento-crystal> . [14.05.2016] [18:03 hs.].
Thiago Sinésio. Crystal Clear Methodologies. Disponível em:
<http://pt.slideshare.net/ThiagoSinsio/metodologia-crystal-clear>.
[10.05.2016] [13:37 hs.].
Leandromtr. Metodologia ágil Crystal. Disponível em:
<http://www.leandromtr.com/tecnologia-informacao/metodologia-agil-
crystal/>. [10.05.2016] [20:08 hs].
Fatec-sr Noturno Turma 3. Metodologias Ágeis - Família Crystal.
Disponível em: <https://www.youtube.com/watch?v=ssdMpROxbh4>.
[15.05.2016][15:33 hs.].

59
 Bibliografia
• DSDM:

Faculdade de Engenharia da Universidade do Porto. DSDM. Disponível

em:<http://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final_14.pdf>.
Acesso em 29 abril. 2016
Youtube. Metodología DSDM. Disponível em:
<https://www.youtube.com/watch?v=1yhwdrw5Yy8>. Acesso em 29 abril.
2016
Wikipédia. Metodologia de Desenvolvimento de Sistemas Dinâmicos.
Disponível em:
<https://pt.wikipedia.org/wiki/Metodologia_de_desenvolvimento_de_siste
mas_din%C3%A2micos >. Acesso em 15 maio. 2016

60