PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

Transcrição

1 PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software Livre GPSL- Gerência de Padrões e Software Livre 1/52

2 Introdução GPSL- Gerência de Padrões e Software Livre 2/52

3 Processo de Desenvolvimento de Software do DATASUS Um processo: Descreve quem faz o quê, como e quando; Define as atividades de uma equipe e especifica quais artefatos devem ser desenvolvidos. O PDS-DATASUS: Provê linhas gerais para os usuários e desenvolvedores, permitindo o estabelecimento de uma visão comum para os projetos do DATASUS; É baseado no RUP (Rational Unified Process); Sofre evolução constante. Objetivo: Estabelecer um modelo de processo que possa ser adequado e utilizado por diferentes projetos. GPSL- Gerência de Padrões e Software Livre 3/52

4 O que é o Rational Unified Process (RUP)? O RUP é um modelo genérico de processo da Rational Software que fornece uma abordagem disciplinada para produzir e gerenciar software. O RUP captura algumas das melhores práticas do desenvolvimento de software. É fornecido em mídia eletrônica acessível por um navegador (browser). Não define uma metodologia. É uma biblioteca de processos. Fornece atividades, artefatos e guias. É representado através da UML. GPSL- Gerência de Padrões e Software Livre 4/52

5 Características do RUP Iterativo e Incremental. O sistema é construído incrementalmente através de vários mini-projetos que se repetem (iterações). Guiado por casos de uso. A arquitetura de software tem papel central. Planejado com foco na eliminação de riscos. Reduz riscos e aumenta a previsibilidade. GPSL- Gerência de Padrões e Software Livre 5/52

6 As Seis Melhores Práticas GPSL- Gerência de Padrões e Software Livre 6/52

7 As Seis Melhores Práticas As melhores práticas apresentadas aqui são abordagens comprovadamente eficazes no meio comercial que, quando usadas em conjunto, atingem diretamente a raiz dos problemas do desenvolvimento de software. São consideradas melhores práticas não apenas porque podem ser quantificadas precisamente, mas, principalmente, porque são amplamente utilizadas em empresas de sucesso da indústria de software. Desenvolvimento Iterativo. Gerência de Requisitos. Arquitetura Baseada em Componentes. Modelagem Visual. Verificação Contínua da Qualidade. Controle de Mudanças. GPSL- Gerência de Padrões e Software Livre 7/52

8 As Seis Melhores Práticas Desenvolvimento Iterativo: Cada iteração incorpora atividades de modelagem de negócio, requisitos, análise e projeto, implementação, testes e implantação à medida em que o projeto vai evoluindo em suas fases de maturação; A cada iteração um conjunto de produtos é gerado. Benefícios: O desenvolvimento iterativo lida com mudanças; O sistema é integrado contínua e progressivamente; Os riscos são atacados cedo; Permite aprendizado e melhoria contínua do processo; Aumenta o reuso; Gera produtos mais robustos; Prevê a possibilidade de mudanças táticas. GPSL- Gerência de Padrões e Software Livre 8/52

9 As Seis Melhores Práticas Desenvolvimento Iterativo: GPSL- Gerência de Padrões e Software Livre 9/52

10 As Seis Melhores Práticas Desenvolvimento Iterativo: Modelo cascata, atrasa a resolução de riscos. GPSL- Gerência de Padrões e Software Livre 10/52

11 As Seis Melhores Práticas Desenvolvimento Iterativo: GPSL- Gerência de Padrões e Software Livre 11/52

12 As Seis Melhores Práticas Gerência de Requisitos. Forma sistemática de elicitar, organizar, comunicar e gerenciar requisitos em um projeto de desenvolvimento de software; Busca elencar, documentar, e controlar requisitos e suas mudanças ao longo do projeto. Algumas dificuldades na definição de requisitos: Alguns requisitos não são óbvios, podendo vir de várias fontes; Nem sempre estão bem escritos; O número de requisitos pode ser incontrolável, o que dificulta o gerenciamento; Requisitos podem sofrer alterações. GPSL- Gerência de Padrões e Software Livre 12/52

13 As Seis Melhores Práticas Arquitetura Baseada em Componentes. A arquitetura de um sistema de software é sua organização ou estrutura de componentes significantes interagindo entre si através de interfaces, sendo estes compostos por componentes e interfaces sucessivamente menores. No RUP, as atividades de projeto são focadas na arquitetura, e fornecem um modo sistemático para produzi-la e validá-la. O foco principal das iterações iniciais do PDS é produzir e validar a arquitetura do software. Benefícios: Reuso ou customização de componentes existentes; Uso de componentes de prateleira (COTS); Evolução incremental dos software existentes. GPSL- Gerência de Padrões e Software Livre 13/52

