Curso de Pós-Graduação Lato Sensu

Especialização em

Engenharia de Software
(EngSw) a Distância

Disciplina/Aula: Engenharia de
Software e Engenharia de Requisitos

Elisamara de Oliveira

Marcelo de Freitas Pintaud

1
 Sumário
Apresentação ...................................................................................................................... 4
Capítulo 1 – Software e Engenharia de Software ............................................................ 5
1.1. Antecedentes Históricos da Engenharia de Software ................................................ 5
1.2. Definições e Conceitos de Software e Engenharia de Software ................................ 8
1.3. O Produto Software .................................................................................................. 13
1.4. Aplicações do Software ............................................................................................ 15
1.5. Mitos do Software ..................................................................................................... 17
Exercícios do Capítulo 1 ................................................................................................. 21
Capítulo 2 – Processo de Software ................................................................................. 23
2.1. Conceitos Básicos de Processo de Software ........................................................... 23
2.2. Padrões, Avaliação e Tecnologias de Processo ...................................................... 27
Exercícios do Capítulo 2 ................................................................................................. 31
Capítulo 3 – Modelos de Processo ................................................................................. 32
3.1. Ciclo de Vida e Modelos de Processo ...................................................................... 32
3.2. Modelos Prescritivos de Processo ........................................................................... 37
3.3. Modelo em Cascata ................................................................................................. 38
3.4. Modelos Evolucionários de Processo ....................................................................... 40
3.4.1. Prototipação ....................................................................................................... 40
3.4.2. Modelo Espiral ................................................................................................... 43
3.4.3. Modelo de Desenvolvimento Concorrente ......................................................... 45
3.5. Modelos Incrementais de Processo ......................................................................... 47
3.5.1. Modelo Incremental............................................................................................ 48
3.5.2. Modelo RAD - Rapid Application Development .................................................. 49
3.6. Desenvolvimento Baseado em Componentes.......................................................... 51
3.7. Modelo de Métodos Formais .................................................................................... 54
3.8. Processo Unificado .................................................................................................. 56
3.9. Desenvolvimento Ágil ............................................................................................... 60
Exercícios do Capítulo 3 ................................................................................................. 65
Capítulo 4 – Engenharia de Requisitos .......................................................................... 68
4.1. Requisitos e Engenharia de Requisitos .................................................................... 68
4.2. Objetivos e Classificação dos Requisitos ................................................................ 70

2
 4.3. Tarefas da Engenharia de Requisitos ...................................................................... 77
Exercícios do Capítulo 4 – parte 1 .................................................................................. 77
4.4. Elicitação de Requisitos ........................................................................................... 84
4.4.1. Técnicas de Coleta de Requisitos ...................................................................... 88
4.4.2. Considerações sobre as Técnicas de Coleta de Requisitos .............................. 95
Exercícios do Capítulo 4 – parte 2 .................................................................................. 97
Considerações Finais....................................................................................................... 99
Respostas Comentadas dos Exercícios ....................................................................... 100
Glossário de Siglas ........................................................................................................ 107
Bibliografia ...................................................................................................................... 108
 Apresentação

Atualmente o software está presente, explicitamente ou mesmo sem se fazer notar,

em diversos aspectos da vida, inclusive nos sistemas críticos que afetam nossa saúde e
nosso bem estar. Diferentemente de outras áreas da Engenharia, novas aplicações de
software aparecem a cada dia e isso torna a área de desenvolvimento de software um
desafio constante, necessitando de pessoas treinadas, capacitadas e em constante
evolução para desempenhar adequadamente as funções necessárias para a produção de
software de qualidade.
As dificuldades em se obter software de qualidade, obedecendo a prazos, custos e
escopo estabelecidos, se mostram presentes desde os primórdios da área de computação.
Devido a isso, uma base sólida sobre a teoria e a prática da Engenharia de Software é
essencial para sabermos como construir bons softwares e avaliarmos os riscos e as
oportunidades que ele pode trazer para o bom desempenho dos negócios.
A Engenharia de Software trilhou um longo caminho desde quando o termo foi
usado pela primeira vez. Convidamos você, caro aluno, a percorrer esse caminho. Ao
longo dessa disciplina, iremos destacar aspectos-chaves da Engenharia de Software,
abordando, dentre outras, as seguintes questões:
• Qual a necessidade de uma disciplina de Engenharia para o desenvolvimento de
software?
• O que se entende por Engenharia de Software?
• O que se entende por software de computador?
• Por que lutamos para construir sistemas de alta qualidade?
• Como podemos categorizar os domínios de aplicação para o software?
• Que mitos ainda existem sobre software?
• O que é um processo de software?
• Que modelos de processo podem ser aplicados ao desenvolvimento de software?
• Quais os pontos fortes e fracos de cada modelo de processo?
• Por que é tão complicado estabelecer os requisitos de um sistema?
• Quais técnicas podem nos auxiliar no estabelecimento dos requisitos?
Quando essas questões forem respondidas, você, caro aluno, estará melhor preparado
para entender os conceitos de gestão e os aspectos técnicos da atividade de Engenharia
de Software que serão abordados nas disciplinas subsequentes do nosso curso.

Marcelo Pintaud
Elisamara de Oliveira
 Capítulo 1 – Software e Engenharia de Software
Caro aluno, neste capítulo abordaremos os antecedentes históricos da
engenharia de software, falaremos sobre os principais conceitos de software e da
engenharia de software, sobre a crise do software, mostraremos as diferenças entre os
produtos “software” x ‘hardware”, exemplificaremos algumas das principais
aplicações do software e o alertaremos sobre o que é mito e realidade na área de
desenvolvimento.

1.1. Antecedentes Históricos da Engenharia de Software

Caros alunos, para entendermos melhor os conceitos fundamentais que envolvem a
área de Engenharia de Software, vamos fazer um breve histórico dos principais fatos que
ocorreram no mundo da tecnologia que justificaram a criação deste ramo da computação.
É interessante vocês notarem que há algumas décadas atrás, não se tinha ideia da
importância que os computadores e, em especial, o software (programas de
computadores), iriam ter e como iriam afetar profundamente a vida de todos nós.
A denominação da “Engenharia de Software” surgiu em 1968, em uma conferência
organizada para discutir a chamada “crise do software”. Mas, para sermos mais precisos, o
termo foi criado no início da década de 1960, tendo sido utilizado oficialmente em 1968
nesta conferência, a NATO Conference on Software Engineering (Conferência da OTAN
sobre Engenharia de Software), que aconteceu na cidade de Garmisch, Alemanha. Nesta
ocasião, todos estavam preocupados em contornar os efeitos da crise do software e
buscar maneiras de dar
um tratamento de
engenharia, ou seja, mais
sistemático e controlado,
ao desenvolvimento de
sistemas de software
complexos.
Um sistema de
software complexo é

caracterizado por um
Fonte:http://profcarolinadgs.webnode.com.br/unip/engenharia-de-software/
conjunto de componentes
5
de software (estruturas de dados, métodos, técnicas) encapsulados na forma de
procedimentos, funções, módulos, objetos ou agentes, interconectados entre si, compondo
a arquitetura do software, que deverão ser executados em sistemas computacionais.

A Crise do Software
A “crise do software” foi um termo criado para descrever as dificuldades
enfrentadas no desenvolvimento de software no final da década de 1960. 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. Essa crise teve como origem a introdução de computadores “mais poderosos”.
O advento deste hardware com mais recursos tornava viáveis softwares bem
maiores e mais complexos que os sistemas existentes. A experiência inicial de
construção desses sistemas mostrou que uma abordagem informal de
desenvolvimento de software não era suficiente. Projetos importantes sofriam
atrasos (às vezes, de alguns anos). Os custos eram muito maiores do que os
inicialmente projetados. As soluções de software não eram confiáveis. Os
programas eram de difícil manutenção. Novas técnicas e novos métodos eram
necessários para controlar a complexidade inerente aos grandes sistemas de
software.

Desta forma, como o principal objetivo dessa conferência foi estabelecer práticas
mais maduras para o processo de desenvolvimento de software, é considerado como o
evento que deu origem à disciplina de Engenharia de Software.

Duas décadas depois, em 1986, Alfred Spector, presidente da Transarc Corporation,

foi co-autor 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 caíam. Por outro lado, os softwares nunca ficavam
prontos dentro do prazo e do orçamento, e, além disso, quase sempre apresentavam
problemas.”

6
 Uma década mais tarde, em 1995, a organização The Standish Group (1995)
publicou um estudo analisando as estatísticas sobre sucesso e fracasso dos projetos de
desenvolvimento de software: o Chaos Report. Neste estudo foi revelado que:

• quase 84% dos projetos de software eram mal-sucedidos, sejam por serem
cancelados ou apresentarem falhas críticas (dentre elas conclusão fora do tempo
previsto, fora do orçamento previsto ou com menos funcionalidades do que o
planejado)
• 31.1% dos projetos eram cancelados antes de serem concluídos
• 52.7% dos projetos apresentavam custo real 189% maior que o estimado e o tempo
de conclusão 222% maior que o previsto
• 16.2% dos projetos eram concluídos dentro de prazo, custo e escopo estimados
• estimou-se que, naquele ano, as agências governamentais e companhias privadas
americanas teriam gasto US$ 81 bilhões apenas em projetos cancelados, e mais
US$ 59 bilhões em projetos concluídos fora do tempo previsto.

O Standish Group continuou publicando regularmente seu relatório nos anos

seguintes e, apesar de 35% dos projetos de software iniciados em 2006 terem obtido
sucesso, ainda é assustador saber que dois terços de todos eles fracassam. Vejam as
estatísticas de 2004:

7
 Observando estes números, fica claro que de 1960 até hoje, mais de 50 anos de
experiência no desenvolvimento de software não bastaram para melhorar efetivamente a
qualidade do software, a despeito da evolução ocorrida na área de Engenharia de Software
e do ferramental disponível.

Grady Booch, um dos criadores da UML – Unified Modeling Language, resumiu

assim a história: “uma doença que dure tanto tempo quanto esta, francamente, deveria ser
chamada de normalidade”. [BOOCH et al, 2006].

Fonte: http://www.virtuadesigner.com/keynotes.html

1.2. Definições e Conceitos de Software e Engenharia de Software

Engenharia de Software é uma disciplina da engenharia que se ocupa de todos os
aspectos da produção de software, desde os estágios iniciais de especificação do sistema
até a manutenção desse sistema, depois que ele entrou em operação. Seu principal
objetivo é fornecer uma estrutura metodológica para a construção de software com alta
qualidade. Para que isso seja conseguido é necessário:

• aplicar teorias, métodos e ferramentas nas situações apropriadas nas diversas

etapas do desenvolvimento

• trabalhar de acordo com as restrições organizacionais e financeiras procurando

soluções que estejam dentro dessas restrições

• gerenciar os projetos de software para que o resultado final esteja dentro do

escopo, custo e prazos planejados

• adotar uma abordagem sistemática e organizada (maneira mais eficaz de

produzir software de alta qualidade)

8
 Apesar da sua indiscutível importância, caro, aluno, as técnicas e métodos da
Engenharia de Software são, atualmente, amplamente, mas não universalmente,
utilizadas.

Mas não podemos falar da Engenharia de Software, sem antes, entendermos o

software e seus fundamentos. Assim, os conceitos de software são apresentados aqui
como uma referência inicial para o estudo do software, propriamente dito, e de seus
processos de desenvolvimento.

Comecemos pelo significado léxico da palavra software e seu significado nos

dicionários:

Dicionário

Software (palavra inglesa, de soft, mole + ware, mercadoria);

[Informática]. Conjunto de programas, processos e regras, e, eventualmente, de
documentação, relativos ao funcionamento de um conjunto de tratamento da
informação (por oposição a hardware). (Dicionário Priberam da Língua Portuguesa,
http://www.priberam.pt/dlpo/dlpo.aspx?pal=software, 2011)

Software é uma sequência de instruções a serem seguidas e/ou executadas,

na manipulação, redirecionamento ou modificação de um dado/informação ou
acontecimento. Software também é o nome dado ao comportamento exibido por
essa seqüência de instruções quando executada em um computador ou máquina
semelhante além de um produto desenvolvido pela Engenharia de software, e inclui
não só o programa de computador propriamente dito, mas também manuais e
especificações. Para fins contábeis e financeiros, o Software é considerado um bem
de capital. (Wikipedia, http://pt.wikipedia.org/wiki/Software, 2011)

Pressman (2010) conceitua o software como:

“(1) Instruções (programas de computador) que, quando executadas,

produzem a função e o desempenho desejados; (2) Estruturas de dados que
possibilitam que os programas manipulem adequadamente a informação; (3)
Documentos que descrevem a operação e o uso dos programas”.
9
 As normas de gestão de qualidade e garantia da qualidade apresentam definições
de software e seus componentes e processos. De acordo com a norma NBR ISO 9000-3,
que é uma interpretação da norma de garantia de qualidade ISO 9001 para aplicação aos
produtos de software, temos as seguintes definições:
Software: Criação intelectual compreendendo os programas, procedimentos, regras
e qualquer documentação correlata à operação de um sistema de processamento
de dados.
Produto de software: Conjunto completo de programas de computador,
procedimentos e documentação correlata, assim como dados designados para
entrega a um usuário.
Item de software: Qualquer parte identificável de um produto de software em etapa
intermediária ou na etapa final de desenvolvimento.
Desenvolvimento: Todas as atividades a serem realizadas para a criação de um
produto de software.
Fase: Segmento definido do trabalho.

Como podemos observar, o conjunto de conceitos apresentados deixa claro que o

software é um produto que exige uma visão ampla, contemplando toda sua complexidade,
não podendo o controle da qualidade ser uma atividade secundária, devendo estar
presente desde o início de seu desenvolvimento até a análise final de entrega.
Comparar o software com produtos
de hardware auxilia na compreensão das
diferenças existentes entre eles e enfatiza
as características inerentes a um software.
O processo de desenvolvimento do software
apresenta diferenças fundamentais em
relação ao hardware [PRESSMAN, 2010]:
• O processo criativo do hardware
gera algo físico (por exemplo,
placas de circuitos). O desenvolvimento de software resulta em um elemento
pertencente a um sistema lógico, intangível;

10
 • O software geralmente é desenvolvido sob medida, ao contrário do hardware, no
qual o projetista tem acesso a componentes existentes que executam tarefas
definidas. O projetista do software nem sempre terá acesso a módulos prontos
para utilização e quando o faz, pode elevar o risco do produto devido a questões
de segurança;
• Os custos do software estão concentrados no desenvolvimento e não no
processo de manufatura. Isto significa que não pode ser gerido como projeto de
manufatura;
• Ao longo do tempo, o produto de software não se desgasta, mas se deteriora em
função da introdução de erros oriundos de atividades de manutenção ou
evoluções implícitas no processo que devem ser reconsideradas no modelo
original.

Desta forma, o software sofre deterioração ocasionada por diversos fatores sendo
uma característica peculiar do produto. Segundo Pressman (2010), no caso do hardware,
temos um alto índice de falhas no início do seu ciclo de vida ocasionadas por defeitos de
fabricação e projeto. Posteriormente os defeitos são corrigidos dando estabilidade nas
falhas ou mantendo-a em um nível muito baixo e suportável para a estrutura. Já no final do
ciclo de vida do produto podem surgir problemas relacionados ao envelhecimento, acúmulo
de poeira, vibração, abuso, temperaturas extremas, entre outros. Este processo pode ser
visto no gráfico apresentado na figura 1.

Figura 1 - Curva de falhas do hardware

Fonte: [PRESSMAN, 2010]

11
 Diferentemente da curva teórica de falhas do hardware, a de software leva em conta
que o software não sofre processos de envelhecimento como o hardware, pois o software
não é algo físico.No início do ciclo de vida do software, teremos problemas (bugs) que
serão ajustados no decorrer do desenvolvimento e se estabilizarão gerando uma tendência
de achatamento da curva. Notemos que esta é apenas uma teoria, já que a curva real do
índice de falhas de um software considera o processo de manutenção e mudanças.
Durante o processo de refinamento do produto ou mudanças aumenta-se,
consideravelmente, a probabilidade de inserção de novos erros, gerando picos na curva de
falhas. As sucessivas alterações do software tendem a introduzir mais erros antes da
estabilização dos erros de alterações anteriores, ocasionando a tendência crescente do
índice de falhas, conforme pode ser visto na figura 2.

Figura 2 - Curva de falhas do software

Fonte: [PRESSMAN, 2010]

Isso nos remete a uma realidade bastante complicada em

relação ao software: ele é um produto que quanto mais se conserta,
pior fica. Um software em constante manutenção pode ser tornar uma
espécie de “colcha de retalhos”, gerando pontos de falhas diversos,
difíceis de se identificar e de se ajustar. O melhor modelo é o
desenvolvimento de um novo produto após o tempo de vida útil do
mesmo, considerando-se as novas necessidades e tecnologias
disponíveis.

12
 Quando o hardware é projetado e construído, faz-se uso de catálogos de
componentes digitais. Cada circuito integrado tem um código de componente, uma função
definida e validada, uma interface bem delineada e um conjunto padrão de integração.
Depois que cada componente é selecionado, ele pode ser requisitado do estoque e
utilizado em diferentes projetos de hardware com alta confiabilidade.
No mundo do software, isso é algo que está apenas começando a ser utilizado
numa escala mais ampla, apesar de existirem alguns casos antigos de “reuso”, como as
bibliotecas de subrotinas científicas. Atualmente, a visão de reuso foi ampliada para
abranger não apenas algoritmos consagrados, mas também estruturas de dados,
interfaces gráficas e diferentes classes e componentes orientados a objetos.

1.3. O Produto Software

Na realidade atual, o software
assume um duplo papel: ele é o produto
e, ao mesmo tempo, o veículo para
entrega do produto. Esta afirmação é do
conhecido autor Roger Pressman
(Pressman, 2010), que explica que o
software, como produto, permite que o
potencial de processamento do hardware
do computador ou da rede de
computadores seja utilizado, pois
transforma informações em um amplo espectro de aplicações, das mais simples às mais
complexas. Como veículo usado para entrega do produto, o software trabalha como
elemento essencial para o controle do computador e seus recursos (como o sistema
operacional), para a comunicação e transmissão da informação (redes) e para a criação e
controle de outros programas (ferramentas e ambientes de desenvolvimento).

A importância do software na nossa sociedade continua a crescer. Ele

entrega o produto mais importante da nossa época: a informação.

13
 O programador solitário de antigamente foi substituído por uma equipe de
especialistas de software, com cada um se concentrando numa parte da tecnologia
necessária para produzir uma aplicação complexa. Mas, os mesmos questionamentos
feitos ao “programador solitário” continuam sendo feitos quando modernos sistemas
baseados em computador estão sendo construídos:
• Por que se leva tanto tempo para concluir um software?

• Por que os custos de desenvolvimento são tão altos?

• Por que não podemos achar todos os erros antes de entregar o software aos
clientes?

• Por que continuamos a ter dificuldade em avaliar o seu progresso enquanto o

software é desenvolvido?

Essas perguntas são manifestações da preocupação sobre o software e a maneira

pela qual ele é desenvolvido. E, como vimos, questões como estas levaram à criação e
adoção da Engenharia de Software.

Assim, caro aluno, o desenvolvimento de software deve ser feito cercando todo o
processo de bastante cuidado. Numa abordagem mais madura do processo de
desenvolvimento, podemos considerar diversos fatores, dentre os quais podemos citar:
• Há similaridades e diferenças entre os projetos de software, assim os modelos
definidos não são aplicáveis a todos os projetos;
• Existe uma estreita relação entre o processo de desenvolvimento e manutenção,
e o produto de software, sendo a escolha do processo fundamental para o
alcance das características desejadas do produto;
• Para uma boa visibilidade do processo é essencial o estabelecimento de critérios
de medição apoiados em objetivos e modelos apropriados;
• O software é um processo experimental, no qual o aprendizado com
realimentação para o processo de desenvolvimento e manutenção dos produtos
é atividade natural;
• Avaliação e realimentação repetitiva são necessárias para o aprendizado e
inclusão de melhorias, além do controle individual de projetos;
• Gerir, registrar e distribuir corretamente as experiências (ou cases) permitirá a
construção de uma competência de software na organização;
14
 • Uma variedade de experiências em relação ao processo, produto, recursos,
defeitos e modelos de qualidade podem formar uma base de experiências
atualizável;
• O processo de desenvolvimento e manutenção de software deve considerar a
reutilização de experiências com definições de quando, como e onde reutilizar;
• As experiências podem ser armazenadas e disponibilizadas de formas variadas
e integradas em repositórios de informações relacionando a similaridade de
projetos, produtos, características, fenômenos e outros.

1.4. Aplicações do Software

O software pode ser aplicado em qualquer situação para a qual um conjunto

previamente especializado de procedimentos (um algoritmo) tenha sido definido.
Exemplos de áreas de aplicações de software são:
• Software de sistema: coleção de programas para
servir outros programas (compiladores, editores,
utilitários para gestão de arquivos, componentes de
sistemas operacionais, etc). Estes tipos de programas
se caracterizam por manterem uma interação intensa
com o hardware.
• Software de tempo real: monitora, analisa e controla
eventos do mundo real à medida em que eles ocorrem.
É o software que gerencia os recursos de um sistema computacional, com o
objetivo de garantir que todos os eventos sejam atendidos dentro de suas
restrições de tempo e sejam gerenciados da forma mais eficiente
possível. Exemplos: sistema de radar aeroespacial, teclado que gera inputs de
teclas pressionadas para um sistema microprocessado, sensor de temperatura
que gera um input para um microcontrolador, sistema de controle de voos, dentre
outros.
• Software comercial: maior área de aplicação de software. Estão na categoria de
software de aplicação que resolvem necessidades específicas do negócio, como
controle de reservas de voos, sistemas de pagamento, de controle de estoque,
etc.

15
• Software científico e de engenharia:
caracterizado por algoritmos que “processam
números” e realizam operações matemáticas
e cálculos mais complexos (astronomia,
análise automotiva de tensões, manufatura
automatizada, previsão de tempo,
simuladores, etc).
• Software embutido: produtos “inteligentes”. São programas armazenados em
ROMs – Read Only Memories, como controle
de teclado para um forno de microondas,
funções digitais em um automóvel – controle
de combustível, mostradores do painel,
sistemas de frenagem, etc. Estes programas
são chamados de firmware, que são
programas gravados no hardware que controlam as funções dos dispositivos
eletrônicos.
• Software para web: as páginas da web
recuperadas por um browser constituem software
que incorpora instruções executáveis na forma de
scripts, permitindo a inclusão de elementos
dinâmicos, animações, acesso a banco de dados
e diversas características que fazem as páginas
HTML estáticas de antigamente parecerem apenas folhas de um livro em papel.
• Software para computadores pessoais: esse mercado “explodiu” nos últimos
anos, englobando uma enorme lista de aplicativos para os desktops e notebooks,
como processadores de texto, planilhas, aplicações
gráficas, aplicações multimídia, etc.
• Software para inteligência artificial: faz uso de
algoritmos não numéricos para resolver problemas
complexos, como sistemas de reconhecimento de
padrões (de imagem e de voz), redes neurais artificiais,
sistemas de controle de robôs, etc.

16
1.5. Mitos do Software
Muitas crenças ou mitos foram
criados acerca de acontecimentos ligados
ao processo de desenvolvimento de
software, desde os primeiros programas.
Mas são informações, muitas vezes,
traiçoeiras. Os mitos podem parecer
verdadeiros, trazer informações sobre fatos
razoáveis e muitas vezes serem divulgados
por pessoas que “entendem do assunto”.
Hoje os profissionais que conhecem a Fonte: http://biosferams.org/2011/07/10-mitos-
sobre-computadores/
Engenharia de Software reconhecem os
mitos pelo o que eles são na realidade: afirmações enganosas que já causaram prejuízo a
diversos profissionais.
Para que você, caro aluno, não seja enganado pelos mitos, pois eles ainda estão
presentes em nosso meio, vamos apresentá-los a você nesta seção, com base na
abordagem de Pressman (2010).

Mitos Administrativos ou Gerenciais

Gerentes estão frequentemente sob pressão para manter o orçamento, cumprir prazos e
aumentar a qualidade. Devido a isso, é comum agarrarem-se a mitos que diminuem
(temporariamente) essa pressão.

• Mito:
Já temos o manual repleto de padrões e procedimentos para a construção do
software. Isso não oferecerá ao meu pessoal tudo o que eles precisam saber?
• Realidade:
- O manual existe. Mas é usado?
- Os profissionais sabem da sua existência?
- Ele reflete as práticas mais modernas de engenharia de software?
- É completo?
- Está voltado p/ melhorar o prazo de entrega focado na qualidade?
Na maioria dos casos a resposta é “não”.
17
 • Mito:
Meu pessoal tem ferramentas de software de última geração; afinal de contas lhes
compramos os mais novos computadores.
• Realidade:
É necessário mais do que computadores de última geração para fazer um
desenvolvimento de software de alta qualidade. Ferramentas Case são mais
importantes. Contudo, a maioria dos desenvolvedores não as usam ainda, ou
subutilizam-nas.

• Mito:
Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e
tirar o atraso.
• Realidade:
Desenvolvimento de software não é um processo mecânico. Quando novas pessoas
são adicionadas, pessoas que estavam trabalhando devem gastar tempo educando
os novatos. Pessoas podem ser adicionadas, mas de um modo planejado e bem
coordenado.

• Mito:
Se decidirmos terceirizar um projeto vamos poder relaxar e deixar que a empresa o
elabore.
• Realidade:
Se uma organização não sabe como gerir e controlar seus projetos de software,
terceirizá-los certamente trará outros problemas, talvez maiores.

Mitos do Cliente

Um cliente que encomenda um software pode ser uma pessoa na mesa vizinha, um grupo
técnico em outra sala, o departamento de promoção/vendas ou uma empresa que
encomendou software sob contrato.

18
O cliente acredita em mitos de software, geralmente porque os gerentes e profissionais de
software fazem pouco para corrigir essa desinformação. Mitos levam a falsas expectativas
(pelo cliente) e à insatisfação com o desenvolvedor.

• Mito:
Uma declaração geral dos objetivos é suficiente para se começar a escrever
programas – podemos preencher os detalhes mais tarde.
• Realidade:
Uma definição inicial ruim é a principal causa de falhas nos esforços de software. É
essencial uma descrição formal do domínio da informação, função, comportamento,
performance, interface, restrições de projeto e critérios de validação. Necessária
intensa comunicação entre cliente e desenvolvedor.

• Mito:
Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser
facilmente acomodadas, porque o software é flexível.
• Realidade:
É verdade que os requisitos de software mudam, mas o impacto das mudanças
varia de acordo com o momento na qual ela ocorre. Em termos de custos, na fase
de definição (x1), na fase de desenvolvimento (1,5 a 6x) e na fase de manutenção
(60 a 100x). Deve ser dada muita atenção às definições iniciais.

Mitos do Profissional

Os mitos que ainda têm crédito entre os

profissionais de software sobreviveram a mais de
50 anos de cultura de programação. No início a
programação era vista como uma forma de arte.

• Mito:
Assim que escrevermos o programa e o
colocarmos em funcionamento nosso Fonte:http://www.nic.br/imprensa/clipping/20
trabalho estará completo. 11/midia628.htm

19
• Realidade:
Estudos mostram que, entre 60% a 80%, de todo o esforço gasto em um programa
serão despendidos depois dele ter sido entregue, pela primeira vez, para o usuário.

• Mito:
Enquanto não tiver o programa “funcionando”, eu não terei realmente nenhuma
maneira de avaliar sua qualidade.
• Realidade:
Um dos mecanismos mais efetivos para garantia de qualidade do software pode ser
aplicado desde o seu início – a Revisão Técnica Formal (um filtro de qualidade).

• Mito:
A única coisa a ser entregue em um projeto bem-sucedido é o programa
funcionando.
• Realidade:
O programa executável é uma das partes da configuração do software. A
documentação é um fator importante também (alicerce para o desenvolvimento e
guia para a manutenção).

• Mito:
A engenharia de software vai nos fazer criar documentação volumosa e
desnecessária que certamente nos atrasará.
• Realidade:
A engenharia de software não se relaciona à criação de documentos. Refere-se à
criação de qualidade. Melhor qualidade leva à redução de retrabalho. E menor
retrabalho resulta em tempos de entrega mais rápidos.

Conclusão sobre os Mitos:

Profissionais de software devem reconhecer a falácia dos mitos. O
reconhecimento das realidades do software é o primeiro passo em direção
à formulação de soluções práticas e eficientes para a Engenharia de
Software.

20
Exercícios do Capítulo 1

1) Qual das questões abaixo não é mais uma das grandes preocupações de um
engenheiro de software?
a) Por que normalmente se gasta tanto tempo para desenvolver software?
b) Por que, via de regra, software custa tão caro?
c) Por que quase sempre não se consegue remover todos os erros do software
antes da sua entrega?
d) Por que hardware é tão caro?

