faculdade 7 de setembro – sistemas de informação engenharia de software – prof. ciro coelho...

Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Melhores Práticas

RUP


Desenvolvimento Iterativo


Boas Práticas: Desenvolvimento iterativo

• Por que desenvolver iterativamente?Riscos

Tempo

Requisitos

Projeto

Implementação

Testes / Integração

Cascata atrasa a resolução de riscosCascata atrasa a resolução de riscos



• Por que desenvolver iterativamente?Riscos

Tempo

IterativoIterativo

CascataCascata

Concepção

Elaboração

Construção

Transição


Desenvolvimento cascata atrasa a redução de riscos

Início da integração

100%

Tempo

Pro

gre

ss

o d

o p

roje

to(%

co

dif

ica

do

)

Deadlineoriginal

Fonte: Software Project Management, Walker Royce


Desenvolvimento iterativo antecipa a redução de riscos

100%

Tempo

Pro

gre

ss

o d

o p

roje

to(%

co

dif

ica

do

)

Fonte: Software Project Management, Walker Royce

Ciclo de vida tradicional

Ciclo de vida iterativo



• Benefícios: Desenvolvimento iterativo lida com mudanças– Requisitos mudam

• Os usuários mudam de idéia durante o projeto– o contexto muda

– aprende-se mais sobre o sistema, a tecnologia

– Novas tecnologias podem ser incorporadas• Como o produto é desenvolvido incrementalmente, uma nova

tecnologia pode ser utilizada mesmo com o projeto em andamento



• Benefícios: O sistema é integrado contínua e progressivamente– A integração não ocorre em um grande big-bang no fim do

projeto– Em Cascata, a integração do sistema pode levar 40% do

esforço total no final do projeto– A integração é feita iterativamente em diversas etapas e

trabalha com quantidades pequenas de elementos inicialmente



• Benefícios: Riscos são atacados cedo– Permite lidar e descobrir riscos cedo, ao invés de esperar pela

última etapa do modelo Cascata– Cada iteração percorre todos os fluxos e exercita

• O uso de ferramentas

• A utilidade/limitação dos componentes de prateleira

• As habilidades (treinamento) das pessoas

– Riscos conhecidos serão atacados e provados inofensivos enquanto novos riscos serão descobertos



• Benefícios: Aprendizado e melhoria– As equipes aprendem ao longo do projeto

• Diversas competências e especialidades são exercitadas a cada iteração

• Programadores, analistas, testadores, projetistas, etc. trabalham desde o início

• A necessidade de treinamento adicional ou ajuda externa é detectada cedo



• Benefícios: Aumenta reuso– O sistema é parcialmente projetado/implementado

• Facilita a identificação de partes reutilizáveis– Ao invés de ter de identificar todas as partes comuns de todo o sistema

• Facilita o uso de componentes de prateleira (COTS)– Várias iterações permitem selecionar e validar diversos produtos



• Benefícios: Produto mais robusto– Erros são corrigidos continuamente

• Falhas são detectadas e corrigidas desde as primeiras iterações

– Problemas de desempenho são descobertos cedo, ao invés de identificá-los próximos da entrega

– Funcionalidades críticas têm muitas oportunidades para serem testadas e melhoradas



• Benefícios: Prevê mudanças táticas– Por exemplo, permite lançar um produto com funcionalidades

reduzidas, porém antes do concorrente



• Benefícios: Melhoria contínua de processo– A avaliação ao final da iteração analisa não apenas o

progresso do projeto, mas também aspectos de melhoria de processo ou melhoria organizacional



“Com o modelo Cascata, tudo parecia sob controle até nos aproximarmos da entrega. Até

que tudo desabava. Com a abordagem iterativa, é muito difícil esconder a verdade por

tanto tempo.”


Arquitetura Baseada em Componentes


Boas práticas: Arquitetura baseada em componentes

• O que é arquitetura de software?

– “Organização da estrutura dos componentes mais significativos do sistema

• Que interagem através de interfaces

• São decompostos em componentes menores e outras interfaces.”

– “É o projeto dos elementos que têm papel dominante para qualidades do sistema como desempenho ou extensibilidade, no longo prazo.”

– “Um sistema complexo é mais que a soma de suas partes. Ele deve ter uma estrutura coerente (arquitetura) que unifique e organize as partes para permitir seu crescimento sem aumentar a complexidade.”



• No RUP– A arquitetura deve ser estabilizada na Elaboração

• Através de uma arquitetura implementável– Uma implementação parcial do sistema que demonstra a viabilidade da

arquitetura

– Como documentar a arquitetura? Através de diferentes visõesAtravés de diferentes visões

<<thread>>

<<thread>>

GUI

Negócios

Comunicação

Dados

BD

Aplicação

S.O.

Middleware

Hardware



• No RUP– Visões da arquitetura

