O documento discute os principais conceitos da engenharia de software, incluindo o SWEBOK que classifica as áreas do conhecimento da engenharia de software, os modelos de processo como cascata e protótipo, e as fases do ciclo de vida de software como requisitos, projeto, codificação e teste.

1. GOVERNO DO ESTADO DO PIAUÍ
UNIVERSIDADE ESTADUAL DO
PIAUÍ UESPI
Prof. Erivelton da Silva Rocha
Graduação: Licenciatura Plena em Computação
Especialista em Engenharia de Sistemas
1

2. Engenharia de Software
Aula - 03
2

3. IMPORTÂNCIA DO SOFTWARE
Um dos pontos fundamentais da importância do software
é pelo seu uso cotidiano, aonde praticamente no mundo
moderno, inexiste a possibilidade de não utilizá-lo. E o outro
ponto é pela manipulação da informação (dado - informação -
conhecimento), e quem a tem possui poder.
3

4. SWEBOK
 O SWEBOK (Guide to the Software Engineering Body of
Knowledge) é o documento técnico desenvolvido com o
apoio do IEEE (Instituto de Engenheiros Elétricos e
Eletrônicos, também popularmente chamado de I3E). Esse
documento estabelece uma classificação hierárquica dos
tópicos tratados pela Engenharia de Software, onde o
nível mais alto são as Áreas do Conhecimento.
4

5. AS DEZ ÁREAS DO CONHECIMENTO TRATADAS
PELO SWEBOK SÃO:
• Requisitos de Software
• Projeto de Software
• Construção de Software
• Teste de Software
• Manutenção de Software
• Gerência de Configuração de Software
• Gerência da Engenharia de Software
• Processo de Engenharia de Software
• Ferramentas e Métodos da Engenharia de Software 5
• Qualidade de Software

6. MODELOS DE PROCESSOS DE
ENGENHARIA DE SOFTWARE
 O Processo de Engenharia de Software envolve todas as
atividades relacionadas ao desenvolvimento de um
software, desde de a análise de requisitos, administração
e gerenciamento de projetos até as técnicas de testes e
manutenção de software.
6

7. REQUISITOS
O analista deve obter respostas a várias perguntas junto
aos usuários:
 O que exatamente se espera que seja feito?
 Qual a abrangência do software?
 Quais os limites, ou o escopo do sistema ?
 Por que se faz aquilo daquela forma?
 Quais as restrições que existem nos procedimentos e
dados utilizados?
7

8. PROJETO/DESENVOLVIMENT
O
 O analista faz especificações técnicas detalhando a solução
criada para atender ao usuário conforme os requisitos
anteriores. Os programadores codificam os programas em
alguma linguagem de programação. Deve-se testar os
programas exaustivamente para atingir um alto nível de
qualidade, e após isso liberá-los para o uso.
8

9. IMPLANTAÇÃO/MANUTENÇÃO
 Na implantação do software pode ocorrer vários problemas
não previstos nas fases anteriores. E a manutenção
permanecerá durante toda sua vida útil e pode ocorrer
motivada por 03 fatores:
 A correção de algum problema existente no software,
 Sua adaptação decorrente de novas exigências (internas ou
externas da empresa)
 Algum melhoramento funcional que seja incorporado ao
software.
9

10. 10

11. MODELOS DE PROCESSO DE
SOFTWARE.
• Modelos de Ciclo de Vida de Software;
• Modelos Prescritivos de Processo
• Paradigmas do Ciclo de Vida;
• Paradigmas do Desenvolvimento de
Software;
• Modelagem do Ciclo de Vida.
11

12. MODELO BALBÚRDIA
 No início da computação, poucos programadores seguiam
algum tipo de metodologia baseando-se, em sua maioria,
na própria experiência. Era o que chamamos hoje de
Modelo Balbúrdia, sistemas desenvolvidos na
informalidade sem nenhum tipo de projeto ou
documentação.
12

13.  Nesse modelo, o software tende a entrar num ciclo de
somente duas fases:
O de implementação
 De implantação.
 E os ajustes ao software para atender aos novos
requisitos, sempre são em clima de urgência e de
stress, motivados por vários fatores, e principalmente
por pressão política.
13

14. 14

15.  Portanto, havia a necessidade se criar um “Ciclo de
Vida” mais inteligente para o desenvolvimento de
Software. Ou seja, um “Ciclo de Vida” semelhante à
própria natureza, com início, meio e fim bem
definidos.
15

16.  Essas atividades podem ser executadas em
diferentes seqüências e agrupadas em diferentes
etapas. O conjunto de regras que definem essas
etapas e seqüências são chamados de
Paradigmas da Engenharia de Software.
16

17. PARADIGMAS DA ENGENHARIA
DE SOFTWARE
 Existem diversos paradigmas:
 Ciclo de vida clássico (seqüencial)
 Modelo de Prototipação
 Modelo Espiral
 Técnicas de Quarta Geração
 Combinação de Paradigmas
