text:
# Metodologia de desenvolvimento de sistemas dinâmicos
Metodologia de Desenvolvimento de Sistemas Dinâmicos (do inglês Dynamic Systems Development Method - DSDM) é uma metodologia de desenvolvimento de software originalmente baseada em "Desenvolvimento Rápido de Aplicação" (RAD). DSDM é uma metodologia de desenvolvimento iterativo e incremental que enfatiza o envolvimento constante do usuário.
Seu objetivo é entregar softwares no tempo e com custo estimados através do controle e ajuste de requisitos ao longo do desenvolvimento. DSDM é um dos modelos de Metodologia Ágil de desenvolvimento de software, e seu formato é propriedade da Agile Alliance.

## Introdução
Como uma extensão do RAD, o DSDM é aplicado em projetos de Sistemas caracterizados pelos cronogramas e custos limitados. Aponta falhas de informação mais comuns destes projetos, incluindo custos excedentes, perda de prazos, falta de envolvimento de usuários e acompanhamento da alta gerência. Através do uso do RAD, contudo, sem os devidos cuidados com o DSDM pode aumentar ainda mais o risco em outros quesitos. DSDM consiste em:
- 3 fases: pré-projeto, ciclo de vida, e pós-projeto.
- A fase ciclo de vida é subdividida em 5 estágios: análise de viabilidade, análise de negócio, Iteração do Modelo Funcional, iteração de elaboração e construção e, por fim, implantação.

Em alguns casos, é possível integrar práticas de outras metodologias, como do Rational Unified Process (RUP), Programação Extrema (XP) e PRINCE2, como complemento ao DSDM. Outro método ágil que o DSDM possui muita similaridade quanto ao processo e conceitos é o Scrum.
Originado no Reino Unido em  1990 através do DSDM Consortium, uma associação de consultores e experts no ramo de Engenharia de Software criado com o intuito de "unir desenvolvimento e promoção de um framework RAD independente" combinando suas experiências em boas práticas. O DSDM Consortium - organização não governamental e independente detém e administra seu próprio framework DSDM. Sua primeira versão foi concluída em janeiro de 1995 e publicada no mês seguinte. Em julho de 2006 foi disponibilizada a versão 4.2 do DSDM. Em 2014, foi disponibilizado online um handbook do DSDM. Adicionalmente, modelos de DSDM podiam ser baixados. Em outubro de 2016, o Consórcio DSDM criou a marca Consórcio Agile Business.

