Problemas e Práticas Recomendadas no Desenvolvimento de Software

Transcrição

1 Problemas e Práticas Recomendadas no Desenvolvimento de Software

2 Objetivos deste módulo Levantar problemas enfrentados na prática do desenvolvimento de software Discutir boas práticas para o desenvolvimento de software Desenvolvimento de software com 2UML

3 Realidade de hoje Grande demanda para desenvolvimento de aplicações não triviais Rápida evolução tecnológica Tempo de desenvolvimento deve ser curto Falta de tempo para amadurecimento dos profissionais Equipes grandes Desenvolvimento de software com 3UML

4 Problemas Software que não atende aos requisitos Software com bugs Tempo e orçamento estourados Grande esforço no trabalho em equipe Desenvolvimento de software com 4UML

5 O que fazer? Seguir um conjunto de práticas e orientações para minimizar os problemas encontrados Desenvolvimento de software com 5UML

6 Problemas encontrados (sintomas) Entendimento não preciso das necessidades dos usuários Dificuldade na mudança de requisitos Módulos que não se encaixam perfeitamente Dificuldade de manutenção de sistemas Descoberta tardia de sérios problemas no projeto Software de qualidade pobre Performance inadequada Membros do time não conseguem acompanhar mudanças Processo de construção de versões não confiável Desenvolvimento de software com 6UML

7 Por que esses problemas acontecem? (causas) Gerência de requisitos insuficiente Comunicação ambígua e insuficiente Arquiteturas frágeis Complexidade dos sistemas Inconsistência entre requisitos, projeto e implementação não detectadas Testes insuficientes Avaliação subjetiva da situação dos projetos Redução de risco tardia (desenv. cascata) Propagação de mudanças descontrolada Automação insuficiente Desenvolvimento de software com 7UML

8 Tratando as causas para eliminar os sintomas Sintomas Causas Entendimento não preciso das necessidades dos usuários Dificuldade na mudança de requisitos Módulos que não se encaixam perfeitamente Dificuldade de manutenção de sistemas Descoberta tardia de sérios problemas no projeto Software de qualidade pobre Performance inadequada Membros do time não conseguem acompanhar mudanças Processo de construção de versões não confiável Gerenciamento de requisitos insuficiente Comunicação ambígua e insuficiente Arquiteturas frágeis Complexidade dos sistemas Inconsistência entre requisitos, projeto e implementação não detectadas Testes insuficientes Avaliação subjetiva da situação dos projetos Redução de risco tardia (desenv. cascata) Propagação de mudanças descontrolada Automação insuficiente Desenvolvimento de software com 8UML Fonte: Rational

9 Boas práticas eliminam as causas Causas Práticas Gerenciamento de requisitos insuficiente Comunicação ambígua e insuficiente Arquiteturas frágeis Complexidade dos sistemas Inconsistência entre requisitos, projeto e implementação não detectadas Testes insuficientes Avaliação subjetiva da situação dos projetos Redução de risco tardia (desenv. cascata) Propagação de mudanças descontrolada Automação insuficiente Desenvolvimento de software com 9UML Desenvolvimento iterativo Gerência de requisitos Arquitetura baseada em componentes Modelagem visual Verificação de qualidade Controle de mudanças Fonte: Rational

10 Boas Práticas da Engenharia de Software (recomendadas pela Rational) Desenvolvimento iterativo Gerência de requisitos Arquitetura baseada em componentes Modelagem visual Verificação de qualidade Controle de mudanças Desenvolvimento de software com 10 UML

11 Prática 1: Desenvolvimento iterativo Diminuir riscos: esclarecendo os requisitos no início do desenvolvimento evitando a descoberta tardia de problemas no projeto, resultando em orçamento ultrapassado e/ou cancelamento de projetos O tempo e dinheiro gastos implementando um projeto incorreto NÃO são recuperáveis Desenvolvimento de software com 11 UML

12 Desenvolvimento cascata atrasa redução de riscos R I S C O Requirements Analysis Design Code & Unit Testing Subsystem Testing System Testing T E M P O Fonte: Rational Desenvolvimento de software com 12 UML

13 Aplicação do modelo cascata iterativamente Iteração 1 Iteração 2 Iteração 3 R A/P I T/I R A/P I T/I R A/P I T/I T E M P O Iterações no início devem atacar maiores riscos Versão executável é produzida ao final de cada iteração Cada iteração inclui integração e teste Desenvolvimento de software com 13 UML Fonte: Rational

14 Desenvolvimento iterativo acelera redução de riscos R I S C O Iterativo Modelo Cascata Iteração Iteração Iteração Iteração Iteração Iteração Iteração T E M P O Desenvolvimento de software com 14 UML Fonte: Rational

