Apostila Engenharia de Software

Prévia do material em texto

1 
 
MINISTÉRIO DA EDUCAÇÃO 
SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA 
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA 
GOIANO 
CAMPUS IPORÁ - GOIÁS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Engenharia de Sistemas de 
Informação 
 
 
 
 
 
 
CURSO: Técnico em Informática PERÍODO: 2º 
 PROFESSORA: Luciana Recart Cardoso 
2 
 
 
 
 
 
SUMÁRIO 
 
 
 
 
1 INTRODUÇÃO AOS SISTEMAS DE INFORMAÇÃO ............................................. 4 
1.1 TEORIA SISTÊMICA ................................................................................................................. 4 
1.1.1DEFINIÇÕES DE SISTEMA ...................................................................................................... 4 
1.1.2 HIERARQUIA DOS SISTEMAS ................................................................................................. 5 
1.1.3 TIPOS DE SISTEMAS ............................................................................................................. 7 
1.1.4 CARACTERÍSTICAS DOS SISTEMAS ....................................................................................... 8 
1.1.5 PARÂMETROS DOS SISTEMAS .............................................................................................. 8 
1.2 CONCEITOS DE SISTEMAS DE INFORMAÇÃO ............................................................................ 9 
1.2.1 SISTEMAS DE INFORMAÇÃO BASEADOS EM COMPUTADOR .................................................. 10 
QUAL A DIFERENÇA ENTRE DADO E INFORMAÇÃO? ...................................................................... 10 
1.2.2 CARACTERÍSTICAS IDEAIS DE UMA INFORMAÇÃO ................................................................ 11 
1.2.3 QUALIDADE DAS INFORMAÇÕES ......................................................................................... 11 
2 INTRODUÇÃO À ENGENHARIA DE SOFTWARE .............................................. 11 
2.1 CRISE DO SOFTWARE ........................................................................................................... 12 
2.2 O QUE É ENGENHARIA DE SOFTWARE? ................................................................................. 12 
2.2.1 OBJETIVOS DA ENGENHARIA DE SOFTWARE ...................................................................... 12 
METAS DA ENGENHARIA DE SOFTWARE ...................................................................................... 13 
2.2.2 O QUE É SOFTWARE? ........................................................................................................ 14 
2.2.3 CARACTERÍSTICAS DO SOFTWARE ..................................................................................... 14 
2.3 QUAL É A DIFERENÇA ENTRE ENGENHARIA DE SOFTWARE E CIÊNCIA DA COMPUTAÇÃO? ...... 18 
2.4 QUAL É A DIFERENÇA ENTRE ENGENHARIA DE SOFTWARE E ENGENHARIA DE SISTEMAS? ..... 18 
2.5 O QUE É UM PROCESSO DE SOFTWARE? ............................................................................... 18 
2.6 O QUE É UM MODELO DE PROCESSO DE SOFTWARE? ............................................................ 18 
2.6.1 MODELO CASCATA ............................................................................................................. 19 
2.6.2 MODELO DE PROTOTIPAGEM ............................................................................................. 20 
2.6.3 MODELO DE PROCESSO DE DESENVOLVIMENTO INCREMENTAL ........................................... 22 
2.6.4 MODELO ITERATIVO ........................................................................................................... 24 
3 
 
DIFERENÇA ENTRE O MODELO ITERATIVO E O MODELO INCREMENTAL ......................................... 25 
2.6.5 MODELO ESPIRAL .............................................................................................................. 26 
QUAIS SÃO OS CUSTOS DA ENGENHARIA DE SOFTWARE? ........................................................... 28 
2.8 O QUE SÃO MÉTODOS DE ENGENHARIA DE SOFTWARE? ....................................................... 28 
PROBLEMAS NO DESENVOLVIMENTO ........................................................................................... 28 
MITOS DO SOFTWARE................................................................................................................. 29 
 
4 
 
 
 
 
 
1 INTRODUÇÃO AOS SISTEMAS DE INFORMAÇÃO 
 
1.1 Teoria Sistêmica 
Na década de 1950, o biólogo alemão Ludwig Von Bertalanffy, estudando organismos 
vivos, observou que quaisquer dos organismos pesquisados, embora se diferenciassem uns 
dos outros em enorme gama de características, mantinham sempre algumas características 
comuns. Von Bertalanffy estendeu as suas observações a outros tipos de organismos, sejam 
mecânicos, sociais etc., e constatou que algumas características se mantinham, não 
importando a natureza do organismo. 
A mais importante característica que sempre se podia destacar era o objetivo 
(propósito) que o organismo atingia. Embora o organismo em observação fosse composto de 
uma série de elementos, percebia-se claramente a interação desses elementos com vistas a 
atingir um objetivo, que seria a finalidade daquele organismo. Desses estudos e observações, 
Von Bertalanffy propôs a chamada Teoria Geral dos Sistemas, chamando de sistema a esses 
organismos visando a um objetivo. 
 
1.1.1Definições de Sistema 
O Sistema é um conjunto de partes interagentes e interdependentes que, 
conjuntamente, formam um todo unitário com determinado objetivo e efetuam determinada 
função (OLIVEIRA, 2002, p. 35). 
 
Sistema pode ser definido como um conjunto de elementos interdependentes que 
interagem com objetivos comuns formando um todo, e onde cada um dos elementos 
componentes comporta-se, por sua vez, como um sistema cujo resultado é maior do que o 
resultado que as unidades poderiam ter se funcionassem independentemente. Qualquer 
conjunto de partes unidas entre si pode ser considerado um sistema, desde que as relações 
entre as partes e o comportamento do todo sejam o foco de atenção (ALVAREZ, 1990, p. 17). 
 
Sistema é um conjunto de partes coordenadas e não relacionadas, formando um todo 
complexo ou unitário (OLIVEIRA, 2002, p. 35). 
5 
 
 
Sistema é uma entidade que tem a capacidade de manter um certo grau de 
organização em face de mudanças internas ou externas, composto de um conjunto de 
elementos, em interação, segundo determinadas leis, para atingir um objetivo específico. 
 
Cada um dos elementos, ao serem reunidos para constituir uma unidade funcional 
maior, desenvolve características que não se encontram em seus componentes isolados. 
 
1.1.2 Hierarquia dos sistemas 
A visão de um sistema depende do interesse de quem pretenda analisá-lo. Uma 
empresa, por exemplo, poderá ser entendida como um sistema ou subsistema ou ainda um 
supersistema, dependendo da análise que se queira fazer: que o sistema tenha um grau de 
autonomia maior do que o subsistema e menor do que o supersistema. 
Aos elementos interdependentes, interatuantes, inter-relacionados, dá-se o nome de 
subsistemas, que podem ser sistemas sob outro foco, dependendo do interesse de quem 
analisa. Depende da abordagem. 
 
 
 
• Milhões de anos-luz de nossa galáxia (no Universo) 
• nossa galáxia, sistema Via Láctea 
• nosso sistema solar 
• nosso planeta Terra, sistema Terra 
6 
 
• uma comunidade indígena, sistema comunidade 
• um sistema árvore (organismo) 
• sistema folha 
• uma molécula 
• sistema átomo 
 
 
Outros exemplos de sistema 
 
Automóvel 
 
Quais os objetivos? 
• transportar passageiros e carga, locomoção mecanizada 
 
Quais os subsistemas que compõem o sistema automóvel? 
• subsistema motor; subsistema caixa de marchas, subsistema suspensão, subsistema 
de frenagem, etc. 
 
 
Computador 
 
Quais os objetivos? 
• Processar e armazenar informações 
 
Quais os subsistemas que compõemo sistema computador? 
• subsistema teclado, subsistema CPU, subsistema vídeo, subsistema HD, subsistema 
placa de vídeo, placa de som, placa de memória, etc. 
7 
 
 
 
 
 
 
1.1.3 Tipos de sistemas 
 
Há uma grande variedade de sistemas e uma ampla gama de tipologias para classificá-
los, de acordo com certas características básicas. 
 
• Quanto a sua constituição: 
o Físicos ou concretos: quando compostos de equipamento, de maquinaria e de 
objetos e coisas reais (equipamento, objetos, hardware); 
o Abstratos ou conceituais: quando compostos por conceitos, planos, hipóteses 
e ideias que muitas vezes só existem no pensamento das pessoas (conceitos, 
planos, ideias, software). 
Na realidade, há uma complementação entre sistemas físicos e abstratos: os sistemas 
físicos precisam de um sistema abstrato para funcionar, e os sistemas abstratos somente se 
realizam quando aplicados a algum sistema físico. 
 
• Quanto a sua natureza: 
o Fechados: não apresentam intercâmbio com o meio ambiente que os circunda, 
sendo assim não recebem nenhuma influência do ambiente e por outro lado 
não o influenciam. Não recebem nenhum recurso externo e nada produzem 
que seja enviado para fora. 
 Ex: A matemática é um sistema fechado, pois não sofrerá nenhuma 
influência do meio ambiente, sempre 1+1 será 2. 
• Abertos: são os sistemas que apresentam relações de intercâmbio com o ambiente, 
por meio de entradas e saídas. 
CPU 
8 
 
Os sistemas abertos trocam matéria, energia e informação regularmente com o meio 
ambiente. São necessariamente adaptativos, isto é, para sobreviver devem reajustar-se 
constantemente às condições do meio. 
 
1.1.4 Características dos sistemas 
 