2) Software é um produto que pode ser manufaturado usando as mesmas tecnologias

usadas para outros artefatos de engenharia.
a) Verdadeiro
b) Falso

3) Software deteriora-se ao invés de se desgastar porque:

a) Software “sofre” quando exposto a ambientes “hostis”
b) Defeitos são mais prováveis de surgir quando o software é usado várias vezes
c) Mudanças frequentes aumentam a probabilidade de se introduzir erros no software
d) Componentes de reposição de sofware são difíceis de se encontrar no mercado

4) Atividades “guarda-chuva” de engenharia de software são aplicadas somente durante

as fases iniciais do desenvolvimento de software:
a) Verdadeiro
b) Falso

21
5) O que caracterizou a chamada “crise do software”?

6) Conforme vimos, Engenharia de Software é uma disciplina da Engenharia que se

ocupa de todos os aspectos da produção de software. Seu principal objetivo é
fornecer uma estrutura metodológica para a construção de software com alta
qualidade. O que é necessário para que isso aconteça?

7) Normalmente, para o leigo, software se constitui no “código fonte + código

executável”. Vimos que para a Engenharia de Software, o conceito de software é
algo mais abrangente. Como Pressman conceitua software?

8) O processo de desenvolvimento do software apresenta diferenças fundamentais

em relação ao hardware. Cite algumas dessas diferenças.

9) Faça um esboço das curvas de taxa de falhas do hardware e do software. Explique

as diferenças entre as curvas.

22
 Capítulo 2 – Processo de Software
Caro aluno, neste capítulo descreveremos o que é um processo de software,
mostraremos as camadas em que a Engenharia de Software se divide, descreveremos
os padrões de processo, a avaliação e as ferramentas que apoiam o processo.

2.1. Conceitos Básicos de Processo de Software

Caro aluno, todo projeto de software inicia-se a partir de alguma necessidade do
negócio. Assim que esta necessidade é identificada, esta costuma ser expressa de forma
informal, através de uma conversa. Mas esta informalidade deve parar por aí. Até mesmo a
especificação da necessidade do cliente é abrangida pelos métodos e técnicas da
Engenharia de Software. E este é um processo bastante complexo. Então vamos começar
a entendê-lo, conhecendo exatamente do que se trata um “processo de software”.

Para que as necessidades da empresa ou de um cliente possa se transformar numa

solução de software, todo o diálogo e a interação entre usuários, projetistas, ferramentas
de desenvolvimento e tecnologias devem ser transformados num processo.

Assim, processo de software é um arcabouço (framework) das

tarefas requeridas para se construir um software de alta qualidade.

Mas, caro aluno, você pode estar se perguntando: processo e engenharia de

software são a mesma coisa?

A resposta é “sim” e “não”. Processo de software define a abordagem que é adotada

quando o software é elaborado. A Engenharia de Software engloba também as tecnologias
que constituem um processo, como métodos, técnicas e ferramentas de desenvolvimento.
Assim, a Engenharia de Software engloba os processos de software.

Podemos definir Engenharia de Software como um processo que envolve a criação

e a utilização de sólidos princípios de engenharia a fim de obter software com as
características:

23
 de alta qualidade
produzido de maneira econômica
que seja confiável
que trabalhe eficientemente em máquinas reais
que seja entregue no prazo
que satisfaça o cliente

A Engenharia de Software é uma tecnologia em ca

camadas, apoiada
fundamentalmente num compromisso organizacional com a qualidade,
qualidade como mostra a
figura 3. Nesta abordagem, podemos
podemos observar que o alicerce da Engenharia de Software é
a camada de processo, que funciona como um adesivo que mantém unidas as camadas
ligadas à tecnologia.

Figura 3
Engenharia de Software: uma tecnologia em camadas

O processo forma uma base para o controle gerencial de projetos de

software e estabelece o contexto no qual os métodos e as técnicas são
aplicados, os produtos do trabalho são produzidos, os marcos são
estabelecidos, a qualidade é assegurada e as modificações
modificações adequadamente
geridas.
Os métodos fornecem as técnicas de “como fazer” a construção de
software. Abrangem um amplo conjunto de tarefas que incluem comunicação,
análise de requisitos, modelagem de projeto, construção de programas, testes
e manutenção.
As ferramentas fornecem apoio automatizado ou semi-automatizado
semi
para o processo e seus métodos.

24
 Para que a Engenharia de Software possa ser aplicada como uma abordagem
disciplinada para o desenvolvimento, operação e manutenção de um software, um
processo deve ser definido. De uma forma geral, um processo é caracterizado por fases:
1. Fase de Definição
2. Fase de Desenvolvimento
3. Fase de Manutenção

1. Fase de Definição: esta fase se concentra no “quê” o sistema de software irá

realizar, isto é, identifica:
• que informação deve ser processada
• que função e desempenho são desejados
• que comportamento deve ser esperado do sistema
• que interfaces devem ser estabelecidas
• que restrições de projeto existem
• que critérios de validação são necessários

Nessa fase, os requisitos-chave do sistema e do software são identificados. Esta

fase engloba 3 importantes etapas:
i. Engenharia de sistemas ou de informação
ii. Planejamento do projeto
iii. Análise de requisitos

2. Fase de Desenvolvimento: esta fase focaliza “como” o desenvolvimento será

realizado, isto é , define:
• como os dados devem ser estruturados
• como as funções devem ser implementadas
• como os detalhes procedimentais devem ser implementados
• como as interfaces devem ser caracterizadas
• como o projeto deve ser traduzido em uma linguagem de programação
• como o teste vai ser realizado

25
 Nesta fase, 3 etapas técnicas específicas ocorrerão:
i. Projeto do Software
ii. Geração de Código
iii. Teste de Software

3. Fase de Manutenção: esta fase tem como alvo as modificações e manutenções

que o software sofrerá. Quatro tipos de modificações são encontradas durante essa fase:
• Manutenção Corretiva: modifica o
software para corrigir defeitos
• Manutenção Adaptativa: modifica o
software para acomodar mudanças no
seu ambiente externo (processador,
sistema operacional, etc)
• Manutenção de Aperfeiçoamento:
aprimora o software além dos requisitos
funcionais originais (cliente/usuário
reconhece e solicita funcionalidades Fonte:
http://www.clickutil.com.br/desenvolvimento
adicionais que trarão benefícios, à
medida que o software é usado).
• Manutenção Preventiva: faz modificações nos programas de modo que eles
possam ser mais facilmente corrigidos, adaptados e melhorados.

Estas 3 fases são complementadas por atividades “guarda-chuva”:

Controle e Rastreamento do Projeto
Gestão de Riscos
Revisões Técnicas Formais
Garantia de Qualidade
Gestão de Configuração de Software
Produção e Preparação de Produtos do Trabalho (documentos)
Gestão de Reusabilidade
Medição

Essas atividades são aplicadas ao longo do processo de software.

26
2.2. Padrões, Avaliação e Tecnologias de Processo
De acordo com Pressman (2010), um processo de software pode ser definido como
uma coleção de padrões que definem um conjunto de atividades, ações, tarefas de
trabalho e produtos de trabalho necessários para o desenvolvimento de software de
computador.
Em termos gerais, um padrão de processo nos fornece um gabarito que permite
que sejam listadas as características mais importantes do processo de software. Mas é
interessante notar, caro aluno, que uma equipe de desenvolvimento pode construir, pela
combinação de padrões, um processo que melhor satisfaça às necessidades do projeto.
Descrever um padrão de projeto é uma tarefa muito importante, pois permite se
identificar particularidades que facilitem a comparação entre os padrões, auxiliando na
decisão de escolha por um padrão específico. Gamma et al (1994) propõem um gabarito
para esta definição, dividido em seções, como apresentado a seguir:
• Nome do padrão e Classificação: o nome é muito importante para um padrão,
pois deve indicar a essência do padrão em poucas palavras.
• Intenção do padrão: descreve o que o padrão faz, qual a sua intenção e qual
problema o padrão se propõe a resolver.
• Também conhecido como: um outro nome pelo qual o padrão é conhecido, caso
exista.
• Motivação: um exemplo de problema de projeto e como a utilização do padrão
resolve este problema.
• Aplicabilidade: condições em que o padrão pode ser aplicado, exemplo de
situação em que o padrão é aplicado e como identificar essas situações.
• Estrutura: uma representação gráfica das classes no padrão utilizando uma
linguagem de modelagem, em que possam ser representados os relacionamentos
entre os objetos e sequências de requisições.
• Participantes: apresenta as classes e objetos que fazem parte do padrão e quais
as suas responsabilidades.
• Colaborações: como os participantes colaboram para atender as suas
responsabilidades.
• Consequências: descreve como o padrão alcança seus objetivos, quais as
decisões e resultados de usar o padrão e que aspectos da estrutura do sistema
podem ser variados independentemente.
27
 • Implementação: que detalhes de implementação devem ser observados se o
padrão for implementado. Deve ser observado se existem detalhes específicos para
uma determinada linguagem.
• Exemplo de código: um exemplo de código que mostre como o padrão deve ser
implementado em alguma linguagem.
• Usos conhecidos: exemplos do padrão encontrados em sistemas reais.
• Padrões relacionados: padrões que se assemelham a este padrão e quais as
diferenças. Apresenta também outros padrões que podem ser utilizados em
conjunto.

A existência ou a simples escolha de um processo de software não garante que o

software será entregue no prazo, que ele atenda as necessidades do projeto e possua as
características técnicas que garantirão sua qualidade no longo prazo. Os padrões de
processo precisam estar ligados de forma sólida às práticas da Engenharia de Software.
Além disso, o processo em si deve ser avaliado para garantir que ele satisfaça a um
conjunto de critérios essenciais para o desenvolvimento bem sucedido. O relacionamento
entre o processo de software e os métodos aplicados para sua avaliação e melhoria é
mostrado na figura 4.

Processo de Software

É examinado por

Identifica Identifica capacidade

modificações para e risco de
Avaliação de
Processo de Software

Conduz a
Melhoria de Processo Determinação da
de Software Capacidade
Motiva

Figura 4
Processo de Software, Avaliação e Melhoria de Processo

28
 Como vimos, os modelos de processo podem e devem ser adaptados para o uso de
uma determinada equipe de projeto de software. Para que se possa conseguir isso, foram
desenvolvidas diversas ferramentas de tecnologia de processo de forma a ajudar as
organizações a analisar o processo que utiliza, organizar as tarefas de trabalho, controlar e
monitorar o progresso do desenvolvimento e ainda gerenciar sua qualidade técnica.
Os componentes da equipe de desenvolvimento podem utilizar as ferramentas para
desenvolver um checklist das tarefas de trabalho a seu cargo. As ferramentas de
tecnologia de processo também podem ser utilizadas para coordenar e gerenciar o uso de
outras ferramentas de engenharia de software apoiadas por computador adequadas às
diversas tarefas de trabalho.

Como vimos neste capítulo, a Engenharia de Software é uma disciplina que

integra processo, métodos e ferramentas para o desenvolvimento de projetos de
software. Há diversos modelos de processo, mas todos possuem algumas
características em comum, definindo um conjunto de atividades de arcabouço,
uma coleção de tarefas para que se consiga realizar as atividades, produtos de
trabalho produzidos nas tarefas e um conjunto de atividades guarda-chuva que
apóiam as atividades de todo o processo.

Vimos, também, que padrões de processo podem ser utilizados para definir
as características de um processo.

29
(Animação 1) Casa Segura – Como o Projeto Começa
A Cena: Sala de reunião na empresa CPI, uma empresa (fictícia) que fabrica produtos de
consumo para uso residencial e comercial.

Os personagens: Roberto, gerente sênior, desenvolvimento de produtos; Vanessa, gerente de

marketing; Paulo, gerente de engenharia; Oscar, vice-presidente executivo, desenvolvimento
de negócios.

Locutor (voz): Caros alunos, vamos dar início a uma sequência de animações para ajudá-lo a
entender como funciona todo o ciclo de desenvolvimento de um projeto de software, desde a
sua concepção até a entrega do produto aos clientes. Estas animações referem-se ao projeto
“Casa Segura”, proposto por Roger Pressman, em seu livro Engenharia de Software, 6ª edição.

A conversa:
Oscar: Tudo bem, Paulo, o que é isto que eu ouvi sobre vocês desenvolverem o quê? Uma caixa
sem-fio universal genérica?

Paulo: É muito interessante, quase do tamanho de uma caixa de fósforo pequena. Pode-se ligá-
la a sensores de todas as naturezas, a uma câmera digital, a praticamente qualquer coisa. Usa o
protocolo sem fio 802.11b. Permite acessar a saída de um dispositivo sem fio. Estamos
pensando que ela vai levar a toda uma nova geração de produtos.

Oscar: Você concorda, Roberto?

Roberto: Sim. De fato, com as vendas tão achatadas como elas têm estado este ano,
precisamos de algo novo. Vanessa e eu estivemos fazendo um pouco de pesquisa de mercado e
achamos que temos uma linha de produtos que pode ser grande.

Oscar: De que tamanho…Acima do nível mínimo?

Roberto (evitando um comprometimento direto): Conte a ele a nossa ideia, Vanessa.

Vanessa: É toda uma geração do que chamamos de “produtos de gestão doméstica”. Nós a
chamamos de CasaSegura. Eles usam a nossa interface sem fio, fornecendo a usuários
domésticos ou de pequenos negócios um sistema que é controlado pelo seu PC – segurança
residencial, vigilância residencial, controle de eletrodomésticos e dispositivos. Você sabe, ligar o
ar condicionado da residência enquanto está indo para casa, essa espécie de coisa.

Paulo (entrando na conversa): A engenharia fez um estudo de viabilidade técnica dessa ideia,
Oscar. É exequível e tem baixo custo de fabricação. A maior parte do hardware é de prateleira.
Software já é mais complicado, mas nada que não possamos fazer.

Oscar: Interessante. Agora, eu perguntei sobre o nível mínimo.

