Post on 18-Apr-2015
Problemas e Práticas Recomendadas no
Desenvolvimento de Software
Desenvolvimento de software com UML 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 UML 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 UML 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 UML 5
O que fazer?
Seguir um conjunto de práticas e orientações para minimizar os problemas encontrados
Desenvolvimento de software com UML 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 UML 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 UML 8
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
Desenvolvimento de software com UML 9
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
Desenvolvimento de software com UML 10
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitosArquitetura baseada
em componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
Desenvolvimento de software com 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 UML 12
Desenvolvimento cascata atrasa redução de riscos
RequirementsAnalysis
Design
System Testing
Code & UnitTesting
SubsystemTesting
T E M P O
RISCO
Fonte: Rational
Desenvolvimento de software com UML 13
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
RA/P
IT/I
R RA/P A/P
I IT/I T/I
Iteração 3Iteração 2Iteração 1
Fonte: Rational
Desenvolvimento de software com UML 14
Desenvolvimento iterativo acelera redução de riscos
RISCO
T E M P O
Modelo Cascata
Iterativo
Iteração | Iteração |Iteração | Iteração |Iteração | Iteração | Iteração |
Fonte: Rational
Desenvolvimento de software com UML 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 UML 16
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitosArquitetura baseada
em componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
Desenvolvimento de software com 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 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 UML 19
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitosArquitetura baseada
em componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
Desenvolvimento de software com 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 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 UML 22
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitosArquitetura baseada
em componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
Desenvolvimento de software com UML 23
Prática 4: Modelagem visual
Facilita entendimento Facilita comunicação
entre a equipe Diminui ambigüidade Permite rastreabilidade
Desenvolvimento de software com UML 24
UML Linguagem para especificar, modelar e
documentar os artefatos de um sistema
Padrão de mercado
Desenvolvimento de software com UML 25
Modelagem Visual usando Diagramas UML
Fonte: Rational
Desenvolvimento de software com UML 26
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitosArquitetura baseada
em componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
Desenvolvimento de software com 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
ImplantaçãoDesenvolvimento
Custo
Fonte: Rational
Desenvolvimento de software com UML 28
Desenvolvimento Iterativo permite a realização de testes contínuos
TEMPO
RA/P
IT/I
R RA/P A/P
I IT/I T/I
Iteração 3Iteração 2Iteração 1
TesteTesteTeste
Fonte: Rational
Desenvolvimento de software com UML 29
Testes precisam ser automatizados
Fonte: Rational
Desenvolvimento de software com UML 30
Automação de Testes reduz Tempo e Esforço
One Manual Test Cycle13,000 Tests 2 Weeks 6 People
TestAutomation
Run More Tests More Often13,000 Test
6 hours1 Person
Fonte: Rational
Desenvolvimento de software com UML 31
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitosArquitetura baseada
em componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
Desenvolvimento de software com 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 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 UML 34
As práticas se complementam
Desenvolveiterativamente
ControlaMudanças
VerificaQualidade
ModelaVisualmente
Usa Arquiteturade Componentes
GerenciaRequisitos
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
Desenvolvimento de software com UML 35
Resultado: Diminuição dos
problemas Maior sucesso nos
projetos tempo orçamento funcionalidade