AULAS_-_Conteudo_Completo

Prévia do material em texto

ENGENHARIA DE SOFTWARE I 
FIGURA DISCIPLINA
1
Prof. Me. Liliane Balduino de Carvalho Coelho
lilianebcc.unip@gmail.com
FUNDAMENTOS DE ENGENHARIA DE 
SOFTWARE
2
CONCEITO DE SOFTWARE
3
• O que é Produto de Software?
Software é o conjunto de programas de computador,
procedimentos, documentação e dados associados que compõe
o software.
4
Muitas pessoas pensam que software é simplesmente outra
palavra para programas de computador. No entanto, quando
falamos de engenharia de software, não se trata apenas do
programa em si, mas de toda a documentação associada e
dados de configurações necessários para fazer esse programa
operar corretamente. (SOMMERVILLE, 2011, p. 17)
CONCEITO DE SOFTWARE
Ou seja, envolve todo o resto que esta envolvido na sua 
fabricação (requisitos, analise, documentação, prototipação, testes, 
manuais de sistema, manuais do usuário).
5
CONCEITO DE SOFTWARE
Para que fique mais fácil compreender o que realmente é software é importante
conhecer suas características, pois são essas que o torna, diferente de todas as outras
coisas que podem ser construídas.
E essas características são também relativamente diferentes das encontradas nos
hardwares.
6
CARACTERÍSTICAS DE SOFTWARE
1. O software é desenvolvido por um processo de Engenharia e não é fabricado no
sentido clássico.
(O que significa o sentido clássico da produção, seria imaginar uma linha de produção
de um produto qualquer, por exemplo de um CARRO, aonde em cada etapa, são
encaixados peças e o produto vai caminhando pela fábrica, até que tudo fique pronto e
passe por uma aprovação de qualidade.
SOFTWARE diferente disso não tem peças que vão sendo agregadas e não caminha por
uma linha de produção, sua fabricação independe de máquinas e depende muito mais
das pessoas e sua especialização no assunto, sua qualidade envolve outros indicadores
e seus problemas apesar de serem mais fácil de solucionar são de outras proporções).
7
CARACTERÍSTICAS DE SOFTWARE
2. O software não se desgasta
Para verificar que o software não se desgasta é interessante fazer uma análise da curva
de falhas entre o hardware e o software.
Curva de falhas 
do Hardware
O gráfico conhecido como o gráfico da banheira, representa a curva de
desgastes do hardware, notem que a quantidade de falha de um
hardware é muito grande no momento de sua criação podendo
acontecer o que chamamos de mortalidade infantil do hardware, depois
que essa taxa de erros se estabiliza ela permanece um tempo inalterada,
porém a medida que o tempo passa e os males ambientais (pó,
umidade, calor) vão ocorrendo as falhas do hardware voltam a ocorrer e
o mesmo tem então um índice de desgaste grande e precisa ser retirado
de uso.
8
CARACTERÍSTICAS DE SOFTWARE
Curvas de falha do Software
Curva IDEAL
A curva ideal do software, seria uma curva que começaria
com grandes quantidades de falhas, pois o software estaria
no seu surgimento, portanto, conteria muitos acertos e
ajustes, e correções de bug e depois essa curva iria se
achatando e não mais subiria ficando assim o software em
pleno uso. Porém essa curva não é ideal ela contém vários
picos aonde os erros aumentam e diminuem, é conhecida
como curva dentada, isso ocorre porque a cada alteração
que é solicitada no software o mesmo sofre alterações e é
passível de novos defeitos, nem sempre essa curva de erros
chega a se estabilizar e novas demandas são necessárias,
fazendo com o que o software não se desgaste mas sim se
deteriore com o tempo. Curva NÃO IDEAL
9
CARACTERÍSTICAS DE SOFTWARE
Curvas de falha do Software
Curva IDEAL
A curva ideal do software, seria uma curva que começaria com
grandes quantidades de falhas, pois o software estaria no seu
surgimento, portanto, conteria muitos acertos e ajustes, e
correções de bug e depois essa curva iria se achatando e não
mais subiria ficando assim o software em pleno uso. Porém
essa curva não é ideal ela contém vários picos aonde os erros
aumentam e diminuem, é conhecida como curva dentada, isso
ocorre porque a cada alteração que é solicitada no software o
mesmo sofre alterações e é passível de novos defeitos, nem
sempre essa curva de erros chega a se estabilizar e novas
demandas são necessárias, fazendo com o que o software não
se desgaste mas sim se deteriore com o tempo.
10
INTRODUÇÃO
Contexto Histórico do software
• Nos anos 40, quando se iniciou a evolução dos sistemas computadorizados, grande
parte dos esforços, e consequentes custos, era concentrada no desenvolvimento do
hardware, em razão, principalmente das limitações e dificuldades encontradas na
época.
• À medida que a tecnologia de hardware foi sendo dominada, as preocupações se
voltaram, no início dos anos 50, para o desenvolvimento dos sistemas operacionais,
onde surgiram então as primeiras realizações destes sistemas, assim como das
chamadas linguagens de programação de alto nível, como FORTRAN e COBOL, e dos
respectivos compiladores.
11
Contexto Histórico do software
• A tendência da época foi de poupar cada vez mais o usuário de um computador de
conhecer profundamente as questões relacionadas ao funcionamento interno da
máquina, permitindo que este pudesse concentrar seus esforços na resolução dos
problemas computacionais em lugar de preocupar-se com os problemas relacionados ao
funcionamento do hardware.
• Já no início dos anos 60, com o surgimento dos sistemas operacionais com
características de multiprogramação, a eficiência e utilidade dos sistemas
computacionais tiveram um considerável crescimento, para o que contribuíram
também, de forma bastante significativa, as constantes quedas de preço do hardware.
Em um sistema de multiprogramação temos frequentemente a
situação onde vários processos estão prontos para serem executados.
O sistema operacional deve decidir qual processo deve ser executado
primeiro.
12
Contexto Histórico do software
• Uma consequência deste crescimento foi a necessidade, cada vez
maior, de desenvolver grandes sistemas de software em
substituição aos pequenos programas aplicativos utilizados até
então.
• Desta necessidade, surgiu um problema nada trivial devido à falta de
experiência e à não adequação dos métodos de desenvolvimento
existentes para pequenos programas, o que foi caracterizado, ainda
na década de 60 como a "crise do software", mas que, por outro
lado, permitiu o nascimento do termo "Engenharia de Software".
13
Contexto Histórico do software
• 1970 – 1980: Período visto como o surgimento do software, foi visto
pela sociedade e pelos pensadores da época como uma nova revolução
industrial, outros pensadores disseram que essa era a terceira onda de
mudanças da história humana.
-Transformação de uma sociedade industrial em uma sociedade da
informação.
- A informação e o conhecimento como centro do poder.
14
Contexto Histórico do software
• 1990: Houve o que os pensadores descreveram como a mudança do
poder, agora com os computadores houve uma democratização do
conhecimento (antigamente o conhecimento estava restrito a um núcleo
de pessoas que se mantinham no poder , principalmente a economia
militar).
• - Surgiram uma série de livros anti-computadores, que enfatizavam
diversas preocupações, mas não colocavam os benefícios.
• - Veio na segunda metade dos anos 90 a ascensão e a ressureição dos
programadores.
15
Contexto Histórico do software
• 2000: Comentários a respeito da bomba relógio - O Bug do Milênio,
aonde todos os autores escreveram sobre a parada de todos os
sistemas, o fim do mundo, baseado em sistemas.
• 2001 até dias atuais: A indústria do software tornou-se e vem se
afirmando como o fator dominante na economia do mundo
industrializado.
16
Até aqui 18/08
A CRISE DO SOFTWARE
17
18
O que foi a Crise do Software e o início da Engenharia de Software?
A Crise do software foi um termo que surgiu nos
fim dos anos 60.
O termo expressava as dificuldades do
desenvolvimento de software frente ao rápido
crescimento da demanda por software, da
complexidade dos problemas a serem
resolvidos e da inexistênciade técnicas
estabelecidas para o desenvolvimento de
sistemas que funcionassem adequadamente ou
pudessem ser validados.
19
A “crise do software” foi um termo cunhado para descrever as dificuldades
enfrentadas no desenvolvimento de software no fim da década de 60. A
complexidade dos problemas, a ausência de técnicas bem estabelecidas e a
crescente demanda por novas aplicações começavam a se tornar um problema
sério.
Foi nessa época, mais precisamente em 1968, que ocorreu a Conferência da
OTAN sobre Engenharia de Software (NATO Software Engineering Conference)
em Garmisch, Alemanha. O principal objetivo dessa reunião era estabelecer
práticas mais maduras para o processo de desenvolvimento, por essa razão o
encontro é considerado hoje como o nascimento da disciplina de Engenharia
de Software.
Crise do Software
20
Duas décadas depois, em 1986, Alfred Spector, presidente da Transarc
Corporation, foi coautor de um artigo comparando a construção de
pontes ao desenvolvimento de software. Sua premissa era de que as
pontes normalmente eram construídas no tempo planejado, no
orçamento, e nunca caiam.
Na contramão, os softwares nunca ficavam prontos dentro do prazo e do 
orçamento, e, além disso, quase sempre apresentavam problemas.
Crise do Software
21
No Início dos anos 70, quando vivia-se a terceira era do software,
houveram muitos problemas de prazo e custo no
desenvolvimento de software, devido a baixa produtividade,
baixa qualidade e difícil manutenção do software.
Crise do Software
Grande parte dos projetos continuam com
estes problemas ainda na atualidade, assim
pode-se dizer que a crise continua vigente.
22
Os principais problemas apontados por Dijkstra (1971) eram:
• Estimativas de prazo e de custo imprecisas.
• Produtividade das pessoas da área de software não acompanha a
demanda.
• Projetos que estouram o cronograma e/ou orçamento.
• Não atendimento dos requisitos do usuário.
• Produtos não gerenciáveis, difíceis de manter e evoluir. A facilidade de
manutenção não era enfatizada como um critério importante, gerando
assim custos de manutenção elevados.
Crise do Software
23
Solução para a crise do software
• Utilização de técnicas, ferramentas e processos sistematizados
para produzir software.
• Treinamento e educação em conjunto com a mudança de
paradigma sobre o que é desenvolver software e como
deveria ser feito.
• Criação da Engenharia de Software.
Crise do Software
24
A criação da Engenharia de Software surgiu numa tentativa de contornar a crise do
software e dar um tratamento de engenharia(mais sistemático e controlado) ao
desenvolvimento de sistemas de software complexos.
Crise do Software
O termo Engenharia de Software tornou-se conhecido após uma conferência em 1968,
quando as dificuldades e armadilhas de projetar sistemas complexos foram discutidas
francamente.
A busca de soluções começou. Ela se concentrou em melhores metodologias e
ferramentas. As mais importantes foram as linguagens de programação que refletem
os estilos procedimental, modular e, em seguida, orientado à objeto.
25
A engenharia de software está
intimamente ligada ao aparecimento e
aperfeiçoamento desses estilos.
Também importantes foram os esforços
de sistematização, automatização da
documentação do programa e testes.
Crise do Software
A Engenharia de Software se concentra nos aspectos práticos da produção de um
sistema de software, enquanto a ciência da computação estuda os fundamentos teóricos
dos aspectos computacionais.
26
Considerando o que foi apresentado até aqui, já foi possível
compreender que o termo software descreve algo um pouco mais
completo e complexo do que um “simples” programa de computador,
bem como deixa claro que, a concepção de um software pode não ser
algo tão simples, obviamente isso irá depender da natureza para a
qual o mesmo está sendo ou foi projetado.
A Engenharia de Software é responsável por coordenar 
os processos de identificação das necessidades do 
cliente, planejamento, análise, desenvolvimento, 
entrega e evolução do software.
Relevância da Engenharia de Software
27
Definição de Engenharia de Software
Os problemas apontados nas seções anteriores não serão, é claro, resolvidos da noite
para o dia, mas reconhecer a existência dos problemas e defini-los da forma mais
precisa e eficaz são, sem dúvida, um primeiro passo para a sua solução.
Figura - Componentes do software
28
• Em primeiro lugar, é preciso estar ciente também de que não existe uma
abordagem mágica que seja a melhor para a solução destes problemas,
mas uma combinação de métodos que sejam abrangentes a todas as
etapas do desenvolvimento de um software.
• Além disto, é importante e desejável que estes métodos sejam
suportados por um conjunto de ferramentas que permita automatizar
o desenrolar destas etapas, juntamente com uma definição clara de
critérios de qualidade e produtividade de software.
São estes aspectos que caracterizam de maneira mais influente a disciplina 
de Engenharia de Software.
29
É uma disciplina de engenharia que se preocupa com
todos os aspectos de produção de software
(SOMMERVILLE, 2011, p. 4).
Esta disciplina descreve como proceder com a análise,
projeto, documentação, desenvolvimento, validação,
implantação e evolução do software, obviamente não
existe uma receita de bolo genérica que se aplica a todo e
qualquer escopo de projeto de software, mas sim um
conjunto de regras, instruções e práticas que norteiam o
desenvolvimento destes.
O que é Engenharia de software
30
Primeiramente, deve-se ter em mente que os processos de
Engenharia de Software são diferentes, dependendo do tipo de
software que se vai desenvolver.
[…] dependendo do nível de conhecimento ou estabilidade dos
requisitos, deve-se optar por um ou outro ciclo de vida, o qual
será́ mais adequado ao tipo de desenvolvimento que se vai
encontrar. WAZLAWICK (2013, p. 4)
31
Na literatura, pode-se encontrar diversas definições da Engenharia de
Software:
"O estabelecimento e uso de sólidos princípios de engenharia para que se
possa obter economicamente um software que seja confiável e que
funcione eficientemente em máquinas reais" [NAU 69].
“A aplicação prática do conhecimento científico para o projeto e a
construção de programas computacionais e a documentação necessária
à sua operação e manutenção.” [Boehm, 76]
32
“Abordagem sistemática para o desenvolvimento, a
operação e a manutenção de software” [Afnor, 83]
“Conjunto de métodos, técnicas e ferramentas necessárias à
produção de software de qualidade para todas as etapas
do ciclo de vida do produto.” [Krakowiak, 85]
33
É importante observar que, ainda que várias definições tenham sido
atribuídas a Engenharia de Software, todas convergem para o fato de que
esta disciplina possui uma importância significativa para o
desenvolvimento de um SOFTWARE PROFISSIONAL.
Tenha em mente que o uso da expressão “software profissional”, neste
contexto, pode ser entendido como software projetado para ser utilizado
por terceiros, sendo ele comercializado ou não, ou seja, em sua essencial
primária, à Engenharia de Software pode ser vista como complicador ou
emprego de esforço desnecessário quando aplicada ao software projetado
para o uso pessoal daquele que o desenvolve.
34
A engenharia de software tem por OBJETIVO apoiar o desenvolvimento
profissional de software, mais do que a programação individual. Ela inclui
técnicas que apoiam especificação, projeto e evolução de programas, que
normalmente não são relevantes para o desenvolvimento de software
pessoal. (SOMMERVILLE, 2011, p. 3)
Segundo Sommerville (2011, p. 29) a Engenharia de Software pode ser vista
como um processo evolutivo, “no qual o software é constantemente
alterado durante seu período de vida em resposta às mudanças de
requisitos e às necessidades do cliente”.
Objetivo da Engenharia de Software
35
De modo mais objetivo, pode-se dizer que a Engenharia de Software
busca prover a tecnologia necessária para produzir software de alta
QUALIDADE a um BAIXOCUSTO. Os dois fatores motivadores são
essencialmente a qualidade e o custo.
A qualidade de um produto de software é um parâmetro cuja
quantificação não é trivial, apesar dos esforços desenvolvidos nesta
direção. Por outro lado, o fator custo pode ser facilmente quantificado
desde que os procedimentos de contabilidade tenham sido
corretamente efetuados.
36
EXERCÍCIOS
Em 1968 aconteceu a NATO Software Engineering Conference, um
evento criado com o objetivo de discutir alternativas para contornar a
Crise do Software. Podemos resumir à crise no desenvolvimento de
software causada por alguns problemas com exceção de:
A) Projetos estourando o prazo.
B) Software de baixa qualidade.
C) Projetos atendendo o orçamento.
D) Software muitas vezes não atendendo os requisitos.
E) Projetos não gerenciáveis e código difícil de manter.
37
EXERCÍCIOS
Assinale a alternativa que melhor explica a frase " O software não se desgasta, ele se
deteriora".
A) Significa que o software não tem falhas.
B)Significa que o software não sofre falhas, mas problemas relacionados ao tempo e
ambiente.
C) Significa que o software não sobre desgastes ambientais (tempo, poeira), mas ao
longo da sua vida sofre diversas alterações por causa das falhas e manutenções
ficando obsoletos ou deteriorados.
D) Significa que o software não sobre desgastes de manutenções ao longo da sua
vida entretanto sofre problemas ambientais e temporais tornando-se obsoletos ou
deteriorados.
E) NDA
38
Aqui 25.08
39
Para determinar quais métodos e técnicas serão utilizadas no
desenvolvimento de um software, é necessário primeiramente
determinar de que tipo ele será. Segundo Sommerville (2011) alguns
dos possíveis tipos de aplicativos são:
Tipos de Software
1. Aplicações stand-alone. Essas são as
aplicações executadas em um computador
local, como um PC. Elas contêm toda a
funcionalidade necessária e não precisam estar
conectadas a uma rede. Exemplos de tais
aplicações são aplicativos de escritório em um
PC, software de manipulação de fotos etc.
40
2. Aplicações interativas baseadas em transações.
São aplicações que executam em um computador remoto, acessadas
pelos usuários a partir de seus computadores ou terminais.
Certamente, aqui são incluídas aplicações Web como aplicações de
comércio eletrônico em que você̂ pode interagir com o sistema
remoto para comprar produtos ou serviços.
Essa classe de aplicações também inclui sistemas corporativos, em
que uma empresa fornece acesso a seus sistemas através de um
navegador Web ou um programa cliente especial e serviços
baseados em nuvem, como é o caso de serviços de e-mail e
compartilhamento de fotos. Aplicações interativas frequentemente
incorporam um grande armazenamento de dados, que é acessado e
atualizado em cada transação.
Tipos de Software
41
3. Sistemas de controle embutidos. São
sistemas de controle que controlam e
gerenciam dispositivos de hardware.
Numericamente, é provável que haja mais
sistemas embutidos do que de qualquer outro
tipo. Exemplos de sistemas embutidos
incluem software em telefone celular,
softwares que controlam antitravamento de
freios em um carro e software em um micro-
ondas para controlar o processo de
cozimento.
Tipos de Software
42
4. Sistemas de processamento de lotes. São sistemas
corporativos projetados para processar dados em
grandes lotes. Eles processam grande número de
entradas individuais para criar as saídas
correspondentes.
Exemplos de sistemas de lotes incluem sistemas
periódicos de cobrança, como sistemas de cobrança
telefônica, e sistemas de pagamentos de salário.
Tipos de Software
43
5. Sistemas de entretenimento. São sistemas cuja
utilização principal é pessoal e cujo objetivo é entreter o
usuário. A maioria desses sistemas é de jogos de
diferentes tipos. A qualidade de interação com o
usuário é a característica particular mais importante dos
sistemas de entretenimento.
Tipos de Software
44
6. Sistemas de coleta de dados. São sistemas que coletam dados de
seu ambiente com um conjunto de sensores e enviam esses dados
para outros sistemas para processamento. O software precisa
interagir com sensores e frequentemente é instalado em um
ambiente hostil, por exemplo, dentro de uma máquina ou em um
lugar remoto.
7. Sistemas de sistemas. São sistemas compostos de uma série de
outros sistemas de software. Alguns deles podem ser produtos
genéricos de software, como um programa de planilha eletrônica.
Outros sistemas do conjunto podem ser escritos especialmente para
esse ambiente. (Sommerville, 2011, p. 7, grifo do autor)
Tipos de Software
45
Mitos do software
A principal consequência dos mitos é que eles causam confusão e
propagam informações erradas. A referência [PRE97] cita alguns mitos
relacionados ao software os quais listamos a seguir:
• Mitos gerenciais
• Mitos do cliente
• Mitos dos desenvolvedores
46
Os gerentes estão sobre pressão constante
para manter o orçamento, para cumprir
cronogramas e para melhorar a qualidade.
Para aliviar esta pressão alguns (mesmo
temporariamente) se agarram aos mitos.
• MITOS GERENCIAIS:
47
Mito: Tem-se livros de primeira qualidade com padrões e procedimentos.
Realidade: eles são necessários, mas não suficientes.
Mito: Tem-se ferramentas moderníssimas e de primeira qualidade para desenvolvimento,
associadas a computadores e instalações de primeira linha.
Realidade: Estas ferramentas têm utilização eficaz, eficiente e adequada?
Mito: Quando se está atrasado, pode-se contratar mais profissionais e recuperar-se do
atraso.
Realidade: Pessoas novas precisam se integrar a equipe existente, precisam aprender.
Isto pode atrasar ainda mais o projeto.
• MITOS GERENCIAIS:
48
Mito: Objetivos gerais são suficientes para se iniciar um projeto.
Realidade: Esta é a maior causa de falhas em projetos. É essencial a descrição formal e
detalhada do domínio da informação, das funções, do desempenho, das interfaces, das
restrições de projeto e dos critérios de validação. Comunicação desenvolvedor X usuário
é vital.
Mito: Requisitos do usuário mudam continuamente, mas estas mudanças podem ser
acomodadas facilmente pois o software é flexível.
Realidade: O impacto destas mudanças varia no tempo ao longo do projeto. O custo
pode ir de uma vez (mudanças ocorridas na definição de requisitos do usuário) a cem
vezes (mudanças ocorridas após a liberação do software).
• MITOS DO CLIENTE
49
• MITOS DOS DESENVOLVEDORES
Estes mitos são fomentados por décadas de "programação". Eles são difíceis de serem
eliminados.
Mito: O trabalho termina quando o programa funciona.
Realidade: Entre 50 e 70% de todo esforço investido num software é gasto na sua
manutenção.
Mito: A qualidade só pode ser avaliada após o programa estar operando.
Realidade: Uma das técnicas mais efetivas para avaliar e garantir qualidade é aplicada na
fase de projeto: Revisões Técnicas Formais (Elas são filtros para detectar certos tipos de
erros).
Mito: O único considerável para o sucesso de um projeto é o programa.
Realidade: Ele é apenas uma parte da configuração de software que inclui programas,
documentos e dados. Documentação é fundamental para as tarefas de manutenção.
50
O que é Processo de Software ?
É um conjunto de tarefas requeridas
para construir um software de
qualidade.
O PROCESSO DE SOFTWARE
Existem vários processos de desenvolvimento de software diferentes, mas todos
envolvem:
✓ especificação – definição do quê o sistema deve fazer;
✓ projeto e implementação – definição da organização do sistema e implementação do
sistema;
✓ validação – checagem de que o sistema faz o que o cliente deseja;
✓ evolução – evolução em resposta a mudanças nas necessidades do cliente.
• Um modelo de processo de desenvolvimento de software é uma representação abstrata
de um processo. Ele apresenta uma descrição do processo de uma perspectiva em
particular.
51
52
O Processo
O processo de desenvolvimento de software é a
estrutura das tarefas que são requeridas para
construir software de altaqualidade.
A engenharia de software foca a qualidade,
utilizando processos, métodos e ferramentas.
Uma das definições para engenharia de software
foi proposta na referência [NAU69], estando
traduzida a seguir:
[Engenharia de software é] o estabelecimento e utilização 
de saudáveis princípios de engenharia a fim de obter 
economicamente software que seja confiável e rode 
eficientemente em máquinas reais.
53
• Se o processo de desenvolvimento de um produto é ruim, sem dúvida
o produto obtido é ruim. No entanto não se deve focar apenas no
processo. O produto é também importante.
• O software deve ser analisado tanto do ponto de vista de processo
como de produto. O desenvolvedor de software deve sentir
satisfação tanto na execução do processo de desenvolvimento como
no exame produto final obtido.
PRODUTO X PROCESSO 
54
Processos x Produto
O processo utilizado no desenvolvimento de
um projeto tem grande reflexo na produtividade e
na qualidade do software desenvolvido.
Os estudos sobre qualidade, mais recentemente, são
voltados para o melhoramento do processo de
desenvolvimento de software, pois ao garantir a
qualidade do processo, já se está dando um grande
passo para garantir também a qualidade do produto.
QUALIDADE DE PRODUTO DE SOFTWARE
55
Exercícios, problemas e trabalhos
1. Os mitos da área de software estão pouco a pouco enfraquecendo.
No entanto outros estão tomando seu lugar. Tente encontrar pelo
menos um mito novo em qualquer uma das categorias.
2. Procure na internet pelo menos duas "definições" para o termo
"Engenharia de Software".
3. O que é mais importante: o produto ou o processo?
4. Explique, utilizando suas próprias palavras, a diferença que existe
entre software e hardware quanto ao desenvolvimento e produto final
56
Até aqui 01.09.2020
PROBLEMAS COM PRAZO, CUSTO E 
QUALIDADE DO SOFTWARE 
57
58
É importante verificar que as tarefas de ORÇAMENTO do projeto, CRONOGRAMA do
projeto e planejamento da QUALIDADE do projeto, são tarefas que devem ser
realizadas para TODOS os projetos em questão e as mesmas devem ser realizadas pelos
seus GERENTES DE PROJETOS.
O gerenciamento de projeto de software é uma parte essencial da engenharia de
software. Um bom gerenciamento não pode garantir o sucesso do projeto, no entanto,
um mau gerenciamento geralmente resulta em falhas do projeto: o software é
entregue com atraso, custa mais do que foi estimado originalmente e falha ao atender
os requisitos mínimos do cliente.
GERENTE DE PROJETOS
O gerente de projetos é quem garante que o projeto
será concluído e os objetivos, alcançados. O gerente do
projeto é quem define: objetivo geral do projeto,
objetivos individuais, cronograma de atividades,
responsabilidades e recursos. Sua principal atribuição é
evitar que as falhas inerentes aos processos
aconteçam.
GERENTE DE PROJETOS
A gestão de projetos é uma profissão do presente e do futuro, adotada
largamente em diversas áreas.
59
60
✓ Os gerentes de softwares são responsáveis pelo
desenvolvimento de planos, cronogramas e estimativa
de custos do projeto.
✓ Eles supervisionam o trabalho para garantir que ele
esteja sendo realizado dentro dos padrões exigidos, e
monitoram o progresso para verificar se o
desenvolvimento está no prazo e dentro do orçamento.
✓ O gerenciamento de projeto é necessário, pois a
engenharia de software está sempre sujeita às
restrições de orçamento e de cronograma da
organização.
GERENTE DE PROJETOS
✓ As organizações precisam de profissionais qualificados
na gestão de projetos para alcançar o sucesso
pretendido.
✓ Um gerente de projetos é um profissional no campo de
gerência de projetos que tem a responsabilidade de
planejar e controlar a execução de projetos em
diversas áreas de atuação, como a construção civil,
arquitetura e desenvolvimento de software, entre
outras.
GERENTE DE PROJETOS
61
62
GERENTE DE PROJETOS
Os gerentes de projetos fazem o mesmo trabalho que gerentes de outra
engenharias, no entanto, a engenharia de software é diferente das outras
engenharias de uma série de maneiras. Algumas das diferenças são:
· O produto é intangível: Ou seja, o software é intangível, não pode ser visto ou
tocado, os gerentes de projeto de software não podem ver seu progresso. Eles
contam e devem confiar em outras pessoas para produzir a documentação
necessária para examinar o progresso.
· Não existe processo padrão em software: O processo de software varia
drasticamente de uma empresa para outra, não existe um padrão na sua
construção, uma linha de produção como produtos manufaturados.
· Projetos de software de grande porte são geralmente projetos “únicos”: Esses
projetos de alguma forma são sempre diferentes dos anteriores, portanto, mesmo
gerentes experientes podem considerar difícil prever problemas.
63
GERENTE DE PROJETOS
Atividades do Gerenciamento - RESUMO
A maioria dos gerentes assume a responsabilidade por algumas ou todas das
seguintes tarefas:
· Elaboração de proposta
· Planejamento e Desenvolvimento do cronograma do projeto
· Custo do projeto
· Monitoração e revisão do projeto
· Seleção e avaliação de pessoal
· Elaboração de relatórios e apresentações.
64
GERENTE DE PROJETOS
65
Planejamento de Projeto
O gerenciamento eficiente de um projeto de software depende de um
planejamento minucioso do progresso do projeto. Os gerentes devem prever
problemas que podem ocorrer e preparar soluções experimentais para esses
problemas. Um plano elaborado no início de um projeto deve ser usado como guia.
Esse plano inicial deve ser o melhor possível em face das informações disponíveis. Ele
deve evoluir à medida que o projeto progride e melhores informações se tornem
disponíveis.
O planejamento é um processo interativo, apenas concluído quando o projeto
é concluído. À medida que as informações se tornam disponíveis durante o projeto, o
plano deve ser regularmente revisado. As metas da empresa constituem um
importante fator que deve ser considerado na formulação do plano do projeto. À
medida que essas metas mudam, as metas do projeto também mudam e, portanto,
são necessárias mudanças no plano de projeto.
66
No inicio do processo de planejamento deve ser avaliado as restrições que afetam o
projeto. Junto com isso deve ser estimado os parâmetros do projeto, como sua
estrutura, tamanho e distribuição de funções.
Planejamento de Projeto
No inicio do processo de planejamento deve-se usar o
Guia de Boas Práticas - PMBOK
67
✓ É um Guia de boas práticas em Gerenciamento de Projetos. Possui um somatório de
conhecimentos relativos à Gerência de Projetos.
✓ Foi desenvolvido pelo PMI (Project Management Institute), visando a pesquisa,
sistematização e divulgação dos conceitos relativos à administração de Projetos.
✓ Este conjunto completo de conhecimentos inclui práticas tradicionais que são
amplamente utilizadas nas mais diversas organizações e em qualquer ramo de
atividade.
✓As práticas estão organizadas em dez áreas de conhecimento e de gestão. São elas:
Integração, Escopo, Custos, Cronograma, Qualidade, Recursos, Comunicações, Riscos,
Aquisições e Partes Interessadas.
✓Adota as melhores práticas de gerência de projetos consolidadas de mercado.
PMBOK
ÁREAS DE CONHECIMENTO DO PMBOK 6ª EDIÇÃO
68
69
As maiorias dos Planos devem incluir as seguintes seções:
Introdução: Descreve brevemente os objetivos do projeto e estabelece as restrições que afetam
o gerenciamento do projeto.
Organização do projeto: Descreve o modo como a equipe de desenvolvimento está organizada,
as pessoas envolvidas e seus papéis na equipe.
Análise de riscos: Descreve os possíveis riscos do projeto, e as estratégias adotadas se os
mesmos ocorrerem.
Requisitos de recursos de hardware e software: Especifica os recursos necessários para o
desenvolvimento.
Estrutura analítica: Especifica a estrutura analítica de um projeto
Cronograma do projeto: Apresenta as dependências entre as atividades, o prazo estimado
necessário para atingir cada marco e a alocação de pessoas nas atividades.Mecanismo de monitoração e relatório: Definem os relatórios de gerenciamento que devem
ser produzido, quando devem ser produzidos e o mecanismo de monitoração utilizado.
Planejamento de Projeto
O QUE É UM PROJETO?
Segundo a NBR 10006 (2008), norma brasileira que documenta as
diretrizes para qualidade em gerenciamento de projetos, o projeto é um
[...] processo único, consistindo de um grupo de atividades coordenadas e
controladas com datas para início e término, empreendido para alcance de
um objetivo conforme requisitos específicos, incluindo limitações de tempo,
custo e recursos.
Para o PMI (2017), o projeto é um “esforço temporário que tem a finalidade de criar
um produto/serviço único”.
Segundo Kerzner (2001) projeto é um empreendimento com um objetivo bem
definido, que consome recursos e opera sob pressões de prazo, custos e qualidade.
70
O QUE É UM PROJETO?
Então aquela viagem que farei pode se tornar um projeto?
A resposta é “sim”.
❖ Tem todos requisitos para ser organizado em um grupo de
atividades controladas por prazos;
❖ Tem um objetivo único;
❖ Envolve orçamento financeiro;
❖ Depende de planejamento prévio;
71
72
CARACTERÍSTICAS DE PROJETO
✓ É temporário;
o Um projeto apresenta um esquema de tempo específico, ou uma vida finita (ou
seja, ele não pode ser um processo que não tem fim);
o Tem uma data de início e uma data na qual o objetivo deve ser alcançado.
✓ Objetivo é definido em termos de Escopo (trabalho a ser realizado), Cronograma
(tempo) e Custo;
✓ Espera-se que o escopo do trabalho seja atingido com qualidade e que traga a
satisfação do cliente.
✓ É um esforço específico e único (não pode ser realizado da mesma forma duas vezes,
por mais que um projeto se pareça com outro, nenhum projeto é idêntico);
73
CARACTERÍSTICAS DE PROJETO
✓ Um projeto de desenvolvimento de um software ou construção de uma casa é
único pelo grau de customização que exigem;
✓ Um projeto faz uso de recursos para realizar tarefa;
✓ Existem vários tipos de recursos: pessoas, organizações, equipamentos, material,
etc;
✓ Um projeto tem um cliente (sponsor – patrocinador), é a pessoa quer fornece os
recursos necessários para realizar o projeto;
✓ Projetos envolvem certo grau de incerteza.
74
Área de CRONOGRAMA
✓ É o conjunto de processos necessários para garantir
que o projeto seja entregue no prazo. Afinal, o
cronograma traz uma visão geral das atividades e das
relações entre elas, além de mostrar os prazos das
atividades e o prazo final do projeto.
✓ Esta área é responsável por estimar recursos e duração
e sequenciar as atividades do projeto. Nela, define-se o
cronograma do projeto a partir do escalonamento das
atividades e suas precedências.
Tempo é um recurso precioso e não renovável, e a
maioria das pessoas gostaria de ter mais tempo para suas
atividades, que frequentemente exigem mais tempo do
que o estimado.
75
Área de CRONOGRAMA
✓ Os processos do gerenciamento do tempo são:
o Planejar o de gerenciamento do cronograma;
o Definir as atividades;
o Sequenciar as atividades;
o Estimar os recursos;
o Estimar a duração;
o Desenvolver o cronograma;
o Controlar o cronograma.
Os processos do gerenciamento do tempo são utilizados para garantir que o andamento das atividades
esteja de acordo com o cronograma e que a entrega do projeto ocorra no prazo comprometido.
76
Custo do Projeto
Existem três parâmetros envolvidos no cálculo do custo total de um projeto de software:
• Custo de hardware e software, incluindo a manutenção
• Custo de viagens e treinamentos
• Custo de esforços
Os custos de uma empresa são os gastos ligados diretamente à produção ou à
atividade-fim de uma organização, como por exemplo: compra de matéria-prima,
pagamento de salários, contas de energia, entre outros. Já as despesas podem ser
consideradas gastos relacionados à manutenção do negócio.
77
Custo do Projeto
O custo mais representativo nos projetos são os custos dos esforços, pois os custos dos
esforços não são apenas salários dos engenheiros de software que estão envolvidos no
projeto. As organizações calculam os custos dos esforços em termos indiretos nos quais
são considerados o custo total de operação da organização, e este é dividido pelo número
de pessoal produtivo. Portanto os seguintes custos são parte do custo total de esforços:
• Custo de subsistência, aquecimento e iluminação no espaço de escritório
• Custo de pessoal de apoio como contadores, administradores, gerentes de sistemas,
faxineiros e técnicos.
• Custo de operações de rede de comunicações
• Custo de instalações centrais, como de biblioteca ou recreação
• Custo de seguridade social e benefícios dos empregados, como pensões e seguros
78
Área de CUSTOS
✓ O principal objetivo é fornecer uma estimativa preliminar do custo total do projeto, já no seu
início. Assim, é possível assegurar que o projeto terá todo o recurso financeiro necessário para a
realização do empreendimento.
✓ Além disso, nessa área também é possível planejar as formas de como os recursos financeiros
serão utilizados ao longo do cronograma do projeto, podendo controlá-los e gerenciá-los da
melhor maneira possível, certificando-se de que o projeto seja finalizado conforme o orçamento
definido.
79
Área de CUSTOS
✓ Os processos do gerenciamento de custo são:
o Planejar o de gerenciamento de custo;
o Estimar os custos;
o Determinar o orçamento;
o Controlar os custos.
80
Uma vez que o projeto esteja em andamento, os gerentes de
projetos devem atualizar regularmente suas estimativas de custo.
Isso ajuda no processo de planejamento e uso eficiente de recursos.
Se as despesas reais são significantemente maiores do que as
estimadas, o gerente de projeto deve tomar alguma providência. Isso
pode envolver a aplicação de recursos adicionais para o projeto ou a
modificação do trabalho a ser realizado.
Área de CUSTOS
81
QUALIDADE - Implantação e Melhoria de Processos de Software
O mercado de software tem evoluído exponencialmente por conta da popularização
dos computadores e dispositivos móveis, fato este, que deriva da globalização e da
necessidade de uma economia mais competitiva, onde se busca um diferencial
estratégico, ocasionando uma necessidade de processos que objetivem a qualidade
dos produtos de software.
82
Existem diversas definições para o que vem a ser qualidade algumas das mais
importantes são:
• Termo subjetivo com significados diferentes para pessoas e contextos diferentes.
• Conjunto de Propriedades de um produto ou serviço, que lhe oferecem aptidões
para satisfazer as necessidades explicitas ou implícitas (ISO 8402, 1994).
• Grau com que o conjunto de propriedades inerentes ao produto satisfaz os
requisitos. (ISO 2000)
Definições de Qualidade
83
A qualidade de software tem se aprimorado significativamente nos últimos 15 anos.
Uma razão para isso é o fato de as empresas terem adotado novas técnicas e
tecnologias, como o uso do desenvolvimento orientado a objeto e de ferramentas de
apoio CASE, e também teve uma crescente conscientização da importância da
qualidade de software.
Bons gerentes de qualidade têm por objetivo desenvolver uma cultura de qualidade
na qual todos os responsáveis por desenvolvimento de produto estão comprometidos
em atingir um alto nível de qualidade de produto. Eles encorajam as equipes a
assumirem a responsabilidade pela qualidade de seu trabalho, e a desenvolverem
novas abordagens para aprimoramento da qualidade.
Área de QUALIDADE
84
Área de QUALIDADE
• O gerenciamento de qualidade formalizada é particularmente importante para as
equipes que estão desenvolvendo sistemas amplos e complexos. A
documentação de qualidade é um registro do que tem sido feito por cada grupo
no projeto. Isso ajuda as pessoas a verificarem se tarefas importantes não foram
esquecidas ou se uma parte da equipe não fez suposições incorretas sobre o que
outras equipes fizeram.
• A documentação de qualidade é também um meio de comunicação ao longo da
existência de um sistema.
• Para sistemas menores,a gerência de qualidade é ainda importante, mas a
mesma pode ser adotada de uma maneira mais informal.
• No desenvolvimento de software a qualidade de projeto abrange os requisitos,
as especificações e o projeto do sistema.
85
Área de QUALIDADE
Satisfação do usuário = produto adequado (ESCOPO)+ máxima qualidade + entrega
no prazo dentro do orçamento (CUSTO).
86
Área de QUALIDADE
Tem por objetivo estabelecer as normas de
qualidade e garantir que os padrões
estabelecidos sejam seguidos.
✓O gerenciamento da qualidade, por sua vez, é responsável por garantir que o projeto
satisfaça os objetivos e funções para os quais ele foi realizado. Normas e padrões de
qualidade são costumeiramente definidos nos processos dessa área, buscando sempre
a melhoria contínua.
✓Pode-se ressaltar que o ciclo PDCA é a base da melhoria da qualidade. Sendo assim, é
comum a realização de auditorias de qualidade, impedindo que um produto que não
atenda às normas e padrões preestabelecidos seja aprovado.
87
Área de QUALIDADE
✓ Os processos do gerenciamento da qualidade de acordo com PMBOK são:
o Planejar gerenciamento da qualidade;
o Realizar a garantia da qualidade;
o Controlar a qualidade.
88
Área de QUALIDADE
Além disso, para a qualidade de um projeto existem três tarefas de suma
importância:
• Controle de Qualidade
• Garantia da Qualidade
• Custo da Qualidade
89
Área de QUALIDADE
• Controle de Qualidade
O controle da variação pode ser equiparado ao controle da qualidade. O controle da
qualidade envolve a série de inspeções, revisões e testes usada ao longo do processo de
software para garantir que cada produto de trabalho satisfaça os requisitos para ele
estabelecidos.
Um conceito chave do controle de qualidade é que todos os produtos de trabalho têm
especificações mensuráveis e definidas com as quais nós podemos comparar os resultados de
cada processo.
• Garantia da Qualidade
Garantia da qualidade consiste em um conjunto de funções para auditar e relatar que
avaliar a efetividade e completeza das atividades de controle de qualidade. A meta da garantia
da qualidade é fornecer a gerência os dados necessários para que fique informada sobre a
qualidade do produto, ganhando assim compreensão e confiança de que a qualidade do produto
está satisfazendo as suas metas.
90
Área de QUALIDADE
Custo da Qualidade
O custo da qualidade inclui todos os custos decorrentes da busca da qualidade ou da
execução das atividades relacionadas à qualidade. Estudos de custo de qualidade
são conduzidos para obter um referencial para o custo de qualidade. Esse custo de
qualidade pode ser dividido em custos associados com a prevenção, com a avaliação
e com as falhas.
• Os custos de prevenção incluem planejamento da qualidade, revisões técnicas
formais, equipamentos de teste e treinamentos.
• Os custos de avaliação incluem atividades para obter entendimento da condição
do produto na primeira execução de cada projeto.
• Os custos de falhas são aqueles que desapareciam se nenhum defeito aparecesse
antes de se entregar um produto ao cliente.
91
Área de QUALIDADE
Custo da Qualidade
Os custos de falhas podem ser subdivididos em custos de falhas internas e custo de
falhas externas.
• Sendo o custo de falhas internas aqueles que ocorrem quando detectamos um
defeito no nosso produto antes do embarque. Os custos de falhas internas incluem
refazer, reparar e analisar o modo como a falha ocorreu.
• O custo de falha externa é associado com os defeitos encontrados depois que o
produto já esta com o cliente, geralmente são os mais caros.
•
92
Qualidade do Produto
A qualidade do produto de software deverá garantir algumas
características para que esse seja considerado realmente um
produto de qualidade.
Essas características serão apresentadas no próximo slide:
93
94
Até aqui 08.09.2020
95
Área de QUALIDADE
Modelos de Qualidade de Software
De maneira mais resumida vamos conhecer alguns modelos de qualidade:
• CMMI
• MPSBr
• ISO
96
Área de QUALIDADE
CMMI
✓ Antes de surgir o modelo CMMI, surgiu o modelo SW – CMM (Capability Maturity Model
for software) é um modelo de capacitação de processos que foi patrocinado pelo
departamento de defesa dos EUA, para avaliação da capacidade dos seus fornecedores
de software. O CMM baseou-se em algumas ideias importantes do movimento de
qualidade industrial.
✓ Com o sucesso do SW-CMM, outros modelos foram sendo criados , o P-CMM(People CMM
para recursos humanos), o SA-CMM (para aquisição de software) e o SE-CMM para
engenharia de sistemas, com o surgimento de todas essas vertentes de modelos começou
a ser causada uma certa confusão de quando usar um e outro, para isso foi criado então o
CMMI que integrou todos esses e pode ser aplicado para a empresa como um todo.
✓ O objetivo do CMMI é servir de guia para melhoria de processos na organização e também
na habilidade dos profissionais em gerenciar o desenvolvimento, a aquisição e
manutenção de produtos e serviços.
✓ O CMMI um pouco diferente do seu originário SW-CMM, pode ser abordado por níveis ou
então em melhoria contínua, atuando com níveis de capacidade.
97
Área de QUALIDADE
Os níveis do CMMI são:
• Inicial – Ad hoc (processos imprevisível e sem controle)
• Nível Gerenciado – Processos disciplinados
• Nível Definido – Processos consistentes padronizados
• Nível gerenciado Quantitativamente – Processos medidos e
controlados
• Nível Otimizado – Processos melhorados continuamente.
98
Área de QUALIDADE
MPSBr
• O MPSBr foi criado por pesquisadores brasileiros para melhoria de processos de
desenvolvimento de softwares em empresas brasileiras.
• O MPS.BR, Melhoria do Processo de Software Brasileiro, é um programa da Softex com
apoio do Ministério da Ciência, Tecnologia, Inovações e Comunicações (MCTIC). Com
inicio em dezembro de 2003, o programa tem como objetivo melhorar a capacidade de
desenvolvimento de software, serviços e as práticas de gestão de RH na indústria de
TIC.
• O MPSBr atende à necessidade de implantar os princípios de engenharia de software
de forma adequada ao contexto das empresas brasileiras, seguindo as principais
abordagens internacionais para definição, avaliação e melhoria de software.
• A definição desse processo baseia-se em três guias: Guia Geral, Guia de aquisição e
Guia de Avaliação.
99
Área de QUALIDADE
O MPSBr assim como o CMMI também define níveis de maturidade, porém esses
níveis são sete compreendidos de A a G sendo:
A – Em otimização
B – Gerenciado Quantitativamente
C – Definido
D – Largamente Definido
E - Parcialmente Definido
F – Gerenciado
G – Parcialmente Gerenciado
100
Área de QUALIDADE
ISO
As normas ISO 9000 é uma referência em sistemas de qualidade, tendo
influência em diversas outras normas e metodologias.
A ISO 9000 tornou-se sinônimo de preocupação com qualidade em todo o
mundo, a sigla é conhecida por consumidores dos mais diversos produtos e funciona
muitas vezes como um apelo de marketing muito eficiente. A série teve origem na
norma britânica BS570, baseada em padrões militares ainda mais antigos.
A ISO 9000 é, na realidade, uma família de normas e tem um caráter genérico.
Serve aos propósitos de qualquer organização, em qualquer ramo de atividade, que
queria realizar o controle de qualidade dos produtos ou serviços oferecidos.
101
Área de QUALIDADE
ISO
A norma ISO/IEC 15504 guarda estreita relação com o modelo CMMI. Essa norma
apresenta estrutura para a realização de avaliações de processos em organizações,
pode ser aplicada em situações como:
• Uma empresa que busca melhorias internas;
• Avaliação de terceiros ao realizarem contratos de prestação de serviços ou
fornecimento de produtos.
102
Com qual custo do projeto os Gerentes mais precisam se preocupar?
A) Custos com Ambientes.
B) Custo com os servidores.
C) Custos com o maquinário necessário.
D) Custo com os recursos e tudo que envolve mantê-los.
E) Custo com o café.
EXERCÍCIOS
103
EXERCÍCIOS
Do que depende um gerenciamento eficiente do Projeto?
A) Deum bom cronograma, para apenas fazer o controle dos recursos e
desenvolvimento.
B) Da monitoração e revisões constante do escopo do projeto.
C) Seleção e avaliação do pessoal.
D) Elaboração de Relatórios e Apresentações em Power Point.
E) Depende de um planejamento minucioso do progresso do projeto, esse
planejamento só termina com o projeto concluído.
104
EXERCÍCIOS
Qual das alternativas citam 3 modelos conhecidos de qualidade.
A) MEC, SEI, SERASA
B) MPSBr, ANFAVIA, TSP
C) CMMI, MPSBr, ISO
D) INFRAERO, NBT, AE
E) CM, QPM, GR
105
EXERCÍCIOS
Com relação à qualidade de software o desenvolvimento do projeto abrange quais
itens:
A) Custo de hardware e software, incluindo a manutenção.
B) Gerenciamento e desenvolvimento.
C) Gerenciamento e controle.
D) Custo e garantia.
E) Requisitos, as especificações e o projeto do sistema.
ETAPAS DE PROCESSO DE PESSOAL E DE 
EQUIPE (PSP/TSP)
106
107
Modelos de Processo Pessoal e de Equipe
O melhor processo de software é aquele que se aproxima do pessoal que fará o serviço.
✓ Personal Software Process (PSP) é um processo de desenvolvimento de software
projetado para ser utilizado por engenheiros de software para a elaboração de
projetos individuais. O PSP foi desenvolvido por Watts Humphrey e está descrito no
seu livro "A Discipline for Software Engineering" (Uma disciplina para Engenharia de
Software) de 1995. O PSP foi desenvolvido para orientar o planejamento e
desenvolvimento de módulos de software ou pequenos programas, mas pode ser
adaptado para outras tarefas pessoais.
✓ Sendo um subconjunto do CMM (Capability Maturity Model), o PSP tem como
filosofia a revisão contínua em cada estágio do ciclo de desenvolvimento. Enquanto o
CMM é focado na melhoria da capacidade organizacional, o foco do PSP é o
engenheiro individual.
108
Os objetivos principais do PSP são:
✓ Melhorar a estimativa de prazo e esforço para o desenvolvimento de um módulo de
software ou programa;
✓ Melhorar o planejamento e o acompanhamento de cronogramas;
✓ Evitar o excesso de compromissos;
✓ Criar um comprometimento pessoal com a qualidade e com a melhoria contínua do
processo;
109
O modelo PSP define cinco atividades: planejamento, projeto de alto nível, revisão do
projeto de alto nível, desenvolvimento e pós-conclusão.
✓ Planejamento: Essa atividade, isola os requisitos e, com base neles, desenvolve
estimativas tanto de tamanho quanto de recurso. Toda métrica é registrada em
planilhas e gabaritos. Finalmente, as tarefas de desenvolvimento são identificadas e
um cronograma de projeto é criado.
✓ Projeto de alto nível: São desenvolvidas especificações externas para cada
componente a ser construído e é criado um projeto dos componentes, Protótipos são
construídos quando existe incerteza. Todos os itens são registrados e monitorados.
✓ Revisão do Projeto de alto nível: Métodos de verificação formal são aplicados para
descobrir erros no projeto.
✓ Desenvolvimento: O projeto em nível de componentes é refinado e revisado. O
código é, revisado, compilado e testado.
✓ Pós- conclusão: Usando as medidas e as métricas coletadas, a efetividade do processo
é determinada.
110
✓ O PSP enfatiza a necessidade de cada engenheiro de software identificar logo os
erros, e igualmente importante, entender os tipos de erros que ele tende a fazer. Isso
é conseguido por meio de uma atividade de avaliação rigorosa desenvolvida em todos
os produtos de trabalho produzidos pelo Engenheiro de Software.
✓ O PSP representa uma abordagem disciplinada, baseada na métrica, da engenharia de
software que pode levar a um choque de cultura em muitos profissionais, quando o
mesmo é usado pela engenharia de software o aperfeiçoamento resultante na
produtividade e qualidade é significativo.
Naturalmente, a melhoria da capacidade de organização do indivíduo 
favorece a melhoria da capacidade organizacional como um todo.
111
TSP (Team Software Process – Processo de Equipe de Software)
Como muitos projetos de software de nível industrial são desenvolvidos por uma equipe
de profissionais, Watts Humphrey estendeu as lições aprendidas com a introdução do
PSP e propôs o TSP. O objetivo do TSP é construir uma equipe de projeto “autodirigida”
que se organize para produzir um software de alta qualidade.
Para isso foi definido os seguintes objetivos:
✓ Construir equipes autodirigidas que planejem e monitorem seu trabalho, estabelecem
metas, e possuam seus próprios processos e planos;
✓ Mostrar aos gerentes como acompanhar e motivar suas equipes, e como ajudá-las a
manter seu desempenho de pico;
✓ Acelerar o aperfeiçoamento do processo de software tornando o comportamento de
nível 5 do CMMI normal e esperado;
✓ Facilitar o ensino as habilidades de equipe de nível industrial.
112
✓ O TSP define as seguintes atividades: lançamento, projeto de alto nível,
implementação, integração e teste, pós-conclusão.
✓ Essas atividades permitem que a equipe planeje, projete e construa softwares de
modo disciplinado e, ao mesmo tempo, meça quantitativamente o processo e o
produto. A pós-conclusão prepara o cenário para aperfeiçoamento do processo.
✓ O TSP usa uma grande variedade de documentos, formulários e normas que servem
para guiar os membros da equipe em seus trabalhos.
✓ O TSP reconhece que as melhores equipes de software são as autodirigidas. Os
membros da equipe estabelecem objetivos do projeto, adaptam o processo para
satisfazer às suas necessidades, têm controle sobre o cronograma e, por meio de
medições e analise da métrica coletada, trabalham continuamente para melhorar a
abordagem da equipe do ponto de vista da Engenharia de software.
113
O TSP é uma abordagem rigorosa de Engenharia e fornece
benefícios distintos e quantificáveis em produtividade e qualidade.
A equipe deve estabelecer um total comprometimento com o
processo e deve passar por treinamentos para garantir que a
abordagem seja propriamente aplicada.
114
EXERCÍCIOS:
José desenvolve pequenos softwares para uma empresa de seu bairro, ele queria medir
melhor a qualidade do seu próprio trabalho, ele sabe que é bem disciplinado para fazer
isso. Qual modelo ele deve usar para realizar essa medição?
A) PSP
B) TST
C) PMP
D) TQP
E) PSS
115
EXERCÍCIOS:
Em uma empresa que desenvolve sistemas de grande porte, o gerente decidiu pedir para
que cada um se auto avaliasse e além disso decidiu aplicar o conceito de equipes
autodirigidas para melhorar a qualidade do software que a equipe produz. Quais os
modelos de processo aplicado?
A) PSP, TTP
B) PSP e TSP
C) PTP, TSP
D) TSP e PPP
E) Espiral, PSP
116
EXERCÍCIOS:
O PSP (Personal Software Process – Processo Pessoal de Software) enfatiza a medição
pessoal tanto do produto do trabalho que é produzido quanto da qualidade resultante do
produto do trabalho.O modelo PSP define cinco atividades que são:
A) Planejamento, monitoramento, metas, processos e planos
B) Planejamento, projeto de alto nível, revisão do projeto de alto nível, desenvolvimento
e pós-conclusão;
C) Análise, requisitos, desenvolvimento, teste e implantação;
D) Análise, projeto de alto nível, metas, processos e implantação;
E) Planejamento, levantamento, desenvolvimento, teste e pós-conclusão
ENTENDENDO COMO OS PROCESSOS 
SÃO EXECUTADOS....
117
118
Fluxo de processo
O chamado fluxo de processo — descreve como são organizadas as atividades
metodológicas, bem como as ações e tarefas que ocorrem dentro de cada atividade
em relação à sequência e ao tempo.
Um fluxo de processo linear executa cada uma das cinco atividades metodológicas
em sequência, começando com a de comunicação e culminando com a entrega
(Figura a).
119
Fluxo de processo
Um fluxo de processo iterativo repete uma ou mais das atividades antes
de prosseguir para a seguinte (Figura b).
120
Fluxo de processo
Um fluxo de processo evolucionário executa as atividades de uma forma “circular”.
Cada volta pelas cinco atividades conduz a uma versão mais completa do software
(Figura c).
121
Fluxo de processo
Um fluxode processo paralelo (Figura d) executa uma ou mais atividades em paralelo com outras
atividades (por exemplo, a modelagem para um aspecto do software poderia ser executada em
paralelo com a construção de um outro aspecto do software).
122
Abordagem de Camadas Engenharia de Software 
Esta abordagem é a reunião de metodologias, métodos, ferramentas, procedimentos e 
princípios a serem utilizados durante o processo de produção de software (percepção do 
software, implantação e manutenção) com intuito de obter produtos de alta qualidade.
abrange um conjunto de três elementos fundamentais: 
Métodos, Ferramentas e Procedimentos (Processo)
Principais metas: melhorar a qualidade de produtos de software, 
aumentar a produtividade do pessoal técnico e aumentar a satisfação do 
cliente. Ou seja, FOCO NA QUALIDADE!
123
Métodos: proporcionam os detalhes de como fazer para
construir o software.
Os métodos da engenharia de software fornecem as
informações técnicas para desenvolver software. Os métodos
envolvem uma ampla gama de tarefas, que incluem:
comunicação, análise de requisitos, modelagem de projeto,
construção de programa, testes e suporte.
Engenharia de Software 
124
 Planejamento e estimativa de projeto
 Análise de requisitos de software e de sistemas
 Projeto da estrutura de dados
 Algoritmo de processamento
 Codificação
 Teste