14 As Seis Melhores Práticas Modelagem Visual: Permite maior nível de abstração mantendo rigorosa sintaxe e semântica; Compreende a utilização de textos e notações gráficas, como a UML, para descrever o projeto de um sistema; Benefícios: Facilita a comunicação entre a equipe do projeto e usuários; Permite decisões de comunicação sem ambigüidade; Explora e compara alternativas de projeto com um baixo custo; Captura requisitos precisamente; Forma a base para a implementação. GPSL- Gerência de Padrões e Software Livre 14/52

15 As Seis Melhores Práticas Verificação Contínua da Qualidade. A verificação contínua da qualidade envolve a avaliação de versões intermediárias do produto e dos artefatos completados ao final de cada iteração, ao longo de todo projeto; A qualidade é de responsabilidade de todos os membros da organização; Qualidade não pode ser alcançada se não for descrita e medida. O PDS não define um papel específico responsável por atividades de controle de qualidade. A qualidade é controlada por atividades específicas de revisão e avaliação periódicas. Em uma abordagem mais tradicional os testes de integração de um software seriam realizados tardiamente no ciclo de vida. GPSL- Gerência de Padrões e Software Livre 15/52

16 As Seis Melhores Práticas Controle de Mudanças: Definição: Controle de Mudanças é uma forma sistemática de se gerenciar modificações em requisitos, projeto e implementação. Cobre também a importante tarefa de manter a rastreabilidade de defeitos, falhas de entendimentos e comprometimento de projeto bem como associar esta atividade com artefatos específicos. GPSL- Gerência de Padrões e Software Livre 16/52

17 As Seis Melhores Práticas Controle de Mudanças: Descrição: Mudanças sempre ocorrem. O controle de mudanças oferece soluções para as raízes dos problemas da construção de um software: Existe um fluxo de trabalho bem definido e que pode ser repetido para todas as requisição de mudanças; Estatísticas de requisição de mudanças servem como métricas para o desenvolvimento de um software futuro; A propagação de mudança é controlável e calculável. GPSL- Gerência de Padrões e Software Livre 17/52

18 Desenvolvimento Iterativo GPSL- Gerência de Padrões e Software Livre 18/52

19 Desenvolvimento Iterativo O ciclo de vida é dividido em fases e iterações; As fases indicam a maturidade do sistema; Cada fase é dividida em iterações; Os riscos são mitigados mais cedo, porque os elementos são integrados progressivamente; Mudanças de requisitos e táticas são acomodadas; É mais fácil melhorar e refinar o produto, aumentando sua robustez. Testes e integrações são realizados muito mais cedo; Organizações podem aprender a medida em que o ciclo de vida evolui. GPSL- Gerência de Padrões e Software Livre 19/52

20 Desenvolvimento Iterativo O que é uma iteração? Uma seqüência distinta de atividades com baseline e critérios de avaliação planejados, resultando em um produto (release) que pode ser interno ou externo. Fatores que podem alterar a duração e a quantidade das iterações de um projeto: Tamanho, estabilidade e maturidade da empresa; Familiaridade com o processo iterativo Tamanho e simplicidade técnica do projeto; Nível de automação utilizado para manejar código e distribuição de informação. GPSL- Gerência de Padrões e Software Livre 20/52

21 Desenvolvimento Iterativo Fase Espaço de tempo entre dois marcos significativos do projeto, durante o qual objetivos são atingidos, artefatos elaborados e decisões sobre passar ou não para a próxima fase são tomadas. GPSL- Gerência de Padrões e Software Livre 21/52

22 Desenvolvimento Iterativo Fase de Concepção: Objetivos: Estabelecer o escopo do projeto; Determinar os principais casos de uso e cenários; Identificar uma arquitetura candidata de acordo com os cenários principais; Estimar custo de projeto e prazo; Identificar riscos potenciais; Preparar o ambiente de suporte do projeto. GPSL- Gerência de Padrões e Software Livre 22/52

23 Desenvolvimento Iterativo Fase de Concepção: Alguns Artefatos produzidos: Documento de Visão; Modelo de Casos de Uso (10% a 20%); Análise de Riscos; Plano de Desenvolvimento de Software; Glossário. GPSL- Gerência de Padrões e Software Livre 23/52

24 Desenvolvimento Iterativo Fase de Concepção: Critérios de Avaliação: Acordo dos stakeholders quanto ao escopo e às estimativas de custo e prazo; Credibilidade das estimativas, prioridades, riscos e processo de desenvolvimento; Os principais riscos foram identificados e existe uma estratégia de mitigação para cada um. GPSL- Gerência de Padrões e Software Livre 24/52

