Você está na página 1de 44
Disciplina: Engenharia de Software Introdução Profa. Anna Beatriz Marques Material adaptado de Dias Neto (2010)
Disciplina: Engenharia de Software Introdução Profa. Anna Beatriz Marques Material adaptado de Dias Neto (2010)
Disciplina: Engenharia de Software Introdução Profa. Anna Beatriz Marques Material adaptado de Dias Neto (2010)

Disciplina:

Engenharia de Software

Introdução

Profa. Anna Beatriz Marques

Disciplina: Engenharia de Software Introdução Profa. Anna Beatriz Marques Material adaptado de Dias Neto (2010)

Material adaptado de Dias Neto (2010)

O que é Engenharia de

Software?

“Engenharia de Software é a aplicação de uma abordagem sistemática, disciplinada e quantificável ao desenvolvimento,

operação e manutenção de software”

IEEE Std 610.12 (1990)

disciplinada e quantificável ao desenvolvimento, operação e manutenção de software” IEEE Std 610.12 (1990)
disciplinada e quantificável ao desenvolvimento, operação e manutenção de software” IEEE Std 610.12 (1990)

Mas eu já sei programar!

Mas eu já sei programar!  Por que preciso de Engenharia de Software?

Por que preciso de Engenharia de Software?

Mas eu já sei programar!  Por que preciso de Engenharia de Software?
Mas eu já sei programar!  Por que preciso de Engenharia de Software?
Mas eu já sei programar!  Por que preciso de Engenharia de Software?

Mas eu já sei programar!

Por que preciso de Engenharia de Software?

o

Programação é parte importante do processo de

o

Engenharia de Software, mas não é tudo!

Precisamos também saber

o

o

O que programar,

Como programar,

o

Se o que foi programado está certo, o etc.

tudo!  Precisamos também saber o o O que programar, Como programar, o Se o que
Precisamos também saber o o O que programar, Como programar, o Se o que foi programado
Precisamos também saber o o O que programar, Como programar, o Se o que foi programado

Programas acadêmicos

Requisitos estáveis e bem definidos

Escopo pequeno (1-10 KLOCS) Prazos razoáveis Equipes pequenas Mão de obra gratuita Não entra em produção Ausência de cliente Ausência de manutenção

razoáveis Equipes pequenas Mão de obra gratuita Não entra em produção Ausência de cliente Ausência de
razoáveis Equipes pequenas Mão de obra gratuita Não entra em produção Ausência de cliente Ausência de

Programas do “mundo real”

Fazer software no “mundo real” deve considerar fatores como:

software no “mundo real” deve considerar fatores como:  Custo  Prazo  Qualidade  Em
software no “mundo real” deve considerar fatores como:  Custo  Prazo  Qualidade  Em

Custo

Prazo

Qualidade

fatores como:  Custo  Prazo  Qualidade  Em função do tamanho do software, esses
fatores como:  Custo  Prazo  Qualidade  Em função do tamanho do software, esses

Em função do tamanho do software, esses fatores se tornam difíceis de

garantir!

 Prazo  Qualidade  Em função do tamanho do software, esses fatores se tornam difíceis
 Prazo  Qualidade  Em função do tamanho do software, esses fatores se tornam difíceis

Cenário 1: Agenda

Objetivo

o Guardar eventos, reuniões e compromissos.

Quanto custa para fazer? Quanto tempo vai levar para ficar pronto?

  Quanto custa para fazer? Quanto tempo vai levar para ficar pronto?  Qual a

Qual a consequência no caso de defeito?

 Quanto custa para fazer? Quanto tempo vai levar para ficar pronto?  Qual a consequência
 Quanto custa para fazer? Quanto tempo vai levar para ficar pronto?  Qual a consequência

Cenário 2: Boeing 777

Objetivo

Controlar todo o hardware do Boeing 777

Quanto custa para fazer?

hardware do Boeing 777    Quanto custa para fazer? Quanto tempo vai levar para

Quanto tempo vai levar para ficar pronto?

