A profissão



  • É uma profissão dedicada a projetar, implementar e modificar software de tal forma que seja de alta qualidade, manutenivel e rápido para construir
    • Por meio de uma abordagem sistemática para analisar, desenhar, avaliar, implantar, testar, manter e refazer um software.



  • Área do conhecimento da computação voltada para:
    • especificação
    • desenvolvimento
    • manutenção
  • de sistemas de software aplicando
    • técnicas
    • metodologias
    • teorias
    • tecnologias
    • práticas de gerência de projetos
    • outras disciplinas
  • objetivando
    • organização
    • produtividade
    • qualidade
    • eficácia
    • evolutibilidade.



  • Atualmente, essas tecnologias e práticas englobam
    • linguagens de programação
    • banco de dados
    • ferramentas
    • plataformas
    • bibliotecas
    • padrões
    • processos
    • Qualidade de Software.



  • Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro
    • especificar
    • projetar
    • implementar
    • manter
    • expandir
  • sistemas de software, avaliando e garantindo suas qualidades.



  • Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento de um Sistema de informação e de um Sistema computacional, pois ambos se confundem!



ES no mundo



  • Reino Unido: Chartered Engineers
  • Canadá: Profissional Engineers
  • EUA: Computer Engineer
  • Portugal: Software Engineer



  • 2006: Considerada a melhor área de trabalho nos EUA
  • 2010: A vez do Brasil


Conceito de Engenharia de Software



  • Surgiu a 40 anos atrás em função da Crise do Software



  • A experiência mostrou que o desenvolvimento informal de software não era suficiente




A Crise do Software



  • Consequências:
    • Projetos importantes com anos de atraso
    • Os custos superavam as previsões
    • Desempenho insatisfatório
    • Não era confiável
    • Difícil de manter



  • Os custos de hardware caíam e os custos de software aumentavam.



Estudo de Caso I

  • Ariane V


Sua capacidade era de 6 toneladas e garantiria a supremacia européia no espaço.


  • Lançamento em 4 de junho de 1996


  • Explosão 40 segundos após a decolagem


  • Destruição do foguete e carga avaliada em US$ 500 milhões




  • Situação: Foguete perdeu o controle de direção


  • Causa: Shut-down simultâneo nos computadores principal e back-up


  • Motivo: Run time error (out of range, overflow)


  • Software: Era considerado “perfeito”


  • Origem: Programa que convertia um valor em ponto flutuante para um inteiro de 16 bits recebeu como entrada um valor fora da faixa permitida.




Estudo de Caso II

Problema do ano 2000 (Wikipedia)


Bug do milênio (ou milénio ) ou Bug Y2K


Foi o termo usado para se referir ao problema previsto ocorrer em todos os

sistemas informatizados na passagem do ano de 1999 para 2000.


Bug é um jargão internacional usado por profissionais e conhecedores de programação, que significa um erro de lógica na programação de um determinado software.


Estudo de Caso III

31/01/2009 Falha no Google classifica todos os sites como malware


  • A falha: Por alguns minutos, todos os resultados de buscas foram classificados pelo Google como inseguros.


  • O fato repercutiu rapidamente movimentando fóruns, blogs e até o Twitter.


  • Situação: Enquanto durou o bug, todos os resultados foram marcados com "este site pode danificar seu computador" (malware).


  • No Twitter: Alguns usuários disseram que a pane também afetou o Gmail, enviando e-mails "bons" para a caixa de spam.



Estudo de Caso IV

04 de fevereiro de 2010: Toyota: Software é responsável por problemas de freio Prius


  • Não é novidade os problemas enfrentados pela Toyota, que obrigaram a montadora japonesa a realizar inúmeros recalls de seus veículos. Um dos modelos afetados nos Estados Unidos foi o Prius 2010.


  • Com defeitos no acelerador e nos freios, os proprietários foram convocados a levar seus veículos até a concessionária para corrigí-los.
  • Uma vez lá, tudo o que os mecânicos precisavam fazer era conectar o carro a um computador e fazer o download da nova versão do software responsável por controlar o sistema de freios


  • Ou seja, no futuro, além de problemas mecânicos os motoristas terão que lidar com falhas e bugs nos sistemas automotivos.



Estudo de Caso V

HTTP 404


O erro 404 ou "Not Found" é um código de resposta http que indica que o cliente pôde comunicar com o servidor mas ou o servidor não pôde encontrar o que foi pedido, ou foi configurado para não cumprir o pedido e não revelar a razão.


Estudo de Caso VI

  • 2038


  • O grave problema é uma falha na representação de datas em computadores, que pode causar erros em alguns programas de computador no ano de 2038.

O problema afeta os programas que utilizam a representação de tempo POSIX, em que a data é calculada através do número de segundos (ignorando os segundos bissextos) desde 1 de janeiro de 1970


Esta representação é padrão nos sistemas operacionais do tipo Unix e afeta a maioria dos sistemas, pois grande parte deste software foi desenvolvido na linguagem C. Na maioria dos sistemas de 32 bits, o tipo de dados time t, utilizado para armazenar esta contagem de segundos, é um inteiro de 32 bits do tipo signed (considera o sinal)