Roberto: Os PCs têm penetrado 60% de todos os domicílios do país. Se pudéssemos dar a essa
coisa o preço adequado, ela poderia ser um eletrodoméstico campeão. Ninguém mais tem a
nossa caixa sem fio – ela é de nossa propriedade intelectual. Vamos ter uma vantagem de dois
anos sobre a concorrência. Receita? Pode ser tanto quanto 30 a 40 milhões de dólares no
segundo ano.
30
Oscar (sorrindo): Vamos levar isso para o nível acima. Eu estou interessado.
Exercícios do Capítulo 2

1) Processos de software podem ser construídos de modelos pré-existentes

objetivando se adequar às necessidades de um determinado projeto
a) Verdadeiro
b) Falso

2) A essência da prática da engenharia de software pode ser resumida em

compreender o problema, planejar a solução, executar o plano e examinar o
resultado.
a) Verdadeiro
b) Falso

3) Qual dos itens listados abaixo não se constitui numa das camadas da engenharia
de software?
a) Processo
b) Manufatura
c) Métodos
d) Ferramentas

4) Cite que tipos de manutenção um software pode sofrer.

5) As atividades “guarda-chuva” dão “cobertura” para as fases envolvidas na

produção de software. Cite algumas dessas atividades.

6) Há uma ilusão por parte de alguns desenvolvedores que basta selecionar um

modelo de processo e aplicá-lo para se obter software de qualidade, dentro do
prazo e custos estabelecidos. Comente sobre esse “mito”.

31
 Capítulo 3 – Modelos de Processo
Caro aluno,, neste capítulo definiremos o que é ciclo de vida
vida de software,
software quais
suas principais etapas e descreveremos os principais modelos de processo de software:
Modelo em Cascata, Modelos Evolucionários (Modelo de Prototipagem, Modelo Espiral
e Modelo Concorrente), Modelos Incrementais (Modelo RAD e Modelo Incremental),
In
Modelo Baseado em Componentes,
Componentes Modelo de Métodos Formais, Processo Unificado e
Métodos Ágeis de Desenvolvimento.

3.1. Ciclo de Vida e Modelos de Processo

O ciclo de vida de um software descreve as fases pelas quais o software passa
desde a sua concepção
oncepção até a descontinuidade de seu uso.
uso O conceito de ciclo de vida de
um software é muitas vezes confundido com o de modelo de processo,
processo mas são conceitos
bem diferentes, como veremos a seguir.
Existem várias propostas e denominações para as fases do
do ciclo de vida de um
software. Nesta nossa abordagem, vamos trabalhar com 4 fases, que são as mais típicas
em diversos ciclos de vida,, de acordo com a proposta de Leite (2007).
(2007). Cada fase inclui um
conjunto de atividades ou disciplinas que devem ser realizadas
re adas pelas pelos envolvidos no
processo de desenvolvimento.. Essas fases são:
1. Fase de Definição
2. Fase de Desenvolvimento
3. Fase de Operação
4. Fase de Retirada

Definição Desenvolvimento Operação Retirada

1. Fase de Definição

A fase de definição do software ocorre em conjunto com outras atividades como a

BPM – Business Process Modeling ou Modelagem de Processos de Negócios
egócios e Análise de
32
Sistemas. Nestas atividades,, diversos profissionais fazem o levantamento da situação
atual em busca da identificação de problemas,
problemas para que possam elaborar propostas de
solução
o de sistemas computacionais que os resolvam.. Dentre as propostas apresentadas,
deve-se fazer um Estudo
studo de Viabilidade,
V incluindo a Análise
nálise de Custo-Benefício,
Custo para se
decidir qual solução será a escolhida.
O resultado desta atividade deve incluir a decisão
decisã se o sistema será adquirido ou
desenvolvido,, indicando informações sobre necessidades de hardware, ferramentas de
software, pessoal, procedimentos, informação e documentação.
Caso haja uma decisão pelo desenvolvimento
mento do sistema, no escopo da Engenharia
de Software, torna-se
se essencial elaborar o documento de Proposta de Desenvolvimento
D de
Software, que pode ser a base de um Contrato de Desenvolvimento.
Nesta fase, os profissionais devem realizar uma tarefa de extrema importância, que
é fazer o levantamento dos Requisitos
R de Software e Modelos de Domínio
omínio. Os requisitos
são fundamentais para que o engenheiro de software possa elaborar um Plano de
Desenvolvimento de Software,, indicando em detalhes os recursos necessários (humanos e
materiais), bem como as estimativas
estimativas de prazos e custos (cronograma e orçamento).

Definição Desenvolvimento Operação Retirada

2. Fase de Desenvolvimento

A fase de desenvolvimento ou de produção do software inclui

inclui todas as atividades
que têm
m por objetivo a construção do produto. Esta
Esta fase inclui as atividades de projeto,
projeto
implementação, verificação e validação do software.
Projeto
A atividade de projeto compreende todo o esforço de concepção e
modelagem que tem
tem por objetivo descrever como o software
soft será
implementado. O projeto inclui:
o Projeto conceitual:
conceitual envolve a elaboração das ideias
ide e conceitos
básicos que determinam os elementos fundamentais do software a ser
desenvolvido.
33
 o Projeto da interface com o usuário: envolve a elaboração das formas
como o usuário vai interagir para realizar suas tarefas, a escolha dos
objetos de interfaces (botões, menus, caixas de texto, etc.), o layout de
janelas e telas, dentre outros; a interface deve garantir uma
usabilidade satisfatória do software e é um fator fundamental de
sucesso do software.
o Projeto da arquitetura do software: se refere à elaboração de uma
visão macroscópica do software em relação aos componentes que
interagem entre si. São exemplos de visões arquitetônicas, a visão
conceitual, visão de módulos, visão de código e visão de execução.
o Projeto dos algoritmos e estruturas de dados: objetiva determinar, de
maneira independente da linguagem de programação a ser adotada,
as soluções algorítmicas e as estruturas de dados associados.
Implementação
A implementação envolve as atividades de codificação, compilação,
integração e testes. A codificação visa traduzir o projeto num programa
utilizando linguagens e ferramentas adequadas. A codificação deve refletir a
estrutura e o comportamento descrito no projeto da arquitetura do software.
Os testes podem ser iniciados durante a fase de implementação. A
depuração de erros ocorre durante a programação utilizando técnicas e
ferramentas adequadas. É fundamental que se adote um controle e
gerenciamento de versões para que se tenha total controle de tudo o que
está sendo codificado.
Verificação e Validação
São atividades que se destinam a mostrar que o sistema está de acordo com
a especificação e que ele atende às expectativas de clientes e usuários. A
validação visa assegurar que o programa está fazendo o que foi definido na
sua especificação. A verificação visa certificar se o programa está correto,
isto é, se não possui erros de execução e está fazendo de forma correta suas
funcionalidades. Existem diferentes formas de verificação e validação. Os
testes de correção, desempenho, confiabilidade, robustez, usabilidade, dentre
outros, podem ser usados para avaliar diversos fatores de qualidade a partir
da execução do software.

34
 Definição Desenvolvimento Operação Retirada

3. Fase de Operação

A fase de operação envolve diferentes tipos de atividades:

• Distribuição e entrega
• Instalação e configuração
figuração
• Utilização
• Manutenção

A distribuição e entrega pode ser feita diretamente pelo desenvolvedor (em caso de
software personalizado) ou em um pacote a ser vendido em prateleiras de lojas ou para ser
baixado pela internet.
O processo de instalação e configuração, normalmente, pode ser feito com a ajuda
de software de instalação disponibilizados pelos fabricantes dos ambientes operacionais.
A utilização é a efetiva entrada em operação do software.
are. A qualidade da utilização
reflete a usabilidade do software.
tware.
A manutenção
enção normalmente ocorre de forma corretiva
corretiva, adaptativa, de
aperfeiçoamento e evolutiva. As
A manutenções podem ser relativas à resolução de
problemas referentes à qualidade do software (falhas, baixo desempenho, baixa
usabilidade, falta de confiabilidade,
fiabilidade, etc.),
etc.) à produção de novas versões do software de
forma a atender aos novos requisitos dos clientes, ou adaptar-se
adaptar se às novas tecnologias que
surgem (hardware, plataformas operacionais, novas linguagens e paradigmas,
paradigmas etc).
Mudanças no domínio de
e aplicação implicam em novos requisitos e incorporação de novas
funcionalidades. Surgimento de novas tecnologias de software e hardware e mudanças
para uma plataforma mais avançada também requerem evolução.

35
 Definição Desenvolvimento Operação Retirada

4. Fase de retirada

A fase de retirada ou desuso de um software é um grande desafio para os tempos

atuais. Há diversos sistemas que estão em funcionamento em empresas,
empresas que possuem
ótimos níveis de confiabilidade e de correção. No entanto, estes sistesmas precisam
evoluir para novas plataformas operacionais ou para permitirem a incorporação de novos
requisitos e funcionalidades.. A retirada desses sistemas legados em
e uma empresa é
sempre uma decisão difícil: como se desfazer daquilo que é confiável e ao qual os
funcionários estão acostumados, após
após anos de treinamento e utilização?
Nestes casos, processos
rocessos de reengenharia podem ser aplicados para viabilizar a
transição ou a migração de um software legado para um novo software de forma a
proporcionar uma retirada mais suave.
Para resolver problemas
lemas reais,
r um engenheiro de software deve incorporar uma
estratégia de desenvolvimento que abrange as camadas de processo, métodos e
ferramentas
erramentas e as fases genéricas da Engenharia de Software. Essa
ssa estratégia é definida
como Modelo de Processo.
O modelo de processo é escolhido com base:
• na natureza do projeto e da aplicação a ser desenvolvida
• nos métodos e ferramentas a serem utilizados
• nos controles e produtos que precisam ser entregues
Alguns Modelos de Processo incluem:
• Modelo em Cascata
• Modelo de Prototipação
otipação
• Modelo RAD
• Modelo Incremental
• Modelo Espiral
• Modelo de Desenvolvimento Baseado em Componentes
• Modelo de Desenvolvimento Concorrente
• Modelo de Métodos Formais
• Modelos de Processos Ágeis
36
 No que se segue estes modelos serão agrupados em categorias e detalhados, de
forma que você, caro aluno, possa conhecer suas características, potencialidades,
limitações e aplicações mais adequadas.

3.2. Modelos Prescritivos de Processo

Processos prescritivos são uma categoria que engloba os processos que possuem
pontos observáveis que a cada passo podem ser verificados e classificados como válidos
ou sujeitos a ajustes.
Enquanto um modelo descritivo retrata como um processo é executado, um modelo
prescritivo retrata como um processo deveria ser executado. Assim, um modelo prescritivo
é uma recomendação que pode ser adaptada ou melhorada pela empresa/equipe de
software que for adotá-la.
Os instrumentos prescritivos do processo de planejamento estratégico explicitam o
que deve ser feito pela organização para se direcionar o esforço de desenvolvimento de
software. Um modelo prescritivo de processo atua como complemento com conjuntos
explícitos de tarefas explícitas para o desenvolvimento. Cada modelo prescritivo de
processo também prescreve um fluxo de trabalho ou maneira como os elementos se inter-
relacionam.
Há vários modelos que são classificados nesta categoria:
• Modelo em Cascata
• Modelos Evolucionários
o Modelo de Prototipagem
o Modelo Espiral
o Modelo Concorrente
• Modelos Incrementais
o Modelo RAD
o Modelo Incremental
• Modelo Baseado em Componentes
• Modelo de Métodos Formais
• Processo Unificado

37
(Animação 2) Casa Segura – Seleção de um Modelo de Processo, Parte I
A cena: Sala de reuniões do grupo de engenharia de software na empresa CPI, uma empresa
(fictícia) que fabrica produtos de consumo para uso residencial e comercial.

Os personagens : Paulo, gerente de engenharia; Douglas, gerente de engenharia de software;

Júnior, membro da equipe de software; Viviane, membro da equipe de software e Edson,
membro da equipe de software.

A conversa:
Paulo: Então, vamos recapitular. Eu gastei algum tempo discutindo a linha de produtos CasaSegura como a
vemos no momento. Sem dúvida, temos muito trabalho a fazer para simplesmente definir a coisas, mas eu
gostaria que vocês começassem a pensar como vão abordar a parte do software desse projeto.

Douglas: Parece que temos sido bastante desorganizados em nossa abordagem de software no passado.

Edson: Eu não sei, Douglas. Sempre conseguimos despachar o produto.

Douglas: Isso é verdade, mas não sem muito sofrimento, e esse projeto parece ser maior e mais complexo
do que qualquer coisa que tenhamos feito no passado.

Júnior: Não parece tão difícil, mas eu concordo... Nossa abordagem ad hoc para os projetos anteriores não
vai funcionar aqui, particularmente se tivermos um prazo muito apertado.

Douglas (sorrindo): Eu quero ser um pouco mais profissional na nossa abordagem. Fui a um curso rápido
na última semana e aprendi bastante sobre engenharia de software... boa coisa. Precisamos de um
processo aqui.

Douglas: Dê uma chance antes de ficar bravo comigo. Eis o que eu quero dizer. [Douglas prossegue
descrevendo o arcabouço de processo e os modelos prescritivos de processo apresentados até agora.]

Douglas: Assim, de qualquer modo, parece que um modelo em cascata não é adequado para nós... ele
considera que tenhamos todos os requisitos antecipadamente e, conhecendo esta empresa, isso não é
provável.

Viviane: Sim, e aquele modelo RAD parece orientado demais à tecnologia da informação... provavelmente
bom para construir um sistema de controle de estoque ou alguma outra coisa, mas não é adequado para o
CasaSegura.

Douglas: Eu concordo.

Edson: Essa abordagem de prototipagem parece boa. Muito parecida com o que nós fazemos aqui.

Viviane: Esse é que é o problema. Estou preocupado que ela não vai nos dar estrutura suficiente.

Douglas: Não se preocupe, temos muitas outras opções e eu quero que vocês escolham o que é melhor
para a equipe e para o projeto.

Júnior (franzindo a testa): Meu trabalho é construir programas de computador, não ficar manipulando
papel.

38
3.3. Modelo em Cascata
No modelo em cascata, também conhecido como ciclo de vida clássico, o processo
de desenvolvimento de software é visto como uma abordagem sistemática e sequencial
sequencia
que começa com a especificação dos requisitos do cliente e progride seguindo as etapas
de planejamento, modelagem, construção e implantação do sistema, conforme ilustra a
figura 5,, culminando na manutenção progressiva do produto entregue.
entregue

Especificação Planejamento Modelagem Construção Implantação

•Iniciação do Estimativas
•Estimativas •Análise •Codificação •Entrega
projeto Cronogramação
•Cronogramação •Projeto •Teste •Manutenção
•Levantamento Monitoração
•Monitoração •Feedback
de requisitos

Figura 5
Modelo em Cascata

Este modelo é o paradigma mais antigo da Engenharia de Software e é bastante

criticado em função dos problemas encontrados nos projetos em que é aplicado. A
realidade tem mostrado que num projeto raramente se segue o fluxo sequencial
sequ que o
modelo propõe, gerando problemas futuros que oneram os custos e prazos. Uma
Um das
causas mais comuns deste problema é a dificuldade do cliente em declarar claramente
todas as suas necessidades e expectativas,
expectativas, ou seja, de definir todos os requisitos
inicialmente.. O foco incorreto ou não claro pode gerar uma distorção que reflete
diretamente na percepção de qualidade por parte do próprio cliente. Isso pode levar a
entregas parciais do produto, o que exige que o cliente tenha muita paciência durante os
aceites parciais que são formalizados em um Documento de Encerramento do Projeto com
observações no campo Restrições “Entrega Parcial de Projeto”,
”, que contém detalhes
quanto à aceitação condicional do projeto por parte do cliente.
Os trabalhos de desenvolvimento de
de software atuais seguem ritmos muito rápidos,
sujeitos a diversas modificações, o que torna o modelo em cascata inadequado para estes
tipos de projeto. Mas, cumpre ressaltar, caro aluno, que embora
mbora o Modelo em Cascata ou
Ciclo de Vida Clássico tenha fragilidades,
fragilidades, ele é significativamente melhor do que uma
abordagem casual para o desenvolvimento de software.
39
3.4. Modelos Evolucionários de Processo
São modelos que consideram a natureza evolutiva do software. Os modelos
evolucionários são iterativos. São implementados de forma a permitir o desenvolvimento
de versões cada vez mais completas do software. Suas características incluem:
• São usados quando o deadline (limite de tempo) não é adequado para o
desenvolvimento do software, ou seja, a data de término não é realística (por
exemplo, prazos reduzidos de mercado face à competitividade).
• Uma versão limitada pode ser introduzida para atender a essa competitividade e
às pressões do negócio.
• São liberados produtos “core” (“núcleo dos produtos”) ao longo do
desenvolvimento.
• Os detalhes e extensões do projeto são definidos ao longo do desenvolvimento.

Os modelos que são agrupados nesta categoria são: Prototipação, Modelo Espiral e
Modelo Concorrente, que são apresentados no que se segue.

3.4.1. Prototipação

É um modelo de 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.
Envolve o desenvolvimento de uma versão inicial do sistema baseada no
atendimento dos requisitos ainda pouco definidos. Este processo permite a descoberta de
falhas difíceis de serem encontradas na comunicação verbal, servindo de apoio à fase de
levantamento de requisitos prevenindo as possíveis falhas no sistema.
O objetivo principal de um protótipo é simular a aparência e funcionalidade do
software permitindo que os clientes, analistas, desenvolvedores e gerentes compreendam
plenamente os requisitos do sistema interagindo, avaliando, alterando e aprovando as
características mais relevantes que o produto deva ter. A figura 6 ilustra este processo.

40
 Modelagem

Plano Rápido

Especificação

Projeto
Rápido

Entrega e
Construção do
Feedback
Protótipo

Figura 6
Modelo de Prototipação

Certamente a redução de custos no desenvolvimento é um dos grandes ganhos de

da prototipação, pois envolve diretamente o usuário final permitindo um desenvolvimento
mais próximo
o dos desejos do cliente
cli priorizando a facilidade de uso. Assim, pode-se
pode obter
um nível de satisfação
ção maior em função do menor número de erros ou falhas de
desenvolvimento comuns na
a passagem de informação entre o analista (que fez o
levantamento de requisitos) e o desenvolvedor (equipe de desenvolvimento
vimento).

41
 Um dos riscos envolvidos neste modelo é o descomprometimento com a
análise do produto, visto que os envolvidos podem se apoiar totalmente no
modelo prototipado gerando uma expectativa muitas vezes irrealista de
desempenho, em função do protótipo ser muito mais enxuto do que o produto
final e estar em ambiente controlado.
Além disso, 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. Ele pode, também, não
n aceitar facilmente a ideia
ia de que a versão final do
software está sendo construída e tentar forçar a utilização do protótipo como
produto final.
Outro risco deste modelo é que o desenvolvedor frequentemente
entemente faz uma
implementação comprometida (utilizando partes de programas existentes,
geradores de relatórios, geradores de janelas) com o objetivo de produzir
rapidamente um protótipo executável. Depois de um tempo ele se familiariza com
essas escolhas, e pode se esquecer que elas não são apropriadas para o produto
final.

Ainda que possam ocorrer

problemas, a prototipação
ão é um
modelo eficiente. A chave para
seu sucesso é definirem-se
se as
regras do jogo logo no começo. O
cliente e o desenvolvedor devem
ambos concordar que
ue o protótipo
seja construído para servir como
um mecanismo a fim de se definir
os requisitos do projeto. A figura 7
traz uma outra visão deste
processo. Figura 7
Outra visão
ão do Modelo de Prototipação

42
 3.4.2. Modelo Espiral

Desenvolvido para abranger as melhores características do Modelo em Cascata e

da Prototipação, acrescentando, ao mesmo tempo, um novo elemento: a análise de riscos.
O modelo em espiral foi desenvolvido por Barry Boehm (1988) em seu artigo
intitulado “A Spiral Model of Software Development and Enhancement”. Este modelo foi o
primeiro a explicar o porquê do modo iterativo e elencar suas vantagens. As iterações têm
uma duração típica de seis meses a dois anos. Cada fase inicia-se com um objetivo
esperado e termina como uma revisão pelo cliente do progresso (que deve ser interna) e
assim por diante. Esforços de análise e engenharia são aplicados em cada fase do projeto,
tendo sempre o foco no objetivo do projeto. A figura 8 ilustra este processo.

Planejamento
Análise de Riscos

Especificação

Modelagem

Implantação
Entrega e Construção do Código
Feedback
Testes

Figura 8
Modelo Espiral

43
 As principais características deste modelo são:

• Engloba a natureza iterativa da Prototipação com os aspectos

sistemáticos e controlados do Modelo em Cascata.
• Fornece potencial para o desenvolvimento rápido de versões incrementais
do software.
• O processo se inicia com a equipe de desenvolvimento movendo-se em
volta da espiral, no sentido horário, a partir do centro.
• O primeiro circuito em torno da espiral pode resultar na especificação do
produto.
• Nas primeiras iterações, a versão incremental pode ser um modelo em
papel ou um protótipo.
• Nas iterações mais adiantadas são produzidas versões incrementais mais
completas e melhoradas.

É uma abordagem realística para o desenvolvimento de