As características dos sistemas são decorrências de dois conceitos: o de propósito (ou 
objetivo) e o de globalismo (ou totalidade). 
• Propósito ou objetivo: Os elementos ou unidades, bem como os relacionamentos, 
definem um arranjo que visa sempre a um objetivo a alcançar. 
• Globalismo ou totalidade: todo o sistema tem uma natureza orgânica, pela qual uma 
ação que produza mudança em uma das unidades do sistema, com muita 
probabilidade deverá produzir alterações em todas as demais unidades deste. 
• Entropia: é a tendência que os sistemas têm para o desgaste, para desintegração, 
para o afrouxamento dos padrões e para um aumento da aleatoriedade. A entropia 
aumenta com o decorrer do tempo. À medida que aumenta a informação, diminui a 
entropia, pois a informação é a base da configuração e da ordem. 
• Negentropia: a informação como meio ou instrumento de ordenação do sistema. 
• Homeostasia: é o equilíbrio ativo entre as partes do sistema. Os sistemas têm uma 
tendência a se adaptarem a fim de alcançarem um equilíbrio interno em face das 
mudanças externas do ambiente. 
 
1.1.5 Parâmetros dos sistemas 
 
Parâmetros são constantes arbitrárias que caracterizam, por suas propriedades, o 
valor e a descrição dimensional de um sistema específico ou de um componente do sistema. 
• Entrada (input): é a força de arranque (ou de partida) do sistema que fornece o material 
ou energia para a operação do sistema. As organizações adquirem ou compram 
materiais para processá-los de alguma maneira. Para assistirem outras funções, como 
os organismos vivos que ingerem alimentos para suprirem outras funções e manter a 
energia. 
• Processamento (throughput): é o fenômeno que produz mudanças, é o mecanismo de 
conversão das entradas em saídas. No animal, a comida é transformada em energia 
e suprimento das células. Na organização, a produção é equivalente a esse ciclo 
animal. Os materiais são processados havendo certa relação entre entradas e saídas 
9 
 
no qual o excesso é o equivalente a energia necessária para a sobrevivência da 
organização (transformação em produtos). 
• Saída, resultado ou produto (output): é a finalidade para a qual se reuniram elementos 
e relações do sistema. A saída deve ser coerente com o objetivo do sistema. 
• Retroalimentação, retroação ou retro informação (feedback): é a função do sistema 
que tem em vista comparar a saída com um critério ou padrão previamente 
estabelecido (objetivo). Os sistemas que não têm condições de continuadamente 
atender a essa condição, comprometem sua capacidade de sobrevivência. A 
retroalimentação visa o controle. 
• Ambiente: é o meio que envolve o sistema. O ambiente serve como fonte de energia 
para o sistema e ambos estão em contínua interação. O ambiente estando em 
constante mudança, o processo de adaptação do sistema é um processo dinâmico. O 
ambiente de um sistema é um conjunto de elementos que não fazem parte do sistema, 
mas que podem causar mudanças no estado do sistema. 
 
 
1.2 Conceitos de Sistemas de Informação 
É uma série de elementos ou componentes inter-relacionados que coletam (entrada), 
manipulam e armazenam (processo), disseminam (saída) os dados e informações e fornecem 
um mecanismo de feedback, apoiando o controle, a coordenação e a tomada de decisão em 
uma organização; auxiliam gerentes e funcionários a analisar problemas, visualizar soluções 
e a criar novos produtos. 
AMBIENTE 
RETROALIMENTAÇÃO 
ENTRADA
informação
energia
recursos materiais
PROCESSAMENTO
ou transformação
SAÍDA
informação
energia
recursos materiais
10 
 
É um tipo especializado de sistema, podendo ser definido como um conjunto de 
componentes inter-relacionados trabalhando juntos para coletar, recuperar, processar, 
armazenar e distribuir a informação com a finalidade de facilitar o planejamento, o controle, a 
coordenação, a análise e o processo decisório em empresas e organizações. 
Os sistemas de informação podem ser manuais ou baseados em computador. Muitos 
sistemas de informação começam como sistemas manuais e se transformam em 
computadorizados que estão configurados para coletar, manipular, armazenar e processar 
dados. 
 
1.2.1 Sistemas de informação baseados em computador 
Sistemas de informação baseados em computador (CBIS - computer-based 
information system), são compostos por: hardware, software, banco de dados, 
telecomunicações, pessoas e procedimentos. 
• Hardware: consiste no equipamento, o computador usado para executar as atividades 
de entrada, processamento e saída. 
• Software: consiste nos programas e nas instruções dadas ao computador. 
• Banco de Dados: é uma coleção organizada de fatos e informações. 
• Telecomunicações: permitem às empresas ligar os sistemas de computador em 
verdadeiras redes de trabalho. 
• Pessoas (peopleware): consiste no elemento mais importante na maior parte dos 
sistemas de informação. Incluem todas as pessoas que gerenciam, executam, 
programam e mantêm o sistema de computador. 
• Procedimentos: incluem as estratégias políticas, métodos e regras usadas pelo 
homem para gerar o sistema de informação baseados em computador. 
 
Qual a diferença entre dado e informação? 
 
 
 
 
Exemplos de dados em uma empresa: quantidade de produção, custo da matéria-
prima, número de funcionários. 
Como resultado da análise de tais dados tem-se a informação: capacidade de 
produção, custo de venda do produto, produtividade do funcionário. 
 
Dado - é qualquer elemento identificado em sua forma bruta que por si só não 
conduz a uma compreensão de determinado fato ou situação. 
 
 
Informação - é o dado trabalhado que permite a tomada de decisão. 
11 
 
Essas informações, ao serem utilizadas pelo executivo de uma empresa, podem afetar 
ou modificar o comportamento existente na empresa, bem como o relacionamento entre as 
suas várias unidades organizacionais. 
O propósito básico da informação é o de habilitar a empresa a alcançar seus objetivos 
pelo uso eficiente dos recursos disponíveis, nos quais se inserem pessoas, materiais, 
equipamentos, tecnologia, dinheiro além da própria informação. 
A eficiência na utilização do recurso informação é medida pela relação do custo paraobtê-la e o valor do benefício derivado do seu custo. 
 
1.2.2 Características ideais de uma informação 
A informação deve ser: (Cautela e Polloni, 1996, p.23): 
• Clara: apresentar o fato com clareza, não o mascarando entre os fatos acessórios. 
• Precisa: deve ter um alto padrão de precisão e nunca apresentar termos como: "por 
volta de...", "cerca de...", "mais ou menos...". 
• Rápida: chegar ao ponto de decisão em tempo hábil para que gere efeito na referida 
decisão. Uma informação pode ser clara e precisa, mas se chegar atrasada, perde a 
sua razão de ser. 
• Dirigida: a quem tenha necessidade dela e que irá decidir com base nessa informação. 
 
1.2.3 Qualidade das informações 
O número de veículos (meios) de informação influencia de maneira fundamental na 
qualidade da informação. A qualidade tende a decrescer à medida que se aumenta o número 
de veículos de informação. 
 
2 INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
Desde sua criação até os dias atuais, os computadores juntamente com seus 
softwares, foram ganhando cada vez mais importância e diversificando sua aplicação nas 
mais distintas áreas de nossas vidas. Atualmente, os computadores e seus softwares estão 
presentes tanto em eletrodomésticos como em complexos sistemas de controle de tráfego 
aéreo, financeiros ou mesmo auxiliando em cirurgias de risco. 
No início, os computadores eram imensos e suas operações eram muito simples. O 
custo com hardware era muito grande e os softwares não tinham custos ou eram baixos. Com 
o passar dos anos, houve uma inversão nessa equação e o tamanho dos computadores é 
cada vez menor, seus preços são mais acessíveis ao passo que sua capacidade de 
12 
 
processamento e armazenamento aumentou vertiginosamente. Os softwares por sua vez, são 
mais complexos, confiáveis e com custos mais altos em relação ao hardware. 
A engenharia de software é um ramo da engenharia que tem como foco o 
desenvolvimento com prazos e custos adequados com alto padrão de qualidade, o que não é 
muito fácil devido às características peculiares do software. A engenharia de software surgiu 
na década de 1970 originada pela crise do software. 
 
2.1 Crise do Software 
A criação de memórias semicondutoras e de microprocessadores trouxe consigo um 
grande aumento na demanda por softwares maiores e mais avançados do que os 
desenvolvidos anteriormente. Até então, os sistemas eram desenvolvidos de maneira informal 
sem a existência de padrões ou mesmo preocupação com documentação ou mesmo com a 
manutenção. A programação era encarada como uma arte e devido a isso, frequentemente 
projetos importantes apresentavam muitos problemas. Em 1968, foi realizada uma 
conferência para discutir o que foi então chamado de “crise do software”. A crise do software 
foi caracterizada por prazos e custos não respeitados, baixa qualidade, baixa produtividade 
dos profissionais, insatisfação dos clientes, entre outros. Nesta conferência surgiu pela 
primeira vez o conceito de engenharia de software. 
 
2.2 O que é Engenharia de Software? 
A engenharia de software é uma disciplina de engenharia relacionada com todos os 
aspectos envolvidos na produção do software, desde os estágios iniciais de especificação do 
sistema até sua manutenção, que acontece depois que este já está em operação. 
A Engenharia de Software deve adotar: 
• uma abordagem sistemática e organizada para o seu trabalho, 
• usar ferramentas e técnicas apropriadas de acordo com: 
o o problema a ser resolvido 
o as restrições de desenvolvimento 
o recursos disponíveis 
 
2.2.1 Objetivos da Engenharia de Software 
• aumentar a produtividade 
• melhorar a qualidade 
• Importância do Software 
13 
 
• uso no cotidiano 
• manipula informação (dado - informação - conhecimento - poder) 
 
Metas da Engenharia de Software 
 
A Engenharia de Software procura fornecer métodos, técnicas e ferramentas para que 
se possa desenvolver softwares que alcancem produtividade no processo de 
desenvolvimento; tenham qualidade e confiabilidade; sejam fáceis de utilizar; sejam de fácil 
manutenção. 
 
Metas da Engenharia de Software 
 