Manutenção
Engenharia de Software 
Métodos
125
Ferramentas: As ferramentas da engenharia de software
fornecem suporte automatizado ou semiautomatizado para o
processo e para os métodos.
Quando as ferramentas são integradas, de modo que as
informações criadas por uma ferramenta possam ser usadas
por outra, é estabelecido um sistema para o suporte ao
desenvolvimento de software, denominado engenharia de
software com o auxílio do computador. (CASE - Computer
Aided Software Engineering )
Engenharia de Software 
126
Procedimentos (Processos): constituem o elo de ligação
entre os métodos e ferramentas.
 sequência em que os métodos serão aplicados
 produtos que se exige que sejam entregues
 controles que ajudam assegurar a qualidade e coordenar as
alterações
 marcos de referência que possibilitam administrar o progresso
do software.
Engenharia de Software 
127
Procedimentos (Processos):
✓ No contexto da engenharia de software, um
processo não é uma prescrição rígida de como
desenvolver um software. Ao contrário, é uma
abordagem adaptável que possibilita às pessoas (a
equipe de software) realizar o trabalho de selecionar
e escolher o conjunto apropriado de ações e tarefas.
✓ A intenção é a de sempre entregar software
dentro do prazo e com qualidade suficiente para
satisfazer àqueles que patrocinaram sua criação e
àqueles que irão utilizá-lo.
Engenharia de Software 
128
Até aqui 15.09.2020
129
A essência da solução de problemas e, consequentemente, a essência da
prática da engenharia de software:
➢1. Compreender o problema (comunicação e análise).
➢2. Planejar uma solução (modelagem e projeto de software).
➢3. Executar o plano (geração de código).
➢4. Examinar o resultado para ter precisão (testes e garantia da
qualidade).
Engenharia de Software 
130
1 . Compreenda o problema. Algumas vezes é difícil de admitir, porém, a maioria de
nós é arrogante quando nos é apresentado um problema. Ouvimos por alguns segundos
e então pensamos: “Ah, sim, estou entendendo, vamos começar a resolver este
problema”. Infelizmente, compreender nem sempre é assim tão fácil. Vale a pena
despender um pouco de tempo respondendo a algumas questões simples:
• Quem tem interesse na solução do problema? Ou seja, quem são os interessados?
• Quais são as incógnitas? Que dados, funções e recursos são necessários para resolver
apropriadamente o problema?
• O problema pode ser compartimentalizado? É possível representá-lo em problemas
menores que talvez sejam mais fáceis de ser compreendidos?
• O problema pode ser representado graficamente? É possível criar um modelo
analítico?
Engenharia de Software 
131
2 . Planeje a solução. Faça um pequeno projeto e indaque:
• Você já viu problemas similares anteriormente? Existem padrões que são reconhecíveis
em uma potencial solução? Existe algum software que implemente os dados, as funções
e características necessárias?
• Algum problema similar já foi resolvido? Em caso positivo, existem elementos da
solução que podem ser reutilizados?
• É possível definir subproblemas? Em caso positivo, existem soluções aparentes e
imediatas para eles?
• É possível representar uma solução de maneira que conduza a uma implementação
efetiva? É possível criar um modelo de projeto?
Engenharia de Software 
132
3. Execute/leve adiante o plano. O projeto elaborado que já foi criado
serve como um mapa para o sistema que se quer construir. Podem surgir
desvios inesperados e é possível que se descubra um caminho ainda melhor
à medida que se prossiga, porém, o “planejamento” nos permitirá que
continuemos sem nos perder.
• A solução se adéqua ao plano? O código-fonte pode ser atribuído ao
modelo de projeto?
• Cada uma das partes componentes da solução está provavelmente
correta? O projeto e o código foram revistos, ou, melhor ainda, provas da
correção foram aplicadas ao algoritmo?
Engenharia de Software 
133
4.Examine o resultado. Não se pode ter certeza de que uma solução
seja perfeita, porém, pode-se assegurar que um número de testes
suficiente tenha sido realizado para revelar o maior número de erros
possível.
• É possível testar cada parte componente da solução? Foi implementada
uma estratégia de testes razoável?
• A solução produz resultados que se adéquam aos dados, às funções e
características necessários? O software foi validado em relação a todas as
solicitações dos interessados?
Engenharia de Software 
134
135
MODELOS DE DESENVOLVIMENTO DE 
SOFTWARE – CICLO DE VIDA
136
137
Modelos de Ciclo de Vida ou Modelos de Processo
• Um modelo de ciclo de vida ou modelo de processo pode ser visto como uma
representação abstrata de um esqueleto de processo, incluindo tipicamente
algumas atividades principais, a ordem de precedência entre elas e, opcionalmente,
artefatos requeridos e produzidos.
• De maneira geral, um modelo de processo descreve uma filosofia de organização de
atividades, estruturando as atividades do processo em fases e definindo como
essas fases estão relacionadas. Entretanto, ele não descreve um curso de ações
preciso, recursos, procedimentos e restrições. Ou seja, ele é um importante ponto de
partida para definir como o projeto deve ser conduzido, mas a sua adoção não é o
suficiente para guiar e controlar um projeto de software na prática.
138
Modelos de Ciclo de Vida ou Modelos de Processo
Ainda que os processos tenham de ser definidos caso a caso, de maneira geral, o ciclo de
vida de um software envolve, pelo menos, as seguintes fases:
• Planejamento: O objetivo do planejamento de projeto é fornecer uma estrutura que
possibilite ao gerente fazer estimativas razoáveis de recursos, custos e prazos. Uma vez
estabelecido o escopo de software, com os requisitos esboçados, uma proposta de
desenvolvimento deve ser elaborada, isto é, um plano de projeto deve ser elaborado
configurando o processo a ser utilizado no desenvolvimento de software.
À medida que o projeto progride, o planejamento deve ser detalhado e atualizado
regularmente. Pelo menos ao final de cada uma das fases do desenvolvimento (análise e
especificação de requisitos, projeto, implementação e testes), o planejamento como um
todo deve ser revisto e o planejamento da etapa seguinte deve ser detalhado. O
planejamento e o acompanhamento do progresso fazem parte do processo de gerência
de projeto.
139
Modelos de Ciclo de Vida ou Modelos de Processo
• Análise e Especificação de Requisitos: Nesta fase, o processo de levantamento de
requisitos é intensificado. O escopo deve ser refinado e os requisitos mais bem
definidos. Para entender a natureza do software a ser construído, o engenheiro de
softwaretem de compreender o domínio do problema, bem como a funcionalidade e o
comportamento esperados.
Uma vez capturados os requisitos do sistema a ser desenvolvido, estes devem ser
modelados, avaliados e documentados. Uma parte vital desta fase é a construção de um
modelo descrevendo o que o software tem de fazer (e não como fazê-lo).
140
Modelos de Ciclo de Vida ou Modelos de Processo
• Projeto: Esta fase é responsável por incorporar requisitos tecnológicos aos
requisitos essenciais do sistema, modelados na fase anterior e, portanto, requer
que a plataforma de implementação seja conhecida. Basicamente, envolve duas
grandes etapas: projeto da arquitetura do sistema e projeto detalhado. O objetivo
da primeira etapa é definir a arquitetura geral do software, tendo por base o
modelo construído na fase de análise de requisitos. Essa arquitetura deve
descrever a estrutura de nível mais alto da aplicação e identificar seus principais
componentes.
O propósito do projeto detalhado é detalhar o projeto do software para cada
componente identificado na etapa anterior. Os componentes de software devem
ser sucessivamente refinados em níveis maiores de detalhamento, até que
possam ser codificados e testados.
141
Modelos de Ciclo de Vida ou Modelos de Processo
• Implementação: O projeto deve ser traduzido para uma forma passível de
execução pela máquina. A fase de implementação realiza esta tarefa, isto é, cada
unidade de software do projeto detalhado é implementada.
• Testes: inclui diversos níveis de testes, a saber, teste de unidade, teste de
integração e teste de sistema. Inicialmente, cada unidade de software
implementada deve ser testada e os resultados documentados. A seguir, os
diversos componentes devem ser integrados sucessivamente até se obter o
sistema. Finalmente, o sistema como um todo deve ser testado.
142
Modelos de Ciclo de Vida ou Modelos de Processo
• Entrega e Implantação: uma vez testado, o software deve ser colocado em produção.
Para tal, contudo, é necessário treinar os usuários, configurar o ambiente de produção
e, muitas vezes, converter bases de dados. O propósito desta fase é estabelecer que o
software satisfaz os requisitos dos usuários. Isto é feito instalando o software e
conduzindo testes de aceitação. Quando o software tiver demonstrado prover as
capacidades requeridas, ele pode ser aceito e a operação iniciada.
• Operação: nesta fase, o software é utilizado pelos usuários no ambiente de
produção.
143
Modelos de Ciclo de Vida ou Modelos de Processo
• Manutenção: seguramente, o software sofrerá mudanças após ter sido entregue
para o usuário. Alterações ocorrerão porque erros foram encontrados, porque o
software precisa ser adaptado para acomodar mudanças em seu ambiente externo,
ou porque o cliente necessita de funcionalidade adicional ou aumento de
desempenho.
Muitas vezes, dependendo do tipo e porte da manutenção necessária, essa fase pode
requerer a definição de um novo processo, onde cada uma das fases precedentes é
reaplicada no contexto de um software existente ao invés de um novo.
144
Modelos de Ciclo de Vida ou Modelos de Processo
Os modelos de processo, de maneira geral, contemplam as fases Análise e
Especificação de Requisitos, Projeto, Implementação, Testes e Entrega e Implantação.
A escolha de um modelo de processo é fortemente dependente das características do
projeto. Assim, é importante conhecer alguns modelos de ciclo de vida e em que
situações são aplicáveis.
Os modelos visam definir como as etapas relativas ao desenvolvimento do software
serão conduzidas e interrelacionadas para atingir o objetivo do desenvolvimento que é a
obtenção de um produto de software de alta qualidade a um custo relativamente baixo.
Os principais modelos de ciclo de vida podem ser agrupados em três categorias
principais: modelos sequenciais, modelos incrementais e modelos evolutivos.
Para escolha de um Ciclo de Vida de Software leva-se em
conta:
natureza do projeto e da aplicação
métodos e ferramentas a serem usados
controles e produtos que precisam ser entregues
145
Alguns ciclos de vida mais conhecidos são:
 Modelo Sequencial ou Clássico – Cascata
