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é
indicado.
174
Vantagens do desenvolvimento Incremental
175
✓ Uma vantagem desta abordagem é a facilidade em testar o sistema,
uma vez que a realização de testes em cada nível de
desenvolvimento é, sem dúvida, mais fácil do que testar o sistema
final.
✓ Além disso, como na Prototipação, a obtenção de um sistema,
mesmo incompleto num dado nível, pode oferecer ao cliente
interessantes informações que sirvam de subsídio para a melhor
definição de futuros requisitos do sistema.
Apresentam características que possibilitam desenvolver versões cada
vez mais completas do software. Nos slides seguintes, são
apresentados dois modelos comuns em processos evolucionários.
 Prototipação
 Espiral
176
Modelos evolucionários
Modelos de processo evolucionário
processo que possibilita que o desenvolvedor crie um modelo
do software que deve ser construído.
 idealmente, o modelo (protótipo) serve como um mecanismo
para identificar os requisitos de software.
apropriado para quando o cliente definiu um conjunto de
objetivos gerais para o software, mas não identificou requisitos
de entrada, processamento e saída com detalhes.
• Prototipação
177
Prototipação
Este protótipo pode ser oferecido ao cliente em diferentes formas, a saber:
Protótipo em papel ou modelo executável em PC retratando a interface
homem máquina capacitando o cliente a compreender a forma de
interação com o software;
Um protótipo de trabalho que implemente um subconjunto dos requisitos
indicados;
Um programa existente (pacote) que permita representar todas ou parte
das funções desejadas para o software a construir.
178
fim
início
construção
produto
refinamento
protótipo
avaliação
protótipo
construção
protótipo
projeto
rápido
obtenção dos
requisitos
Prototipação - O paradigma da prototipação
179
Atividades da Prototipação
Obtenção dos Requisitos:
desenvolvedor e cliente definem os 
objetivos gerais do software, identificam 
quais requisitos são conhecidos e as áreas 
que necessitam de definições adicionais
Projeto Rápido: representação dos 
aspectos do software que são visíveis ao 
usuário (abordagens de entrada e 
formatos de saída)
fim
início
construção 
produto
refinamento 
protótipo
avaliação 
protótipo
construção 
protótipo
projeto 
rápido
obtenção 
dos 
requisitos
180
Construção Protótipo:
implementação do projeto rápido
Avaliação do Protótipo: cliente e 
desenvolvedor avaliam o protótipo 
Atividades da Prototipação
fim
início
construção 
produto
refinamento 
protótipo
avaliação 
protótipo
construção 
protótipo
projeto 
rápido
obtenção 
dos 
requisitos
181
Refinamento dos Requisitos: cliente e
desenvolvedor refinam os requisitos do
software a ser desenvolvido.
Ocorre neste ponto um processo de iteração
que pode conduzir a 1ª atividade até que as
necessidades do cliente sejam satisfeitas e o
desenvolvedor compreenda o que precisa
ser feito.
Atividades da Prototipação
fim
início
construção 
produto
refinamento 
protótipo
avaliação 
protótipo
construção 
protótipo
projeto 
rápido
obtenção 
dos 
requisitos
182
Construção Produto: 
identificados os requisitos, o 
protótipo deve ser descartado e a 
versão de produção deve ser 
construída considerando os 
critérios de qualidade. 
Atividades da Prototipação
fim
início
construção 
produto
refinamento 
protótipo
avaliação 
protótipo
construção 
protótipo
projeto 
rápido
obtenção 
dos 
requisitos
183
Problemas com a Prototipação
cliente não sabe que o software que ele vê não considerou, durante o
desenvolvimento, a qualidade global e a manutenibilidade a longo prazo.
 Não aceita bem a ideia que a versão final do software vai ser construída e "força"
a utilização do protótipo como produto final.
184
Problemas com a Prototipação
desenvolvedor frequentemente faz uma implementação
comprometida (utilizando o que está disponível) com o
objetivo de produzir rapidamente um protótipo. Depois de
um tempo ele familiariza com essas escolhas, e esquece que elas
não são apropriadas para o produto final.
185
Ainda que possam ocorrer problemas, a prototipação é um
ciclo de vida eficiente ✓
A chave é definir-se as regras do jogo logo no começo✓
O cliente e o desenvolvedor devem ambos concordar que o
protótipo seja construído para servir como um mecanismo a
fim de definir os requisitos✓
Prototipação (comentários)
186
Ciclo de Vida em Espiral
✓ engloba as melhores características do ciclo de vida Clássico e da
Prototipação, adicionando um novo elemento: a Análise de Risco;
✓ segue a abordagem de passos sistemáticos do Ciclo de Vida
Clássico incorporando-os numa estrutura iterativa que reflete
mais realisticamente o mundo real;
✓ usa a Prototipação, em qualquer etapa da evolução do produto,
como mecanismo de redução de riscos
187
Ciclo de Vida em Espiral
✓ Foi originalmente proposto por Boehm em 1988. Uma maneira
simplista de analisar este modelo é considerá-lo como um modelo
cascata onde cada fase é precedida por uma análise de risco e sua
execução é feita evolucionariamente.
✓O modelo espiral completo está ilustrado na figura a seguir. A
dimensão radial representa o custo acumulado atualizado e a
dimensão angular representa o progresso através da espiral. Cada
setor da espiral corresponde a uma tarefa (fase)do desenvolvimento.
188
Ciclo de Vida em Espiral
✓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 "Avaliação de alternativas, , identificação e
solução de riscos", executa-se uma análise de risco. 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.
189
Modelo Espiral
190
decisão de continuar ou não
direção de um 
sistema concluídoavaliação
do cliente engenharia
análise dos
riscos
planejamento
Espiral
191
Atividades do Ciclo de Vida em Espiral
Planejamento: determinação dos objetivos,
alternativas e restrições.
Análise de Risco: análise das alternativas e
identificação / resolução dos riscos.
Construção: desenvolvimento do produto no
nível seguinte.
Avaliação do Cliente: avaliação do produto e
planejamento das novas fases
avaliação
do cliente
engenharia
análise dos 
riscos
planejamento
192
Modelo Espiral Completo
193
Modelo Espiral - Considerações
194
✓ O modelo espiral é uma abordagem realista para o desenvolvimento de sistemas
e de software em larga escala. Pelo fato de o software evoluir à medida que o
processo avança, o desenvolvedor e o cliente compreendem e reagem melhor aos
riscos em cada nível evolucionário. Esse modelo usa a prototipação como
mecanismo de redução de riscos e, mais importante, torna possível a aplicação
da prototipação em qualquer estágio do processo evolutivo do produto.
✓ Mantém a abordagem em etapas, de forma sistemática, sugerida pelo ciclo de
vida clássico, mas a incorpora em uma metodologia iterativa que reflete mais
realisticamente o mundo real. O modelo espiral requer consideração direta dos
riscos técnicos em todos os estágios do projeto e, se aplicado apropriadamente,
reduz os riscos antes de se tornarem problemáticos.
 O objetivo dos modelos evolucionários é desenvolver
software de alta qualidade. Entretanto, é possível
usar um processo evolucionário para enfatizar a
flexibilidade, a extensibilidade e a velocidade do
desenvolvimento.
 O desafio para as equipes de software e seus gerentes