Qual a consequência no caso de defeito?

 Quanto custa para fazer? Quanto tempo vai levar para ficar pronto? Qual a consequência no
 Quanto custa para fazer? Quanto tempo vai levar para ficar pronto? Qual a consequência no
O que acontece se o desenvolvedor errar?  CASO REAL 1: Therac – 25 Máquina
O que acontece se o
desenvolvedor errar?
 CASO REAL 1: Therac – 25
Máquina de radioterapia controlada por computador
Problema:
Doses indevidas de radiação emitidas
Causa:
Interface com usuário inapropriada
Documentação deficiente
Software reutilizado sem ser adaptado
para o novo hardware
Software de sensores de falha com
defeito
Consequências
Ao menos 5 mortes entre 1985 e 1987

O que acontece se o

desenvolvedor errar?

CASO REAL 2: Mars Climate Orbiter

desenvolvedor errar?  CASO REAL 2: Mars Climate Orbiter Sonda da NASA lançada para realizar o

Sonda da NASA lançada para realizar o estudo das variáveis atmosféricas

Problema:

Foi destruído devido a um erro de navegação

Causa:

A equipe da Terra usou medidas inglesas para calcular os parâmetros de inserção e enviou os dados a nave e esta

apenas realizavam cálculos no sistema métrico.

Consequências

perda de US$ 300 milhões

    
apenas realizavam cálculos no sistema métrico. Consequências  perda de US$ 300 milhões   

Software X Hardware

Software é desenvolvido por um processo de engenharia

Alto custo de criação (na maioria desenvolvido sob encomenda) Baixo custo de reprodução Não se desgasta Defeitos no produto usualmente são conseqüências de problemas no processo de desenvolvimento.

Hardware é manufaturado

Alto custo de reprodução

Pode desgastar

Pode ser substituído na totalidade ou em partes

  Alto custo de reprodução Pode desgastar  Pode ser substituído na totalidade ou em
  Alto custo de reprodução Pode desgastar  Pode ser substituído na totalidade ou em

Software X Hardware

Software X Hardware  Curva ideal de falha de software

Curva ideal de falha de software

Software X Hardware  Curva ideal de falha de software
Software X Hardware  Curva ideal de falha de software
Software X Hardware  Curva ideal de falha de software

Software X Hardware

Curva real de falha de software

Software X Hardware  Curva real de falha de software
Software X Hardware  Curva real de falha de software
Software X Hardware  Curva real de falha de software

Engenharia de Software

“É a criação e a utilização de sólidos princípios de

engenharia afim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em máquinas reais.” Fritz Bauer, 1969.

“Aplicação de uma abordagem sistemática, disciplinada e quantificável, para o desenvolvimento, operação e manutenção do

software; isto é, a aplicação de engenharia ao

software.”

IEEE Std610.12 (1990)

operação e manutenção do software; isto é, a aplicação de engenharia ao software.” IEEE Std610.12 (1990)
operação e manutenção do software; isto é, a aplicação de engenharia ao software.” IEEE Std610.12 (1990)
Atributos de um bom software Descrição Característica do produto Confiabilidade e segurança Manutenabilidade O

Atributos de um bom software

Descrição

Característica do produto Confiabilidade e segurança
Característica
do produto
Confiabilidade e
segurança

Manutenabilidade O software deve ser construído de tal forma que possa atender as novas necessidades do cliente. A mudança é

uma exigência inevitável em um ambiente de negócios em

constante mudança.

em um ambiente de negócios em constante mudança. Softwarews confiáveis não devem causar danos físicos ou

Softwarews confiáveis não devem causar danos físicos ou econômicos em caso de falha no sistema. Usuários com más intenções não devem ser capazes de acessar ou danificar o sistema.

Eficiência Um software eficiente não deve desperdiçar recursos do

sistema, como memória ou processador. Eficiência inclui a capacidade de resposta, tempo de processamento, utilização de memória, etc.

Aceitabilidade Software deve ser aceitável pelos usuários para os quais foi

projetado. Isto siginifica que o software deve ser

