Dynamic Systems Development Method

Apresentação em tema: "Dynamic Systems Development Method"— Transcrição da apresentação:

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 Sumário dos tópicos a serem abordados na apresentação.

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 Uma breve descrição do surgimento do processo e de suas evoluções ao longo do tempo. O ponto principal a ser considerado é a necessidade que as empresas possuíam -- na época da criação do processo -- de criar-se um Framework RAD (Rapid Application Development). Para tal, elas se uniram e conjuntamente desenvolveram e promoveram tal Framework (formação do Consórcio). O Consórcio: Trata-se de uma organização sem fins lucrativos que administra o Framework DSDM. Ele supervisiona a licença para o uso do Framework, onde apenas full members possuem licença para usá-lo em projetos (internos e/ou externos). A missão do Consórcio é continuamente desenvolver e promover o Framework. O objetivo é traduzir essa evolução em produtos e serviços que outros membros possam usar para entregar soluções que melhor se adequam às suas necessidades. Todos os membros do Consórcio são convidados a se envolverem na evolução do Framework. O Consórcio Internacional fia no Reino Unido, mas existem Consórcios independentes no Benelux, França, América do Norte, Suécia e Dinamarca.

4 Histórico (II) O diagrama contém a evolução do processo, mostrando as diversas versões que foram lançadas ao longo dos anos.

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. Utilizando-se o processo DSDM, alguns princípios são considerados e seguidos durante todo o desenvolvimento: A participação ativa do usuário é imperativa: o DSDM utiliza uma abordagem tal que ele se torna uma aproximação centrada no usuário. O usuário possui uma participação ativa durante todo o ciclo de vida. 2. A equipe deve ser capaz de tomar decisões: uma equipe DSDM é composta por desenvolvedores e usuários, onde as decisões devem ser feitas com base nos requisitos refinados ou alterados. Não há necessidade de recorrer-se ao alto gerenciamento  a tomada de decisão é rápida. 3. O foco é na frequente entrega dos produtos: a equipe produz produtos concordados com o ciclo de vida e escolhe a melhor aproximação para alcançar os objetivos. O foco é colocado na entrega, não apenas nas atividades. 4. A finalidade do negócio é o critério essencial para a aceitação dos produtos a serem entregues: “construa o produto certo antes de construí-lo direito.” Para o DSDM encontrar a necessidade do negócio é mais importante do que a perfeição técnica.

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. Continuação dos princípios DSDM... 5. Desenvolvimento iterativo e incremental é necessário para convergir em uma solução exata do negócio: o DSDM permite que as soluções emerjam incrementalmente. Nele os desenvolvedores devem fazer uso total do feedback do usuário. Soluções parciais podem ser entregues para satisfazer-se necessidades imediatas. 6. Todas as mudanças durante o desenvolvimento são reversíveis: todo produto deve estar num estado conhecido o tempo todo. Se uma aproximação não funciona, deve ser possível voltar atrás. A equipe, assim, deve ser capaz de encarar mudanças e não ser defensiva. 7. Requisitos são baseados em alto nível: deve-se concordar com a finalidade e escopo do sistema. Além disso, as Baselines devem ser feitas em um nível que permita uma investigação detalhada das exigências da fase anterior. 8. Testes são integrados durante todo o ciclo de vida: os testes não devem ser apenas uma fase separada no fim do processo: o sistema é testado e revisado incrementalmente por desenvolvedores e usuários. Além do mais, testes evoluem com a maturação de protótipos. O alvo principal é encontrar e reparar erros assim que possível. 9. Colaboração e cooperação entre todas as partes interessadas são essenciais: todos trabalham juntos como uma equipe. Deve-se compartilhar os objetivos para que se alcance os objetivos do negócio. Todas as partes devem estar envolvidas e não apenas o núcleo. “Dê e faça de todos os lados”.