Cascata V
 Modelo Incremental
 Modelos Evolucionários
Prototipação 
Modelo Espiral 
MODELOS DE DESENVOLVIMENTO 
146
Ciclo de Vida Sequencial
Como o nome indica, os modelos sequenciais organizam o
processo em uma sequência linear de fases. O principal modelo
desta categoria é o modelo em cascata, a partir do qual diversos
outros modelos foram propostos, inclusive a maioria dos
modelos incrementais e evolutivos.
147
Ciclo de Vida Clássico (Cascata)
 Cada fase envolve a elaboração de um ou mais documentos, que devem
ser aprovados antes de se iniciar a fase seguinte. Assim, uma fase só
deve ser iniciada após a conclusão daquela que a precede. Uma vez que,
na prática, essas fases se sobrepõem de alguma forma, geralmente,
permite-se um retorno à fase anterior para a correção de erros
encontrados. A entrega do sistema completo ocorre em um único
marco, ao final da fase de Entrega e Implantação.
 O uso de revisões ao fim de cada fase permite o envolvimento do
usuário. Além disso, cada fase serve como uma base aprovada e
documentada para o passo seguinte, facilitando bastante a gerência de
configuração.
148
Ciclo de Vida Clássico (Cascata)
➢Este é o modelo mais simples de desenvolvimento de software,
estabelecendo uma ordenação linear no que diz respeito à
realização das diferentes etapas;
➢modelo mais antigo e o mais amplamente usado da engenharia
de software;
➢modelado em função do ciclo da engenharia convencional;
➢requer uma abordagem sistemática, sequencial ao
desenvolvimento de software.
149
Quando usar o Ciclo de Vida Clássico (Cascata)
 há casos em que os requisitos de um problema são bem compreendidos