compreensível, usável e compatível com outros sistemas

que estes usuários utilizam.

Elementos da Engenharia de

Software

Elementos da Engenharia de Software Ferramentas Métodos Processo Foco na qualidade
Ferramentas Métodos Processo Foco na qualidade
Ferramentas
Métodos
Processo
Foco na qualidade
Elementos da Engenharia de Software Ferramentas Métodos Processo Foco na qualidade
Elementos da Engenharia de Software Ferramentas Métodos Processo Foco na qualidade

Elementos da Engenharia de

Software

A base em que se apoia é o foco em qualidade Processo:

A camada de processo é o alicerce Define os passos gerais para o desenvolvimento e manutenção do software Serve como uma estrutura de encadeamento de métodos e ferramentas

Métodos

São os “how to’s” de como fazer um passo específico do processo para construir software

Ferramentas

Automatizam o processo e os métodos.

um passo específico do processo para construir software  Ferramentas  Automatizam o processo e os
um passo específico do processo para construir software  Ferramentas  Automatizam o processo e os

Receita de brigadeiro

Receita de brigadeiro 1.Coloque em uma panela funda o leite condensado, a margarina e o chocolate

1.Coloque em uma panela funda o leite

condensado, a margarina e o chocolate em pó.

2.Cozinhe [no fogão] em fogo médio e mexa sem parar com uma colher de

pau.

O que é

processo, método e ferramenta?

3.Cozinhe até que o brigadeiro comece a desgrudar da panela.

4.Deixe esfriar bem, então unte as mãos

com margarina, faça as bolinhas e

envolva-as em chocolate granulado.

4.Deixe esfriar bem, então unte as mãos com margarina, faça as bolinhas e envolva-as em chocolate
4.Deixe esfriar bem, então unte as mãos com margarina, faça as bolinhas e envolva-as em chocolate
4.Deixe esfriar bem, então unte as mãos com margarina, faça as bolinhas e envolva-as em chocolate

Receita de brigadeiro

Receita de brigadeiro Processo Ferramentas Métodos 1. Coloque em uma panela funda o leite condensado, a
Processo Ferramentas
Processo
Ferramentas

Métodos

1.Coloque em uma panela funda o leite

condensado, a margarina e o chocolate em pó.

funda o leite condensado, a margarina e o chocolate em pó. 2. Cozinhe [no fogão ]

2.Cozinhe [no fogão] em fogo médio e mexa sem parar com uma colher de

pau.

3.Cozinhe até que o brigadeiro comece a desgrudar da panela.

4. Deixe esfriar bem, então unte as mãos

com margarina, faça as bolinhas e

envolva-as em chocolate granulado.

O supermercado de

Engenharia de Software

ES fornece um conjunto de

métodos para produzir software de qualidade

um conjunto de métodos para produzir software de qualidade Pense como em um supermercado o Em

Pense como em um supermercado

o Em função do problema, se escolhe o processo, os métodos e as ferramentas

Cuidado

Menos do que o necessário pode levar a

desordem

o Mais do que o necessário pode emperrar o projeto

  o
o
Menos do que o necessário pode levar a desordem o Mais do que o necessário pode

Engenharia de Software é mesmo importante?

Engenharia de Software é mesmo importante? Academia + Indústria Prêmio de MELHOR ARTIGO como relato de
Academia + Indústria
Academia + Indústria

Prêmio de MELHOR ARTIGO como relato de experiência do SBQS 2014:

“Avaliando a qualidade de um aplicativo web móvel através de um

teste de usabilidade: um relato de experiência”

“Avaliando a qualidade de um aplicativo web móvel através de um teste de usabilidade: um relato
“Avaliando a qualidade de um aplicativo web móvel através de um teste de usabilidade: um relato

Personagens da Engenharia

Personagens da Engenharia de Software  Gerente        Cliente Usuário

de Software

Gerente

