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