Manutenção: 
• quantidade de software a manter tende a crescer 
• tornar o software fácil de ser mantido (modificabilidade) 
 
Qualidade e Confiabilidade: 
• conformidade com requisitos definidos 
• ausência de defeitos 
• robustez 
 
Produtividade: 
• custos e prazos 
• gerenciamento do processo 
• inteligibilidade 
• equipes de desenvolvimento 
 
Facilidade de uso: 
• performance 
• interface com usuário 
 
Qual a diferença entre objetivo e meta? 
14 
 
 
 
 
 
 
 
 
 
 
 
Por exemplo, caso o objetivo seja chegar ao peso ideal em um ano (valor e prazo 
aproximados), uma das metas pode ser perder três quilos até o final do próximo mês (valor e 
prazos precisos, caminhando para o objetivo). 
 
2.2.2 O que é software? 
 
É comum associar o termo software a programas de computador, mas na verdade é 
bem mais que isso. Softwares são sim programas de computador, geralmente um conjunto 
de programas separados, acompanhados de todos os dados a ele associados, tais como e 
suas documentações que vão desde a descrição da estrutura do sistema até a documentação 
que orienta o usuário em relação a como usá-lo e ainda sites Web nos quais o usuário obtém 
informações recentes. 
Produtos de software podem ser desenvolvidos para um cliente específico ou pode ser 
desenvolvido para o mercado em geral 
Produtos de software podem ser: 
1. Genéricos – desenvolvidos para serem vendidos para uma ampla gama de 
clientes 
2. Sob encomenda – desenvolvido para um único cliente de acordo com a sua 
necessidade. 
2.2.3 Características do software 
Para que se possa obter a compreensão do que é software (e, principalmente, uma 
compreensão da engenharia de software), é importante examinar as características do 
software que o tornam diferente das outras coisas que os seres humanos constroem. Quando 
o hardware é construído, o processo criativo humano (análise, projeto, construção e teste) é 
imediatamente traduzido numa forma física. Se construirmos um novo computador, nossos 
O objetivo é um ponto concreto que 
se quer atingir, devendo ter parâmetros 
numéricos e datas a serem alcançadas, de 
modo geral: Ressalta-se que a meta é uma 
segmentação do objetivo, em que o 
aspecto quantitativo tem uma importância 
maior, ou seja, é mais preciso em valor e 
em data, pois é mais próximo que o 
objetivo. 
15 
 
esboços iniciais, desenhos de projeto e protótipo em forma de breadboard (arranjo 
experimental de circuitos eletrônicos) evoluem para um produto físico (chips VLSI, placas de 
circuito, fontes de energia etc.). 
 
O software é um elemento de sistema lógico, e não físico 
Portanto, o software tem características que são consideravelmente diferentes das do 
hardware. 
O software é desenvolvido ou projetado por engenharia, não manufaturado no sentido 
costumeiro. 
Apesar de existirem algumas semelhanças entre o desenvolvimento de software e a 
manufatura de hardware, as duas atividades são fundamentalmente diferentes. Em ambas as 
atividades, a alta qualidade é obtida mediante um bom projeto, mas a fase de manufatura do 
hardware pode introduzir problemas de qualidade que inexistem (ou são facilmente corrigidos) 
para o software. As duas atividades dependem de pessoas, mas a relação entre as pessoas 
envolvidas e o trabalho executado é totalmente diferente. Embora exijam a construção de um 
"produto", as abordagens são muito diferentes. 
Os custos do software estão concentrados no trabalho de engenharia. Isto significa 
que os projetos de software não podem ser conduzidos como se fossem projetos de 
manufatura. 
No decorrer da década passada, o conceito de "fábrica de software" foi discutido na 
literatura. Torna-se importante observar que este termo não implica que a manufatura de 
hardware e o desenvolvimento de software sejam equivalentes.Ao contrário, o conceito de 
fábrica de software recomenda o uso de ferramentas automatizadas para o desenvolvimento 
de software. 
 
O software não se "desgasta" 
A figura a seguir mostra o índice de falhas como uma função do tempo para o hardware. 
A relação, muitas vezes chamada "curva da banheira", indica que o hardware exibe índices 
de falhas relativamente elevados logo no começo de seu ciclo de vida (estas falhas 
frequentemente são atribuídas a defeitos de projeto e manufatura); os defeitos são corrigidos 
e o índice de falhas cai para um nível estável (esperançosamente, muito baixo) durante certo 
período de tempo. À medida que o tempo passa, entretanto, o índice de falhas eleva-se 
novamente conforme os componentes de hardware sofrem os efeitos cumulativos de poeira, 
vibração, abuso, temperaturas extremas e muitos outros males ambientais. Colocado de 
maneira simples o hardware começa a se desgastar. 
 
16 
 
 
Curva de falhas para o hardware 
 
O software não é sensível aos problemas ambientais que fazem com que o hardware 
se desgaste. Teoricamente, portanto, a curva do índice de falhas para o software assumiria a 
forma representada na figura abaixo. Defeitos não descobertos provocarão elevados índices 
de falhas no começo da vida de um programa. Porém esses são corrigidos (espera-se que 
novos erros não sejam introduzidos) e a curva achata-se, como mostra a Figura 2. Esta figura 
representa de forma grosseira e simplificada os modelos de falhas reais para o software. 
Entretanto, fica claro que o software não se desgasta. Todavia se deteriora. 
 
In
d
ic
e 
d
e 
fa
lh
as
Tempo
Continua na mesma taxa até a
absolescência
 
Curva de falhas do software (idealizada) 
Esta aparente contradição pode ser mais bem explicada considerando a de falhas 
reais para o software. Durante sua vida, o software enfrentará mudanças (manutenção). 
Quando estas são feitas, é provável que novos defeitos sejam introduzidos, fazendo com que 
a curva do índice de falhas apresente picos, como mostrado na figura abaixo: 
 
 
In
d
ic
e 
d
e 
fa
lh
as
Tempo
Elevados índices
de falhas "Desgaste"
17 
 
In
d
ic
e 
d
e 
fa
lh
as
Tempo
Mudanças
Curva Idealizada
Curva real
 
Curva de falhas reais para o software 
 
Outro aspecto do uso ilustra a diferença entre o hardware e o software. Quando se 
desgasta, um componente de hardware é substituído por uma "peça de reposição". Não 
existem peças de reposição para o software. Toda falha de software indica um erro de projeto 
ou no processo por meio do qual o projeto foi traduzido em código executável por máquina. 
Portanto a manutenção do software envolve consideravelmente mais complexidade do que a 
manutenção de hardware. 
 
 
A maioria dos softwares é feita sob medida 
Em vez de ser montada a partir de componentes existentes, a maioria dos softwares 
são desenvolvidos para um cliente em específico, diferente de outros produtos, em que um 
modelo de projeto servirá para outros vários clientes. 
Consideremos a maneira segundo a qual o hardware de controle para um produto 
baseado em microprocessadores é projetado e construído. O engenheiro de projetos desenha 
um esquema simples do circuito digital, faz algumas análises fundamentais para garantir que 
a função adequada seja conseguida e depois vai a estante onde existem catálogos de 
componentes digitais. Cada circuito integrado ou chip tem uma numeração de peça, uma 
função definida e validada, uma interface bem definida e um conjunto padrão de diretrizes de 
integração. Depois que cada componente é escolhido, o hardware pode ser encomendado. 
Infelizmente, os projetistas de software não podem permitir-se ao que acabamos de 
descrever. Com poucas exceções, não existem catálogos de componentes de software. É 
possível encomendar software não destinado à publicação, mas somente como uma unidade 
completa, não como componente que possa ser montado novamente em novos programas, 
embora esta situação esteja em mudança com a difusão do uso de programação orientada a 
objetos. 
18 
 
Ainda que muita coisa tenha sido escrita sobre reusabilidade de software, somente agora 
começam a aparecer as primeiras tentativas bem sucedidas. 
 
2.3 Qual é a diferença entre Engenharia de Software e Ciência da Computação? 
A Ciência da Computação preocupa-se com as teorias e os fundamentos; a 
Engenharia de Software preocupa-se com os aspetos práticos inerentes ao desenvolvimento 
e implantação de software. 
As teorias da Ciência da Computação são, atualmente, insuficientes para servir como 
a única de base para a Engenharia de Software. 
 
2.4 Qual é a diferença entre Engenharia de Software e Engenharia de Sistemas? 
A Engenharia de Sistemas preocupa-se com todos os aspetos do desenvolvimento de 
sistemas baseados em computador, incluindo hardware, software e engenharia de processos. 
A Engenharia de Software é parte desse processo. 
Engenheiros de Sistemas estão envolvidos na especificação de sistemas, projeto 
arquitetural, integração e implantação. 
 
2.5 O que é um processo de software? 
 
• Um conjunto de atividades cujo objetivo é o desenvolvimento ou evolução do 
software 
• As atividades genéricas presentes em todos os processos de software são: 
o Especificação – o que o sistema deve fazer e quais são as restrições de 
desenvolvimento 
o Desenvolvimento – Produção do sistema de software 
o Validação- verificação de que o software faz o que o cliente queria 
o Evolução- mudar o software em resposta à demanda por mudanças 
2.6 O que é um modelo de processo de software? 
 
Representação simplificada de um processo de software vista sob uma perspectiva 
específica. 
Exemplos de perspectivas de processo: 
• Workflow – sequencia de atividades; 
• Dataflow – fluxo de informação; 
19 
 
• Papel/ação – quem faz o que? 
 
Modelos genéricos de processos 
• Modelo cascata; 
• Desenvolvimento evolucionário; 
• Transformação formal e 
• Integração a partir de componentes reutilizáveis. 
 
