Engenharia de

Software I
Instituto Federal de Mato Grosso do Sul
Tecnólogo em Análise e Desenvolvimento de
Sistemas
Prof. Me. Wilbert Viana Barbosa
Ementa
 Introdução à Engenharia de Software, ciclo de vida de
um software;
 Metodologias e modelos de desenvolvimento de
software, processos de desenvolvimento de software;
 Práticas de desenvolvimento de software, introdução à
engenharia de requisitos, introdução à análise e
modelagem de software
Introdução à Engenharia
de Software
Desenvolvimento de software profissional
Ética na Engenharia de Software
Referência
 SOMMERVILLE, Ian. Engenharia de Software, 10ª ed. São
Paulo: Pearson Education do Brasil, 2018.
O que é Engenharia de Software?

 A engenharia de software é uma disciplina de

engenharia que se preocupa com os aspectos da
produção de software, desde sua concepção inicial até
sua operação e manutenção.
 Especificação;
 desenvolvimento;
 validação; e
 evolução do software.
 Entregar o produto certo dentro do prazo.
Engenharia de Software - Histórico

 Crise do Software – 1968 (quando o conceito de

engenharia de software foi proposto pela primeira vez)
 Sistemas pouco confiáveis;
 Sistemas mais caros que o previsto;
 Sistemas desenvolvidos num prazo muito maior do que o
estipulado.
 1970 e 1980 – desenvolvimento de uma série de
técnicas e métodos de engenharia de software.
Desenvolvimento de software profissional

 Diferentes de softwares “pessoal”, o software

profissional se destina a ser utilizado por outras pessoas
além de seu desenvolvedor e é desenvolvido
normalmente por times, e não por indivíduos; é mantido
e alterado ao longo de sua vida útil.
 Documentação;
 Bibliotecas;
 Websites de apoio
 Dados de configuração;
 Descrição da estrutura;
 Manual do uso.
Desenvolvimento de software profissional

 No desenvolvimento de software profissional, há dois

tipos de produto de software;
 Produtos genéricos: (stand-alone)
 SGBDs;
 Pacotes office;
 Pacotes de Desenho;
 Ferramentas de Gerenciamento de Projetos.
 Software personalizado: (feito sob medida)
 Sistemas de controle para dispositivos eletrônicos;
 Sistema de apoio de processos de negócio;
 ERP e CRM.
Desenvolvimento de software profissional

 Atributos essenciais de um bom software

Característica do produto Descrição

Aceitabilidade O software deve ser aceitável para o tipo de usuário para o qual foi projetado. Isso significa que deve ser
inteligível, útil e compatível com outros sistemas utilizados pelos usuários.
Dependabilidade e segurança A dependabilidade do software inclui uma gama de características, incluindo confiabilidade, segurança da
da informação (security) informação (security) e segurança (safety). O software com dependabilidade não deve causar danos físicos ou
econômicos em caso de falha do sistema. Ele também deve ser protegido para que usuários maliciosos não
consigam acessar ou danificar o sistema.
Eficiência O software não deve desperdiçar os recursos do sistema, como memória e ciclos do processador. Portanto,
eficiência inclui responsividade, tempo de processamento, utilização de recursos etc.
Manutenibilidade O software deve ser escrito de forma que possa evoluir e satisfazer às necessidades mutáveis dos clientes. Esse
é um atributo crítico, pois a modificação do software é um requisito inevitável de um ambiente empresarial
mutável.
Desenvolvimento de software profissional
 Disciplina de engenharia. Engenheiros fazem as coisas funcionarem.
Eles aplicam teorias, métodos e ferramentas onde for apropriado. No
entanto, eles os usam seletivamente e sempre tentam descobrir as
soluções para os problemas, mesmo quando não há teorias e
métodos aplicáveis. Os engenheiros também reconhecem que
devem trabalhar de acordo com as restrições organizacionais e
financeiras, então buscam soluções dentro dessas restrições.
 Todos os aspectos da produção de software. A engenharia de
