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


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


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


O que fazer?

Seguir um conjunto de práticas e orientações para minimizar os problemas encontrados


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


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


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


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


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


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 cascata atrasa redução de riscos

RequirementsAnalysis

Design

System Testing

Code & UnitTesting

SubsystemTesting

T E M P O

RISCO

Fonte: Rational


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


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


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!


Os requisitos direcionam todo o desenvolvimento

Projeto e implementação Gerência de projeto Gerência de mudanças Testes


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


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


Prática 4: Modelagem visual

Facilita entendimento Facilita comunicação entre a

equipe Diminui ambigüidade Permite rastreabilidade


UML Linguagem para especificar, modelar e

documentar os artefatos de um sistema Padrão de mercado


Modelagem Visual usando Diagramas UML

Fonte: Rational


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 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


Testes precisam ser automatizados

Fonte: Rational


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


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


Prática 6: Controle de mudanças

É preciso ter um controle! Uso de uma ferramenta para gerenciar

versões e pedidos de mudanças


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


Resultado: Diminuição dos

problemas Maior sucesso nos

projetos tempo orçamento funcionalidade

problemas e práticas recomendadas - facom | faculdade de ...bacala/mds2011/mds2.pdf ·...

Documents