Cliente Usuário Analista Arquiteto de Software Desenvolvedor Equipe de Teste e nós!!!

       Cliente Usuário Analista Arquiteto de Software Desenvolvedor Equipe de
       Cliente Usuário Analista Arquiteto de Software Desenvolvedor Equipe de
     Cliente Usuário Analista Arquiteto de Software Desenvolvedor Equipe de Teste e
     Cliente Usuário Analista Arquiteto de Software Desenvolvedor Equipe de Teste e
O Gerente  Responsabilidades:  Planejar e controlar a execução das demandas de projetos de

O Gerente

Responsabilidades:

Planejar e controlar a execução das

demandas de projetos de software;

Acompanhar o treinamento, avaliar o desempenho de sua equipe e mantê-la motivada, resolvendo conflitos. Desenvolver o cronograma do projeto; Definir práticas para garantir a integridade e a qualidade dos artefatos do projeto. Conduzir o projeto, com o respaldo dos stakeholders.

Habilidades:

Experiência no domínio da aplicação; Planejamento e análise de decisões. Apresentação, comunicação e negociação;

Gerenciamento de tempo, escopo, riscos, estimativas.

de decisões. Apresentação, comunicação e negociação;  Gerenciamento de tempo, escopo, riscos, estimativas .
de decisões. Apresentação, comunicação e negociação;  Gerenciamento de tempo, escopo, riscos, estimativas .

O Cliente

É quem contrata e paga pelo serviço Responsabilidade

Identificar os usuários que devem fornecer os

requisitos a serem desenvolvidos. Formalizar o contrato de desenvolvimento do software.

Avaliar se o produto entregue atende às

necessidades.

 Formalizar o contrato de desenvolvimento do software.  Avaliar se o produto entregue atende às
Formalizar o contrato de desenvolvimento do software.  Avaliar se o produto entregue atende às necessidades.
Formalizar o contrato de desenvolvimento do software.  Avaliar se o produto entregue atende às necessidades.

O usuário

É quem irá utilizar o software em

Seu dia-a-dia.

Responsabilidade

utilizar o software em Seu dia-a-dia.  Responsabilidade    Fornecer com detalhes aos engenheiros

Fornecer com detalhes aos engenheiros de

software os requisitos a serem desenvolvidos.

Realizar reuniões periódicas para elicitação e verificação dos requisitos. Avaliar se o produto entregue atende às

necessidades.

periódicas para elicitação e verificação dos requisitos. Avaliar se o produto entregue atende às necessidades.
periódicas para elicitação e verificação dos requisitos. Avaliar se o produto entregue atende às necessidades.

O Analista de Sistemas

Responsabilidades:

Liderar e coordenar a identificação e especificação

de requisitos e a modelagem de casos de uso, delimitando o sistema e definindo sua funcionalidade;

Revisar os requisitos escritos.

Projetar a interface das aplicações.

requisitos escritos. Projetar a interface das aplicações.   Habilidades:    Ser um bom

Habilidades:

Ser um bom facilitador; Comunicação acima da média. Conhecimento dos domínios do negócio e da tecnologia.

  Ser um bom facilitador; Comunicação acima da média. Conhecimento dos domínios do negócio e
  Ser um bom facilitador; Comunicação acima da média. Conhecimento dos domínios do negócio e

O Arquiteto de Software

Responsabilidades:

Liderar e coordenar as atividades e os artefatos técnicos no decorrer do projeto.

Estabelecer a estrutura geral de cada visão de arquitetura:

A decomposição da visão, o agrupamento dos

elementos e as interfaces entre esses principais

agrupamentos.

Habilidades:

Conhecer totalmente os requisitos. Tomar decisões técnicas importantes e fazer com que essas decisões sejam cumpridas à risca. O arquiteto de software é a força técnica orientadora existente por trás do projeto, não um visionário ou sonhador.

O arquiteto de software é a força técnica orientadora existente por trás do projeto, não um
O arquiteto de software é a força técnica orientadora existente por trás do projeto, não um

O Desenvolvedor

Responsabilidade:

Desenvolver e testar componentes de acordo

com os padrões adotados para o projeto, para fins de