15 Características do modelo iterativo Riscos críticos são resolvidos antes que grandes investimentos sejam realizados Permite feedback dos usuários desde cedo Testes e integração são atividades contínuas Pequenos objetivos, foco em curto-prazo Progresso é medido de forma mais concreta Implementações parciais podem ser implantadas Desenvolvimento de software com 15 UML

16 Boas Práticas da Engenharia de Software (recomendadas pela Rational) Desenvolvimento iterativo Gerência de requisitos Arquitetura baseada em componentes Modelagem visual Verificação de qualidade Controle de mudanças Desenvolvimento de software com 16 UML

17 Prática 2: Gerência de requisitos Elicitar, organizar e documentar os requisitos do sistema Avaliar mudanças (impacto) Documentar decisões Entrar em acordo com os usuários Requisitos sempre MUDAM! Desenvolvimento de software com 17 UML

18 Os requisitos direcionam todo o desenvolvimento Projeto e implementação Gerência de projeto Gerência de mudanças Testes Desenvolvimento de software com 18 UML

19 Boas Práticas da Engenharia de Software (recomendadas pela Rational) Desenvolvimento iterativo Gerência de requisitos Arquitetura baseada em componentes Modelagem visual Verificação de qualidade Controle de mudanças Desenvolvimento de software com 19 UML

20 Prática 3: Arquitetura baseada em componentes Arquitetura de Software: definição dos elementos estruturais seus inter-relacionamentos comportamento destes elementos Decisão de como estruturar o projeto Deve levar em consideração os requisitos funcionais e não-funcionais Desenvolvimento de software com 20 UML

21 Prática 3: Arquitetura baseada em componentes Uma boa arquitetura deve ser: flexível (facilitando manutenibilidade e extensibilidade) baseada em componentes módulos devem ser independentes componentes devem ser reutilizados Desenvolvimento de software com 21 UML

22 Boas Práticas da Engenharia de Software (recomendadas pela Rational) Desenvolvimento iterativo Gerência de requisitos Arquitetura baseada em componentes Modelagem visual Verificação de qualidade Controle de mudanças Desenvolvimento de software com 22 UML

23 Prática 4: Modelagem visual Facilita entendimento Facilita comunicação entre a equipe Diminui ambigüidade Permite rastreabilidade Desenvolvimento de software com 23 UML

24 UML Linguagem para especificar, modelar e documentar os artefatos de um sistema Padrão de mercado Desenvolvimento de software com 24 UML

25 Modelagem Visual usando Diagramas UML Desenvolvimento de software com 25 UML Fonte: Rational

26 Boas Práticas da Engenharia de Software (recomendadas pela Rational) Desenvolvimento iterativo Gerência de requisitos Arquitetura baseada em componentes Modelagem visual Verificação de qualidade Controle de mudanças Desenvolvimento de software com 26 UML

27 Prática 5: Verificação de qualidade Defeitos em projetos de software são 10 a 100 vezes mais caros de corrigir na fase de manutenção Custo Desenvolvimento Implantação Fonte: Rational Desenvolvimento de software com 27 UML

28 Desenvolvimento Iterativo permite a realização de testes contínuos Iteração 1 Iteração 2 Iteração 3 R A/P I T/I R A/P I T/I R A/P I T/I TEMPO Teste Teste Teste Desenvolvimento de software com 28 UML Fonte: Rational

29 Testes precisam ser automatizados Desenvolvimento de software com 29 UML Fonte: Rational

30 Automação de Testes reduz Tempo e Esforço One Manual Test Cycle 13,000 Tests 2 Weeks 6 People Test Automation 13,000 Test 6 hours 1 Person Run More Tests More Often Desenvolvimento de software com 30 UML Fonte: Rational

31 Boas Práticas da Engenharia de Software (recomendadas pela Rational) Desenvolvimento iterativo Gerência de requisitos Arquitetura baseada em componentes Modelagem visual Verificação de qualidade Controle de mudanças Desenvolvimento de software com 31 UML

32 Prática 6: Controle de mudanças Como gerenciar vários desenvolvedores, várias iterações, várias versões? Problemas mais comuns: atualização simultânea notificação incompleta múltiplas versões Desenvolvimento de software com 32 UML

33 Prática 6: Controle de mudanças É preciso ter um controle! Uso de uma ferramenta para gerenciar versões e pedidos de mudanças Desenvolvimento de software com 33 UML

34 As práticas se complementam Garante envolvimento dos usuários à medida que os requisitos evoluem Gerencia Requisitos Valida decisões de arquitetura desde cedo Usa Arquitetura de Componentes Desenvolve iterativamente Trata complexidade de projeto/ implementação incrementalmente Mede qualidade desde cedo e freqüentemente Modela Visualmente Verifica Qualidade Fonte: Rational Evolui versões incrementalmente Controla Mudanças Desenvolvimento de software com 34 UML

35 Resultado: Diminuição dos problemas Maior sucesso nos projetos tempo orçamento funcionalidade Desenvolvimento de software com 35 UML