Você está na página 1de 51

Engenharia de Software

Prof. Dr. Marcos Kalinowski


Email: mk@kalisoftware.com
Este material contou com a colaboração
dos Profs. David Zanetti e Sávio Figueiredo
1
ENGENHARIA DE SOFTWARE

“Enfoque sistemático para o desenvolvimento, operação,


manutenção e descontinuação do software”
IEEE Glossary of Software Terminology

“Aplicação prática do conhecimento científico no projeto e


construção de programas e da documentação requerida para
desenvolver, operar e manter esses programas”
Barry Boehm

“Criação e a utilização de sólidos princípios de engenharia a fim


de obter softwares econômicos que sejam confiáveis e que
trabalhem eficientemente em máquinas reais”
Fritz Bauer
3
ENGENHARIA DE SOFTWARE

– Características do Software
• Software é desenvolvido e não manufaturado.

• Software não se desgasta, mas sofre modificações.

• Maior parte ainda é desenvolvida sob encomenda, de


forma que muitas vezes se parte do zero.

• Atividade criativa e dependente do conhecimento


humano. 4
ENGENHARIA DE SOFTWARE

– Tipos de Aplicação
• Sistemas – SW e/ou HW
• Tempo Real – Tempo de resposta
• Software de apoio à tomada de decisão – BPM, ERP, CRM, BI.
• Especialistas – Substitui um especialista no negócio. Apóia a tomada
de decisão.
• Embutido – Reside dentro de um HW
• Web – Acesso remoto
• Ubíquio – Não se nota a presença. IHC invisível.
• Legado – Desenvolvido há longo tempo
5
Mito
O programa está 95% pronto

Realidade
• Programadores são extremamente otimistas
• Programadores costumam acreditar na própria capacidade de
resolver problemas de forma imediata, mesmo na contínua
evidência do contrário
Exercícios - Fundamentos

7
ENGENHARIA DE SOFTWARE

Julgue os itens abaixo como certos ou errados:

1) Computação úbiqua são aplicações que utilizam algoritmos para resolver


problemas complexos que incluem robótica (sistemas especialistas,
processamento de imagem, etc.).

2) Uma idéia geral dos objetivos é suficiente para começar a escrever os


programas

3) Um livro de padrões de projeto e procedimentos basta para prover a minha


equipe todo o conhecimento necessário.

4) Minha equipe possui as ferramentas modernas e os computadores mais


modernos, mas isso não é suficiente para garantir um software de
qualidade.
ENGENHARIA DE SOFTWARE

Julgue os itens abaixo como certos ou errados:

5) Para conseguir analisar a qualidade, preciso possuir algo que seja


executável.

6) Os requisitos mudam constantemente, mas é fácil acomodar estas


mudanças, afinal o software é flexível.

7) O software se desgasta com o tempo e correções serão necessárias.


ENGENHARIA DE SOFTWARE

8- Qual a principal causa de deterioração de um software ?

a) Usuários mal preparados.


b) Modificações.
c) O desgaste do software com o tempo.
d) Programas sem documentação.
e) Imprevistos.

10
ENGENHARIA DE SOFTWARE

– Processo de SW
• Conjunto de passos para criar o software, dentro do prazo e
custo e com qualidade.
• Evita o caos.
• Podem ser avaliados quanto à qualidade
• “formam a base para o controle gerencial de projetos de software
e estabelecem o contexto no qual métodos técnicos são
aplicados, os produtos de trabalho são produzidos, os marcos
são estabelecidos, a qualidade é assegurada e as modificações
são adequadamente geridas”.
11
ENGENHARIA DE SOFTWARE

Engenharia de Software

Ferramentas

Métodos

Processo

Foco na Qualidade

12
ENGENHARIA DE SOFTWARE

– Arcabouço de Processos de SW
• Conjunto de atividades aplicáveis a todos os projetos de software:
– Comunicação com os interessados
– Planejamento dos recursos disponíveis para o projeto
– Modelagem – requisitos + projeto
– Construção – codificação + testes
– Implantação – entrega do SW

• Fases genéricas:
– Definição (o que?)
– Desenvolvimento (como?)
– Manutenção (mudanças)

13
ENGENHARIA DE SOFTWARE

– Arcabouço de Processos de SW
• Atividades Guarda-Chuva (de apoio):
– Acompanhamento e controle
– Gestão de Risco
– Revisões técnicas formais
– Garantia da Qualidade
– Gestão de Configuração
– Documentação
– Medição
– Gestão do reuso
– Preparação e produção do produto de trabalho
14
ENGENHARIA DE SOFTWARE