integração com subsistemas maiores. Desenvolver e testar os componentes de software e os subsistemas correspondentes. Revisar o código escrito e corrigir defeitos encontrados.

Habilidades:

Familiaridade com ferramentas usadas para desenvolvimento e automação de testes Habilidades de programação

Conhecimento do sistema ou do aplicativo

para desenvolvimento e automação de testes Habilidades de programação  Conhecimento do sistema ou do aplicativo
para desenvolvimento e automação de testes Habilidades de programação  Conhecimento do sistema ou do aplicativo
para desenvolvimento e automação de testes Habilidades de programação  Conhecimento do sistema ou do aplicativo

A Equipe de Teste

Responsabilidades:

Planejamento, projeto, execução e controle dos testes.

Podem ser divididas entre gerentes de teste, projetistas de

teste e testadores.

Funções:

Identificar a abordagem de implementação mais apropriada para um dado teste. Planejar cronograma e custos para os testes em um projeto.

Identificar as técnicas de teste e ferramentas de suporte apropriadas. Especificar e executar os testes

Registrar os resultados dos testes

os testes Registrar os resultados dos testes      Analisar falhas na execução

Analisar falhas na execução do software

Monitorar a execução dos testes

testes      Analisar falhas na execução do software  Monitorar a execução
testes      Analisar falhas na execução do software  Monitorar a execução

E nós!

Engenheiros de software:

Solucionador de problemas Necessidade de trabalhar em equipe Adequar sua função ao seu perfil

Requer uma formação aprimorada para exercê-la!! Aproveitar as qualidades e potencial de cada membro da equipe Suprir as carências de cada membro da equipe.

exercê-la!! Aproveitar as qualidades e potencial de cada membro da equipe Suprir as carências de cada
exercê-la!! Aproveitar as qualidades e potencial de cada membro da equipe Suprir as carências de cada

E nós!

Liste quais seriam suas habilidades como

engenheiro de software.

Indique quais os personagens que você acredita que desempenharia bem,

dentre os listados na aula.

Justifique sua escolha.

quais os personagens que você acredita que desempenharia bem, dentre os listados na aula. Justifique sua
quais os personagens que você acredita que desempenharia bem, dentre os listados na aula. Justifique sua

Mitos do Software

Basta um bom livro de Engenharia de Software para fazer bom software.

livro de Engenharia de Software para fazer bom software. Realidade: Um bom livro certamente ajuda, mas

Realidade:

Um bom livro certamente ajuda, mas ele precisa refletir as técnicas mais modernas de Engenharia de

Software e ser lido!

33

livro certamente ajuda, mas ele precisa refletir as técnicas mais modernas de Engenharia de Software e
livro certamente ajuda, mas ele precisa refletir as técnicas mais modernas de Engenharia de Software e

Mitos do Software

Se estivermos como cronograma atrasado, basta adicionar mais gente ao projeto

cronograma atrasado, basta adicionar mais gente ao projeto Realidade:  Adicionar gente a um projeto atrasado

Realidade:

Adicionar gente a um projeto atrasado faz o projeto atrasar mais!

As pessoas que estão entrando terão que aprender

sobre o projeto antes de começar a ajudar no desenvolvimento. As pessoas que estão no desenvolvimento, terão

que parar para explicar aos que estão entrando

34

 As pessoas que estão no desenvolvimento, terão que parar para explicar aos que estão entrando
 As pessoas que estão no desenvolvimento, terão que parar para explicar aos que estão entrando

Mitos do Software

Se o projeto for terceirizado, todos os meus problemas estão resolvidos.

terceirizado, todos os meus problemas estão resolvidos. Realidade: É mais difícil gerenciar projetos

Realidade:

É mais difícil gerenciar projetos terceirizados do que projetos internos!

35

estão resolvidos. Realidade: É mais difícil gerenciar projetos terceirizados do que projetos internos! 35
estão resolvidos. Realidade: É mais difícil gerenciar projetos terceirizados do que projetos internos! 35

Mitos do Software

Basta dar uma idéia geral do que é necessário no início