25 Desenvolvimento Iterativo Fase de Elaboração: Objetivos: Definir, validar e estabelecer uma baseline da arquitetura o mais rápido possível; Refinar o ambiente de suporte; Detalhar o plano para a fase de construção; Demonstrar que a arquitetura escolhida sustenta as características funcionais e não funcionais com um custo e prazo de implementação razoável. GPSL- Gerência de Padrões e Software Livre 25/52

26 Desenvolvimento Iterativo Fase de Elaboração: Alguns Artefatos produzidos: Modelo de Casos de Uso (80% completo); Especificação Suplementar; Documento de Arquitetura de Software; Protótipo executável da arquitetura; Analise de Riscos (revisado); Plano de Desenvolvimento de Software (estabilizado); Material de Suporte. GPSL- Gerência de Padrões e Software Livre 26/52

27 Desenvolvimento Iterativo Fase de Elaboração: Critérios de Avaliação: Visão do produto e requisitos estáveis; Arquitetura estável; Testes e avaliações críticos foram realizados; elementos de maior riscos foram encaminhados e resolvidos; Plano de iteração para a fase de construção foi suficientemente detalhado; Todos os stakeholders concordam que a visão atual pode ser atingida se o plano atual for executado para desenvolver o sistema completo de acordo com o contexto atual da arquitetura; Os gastos com recursos planejados versus realizados até o momento são aceitáveis. GPSL- Gerência de Padrões e Software Livre 27/52

28 Desenvolvimento Iterativo Fase de Construção: Objetivos: Completar o produto de software até que ele esteja pronto para a produção; Minimizar o custo de desenvolvimento otimizando recursos e evitando retrabalhos desnecessários; Atingir qualidade adequada o mais rápido possível; Atingir versões utilizavéis (alfa, beta e outros releases de teste) o mais rápido possível. Alguns Artefatos produzidos: Sistema integrado; Manuais de usuário; Notas de Versão; Plano de Implantação. GPSL- Gerência de Padrões e Software Livre 28/52

29 Desenvolvimento Iterativo Fase de Construção: Critérios de Avaliação: Os critérios de avaliação para a fase de construção envolvem as respostas para as seguintes questões : Esta versão do produto está estável e madura suficiente para ser distribuída para a comunidade de usuários? Todos os stakeholders estão prontos para transição do produto para comunidade de usuários? Os gastos com recursos planejados versus realizados até o momento continuam aceitáveis? GPSL- Gerência de Padrões e Software Livre 29/52

30 Desenvolvimento Iterativo Fase de Transição: Objetivos: Atingir auto-suficiência do usuário quanto ao produto; Obter o consentimento dos stakeholders de que a implementação está completa e consistente de acordo com os critérios de avaliação da visão do produto; Estabilizar o produto final de maneira rápida com custos aceitáveis. Alguns Artefatos produzidos: Versão final do sistema; Aceite Final do Projeto. GPSL- Gerência de Padrões e Software Livre 30/52

31 Desenvolvimento Iterativo Fase de Transição: Critérios de Avaliação: O critério de avaliação para a fase de transição envolvem a resposta para a seguinte questão: O usuário esta satisfeito? GPSL- Gerência de Padrões e Software Livre 31/52

32 Elementos do PDS GPSL- Gerência de Padrões e Software Livre 32/52

33 Elementos Chave do PDS Papéis São as responsabilidades de um indivíduo ou grupo. Definem O quem (Ex.: Analista de Sistemas, Projetista, Arquiteto, Gerente do Projeto). Artefatos Pedaço de informação que é produzido,modificado ou usado por um processo. Definem O quê (Ex.: documentos, diagramas, código-fonte, executável). Atividades São unidades de trabalho que produzem um resultado de valor significativo para o projeto. São realizadas por um papel específico e são compostas de: objetivos, passos, entradas e saídas, guias e padrões. Definem O como. Fluxos de Atividades Representam uma seqüência de atividades correlacionadas e mostram as interações entre os papéis. O PDS utiliza o Diagrama de Atividades para representar o workflow de uma disciplina. Definem O quando. GPSL- Gerência de Padrões e Software Livre 33/52

34 Estrutura Estática Disciplinas Agrupam as atividades correlacionadas, especificando o que deve ser feito pelos papéis, em termos de atividades e artefatos, através dos Fluxos de Atividades. Fluxo de Atividades Detalhe de Fluxo de Atividades GPSL- Gerência de Padrões e Software Livre 34/52

35 Elementos Adicionais do PDS Modelos São modelos de artefatos. O PDS possui templates para a maior parte dos artefatos gerados pelas atividades. GPSL- Gerência de Padrões e Software Livre 35/52

36 Disciplinas GPSL- Gerência de Padrões e Software Livre 36/52

37 Disciplinas GPSL- Gerência de Padrões e Software Livre 37/52