— quando o trabalho flui da comunicação ao emprego de forma
relativamente linear.
 Essa situação ocorre algumas vezes quando adaptações ou
aperfeiçoamentos bem definidos precisam ser feitos em um sistema
existente (por exemplo, uma adaptação em software contábil exigida
devido a mudanças nas normas governamentais).
 Pode ocorrer também em um número limitado de novos esforços de
desenvolvimento, mas apenas quando os requisitos estão bem definidos
e são razoavelmente estáveis.
150
Engenharia de 
Requisitos
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
Cascata
151
Atividades do Ciclo de Vida Clássico
ENGENHARIA DE REQUSITOS
 envolve a coleta de requisitos em nível do 
sistema, pequena quantidade de projeto e 
análise de alto nível 
Engenharia de 
Requisitos
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
152
Atividades do Ciclo de Vida Clássico
ANÁLISE DE REQUISITOS DE 
SOFTWARE
 processo de coleta dos requisitos 
é intensificado e concentrado 
especificamente no software
 deve-se compreender o domínio 
da informação, a função, 
desempenho e interfaces 
exigidos
 os requisitos (para o sistema e para 
o software) são documentados e 
revistos com o cliente
Engenharia de 
Requisitos
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
153
Atividades do Ciclo de Vida Clássico
PROJETO
 tradução dos requisitos do software para um 