2.6.1 Modelo cascata 
Também conhecido como ciclo de vida clássico, tem como principal característica a 
sequencia de atividades onde cada fase transcorre completamente e seus produtos são vistos 
como entrada para uma nova fase. Sofreu diversos ajustes e aprimoramentos sendo muito 
utilizado nos dias atuais. 
A Figura 1 mostra uma descrição visual do modelo cascata: 
 
 
 
 
 
 
 
 
 
 
 
 
 
Modelo cascata 
A ideia principal do modelo é que as diferentes etapas de desenvolvimento seguem 
uma sequência, ou seja, a saída da primeira etapa flui para a segunda etapa, a saída da 
segunda flui para a terceira e assim por diante. As atividades são agrupadas em tarefas, 
executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior 
tiver terminado. 
O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito 
bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no andamento 
de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os 
Análise 
Projeto 
Implantação 
Codificação 
Testes 
20 
 
modelos e as conclusões das tarefas anteriores, é normal que as novas ideias sobre o sistema 
não sejam aproveitadas. 
Numa tentativa de resolver este tipo de problema foi definido um novo tipo de 
processo baseado no clássico em cascata, designado por modelo em cascata revisto, cuja 
principal diferença consiste em prever a possibilidade de a partir de qualquer tarefa do ciclo 
se poder regressar a uma tarefa anterior de forma a contemplar alterações funcionais e/ou 
técnicas que entretanto tenham surgido, em virtude de um maior conhecimento que se tenha 
obtido. O risco desta abordagem é que, na ausência de um processo de gestão do projeto e 
de controle das alterações bem definido, podemos passar o tempo num ciclo infinito, sem 
nunca se atingir o objetivo final, ou seja, disponibilizar o sistemaa funcionar. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Cascata revisto 
2.6.2 Modelo de Prototipagem 
Muitas vezes nos deparamos com situações em que o cliente ainda não identificou 
os requisitos de entrada, processamento e saída de forma detalhada. Existem também outros 
casos que o desenvolvedor não tem a certeza do efeito de um determinado algoritmo, da 
compatibilidade com determinado sistema operacional ou ainda se a usabilidade está boa. 
Em todos os casos geralmente acarreta em erros e consequentemente na insatisfação do 
cliente. Nessas e em outras muitas situações a Prototipação da Engenharia de Software pode 
representar uma excelente abordagem. 
Análise 
Projeto 
Implantação 
Codificação 
Testes 
21 
 
A Prototipação é um processo no qual o desenvolvedor tem a capacidade de criar 
um modelo do software que será implementado. O modelo pode assumir uma das três formas: 
1. Um modelo em papel que o usuário tenha a visão da interação homem-máquina e 
quantas interações ocorrerá. 
2. Um protótipo de trabalho que implementa algumas funcionalidades exigidas pelo 
software. 
3. Um programa existente que executa parte ou toda a função desejada, mas que 
tem outras características que serão melhoradas posteriormente. 
A sequência de eventos para o paradigma de prototipação é ilustrada a seguir. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Modelo Prototipação 
 
Como em todas as abordagens do desenvolvimento de software, a prototipação inicia-
se com a coleta de requisitos. Durante essa fase, clientes e desenvolvedores ficam em 
constante interação, facilitando assim o levantamento de requisitos e funcionalidades do 
sistema. Ocorre então a elaboração de um “projeto rápido”, concentrando-se nos aspectos 
definidos pelo usuário. O Projeto rápido leva a construção de um protótipo que é avaliado pelo 
cliente/usuário e é usado para refinar os requisitos. 
Assim como o Ciclo de Vida Clássico, a Prototipação como paradigma da Engenharia 
de Software pode trazer problemas nas seguintes situações: 
1. O Protótipo na grande maioria das vezes é projetado sem a preocupação com a qualidade 
e manutenibilidade a longo prazo. 
2. A implementação utilizada para apresentar o protótipo pode no final ser a definitiva. 
Coleta de 
requisitos 
Refinamento 
protótipo Projeto 
Avaliação do 
protótipo 
Construção 
do protótipo 
22 
 
3. Com o tempo os desenvolvedores podem se acostumar com a forma de codificação da 
prototipação. 
4. O descarte do protótipo pode ser visto como perda de tempo pelo cliente. 
A Prototipação é um paradigma eficiente da Engenharia de Software. A chave é o 
acordo entre cliente e desenvolver que o protótipo será construído a fim de servir como base 
para definição de requisitos. Ele será depois descartado (pelo menos em parte) e o software 
real será projetado, levando-se em consideração a qualidade e a manutenibilidade. 
Vimos que a ideia principal da prototipação é a criação de uma espécie de “modelo” 
que servirá de base para algo real. 
 
2.6.3 Modelo de processo de desenvolvimento incremental 
O Modelo Incremental foi desenvolvido através da combinação entre os modelos linear 
e prototipação. O desenvolvimento é dividido em etapas, denominadas “incrementos”, que 
produzirão acréscimos ao sistema, até a sua versão final. 
Em cada incremento é realizado todo o ciclo do desenvolvimento de software, desde 
o planejamento até os testes do sistema já em funcionamento. Cada etapa produz um sistema 
totalmente funcional, apesar de ainda não cobrir todos os requisitos. 
O Modelo Incremental apresenta diversas vantagens para o desenvolvimento de um 
software, especialmente se os requisitos não estão claros inicialmente. Por exemplo: quando 
o Modelo Incremental é utilizado, o primeiro incremento é normalmente constituído do núcleo 
do sistema. Isto é, os requisitos básicos são implementados, e os detalhes suprimidos. Esse 
produto será entregue para uma avaliação, que poderá detectar, inicialmente, problemas que 
poderiam ter dimensões muito maiores se detectados somente na entrega do produto final. 
Outra vantagem para o desenvolvedor é que, em contato com o sistema, o cliente 
esclarece seus requisitos e suas prioridades para os próximos incrementos, além de contar 
com os serviços da versão já produzida. 
 
 
 
 
 
 
 
 
 
23 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Modelo incremental 
 
Vantagens do processo incremental 
- Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e identificar 
medidas para eliminá-los ou controlá-los; 
- Redução dos riscos envolvendo custos a um único incremento. Se a equipe que 
desenvolve o software precisar repetir a iteração, a organização perde somente o esforço mal 
direcionado de uma iteração, não o valor de um produto inteiro; 
- Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento; 
- Disponibilização natural de um conjunto de regras para melhor controlar os 
inevitáveis pedidos de alterações futuras; 
- Permite que os vários intervenientes possam trabalhar mais efetivamente pela 
interação e partilha de comunicação daí resultante. 
Análise 
Projeto 
Codificação 
Testes 
Análise 
Projeto 
Implantação 
Codificação 
Testes 
1ª Versão 
2ª Versão 
24 
 
2.6.4 Modelo Iterativo 
Modelo concebido com base nas limitações do modelo em cascata, combinando as 
vantagens deste com as do modelo Prototipação. A ideia principal é a de que um sistema 
deve ser desenvolvido de forma incremental, onde a cada incremento serão adicionadas ao 
sistema novas capacidades funcionais, até a obtenção do sistema final. A cada passo 
realizado, modificações podem ser introduzidas. 
Uma implementação inicial do sistema é obtida, na forma de um subconjunto da 
solução do problema global deve contemplar os principais aspectos que sejam facilmente 
identificáveis no que diz respeito ao problema a ser resolvido. 
A lista de controle de projeto contem todos os passos a serem realizados para a 
obtenção do sistema final definindo quais tarefas devem ser realizadas a cada iteração. 
Todo o desenvolvimento é gerenciado para se medir em um determinado nível, o quão 
distante se está da última iteração. 
Cada iteração do modelo consiste em retirar um passo da lista de controle de projeto 
através da realização de três etapas (projeto, implementação e análise) até que a lista esteja 
completamente vazia. 
Vantagens desta abordagem 
• facilidade em testar o sistema, uma vez que a realização de testes em cada 
nível de desenvolvimento é mais fácil do que testar o sistema na sua versão final 
• obtenção de um sistema (mesmo incompleto) rapidamente, o que pode 
oferecer ao cliente interessantes informações que sirvam de subsídio para a melhor definição 
de futuros requisitos do sistema (como na Prototipação). 
 
 
 
 
 
 
 
 
 
 
 
 
 
Modelo iterativo 
Análise 
Projeto 
Codificação 
Análise 
Projeto 
Codificação 
Análise 
Projeto 
Codificação 
0 1 N 
. . . 
25 
 
Diferença entre o modelo iterativo e o modelo Incremental 
Os modelos iterativo e incremental podem ser facilmente confundidos, mas são 
profundamente diferentes. 
No modelo incremental, desenvolve-se uma primeira versão, sem se preocupar muito 
com o todo. Portanto, o desenvolvimento se inicia sem que haja um conhecimento amplo dos 
requisitos do sistema. Através do feedback do usuário, os requisitos vão sendo elicitados e 
implementados nas versões subsequentes do sistema. 
No modelo iterativo, tem-se uma visão inicial de todos (ou quase todos) os requisitos 
do usuário, mas não se implementam todos de uma vez: a cada iteração é implementado um 
subconjunto de requisitos. Estes requisitos são então apresentados ao usuário, que fica 
satisfeito ao ver que os trabalhos estão evoluindo. Eventualmente, um requisito pode ser até 
implantado e disponibilizado para uso. Admite-se que o levantamentoinicial registre 80% dos 
requisitos do sistema. Os outros surgem durante o desenvolvimento. Não vale a pena investir 
muito tempo para se esgotar todos os requisitos: perde-se tempo e corre-se o risco de levantar 
falsos requisitos (desnecessários). 
Observe as figuras que auxiliam em um comparativo entre os modelos incremental e 
Iterativo: 
 
 
 
26 
 
