A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software Engenharia de Software Prof. Inês Ap. Gasparotto Boaventura 1. Semestre/2001.

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software Engenharia de Software Prof. Inês Ap. Gasparotto Boaventura 1. Semestre/2001."— Transcrição da apresentação:

1 Engenharia de Software Engenharia de Software Prof. Inês Ap. Gasparotto Boaventura 1. Semestre/2001

2 Tópicos 1- Introdução à Engenharia de Software 2 - Fundamentos Organizacionais de Sistemas de Informação - Gerência de projeto de software 3 - Gerência de projeto de software 4- Gerenciamento para a qualidade de software 5- Acompanhamento do processo de desenvolvimento de software.

3 Software 1- Instruções quando executadas produzem a função e o desempenho desejados 2 - Estruturas de Dados possibilitam que os programas manipulem adequadamente a informação 3 - Documentos descrevem a operação e o uso dos programas

4 Características do Software 1. desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico 2. não se desgasta mas se deteriora 3. a maioria é feita sob medida em vez de ser montada a partir de componentes existentes

5 Aplicações do Software

6 Evolução do Software ( ) O hardware sofreu contínuas mudanças O software era uma arte "secundária" para a qual havia poucos métodos sistemáticos O hardware era de propósito geral O software era específico para cada aplicação Não havia documentação

7 Evolução do Software ( ) Multiprogramação e sistemas multiusuários Técnicas interativas Sistemas de tempo real 1 a geração de SGBDs Produto de software - software houses Bibliotecas de Software Cresce n o de sistemas baseado em computador Manutenção quase impossível..... CRISE DE SOFTWARE..... CRISE DE SOFTWARE

8 Evolução do Software ( hoje) Sistemas distribuídos Redes locais e globais Uso generalizado de microprocessadores - produtos inteligentes Hardware de baixo custo Impacto de consumo..... CRISE DE SOFTWARE (aflição crônica???)

9 Evolução do Software atualidade (Quarta era do software: atualidade) Tecnologias orientadas o objetos Sistemas especialistas e software de inteligência artificial usados na prática Software de rede neural artificial Computação Paralela Internet..... CRISE DE SOFTWARE (aflição crônica???)

10 Crise de Software Refere-se a um conjunto de problemas encontrados no desenvolvimento de software: As estimativas de prazo e de custo freqüentemente são imprecisas (1) As estimativas de prazo e de custo freqüentemente são imprecisas Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software Sem nenhuma indicação sólida de produtividade, não podemos avaliar com precisão a eficácia de novas ferramentas, métodos ou padrões

11 Crise de Software A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços (2) A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços Os projetos de desenvolvimento de software normalmente são efetuados apenas com um vago indício das exigências do cliente

12 Crise de Software A qualidade de software às vezes é menos que adequada (3) A qualidade de software às vezes é menos que adequada Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software O software existente é muito difícil de manter (4) O software existente é muito difícil de manter A tarefa de manutenção devora o orçamento destinado ao software A facilidade de manutenção não foi enfatizada como um critério importante

13 Crise de Software estimativas de prazo e de custo produtividade das pessoas qualidade de software software difícil de manter

14 Causas dos problemas associados à Crise de Software 1. próprio caráter do Software O software é um elemento de sistema lógico e não físico (produto intangível) Conseqüentemente, o sucesso é medido pela qualidade de uma única entidade e não pela qualidade de muitas entidades manufaturadas O software não se desgasta, mas se deteriora!!!

15 2. falhas das pessoas responsáveis pelo desenvolvimento de Software Gerentes sem nenhum background em software Os profissionais da área de software têm recebido pouco treinamento formal em novas técnicas para o desenvolvimento de software Resistência a mudanças. Causas dos problemas associados à Crise de Software

16 3. mitos do Software propagaram desinformação e confusão administrativos administrativos cliente cliente profissional profissional Causas dos problemas associados à Crise de Software

17 Mitos do Software (administrativos) Já temos um manual repleto de padrões e procedimentos para a construção de software. Isso não oferecerá ao meu pessoal tudo o que eles precisam saber? Realidade: Será que o manual é usado? Os profissionais sabem que ele existe? Ele reflete a prática moderna de desenvolvimento de software? Ele é completo? Realidade: Será que o manual é usado? Os profissionais sabem que ele existe? Ele reflete a prática moderna de desenvolvimento de software? Ele é completo?

