SLIDE 4

Prévia do material em texto

Aula 04 – Aspectos Gerais de 
Sistemas Distribuídos e 
CMMI
Tema 01 – Sociedade
Conectada
Valter Castelhano de Oliveira
Sumário da Aula
• Sociedade conectada
• Engenharia de Requisitos
• CMMi
• Sistemas Distribuído
1 bilhão de lugares 
conectados
LUGARES
PESSOAS
COISAS
50 bilhões de 
coisas conectadas
5 bilhões de pessoas 
conectadas
Ritmo da Mudança
Em 2018!!!
850 M
PCs and tablets
9.3 BN
Mobile subscriptions
3.3 BN
Smartphone 
subscriptions
6.5 BN
Mobile broadband 
subscriptions
Um mundo conectado é apenas o começo
• Quando uma pessoa se conecta, seu mundo se 
altera.
• Com todo o mundo conectado, nosso mundo se 
altera.
Transformação da Indústria
Digitalização resulta em crescimento de toda a indústria de mídia
EM 2007 PARA 2016
Produtos de Media USD 381 bn  USD 352 bn
Serviços de Media online USD 21.7 bn  USD 104 bn
TOTAL USD 402 bn  USD 456 bn
Uma nova mentalidade
• Novo papel das telecomunicações
• Processamento e armazenamento – Cloud
• 2020: mobile a 1 giga
• 2020: redução consumo petróleo
• Internet das coisas e sensores
• Globalização de oportunidades
• Novos negócios e empreendedorismo
• Capacitação das pessoas
Desenvolvimento de sistemas, aplicativos, etc
Crise: Chaos Report!
Chaos report - http://www.standishgroup.com/
Sucesso projetos
Bem sucedido
Fracassado
Problemático
Pequenos Grandes
Custo desenvolvimento
Projetos pequenos: menos de $1 milhão
Projetos grandes: mais de $10 milliões
Chaos report - http://www.standishgroup.com/
Custo reparo sistema
1
6
10
40
70
500
0 100 200 300 400 500 600
Custo Relativo de correção de problemas
Requisitos
Design
Construção
Teste Des
Teste Aceitaçào
Produção
Et
ap
a 
ci
cl
o 
de
 v
