problemas e práticas recomendadas - facom | faculdade de ...bacala/mds2011/mds2.pdf ·...
TRANSCRIPT
![Page 1: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/1.jpg)
Problemas e Práticas Recomendadas no
Desenvolvimento de Software
![Page 2: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/2.jpg)
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
![Page 3: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/3.jpg)
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
![Page 4: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/4.jpg)
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
![Page 5: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/5.jpg)
Desenvolvimento de software com UML5
O que fazer?
Seguir um conjunto de práticas e orientações para minimizar os problemas encontrados
![Page 6: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/6.jpg)
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
![Page 7: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/7.jpg)
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
![Page 8: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/8.jpg)
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
![Page 9: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/9.jpg)
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
![Page 10: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/10.jpg)
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
![Page 11: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/11.jpg)
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
![Page 12: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/12.jpg)
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
![Page 13: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/13.jpg)
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
![Page 14: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/14.jpg)
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
![Page 15: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/15.jpg)
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
![Page 16: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/16.jpg)
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
![Page 17: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/17.jpg)
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!
![Page 18: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/18.jpg)
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
![Page 19: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/19.jpg)
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
![Page 20: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/20.jpg)
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
![Page 21: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/21.jpg)
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
![Page 22: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/22.jpg)
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
![Page 23: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/23.jpg)
Desenvolvimento de software com UML23
Prática 4: Modelagem visual
Facilita entendimento Facilita comunicação entre a
equipe Diminui ambigüidade Permite rastreabilidade
![Page 24: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/24.jpg)
Desenvolvimento de software com UML24
UML Linguagem para especificar, modelar e
documentar os artefatos de um sistema Padrão de mercado
![Page 25: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/25.jpg)
Desenvolvimento de software com UML25
Modelagem Visual usando Diagramas UML
Fonte: Rational
![Page 26: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/26.jpg)
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
![Page 27: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/27.jpg)
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
![Page 28: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/28.jpg)
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
![Page 29: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/29.jpg)
Desenvolvimento de software com UML29
Testes precisam ser automatizados
Fonte: Rational
![Page 30: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/30.jpg)
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
![Page 31: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/31.jpg)
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
![Page 32: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/32.jpg)
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
![Page 33: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/33.jpg)
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
![Page 34: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/34.jpg)
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
![Page 35: Problemas e Práticas Recomendadas - FACOM | Faculdade de ...bacala/MDS2011/MDS2.pdf · Desenvolvimento de software com UML20 Prática 3: Arquitetura baseada em componentes Arquitetura](https://reader033.vdocuments.pub/reader033/viewer/2022050115/5f4bf9ae1d21e95cc83d152b/html5/thumbnails/35.jpg)
Desenvolvimento de software com UML35
Resultado: Diminuição dos
problemas Maior sucesso nos
projetos tempo orçamento funcionalidade