A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Problemas e Práticas Recomendadas no Desenvolvimento de Software.

Apresentações semelhantes


Apresentação em tema: "Problemas e Práticas Recomendadas no Desenvolvimento de Software."— Transcrição da apresentação:

1 Problemas e Práticas Recomendadas no Desenvolvimento de Software

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

3 Desenvolvimento de software com UML3 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

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

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

6 Desenvolvimento de software com UML6 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

7 Desenvolvimento de software com UML7 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

8 Desenvolvimento de software com UML8 Tratando as causas para eliminar os 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 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 CausasSintomas Fonte: Rational

9 Desenvolvimento de software com UML9 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 Boas práticas eliminam as causas Desenvolvimento iterativo Gerência de requisitos Arquitetura baseada em componentes Modelagem visual Verificação de qualidade Controle de mudanças PráticasCausas Fonte: Rational

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

11 Desenvolvimento de software com UML11 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

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

13 Desenvolvimento de software com UML13 Aplicação do modelo cascata iterativamente 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 T E M P O R A/P I T/I RR A/P II T/I Iteração 3Iteração 2Iteração 1 Fonte: Rational

14 Desenvolvimento de software com UML14 Desenvolvimento iterativo acelera redução de riscos RISCORISCO T E M P O Modelo Cascata Iterativo Iteração | Fonte: Rational

15 Desenvolvimento de software com UML15 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

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

17 Desenvolvimento de software com UML17 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!

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

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

20 Desenvolvimento de software com UML20 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

21 Desenvolvimento de software com UML21 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

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

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

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

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

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

27 Desenvolvimento de software com UML27 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 ImplantaçãoDesenvolvimento Custo Fonte: Rational

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

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

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

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

32 Desenvolvimento de software com UML32 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

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

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

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


Carregar ppt "Problemas e Práticas Recomendadas no Desenvolvimento de Software."

Apresentações semelhantes


Anúncios Google