DSDM Dynamic Systems Development Methodology

Daniel Dinis Teixeira, Fernando Jorge Afonso Pires, Jos Pedro Gaiolas de Sousa
Pinto, Tiago Alexandre Gonalves Pereira Santos
Faculdade de Engenharia da Universidade do Porto

Resumo. Foi objectivo deste trabalho explorar a metodologia DSDM (Dynamic

Systems Development Methodology). Depois de uma breve explicao sobre as
metodologias geis, onde a DSDM se insere, foram apresentados os seus princpios e processos, bem como os prs e contras da sua utilizao. Em anexo,
decidimos apresentar um exemplo real dado pela consultora norte-americana
Michelle Johnston para a importncia da DSDM em solues de comrcio electrnico.

1.

Introduo

A DSDM (Dynamic Systems Development Methodology) insere-se no ramo das

metodologias geis de apoio ao desenvolvimento de software. Esta metodologia, visa
desenvolver uma aplicao com a qualidade desejada sem ultrapassar limites de tempo e oramento. Para o conseguir, a DSDM foca-se na interaco com o cliente e o
utilizador final, entrega de prottipos frequentes, equipas de desenvolvimento autnomas, testes massificados durante todo o processo e na definio de prioridades
entre a lista de requisitos dada pelo cliente. As trs fases que constituem esta metodologia, assim como os seus processos, princpios e casos de utilizao, so explicados
neste artigo de sntese, realizado para a disciplina de Engenharia de Software, do 3
ano da Licenciatura de Engenharia Informtica e Computao da Faculdade de Engenharia da Universidade do Porto.

2.

Metodologias geis

A maioria do desenvolvimento de software feita de forma catica, vulgarmente

caracterizada pelo mtodo programar e corrigir. O cdigo feito sem um planeamento aprofundado do problema, sendo muitas vezes agregado a pores de cdigo
distinto para a resoluo de pequenos problemas que surgem conforme o software vai
sendo desenvolvido.
Este procedimento eficaz para pequenas aplicaes mas, com o aumento do sistema
construdo, torna-se bastante mais difcil adicionar novas funcionalidades ao programa ou alterar outras j existentes. Alm disso, os bugs tornam-se bastante mais frequentes e bem mais difceis de resolver.

Uma longa fase de testes posterior concepo do programa uma caracterstica

deste tipo de programao, bem como um sinal de que foi usada. Dado ser muito
difcil estabelecer prazos exactos para uma fase de testes e debugging to longa, o
tempo previsto para a execuo do trabalho tambm difcil de determinar.
Este estilo de desenvolvimento de projectos foi predominante durante muito tempo,
tendo como mais forte concorrente o Desenvolvimento Metdico. O Desenvolvimento
Metdico impe um processo de desenvolvimento disciplinado, com o objectivo de
tornar o desenvolvimento de software previsvel e eficiente, conseguido atravs do
desenvolvimento de documentao detalhada e dando um grande nfase ao planeamento inspirado noutras reas da engenharia de software.
O desenvolvimento metdico j existe h bastante tempo, mas nunca chegou a ser
frequentemente utilizado devido sua falta de eficcia uma metodologia burocrtica sendo que, para a seguir, necessrio cumprir diversos itens que tornam o desenvolvimento do software muito mais demorado.

Fig. 1. Metodologias geis

Derivada desta metodologia surgiu um novo grupo apelidado de Metodologias geis

(esta designao deriva da comparao, em termos burocrticos, com o desenvolvimento metdico). Estes novos mtodos tentam encontrar um ponto de equilbrio

ptimo entre o trabalho diminuto e o trabalho excessivo, rentabilizando o pagamento