conjunto de representações que podem ser 
avaliadas quanto à qualidade, antes que a 
codificação se inicie
 se concentra em 4 atributos do programa: 
➢ Estrutura de Dados,
➢ Arquitetura de Software, 
➢ Detalhes Procedimentais e 
➢ Caracterização de Interfaces
Engenharia de 
Requisitos
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
154
Atividades do Ciclo de Vida Clássico
CODIFICAÇÃO
 tradução das representações 
do projeto para uma linguagem 
“artificial” resultando em 
instruções executáveis pelo 
computador
Engenharia de 
Requisitos
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
155
Atividades do Ciclo de Vida Clássico
TESTES
Concentram-se:
 nos aspectoslógicos internos 
do software, garantindo que 
todas as instruções tenham sido 
testadas 
 nos aspectos funcionais 
externos, para descobrir erros e 
garantir que a entrada definida 
produza resultados que 
concordem com os esperados.
Engenharia de 
Requisitos
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
156
Atividades do Ciclo de Vida Clássico
MANUTENÇÃO
 o software deverá sofrer mudanças depois que 
for entregue ao cliente 
Engenharia de 
Requisitos
Análise de 
Requisitos 
Projeto 
Codificação 
Testes 
Manutenção
 causas das mudanças: 
erros, adaptação do 
software para acomodar 
mudanças em seu 
ambiente externo e 
exigência do cliente para 
acréscimos funcionais e de 
desempenho
157
Modelo Cascata - Modelo V
158
 Uma variação na representação do modelo cascata é denominada