software de grande porte. Como o software evolui na medida em
que o processo avança, o cliente e o desenvolvedor entendem
melhor e reagem aos riscos em cada nível evolucionário. Para
pequenos projetos, os conceitos de desenvolvimento de
software ágil tornam-se uma alternativa mais viável.
Como vantagens deste modelo, podemos citar as
estimativas realísticas dadas à identificação de problemas importantes logo no início do
processo, versatilidade para lidar com mudanças (quando inevitáveis), desenvolvimento
antecipado por parte dos engenheiros de software que têm visibilidade das necessidades
por fases, Usa prototipagem (em qualquer estágio de evolução do produto) como
mecanismo de redução de risco.
No entanto, o uso do modelo Espiral exige considerável experiência na
determinação de riscos e depende dessa experiência para ter sucesso. Além disso, pode
ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável.

44
 3.4.3. Modelo de Desenvolvimento Concorrente

De acordo com Pressman (2010), o modelo de Desenvolvimento Concorrente,

também chamado de Engenharia Concorrente, pode ser representado, esquematicamente,
como uma série de atividades de arcabouço, ações e tarefas da Engenharia de Software e
seus estados associados.
Um exemplo do uso deste modelo pode ver visto na figura 9. A figura traz a
atividade “Modelagem” do modelo Espiral (veja figura 8), espelhada no modelo
Concorrente.

Figura 9
Transições de Estado no Modelo de Desenvolvimento Concorrente

No modelo Concorrente, uma atividade pode estar em qualquer um dos estados

apresentados na figura (em desenvolvimento, sob inspeção, aguardando modificações,
etc) a qualquer tempo. O modelo define uma série de eventos que vão disparar transições
de um estado para outro, para cada uma das atividades, ações ou tarefas da Engenharia
de Software. Por exemplo, suponha que durante os estágios da etapa de projeto,
descobre-se uma inconsistência no modelo de análise. Isso geraria o evento “correção no
modelo de análise”, que, por sua vez, implicaria na passagem da atividade de análise do
estado “pronto” para o estado “aguardando modificações”

45
De forma geral, as principais características deste modelo são:
• Todas as atividades ocorrem em paralelo, mas estão em diferentes estados.
• O modelo define uma série de eventos que vão disparar transições de estado
para estado, para cada uma das atividades.
• Em vez de usar uma sequência como o modelo em cascata, ele define uma
rede de atividades.
• Eventos gerados dentro de uma certa atividade ou em algum outro lugar da
rede de atividades disparam transições entre estados de uma atividade
• Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma
visão exata de como está o estado do projeto.
• Em vários projetos pode existir uma simultaneidade (concorrência) entre as
várias atividades de desenvolvimento e de gestão de projetos.
• É representado como uma série de grandes atividades técnicas, tarefas e
seus estados associados (fornece um panorama preciso do estado atual do
projeto).

O software moderno é caracterizado por modificações contínuas, prazos

muito curtos e por uma necessidade premente de satisfazer o usuário ou cliente.
Os modelos evolucionários de processo foram criados com o objetivo de resolver
estes problemas, mas também têm suas fragilidades. Uma delas é que a
prototipagem pode trazer problemas para o planejamento do projeto em função do
número impreciso de ciclos necessários para se concluir o produto. Outra se
refere ao foco dado à flexibilidade e extensibilidade ao invés da alta qualidade. Se
o foco for centrado na qualidade, o projeto pode resultar em atraso, o que pode
comprometer a competitividade do empreendimento.

46
(Animação 3) Casa Segura – Seleção de um Modelo de Processo, Parte II

A cena: Sala de reuniões de engenharia de software na empresa CPI, uma empresa que fabrica
produtos de consumo para uso doméstico e comercial.

Os personagens : Paulo, gerente de engenharia; Douglas, gerente de engenharia de software;

Júnior, membro da equipe de software; Viviane, membro da equipe de software e Edson,
membro da equipe de software.

A conversa:

(Locutor (voz): Douglas descreve as opções de processos evolucionários.)

Edson: Agora estou vendo alguma coisa da qual gosto. Uma abordagem incremental faz
sentido e eu realmente gosto do fluxo daquela coisa de modelo espiral. Isso é manter a coisa
real.

Viviane: Eu concordo. Entregamos um incremento, aprendemos por meio do feedback do

cliente, replanejamos e depois entregamos outro incremento. Ela também se encaixa na
natureza do produto. Podemos por alguma coisa no mercado rapidamente e depois adicionar
funcionabilidades a cada versão, isto é, incrementos.

Paulo: Espere um pouco, você disse que reformamos o plano em cada volta em torno da
espiral, Douglas? Isso não é tão bom, precisamos de um plano, de um cronograma e
precisamos nos ater a ele.

Douglas: Essa é uma escola de pensamento antiga, Paulo. Como o Edson disse, temos de
manter a coisa real. Eu proponho que é melhor adaptar o plano à medida que aprendemos
mais e à medida que modificações são solicitadas. É muito mais realista. Qual o sentido de um
plano se ele não reflete a realidade?

Paulo (franzindo a testa): Eu penso que sim, mas a gerência superior não vai gostar disso...
eles querem um plano fixo.

Douglas (sorrindo): Então você vai ter que reeducá-los, meu amigo.

47
3.5. Modelos Incrementais de Processo
Caro aluno, há diversas situações em que os requisitos iniciais do software estão
razoavelmente bem definidos, mas o escopo global do processo de desenvolvimento
claramente elimina uma abordagem puramente linear ou sequencial. Adicionalmente pode
haver a necessidade de se fornecer rapidamente um conjunto limitado de funcionalidades
do software aos usuários e depois refinar, melhorar e expandir aquela funcionalidade em
versões mais avançadas do software. Nestes casos, os modelos de processo que
produzem software em incrementos são os mais indicados.

Os processos incrementais que discutiremos aqui incluem o Modelo Incremental e o

Modelo RAD – Rapid Application Development (Desenvolvimento Rápido de Aplicação).

3.5.1. Modelo Incremental

O modelo incremental combina elementos do modelo em cascata, mas aplicados de

forma interativa. O modelo de processo incremental é interativo como a prototipagem, mas
diferentemente da prototipagem, o incremental tem como objetivo apresentar um produto
operacional a cada incremento realizado. Este processo pode ser visto na figura 10.
Esse modelo é muito útil quando a empresa não possui mão de obra disponível,
num dado período, para uma implementação completa, dentro do prazo estipulado.

Figura 10
Modelo de Processo Incremental

48
 De uma forma geral, o Modelo Incremental apresenta as características:
• Combina elementos do Modelo em Cascata (aplicado repetitivamente) com a
filosofia iterativa da Prototipação.
• Aplica sequências lineares de uma forma racional à medida que o tempo
passa.
• Cada sequência linear produz um incremento do software e pode gerar uma
entrega parcial do produto.
• Os primeiros incrementos são versões simplificadas do produto final.
• O primeiro incremento é chamado de “núcleo do produto” (core).

Um exemplo clássico de aplicação do Modelo Incremental é no desenvolvimento de

um processador de texto. Para este projeto as etapas incrementais podem ser assim
definidas:
[1] Primeiro Incremento: poderia efetuar as funções de controle de versões de
arquivos, edição e produção de documentos
[2] Segundo Incremento: adicionaria capacidade de edição e de produção de
documentos mais sofisticadas
[3] Terceiro Incremento: incluiria a verificação sintática e gramatical
[4] Quarto Incremento: adicionaria a capacidade avançada de disposição de
página
Note que todo o processo pode se repetir até que um produto completo seja
produzido.

3.5.2. Modelo RAD - Rapid Application Development

O modelo RAD - Rapid Application Development (Desenvolvimento Rápido de

Aplicação) é uma adaptação do modelo em Cascata, mas que enfatiza um
desenvolvimento extremamente rápido. A “alta velocidade” é conseguida através de uma
abordagem de construção baseada em componentes, ou seja, o sistema é modularizado.
Se os requisitos forem bem definidos e o objetivo do projeto for restrito, a equipe
pode criar um sistema plenamente funcional em pouco tempo.

49
 O RAD enquadra-se no modelo de atividades de arcabouço do Modelo em Cascata:
• Especificação: atividade em que se entende o problema de negócio, as
características das informações e é realizado o levantamento de requisitos.
• Planejamento: atividade essencial. Várias equipes trabalham em paralelo em
diferentes funções.
• Modelagem: estabelece representações de projeto que servem como base
para a atividade de construção. Abrange três fases:
o Modelagem de negócio
o Modelagem de dados
o Modelagem de processo
• Construção: faz uso de componentes de software preexistentes e geração de
códigos.
• Implantação: estabelece a base para iterações subsequentes, se
necessárias.
A figura 10 apresenta a representação esquemática do modelo RAD em relação ao
modelo sequencial tradiconal.

Figura 11 Modelo RAD x Modelo Tradicional

Fonte: http://www.etondigital.com/services/rapid-application-development/

As situações de desenvolvimento mais adequadas para se utilizar o Modelo RAD

incluem:

50
 • Projetos em que os requisitos estão bem definidos, o objetivo do sistema é
restrito e se deseja criar um “sistema plenamente funcional” dentro de
períodos muito curtos (por exemplo, de 60 a 90 dias, como a figura 11
sugere)
• Projetos em que há fortes restrições de tempo impostas pelo cliente .
• Aplicações que podem ser modularizadas de forma que cada função principal
possa ser completada em menos de 3 meses.
• Projetos em que cada função principal possa ser alocada para uma equipe
distinta e depois integradas para formar o todo do produto.
Mas, a utilização do modelo RAD também pode implicar em problemas. Para
projetos grandes, mas mensuráveis, o RAD requer um número elevado de recursos
humanos que sejam suficientes para criar um número adequado de equipes. Além disso, o
RAD requer um comprometimento entre desenvolvedores e clientes para que as atividades
possam ser realizadas rapidamente e o sistema seja concluído em um tempo curto. Se o
comprometimento for abandonado por qualquer das partes, o projeto falhará. O uso do
RAD também não é apropriado quando os riscos técnicos são grandes (por exemplo,
quando a aplicação faz uso de uma nova tecnologia).

3.6. Desenvolvimento Baseado em Componentes

O Desenvolvimento Baseado em Componentes ou CBD- Component-based
Development, também é conhecido como Component-based Software Engineering (CBSE)
ou simplesmente como Componente de Software. Hoje em dia é muito comum que os
desenvolvedores utilizem componentes de software que são encontrados em bibliotecas
de uso gratuito ou mesmo disponíveis para compra. Estes componentes são conhecidos
como COTS– Commercial-Off-The-Shelf, ou software comercial de prateleira. Geralmente
estes componentes oferecem funcionalidades com interfaces bem definidas que podem ser
facilmente integrados no software sendo desenvolvido.
O método de Desenvolvimento Baseado em Componentes incorpora as
características de construção de componentes de biblioteca ao Modelo Espiral. De
natureza evolucionária, adota uma abordagem iterativa para a criação de software. Assim,
o modelo constrói aplicações a partir de componentes de software previamente
preparados. As atividades de modelagem e construção começam com a identificação de

51
componentes candidatos. Esses componentes podem ser projetados como módulos de
software convencional ou como classes ou pacotes de classes orientadas a objeto.
No paradigma orientado a objetos uma classe encapsula dados e algoritmos,
algoritmos que
também podem ser utilizados para manipular os dados. Através desta abordagem,
abordagem uma
biblioteca de classes pode ser construída com as classes identificadas no desenvolvimento
do software e a partir de então toda iteração
iteração da espiral deverá verificar o conteúdo da
biblioteca que pode ser reutilizado.
reutilizado A figura 12 ilustra este processo.

Planejamento
Análise de Riscos

Especificação

Modelagem

Implantação
Entrega e Construção do Código
Feedback Testes

Figura 12
Modelo do Desenvolvimento Baseado em Componentes

O modelo de Desenvolvimento Baseado em Componentes

leva ao reuso
reuso de software, e a reusabilidade fornece aos engenheiros
vários benefícios. Com base nesta reusabilidade, estudos
e relatam
uma redução de 70%
70 no prazo do ciclo
iclo de desenvolvimento e de
84%
% no custo dos
do projetoss desenvolvidos neste modelo de processo,
processo
com índices
ndices de produtividade em torno de 26.2, superior ao índice
padrão de 16.9 da indústria.
indústria [PRESSMAN, 2006].

52
 O reuso de software se refere à utilização de software existente para o
desenvolvimento de um novo software. A decisão quanto à utilização de componentes
reutilizáveis envolve comparações entre o investimento necessário para a sua
aquisição e os gastos para o desenvolvimento de uma solução customizada. Devem
ser estimados os custos e benefícios líquidos no investimento em reuso de software e
serem avaliados os ganhos com a adoção do reuso.
Muitos métodos para o reuso estão em prática no mercado atual, sendo sua
escolha determinada pela sua adequação ao modelo de negócio ou às tecnologias
utilizadas.
O RiSE - Reuse in Software Engineering, por exemplo, é um esforço em
direção a um efetivo framework de métodos, processos, ferramentas e boas práticas
relacionados ao reuso de software que compreende aspectos técnicos e não técnicos.
O CRUISE - Component Reuse in Software Engineering, no formato de livro on
line e livre com foco em reuso de software, é um dos primeiros esforços em mapear o
reuso de software que cita as áreas chave, desenvolvimento baseado em
componentes, reengenharia, ferramentas, qualidade de componentes de software,
métricas para reuso, repositórios, engenharia de domínio, linhas de produtos, entre
outros aspectos.
O RAD - Rapid Application Development, visto anteriormente, é um modelo de
processo de desenvolvimento de software iterativo e incremental que enfatiza um
ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias) tendo um foco
considerável no reuso para se atingir um prazo tão justo tornando-o uma técnica de
quarta geração que reutiliza componentes de programas existentes ou cria
componentes reutilizáveis.

53
3.7. Modelo de Métodos Formais
Os métodos formais são técnicas baseadas em formalismos matemáticos que
podem ser usados para a especificação, desenvolvimento
e verificação de sistemas de software. Seu uso para o
desenvolvimento de software é motivado pela base que
fornecem garantindo confiabilidade e robustez a um
projeto, uma vez que executam análises matemáticas
apropriadas. No entanto, o alto custo do uso de métodos
formais restringe o seu uso ao desenvolvimento de
sistemas de alta integridade, no qual há alta probabilidade
das falhas conduzirem à perda de vidas ou sérios
prejuízos (como nas missões espaciais e no controle de
vôos, por exemplo).
No modelo de Métodos Formais, também conhecido como Engenharia de Software
Cleanroom (Sala Limpa), uma questão fundamental é garantir que o software é realmente
uma solução para o problema proposto. Para realizar tal tarefa, deve-se primeiro construir
um modelo da solução (especificação) utilizando uma linguagem formal. Tendo este
modelo formal como base, o método permite:
• realizar provas matemáticas que garantem que este modelo possui as
propriedades requisitadas (verificação);

• analisar se a solução proposta é aceitável do ponto de vista de

desempenho, indicando quais as melhores estratégias para
implementação a serem seguidas;

• validar o modelo através de simulações;

• realizar o desenvolvimento do software podendo-se provar que a

implementação está correta (geração de código correto).

Dentre os vários métodos de especificação formal existentes, destacam-se o

método Z, que já foi utilizado em várias aplicações práticas, e o método de gramáticas de
grafos, por possuir uma linguagem visual de representação e descrever com naturalidade
fenômenos de sistemas concorrentes.

54
 De uma maneira mais abrangente, podemos caracterizar assim o modelo de
Métodos Formais:

• Permite especificar, desenvolver e verificar um software através de uma rigorosa

notação matemática.
• Fornece um mecanismo para eliminar muitos problemas encontrados nos outros
modelos, como por exemplo, ambiguidade, incompletude e inconsistência, que
podem ser descobertos e corrigidos mais facilmente através de análise
matemática.
• Promete o desenvolvimento de software livre de defeitos.
• Consome muito tempo de desenvolvimento e é muito caro.

Como poucos desenvolvedores possuem o conhecimento necessário para utilizá-lo,

são requeridos muitos cursos e treinamentos. É difícil usar tais modelos matemáticos
formais como meio de comunicação com a maioria dos clientes. Assim, como já dissemos,
sua área de aplicação é muito restrita, abrangendo, principalmente, aplicações críticas.

Links interessantes

Caro aluno,

Para mais informações sobre os Métodos Formais, consulte o link:

http://www.tiosam.org/enciclopedia/index.asp?q=Métodos_formais

Para entender como funciona o controle de tráfego aéreo (projeto crítico),

assista ao filme:

http://youtu.be/7wsrs3a-y3M

55
3.8. Processo Unificado
O Processo Unificado (PU) ou Unified Process (UP) surgiu como um processo para
o desenvolvimento de software visando à construção de sistemas orientados a objetos (o
RUP – Rational Unified Process é um refinamento do Processo Unificado). É um processo
iterativo e adaptativo de desenvolvimento e vem ganhando cada vez mais adeptos devido
à maneira organizada e consistente que oferece na condução de um projeto.
O PU utiliza uma abordagem evolucionária paro o desenvolvimento de software. O
ciclo de vida iterativo é baseado em refinamentos e incrementos sucessivos a fim de
convergir para um sistema adequado. Em cada iteração, procura-se incrementar 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 PU foi modelado usando o Software Process Engineering Model (SPEM) que é
um padrão para modelagem de processos baseado em UML- Unified Modeling Language.
O processo tem duas estruturas, ou duas dimensões, a saber:
- Estrutura dinâmica - representa a dimensão do tempo no processo.
- Estrutura estática - descreve como elementos do processo são agrupados em
disciplinas.
A estrutura que representa o tempo é denominada fase e a estrutura que representa
os elementos do processo são as disciplinas, conforme mostra a figura 13.

Fases

Uma fase é definida como a dimensão de tempo entre duas maiores marcas (major
milestones) de processos, durante a qual um conjunto bem definido de objetivos é
encontrado, artefatos são completados e a decisão é tomada no sentido de ir para a
próxima fase ou não. "Maiores marcas" podem ser definidas como eventos de grandes
sistemas organizados no final de cada fase de desenvolvimento para fornecer visibilidade
aos seus problemas, sincronizar o gerenciamento com as perspectivas de engenharia e
verificar se os objetivos de cada fase foram obtidos. Este conceito está intimamente
relacionado ao risco que deve ser considerado na medida em que o sistema estiver
evoluindo. Para cada fase os maiores milestones buscam identificar e antecipar os riscos.

56
 Figura 13
Fonte: http://isosoftware.blogspot.com/2010/02/processo-unificado-pu-unified-process.html

O Processo Unificado organiza suas iterações em quatro fases principais:

[1] Concepção ou Iniciação: o objetivo desta fase é levantar, de forma genérica

e pouco precisa, o escopo do projeto. Não deve existir aqui a pretensão de
especificar de forma detalhada os requisitos, a ideia é ter uma visão inicial do
problema, estimar de forma vaga o esforço e os prazos e determinar se o
projeto é viável e merece uma análise mais profunda.
[2] Elaboraçã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. Ao fim desta fase, deseja-se que 90% dos requisitos tenham sido
levantados em detalhes, o núcleo do sistema tenha sido implementado com

57
 alta qualidade, os principais riscos tenham sido tratados e haja condições
para se fazer estimativas mais realistas.
[3] Construção: implementação iterativa dos elementos restantes de menor
risco e mais fáceis e preparação para a implantação.
[4] Transição: testes finais e implantação.

Disciplinas

Uma disciplina é uma coleção de atividades relacionadas que estão ligadas à maior
área de interesse dentro do processo em geral. Cada disciplina possui, resumidamente, os
seguintes objetivos específicos:

Modelagem de Negócios: entender a estrutura e a dinâmica da organização para a

qual o produto será desenvolvido; identificar problemas correntes na organização e
possíveis aperfeiçoamentos; assegurar que o cliente, o usuário final e os
desenvolvedores possuam a mesma compreensão da empresa; produzir os
requisitos de sistemas necessários para suportar os objetivos da organização.
Requisitos: estabelecer e manter o consentimento entre clientes e stakeholders
sobre o que o sistema deve fazer; fornecer uma melhor compreensão dos requisitos
aos desenvolvedores; definir os limites do sistema; fornecer as bases para o
planejamento das iterações, estimativas de custo e tempo de desenvolvimento;
definir as interfaces do sistema baseado nas necessidades e objetivos dos usuários.
Análise e Design: transformar os requisitos dentro de um projeto do que será o
sistema; desenvolver uma arquitetura robusta para o sistema; adaptar o projeto para
ajustá-lo ao ambiente de implementação.
Implementação: preparar a organização do código em termos de implementação
de subsistemas, organizados em camadas; implementar classes e objetos em
termos de seus componentes; testar os componentes desenvolvidos como
unidades; integrar os resultados obtidos por implementadores individuais (ou
equipes) em um sistema executável.
Teste: verificar a interação entre os objetos; verificar a integração de todos os
componentes de software; verificar se todos os requisitos foram implementados
corretamente; verificar os defeitos e assegurar que eles foram tratados antes da
entrega do produto.

58
Implantação: descrever as atividades associadas à verificação para que o produto
esteja disponível ao usuário final.
Gerenciamento de Configuração e Mudança: identificar itens de configuração;
restringir alterações para aqueles itens; auditar as alterações neles feitas; definir e
gerenciar as alterações daqueles itens.
Gerenciamento de Projeto: fornecer uma estrutura para gerenciamento de projeto
de software; fornecer um guia prático para planejamento, recrutamento, execução e
monitoramento de projeto; fornecer uma estrutura para o gerenciamento de riscos.
Ambiente: identificar as atividades necessárias para configurar o processo para o
projeto; descrever as atividades requeridas para desenvolver as guias mestras no
suporte ao projeto; fornecer para a organização de desenvolvimento de software, o
ambiente de processos e ferramentas que suportarão a equipe de desenvolvimento.