2.6.5 Modelo Espiral 
Neste modelo o projeto é tratado como uma série de pequenos ciclos, cada um 
finalizando uma versão de um software executável. 
O modelo em espiral foi proposto como forma de integrar os diversos modelos 
existentes à época, eliminando suas dificuldades e explorando seus pontos fortes. Foi 
desenvolvido para abranger as melhores características tanto do ciclo de vida clássico como 
da prototipação acrescentando, ao mesmo tempo, um novo elemento: a análise de riscos. 
Entretanto a integração não se dá através da simples incorporação de características 
dos modelos anteriores. O modelo em espiral assume que o processo de desenvolvimento 
ocorre em ciclos, cada um contendo fases de avaliação e planejamento, onde a opção de 
abordagem para a próxima fase (ou ciclo) é determinada. Estas opções podem acomodar 
características de outros modelos. 
O modelo original em espiral organiza o desenvolvimento como um processo iterativo 
em que vários conjuntos de quatro fases se sucedem até se obter o sistema final. Um ciclo se 
inicia com a determinação de objetivos, alternativas e restrições (primeira tarefa) onde ocorre 
o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os 
objetivos. Na segunda tarefa, análise e avaliação de alternativas, identificação e solução de 
riscos, executa-se uma análise de risco. A prototipação é uma boa ferramenta para tratar 
riscos. Se o risco for considerado inaceitável, pode parar o projeto. Na terceira tarefa ocorre 
o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na 
quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo. 
A figura abaixo exemplifica uma representação do modelo espiral. 
 
 
Modelo espiral 
 
Variações do modelo espiral consideram entre três e seis tarefas ou setores da 
espiral, que podem ser: 
- comunicação com o cliente; 
27 
 
- planejamento; 
- análise de risco; 
- engenharia; 
- construção e liberação; 
- avaliação do cliente. 
O modelo espiral é atualmente a abordagem mais realística para desenvolvimento 
de software em grande escala, e usa uma abordagem que capacita a empresa que presta o 
serviço, e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo 
exige considerável experiência na determinação de riscos e depende dessa experiência para 
ter sucesso, pode ser difícil convencer os clientes que uma abordagem evolutiva é controlável. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Iterativo X Interativo 
Duas palavras muito comuns na área de informática, mas que constantemente são 
confundidas em seu significado e aplicação: iterativo e interativo. 
Iterativo se refere a ciclo, repetição. 
Uma Iteração é um ciclo ou uma etapa 
de uma rotina maior. 
Interativo, se refere a relacionamento, 
comunicação. 
Uma interação é uma ação mútua, uma entidade 
agindo sobre a outra ou vice-versa. 
 
Equívoco 
28 
 
Quais são os custos da Engenharia de Software? 
 
Aproximadamente 60% do custo são de desenvolvimento, 40% são para testes. Em 
software sob medida, custos de evolução normalmente excedem os de desenvolvimento. 
Os custos variam de acordo com: 
• o tipo do sistema a ser desenvolvido; 
• atributos de requisitos tais como performance e confiabilidade; 
• A distribuição do custo depende do modelo de desenvolvimento utilizado. 
 
2.8 O que são métodos de Engenharia de Software? 
 
Abordagens estruturadas de desenvolvimento que incluem modelos de sistema, 
notações, regras, diretrizes de projeto e guia de processo. 
Descrições de modelos de sistema: 
Descrições de modelos gráficos que devem ser produzidos 
Regras: 
Restrições aplicadas aos modelos do sistema 
Recomendações: 
Orientações sobre boas práticas de projeto 
Guia de processo: 
Quais são as próximas atividades 
Engenharia: Aplicação de conhecimentos científicos e empíricos, e certas habilidades 
para criação de estruturas. 
Software: Programa de computador. 
Engenharia de Software: Aplicação prática do conhecimento para a construção de 
programas. 
 
 
Problemas no desenvolvimento 
 
Entendimento do problema 
Definição inadequada 
Deficiência no levantamento de necessidades 
Deficiência na estruturação e planejamento do projeto 
Deficiência na organização do projeto 
29 
 
Dificuldade no encerramento do projeto 
Diálogo entre usuários e analistas 
Documentação inadequada 
Modelos diversos para representação da solução 
Passagem da representação da solução para o sistema de processamento de dados 
Falta de padronização 
 
Mitos do Software 
 
1 - “Já temos um manual repleto de padrões e procedimentos para a construção de 
software. Isso já é suficiente para o pessoal do desenvolvimento”. 
2 - “Meu pessoal tem ferramentas de última geração, afinal de contas compramos os 
mais novos computadores”. 
3 - “Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e 
tirar o atraso”. 
4 - “Uma declaração geral dos objetivos é suficiente para se começar a escrever 
programas, podemos preencher os detalhes mais tarde”. 
5 - “Os requisitos de projeto modificam-se continuamente, mas as mudanças podem 
ser facilmente acomodadas, porque o software é flexível”. 
6 - “Assim que escrevermos o programa e o colocarmos em funcionamento, nosso 
trabalho estará completo”. 
7 - “Enquanto não tiver o programa funcionando, eu não terei realmente nenhuma 
maneira de avaliar sua qualidade”. 
8 - “A única coisa a ser entregue em um projeto bem-sucedido é o programa 
funcionando”. 
 
 
Paradigmas de Engenharia de Software 
 
Método é uma palavra que vem do grego méthodos, que significa “caminho para se 
chegar a um fim”. 
O Aurélio define método como sendo “programa que regula previamente uma série de 
operações que se devem realizar, apontando erros evitáveis, em vista de um resultado 
determinado”. 
 
Técnica é uma palavra que vem do grego technikós, que significa "relativo à arte". 
30 
 
O Aurélio [FER75] define técnica como sendo “a parte material ou o conjunto de 
processos de uma arte”. 
 
Ferramenta é uma palavra que vem do latim ferramentum. 
O Aurélio [FER75] define ferramenta como sendo “qualquer utensílio empregado nas 
artes e ofícios”. 
 
Estes três elementos devem ser envolvidos em um único conjunto de etapas. 
O arcabouço deste conjunto é conhecido como ciclo de vida ou paradigma de 
engenharia de software. 
A definição do paradigma, dos métodos, das ferramentas e técnicas para aplicação 
em desenvolvimento de software cria uma metodologia de desenvolvimento de sistemas 
(MDS). 
 
Ciclo de vida do software é um modelo que orienta as principais atividades no 
desenvolvimento de um sistema / software. Ele é fundamental para a definição de uma MDS. 
 
Apresentaremos os enfoques mais comuns de modelos de ciclo de vida do sistema / 
software. 
Modelo tradicional ou em Cascata (Waterfall) 
Este abordagem baseia-se no modelo cascata ou método linear de desenvolvimento 
(figura 2). 
Podem ser utilizados conceitos de Engenharia de Software, a qual prevê atividade de 
verificação (estamos fazendo o produto de forma correta?), validação (estamos fazendo o 
produto certo?) e de controle de qualidade. 
 
O ciclo é representado pelas seguintes fases: 
Viabilidade: definição preliminar do escopo do sistema, restrições e conceitos 
alternativos; 
Análise: especificação funcional do sistema (Projeto Lógico); 
Projeto: especificação completa da arquitetura de hardware e software, estruturas de 
controle, estruturas de dados do sistema,interfaces; 
Implementação: codificação e teste individual dos programas; 
Teste: teste dos componentes integrados do sistema; 
Implantação: implantação de maneira gradativa, a fim de evitar insatisfação e 
possibilitando a recorreção do sistema. Implantação piloto / paralela e definitiva; 
31 
 
Operação e Manutenção: utilização do sistema e modificações decorrentes de erros, 
mudança de necessidades, etc. 
 
O modelo cascata é apropriado para sistemas transacionais onde as rotinas e 
procedimentos a serem automatizados são altamente estruturados. 
 
A principal desvantagem desta abordagem é o alto custo de correção das 
especificações quando nas fases de Teste e Implantação. 
Modelo de ciclo de vida com prototipação 
Conjunto de técnicas e ferramentas de software para o desenvolvimento de modelos 
“vivos” de sistemas. 
 
Objetivo: Antecipar ao usuário final um modelo de sistema para que ele possa avaliar 
sua finalidade, identificar erros e omissões, quando em utilização, efetuando de imediato 
correções e ajustes. 
 
A filosofia de protótipos possui as seguintes vantagens: 
• maior garantia de sucesso técnico e psicológico; 
• redução no fator tempo: "o usuário gosta de ver o sistema funcionando"; 
• ideal para sistemas gerenciais e de apoio a decisão. 
 
Como desvantagens temos: 
• exige elevada capacitação gerencial por parte da equipe do projeto; 
• aparentemente, mais dispendioso (a longo prazo esta desvantagem tende a 
desaparecer); 
• exige uma ferramenta apropriada de prototipação. 
 
Modelo Espiral ou Evolutivo 
Modelo de ciclo de vida que se utiliza de protótipos por se adequar muito bem com 
esta filosofia de desenvolvimento. Cada passo através do ciclo inclui: planejamento, análise e 
projeto, prototipação e avaliação. Os passos vão sendo repetidos até que um produto seja 
obtido. 
Este é um modelo que atende os seguintes casos: 
• o problema a ser resolvido não está totalmente entendido; 
• a realidade pode mudar enquanto o sistema está sendo desenvolvido; 
• a própria solução adotada pode ter algum efeito colateral desconhecido; 
32 
 
• a preocupação está centrada mais na qualidade e funcionalidade do que se 
produz. 
 
Com base na experiência adquirida com a primeira versão, estabelecem-se novos 
requisitos para o sistema, e uma nova versão é concebida e implementada. 
 