18 Meu pessoal tem ferramentas de desenvolvimento de software de última geração; afinal lhes compramos os mais novos computadores. Mitos do Software (administrativos) Realidade: É preciso muito mais do que os mais recentes computadores para se fazer um desenvolvimento de software de alta qualidade. Realidade: É preciso muito mais do que os mais recentes computadores para se fazer um desenvolvimento de software de alta qualidade.

19 Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso. Mitos do Software (administrativos) Realidade: O desenvolvimento de software não é um processo mecânico igual à manufatura. Acrescentar pessoas em um projeto torna-o ainda mais atrasado. Pessoas podem ser acrescentadas, mas somente de uma forma planejada. Realidade: O desenvolvimento de software não é um processo mecânico igual à manufatura. Acrescentar pessoas em um projeto torna-o ainda mais atrasado. Pessoas podem ser acrescentadas, mas somente de uma forma planejada.

20 Uma declaração geral dos objetivos é suficiente para se começar a escrever programas - podemos preencher os detalhes mais tarde. Mitos do Software (cliente) Realidade: Uma definição inicial ruim é a principal causa de fracassos dos esforços de desenvolvimento de software. É fundamental uma descrição formal e detalhada do domínio da informação, função, desempenho, interfaces, restrições de projeto e critérios de validação. Realidade: Uma definição inicial ruim é a principal causa de fracassos dos esforços de desenvolvimento de software. É fundamental uma descrição formal e detalhada do domínio da informação, função, desempenho, interfaces, restrições de projeto e critérios de validação.

21 Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível. Mitos do Software (cliente) Realidade: Uma mudança, quando solicitada tardiamente num projeto, pode ser maior do que mais do que uma ordem de magnitude mais dispendiosa do que a mesma mudança solicitada nas fases iniciais. Realidade: Uma mudança, quando solicitada tardiamente num projeto, pode ser maior do que mais do que uma ordem de magnitude mais dispendiosa do que a mesma mudança solicitada nas fases iniciais.

22 Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho estará completo. Mitos do Software (profissional) Realidade: Os dados da indústria indicam que entre 50 e 70% de todo esforço gasto num programa serão despendidos depois que ele for entregue pela primeira vez ao cliente. Realidade: Os dados da indústria indicam que entre 50 e 70% de todo esforço gasto num programa serão despendidos depois que ele for entregue pela primeira vez ao cliente.

23 Enquanto não tiver o programa "funcionando", eu não terei realmente nenhuma maneira de avaliar sua qualidade. Mitos do Software (profissional) Realidade: Um programa funcionando é somente uma parte de uma Configuração de Software que inclui todos os itens de informação produzidos durante a construção e manutenção do software. Realidade: Um programa funcionando é somente uma parte de uma Configuração de Software que inclui todos os itens de informação produzidos durante a construção e manutenção do software.

24 Preocupação: Sistematizar o processo de criação e manutenção de software.

25 Boehm: Engenharia de software envolve a aplicação prática de conhecimento científico para o projeto e construção de programas de computador e a documentação associada necessária para desenvolvê-los, operá-los e mantê-los. Engenharia de Software Definições

26 IEEE Standard Glossary of Software Engineering terminology: Engenharia de software é uma abordagem sistemática para o desenvolvimento, operação, manutenção de software Software: programas de computador, procedimentos, regras, documentação possivelmente associada, e dados sobre sua operação. Engenharia de Software Definições

27 Fairley: Engenharia de software é a disciplina tecnologica e gerencial preocupada com a produção sistemática e manutenção de produtos de software que são desenvolvidos e modificados no prazo estabelecido e dentro das estimativas de custo. Engenharia de Software Definições

28 abrange um conjunto de três elementos fundamentais: Métodos, Ferramentas e Procedimentos Principais metas: melhorar a qualidade de produtos de software, aumentar a produtividade do pessoal técnico e aumentar a satisfação do cliente.

29 métodos métodos: proporcionam os detalhes de como fazer para construir o software Engenharia de Software

30 Planejamento e estimativa de projeto Análise de requisitos de software e de sistemas Projeto da estrutura de dados Algoritmo de processamento Codificação Teste Manutenção Engenharia de Software

31 ferramentas ferramentas: dão suporte automatizado aos métodos. existem atualmente ferramentas para sustentar cada um dos métodos quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE - Computer Aided Software Engineering Engenharia de Software

32 procedimentos procedimentos: constituem o elo entre os métodos e ferramentas seqüência em que os métodos serão aplicados produtos que se exige que sejam entregues controles que ajudam assegurar a qualidade e coordenar as alterações marcos de referência que possibilitam administrar o progresso do software. Engenharia de Software