será estabelecer um equilíbrio apropriado entre esses
parâmetros críticos de projeto e produto e a
satisfação dos clientes (o árbitro final da qualidade de
um software).
195
Modelos evolucionários (comentários)
DESENVOLVIMENTOÁGIL
196
197
O que é? A engenharia de software ágil combina filosofia com um
conjunto de princípios de desenvolvimento. A filosofia defende a
satisfação do cliente e a entrega de incremental prévio; equipes
de projeto pequenas e altamente motivadas; métodos informais;
artefato de engenharia de software mínimos e, acima de tudo,
simplicidade no desenvolvimento geral.
Os princípios de desenvolvimento priorizam a entrega mais que
análise e projeto (embora essas atividades não sejam
desencorajadas); também priorizam a comunicação ativa e
contínua entre desenvolvedores e clientes.
DESENVOLVIMENTO ÁGIL
No começo de 2001, um grupo de 17 desenvolvedores reconhecidos se juntou em Utah,
nos EUA, para discutir maneiras de desenvolvimento mais leves com base em suas
experiências. Eles assinaram um documento chamado “Manifesto para o
Desenvolvimento Ágil de Software”.
198
Quem realiza? Os engenheiros de software e outros envolvidos no projeto
(gerentes, clientes, usuários finais) trabalham conjuntamente em uma equipe
ágil — uma equipe que se auto-organiza e que controla seu próprio destino.
Uma equipe ágil acelera a comunicação e a colaboração entre todos os
participantes (que estão a seu serviço).
DESENVOLVIMENTO ÁGIL
Por que é importante? O moderno ambiente dos sistemas e
dos produtos da área é acelerado e está em constante
mudança. A engenharia de software ágil constitui uma
razoável alternativa para a engenharia convencional voltada
para certas classes de software e para certos tipos de
projetos, e tem se mostrado capaz de entregar sistemas
corretos rapidamente.
199
Quais são as etapas envolvidas? O desenvolvimento ágil poderia ser mais bem
denominado “engenharia de software flexível”. As atividades metodológicas
básicas permanecem: comunicação, planejamento, modelagem, construção e
emprego. Entretanto, estas se transformam em um conjunto de tarefas mínimas
que impulsiona a equipe para o desenvolvimento e para a entrega (pode-se
levantar a questão de que isso é feito em detrimento da análise do problema e
do projeto de soluções).
DESENVOLVIMENTO ÁGIL
Qual é o artefato? Tanto o cliente como o engenheiro têm o
mesmo parecer: o único artefato realmente importante
consiste em um “incremento de software” operacional que
seja entregue, adequadamente, na data combinada.
Como garantir que o trabalho foi realizado corretamente? Se a equipe ágil concordar
que o processo funciona e essa equipe produz incrementos de software passíveis de
entrega e que satisfaçam o cliente, então, o trabalho está correto.
200
Fundamentos-chave:
✓ Indivíduos e interações acima de processos e ferramentas;
✓ Software funcionando acima de documentação abrangente;
✓ Colaboração com o consumidor/cliente acima de negociação de contratos,
✓ Resposta às transformações/mudanças, mais do que seguir um plano.
DESENVOLVIMENTO ÁGIL
201
Qual é a importância da metodologia ágil para as empresas?
As metodologias ágeis têm por finalidade maximizar o trabalho das equipes de projetos e
os resultados gerados aos clientes, tendo por base seus 12 princípios:
1. Ter como prioridade a satisfação do cliente por meio de entregas de valor contínuas
e rápidas;
2. Ser receptivo a alterações nos requisitos em qualquer fase do processo. Aliás,
ambientes mutáveis são empregados em toda etapa do projeto para entregar ao
cliente vantagem competitiva;
3. Realizar entregas frequentes (do produto ou serviço) no menor período de tempo
possível;
4. Manter a colaboração das partes envolvidas em todo o projeto, diariamente;
5. Fornecer o ambiente, as ferramentas e o suporte necessários aos indivíduos do
projeto, além de acreditar neles para realizar as atividades;
DESENVOLVIMENTO ÁGIL
202
6. Estimular a comunicação pessoal, que transmite as informações necessárias ao
time de colaboradores, sendo o meio mais eficiente. Nesse ponto, atenção especial
para reuniões presenciais, consideradas mais eficazes para o sucesso do projeto;
7. Um produto final de trabalho corresponde à medida final do êxito. No caso da
tecnologia, a medida primária de progresso consiste no software em funcionamento;
8. Os profissionais envolvidos no processo precisam manter um ritmo constante, de
modo indefinido, pois fluxos ágeis estimulam um desenvolvimento sustentável. Da
mesma maneira, o desenvolvimento sustentável é feito por intermédio de processos
ágeis, por meio dos quais as partes interessadas conseguem manter um ritmo
contínuo e cíclico;
DESENVOLVIMENTO ÁGIL
203
9. Manter atenção frequente à excelência de design e técnica eleva ou aprimorar a
agilidade;
10. Eliminar o máximo de esforços que não geram valor ao produto, pois a simplicidade
é fundamental;
11. Equipes auto-organizáveis propiciam os melhores designs e arquiteturas, além de
atenderem aos requisitos do projeto,
12. Por meio de intervalos regulares, o time de colaboradores do projeto reflete sobre
como melhorar a sua eficiência e eficácia para otimizar o seu comportamento.
DESENVOLVIMENTO ÁGIL
204
✓ Esses princípios geram benefícios às empresas, como aumento na satisfação do
público e comunicação ativa entre os participantes do projeto e os clientes. Isso pode
reduzir custos.
✓ Além do mais, há grande enfoque em prazos, de modo que é possível sincronizar o
cronograma de execução de orçamento do projeto com as etapas e entregas aos
clientes.
DESENVOLVIMENTO ÁGIL
205
Existem métodos que se utilizam de processos ágeis para fortalecerem as suas
abordagens, tornando os procedimentos em que são aplicados mais eficientes. Veja
alguns exemplos adiante.
✓ Kanban
Kanban, termo de origem japonesa que significa literalmente “cartão” ou “sinalização”.
Seu conceito está relacionado ao uso de cartões — posteriormente de post-it, luzes, caixas
vazias, etc — para indicar o status de transportes ou fluxos de produção em companhias
de fabricação em série.
✓ Lean
A Metodologia Lean é anterior ao manifesto ágil, tendo surgido no Japão do pós-guerra,
em indústrias automobilísticas que desejavam ser mais produtivas. Por compreender
modelos de processos enxutos, com poucos desperdícios, essa abordagem é compatível
com as metodologias ágeis.
DESENVOLVIMENTO ÁGIL 
Métodos de uso relacionados à metodologia ágil
206
✓ Scrum
Scrum consiste em uma metodologia ágil para planejamento e gerenciamento de
projetos (especialmente de software). Nele, cada projeto é segmentado em ciclos,
geralmente mensais, conhecidos como sprints, que consistem em um time box (caixa de
tempo) ou um intervalo em que um conjunto de atividades deve ser realizado.
No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de
Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve
ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou
seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.
DESENVOLVIMENTO ÁGIL - Scrum
Métodos de uso relacionados à metodologia ágil
207
✓ As funcionalidades a serem implementadas em um projeto são mantidas em uma lista
que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint
Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner
prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será
capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint
são transferidas do Product Backlog para o Sprint Backlog.
✓ O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os
prioriza nas Sprint Planning Meetings. O Scrum Team olha para o Product Backlog
priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final
de um Sprint (iteração).
DESENVOLVIMENTO ÁGIL - Scrum
Métodos de uso relacionados à metodologia ágil
208
✓ A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente
de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento
sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o
trabalhodo dia que se inicia.
DESENVOLVIMENTO ÁGIL - Scrum
Métodos de uso relacionados à metodologia ágil
209
✓ Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma
Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte
para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a ilustração a
baixo:
DESENVOLVIMENTO ÁGIL - Scrum
210
✓ Extreme Programming – XP
A Programação Extrema é uma das metodologias ágeis mais conhecidas. Foi criada por
Kent Beck e ganhou notoriedade a partir da OOPLSA 2000 (a maior conferência
internacional de Orientação a Objetos). A primeira reação a XP foi bem controversa.
Alguns amaram (normalmente os programadores), outros odiaram. Em XP, o bom
programador se sente mais livre para fazer o que faria se não existissem regras. Ao
mesmo tempo, XP obriga o “mau” programador a se comportar de forma similar ao
bom.
DESENVOLVIMENTO ÁGIL 
Métodos de uso relacionados à metodologia ágil
211
DESENVOLVIMENTO ÁGIL - Extreme Programming – XP 
Métodos de uso relacionados à metodologia ágil
A Programação Extrema é baseada em cinco valores, alguns princípios e várias práticas.
Ela se destina a times de até dez programadores, projetos de curto e médio prazo.
Os cinco valores de XP são:
1. Comunicação – para um projeto de sucesso é necessária muita interação entre os
membros da equipe, programadores, cliente, treinador. Para desenvolver um produto,
o time precisa ter muita qualidade nos canais de comunicação. Conversas cara-a-cara
são sempre melhores do que telefonemas, e-mails, cartas ou fax.
2. Feedback – as respostas às decisões tomadas devem ser rápidas e visíveis. Todos
devem ter, o tempo todo, consciência do que está acontecendo.
212
DESENVOLVIMENTO ÁGIL - Extreme Programming – XP 
Métodos de uso relacionados à metodologia ágil
3. Coragem – alterar um código em produção, sem causar bugs, com agilidade, exige
muita coragem e responsabilidade.
4. Simplicidade – para atender rapidamente às necessidades do cliente, quase sempre
um dos valores mais importantes é simplicidade. Normalmente o que o cliente quer é
muito mais simples do que aquilo que os programadores constroem.
5. Respeito – todos têm sua importância dentro da equipe e devem ser respeitados e
valorizados. Isso mantém o trabalho energizado.
213
DESENVOLVIMENTO ÁGIL - Extreme Programming – XP 
XP, valores, princípios e práticas
Em XP existem quatro papéis principais:
✓ Programadores – foco central da metodologia, sem hierarquia.
✓ Treinador (ou coach) – pessoa com mais experiência no time, responsável por
lembrar os outros das regras do jogo (que são as práticas e os valores de XP). O
treinador não precisa necessariamente ser o melhor programador da equipe e sim o
que mais entende da metodologia XP.
✓ Acompanhador (ou tracker) – responsável por trazer para o time dados, gráficos,
informações que mostrem o andamento do projeto e ajudem a equipe a tomar
decisões de implementação, arquitetura e design. Algumas vezes o próprio coach faz
papel de tracker. Outras o time escolhe sozinho quem exercerá este papel.
✓ Cliente – em XP o cliente faz parte da equipe. Deve estar sempre presente e pronto
para responder às dúvidas dos programadores.
214
DESENVOLVIMENTO ÁGIL - Extreme Programming – XP 
Resumo das práticas:
✓ Planejamento – assim como no Scrum, existe uma fase de planejamento, quando
desenvolvedores e cliente se encontram para priorizar e estimar histórias.
✓ Fases Pequenas – cada fase é chamada de iteração (Sprint no Scrum). Elas devem
durar no máximo 30 dias, mas o ideal é que seja 15 ou até 7 dias.
✓ Design Simples – seguindo o valor simplicidade, os projetos devem ser simples e
atender a cada passo somente o que foi pedido. Nada de matar formigas com
canhão!
✓ Testes – todo desenvolvimento inclui testes.
215
DESENVOLVIMENTO ÁGIL - Extreme Programming – XP 
✓ Refatoração – é um conjunto de técnicas para modificar o código do sistema sem
alterar nenhuma funcionalidade. O objetivo é simplificar, melhorar o design, limpar,
enfim, deixar o código mais fácil de entender e dar manutenção.
✓ Programação Pareada – em XP dois programadores sentam juntos no mesmo
computador e programam juntos. Enquanto um programador digita, o outro
observa, pensa em melhorias, alternativas. Identifica erros, etc.
✓ Propriedade Coletiva – O código fonte não pertence a um único programador. Todos
da equipe são responsáveis. Todos alteram código de todos (mas sempre rodando os
testes para se certificar que nada foi quebrado).
216
DESENVOLVIMENTO ÁGIL - Extreme Programming – XP 
✓ Integração Contínua – depois de testada, cada nova funcionalidade deve ser
imediatamente sincronizada entre todos os desenvolvedores. Quanto mais frequente
for essa integração, menores são as chances de conflitos de arquivos que vários
programadores alteram simultaneamente.
✓ Semana de 40 horas – programar é uma atividade intensa e que não rende se o
programador não estiver descansado e disposto. Por isso, 40 horas de trabalho por
semana é essencial para a saúde do time.
✓ Cliente Sempre Presente – o cliente não é alguém de fora, mas sim um membro da
equipe. Ele deve estar sempre disponível e pronto para atender às dúvidas dos
desenvolvedores.
✓ Padronizações – se todo o time seguir padrões pré-acordados de codificação, mais
fácil será manter e entender o que já está feito. O uso de padrões é uma das formas
de reforçar o valor comunicação.
217
DESENVOLVIMENTO ÁGIL x DESENVOLVIMENTO TRADICIONAL
A Metodologia Tradicional possui etapas bem definidas sendo o planejamento do
projeto, uma estimativa em termos de prazo e orçamento, a execução e entrega no final.
Por exemplo:
✓ Planejamento do software (como ele ficará no final)
✓ Planejamento das atividades que serão necessárias (definição e análise dos requisitos,
programação, design, etc)
✓ Definição de prazos e custos
✓ Execução
✓ Testes
✓ Implantação
218
DESENVOLVIMENTO ÁGIL x DESENVOLVIMENTO TRADICIONAL
✓ Apesar do nome, a palavra ágil aqui não significa agilidade e sim o poder de “quebrar”
o projeto em partes menores.
✓ Ao contrário da metodologia tradicional que em várias técnicas de ciclo de vida, faz
apenas uma entrega já com o projeto final, aqui se faz entregas constantemente até
entregar todo o projeto.
✓ A preocupação com custo, qualidade e prazos são as mesmas da metodologia
tradicional, porém é possível conseguir controlar e gerenciar as mudanças que
provavelmente irão aparecer no decorrer do projeto.
✓ Na metodologia ágil o foco principal é a entrega de valor ao cliente, por isso é
priorizado a entrega, à documentação, por exemplo. Mas isso não quer dizer que não
é documentado, não planejado, assim como na tradicional. Na metodologia ágil
também existem esses aspectos, mas de maneiras diferentes. Por exemplo, o
planejamento da metodologia ágil é de forma iterativa e incremental enquanto a da
tradicional planeja com muita antecedência como será cada etapa do projeto.
✓ Dentro desta metodologia o mais utilizado e que provavelmente é o Scrum.
219
DESENVOLVIMENTO ÁGIL x DESENVOLVIMENTO TRADICIONAL
Como saber qual utilizar?
✓ Isso vai depender muito do tipo de projeto e cultura da empresa. A própria empresa
pode preferir a metodologia tradicional, ainda mais se os envolvidos do projeto não
estão acostumados a trabalhar com uma metodologia ágil, ainda que ela se aplique a
aquele projeto.
✓ O ideal é estudar o projeto, conhecer os requisitos, tecnologias a serem utilizadas…
tudo o que julgar necessário. E a partir disso tudo analisar se é melhor partir pela
metodologia ágil ou a tradicional. Em um projeto onde as necessidades do cliente
podem mudar a qualquer momento (o que é muito comum), será necessário ter a
liberdade de poder fazer mudanças necessárias tanto pelo lado do cliente quanto de
tecnologia, se precisar. Projetos que provavelmente terão mudanças constantes,
precisa ter um planejamento mais flexível, sendo assim a metodologia mais viável
seria a ágil.
220
DESENVOLVIMENTOÁGIL x DESENVOLVIMENTO TRADICIONAL
Como saber qual utilizar?
✓ A metodologia tradicional é uma boa opção em casos mais específicos, como por
exemplo em algo que precisa ser planejado e decidido desde o início. Se o projeto tem
poucas chances de ter mudanças e com baixo risco, o ideal é ter um plano de projeto
mais detalhado antes de iniciar.
Vale lembrar que a escolha da metodologia é importante não somente para se ter
sucesso no processo, mas principalmente, na entrega do produto. As duas
metodologias têm vantagens e podem ser utilizadas até mesmo de forma conjunta,
convivendo perfeitamente bem, até mesmo porque o foco das duas é a otimização de
projetos. A escolha entre a metodologia tradicional e ágil não precisa ser um conflito.
Deve-se respeitar às premissas das duas metodologias e saber o que cada uma pode
agregar aos objetivos de cada projeto.
Concluindo…
Até aqui 29.09.2020
221
222
RAPID APPLICATION DEVELOPMENT- RAD
223
✓ Rapid Application Development
(RAD) ou Desenvolvimento
Rápido de Aplicação é um
modelo de processo de
desenvolvimento de software
incremental, que enfatiza um
ciclo de desenvolvimento curto.
Foi registrado por James Martin,
em 1991.
224
CARACTERISTICAS
✓ É um processo de desenvolvimento de aplicações de forma rápida com objetivos
bem definidos e análise de requisitos extremamente bem alinhada. Esse modelo
enfatiza um ciclo de desenvolvimento curto, com o intuito de ter um
desenvolvimento melhor e mais rápido.
✓ No desenvolvimento incremental, uma das características de RAD, o sistema é
dividido em módulos, tomando por base a funcionalidade. Tendo os incrementos
definidos, a cada ciclo é acrescido de novas funcionalidades ou até mesmo
modificações, caso seja necessário.
✓ Outra característica é justamente essa maleabilidade de adaptação dos processos e
a capacidade de se manter em constante evolução.
225
✓ O Modelo RAD é uma adaptação de “alta velocidade” do modelo em cascata, no qual
o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção
baseada em componentes.
✓ No modelo RAD a comunicação trabalha para entender os problemas do negócios e as
características informais que o software precisa acomodar.
✓ O planejamento é essencial, porque várias equipes de software trabalham em
paralelo em diferentes funções do sistema.
✓ A modelagem abrange três das fases principais – modelagem de negócios,
modelagem dos dados e modelagem dos processos.
✓ A implantação estabelece a base das iterações subsequentes se necessárias.
✓ Se uma aplicação comercial pode ser modularizada de modo a permitir que cada
função principal possa ser completada em menos de três meses é uma candidata ao
RAD.
226
✓ A aplicabilidade do modelo em uma empresa exige recursos humanos suficiente
para todas as equipes. Clientes e desenvolvedores também devem estar
comprometidos com as atividades do processo a fim de finalizar a construção do
produto num prazo curto.
✓ Importante: Aplicações que não são passíveis de modularização não acondicionam
processos instanciados a partir do modelo RAD. Lembre-se também que, durante o
desenvolvimento, os módulos devem ser integrados, esta integração exige que as
regras de interfaces sejam bem definidas e respeitadas.
✓ As fases de modelagem e geração da aplicação são executadas por diversas equipes.
Essa divisão otimiza tempo, além do reaproveitamento de módulos prontos que faz
com que o desenvolvimento cumpra prazos curtos. Por fim, ocorre a integração
desses componentes.
227
O RAD tem uma capacidade muito grande de potencializar o desempenho dos
profissionais da equipe. Algumas outras VANTAGENS são:
✓ economia de tempo
✓ progresso mensurável
✓ trabalho com modelos
✓ integração mais rápida de sistemas
✓ feedback constante
228
Modelo RAD
229
A abordagem RAD tem DESVANTAGENS:
✓ Se uma aplicação não puder ser modularizada de modo que cada função principal
seja completada em menos de 3 meses, não é aconselhável o uso do RAD;
✓ Para projetos grandes (mas escaláveis) o RAD exige recursos humanos suficientes
para criar o número correto de equipes, isso implica um alto custo com a equipe;
✓ O envolvimento com o usuário tem que ser ativo;
✓ Comprometimento da equipe do projeto;
✓ O RAD não é aconselhável quando os riscos técnicos são altos e não é indicada
quando se está testando novas tecnologias ou quando o novo software exige alto
grau de interoperabilidade com programas de computador existentes. Falta de
prazo pode implicar qualidade reduzida, e há necessidade de habilidade maior dos
desenvolvedores, e suporte maior da gerência e dos clientes;
230
✓ Custo do conjunto de ferramentas e hardware para rodar a aplicação;
✓ Mais difícil de acompanhar o projeto(pois não existe os marcos clássicos);
✓ Menos eficientes;
✓ Perda de precisão científica (falta de métodos formais);
✓ Pode acidentalmente levar ao retorno das práticas caóticas no desenvolvimento;
✓ Funções desnecessárias (reuso de componentes);
✓ Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes);
✓ Padronização (aparência diferente entre os módulos e componentes);
✓ Sucessos anteriores são difíceis de se reproduzir.
231
✓ Um ponto muito importante é que a aplicação deve
possuir requisitos muito bem definidos;
✓ A performance não é o mais importante;
✓A distribuição do produto é pequena;
✓O âmbito do projeto é restrito;
✓O sistema pode ser dividido em vários módulos
independentes;
✓Quando envolve poucos riscos técnicos.Quando devo USAR?
232
✓ A aplicação precisa interagir com outros programas;
✓ A distribuição do produto será em grande escala;
✓ Para se construir sistemas operacionais (confiabilidade
exigida alta demais)
✓ Jogos de computador (performance exigida muito alta)
✓ Riscos tecnológicos muito altos;
✓ O sistema não pode ser modularizado.
Quando devo
EVITAR?
233
PU - Processo Unificado
234
Principal Ideia:
✓ Desenvolvimento Iterativo e Incremental - O PU utiliza um paradigma evolucionário para
o desenvolvimento de softwares.
✓ O ciclo de vida iterativo é baseado em refinamentos e incrementos sucessivos a fim de
convergir para um sistema adequado. Em cada iteração incrementa-se um pouco mais o
produto, baseando-se na experiência obtida nas iterações anteriores e no feedback do
usuário.
✓ Cada iteração pode ser considerada um miniprojeto de duração fixa, sendo que cada um
destes inclui suas próprias atividades de análise de requisitos, projeto, implementação e
testes.
✓ O processo unificado (Unified Process - UP) de desenvolvimento de software é o conjunto
de atividades necessárias para transformar requisitos do usuário em um sistema de
software.
✓ O Processo Unificado (PU) surgiu como um processo popular para o desenvolvimento de
software visando à construção de sistemas orientados a objetos (o RUP – Rational Unified
Process é um refinamento do PU).
235
O resultado de cada iteração é um sistema executável, porém incompleto. Ele não está pronto para
ser colocado em produção e pode continuar nesta situação ainda por muitas iterações. Vale ressaltar
também que cada iteração produz um sistema com qualidade de produto final, e não um protótipo.
236
Realimentação e Adaptação: A chave para o sucesso!
Ao invés de combater a inevitável mudança que ocorre no desenvolvimento de
software (principalmente nas fases iniciais), o PU prega uma atitude de aceitar a
mudança e a adaptação como fatores inevitáveis e, de fato, essenciais. Não se deve
tentar especificar completa e corretamente o sistema de uma só vez, com a ideia de
criar um conjunto congelado de requisitos.
Em cada iteração é escolhido um pequeno subconjunto de requisitos, os quais são
rapidamente projetados, implementados e testados pelos usuários. Isso leva a uma
realimentação rápida - baseada em dados concretos de usuários, desenvolvedores e
testes – que possibilita modificar ou adaptar a compreensão dos requisitos do
projeto.
237
Os usuários finais podem ver um sistema parcial, utilizá-lo e assim terão mais
subsídios paracriticar ou aprovar. Esse ciclo de avaliações e detecção de falhas
não traduz um erro, mas sim, representam um modo hábil de progredir e
descobrir o que é de real valor para os interessados no projeto. Além de melhorar
a compreensão dos requisitos, a implementação precoce possibilita detectar se o
projeto está no caminho certo ou, por exemplo, se alguma mudança na arquitetura
central deve ser feita.
Consequentemente o trabalho progride por meio de uma série de ciclos
estruturados em construção-realimentação- adaptação. É melhor resolver e por à
prova as decisões arriscadas e fundamentais de projeto logo no início e o
desenvolvimento iterativo fornece o mecanismo para isso.
238
CARACTERÍSTICAS:
✓ Iterativo e Incremental - O Processo Unificado é um processo Iterativo e
Incremental. As fases de Elaboração, Construção e Transição são divididas em
uma série de interações. (A fase de Iniciação também pode ser dividida em
iterações para grandes projetos). Cada iteração resulta em um incremento, que é
uma versão do sistema que contém funcionalidades adicionais ou melhoradas
em comparação com a versão anterior.
✓ Dirigido por Casos de Uso - No Processo Unificado, Casos de Uso são usados
para capturar requisitos funcionais e refinar o conteúdo das iterações. Cada
iteração tem um conjunto de casos de uso ou cenários de requisitos durante
todo o tempo de implementação, teste e desenvolvimento.
239
✓ Centrado na Arquitetura - O Processo Unificado insiste que a Arquitetura deve estar
no centro dos esforços da equipe do projeto, para dar forma ao sistema. Uma vez que
não existe um modelo único suficiente para cobrir todos os aspectos do sistema, o
Processo Unificado suporta múltiplas visões e modelos arquiteturais.
✓ Focado no Risco - O Processo Unificado requer que a equipe do projeto concentre-se
em enfrentar os Riscos mais críticos no início do ciclo de vida do projeto. As entregas
de cada iteração, especialmente na fase de Elaboração, devem ser selecionadas de
forma a garantir que os maiores riscos sejam tratados em primeiro lugar.
240
Ele é baseado em componentes, o que significa o sistema ser construído a partir
de componentes de software interconectados via interfaces muito bem definidas.
O processo unificado utiliza a Linguagem de Modelagem Unificada (Unified
Modeling Language – UML) no preparo de todos os artefatos do sistema.
241
O processo unificado de software possui 4 fases:
1. Fase da Concepção:
o Abrange atividades de comunicação com os clientes e de planejamento. Em colaboração
com os clientes e usuários finais , os requisitos de negócio para o software são
identificados, um rascunho de arquitetura é proposto.
o Os requisitos de negócios são escritos por meio de casos de uso preliminares. Um caso de
uso descreve uma sequência de ações que são realizadas por um ator.
o Não deve existir aqui a pretensão de especificar de forma detalhada requisitos, a ideia é
ter uma visão inicial do problema, estimar de forma vaga esforço e prazos e determinar se
o projeto é viável e merece uma análise mais profunda.
242
2. Fase de elaboração:
o Na fase de elaboração todos (ou a grande maioria dos requisitos) são levantados em
detalhes. Numa primeira iteração um ou dois requisitos, os de maior risco e valor
arquitetural, são especificados em detalhes. Estes são implementados e servem como
base de avaliação junto ao usuário e desenvolvedores para o planejamento da próxima
iteração. Em cada nova iteração na fase de elaboração pode haver um seminário de
requisitos, onde requisitos antigos são melhor esclarecidos e novos são detalhados.
o Ao fim da fase, 90% dos requisitos foram levantados em detalhes, o núcleo do sistema foi
implementado com alta qualidade, os principais riscos foram tratados e pode-se então
fazer estimativas mais realistas.
o Refina e expande os casos de uso preliminares que foram desenvolvidos como parte da
fase de concepção e expande a representação arquitetural para incluir cinco visões
diferentes do software – o modelo de caso de uso, o modelo de análise, o modelo de
projeto, o modelo de implementação e o modelo de implantação.
243
3. A fase da construção:
o implementação iterativa dos elementos restantes de menor risco e mais fáceis e
preparação para a implantação.
o É idêntica as atividades de construção definidas pelos modelos genéricos, essa fase
desenvolve ou adquire componentes de software que vão tornar cada caso de uso
operacional para os usuários finais. Todas as características e funções necessárias e
requeridas do incremento de software serão implementadas no código fonte. À
medida que os componentes são implementados , testes unitários são realizados.
4. Fase de Transição: Testes finais e implantação. Abrange os últimos estágios da vida
genérica de construção e a primeira parte genérica da atividade de implantação. O
software é dado ao usuário final para testes beta e relatórios de feedback do usuário
sobre defeitos e modificações necessárias.
244
Esboço do cronograma de um PU
245
Resumindo, os principais BENEFÍCIOS do PU são:
✓ Mitigação precoce, ao invés de tardia, de altos riscos;
✓ Progresso visível desde o início;
✓ Realimentação, envolvimento do usuário e adaptação imediatos, levando a um sistema
refinado que atenda, de forma mais adequada, às reais necessidades dos interessados;
✓ A complexidade é administrada; a equipe não é sobrecarregada pela “paralisia da
análise” ou por passos muito longos e complexos;
✓ O aprendizado obtido em uma iteração pode ser usado para melhorar o próprio
processo de desenvolvimento.
246
Conclusão
✓ O Processo Unificado foi criado para ser um processo ágil de desenvolvimento e
prega uma abordagem realística para a condução de um projeto. Ao contrário do
modelo em cascata, onde cada etapa do ciclo de vida é realizada integralmente e
de uma só vez (e que é mais apropriado para a construção de prédios do que para
softwares), no PU as atividades são repetidas quantas vezes forem preciso, em
ciclos organizados.
✓ Não há um plano detalhado para todo um projeto. Há um plano de alto nível
(chamado Plano de Fases) que estima a data de término do projeto e outros
marcos de referência principais, mas ele não detalha os passos de granularidade
fina para se atingir tais marcos. Um plano detalhado (chamado Plano de Iterações)
somente planeja a iteração a ser feita em seguida. O planejamento detalhado é
feito de forma adaptativa, de iteração para iteração.
247
EXERCÍCIOS
A empresa de software PAPAQUITOS SA pegou um projeto de desenvolvimento que
requer um desenvolvimento de alta velocidade, visando essa característica o
engenheiro de software dividiu esse desenvolvimento em iterações, com duração
cada uma delas de 60 a 90 dias e distribui isso por várias equipes. Que modelo de
desenvolvimento esse engenheiro usou?
A) Incremental
B) Espiral
C) RAD
D) Prototipação
E) Cascata
248
O processo unificado (PU) compactou as fases do processo genérico em 4 fases, quais
são elas?
A) Concepção, Planejamento, Modelagem, Construção
B) Concepção, Elaboração, Construção, Implantação
C) Concepção, Elaboração, Construção, Transição
D) Planejamento, Elaboração, Comunicação, Construção
E) Comunicação, Planejamento, Construção e Implantação
249
Na fase de Concepção do modelo PU (Processos Unificados) podemos descrever os
requisitos de negócio através das preliminares (artefatos):
A) Diagrama Atividade
B) Diagrama Sequência
C) Diagrama Estado
D) Diagrama Casos de Uso
E) Diagrama Classes
Até aqui 06.10.2020
250
251
Processo Unificado da Rational - RUP
252
Desafio:
Um grande problema nos projetos atuais é o grande dinamismo e complexidade
dos negócios nos dias de hoje. Cada vez mais os sistemas são complexos e
precisam estar prontos em menos tempo. Mais do que isso, as necessidades
mudam ao longo do tempo e a especificação de um sistema provavelmente será
alterada durante seu desenvolvimento. Além disso, temos tecnologias novas
(software e hardware) surgindo a cada dia. Algumas funcionambem. Outras não.
Visando atacar estes problemas, o RUP adota as seguintes premissas básicas:
o Uso de iterações para evitar o impacto de mudanças no projeto;
o Gerenciamento de mudanças;
o Abordagens dos pontos de maior risco o mais cedo possível.
253
✓ O Processo Unificado da Rational conhecido como RUP (Rational Unified Process), é
um processo proprietário de engenharia de software criado para apoiar o
desenvolvimento orientado a objetos, fornecendo uma forma sistemática para se
obter vantagens no uso da UML. Foi criado pela Rational Software Corporation e
adquirido em fevereiro de 2003 pela IBM.
✓ O principal objetivo do RUP é atender as necessidades dos usuários garantindo uma
produção de software de alta qualidade que cumpra um cronograma e um
orçamento previsíveis. Assim, o RUP mostra como o sistema será construído na fase
de implementação, gerando o modelo do projeto e, opcionalmente, o modelo de
análise que é utilizado para garantir a robustez.
✓ O RUP define perfeitamente quem é responsável pelo que, como as coisas deverão
ser feitas e quando devem ser realizadas, descrevendo todas as metas de
desenvolvimento especificamente para que sejam alcançadas.
Processo Unificado da Rational - RUP
254
Características:
✓ Utiliza uma abordagem de orientação a objetos em sua concepção e é projetado e
documentado utilizando a notação UML para ilustrar os processos em ação.
✓ Suas características principais: Iterativo e Incremental.
✓ Inicialmente foi desenvolvido e comercializado pela Rational, e desde 2003 pertence
a IBM.
✓ O RUP utiliza pequenos ciclos de projetos (mini-projetos) que correspondem à uma
iteração e que resultam em um incremento no software. Iterações referem-se a
passos e incrementos à evolução do produto.
Processo Unificado da Rational - RUP
255
✓ Derivado dos trabalhos sobre UML e do Processo Unificado de
Desenvolvimento de Software, ele traz elementos de todos os
modelos genéricos de processo, apoia a iteração e ilustra boas
práticas de especificação e projeto (Sommervillie 2007).
✓ Ele captura seis das melhores práticas no desenvolvimento de
software de forma satisfatória para uma grande faixa de projetos
e organizações (Krutchten 2003).
Processo Unificado da Rational - RUP
256
As melhores práticas abordadas são as seguintes (Sommerville 2007):
1. Desenvolver o software iterativamente: planejar os incrementos de software com base
nas prioridades do cliente e desenvolver e entregar o mais cedo possível às características
de sistema de maior prioridade no processo de desenvolvimento.
2. Gerenciar Requisitos: documentar explicitamente os requisitos do cliente e manter
acompanhamento das mudanças desses requisitos. Analisar o impacto das mudanças no
sistema antes de aceitá-las.
3. Usar arquiteturas baseadas em componentes: Estruturar a arquitetura do sistema com
componentes, reduzindo a quantidade de software a ser desenvolvido e,
consequentemente, reduzir custos e riscos.
Processo Unificado da Rational - RUP
257
4. Modelar software visualmente: usar modelos gráficos de UML para apresentar as visões
estática e dinâmica do software.
5. Verificar continuamente a qualidade do software: garantir que o software atenda aos
padrões de qualidade da organização.
6. Controlar as mudanças do software: gerenciar as mudanças do software, usando um
sistema de gerenciamento de mudanças, procedimentos e ferramentas de gerenciamento
de configuração.
Processo Unificado da Rational - RUP
258
Alcançando as melhores práticas:
✓ Abordagem iterativa.
✓ Guia para atividades e artefatos.
✓ Processo focado na arquitetura.
✓ Casos de uso dirigem o projeto e a implementação.
✓ Modelos simplificados de sistemas.
Processo Unificado da Rational - RUP
259
Processo Unificado da Rational – RUP
Conceitos básicos 
Trabalhador – Worker
✓O trabalhador define o comportamento e as
responsabilidades de um indivíduo, ou um
conjunto de indivíduos trabalhando em uma
equipe, dentro do contexto de uma organização
de software;
✓O trabalhador representa um cargo executado
por indivíduos em um projeto e define como
eles devem realizar o trabalho;
✓ Exemplos: engenheiros de requisitos, analistas
de sistemas, gerentes de projetos, arquitetos de
software, testadores, entre outros.
260
Processo Unificado da Rational – RUP
Conceitos básicos 
Atividade – Activity
✓Uma atividade é uma unidade de trabalho que
um indivíduo que representa um trabalhador é
encarregado de executá-la;
✓Uma atividade tem uma finalidade clara,
usualmente expressa em termos de criação ou
atualização de algum artefato, como um modelo,
uma classe, um plano.
261
Processo Unificado da Rational – RUP
Conceitos básicos 
Artefatos - Artifacts
✓Atividades têm artefatos com entrada e saída;
✓Um artefato é um produto de trabalho do processo. Trabalhadores usam artefatos para
executar suas atividades, e produzem artefatos durante a execução de suas atividades;
✓Artefatos são de responsabilidades de um único trabalhador, em um processo, cada
porção de informação é de responsabilidade de uma pessoa específica.
262
Processo Unificado da Rational – RUP
Trabalhador, Atividade e Artefato
263
Processo Unificado da Rational - RUP
O RUP, além de uma metodologia, é um produto comercializado pela Rational, que é
uma grande documentação baseada em hipertexto (HTML). Do conteúdo deste material,
destaca-se os seguintes assuntos:
Workflows: Cada workflow é descrito em detalhe, apresentando passo a passo as
tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos. Cada tarefa,
subproduto e papel é descrito em detalhe. Este modelo pode ser seguido à risca ou
adaptado conforme sua necessidade específica.
Tarefas: Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a
qual workflow ela pertence e quais são os subprodutos de entrada e saída.
264
Processo Unificado da Rational - RUP
Modelo de equipe: Os diversos papéis necessários no projeto são descritos em detalhe.
Assim como no MSF, cada papel pode ser representado por mais de uma pessoa, ou
uma pessoa pode ter mais de um papel, dependendo da carga de trabalho necessário.
Porém o RUP aborda os papéis em um maior nível de detalhe. Ao todo são mais de 30.
Exemplos de papéis são: analista de sistemas, analista de negócio, etc.
Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos
documentos (artifacts) gerados ao longo do projeto. Estes documentos são descritos em
detalhe, assim como as tarefas que os geram e as que os utilizam. Para os usuários das
ferramentas Rational, existe um recurso adicional e-coach, que orienta o usuário a usar
ferramentas como o Requisite Pro passo a passo. Os documentos são totalmente
compatíveis com a UML, o que reforça a questão de padronização.
265
Processo Unificado da Rational – RUP
No Processo Unficado Rational existem nove Disciplinas, que são divididas em seis
disciplinas de Processo e três de Suporte:
✓ As Disciplinas de Processo são:
o Modelagem de Negócio;
o Requisitos;
o Análise de Projeto;
o Implementação;
o Testes;
o Implantação.
✓ As Disciplinas de Suporte são:
o Gerenciamento de Configuração e Alteração;
o Gerenciamento de Projetos;
o Ambiente.
266
Processo Unificado da Rational – RUP
Estrutura Básica do RUP - Nesta metodologia, o projeto passa por 4 fases básicas. Estas fases
são:
1. Iniciação - entendimento da necessidade e visão do projeto;
2. Elaboração - especificação e abordagem dos pontos de maior risco;
3. Construção - desenvolvimento principal do sistema;
4. Transição - ajustes, implantação e transferência de propriedade do sistema.
267
Processo Unificado da Rational – RUP
✓ Apesar de parecer um modelo em cascata, na verdade cada fase é composta de
uma ou mais iterações, o que se assemelha a um modelo em espiral. Estas
iterações são em geral curtas (1-2 semanas) e abordam algumas poucas funções
do sistema. Isto reduz o impacto de mudanças, pois quanto menor o tempo,
menor a probabilidade de haver uma mudança neste período para as funçõesem questão.
✓ Além das fases e iterações, existem os workflows. Cada workflow é na verdade
uma sequência de tarefas encadeadas e relacionadas a um aspecto importante
do projeto, tal como análise do negócio, testes, etc. Os gráficos da figura
mostram a ênfase de cada workflow em cada etapa do projeto.
268
✓ O RUP organiza o desenvolvimento de software em quatro fases, onde são tratadas questões
sobre planejamento, levantamento de requisitos, análise, implementação, teste e implantação
do software. Cada fase tem um papel fundamental para que o objetivo seja cumprido pela
disciplinas apresentadas, distribuídos entre vários profissionais como o Analista de sistema,
Projetista, Projetista de testes, entre outros.
Processo Unificado da Rational - RUP
DISCIPLINAS
As disciplinas agrupam 
atividades relacionadas nas 
fases.
A iteração percorre todas 
as disciplinas.
Tempo
C
o
n
te
ú
d
o
269
1. Concepção / Iniciação:
o Esta fase do RUP abrange as tarefas de comunicação com o cliente e
planejamento. É feito um plano de projeto avaliando os possíveis riscos, as
estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos
requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência
das partes interessadas na definição do escopo do projeto, onde são examinados
os objetivos para se decidir sobre a continuidade do desenvolvimento.
o Nesta fase é estabelecido um business case[2] (Caso de uso de negócio) para o
sistema. Devem ser identificadas todas as entidades externas (pessoas e
sistemas/atores) que irão interagir com o sistema em desenvolvimento e definir
essas interações. Essas informações são utilizadas para avaliar a contribuição do
novo sistema para o negócio.
Processo Unificado da Rational - RUP
270
2. Elaboração:
o Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é
analisar de forma mais detalhada a análise do domínio do problema, revisando
os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua
forma básica. Indagações como "O plano do projeto é confiável?", "Os custos
são admissíveis?" são esclarecidas nesta etapa.
o Ao final desta fase deve-se ter um modelo de requisitos para o sistema (os casos
de uso da UML são especificados), uma descrição de arquitetura e um plano de
desenvolvimento do software.
Processo Unificado da Rational - RUP
271
3. Construção:
o Está fase está essencialmente relacionada ao projeto, programação e teste do
sistema. As partes do sistema são desenvolvidas paralelamente e integradas durante
esta fase. Ao final deve-se ter um sistema de software em funcionamento e a
documentação associada pronta para ser liberada para os usuários.
4. Transição:
o Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é
disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As
atividades desta fase incluem o treinamento dos usuários finais e também a
realização de testes da versão beta do sistema visando garantir que o mesmo possua
o nível adequado de qualidade.
A versão beta de um software ou produto é a versão em estágio ainda de desenvolvimento, mas que é 
considerada aceitável para ser lançada para o público, mesmo que ainda possua bugs e problemas que precisarão 
ser reparados pelos desenvolvedores antes do lançamento definitivo do produto ao mercado na sua versão final.
Processo Unificado da Rational - RUP
272
Processo Unificado da Rational – RUP
Disciplinas e Modelos
273
Processo Unificado da Rational - RUP
Cada disciplina do RUP contém um fluxo de trabalho (workflow). Um workflow é um fluxo de atividades 
de alto-nível (Workflow Details) que produzem um resultado de valor observável.
Workflow Details
Workflows Details
mostram trabalhadores, 
atividades que estes 
executam, artefatos e 
entrada e artefatos de 
saída.
Exemplo: Disciplina de Requisitos Exemplo de diagrama Workflow Details: 
Analyze the Problem
274
Processo Unificado da Rational – RUP
Como Adotar
o Com base nestes recursos a adoção do RUP pode ser feita de mais de uma maneira.
Um extremo seria usar o RUP à risca, ou seja, aplicar todos os métodos e processos
exatamente como são propostos.
o A vantagem desta abordagem é que nada deve ser alterado, pois o RUP é bem
completo e detalhado. Porém existe um preço a ser pago, pois o RUP na íntegra é
complexo.
o Esta abordagem implicaria em treinamentos, projetos piloto, etc. Propostas de
projetos de adoção do RUP são descritos no próprio produto.
275
Processo Unificado da Rational – RUP
Conclusão:
Utilizando o RUP é possível obter:
✓ Software de qualidade.
✓ Produtividade no desenvolvimento, operação e manutenção do software.
✓ Controle sobre o desenvolvimento dentro de custos, prazos e níveis de qualidade
desejados.
✓ Estimativas de prazos e custos com maior precisão.
276
ICONIX
277
✓ A Metodologia ICONIX foi elaborada por Doug Rosenberg e Kendall Scott a partir da síntese do
processo unificado pelos “três amigos” - Booch, Rumbaugh, e Jacobson o qual tem dado
suporte e conhecimento a mesma desde 1993.
✓ O ICONIX é “um processo simplificado que unifica conjuntos de métodos de orientação a
objetos em uma abordagem completa, com o objetivo de dar cobertura ao ciclo de vida”.
✓ É considerado uma metodologia pura, prática e simples, mas também poderosa e com um
componente de análise e representação dos problemas sólido e eficaz.
✓ A metodologia ICONIX é caracterizada como um Processo de Desenvolvimento de Software
desenvolvido pela ICONIX Software Engineering.
✓ O ICONIX é um processo que se situa entre o RUP – Rational Unified Process (qualificado pelos
autores como “imenso”) e o XP- eXtreme.
ICONIX
278
✓ Iconix é um processo de desenvolvimento de software - Modelo de Engenharia de
Software desenvolvido pela Iconix Software Engineering . Trata-se de uma
metodologia prática e simples, mas também poderosa e com um componente de
análise e representação de problemas sólidos e eficazes.
✓ É um processo não tão burocrático quanto o RUP, ou seja, não gera tanta
documentação, mas também não pode ser considerado tão simples como o XP.
O Iconix é um processo que está adaptado ao padrão UML, possuindo uma
característica exclusiva chamada Rastreabilidade dos Requisitos , que através dos
seus mecanismos permite checar em todas as fases se os requisitos estão sendo
atendidos.
ICONIX
279
Os principais diagramas usados no processo são:
✓ Modelo de Domínio: é uma parte essencial do ICONIX, ele constrói uma porção
estática inicial de um modelo que é essencial para dirigir a fase de design a partir
dos casos de uso.
o Basicamente o modelo de domínio consiste em descobrir objetos de um
problema do mundo real. Para realizar o modelo de domínio é preciso tentar
descobrir o maior número possível de classes existentes no problema para o
qual se pretende desenvolver o software.
ICONIX
280
Modelo de Domínio
281
✓ Modelo de Caso de Uso:
Esse modelo é usado para representar as exigências dos usuários, seja para um sistema
novo, ou partindo de um já existente. Ele deve detalhar de forma clara e legível todos
os cenários que os usuários executarão para realizar alguma tarefa.
Caso de Uso de Negócio Caso de Uso de Software
282
Até aqui 13/10/2020
283
Análise de Robustez (conceito e diagramas recuperados da visão original de Ivar Jacobson)
ICONIX: Diagramas de Robustez
RASTREABILIDADE
Diagrama de caso 
de uso
Descrição de 
casos de uso
Diagrama de 
robustez
Diagrama de 
sequência
284
Análise de Requisitos
✓ Requisitos x Casos de Uso:
o Um Caso de Uso descreve uma unidade de comportamento.
o Um Requisito descreve uma regra que governa o
comportamento.
o Um Caso de Uso satisfaz um ou mais Requisitos Funcionais.
o Um Requisito Funcional pode ser satisfeito por um ou mais Casos 
de Uso.
285
Análise e Desenho Preliminar
✓ Fazer as descrições dos Casos de Uso com os cenários principais, alternativos e
exceções
✓ Fazer a análise de robustez, isto é, para cadaCaso de Uso:
o Identificar um primeiro conjunto de objetos.
o Criar Diagramas de Robustez usando os estereótipos de classes boundary
(fronteira), control (controle), e entity (entidade).
o Atualizar o modelo do domínio, com os novos objetos e atributos descobertos.
✓ Terminar a atualização do diagrama de classes de modo a refletir a conclusão da
fase de análise (iteração mais detalhada do diagrama de domínio).
286
Diagrama de Robustez
Os Diagramas de Robustez usam três tipos de estereótipos:
✓ Objetos de fronteira/interface («boundary»)
✓ Objetos de entidade («entity»)
✓ Objetos de controle («control»)
287
✓ Diagrama de Robustez:
Essa fase tem como objetivo conectar a fase de análise com a parte de projeto
assegurando que a descrição dos casos de uso está correta, além de descobrir novos
objetos através do fluxo de ação.
Este diagrama usa três tipos de estereótipos:
o Objetos de fronteira/interface (<<>boundary>) – Permitem aos atores a comunicação com o sistema
(janela, páginas web, janelas de diálogo).
o Objetos de entidade (<<entity>>) - correspondem geralmente aos objetos identificados no modelo de
domínio.
o Objetos de controle (<<control>>) – integradores entre os objetos de fronteira e os objetos de
entidade:
▪ Contém as regras de negócio e as políticas de funcionamento do modo a potencializarem a
independência das interfaces com os utilizadores, dos esquemas das bases de dados, etc.
▪ Acabam geralmente por se convertidos em métodos de objetos de entidade ou de objetos de
fronteira, embora resultem ocasionalmente também em objetos no modelo estático.
288
289
✓ Diagrama de Sequência:
Tem como objetivo construir um modelo dinâmico entre o usuário e o
sistema. Para isso é necessário usar os objetos e suas iterações identificados
na análise robusta, porém detalhando todo o fluxo de ação.
290
✓ Diagrama de Classe:
Nada mais é do que o
modelo de domínio
que foi atualizado ao
longo de todas as fases
do processo e
representa todas as
funcionalidades do
sistema de modo
estático sem as
iterações com o
usuário.
291
O ICONIX é dividido em dois grandes setores, modelo estático e modelo dinâmico,
esses podem ser desenvolvidos paralelamente e de forma recursiva, o modelo estático
é formado pelo diagrama de domínio e de classe e o dinâmico pelos demais.
Dinâmica: Apresenta a
interação do usuário com
o sistema, utilizando dos
seguintes artefatos:
Diagrama de caso de uso,
diagrama de robustez e
diagrama de sequência.
Estática: Mostra o
funcionamento do
sistema sem nenhum
dinamismo e interação
do usuário. Utiliza dos
seguintes artefatos:
Modelo de domínio e
diagrama de classe.
292
293
294
✓ O Iconix trabalha a partir de um protótipo de Interfaces onde se desenvolvem os
diagramas de caso de uso baseados nos requisitos levantados. A partir do diagrama
do caso de uso, se faz análise robusta para cada caso de uso. Com os resultados
obtidos é possível desenvolver o diagrama de sequência e posteriormente
complementar o domínio com novos métodos e atributos descobertos.
✓ É um processo dirigido por casos de uso, como o RUP, mas não é tão burocrático, ou
seja, não gera tanta documentação.
✓ O ICONIX também é um processo relativamente compacto, como o XP, mas não
descarta a análise e projeto (design) como o XP faz.
✓ O ICONIX utiliza a linguagem de modelagem UML e possui uma característica
exclusiva chamada “Rastreabilidade dos Requisitos” (Traceability of Requirements),
mais precisamente, ele permite “obrigatoriamente” por meio de seus mecanismos,
verificar em todas as fases, se os requisitos estão sendo atendidos.
295
O ICONIX tem como base responder algumas questões fundamentais sobre o software.
Assim, utiliza técnicas da UML que auxiliam a prover a melhor resposta. As questões e as
técnicas são:
QUESTÕES TÉCNICAS
1 – Quem são os usuários do sistema (ou atores), e o 
que eles estão tentando fazer?
Utilizar casos de uso
2 – O que são, no “mundo real” (Chamado domínio de 
problema), os objetos e as associações entre eles?
Utilizar diagrama de classe de alto nível
3 – Que objetos são necessários para cada caso de uso? Utilizar análise de robustez
4 – Como objetos estão colaborando e interagindo 
dentro de cada caso de uso?
Utilizar diagrama de sequência e de 
colaboração
5 – Como será manipulado em tempo real aspectos de 
controle?
Utilizar diagrama de estado
6 – Como realmente será construído o sistema em um 
nível prático?
Utilizar diagrama de classe de baixo nível
296
As CARACTERÍSTICAS-CHAVE do ICONIX são:
✓ Uso enxuto da UML: os passos do processo estabelecem apenas um conjunto
mínimo e suficiente para que um projeto orientado a objetos seja bem sucedido.
✓ Alto grau de rastreabilidade: a cada passo do processo retorna-se de alguma forma
aos requisitos. Nenhuma parte do processo permite que o analista se afaste muito
das necessidades do usuário.
✓ Iterativo e incremental: múltiplas iterações acontecem entre o desenvolvimento
do modelo de domínio e a identificação e análise dos casos de uso. O modelo
estático é incrementalmente refinado durante as sucessivas iterações que
acontecem no modelo dinâmico.
297
Conclusões sobre ICONIX:
✓O ICONIX é um processo com uma abordagem essencialmente prática, que promove
a modelação de um sistema segundo o paradigma “Objecto Oriented”, segundo um
princípio de que se deve modelar e desenhar incrementalmente, fazendo o menos
possível em cada passo (conseguem-se especificar 80% da maioria dos sistemas com
apenas 20% de esforço de análise e desenho).
✓O ICONIX é um processo conduzido por casos, de modo iterativo e incremental
(distinguindo-se entre requisitos e casos de utilização).
✓ ICONIX não privilegia explicitamente alguns diagramas da UML, tais como diagrama de
estado ou de arquitetura, e mesmo os diagramas de colaboração.
298
PRAXIS - Processo para Aplicativos e Extensíveis Interativos
299
PRAXIS
✓ O PRAXIS é um processo de software, baseado no Processo Unificado (UP),
desenhado para dar suporte a projetos didáticos. A sigla PRAXIS significa Processo
para Aplicativos e Extensíveis Interativos, refletindo em uma ênfase no
desenvolvimento de aplicativos gráficos interativos, baseados na tecnologia
orientada a objeto.
✓ O PRAXIS propõe um ciclo de vida composto por fases que produzem um conjunto
precisamente definido de artefatos (documentos e modelos). Para construir cada um
dos artefatos, o usuário de processo (estudante ou Engenheiro) precisa exercitar um
conjunto de práticas recomendáveis. Na construção desses artefatos, o usuário do
processo é guiado por padrões e auxiliado pelos modelos de documentos e
exemplos constantes de material de apoio.
300
PRAXIS é um modelo baseado nos modelos RUP (sendo esta sua
principal referência), TSP e PSP. Na realidade, trata-se de uma
instância (implementação) do RUP, que ganhou expressão no mercado
em função de seu "berço" (DCC UFMG - Referência em computação) e
por ter sido utilizado em cursos de graduação e pós graduação por
longos períodos. Entretanto, existem limitações para sua difusão, falta
de divulgação de longo alcance, fora de MG, e a questão do "perfil
acadêmico" excessivo do modelo, caracterizado, por exemplo pelo
excessivo número de artefatos gerado ao longo do projeto (relatórios,
modelos, especificações, etc.)
301
O modelo baseia-se numa visão sobreposta, por duas fontes do mesmo fato: O
Desenvolvimento de Software.
A primeira visão é a do "fluxo técnico":
- Atividade do engenheiro de software
- Gestão de requisitos
- Análise (Projeto lógico)
- Desenho (Diagramação, UML)
- Implementação
- Engenharia de Sistemas
302
> A segunda visão é a gerencial, cuja responsabilidade é do gestor de projetos. Cada
passo/fase, é vista segundo um "script" estruturado da seguinte forma:
- Descrição
- Pré Requisitos
- Insumos
- Atividades
- Resultados Esperados
- Critérios de aprovação
303
O PRAXIS adota as mesmas fases (Concepção, Elaboração, Construção, Transição) e os
mesmos fluxos do Processo Unificado. Os principais elementosque constituem o
PRAXIS são:
✓ Passo: Divisão formal de um processo, com pré-requisitos, entradas, critérios de
aprovação e resultados definidos.
✓ Fase: Divisão maior de um processo, para fins gerenciais, que corresponde aos
pontos principais de aceitação por parte do cliente.
✓ Interação: Passo constituinte de uma fase, no qual se atinge um conjunto bem
definido de metas parciais de um projeto.
✓ Script: Conjunto de instruções que define como uma iteração deve ser executada.
✓ Fluxo: Subprocesso caracterizado por um tema Técnico ou Gerencial.
✓ Subfluxo: Conjunto de atividades mais estreitamente correlatas faz parte de um
fluxo maior.
✓ Atividade: Passo constituinte de um fluxo
✓ Técnica: Método ou prática aplicável à execução de um conjunto de atividades.
304
CLEAROOM – SALA LIMPA
305
Clearoom
O desenvolvimento de software Cleanroom é uma
filosofia de desenvolvimento de software que usa
métodos formais para apoiar inspeção rigorosa de
software.
O objetivo dessa abordagem para o
desenvolvimento de software é o software com
defeito zero. O nome Cleanroom foi derivado por
analogia com unidades de fabricação de
semicondutores, em que os defeitos são evitados na
manufatura em uma atmosfera ultra limpa.
306
A abordagem Cleanroom para desenvolvimento de software baseia-se em cinco estratégias
principais:
A abordagem Cleanroom, baseia-se nas seguintes estratégias:
1. Especificação Formal: o software a ser desenvolvido é especificado formalmente.
2. Desenvolvimento Incremental: o software é particionado em incremento
desenvolvidos e validados separadamente.
3. Programação Estruturada: um número limitado de construções abstratas de controle e
de dados são usados. O processo de codificação de um programa é um processo de
refinamentos sucessivos da especificação.
4. Verificação Estática: o software é verificado estaticamente por meio de inspeções
rigorosas de software.
5. Testes Estatísticos de Sistema: cada incremento de software é testado estatisticamente
parta determinar a confiabilidade. Esses testes são baseados num perfil operacional
desenvolvido em paralelo com a especificação do sistema.
307
CONSIDERAÇÕES:
✓ O uso desta abordagem tem levado a construção de softwares com poucos erros. Os
custos desses projetos foram comparáveis a outros projetos que usaram técnicas de
desenvolvimento convencionais.
✓ A inspeção rigorosa do programa é uma parte fundamental do processo Cleanroom.
Um modelo de estado do sistema é criado como especificação do sistema, onde o
mesmo é refinado através de uma serie de modelos de sistema detalhada para um
programa executável.
✓ Os argumentos matemáticos usados nos Cleanroom não são provas formais de
correção. Elas dependem do uso do conhecimento de semânticas formais de
linguagem de programação para construir teorias que relacionem o programa e a sua
especificação formal.
✓ O desenvolvimento Cleanroom funciona quando é praticado por engenheiro
habilidosos e comprometido.
308
Qual a principal característica do Iconix?
A) Rastreabilidade de Segurança
B) Utilização de UML
C) Rastreabilidade de Requisitos
D) Uso do Diagrama de Sequência
E) Nenhuma das anteriores
EXERCÍCIOS
309
EXERCÍCIOS
Em qual outro modelo de Processo o Praxis é baseado?
A) RUP
B) Clearoom
C) Métodos Formais
D) Espiral
E) Processo Unificado - PU
310
EXERCÍCIOS
A abordagem Cleanroom para desenvolvimento de software baseia-se em cinco
estratégias principais com exceção de:
A) Especificação informal
B) Desenvolvimento Incremental
C) Programação Estruturada
D) Verificação estática
E) Testes estáticos do sistema
311
Até aqui 20.10.2020
312
DSDM (Dynamic Systems Development Method – Método de 
desenvolvimento dinâmico de sistemas)
313
✓ Atualmente, existem diversos métodos ágeis usados no mercado, cujo o objetivo é
atender às demandas dos clientes e seus projetos de maneira mais flexível e com
maior produtividade. Um exemplo de método ágil empregado no desenvolvimento
de projetos e também no meio tecnológico é o DSDM (do inglês Dynamic Systems
Development Method).
✓ Originado no Reino Unido em 1990, através do DSDM Consortium, uma associação
de consultores e especialistas no ramo de Engenharia de Software, partilharam e
combinaram as suas melhores técnicas e experiências. Seu objetivo era a união do
desenvolvimento de uma extensão do RAD (Rapid Application Development)
independente, cuja as principais características são os prazos curtos e orçamentos
fixos.
314
✓ O DSDM é uma metodologia de desenvolvimento de sistemas dinâmicos, que visa
desenvolver projetos com a qualidade desejada sem ultrapassar limites de tempo e
orçamento. Entre suas melhores práticas estão o desenvolvimento incremental e
iterativo, exigências flexíveis, a colaboração e comunicação entre cliente e equipe,
além da integração de funcionalidades.
✓ O DSDM é uma abordagem ágil de desenvolvimento de software que fornece um
arcabouço para construir e manter sistemas que satisfazem às restrições de prazos
apertadas, por meio do uso de prototipagem incremental em um ambiente
controlado de projeto.
315
O DSDM consiste em três fases sequenciais: Pré-Projeto, Projeto e Pós-Projeto.
✓ Fase 1: O Pré-Projeto
No pré-projeto são identificados os projetos candidatos, onde são definidos o
orçamento e a assinatura do contrato. Estes critérios devem ser controlados
antecipadamente para evitar problemas futuros e em estágios mais críticos.
✓ Fase 2: O Ciclo de Vida do Projeto
Nesta etapa, o Estudo de viabilidade e o Estudo de Negócio são fases sequenciais que
se completam entre si. Após a conclusão destas fases, o sistema é desenvolvido
iterativamente e de forma incremental nos níveis de Análise Funcional, Desenho e
Implementação. Veja seguir o que representa cada fase.
316
o Estudo da Viabilidade – Estabelece requisitos básicos de negócio e restrições associados à
aplicação a ser construída. Depois avalia se a aplicação é um candidato viável para o processo
DSDM.
o Estudo do Negócio – Incrementa todo o trabalho realizado no Estudo de Viabilidade. Depois do
projeto ser declarado viável para o uso da DSDM, este nível examina o processo de
financiamento, os utilizadores envolvidos e as suas necessidades e desejos respectivos.
o Iteração de Modelos Funcionais – Onde é produzido um conjunto de protótipos incrementais
que demonstram a funcionalidade para o cliente. Neste ciclo iterativo procura-se juntar os
requisitos adicionais ao se obter feedback dos usuários conforme eles vão testando e utilizando
o protótipo.
o Iteração de Projeto e Desenvolvimento – Onde revisitamos os protótipos desenvolvidos
durante a iteração de modelos funcionais, para assegurar que cada um tenha passado por um
processo de engenharia. Assim, conseguimos oferecer aos usuários finais o valor de negócio em
termos operacionais.
o Implementação – Onde de fato colocamos a última versão do incremento de software no
ambiente operacional. Nesta última fase o incremento pode não estar 100% completo ou ainda
alterações podem ser solicitadas conforme o incremento seja alocado.
317
Fase 3: Pós-Projeto
Esta fase garante a eficiência e eficácia do projeto. Através de manutenções, melhorias e
ajustes de acordo com os princípios do DSDM. A manutenção pode ser vista como um
contínuo desenvolvimento. Invés de finalizar o ciclo de vida de apenas 1 vez,
normalmente o projeto pode retomar fases anteriores a fim de refinar ainda mais o
passo concluído.
Considerações:
O DSDM é uma ótima e segura base para equipes de desenvolvimento que têm em
mãos projetos com necessidade de execução rápida e com requisitos flexíveis. Onde
visa desenvolver projetos com a qualidade desejada sem ultrapassar limites de tempo e
orçamento. É constituída por 3 fases que ajudam na facilitação do projeto e de seu
desenvolvimento. A partir desta metodologia, é possível construir um trabalho que
agrade ao cliente, à equipe de desenvolvimento e aos utilizadores finais que terão a
oportunidade de interagir com todo o desenvolvimento do sistemade informação,
através das frequentes fases de testes.
318
FAMÍLIA CRYSTAL
319
Crystal
✓ Criada no final da década de 90 por Alistair Cockburn e Jim Highsmith, a família
Crystal se baseia na gestão de pessoas, tendo o foco na interação, habilidades,
talentos e comunicação.
✓ Segundo o criador Cockburn, as pessoas de uma equipe possuem diferentes
talentos e habilidades, sendo um diferencial durante o desenvolvimento de um
projeto, já que as pessoas têm uma importância muito grande no desempenho do
projeto. Além disso, foi criada para atender vários tipos de projetos e equipes que
precisam de táticas para resolver diversos problemas.
✓ Não há uma metodologia Crystal e sim diferentes tipos de metodologia Crystal
para diferentes tipos de projeto, por isso chamamos de família Crystal. É uma
família de metodologias que une diferentes modelos de processo, mas com
elementos centrais que são comuns a todas, além dos papéis e práticas específicas
de cada uma.
320
A criticidade é dividida em 4 níveis: (C) conforto, (D) baixo custo, (E) alto custo e (L)
risco de vida. Assim é possível escolher a melhor metodologia para aquele projeto,
adotando um conjunto de políticas adequadas para cada situação.
Algumas práticas da metodologia são:
✓ a entrega em intervalos regulares;
✓ o monitoramento do progresso;
✓ envolvimento direto com o cliente;
✓ inspeções constantes a cada incremento;
✓ os feedback que servem para ajuste do produto e da metodologia caso necessário.
321
Segundo os autores da metodologia, acredita-se que a metodologia adequada é
baseada no tamanho da equipe e nos riscos envolvidos no projeto. Por isso, a
família Crystal é dividida em cores, onde deve-se escolher a cor que mais for
apropriada para cada projeto, de acordo com o nível de criticidade e o tamanho da
equipe. Quanto mais escura for a cor, mais crítico é o sistema e, consequentemente,
será utilizada a metodologia mais “pesada”.
Por exemplo, um projeto com 50 pessoas envolvidas precisa de uma metodologia
mais pesada do que um projeto com 10 pessoas. Pode-se avaliar o projeto por duas
visões: número de pessoas e criticidade do sistema.
322
Modelagem Ágil (AM)
323
Modelagem Ágil (AM)
A modelagem Ágil foi inspirada para a utilização em softwares muito grandes. Apesar da
AM sugerir uma ampla gama de princípios de modelagem centrais e suplementares os
elementos que tornam AM peculiar são:
✓ Modelar com uma finalidade: Um desenvolvedor que usa AM deve ter uma meta
específica em mente antes de criar o modelo. Uma vez identificada a meta do modelo,
o tipo de notação a ser usada e o nível de detalhes a ser exigido serão óbvios.
✓ Usar modelos múltiplos: Há muitos modelos e notações diferentes que podem ser
usados para descrever software. Apenas um pequeno subconjunto é essencial para a
maioria dos projetos. A AM sugere que, para fornecer a visão necessária, cada modelo
apresente um aspecto diferente do sistema e que apenas aqueles modelos que
ofereçam valor seja usados.
324
✓ Viajar leve: À medida que o trabalho de engenharia de software prossegue, conserve
apenas aqueles modelos que fornecerão valor ao longo do prazo e livre-se do resto.
✓ O conteúdo é mais importante que a representação: Um modelo sistematicamente
perfeito que leva pouco conteúdo útil não são tão valioso com um modelo com notação
defeituosa, mas que fornece conteúdo valioso .
✓ Conhecer os modelos e ferramentas que você usa para criá-los: Entenda os pontos
fortes e fracos de cada modelo e das ferramentas que são usadas para criá-los
✓ Adaptar localmente: A abordagem de modelagem deve ser adaptada às necessidades
da equipe ágil.
325
Apesar da AM (Modelagem Ágil) sugerir uma ampla gama de princípios de modelagem
centrais e suplementares o que não torna AM peculiar é:
A) Modelar com uma finalidade
B) Não usar modelos múltiplos
C) O conteúdo é mais importante que a representação
D) Conhecer os modelos e ferramentas que você usa para criá-los
E) Adaptar localmente
EXERCÍCIOS
326
Princípios Centrais, Comunicação e 
Planejamento
327
De modo genérico, a prática é uma coleção de conceitos, princípios, métodos e
ferramentas da qual um engenheiro de software faz uso diariamente. A prática preenche
um modelo de processo de software com as receitas técnicas e gerenciais necessárias
para fazer o serviço.
A essência da prática da engenharia de software baseou-se na essência da resolução de
problemas que é:
1. Entenda o problema (comunicação e análise)
2. Planeje uma solução (modelagem e projeto de software)
3. Execute o plano (geração do código)
4. Examine o resultado quanto à precisão (teste e garantia da qualidade).
328
Princípios Centrais
Existem 7 princípios centrais para a prática da engenharia de software:
✓ O Primeiro Princípio: A razão por que tudo existe.
Um sistema de software existe por uma razão: para fornecer valor aos seus usuários.
Todas as decisões devem ser tomadas com isso em mente.
A pergunta deve ser feita: Isso adiciona valor real ao sistema? Se a resposta for não, não
faça. Todos os outros princípios se apoiam nesse.
✓ O Segundo Princípio: KISS(Keep it Simple,Stupid – Mantenha a coisa simples)
Todo projeto deve ser tão simples quanto possível. Isso facilita ter um sistema mais fácil
de entender e de manter, mas não quer dizer que características internas, devam ser
descartadas em nome da simplicidade. Simples também não significa rápido e sujo.
✓ O Terceiro princípio: Mantenha a Visão
Uma visão clara é essencial para o sucesso de um projeto de software. Ter um arquiteto
fortalecido que possa manter a visão e exige que ela seja respeitada ajuda a garantir um
projeto de software muito bem sucedido.
329
✓ O Quarto Princípio: O que você produz outros vão consumir
De um modo ou de outro alguém mais vai usar, manter, documentar ou precisará entender
o seu sistema. Assim, sempre especifique, projete e implemente sabendo que mais alguém
terá de entender o eu você esta fazendo.
✓ O Quinto Princípio: Esteja Aberto para o Futuro
Os sistemas de software com verdadeira “força industrial” precisam durar muito mais. Para
fazer isso com sucesso, eles precisam estar prontos para se adaptar a essas e outras
modificações. Sistemas que fazem isso com sucesso são aqueles que foram projetados dessa
forma desde o início.
✓ O Sexto Princípio: Planeje com Antecedência o Reuso
Reuso poupa tempo e esforço. O reuso de código e de projetos tem sido proclamado como
um importante beneficio do uso de tecnologia orientada a objetos.
Planejar o reuso com antecedência reduz custo e aumenta o valor tanto dos componentes
reusáveis quanto do sistema ao qual será incorporado.
✓ O Sétimo Princípio: Pense!
Raciocinar clara e completamente antes da ação quase sempre produz melhores resultados.
Quando se pensa sobre algo é mais provável que o faça corretamente. Você também
adquire conhecimento sobre como fazê-lo novamente.
330
Prática da COMUNICAÇÃO
Antes que os requisitos do cliente possam ser analisados, modelados ou especificados,
eles precisam ser coletados por meio de uma atividade de comunicação. O caminho da
comunicação para o entendimento é frequentemente cheio de buracos.
A comunicação efetiva esta entre as atividades mas desafiadoras com as quais se
confronta um engenheiro de software.
Os princípios da comunicação são:
Princípio 1: Escute
Tente se concentrar nas palavras do interlocutor em vez de na formulação de sua
resposta a essas palavras. Peça esclarecimento se algo estiver obscuro. Evite interrupções
constantes.
Princípio 2: Prepare-se Antes de se comunicar
Gaste tempo em entender o problema antes de se encontrar com os outros,
pesquise a respeito para entender a “linguagem” do usuário.
331
Princípio 3: Alguém deve facilitar a atividade
Toda reunião de comunicação deve ter um líder (facilitador) para manter a
conversa se movendo em uma direção produtiva, para mediar qualquer conflito e para
garantir que os outros princípios sejam seguidos.
Princípio 4: Comunicação face a face é melhor
Costuma funcionar melhor quandoalguma outra representação da comunicação
relevante é apresentada.
Princípio 5: Faça anotações e documente as decisões
As coisas têm um modo de escorrer por entre os dedos. Alguém que participe
da comunicação deve servir como um registrador e anotar todos os pontos importantes.
Princípio 6: Busque Colaboração
Colaboração e consenso ocorrem quando o conhecimento coletivo dos
membros da equipe é combinado para descrever funções e características do sistema.
332
Princípio 7: Conserve-se focado, modularize sua discussão
Quanto mais pessoas estiverem envolvidas em uma comunicação, mais
provavelmente aquela discussão vai ficar saltando de um tópico para o outro. O facilitador
deve manter a conversa modular, abandonando um tópico apenas depois que estiver
resolvido.
Princípio 8: Se algo não esta claro desenhe uma figura
A comunicação verbal vão só até um certo ponto, um esboço ou um desenho pode
frequentemente fornecer esclarecimento.
Princípio 9: Prossiga
A comunicação, como qualquer atividade de engenharia leva tempo. Em vez de
iterar sem fim, as pessoas que participam devem reconhecer que muito tópicos requer
discussão e devem prosseguir com a reunião sem se prender a eles nesse momento.
Princípio 10: Negociação
Existem muitas instâncias em que os engenheiros de software e os clientes devem
negociar funções e características, isso deve ser feito de modo que ambas as partes saiam
ganhando, assim sendo negociação exige comprometimento de ambas as partes.
333
Práticas do PLANEJAMENTO
A atividade de planejamento inclui um conjunto de práticas gerenciais e técnicas
que permitem a equipe de software definir um roteiro enquanto ela se move em direção
a sua meta estratégica e seus objetivos táticos.
Em muitos projetos o planejamento excessivo consome tempo e não produz
frutos, mas a falta de planejamento é uma receita para o caos. O planejamento deve ser
conduzido com moderação.
Independente do rigor com o qual o planejamento é conduzido os princípios a
seguir se aplicam:
Princípio 1: Entenda o escopo do Projeto
É impossível usar um roteiro se você não souber para onde está indo. O escopo
fornece a equipe de software um destino
Princípio 2: Envolva o cliente na atividade de planejamento
O cliente que define as prioridades e oferece as restrições do projeto, por isso
ele deve ser envolvido no planejamento.
334
Princípio 3: Reconheça que o planejamento é iterativo
Um plano de projeto nunca é gravado em pedra. Quando o trabalho tem início, é
muito provável que as coisas se modifiquem, como consequência o plano deve ser
ajustado para acomodar as modificações.
Princípio 4: Estime com base no que é sabido
A intenção de uma estimativa é fornecer uma indicação de esforço, o custo, a
duração de tarefas com base no entendimento atual da equipe quanto ao trabalho a ser
feito.
Princípio 5: Considere riscos à medida que você define o plano
Se a equipe tiver definido riscos que têm grande impacto e alta probabilidade, é
necessário planejamento e contingência.
Princípio 6: Seja realista
As pessoas não trabalham 100% do tempo do dia, sempre há ruídos em qualquer
comunicação humana, omissões, ambiguidade.
335
Princípio 7: Ajuste a granularidade a medida que você define o plano
Granularidade refere-se ao nível de detalhes introduzido à medida que um plano
de projeto é desenvolvido.
Princípio 8: Defina como você pretende garantir a qualidade
O plano deve identificar como a equipe de software pode garantir a qualidade.
Princípio 9: Descreva como você pretende acomodar as modificações
Mesmo o melhor planejamento pode ser comprometido por modificações
descontroladas. A equipe de software deve identificar como as modificações devem ser
acomodadas à medida que o trabalho prossegue.
Princípio 10: Acompanhe o plano com frequência e faça os ajustes necessários
Projetos de software se atrasam um dia de cada vez. Assim faz sentido
acompanhar o progresso diariamente, procurando áreas problemáticas e situações em que
o trabalho não esta de acordo com o programado.
336
Qual das alternativas tem um dos princípios da
Comunicação?
A) Se algo não esta claro desenhe uma figura
B) A razão porque tudo existe
C) Entenda o escopo do projeto
D) Mantenha a Visão
E) O que você produz outros vão consumir
EXERCÍCIOS
337
O princípio: "Estime com base no que é sabido", é um principio da ...
A) Comunicação
B) Modelagem e Analise
C) Construção
D) Planejamento
E) Princípios Gerais
EXERCÍCIOS
338
A descrição : "As pessoas não trabalham 100% do tempo do dia, sempre há ruídos em
qualquer comunicação humana, omissões, ambiguidade." diz respeito a qual princípio?
A) Estime com base no que é sabido
B) Busque colaboração
C) Escute
D) Seja Realista
E) Descreva como você pretende acomodar as modificações
EXERCÍCIOS
339
O Princípio “Planeje com Antecedência o Reuso” é um principio:
A) Central
B) Comunicação
C) Planejamento
D) Reuso
E) Consumismo
EXERCÍCIOS
340
Projetos de software se atrasam um dia de cada vez. Assim faz sentido aplicar um dos
princípios do planejamento que é:
A) Considere riscos à medida que você define o plano
B) Acompanhe o plano com frequência e faça os ajustes necessários
C) Defina como você pretende garantir a qualidade
D) Descreva como você pretende acomodar as modificações
E) Estime com base no que é sabido
EXERCÍCIOS
341
Finalizamos todo conteúdo programático
Muito Obrigada!!!
342
Referências
• PRESSMAN, Roger. Software Engineering: A Practitioner’s Approach,
6ª edição, Mc Graw Hill, 2005 .
• «Ariane-5G». Gunter’s Space Page. Consultado em6 September 2014.
• Naur and B. Randell, Eds.Software Engineering. Report on a
Conference held in Garmisch, Oct. 1968, sponsored by NATO
• https://ariane.cnes.fr/en/5-goodies/decollage-parfait-pour-ariane-5
• http://www.laps.ufpa.br/yomara/paginav2/aps/processo%20unificad
o%20rup.pdf
• http://www.ibm.com/software/awdtools/rup/
https://ariane.cnes.fr/en/5-goodies/decollage-parfait-pour-ariane-5