• Casos de uso• Visão lógica• Implementação• Processo• Distribuição• GUI• Segurança• Dados• Etc...

Visões recomendadas pelo RUP



• A descrição de arquitetura– Cada visão é um subconjunto dos modelos

• O documento da arquitetura deve ser uma reescrita dos modelos para torná-lo mais fácil de entender

• Stakeholders devem ser capazes de entender a arquitetura

• As visões são abstrações ou simplificações dos modelos que enfatizam as características mais importantes de cada modelo

– Deve ser analisada, projetada, implementada e testada na Elaboração

– Ao final da Elaboração, o arquiteto deve estar apto a afirmar: “Eu sei que posso construir o resto do sistema sem encontrar nenhum problema técnico crítico.”



• Visão de Casos de Uso– Ilustra os casos de uso e cenários arquiteturalmente

importantes• Como toda visão de arquitetura, é um subconjunto do modelo

completo

Extrato

Transferência Login



• Visão Lógica– Ilustra os subsistemas, pacotes ou classes

arquiteturalmente relevantes– Tanto aspectos estruturais como aspectos dinâmicos são

projetados– Pode envolver diagramas de

• Classes• Estados e Interação• Objetos

Financeiro

Estoque

Contabilidade



• Visão Implementação– Captura decisões de implementação

• Diagrama de dependências entre subsistemas (relação de import)

• Organização dos componentes

– Auxilia • Na alocação das equipes (ou terceiros) que realizarão as

atividades

• Na estimativa do tamanho do sistema

• Na descoberta de oportunidades de reuso

Arquivo fonte

<<EXE>>

Executável



• Visão de Processos– Ilustra a decomposição do sistema em termos de processos

relevantes arquiteturalmente– Inclui o mapeamento de classes e subsistemas em

processos e threads– Representado por diagramas de classes e objetos que

contenham processos ou threads

<process>Caixa

Eletrônico

<thread>ControladorGUI

<thread>ConexãoServidor

<thread>ControladorDispositivos



• Visão de Distribuição– Provê entendimento da distribuição física do sistema

através de vários nós da rede– Os objetos responsáveis por controle de processamentos

podem ser alocados a cada nó• A capacidade do nó em processar o objeto e a capacidade de

conexão dos nós (por exemplo, a largura da banda) devem ser considerados

:Contribuinte

:Cliente

:Browser

:ServidorReceita

:ControleTransacao

:Impressora

:ServidorBD

:ControleDeclarações

InternetRedelocal



• Um processo ingênuo para definição de arquitetura– Primeiro, preocupe-se com a infra-estrutura geral

• O sistema deve seguir alguma norma, padrão, política ou lei?

• O sistema tem que se conectar com algum sistema legado?

• Será utilizado algum middleware?

• Quais serão os sistemas operacionais?

• Qual será o SGBD?

• Existe a necessidade de se conectar com um hardware específico? Se sim, quais são seus drivers?

• Descreva os nós e suas conexões (visão de distribuição)

– Apenas um entendimento geral do domínio da aplicação é necessário



• Um processo ingênuo para definição de arquitetura– Depois, preocupe-se com a infra-estrutura específica da

aplicação• Quais os casos de uso mais relevantes?

(Visão de Casos de Uso)

• Quais os processos mais importantes?(Visão de Processos)

• Como o sistema será modularizado (quais são os subsistemas)?

(Visão Lógica)

• Qual a relação dos componentes de implementação e elementos de projeto?

(Visão de Implementação)



• Um processo ingênuo para definição de arquitetura

Aplicações GeraisAplicações Gerais

Políticas

Normas

Leis

Requisitos não-funcionais

Sistemas legados

Padrões

Middleware

SGBD

Sistema Operacional

Drivers

Sistema de rede

Aplicações EspecíficasAplicações Específicas

Visão de Distribuição

Visão de Casos de Uso

Visão de Processos

Visão Lógica

Visão de Implementação



• Um processo ingênuo para definição de arquitetura– A cada projeto o processo pode dar ênfase a aspectos ou

visões diferentes• Depende do projeto

– A arquitetura não é apenas documentada, mas implementada (arquitetura executável)

• A implementação e teste demonstram sua viabilidade

– Desenvolve-se a arquitetura até se adquirir confiança que ela suporta casos de uso

• Hoje

• E suportará novos casos de uso no futuro

– Enquanto a arquitetura não estiver estável, o projeto ainda não tem maturidade para iniciar a fase de Construção



• Arquiteturas não especificam todos os detalhes do sistema– Apenas dão uma perspectiva da organização geral do sistema

– Estão relacionados com a estrutura dos componentes principais (de alto nível) do sistema, seu comportamento e qualidades como

• Usabilidade, desempenho, flexibilidade, reusabilidade, entendimento, extensibilidade, etc.