software não se preocupa apenas com os processos técnicos do
desenvolvimento de software. Ela também inclui atividades como
gerenciamento de projeto de software e desenvolvimento de
ferramentas, métodos e teorias para apoiar a produção de software.
Desenvolvimento de software profissional

 No desenvolvimento de software profissional, a

Engenharia se trata de obter resultados que atendam à
qualidade exigida, dentro do cronograma e do
orçamento.
 Fazer conceções
 Evitar um certo perfeccionismo
Desenvolvimento de software profissional

 Importância
 Dependência crescente de sistemas de softwares avançados
 Aumento da qualidade e redução de custo e tempo no
desenvolvimento
Desenvolvimento de software profissional

 Processo de Software: a abordagem sistematizada

utilizada na engenharia de software é chamada de
processo de software e consististe em uma sequência
de atividades que leva à produção de software
Desenvolvimento de software profissional

 Quatro Atividades comuns no processo de software

 Especificação de software, em que clientes e engenheiros
definem o software a ser produzido e as restrições de sua
operação;
 Desenvolvimento de software, em que o software é
projetado e programado;
 Validação de software, em que o software é verificado para
garantir que é o que o cliente quer;
 Evolução de software, em que o software é modificado para
refletir a mudança de requisitos do cliente e do mercado.
Questões
 Por que Engenharia de Software?
 Quais são as diferenças entre desenvolvimento de
software amador e profissional?
 Quais são os atributos essenciais de um bom software?
 O que é Processo de Software?
Ética na Engenharia de Software
 Condutas profissionais
 Confidencialidade
 Competência
 Direitos de propriedade intelectual
 Mau uso de computador
Ética na Engenharia de Software
 Código de Conduta da ACM e IEEE - Princípios
1. Público
2. Cliente e empregador
3. Produto
4. Julgamento/Opinião
5. Gerenciamento/Gestão
6. Profissão
7. Colegas
8. Si Próprio/Caráter
Questões
 O Que é e qual é o papel da tecnologia na Sociedade?
 Qual é o meu papel como desenvolvedor de tecnologia?
 Quais são as minhas responsabilidades para com a
sociedade no que diz respeito ao desenvolvimento de
tecnologias?
Aula 02 – Processos de
Software
Modelos de processo de software
Atividades do processo
Processo de Software

Conjunto de atividades relacionadas que levam à

produção de um sistema de software.
Sommerville (2018 p. 29)
Processo de Software

Especificação. Desenvolvimento. Validação. Evolução.

• A funcionalidade do • O software deve ser • O software deve ser • O software deve
software e as produzido para validado para evoluir para atender
restrições sobre atender às garantir que atenda às mudanças nas
suas operações especificações. às demandas do necessidades dos
devem ser cliente. clientes.
definidas.
Modelos de Processo de Software

Modelo em Desenvolvimento Integração e

Cascata Incremental configuração

Baseia-se na disponibilidade de
Representa atividades fundamentais Intercala as atividades de
componentes ou sistemas reusáveis.
do processo, como especificação, especificação, desenvolvimento e
O processo de desenvolvimento do
desenvolvimento, validação e validação. O sistema é desenvolvido
sistema concentra-se na
evolução, na forma de fases como uma série de versões
configuração desses componentes,
distintas, como especificação de (incrementos), com cada uma delas
para que sejam utilizados em um
requisitos, projeto de software, acrescentando funcionalidade à
novo contexto, e na integração
implementação e testes. versão anterior.
deles em um sistema.
Modelo em cascata
Desenvolvimento Incremental
E.S. orientada a reuso
Especificação do Software
 Engenharia de Requisitos
 Compreender e definir quais serviços são necessários
para o sistema e identificar as restrições sobre suas
operações e desenvolvimento.
 Erro nesta etapa geram problemas posteriores no
projeto e na implementação do sistema.
 O processo de engenharia de requisitos visa a produção
