técnicas de desenvolvimento de sistemas de software aula 1 processo, produto e processos de...

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