GOVERNO DO ESTADO DO PIAUÍUNIVERSIDADE ESTADUAL DO PIAUÍ UESPI

Prof. Erivelton da Silva RochaGraduação: Licenciatura Plena em ComputaçãoEspecialista em Engenharia de Sistemas1

Engenharia de SoftwareAula - 03

2

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

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

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

• Qualidade de Software5

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

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

PROJETO/DESENVOLVIMENTO

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

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

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

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

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

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

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

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

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

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

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

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

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

Resultado: Especificação dos requisitos.23

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

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

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

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

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

PROBLEMAS DO CICLO DE VIDA CLÁSSICO

Resultado: Clientes insatisfeitos Modificações no sistema Aumento dos custos Possibilidade de introdução de erros.

29