De uma maneira geral, podemos assim caracterizar o Processo Unificado:

• é um framework genérico de um processo de desenvolvimento;

• é baseado em componentes;
• utiliza toda a definição da UML;
• é dirigido pelos use cases, centrado na arquitetura, iterativo e incremental
(conceitos-chave).

O Processo Unificado foi criado para ser um processo ágil de

desenvolvimento e propõe uma abordagem realística para a
condução de um projeto. Ao contrário do modelo em cascata, em
que cada etapa do ciclo de vida deve ser realizada integral e
sequencialmente, 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.

59
3.9. Desenvolvimento Ágil
As definições modernas de desenvolvimento de software ágil evoluíram a partir de
meados de 1990 como parte de uma reação contra métodos caracterizados por uma
regulamentação complexa e rígida e contra a regimentação e sequenciamento usados no
modelo em cascata. O objetivo era desburocratizar os procedimentos que tornavam as
etapas dos processos lentas, o que era contrário ao modo de trabalho usual dos
engenheiros de software.
Inicialmente, os métodos ágeis foram denominados de “métodos leves”. Em 2001,
Kent Beck e 16 outros notáveis profissionais da área de Engenharia de Software se
reuniram, adotaram o nome métodos ágeis, e publicaram o Manifesto Ágil, documento
que reúne os princípios e práticas desta metodologia de desenvolvimento. Esses veteranos
formaram a Agile Alliance ou Aliança Ágil, uma organização não lucrativa que promove e
fomenta o desenvolvimento ágil.

Os membros da Aliança Ágil, declararam assim os princípios da

metodologia em seu manifesto:

“Estamos descobrindo maneiras melhores de desenvolver software

fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
trabalho, passamos a valorizar:

• Indivíduos e interação entre eles mais que processos e ferramentas;

• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os

itens à esquerda.”

60
 Os principais modelos baseados na concepção de Desenvolvimento Ágil incluem o
Scrum, criado em 1986, o ASD- Adaptive Software Development, o FDD- Feature Driven
Development, o DSDM - Dynamic Systems Development Method de 1995, o Crystal e a
XP – eXtreme Programming ou Programação Extrema, criados em 1996.
O Desenvolvimento Ágil de Software - Agile Software Development, envolve uma
metodologia que visa minimizar os riscos por meio de desenvolvimentos em curtos
períodos ou iterações, como mostra a figura 14. A iteração típica envolve o
desenvolvimento em fases curtas, de 1 a 4 semanas, envolvendo todas as tarefas
necessárias para implantar uma funcionalidade. Considerando-se o período curto de cada
iteração, a comunicação mantida entre os stakeholders é em tempo real sendo,
preferencialmente, tratada por meio verbal (embora documentada), ou “face-a-face”,
visando minimizar entendimentos parciais ou errôneos. Para tanto é necessário
estabelecer-se um local físico (uma sala) onde toda a equipe necessária ficará focada no
projeto.

Figura 14 – Etapas do Desenvolvimento Ágil

Fonte: http://www.sstecnologia.com.br/

Alguns críticos do processo ágil afirmam que o maior risco deste tipo de abordagem
é a baixa qualidade ou mesmo inexistência de documentação do projeto devido à interação
humana “face-a-face” que, se por um lado traz agilidade na comunicação, por outro traz a
informalidade nas definições. Assim sendo, é necessário um bom acompanhamento do

61
gestor do projeto para garantir a qualidade dos trabalhos independente do processo
utilizado.
De uma forma geral, os processos ágeis atendem aos projetos de software que,
normalmente, apresentam:
• Dificuldade em prever com antecedência quais requisitos vão persistir e quais
serão modificados, bem como prever quais prioridades dos clientes sofrerão
mudanças ao longo do projeto;
• Intercalação das etapas de projeto e construção, que vão sendo realizadas
juntas de modo que os modelos de projeto vão sendo comprovados na
medida em que são criados;
• Análise, projeto, construção e testes não são tão previsíveis, do ponto de
vista do planejamento, como seria desejado.

Caro aluno, em defesa dos métodos ágeis e fazendo uma crítica ao chamado
“desenvolvimento tradicional”, encontramos a seguinte comparação na pesquisa que
fizemos na internet:

Fonte: http://icarovinicius.com.br/blog/tag/metodologias-ageis/

62
 A metodologia ágil vem gerando grande debate, fazendo muitos desenvolvedores
apaixonados e muitos outros críticos ferrenhos. Mas temos que manter a imparcialidade
profissional e questionarmos o que realmente tem que ser observado, como:
• Qual é a melhor forma de se alcançar a agilidade nos processos e práticas do
desenvolvimento de software?
• Como construir softwares que satisfaçam às necessidades do cliente e
possua características de qualidade que permitam sua extensão e ampliação
para satisfazer as necessidades do cliente no longo prazo?

Leia o artigo “Desenvolvimento Ágil Funciona?”

Publicado na revista INFO Exame Online de 30/06/2009
http://info.abril.com.br/noticias/ti/desenvolvimento-agil-funciona-30062009-3.shl

Scrum e Extreme Programming são algumas metodologias ágeis que estão em voga no momento. Elas refletem
o espírito deste manifesto ágil?

Com a nossa cultura de fast food, de querer achar uma receita mágica para tudo, o mundo ágil ganhou força
dentro de um certo nicho de desenvolvimento. A gente ouve falar muito hoje de Scrum, de Extreme Programming,
mas se usam essas ferramentas apenas como ferramentas. Isso não funciona. Tem gente que até discute se o pico
recente de Scrum não foi mais negativo que positivo, porque muita gente está aplicando e não atinge os
resultados, simplesmente porque usa o raciocínio antigo com ferramentas novas. Os valores não foram
entendidos. Scrum é um template. Ele te diz que você tem esse papel chamado product owner, você tem este tempo
chamado sprint, tem essa atividade chamada scrum diário, e essas coisas chamadas retrospectiva e backlog. Ele
te dá nomes e elementos que você aplica. Mas não é só aplicar e ponto. Isso é só o começo. A grande mensagem
da forma ágil de pensar é que o procedimento não é importante. É irrelevante se eu chamo o meu tempo de
trabalho de sprint ou o dono do projeto de product owner. É absolutamente irrelevante, se eu não entendi os
valores que são entregar valor ao cliente, criar uma organização de aprendizado, acreditar nas pessoas e dar
suporte a elas. Esses princípios é que são importantes, mas não são explícitos. Em vez disso eu tenho papéis,
cargos e atividades. Não se explicam os porquês e não entendendo os porquês você vai fazer exatamente a mesma
coisa, mas em vez de chamar o sujeito de gerente de projeto você vai chamá-lo de product owner. Mas nada
mudou.

Para saber mais sobre Desenvolvimento Ágil:

Exemplo de Desenvolvimento Ágil SCRUM

http://www.devin.com.br/modelo-scrum/

Coletânea de artigos sobre Desenvolvimento Ágil

http://www.fernandocosta.com.br/category/desenvolvimento-agil/

63
(Animação 4) Casa Segura – Considerando o Desenvolvimento Ágil de Softwares
A cena: escritório do Douglas.
Os personagens: Douglas, gerente de engenharia de software, Júnior, membro da equipe de software,
Viviane, membro da equipe de software.

A conversa:
(Uma batida na porta)
Júnior: Douglas, você tem um minuto?
Douglas: Lógico, Júnior, o que há?
Júnior: Estivemos pensando em nossa discussão de processo de ontem... Você sabe... que processo vamos
escolher para esse novo projeto Casasegura.
Douglas: E?
Viviane: Eu estava falando com um amigo de outra empresa, e ele me falou sobre Extreme Programming. É
um modelo ágil de processo, você já ouviu falar?
Douglas: Já, um pouco bem e um pouco mal.
Júnior: Bem, parece bastante bom para nós. Deixa a gente desenvolver software d e modo realmente
rápido, usa uma coisa chamada programação aos pares para fazer verificações de qualidade em tempo
real... É bastante interessante, na minha opinião.
Douglas: De fato, tem idéias realmente boas. Eu gosto do conceito de “programação aos pares”, por
exemplo, e da ideia de que os interessados devam fazer parte da equipe.
Júnior: Anh? Você quer dizer que o pessoal de marketing vai trabalhar na equipe de projeto conosco?
Douglas (concordando): Eles são os interessados, não são?
Júnior: É mas... eles vão ficar fazendo pedidos de modificação a cada cinco minutos.
Viviane: Não necessariamente. Meu amigo disse que existem modos de “acolher” modificações durante um
projeto XP.
Douglas: Então vocês pensam que nós poderíamos usar o XP?
Júnior: Definitivamente, vale a pena considerar.
Douglas: Concordo. E, mesmo que escolhamos um modelo incremental para nossa abordagem, podemos
incorporar muito do que o XP tem a oferecer.
Viviane: Douglas, antes você disse “ um pouco bem e um pouco mal”. O que era o “mal”?
Douglas: O que eu não gosto é o modo como o XP menospreza a análise e o projeto ... parece dizer que é na
escrita de código que a ação reside.

(Os membros da equipe se entreolham e sorriem.)

Douglas: Então, você concorda com a abordagem XP?

Júnior (falando pelos dois): Escrever código é o que nós fazemos, chefe!
Douglas ( rindo): É verdade, mas eu gostaria de ver vocês gastando um pouco menos de tempo codificando
e depois recodificando, e um pouco mais de tempo analisando o que tem de ser feito e projetando uma
solução que funcione.

Viviane: Talvez nós possamos agir dos dois modos, agilidade com um pouco de disciplina.

Douglas: Acredito que podemos, Viviane. Na verdade, estou certo disso.

64
Exercícios do Capítulo 3

1) Em relação ao modelo Em Cascata podemos afirmar que é:

a) Uma abordagem razoável quando os requisitos estão bem estabelecidos
b) Uma boa abordagem quando se tem pressa em entregar o software
c) A melhor abordagem para se usar quando se tem uma grande equipe de
desenvolvimento
d) Um modelo ultrapassado que raramente é utilizado atualmente

2) Quais são as 5 atividades gerais da Engenharia de Software, também caracterizadas no

modelo Em Cascata?
a) Especificação, gerenciamento de risco, medida, produção, revisão
b) Análise, projeto, implementação, testes, manutenção
c) Especificação, planejamento, modelagem, construção, implantação (entrega)
d) Análise, planejamento, projeto, programação, análise de risco

3) Podemos dizer que o modelo incremental é:

a) Uma abordagem razoável quando os requisitos estão bem estabelecidos
b) Uma boa abordagem quando um produto de trabalho “núcleo” é requerido rapidamente
c) A melhor abordagem para se usar quando se tem uma grande equipe de
desenvolvimento
d) Um modelo revolucionário que normalmente não é utilizado para desenvolver produtos
comerciais

4) Podemos afirmar que modelos de processo evolucionários:

a) São iterativos por natureza
b) Podem facilmente acomodar mudanças de requisitos
c) Quase sempre não produzem produtos descartáveis
d) Todas as alternativas anteriores estão corretas

5) O modelo de prototipagem é:
a) Uma abordagem razoável quando os requisitos estão bem definidos
b) A melhor abordagem para usar em projetos com grandes equipes de desenvolvimento
c) Uma abordagem razoável quando o cliente não consegue definir os requisitos claramente
d) Um modelo de alto risco que raramente produz software de qualidade

65
6) O modelo espiral de desenvolvimento de software:
a) Finaliza com a entrega do software
b) É mais caótico que o modelo incremental
c) Inclui avaliação de riscos a cada iteração
d) Todas as afirmativas anteriores estão corretas

7) O modelo de desenvolvimento concorrente:

a) É outro nome para engenharia concorrente
b) Define eventos que podem desencadear transições de estados dentro de cada fase de
desenvolvimento
c) Somente é usado para desenvolver sistemas distribuídos
d) É usado sempre que um grande número de solicitações de alteração de requisitos é
previsto
e) Somente a e b são verdadeiras

8) Podemos dizer que o modelo de desenvolvimento baseado em componentes:

a) Somente é apropriado para projetos ligados a hardware
b) Não é capaz de suportar o desenvolvimento de componentes reusáveis
c) Depende da tecnologia de objetos como suporte
d) Não se mostra “rentável” quando quantificado por métricas de software

9) O modelo de métodos formais faz uso de métodos matemáticos para:

a) Definir a especificação de requisitos
b) Desenvolver sistemas livres de defeitos
c) Verificar a corretude de sistemas baseados em computador
d) Todas as alternativas anteriores são corretas

10) Qual dos nomes abaixo não representa uma das fases do modelo de processo unificado?
a) Fase de iniciação
b) Fase de validação
c) Fase de elaboração
d) Fase de construção

66
11) O que se entende por “ciclo de vida”?

12) Qual a diferença entre um modelo descritivo e um modelo prescritivo de processo?

13) O que caracteriza os modelos evolucionários de processo?

14) Em que situações os modelos incrementais são mais indicados?

15) Cite uma das principais diferenças entre o Modelo Incremental e o Modelo de
Prototipagem.

16) Cite quais são as duas dimensões do Processo Unificado.

17) Quais são as fases e as disciplinas do Processo Unificado?

18) Quais são as principais características do Processo Unificado?

19) Quais são os princípios das metodologias ágeis?

20) Nos modelos de processos ágeis o único produto de trabalho gerado é o programa de
trabalho.
a) Verdadeiro
b) Falso

67
 Capítulo 4 – Engenharia de Requisitos
Caro aluno, neste capítulo definiremos o que são requisitos de software e a sua
importância dentro da Engenharia de Requisitos. Todas as etapas, conceitos e
definições ligadas à ER serão apresentadas.

4.1. Requisitos e Engenharia de Requisitos

Caro aluno, a Engenharia de Requisitos (ER) pode ser vista como uma sub-área da
Engenharia de Software, cujo principal objetivo é a obtenção de uma especificação correta
e completa dos requisitos de um sistema de software.
A Engenharia de Requisitos tem se tornado cada vez mais necessária para resolver
os problemas encontrados nas organizações com relação à definição de sistemas. De
acordo com estudos realizados pelas empresas GTE, TRW e IBM (na década de 1970), foi
mostrado que o custo relativo de um erro localizado durante a análise de requisitos seria
0.1, um erro localizado na fase de implementação seria 1 (10 vezes mais), na fase de
testes seu custo relativo subiria para 2 (20 vezes mais), terminando com um custo relativo
de 20 (200 vezes mais) na fase final de manutenção. Apesar de este estudo ser antigo, os
dados atuais ainda o confirmam, como pode ser visto na figura 15.

Figura 15 - Custo do Erro em Software

Fonte: https://www.mar.mil.br/sdms/0050-apresentacao.ppt

68
 Na figura 15, a fase de Análise, corresponde à análise de requisitos. Como pode ser
visto, o custo aumenta com o tempo de descoberta do erro e os erros mais caros são
aqueles cometidos na Análise de Requisitos. Muitas vezes estes erros são descobertos
pelo próprio cliente, mesmo antes da entrega do produto, quando ele participa ativamente.
Assim, os requisitos deficientes são considerados uma das maiores causas de falhas nos
projetos de software.
Mas, afinal, o que são os requisitos?

De acordo com o IEEE - Institute of Electrical and Electronics Engineers,

requisito é:
Uma condição ou capacidade que um usuário necessita para resolver um
problema ou alcançar um objetivo.
Uma condição ou capacidade que deve ser satisfeita por um sistema para
satisfazer um contrato ou um padrão.
De acordo com Sommerville:
Os requisitos para um sistema de software estabelecem o que o sistema deve
fazer e definem restrições sobre sua operação e implementação.
De acordo com o dicionário, requisito é:
Condição necessária para a obtenção de certo objetivo, ou para o
preenchimento de certo fim.

De acordo com Pressman (2010) Na perspectiva do processo de software, a

Engenharia de Requisitos é uma ação de engenharia de software que começa durante a
atividade de Especificação e continua durante a atividade de modelagem.
Para que o processo de desenvolvimento de software seja bem sucedido é
fundamental que haja uma compreensão completa dos requisitos de software. Tanto o
desenvolvedor como o cliente desempenham um papel ativo na análise e especificação
dos requisitos. O desenvolvedor age como indagador, consultor e solucionador de
problemas e o cliente tenta traduzir os conceitos relativos ao desempenho do software que
ele tem concebido apenas em sua mente, tarefa que é, às vezes, bastante complicada e
nebulosa, em detalhes concretos.

69
4.2. Objetivos e Classificação dos Requisitos
Os requisitos têm por objetivo:
• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o
que o sistema deve fazer;
• Oferecer aos desenvolvedores uma compreensão melhor do sistema a ser
desenvolvido;
• Delimitar o sistema;
• Planejar o desenvolvimento do sistema;
• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do
sistema.

De acordo com Sommerville (2007), os requisitos são classificados como funcionais,

não funcionais, de domínio, do usuário e do sistema. Mas algumas destas classes ainda
apresentam uma subclassificação. Uma breve descrição destas categorias é apresentada
no que se segue.

1. Requisitos Funcionais
São requisitos que descrevem a funcionalidade (funções que o sistema deve
realizar) ou os serviços que se espera que o sistema faça. Exemplos de requisitos
funcionais: cadastro de cliente; emissão de nota fiscal; consulta ao estoque; geração
de pedido.
2. Requisitos Não-Funcionais
São requisitos que não dizem respeito diretamente à funcionalidade do sistema,
mas expressam propriedades do sistema e/ou restrições sobre os serviços ou
funções por ele providas. Sua classificação é mostrada na figura 16.
Podem ser categorizados em:
2.1.1. Requisitos de Produto
São requisitos que especificam o comportamento do produto, como por
exemplo:
• Requisitos de Facilidade de Uso ou de Usabilidade: referem-se ao
esforço para utilizar ou aprender a utilizar o produto. Estão
relacionados com a interação do usuário junto ao sistema.

70
 • Requisitos de Confiabilidade: referem-se à frequência de ocorrência de
falhas e recuperabilidade em caso de falha, como: tempo médio de
falhas; probabilidade de indisponibilidade; taxa de ocorrência de falhas;
tempo de reinício após falha; percentual de eventos causando falhas;
probabilidade de corrupção de dados após falha.
• Requisitos de Eficiência: referem-se ao desempenho do sistema e
estão associados à eficiência, uso de recursos e tempo de resposta da
aplicação, como: transações processadas/segundo; tempo de resposta
do usuário/evento, entre outros.
• Requisitos de Portabilidade: são relativos à capacidade de transferir o
produto para outros ambientes
2.1.2. Requisitos Organizacionais
São requisitos derivados das políticas organizacionais do cliente e do
desenvolvedor, como por exemplo:
• Requisitos de Implementação: ligados às regras de codificação e
restrições de software e hardware usados para desenvolver ou
executar o sistema
• Requisitos de Padrões: referem-se à definição da linguagem de
programação e às normas que devem ser seguidas pelo sistema ou no
processo de desenvolvimento
• Requisitos de entrega: referem-se ao modo como será implantada a
solução como configurações necessárias e ordem de instalação dos
pacotes
2.1.3. Requisitos Externos
São requisitos procedentes de fatores externos ao sistema e ao seu processo
de desenvolvimento, como por exemplo:
• Requisitos Éticos
• Requisitos Legais (como política de privacidade e direitos autorais)
• Requisitos de Interoperabilidade
Exemplos: o sistema não deverá revelar aos operadores nenhuma
informação pessoal sobre os clientes, além de seus nomes e o número de
referência (legislação de privacidade); em razão das restrições referentes

71
 aos direitos autorais, alguns documentos devem ser excluídos imediatamente
ao serem fornecidos.
3. Requisitos de Domínio
São requisitos derivados do domínio da aplicação do sistema. Ao invés de
serem obtidos a partir das necessidades específicas dos usuários do sistema,
eles podem se transformar em novos requisitos funcionais, ou serem regras de
negócios específica do domínio do problema. Por exemplo:
Utilização de uma interface padrão utilizando a norma Z39.50;
Disponibilização de arquivos somente para leitura devido aos direitos
autorais;
4. Requisitos do Usuário
São os requisitos funcionais e não funcionais do sistema sob o ponto de vista do
usuário. Em geral apresentam problemas como falta de clareza, confusão e
fusão, ou seja, requisitos diferentes escritos como um único requisito.
5. Requisitos do Sistema
São descrições mais detalhadas dos requisitos do usuário. São a base para que
os engenheiros de software possam fazer o projeto do sistema. Servem como
base para um contrato destinado à implementação do sistema.

Figura 16 – Classificação dos requisitos não-funcionais

Fonte: http://evertongomede.blogspot.com/2010/09/taxonomiados-requisitos-nao-funcionais.html

72
 Dicionário