• As 5 visões podem não ser suficientes e completas em todos os projetos

• Mesmo quando a empresa possui um padrão de arquitetura– Isto não elimina a fase de projeto da arquitetura



• O que é um componente?– "Um pedaço de software

• Não trivial• Substituível • Praticamente independente • Com funcionalidade e escopo bem definidos."

Rational

– Por exemplo: módulo, pacote ou subsistema



• Desenvolvimento baseado em componentes– “Buy, do not build!”

Fred Brooks

• Constrói sistemas através da integração de componentes de software previamente existentes

• Melhora a flexibilidade e manutenibilidade dos sistemas• Potencialmente, reduz os custos de desenvolvimento e permite

“montar” sistemas rapidamente– Aumenta o reuso evitando reescrita de código

Escrita de código(programação)

Escrita de código(programação)

Montagem de software(componentização)

Montagem de software(componentização)



• Componentes comerciais (COTS – Commercial Off-The-Shelf)

Vantagens Desvantagens

Custo previsível (licença) Upgrade freqüente ou upgrade interrompido

Amplamente utilizada, tecnologia madura

Pagamentos adiantados

Disponível imediatamente Taxas freqüentes de manutenção

Existe uma empresa dedicada ao suporte

Dependência com o fornecedor

Independência de hardware/software

Eficiência pode ser sacrificada

Rico em funcionalidades Restrições de funcionalidades



• Componentes comerciais (COTS – Commercial Off-The-Shelf)

Vantagens Desvantagens

Não há controle sobre upgrades ou sobre a manutenção

Algumas (ou várias) funcionalidades podem consumir recursos desnecessariamente

Confiabilidade ou estabilidade podem ser inadequados

Incompatibilidade com outros fornecedores

Fonte: Software Project ManagementWalker Royce



• Queremos o melhor dos dois mundos

ComponentesComponentes

ArquiteturaArquitetura

bem documentada

e definida em termos de



• Arquitetura + Componentes– Uma arquitetura modular permite

• Isolar• Projetar• Desenvolver• Testar• Integrar componentes bem definidos

– Alguns componentes podem ser desenvolvidos para se tornarem reusáveis nos próximos projetos

– Muitos componentes podem ser encontrados na indústria– Evolução no desenvolvimento de software



• Boas arquiteturas são– Flexíveis

• Reuso significativo• Clara divisão de trabalho entre os times• Melhora manutenibilidade e extensibilidade• Encapsulamento de hardware e dependências de sistemas

– Baseadas em componentes• Reuso ou customização de componentes existentes• Escolha de componentes de prateleira• Evolução incremental dos software existentes


Controle de Mudanças


Boas práticas: Controle mudanças

• Contexto atual– Vários desenvolvedores– Diferentes equipes– Equipes em diferentes locais

• Trabalhando juntas– Em várias iterações

– Em vários releases

– Em vários produtos

– Em diferentes plataformas

Sem controle de mudanças, o desenvolvimento pode facilmente degenerar para o caos.



• Deve-se ter procedimentos bem definidos – Melhora a alocação de recursos baseado em determinadas

prioridades ou riscos– Se usado em uma abordagem iterativa, permite contínuo

monitoramento de mudanças e, conseqüentemente, rápida descoberta de problemas



• Benefícios– O fluxo de mudanças de requisitos é bem definido e repetível– Requisição de mudanças permite uma comunicação mais

eficiente– Áreas de trabalho isoladas diminuem as interferências entre

equipes trabalhando em paralelo– Estatísticas sobre taxa de alterações de artefatos fornecem uma

boa métrica para avaliar o status do projeto– A propagação da mudança é avaliada e controlada– Mudanças podem ser mantidas em um sistema robusto e

configurável


Gerência de Requisitos


Boas práticas: Gerência de requisitos

• O que é um requisito?– “Especifica o que deve ser implementado. Descreve o

comportamento do sistema, uma propriedade ou atributo.”Ian Sommervile e Pete Sawyer

(Requirements Engineering – A Good Practice Guide)

– “Uma condição ou capacidade com a qual o sistema deve ter conformidade.”

Rational

• Gerência de requisitos– Abordagem sistemática para

• Levantar, organizar e documentar requisitos• Estabelecer e manter um acordo entre o cliente e os

desenvolvedores a respeito de mudanças de requisitos



• Requisitos e suas dependências

Requisitos

Stakeholders

Documentos da organização

Projeto



• Problemas com requisitos?– Requisitos não são sempre óbvios– Possuem diferentes fontes– Existem diferentes tipos e em diferentes níveis de detalhe– O número de requisitos pode se tornar intratável– Relacionam-se com outros requisitos e outros documentos

e pessoas– Possuem propriedades únicas. Não são todos igualmente

importantes nem fáceis de implementar– Podem estar relacionados a diferentes interesses de

