1 / 18

D ynamic S ystems D evelopment M ethod

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.

adem
Download Presentation

D ynamic S ystems D evelopment M ethod

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Dynamic Systems Development Method Eduardo C. Zini Marcelo A. Dantas Marcelo F. Cruz MC746 - Prof. Eliane

  2. Sumário • Histórico • Princípios • Ciclo de Vida • Fases • Papéis • Qualidade • Testes • Caso de Sucesso • Conclusões • Referências

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

  4. Histórico (II)

  5. Princípios • A participação ativa do usuário é imperativa. • A equipe deve ser capaz de tomar decisões. • O foco é na freqüente entrega dos produtos. • A finalidade do negócio é o critério essencial para a aceitação dos produtos a serem entregues.

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

  7. Ciclo de Vida Pré-Projeto Pós-Projeto

  8. Fases • Pré-projeto: assegura que somente projetos seguros são iniciados e que seus ajustes são feitos corretamente. • 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. • 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.

  9. Fases (II) • 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. • Implementação: passagem do desenvolvimento para o processo operacional. • 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.

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

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

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

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

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

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

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

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

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

More Related