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.

Modelo do processo DSDM de Desenvolvimento de Software

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é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 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 mais a frente neste tópico.

Diagrama de processo do ciclo de vida de um projeto DSDM

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 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.
	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.
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.
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

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. 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.

Modelo de Metadados da Iteração do Modelo Funcional

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.

Modelo 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).
	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.
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.
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.
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 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 [1].
• 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é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 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.

Exemplo de um mapa geológico de informação do Metamodelo, com 4 tipos de metaobjetos, and their self-references.

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.

Ver também

• Desenvolvimento ágil de software
• Programação extrema
• Desenvolvimento iterativo e incremental
• Método MoSCoW
• IBM Rational Unified Process
• Rapid Application Development
• Princípio de Pareto (regra 80/20)
• PRINCE2
• Scrum
• Método de Análise Estruturada de Sistemas
• Test Driven Development
• Lean manufacturing
• 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 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

Ligações externas

• The DSDM Consortium
• Dynamic System Development Method by Benjamin J. J. Voigt, Zurich, 2004.