em relao ao trabalho feito.
Como resultado, as metodologias geis tm sido adoptadas em diversas aplicaes e
alterado significativamente as metodologias de engenharia de software. A diferena
mais imediata pode ser observada pela falta de necessidade em gerar muita documentao para fazer as mesmas tarefas. Estas metodologias so mais orientadas ao cdigo
propriamente dito, planeando os passos para o desenvolvimento deste e documentando-o.
A falta de documentao das metodologias geis resulta de algumas diferenas substanciais em relao ao desenvolvimento metdico:
1 As Metodologias geis so propositadamente flexveis, ao invs de estticas e previsveis. O desenvolvimento metdico tende a tentar planear uma grande
parte da criao de software em grande detalhe, para um longo perodo de tempo,
situao que s satisfatria enquanto os requisitos no mudarem. Pelo contrrio, os
mtodos geis esto preparados para as mudanas. Tendem a ser processos que se
adaptam e melhoram com as alteraes.
2 As Metodologias geis so orientadas s pessoas e no aos processos. O
objectivo do desenvolvimento metdico definir processos que funcionaram bem
quaisquer que sejam os utilizadores. Estes mtodos baseiam-se na suposio de que
nenhum processo alguma vez ir ultrapassar as capacidades da equipa de desenvolvimento. Portanto, o seu papel neste processo suportar a equipa de desenvolvimento
no seu trabalho e dar-lhes a perceber o que realmente necessitam.

3.

Dynamic Systems Development Methodology

3.1

Introduo Metodologia

A DSDM fornece uma framework para uma abordagem interactiva e incremental de

desenvolvimento de Sistemas de Informao (SI). Desenvolveu-se nos anos 90 na
Inglaterra e foi aplicado pela primeira vez em 1995. Nesta altura (Novembro de
2005), o Manual DSDM encontra-se na 4 verso. Esta metodologia foi desenvolvida
por um consrcio de vendedores e peritos no campo dos Sistemas de Informao, no
qual partilharam e combinaram as suas melhores tcnicas. Assim, a DSDM surge
como uma extenso do RAD (Rapid Application Development), focada em projectos
de Sistemas de Informao caracterizados por prazos e oramentos apertados.
A DSDM aborda os problemas que frequentemente ocorrem no desenvolvimento de
informao que se prendem essencialmente com a falta de tempo, com oramentos
mais apertados ou com outro tipo de razes para que o projecto falhe, tal como a falta
de envolvimento dos encarregados do projecto ou dos utilizadores finais.

Fig. 2. Princpio fundamental da DSDM

3.2

Princpios da DSDM

A DSDM segue alguns princpios chave. Estes princpios delimitam as bases do

desenvolvimento utilizando DSDM.
O ponto fundamental desta metodologia prende-se com a entrega de um sistema que se aproxime das actuais necessidades de negcio. No uma
metodologia to directa que fornea todas as necessidades de negcio, mas
centraliza todo o potencial na concretizao final de todos os objectivos do
projecto.
Nenhum sistema completamente construdo na primeira tentativa. Num
processo de desenvolvimento de um sistema informtico 80% da soluo
pode ser desenvolvida em 20% do tempo necessrio para encontrar a soluo
perfeita. Para aperfeioar a parte final poder ser necessrio que o projecto
ultrapasse o seu tempo e oramento estipulados. Uma vez que a DSDM
caracterizada por realizar exactamente o que a empresa necessita, muitas
vezes desnecessrio chegar soluo perfeita.
A entrega do projecto deve ser feita na data estipulada, dentro do oramento
previsto e com boa qualidade (Fig. 2).
As exigncias para o Sistema de Informao tm que ser flexveis. Tal como
falaremos mais tarde, exigncias flexveis so tpicos importantes da
DSDM.
Esta metodologia apenas requer que cada etapa do desenvolvimento seja
completada at que seja possvel iniciar o passo seguinte. Isto faz com que
cada fase do projecto possa comear sem ter que esperar que as fases que
comearam anteriormente sejam totalmente terminadas.

A comunicao entre todas as partes envolvidas (stakeholders) tambm

um pr-requisito bastante importante para que o projecto corra com a eficincia desejada.
O envolvimento dos utilizadores a chave para esta eficincia.

3.3

As equipas responsveis tm que ser dotadas de um sentido de deciso, sendo este tambm um ponto fulcral na progresso do projecto.
Tal como as equipas de desenvolvimento tambm as equipas de gesto do
projecto esto incorporadas na DSDM.
Aps o desenvolvimento do Sistema de Informao, a DSDM pode tambm
ser usado para expandir o Sistema obtido.
Pr-requisitos para a Utilizao da DSDM