– Modelos de Ciclo de Vida


• Conjunto de atividades p/ construção do SW.
• Cada organização define o mais adequado.
• Pode ser escolhido de acordo com a natureza da aplicação e as
caracteristicas do projeto.
• Não existe “O Melhor”.
• Geralmente diferem em:
– Fluxo de atividades e interdependencia
– Grau de detalhamento
– Grau de participação
– Organização e detalhamento da equipe 15
Exercícios - Processos de
Software

16
ENGENHARIA DE SOFTWARE

Julgue os itens abaixo como certos ou errados:

1) Podemos considerar as atividades de levantamento de requisitos


como sendo atividades guarda-chuvas.

2) É possível possuir um processo de melhoria de processos, e


posso aplicar este processo a ele mesmo para melhorá-lo.

3) A qualidade do produto está fortemente relacionada com a


qualidade do processo.

4) Medição pode ser considerada uma atividade guarda-chuva.


ENGENHARIA DE SOFTWARE

Julgue os itens abaixo como certos ou errados:

5) Processos podem ser avaliados em relação às práticas descritas nos


modelos de ciclo de vida.

6) Processo é o conjunto de atividades executadas para gerar um produto


ou serviço.

7) Através dos processos, é possível diminuir o retrabalho e a qualidade,


mas não é possível melhorar as estimativas.
ENGENHARIA DE SOFTWARE

– Modelo Cascata ou Clássico


• Mais usado
• Simples e de fácil gerência.
• Variações no no e nomes das fases.
• Uma fase não começa antes do término de outra
• Todo o sistema é entregue de uma só vez
• Problemas:
– Mudança de requisitos.
– Sistemas grandes
– Erros detectados no final 19
ENGENHARIA DE SOFTWARE

Modelo em Cascata ou Clássico

Comunicação Planejamento Modelagem Construção Implantação

20
ENGENHARIA DE SOFTWARE

– Prototipagem rápida
• Ocorre junto com o cascata

• Protótipo é usado como mecanismo para entender requisitos


e é jogado fora.

• Problemas:
– Custo.

– Usuário tende a gostar do protótipo.

21
ENGENHARIA DE SOFTWARE

Comunicação Planejamento Modelagem Construção Implantação

Protótipo
Rápido

22
ENGENHARIA DE SOFTWARE

– Modelos Incrementais:
• O sistema é desenvolvido em incrementos até ficar
completo.

• Desenvolve-se uma versão parcial e vai-se adicionando


funcionalidades.

• Pode fornecer versões preliminares.

• Bom para prazos apertados e pouca mão de obra.

• Reduz riscos.
23
ENGENHARIA DE SOFTWARE

incremento 1

Comunicação Planejamento Modelagem Construção Implantação

...

Incremento 2 Comunicação Planejamento Modelagem Construção Implantação

Incremento 3 Comunicação Planejamento Modelagem Construção Implantação

Incremento n Comunicação Planejamento Modelagem Construção Implantação

24
ENGENHARIA DE SOFTWARE

– RAD
• Rapid Application Development.
• Requisitos muito bem compreendidos.
• Sistema funcional em 60-90 dias.
• Baseado em componentes.
• Usa técnicas de 4a. geração, reuso e ferramentas
automatizadas, para diminuir o tempo.
• Requer RH e comprometimento.
• Não apropriado para riscos altos.
• Exige modularidade.

25
ENGENHARIA DE SOFTWARE

Comunicação Planejamento

equipe n

equipe 2 Modelagem

equipe 1 Modelagem
Construção
Modelagem
Construção

Construção

Implantação 26
ENGENHARIA DE SOFTWARE

– Modelos Evolutivos
• Software evolui com o tempo e o uso das versões iniciais.
• Modelo Iterativo.
• Requisitos são parcialmente definidos e depois são refinados.
• Desenvolve-se uma versão parcial que atinge requisitos conhecidos.
• A partir do conhecimento adquirido com o uso, evolui-se o produto

Comunicação Comunicação ... Comunicação

Planejamento Planejamento Planejamento

Modelagem Modelagem Modelagem

Construção Construção Construção

Implantação Implantação Implantação


ENGENHARIA DE SOFTWARE

– Espiral
• Abordagem cíclica guiada por riscos.

• Software desenvolvido em versões evolucionárias.

• Aumenta incrementalmente o grau de definição e


implementação de um sistema enquanto seu grau de risco
diminui.

• Marcos de Ancoragem – Pontos de Controle.

28
ENGENHARIA DE SOFTWARE
Modelo Espiral