de um documento de requisitos acordados que
especifique um sistema que satisfaça os requisitos dos
stakeholders.
Especificação do Software
Leitura recomendada
 Requisitos funcionais e não funcionais: o que são?
Atividade em sala
 Separem-se em grupos de 4 a 6 integrantes (não é
necessário ser do mesmo período)
 Reúna com o seu grupo e faça um “brainstorm”
indicando possíveis produtos (sistemas) que poderiam
ser desenvolvidos com fins mercadológicos.
 Cadastrem o grupo em no link abaixo:
 https://forms.gle/Q5veaZ1vhXHZmZi46
Questão 01 – prova interdisciplinar
O conceito de engenharia de software foi proposto a) Complexidade: O software tornou-se cada vez mais complexo
ao longo do tempo, o que torna difícil prever como ele se
pela primeira vez em 1968, em uma conferência
comportará em todas as situações.
realizada para discutir o que então se chamava de
b) Atrasos e orçamentos estourados: Projetos de software
crise do software (NAUR, RANDELL, 1969). Ficou claro
muitas vezes enfrentam atrasos significativos e estouros de
que as abordagens individuais ao desenvolvimento orçamento.
de programas não escalavam para sistemas de
c) Mudanças de requisitos: Requisitos de software podem
software grandes e complexos. mudar ao longo do tempo, o que pode causar desafios
adicionais no desenvolvimento de software.
Dentre os fatores abaixo, qual deles NÃO foi
considerado um motivo para o desencadeamento da d) Qualidade e confiabilidade: Muitos sistemas de software têm
crise do software: problemas de qualidade e confiabilidade, o que pode resultar
em falhas, bugs e vulnerabilidades de segurança.

e) Abundância de talentos: A demanda por profissionais de

software qualificados era suprida na época, porém a
ausências de métodos eficazes de desenvolvimento resultava
em projetos mal executados.
Questão 02 – prova interdisciplinar
A engenharia de software surgiu para lidar com o problema que a) Estão corretas as afirmativas I, II e III.
assolava o desenvolvimento de softwares profissional. A partir dela,
durante as 5 últimas décadas, foram desenvolvidas diversas técnicas b) Estão corretas as afirmativas I e II apenas.
e métodos que pudessem contribuir para o melhoramento dos
projetos. c) Estão corretas as afirmativas I e III apenas.
Diante disso, considere as afirmativas abaixo: d) Estão corretas as afirmativas II e III apenas.
I. O propósito da engenharia de software é entregar o software e) Está correta a afirmativa I apenas.
correto, dentro do prazo e de acordo com o orçamento previsto
inicialmente.
II. O cerne da engenharia de software está descrito nos processos
de software.
III. Não há modelos de processos de software universais, a equipe
deverá avaliar qual modelo se adequa mais ao seu projeto,
podendo optar por versões híbridas em que mais de um
modelo pode se aplicar ao projeto.

Assinale a alternativa correta:

Questão 03 – prova interdisciplinar
Embora a profissão de TI não seja integralmente a) Público e Profissão
regulamentada no Brasil, sendo apenas a Engenharia
b) Cliente e empregador
de Software regulamentada pelo CREA. Diversas
agências nacionais, como SBC e internacionais como c) Gestão e Confidencialidade
ACM e IEEE se encarregam de definir diretrizes para a d) Público e Produto
profissão. Uma dessas diretrizes é o código de
conduta ética desenvolvido pela ACM e o IEEE. e) Colega e Caráter

Assinale a alternativa que não apresenta um ou mais

princípios desse código:
Questão 04 – prova interdisciplinar
A abordagem sistematizada utilizada na engenharia de software é I. Esse modelo considera as atividades fundamentais do processo de
chamada de processo de software e consististe em uma sequência de especificação, desenvolvimento, validação e evolução, e representa
atividades que leva à produção de software. Sommerville (2018) também cada uma delas como fases distintas;
coloca o processo de software como um conjunto de atividades
II. Essa abordagem intercala as atividades de especificação,
relacionadas que levam à produção de um sistema de software.
desenvolvimento e validação. O sistema é desenvolvido como uma
série de versões.
É sabido que o processo de software deve passar por quatro atividades:
especificação do software, desenvolvimento do software, validação do
As descrições acima descrevem respectivamente os modelos:
software e evolução do software.