O último registro de tempo que pode ser representado por este formato, seguindo o padrão POSIX, é 03:14:07 na terça-feira 19 de janeiro de 2038 (UTC). Após este momento a data será representada por um número decimal negativo que, dependendo da implementação, corresponderá ao ano 1970 ou 1901


Este valor para a data corrente certamente resultará em erros de cálculo e de funcionamento na maior parte dos programas em execução pelo sistema.


Análise do Sotware


No início:


  • Programação era uma forma de arte


  • Poucos métodos formais eram aplicados


  • Esquema baseado em tentativa e erro


  • Mundo indisciplinado



Atualmente:


  • Software é o item de maior custo


  • Está presente em 99% dos negócios


  • Existe uma demora na conclusão:
    • Porque se usam métodos e ferramentas?
    • Por que surgem tantos erros?
    • Por que é difícil medir os erros?


  • Alto volume de manutenção nas aplicações


  • Modismo inconsciente.


FAQ (Frequently Asked Questions)


O que é software?


  • Instruções que quando executadas, produzem a função e o desempenho desejados
  • Estruturas de dados que permitem a manipulação das informações
  • Documentos que descrevem a operação e o uso dos programas


  • Existem basicamente duas classificações:
    • Produtos genéricos
    • Produtos sob encomenda



Qual a diferença entre Engenharia de Software e Engenharia da Computação?


  • Engenharia de Computação: Relação com teorias e fundamentos


  • Engenharia de Software: Relação com a prática de desenvolvimento e entrega de software útil e de qualidade.


  • Ideal: Engenheiro se basear na teoria da Ciência da Computação
  • Métodos ad hoc são necessários.





O que é processo de software?


Conjunto de atividades cujo objetivo é o desenvolvimento ou evolução de software



1. Especificação

2. Desenvolvimento

3. Validação

4. Evolução




Como é a distribuição dos custos na criação de um software?


  • 60% => Desenvolvimento
  • 40% => Testes e aceitação


Depende de algumas variáveis:

  • Porte do sistema
  • Integração
  • Tempo de vida
  • Reutilização





Quais são as principais categorias de software?


  • Software básico => Linguagens baixo nível

  • Software tempo real => Resposta imediata

  • Software comercial => Aplicações especificas

  • Software científico => Envolvem complexidade

  • Software embutido => Embarcado em dispositivos

  • Software para PC => Aplicações comuns

  • Software de IA => Programas que aprendem
  • Software para web => Internet




O que é CASE?


Acrônimo de Computer-Aided Software Engineering



Sistemas de software que fornecem apoio automatizado para atividades de processo de software.


  • Controle de Versão
  • Gerência de Projetos
  • Edição
  • Planejamento
  • Prototipagem
  • Teste
  • Documentação
  • Análise de Programa
  • Métricas
  • Programação
  • Reengenharia
  • Depuração
  • ?





Quais são os atributos de um bom software?


  • Facilidade de manutenção: Deve permitir evolução simplificada


  • Confiança: Confiabilidade, proteção e segurança


  • Eficiência: Não deve desperdiçar recursos do sistema


  • Usabilidade: Deve apresentar uma interface amigável com o usuário e documentação adequada





Quais os desafios-chave de ESOF?


  • Heterogeneidade: Flexibilidade, adaptação


  • Entrega: Menor tempo de desenvolvimento mantendo a qualidade


  • Confiança: Técnicas que mantenham a fidelidade do usuário.




Algumas perguntas


01) A crise do software ainda existe (existiu)? Gesmar

  • Sim.
  • Índice de sucesso em projetos
    • 68% dos projetos nunca foram colocados em produção ou foram cancelados
    • 45% acima do custo estimado
    • 63% acima do prazo esperado
    • 67% das funcionalidades é que são entregues
  • Presente
    • Silos = Bug Ping Pong
  • Impacto
    • Desenvolvedores sentem-se desmotivados
    • Testadores não são respeitados
    • Impacto negativo no negócio


02) Por que se errou tanto e se continua errando na construção de softwares? Tiago, Matheus e João Paulo

  • Entendimento distorcido de cada stakeholder
    • O desenvolvimento de software tem várias etapas (passagem de bastão)
    • Deve ter uma comunicação eficaz
    • Pode-se usar ferramentas para ajudar no conhecimento completo
    • As estimativas para definições de prazo e custo ainda são inadequados
  • Motivos:
    • Má prospecção dos requisitos
    • Levantamento inadequado dos riscos
    • Previsão de tempo de projeto subestimado
    • Planejamento rápido e sem detalhes
    • Não acompanhamento do avanço da tecnologia
    • Alto volume de tecnologia disponĩvel
  • Consequências dos erros?
    • Mais de 30% dos projetos são cancelados antes de serem finalizados
    • Mais de 70% dos projetos falham nas entregas das funcionalidades esperadas
    • Os custos extrapolam mais de 180% dos valores originalmente previstos
    • Os prazo excedem em mais de 200%, os cronogramas originais
  • Onde melhorar?
    • No planejamento
    • Na comunicação
    • Na aplicação e escolha das metodologias e tecnologias
  • O que os erros podem causar?
    • Insatisfação do contratante
    • Equipe desmotivada
    • Custo final extrapolado
    • Quebra de contrato e demissão em massa