id
a
Carr, J. "Requirements engineering and management: the key to designing quality complex systems", 
TQM Magazine, V12 N6, 2000
Processo de Engenharia de Sistemas
Definição de 
Requisitos
Design do Sistema
Desenvolvimento 
Subsistema
Integração do 
Sistema
Instalação do 
Sistema
Evolução do Sistema
Desativação do 
Sistema
Tema 2
Engenharia de Requisitos
Valter Castelhano de Oliveira
Engenharia de Requisitos
• Processo de estabelecer os serviços que o
consumidor requer do sistema e as restrições
pela quais ele é operado e desenvolvido
• Identificação de objetivos e oportunidades para
o novo sistema (system to-be)
• Definição de funcionalidades, restrições e
responsabilidades do novo sistema
• Registro de tudo em documento
Requisitos
• Níveis de abstração dos requisitos pode variar
desde o nível mais abstrato de serviço ou
desejo, passando por uma restrição do sistema
até um detalhamento funcional de uma
especificação formal
• Podemos ter requisitos com dupla função:
– Base para a oferta de um contrato - deve ser
aberto a interpretação
– Base para o próprio contrato - deve ser
definido em detalhe
Abstração de Requisitos
• Para estabelecer contrato para o desenvolvimento de um
grande projeto, requisito abstrato para não predefinir
uma solução.
• Requisitos redigidos de modo que os diversos
fornecedores possam apresentar propostas, oferecendo,
diferentes maneiras de atender às necessidades do
cliente.
• Contratado, o fornecedor elabora uma definição
detalhada do sistema para o cliente, de modo que o
cliente compreenda e valide o sistema.
• Estas variedades podem ser chamadas de documentos
de requisitos do sistema
Tipos de Requisitos
• Requisitos do usuário
– Linguagem natural e diagramas contendo funções e
restrições do futuro sistema. Redigido para
consumidores
• Requisitos do sistema
– Documento estruturado e detalhado. Escrito como um
contrato entre o cliente e o contratado
• Especificação de Sistema
– Descrição detalhada do sistema, base para o projeto
ou implementação. Escrito para os desenvolvedores
Categorias de Requisitos
• Requisitos Funcionais
– Declarações de funções que o sistema deve fornecer, como o
sistema deve reagir a entradas específicas e como deve se
comportar em determinadas situações. Ex. O sistema fornecerá
telas apropriadas para o usuário ler documentos no repositório
de documentos
• Requisitos não funcionais
– São restrições sobre os serviços ou as funções oferecidos pelo
sistema. Ex: restrições de tempos, processo de desenvolvimento,
padrões, leis e normas, etc.
• Requisitos de domínio
– São requisitos que se originam do domínio de aplicação do
sistema e que refletem características desse domínio. Podem ser
requisitos funcionais ou não funcionais
Requisitos imprecisos
• Requisitos declarados de forma imprecisa pode
causar problemas
• Ambiguidade no registro dos requisitos causa
diferentes interpretações de desenvolvedores e
usuários
• Considere o termo “visualizadores apropriados”
– Intenção do usuário - um visualizador de propósito
específico para cada tipo de documento
– Interpretação do desenvolvedor - Prover um
visualizador em texto que apresenta o conteúdo do
documento
Completude e consistência de requisitos
• Requisitos devem ser completos e consistentes
– Completo: incluir descrições sobre todas as
facilidades requeridas
– Consistente: inexistência de conflitos e contradições
nas descrições das facilidades do sistema
• Na prática é impossível produzir um documento
de requisitos completo e consistente
Requisitos não funcionais
• Definir as propriedades e restrições do sistema.
– Requisitos de produto: velocidade de execução,
confiabilidade, etc
– Requisitos organizacionais: padrões de processo
utilizado, requisitos de implementação, etc
– Requisitos externos: requisitos de
interoperabilidade, requisitos de legislação, etc
• Requisitos não funcionais podem ser mais
críticos que funcionais.
– Se não for satisfeito, o sistema vai ser inútil
Objetivos e requisitos
• Requisitos não funcionais dificuldade para
determinar precisamente
• Requisitos imprecisos podem ser difíceis de
verificar
• Objetivo
– Uma intenção geral como por exemplo fácil de utilizar
• Requisito não funcional verificável
– Uma sentença utilizando alguma medida que pode ser
objetivamente testada
• Objetivos são de grande valor para os
desenvolvedores assim que eles transmitem as
intenções dos usuários do sistema
Exemplo de objetivo e requisito
• Uma meta do sistema
– O sistema deve ser fácil de utilizar por controladores
experientes e deve ser organizado de modo que os
erros dos usuários sejam minimizados
• Um requisito não funcional verificável
– Controladores experientes devem ser capazes de
utilizar todas as funções do sistema depois de um
total de duas horas de treinamento. Depois desse
treinamento, o número médio de erros feitos por
usuários experientes não deve exceder dois por dia
Métricas para requisitos não funcionais
• Velocidade: transações por minuto, tempo de resposta
ao usuário, tempo de refresh de tela
• Tamanho: K bytes
• Facilidade de uso: tempo de treinamento, número de
telas de ajuda
• Confiabilidade: tempo média para falhar, probabilidade
de indisponibilidade, taxa de ocorrência de falhas,
disponibilidade
• Robustez: tempo de reinício após falha, porcentagem de
eventos que causam falha, probabilidade de dados
serem corrompidos
• Portabilidade: número de sistemas alvo, porcentagem de
declarações dependentes de sistema alvo
Requisitos de domínio
• Derivados do domínio da aplicação e descrevem
características do sistema e aspectos que
refletem o domínio
• Domínios disjuntos (especialista e
desenvolvedores).
• Se os requisitos de domínio não são satisfeitos,
o sistema talvez seja não aplicável
• Ex. : Regras físicas, padrões organizacionais,
normas,etc.
Requisitos do usuário
• Requisitos funcionais e não-funcionais devem ser
descritos para que sejam compreensíveis pelos
usuários que não tem conhecimento técnico
• Requisitos do usuário são definidos utilizando
linguagem natural, tabelas e diagrama
Problemas com linguagem natural 
• Falta de clareza
• É difícil ter precisão sem fazer o documento difícil
de ler
• Confusão de requisitos
• Requisitos funcionais e não funcionais podem estar
misturados
• Fusão de requisitos
• Requisitos diferentes podem ser expressos juntos
Como escrever requisitos 
• Utilizar formato padrão
• Utilizar linguagem de maneira consistente.
– “será” para os requisitos necessários
– “deverá” para os requisitos desejáveis
• Utilizar destaques no texto para identificar
partes chaves do requisito
• Evitar o uso de “jargões”
Requisitos de sistema 
• Especificações mais detalhadas dos requisitos
dos usuários
• Serve como base para modelar o sistema
• Deve ser utilizado como parte do contrato do
sistema
• Devem ser expressos utilizando modelos (model
driven)
Requisitos e desenho (design)
• Em princípio os requisitos deveriam descrever o
que o sistema deveria fazer e o projeto deveria
descrever como fazer isso
• Na prática, requisitos e desenho são
inseparáveis
– A arquitetura do sistema pode ser projetada para
ajudar a especificação de requisitos
– O sistema dever interoperar com outros sistemas.
Esta interoperação geram outros requisitos de design
– O uso de um projeto específico pode ser um requisito
do domínio do sistema
Problemas com a especificação de sistema 
em linguagem natural
• Ambiguidade
– Leitores e escritores do requisitos devem interpretar
as palavras da mesma maneira. Linguagem natural é
por natureza ambígua
• Muito flexível
– A mesma coisa pode ser dita de várias maneiras
diferentes na especificação
• Perda de modularização
– Estruturas em linguagem natural são inadequadas
para es
Especificação em linguagem natural 
• Uma forma limitada da linguagem natural deve
ser utilizadas para expressar requisitos
• Isto remove alguns problemas resultantes da
ambigüidade e flexibilidade e impõe um grau de
uniformidade na especificação
• Normalmente suportadas pelo uso de
formulários padrão
Especificações baseadas em 
formulários-padrão 
• Definição da função ou entidade
• Descrição das entradas e de onde elas vem
• Descrição das saídas e para onde elas vão
• Indicação de outras entidades requeridas
• Pré e pós condições (se apropriadas)
• Os efeitos colaterais (se existirem)
Documentos de requisitos 
• Os documentos de requisitos são declarações
oficiais sobre o que é requerido dos
desenvolvedores do sistema
• Deveria incluir ambos uma definição e uma
especificação de requisitos
• Ele NÃO é um documento de projeto. O tanto
quando possível, ele deveria dizer O QUE o
sistema deveria fazer e não COMO deveria fazer
Documentos de requisitos especificam 
Requisitos 
• Especificam o comportamento externo do sistema
• Especificam as restrições de implementação
• Fáceis de serem alterados
• Servem como ferramenta de referência para a
manutenção do sistema
• Gravam registros previstos a respeito do ciclo de vida do
sistema (por exemplo: prever as mudanças)
• Especificam a resposta para eventos não esperados
• Devemos antecipar a formalização dos requisitos.
Tema 3
CMMi
Valter Castelhano de Oliveira
CMMI – Motivação
Principais problemas das organizações durante a
gerência dos seus projetos:
Falta de definição das responsabilidades.
Retrabalho por falta de qualidade.
Problemas com fornecedores.
Falta de conhecimento técnico.
Falta de competências para gerenciar os projetos.
CMMI – Motivação
Falta de uma ferramenta de apoio.
Falta de uma metodologia de apoio.
Mudanças constantes no escopo.
Recursos humanos insuficientes.
Mudanças de prioridade.
Estimativas incorretas.
CMMI – Motivação
Riscos não avaliados corretamente.
Falta de apoio da alta administração.
Problemas de comunicação.
Não cumprimento do orçamento.
Não cumprimento dos prazos.
Influenciadores
Pessoas Tecnologia
Processos
CMMI
O que é o CMMI®?
Capability Maturity Model Integration
1. Qualidade ou estado de ser capaz.
2. Característica ou faculdade de desenvolver 
potencialidade.
3. Facilidade ou potencial para indicar o uso ou o 
desenvolvimento.
CMMI
O que é o CMMI®?
Capability Maturity Model Integration
1. Qualidade ou estado de estar maduro.
2. Estado de adaptação ou ajustamento ao seu próprio
meio.
3. Estado ou condição de pleno desenvolvimento.
CMMI
O que é o CMMI®?
Capability Maturity Model Integration
1. Representação de algo, geralmente em miniatura.
CMMI
Definição
CMMI (Capability Maturity Model Integration – Modelo Integrado de
Maturidade e de Capacidade) é um modelo de maturidade para
melhoria de processo, destinado ao desenvolvimento de produtos e
serviços, composto pelas melhores práticas associadas a atividades
de desenvolvimento e manutenção que cobrem o ciclo de vida do
produto, desde a concepção até a entrega e manutenção
(SEI – Software Engineering Institute, 2006).
Modelos CMMI
Definição
São coleções de melhores práticas e de metas
para melhoria de processos que as organizações
utilizam para avaliar e melhorar seus processos.
As metas e práticas são organizadas em grupos
chamados de "áreas de processo."
Modelo CMMI
CMMI para Aquisição (CMMI-ACQ)
Orientações para as organizações que gerenciam
a cadeia de abastecimento sobre aquisição e
integração de produtos e serviços de forma a
atender às necessidades do cliente.
Foi projetado para as empresas que trabalham
com os fornecedores para montar um produto ou
fornecer um serviço.
Modelo CMMI
CMMI para Desenvolvimento (CMMI-DEV)
Fornece orientações para melhorar a eficácia,
eficiência e qualidade de produtos e
desenvolvimento de serviços.
Foi projetado para empresas que se concentram
no desenvolvimento de produtos e serviços.
Modelo CMMI
CMMI para Serviços (CMMI-SVC)
Fornece orientação às organizações que
estabelecem, gerenciam e prestam serviços que
atendam as necessidades dos clientes e usuários
finais.
Foi projetado para empresas que focam a
criação, gestão e prestação de serviços.
Estrutura do Modelo CMMI
São 22 áreas de processo distribuídas em:
 Quatro categorias.
 Cinco níveis de maturidade.