33 etapas conjunto de etapas que envolvemétodosferramentasprocedimentos CICLO DE VIDA DE SOFTWARE Essas etapas são conhecidas como componentes de CICLO DE VIDA DE SOFTWARE ou Processo de Software Engenharia de Software

34 Alguns ciclos de vida mais conhecidos são: Ciclo deVida Clássico Ciclo de Vida Clássico Prototipação Prototipação ModeloEspiral Modelo Espiral Técnicas de 4 a Geração Técnicas de 4 a Geração Engenharia de Software

35 para escolha de um Ciclo de Vida de Software: natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues

36 Ciclo de Vida Clássico (Cascata) modelo mais antigo e o mais amplamente usado da engenharia de software modelado em função do ciclo da engenharia convencional requer uma abordagem sistemática, seqüencial ao desenvolvimento de software

37 Engenharia de Sistemas Análise de Requisitos ProjetoProjeto CodificaçãoCodificação TestesTestes ManutençãoManutenção Cascata

38 Atividades do Ciclo de Vida Clássico ANÁLISE E ENGENHARIA DE SISTEMAS envolve a coleta de requisitos em nível do sistema, pequena quantidade de projeto e análise de alto nível Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção visão essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados)

39 Atividades do Ciclo de Vida Clássico ANÁLISE DE REQUISITOS DE SOFTWARE processo de coleta dos requisitos é intensificado e concentrado especificamente no software deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos os requisitos (para o sistema e para o software) são documentados e revistos com o cliente Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

40 Atividades do Ciclo de Vida Clássico PROJETO tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie se concentra em 4 atributos do programa: Estrutura de Dados, Arquitetura de Software, Detalhes Procedimentais e Caracterização de Interfaces Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

41 Atividades do Ciclo de Vida Clássico CODIFICAÇÃO tradução das representações do projeto para uma linguagem artificial resultando em instruções executáveis pelo computador Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

42 Atividades do Ciclo de Vida Clássico TESTES Concentram-se: nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados. Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção

43 Atividades do Ciclo de Vida Clássico MANUTENÇÃO o software deverá sofrer mudanças depois que for entregue ao cliente Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção causas das mudanças: erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho

44 Problemas com o Ciclo de Vida Clássico projetos reais raramente seguem o fluxo seqüencial que o modelo propõe logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural o cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento

45 Embora o Ciclo de Vida Clássico tenha fragilidades, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software Clássico (comentários) Clássico (comentários)

46 Prototipação Prototipação processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. protótipo idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software. apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes.

47 fim início construção produto refinamento protótipo avaliação protótipo construção protótipo projeto rápido obtenção dos requisitos Prototipação Prototipação

48 Atividades da Prototipação Obtenção dos Requisitos: Obtenção dos Requisitos: desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais Projeto Rápido: Projeto Rápido: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída) fim início construção produto refinamento protótipo avaliação protótipo construção protótipo projeto rápido obtenção dos requisitos

49 Construção Protótipo: Construção Protótipo: implementação do projeto rápido Avaliação do Protótipo: Avaliação do Protótipo: cliente e desenvolvedor avaliam o protótipo Atividades da Prototipação fim início construção produto refinamento protótipo avaliação protótipo construção protótipo projeto rápido obtenção dos requisitos

50 Refinamento dos Requisitos: Refinamento dos Requisitos: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. iteração Ocorre neste ponto um processo de iteração que pode conduzir a 1a. atividade até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito. Atividades da Prototipação fim início construção produto refinamento protótipo avaliação protótipo construção protótipo projeto rápido obtenção dos requisitos

51 Construção Produto: Construção Produto: identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade. Atividades da Prototipação fim início construção produto refinamento protótipo avaliação protótipo construção protótipo projeto rápido obtenção dos requisitos

52 Problemas com a Prototipação cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo. Não aceita bem a idéia que a versão final do software vai ser construída e "força" a utilização do protótipo como produto final.

53 Problemas com a Prototipação desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo. Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final.

54 Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente A chave é definir-se as regras do jogo logo no começo O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos Prototipação (comentários) Prototipação (comentários)

55 Ciclo de Vida em Espiral Análise de Risco engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo elemento: a Análise de Risco iterativa segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos

56 decisão de continuar ou não direção de um sistema concluído avaliação do cliente engenharia análise dos riscos planejamento Espiral