03) O uso de um processo formal de desenvolvimento traz ganhos de produtividade para uma equipe? Júlio e Júlio

Antes de tentarmos responder esta pergunta, vamos relembrar o que é Processo Formal.

Planejamento é definido como:

  • quais atividades;
  • quem deve realiza-las;
  • como realizar;
  • por que realizar;
  • quando realizar e finalizar;
  • quanto deve custar.

Este planejamento resulta em:

  • realizar estimativas;
  • elaborar estrutura de divisão de trabalho;
  • definir equipe e recursos;
  • alocar pessoas e atividades;
  • elaborar cronograma;
  • elaborar orçamento.

Além disso, deve-se fazer:

  • análise de riscos;
  • revisões periódicas.

Já Modelos indicam quais são as atividades e as relações entre elas. Alguns exemplos são:

  • em cascata;
  • incremental;
  • evolucionário;
  • desenvolvimento ágil.

Reunindo os conceitos de planejamentos e modelos anteriores, definimos Processo Formal de software como o Planejamento associado a um Modelo de Processo.


Pontos positivos do Processo Formal:

  • o desenvolvedor sabe o que fazer;
  • a data para início e fim são definidas;
  • é possível dimensionar o tamanho;
  • é possível dimensionar a quantidade de artefatos;
  • é possível dimensionar o esforço necessário;
  • é possível ter noção quanto custa;
  • é possivel perceber se há recursos para o desenvolvimento;
  • facilita gerenciamento de equipe, produção, prazos, custos;
  • a possibilidade da utilização de métricas para estimações.

Pontos negativos:

  • a difícil escolha do modelo apropriado para cada especificidade. Exemplos: Processo Unificado Rational, Processo Unificado, Programação Extrema, etc.

Portanto, a eficiência no ganho de produtividade ao utilizarmos Processo Formal de Desenvolvimento depende da escolha certa do modelo.


04) Comprar não é melhor que fazer? Clarissa e Hudson

  • Deve-se avaliar o foco, o negócio e a estratégia
  • Comprando
    • Menor custo
    • Menor tempo de entrega
    • Não customizado
  • Fazendo
    • Customizado
    • Maior qualidade
    • Maior custo e tempo de entrega
  • Para fazer:
    • Necessita conhecimento, muito conhecimento
    • Demanda tempo e boa organização
    • Menor custoo, se bem feito
    • Personalizado
  • Para comprar:
    • Linha de montagem profissional
    • Equipe para manutenção
    • Vários níveis de customização
    • Alto custo
    • Demanda tempo
  • Avalie:
    • Os custos
    • Os riscos
    • O tempo
    • A necessidade
    • A comodidade


05) O desenvolvimento ágil, ajuda ou atrapalha? Alexandre e Deus

06) As revisões por pares são mais eficientes que testes funcionais? Luiz Cláudio

  • Manifesto Ágil
    • Indivíduos e interações são mais importantes que processos e ferramentas
    • Software funcionando é mais importante do que documentação completa e detalhada
    • Colaboração com o cliente é mais importante do que negociação de contratos
    • Adaptação a mudanças é mais importante do que seguir o plano inicial
  • Princípios:
    • Objetivo: satisfazer o cliente entregando, rapidamente e com freqüência, sistemas com algum valor
    • Entregar versões funcionais em prazos curtos
    • Estar preparado para requisitos mutantes
    • Pessoal de negócios e desenvolvedores juntos
    • Troca de informações através de conversas diretas
  • Principais métodos ágeis:
    • Programação eXtrema (XP)
    • Crystal (uma família de métodos)
    • Scrum
    • Lean
    • Feature-driven Development
    • e outros
  • Modelo Tradicional de Desenvolvimento de Software
    • A. Levantamento de Requisitos
    • B. Análise de Requisitos
    • C. Desenho da Arquitetura
    • D. Implementação
    • E. Testes
    • G. Produção / Manutenção
  • Princípios básicos do XP
    • Feedback rápido
    • Simplicidade é o melhor negócio
    • Mudanças incrementais
    • Embrace change => não valorize o medo
    • Alta qualidade do código
  • Programação em pares:
    • Erro de um detectado imediatamente pelo outro (grande economia de tempo)
    • Maior diversidade de idéias, técnicas, algoritmos
    • Enquanto um escreve, o outro pensa em contra-exemplos, problemas de eficiência, etc
    • Vergonha de escrever código feio (gambiarras) na frente do seu par
    • Pareamento de acordo com especialidades.Exemplos:
      • Sistema Multimídia Orientado a Objetos
      • Aplicação Web com alto nível de segurança
  • Testes no XP
    • Testes de unidade: escrito pelos programadores
    • Testes funcionais: escrito pelos clientes

07) POO é melhor que PP? Renato, Luciene e Leonardo

08) Uma empresa CMM Nível n+1 produz melhor software que uma empresa CMM Nível n? Will