A prototipação no ciclo de vida espiral tem como objetivos: 
• estabelecer um diálogo intensivo entre usuários e analistas/projetistas; 
• encurtar ao máximo o ciclo "concepção-implementação-utilização-avaliação" 
do sistema; 
• possibilitar a evolução do sistema através de vários ciclos ou refinamentos 
sucessivos; 
• avaliar constantemente o sistema. 
 
 
O que é CASE (Computer-Aided Software Engineering)? 
Sistemas de software cujo objetivo é fornecer apoio automatizado para atividades do 
processo de software. Sistemas CASE são normalmente usados para sustentar métodos 
Upper-CASE 
Ferramentas que dão apoio às atividades iniciais do processo, tais como de análise de 
requisitos e projeto 
Lower-CASE 
Ferramentas que dão apoio às atividades finais do processo, tais como programação, 
depuração e teste 
 
Quais são os atributos de um bom software? 
 
Ter funcionalidade e desempenho solicitado pelo usuário, deve ser manutenível, 
confiável e usável. 
Manutenibilidade 
O software deve evoluir para atender as necessidades de mudanças 
Confiabilidade 
O software deve ser confiável 
Eficiência 
O software não deve esbanjar os recursos do sistema 
Usabilidade 
33 
 
O software deve ser usável pelos seus usuários 
Quais são os principais desafios enfrentados pela engenharia de software? 
Competição com sistemas legados, com aumento da diversidade e com a demanda 
reduzida do tempo de liberação 
Sistemas Legados 
Sistemas antigos e valiosos devem ser mantidos e atualizados 
Diversidade 
Sistemas são distribuídos e incluídos num misto de hardware e software 
Liberação 
Aumento da pressão para rápida liberação do software 
 
Responsabilidade Profissional e Ética 
 
Engenheiros de Software comprometem-se com responsabilidades ao invés de 
apenas envolver-se com a aplicação de habilidades técnicas 
Engenheiros de Software devem se comportar de maneira honesta, ética e 
responsável se quiserem ser respeitados como profissionais 
Comportamento ético é muito mais do que simplesmente respeitar as leis. 
 
Assuntos de responsabilidade profissional 
 
Confidencialidade 
Engenheiros devem respeitar a confidencialidade de seus empregados ou clientes 
independentemente da existência de um acordo de confidencialidade formal. 
Competência 
Engenheiros não devem violar seu nível de competência. Eles não devem 
propositalmente aceitar trabalhos que estejam fora de sua competência. 
 
Assuntos de responsabilidade profissional 
 
Direitos da propriedade intelectual 
Engenheiros devem estar cientes da legislação local que governa o uso da 
propriedade intelectual tais como padrões, copyright, etc. Eles devem ter cuidado em 
assegurar que a propriedade intelectual dos empregados e clientes sejam protegidas. 
Uso impróprio do computador 
Engenheiros de software não devem usar suas habilidades técnicas para fazer uso 
inapropriado de computadores de outras pessoas. O uso impróprio do computador varia 
34 
 
desde algo trivial (por exemplo, jogar jogos de computador nos computadores de 
empregados) até a algo mais sério (disseminação de vírus). 
 
Código de ética da ACM/IEEE 
 
A sociedade de profissionais dos EUA definiram um código de ética e de prática. 
Membros dessas organizações assinam o código de prática quando se filiam. 
O Código contêm 8 Princípios relacionados ao comportamento e decisões tomadas 
por profissionais de ES, incluindo praticantes, educadores, gerentes, supervisores e diretores, 
bem como estagiários e estudantes da profissão. 
 
Código de ética – Introdução 
 
Introdução 
A pequena versão do código resume as aspirações num nível alto de abstração; as 
cláusulas incluídas na versão completa dão exemplos e detalhes de como estas aspirações 
mudam a maneira que nós agimos como profissionais de ES. Sem as aspirações, os detalhes 
podem se transformar em algo tedioso; sem os detalhes, as aspirações podem se transformar 
em algo profundo, porém vazio; juntos, as aspirações e os detalhes formam um código coeso. 
Engenheiros de software irão executar a análise, especificação, projeto, 
desenvolvimento, testes e manutenções de software como uma profissão benéfica e 
respeitada. De acordo com seu compromisso com a saúde, segurança e bem estar do público, 
engenheiros de software irão aderir aos seguintes princípios: 
 
Código de ética – princípios 
 
1. PÚBLICO 
Engenheiros de Software irão atuar de acordo com o interesse público. 
2. CLIENTE AND EMPREGADO 
Engenheiros de Software irão atuar de acordo com os melhores interesses de seus 
clientes e empregados e consistentemente com o interesse público. 
3. PRODUTOS 
Engenheiros de Software irão assegurar que seus produtos e alterações associadas 
atendam, tanto quanto possível, os melhores padrões profissionais. 
4. JULGAMENTO 
Engenheiros de Software irá manter a integridade e independência no seu julgamento 
profissional. 
35 
 
5. GERENCIAMENTO 
Gerentes e líderes de ES irão se comprometer e promover uma abordagem ética para 
o gerenciamento do desenvolvimento e manutenção de software. 
6. PROFISSÃO 
Engenheiros de Software irão promover a integridade e reputação de profissionais 
consistentes com o interesse público. 
7. COLEGAS 
Engenheiros de software irão ser honestos e opiar seus colegas. 
8. PARA SI MESMOS 
Engenheiros de software irão se envolver, durante a sua vida, em aprender as práticas 
de sua profissão e promover abordagens éticas para a prática de sua profissão. 
 
Dilemas éticos 
 
Desacordo com os princípios políticos da gerência sênior. 
Empregados agem de forma não ética e liberaum sistema de segurança crítica sem 
finalizar os no sistema. 
Participação no desenvolvimento de sistemas de armas militares ou sistemas 
nucleares. 
 
Pontos chaves 
A ES é uma disciplina de engenharia preocupada com todos os aspectos da produção 
de software. 
Produtos de software consistem de programas desenvolvidos e documentações 
associadas. Os atributos essenciais desses produtos são: manutenibilidade, confiabilidade, 
eficiência e usabilidade. 
O processo de software consiste de atividades envolvidas no desenvolvimento de 
produtos de software. As atividades básicas são: especificação, desenvolvimento, validação 
e evolução de software. 
Métodos são formas organizadas de produzir produtos. 
Consistem de recomendações a serem seguidas, de notações a serem usadas, regras 
para descrições de sistemas que serão produzidos, e de diretrizes e guias de projeto. 
Ferramentas CASE são sistemas de software que são projetados para apoiar 
atividades rotineiras do processo de software, tal como edição de diagramas de projeto, 
validação 
da consistência de diagramas e rastreabilidade dos testes executados 
36 
 
Engenheiros de software possuem responsabilidades para com a profissão e 
sociedade. Eles não devem se concentrar exclusivamente em assuntos técnicos. 
As sociedades de profissionais publicaram o código de conduta que estabelece os 
padrões comportamentais esperados de seus membros. 
 
Engenharia de Sistemas 
 
Projetar, implementar, implantar, operar sistemas compostas por hardware, software 
e pessoas 
 
Objetivos 
Explicar por que sistemas de software são afetados por vários assuntos de engenharia 
de sistemas 
Introduzir conceitos de propriedades de sistemas emergentes, tais como confiabilidade 
e segurança 
Explicar por que os ambientes de sistemas devem ser considerados no processo de 
projeto de sistemas 
Explicar engenharia de sistemas e processos de aquisição de sistemas 
Tópicos cobertos 
Propriedades de sistemas emergentes 
Sistemas e seus ambientes 
Modelagem de sistema 
Processo de engenharia de sistemas 
Aquisição de sistemas 
 
O que é um sistema? 
Uma coleção intencional de componentes inter-relacionados que trabalham juntos 
para atingir algum objetivo comum. 
Um sistema pode conter software, hardware mecânicos, elétricos e eletrônicos e 
pessoas. 
Componentes de sistema dependem de outros componentes de sistema. 
Propriedades e comportamentos dos componentes de sistema são intricados e inter-
relacionados. 
 
Problemas da engenharia de sistemas 
Grandes sistemas são normalmente projetados para resolver graves problemas 
37 
 
A engenharia de sistemas necessita de uma incrível coordenação e disciplina devido 
a: 
Possibilidades quase infinitas para projetar componentes intercambiáveis 
Desconfiança mútua e falta de entendimento entre disciplinas de engenharia 
Sistemas devem ser projetados para durar muitos anos mesmo em ambientes que 
sofram mudanças 
Engenharia de Software e de sistemas 
A proporção de software nos sistemas está aumentando. 
Sistemas eletrônicos de propósito geral controlado por software está substituindo 
sistemas de propósitos específicos. 
Problemas da engenharia de sistemas são similares aos problemas da engenharia de 
software 
O software é (infelizmente) visto como um problema da engenharia de sistemas. 
Muitos projetos de grandes sistemas têm sofrido atrasos por causa dos problemas de 
software. 
 
Propriedades emergentes 
Propriedades do sistema como um todo ao invés de propriedades que podem ser 
derivadas de componentes do sistema. 
Propriedades emergentes são uma conseqüência do relacionamento entre 
componentes do sistema. 
Então eles podem somente ser estimados e medidos uma vez que os componentes 
tenham sido integrados ao sistema 
 
Exemplos de propriedades emergentes 
O peso total do sistema 
É um exemplo de uma propriedade emergente que pode ser computado a partir das 
propriedades individuais. 
Confiabilidade do sistema 
Depende da confiabilidade dos componentes do sistema e do relacionamento entre 
eles. 
Usabilidade de um sistema 
Essa é uma propriedade muito complexa, que não depende só do hardware e do 
software, mas também dos operadores do sistema e do ambiente em que ele é usado. 
 
Tipos de propriedades emergentes 
Propriedades funcionais 
38 
 