Para que a DSDM seja um sucesso, um nmero definido de pr-requisitos devem ser
implementados. Em primeiro lugar, necessria a existncia de uma interactividade
entre a equipa de desenvolvimento, os utilizadores finais e os gestores de projecto. A
falta de motivao da equipa de gesto ou a falta de envolvimento dos utilizadoresfinais uma das mais frequentes causas de falha do desenvolvimento de projectos de
Sistemas de Informao. Um segundo, e importante, pr-requisito a facilidade de
decomposio em mdulos. Esta possibilidade de decompor o projecto em partes
mais pequenas, possibilita as abordagens iterativa e incremental da DSDM. Esta funcionalidade possibilita a criao de diversos projectos mais pequenos, tambm eles a
serem desenvolvidos segundo os princpios da DSDM. A terceira, e no menos
importante, propriedade relaciona-se com a possibilidade de definir claramente os
requisitos do SI, introduzindo-lhes uma ordem segundo a sua prioridade de implementao.
Os projectos que no preencham estes requisitos ajustam-se menos ao desenvolvimento utilizando a DSDM. Por exemplo, projectos complexos que so difceis ou
impossveis de decompor no podero ser desenvolvidos usando uma abordagem
DSDM. De uma forma semelhante, requisitos pouco claros ou que no possam ser
escalonados por uma ordem de preferncia podem fazer com que os projectos ultrapassem o tempo e oramento estipulados, efeitos que a DSDM foi feita para evitar.
Outro grupo de projectos para o qual a DSDM no apropriada aquele cujo produto
final necessitar de um estado de segurana-crtica. A intensiva fase de testes e validao necessria neste tipo de projectos colide com os objectivos da DSDM em estar
pronta a tempo e sem ultrapassar o oramento estipulado. Por fim, os projectos que
apontam para componentes reutilizveis podem no ser apropriados para um desenvolvimento utilizando a DSDM j que as necessidades de perfeio neste tipo de
projectos colidem com o princpio 80%/20% descrito anteriormente.

3.4

As fases da DSDM

O framework DSDM consiste em trs fases sequenciais: Pr-Projecto, Projecto e

Ps-Projecto. A fase de Projecto do DSDM a mais elaborada das trs fases. Ela
consiste em 5 nveis formadas por uma abordagem passo-a-passo e iterativa no desenvolvimento de um SI. As trs fases e correspondentes nveis so explicadas exaustivamente nas seces seguintes.
Fase 1: O Pr-Projecto
Na fase do pr-projecto, o projecto candidato identificado, tratando-se depois do seu
plano de financiamento e sendo assegurado um compromisso de realizao. Tratar
destas questes numa fase inicial evita problemas futuros em fases mais avanadas do
desenvolvimento do projecto.

Fig. 3. Ciclo de Vida de um Projecto em DSDM

Fase 2: O Ciclo de Vida do Projecto

A viso geral de um processo DSDM, presente na Fig. 3, representa o Ciclo de Vida
do Projecto nesta segunda fase da metodologia. Ela mostra os 5 nveis que a equipa
de desenvolvimento ter de percorrer para criar um SI. Os dois primeiros nveis, o
Estudo de Viabilidade e o Estudo de Negcio, so fases sequenciais que se complementam. Depois destas fases estarem concludas, o sistema desenvolvido iterativamente e de forma incremental nos nveis de Anlise Funcional, Desenho e Implementao.

Nvel 1: O Estudo de Viabilidade

