View
20
Download
0
Category
Preview:
DESCRIPTION
D ynamic S ystems D evelopment M ethod. 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. - PowerPoint PPT Presentation
Citation preview
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)
Recommended