Dynamic SystemsDevelopmentMethod Eduardo C. Zini

Marcelo A. Dantas

Marcelo F. Cruz

MC746 - Prof. Eliane

Sumário

• Histórico

• Princípios

• Ciclo de Vida

• Fases

• Papéis

• Qualidade

• Testes

• Caso de Sucesso

• Conclusões

• Referências

Histórico

• Surgiu em 1994 como uma evolução das ferramentas RAD (Rapid Application Developement).

• Em fevereiro de 1994 foi definida a necessidade de criar um framework de alto nível.

• Foram criados três grupos, um para definir o conteúdo do framework, outro para a definição dos processos e procedimentos, e outro para cuidar do marketing e do gerenciamento.

• Em janeiro de 1997 houve um workshop para decidir que mudanças eram necessárias no método; em outubro de 1997 foi publicada a terceira versão.

• Atualmente estamos na versão 4.2

Histórico (II)

Princípios

1. A participação ativa do usuário é imperativa.

2. A equipe deve ser capaz de tomar decisões.

3. O foco é na freqüente entrega dos produtos.

4. A finalidade do negócio é o critério essencial para a aceitação dos produtos a serem entregues.

Princípios (II)

5. O desenvolvimento iterativo e incremental é necessário para convergir em uma solução exata do negócio.

6. Todas as mudanças durante o desenvolvimento são reversíveis.

7. Requisitos são baseados em alto nível.

8. Testes são integrados durante todo o ciclo de vida.

9. Colaboração e cooperação entre todas as partes interessadas são essenciais.

Ciclo de Vida

Pré-Projeto Pós-Projeto

Fases

1. Pré-projeto: assegura que somente projetos seguros são iniciados e que seus ajustes são feitos corretamente.

2. Estudo das Possibilidades (Negócio): o projeto iniciado começa com um estudo de ‘possibilidades’. Um importante aspecto desse passo é a avaliação de quanto o DSDM é aplicável ao projeto.

3. Iteração do Modelo Funcional: refinamento dos aspectos de negócio do sistema, isto é, construindo um processamento de alto nível e organizando informações dos requisitos identificados durante o estudo do negócio.

Fases (II)

4. Iteração de Projeto e Construção: o sistema é arquitetado para um padrão suficientemente seguro para ser colocado nas mãos do usuário.

5. Implementação: passagem do desenvolvimento para o processo operacional.

6. Pós-projeto: sustenta a solução operacional. A natureza iterativa e incremental do DSDM permite que a manutenção possa ser feita como um contínuo desenvolvimento.

Papéis

• Patrocinador Executivo

• Visionário

• Usuário Embaixador

• Usuário Conselheiro

• Gerente de Projeto

• Coordenador Técnico

• Líder de Equipe

• Desenvolvedor

• Testador

• Anotador

• Facilitador

• Especialista em Papéis

Qualidade

• Seminários (reuniões) eficientes

• Participação contínua e focada do usuário

• Revisões (protótipos ou documentação)

• Testes completos (validação constante de requisitos)

• Gerência de configuração

• Abordagem flexível e não supérflua

• Perigo de perda de foco (focar sempre no business purpose)

• Constante ênfase na validação de requisitos-chave

• Natural refinamento de requisitos

Qualidade (II)

• Planejamento (como a qualidade deve ser checada, quem deve fazê-lo, quem tem autoridade para determinar a aceitação do produto e o que fazer se uma falha for localizada, padrões a aplicar)

• Auditorias (evitar re-trabalho, desperdício de esforço e aspectos supérfluos)

• Experiências reais passadas são um guia

• Requisitos não-funcionais

• Guia da British Standards Institution e DSDM Consortium (TickIt – verificação de cláusula a cláusula)

Testes

• Objetivo assegurar que o sistema seja compatível com todos os requisitos de negócio.

• Testes concentrados nas partes de um sistema que proporcionam os benefícios chaves do negócio é a principal prioridade.

• Teste a cada estágio do processo de desenvolvimento.

• Sempre que possível, o teste deve ser feito por outro que não o criador do software.

Caso de Sucesso

Paul Strassman (consultor de TI americano):

•28% dos projetos são entregues dentro do prazo e do orçamento

•23% falham completamente (e são cancelados)

•49% se perdem em cronograma ou orçamento

-Diretoria de Tecnologias de Informação e Comunicações (ICT) da ABN-AMRO Netherlands decidiu adotar o DSDM.

- Inspiration

- ¾ de todo o dinheiro lucrado pelo banco eram gastos na ICT (desperdício)

Caso de Sucesso (II)

Melhorias alcançadas:

• “time-to-market” aperfeiçoado

• sistemas funcionais desde o início

• sistemas adequados às finalidades

• equipes mais bem treinadas

• sistemas com maior qualidade

• remoção de barreiras entre TI e usuários

• melhorias significativas em produtividade

• sistemas mais bem documentados e projetados

Conclusões

Prós:Gerenciamento Encaminha o projeto para

uma entrega dentro do prazo e orçamento

Permite ‘aviso’ prematuro de possível fracasso no projeto

Gerenciamente de Projeto Baseado em objetivos Processo definido

claramente com pontos regulares de revisão

Negócios e Usuários Proprietário da solução Habilidade de direcionar o

projeto para um melhor benefício nos negócios

Entrega de uma solução funcional em tempo

Desenvolvedores Responsabilidade Oportunidades crescentes Envolvimento do usuário

Conclusões (II)

Contras:

Críticas comuns aos processos ágeis:

Ênfase “insuficiente” na qualidade Pouca documentação Mudança constante nos requisitos durante todo o processo.

Referências

www.dsdm.org

www.dsdm.nl/nl/diensten/suitcase.asp

www.pcsupportadvisor.com/nasample/D1121.pdf

www.codeproject.com/gen/design/dsdm.asp

Risk-Based E-Business Testing Paul Gerrard and Neil Thompson, Artech House; 1st edition (August 2002)