diversos stakeholders– Requisitos mudam



Como contra-atacar?• Analise o problema

– Entenda o problema por trás dos requisitos e proponha soluções em alto nível

– Chegue a um acordo com todos os envolvidos no projeto em relação ao problemas reais da organização e sobre quem são os stakeholders

– Defina o escopo da solução



Como contra-atacar?• Entenda as necessidades dos stakeholders

– Possíveis fontes de requisitos• Clientes, parceiros, usuários, especialistas do domínio

– Temos que descobrir• Quem são os stakeholders

• Como conseguir acesso a eles

• Qual a melhor abordagem para adquirir informações dos stakeholders

– Ao final, uma lista de requisitos ou necessidades é produzida com prioridades relativas entre eles



Como contra-atacar?• Defina o sistema

– Traduzir as necessidades dos stakeholders em um sistema a ser desenvolvido

– Eventualmente pode-se implementar protótipos ou modelos de projeto relacionados aos requisitos mais importantes.

– Produz-se como saída uma descrição do sistema



Como contra-atacar?• Gerencie o escopo do projeto

– A priorização dos requisitos é fundamental• Desenvolvedores devem manter-se focados em tarefas que

atacam riscos ou estabilizam a arquitetura

• O escopo de cada iteração deve ser negociado com os stakeholders para garantir a resolução de riscos o mais cedo possível



Como contra-atacar?• Refine a definição do sistema

– A definição detalhada do sistema deve ser apresentada de forma simples para que os stakeholders entendam, concordem e se comprometam com o documento

– Deve conter• Funcionalidades• Conformidade com padrões, leis, regulamentos• Requisitos não funcionais (usabilidade, confiabilidade,

desempenho, etc.)

– Utilize casos de uso• Contam uma estória de como o sistema será utilizado• Colocam requisitos em um contexto de uso e comunicam

eficientemente requisitos com os stakeholders



Como contra-atacar?• Gerencie mudanças

– Requisitos vão mudar– Mudanças causam

• Trabalho para implementar as mudanças• Impacto em outros requisitos

– Rastreamento • Controle de mudanças é essencial• Requisitos têm que estar estruturados de forma flexível e que

seja fácil de estender• Defina procedimentos claros para mudanças• Identifique quais dependências são importantes rastrear



Como contra-atacar?• Desenvolva baseado em casos de uso

– Ao invés de ter uma lista de requisitos, organize-os na forma de uma estória que conte como se utiliza o sistema (casos de uso)

– Contribui para completude e consistência– Facilita o entendimento e a visualização de um requisito do

ponto de vista do usuário– Casos de uso fazem a ligação entre diversos fluxos

(requisitos, análise e projeto, implementação, teste, planejamento e gerenciamento, implantação)


Modelagem Visual


Boas práticas: Modelagem visual

• O que é um modelo?– Uma simplificação da realidade sob um determinado ponto

de vista• É necessário para auxiliar nosso entendimento de um sistema

complexo

• UML (Unified Modeling Language)– Notação padrão para modelagem de software

• Especificação, visualização, construção e documentação

– Contém diversos diagramas que exploram diferentes perspectivas de um sistema

– Definido através do consórcio OMG (Object Management Group)


Boas práticas: Modelagem visual

• Capturam a estrutura e o comportamento de arquiteturas e componentes

• Mostram como os componentes se encaixam• Podem abstrair ou detalhar componentes de acordo com

o propósito do modelo• Mantém consistência entre projeto e implementação• Promove comunicação não ambígua em comparação

com linguagem natural


Verificação da Qualidade


Boas práticas: Verificação de qualidade

• Qualidade é uma característica identificada por– algo que satisfaz ou excede os requisitos– foi avaliado de acordo com medidas e critérios previamente

definidos– foi produzido por um processo previamente definido



• Qualidade é multi-dimensional– Confiabilidade

• Robustez, uso de recursos, integridade de código e estrutura

– Funcionalidade• Habilidade para executar os casos de uso como especificados

– Desempenho• Tempo de execução do sistema

– Acesso a dados– Chamada de funções– Chamada ao sistema– Carga de dados em ambiente de produção

– Progresso• Casos de uso finalizados ou marcos alcançados

– Variação• Diferenças entre planejado e executado



• Qualidade não pode ser alcançada se não for – Descrita– Medida– Parte de um processo

• Qualidade pode ser medida de formas diversas– As métricas são definidas para se atingir as metas do

projeto, da organização e do cliente

• Qualidade não é atingida por si só– Deve haver um processo implementado, usado e medido

A gerência de qualidade no RUP é implementada em todos os fluxos, fases e iterações.


Melhores Práticas

RUP

faculdade 7 de setembro – sistemas de informação engenharia de software – prof. ciro coelho...

Documents