Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf ·...
Transcript of Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf ·...
Problemas e Práticas Recomendadas no
Desenvolvimento de Software
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
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
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
Desenvolvimento de software com UML5
O que fazer?
Seguir um conjunto de práticas e orientações para minimizar os problemas encontrados
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
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
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
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
Desenvolvimento de software com UML10
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitos Arquitetura baseadaem componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
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
Desenvolvimento de software com UML12
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 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
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 UML14
Desenvolvimento iterativo acelera redução de riscos
RISCO
T E M P O
Modelo CascataIterativo
Iteração | Iteração |Iteração | Iteração |Iteração | Iteração | Iteração |
Fonte: Rational
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
Desenvolvimento de software com UML16
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitos Arquitetura baseadaem componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
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!
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
Desenvolvimento de software com UML19
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitos Arquitetura baseadaem componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
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
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
Desenvolvimento de software com UML22
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitos Arquitetura baseadaem componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
Desenvolvimento de software com UML23
Prática 4: Modelagem visual
Facilita entendimento Facilita comunicação entre a
equipe Diminui ambigüidade Permite rastreabilidade
Desenvolvimento de software com UML24
UML Linguagem para especificar, modelar e
documentar os artefatos de um sistema Padrão de mercado
Desenvolvimento de software com UML25
Modelagem Visual usando Diagramas UML
Fonte: Rational
Desenvolvimento de software com UML26
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitos Arquitetura baseadaem componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
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
Desenvolvimento de software com UML28
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 UML29
Testes precisam ser automatizados
Fonte: Rational
Desenvolvimento de software com UML30
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 UML31
Boas Práticas da Engenharia de Software(recomendadas pela Rational)
Gerência de requisitos Arquitetura baseadaem componentes
Modelagem visual Verificação de qualidade Controle de mudanças
Desenvolvimentoiterativo
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
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
Desenvolvimento de software com UML34
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 UML35
Resultado: Diminuição dos
problemas Maior sucesso nos
projetos tempo orçamento funcionalidade