Durante este nvel do projecto, a viabilidade de utilizao da DSDM para este projecto examinada. Os pr-requisitos para o uso da DSDM so encontrados respondendo
a questes como: Pode este projecto ir de encontro s necessidades de negcio apontadas?, , este projecto, adequado ao uso da DSDM? e Quais so os riscos mais
importantes envolvidos?. As tcnicas mais importantes utilizadas nesta fase so os
workshops.
Para entrega ao cliente, so preparados neste nvel o Relatrio e o Prottipo de Viabilidade que dizem respeito viabilidade do projecto em mos. A estes, adicionam-se
um esboo global do plano para o resto do projecto e um Registo de Risco que identifica os riscos mais importantes no projecto.
Nvel 2: O Estudo do Negcio
O Estudo do Negcio incrementa todo o trabalho realizado no Estudo de Viabilidade.
Depois do projecto ser declarado fivel para o uso da DSDM, este nvel examina o
processo de financiamento, os utilizadores envolvidos e as suas necessidades e desejos respectivos. Uma vez mais, os workshops so uma das mais valiosas tcnicas.
Workshops nos quais os diferentes stakeholders se renam e discutam o sistema proposto. A informao retirada destas sesses combinada numa lista de requisitos.
Uma importante propriedade desta lista de requisitos a possibilidade de se definir
prioridades. Estas prioridades so definidas utilizando uma perspectiva MoSCoW1.
Baseado neste escalonamento, um plano de desenvolvimento construdo como uma
linha mestra para o resto do projecto. Uma importante tcnica utilizada no desenvolvimento do plano a tcnica de Timeboxing2. Esta tcnica essencial para serem
atingidos os objectivos da DSDM, nomeadamente a imposio de tempo e oramento
fixos, garantindo no entanto a qualidade desejada. Uma arquitectura de sistema
outro meio para guiar o desenvolvimento do Sistema de Informao.
No final deste nvel, devero estar prontos para entrega ao cliente: uma definio de
rea de negcio que descreve o contexto do projecto dentro da companhia, a definio da arquitectura do sistema que fornece uma arquitectura global inicial do SI em
desenvolvimento juntamente com o plano de desenvolvimento que reala os passos
mais importantes no processo de desenvolvimento. Na base destes dois ltimos documentos est a lista de prioridades dos requisitos. A lista define todos os requisitos do
sistema, organizados de acordo com o princpio do MoSCoW. Por fim, o Registo de
Risco actualizado com os factos que foram identificados durante esta fase da
DSDM.

1
2

Mtodo de definio de prioridades, definido na seco 3.5

Encapsulamento de tempo, definido na seco 3.5

Nvel 3: Anlise Funcional

Os requisitos que foram identificados nos nveis anteriores so convertidos para um
Modelo Funcional. A Prototipagem uma das tcnicas chave dentro deste nvel,
que ajuda no bom envolvimento do utilizador final com o projecto. O prottipo
desenvolvido revisto pelos diferentes grupos de utilizadores. Para assegurar a qualidade do projecto, os testes so implementados em cada iterao da DSDM. Uma
importante parte dos testes so realizados na Anlise Funcional. O Modelo Funcional
pode ser subdividido em quatro sub nveis:
Identificar Prottipo Funcional: determinar as funcionalidades a ser implementadas
no prottipo que resulta desta iterao.
Acordar Calendrio de Tarefas: definir como e quando desenvolver estas funcionalidades.
Criar Prottipo Funcional: desenvolver o prottipo.
Rever o Prottipo: procurar correces possveis no prottipo desenvolvido. Isto pode
ser feito atravs de testes com utilizadores finais e revendo a documentao.
Neste nvel, necessrio entregar ao cliente o Modelo Funcional e o Prottipo Funcional que, juntos, representam as funcionalidades que podem ser realizadas nesta
iterao, prontas para serem testadas pelos utilizadores. Alm destes dois documentos, a Lista de Requisies actualizada, sendo apagados os itens que foram implementados e repensando as prioridades dos requisitos restantes.
Nvel 4: Desenho
O ponto central desta iterao da DSDM a integrao das componentes funcionais
do nvel anterior num sistema que satisfaa as necessidades do utilizador. Mais uma
vez, os testes so uma das actividades mais importantes. O Desenho pode ser dividido
em quatro sub nveis:
Identificar Prottipo de Desenho: identificar requisies funcionais e no-funcionais
que so necessrios no sistema testado.
Acordar Calendrio de Tarefas: definir como e quando desenvolver estes requisitos.
Criar Prottipo de Desenho: criar um sistema que possa, com segurana, ser fornecido aos utilizadores finais para um uso dirio.
Rever Prottipo de Desenho: verificar a exactido do sistema desenhado. Mais uma
vez, os testes e revises so peas fundamentais.
Ao utilizador, sero entregues o Prottipo de Desenho para que estes efectuem testes
ao produto-prottipo.