7 Ciclo de Vida Pré-Projeto Pós-Projeto
O ciclo de vida é composto por algumas fases (as fases em si serão melhores detalhadas na seção seguinte), onde algumas delas pode ser subdividida: 1. Pré-projeto 2. Praticidade/Negócio 3. Iteração do Modelo Funcional Essa fase tem como subfases: Identificação, criação, revisão e aprovação do protótipo funcional. 4. Iteração de Projeto e Construção Essa iteração possui como subfases: Identificação, criação, revisão e aprovação do Protótipo de Design. 5. Implementação Aqui temos como subfases: Implementação, criação do guia do usuário, revisões de negócio e treinamento do usuário. 6. Pós-Projeto O fluxo normal desse ciclo, conforme mostrado na figura desse slide, é a ordem crescente desses itens listados acima (setas amarelas e brancas na figura). Em caso de necessidade, a volta entre as fases adjacentes é permitida (setas azuis) depois disso retornando ao fluxo normal.

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. Inicia a apresentação das fases de um ciclo DSDM: 1 – Pré-Projeto Essa fase assegura que os prazos do projeto são factíveis e que os contratos estão devidamente acertados. 2 – Estudos das Possibilidades Essa fase estuda a aplicabilidade do DSDM ao projeto, se todas as suas fases são necessárias e realiza a extração dos requisitos de negócio. 3 – Iteração do Modelo Funcional Essa fase agrupa os requisitos de negócio da fase anterior em um processamento de mais alto nível organizando melhor as informações coletadas.

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. 4 – Iteração do Projeto e Construção Esse é o passo onde a arquitetura do sistema é definida e modelada, como decisões de Design e Diagramação. 5 – Implementação Essa é a fase onde o Design é implementado e testado. 6 – Pós-Projeto Validação do Sistema e Correção de Defeitos.

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 Temos como descrição dos papéis: • Patrocinador Executivo (Sponsor) – É quem paga o projeto e tomas as decisões de negócio. • Visionário – Responsável por assumir um projeto já iniciado. • Usuário Embaixador – Usuário atuante na área de negócio a ser desenvolvida. • Usuário Conselheiro – É o usuário que tem o conhecimento do que está sendo automatizado. • Gerente de Projeto – Pode ser usuário ou da área de TI. • Coordenador Técnico – Situa-se acima do time de desenvolvimento. • Líder de Equipe – Trabalha pra manter a equipe sincronizada e trabalhando como um todo. • Desenvolvedor – É quem modela, interpreta e implementa os requisitos de negócio. • Testador – Faz os testes que não são do usuário. • Anotador – Toma nota dos acontecimentos de reuniões e inspeções. • Facilitador – Gerencia as reuniões e inspeções. • Especialista em Papéis - Pode ser o Arquiteto de Negócio, Gerenciador de Qualidade, Integrador do Sistema...

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 Espera-se que o próprio processo DSDM agregue qualidade ao processo, uma vez que esta, do ponto de vista do usuário, é definida em termos do modo que o sistema provê suporte e funcionalidades esperados ("fitness for purpose"). Dado que um dos princípios básicos do DSDM é o "fitness for business purpose", ou seja, a busca pelo sistema funcionalmente ideal para o problema proposto (e a ênfase nos pontos-chave do sistema), é esperado que o processo DSDM gere, 'naturalmente', sistemas computacionais de alta qualidade. É muito importante que a abordagem da empresa para a qualidade do projeto seja flexível suficiente para ir de encontro às necessidades de um projeto DSDM. Se for muito rigorosa, como por exemplo, definindo ações que devem ser tomadas, ou registros que devem ser mantidos, sem foco nos benefícios que isso trará ao projeto, certamente este irá perder seu foco (business purpose).

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) Apesar do uso apropriado do DSDM praticamente assegurar sua qualidade, é necessário um planejamento de testes para definição de papéis dos membros do projeto para que apliquem determinados mecanismos e técnicas. Esse planejamento de qualidade deve ser parte integral da atividade de planejamento do projeto, e deve cobrir escalas de tempo, recursos, métodos de relatórios, controles de gerenciamento, etc. Algumas corporações preferem não separar a qualidade do projeto do desenvolvimento em si, para evitar sua 'subvalorização'. - Requisitos não-funcionais Os requisitos não-funcionais terão impacto significante no grau nos quais os controles de qualidade devem ser aplicados aos produtos. Todos ele devem ser cuidadosamente examinados para se verificar seu impacto no desenvolvimento e o rigor que deve ser definido para cada tipo de teste. Requisitos relacionados a performance, confiabilidade, segurança e manutenibilidade têm enorme importância em projetos que devem ser entregues rapidamente. A decisões devem ser tomadas no começo do projeto para que se saiba o que deve ser feito prioritariamente e o que pode ser deixado pra depois.

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. Contém apenas um resumo dos pontos-chave no processo de teste.

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) Seguindo a abordagem DSDM na ABN AMRO Netherlands, um Centro de Conhecimento foi criado apoiado em treinamento em um Help Desk. Nasceu o ‘Inspiration’, programa de melhorias constantes no processo de software, na cultura dos funcionários e no suporte aos gerentes e funcionários.

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 Após a adoção do DSDM o ABN-AMRO Bank atingiu muitas metas previstas anteriormente, incluindo alguns aspectos listados acima, como relevante melhoria de qualidade de seus sistemas.

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 Apresentamos aqui alguns benefícios que o processo DSDM pode trazer no desenvolvimento (para as diversas partes constituintes) de um negócio: Gerenciamento em geral: o DSDM é colocado no sentido que deve-se seguir sempre uma linha de direção durante todo o desenvolvimento: entrega dentro do prazo e orçamento. Dessa maneira permiti-se também que haja um alerta prematuro quanto a um possível fracasso. Gerenciamento de projeto: o desenrolar do processo é sempre realizado baseando-se em objetivos. As metas a serem alcançadas são claramente definidas e pontos de revisão, para posteriores análises, são registrados regularmente. Negócios e usuários: utilizando-se DSDM possui-se sempre a propriedade da solução e pode-se assim haver o direcionamento do projeto para um melhor benefício em termos de negócio. Além disso consegue-se a entrega de uma solução funcional em tempo. Desenvolvedores: para desenvolvedores o DSDM permite que haja sempre uma responsabilidade para com suas atribuições. O envolvimento do usuário auxilia o trabalho dos desenvolvedores, pois estes podem esclarecer quaisquer adversidades de maneira direta com aquele. Além do mais o DSDM permite oportunidades crescentes para que o desenvolvedor possa evoluir constantemente.

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. Algumas críticas se referem aos processos ágeis de modo geral. Estes vão, em alguns aspectos, totalmente contra algumas práticas comuns aos processos mais ‘burocráticos’ e demorados, que são ditos mais confiáveis.

18 Referências www.dsdm.org www.dsdm.nl/nl/diensten/suitcase.asp
Risk-Based E-Business Testing Paul Gerrard and Neil Thompson, Artech House; 1st edition (August 2002)