a) Modelo Cascata; Modelo Incremental e Engenharia de software

Diante desses princípios, modelos de processo foram criados para
orientada a reuso
suportar metodologias de desenvolvimento de projetos de software que
garantissem a entrega de um produto dentro dos padrões de qualidade b) Modelo Cascata; Engenharia de software orientada a reuso e Modelo
exigidos. Incremental

A respeito dos modelos de processo de software, analise as seguintes c) Engenharia de software orientada a reuso; Modelo Incremental e
afirmativas: Modelo Cascata

d) Engenharia de software orientada a reuso; Modelo Cascata e Modelo

I. Nessa abordagem, o processo de desenvolvimento do sistema Incremental
concentra-se na integração de componentes em um sistema já
existente em vez de desenvolver um sistema a partir do zero. e) Modelo Incremental; Engenharia de software orientada a reuso e
Modelo Cascata
Requisitos Funcionais
 Requisitos que descrevem funções do sistema;
 Pode-se dizer que é tudo aquilo que o usuário
compreende que o sistema faça;
 Descrevem ações a serem realizadas no sistema;
 É conveniente que esses requisitos sejam claros,
objetivos e não ambíguos;
 Exemplos: inserir dados em um formulário; buscar
pratos específicos em um cardápio; consultar o status
de um pedido; realizar compras;
Requisitos Não-funcionais
 Requisitos que descrevem como as funções do sistema
serão feitas;
 Estão relacionados ao “background” do sistema;
 Descrevem como as ações serão realizadas no sistema;
 Exemplos: tipo de sistema operacional; hardware a ser
utilizado; processamento; consumo de memória;
conexão; banco de dados; tipos de dispositivos em que
o software pode ser usado.
Engenharia de Requisitos

Gerenciamen
Concepção Elicitação Elaboração Negociação Especificação Validação
to

com a
após a definição e a garante que
nessa etapa todos os
modelagem documentaçã os requisitos
define a visão define todos tudo o que foi requisitos
dos requisitos o dos aprovados e
geral do os requisitos definido aprovados
é preciso requisitos, aplicados
sistema pelos funcionais e anteriormente são
negociar o nessa etapa o continuem
principais não é transformado
que será que foi em
envolvidos no funcionais do transformado s em
mantido ou elaborado é conformidade
projeto; projeto; em diagramas especificaçõe
descartado no validado por com o que foi
(modelos); s técnicas;
projeto; todos os definido.
envolvidos;
Projeto e implementação do software
 Processo de elaboração de um sistema executável para
ser entregue ao cliente;
 Envolve, normalmente, o projeto (design) e a
programação;
 Se o processo for ágil, o projeto e a implementação são
intercalados.
 O projeto é uma descrição da estrutura do software a
ser implementado.
 O projeto não é algo acabado, são acrescentados
detalhes à medida que o projeto é desenvolvido.
Projeto e implementação do software
Projeto e implementação do software
 Projeto de arquitetura: identifica-se a estrutura global do
sistema e os componentes principais, observando o seu
relacionamento e como eles estão distribuídos;
 Projeto de banco de dados: projeta-se as estruturas de dados
do sistema e como elas devem ser representadas em um
banco de dados;
 Projeto de interface: define-se as interfaces entre componentes
do sistema. Essa especificação deve ser inequívoca;
 Seleção e projeto de componentes: busca-se por componentes
reusáveis e, caso não haja componentes adequados, projeta-se
novos componentes de software.
Leitura recomendada
 Atividades básicas ao processo de desenvolvimento de
Software
Validação do software
 A verificação e validação do software (V&V) destina-se a