Nvel 5: Implementao
No nvel de Implementao, o sistema testado e a sua documentao so entregues
aos utilizadores finais que devero comear a ser treinados para a futura utilizao do
novo SI. O sistema a ser entregue foi revisto para incluir todos os requisitos que
foram definidos nos primeiros nveis do projecto. O nvel de implementao pode ser
dividido em quatro sub nveis:
Aprovao do utilizador: os utilizadores finais aprovam o sistema testado para
implementao e as linhas mestras para a implementao e uso do sistema so criadas.
Treinar os utilizadores: treinar os futuros utilizadores no uso do sistema.
Implementao: implementar o sistema testado no local de trabalho dos utilizadores
finais.
Rever Negcio: rever o impacto do sistema implementado no negcio, um problema
central ser tentar compreender se o sistema vai de encontro aos objectivos definidos
no incio do projecto. Dependendo disto, o projecto passar para a fase seguinte, o
Ps-Projecto ou voltar a uma das fases anteriores para desenvolvimento posterior.
No final deste nvel, o sistema dever ser entregue e instalado, pronto para o uso de
todos os utilizadores finais e a Documentao de Utilizao do Sistema dever ser
detalhada.
Fase 3: Ps-Projecto
A fase de ps-projecto assegura um sistema de actuao eficiente. Isto implementado atravs da manuteno e melhoramentos de acordo com os princpios da DSDM.
At mesmo a iniciao de novos projectos, para actualizar o sistema existente ou
desenvolver um novo sistema, possvel.
3.5

Lista de Conceitos Utilizados

Timeboxing
Timeboxing, ou encapsulamento do tempo, uma das tcnicas utilizadas nos projectos baseados na metodologia DSDM. Esta tcnica utilizada para suportar um dos
objectivos principais da DSDM: realizar o desenvolvimento de um Sistema de Informao no tempo previsto, dentro do oramento e com a qualidade desejada. A principal ideia por de trs do Timeboxing dividir o projecto em pores, cada uma com
um oramento fixo e uma data de entrega estipulada. Para cada poro, seleccionado um nmero de requisitos que so escalonados de acordo com o princpio de MoSCoW. Uma vez que o tempo e o oramento so fixos, a nica varivel restante aquela que representa os requisitos. Portanto, se um projecto est a ficar sem tempo ou
dinheiro, os requisitos com menor prioridade so omitidos. Isto significa, efectivamente, que um produto incompleto entregue, devido aos princpios subjacentes
DSDM de que 80% do projecto pode ser realizado em 20% do tempo que leva a cons-

truir o produto completo e de que nenhum sistema construdo na perfeio primeira tentativa.
MoSCoW
A tcnica MoSCoW representa um mtodo de definio de prioridades nas tarefas
efectuadas. Neste contexto, a tcnica MoSCoW da DSDM usada para dar prioridade
aos requisitos enunciados. um acrnimo 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.
TEM de ter isto.
DEVE ter isto se for possvel de todo.
PODE ter isto se no afectar o resto.

NO VAI ter isto agora mas SERIA bom ter no futuro.

Prototipagem
Esta tcnica refere-se criao de prottipos do sistema em desenvolvimento numa
fase inicial do projecto. Ela possibilita a descoberta antecipada de possveis problemas no sistema e o teste por parte dos futuros utilizadores do sistema. Deste modo,
conseguido um bom envolvimento do utilizador final com o sistema, sendo este um
dos principais factores de sucesso da DSDM.
Workshop
Esta uma das tcnicas de um projecto DSDM que tem como alvo juntar os diferentes stakeholders fazendo com que estes discutam as requisies estipuladas e as funcionalidades do produto, levando, no fim, a um entendimento mtuo. Num workshop,
os stakeholders renem-se e discutem o projecto.
Testes
Outro aspecto de relevo dos objectivos da DSDM a criao de um SI com boa qualidade. Para obter esta soluo, a DSDM obriga a efectuar testes em todas as iteraes. Uma vez que a DSDM uma metodologia independente de ferramentas e tcnicas, a equipa do projecto livre de escolher o seu prprio mtodo de realizao de
testes.
3.6

Natureza Iterativa e Incremental

Seguindo a tcnica de Timeboxing e dando prioridade a todos os requisitos, a DSDM

fornece tambm uma aproximao iterativa ao desenvolvimento de Sistemas de
Informao, aproximao que est ilustrada no esquema apresentado anteriormente

(Fig. 3). Os passos de Anlise Funcional, Desenho e Implementao esto totalmente