## Evolução histórica
A DSDM fornece um framework para uma abordagem interativa e incremental de desenvolvimento de Sistemas de Informação (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ª versão. Esta metodologia foi desenvolvida por um consórcio de vendedores e peritos no campo dos Sistemas de Informação, no qual partilharam e combinaram as suas melhores técnicas. Assim, a DSDM surge como uma extensão do RAD (Rapid Application Development), focada em projetos de Sistemas de Informação caracterizados por prazos e orçamentos apertados. A DSDM aborda os problemas que frequentemente ocorrem no desenvolvimento de informação que se prendem essencialmente com a falta de tempo, com orçamentos mais apertados ou com outro tipo de razões para que o projeto falhe, tal como a falta de envolvimento dos encarregados do projeto ou dos utilizadores finais.

## O DSDM

### Princípios
Existem 9 princípios formados por 4 séries e 5 pontos-chave.
- 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.
- 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.
- Eficácia: o critério principal para ser considerado "entregável" é entregar um sistema que demonstre auxiliar nas necessidades e negócio atuais. É mais importante um sistema corresponder às necessidades de negócio do que focar nas funcionalidades.
- Feedback: o desenvolvimento é iterativo e incremental controlado por feedbacks de usuários, a fim de tornar a solução eficaz ao negócio.
- Reversibilidade: todas as alterações feitas no desenvolvimento são reversíveis.
- Previsibilidade: o escopo e requisitos de alto nível devem ser definidos antes que o projeto se inicie.
- Ausência de Testes no escopo: testes são tratados fora do ciclo de vida do projeto. (Veja Desenvolvimento orientado a testes para uma comparação).
- Comunicação: é necessária excelente comunicação e cooperação de todos os envolvidos para obter maior eficácia e eficiência no projeto.

### Considerações adicionais
- Prioridades: nenhum sistema é construído perfeitamente logo de início. (confira Princípio de Pareto ou regra 80/20). Em geral, 80% do resultado final são oriundos de 20% dos requisitos, por esta razão o DSDM inicia pela implementação bem sucedida destes 20% críticos; desta forma pode produzir um sistema que ofereça funcionalidades suficientes para satisfazer usuários finais e os 80% restantes podem ser distribuídos nas demais iterações, além de reduzir o risco do projeto ultrapassar seus limites de prazo e orçamento.
- Tripé de qualidade: a entrega do projeto deve ser feita a tempo, custo e de ser de boa qualidade.
- Interseções: cada passo do desenvolvimento deve estar completo apenas o suficiente para que se inicie o próximo passo. Isto permite que a nova iteração seja iniciada sem atrasos desnecessários.
- Maleabilidade: alterações no design podem coincidir com alterações na demanda de usuários finais, uma vez que cada iteração do sistema é aprimorada de forma incremental.
- Gerenciamento: técnicas de Gerência de Projeto e Desenvolvimento de Sistemas são incorporadas.
- Híbrido: DSDM pode ser aplicado tanto em novos projetos quanto em aprimoramento de sistemas já existentes.
- Objetividade: a gerência de risco deve focar nas funcionalidades a serem entregues, não no processo de desenvolvimento e nem em artefatos (como requisitos e criação de documentos).
- Foco na entrega: gerenciamento valoriza muito mais entrega do produto que tarefa cumprida.
- Funcionalidade: estimativa deve se basear na funcionalidade de negócios em vez de em linhas de código.

### Prérequisitospara utilizar o DSDM
Para obter sucesso com o DSDM, um número de pré-requisitos deve ser alcançado. Inicialmente, deve haver interação entre o time do projeto, futuros usuários e o alto-escalão. Isto permite identificar futuras falhas no sistema acarretadas pela falta de acompanhamento da gerência ou envolvimento de usuário. O segundo requisito para um projeto DSDM é que ele possa ser fracionado em pequenas partes permitindo um maior detalhamento em cada iteração.
Exemplos de projetos que o DSDM não é uma boa indicação:
- Projetos de segurança crítica - Os testes e validações extensos destes projetos conflitam com os objetivos de custo e prazo do DSDM.

- Projetos baseados na reutilização de componentes - A necessidade de perfeição nestes casos é muito alta e conflitam com o  princípio 80-20 descritos anteriormente.

## Fases do Projeto DSDM
O framework DSDM consiste de 3 fases sequenciais, nomeadas de pré-projeto, ciclo de vida e pós-projeto. O ciclo de vida é a fase mais elaborada das 3. Consiste em 4 estágios que formam o passo-a-passo das iterações aplicadas ao desenvolvimento do sistema. Estas 3 fases e seus respectivos estágios serão abrangidos nas seções subsequentes, veja abaixo as atividades principais de cada fase/etapa:
Fase 1 - O Pré-ProjetoNo pré-projeto são identificados os projetos candidatos, são definidos orçamento e assinatura do contrato. Controlando estes critérios antecipadamente pode-se evitar problemas futuros e em estágios mais críticos.
Fase 2 - O Ciclo de VidaAnálise de viabilidade e negócios são fases sequenciais que se completam entre si. Após a conclusão destas fases, o sistema é desenvolvido iterativamente e incrementalmente segundo as iterações do Modelo Funcional, desenho e construção, até à implementação. A iteração e natureza incremental do DSDM serão citadas mais a frente.
Fase 3 - Pós-projetoEsta fase garante a eficiência e eficácia do projeto. Através de manutenções, melhorias e ajustes de acordo com os princípios do DSDM. A manutenção pode ser vista como um contínuo desenvolvimento. Invés de finalizar o ciclo de vida de apenas 1 vez, normalmente o projeto pode retomar fases/etapas anteriores a fim de refinar ainda mais o passo concluído.
Abaixo encontra-se o diagrama de processo de todo o ciclo de vida (4 etapas).Isto ilustra a iteração de desenvolvimento, iniciando no Modelo funcional, passando pelo desenho, construção até chegar à implantação. A explicação de cada fase será descrita mais a frente neste tópico.

### Os 4 estágios do ciclo de vida
| Atividade                        | Sub-atividade                      | Descrição                                                                                |
| -------------------------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Análise                          | Análise de Viabilidade             | Estágio onde a utilização do DSDM é avaliada. Analisando o tipo de projeto, problemas organizacionais e de pessoas, é tomada a decisão de se utilizar ou não o DSDM. Por esta razão são gerados artefatos de RELATÓRIO DE VIABILIDADE, PROTÓTIPO DE VIABILIDADE, e um PLANO DE DETALHAMENTO GLOBAL que inclui o PLANO DE DESENVOLVIMENTO e CONTROLE DE RISCO.          |
| Análise                          | Análise de Negócio                 | Onde são analisadas características essenciais do negócio e tecnologias a serem empregadas. Capacidade de se montar grupos de trabalho, onde existam clientes experts suficientes para fornecer maiores peculiaridades do sistema e concordarem com as prioridades de desenvolvimento.                                                                                |
| Iteração do Modelo Funcional     | Identificar o Protótipo Funcional  | Determinar as funcionalidades que serão implementadas é o resultado desta iteração. Neste sub-estágio, um MODELO FUNCIONAL é desenvolvido de acordo com o resultado com o artefato resultante do estágio de Análise do negócio.                                                                                |
| Iteração do Modelo Funcional     | Agenda                             | Definir quando e como as funcionalidades serão implantadas.                                                                                |
| Iteração do Modelo Funcional     | Criação do Protótipo Funcional     | Desenvolver um PROTÓTIPO FUNCIONAL, de acordo com a Agenda e o MODELO FUNCIONAL.                                                                                |
| Iteração do Modelo Funcional     | Revisão do Protótipo Funcional     | Efetuar correções do protótipo desenvolvido. Isto pode ser feito através de testes dos usuários finais ou por análise da documentação. O artefato gerado aqui é o DOCUMENTO DE REVISÃO DO PROTÓTIPO FUNCIONAL.                                                                                |
| Iteração de Desenho e Construção | Identificar o modelo do Desenho    | Identificar requisitos funcionais e não-funcionais que devem estar no sistema testado. Baseado nestas identificações, uma ESTRATÉGIA DE IMPLANTAÇÃO é gerada e caso haja EVIDÊNCIAS DE TESTE de iterações anteriores, estas serão utilizadas para criação desta estratégia.                                                                                |
| Iteração de Desenho e Construção | Agenda                             | Como e quando serão realizados estes requisitos.                                                                                |
| Iteração de Desenho e Construção | Criação do Protótipo do Desenho    | Criar um sistema (PROTÓTIPO) que pode tranquilamente ser manipulado pelos usuários finais no uso diário, também para razões de teste.                                                                                |
| Iteração de Desenho e Construção | Revisão do Protótipo               | Efetuar correções no sistema desenhado. Novamente testando e revisando através das técnicas mais utilizadas. Uma DOCUMENTAÇÃO PARA USUÁRIO e EVIDÊNCIA DE TESTE serão gerados.                                                                                |
| Implantação                      | Orientações e Aprovação do usuário | Usuários finais aprovam o sistema testado (APPROVAL) pela implantação e orientação fornecida pelo respectivo sistema criado.                                                                                |
| Implantação                      | Treinamento                        | Treinar futuros usuários finais no uso do sistema. USUÁRIOS TREINADOS é o artefato entregue neste sub-estágio.                                                                                |
| Implantação                      | Implantação                        | Implantar o sistema testado e liberar aos usuários finais, chamado SISTEMA ENTREGUE.                                                                                |
| Implantação                      | Revisão de Negócio                 | Rever o impacto que o sistema implantado causa sobre o negócio, pode-se utilizar o cruzamento dos objetivos iniciais com a análise atual como termômetro. Dependendo do resultado o projeto passa para o próximo estágio ou reinicia este estágio a fim de refinar e melhorar os resultados. Esta revisão será documentada através do DOCUMENTO DE REVISÃO DO PROJETO. |

### Os 4 estágios do ciclo de vida do projeto

#### Estágio 1A: Análise de Viabilidade
Durante este estágio do projeto, a viabilidade de uso do DSDM é examinada. Pré-requisitos para o uso do DSDM são avaliados respondendo-se algumas questões como: ‘Pode este projeto atender as necessidades do negócio?’, ‘Este projeto é próprio para o DSDM?’ e ‘Quais os riscos mais importantes que estão envolvidos?’. A técnica fundamental desta fase é a utilização dos Grupos de trabalho.
Os artefatos para este estágio são Relatório de viabilidade e Protótipo da Viabilidade. São estendidos até o Planejamento de Definições Gerais até o resto do projeto, e além deste um controle de Risco identifica os riscos mais impactantes do projeto.
Essa análise não deve passar de algumas semanas; duas ou três são consideradas tempo suficiente para deliberar sobre a viabilidade. como produto final, são criados um relatório de viabilidade e um plano geral de desenvolvimento.
Análise de negócio
Oriundo da Análise de Viabilidade. Após o projeto ser deferido viável para o uso do DSDM, este estágio examina a influência dos processos do negócio, usuários envolvidos e seus respectivos desejos e necessidades. Novamente os Grupos de Trabalho são uma das mais valiosas técnicas, Grupos de Trabalho juntam diferentes envolvidos para discutir o propósito do sistema. A informação gerada nestas sessões é combinada com a lista de requisitos. Uma propriedade importante da lista de requisitos é o fato dos requisitos estarem (ou poderem) ser priorizados. Geralmente este requisitos são priorizados segundo o método de MoSCoW. Baseados nestas prioridades, o plano de desenvolvimento é construído como base para o resto do projeto.
Uma técnica importante utilizada no desenvolvimento do plano é a Timeboxing. Esta técnica é essencial para alcançar os objetivos do DSDM, baseados e custo e prazo, garantindo a qualidade desejada. A Arquitetura do Sistema é outro documento fundamental no auxilio do sistema. Os artefatos para este estágio são definições que relatam o contexto do projeto dentro da companhia. A Arquitetura do Sistema, fornece a arquitetura global inicial do Sistema em desenvolvimento junto com um plano de desenvolvimento que destaca os pontos mais importantes num processo de desenvolvimento. Na base destes 2 documentos encontra-se a lista de priorização de requisitos. O que define todos os requisitos do sistemas. E por último, o controle de Risco é atualizado com os fatos que forem identificados durante esta fase do DSDM.

#### Estágio 2: Iteração do Modelo Funcional
Os requisitos identificados nos estágios anteriores serão convertidos em modelos funcionais. Este modelo consiste tanto do funcionamento do protótipo quanto do modelo. Prototipar é uma saída para técnicas de projeto em que neste estágio auxilia num verdadeiro envolvimento do usuário no projeto.
O protótipo desenvolvido é revisado por diferentes grupos. De forma a garantir qualidade, os testes são efetuados ao longo de cada iteração. Uma parte importante do teste é realizada na Iteração do Modelo Funcional. O Modelo Funcional pode ser dividido em 4 sub-estágios:
- Identificação do protótipo funcional: determina funcionalidades a serem implementadas resultantes desta iteração.
- Agenda: concilia como e quando serão feitas estas funcionalidades.
- Criação do protótipo funcional: desenvolver o protótipo. Investigar, refinar e consolidar com os protótipos funcionais das iterações anteriores.
- Revisão do protótipo: efetuar correções no desenvolvimento do projeto. Isto pode ser feito através de testes de usuários, através destas evidências e feedbacks dos usuários é gerado o documento de revisão do Protótipo.

Os artefatos desta etapa são Modelo Funcional e Protótipo Funcional os quais juntos representam as funcionalidades que serão trabalhadas nesta iteração, prontas para serem testadas por usuários. Depois disso, a lista de requisitos é atualizada, removendo-se os itens entregues e refazendo a lista de prioridades dos requisitos remanescentes. Além disso o Log de Riscos também é atualizado por uma análise de riscos do conteúdo desenvolvido após a revisão do documento da prototipação.

#### Estágio 3: iteração de desenho e construção
O maior intuito desta Iteração do DSDM é integrar os componentes funcionais de fases anteriores em um sistema que satisfaça as necessidades do usuário. Ele também controla os requisitos não funcionais que foram definidos para o Sistema. Novamente Testes vem a ser uma atividade fundamental no andamento deste estágio. A iteração de Desenho e Construção também pode ser dividida em 4 sub-estágios:
- Definir desenho do protótipo: Identificar requisitos funcionais e não funcionais que precisam ser testados no sistema.
- Agenda: Definir quando e como serão realizados estes requisitos.
- Criação do desenho do protótipo: criar um sistema que possa ser seguramente manipulado por um usuário no uso diário. Investigar, refinar e consolidar o protótipo da iteração atual dentro do processo de prototipação é um ponto essencial.
- Revisar o protótipo desenhado: efetuar ajustes no desenho do sistema, novamente testando e revisando com as principais técnicas já utilizadas, uma vez que os feedbacks dos usuários e as evidências de teste são necessárias para geração da documentação do usuário.

Os artefatos a serem entregues neste estágio são Desenho do Protótipo que os usuários testaram e ao final desta Iteração o sistema testado é transferido para a próxima fase. Neste estágio, o sistema é construído exatamente de acordo com o desenho e funções consolidadas e integradas no protótipo. Outro artefato desta iteração é a Documentação de Usuário.

#### Estágio 4: implantação
Na fase de Implantação, o sistema testado e mais a documentação de usuário é entregue aos usuários e treinos à estes futuros usuários são aplicados. O sistema para ser entregue deve ter seus requisitos revisados de acordo com o que foi definido nas etapas iniciais do projeto. O estágio de implantação é dividido em 4 sub-estágios:
- Orientações e aprovação do usuário: usuários aprovam o sistema testado e algumas orientações de uso e implantação do sistema são definidas.
- Treinamento: treinamento de futuros usuários no uso do sistema.
- Implantação: implantar propriamente o sistema concluído na localidade dos usuários.
- Revisão de Negócios: rever o impacto que o sistema implantado causa sobre o negócio, pode-se utilizar o cruzamento dos objetivos iniciais com a análise atual como termômetro. Dependendo do resultado o projeto passa para o próximo estágio ou reinicia este estágio a fim de refinar e melhorar os resultados. Esta revisão será documentada através do DOCUMENTO DE REVISÃO DO PROJETO.

Os artefatos deste estágio consistem em Entrega do Sistema no Local, pronto para utilização dos usuários finais, Treinamento de usuários e Documento de Revisão do Projeto do sistema entregue.

## Iteração do Modelo Funcional DSDM

### Modelo de metadados
As associações entre os conceitos das entregas e o estágio de iteração do Modelo Funcional são ilustrados no modelo de Metadados abaixo. Este modelo irá combinar com o diagrama de meta-processos da fase de Iteração do Modelo Funcional na próxima parte.
| Conceito                                       | Definição                                                                                |
| ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| CONTROLE DE RISCO                              | Log dos riscos identificados. Importante desde que perdure na próxima etapa, um problema encontrado será mais difícil de se tratar. O log de risco deverá ser atualizado continuamente. (VTT Publication 478)                                                         |
| LISTA DE PRIORIZAÇÃO DE REQUISITOS             | Lista de requisitos baseadas em suas prioridades. O processo de priorização é baseado no modelo MoSCoW, para determinar quais requisitos devem ser implementados primeiro no sistema (que coincidam com as necessidades do sistema).                                  |
| LISTA DE REQUISITOS NÃO-FUNCIONAIS             | Listagem dos requisitos que serão tratados em estágios seguintes. (VTT Publication 478)                                                                                |
| REQUISITOS FUNCIONAIS                          | Função utilizada para construir o modelo e protótipo de acordo com suas prioridades.                                                                                |
| MODELO FUNCIONAL                               | Modelo baseado em requisitos funcionais. Será utilizado de acordo com o desenvolvimento do protótipo Funcional. Este conceito será utilizado para desenvolver o PLANO DE PROTOTIPAGEM.                                                                                |
| PROTOTIPAGEM                                   | Processo de unir rapidamente uma forma de trabalho (um protótipo) de forma a testar vários aspectos de design, ilustrar idéias e funcionalidades conseguindo antecipadamente identificar a reação do usuário.                                                         |
| DIVISÃO DE TEMPO                               | Lista de tempo necessário para certas atividades a fim de executar o planejamento de acordo com a agenda.                                                                                |
| PLANO DE PROTOTIPAGEM                          | Plano de atividades dentro de um processo de prototipagem que será utilizado em períodos de tempo disponíveis de acordo co a agenda.                                                                                |
| AGENDA                                         | Definição do plano de atividades e tempo necessário acordados entre os desenvolvedores. Este conceito será utilizado para suportar a implantação do PROTÓTIPO FUNCIONAL.                                                                                |
| PROTÓTIPO FUNCIONAL                            | Um protótipo de funções que o sistema deve executar e como deve ser feito.                                                                                |
| PLANO DE IMPLANTAÇÃO                           | Preparação de atividades necessárias à implantação do protótipo funcional de acordo com a agenda e lista priorizada de requisitos.                                                                                |
| FUNCÃO REFINADA                                | Função do protótipo que está sendo revisada na iteração atual antes de ser combinada e testada com as demais.                                                                                |
| FUNÇÃO COMBINADA                               | Função do protótipo que é combinada com outros protótipos funcionais de iterações anteriores. A nova combinação funcional do protótipo será testada no próximo estágio.                                                                                |
| REGISTRO DE TESTE                              | Conjunto de evidências de teste onde o script, procedimento, e resultados dos testes são incluídos. Este registro é utilizado no desenvolvimento do DOCUMENTO DE REVISÃO DE PROTOTIPAGEM FUNCIONAL, além de indiretamente atualizar a LISTA PRIORIZADA DE REQUISITOS. |
| DOCUMENTO DE REVISÃO DE PROTOTIPAGEM FUNCIONAL | Coleta comentários gerais de usuários sobre o incremento atual, trabalhando como uma entrada para as iterações subsequentes (VTT Publication 478). Este documento de revisão será utilizado para atualizar o CONTROLE DE RISCO e LISTA DE PRIORIZAÇÃO DE REQUISITOS.  |

### Modelo de processo
A atividade de identificar o protótipo funcional é identificar funcionalidade que podem estar no protótipo da iteração corrente. Lembrando que, análise e código foram feitos; protótipo são construídos, e experiências adquiridas com eles são utilizadas para aprimorar a análise de modelos (baseado também na atualização da lista priorizada de requisitos e controle de risco). A construção de protótipo não pode ser descartada por inteiro, mas gradualmente transformada na qualidade que será aplicada no final do produto final. A Agenda determina quando e como a prototipação será implantada; isto oferece um escopo para avaliação de tempo hábil e plano de prototipagem. Uma vez que testes são feitos ao longo de todo o processo, Isto também se torna parte essencial desta fase, por esta razão é incluída na atividade de revisão de protótipo logo após o protótipo funcional é construído, e este registro de teste será eventualmente utilizado no processo de revisão do protótipo e gerar o documento de revisão. Abaixo o diagrama do processo da Iteração do Modelo Funcional.
| Atividade                         | Sub-atividade                       | Descrição                                                                                |
| --------------------------------- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Identificar o Protótipo Funcional | Análise de Requisitos               | Os requisitos do protótipo atual são analisados de acordo com a lista priorizada de requisitos criada anteriormente (iteração anterior e/ou na fase anterior - Análise de negócio).                                                                                |
| Identificar o Protótipo Funcional | Listar Requisitos da Iteração atual | Seleciona os requisitos funcionais que serão implementados na iteração do protótipo atual, e as lista como REQUISITOS FUNCIONAIS.                                                                                |
| Identificar o Protótipo Funcional | Listar requisitos não funcionais    | Incluir na LISTA DE REQUISITOS NÃO-FUNCIONAIS os requisitos identificados como sendo não-funcionais.                                                                                |
| Identificar o Protótipo Funcional | Criar um Modelo Funcional           | Analisar modelo e protótipo de código estão incluídos nesta sub-atividade para desenvolver o MODELO FUNCIONAL.                                                                                |
| Agenda                            | Determinar o tempo                  | Identificar possíveis disponibilidades (períodos) para executar atividades de prototipação de acordo com plano e estratégia de prototipagem.                                                                                |
| Agenda                            | Definir Desenvolvimento             | O PLANO DE PROTOTIPAGEM, incluindo todas as atividades de prototipagem serão executados no tempo disponível.                                                                                |
| Agenda                            | Agenda                              | Concordância de quando e como as atividades de prototipagem serão executadas.                                                                                |
| Criar Protótipo Funcional         | Investigar                          | Investigar requisitos; análise do MODELO FUNCIONAL que foi criado anteriormente, e definir um PLANO DE IMPLANTAÇÃO de acordo com o modelo de análise, será utilizado para construir o protótipo na próxima sub-atividade.                                                                                |
| Criar Protótipo Funcional         | Refinar                             | Implementar o MODELO FUNCIONAL e PLANO DE IMPLANTAÇÃO para construir o PROTÓTIPO FUNCIONAL. Este protótipo será refinado antes de ser combinado com outras funções. Este protótipo será gradualmente movido para qualidade a qual poderá estar incluída até a versão final (através do processo de refinamento).                                    |
| Criar Protótipo Funcional         | Consolidação                        | Consolidar o PROTÓTIPO FUNCIONAL refinado com o protótipo das iterações anteriores. A nova combinação PROTÓTIPO FUNCIONAL será testada na atividade a seguir.                                                                                |
| Revisar protótipo                 | Testar protótipo                    | Parte essencial do DSDM que deve estar inclusa ao longo de todo o processo. O REGISTRO DE TESTE será utilizado junto aos comentários de usuários para desenvolver DOCUMENTO DE REVISÃO DE PROTOTIPAGEM na próxima atividade da fase da Iteração do Modelo Funcional.                                                                                |
| Revisar protótipo                 | Revisar Protótipo                   | Coletar comentários de usuários e documentação. Evidências de teste irão gerar regras importantes ao desenvolvimento deste relatório de revisão. Baseado neste DOCUMENTO DE REVISÃO DE PROTOTIPAGEM, a lista de requisitos priorizados e controle de risco serão atualizados, então será decidido se devem ser mantidos na próxima iteração ou não. |

## Outros tópicos DSDM

### Centrode Técnicas do DSDM
- Timeboxing Timeboxing é uma das técnicas de projeto do DSDM. Utilizada no suporte aos objetivos principais para realização do desenvolvimento do sistema no prazo estimado, além de manter o custo e qualidade desejados. A principal ideia por trás do timeboxing é a divisão do projeto em porções, cada um com um orçamento e prazo estimados. Para cada porção um número de requisitos são selecionados e priorizados de acordo com o princípio de MoSCoW. Devido ao tempo e custo serem fixos, as variáveis remanescentes são os requisitos. Desta forma se o prazo ou o custo está se esgotando requisitos de baixa prioridade são omitidos. Não significa que o produto ficará inacabado ou será entregue pela metade, pois de acordo com o Princípio de Pareto, onde 80% do projeto vem de 20% dos requisitos do sistema, assim uma vez que os 20% dos requisitos mais importantes forem implementados no sistema será possível atender as necessidades do negócio além do que nenhum sistema é construído em sua total perfeição logo de início.
- MoSCoW MoSCoW Representa a forma de priorização de itens. No contexto do DSDM o método MoSCoW é utilizado para priorizar requisitos. o acrônimo MoSCoW se refere à:

MUST: requisitos que DEVEM estar de acordo com as necessidades do negócio.
SHOULD: requisitos que devem ser considerados ao máximo, mas que não impactam no sucesso do projeto.
COULD: incluir este requisito caso não afete o tamanho das necessidades de negócio do projeto.
WOULD: Incluir este requisito no caso de futuramente existir tempo sobrando (ou em futuros desenvolvimentos).
- Prototipagem Se refere à criação de protótipos do sistema em desenvolvimento em estágios iniciais do projeto. Isto permite descobrir rapidamente falhas no sistema e permitir um ‘test-drive’ aos usuários do sistema, o que vem a ser uma ótima maneira de se realizar o envolvimento do usuário, um dos fatores chave do DSDM.
- Testes Um terceiro aspecto importante do DSDM é a criação de um sistema de boa qualidade. Para alcançar este quesito, DSDM aplica testes ao longo de cada iteração. Considerando que o DSDM é um método e ferramenta independente, o time de projeto é livre para escolher por conta própria o Método de gerenciamento de teste, por exemplo .
- Grupos de Trabalho Uma das técnicas do DSDM que objetiva e permite que diferentes envolvidos discutam juntos requisitos, funcionalidades e entendimento mútuo. Num grupo de trabalho os envolvidos se unem a discutir apenas sobre o projeto.
- Modelagem Esta técnica é essencial e propositalmente utilizada para visualizar uma representação gráfica de aspectos específicos do sistema ou área de negócio que será trabalhado. Modelagem permite um melhor entendimento para o time do projeto do DSDM que está fora do domínio do negócio.
- Gerenciamento de Configuração Uma boa implantação da técnica de Gerenciamento de Configuração o dinamismo natural do DSDM. Uma vez que exista mais de uma coisa para controlar ao mesmo tempo durante o processo de desenvolvimento do sistema, e os produtos são entregues frequentemente  num tempo muito rápido, os produtos por esta razão tem de ser estritamente controlados se foram completamente concluídos.

### Papéisdo DSDM
Existem alguns papéis aplicados junto ao ambiente DSDM. É interessante que seja definido previamente os papéis que cada membro do projeto irá representar antes de se iniciar as atividades. Cada papel tem sua própria responsabilidade. São eles:
- Gerente executivo: também chamado de “Campeão do Projeto”. Papel importante para usuários os quais possuem habilidades e responsabilidades em cumprir determinados prazos e recursos. Este papel é a ultima palavra na tomada de decisões.
- Visionário: aquele que tem a responsabilidade de iniciar projeto certificando que os requisitos essenciais foram definidos. O visionário tem a percepção acurada dos objetivos de negócio do sistema e projeto. Outra tarefa é supervisionar e manter o desenvolvimento do processo "na linha".
- Intermediador: usuário que traz o conhecimento de outras áreas para o projeto, certifica que os desenvolvedores receberam quantidade suficiente de feedback de usuários durante o processo de desenvolvimento.
- Anunciante: qualquer usuário que represente um importante ponto de vista e traga diariamente conhecimento ao projeto.
- Gerente de projeto: pode ser qualquer do grupo de usuários ou Gerencia de TI que gerenciará o projeto como um todo.
- Coordenador Técnico: responsável no desenho da arquitetura do Sistema e controle da qualidade técnica do projeto.
- Líder de time: lidera seu time e mantém a harmonia do projeto e trabalho em grupo.
- Desenvolvedor: interpreta o modelo e requisitos do sistema incluindo desenvolvimento de artefatos de código e construção de protótipos.
- Testador: Confere o funcionamento da parte técnica através da execução de algumas tarefas. O Testador deverá possuir alguns comentários e documentação.
- Escrivão: Responsável por recolher e armazenar requisitos, acordos e decisões tomadas entre todos os grupos de trabalho.
- Facilitador: Gerencia progresso dos grupos de trabalho, age como motor de preparação e comunicação.
- Papéis específicos: Arquiteto de negócios, Gestor de Qualidade, Integrador de Sistema, etc.

### Iteratividadee natureza Incremental
Após o timeboxing e priorização de requisitos, O DSDM oferece também uma forma de Desenvolvimento Incremental e Iterativo ao sistema. Isto pode ser visto na ilustração exibida no Modelo do Processo.
Os estágios das Iterações do Modelo Funcional, Desenho, construção e Implantação podem percorrer seus sub-estágios inúmeras vezes antes de passar para o próximo passo. Cada iteração inclui uma lista de funcionalidades, e toda iteração é construída baseada no seu predecessor. Se necessário cada iteração também pode ser desfeita.
A ilustração do resumo do processo mostra também setas retornando à estágios anteriores. Por exemplo, a ligação Implantação x Análise de Negócio. Caso uma grande funcionalidade foi descoberta durante o desenvolvimento e não pôde ser implementada, é possível reiniciar definindo novos requisitos no estudo de caso. Da mesma forma, há uma ligação entre Implantação e Iteração do Modelo Funcional. Funcionalidades podem ser omitidas durante o Modelo Funcional anterior devido a limites de tempo ou custo. O projeto deve ir à fase de Pós-projeto somente após reconhecer que todos os requisitos definidos no escopo foram entregues.
Devido a natureza Iterativa do DSDM, é essencial efetuar um ótimo trabalho no levantamento de requisitos e Gerência de Configuração durante todo o projeto. Isto garante que os projetos definidos anteriormente foram implantados na fases anteriores do projeto.

### Metamodelo (Metamodelagem)
Metamodelagem define em alto nível métodos e técnicas. Permitindo que sejam comparados métodos, técnicas e Engenharias similares existentes aos novos.
O Modelo de metadados, representado abaixo: demonstra os conceitos e associações entre estes conceitos do DSDM. Como pode ser visto, pode-se identificar 2 conceitos principais, Fase e Fluxo. Cada Fluxo se origina de uma Fase dentro do DSDM. Os Fluxos podem ser divididos em sub-conceitos Dados e Produto. Esta subdivisão é denotada por um C, que significa que a subdivisão foi separada e concluída. Em outras palavras, Fluxo será sempre Fluxo de dados ou Fluxo do produto, jamais ambos. No caso do DSDM Fluxo de Dados pode ser um ponto de retorno à fases anteriores. Fluxo de produtos são formas tangíveis que resultam de Fases e serão incluídos na próxima Fase, por exemplo protótipos e relatórios.
Há ainda um segundo conceito de Fase que também pode ser dividido em 2 subconceitos com a ordem de separar e completar. São eles Sequencial e Fases Iterativas. Conforme descrito em seção anterior, o DSDM inicia com 2 fases sequenciais, Análise de Viabilidade e então do Negócio. Após um número de fases iterativas, ex: Modelo Funcional, Desenho, construção e implantação.
A figura mostra também um numero de regras e problemas que não estão incluídos no modelo, mas são importantes para o Metamodelo. Primeiro as regras que controlam o comportamento dos Fluxos, restringindo a liberdade do fluxo, o que corresponde às transições de Fases dentro do DSDM. Junto às regras um numero de importantes critérios são utilizados para garantir o ciclo de vida do projeto.

## Fatores críticos de sucesso do DSDM
No DSDM uma série de fatores são identificados como sendo de grande importância para garantir o sucesso do projeto.
- Fator 1: Inicialmente há a aceitação do DSDM pelo gerente Senior e outros colaboradores. Isto garante que diferentes atores do projeto sejam motivados pelo início e demais envolvidos no projeto.

- Fator 2: O segundo fator segue diretamente daqui e é o que a gerência de empenho garante como envolvimento do usuário final. A prototipagem requer um forte e dedicado envolvimento do usuário em testar e avalizar os protótipos funcionais.

- Fator 3: Aqui se encontra o time do projeto. Este time deve ser composto por membros capacitados, um ponto importante é o empenho deste time. Significa que o time (um ou mais membros) possuem poder e permissões de tomar decisões importantes com relação ao projeto sem a necessidade de se formalizar propostas à alta gerência, o que seria um grande consumidor de tempo. De forma ao time estar apto a concluir um projeto com sucesso, é necessário também a escolha adequada da tecnologia. O que se refere ao ambiente de desenvolvimento, ferramentas de gerenciamento de projeto, etc.

- Fator 4: Finalmente o DSDM define um relacionamento de suporte necessário entre o cliente e fornecedor. Isto vale para projetos que estão sendo realizados dentro da empresa ou por fornecedores. O documento que relata este suporte de relacionamento vem a ser o  ISPL.

## Comparação com outros tipos de desenvolvimento de software
Durante anos um grande número de métodos de desenvolvimento de sistemas tem sido desenvolvidos e aplicados, divididos em Métodos estruturados, métodos RAD e Métodos orientado a objetos. Muitos destes métodos demonstram similaridades um com outro e também com o DSDM. Por exemplo Programação Extrema(XP) também possui um formato iterativo ao desenvolvimento baseado com envolvimento do usuário.
O Rational Unified Process (RUP) é provavelmente o método mais similar ao DSDM assim é também o formato mais dinâmico de desenvolvimento de sistema de informação. Novamente o formato iterativo é utilizado neste método de desenvolvimento.
Como o XP e o RUP existem muitos outros métodos de desenvolvimento que demonstram similaridades com o DSDM, mas DSDM se diferencia por si só pelo número de caminhos que pode adotar. Primeiro temos um fato que produz uma ferramenta e um framework técnico independente. Isto permite usuários preencherem etapas específicas do processo om suas próprias técnicas e escolhas de documentação de software. Outra funcionalidade exclusiva é o fato de que variáveis no desenvolvimento não são considerados recursos ou tempo, mas requisitos. Assim garantimos os pontos principais do DSDM, marcados para se manterem no custo e prazo definidos. E por último o forte foco na comunicação entre e no envolvimento de todos responsáveis pelo sistema. Contudo isso é encontrado em outros métodos, DSDM acredita fortemente no comprometimento do projeto para garantir o sucesso do projeto.

## Outras Leituras
- Coleman and Verbruggen: A quality software process for rapid application development, Software Quality Journal 7, p. 107-1222 (1998)
- Beynon-Davies and Williams: The diffusion of information systems development methods, Journal of Strategic Information Systems 12 p. 29-46 (2003)
- Sjaak Brinkkemper, Saeki and Harmsen: Assembly Techniques for Method Engineering, Advanced Information Systems Engineering, Proceedings of CaiSE'98, Springer Verlag (1998)
- Abrahamsson, Salo, Ronkainen, Warsta Agile Software Development Methods: Review and Analysis, VTT Publications 478, p. 61-68 (2002)
- Tuffs, Stapleton, West, Eason: Inter-operability of DSDM with the Rational Unified Process, DSDM Consortium, Issue 1, p. 1-29 (1999)
- Rietmann: DSDM in a bird’s eye view, DSDM Consortium, p. 3-8 (2001)
- iSDLC integrated Systems Development Life Cycle

wikitext:
{{Mais notas|data=outubro de 2020}}
[[Image:DSDM Development Process.svg|thumb|320px|Modelo do processo DSDM de Desenvolvimento de Software]]

'''Metodologia de Desenvolvimento de Sistemas Dinâmicos''' (do [[Língua inglesa|inglês]] ''Dynamic Systems Development Method - DSDM'') é uma [[Metodologia (engenharia de software)|metodologia]] de [[desenvolvimento de software]] originalmente baseada em "Desenvolvimento Rápido de Aplicação" ([[Rapid Application Development|RAD]]). DSDM é uma metodologia de [[desenvolvimento iterativo e incremental]] que enfatiza o envolvimento constante do usuário.

Seu objetivo é entregar [[software]]s no tempo e com custo estimados através do controle e ajuste de requisitos ao longo do desenvolvimento. DSDM é um dos modelos de [[Desenvolvimento ágil de software|Metodologia Ágil]] de desenvolvimento de software, e seu formato é propriedade da ''Agile Alliance''.

== Introdução ==
Como uma extensão do [[Rapid Application Development|RAD]], o DSDM é aplicado em projetos de [[Sistemas]] caracterizados pelos cronogramas e custos limitados. Aponta falhas de informação mais comuns destes projetos, incluindo custos excedentes, perda de prazos, falta de envolvimento de usuários e acompanhamento da alta gerência. Através do uso do RAD, contudo, sem os devidos cuidados com o DSDM pode aumentar ainda mais o risco em outros quesitos. DSDM consiste em:
* 3 [[#fases|fases]]: pré-projeto, ciclo de vida, e pós-projeto.
* A fase ciclo de vida é subdividida em 5 estágios: análise de viabilidade, análise de negócio, Iteração do [[Modelo Funcional]], iteração de elaboração e construção e, por fim, implantação.

Em alguns casos, é possível integrar práticas de outras metodologias, como do [[IBM Rational Unified Process|Rational Unified Process (RUP)]], [[Programação Extrema|Programação Extrema (XP)]] e [[PRINCE2]], como complemento ao DSDM. Outro método ágil que o DSDM possui muita similaridade quanto ao processo e conceitos é o [[Scrum]].

Originado no Reino Unido em  1990 através do DSDM Consortium, uma associação de consultores e experts no ramo de [[Engenharia de Software]] criado com o intuito de "unir desenvolvimento e promoção de um [[framework]] RAD independente" combinando suas experiências em boas práticas. O DSDM Consortium - [[organização não governamental]] e independente detém e administra seu próprio framework DSDM. Sua primeira versão foi concluída em janeiro de 1995 e publicada no mês seguinte. Em julho de 2006 foi disponibilizada a versão 4.2 do DSDM.<ref>{{citar web|url= https://www.agilebusiness.org/page/whatisdsdm |título= What is DSDM?})</ref> Em 2014, foi disponibilizado ''online'' um ''handbook'' do DSDM.<ref name="auto">{{Citar web|url=https://www.agilebusiness.org/resources/dsdm-handbooks/the-dsdm-agile-project-framework-2014-onwards|título=The DSDM Agile Project Framework (2014 Onwards)|data=4/2/2014|publicado=Agile Business Consortium|wayb= 20170729234649|urlmorta= sim}}</ref> Adicionalmente, modelos de DSDM podiam ser baixados.<ref>{{citar web|url=https://www.agilebusiness.org/resources/templates-and-tools/atern-template-complete-set|título=
Atern Template: Complete Set|wayb= 20171107003919|urlmorta= sim}}</ref> Em outubro de 2016, o Consórcio DSDM criou a marca ''Consórcio Agile Business''.<ref>{{citar web|título=Agile's DSDM Consortium evolves into Agile Business Consortium|url=https://pressdispensary.co.uk/releases/c994112/Agiles-DSDM-Consortium-evolves-into-Agile-Business-Consortium.html|publicado=Press Dispensary|wayb= 20161111173620|urlmorta= sim}}</ref>

== Evolução histórica ==
A DSDM fornece um framework para uma abordagem interativa e incremental de desenvolvimento de [[Sistema de informação|Sistemas de Informação]] (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ª versão. Esta metodologia foi desenvolvida por um consórcio de vendedores e peritos no campo dos Sistemas de Informação, no qual partilharam e combinaram as suas melhores técnicas. Assim, a DSDM surge como uma extensão do RAD (Rapid Application Development), focada em projetos de Sistemas de Informação caracterizados por prazos e orçamentos apertados. A DSDM aborda os problemas que frequentemente ocorrem no desenvolvimento de informação que se prendem essencialmente com a falta de tempo, com orçamentos mais apertados ou com outro tipo de razões para que o projeto falhe, tal como a falta de envolvimento dos encarregados do projeto ou dos utilizadores finais.<ref>{{citar web|url=https://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final_14.pdf|titulo=DSDM – Dynamic Systems Development Methodology|wayb= 20170329154845|urlmorta= sim}}</ref>

== O DSDM ==
===
Princípios
===
Existem 9 princípios formados por 4 séries e 5 pontos-chave.
* 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.
* 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.
* Eficácia: o critério principal para ser considerado "entregável" é entregar um sistema que demonstre auxiliar nas necessidades e negócio atuais. É mais importante um sistema corresponder às necessidades de negócio do que focar nas funcionalidades.
* Feedback: o desenvolvimento é iterativo e incremental controlado por feedbacks de usuários, a fim de tornar a solução eficaz ao negócio.
* Reversibilidade: todas as alterações feitas no desenvolvimento são reversíveis.
* Previsibilidade: o escopo e requisitos de alto nível devem ser definidos antes que o projeto se inicie.
* Ausência de Testes no escopo: testes são tratados fora do ciclo de vida do projeto. (Veja [[Desenvolvimento orientado a testes]] para uma comparação).
* Comunicação: é necessária excelente comunicação e cooperação de todos os envolvidos para obter maior eficácia e eficiência no projeto.

===Considerações adicionais===
* Prioridades: nenhum sistema é construído perfeitamente logo de início. (confira [[Princípio de Pareto|Princípio de Pareto ou regra 80/20]]). Em geral, 80% do resultado final são oriundos de 20% dos requisitos, por esta razão o DSDM inicia pela implementação bem sucedida destes 20% críticos; desta forma pode produzir um sistema que ofereça funcionalidades suficientes para satisfazer usuários finais e os 80% restantes podem ser distribuídos nas demais iterações, além de reduzir o risco do projeto ultrapassar seus limites de prazo e orçamento.
* Tripé de qualidade: a entrega do projeto deve ser feita a tempo, custo e de ser de boa qualidade.
* Interseções: cada passo do desenvolvimento deve estar completo apenas o suficiente para que se inicie o próximo passo. Isto permite que a nova iteração seja iniciada sem atrasos desnecessários.
* Maleabilidade: alterações no design podem coincidir com alterações na demanda de usuários finais, uma vez que cada iteração do sistema é aprimorada de forma incremental.
* Gerenciamento: técnicas de Gerência de Projeto e [[Desenvolvimento de software|Desenvolvimento de Sistemas]] são incorporadas.
* Híbrido: DSDM pode ser aplicado tanto em novos projetos quanto em aprimoramento de sistemas já existentes.
* Objetividade: a gerência de risco deve focar nas funcionalidades a serem entregues, não no processo de desenvolvimento e nem em artefatos (como requisitos e criação de documentos).
* Foco na entrega: gerenciamento valoriza muito mais entrega do produto que tarefa cumprida.
* Funcionalidade: estimativa deve se basear na funcionalidade de negócios em vez de em linhas de código.

===
 Prérequisitos
 para utilizar o DSDM===
Para obter sucesso com o DSDM, um número de pré-requisitos deve ser alcançado. Inicialmente, deve haver interação entre o time do projeto, futuros usuários e o alto-escalão. Isto permite identificar futuras falhas no sistema acarretadas pela falta de acompanhamento da gerência ou envolvimento de usuário. O segundo requisito para um projeto DSDM é que ele possa ser [[fracionado]] em pequenas partes permitindo um maior detalhamento em cada iteração.

Exemplos de projetos que o DSDM não é uma boa indicação:
* Projetos de segurança crítica - Os testes e validações extensos destes projetos conflitam com os objetivos de custo e prazo do DSDM.

* Projetos baseados na reutilização de componentes - A necessidade de perfeição nestes casos é muito alta e conflitam com o  [[#principles|princípio 80-20]] descritos anteriormente.

== Fases do Projeto DSDM ==
O framework DSDM consiste de 3 fases sequenciais, nomeadas de pré-projeto, ciclo de vida e pós-projeto. O ciclo de vida é a fase mais elaborada das 3. Consiste em 4 estágios que formam o passo-a-passo das iterações aplicadas ao desenvolvimento do sistema. Estas 3 fases e seus respectivos estágios serão abrangidos nas seções subsequentes, veja abaixo as atividades principais de cada fase/etapa:

; Fase 1 - O Pré-Projeto : No pré-projeto são identificados os projetos candidatos, são definidos orçamento e assinatura do contrato. Controlando estes critérios antecipadamente pode-se evitar problemas futuros e em estágios mais críticos.

; Fase 2 - O Ciclo de Vida : Análise de viabilidade e negócios são fases sequenciais que se completam entre si. Após a conclusão destas fases, o sistema é desenvolvido iterativamente e incrementalmente segundo as iterações do Modelo Funcional, desenho e construção, até à implementação. A iteração e natureza incremental do DSDM serão citadas mais a frente.

; Fase 3 - Pós-projeto : Esta fase garante a eficiência e eficácia do projeto. Através de manutenções, melhorias e ajustes de acordo com os princípios do DSDM. A manutenção pode ser vista como um contínuo desenvolvimento. Invés de finalizar o ciclo de vida de apenas 1 vez, normalmente o projeto pode retomar fases/etapas anteriores a fim de refinar ainda mais o passo concluído.

Abaixo encontra-se o diagrama de processo de todo o ciclo de vida (4 etapas).Isto ilustra a iteração de desenvolvimento, iniciando no Modelo funcional, passando pelo desenho, construção até chegar à implantação. A explicação de cada fase será descrita [[#phases|mais a frente neste tópico]].

[[Image:processdata-DSDM.png|thumb|640px|center|Diagrama de processo do ciclo de vida de um projeto DSDM]]

=== Os 4 estágios do ciclo de vida ===
{| border="1" cellpadding="5" cellspacing="0"
|-
! style="background:#efefef;" | Atividade || style="background:#efefef;" | Sub-atividade || style="background:#efefef;" | Descrição
|-
| rowspan=2| Análise
| Análise de Viabilidade
| Estágio onde a utilização do DSDM é avaliada. Analisando o tipo de projeto, problemas organizacionais e de pessoas, é tomada a decisão de se utilizar ou não o DSDM. Por esta razão são gerados artefatos de RELATÓRIO DE VIABILIDADE, PROTÓTIPO DE VIABILIDADE, e um PLANO DE DETALHAMENTO GLOBAL que inclui o PLANO DE DESENVOLVIMENTO e CONTROLE DE RISCO.
|-
| Análise de Negócio
| Onde são analisadas características essenciais do negócio e tecnologias a serem empregadas. Capacidade de se montar grupos de trabalho, onde existam clientes experts suficientes para fornecer maiores peculiaridades do sistema e concordarem com as prioridades de desenvolvimento.
|-
| rowspan=4| Iteração do Modelo Funcional
| Identificar o Protótipo Funcional
| Determinar as funcionalidades que serão implementadas é o resultado desta iteração. Neste sub-estágio, um MODELO FUNCIONAL é desenvolvido de acordo com o resultado com o artefato resultante do estágio de Análise do negócio.
|-
| Agenda
| Definir quando e como as funcionalidades serão implantadas.
|-
| Criação do Protótipo Funcional
| Desenvolver um PROTÓTIPO FUNCIONAL, de acordo com a Agenda e o MODELO FUNCIONAL.
|-
| Revisão do Protótipo Funcional
| Efetuar correções do protótipo desenvolvido. Isto pode ser feito através de testes dos usuários finais ou por análise da documentação. O artefato gerado aqui é o DOCUMENTO DE REVISÃO DO PROTÓTIPO FUNCIONAL.
|-
| rowspan=4| Iteração de Desenho e Construção
| Identificar o modelo do Desenho
| Identificar requisitos funcionais e não-funcionais que devem estar no sistema testado. Baseado nestas identificações, uma ESTRATÉGIA DE IMPLANTAÇÃO é gerada e caso haja EVIDÊNCIAS DE TESTE de iterações anteriores, estas serão utilizadas para criação desta estratégia.
|-
| Agenda
| Como e quando serão realizados estes requisitos.
|-
| Criação do Protótipo do Desenho
| Criar um sistema (PROTÓTIPO) que pode tranquilamente ser manipulado pelos usuários finais no uso diário, também para razões de teste.
|-
| Revisão do Protótipo
| Efetuar correções no sistema desenhado. Novamente testando e revisando através das técnicas mais utilizadas. Uma DOCUMENTAÇÃO PARA USUÁRIO e EVIDÊNCIA DE TESTE serão gerados.
|-
| rowspan=4| Implantação
| Orientações e Aprovação do usuário
| Usuários finais aprovam o sistema testado (APPROVAL) pela implantação e orientação fornecida pelo respectivo sistema criado.
|-
| Treinamento
| Treinar futuros usuários finais no uso do sistema. USUÁRIOS TREINADOS é o artefato entregue neste sub-estágio.
|-
| Implantação
| Implantar o sistema testado e liberar aos usuários finais, chamado SISTEMA ENTREGUE.
|-
| Revisão de Negócio
| Rever o impacto que o sistema implantado causa sobre o negócio, pode-se utilizar o cruzamento dos objetivos iniciais com a análise atual como termômetro. Dependendo do resultado o projeto passa para o próximo estágio ou reinicia este estágio a fim de refinar e melhorar os resultados. Esta revisão será documentada através do DOCUMENTO DE REVISÃO DO PROJETO.
|}

=== Os 4 estágios do ciclo de vida do projeto ===
[[Image:DSDM Development Process.svg|thumb|320px|Modelo DSDM do processo de desenvolvimento de software.]]
====Estágio 1A: Análise de Viabilidade====
Durante este estágio do projeto, a viabilidade de uso do DSDM é examinada. [[#prerequisites|Pré-requisitos]] para o uso do DSDM são avaliados respondendo-se algumas questões como: ‘Pode este projeto atender as necessidades do negócio?’, ‘Este projeto é próprio para o DSDM?’ e ‘Quais os riscos mais importantes que estão envolvidos?’. A técnica fundamental desta fase é a utilização dos [[#workshop|Grupos de trabalho]].

Os artefatos para este estágio são Relatório de viabilidade e Protótipo da Viabilidade. São estendidos até o Planejamento de Definições Gerais até o resto do projeto, e além deste um controle de Risco identifica os riscos mais impactantes do projeto.

Essa análise não deve passar de algumas semanas; duas ou três são consideradas tempo suficiente para deliberar sobre a viabilidade. como produto final, são criados um relatório de viabilidade e um plano geral de desenvolvimento.<ref>{{citar livro|título=Metodologias Ágeis. Engenharia de Software Sob Medida|ultimo=SBROCCO|primeiro=José Henrique Teixeira de Carvalho|ultimo2=MACEDO|primeiro2=Paulo Cesar de|editora=Érica|ano=2012|local=São Paulo|páginas=|acessodata=}}</ref>

;Análise de negócio
Oriundo da [[Análise de Viabilidade]]. Após o projeto ser deferido viável para o uso do DSDM, este estágio examina a influência dos processos do negócio, usuários envolvidos e seus respectivos desejos e necessidades. Novamente os [[#workshop|Grupos de Trabalho]] são uma das mais valiosas técnicas, Grupos de Trabalho juntam diferentes envolvidos para discutir o propósito do sistema. A informação gerada nestas sessões é combinada com a lista de requisitos. Uma propriedade importante da lista de requisitos é o fato dos requisitos estarem (ou poderem) ser priorizados. Geralmente este requisitos são priorizados segundo o método de MoSCoW. Baseados nestas prioridades, o plano de desenvolvimento é construído como base para o resto do''' projeto.

Uma técnica importante utilizada no desenvolvimento do plano é a [[#timeboxing|Timeboxing]]. Esta técnica é essencial para alcançar os objetivos do DSDM, baseados e custo e prazo, garantindo a qualidade desejada. A [[Arquitetura de software|Arquitetura do Sistema]] é outro documento fundamental no auxilio do sistema. Os artefatos para este estágio são definições que relatam o contexto do projeto dentro da companhia. A Arquitetura do Sistema, fornece a arquitetura global inicial do Sistema em desenvolvimento junto com um plano de desenvolvimento que destaca os pontos mais importantes num processo de desenvolvimento. Na base destes 2 documentos encontra-se a lista de priorização de requisitos. O que define todos os requisitos do sistemas. E por último, o controle de Risco é atualizado com os fatos que forem identificados durante esta fase do DSDM.

====Estágio 2: Iteração do Modelo Funcional====
Os requisitos identificados nos estágios anteriores serão convertidos em modelos funcionais. Este modelo consiste tanto do funcionamento do protótipo quanto do modelo. Prototipar é uma saída para técnicas de projeto em que neste estágio auxilia num verdadeiro envolvimento do usuário no projeto.
O protótipo desenvolvido é revisado por diferentes grupos. De forma a garantir qualidade, os testes são efetuados ao longo de cada iteração. Uma parte importante do teste é realizada na Iteração do Modelo Funcional. O Modelo Funcional pode ser dividido em 4 sub-estágios:

* Identificação do protótipo funcional: determina funcionalidades a serem implementadas resultantes desta iteração.
* Agenda: concilia como e quando serão feitas estas funcionalidades.
* Criação do protótipo funcional: desenvolver o protótipo. Investigar, refinar e consolidar com os protótipos funcionais das iterações anteriores.
* Revisão do protótipo: efetuar correções no desenvolvimento do projeto. Isto pode ser feito através de testes de usuários, através destas evidências e feedbacks dos usuários é gerado o documento de revisão do Protótipo.

Os artefatos desta etapa são Modelo Funcional e Protótipo Funcional os quais juntos representam as funcionalidades que serão trabalhadas nesta iteração, prontas para serem testadas por usuários. Depois disso, a lista de requisitos é atualizada, removendo-se os itens entregues e refazendo a lista de prioridades dos requisitos remanescentes. Além disso o Log de Riscos também é atualizado por uma análise de riscos do conteúdo desenvolvido após a revisão do documento da prototipação.

==== Estágio 3: iteração de desenho e construção ====
O maior intuito desta Iteração do DSDM é integrar os componentes funcionais de fases anteriores em um sistema que satisfaça as necessidades do usuário. Ele também controla os requisitos não funcionais que foram definidos para o Sistema. Novamente [[#testing|Testes]] vem a ser uma atividade fundamental no andamento deste estágio. A iteração de Desenho e Construção também pode ser dividida em 4 sub-estágios:

* Definir desenho do protótipo: Identificar requisitos funcionais e não funcionais que precisam ser testados no sistema.
* Agenda: Definir quando e como serão realizados estes requisitos.
* Criação do desenho do protótipo: criar um sistema que possa ser seguramente manipulado por um usuário no uso diário. Investigar, refinar e consolidar o protótipo da iteração atual dentro do processo de prototipação é um ponto essencial.
* Revisar o protótipo desenhado: efetuar ajustes no desenho do sistema, novamente testando e revisando com as principais técnicas já utilizadas, uma vez que os feedbacks dos usuários e as evidências de teste são necessárias para geração da documentação do usuário.

Os artefatos a serem entregues neste estágio são Desenho do Protótipo que os usuários testaram e ao final desta Iteração o sistema testado é transferido para a próxima fase. Neste estágio, o sistema é construído exatamente de acordo com o desenho e funções consolidadas e integradas no protótipo. Outro artefato desta iteração é a Documentação de Usuário.

====Estágio 4: implantação====
Na fase de Implantação, o sistema testado e mais a documentação de usuário é entregue aos usuários e treinos à estes futuros usuários são aplicados. O sistema para ser entregue deve ter seus requisitos revisados de acordo com o que foi definido nas etapas iniciais do projeto. O estágio de implantação é dividido em 4 sub-estágios:

* Orientações e aprovação do usuário: usuários aprovam o sistema testado e algumas orientações de uso e implantação do sistema são definidas.
* Treinamento: treinamento de futuros usuários no uso do sistema.
* Implantação: implantar propriamente o sistema concluído na localidade dos usuários.
* Revisão de Negócios: rever o impacto que o sistema implantado causa sobre o negócio, pode-se utilizar o cruzamento dos objetivos iniciais com a análise atual como termômetro. Dependendo do resultado o projeto passa para o próximo estágio ou reinicia este estágio a fim de refinar e melhorar os resultados. Esta revisão será documentada através do DOCUMENTO DE REVISÃO DO PROJETO.

Os artefatos deste estágio consistem em Entrega do Sistema no Local, pronto para utilização dos usuários finais, Treinamento de usuários e Documento de Revisão do Projeto do sistema entregue.

== Iteração do Modelo Funcional DSDM ==
=== Modelo de metadados ===
As associações entre os conceitos das entregas e o estágio de iteração do Modelo Funcional são ilustrados no modelo de Metadados abaixo. Este modelo irá combinar com o diagrama de meta-processos da fase de Iteração do Modelo Funcional na próxima parte.

[[Image:metadata-DSDM.png|400px|thumb|center|Modelo de Metadados da Iteração do Modelo Funcional]]

{| border="1" cellpadding="5" cellspacing="0"
|-
! style="background:#efefef;" | Conceito || style="background:#efefef;" | Definição
|-
| CONTROLE DE RISCO
| Log dos riscos identificados. Importante desde que perdure na próxima etapa, um problema encontrado será mais difícil de se tratar. O log de risco deverá ser atualizado continuamente. (VTT Publication 478)
|-
| LISTA DE PRIORIZAÇÃO DE REQUISITOS
| Lista de requisitos baseadas em suas prioridades. O processo de priorização é baseado no modelo MoSCoW, para determinar quais requisitos devem ser implementados primeiro no sistema (que coincidam com as necessidades do sistema).
|-
| LISTA DE REQUISITOS NÃO-FUNCIONAIS
| Listagem dos requisitos que serão tratados em estágios seguintes. (VTT Publication 478)
|-
| REQUISITOS FUNCIONAIS
| Função utilizada para construir o modelo e protótipo de acordo com suas prioridades.
|-
| MODELO FUNCIONAL
| Modelo baseado em requisitos funcionais. Será utilizado de acordo com o desenvolvimento do protótipo Funcional. Este conceito será utilizado para desenvolver o PLANO DE PROTOTIPAGEM.
|-
| PROTOTIPAGEM
| Processo de unir rapidamente uma forma de trabalho (um protótipo) de forma a testar vários aspectos de design, ilustrar idéias e funcionalidades conseguindo antecipadamente identificar a reação do usuário.
|-
| DIVISÃO DE TEMPO
| Lista de tempo necessário para certas atividades a fim de executar o planejamento de acordo com a agenda.
|-
| PLANO DE PROTOTIPAGEM
| Plano de atividades dentro de um processo de prototipagem que será utilizado em períodos de tempo disponíveis de acordo co a agenda.
|-
| AGENDA
| Definição do plano de atividades e tempo necessário acordados entre os desenvolvedores. Este conceito será utilizado para suportar a implantação do PROTÓTIPO FUNCIONAL.
|-
| PROTÓTIPO FUNCIONAL
| Um protótipo de funções que o sistema deve executar e como deve ser feito.
|-
| PLANO DE IMPLANTAÇÃO
| Preparação de atividades necessárias à implantação do protótipo funcional de acordo com a agenda e lista priorizada de requisitos.
|-
| FUNCÃO REFINADA
| Função do protótipo que está sendo revisada na iteração atual antes de ser combinada e testada com as demais.
|-
| FUNÇÃO COMBINADA
| Função do protótipo que é combinada com outros protótipos funcionais de iterações anteriores. A nova combinação funcional do protótipo será testada no próximo estágio.
|-
| REGISTRO DE TESTE
| Conjunto de evidências de teste onde o script, procedimento, e resultados dos testes são incluídos. Este registro é utilizado no desenvolvimento do DOCUMENTO DE REVISÃO DE PROTOTIPAGEM FUNCIONAL, além de indiretamente atualizar a LISTA PRIORIZADA DE REQUISITOS.
|-
| DOCUMENTO DE REVISÃO DE PROTOTIPAGEM FUNCIONAL
| Coleta comentários gerais de usuários sobre o incremento atual, trabalhando como uma entrada para as iterações subsequentes (VTT Publication 478). Este documento de revisão será utilizado para atualizar o CONTROLE DE RISCO e LISTA DE PRIORIZAÇÃO DE REQUISITOS.
|}

=== Modelo de processo ===
A atividade de identificar o protótipo funcional é identificar funcionalidade que podem estar no protótipo da iteração corrente. Lembrando que, análise e código foram feitos; protótipo são construídos, e experiências adquiridas com eles são utilizadas para aprimorar a análise de modelos (baseado também na atualização da lista priorizada de requisitos e controle de risco). A construção de protótipo não pode ser descartada por inteiro, mas gradualmente transformada na qualidade que será aplicada no final do produto final. A Agenda determina quando e como a prototipação será implantada; isto oferece um escopo para avaliação de tempo hábil e plano de prototipagem. Uma vez que testes são feitos ao longo de todo o processo, Isto também se torna parte essencial desta fase, por esta razão é incluída na atividade de revisão de protótipo logo após o protótipo funcional é construído, e este registro de teste será eventualmente utilizado no processo de revisão do protótipo e gerar o documento de revisão. Abaixo o diagrama do processo da Iteração do Modelo Funcional.

[[Image:processdata-FMI.png|thumb|620px|center|Modelo da Iteração do Modelo Funcional.]]

{| border="1" cellpadding="5" cellspacing="0"
|-
! style="background:#efefef;" | Atividade || style="background:#efefef;" | Sub-atividade || style="background:#efefef;" | Descrição
|-
| rowspan=4| Identificar o Protótipo Funcional
| Análise de Requisitos
| Os requisitos do protótipo atual são analisados de acordo com a lista priorizada de requisitos criada anteriormente (iteração anterior e/ou na fase anterior - Análise de negócio).
|-
| Listar Requisitos da Iteração atual
| Seleciona os requisitos funcionais que serão implementados na iteração do protótipo atual, e as lista como REQUISITOS FUNCIONAIS.
|-
| Listar requisitos não funcionais
| Incluir na LISTA DE REQUISITOS NÃO-FUNCIONAIS os requisitos identificados como sendo não-funcionais.
|-
| Criar um Modelo Funcional
| Analisar modelo e protótipo de código estão incluídos nesta sub-atividade para desenvolver o MODELO FUNCIONAL.
|-
| rowspan=3| Agenda
| Determinar o tempo
| Identificar possíveis disponibilidades (períodos) para executar atividades de prototipação de acordo com plano e estratégia de prototipagem.
|-
| Definir Desenvolvimento
| O PLANO DE PROTOTIPAGEM, incluindo todas as atividades de prototipagem serão executados no tempo disponível.
|-
| Agenda
| Concordância de quando e como as atividades de prototipagem serão executadas.
|-
| rowspan=3| Criar Protótipo Funcional
| Investigar
| Investigar requisitos; análise do MODELO FUNCIONAL que foi criado anteriormente, e definir um PLANO DE IMPLANTAÇÃO de acordo com o modelo de análise, será utilizado para construir o protótipo na próxima sub-atividade.
|-
| Refinar
| Implementar o MODELO FUNCIONAL e PLANO DE IMPLANTAÇÃO para construir o PROTÓTIPO FUNCIONAL. Este protótipo será refinado antes de ser combinado com outras funções. Este protótipo será gradualmente movido para qualidade a qual poderá estar incluída até a versão final (através do processo de refinamento).
|-
| Consolidação
| Consolidar o PROTÓTIPO FUNCIONAL refinado com o protótipo das iterações anteriores. A nova combinação PROTÓTIPO FUNCIONAL será testada na atividade a seguir.
|-
| rowspan=2| Revisar protótipo
| Testar protótipo
| Parte essencial do DSDM que deve estar inclusa ao longo de todo o processo. O REGISTRO DE TESTE será utilizado junto aos comentários de usuários para desenvolver DOCUMENTO DE REVISÃO DE PROTOTIPAGEM na próxima atividade da fase da Iteração do Modelo Funcional.
|-
| Revisar Protótipo
| Coletar comentários de usuários e documentação. Evidências de teste irão gerar regras importantes ao desenvolvimento deste relatório de revisão. Baseado neste DOCUMENTO DE REVISÃO DE PROTOTIPAGEM, a lista de requisitos priorizados e controle de risco serão atualizados, então será decidido se devem ser mantidos na próxima iteração ou não.
|}

== Outros tópicos DSDM ==
===
Centro
 de Técnicas do DSDM===
*
Timeboxing
 Timeboxing é uma das técnicas de projeto do DSDM. Utilizada no suporte aos objetivos principais para realização do desenvolvimento do sistema no prazo estimado, além de manter o custo e qualidade desejados. A principal ideia por trás do timeboxing é a divisão do projeto em porções, cada um com um orçamento e prazo estimados. Para cada porção um número de requisitos são selecionados e priorizados de acordo com o princípio de [[:en:MoSCoW_method|MoSCoW]]. Devido ao tempo e custo serem fixos, as variáveis remanescentes são os requisitos. Desta forma se o prazo ou o custo está se esgotando requisitos de baixa prioridade são omitidos. Não significa que o produto ficará inacabado ou será entregue pela metade, pois de acordo com o [[Princípio de Pareto]], onde 80% do projeto vem de 20% dos requisitos do sistema, assim uma vez que os 20% dos requisitos mais importantes forem implementados no sistema será possível atender as necessidades do negócio além do que nenhum sistema é construído em sua total perfeição logo de início.
* MoSCoW [[MoSCoW]] Representa a forma de priorização de itens. No contexto do DSDM o método MoSCoW é utilizado para priorizar requisitos. o acrônimo MoSCoW se refere à:
: MUST: requisitos que DEVEM estar de acordo com as necessidades do negócio.
: SHOULD: requisitos que devem ser considerados ao máximo, mas que não impactam no sucesso do projeto.
: COULD: incluir este requisito caso não afete o tamanho das necessidades de negócio do projeto.
: WOULD: Incluir este requisito no caso de futuramente existir tempo sobrando (ou em futuros desenvolvimentos).
*
Prototipagem
 Se refere à criação de protótipos do sistema em desenvolvimento em estágios iniciais do projeto. Isto permite descobrir rapidamente falhas no sistema e permitir um ‘test-drive’ aos usuários do sistema, o que vem a ser uma ótima maneira de se realizar o envolvimento do usuário, um dos fatores chave do DSDM.
*
Testes
 Um terceiro aspecto importante do DSDM é a criação de um sistema de boa qualidade. Para alcançar este quesito, DSDM aplica testes ao longo de cada iteração. Considerando que o DSDM é um método e ferramenta independente, o time de projeto é livre para escolher por conta própria o [[Teste de software|Método de gerenciamento de teste]], por exemplo [https://web.archive.org/web/20091117202658/http://eng.tmap.net/Home/TMap/].
*
Grupos de Trabalho
 Uma das técnicas do DSDM que objetiva e permite que diferentes envolvidos discutam juntos requisitos, funcionalidades e entendimento mútuo. Num grupo de trabalho os envolvidos se unem a discutir apenas sobre o projeto.
*
Modelagem
 Esta técnica é essencial e propositalmente utilizada para visualizar uma representação gráfica de aspectos específicos do sistema ou área de negócio que será trabalhado. Modelagem permite um melhor entendimento para o time do projeto do DSDM que está fora do domínio do negócio.
*
Gerenciamento de Configuração
 Uma boa implantação da técnica de [[Gerência de Configuração de Software|Gerenciamento de Configuração]] o dinamismo natural do DSDM. Uma vez que exista mais de uma coisa para controlar ao mesmo tempo durante o processo de desenvolvimento do sistema, e os produtos são entregues frequentemente  num tempo muito rápido, os produtos por esta razão tem de ser estritamente controlados se foram completamente concluídos.

===
Papéis
 do DSDM===
Existem alguns papéis aplicados junto ao ambiente DSDM. É interessante que seja definido previamente os papéis que cada membro do projeto irá representar antes de se iniciar as atividades. Cada papel tem sua própria responsabilidade. São eles:
* Gerente executivo: também chamado de “Campeão do Projeto”. Papel importante para usuários os quais possuem habilidades e responsabilidades em cumprir determinados prazos e recursos. Este papel é a ultima palavra na tomada de decisões.
* Visionário: aquele que tem a responsabilidade de iniciar projeto certificando que os requisitos essenciais foram definidos. O visionário tem a percepção acurada dos objetivos de negócio do sistema e projeto. Outra tarefa é supervisionar e manter o desenvolvimento do processo "na linha".
* Intermediador: usuário que traz o conhecimento de outras áreas para o projeto, certifica que os desenvolvedores receberam quantidade suficiente de feedback de usuários durante o processo de desenvolvimento.
* Anunciante: qualquer usuário que represente um importante ponto de vista e traga diariamente conhecimento ao projeto.
* Gerente de projeto: pode ser qualquer do grupo de usuários ou Gerencia de TI que gerenciará o projeto como um todo.
* Coordenador Técnico: responsável no desenho da arquitetura do Sistema e controle da qualidade técnica do projeto.
* Líder de time: lidera seu time e mantém a harmonia do projeto e trabalho em grupo.
* Desenvolvedor: interpreta o modelo e requisitos do sistema incluindo desenvolvimento de artefatos de código e construção de protótipos.
* Testador: Confere o funcionamento da parte técnica através da execução de algumas tarefas. O Testador deverá possuir alguns comentários e documentação.
* Escrivão: Responsável por recolher e armazenar requisitos, acordos e decisões tomadas entre todos os grupos de trabalho.
* Facilitador: Gerencia progresso dos grupos de trabalho, age como motor de preparação e comunicação.
* Papéis específicos: Arquiteto de negócios, Gestor de Qualidade, Integrador de Sistema, etc.

===
Iteratividade
 e natureza Incremental===
Após o [[#timeboxing|timeboxing]] e priorização de requisitos, O DSDM oferece também uma forma de [[Desenvolvimento iterativo e incremental|Desenvolvimento Incremental e Iterativo]] ao sistema. Isto pode ser visto na ilustração exibida no [[#Modelo_do_Processo|Modelo do Processo]].

Os estágios das Iterações do Modelo Funcional, Desenho, construção e Implantação podem percorrer seus sub-estágios inúmeras vezes antes de passar para o próximo passo. Cada iteração inclui uma lista de funcionalidades, e toda iteração é construída baseada no seu predecessor. Se necessário cada iteração também pode ser desfeita.

A ilustração do resumo do processo mostra também setas retornando à estágios anteriores. Por exemplo, a ligação Implantação x Análise de Negócio. Caso uma grande funcionalidade foi descoberta durante o desenvolvimento e não pôde ser implementada, é possível reiniciar definindo novos requisitos no estudo de caso. Da mesma forma, há uma ligação entre Implantação e Iteração do Modelo Funcional. Funcionalidades podem ser omitidas durante o Modelo Funcional anterior devido a limites de tempo ou custo. O projeto deve ir à fase de Pós-projeto somente após reconhecer que todos os requisitos definidos no escopo foram entregues.

Devido a natureza Iterativa do DSDM, é essencial efetuar um ótimo trabalho no [[Engenharia de requisitos|levantamento de requisitos]] e [[Gerência de Configuração de Software|Gerência de Configuração]] durante todo o projeto. Isto garante que os projetos definidos anteriormente foram implantados na fases anteriores do projeto.

=== Metamodelo (Metamodelagem) ===
[[Metamodelagem]] define em alto nível métodos e técnicas. Permitindo que sejam comparados métodos, técnicas e Engenharias similares existentes aos novos.

O Modelo de metadados, representado abaixo: demonstra os conceitos e associações entre estes conceitos do DSDM. Como pode ser visto, pode-se identificar 2 conceitos principais, ''Fase'' e ''Fluxo''. Cada ''Fluxo'' se origina de uma ''Fase'' dentro do DSDM. Os Fluxos podem ser divididos em sub-conceitos ''Dados'' e ''Produto''. Esta subdivisão é denotada por um ''C'', que significa que a subdivisão foi separada e concluída. Em outras palavras, ''Fluxo'' será sempre ''Fluxo de dados'' ou ''Fluxo do produto'', jamais ambos. No caso do DSDM ''Fluxo de Dados'' pode ser um ponto de retorno à fases anteriores. ''Fluxo de produtos são formas tangíveis que resultam de ''Fases'' e serão incluídos na próxima ''Fase'', por exemplo protótipos e relatórios.

[[Image:Geologic map information meta-model.jpg|thumb|400px|Exemplo de um mapa geológico de informação do Metamodelo, com 4 tipos de metaobjetos, and their self-references.<ref>David R. Soller et al. (2001) [http://pubs.usgs.gov/of/2001/of01-223/soller2.html Progress Report on the National Geologic Map Database, Phase 3: An Online Database of Map Information] Digital Mapping Techniques '01 -- Workshop Proceedings U.S. Geological Survey Open-File Report 01-223.</ref>]]

Há ainda um segundo conceito de ''Fase'' que também pode ser dividido em 2 subconceitos com a ordem de separar e completar. São eles ''Sequencial'' e ''Fases Iterativas''. Conforme descrito em seção anterior, o DSDM inicia com 2 fases sequenciais, Análise de Viabilidade e então do Negócio. Após um número de fases iterativas, ex: Modelo Funcional, Desenho, construção e implantação.
A figura mostra também um numero de regras e problemas que não estão incluídos no modelo, mas são importantes para o Metamodelo. Primeiro as regras que controlam o comportamento dos ''Fluxos'', restringindo a liberdade do fluxo, o que corresponde às transições de ''Fases'' dentro do DSDM. Junto às regras um numero de importantes critérios são utilizados para garantir o ciclo de vida do projeto.

== Fatores críticos de sucesso do DSDM ==
No DSDM uma série de fatores são identificados como sendo de grande importância para garantir o sucesso do projeto.

* Fator 1: Inicialmente há a aceitação do DSDM pelo gerente Senior e outros colaboradores. Isto garante que diferentes atores do projeto sejam motivados pelo início e demais envolvidos no projeto.

* Fator 2: O segundo fator segue diretamente daqui e é o que a gerência de empenho garante como envolvimento do usuário final. A prototipagem requer um forte e dedicado envolvimento do usuário em testar e avalizar os protótipos funcionais.

* Fator 3: Aqui se encontra o time do projeto. Este time deve ser composto por membros capacitados, um ponto importante é o empenho deste time. Significa que o time (um ou mais membros) possuem poder e permissões de tomar decisões importantes com relação ao projeto sem a necessidade de se formalizar propostas à alta gerência, o que seria um grande consumidor de tempo. De forma ao time estar apto a concluir um projeto com sucesso, é necessário também a escolha adequada da tecnologia. O que se refere ao ambiente de desenvolvimento, ferramentas de gerenciamento de projeto, etc.

* Fator 4: Finalmente o DSDM define um relacionamento de suporte necessário entre o cliente e fornecedor. Isto vale para projetos que estão sendo realizados dentro da empresa ou por fornecedores. O documento que relata este suporte de relacionamento vem a ser o  [[ISPL]].

== Comparação com outros tipos de desenvolvimento de software ==
Durante anos um grande número de métodos de desenvolvimento de sistemas tem sido desenvolvidos e aplicados, divididos em [[SSADM|Métodos estruturados]], [[Rapid Application Development|métodos RAD]] e [[Orientação a objetos|Métodos orientado a objetos]]. Muitos destes métodos demonstram similaridades um com outro e também com o DSDM. Por exemplo [[Programação extrema|Programação Extrema]](XP) também possui um formato [[#iterative|iterativo]] ao desenvolvimento baseado com envolvimento do usuário.

O [[Rational Unified Process]] (RUP) é provavelmente o método mais similar ao DSDM assim é também o formato mais dinâmico de desenvolvimento de sistema de informação. Novamente o formato [[#iterative|iterativo]] é utilizado neste método de desenvolvimento.

Como o XP e o RUP existem muitos outros métodos de desenvolvimento que demonstram similaridades com o DSDM, mas DSDM se diferencia por si só pelo número de caminhos que pode adotar. ''Primeiro temos um fato que produz uma ferramenta e um framework técnico independente. Isto permite usuários preencherem etapas específicas do processo om suas próprias técnicas e escolhas de documentação de software. Outra funcionalidade exclusiva é o fato de que variáveis no desenvolvimento não são considerados recursos ou tempo,'' mas requisitos. Assim garantimos os pontos principais do DSDM, marcados para se manterem no custo e prazo definidos. E por último o forte foco na comunicação entre e no envolvimento de todos responsáveis pelo sistema. Contudo isso é encontrado em outros métodos, DSDM acredita fortemente no comprometimento do projeto para garantir o sucesso do projeto.

{{referências}}

== Ver também ==
* [[Desenvolvimento ágil de software]]
* [[Programação extrema]]
* [[Desenvolvimento iterativo e incremental]]
*[[:en:MoSCoW_method|Método MoSCoW]]
* [[IBM Rational Unified Process]]
* [[Rapid Application Development]]
* [[Princípio de Pareto]] (regra 80/20)
* [[PRINCE2]]
* [[Scrum]]
*[[Análise estruturada|Método de Análise Estruturada de Sistemas]]
*[[Test Driven Development]]
*[[Lean manufacturing]]
*[[:en:FDD|Feature Driven Development]]
*[[Programação extrema]]

== Outras Leituras ==
* Coleman and Verbruggen: ''A quality software process for rapid application development'', Software Quality Journal 7, p. 107-1222 (1998)
* Beynon-Davies and Williams: ''The diffusion of information systems development methods'', Journal of Strategic Information Systems 12 p. 29-46 (2003)
* [[Sjaak Brinkkemper]], Saeki and Harmsen: ''Assembly Techniques for Method Engineering'', Advanced Information Systems Engineering, Proceedings of CaiSE'98, Springer Verlag (1998)
* Abrahamsson, Salo, Ronkainen, Warsta ''[http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf Agile Software Development Methods: Review and Analysis]'', VTT Publications 478, p. 61-68 (2002)
* Tuffs, Stapleton, West, Eason: ''Inter-operability of DSDM with the Rational Unified Process'', DSDM Consortium, Issue 1, p. 1-29 (1999)
* Rietmann: ''DSDM in a bird’s eye view'', DSDM Consortium, p. 3-8 (2001)
* [https://web.archive.org/web/20080527234850/http://sdlc.bobstewart.com/ iSDLC] integrated Systems Development Life Cycle

== Ligações externas ==
{{commonscat|Dynamic Systems Development Method}}
* [http://www.dsdm.org The DSDM Consortium]
* [http://www.ifi.uzh.ch/rerg/fileadmin/downloads/teaching/seminars/seminar_ws0304/14_Voigt_DSMD_Ausarbeitung.pdf Dynamic System Development Method] by Benjamin J. J. Voigt, Zurich, 2004.

{{Software Engineering}}

[[Categoria:Processo de desenvolvimento de software]]
[[Categoria:Gerência de projetos]]


text:
# Laurel Springs
Laurel Springs é um distrito localizado no estado americano de Nova Jérsei, no Condado de Camden.

## Demografia
Segundo o censo americano de 2000, a sua população era de 1970 habitantes.
Em 2006, foi estimada uma população de 1923, um decréscimo de 47 (-2.4%).

## Geografia
De acordo com o United States Census Bureau tem uma área de
1,2 km², dos quais 1,2 km² cobertos por terra e 0,0 km² cobertos por água.

## Localidades na vizinhança
O diagrama seguinte representa as localidades num raio de 4 km ao redor de Laurel Springs.

wikiname: ptwiki

title: Laurel Springs

in_language: pt

wikitext:
{{Info/Localidade dos EUA|
|nome       = Laurel Springs
|imagem     = 2018-10-01 10 06 52 View west along U.S. Route 30 (White Horse Pike) at Madison Avenue along the border of Laurel Springs and Lindenwold in Camden County, New Jersey.jpg
|imagem_legenda =
|estado     = Nova Jérsei
|condado    = [[Condado de Camden (Nova Jérsei)|Condado de Camden]]
|população  = 1923
|data_pop   = 2006
|área       = 1.2
|área_água  = 0.0
|latG       = 39
|latM       = 49
|latS       = 19
|latP       = N
|lonG       = 75
|lonM       = 0
|lonS       = 15
|lonP       = W
|coord_título = s
|altitude   =
|códigoFIPS = 39210
|tipo       = distrito
|mapa_detalhado=
}}
'''Laurel Springs''' é um [[distrito]] localizado no [[Estados dos Estados Unidos da América|estado]] [[Estados Unidos da América|americano]] de [[Nova Jérsei]], no [[Condado de Camden (Nova Jérsei)|Condado de Camden]].

== Demografia ==
Segundo o [[Censo demográfico|censo]] americano de 2000, a sua população era de 1970 [[habitante]]s.<ref>{{Citar web |url=http://www.census.gov/Press-Release/www/2001/sumfile1.html |titulo=U.S. Census Bureau. Census 2000 Summary File 1 |acessodata=2007-10-10 |arquivourl=https://web.archive.org/web/20100111104338/http://www.census.gov/Press-Release/www/2001/sumfile1.html |arquivodata=2010-01-11 |urlmorta=yes }}</ref>
Em 2006, foi estimada uma população de 1923,<ref>[http://www.census.gov/popest/datasets.html U.S. Census Bureau. Estimativa da população (julho de 2006)]</ref> um decréscimo de 47 (-2.4%).

== Geografia ==
De acordo com o '''[[United States Census Bureau]]''' tem uma [[área]] de
1,2 km², dos quais 1,2 km² cobertos por terra e 0,0 km² cobertos por [[água]].

== Localidades na vizinhança ==
O diagrama seguinte representa as [[localidade]]s num [[raio]] de 4 km ao redor de Laurel Springs.

[[Ficheiro:Blank map.svg|400px|left|Localidades na vizinhança]]
{{Image label|x=0.5|y=0.5|scale=400|text=[[Ficheiro:Map pointer black.svg|20px|Laurel Springs]]'''Laurel Springs'''}}
{{Image label|x=0.692|y=0.701|scale=400|text=[[Ficheiro:Small-city-symbol.svg|14px|Localidades com 4986 habitantes (2000)]][[Clementon (Nova Jérsei)|Clementon]] (2 km)}}
{{Image label|x=0.545|y=0.174|scale=400|text=[[Ficheiro:Small-city-symbol.svg|18px|Localidades com 10440 habitantes (2000)]][[Echelon (Nova Jérsei)|Echelon]] (3 km)}}
{{Image label|x=0.839|y=0.354|scale=400|text=[[Ficheiro:Small-city-symbol.svg|10px|Localidades com 2435 habitantes (2000)]][[Gibbsboro (Nova Jérsei)|Gibbsboro]] (3 km)}}
{{Image label|x=0.348|y=0.312|scale=400|text=[[Ficheiro:Small-city-symbol.svg|10px|Localidades com 1029 habitantes (2000)]][[Hi-Nella (Nova Jérsei)|Hi-Nella]] (2 km)}}
{{Image label|x=0.631|y=0.545|scale=400|text=[[Ficheiro:Small-city-symbol.svg|20px|Localidades com 17414 habitantes (2000)]][[Lindenwold (Nova Jérsei)|Lindenwold]] (1 km)}}
{{Image label|x=0.337|y=0.226|scale=400|text=[[Ficheiro:Small-city-symbol.svg|16px|Localidades com 5192 habitantes (2000)]][[Somerdale]] (3 km)}}
{{Image label|x=0.409|y=0.413|scale=400|text=[[Ficheiro:Small-city-symbol.svg|16px|Localidades com 7271 habitantes (2000)]][[Stratford (Nova Jérsei)|Stratford]] (1 km)}}

{{referências}}

== Ligações externas ==
* {{City-data|Laurel-Springs|New-Jersey}}

[[Categoria:Cidades de Nova Jérsei]]

title: Localidade dos Estados Unidos

Localidade dos Estados Unidos: · Laurel Springs Localização de Laurel Springs em Nova Jérsei

Localidade dos Estados Unidos: · Laurel Springs Localização de Laurel Springs nos Estados Unidos

title: Localização

Condado: Condado de Camden

Estado: Nova Jérsei

Tipo de localidade: Distrito

title: Características geográficas

Área: 1,2 km²

- água: 0,0 km²

title: Códigos

Códigos: Portal dos Estados Unidos


text:
# Jaci Jaterê
Jaci Jaterê (também grafado como Jasy Jatere em Guarani e Yasy Yateré em espanhol) é uma importante figura da Mitologia guarani. Um dos sete filhos de Tau e Kerana, as lendas de Yacy Yateré são das mais importantes da cultura das populações que falam o idioma Guarani, na América do Sul.
Com um nome que significa literalmente pedaço da Lua, é único dentre os seus irmãos a não possuir uma aparência monstruosa. Usualmente é descrito como um homem de pequena estatura, ou talvez uma criança, aloirado e às vezes com olhos azuis. Tem uma aparência distinta, algumas vezes descrita como bela ou encantadora, e carrega um bastão ou cajado mágico. Como a maioria de seus irmãos, habita na mata, sendo considerado o protetor da erva-mate. Algumas vezes é visto como protetor dos tesouros escondidos.
Jaci Jaterê também é considerado o senhor da sesta, o tradicional descanso ao meio do dia das culturas latino-americanas. De acordo com uma das versões do mito, ele deixa a floresta e percorre as vilas procurando por crianças que não descansam durante a sesta. Embora seja naturalmente invisível, ele se mostra a essas crianças e aquelas que veem seu cajado caem em transe ou ficam catalépticas. Algumas versões dizem que essas crianças são levadas para um local secreto da floresta, onde brincam até o fim da sesta, quando recebem um beijo mágico que as devolve a suas camas, sem memória da experiência.
Outras são menos claras, onde as crianças são transformadas em feras ou entregues ao seu irmão Ao Ao, uma criatura canibal que se alimenta delas. Muitas lendas Guarani têm muitas versões por serem apenas orais, mas está claro que a intenção é manter as crianças obedientes e sossegadas durante a sesta.
Como já foi dito, o poder de Jaci Jaterê vem de seu bastão mágico, e se alguém for capaz de tirar seu cajado, ele se atira ao chão e chora como uma criança pequena. Neste estado, se alguém perguntar pelos tesouros escondidos, recebe uma recompensa, lenda semelhante ao Leprechaun ou duende europeu.
Alguns estudos associam o Jaci Jaterê à gênese da lenda do Saci Pererê, que por influências africanas e europeias acabou por se distanciar das características originais.

title: Jaci Jaterê

wikitext:
[[Arquivo:Yasy Yatere.JPG|250px|right|thumb|Representação artística contemporânea]]
'''Jaci Jaterê''' (também grafado como '''Jasy Jatere''' em Guarani e '''Yasy Yateré''' em espanhol) é uma importante figura da [[Mitologia guarani]]. Um dos sete filhos de [[Tau (mitologia)|Tau]] e [[Kerana]], as lendas de ''Yacy Yateré'' são das mais importantes da cultura das populações que falam o idioma Guarani, na [[América do Sul]].

Com um nome que significa literalmente ''pedaço da Lua'', é único dentre os seus irmãos a não possuir uma aparência monstruosa. Usualmente é descrito como um homem de pequena estatura, ou talvez uma criança, aloirado e às vezes com olhos azuis. Tem uma aparência distinta, algumas vezes descrita como bela ou encantadora, e carrega um bastão ou cajado mágico. Como a maioria de seus irmãos, habita na mata, sendo considerado o protetor da [[erva-mate]]. Algumas vezes é visto como protetor dos tesouros escondidos.

'''Jaci Jaterê''' também é considerado o senhor da sesta, o tradicional descanso ao meio do dia das culturas latino-americanas. De acordo com uma das versões do [[mito]], ele deixa a floresta e percorre as vilas procurando por crianças que não descansam durante a sesta. Embora seja naturalmente invisível, ele se mostra a essas crianças e aquelas que veem seu cajado caem em [[transe]] ou ficam [[catalepsia|catalépticas]]. Algumas versões dizem que essas crianças são levadas para um local secreto da floresta, onde brincam até o fim da sesta, quando recebem um beijo [[mágico]] que as devolve a suas camas, sem memória da experiência.

Outras são menos claras, onde as crianças são transformadas em feras ou entregues ao seu irmão [[Ao Ao]], uma criatura [[canibal]] que se alimenta delas. Muitas lendas Guarani têm muitas versões por serem apenas orais, mas está claro que a intenção é manter as crianças obedientes e sossegadas durante a sesta.

Como já foi dito, o poder de Jaci Jaterê vem de seu bastão mágico, e se alguém for capaz de tirar seu cajado, ele se atira ao chão e chora como uma criança pequena. Neste estado, se alguém perguntar pelos [[tesouro]]s escondidos, recebe uma recompensa, lenda semelhante ao [[Leprechaun]] ou [[duende]] europeu.

Alguns estudos associam o Jaci Jaterê à gênese da lenda do [[Saci|Saci Pererê]], que por influências africanas e europeias acabou por se distanciar das características originais.<ref>[http://www.ple.uem.br/3celli_anais/trabalhos/estudos_linguisticos/pfd_linguisticos/034.pdf Leitura e Análise Linguística: Narrativa com o mito Saci-Pererê]</ref>

==Referências==
<references/>

==Bibliografia==
*{{citar livro
 | autor     = CASCUDO, Luís da Câmara
 | título    = Dicionário do Folclore Brasileiro
 | subtítulo = Vols. 1 e 2
 | local     = Rio de Janeiro
 | editora   = Edições de Ouro
 | ano       = 1989
 |isbn= 9788526006447
}}
*{{citar livro
 | autor     = PORTO, Idelma Maria Nunes
 | título    = Leitura e análise linguística: narrativa com o mito Saci-Pererê
 | subtítulo = ''in'' III CELLI
 | local     = Maringá
 | ano       = 2009
 | páginas   = 1415-1424
 |isbn= 9788599680056
}}

[[Categoria:Mitologia tupi-guarani]]
[[Categoria:Criaturas fantásticas]]
[[Categoria:Deidades da infância]]


text:
# Meow!
Meow! é um curta-metragem de animação brasileiro de 1981, realizado por Marcos Magalhães. É considerado um dos filmes mais importantes da animação nacional. Foi a primeira vez em que um curta animado brasileiro venceu o Prêmio Especial do Júri do Festival de Cannes. Em 22 de dezembro de 2017, a Associação Brasileira de Críticos de Cinema elegeu Meow! como o terceiro melhor filme de animação brasileiro.

title: Meow!

wikitext:
'''''Meow!''''' é um [[curta-metragem]] de [[animação]] [[brasil]]eiro de 1981, realizado por [[Marcos Magalhães]]. É considerado um dos filmes mais importantes da animação nacional. Foi a primeira vez em que um curta animado brasileiro venceu o Prêmio Especial do Júri do [[Festival de Cannes]].<ref name="continente">{{Citar web |ultimo=Buccini |primeiro=Marcos |autorlink=Marcos Buccini |url=https://revistacontinente.com.br/edicoes/202/cem-anos-da-animacao-brasileira |titulo=Cem anos da animação brasileira |data=2017-10-02 |acessodata=2022-01-17 |website=Revista Continente}}</ref> Em 22 de dezembro de 2017, a [[Associação Brasileira de Críticos de Cinema]] elegeu ''Meow!'' como o terceiro [[Lista dos 100 melhores filmes de animação brasileiros segundo a ABRACCINE|melhor filme de animação brasileiro]].<ref>{{citar web |url=https://abraccine.org/2017/12/22/abraccine-elege-o-menino-e-o-mundo-como-a-melhor-animacao-brasileira/ |título=ABRACCINE elege "O Menino e o Mundo" como a melhor animação brasileira|acessodata=2022-01-03 |data=22 de dezembro de 2017 |publicado=[[Associação Brasileira de Críticos de Cinema]]}}</ref>

{{Referências}}

== Ligações externas ==
*[https://www.itaucultural.org.br/meow ''Meow!''] no [[Itaú Cultural]]

[[Categoria:Filmes do Brasil de 1981]]
[[Categoria:Filmes de animação do Brasil]]