57 Atividades do Ciclo de Vida em Espiral Planejamento: Planejamento: determinação dos objetivos, alternativas e restrições Análise de Risco: análise das alternativas e identificação / resolução dos riscos Construção: Construção: desenvolvimento do produto no nível seguinte Avaliação do Cliente: Avaliação do Cliente: avaliação do produto e planejamento das novas fases avaliação do cliente engenharia análise dos riscos planejamento

58 é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala. usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva. pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso Espiral (comentários)

59 o modelo é relativamente novo e não tem sido amplamente usado Demorará muitos anos até que a eficácia desse modelo possa ser determinada com certeza absoluta. Espiral (comentários)

60 Técnicas de 4 a Geração Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja próximo à linguagem natural. Engloba um conjunto de ferramentas de software que possibilitam que: sistema seja especificado em uma linguagem de alto nível o sistema seja especificado em uma linguagem de alto nível e código fonte seja gerado automaticamente o código fonte seja gerado automaticamente a partir dessas especificações

61 Obtenção dos Requisitos Estratégia do Projeto Implementação usando 4GL Testes Técnicas de 4 a Geração

62 Ferramentas do ambiente de desenvolvimento de software de 4GL O ambiente de desenvolvimento de software que sustenta o ciclo de vida de 4 a geração inclui as ferramentas: linguagens não procedimentais para consulta de banco de dados geração de relatórios manipulação de dados interação e definição de telas geração de códigos capacidade gráfica de alto nível capacidade de planilhas eletrônicas

63 Atividades das Técnicas de 4 a Geração 1. obtenção dos Requisitos: 1. obtenção dos Requisitos: o cliente descreve os requisitos os quais são traduzidos para um protótipo operacional Obtenção dos Requisitos Estratégia do Projeto Implementaçã o usando 4GL Testes o cliente pode estar inseguro quanto aos requisitos o cliente pode ser incapaz de especificar as informações de um modo que uma ferramenta 4GL possa consumir as 4GLs atuais não são sofisticadas suficientemente para acomodar a verdadeira "linguagem natural"

64 2. estratégia de "Projeto": 2. estratégia de "Projeto": para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação usando uma Linguagem de 4G Obtenção dos Requisitos Estratégia do Projeto Implementaçã o usando 4GL Testes Atividades das Técnicas de 4 a Geração para grandes projetos é necessário desenvolver uma estratégia de projeto. De outro modo ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade)

65 3. implementação usando 4GL: 3. implementação usando 4GL: os resultados desejados são representados de modo que haja geração automática de código. Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL Atividades das Técnicas de 4 a Geração Obtenção dos Requisitos Estratégia do Projeto Implementaçã o usando 4GL Testes

66 Atividades das Técnicas de 4 a Geração Obtenção dos Requisitos Estratégia do Projeto Implementaçã o usando 4GL Testes 4. teste: 4. teste: o desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.

67 PROPONENTES: PROPONENTES: redução dramática no tempo de desenvolvimento do software (aumento de produtividade) OPONENTES OPONENTES: as 4GL atuais não são mais fáceis de usar do que as linguagens de programação o código fonte produzido é ineficiente a manutenibilidade de sistemas usando técnicas 4G ainda é questionável Técnicas de 4 a Geração (comentários)

68 Engenharia de Software uma visão genérica processo de desenvolvimento de software O processo de desenvolvimento de software contém 3 fases genéricas, independentes do modelo de engenharia de software escolhido: DEFINIÇÃO 1. DEFINIÇÃO, DESENVOLVIMENTO 2. DESENVOLVIMENTO e MANUTENÇÃO 3. MANUTENÇÃO.

69 Engenharia de Software uma visão genérica

70 DEFINIÇÃOo que DEFINIÇÃO : o que será desenvolvido. Análise do Sistema: Análise do Sistema: define o papel de cada elemento num sistema baseado em computador, atribuindo em última análise, o papel que o software desempenhará. Planejamento do Projeto de Software: Planejamento do Projeto de Software: assim que o escopo do software é estabelecido, os riscos são analisados, os recursos são alocados, os custos são estimados e, tarefas e programação de trabalho definidas. Engenharia de Software uma visão genérica

71 Análise de Requisitos: Análise de Requisitos: o escopo definido para o software proporciona uma direção, mas uma definição detalhada do domínio da informação e da função do software é necessária antes que o trabalho inicie. Engenharia de Software uma visão genérica

72 DESENVOLVIMENTOcomo DESENVOLVIMENTO: como o software vai ser desenvolvido. Projeto de Software: Projeto de Software: traduz os requisitos do software num conjunto de representações (algumas gráficas, outras tabulares ou baseadas em linguagem) que descrevem a estrutura de dados, a arquitetura do software, os procedimentos algorítmicos e as características de interface. Engenharia de Software uma visão genérica

