Técnicas de Desenvolvimento de Sistemas de Software

Apresentação em tema: "Técnicas de Desenvolvimento de Sistemas de Software"— Transcrição da apresentação:

1 Técnicas de Desenvolvimento de Sistemas de Software
Aula 1 Processo, Produto e Processos de Engenharia de Software

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

3 Processo Entrada Saída PROCESSAMENTO Produto (Resultado): - Bem
- Serviço

4 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

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

6 Controle de Qualidade Evolução
Inspeção Pós-Produção Controle Estatístico Procedimento de Produção Educação das Pessoas Otimização de Processos Projeto Robusto 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

7 Diagrama de Ishikawa Uma das Ferramentas da Qualidade
Diagrama Causa-Efeito (Espinha de Peixe) Quatro M’s influem no Processo Matéria-Prima Método Resultado Mão de Obra Máquina

8 Diagrama de Ishikawa Há autores que sugerem variações dos M’s que influem no Processo Meio Ambiente Matéria-Prima Método Resultado Mão de Obra Máquina

9 Diagrama de Ishikawa Resultado é o efeito visível
As causas agem positiva ou negativamente em cada um dos 4 M´s, levando ao efeito Matéria-Prima Método Causa que age negativamente Causa que age positivamente Resultado Fora do Padrão Estabelecido Mão de Obra Máquina

10 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

11 Processos nas Corporações
Corporações Tradicionais Onde estão os processos ??? Presidência Financeiro Administrativo Comercial Industrial

12 Processos nas Corporações
Corporações Modernas Financeiro Administrativo Comercial Industrial Início Fim: Resultados Pontos Intermediários de Medição e Controle

13 Processos nas Corporações
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

14 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

15 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

16 Curva de Falhas Hardware
Curva da Banheira

17 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

18 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

19 Curva Ideal de Falhas Software

20 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

21 Curva Real de Falhas Software

22 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

23 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

24 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

25 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

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

27 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

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

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

30 Curva de Custo de uma Mudança
Mitos do Cliente Curva de Custo de uma Mudança

31 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

32 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

33 Engenharia de Software Definiçã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)

34 Engenharia de Software Definiçã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)

35 Engenharia de Software Definiçã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)

36 Os Pilares de Sustentação do Processo de Desenvolvimento
Métodos Ferramentas Procedimentos Mão de Obra Usa Para Desenvolver Produto de Software: Custo Aceitável Alta Qualidade Alta Confiabilidade

37 O Processo de Desenvolvimento de Software
Diagrama de Ishikawa Elementos que agem em Engenharia de Software Matéria-Prima: Método: Requisitos Informação Padrões, Normas, Regras Produto de Software Máquina: Mão de Obra: Computadores Software de Apoio Ferramentas CASE Analistas Programadores Engenheiros de Software

38 Engenharia de Software
A importância dos modelos, métodos e principais Paradigmas

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

40 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).

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

42 Engenharia de Software Princí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.

43 Engenharia de Software Princípios da Modelagem
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.

44 Engenharia de Software Princí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.

45 Modelos e Requisitos Atençã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).

46 Projetando uma casa de cachorro
Pode ser construida por uma pessoa. Requer: Modelagem mínima Processo simples Ferramentas simples

47 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 definido Ferramentas poderosas

48 Projetando uma grande obra

49 Modelando uma casa Maquete é um tipo de prototipagem.

50 A complexidade dos modelos
A complexidade dos modelos adotados (do processo de modelagem) depende da complexidade do problema a ser modelado.

51 A complexidade dos modelos
A complexidade dos modelos adotados (do processo de modelagem) depende da complexidade do problema a ser modelado.

52 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

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

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

55 A burocracia dos Métodos
Qualquer método é melhor que nenhum !!!

56 Paradigmas da Engenharia de Software
Clássico (Linear ou em Cascata) Prototipação Incremental Evolutivo em Espiral RAD (Rapid Aplication Development) Outros Paradigmas

57 Ciclos de Vida de Software Modelo Clássico (Cascata)

58 Ciclos de Vida de Software Modelo Clássico Atualizado

59 Ciclos de Vida de Software Modelo Clássico (visão realista)

60 Ciclos de Vida de Software Modelo Incremental

61 Ciclos de Vida de Software Modelo Evolutivo (Exploratório)

62 Ciclos de Vida de Software Prototipação
O desenvolvimento prossegue por meio de um ciclo de vida completo.

63 Ciclos de Vida de Software Modelo Espiral Atualizado

64 Ciclos de Vida de Software Modelo RAD

65 Ciclos de Vida de Software Modelo RUP