Planejamento
Estimativa
Cronograma
Recursos
Análise de Riscos

Comunicação

Início Modelagem
Análise e
Projeto

Implantação Construção
entrega
Código e
feedback
Teste
29
ENGENHARIA DE SOFTWARE

Modelo Espiral - Variações

30
ENGENHARIA DE SOFTWARE

Modelo Espiral

• Marcos de Ancoragem: Ajudam a estabelecer quando um ciclo é completado em


torno da espiral e fornecem marcos de decisão antes do projeto de software
prosseguir.

– Objetivos do ciclo de Vida (LCO)


– Objetivos gerais, escopo, fronteiras

– Arquitetura do Ciclo de Vida (LCA)


– Incrementos
– Projeto detalhado por incremento

– Capacidade Inicial de Operação (IOC)


– Preparação do software para implentação
– Preparação do ambiente
– Preparação do usuário

31
Exercícios – Modelos
Prescritivos

32
ENGENHARIA DE SOFTWARE

PETROBRAS 2010
BNDES 2005
Considere as seguintes assertivas sobre o processo evolutivo de software conhecido
com modelo em espiral.

I- Cada passo da espiral termina com um conjunto de atividades de negociação.


II- Cada atividade de negociação inicia com a identificação das partes interessadas.
III- A definição do Ciclo de vida Arquitetural é um dos três marcos do processo
conhecidos como pontos de ancoragem (anchor points).

As assertivas corretas são:


(A) somente I;
(B) somente II;
(C) somente III;
(D) somente II e III;
(E) I, II e III.
BNDES 2005
Julgue os itens abaixo:

• O modelo seqüencial linear abrange as seguintes atividades: modelagem e


engenharia do sistema; análise de requisitos de software; projeto; geração de
código; teste e manutenção.

• O modelo de prototipagem é um modelo de processo de desenvolvimento de


software incremental que enfatiza um ciclo de desenvolvimento curto. Esse modelo
é uma adaptação de alta velocidade do modelo orientado a objetos.

• O modelo espiral é um modelo de processo de software evolucionário que combina


a natureza interativa de prototipagem com os aspectos controlados do modelo
seqüencial linear.
BNDES 2005
Julgue os itens abaixo:

• O modelo de processo concorrente é freqüentemente usado como paradigma para


o desenvolvimento de aplicações cliente/servidor, definindo atividades em duas
dimensões: de sistema e de componentes.

• O paradigma do desenvolvimento rápido de aplicação (RAD) começa com a


definição de requisitos, em que o desenvolvedor usa partes de programas
existentes e aplica ferramentas que possibilitam que programas executáveis sejam
gerados rapidamente. O projeto é avaliado constantemente pelo cliente/usuário e
usado para refinar os requisitos do software em desenvolvimento.

• O desenvolvimento baseado em aspectos se baseia na busca por interesses


transversais.
BNDES 2010
No ciclo de vida em cascata, o custo de correção é
menor na fase de:

(A) testes.
(B) transição.
(C) implementação.
(D) requisitos.
(E) manutenção.
PRODAM
• Qual das alternativas a seguir corresponde ao modelo de processo, proposto no final da
década de 80, que tem como principais características ser evolucionário, iterativo e
focado na redução dos riscos?

A) Modelo em Espiral.
B) Modelo em Cascata.
C) Modelo em V.
D) Modelo Transformacional.
E) Modelo de Especificação Operacional.
ELETROBRAS

• Considere as seguintes afirmativas sobre modelos de ciclo de vida de


desenvolvimento de sistemas:

I . No modelo incremental, a implementação do sistema é feita antes de sua


especificação.
II . No modelo em cascata, cada fase inicia somente quando sua predecessora
termina.
III . O modelo em espiral requer que a especificação do sistema seja feita
somente uma vez.

A(s) afirmativa(s) correta(s) é/são somente:

(A) I;
(B) II;
(C) III;
(D) I e II;
(E) II e III.
ENGENHARIA DE SOFTWARE

O Modelo de processo de software incremental que enfatiza um ciclo de desenvolvimento


extremamente curto, obtido pelo uso de construção baseada em componentes, é
denominado:

A) RAD.

B) Seqüencial Linear.

C) Prototipagem.

D) Espiral.

E) Incremental.

40
ENGENHARIA DE SOFTWARE

PETROBRAS 2010
ENGENHARIA DE SOFTWARE

Considerando o mais antigo dos paradigmas de