17

18. PARADIGMAS DA
ENGENHARIA DE SOFTWARE
Para se escolher entre um ou outro paradigma deve-
se levar em consideração diversos fatores:
 Processo de desenvolvimento a ser adotado
 Tipo de aplicação a ser desenvolvida
 Métodos e ferramentas a serem utilizadas
 Controles e produtos que precisam ser entregues
 Expectativa do cliente 18

19. CICLO DE VIDA CLÁSSICO
 Também conhecido como modelo cascata
 Modelo mais antigo a ser utilizado
 Foi desenvolvido com base no ciclo de vida da
engenharia tradicional
 É caracterizado por uma abordagem seqüencial
para o desenvolvimento do software
 Cada atividade é uma fase distinta. Só após o seu
total término é que a próxima etapa começa
 Hoje em dia é somente uma grande referência.
19

20. 20

21. FASE 1 E 2 – ENGENHARIA DE SISTEMAS
E ANÁLISE DE REQUISITOS
 Envolve a coleta dos requisitos para todos os elementos do
sistema
 Análise em alto nível. Pouco projeto
 Visão global do sistema: tarefas, interface com usuário,
interface com o hardware, interface com banco de dados,
etc.
21

22. FASE 1 E 2 – ENGENHARIA DE SISTEMAS
E ANÁLISE DE REQUISITOS
 A análise envolve diversas tarefas:
 identificar as necessidades dos usuários
 Realizar as análise dos custos envolvidos
 Realizar a análise dos recursos necessários tanto de
ferramentas quanto de pessoal
 Estabelecer restrições de prazo e custo
 Realizar um projeto inicial e global do sistema, incluindo sua
divisão em módulos.
22

23. FASE 1 E 2 – ENGENHARIA DE SISTEMAS
E ANÁLISE DE REQUISITOS
Como realizar a análise:
 entrevista entre o analista e o cliente
 Questionários
 O analista deve saber fazer as perguntas certas, orientar, esclarecer e
dar conselhos
 O cliente deve ser capaz de esclarecer suas expectativas e metas de
projeto.
 Técnicas: análise estruturada, análise orientada a objetos, métodos
formais
23
 Resultado: Especificação dos requisitos.

24. FASE 3 - PROJETO
 Refinar a especificação global do sistema gerada na
fase de análise
 O objetivo é realizar uma especificação mais detalhada
do sistema, de forma que seja possível avaliar a
qualidade prevista, antes de iniciar a codificação
 Definições realizadas nesta fase:
 Estrutura de dados
 Arquitetura de Software
 Detalhes Procedimentais
 Interface entre módulos com o usuário 24

25. FASE 4 - CODIFICAÇÃO
 Consiste simplesmente em implementar o que foi definido no
projeto
 Quando o projeto é bem feito s os desenvolvedores são
experientes e/ou competentes, esta etapa e relativamente simples
 Em outras palavras, esta etapa consiste da tradução do projeto
para uma linguagem artificial, resultando em instruções
executáveis pelo computador
 Falando de maneira ainda mais simples: codificação significa
escrever programas
25

26. FASE 5 - TESTE
 Consiste em testar o software, o que pode ser realizado
de diversas formas:
 Teste de caixa preta – consiste em testar o software
ignorando o processamento interno. Apenas verifica se,
para um conjunto de dados de entrada, o conjunto de
dados de saída é esperado.
 Teste de caixa branca: consiste em testar internamente
o software, garantindo que todas as instruções tenham
sido testadas.
26

27. FASE 6 - MANUTENÇÃO
 Muito provavelmente, o software deverá sofrer mudanças
depois de entregue ao cliente, devido a erros ou novas
funcionalidades requeridas.
 Tipo de manutenção
 Manutenção corretiva: consiste em diagnósticas e corrigir erros
 Manutenção adaptativa: adapta o software devido a mudanças no
hardware ou software (por exemplo, novo sistema operacional)
 Manutenção perfectiva: melhorar o desempenho do software ou
adicionar funcionalidades
 Manutenção preventiva: melhorar a confiabilidade ou garantir
possibilidade de manutenção futura. 27

28. PROBLEMAS DO CICLO DE VIDA
CLÁSSICO
 Dificilmente projetos reais seguem um fluxo
seqüencial
 Nem sempre é possível estabelecer inicialmente todos
os requisitos necessários, devido a incertezas tanto do
cliente quanto do desenvolvedor
 O cliente deve esperar até o final de todas as etapas
como será o produto. Nem sempre ele consegue
visualizar exatamente com será o produto final.
28

29. PROBLEMAS DO CICLO DE VIDA
CLÁSSICO
 Resultado:
 Clientes insatisfeitos
 Modificações no sistema
 Aumento dos custos
 Possibilidade de introdução de erros.
29