• Stakeholders (Influenciadores/Envolvidos)
São as partes interessadas no projeto, ou seja, são pessoas e organizações
envolvidas no projeto ou que possuem interesses que podem ser afetados pelo
projeto, podendo exercer influência sobre os resultados do projeto.
• Baseline
Conjunto de artefatos de software que servem de base para o seu
desenvolvimento.
• DERS - Documento de Especificação de Requisitos de Software
De acordo com o IEEE este documento deve ser completo e não ambíguo, sendo
responsável por auxiliar os clientes de software a descrever com precisão o que
eles desejam obter, e desenvolvedores de software a entender exatamente o que
o cliente deseja. Para os clientes, desenvolvedores e outros indivíduos ligados ao
projeto, um bom DERS deve prover diversos benefícios, tais como:
• Estabelecer a base de acordo entre os clientes e a empresa fornecedora
sobre o que o software irá fazer;
• Reduzir o esforço de desenvolvimento;
• Prover uma base para estimativas de custo e prazos;
• Prover uma base para validação e verificação do produto;
• Facilitar a manutenção do produto de software final.
Um DERS conta com alguns padrões indicados para sua elaboração. O IEEE
elaborou um documento que contém padrões e práticas recomendadas para a
criação do DERS chamado IEEE Recommended Practice for Software
Requirements Specification - Práticas Recomendadas para a Especificação de
Requisitos de Software. Este documento está disponível em:
http://www6.conestogac.on.ca/~set/courses/year1/sef/documents/IEEE830-
1998Standard.pdf

73
 A Engenharia de Requisitos reúne as primeiras atividades a serem realizadas nos
diversos modelos de processo de
software. Seu objetivo é definir o que
deve ser feito e não a forma como será Projeto do
Software
implementado o sistema. Serve
erve como
ponte entre o projeto e a construção do
Engenharia
software e define as bases do contrato de
Requisitos
entre o desenvolvedor e o cliente.
Construção do
Realiza a aquisição, o refinamento e a Software

verificação das necessidades do

sistema. A meta é sistematizar o
processo de definição dos requisitos, obtendo uma especificação correta e completa do
sistema para elaboração do DERS
ERS.

A Engenharia de Requisitos possibilita que:

• o engenheiro de sistemas:
sistemas
especifique
specifique a função
fu e o desempenho do software
indique
ndique a interface do software com outros elementos do sistema
sist
estabeleça
stabeleça quais são as restrições
restrições de projeto que o software deve
enfrentar.
• o engenheiro de software:
software
aprimore
primore a alocação de software e construa modelos do processo, dos
dados e dos domínios comportamentais que
que serão tratados pelo software
• o projetista de software:
software
tenha
enha uma representação
representação da informação e da função que pode ser
traduzida em projeto procedimental,
pr cedimental, arquitetônico e de dados
• o desenvolvedor e o cliente:
definam os critérios para avaliar a qualidade logo que o software seja
construído.

74
 O analista ou engenheiro de de requisitos possui
um papel fundamental na Engenharia de Requisitos.
Geralmente possui um perfil que inclui capacidade de:
• compreender conceitos abstratos, reorganizá-los
em divisões lógicas e sintetizar "soluções"
baseadas em cada divisão
• absorver fatos pertinentes de fontes conflitantes ou confusas
• entender os ambientes operacionais do cliente e aplicar soluções de hardware e/ou
software aos ambientes do cliente
• comunicar-se bem nas formas escrita e verbal
O analista ou engenheiro de requisitos executa ou coordena as tarefas associadas à
análise de requisitos de software. O analista deve estabelecer a comunicação com a
atividade de análise. Ele estabelece o contato com os stakeholders, quais sejam, pessoas
da administração e da equipe técnica da organização do cliente e a equipe de
desenvolvimento do software. A meta do analista é identificar os elementos básicos dos
problemas da organização, conforme percebidos pelo cliente. O analista deve ser capaz de
criar modelos do sistema objetivando compreender melhor o fluxo de dados e de controle,
o processamento funcional e a operação comportamental do sistema a ser construído.
Este modelo servirá como base para o projeto de software e para a criação de sua
especificação. O analista geralmente é o responsável pelo desenvolvimento de uma
Especificação de Requisitos de Software e participa de todas as revisões.
O perfil dos stakeholders, ou pessoas envolvidas na definição dos requisitos, pode
ser assim definido:

75
(Animação 5) Casa Segura – Erros de Comunicação

A cena: Local de trabalho da equipe de engenharia de software.

Os personagens: Júnior, membro da equipe de software, Viviane, membro da equipe de software;

Edson, membro da equipe de software.

A conversa:

Edson: O que você sabe sobre esse projeto CasaSegura?

Viviane: A reunião inicial está programada para a próxima semana.

Júnior: Eu já fiz um pouco de investigação, mas não fui muito bem.

Edson: O que você quer dizer com isso?

Júnior: Bem, eu dei um telefonema para a Vanessa. Ela é a pessoa de marketing nessa coisa.

Viviane: E..?

Júnior: Eu queria que ela me contasse quais as funções e características do Casasegura... esse tipo
de coisa. Em vez disso, ela começou a me fazer perguntas sobre sistemas de segurança, sistemas
de vigilância... eu não sou especialista.

Viviane: e o que isso lhe diz?

( Júnior sacode os ombros)

Viviane: Que o marketing vai precisar da gente agindo como consultores, e que é melhor nós
fazermos a lição de casa sobre essa área de produto antes da reunião de partida. Douglas disse
que queria que “ colaborássemos” com nosso cliente, assim é melhor que a gente aprenda a fazer
isso.

Edson: Provavelmente teria sido melhor se você tivesse ido até a sala dela. Telefonemas não
funcionam tão bem para esse tipo de coisa.

Júnior: Vocês dois estão certos. Nós precisamos juntar a nossa ação ou nossas comunicações
iniciais vão ser uma luta.

Viviane: Eu vi o Douglas lendo um livro sobre “ engenharia de requisitos”. Aposto que lista alguns
princípios de boa comunicação. Vou pedir emprestado o livro para ele.

Júnior: Boa ideia, depois você pode nos ensinar.

Viviane ( sorrindo): É, está certo.

76
 Exercícios do Capítulo 4 – parte 1

Leia a descrição do sistema automático de emissão de passagens.

“Um sistema automático de emissão de passagens vende passagens de ônibus. Os usuários

escolhem seu destino e apresentam um cartão de crédito e um número de identificação
pessoal. A passagem é emitida e o custo dessa passagem é incluído em sua conta do cartão
de crédito. Quando o usuário pressiona o botão para iniciar, uma tela de menu com os
possíveis destinos é ativada, juntamente com uma mensagem para que o usuário selecione
o destino. Uma vez selecionado um destino, pede-se que os usuários insiram o cartão de
crédito. A validação do cartão é checada e o usuário, então, deve fornecer um número de
identificação pessoal. Quando a transação de crédito é validada, a passagem é emitida.”

Responda:
a) Aponte as ambiguidades e omissões.
b) Descreva os requisitos funcionais.
c) Descreva os requisitos não-funcionais.
d) Identifique os Stakeholders.

4.3. Tarefas da Engenharia de Requisitos

A Engenharia de Requisitos fornece um mecanismo adequado para entender o que

o cliente deseja, analisar as suas necessidades, negociar uma solução adequada ao seu
problema, validar a especificação e administrar os requisitos à medida que eles são
transformados em um sistema em operação. Para isso, o processo de ER é realizado por
meio de 7 etapas distintas, que serão explicadas no que se segue, com base em
Pressman (2006).

1. Concepção ou Estudo de Viabilidade do Sistema

O estudo de viabilidade é um estudo breve, direcionado, que se destina a responder
a algumas perguntas:

77
 O sistema contribui para os objetivos gerais da empresa?
O sistema pode ser implementado com a utilização de tecnologia atual dentro
das restrições de custo e prazo?
O sistema pode ser integrado com outros sistemas já em operação?
Após responder essas questões é necessário questionar as fontes de informação
(stakeholders). Para isso, são recomendadas algumas perguntas, como:
Como a empresa se comportaria, se esse sistema não fosse implementado?
Quais são os problemas com os processos atuais e como um novo sistema
ajudaria a diminuir esses problemas?
Que contribuição direta o sistema trará para os objetivos da empresa?
As informações podem ser transferidas para outros sistemas e também
podem ser recebidas a partir deles?
O sistema requer tecnologia que não tenha sido utilizada anteriormente na
empresa?
O que precisa e o que não precisa ser compatível com a empresa?
Quem vai usar o sistema?
Após obter essas respostas, deve-se preparar um relatório de viabilidade.

2. Levantamento dos Requisitos

Após os estudos iniciais de viabilidade, o próximo passo é o levantamento dos
requisitos. Nesta etapa deve-se descobrir mais informações sobre o domínio da
aplicação, que serviços o sistema deve oferecer, desempenho exigido, dentre
outros. O levantamento de requisitos pode envolver diferentes tipos de pessoas da
empresa, os stakeholders. Frequentemente os clientes não sabem na realidade o
que querem do sistema computacional, a não ser em termos muito gerais.
Costumam expressar os requisitos utilizando seus próprios termos e com o
conhecimento implícito de sua área de atuação. Diferentes stakeholders têm em
mente diferentes requisitos e podem expressá-los de maneiras distintas. Além disso,
fatores políticos podem influenciar os requisitos do sistema. O ambiente econômico
e de negócios, no qual a análise de requisitos ocorre, é dinâmico, ou seja,
inevitavelmente, o ambiente se modifica durante o projeto. Como consequência, a
importância dos requisitos específicos pode mudar. Assim, novos requisitos podem

78
 surgir por parte dos novos stakeholders, que não haviam sido consultados
inicialmente.
3. Análise de Requisitos
As informações obtidas do cliente durante a concepção e o levantamento são
expandidas e refinadas durante a análise (ou elaboração) de requisitos. Esta
atividade da ER tem por objetivo desenvolver um modelo técnico refinado das
funções, características e restrições do software. É guiada pela criação e
refinamento de cenários do usuário que descrevem como o usuário final (e outros
atores) vão interagir com o sistema.

As etapas de Levantamento e Análise de Requisitos são conhecidas em conjunto como

Elicitação de Requisitos e envolvem:
Compreensão do domínio: Os analistas devem desenvolver sua compreensão do
domínio da aplicação. Por exemplo, se for um sistema para uma loja, o analista
deverá descobrir como operam as lojas de varejo.
Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para
descobrir seus requisitos. Certamente a compreensão do domínio se desenvolve mais
durante essa atividade.
Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e
os organiza em grupos coerentes.
Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os
requisitos podem apresentar conflitos. Essa atividade se ocupa em encontrar e
solucionar esses possíveis conflitos.
Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais
importantes do que outros. Esse estágio envolve a interação com os stakeholders,
para descobrir os requisitos mais importantes.
Verificação de requisitos: Os requisitos são verificados, a fim de se descobrir se eles
são completos e consistentes e se estão em concordância com o que os stakeholders
realmente desejam do sistema.

4. Negociação dos Requisitos

A negociação categoriza e organiza os requisitos em subconjuntos relacionados.
Neste passo as seguintes perguntas devem ser respondidas:
Cada requisito está consistente com o objetivo global do sistema?
Todos os requisitos foram especificados no nível de abstração adequado?
O requisito é realmente necessário ou representa uma característica adicional
que pode não ser essencial para o objetivo do sistema?

79
 Cada requisito é limitado e não-ambíguo?
Cada requisito tem atribuição? (Será utilizado por alguém)
Algum requisito conflita com outros requisitos?
Cada requisito é realizável no ambiente técnico?
Cada requisito pode ser testado, quando estiver implementado?
Qual é a prioridade desse requisito?

5. Especificação dos Requisitos

Especificação de Requisitos, geralmente é um documento escrito, que contém o
detalhamento do sistema, os requisitos funcionais e não-funcionais e os modelos do
sistema que podem ser representados através de diagramas como IDEF0
(Integration Definition for Function Modeling), diagramas de casos de uso da UML
(Unified Modeling Language), diagramas de classes preliminar, diagramas de
sequência e prototipação.

6. Validação dos Requisitos

A validação de requisitos examina a especificação de requisitos para garantir que
todos os requisitos do sistema tenham sido identificados e detalhados, que as
inconsistências, omissões e erros tenham sido detectados e corrigidos e que as
prioridades tenham sido estabelecidas. Tem a função de mostrar que os requisitos
realmente definem o sistema que o cliente deseja. São realizadas diversas
verificações, como:
Verificações de validade: Um usuário pode pensar que um sistema é
necessário para realizar certas funções, mas mais estudos e análises podem
identificar funções adicionais ou diferentes necessárias.
Verificações de consistência: Os requisitos em um documento não devem ser
conflitantes, ou seja, não devem existir restrições contraditórias ou descrições
diferentes para uma mesma função do sistema.
Verificações de completeza: O documento de requisitos (DERS) deve incluir
requisitos que definam todas as funções e restrições exigidas pelo usuário do
sistema.
Verificações de realismo: Utilizando o conhecimento da tecnologia existente,
os requisitos devem ser verificados, a fim de assegurar que eles realmente

80
 podem ser implementados. Essas verificações devem também levar em conta
o orçamento e os prazos para o desenvolvimento do sistema.
Facilidade de verificação: Para reduzir o potencial de divergências entre
cliente e desenvolvedor, os requisitos do sistema devem sempre ser escritos
de modo que possam ser verificados. Isso significa que um conjunto de
verificações pode ser projetado para mostrar que o sistema entregue cumpre
com esses requisitos.
O requisito é realmente passível de ser testado, como foi definido?
O requisito pode ser adequadamente compreendido pelos
compradores ou usuários finais do sistema?
A origem do requisito é claramente definida?
O requisito é adaptável?
Ele pode ser modificado sem que isso provoque efeitos em grande
escala em outros requisitos do sistema?
Um dos mecanismos de validação de requisitos é a RTF- Revisão Técnica Formal
(Capítulo 26, item 26.4.1. Pressman, 2006). Em uma RTF com esse propósito, a
equipe de desenvolvimento deve conduzir o cliente pelos requisitos do sistema,
explicando as implicações de cada requisito. A equipe de revisão deve verificar cada
requisito, em termo de sua consistência e verificar os requisitos como um todo sob o
ponto de vista de sua completeza. A RTF é uma atividade que garante a qualidade
do software.

7. Gestão de Requisitos

Gestão de Requisitos é um conjunto de atividades que ajuda a equipe de projeto a

identificar, controlar e rastrear requisitos e modificações de requisitos a qualquer
momento no desenvolvimento do sistema. Para auxiliar na gestão de requisitos
tabelas de rastreamento são criadas com o objetivo de verificar as relações entre
requisitos e o impacto da mudança de requisitos. Os requisitos mudam e há uma
série de razões para isso, como: os problemas podem ser muito intricados, as
especificações podem ficar incompletas, o aumento do entendimento do sistema
ocorre ao longo do projeto, como há vários usuários, há várias visões, quem paga
pelo sistema geralmente é diferente de quem o usa, a empresa e o ambiente se
modificam e, na medida em que os usuários se familiarizam com o sistema, novos

81
 requisitos surgem. A gestão de requisitos precisa de apoio automatizado como
ferramentas CASE - Computer Aided Software Engineering para:
Armazenamento de requisitos: os requisitos devem ser mantidos em um
depósito de dados seguro, gerenciado, que seja acessível por todos os
envolvidos no processo de engenharia de requisitos.
Gerenciamento de mudanças: esse processo pode ser simplificado se o
apoio de ferramentas estiver disponível.
Gerenciamento de facilidade de rastreamento: o apoio de ferramentas para a
rastreabilidade permite que sejam descobertos requisitos relacionados.
1)

82
 Com base na animação que você
acabou de assistir, caro aluno, as dicas
que podemos lhe dar para quando você
estiver tentando descobrir o que o seu
cliente quer do seu novo software são:

• Em primeiro lugar evite perguntar

ao cliente o que ele quer que o
novo sistema faça
• Entenda, primeiro, como são
atualmente os processos do seu
cliente
• Pergunte ao cliente quais processos que ele sabe que funcionam bem no sistema
atual. Faça o cliente explicar porque ele acha que funcionam bem. Faça o mesmo
com os processos que existem e funcionam mal.
• Descubra quais são os processos atuais que existem, mas que ninguém usa e
porque não são usados.
• Baseado nessas informações, desenvolva uma lista ou um protótipo do que você
acredita que o cliente precisa. Quanto mais claramente esse protótipo puder ser
compreendido pelo cliente melhor. Por exemplo, se for um cliente da área técnica
você poderá lhe mostrar os casos de uso ou usar diagramas mais técnicos. Se for
um cliente de negócio, você vai precisar de algo mais visual, então faça desenhos
ou crie uma animação…
• Faça o cliente analisar o seu protótipo ou sua lista, mesmo que seja difícil para ele.
Procure estar sempre “cara-a-cara” com seu cliente enquanto ele estiver fazendo a
análise.
• Assinale os requisitos que o cliente concorda e aqueles que ele discorda. Baseado
nessas informações descubra se ainda existem pontos do processo que você não
entendeu corretamente.
• Faça um novo protótipo ou uma nova lista. A partir daqui o processo se repete até
que o cliente concorde com a maioria dos requisitos do sistema. Ter 100% de
concordância não é fácil, mas deve haver uma sensação de comprometimento e de
entendimento entre você e seu cliente após este processo.

83
4.4. Elicitação de Requisitos

De acordo com o PMBoK –

Project Management Body of
Knowledge, um guia que reúne o
conjunto de Melhores Práticas em
Gerenciamento de Projetos produzido
pelo PMI - Project Management
Institute (2008), o processo de elicitação de requisitos envolve:

• Coleta
Processo de definir e documentar as funções e funcionalidades do projeto e do produto
necessárias para atender às necessidades e expectativas dos stakeholders. O sucesso
do projeto é diretamente influenciado pela atenção na coleta e gerenciamento dos
requisitos do projeto e do produto. Os requisitos incluem as necessidades quantificadas
e documentadas e as expectativas do patrocinador, cliente e demais stakeholders.
Estes requisitos precisam ser obtidos, analisados e registrados com detalhes
suficientes para serem medidos uma vez que a execução do projeto se inicie. Coletar
os requisitos reúne as atividades de definir e gerenciar as expectativas do cliente.
• Entrevistas
Uma entrevista é um meio que pode ser formal ou informal de se descobrir informações
dos stakeholders por meio de conversas diretas. Normalmente é feita por meio de
perguntas preparadas ou espontâneas e do registro das respostas. São
frequentemente conduzidas individualmente, mas podem envolver múltiplos
entrevistadores e/ou entrevistados. Entrevistar participantes experientes, stakeholders e
especialistas no assunto do projeto pode auxiliar na identificação e definição das
características e funções das entregas desejadas.
• Documentação
Os componentes da documentação podem incluir, mas não estão limitados a:
A necessidade do negócio ou oportunidade a ser aproveitada, descrevendo as
limitações da situação atual e por que o projeto foi empreendido
Objetivos do negócio e do projeto para permitir rastreamento
Requisitos funcionais descrevendo processos de negócio, informações e
interação com o produto de forma apropriada a ser documentada textualmente
84
 Requisitos não funcionais, tais como nível de serviço, desempenho, cuidados,
segurança, atendimento
ento a leis e regulamentos, etc
Impactos em outras áreas organizacionais
organizaci
Impactos em outras entidades internas
internas ou externas à organização

A figura 17 ilustra o fluxo ao qual é submetida uma análise de requisitos toda vez
que o cliente manifesta uma (nova) necessidade.

Figura 17 – Fluxo da análise de requisitos

Fonte: http://blogbohm.com/2010/10/18/analise-de-requisitos-como-ferramenta
http://blogbohm.com/2010/10/18/analise ferramenta-de-planejamento/

85
 Para que este processo ocorra com sucesso, os requisitos devem ser claros,
completos, sem ambiguidade, implementáveis, consistentes e testáveis como mostra a
tabela 1. Os requisitos que não apresentem estas qualidades são problemáticos: eles
devem ser revistos e renegociados com os clientes e usuários.

Tabela 1 – Características dos requisitos

Não ambíguo todo requisito tem apenas uma interpretação possível.
todo requisito representa algo requerido ao sistema/funcionalidade a
Correto
ser construído.
contém tudo o que o software deve fazer e atender em todas as
Completo
situações possíveis.
todas as pessoas podem facilmente compreender o significado de
Compreensível
todos os requisitos com um mínimo de explicação.
atendem ao conjunto de técnicas que podem ser usadas para verificar
Verificável
que todo requisito está implementado pelo sistema.
Internamente não há requisitos conflitantes entre si.
Consistente
Externamente não há requisitos conflitantes com outra documentação de projeto já
Consistente definida.
possibilita que um projeto seja implementado corretamente com
Realizável
todos os requisitos declarados.
é tão pequeno quanto possível, sem afetar qualquer outra qualidade
Conciso
que deva atender.
é escrito de modo que facilite o “referenciamento” de cada requisito
Rastreável
individualmente.
sua estrutura e estilo são tais que qualquer mudança pode ser feita
Modificável
facilmente, completamente e consistentemente.
Anotado por permite que se possa facilmente determinar qual requisito é mais
Importância Relativa importante para os clientes.
Anotado por permite que se possa facilmente determinar qual requisito é mais
Estabilidade Relativa suscetível à mudança.
permite que se possa facilmente localizar informações e
Organizado
relacionamentos lógicos entre seções adjacentes.

86
(Animação 7) Casa Segura – Engenharia de Sistema Preliminar

A Cena: O espaço de trabalho da equipe de engenharia de software depois do encontro inicial

ter ocorrido.

Os participantes: Júnior, membro da equipe de software, Viviane, membro da equipe de

software, Edson, membro da equipe de software.

Locutor (voz): Esta conversa se passa depois do encontro inicial ter ocorrido.

A conversa:

Edson: Eu penso que foi muito bem

