Upload
internet
View
105
Download
0
Embed Size (px)
Citation preview
Técnicas de Desenvolvimento de Sistemas de Software
Aula 1
Processo, Produto e Processos de Engenharia de Software
Processo
processo sm (lat processu)
1 Ato de proceder ou de andar. 2 (...). 3 Concatenação ou sucessão de fenômenos. 4 (...). 5 Série de ações sistemáticas visando a certo resultado.
Processo
PROCESSAMENTOEntrada Saída
Produto (Resultado): - Bem - Serviço
Produto
produto sm (lat productu)
1 Aquilo que é produzido; resultado da produção. 2 Resultado ou rendimento do trabalho físico ou intelectual: Ele vive do produto de seu trabalho.
• Produto é o resultado observável de um processo
Controle de Qualidade
• Primeira Visão: Foco no Produto– Medição no final da linha de produção– Ajustes, correções, reação à reclamações– Ex: medida de Refugo de Produção
• Visão Moderna: Foco no Processo– Medição do final da linha é apenas uma dentre
as realizadas durante todo o processo– Medição Permanente e “Feed-Back”– Prevenção e Melhoria Contínua do Processo– Ex: TQM (Total Quality Managemnent)
Controle de Qualidade Evolução
InspeçãoPós-Produção
Controle Estatístico
Procedimentode Produção
Educaçãodas Pessoas
Otimizaçãode Processos
ProjetoRobusto
Engenharia Simultânea
Avaliação do produto final, depois de pronto
Avaliação dos subprodutos das etapas de produção
Avaliação de todo o procedimento de produção
Avaliação das pessoas envolvidas no processo
Avaliação e otimização de cada processo
Avaliação do projeto de produção
Avaliação da própria concepção do produto
1900
1940
1950
1960
1970
1980
1990
Diagrama de Ishikawa
• Uma das Ferramentas da Qualidade
• Diagrama Causa-Efeito (Espinha de Peixe)
• Quatro M’s influem no Processo
Resultado
MétodoMatéria-Prima
MáquinaMão de Obra
Diagrama de Ishikawa
• Há autores que sugerem variações dos M’s que influem no Processo
Resultado
MétodoMatéria-Prima
MáquinaMão de Obra
Meio Ambiente
Diagrama de Ishikawa
• Resultado é o efeito visível
• As causas agem positiva ou negativamente em cada um dos 4 M´s, levando ao efeito
Resultado Fora do Padrão Estabelecido
MétodoMatéria-Prima
MáquinaMão de Obra
Causa que age negativamente
Causa que age positivamente
Controle de Qualidade
• A simples existência de um processo bem definido não garante resultados dentro dos padrões esperados
• É fundamental que o processo seja continuamente controlado– Medição em todos os pontos do processo– Avaliação da Medidas– Feed-Back– Melhoria do Processo
Processos nas Corporações
• Corporações Tradicionais
• Onde estão os processos ???
Presidência
Financeiro Administrativo Comercial Industrial
Processos nas Corporações
• Corporações Modernas
Financeiro Administrativo Comercial Industrial
Início
Fim:
Resultados
Pontos Intermediários de Medição e Controle
• Dinamismo dos negócios– Competitividade– Produtividade
• Processos acompanham esse dinamismo– Atualização– Melhoria Contínua– Novos mercados e tecnologia
• Software é componente crítico nas corporações modernas
Processos nas Corporações
• Software implica em mudanças
• Software tem que acompanhar o frenesi das corporações modernas
• Software está constantemente sendo melhorado, corrigido e adaptado
• Logo, deve haver um processo para Desenvolvimento de Software
• Logo, não existe dinamismo nos negócios sem Engenharia de Software
Processos nas Corporações
O que é Hardware???
• Tudo que pode ser imutável ou pouco modificado em um sistema computacional é definido como hardware
• Hardware é produto de um processo repetitivo e, em geral, em escala
• Hardware sofre desgaste durante seu ciclo de vida
• Hardware sofre manutenção
Curva de Falhas Hardware
Curva da Banheira
O que é Software??
• Tudo o que tiver que ser mudado em um sistema computacional é definido com software
• Software é desenvolvido por Engenharia e não manufaturado no sentido clássico
• Software não sofre desgaste em seu ciclo de vida
• A maioria dos software é feita sob medida em vez de ser montada a partir de componentes
Produtos de Software
• Segundo Pressman, consistem de:– Instruções – Estruturas de Dados– Documentos
• Três categorias de Produtos de Software:– Básicos, fornecem apoio a outros softwares– Específicos (ou aplicativos), desenvolvidos sob
medida para os problemas de um cliente– Genéricos (utilitários ou pacotes), disponíveis
para compra por qualquer cliente
Curva Ideal de Falhas Software
Aplicações do Software
• Software Básico
• Tempo Real
• Comercial
• Científico
• Apoio à Atividades de Engenharia
• Embutido (ou Embarcado - tradução ruim)
• Computação Pessoal
• Inteligência Artificial
Curva Real de FalhasSoftware
A “Crise” do Software
Crise sf (gr Krísis) 1 Ponto decisivo no curso de algo 2
Momento ou evento decisivo, crucial 3 Momento crítico ou decisivo
• O Desenvolvimento de software é crítico há mais de 30 anos
• “Crise” do software diz respeito ao conjunto de problemas encontrados nas práticas de desenvolvimento de software
A “Crise” do Software
Problemas Identificados:
1. Estimativas de prazos e custo imprecisas
2. Produtividade do pessoal de software não acompanha a demanda
3.Qualidade do software é inferior a adequada
A “Crise” do Software
Problemas são manifestações de outras
dificuldades:
1. Falta de coleta de informações sobre o processo de desenvolvimento de software
2. Projetos são desenvolvidos com indícios vagos das exigências do cliente
3. Qualidade de software é suspeita. Nos últimos anos surgiram as primeiras preocupações com a garantia de qualidade
A “Crise” do Software
Causas:
1. Características do Software
2. Erros cometidos pelas pessoas que detinham a responsabilidade pelo desenvolvimento de Software
3. Resistência a mudanças
Mitos do Software
• Surgiram nos primórdios do desenvolvimento de software
• Categorias de mitos:– Mitos Administrativos (Gerenciais)– Mitos dos Usuários– Mitos do Profissional de Informática
• Conclusão: Problema não está no Software (Produto) e sim como ele é desenvolvido (Processo)
Mitos Administrativos ou Gerenciais
• Já temos todos os manuais de normas e procedimentos. Isso já é suficiente para meu pessoal descobrir tudo o que precisam– Nada adianta a existência de padrões de não há
controle do mesmo garantia de qualidade
• Nossa instalação tem ferramentas de desenvolvimento de última geração– A simples existência das ferramentas não garante
ganhos de eficiência e qualidade
Mitos Administrativos ou Gerenciais
• Se estivermos com os prazos atrasados, podemos contratar mais programadores e “tirar o atraso”– Desenvolvimento de software não é um
processo mecânico como de manufatura. Novas pessoas certamente tornarão um projeto atrasado ainda mais atrasado.
Mitos do Cliente
• Uma declaração geral dos objetivos é suficiente para começarmos a programar. Os detalhes nós preenchemos depois– Definição inicial ruim certamente implicará em
software ruim (de baixa qualidade)
• Requisitos de um projeto mudam continuamente, mas software é fácil de ser modificados, visto que é flexível.
Mitos do Cliente
Curva de Custo de uma Mudança
Mitos do Profissional
• Assim que acabarmos de escrever os programas e implantarmos o sistema nosso trabalho estará completo– Estudos apontam que 50 a 70% despendido em um
programa, ocorre depois de sua 1ª entrega
• Antes do programa estar “rodando” não posso avaliar a qualidade do mesmo– Existem técnicas de Revisão e Inspeção de Programas
aplicáveis antes da programação propriamente dita
Mitos do Profissional
• A única coisa importante de um projeto bem sucedido é o programa funcionando em produção– Programa é apenas um item da configuração de um
software. Outros Itens:• Planos • Especificação de Requisitos• Banco de Dados• Documentação• Casos de Teste• Manuais, helps e Tutores-Online
Engenharia de SoftwareDefinição I
• Estabelecimento e uso de sólidos princípios de Engenharia para que se possa obter economicamente um software que seja confiável e que funciona eficientemente e maquinas reais - (Fritz Bauer 1969)
Engenharia de SoftwareDefinição II
• Aplicação de abordagens sistemáticas, disciplinadas e quantificáveis para o desenvolvimento, operação e manutenção de um software - (Glossário IEEE 1993)
Engenharia de SoftwareDefinição III
• Estabelecimento e uso dos princípios básicos da Engenharia com a finalidade de desenvolver software de maneira sistemática e econômica, resultando em um produto confiável e eficiente (Pressman)
Os Pilares de Sustentação do Processo de Desenvolvimento
• Métodos
• Ferramentas
• Procedimentos
• Mão de Obra
PROCESSO
Produto de Software:•Custo Aceitável•Alta Qualidade•Alta Confiabilidade
Usa Para Desenvolver
O Processo de Desenvolvimento de Software
Produto de Software
Método:Matéria-Prima:
Mão de Obra: Máquina:
Diagrama de Ishikawa Elementos que agem em Engenharia de
SoftwareRequisitosInformaçã
oPadrões, Normas, Regras
ComputadoresSoftware de ApoioFerramentas CASE
AnalistasProgramadoresEngenheiros de Software
Engenharia de Software
A importância dos modelos, métodos e principais Paradigmas
Modelos em Engenharia de Software - Abstração
Um modelo é uma abstração de um objeto ou fenômeno
sob um determinado ponto de vista e um certo nível
de detalhamento.
Modelos em Engenharia de Software - Utilidade
Modelos são úteis para:
– Compreender o problema sob seus diversos aspectos
(entendimento).
– Representar o ambiente no qual o sistema deverá se
inserir.
– Desenvolver soluções para o problema (criatividade +
método + técnicas + ferramentas).
Modelos em Engenharia de Software - Utilidade
Modelos são úteis para:
– Escolher dentre as possíveis soluções, a mais
adequada.
– Ensaia (testar) a solução escolhida (depuração).
– Registrar e comunicar o projeto para terceiros
(documentação)
Engenharia de SoftwarePrincípios da Modelagem
1- A escolha do tipo de modelo a ser criado tem
uma profunda influência sobre como a solução
do problema será enfocada e construída.
2- Qualquer modelo pode ser expresso em
diferentes níveis de precisão.
UML: User Guide - Booch, Rumbaugh, Jacobson.
3- Os melhores modelos são “conectados”
(aderentes) à realidade.
4- Um único modelo não é suficiente. Qualquer
sistema não trivial é melhor enfocado com um
pequeno conjunto de modelos semi-independentes.
UML: User Guide - Booch, Rumbaugh, Jacobson.
Engenharia de SoftwarePrincípios da Modelagem
Modelar é uma maneira de analisarmos
conceitualmente um problema do mundo real
usando modelos.Quem define um problema, já o resolveu pela metade.
Julian Huxley
Nós construímos modelos para entender melhor
um sistema que será desenvolvido.
Construímos modelos de sistemas complexos
porque não conseguimos entendê-los tal como
são, na sua totalidade.
Engenharia de SoftwarePrincípios da Modelagem
Modelos e RequisitosAtenção
Modelos são úteis para a especificação dos
requisitos já definidas mas não são úteis para a
determinação desses requisitos.
Modelar requer o conhecimento da metodologia
de modelagem a ser empregada (sua
simbologia e sintaxe), dos procedimentos para
sua aplicação e de ferramentas que
automatizam a metodologia ( se disponíveis).
Pode ser construida por uma pessoa.Requer:
Modelagem mínimaProcesso simplesFerramentas simples
Projetando uma casa de cachorro
Projetando uma casa
A construção será mais eficiente (especialistas) e mais rápida se for feita por uma equipe.
Requer:Modelagem (planta baixa, elétrica, hidráulica etc.)Processo bem definidoFerramentas poderosas
Projetando uma grande obra
Modelando uma casa
Maquete é um tipode prototipagem.
A complexidade dos modelos
A complexidade dos modelos adotados (do processo
de modelagem) depende da complexidade do
problema a ser modelado.
A complexidade dos modelos
A complexidade dos modelos adotados (do
processo de modelagem) depende da
complexidade do problema a ser modelado.
Modelar x Construir (Desenvolver)
Uma linguagem de modelagem é uma notação
gráfica que os métodos usam para expressar
projetos. Se restringe a criação e ensaio dos
modelos; não é um método de desenvolvimento
do produto de software.
A transposição do modelo para o produto será
feita através do processo de construção de
software. Ex: RUP – Rational Unified Process
A burocracia dos Métodos
Métodos e Metodologias: até que ponto são úteis
e a partir de onde apenas criam formalismo
desnecessário (burocracia) ?
• Uniformizam o trabalho;
• Aumenta a produtividade (a médio prazo);
• Aumenta a qualidade;
• Cria sistemas independentes de desenvolvedores;
• Permite maior controle sobre o projeto.
A burocracia dos Métodos
Métodos devem prover rigor sem sacrificar a
utilidade e a produtividade. Não deve se transforma
numa fábrica de documentos sem utilidade. Como ?
• Usar o método apropriado;
• Adequá-lo à empresa, ao problema e à equipe;
• Implantá-lo adequadamente, com treinamento e com a
necessária flexibilidade;
• Usar, em cada caso, apenas os modelos que se fizerem
necessários.
A burocracia dos Métodos
Qualquer método é melhor que nenhum !!!
Paradigmas da Engenharia de Software
• Clássico (Linear ou em Cascata)
• Prototipação
• Incremental
• Evolutivo
• em Espiral
• RAD (Rapid Aplication Development)
• Outros Paradigmas
Ciclos de Vida de SoftwareModelo Clássico (Cascata)
Ciclos de Vida de SoftwareModelo Clássico Atualizado
Ciclos de Vida de SoftwareModelo Clássico (visão realista)
Ciclos de Vida de SoftwareModelo Incremental
Ciclos de Vida de SoftwareModelo Evolutivo (Exploratório)
Ciclos de Vida de SoftwarePrototipação
O desenvolvimentoprossegue por meiode um ciclo de vidacompleto.
Ciclos de Vida de SoftwareModelo Espiral Atualizado
Ciclos de Vida de SoftwareModelo RAD
Ciclos de Vida de SoftwareModelo RUP