38 Disciplina Planejamento e Gerência Objetivos: Prover um framework para gerência de projetos de software; Guia o planejamento, a execução e o monitoramento do projeto; Prover um framework para gerenciar riscos. O fluxo de atividades foca nos aspectos específicos de um processo de desenvolvimento iterativo e incremental : Planejar o projeto e uma iteração em particular (2 níveis de planos - fases e iteração); Gerenciar riscos; Monitorar o progresso e as métricas de um projeto iterativo; Não cobre todos os aspectos da gerência de projetos: gestão de pessoas, orçamentária e de contratos, por exemplo. GPSL- Gerência de Padrões e Software Livre 38/52

39 Disciplina Modelagem do Negócio Objetivos: Permitir um entendimento da estrutura e da dinâmica da organização na qual o sistema está inserido; Fornecer uma visão dos problemas da organização e identificar oportunidades de melhoria em seus processos de negócio; Garantir que os usuários, clientes e desenvolvedores tenham um entendimento comum dos processos de negócio da organização; Derivar os requisitos de sistema necessários para suportar os negócios da organização. GPSL- Gerência de Padrões e Software Livre 39/52

40 Disciplina Requisitos Objetivos: Estabelecer e manter um entendimento comum entre os usuários e desenvolvedores sobre o quê o sistema deve fazer e por quê; Definir o escopo do sistema; Prover uma base para planejamento das iterações; Prover uma base para estimativa de custos e tempo de desenvolvimento; Definir uma interface para o sistema focando nas necessidades dos usuários. GPSL- Gerência de Padrões e Software Livre 40/52

41 Disciplina Análise e Projeto Objetivos: Traduzir os requisitos do sistema em uma especificação que descreva como implementá-lo: A atividade de Análise transforma as especificações de requisitos dirigidos por casos de uso em um conjunto de classes e seus relacionamentos e contempla alguns diagramas (Diagrama de Classes, de Seqüência); A atividade de Projeto refina o modelo gerado na análise, incorporando elementos de projeto (novas classes, detalhamento dos atributos e métodos, definição de subsistemas e elementos da arquitetura) e define as tabelas do banco de dados; GPSL- Gerência de Padrões e Software Livre 41/52

42 Disciplina Implementação Objetivos: Construir, testar e manter de forma mais eficiente possível os componentes que implementam os requisitos do sistema. Definir uma estrutura de implementação através da organização dos artefatos de implementação, definição da dependência entre os componentes e estrutura de diretórios; Implementar componentes e testá-los (testes de unidade); Integrar componentes implementados em subsistemas; Integrar os diversos subsistemas no sistema. GPSL- Gerência de Padrões e Software Livre 42/52

43 Disciplina Teste A disciplina de Teste do PDS, está descrita detalhadamente no Processo de Teste de Software (PTS). O PTS integra técnicas de testes, procedimentos e ferramentas para avaliação da qualidade do software desenvolvido no DATASUS. GPSL- Gerência de Padrões e Software Livre 43/52

44 Disciplina Implantação Objetivos: Garantir que o produto de software seja disponibilizado a seus usuários finais. Gerenciar os testes dos usuários e de aceitação; Empacotar, distribuir e instalar o produto; Treinar os usuários; Migrar e/ou converter sistemas e bases de dados legados. Muito dependente do contexto do negócio e do produto. GPSL- Gerência de Padrões e Software Livre 44/52

45 Disciplina Gerência de Configuração e Mudanças Objetivos: Gerenciar e controlar a evolução do software através do controle formal de versão e de solicitações de mudanças, mantendo a integridade dos artefatos do projeto; Prover e gerenciar um espaço de trabalho (repositório) para armazenar os artefatos que terão controle de versão, identificando as versões existentes e o histórico de mudanças dos mesmos; Controlar as requisições de mudanças, mantendo informações sobre as razões e motivações para cada uma delas, além de: artefatos que serão afetados, status (nova, aprovada, reprovada) e o impacto das mesmas no projeto. GPSL- Gerência de Padrões e Software Livre 45/52

46 Papéis GPSL- Gerência de Padrões e Software Livre 46/52

47 Papéis Analistas Analistas: Analista de Negócio Analista de Sistemas GPSL- Gerência de Padrões e Software Livre 47/52

48 Papéis Desenvolvedores Desenvolvedores: Arquiteto Integrador Programador Projetista de Banco de Dados GPSL- Gerência de Padrões e Software Livre 48/52

49 Papéis Gerentes Gerentes: Comitê de Controle de Mudança Gerente de Configuração Gerente de Implantação Gerente de Projeto GPSL- Gerência de Padrões e Software Livre 49/52

50 Papéis Outros Outros Papéis: Escritor Técnico Stakeholders GPSL- Gerência de Padrões e Software Livre 50/52

51 Maiores Informações Site: GPSL- Gerência de Padrões e Software Livre 51/52