Elas aparecem quando todas as partes do sistema trabalham em conjunto para atingir 
algum objetivo. Por exemplo, uma bicicleta tem uma propriedade funcional de ser um 
dispositivo de transporte, uma vez que está montada com todos os seus componentes. 
Propriedades emergentes não funcionais 
Elas são confiabilidade, desempenho, segurança e proteção. Estão relacionadas ao 
comportamento do sistema em seu ambiente operacional. Muitas vezes, elas são críticos aos 
sistemas computacionais, uma vez que uma falha em atingir um nível mínimo definido nessas 
propriedades pode inutilizar o sistema. 
 
Confiabilidade de sistemas 
Devido a interdependência de componentes, falhas podem se propagar através do 
sistema 
As falhas do sistema ocorrem com freqüência devido aos inter-relacionamentos 
imprevistos entre componentes 
É provavelmente impossível antecipar todos os possíveis relacionamentos de 
componentes 
Medidas de confiabilidade de software podem dar uma falsa idéia de confiabilidade de 
sistema 
 
Influências sobre confiabilidade 
Confiabilidade de Hardware 
Qual é a probabilidade de um componente falhar e quanto tempo leva para reparar 
esse componente? 
Confiabilidade de Software 
Qual é a probabilidade de que um componente de software venha a produzir uma 
saída incorreta? Falhas de software normalmente são distintas das falhas de hardware, pois 
o software não se desgasta. 
Confiabilidade do Operador 
Qual é a probabilidade de que o operador de um sistema cometa um erro? 
 
Relacionamento de confiabilidade 
Falhas de hardware podem gerar falsos sinais, fora dos limites das entradas esperadas 
pelo software. 
Erros de software podem ativar alarmes, causando tensão no operador e induzi-lo a 
erros 
O ambiente no qual um sistema está instalado pode afetar sua confiabilidade 
 
39 
 
Propriedades que o sistema não deve exibir 
Propriedades tais como desempenho e confiabilidade podem ser medidas depois que 
o sistema estiver funcionando 
No entanto, algumas propriedades são propriedades que o sistema não deve exibir: 
Segurança – o sistema não deve comportar-se de forma insegura. 
Proteção – o sistema não deve permitir uso não autorizado 
Medir ou estimar essas propriedades é muito difícil 
 
Sistemas e seus ambientes 
Sistemas não são independentes, eles existem dentro de um ambiente 
Funções do sistema podem se alterar devido ao ambiente 
O ambiente afeta a funcionalidade do sistema, por exemplo, sistemas precisam de 
energia elétrica fornecida pelo ambiente 
Tanto o ambiente organizacional quanto o ambiente físico são importantes 
 
Hierarquias de sistemas 
 
Fatores humanos e organizacionais 
Mudanças no processo 
O sistema requer mudanças nos processos de trabalho, no ambiente? 
Mudanças nas tarefas 
Os sistemas diminuem a habilidade dos usuários em um ambiente ou fazem com que 
modifiquem o modo como eles trabalham? 
Mudanças organizacionais 
O sistema modifica a estrutura de poder político em uma organização? 
 
Modelando a arquitetura do sistema 
Um modelo arquitetural apresenta um visão abstrata de subsistemas compondo um 
sistema 
Muitos incluem fluxo de informações entre subsistemas 
Normalmente apresentados como um diagrama de blocos 
Podem identificar diferentes tipos de componentes funcionais no modelo 
 
Sistema de alarme contra intrusos 
 
Tipos de componentes no sistema de alarme 
Sensor 
40 
 
Sensor de movimento, sensor de porta 
Atuador 
Sirene 
Comunicação 
Discador de telefone 
Coordenação 
Controlador de alarme 
Interface 
Sintetizador de voz 
 
Arquitetura do sistema ATC 
 
Componentesfuncionais do sistema 
 
Componentes de Sensor 
Componentes de Atuador 
Componentes de Computação 
Componentes de Comunicação 
Componentes de Coordenação 
Componentes de Interface 
 
Componentes de Sistema 
Componentes de Sensor 
Informações coletadas do ambiente do sistema. Por exemplo, radar do sistema de 
controle de tráfego aéreo. 
Componentes de Atuador 
Provoca alguma mudança no ambiente do sistema. Por exemplo, válvulas num 
sistema de controle de processo que aumenta ou reduz o fluxo de materiais num cano 
Componentes de Computação 
Realizar alguma computação sobre uma entrada para produzir uma saída. Por 
exemplo, um processador de ponto flutuante num sistema computacional 
Componentes de Comunicação 
Permitem que componentes do sistema comuniquem-se uns com os outros: 
computadores distribuídos interligados em rede 
Componentes de Coordenação 
Coordena as interações de outros componentes do sistema: escalonador de sistema 
em tempo real 
41 
 
Componentes de Interface 
Facilitam as interações com outros componentes do sistema: interface com o operador 
Todos os componentes são normalmente controlados por software 
 
O processo de engenharia de sistemas 
Normalmente seguem o modelo “cascata” devido ao desenvolvimento paralelo de 
diferentes partes do sistema 
Pequenos escopos para interação entre fases devido as mudanças de hardware serem 
de alto custo. Software podem ter que compensar os problemas de hardware 
Envolvem, inevitavelmente, engenheiros de diferentes disciplinas que devem trabalhar 
juntos. 
Há muitos escopos de equívocos aqui. Diferentes disciplinas usam vocabulários 
diferentes e é necessária muita negociação. Engenheiros podem ter agendas pessoais para 
cumprir. 
 
O processo de engenharia de sistemas 
 
Envolvimento interdisciplinar 
 
Definição de requisitos do sistema 
Três tipos de requisitos definidos neste estágio 
Requisitos funcionais abstratos. Funções do sistema são definidos de forma abstrata 
Propriedades do sistema. São definidos os requisitos nãofuncionais do sistema 
Características indesejáveis. É especificado o comportamento inaceitável do sistema 
Deve-se também definir os objetivos gerais da organização para o sistema 
 
Objetivos do sistema 
Objetivos funcionais 
Fornecer um sistema de alarme contra incêndios e contra intrusos para um edifício, 
com o objetivo de divulgar avisos internos e externos referentes a incêndios ou à entrada de 
pessoas não autorizadas 
Objetivos organizacionais 
Assegurar que as funcionalidades normais executadas edifício não sejam seriamente 
perturbados por eventos tais como de incêndio e entrada não autorizada de pessoas 
 
Problemas de requisitos do sistema 
Alteração de como o sistema está sendo especificado 
42 
 
Necessidade de antecipar o desenvolvimento de hardware/comunicações durante o 
tempo de vida do sistema 
Dificuldade de definir requisitos não-funcionais (particularmente) sem uma visão da 
estrutura de componentes do sistema 
 
O processo de projeto de sistemas 
Agrupar requisitos 
Organizar requisitos em grupos relacionados 
Identificar subsistemas 
Identificar um conjunto de subsistemas que coletivamente possam atender os 
requisitos do sistema 
Atribuir requisitos aos subsistemas 
Introdução de problemas específicos quando COTS são integrados 
Especificar funcionalidade de subsistemas 
Definir interfaces de subsistemas 
Atividade crítica para o desenvolvimento paralelo de subsistemas 
 
O processo de projeto de sistemas 
 
 
Problemas de projeto de sistemas 
A divisão de requisitos entre hardware, software e componentes humanos pode 
envolver muita negociação 
Assume-se que dificuldades em resolver problemas de projeto são normalmente 
resolvidos por software 
Plataformas de hardware podem não ser apropriados para atender os requisitos de 
software tal que o software deve compensar isso 
 
Desenvolvimento de subsistemas 
Normalmente, projetos de hardware, software e comunicações são desenvolvidos em 
paralelo 
Muitos envolvem algumas aquisições de sistemas COTS (Commercial Off-the-Shelf) 
Falha de comunicação entre as equipes de implementação 
Mecanismos burocráticos e lentos para aprovar mudanças no sistema faz com que o 
cronograma de desenvolvimento seja estendido devido a necessidade de re-trabalho 
Integração de sistemas 
43 
 
É o processo de colocar, todos juntos, hardware, software e pessoas para compor o 
sistema 
Deve ser realizado incrementalmente tal que os subsistemas sejam integrados um de 
cada vez 
Problemas de interface entre subsistemas são normalmente encontrados neste 
estágio 
Podem existir problemas de incompatibilidade de versões entre componentes de 
sistema 
 
Instalação do sistema 
Suposições sobre o ambiente podem ser incorretas 
Podem existir resistência humana na introdução de um novo sistema 
O sistema pode precisar coexistir com sistemas alternativos por algum tempo 
Podem existir problemas de instalação física (por exemplo, problemas de cabeamento) 
Identificação da necessidade de treinamento de operadores 
 
Operação do sistema 
Irão surgir requisitos inesperados 
Usuários podem usar o sistema de maneira nãoprevista pelos projetistas do sistema 
Podem aparecer problemas de interação com outros sistemas 
Problemas físicos de incompatibilidade 
Problemas de conversão de dados 
Elevação da média de erros de operação devido a inconsistências de interface 
 
Evolução do sistema 
Grandes sistemas tem um longo tempo de vida. Eles evoluem para atender as 
mudanças de requisitos 
A evolução é cara 
Mudanças devem ser analisados sob a perspectiva técnica e de negócio 
A interação de subsistemas pode gerar problemas não previstos 
Raramente existe uma lógica para decisões legítimas de projeto 
A estrutura do sistema é corrompida pelas mudanças realizadas 
Sistemas existentes que devem ser mantidos são chamados de sistemas legados 
 
Desativação de sistemas 
Tirar o sistema de serviço após terminado o seu tempo de vida 
44 
 