Basta dar uma idéia geral do que é necessário no início Realidade:  Requisitos ambíguos normalmente

Realidade:

Requisitos ambíguos normalmente são uma receita para desastre! Comunicação contínua com o cliente é fundamental!

36

ambíguos normalmente são uma receita para desastre!  Comunicação contínua com o cliente é fundamental! 36
ambíguos normalmente são uma receita para desastre!  Comunicação contínua com o cliente é fundamental! 36

Mitos do Software

Modificações podem ser facilmente acomodadas, porque software é flexível.

ser facilmente acomodadas, porque software é flexível. Realidade:  O impacto de modificações no software

Realidade:

O impacto de modificações no software varia em função da modificação e do momento em que ela é requisitada!

Comunicação contínua com o cliente é

fundamental!

37

modificação e do momento em que ela é requisitada!  Comunicação contínua com o cliente é
modificação e do momento em que ela é requisitada!  Comunicação contínua com o cliente é

Mitos do Software

Assim que o código for escrito o trabalho termina.

 Assim que o código for escrito o trabalho termina. Realidade:  60% a 80% do

Realidade:

60% a 80% do esforço será gasto depois que o código foi escrito! Vale a pena esforçar para chegar a um bom código (boa documentação, bom projeto, etc.)!

38

foi escrito!  Vale a pena esforçar para chegar a um bom código (boa documentação, bom
foi escrito!  Vale a pena esforçar para chegar a um bom código (boa documentação, bom

Mitos do Software

Só é possível verificar a qualidade de um software quando o executável existir

a qualidade de um software quando o executável existir Realidade: Revisões usualmente são mais eficazes que

Realidade:

Revisões usualmente são mais eficazes que testes, e podem ser utilizadas antes do software estar

executável!

39

Revisões usualmente são mais eficazes que testes, e podem ser utilizadas antes do software estar executável!
Revisões usualmente são mais eficazes que testes, e podem ser utilizadas antes do software estar executável!

Mitos do Software

O único produto a ser entregue em um projeto é o código.

O único produto a ser entregue em um projeto é o código. Realidade: Além do código,

Realidade:

Além do código, documentações tanto para a manutenção quanto para o uso são fundamentais!

40

Realidade: Além do código, documentações tanto para a manutenção quanto para o uso são fundamentais! 40
Realidade: Além do código, documentações tanto para a manutenção quanto para o uso são fundamentais! 40

Mitos do Software

Engenharia de software gera documentação desnecessária.

Engenharia de software gera documentação desnecessária. Realidade:  Engenharia de software foca em criar

Realidade:

Engenharia de software foca em criar qualidade, e não criar documentos! Algum grau de documentação é necessário para evitar retrabalho! Questione sempre que encontrar um documento desnecessário para o projeto!

41

necessário para evitar retrabalho!  Questione sempre que encontrar um documento desnecessário para o projeto! 41
necessário para evitar retrabalho!  Questione sempre que encontrar um documento desnecessário para o projeto! 41

Jogo dos “seteerros

A nossa empresa fez o levantamento dos requisitos

com o cliente tentando esclarecer todas as

ambigüidades. Após a fase de levantamento dos requisitos, o projeto passou para a fase de codificação.

Ao final da codificação e geração do executável, o

projeto foi testado.

Só após o teste, a empresa acionou o cliente novamente para a entrega do código gerado.

Durante a fase de codificação e após verificar um

atraso no cronograma, mais profissionais foram

incluídos na equipe e parte do projeto foi terceirizada.

Após a codificação do produto, toda a equipe foi deslocada para o desenvolvimento de outro projeto.

 Após a codificação do produto, toda a equipe foi deslocada para o desenvolvimento de outro
 Após a codificação do produto, toda a equipe foi deslocada para o desenvolvimento de outro

Nós precisamos de Engenharia de Software

Nós precisamos de Engenharia de Software
Nós precisamos de Engenharia de Software
Nós precisamos de Engenharia de Software
Nós precisamos de Engenharia de Software

Dúvidas?

Dúvidas?
Dúvidas?
Dúvidas?