modelo V. Este modelo descreve a relação entre ações de garantia da
qualidade e as ações associadas à comunicação, modelagem e atividades
de construção iniciais.
 O modelo procura enfatizar a estreita relação entre as atividades de teste
(teste de unidade, teste de integração, teste de sistema e teste de
aceitação) e as demais fases do processo.
 A conexão entre os lados direito e esquerdo do modelo em V implica que,
caso sejam encontrados problemas em uma atividade de teste, a
correspondente fase do lado esquerdo e suas fases subsequentes podem
ter de ser executadas novamente para corrigir ou melhorar esses
problemas.
159
Modelo Cascata - Modelo V
160
Na realidade, não existe uma diferença
fundamental entre o ciclo de vida clássico e o
modelo V.
O modelo V fornece uma forma para visualizar
como a verificação e as ações de validação são
aplicadas ao trabalho de engenharia anterior.
Modelo Cascata - Modelo V
Limitações do Ciclo de Vida Clássico
 O modelo assume que os requisitos são inalterados ao longo do
desenvolvimento; isto em boa parte dos casos não é verdadeira, uma
vez que nem todos os requisitos são completamente definidos na etapa
de análise;
Muitas vezes, a definição dos requisitos pode conduzir à definição do
hardware sobre o qual o sistema vai funcionar; dado que muitos projetos
podem levar diversos anos para serem concluídos, estabelecer os
requisitos em termos de hardware é um tanto temeroso, dadas as
frequentes evoluções no hardware;
161
Problemas com o Ciclo de Vida Clássico
 Os requisitos devem ser estabelecidos de maneira completa, correta