Pode ser necessário a remoção de materiais (por exemplo, produtos químicos 
perigosos) que podem poluir o ambiente 
A desativação deve ser planejada durante o projeto do sistema 
Pode ser necessário que os dados sejam reestruturados e convertidos para que 
possam ser usados em outros sistemas 
 
Aquisição do sistema 
Aquisição de um sistema para atender as necessidades da organização 
Alguns projetos de especificação e de arquitetura de sistema normalmente necessitam 
ser adquiridos 
Você precisa de uma especificação para fechar um contrato de desenvolvimento do 
sistema 
A especificação deve permitir a compra de sistemas COTS (commercial off-the-shelf), 
quase sempre mais barato do que desenvolver um sistema a partir do zero. 
 
O processo de aquisição de sistemas 
 
Consequência da aquisição 
Requisitos podem ter que ser modificados para se adaptar às capacidades de 
componentes COTS 
A especificação de requisitos pode ser parte do contrato de desenvolvimento do 
sistema 
Existe, normalmente, um período de negociação para combinar mudanças após a 
seleção do contrato de construção do sistema 
 
Contratos e subcontratos 
A aquisição de grandes sistemas de hardware / software é normalmente baseado em 
alguns pontos principais do contrato 
Subcontratos são emitidos a outros fornecedores para fornecer partes do sistema 
Clientes possuem vínculo com o principal contratado e não negocia diretamente com 
os subcontratados 
Modelo Contratado / Subcontratado 
 
Pontos chaves 
A Engenharia de Sistemas inclui várias disciplinas 
Propriedades emergentes são propriedades que são características do sistema como 
um todo e não apenas de suas partes 
45 
 
Modelos arquiteturais mostram os principais subsistemas e suas interconexões, são 
normalmente descritos usando diagrama de blocos 
 
Pontos chaves 
Os tipos de componentes de sistemas são: sensor, atuador, computação, 
coordenação, comunicaçãoe interface 
O processo de engenharia de sistemas baseia-se, normalmente, no modelo “cascata” 
e possui as fases de especificação, projeto, desenvolvimento e integração 
A aquisição de sistemas está preocupada em decidir qual sistema comprar e quem irá 
pagar por ele 
 
Conclusão 
A engenharia de sistemas é difícil! Nunca existirá respostas fáceis para problemas 
complexos de desenvolvimento de sistemas 
Engenheiros de sistemas não tem todas as respostas, mas conhecem melhor a visão 
sistêmica 
Disciplinas precisam reconhecer outras forças ativamente, ao invés de relutantemente 
cooperar no processo de engenharia de sistemas 
 
Processo de Software 
 
Conjunto coerente de atividades para especificar, projetar, implementar e testar 
sistemas de software 
 
Objetivos 
Introduzir modelos de processos de software 
Descrever vários modelos diferentes e quando eles podem ser usados 
Descrever, em linhas gerais, os modelos de processos para a engenharia de 
requisitos, desenvolvimento de software, estes e evolução 
Introduzir tecnologias CASE de apoio às atividades do processo de software 
 
O processo de software 
Conjunto estruturado de atividades necessárias para desenvolver um sistema de 
software 
Especificação 
Projeto e implementação 
Validação 
46 
 
Evolução 
Um modelo de processo de software é uma representação abstrata de um processo. 
Ele apresenta uma descrição de um processo a partir de alguma perspectiva particular 
 
Modelos de processos genéricos de software 
O modelo “cascata” 
Fases separadas e distintas da especificação e desenvolvimento 
Desenvolvimento evolucionário 
Especificação e desenvolvimento estão entrelaçados 
Desenvolvimento formal de sistemas 
Um modelo matemático do sistema é formalmente transformado para uma 
implementação 
Desenvolvimento orientado a reuso 
O sistema é montado a partir de componentes existentes 
 
Modelo cascata 
 
Fases do modelo cascata 
Análise e definição de requisitos 
Projeto de sistemas e de software 
Implementação e teste de unidades 
Integração e teste de sistemas 
Operação e manutenção 
A desvantagem do modelo cascata é a dificuldade de acomodar mudanças depois que 
o processo está em andamento 
 
Problemas do modelo cascata 
 
Inflexibilidade de particionar o projeto nesses estágios distintos. Nunca conseguimos 
isso. 
Dificuldade de responder a mudanças de requisitos de clientes 
Assim, o modelo somente é apropriado quando os requisitos estiverem bem 
consolidados e entendidos. 
 
Desenvolvimento evolucionário 
 
Desenvolvimento exploratório – Tipo 1 
47 
 
O objetivo é trabalhar junto aos clientes e desenvolver um sistema final a partir de um 
esboço inicial da especificação. O desenvolvimento inicia com requisitos bem compreendidos 
Protótipos descartáveis – Tipo 2 
O objetivo é entender os requisitos do sistema. Pode-se iniciar o processo com 
requisitos pouco entendidos. 
 
Problemas 
O processo não é visível 
Os sistemas normalmente são mal-estruturados 
Podem ser exigidas ferramentas e técnicas especiais 
Aplicabilidade 
Sistemas interativos de tamanho pequeno ou médio 
Partes de um grande sistema (por exemplo, interface de usuário) 
Sistemas de vida curta 
 
Desenvolvimento formal de sistemas 
Baseado na transformação de uma especificação matemática através de diferentes 
representações para um programa executável 
As transformações preservam a exatidão, tal que é fácil mostrar que o programa 
encontra-se em conformidade com a especificação 
Incorporado na abordagem ‘Cleanroom’, que veremos no capítulo 19, para o 
desenvolvimento de software 
 
Transformações Formais 
Problemas 
Necessita de habilidades e treinamento especializado para aplicar a técnica 
Dificuldade de especificar formalmente alguns aspectos do sistema tais como interface 
do usuário 
Aplicabilidade 
Sistemas críticos especialmente aqueles onde um caso de segurança e a 
confiabilidade deve ser produzido antes que o sistema seja colocado em operação. 
 
Desenvolvimento orientado ao reuso 
Baseado no reuso sistemático onde os sistemas são integrados a partir de 
componentes existentes ou sistemas COTS (Commercial-off-shelf) 
Estágios do Processo 
Análise de componente 
48 
 
Modificação de requisitos 
Projeto de sistema com reuso 
Desenvolvimento e integração 
Esta abordagem está se tornando cada vez mais importante mas ainda conta com uma 
limitada experiência 
 
Interação do Processo 
Requisitos de sistema SEMPRE evoluem no curso de um projeto, assim a iteração do 
processo onde os primeiros estágios são retrabalhados é sempre parte do processo de 
grandes sistemas 
A iteração pode ser aplicada a qualquer dos modelos de processos genéricos 
Duas abordagens relacionadas 
Desenvolvimento incrementa 
Desenvolvimento espiral 
 
Desenvolvimento Incremental 
 
Ao invés de entregar o sistema de uma única vez, o desenvolvimento e liberação é 
dividido em incrementos, onde cada incremento libera parte da funcionalidade requerida 
Requisitos do usuário são priorizados e os requisitos de maior prioridade são incluídos 
nos incrementos iniciais 
Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são 
congelados apesar de, posteriormente, poder continuar a evoluir. 
 
Vantagens do desenvolvimento incremental 
Retorno de valor ao cliente a cada incremento liberado, pois funcionalidades são 
disponibilizadas desde o início 
Os incrementos iniciais atuam como protótipo, ajudando a elucidar requisitos para os 
próximos incrementos 
Baixo risco de falha geral do projeto 
Os serviços do sistema de maior prioridade tendem a receber mais testes 
 
Extreme programming (XP) 
 
Nova abordagem de desenvolvimento baseado no desenvolvimento e liberação de 
incrementos de funcionalidade muito pequenos 
49 
 
Contar com aprimoramento constante de código, envolvimento do usuário com a 
equipe de desenvolvimento e programação em pares 
 
Desenvolvimento Espiral 
 
O processo é representado como uma espiral ao invés de como uma seqüência de 
atividades com backtracking 
Cada loop na espiral representa uma fase do processo 
Nenhuma fase fixa, tais como especificação ou projeto – loops na espiral são 
escolhidos dependendo do que é requerido 
Riscos são explicitamente avaliados e resolvidos durante o processo 
 
Modelo espiral do processo de software 
 
Setores do modelo espiral 
Definição de objetivos 
São identificados os objetivos específicos da fase 
Avaliação e redução de riscos 
Riscos são avaliados e atividades executadas para reduzir os principais riscos 
Desenvolvimento e validação 
Um modelo de desenvolvimento do sistema é escolhido, o qual pode ser qualquer um 
dos modelos genéricos 
Planejamento 
O projeto é revisado e a próxima fase do espiral é planejada 
 
Especificação de Software 
 
O processo de estabelecer quais serviços são requeridos e as restrições sobre a 
operação e desenvolvimento do sistema 
Processo de engenharia de requisitos 
Estudo de viabilidade 
Elucidação e análise de requisitos 
Especificação de requisitos 
Validação de requisitos 
 
O processo de engenharia de requisitos 
 
50 
 
Implementação e projeto de software 
O processo de converter a especificação do sistema num sistema executável 
Projeto de software 
Projetar uma estrutura de software que realiza a especificação 
Implementação 
Traduzir esta estrutura num programa executável 
As atividades de projeto e implementação estão intimamente relacionadas e podem 
ser 
Sobrepostas 
 
Atividades do processo de projeto 
Projeto arquitetural 
Especificação abstrata 
Projeto de interface 
Projeto de componente 
Projeto da estrutura de dados 
Projeto de algoritmo 
 
Processo de projeto de software 
 
 
Métodos de projeto 
Abordagem sistemática para desenvolver um projeto de software 
O projeto é normalmente documentado como um conjunto de modelos gráficos 
Modelos possíveis 
Modelo