Viviane: Sim...mas tudo o que fizemos foi olhar o sistema global – temos bastante trabalho de
levantamento de requisitos a fazer para o software.

Júnior: É por isso que temos reuniões adicionais programadas para os próximos cinco dias.
Aliás, sugeri que dois dos “clientes” se deslocassem até aqui por algumas das próximas
semanas. Você sabe, viver conosco de modo que possamos realmente nos comunicar, quer
dizer, colaborar.

Viviane: Como foi isso?

Júnior: Bem, eles me olharam como se eu fosse louco, mas Douglas [o gerente de engenharia
de software] gosta da ideia – ela é ágil – assim ele está falando com eles.

Edson: Fiz anotações usando meu tablet durante a reunião, e cheguei a uma lista de funções
básicas.

Júnior: Excelente. Vamos ver.

Edson: OK. Vou ler o que escrevi.

Anotações preliminares sobre a estrutura/fucionalidade do CasaSegura:
- O sistema fará uso de um ou mais PCs, vários painéis montados nas paredes e/ou painéis de
controle portáteis e vários sensores e controladores de eletrodomésticos/dispositivos
- Todos se comunicarão via protocolos sem fio
- Todo software, com exceção de nossa caixa sem fio, será de prateleira
- Em relação às funções de segurança da residência haverá monitoração por sensor de
movimento.
Monitoração de níveis de CO, fogo, fumaça. Monitoração de níveis de água em porões.
Monitoração de movimento externo. Modificação de segurança via internet.

(Como a lista é grande e não cabe relacioná-la inteira, o som vai diminuindo e a imagem se
esvaindo até finalizar).

87
 4.4.1. Técnicas de Coleta de Requisitos

A coleta ou extração de requisitos é feita através de técnicas. Nesta etapa, os

requisitos são documentados à medida em que são coletados e deste processo resulta um
documento preliminar dos requistos do sistema. No que se segue serão apresentadas as
principais técnicas utilizadas.

4.4.1.1 Entrevistas

Refere-se a uma série de encontros com os

clientes ou usuários que explicam o seu trabalho,
ambiente em que atuam, necessidades, dentre outros
assuntos pertinenetes. Requer, do analista de
requisitos, habilidades sociais como saber ouvir, saber
inferir, saber dirimir conflitos. Estas habilidades são
estendidas à equipe de desenvolvimento. Os 4 passos
de uma entrevista são:

[1] Planejamento da Entrevista:

Deve-se decidir quem será entrevistado.
Preparar os entrevistados (agendar data e hora, comentar sobre o assunto).
Preparar a lista de questões de diversos tipos:
o Abertas: “Explique como esse relatório é produzido.”
o Fechadas: “Quantos relatórios desse tipo são gerados?”
o Sequenciais: “Por quê?” “Dê um exemplo. ” deve-se preocupar em dar
continuidade a uma questão.
o Preparar mais de uma questão para um tópico a fim de confirmar a
resposta e deixá-la mais completa.
[2] Condução da Entrevista:
Pirâmide: Começa com questões fechadas e expande para questões abertas
dirigidas. É uma abordagem importante quando o entrevistado parece
relutante em falar do assunto.
Funil: Começa obtendo detalhes e dá continuidade obtendo respostas diretas.
Muitas questões fechadas e sequenciais tornam-se desnecessárias.

88
 Diamante: Combina as duas abordagens anteriores. A entrevista fica menos
cansativa, pois varia o tipo de questão. Na entrevista não deve-se induzir
respostas, como “O relatório deveria ser gerado semanalmente?”
[3] Finalização da Entrevista:
Deve-se reservar um tempo, o menor possível, que seja adequado para
sumarizar as informações recebidas. O analista deve explicar os próximos
passos ao cliente e apresentar a importância da entrevista, agradecendo o
entrevistado.
[4] Análise de Resultados:
Deve-se produzir um documento da entrevista e descobrir ambiguidades, conflitos e
omissões. As informações devem ser consolidadas e documentadas.

Mas a técnica de entrevista apresenta diversos problemas:

• Observação: pessoas diferentes se concentram em diferentes aspectos e
podem “ver” coisas diferentes.
• Interpretação: o entrevistador e o entrevistado podem estar interpretando
palavras comuns de maneira diferente, tais como “pequena quantidade de
dados” ou “caracteres especiais”.
• Ambiguidades: há ambigüidades inerentes à maioria das formas de
comunicação, especialmente em linguagem natural.
• Conflitos: entrevistador e entrevistado podem ter opiniões conflitantes sobre
um determinado problema e a tendência é registrar o ponto de vista do
entrevistador.

4.4.1.2. Questionários

É uma forma rápida de se obter dados de uma grande quantidade de usuários que
podem estar em lugares geograficamente distintos. Os tipos de dados que podem ser
coletados através de questionários são:
Dados sobre a utilização do sistema atual
Problemas e dificuldades que os usuários enfrentam em seu trabalho
Expectativa dos usuários em relação ao novo sistema
As questões devem ser claras e objetivas. Deve-se preparar mais de uma questão
para um tópico a fim de confirmar a resposta e deixá-la mais completa.
89
 Os tipos de questões que compõem os questionários são:
• Abertas-dirigidas: Antecipam o tipo de resposta. Devem ser utilizadas quando
não é possível ou não deve-se criar alternativas. Por exemplo: “Por que você
acha que os manuais do usuário do sistema financeiro não funcionam?”
• Fechadas: Utilizadas quando é possível listar as possíveis alternativas. Por
exemplo: “Os dados sobre vendas são entregues com que frequência?
Alternativas: diariamente, semanalmente, quinzenalmente, mensalmente,
trimestralmente”.
Na elaboração do questionário, os seguintes cuidados devem ser tomados:
Questões mais importantes devem vir primeiro.
Questões com conteúdo semelhante e relacionadas devem estar próximas.
Questões que podem gerar controvérsias devem ser deixadas para depois.

4.4.1.3. Brainstorming

É uma técnica básica para geração de ideias. Devem ser realizadas uma ou várias
reuniões que permitam que as pessoas sugiram e explorem ideias sem que sejam
criticadas ou julgadas. Deve existir um líder responsável por conduzir a reunião sem
restringi-la. É especialmente útil no começo do processo de extração de requisitos. Mas
apresenta uma desvantagem, já que não é uma técnica não muito estruturada, pode não
produzir a mesma qualidade ou nível de detalhe que se consegue com outras técnicas. O
brainstorming (ou tempestade cerebral) basicamente é dividido em duas etapas:
[1] Geração das ideias:
São as reuniões que tem como objetivo fornecer ideias,
sem discussões sobre o mérito delas. Existem 4 regras:
É proibido criticar ideias.
Ideias não convencionais ou estranhas são
encorajadas.
Número de ideias geradas deve ser bem grande.
Os participantes devem ser encorajados a
enriquecer as ideias dos outros participantes.
[2] Consolidação das ideias:
As ideias geradas são discutidas, revisadas, organizadas, avaliadas, consolidadas,
descartadas e priorizadas.
90
(Animação 8) Casa Segura – Condução de uma Reunião de Coleta de Requisitos

A Cena: Uma sala de reunião. A primeira reunião de coleta de requisitos está em progresso.

Os personagens: Júnior, membro da equipe de software, Viviane, membro da equipe de

software, Edson, membro da equipe de software; Douglas, gerente de engenharia de software;
três membros de marketing; um representante de engenharia de produto e um facilitador.

Locutor (voz): A primeira reunião de coleta de requisitos está em progresso.

A conversa:

Facilitador (apontando para o quadro): Então, esta é a lista atual de objetos e serviços para a
função de segurança residencial.

Pessoa de Marketing: Isso praticamente cobre tudo do nosso ponto de vista.

Viviane: Alguém não mencionou que queria toda a funcionalidade da CasaSegura acessível via
Internet? Isso incluiria a função de segurança residencial, não?

Pessoa de Marketing: É, está certo...vamos ter de acrescentar essa funcionalidade e os objetos

adequados.

Facilitador: Isso também acrescenta algumas restrições?

Júnior: Sim, tanto técnicas quanto legais.

Representante da Produção: O que isso significa?

Júnior: Precisamos estar certos de que uma pessoa de fora não pode invadir o sistema,
desarmá-lo e roubar o lugar ou pior. Pesada responsabilidade de nossa parte.

Douglas: Muito certo.

Marketing: Mas nós ainda precisamos de conectividade via Internet...basta nos certificarmos
de impedir a invasão de uma pessoa de fora.

Edson: Isso é mais fácil de falar do que de fazer e...

Facilitador (interrompendo): Eu não quero discutir esse ponto agora. Vamos anotá-lo como
um item de ação e prosseguir.

(Douglas, servindo como secretário da reunião faz a anotação adequada).

Facilitador: Tenho um sentimento de que existe ainda mais a considerar.

(Locutor (voz): O grupo gasta os 45 minutos seguintes refinando e expandindo os detalhes da

função de segurança residencial).
91
4.4.1.4. JAD - Joint Application Development

Técnica utilizada para promover a cooperação, o entendimento e o trabalho em

grupo entre usuários e desenvolvedores. É baseada em quatro
uatro princípios:
1. Dinâmica em grupo:
grupo: utilização de sessões de grupo (encontros de usuários
usuário
e desenvolvedores).
2. Uso de técnicas visuais:
visuais utilização de data-show, projetor, vídeos, etc.
3. Manutenção do processo organizado e racional:
racional: controle da sessão através
de um líder que tem o objetivo final de identificar um conjunto preliminar de
requisitos.
4. Utilização de documentação padrão:
padrão: criação de um documento com os
requisitos identificados.
identificados
Geralmente existem seis papéis (responsabilidades) divididas entre a equipe de
desenvolvimento e usuários, que são: líder da sessão, engenheiro de requisitos, executor,
representantes dos usuários, representantes
representantes de produtos de software e especialistas.

4.1.1.5. 5W1H

A técnica 5W1H é mundialmente difundida e utilizada em diversos tipos de

situações, sendo muito útil na coleta de requisitos.
requis Vamos ver o que são os 5 Ws e o único
H, assim como algumass perguntas comumente aplicadas nestas fases.
• Who (Quem) – refere-se
se às responsabilidades
Quem é o cliente / usuário
us do
sistema? Who
Quem executa?
Quem gerencia? When What

Quem fornece?
Quem participa das decisões? 5W1H
• What (O Que) – refere-se
se às etapas
Why Where
Quais
uais são as entradas do
sistema?
How
Quais são as saídas?
Quais são os indicadores?
Quais são as metas?

92
 Quais são os recursos?
Quais são os problemas?
Quais são os métodos / tecnologias empregados?
Que informações ou insumos são necessários para o trabalho? Quem as
fornecem?
Quais são as regras que determinam como o trabalho será feito?
Há alguma coisa que possa parar, atrasar ou impedir o processo?
Há espera para completar o processo?
Quais são as exceções?
Quais são as alternativas, caso o sistema não funcione conforme as
expectativas?
Qual ação é tomada quando uma etapa falha?
• When (Quando) – refere-se ao tempo
Quando é planejado o processo?
Quando é executado?
Quando é avaliado?
Quanto tempo leva o processo?
Com que frequência a atividade é executada?
• Where (Onde) refere-se aos locais
Onde é planejado o processo?
Onde é executado?
Onde é avaliado?
• Why (Porque) – refere-se às justificativas
Porque / para que esse processo existe?
Quais são os fatores que determinam quando um produto é aceitável?
• How (Como) – refere-se aos métodos
Como é planejado o processo?
Como é executado?
Como é avaliado?
Como as informações são registradas e disseminadas?
Como é avaliada a satisfação do cliente?
Como são as medidas específicas associadas ao sistema, caso existam?

93
 4.4.1.6. PIECES - Performance, Informação, Economia, Controle, Eficiência,
Serviços

Quando o desenvolvedor inexperiente apresenta dificuldades em determinar como

começar e o que perguntar para extrair os requisitos do cliente, é interessante utilizar a
técnica PIECES, pois ela ajuda a resolver esse problema. A técnica fornece um conjunto
de categorias de problemas que ajudam o engenheiro de requisitos a estruturar o processo
de extração de requisitos. Em cada categoria existem várias questões que o
desenvolvedor deve explorar com os usuários. Pode ser adaptada para domínios de
aplicação específicos.
As seis categorias de questões são:
1) Performance: reflete o que usuário espera
2) Informação (e dados): refere-se ao tipo de acesso às informações: relatórios,
funções on-line; inclui a quantidade de informação oferecida pelo software: na
medida certa, no tempo propício e em forma utilizável
3) Economia: relaciona-se ao custo de usar um produto de software:
processadores, armazenagem, conexões de rede, etc
4) Controle: inclui as restrições de acesso ao sistema, acesso a algumas
informações e habilidade de monitorar o comportamento do sistema
5) Eficiência: procura evitar coletar o mesmo dado mais de uma vez e armazená-lo
em espaços múltiplos
6) Serviços: refere-se a que tipo de serviços os usuários necessitam que o
software realize

4.4.1.7. Prototipação

Técnica que tem como objetivo extrair, entender e validar os requisitos. É baseada
no conceito do processo de desenvolvimento de software de prototipação, já estudado
anteriormente. Um protótipo do produto pode ser construído. Através do protótipo, os
usuários podem descobrir quais são as suas reais necessidades. É benéfica somente se
protótipo puder ser construído de forma mais rápida que o sistema real. É especialmente
útil para superar dificuldades de comunicação de necessidades por parte dos usuários.

94
 4.4.2. Considerações sobre as Técnicas de Coleta de Requisitos

Caro aluno, as técnicas apresentadas visam superar as dificuldades inerentes ao

processo de extração dos requisitos. Nenhuma técnica é suficiente por si só. Você, como
desenvolvedor, deve escolher um conjunto de técnicas que melhor se adaptem ao produto
a ser desenvolvido. Mas podemos elencar alguns procedimentos gerais que podem fazer
parte de qualquer processo de extração de requisitos e ajudá-lo neste processo:
Você deve perguntar e identificar as pessoas apropriadas para responder quais são
os requisitos
Você deve observar o comportamento dos usuários de um produto existente e inferir
suas necessidades a partir de seu comportamento
Você deve discutir com os usuários suas necessidades e junto com eles formular
um entendimento comum dos requisitos
É importante você negociar com os usuários, a partir de um conjunto-padrão de
requisitos, quais serão incluídos, excluídos ou modificados
Você deve estudar e identificar os problemas, isso ajuda a identificar os requisitos
que podem melhorar o produto

Na geração do documento preliminar dos requisitos extraídos em qualquer

técnica, pode-se utilizar Modelo de Caso de Uso da UML para se ter uma
ideia geral do escopo do produto de software. Geralmente esse não é o
modelo final, mas serve como subsídio para a próxima etapa da Engenharia
de Requisitos referente à análise e negociação de requisitos.

Coleção de artigos sobre Engenharia de Requisitos

http://analiserequisitos.blogspot.com/

Estudo de caso na área médica:

http://www.scielo.br/scielo.php?pid=S0103-
17592009000400014&script=sci_arttext

Manual em Português sobre Certificação PMI em Gerenciamento de Projetos

PMBok:
http://www.pmi.org/~/media/PDF/Certifications/PT_PMP_Handbook_Full_Portugu
ese.ashx
95
(Animação 9) Casa Segura – Desenvolvimento de um Cenário de Usuário
Preliminar
A cena: Uma sala de reunião, continuando a primeira reunião de coleta de requisitos.

Os personagens: Júnior, membro da equipe de software; Viviane, membro da equipe de

software; Edson, membro da equipe de software, Douglas, gerente de engenharia de software;
três membros de marketing, um representante de engenharia de produção e um facilitador.

A conversa:
Facilitador: Estivemos conversando sobre segurança de acesso à funcionabilidade do
CasaSegura que vai ficar acessível via Internet. Eu gostaria de tentar algo.
Vamos desenvolver um cenário de usuário para acesso à função de segurança residencial.
Júnior: Como?
Facilitador: Podemos fazê-lo de diferentes modos, mas, por agora, eu gostaria de conservar as
coisas realmente informais. Conte-nos (ele aponta para uma pessoa de marketing) como você
imagina o acesso ao sistema.
Pessoa de Marketing: Hmm, bem, isso é o tipo de coisa que eu faria se estivesse longe de casa
e tivesse de deixar alguém entrar nela, por exemplo, uma arrumadeira ou uma pessoa de
manutenção que não tivesse o código de segurança.
Facilitador (sorrindo): Essa é razão pela qual você faria isso... diga-me como você realmente
faria isso.
Pessoa do Marketing: Hmm... a primeira coisa que eu precisaria seria de um PC. Eu entraria no
site que nós manteríamos para todos os usuários do CasaSegura. Forneceria a minha ID de
usuário e...
Viviane (interrompendo): A página web teria de ser segura, criptografada para garantir que
estivéssemos seguros e...
Facilitador ( interrompendo): Essa é uma boa informação, Viviane, mas é técnica. Vamos
apenas nos concentrar sobre como usuário final vai usar a possibilidade, certo?
Viviane: Sem problemas.
Pessoa de Marketing: Então, como eu estava dizendo, eu entraria em um site e forneceria
minha ID de usuário e dois níveis de senha.
Júnior: E se eu esquecesse minha senha?
Facilitador (interrompendo): Boa ideia, Júnior, mas não vamos cuidar disso agora. Vamos fazer
uma anotação sobre isso e chamá-la de “exceção”. Estou certo de que haverá outras.
Pessoa de Marketing: Depois que eu introduzisse as senhas, uma tela representando todas as
funções CasaSegura apareceria . Eu selecionaria a função segurança residencial. O sistema
poderia solicitar que eu verificasse quem sou, digamos perguntando o meu endereço ou o
número de telefone ou alguma outra coisa. Depois, ele exibiria uma figura do painel de controle
do sistema de segurança junto com uma lista de funções que eu poderia realizar – armar o
sistema, desarmar o sistema, desarmar um ou mais sensores. Acho que ele poderia também me
permitir reconfigurar zonas de segurança e outras coisas análogas, mas não estou certo disso.

( Locutor(voz): À medida que a pessoa de marketing continua a falar, Douglas faz várias
anotações. Elas formam a base do primeiro cenário de caso de uso informal. Alternativamente,
a pessoa de marketing poderia ter sido solicitada a redigir o cenário, mas isso seria feito fora da
reunião.)

96
Exercícios do Capítulo 4 – parte 2

1) Stakeholder é qualquer pessoa que vá comprar o software em desenvolvimento.

a) Verdadeiro
b) Falso

2) É relativamente comum para diferentes usuários propor requisitos conflitantes, cada qual
argumentando que sua versão é a mais adequada ou melhor.
a) Verdadeiro
b) Falso

3) Na validação de requisitos, o modelo de requisitos é revisto para assegurar sua viabilidade

técnica.
a) Verdadeiro
b) Falso

4) Faça a associação e assinale a resposta correta sobre a técnica PIECES:

i-Performance ii-Informação iii-Economia iv-Controle v-Eficiência vi-Serviços

A- relaciona-se ao custo de usar um produto de software: processadores, armazenagem,

conexões de rede, etc
B- inclui as restrições de acesso ao sistema, acesso a algumas informações e habilidade de
monitorar o comportamento do sistema
C- reflete o que usuário espera
D- refere-se a que tipo de serviços os usuários necessitam que o software realize
E- refere-se ao tipo de acesso às informações: relatórios, funções on-line; inclui a quantidade de
informação oferecida pelo software: na medida certa, no tempo propício e em forma utilizável
F- procura evitar coletar o mesmo dado mais de uma vez e armazená-lo em espaços múltiplos

a) i-C ii-E iii-A iv-B v-F vi-D

b) i-F ii-C iii-A iv-E v-D vi-B
c) i-E ii-D iii-B iv-F v-C vi-A
d) i-A ii-E iii-F iv-C v-B vi-D

97
5) Qual é o principal objetivo da Engenharia de Requisitos?

6) Qual a definição de requisitos segundo o IEEE?

7) Defina Requisitos Funcionais e Requisitos Não-Funcionais.

8) O que se entende por stakeholder?

9) Quais os benefícios que se espera de um documento de especificação de requisitos?

10) Um dos principais pontos a se considerar em qualquer projeto é o chamado estudo de

viabilidade. Para projetos de software não é diferente. Relacione as principais questões que
se deve considerar no estudo de viabilidade de um projeto de software.

11) Cite algumas técnicas de levantamento de requisitos estudadas na disciplina.

98
 Considerações Finais