As metas e práticas são organizadas em grupos
chamados áreas de processo.
CMMI – Visão Geral
Tema 4
Sistemas Distribuídos
Valter Castelhano de Oliveira
Sistemas Distribuídos
Definição
Sistema distribuído é um sistema no qual os
componentes de hardware e software,
localizados em computadores de uma rede,
comunicam e coordenam suas ações somente
pela troca de mensagens (Coulouris).
• Consequências desta definição:
– Concorrência de componentes.
– Ausência de relógio global.
– Falhas independentes.
Sistemas Distribuídos
Definição
• Coleção de computadores independentes
que se apresentam ao usuário como
um único sistema coerente (Tanenbaum).
• Essa definição implica em:
– Máquinas autônomas (camada de software unifica e
torna a visão homogênea).
– Usuários pensam que estão lidando com um único
sistema.
Vantagens dos Sistemas Distribuídos
• Economia
– Aproveitar recursos ociosos; é mais barato ter
vários processadores interconectados do que um
supercomputador.
• Distribuição inerente
– Algumas aplicações são distribuídas por natureza.
• Tolerância a falhas
– Em caso de falha de uma máquina, o sistema
pode sobreviver, mesmo com desempenho
degradado.Vantagens dos Sistemas Distribuídos
• Crescimento incremental
– O poder computacional pode ser aumentado
através da inclusão de novos equipamentos.
• Flexibilidade
– Maior flexibilidade na alocação dos recursos,
permitindo que usuários compartilhem dados,
processamento e dispositivos.
Desvantagens dos Sistemas Distribuídos
• Aplicações mais complexas
– Pouco software de alto nível disponível
para sistemas distribuídos.
• Segurança
– Necessidade de construir mecanismos
para controle de acesso às informações.
• Dependência da rede
– Falhas.
– Capacidade de tráfego insuficiente.
Conceitos de Hardware
• Sistemas distribuídos consistem de
várias CPUs
– Diferentes maneiras de se organizar o
hardware (interconexão e comunicação).
• Classificação
– Multiprocessador (memória compartilhada).
– Multicomputador.
Clusters Computacionais
Definição
Sistema distribuído de computadores
independentes e interligados cujo objetivo é suprir
a necessidade de um grande poder computacional.
Clusters Computacionais
Vantagens:
• Alto desempenho.
• Escalabilidade.
• Tolerância a falhas.
• Balanceamento de carga.
• Independência de fornecedores.
• Baixo custo.
Clusters Computacionais – Tipos
• Alta Disponibilidade e tolerância a
falhas – disponibiliza serviços e recursos de
forma contínua. Usado em base de dados de
missões críticas: correio, servidores de
arquivos e aplicações.
• Balanceamento de carga – distribui o
tráfego de entrada ou requisições de
recursos aos nós que executam os mesmos
programas entre as máquinas que compõem
o cluster. Usado, em geral, em servidores de
web.
Clusters Computacionais – Tipos
• Combinação entre alta disponibilidade e
balanceamento de carga – sistemas ativos por um
longo período de tempo e em plena condição de uso.
Usado em servidores de web que necessitam de alta
disponibilidade, e-mail, notícias ou ftp.
• Processamento distribuído ou processamento
paralelo – aumenta o desempenho das aplicações,
dividindo-as em pequenas tarefas distribuídas entre as
estações. Usado para computação científica ou análises
financeiras, tarefas típicas para exigência de alto poder
de processamento.
Clusters Computacionais – Beowulf
• Não exige uma arquitetura específica, tão pouco
máquinas homogêneas.
• Conexão entre os nós, que pode ser feita por meio
de ethernet.
• Deve haver um ou mais nós mestres (front-end)
para realizar o controle dos nós escravos (back-
end).
• O sistema operacional, baseado em Linux, contendo
todas as ferramentas necessárias para a
configuração do cluster.
Clusters Computacionais – Beowulf
Clusters Computacionais – Beowulf
É necessário que haja um nó mestre (servidor)
que realiza toda a distribuição das tarefas e o
monitoramento do desempenho do cluster.
Clusters Computacionais – OpenMosix
• Distribui processos – ao detectar o alto volume
de processamento, migram as instâncias entre
as máquinas do cluster, sendo processadas
simultaneamente, sem a necessidade de
adaptação do código.
• Diferença: ao invés de quebrar os processos
como em clusters Beowulf, o Mosix realiza
migração.