73 Codificação: Codificação: as representações do projeto devem ser convertidas numa linguagem artificial (a linguagem pode ser uma linguagem de programação convencional ou uma linguagem não procedimental) que resulte em instruções que possam ser executadas pelo computador. Realização de Testes do Software: Realização de Testes do Software: logo que o software é implementado numa forma executável por máquina, ele deve ser testado para que se possa descobrir defeitos de função, lógica e implementação. Engenharia de Software uma visão genérica

74 MANUTENÇÃO: mudanças MANUTENÇÃO: concentra-se nas mudanças que ocorrerão depois que o software for liberado para uso operacional Correção Adaptação Melhoramento Funcional Engenharia de Software uma visão genérica

75 Correção: manutenção corretiva Correção: mesmo com as melhores atividades de garantia de qualidade de software, é provável que o cliente descubra defeitos no software. A manutenção corretiva muda o software para corrigir defeitos. Adaptação: manutenção adaptativa Adaptação: com o passar do tempo, o ambiente original (por exemplo a CPU, o sistema operacional e periféricos) para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa muda o software para acomodar mudanças em seu ambiente. Engenharia de Software uma visão genérica

76 Melhoramento Funcional: Melhoramento Funcional: a medida que o software é usado, o cliente/usuário reconhecerá funções adicionais que oferecerão benefícios. manutenção perfectiva A manutenção perfectiva estende o software para além de suas exigências funcionais originais. Engenharia de Software uma visão genérica

77 Atividades de Proteção: Atividades de Proteção: as fases e etapas correlatas descritas são complementadas por uma série de atividades de proteção. Revisões: Revisões: efetuadas para garantir que a qualidade seja mantida à medida que cada etapa é concluída. Documentação: Documentação: é desenvolvida e controlada para garantir que informações completas sobre o software estejam disponíveis para uso posterior. Controle das Mudanças: Controle das Mudanças: é instituído de forma que as mudanças possam ser aprovadas e acompanhadas. Engenharia de Software uma visão genérica

78 A Engenharia de Software também se preocupa com questões gerenciais, que encontra-se do lado oposto ao domínio da programação Gerenciamento: necessário para coordenar as atividades técnicas em projetos de produtos de software. Engenharia de Software uma aborgagem gerencial

79 Em geral, um produto de software inclui: -> Código fonte, e documentação relacionada: -> Código fonte, e documentação relacionada: documento de requisitos especificação do projeto planos de teste princípios de operação procedimentos para garantia da qualidade Engenharia de Software uma aborgagem gerencial

80 Em geral, um produto de software inclui: -> Cogido fonte, e documentação relacionada: -> Cogido fonte, e documentação relacionada: relatórios de problemas com o software procedimentos de manutenção manuais do usuário instruções para instalação auxílio para treinamento Engenharia de Software uma aborgagem gerencial

81 Qualidade de software : preocupação principal dos gerentes de software. -> Principal atributo de qualidade: utilidade -> Principal atributo de qualidade: utilidade -> outros atributos de qualidade: - transportabilidade - eficiência - clareza - confiabilidade Engenharia de Software uma aborgagem gerencial

82 Fatore de Qualidade e Produtividade : Fatores que influenciam a qualidade: Fatores que influenciam a qualidade: Habilidade Individual Habilidade Individual Comunicação da equipe Comunicação da equipe Complexidade do produto Complexidade do produto Notações apropriadas Notações apropriadas Abordagens sistemáticas Abordagens sistemáticas controle de mudanças controle de mudanças Engenharia de Software uma aborgagem gerencial

83 Fatore de Qualidade e Produtividade : Fatores que influenciam a qualidade: Fatores que influenciam a qualidade: Adequação de treinamento Adequação de treinamento Habilidades de gerenciamento Habilidades de gerenciamento Metas apropriadas Metas apropriadas Entendimento do problema Entendimento do problema Estabilidade dos requisitos Estabilidade dos requisitos Habilidades necessárias Habilidades necessárias Engenharia de Software uma aborgagem gerencial