mostrar que um sistema está em conformidade com sua
especificação e que satisfaz as expectativas do cliente
do sistema;
 Principal técnica de validação é o teste.
 Verificação
 O sistema está funcionando da maneira correta?
 Validação
 É o software correto?
Validação do software
Validação do software
 Teste de componente: Os componentes do sistema são
testados pelas pessoas que o desenvolvem;
 Teste de Sistema: Os componentes são integrados. Visa
encontrar erros de interações imprevistas entre os
componentes e de interface;
 Teste do cliente: O sistema é testado pelo cliente (ou
cliente potencial) em vez de usar dados de simulação.
Leitura recomendada
 Test Driven Development: TDD Simples e Prático
Evolução do software
 Fase de manutenção do software
 Todo software ativo necessitará de mudanças
 Para reparo de bugs (erros da implementação)
 Para adaptação à mudanças de processos de negócio
 Para adesão de novas funcionalidades
 A evolução revisita todas as etapas de um processo de
software (especificação, desenvolvimento, validação)
Evolução do software
Leitura recomendada
 Evolução de Software
Atividade
 Reúna o seu grupo e desenvolva:
 Descrição do sistema que pretendem desenvolver;
 Diga qual ou quais modelo/s de processo de software é/são
mais adequado/s aos seu projeto.
 Liste os requisitos funcionais (pelo menos 10) e justifique a
classificação;
 Liste os requisitos não-funcionais (pelo menos 10) e justifique
a classificação;
Aula 03 – Ciclo do vida do
Software
Aula 04 - Modelagem
Diagrama de Caso de Uso
 Sistema
 Atores
 Caso de uso
 Relacionamentos
 Associação;
Diagrama de Caso de Uso
 Sistema
 Representa a aplicação a ser desenvolvida
 Todas as ações (funcionalidades) que acontecem na aplicação
devem ficar dentro do retângulo.
Nome do Sistema
Diagrama de Caso de Uso
 Atores
 Algo ou alguém que usa o sistema para atingir uma meta
 Podendo ser:
 Pessoa;
 Organização;
 Outro sistema;
 Dispositivo externo.
 Os atores são posicionados do lado externo do sistema (retângulo)
 Atores primários iniciam a utilização do sistema (ficam à esquerda
do sistema)
 Atores secundários reagem às solicitações do ator primário (ficam à
direita do sistema)
Diagrama de Caso de Uso
 Caso de uso
 Representa uma ação que realiza uma tarefa dentro do
sistema
 São posicionados dentro do retângulo.
 Os casos de uso sempre começam com verbos, pois indicam
ações a serem feitas nos sistemas e devem ser
suficientemente descritivos.
 É importante que se tente colocar os casos de uso numa
sequência lógica, normalmente em ordem cronológica das
atividades. Por exemplo: “fazer login” vem primeiro, pois é a
primeira coisa que o usuário irá fazer.
Diagrama de Caso de Uso
 Associação
 Indica uma interação ou comunicação simples no sistema
Nome do Sistema
Diagrama de Caso de Uso
 Inclusão <<incluir>>

 Indica uma interação obrigatória, sempre que o caso de uso

base for executado, o caso de uso incluído também deverá ser
executado.
Nome do Sistema

<<incluir>> Caso de
Caso de
uso
uso base
incluído
Diagrama de Caso de Uso
<<estender>>
 Extensão
 Indica uma interação condicional, quando o caso de uso base
for executado, o caso de uso estendido deverá ser executado
se atender à condição pré-determinada.
Nome do Sistema

<<estender>> Caso de
Caso de
uso
uso base
estendido
Diagrama de Caso de Uso
 Generalização
 Indica uma especialização do caso de uso. Cada caso de uso
especializado compartilha das características do caso de uso
geral, porém sempre acrescenta alguma coisa nova.
Nome do Sistema

Caso de
uso geral

Caso de uso
especializado
Diagrama de Caso de Uso
Aula extra – Orientação a
Objetos
Introdução
 É a utilização de técnicas de programação e