e clara logo no início de um projeto. A aplicação deve, portanto, ser
entendida pelo desenvolvedor desde o início do projeto. Entretanto,
frequentemente, é difícil para o usuário colocar todos os requisitos
explicitamente. O modelo em cascata requer isto e tem dificuldade de
acomodar a incerteza natural que existe no início de muitos projetos.
162
Limitações do Ciclo de Vida Clássico
O modelo impõe que todos os requisitos sejam completamente
especificados antes do prosseguimento das etapas seguintes; em alguns
projetos, é às vezes mais interessante poder especificar completamente
somente parte do sistema, prosseguir com o desenvolvimento do
sistema, e só então encaminhar os requisitos de outras partes; isto não é
previsto a nível do modelo;
As primeiras versões operacionais do software são obtidas nas etapas
mais tardias do processo, o que na maioria das vezes inquieta o cliente,
uma vez que ele quer ter acesso rápido ao seu produto.
163
Problemas com o Ciclo de Vida Clássico
 projetos reais raramente seguem o fluxo sequencial que o modelo
propõe;
 logo no início é difícil estabelecer explicitamente todos os requisitos.
No começo dos projetos sempre existe uma incerteza natural;
o cliente deve ter paciência. Uma versão executável do software só
fica disponível numa etapa avançada do desenvolvimento. Um erro
grave, se não detectado até o programa operacional ser revisto, pode
ser desastroso.
164
Problemas com o Ciclo de Vida Clássico
 A introdução de certos membros da equipe, tais como projetistas e