desenvolvimento de software, assinale a alternativa correta:
a) É comum identificar erros ao longo do processo e corrigi-los.
b) Ao longo do desenvolvimento são geradas várias versões
executáveis.
c) Obedece um fluxo seqüencial.
d) Utiliza-se de protótipos.
e) Utiliza-se de conceitos matemáticos

42
ENGENHARIA DE SOFTWARE

Assinale a alternativa que aponta uma desvantagem do modelo de


prototipagem:
a) Não permite uma grande interação com o cliente.
b) Dificulta o processo de definição de requisitos.
c) Por vezes, considera-se um protótipo o produto final.
d) Não permite que o cliente teste o protótipo.
e) Obedece um fluxo seqüencial.

43
ENGENHARIA DE SOFTWARE

Assinale a alternativa que não corresponde a uma das técnicas


utilizadas pelo modelo RAD para produzir software rapidamente:

a) Reuso de componentes.
b) Modularidade.
c) Negociação.
d) Incrementos em ciclos curtos.
e) Ferramentas de quarta geração.

44
ENGENHARIA DE SOFTWARE

Há diversas formas de se conduzir um projeto de software


visando a economia de recursos. O modelo baseado em
componentes, por exemplo, incorpora, fundamentalmente:

A) A utilização de ferramentas CASE.


B) O cumprimento fiel das boas práticas de gerência.
C) O investimento na formação de pessoal.
D) O uso de ferramentas matemáticas de análise e projeto.
E) A reutilização de software.
45
ENGENHARIA DE SOFTWARE

Assinale a opção que apresenta o modelo de processo de software


que se caracteriza mais fortemente por uma abordagem sistemática e
seqüencial para o desenvolvimento de software:

A) Espiral.

B) Cascata.

C) Incremental.

D) Prototipação.

E) Concorrente.
46
ENGENHARIA DE SOFTWARE

BNDES 2002 – Analista de Suporte

• Dentro de uma visão de um ciclo de vida de projeto, o número de


fases de um projeto é uma função de sua natureza, podendo variar de
quatro a nove. Uma dessas fases é aquela em que se detalhará tudo
aquilo que será feito, incluindo cronogramas, interdependências entre
atividades, alocação dos recursos envolvidos, análise dos custos,
entre outros. Essa fase é denominada

a) controle.
b) execução.
c) iniciação.
d) finalização.
e) planejamento.
ENGENHARIA DE SOFTWARE

BNDES 2002 – Analista de Suporte

• Entre os paradigmas de ciclo de vida de engenharia de


software, aquele que se caracteriza mais fortemente por
uma abordagem sistemática e seqüencial das atividades é
o denominado

a) espiral.
b) híbrido.
c) prototipação.
d) clássico ou cascata.
e) técnicas de quarta geração.
ENGENHARIA DE SOFTWARE

BNDES 2002 – Analista de Desenvolvimento

• Considere as seguintes afirmações sobre os paradigmas de ciclo de vida de


engenharia de software.

I. No paradigma de prototipação, o protótipo idealmente serve como mecanismo


para identificar os requisitos de software.
II. No paradigma de prototipação, o protótipo será descartado (no todo ou em
parte) e o software real será reprojetado.
III. O modelo espiral define quatro atividades, que são executadas nesta ordem:
planejamento, análise de riscos, engenharia, avaliação pelo cliente.

Sobre as afirmações, pode-se dizer que

a) apenas I está correta.


b) apenas I e II estão correta.
c) apenas I e III estão correta.
d) apenas II e III estão correta.
e) I, II e III estão corretas.
ENGENHARIA DE SOFTWARE

Marinha 2008

O trabalho associado à engenharia de software pode ser categorizado


em três fases genéricas, independentemente da área de aplicação, do
tamanho ou de sua complexidade.

Assinale a opção que apresenta essas três fases.

a) Escopo, construção e testes.


b) Definição, desenvolvimento e manutenção.
c) Modelagem, geração e entrega.
d) Análise, projeto e manutenção.
e) Comunicação com o cliente, planejamento e construção.
ENGENHARIA DE SOFTWARE

BNDES 2005 – Analista de Desenvolvimento

• Considere as seguintes assertivas sobre o processo de desenvolvimento de


software conhecido como Engenharia de Software Baseada em Componentes
(ESBC):

I- O ESBC dá ênfase ao paralelismo entre tarefas.


II- A atividade de Engenharia de Domínio produz uma lista de componentes que
podem ser reutilizados.
III- O modelo de troca de dados é um dos ingredientes arquiteturais necessários
para a atividade de composição de componentes.

As assertivas corretas são:

a) somente I;
b) somente II;
c) somente III;
d) somente I e II;
e) I, II e III.