Caro aluno, essa disciplina introduziu muitos aspectos essenciais para a prática da
Engenharia de Software. Vimos que o processo de desenvolvimento de software envolve
atividades, recursos e produtos.
Vimos que um modelo de processo é útil para orientar o comportamento quando
você estiver trabalhando em grupo. Modelos de processo detalhados nos dizem como
coordenar e colaborar com nossos colegas, enquanto se projeta e se contrói um sistema.
Os modelos também mostram a cada membro da equipe quais atividades ocorrem, quando
e por quem elas são realizadas, de modo a tornar clara a divisão de tarefas.
Vimos que os requisitos podem ser modificados até mesmo enquanto analisamos o
problema e desenvolvemos a solução. E que a solução deve estar bem documentada e ser
flexível, devendo-se documentar as suposições e os algoritmos utilizados, de tal modo que
seja fácil mudá-los posteriormente.
Possivelmente, caro aluno, você fará grande parte do seu trabalho como membro de
uma equipe de desenvolvimento maior. Como vimos nessa disciplina, o desenvolvimento
de software envolve análise de requisitos, projeto, implementação, teste, gerência de
configuração, garantia da qualidade, dentre outras atividades. Você e outras pessoas de
sua equipe podem desempenhar vários papéis, e o sucesso do projeto depende em larga
escala da comunicação e coordenação entre os membros da equipe.
Vimos também que você pode ajudar no sucesso de seu projeto, selecionando um
processo de desenvolvimento apropriado ao tamanho da equipe, ao nível de risco do
projeto e ao domínio do aplicativo, bem como utilizando ferramentas bem integradas que
apóiem o tipo de comunicação necessária ao seu projeto.
No andamento do nosso curso, vários aspectos fundamentais estudados nesta
disciplina serão abordados em maiores detalhes, proporcionando a você, caro aluno, um
entendimento e um conhecimento maior dos conceitos, métodos, técnicas e ferramentas
da Engenharia de Software que auxiliam na obtenção de um produto de qualidade,
respeitando os prazos, custos e escopo estabelecidos.

Prof. Marcelo Pintaud e Profa. Elisamara

99
 Respostas Comentadas dos Exercícios
Capítulo 1

1) Qual das questões abaixo não é mais uma das grandes preocupações de um engenheiro de software?
d) Por que hardware é tão caro?

2) Software é um produto que pode ser manufaturado usando as mesmas tecnologias usadas para
outros artefatos de engenharia.
b) Falso

3) Software deteriora-se ao invés de se desgastar porque:

c) Mudanças frequentes aumentam a probabilidade de introduzir erros no software

4) Atividades “guarda-chuva” de engenharia de software são aplicadas somente durante as fases iniciais
do desenvolvimento de software:
b) Falso

5) O que caracterizou a chamada “crise do software”?

A “crise do software” foi um termo criado para descrever as dificuldades enfrentadas no desenvolvimento
de software no final da década de 1960. 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. Essa
crise teve como origem a introdução de computadores “mais poderosos”. Mas a caracterização da crise teve
como ponto fundamental o fato de que os softwares eram entregues fora do prazo, com custos mais
elevados do que os projetados inicialmente e com uma qualidade aquém do esperado.

6) Conforme vimos, Engenharia de Software é uma disciplina da Engenharia que se ocupa de todos os
aspectos da produção de software. Seu principal objetivo é fornecer uma estrutura metodológica para a
construção de software com alta qualidade. O que é necessário para que isso aconteça?
aplicar teorias, métodos e ferramentas nas situações apropriadas nas diversas etapas do
desenvolvimento
trabalhar de acordo com as restrições organizacionais e financeiras procurando soluções que
estejam dentro dessas restrições
gerenciar os projetos de software para que o resultado final esteja dentro do escopo, custo e prazos
planejados
adotar uma abordagem sistemática e organizada (maneira mais eficaz de produzir software de alta
qualidade)

7) Normalmente, para o leigo, software se constitui no “código fonte + código executável”. Vimos
que para a Engenharia de Software, o conceito de software é algo mais abrangente. Como Pressman
conceitua software?
“Instruções (programas de computador) que, quando executadas, produzem a função e o desempenho
desejados; (2) Estruturas de dados que possibilitam que os programas manipulem adequadamente a
informação; (3) Documentos que descrevem a operação e o uso dos programas”.
100
8) O processo de desenvolvimento do software apresenta diferenças fundamentais em relação ao
hardware. Cite algumas dessas diferenças.
O processo criativo do hardware gera algo físico (por exemplo, placas de circuitos). O
desenvolvimento de software resulta em um elemento pertencente a um sistema lógico, intangível;
O software geralmente é desenvolvido sob medida, ao contrário do hardware, no qual o projetista
tem acesso a componentes existentes que executam tarefas definidas.
O projetista do software nem sempre terá acesso a módulos prontos para utilização e quando o faz,
pode elevar o risco do produto devido a questões de segurança;
Os custos do software estão concentrados no desenvolvimento e não no processo de manufatura.
Isto significa que não pode ser gerido como projeto de manufatura;
Ao longo do tempo, o produto de software não se desgasta, mas se deteriora em função da
introdução de erros oriundos de atividades de manutenção ou evoluções implícitas no processo que
devem ser reconsideradas no modelo original.

9) Faça um esboço das curvas de taxa de falhas do hardware e do software. Explique as

diferenças entre as curvas.
Hardware: Software:

Diferenças: no caso do hardware, há um alto índice de falhas no início do seu ciclo de vida originadas de
defeitos de fabricação e projeto; depois os defeitos são corrigidos dando estabilidade nas falhas; no final
do ciclo de vida do produto podem surgir problemas relacionados ao desgaste do uso. Diferentemente
da curva teórica de falhas do hardware, o software não sofre processos de envelhecimento como o
hardware, pois o software não é algo físico. No início do ciclo de vida do software, há problemas que
serão ajustados no decorrer do desenvolvimento e se estabilizarão gerando uma tendência de
achatamento da curva; durante o processo de refinamento do produto ou mudanças aumenta-se a
probabilidade de inserção de novos erros, gerando picos na curva de falhas; as sucessivas alterações do
software tendem a introduzir mais erros antes da estabilização dos erros de alterações anteriores,
ocasionando a tendência crescente do índice de falhas.

101
Capítulo 2

1) Processos de software podem ser construídos de modelos pré-existentes objetivando se adequar às

necessidades de um determinado projeto
a) Verdadeiro

2) A essência da prática da engenharia de software pode ser resumida em compreender o problema,

planejar a solução, executar o plano e examinar o resultado.
a) Verdadeiro

3) Qual dos itens listados abaixo não se constitui numa das camadas da engenharia de software?
b) Manufatura

4) Cite que tipos de manutenção um software pode sofrer.

Manutenção Corretiva: modifica o software para corrigir defeitos
Manutenção Adaptativa: modifica o software para acomodar mudanças no seu ambiente
externo (processador, sistema operacional, etc)
Manutenção de Aperfeiçoamento: aprimora o software além dos requisitos funcionais originais
(cliente/usuário reconhece e solicita funcionalidades adicionais que trarão benefícios, à medida que
o software é usado).
Manutenção Preventiva: faz modificações nos programas de modo que eles possam ser mais
facilmente corrigidos, adaptados e melhorados.

5) As atividades “guarda-chuva” dão “cobertura” para as fases envolvidas na produção de software. Cite
algumas dessas atividades.
Controle e Rastreamento do Projeto
Gestão de Riscos
Revisões Técnicas Formais
Garantia de Qualidade
Gestão de Configuração de Software
Produção e Preparação de Produtos do Trabalho (documentos)
Gestão de Reusabilidade
Medição

6) Há uma ilusão por parte de alguns desenvolvedores que basta selecionar um modelo de processo e
aplicá-lo para se obter software de qualidade, dentro do prazo e custos estabelecidos. Comente sobre
esse “mito”.
A existência ou a simples escolha de um processo de software não garante que o software será entregue
no prazo, que ele atenda as necessidades do projeto e possua as características técnicas que garantirão
sua qualidade no longo prazo. Os padrões de processo precisam estar ligados de forma sólida às práticas
da Engenharia de Software. Além disso, o processo em si deve ser avaliado para garantir que ele
satisfaça a um conjunto de critérios essenciais para o desenvolvimento bem sucedido.

102
Capítulo 3

1) Em relação ao modelo Em Cascata podemos afirmar que é:

a) Uma abordagem razoável quando os requisitos estão bem estabelecidos

2) Quais são as 5 atividades gerais da Engenharia de Software, também caracterizadas no modelo Em

Cascata?
c) Especificação, planejamento, modelagem, construção, implantação (entrega)
3) Podemos dizer que o modelo incremental é:
b) Uma boa abordagem quando um produto de trabalho “núcleo” é requerido rapidamente

4) Podemos afirmar que modelos de processo evolucionários:

d) Todas as alternativas anteriores estão corretas

5) O modelo de prototipagem é:
c) Uma abordagem razoável quando o cliente não consegue definir os requisitos claramente

6) O modelo espiral de desenvolvimento de software:

c) Inclui avaliação de riscos a cada iteração

7) O modelo de desenvolvimento concorrente:

e) Somente a e b são verdadeiras

8) Podemos dizer que o modelo de desenvolvimento baseado em componentes:

c) Depende da tecnologia de objetos como suporte

9) O modelo de métodos formais faz uso de métodos matemáticos para:

d) Todas as alternativas anteriores são corretas

10) Qual dos nomes abaixo não representa uma das fases do modelo de processo unificado?
b) Fase de validação

11) O que se entende por “ciclo de vida”?

Ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até a
descontinuidade de seu uso.

12) Qual a diferença entre um modelo descritivo e um modelo prescritivo de processo?

Enquanto um modelo descritivo retrata como um processo é executado, um modelo prescritivo retrata
como um processo deveria ser executado. Assim, um modelo prescritivo é uma recomendação que pode
ser adaptada ou melhorada pela empresa/equipe de software que for adotá-la.

13) O que caracteriza os modelos evolucionários de processo?

São modelos que consideram a natureza evolutiva do software. Os modelos evolucionários são
iterativos. São implementados de forma a permitir o desenvolvimento de versões cada vez mais
completas do software. Suas características incluem:
103
 São usados quando o deadline (limite de tempo) não é adequado para o desenvolvimento do
software, ou seja, a data de término não é realística (por exemplo, prazos reduzidos de mercado
face à competitividade).
Uma versão limitada pode ser introduzida para atender a essa competitividade e às pressões do
negócio.
São liberados produtos “core” (“núcleo dos produtos”) ao longo do desenvolvimento.
Os detalhes e extensões do projeto são definidos ao longo do desenvolvimento.

14) Em que situações os modelos incrementais são mais indicados?

Em situações em que os requisitos iniciais do software estão razoavelmente bem definidos, mas o
escopo global do processo de desenvolvimento claramente elimina uma abordagem puramente linear
ou sequencial. Adicionalmente pode haver a necessidade de se fornecer rapidamente um conjunto
limitado de funcionalidades do software aos usuários e depois refinar, melhorar e expandir aquela
funcionalidade em versões mais avançadas do software. Nestes casos, os modelos de processo que
produzem software em incrementos são os mais indicados.

15) Cite uma das principais diferenças entre o Modelo Incremental e o Modelo de Prototipagem.
O modelo de processo incremental é interativo como a prototipagem, mas diferentemente da
prototipagem, o incremental tem como objetivo apresentar um produto operacional a cada incremento
realizado.

16) Cite quais são as duas dimensões do Processo Unificado.

- Estrutura dinâmica - representa a dimensão do tempo no processo.
- Estrutura estática - descreve como elementos do processo são agrupados em disciplinas.

17) Quais são as fases e as disciplinas do Processo Unificado?

Fases : Concepção ou Iniciação, Elaboração, Construção, Transição
Disciplinas: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste, Implantação,
Gerenciamento de Configuração e Mudança, Gerenciamento de Projeto, Ambiente

18) Quais são as principais características do Processo Unificado?

é um framework genérico de um processo de desenvolvimento;
é baseado em componentes;
utiliza toda a definição da UML;
é dirigido pelos use cases, centrado na arquitetura, iterativo e incremental (conceitos-chave).

19) Quais são os princípios das metodologias ágeis?

Valorizar indivíduos (e a interação entre eles) mais que processos e ferramentas;
Valorizar o software em funcionamento mais do que documentação abrangente;
Valorizar a colaboração com o cliente mais do que negociação de contratos;
Valorizar responder a mudanças mais que seguir um plano.

20) Nos modelos de processos ágeis o único produto de trabalho gerado é o programa de trabalho.
b) Falso

104
Capítulo 4 – parte 1

a) Aponte as ambiguidades e omissões.

O texto está mal formulado.
É dito duas vezes que o usuário deve apresentar um cartão de crédito e um número de
identificação.
Também é dito primeiro que "o cartão deve ser apresentado" e posteriormente que "o
usuário insira um cartão de crédito". "Apresentar", "inserir", o que se quer dizer com isso?
Mesma coisa para o número de identificação, sendo que não fica claro o que quer se dizer
com as palavras "apresentar" e "fornecer".
Inicialmente é dito que o usuário escolhe seu destino, mas não diz como isso é feito.
Posteriormente, é dito que o usuário pressiona o botão iniciar e uma tela de menu
apresentada com possíveis destinos.
Um usuário pode comprar várias passagens para o mesmo destino ao mesmo tempo ou
deve comprar uma de cada vez?
Um usuário pode cancelar uma compra?
O sistema acusará caso um cartão inválido seja inserido?

b) Descreva os requisitos funcionais.

O sistema emitirá passagens de ônibus
O usuário poderá escolher seu destino através de um menu
O sistema incluirá o preço da passagem no cartão de crédito do usuário

c) Descreva os requisitos não-funcionais (e de interface).

Deverá haver um botão para iniciar
Uma mensagem deve ser apresentada solicitando que o usuário selecione o destino
Uma mensagem será apresentada solicitando que o usuário insira o cartáo de crédito

d) Identifique os stakeholders.
Usuários
Desenvolvedores
?outros stakeholders podem ser supostos, mas não estão identificados no texto

Capítulo 4 – parte 2

1) Stakeholder é qualquer pessoa que vá comprar o software em desenvolvimento.

a) Falso

2) É relativamente comum para diferentes usuários propor requisitos conflitantes, cada qual
argumentando que sua versão é a mais adequada ou melhor.
a) Verdadeiro

3) Na validação de requisitos, o modelo de requisitos é revisto para assegurar sua viabilidade técnica.
b) Falso
4) Faça a associação e assinale a resposta correta sobre a técnica PIECES:
a) i-C ii-E iii-A iv-B v-F vi-D

5) Qual é o principal objetivo da Engenharia de Requisitos?

O principal objetivo da ER é a obtenção de uma especificação correta e completa dos requisitos de um
sistema de software.
105
6) Qual a definição de requisitos segundo o IEEE?
Uma condição ou capacidade que um usuário necessita para resolver um problema ou alcançar um
objetivo. Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um
contrato ou um padrão.

7) Defina Requisitos Funcionais e Requisitos Não-Funcionais.

Requisitos Funcionais: São requisitos que descrevem a funcionalidade (funções que o sistema deve
realizar) ou os serviços que se espera que o sistema faça. Exemplos de requisitos funcionais: cadastro de
cliente; emissão de nota fiscal; consulta ao estoque; geração de pedido.
Requisitos Não-Funcionais: São requisitos que não dizem respeito diretamente à funcionalidade do
sistema, mas expressam propriedades do sistema e/ou restrições sobre os serviços ou funções por ele
providas.

8) O que se entende por stakeholder?

São as partes interessadas no projeto, ou seja, são pessoas e organizações envolvidas no projeto ou que
possuem interesses que podem ser afetados pelo projeto, podendo exercer influência sobre os
resultados do projeto.

9) Quais os benefícios que se espera de um documento de especificação de requisitos?

Que estabeleça a base de acordo entre os clientes e a empresa fornecedora sobre o que o
software irá fazer;
Que reduza o esforço de desenvolvimento;
Que forneça uma base para estimativas de custo e prazos;
Que forneça uma base para validação e verificação do produto;
Que facilite a manutenção do produto de software final.

10) Um dos principais pontos a se considerar em qualquer projeto é o chamado estudo de viabilidade.
Para projetos de software não é diferente. Relacione as principais questões que se deve considerar no
estudo de viabilidade de um projeto de software.
O estudo de viabilidade é um estudo breve, direcionado, que se destina a responder a algumas
perguntas:
O sistema contribui para os objetivos gerais da empresa?
O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de
custo e prazo?
O sistema pode ser integrado com outros sistemas já em operação?
Após responder essas questões é necessário questionar as fontes de informação (stakeholders). Para
isso, são recomendadas algumas perguntas, como:
Como a empresa se comportaria, se esse sistema não fosse implementado?
Quais são os problemas com os processos atuais e como um novo sistema ajudaria a diminuir
esses problemas?
Que contribuição direta o sistema trará para os objetivos da empresa?
As informações podem ser transferidas para outros sistemas e também podem ser recebidas a
partir deles?
O sistema requer tecnologia que não tenha sido utilizada anteriormente na empresa?
O que precisa e o que não precisa ser compatível com a empresa?
Quem vai usar o sistema?

11) Cite algumas técnicas de levantamento de requisitos estudadas na disciplina.

Entrevistas, Prototipação, JAD, Brainstorming, PIECES.

106
 Glossário de Siglas
ASD- Adaptive Software Development (Desenvolvimento de Software Adaptativo)
BPM – Business Process Modeling (Modelagem de Processos de Negócio)
CASE - Computer-Aided Software Engineering (Engenharia de Software Auxiliada por
Computador)
CBD - Component-based Development (Desenvolvimento Baseado em Componentes)
CBSE - Component-based Software Engineering (Engenharia de Software Baseada em
Componentes)
COTS– commercial-off-the-shelf (software comercial de prateleira)
CRUISE - Component Reuse in Software Engineering (Reuso de Componentes em
Engenharia de Software)
DERS - Documento de Especificação de Requisitos de Software
DSDM - Dynamic Systems Development Method (Método de Desenvolvimento de
Sistemas Dinâmico)
FDD- Feature Driven Development (Desenvolvimento Dirigido por Característica)
IDEF0 - Integration Definition for Function Modeling (Definição Integrada para Modelagem
de Função)
IEEE - Institute of Electrical and Electronics Engineers (Instituto de Engenheiros Eletricistas
e Eletrônicos)
JAD - Joint Application Development (ou Design)(Desenvolvimento de Aplicações em
Equipe)
PMI - Project Management Institute (Instituto de Gerenciamento de Projetos)
PMBoK – Project Management Body of Knowledge. (Conjunto de Melhores Práticas em
Gerenciamento de Projetos)
UML – Unified Modeling Language (Linguagem de Modelagem Unificada)
RAD – Rapid Application Development (Desenvolvimento Rápido de Aplicação).
RiSE - Reuse in Software Engineering (Reuso em Engenharia de Software)
ROM – Read Only Memory (Memória Somente de Leitura)
RTF- Revisão Técnica Formal
XP – eXtreme Programming (Programação Extrema)

107
 Bibliografia
ANDRADE, Adriana; ROSSETTI, José P. Governança Corporativa. São Paulo: Atlas,
2007.
BLAHA, Michael. Modelagem e projetos baseados em objetos com UML. Rio de
Janeiro: Elsevier, 2006.
BOEHM, Barry W. A Spiral Model of Software Development and Enhancement.
Computer, vol. 21, no. 5. May, 1988. p. 61-72.
BOOCH, G., RUMBAUGH, J., JACOBSON, I. UML – guia do usuário. Rio de Janeiro:
Editora Campus, 2006.
BLOOGS, Wendy. Mastering UML com Rational Rose 2002: A Bíblia. Rio de Janeiro:
Alta Books, 2002.
CRUZ, Márcia; GONSALES, Samuel. 2010. Disponível em
http://blogbohm.com/2010/10/18/analise-de-requisitos-como-ferramenta-de-
planejamento/. Acesso em 03 dez. 2011.
FONSECA, Ijar M. Princípios Fundamentais da Análise de Requisitos. Disponível
em: http://www2.dem.inpe.br/ijar/AnalEstr.html. Acesso em 01 dez. 2011.
GASTALDO, Denise L.; MIDORIKAWA, Edson T. Processo de Engenharia de
Requisitos Aplicado a Requisitos Não-Funcionais de Desempenho – Um
Estudo de Caso. 2002. Disponível em: http://wer.inf.puc-
rio.br/wer03/artigos/denise_gastaldo.pdf. Acesso em 30 nov. 2011.
HERITAGE. Dicionário web. Disponível em:
http://www.thefreedictionary.com/information+technology. Acesso em: 13 nov.
2011.
LEITE, Jair C. Ciclo de vida de Software. 2007. Disponível em:
http://engenhariadesoftware.blogspot.com/2007/02/ciclo-de-vida-do-software-
parte-1.html. Acesso em: 11 nov. 2011.
PAULA FILHO, Wilson P. Engenharia de software: fundamentos, métodos e
padrões. 3.ed. Rio de Janeiro: LTC, 2009.
PETERS, J. F.; PEDRYC, W. Engenharia de software: teoria e prática. Rio de
Janeiro: Campus, 2001.

108
PMI - Project Management Institute. Um guia do Conjunto de Melhores Práticas em
gerenciamento de Projetos (Guia PMBOK) – Quarta Edição. Atlanta: PMI Book
Service Center, 2008.

PMI- Project Management Institute. PMBOK – Guia do Conjunto de Conhecimentos.

2010.

PRESSMAN, R. S. Engenharia de Software. 7.ed. São Paulo: McGraw-Hill, 2010.

PRESSMAN, R. S. Engenharia de Software. 6.ed. São Paulo: McGraw-Hill, 2006.
RUMBAUGH, James; et al. Modelagem e Projeto baseados em objetos. Rio de
Janeiro: Campus, 2006.
SCHACH, Stephen. Engenharia de Software: os paradigmas clássico e orientado a
objetos. São Paulo: McGrawHill, 2008.
SHORE, James; WARDEN, Shane. A Arte do Desenvolvimento Ágil. Porto Alegre:
Alta Books, 2008.
SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Addison-Wesley, 2007.
THE STANDISH GROUP. The Standish Group Report – Chaos. 1995. Disponível em:
http://www.projectsmart.co.uk/docs/chaos-report.pdf. Acesso em 02 nov. 2011.

109