mecanismos de linguagem de programação para
agrupar e restringir acesso à atributos métodos e
classes.
 É um paradigma que organiza os dados em
agrupamentos chamados de classes.
Classe
 É um conjunto de objetos que possuem características
(atributos) e comportamentos (métodos) semelhantes.
 Exemplo:
PESSOA
PESSOA
---------------------
---------------------
Cabeça
CPF
Tronco
Nome
Membros
Endereço
--------------------
--------------------
Pensa
Cadastrar
Anda
Editar
Come
Comprar
Dorme
Objetos
 São instâncias de uma determinada classe. Os objetos
são a “materialização” das classes.
 É quando o conjunto de dados passa a ter uma
identidade.
 Exemplo: PESSOA
---------------------
CPF: 000.000.000-00
Nome: Wilbert Viana
Endereço: Rua A
--------------------
Cadastrar
Editar
Comprar
Atributos e Métodos
 Atributos: são os dados referentes a uma classe,
podemos dizer que os atributos são o conjunto de dados
(variáveis) de um objeto.
 Métodos: São as ações que um objeto pode realizar
dentro do sistema.
Herança
 princípio de orientação a objetos, que permite que
classes compartilhem atributos e métodos, através de
"heranças". Ela é usada na intenção de reaproveitar
código ou comportamento generalizado ou especializar
operações ou atributos.
PESSOA
--------------------- FUNCIONÁRIO
CPF ---------------------
Nome Id
Endereço Função
-------------------- Salário
Cadastrar --------------------
Editar Dar baixa em estoque
Excluir
Encapsulamento
 O encapsulamento é um recurso da POO em que objetos são
utilizados para representar entidades do mundo real e
encapsulam os dados e os comportamentos relacionados a
esses elementos.
 Está relacionado à visibilidade dos atributos e métodos:
 private (-) os atributos e os métodos marcados como “private” só
podem ser acessados dentro da própria classe em que foram
declarados;
 protected (#) os atributos e os métodos marcados como
“protected” podem ser acessados dentro da própria classe e das
subclasses;
 public (+) os atributos e os métodos marcados como “public” podem
ser acessados por qualquer classe.
Diagrama de classe
 Classe Classe

 Atributos e Métodos Atributos

 Visibilidade (encapsulamento) Métodos

 Relacionamentos
 Herança
 Associação
 Agregação
 Composição
 Multiplicidade
Diagrama de classe
 Classe
 Atributos e Métodos
Pessoa
 Visibilidade (encapsulamento) - codPessoa: string
- nome: string
- dataNasc: date
+ cadastrarReg()
+ excluirReg()
Diagrama de classe
 Herança

Pessoa Cliente
- codPessoa: string - codCliente: string
- nome: string - cpf: string
- dataNasc: date
+ cadastrarReg() + comprarProd()
+ excluirReg() + devolverProd()
Diagrama de classe
 Associação
 Relacionamento sem dependência.

Funcionario Departamento
- codFunc: string - codSetor: string
- funcao: string está vinculado - desc: string
- salario: date
Diagrama de classe
 Agregação
 Quando uma parte pode existir fora do todo.

Funcionario Dependente
- codFunc: int - codDep: int
- nome: string - nome: string
- cpf: string - idade: int
Diagrama de classe
 Composição
 Quando uma parte não pode existir fora do todo.

Cliente Pedido
- codCliente: int - codPedido: string
- nome: string - dataCriacao: date
- cpf: string - dataEnvio: date
+ comprarProd() + finalizarPedido()
+ devolverProd()
Diagrama de classe
 Multiplicidade
 0..1 (zero a um)
 n (quantidade específica)
 0..* (zero a muitos)
 1..* (um a vários)
 m..n (intervalo específico) Funcionario Departamento
- codFunc: string - codSetor: string
- funcao: string 1..* 1 - desc: string
- salario: date
está vinculado
Diagrama de classe
Continua...