84 Questões gerenciais Os gerentes de software: Os gerentes de software: controlam os recursos e o ambiente no qual as atividades técnicas ocorrem. controlam os recursos e o ambiente no qual as atividades técnicas ocorrem. responsáveis pela entrega do produto no prazo e dentro das estimativas de custo. responsáveis pela entrega do produto no prazo e dentro das estimativas de custo. devem garantir que o produto tenha os atributos funcionais e de qualidade desejados pelo cliente. devem garantir que o produto tenha os atributos funcionais e de qualidade desejados pelo cliente. Treinam empregados. Treinam empregados. desenvolvem planos e estratégias de marketing. desenvolvem planos e estratégias de marketing. Engenharia de Software uma aborgagem gerencial

85 Preocupações de gerenciamento de projeto: métodos para organizar e monitorar um projeto. métodos para organizar e monitorar um projeto. técnicas de estimativa de custo. técnicas de estimativa de custo. política de alocação de recursos. política de alocação de recursos. controle orçamentário. controle orçamentário. avaliação do progresso. avaliação do progresso. realocação de recursos. realocação de recursos. ajustes no cronograma. ajustes no cronograma. Engenharia de Software uma aborgagem gerencial

86 Preocupações de gerenciamento de projeto: estabelecer procedimentos para garantia de qualidade. estabelecer procedimentos para garantia de qualidade. manter o controle de várias versões do produto. manter o controle de várias versões do produto. facilitar a comunicação entre os membros do projeto. facilitar a comunicação entre os membros do projeto. comunicação com o cliente. comunicação com o cliente. estabelecer contratos com o cliente. estabelecer contratos com o cliente. garantir que os termos legais e contratuais do projeto sejam cumpridos. garantir que os termos legais e contratuais do projeto sejam cumpridos. Engenharia de Software uma aborgagem gerencial

87 Problemas na área de gerenciamento: falta de planejamento para projetos de software. falta de planejamento para projetos de software. falta de técnicas e procedimentos para selecionar gerentes de projeto. falta de técnicas e procedimentos para selecionar gerentes de projeto. falta de habilidade em estimar os recursos necessários para o projeto. falta de habilidade em estimar os recursos necessários para o projeto. falta de um processo de desenvolvimento bem estabelecido. falta de um processo de desenvolvimento bem estabelecido. falta de estratégias para o gerente acompanhar o progresso do projeto. falta de estratégias para o gerente acompanhar o progresso do projeto. falta de padrões e técnicas para medir produtividade. falta de padrões e técnicas para medir produtividade. Engenharia de Software uma aborgagem gerencial

88 Fatores que melhoram o gerenciamento: treinar gerentes, e desenvolvedores de software. treinar gerentes, e desenvolvedores de software. estabelecer o uso de padrões, procedimentos e documentação. estabelecer o uso de padrões, procedimentos e documentação. analisar dados de projetos passados para avaliar métodos efetivos. analisar dados de projetos passados para avaliar métodos efetivos. definir objetivos em termos de qualidade desejada. definir objetivos em termos de qualidade desejada. definir qualidade em termos de produtos a ser entregues. definir qualidade em termos de produtos a ser entregues. Selecionar gerentes de projetos com habilidades para gerenciamento. Selecionar gerentes de projetos com habilidades para gerenciamento. Desenvolver uma maneira de avaliar os desenvolvedores de software. Desenvolver uma maneira de avaliar os desenvolvedores de software. Engenharia de Software uma aborgagem gerencial

89 Conclusão ENGENHARIA DE SOFTWARE pode ser vista como uma abordagem de desenvolvimento de software elaborada com disciplina e métodos bem definidos......a construção por múltiplas pessoas de um software de múltiplas versões [Parnas 1987]

90 Pontos a ponderar O software é o fator de diferenciação de muitos produtos e sistemas baseados em computador. Apresente exemplos de dois ou três produtos e de pelo menos um sistema em que o software, não o hardware, é o elemento que faz a diferença. Nas décadas de 1950 e 1960, a programação de computador era uma forma de arte aprendida num ambiente semelhante ao de aprendizes. Como os primórdios afetaram as práticas de desenvolvimento de software atuais? Apresente cinco exemplos de desenvolvimento de software que seriam adequados à prototipação. Cite duas ou três aplicações que seriam mais difíceis de ser representadas em protótipos.,

91 Pontos a ponderar Os mitos de software citados em aula são somente alguns entre muitos outros. Liste mitos adicionais para cada uma das categorias apresentadas. Existe algum caso em que as fases genéricas do processo de engenharia de software não se aplicam? Se assim for, descreva-o.,


Carregar ppt "Engenharia de Software Engenharia de Software Prof. Inês Ap. Gasparotto Boaventura 1. Semestre/2001."

Apresentações semelhantes


Anúncios Google