descritos de maneira iterativa o que demonstra que cada um dos nveis pode regressar
aos sub-nveis, antes de entrar no passo seguinte. Cada iterao aborda um novo conjunto de funcionalidades. Graas aproximao de desenvolvimento incremental,
todas as iteraes so construdas a partir do um antecessor que j se encontre a funcionar. Cada um destes incrementos pode ento voltar atrs quando/se necessrio. A
Fig. 3 representa situaes em que tal pode acontecer, ou seja, as setas regressam s
etapas anteriores. Como exemplo temos uma seta que regressa ao Estudo do Negcio
proveniente da Implementao. Se uma grande funcionalidade for descoberta durante
o decorrer do projecto, e esta no possa ser implementada, existe a possibilidade de
recomear tendo em conta as novas exigncias no Estudo do Negcio.
Outro exemplo de retrocesso encontra-se ilustrado pela seta que liga a Implementao
Anlise Funcional. Isto pode acontecer quando a funcionalidade omitida no processo prvio de Anlise Funcional, essencialmente devido falta de tempo ou de
restries oramentais. Apenas quando todas as exigncias necessrias realizao do
ajuste do projecto e aos objectivos do trabalho estiverem concludas, o projecto avana para as fases posteriores.
Graas a esta natureza iterativa, necessrio manter um bom grau de exigncia da
equipa gestora durante todo o desenvolvimento. Isto assegura que o projecto implementa todos os requisitos pedidos essenciais, na forma desejada definida nas fases
anteriores do projecto.
3.7

Factores de Sucesso da DSDM

Dentro da DSDM existe um grande nmero de factores identificados como de extrema importncia para assegurar o sucesso do projecto. Em primeira instncia necessria uma boa receptividade do DSDM por parte da equipa snior de gesto tal como
da restante equipa. Isto assegura que todas as partes envolvidas no projecto ganhem
motivao desde o incio e que permaneam determinadas durante o decorrer do
projecto.
O segundo factor provm directamente do tpico anterior e relaciona-se com o compromisso de gesto que assegura o envolvimento do utilizador. A Prototipagem
necessita de um envolvimento forte e dedicado por parte do utilizador a fim de testar
e julgar o funcionamento do prottipo.
Temos tambm a equipa responsvel pelo projecto. Esta equipa deve ser composta
por uma equipa hbil com o propsito de formar uma unio estvel. Uma questo
relevante prende-se com o facto de ser necessrio dotar a equipa de desenvolvimento
de algum poder. Isto significa que a equipa deve ter a possibilidade de tomar decises
importantes sem necessitar de enviar propostas formais aos elementos mais influentes
ou ao cliente, o que permite uma grande poupana de tempo.
Para que a equipa seja capaz de obter sucesso, tambm necessrio oferecer todas as
condies e tecnologias requeridas para a conduo correcta do projecto.

3.8

Comparao com outras Metodologias de Desenvolvimento

Ao longo dos anos, um grande nmero de mtodos de desenvolvimento de sistemas

de informao vm a ser desenvolvidos e aplicados, dividindo-se em Mtodos Estruturados, Mtodos RAD e Mtodos Orientados-a-Objectos. Muitos destes mtodos
tm grandes semelhanas entre eles, o mesmo acontecendo com a DSDM. Como
exemplo poderemos citar a extreme Programming (XP), que se baseia numa aproximao iterativa ao desenvolvimento de sistemas de informao com uma grande
influncia do utilizador.
O Rational Unified Process ser talvez o mtodo que mais tem em comum com a
DSDM j que se apresenta como uma Metodologia Dinmica de desenvolvimento de
Sistemas de Informao. Mais uma vez utilizada uma aproximao iterativa neste
mtodo de desenvolvimento.
Tal como a XP e a RUP, existem muitos outros mtodos de desenvolvimento que
partilham caractersticas comuns com a DSDM. Apesar disso, esta metodologia distingue-se de todas as outras em diversas vertentes. Em primeiro lugar est o facto de
fornecer um framework independente de ferramentas e de tcnicas, o que possibilita
que a equipa de desenvolvimento utilize as ferramentas s quais se encontra mais
adaptada. Outra particularidade desta metodologia prende-se com o facto do desenvolvimento no girar em torno do tempo/recursos, mas sim das exigncias. Isto assegura o principal objectivo da DSDM, nomeadamente manter todo o projecto dentro
dos limites oramentais e temporais.
Por fim, dada maior importncia comunicao entre todos os elementos da stakeholder do sistema. Embora este ponto seja comum a outras metodologias, a DSDM
acredita verdadeiramente num compromisso que assegura o sucesso final do projecto.

4.

Adequao da DSDM