programadores, é frequentemente adiada desnecessariamente. A
natureza linear do ciclo de vida clássico leva a “estados de bloqueio”
nos quais alguns membros da equipe do projeto precisam esperar que
outros membros da equipe completem tarefas dependentes.
165
Considerações do Ciclo de Vida Clássico
Os modelos sequenciais pressupõem que o sistema é entregue completo,
após a realização de todas as atividades do desenvolvimento. Entretanto, nos
dias de hoje, os clientes não estão mais dispostos a esperar o tempo
necessário para tal, sobretudo, quando se trata de grandes sistemas.
Dependendo do porte do sistema, podem se passar anos até que o sistema
fique pronto, sendo inviável esperar. Assim, outros modelos foram
propostos visando a, dentre outros, reduzir o tempo de desenvolvimento. A
entrega por partes, possibilitando ao usuário dispor de algumas
funcionalidades do sistema enquanto outras estão sendo ainda
desenvolvidas, é um dos principais mecanismos utilizados por esses
modelos, como veremos a seguir.
166
Embora o Ciclo de Vida Clássico tenha 
fragilidades, ele é significativamente 
melhor do que uma abordagem casual 
ao desenvolvimento de software
Clássico (comentários)
167
Até aqui 22/09/2020
168
Modelo Incremental
 No desenvolvimento incremental, o sistema é dividido em
subsistemas ou módulos, tomando por base a funcionalidade.
 Os incrementos (ou versões) são definidos, começando com um
pequeno subsistema funcional que, a cada ciclo, é acrescido de novas
funcionalidades.
 Além de acrescentar novas funcionalidades, nos novos ciclos, as
funcionalidades providas anteriormente podem ser modificadas para
melhor satisfazer às necessidades dos clientes / usuários.
 Vale destacar que a definição das versões (e a correspondente
segmentação e atribuição dos requisitos a essas versões) é realizada
antes do desenvolvimento da primeira versão.
169
Modelo Incremental
O modelo incremental pode ser visto como uma filosofia básica que
comporta diversas variações.
O princípio fundamental é que, a cada ciclo ou iteração, uma versão
operacional do sistema será produzida e entregue para uso ou
avaliação detalhada do cliente. Para tal, requisitos têm de ser
minimamente levantados e há de se constatar que o sistema é modular,
de modo que se possa planejar o desenvolvimento em incrementos.
O primeiro incremento tipicamente contém funcionalidades centrais,
tratando dos requisitos básicos. Outras características são tratadas em
ciclos subsequentes.
170
Modelo Incremental
 O modelo incremental combina elementos dos fluxos de processos
lineares e paralelos. O modelo de processo incremental tem seu foco
voltado para a entrega de um produto operacional com cada
incremento.
 Os primeiros incrementos são versões seccionadas do produto final,
mas eles realmente possuem capacidade para atender ao usuário e
também oferecem uma plataforma para avaliação do usuário.
171
Modelo Incremental
 O desenvolvimento incremental é particularmente útil nos casos em
que não há pessoal disponível para uma completa implementação
na época de vencimento do prazo estabelecido para o projeto.
 Os primeiros incrementos podem ser implementados com número
mais reduzido de pessoal. Se o produto essencial for bem acolhido,
então um pessoal adicional (se necessário) poderá ser acrescentado
para implementar o incremento seguinte.
172
Modelo Incremental
173
o modelo incremental 
aplica sequências 
lineares, de forma 
escalonada, à medida 
que o tempo vai 
avançando. 
Cada sequência linear gera “incrementais” (entregáveis/aprovados/liberados) do software de 
maneira similar aos incrementais gerados por um fluxo de processos evolucionários.
Modelo Incremental
Há muitas situações em que os requisitos são
razoavelmente bem definidos, mas o tamanho do
sistema a ser desenvolvido impossibilita a adoção de
um modelo sequencial, sobretudo pela necessidade
de disponibilizar rapidamente uma versão para o
usuário. Nesses casos, um modelo incremental