Engenharia de Software

1
Engenharia de Software
2
Tópicos

• 1- Introdução à Engenharia de Software
• 2 - Fundamentos Organizacionais de Sistemas de
  Informação
• 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
Curva de falhas para o Hardware

6
Curva de falhas do Software
7
Aplicações do Software
8
Evolução do Software

• (1950 - 1965)
• 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

9
Evolução do Software

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

10
Evolução do Software

• (1975 - 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???)

11
Evolução do Software

• (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???)

12
Crise de Software

• Refere-se a um conjunto de problemas encontrados
  no desenvolvimento de software
• (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

13
Crise de Software

• (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

14
Crise de Software

• (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
• (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

15
Crise de Software

• estimativas de prazo e de custo ?
• produtividade das pessoas ?
• qualidade de software ?
• software difícil de manter ?

16
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!!!

17
Causas dos problemas associados à Crise de
Software

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

18
Causas dos problemas associados à Crise de
Software

• 3. mitos do Software
• propagaram desinformação e confusão
• administrativos
• cliente
• profissional

19
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?
20
Mitos do Software (administrativos)

• Meu pessoal tem ferramentas de desenvolvimento
  de software de última geração afinal lhes
  compramos os mais novos computadores.

Realidade É preciso muito mais do que os mais
recentes computadores para se fazer um
desenvolvimento de software de alta qualidade.
21
Mitos do Software (administrativos)

• Se nós estamos atrasados nos prazos, podemos
  adicionar mais programadores e tirar o atraso.

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.
22
Mitos do Software (clientes)

• Uma declaração geral dos objetivos é suficiente
  para se começar a escrever programas - podemos
  preencher os detalhes mais tarde.

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.
23
Mitos do Software (clientes)

• Os requisitos de projeto modificam-se
  continuamente, mas as mudanças podem ser
  facilmente acomodadas, porque o software é
  flexível.

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.
24
magnitude das mudanças
25
Mitos do Software (profissional)

• Assim que escrevermos o programa e o colocarmos
  em funcionamento nosso trabalho estará completo.

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.
26
Mitos do Software (profissional)

• Enquanto não tiver o programa "funcionando", eu
  não terei realmente nenhuma maneira de avaliar
  sua qualidade.

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.
27
Engenharia de Software

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

28
Engenharia de Software Definições

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

29
Engenharia de Software Definições

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

30
Engenharia de Software Definições

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

31
Engenharia de Software

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

32
Engenharia de Software

• métodos proporcionam os detalhes de como
  fazer para construir o software.

33
Engenharia de Software

• 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

34
Engenharia de Software

• 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

35
Engenharia de Software

• procedimentos constituem o elo de
• ligação 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.

36
Engenharia de Software

• conjunto de etapas que envolve
• métodos
• ferramentas
• procedimentos
• Essas etapas são conhecidas como componentes de
  CICLO DE VIDA DE SOFTWARE
• ou Processo de Software

37
Engenharia de Software

• Alguns ciclos de vida mais conhecidos são
• Ciclo de Vida Clássico
• Prototipação
• Modelo Espiral
• Técnicas de 4a Geração

38
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

39
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

40
Cascata
41
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
? visão essencial quando o software deve fazer
interface com outros elementos (hardware, pessoas
e banco de dados)
42
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
43
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

44
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

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

46
Atividades do Ciclo de Vida Clássico

• MANUTENÇÃO
• ? o software deverá sofrer mudanças depois que
  for entregue ao cliente

? 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
47
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

48
Clássico (comentários)

• Embora o Ciclo de Vida Clássico tenha
  fragilidades, ele é significativamente melhor do
  que uma abordagem casual ao desenvolvimento de
  software

49
Prototipação

• processo que possibilita que o desenvolvedor crie
  um modelo do software que deve ser construído.
• 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.

50
Prototipação
51
Atividades da Prototipação

• 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 representação dos aspectos do
  software que são visíveis ao usuário (abordagens
  de entrada e formatos de saída)

52
Atividades da Prototipação

• Construção Protótipo implementação do projeto
  rápido
• Avaliação do Protótipo cliente e desenvolvedor
  avaliam o protótipo

53
Atividades da Prototipação

• Refinamento dos Requisitos cliente e
  desenvolvedor refinam os requisitos do software a
  ser desenvolvido.
• 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.

54
Atividades da Prototipação
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.
55
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.

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

57
Prototipação (comentários)

• 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 ?

58
Ciclo de Vida em Espiral

• engloba as melhores características do ciclo de
  vida Clássico e da Prototipação, adicionando um
  novo elemento a Análise de Risco
• 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

59
Espiral
60
Atividades do Ciclo de Vida em Espiral

• 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 desenvolvimento do produto no nível
  seguinte
• Avaliação do Cliente avaliação do produto e
  planejamento das novas fases

61
Espiral (comentários)

• é, 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

62
Espiral (comentários)

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

63
Técnicas de 4a 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
• o sistema seja especificado em uma linguagem de
  alto nível e
• o código fonte seja gerado automaticamente a
  partir dessas especificações

64
Técnicas de 4a Geração
65
Ferramentas do ambiente de desenvolvimento de
software de 4GL

• O ambiente de desenvolvimento de software que
  sustenta o ciclo de vida de 4a 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

66
Atividades das Técnicas de 4a Geração

• 1. obtenção dos Requisitos o cliente descreve os
  requisitos os quais são traduzidos para um
  protótipo operacional

• 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"

67
Atividades das Técnicas de 4a Geração

• 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

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

68
Atividades das Técnicas de 4a Geração

• 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

69
Atividades das Técnicas de 4a Geração

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

70
Técnicas de 4a Geração (comentários)

• PROPONENTES redução dramática no tempo de
  desenvolvimento do software (aumento de
  produtividade)
• 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

71
Mudança na natureza de desenvolvimento de software
72
Combinação dos Métodos de Ciclo de Vida
73
Engenharia de Software uma visão genérica

• O processo de desenvolvimento de software contém
  3 fases genéricas, independentes do modelo de
  engenharia de software escolhido
• 1. DEFINIÇÃO,
• 2. DESENVOLVIMENTO e
• 3. MANUTENÇÃO.

74
Engenharia de Software uma visão genérica
75
Engenharia de Software uma visão genérica

• DEFINIÇÃO o que será desenvolvido.
• 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 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.

76
Engenharia de Software uma visão genérica

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

77
Engenharia de Software uma visão genérica

• DESENVOLVIMENTO como o software vai ser
  desenvolvido.
• 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.

78
Engenharia de Software uma visão genérica

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

79
Engenharia de Software uma visão genérica

• 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

80
Engenharia de Software uma visão genérica

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

81
Engenharia de Software uma visão genérica

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

82
Engenharia de Software uma visão genérica

• Atividades de Proteção as fases e etapas
  correlatas descritas são complementadas por uma
  série de atividades de proteção.
• Revisões efetuadas para garantir que a
  qualidade seja mantida à medida que cada etapa é
  concluída.

83
Engenharia de Software uma visão genérica

• Documentação é desenvolvida e controlada para
  garantir que informações completas sobre o
  software estejam disponíveis para uso posterior.
• Controle das Mudanças é instituído de forma que
  as mudanças possam ser aprovadas e acompanhadas.

84
Engenharia de Software uma abordagem gerencial

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

85
Engenharia de Software uma abordagem gerencial

• Em geral, um produto de software inclui
• -gt 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

86
Engenharia de Software uma abordagem gerencial

• Em geral, um produto de software inclui
• -gt 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

87
Engenharia de Software uma abordagem gerencial

• Qualidade de software preocupação principal
  dos
• gerentes de software.
• -gt Principal atributo de qualidade utilidade
• -gt outros atributos de qualidade
• - transportabilidade
• - eficiência
• - clareza
• - confiabilidade

88
Engenharia de Software uma abordagem gerencial

• Fatores de Qualidade e Produtividade
• Fatores que influenciam a qualidade
• Habilidade Individual
• Comunicação da equipe
• Complexidade do produto
• Notações apropriadas
• Abordagens sistemáticas
• controle de mudanças

89
Engenharia de Software uma abordagem gerencial

• Fatores de Qualidade e Produtividade
• Fatores que influenciam a qualidade
• Adequação de treinamento
• Habilidades de gerenciamento
• Metas apropriadas
• Entendimento do problema
• Estabilidade dos requisitos
• Habilidades necessárias

90
Engenharia de Software uma abordagem gerencial

• Questões gerenciais
• Os gerentes de software
• 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.

91
Engenharia de Software uma abordagem gerencial

• Questões gerenciais
• Os gerentes de software
• devem garantir que o produto tenha os atributos
  funcionais e de qualidade desejados pelo cliente.
• Treinam empregados.
• desenvolvem planos e estratégias de marketing.

92
Engenharia de Software uma abordagem gerencial

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

93
Engenharia de Software uma abordagem gerencial

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

94
Engenharia de Software uma abordagem gerencial

• Problemas na área de gerenciamento
• falta de planejamento para projetos de software.
• falta de técnicas e procedimentos para selecionar
  gerentes de projeto.
• falta de habilidade em estimar os recursos
  necessários para o projeto.

95
Engenharia de Software uma abordagem gerencial

• Problemas na área de gerenciamento
• falta de um processo de desenvolvimento bem
  estabelecido.
• falta de estratégias para o gerente acompanhar o
  progresso do projeto.
• falta de padrões e técnicas para medir
  produtividade.

96
Engenharia de Software uma abordagem gerencial

• Fatores que melhoram o gerenciamento
• treinar gerentes, e desenvolvedores de software.
• estabelecer o uso de padrões, procedimentos e
  documentação.
• analisar dados de projetos passados para avaliar
  métodos efetivos.

97
Engenharia de Software uma abordagem gerencial

• definir objetivos em termos de qualidade
  desejada.
• definir qualidade em termos de produtos a ser
  entregues.
• Selecionar gerentes de projetos com habilidades
  para gerenciamento.
• Desenvolver uma maneira de avaliar os
  desenvolvedores de software.

98
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
99
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?

,
100
Pontos a ponderar

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

,
101
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.

102
REFERÊNCIAS

• ANTUNES, Paulo Bessa. Direito Ambiental. 2ed.
  Amplamente Reformulado. 14ª ed., Rio de Janeiro
  Atlas, 2012.
• Amaral, Diogo Freitas, Ciência Política, vol I
  ,Coimbra,1990 
• AQUINO, Rubim Santos Leão de . et al. História
  das Sociedades Americanas. 7 ed. Rio de Janeiro
  Record, 2000.
• ARANHA, Maria Lúcia. Filosofando Introdução á
  Filosofia. São Paulo Moderna, 1993.
• ARRUDA, José Jobson de A. e PILETTI, Nelson. Toda
  a História. 4 ed. São Paulo Ática,
  1996.ASCENSÃO, José de Oliveira. Breves
  Observações ao Projeto de Substitutivo da Lei de
  Direitos Autorais. Direito da Internet e da
  Sociedade da Informação. Rio de Janeiro Ed.
  Forense, 2002.
• BRANCO JR., Sérgio Vieira. Direitos Autorais na
  Internet e o Uso de Obras Alheias. Ed. Lúmen
  Júris, 2007.
• BUZZI, Arcângelo. Introdução ao Pensar.
  Petrópolis ed. Vozes, 1997.CAPEZ,
  Fernando. Curso de Direito Penal. V. 2, Parte
  Especial. 10. Ed. São Paulo Saraiva, 2010.
• CERQUEIRA, João da Gama. Tratado da Propriedade
  Industrial, vol. II, parte II. Revista Forense
  Rio de Janeiro, 1952.
• CHAUÍ, Marilena. Convite á Filosofia. São
  Paulo,10ª. Ed.,Ática,1998.
• COTRIM, Gilberto. História Global Brasil e
  Geral. 6 ed. São Paulo Saraiva, 2002.
• CRETELLA JÚNIOR, José. Curso de Direito
  Administrativo. Rio de Janeiro Forense, 2003.
• DEON SETTE, MARLI T. Direito ambiental.
  Coordenadores Marcelo Magalhães Peixoto e Sérgio
  Augusto Zampol
• DINIZ, Maria Helena. Curso de direito civil
  brasileiro teoria das obrigações contratuais e
  extracontratuais. 3. ed. São Paulo Saraiva,
  1998, v. 3.
• DI PIETRO, Maria Sylvia Zanella. Direito
  Administrativo. São Paulo Atlas, 2005.
• COELHO, Fábio Ulhoa. Curso de direito comercial.
  6. ed. São Paulo Saraiva, 2002, v. 1, 2 e 3.

103
REFERÊNCIAS

• FERRAZ JUNIOR, Tercio Sampaio. Introdução ao
  Estudo do Direito técnica, decisão, dominação.
  6.ed. São Paulo Atlas, 2008.
• FIORILLO, Celso Antonio Pacheco. Curso de Direito
  Ambiental Brasileiro. 13ª ed., rev., atual. E
  compl. São Paulo Saraiva, 2012.
• FRAGOSO, Heleno Cláudio. Lições de direito penal
  especial. 11. ed. atual. por Fernando Fragoso.
  Rio de Janeiro Forense, 2005.
• GONÇALVES, Carlos Roberto. Direito Civil
  Brasileiro, vol I Parte Geral. São Paulo
  Saraiva, 2007
• GAGLIANO, Plablo Stolze PAMPLONA FILHO,
  Rodolfo. Novo curso de direito civil, v. 1 - 5
  ed. São Paulo Saraiva. 2004.
• GRINOVER, Ada Pellegrini et al. Código Brasileiro
  de Defesa do Consumidor comentado pelos autores
  do anteprojeto. 8. ed. rev., ampl. e atual. Rio
  de Janeiro FU, 2004.
• JESUS, Damásio E. de. Direito Penal V. 2
  Parte Especial dos Crimes Contra a Pessoa a dos
  Crimes Contra o Patrimônio. 30 ed. São Paulo
  Saraiva, 2010.
• LAKATOS,  Eva Maria. Introdução à Sociologia. São
  Paulo Atlas, 1997
• LAKATOS, E. M. MARCONI, M. A. Sociologia Geral.
  São Paulo Atlas, 1999
• MARQUES, Claudia Lima. Contratos no Código de
  Defesa do Consumidor o novo regime das relações
  contratuais.4. ed. rev., atual. e ampl. São
  Paulo RT, 2004.
• MARTINS FILHO, Ives Gandra da Silva. Manual de
  direito e processo do trabalho. 18.ed. São Paulo
  Saraiva, 2009.
• MARTINS, Sérgio Pinto.Direito do Trabalho. 25.ed.
  São Paulo Atlas, 2009.
• MARTINS, Carlos Benedito.  O que é Sociologia. 
  Rio de Janeiro Zahar, 1988
• MEDAUAR, Odete. Direito Administrativo Moderno.
  São Paulo RT, 2001.
• MEIRELLES, Hely Lopes. Direito Administrativo
  Brasileiro. São Paulo Malheiros, 1996.
• MIRABETE, Julio Fabbrini. Processo penal. 18. ed.
  São Paulo Editora Atlas, 2006.

104
REFERÊNCIAS

• MORAES, de Alexandre. Direito Constitucional. São
  Paulo Atlas, 2004.
• PEIXINHO, Manoel Messias. Os princípios da
  Constituição de 1988. Rio de Janeiro Lúmen
  Júris, 2001.
• Piçarra, Nuno, A separação dos poderes como
  doutrina e princípio constitucional um
  contributo para o estudo das suas origens e
  evolução, Coimbra, Coimbra Editora, 1989 
• NUCCI, Guilherme de Souza. Manual de processo
  penal e execução penal. 3. ed. São Paulo
  Editora Revista dos Tribunais, 2007.
• PEREIRA, Caio Mario da Silva. Instituições de
  direito civil, v.1. Rio de Janeiro Forense.
  2004.
• POLETTI, Ronaldo. Introdução ao Direito. 4. ed.,
  São Paulo Saraiva, 2010..
• PRADO, Luiz Regis. Curso de direito penal
  brasileiro. 11. ed. São Paulo RT, 2007, v. 2.
• REALE, Miguel. Lições Preliminares de Direito.
  27.ed São Paulo Saraiva, 2006.
• REQUIÃO, Rubens. Curso de direito comercial. 8.
  ed. São Paulo Saraiva, 1977, v. 1 e 2.
• RUSSOMANO, Mozart Victor. Comentários à
  Consolidação das Leis do Trabalho. 3. ed. Rio de
  Janeiro Forense, 2005.
• SELL, Carlos Eduardo. Sociologia Clássica .
  Itajai EdUnivali, 2002
• VENOSA, Sílvio de Salvo. Direito Civil (Parte
  Geral), v.1 3 ed. São Paulo Atlas. 2003.

ATENÇÃO Parte deste material foi coletado na
internet e não foi possível identificar a
autoria. Este material se destina para fins de
estudo e não se encontra completamente
atualizado.
105
FIM

• _________________Obrigado pela atenção!!
• Acimarney C. S. Freitas Advogado OAB-BA Nº
  30.553
• Professor de Direito do Instituto Federal de
  Educação Ciência e Tecnologia da Bahia IFBA
  campus de Vitória da Conquista
• Diretor do Instituto Federal de Educação Ciência
  e Tecnologia da Bahia IFBA campus de Brumado.
• Bacharel em Teologia
• Especialista em Direito Educacional - FTC
• Especialista em Educação Profissional e de Jovens
  e Adultos - IFBA
• Mestrando em Filosofia - UFSC
• Email acimarney_at_gmail.com
• Facebook Ney Maximus