4.1

Projectos Adequados Utilizao da DSDM

Projectos de Mudana Estes projectos necessitam constantemente de sugestes

dos clientes, conhecer os seus pontos de vista para poder encontrar a melhor maneira
de alcanar os objectivos.
Projectos Criativos Os projectos criativos apelam a sesses de brainstorming.
Estes projectos necessitam de uma forte participao dos clientes e privilegia a modelao e visualizao conforme a motivao dos utilizadores.
Projectos Urgentes Projectos time to market so dos mais conceituados para se
poderem adaptar DSDM. O mtodo das Timeboxes e prioridades de funes levam
entrega do produto hora com as funcionalidades essenciais.

Projectos Ergonmicos Este tipo de projectos exigem uma interface bastante evoluda e adaptada ao homem tornando o papel dos utilizadores e de peritos em factores
humanos, estticos e ergonmicos cruciais.
Projectos Multidisciplinares Os princpios de responsabilidade e cooperao da
DSDM reflectem o seu poder neste tipo de projectos. necessrio efectuar constantemente testes durante todo o projecto com de uma forma colectiva.
Projectos de Novas Tecnologias Estes projectos necessitam de um espao para a
experimentao e privilegiam o retorno das experincias antes de tomar decises
definitivas. necessrio por vezes alterar a estrutura do projecto e com os princpios
da reutilizao e reconfigurao que DSDM oferece, isto torna-se possvel.
Projectos de Desenvolvimento de Produtos A DSDM adaptada para projectos
de desenvolvimento de produtos. Estes projectos tm frequentemente timings apertados. DSDM insiste sobre validaes frequentes adaptadas s necessidades do consumidor.

4.2

Projectos No Adequados Utilizao da DSDM

5.

Clientes no disponveis para efectuar testes.

Culturas muito hierrquicas.
Algoritmos complexos de validar e visualizar.
Sistemas crticos segurana humana.
Arquitectura pouco modular.
Tecnologias que no permitem a Prototipagem
Reversibilidades e gesto de configurao difceis de praticar.
Cargo e responsabilidade dos clientes muito falsa.
Falta de confiana dos clientes.

Concluses

Apesar da utilizao de uma metodologia gil no ser aconselhada para todos os tipos
de projecto, a DSDM uma ptima e segura base para equipas de desenvolvimento
que tm em mos projectos com necessidade de execuo rpida e com requisitos
flexveis. A partir desta metodologia, possvel construir um trabalho que agrade ao
cliente - graas ao cumprimento dos prazos e oramentos - equipa de desenvolvimento que ter em mos um projecto organizado e com obrigao de cumprir apenas os requisitos necessrios execuo do sistema e aos utilizadores finais que
tero a oportunidade de interagir com todo o desenvolvimento do sistema de informao, atravs das frequentes fases de testes.

6.

Bibliografia

[DSDMC, 1997] DSDM Consortium. Delivering Aginle Business Solution on Time.

[Online]. Disponvel em http://www.dsdm.org/ [Consultado em 30/11/05]
[Flowler, 2003] Fowler, Martin. The New Methodology. [Online]. Disponvel em
http://www.martinfowler.com/articles/newMethodology.html [Consultado em
30/11/05]
[HI5, 2005] HI5, Whos in? [Online]. Disponvel em
http://www.hi5.com/default.html [Consultado (pelo Tiago) em 30/11/05]
[Clifton et al., 2003] Clifton, Marc. Dunlap, J., What is DSDM? [Online]. Disponvel
em http://www.codeproject.com/gen/design/dsdm.asp [Consultado em 30/11/05]
[Sollicito, 2003] Sollicito, To DSDM or not to DSDM? [Online]. Disponvel em
http://www.informit.com/articles/article.asp?p=20696&redir=1&rl=1 [Consultado em
30/11/05]
[Wikipedia, 2003] Wikipedia.org, Dynamic Systems Development Methodology
[Online]. Disponvel em http://en.wikipedia.org/wiki/DSDM [Consultado em
30/11/05]
[Morais, 1998] Morais, A., Dicionrio Ingls-Portugues 3 Edio
[Dynamic Ventures, 2004] Dynamyc Ventures Inc., Costum Software Development?
[Online]. Disponvel em www.dyve.com/ dv/methodology.htm [Consultado em
30/11/05]