Engenharia Software

Engenharia de Softwares e Engenharia de Requisitos
Engenharia de
Software e Engenharia
de Requisitos
Prof Elisamara de Oliveira
Prof Marcelo de Freitas Pintaud
1
Apresentao 3
Sumrio
Software e Engenharia de Software
Antecedentes Histricos da Engenharia de Software
Definies e Conceitos de Software e Engenharia de Software
O Produto Software
Aplicaes do Software
10
Mitos do Software
12
Exerccios do Captulo 1
15
Processo de Software
16
Conceitos Bsicos de Processo de Software
16
Padres, Avaliao e Tecnologias de Processo
18
20
Modelos de Processo
21
Ciclo de Vida e Modelos de Processo
21
Modelos Prescritivos de Processo
24
Modelo em Cascata
24
Modelos Evolucionrios de Processo
25
Prototipao
25
Modelo Espiral
26
Modelo de Desenvolvimento Concorrente
28
Modelos Incrementais de Processo
29
Modelo Incremental
29
Desenvolvimento Baseado em Componentes
32
Modelo de Mtodos Formais
33
Processo Unificado
34
Desenvolvimento gil
37
41
Engenharia de Requisitos
44
Requisitos e Engenharia de Requisitos
44
Objetivos e Classificao dos Requisitos
45
Requisitos de Produto
45
Requisitos Organizacionais
45
Requisitos Externos
46
Tarefas da Engenharia de Requisitos
49
Exerccios do Captulo 4 - Parte 1
49
Elicitao de Requisitos
53
Tcnicas de Coleta de Requisitos
55
Consideraes sobre as Tcnicas de Coleta de Requisitos
59
60
Consideraes Finais
62
Respostas Comentadas dos Exerccios
63
Captulo 1
63
Captulo 2
65
Captulo 3
66
Captulo 4 Parte 1
68
Captulo 4 Parte 2
68
Glossrio de Siglas
71
Referncias Bibliogrficas
72
Apresentao
Atualmente o software est presente, explicitamente ou mesmo sem se fazer notar, em diversos aspectos
da vida, inclusive nos sistemas crticos que afetam nossa sade e nosso bem estar. Diferentemente de outras
reas da Engenharia, novas aplicaes 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
evoluo para desempenhar adequadamente as funes necessrias para a produo de software de qualidade.
As dificuldades em se obter software de qualidade, obedecendo a prazos, custos e escopo estabelecidos,
se mostram presentes desde os primrdios da rea de computao. Devido a isso, uma base slida sobre
a teoria e a prtica 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 negcios.
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 questes:
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 domnios de aplicao 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 to complicado estabelecer os requisitos de um sistema?
Quais tcnicas podem nos auxiliar no estabelecimento dos requisitos?
Quando essas questes forem respondidas, voc, caro aluno, estar melhor preparado para entender os
conceitos de gesto e os aspectos tcnicos da atividade de Engenharia de Software que sero abordados nas
disciplinas subsequentes do nosso curso.
Marcelo Pintaud
Elisamara de Oliveira

Caro aluno, neste captulo abordaremos os antecedentes histricos da engenharia de software,
falaremos sobre os principais conceitos de software e da engenharia de software, sobre a crise
do software, mostraremos as diferenas entre os produtos software x hardware, exemplificaremos algumas das principais aplicaes do software e o alertaremos sobre o que mito e
realidade na rea de desenvolvimento.
Antecedentes Histricos da
Engenharia de Software
software e buscar maneiras de dar um tratamento de

engenharia, ou seja, mais sistemtico e controlado,
ao desenvolvimento de sistemas de software complexos.
Caros alunos, para entendermos melhor os conceitos fundamentais que envolvem a rea de Engenharia de Software, vamos fazer um breve histrico dos
principais fatos que ocorreram no mundo da tecnologia que justificaram a criao deste ramo da computao. interessante vocs notarem que h algumas
dcadas atrs, no se tinha ideia da importncia que
os computadores e, em especial, o software (programas de computadores), iriam ter e como iriam afetar
profundamente a vida de todos ns.
Um sistema de software complexo caracterizado

por um conjunto de componentes de software (estruturas de dados, mtodos, tcnicas) encapsulados
na forma de procedimentos, funes, mdulos, objetos ou agentes, interconectados entre si, compondo
a arquitetura do software, que devero ser executados em sistemas computacionais.
A denominao da Engenharia de Software surgiu em 1968, em uma conferncia organizada para

discutir a chamada crise do software. Mas, para
sermos mais precisos, o termo foi criado no incio da
dcada de 1960, tendo sido utilizado oficialmente em
1968 nesta conferncia, a NATO Conference on Software Engineering (Conferncia da OTAN sobre Engenharia de Software), que aconteceu na cidade de
Garmisch, Alemanha. Nesta ocasio, todos estavam
preocupados em contornar os efeitos da crise do
Fonte: http://profcarolinadgs.webnode.com.br/unip/engenhariade-software/
A Crise do Software
A crise do software foi um termo criado para descrever as dificuldades enfrentadas no desenvolvimento de
software no final da dcada de 1960. A complexidade dos problemas, a ausncia de tcnicas bem estabelecidas
e a crescente demanda por novas aplicaes comeavam a se tornar um problema srio. Essa crise teve como
origem a introduo de computadores mais poderosos. O advento deste hardware com mais recursos tornava
viveis softwares bem maiores e mais complexos que os sistemas existentes. A experincia inicial de construo
desses sistemas mostrou que uma abordagem informal de desenvolvimento de software no era suficiente.
Projetos importantes sofriam atrasos (s vezes, de alguns anos). Os custos eram muito maiores do que os inicialmente projetados. As solues de software no eram confiveis. Os programas eram de difcil manuteno.
Novas tcnicas e novos mtodos eram necessrios para controlar a complexidade inerente aos grandes sistemas
de software.
Desta forma, como o principal objetivo dessa conferncia foi estabelecer prticas mais maduras para o
processo de desenvolvimento de software, considerado como o evento que deu origem disciplina de Engenharia de Software.
Duas dcadas depois, em 1986, Alfred Spector, presidente da Transarc Corporation, foi co-autor de um
artigo comparando a construo de pontes ao desenvolvimento de software. Sua premissa era de que As
pontes normalmente eram construdas no tempo planejado, no oramento e nunca caam. Por outro lado, os
softwares nunca ficavam prontos dentro do prazo e do oramento, e, alm disso, quase sempre apresentavam problemas.
Uma dcada mais tarde, em 1995, a organizao The Standish Group (1995) publicou um estudo analisando as estatsticas 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 crticas (dentre elas concluso fora do tempo previsto, fora do oramento previsto ou com
menos funcionalidades do que o planejado)
31.1% dos projetos eram cancelados antes de serem concludos
52.7% dos projetos apresentavam custo real 189% maior que o estimado e o tempo de concluso
222% maior que o previsto
16.2% dos projetos eram concludos dentro de prazo, custo e escopo estimados
estimou-se que, naquele ano, as agncias governamentais e companhias privadas americanas teriam
gasto US$ 81 bilhes apenas em projetos cancelados, e mais US$ 59 bilhes em projetos concludos
fora do tempo previsto.
O Standish Group continuou publicando regularmente seu relatrio nos anos seguintes e, apesar de 35%
dos projetos de software iniciados em 2006 terem obtido sucesso, ainda assustador saber que dois teros
de todos eles fracassam. Vejam as estatsticas de 2004:
Observando estes nmeros, fica claro que de 1960

at hoje, mais de 50 anos de experincia no desenvolvimento de software no bastaram para melhorar
efetivamente a qualidade do software, a despeito da
evoluo ocorrida na rea de Engenharia de Software
e do ferramental disponvel.
ficao do sistema at a manuteno desse sistema,

depois que ele entrou em operao. Seu principal objetivo fornecer uma estrutura metodolgica para a
construo de software com alta qualidade. Para que
isso seja conseguido necessrio:
aplicar teorias, mtodos e ferramentas nas situaes apropriadas nas diversas etapas do desenvolvimento
trabalhar de acordo com as restries organizacionais e financeiras procurando solues que
estejam dentro dessas restries
gerenciar os projetos de software para que o
resultado final esteja dentro do escopo, custo e
prazos planejados
adotar uma abordagem sistemtica e organizada (maneira mais eficaz de produzir software
de alta qualidade)
Grady Booch, um dos criadores da UML Unified

Modeling Language, resumiu assim a histria: uma
doena que dure tanto tempo quanto esta, francamente, deveria ser chamada de normalidade. [BOOCH et al, 2006].
Definies e Conceitos de
Apesar da sua indiscutvel importncia, caro, aluno, as tcnicas e mtodos da Engenharia de Software so, atualmente, amplamente, mas no universalmente, utilizadas.
Engenharia de Software uma disciplina da engenharia que se ocupa de todos os aspectos da produo de software, desde os estgios iniciais de especi-
Mas no podemos falar da Engenharia de Software, sem antes, entendermos o software e seus
fundamentos. Assim, os conceitos de software so
apresentados aqui como uma referncia inicial para
o estudo do software, propriamente dito, e de seus
processos de desenvolvimento.
As normas de gesto de qualidade e garantia da

qualidade apresentam definies de software e seus
componentes e processos. De acordo com a norma
NBR ISO 9000-3, que uma interpretao da norma
de garantia de qualidade ISO 9001 para aplicao aos
produtos de software, temos as seguintes definies:
Comecemos pelo significado lxico da palavra software e seu significado nos dicionrios:
Software: Criao intelectual compreendendo

os programas, procedimentos, regras e qualquer documentao correlata operao de
um sistema de processamento de dados.
Produto de software: Conjunto completo
de programas de computador, procedimentos
e documentao correlata, assim como dados
designados para entrega a um usurio.
Item de software: Qualquer parte identificvel de um produto de software em etapa intermediria ou na etapa final de desenvolvimento.
Desenvolvimento: Todas as atividades a serem realizadas para a criao de um produto
de software.
Fase: Segmento definido do trabalho.
Software (palavra inglesa, de soft, mole + ware,

mercadoria); [Informtica]. Conjunto de programas,
processos e regras, e, eventualmente, de documentao, relativos ao funcionamento de um conjunto de
tratamento da informao (por oposio a hardware).
(Dicionrio Priberam da Lngua Portuguesa, http://
www.priberam.pt/dlpo/dlpo.aspx?pal=software, 2011)
Software uma sequncia de instrues a serem

seguidas e/ou executadas, na manipulao, redirecio-
Como podemos observar, o conjunto de conceitos

apresentados deixa claro que o software um produto que exige uma viso ampla, contemplando toda
sua complexidade, no podendo o controle da qualidade ser uma atividade secundria, devendo estar
presente desde o incio de seu desenvolvimento at a
anlise final de entrega.
namento ou modificao de um dado/informao ou

acontecimento. Software tambm o nome dado ao
comportamento exibido por essa seqncia de instrues quando executada em um computador ou mquina semelhante alm de um produto desenvolvido pela
Engenharia de software, e inclui no s o programa de
computador propriamente dito, mas tambm manuais
e especificaes. Para fins contbeis e financeiros, o
Software considerado um bem de capital. (Wikipedia, http://pt.wikipedia.org/wiki/Software, 2011)
Pressman (2010) conceitua o software como:

(1) Instrues (programas de computador)
que, quando executadas, produzem a funo e o
desempenho desejados; (2) Estruturas de dados
que possibilitam que os programas manipulem
adequadamente a informao; (3) Documentos
que descrevem a operao e o uso dos programas.
Comparar o software com produtos de hardware

auxilia na compreenso das diferenas existentes entre eles e enfatiza as caractersticas inerentes a um
software. O processo de desenvolvimento do software apresenta diferenas fundamentais em relao ao
hardware [PRESSMAN, 2010]:
O processo criativo do hardware gera algo fsico (por exemplo, placas de circuitos). O desenvolvimento de software resulta em um elemento pertencente a um sistema lgico, intangvel;
O software geralmente desenvolvido sob medida, ao contrrio do hardware, no qual o projetista tem acesso a componentes existentes
que executam tarefas definidas. O projetista do
software nem sempre ter acesso a mdulos
prontos para utilizao e quando o faz, pode
elevar o risco do produto devido a questes de
segurana;
Os custos do software esto concentrados no
desenvolvimento e no no processo de manufatura. Isto significa que no pode ser gerido
como projeto de manufatura;
Ao longo do tempo, o produto de software no
se desgasta, mas se deteriora em funo da
introduo de erros oriundos de atividades de
manuteno ou evolues implcitas no processo que devem ser reconsideradas no modelo
original.
Figura 1 - Curva de falhas do hardware

Fonte: [PRESSMAN, 2010]
Diferentemente da curva terica de falhas do hardware, a de software leva em conta que o software
no sofre processos de envelhecimento como o hardware, pois o software no algo fsico.No incio do
ciclo de vida do software, teremos problemas (bugs)
que sero ajustados no decorrer do desenvolvimento
e se estabilizaro gerando uma tendncia 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 manuteno e mudanas. Durante o processo de refinamento do produto ou mudanas aumenta-se, consideravelmente,
a probabilidade de insero de novos erros, gerando
picos na curva de falhas. As sucessivas alteraes do
software tendem a introduzir mais erros antes da estabilizao dos erros de alteraes anteriores, ocasionando a tendncia crescente do ndice de falhas,
conforme pode ser visto na figura 2.
Desta forma, o software sofre deteriorao ocasionada por diversos fatores sendo uma caracterstica peculiar do produto. Segundo Pressman (2010),
no caso do hardware, temos um alto ndice de falhas no incio do seu ciclo de vida ocasionadas por
defeitos de fabricao e projeto. Posteriormente os
defeitos so corrigidos dando estabilidade nas falhas
ou mantendo-a em um nvel muito baixo e suportvel para a estrutura. J no final do ciclo de vida
do produto podem surgir problemas relacionados ao
envelhecimento, acmulo de poeira, vibrao, abuso,
temperaturas extremas, entre outros. Este processo
pode ser visto no grfico apresentado na figura 1.
Figura 2 - Curva de falhas do software

Fonte: [PRESSMAN, 2010]
Como veculo 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 comunicao e transmisso da
informao (redes) e para a criao e controle de
outros programas (ferramentas e ambientes de desenvolvimento).
Isso nos remete a uma realidade bastante complicada

em relao ao software: ele um produto que quanto
mais se conserta, pior fica. Um software em constante
manuteno pode ser tornar uma espcie de colcha
de retalhos, gerando pontos de falhas diversos, difceis
de se identificar e de se ajustar. O melhor modelo o
desenvolvimento de um novo produto aps o tempo
de vida til do mesmo, considerando-se as novas
necessidades e tecnologias disponveis.
Quando o hardware projetado e construdo, faz-se uso de catlogos de componentes digitais. Cada
circuito integrado tem um cdigo de componente,
uma funo definida e validada, uma interface bem
delineada e um conjunto padro de integrao. Depois que cada componente selecionado, ele pode
ser requisitado do estoque e utilizado em diferentes
projetos de hardware com alta confiabilidade.
A importncia do software na nossa sociedade

continua a crescer. Ele entrega o produto mais
importante da nossa poca: a informao.
No mundo do software, isso algo que est apenas comeando a ser utilizado numa escala mais
ampla, apesar de existirem alguns casos antigos de
reuso, como as bibliotecas de subrotinas cientficas. Atualmente, a viso de reuso foi ampliada para
abranger no apenas algoritmos consagrados, mas
tambm estruturas de dados, interfaces grficas e
diferentes classes e componentes orientados a objetos.
O programador solitrio de antigamente foi substitudo por uma equipe de especialistas de software,
com cada um se concentrando numa parte da tecnologia necessria para produzir uma aplicao complexa. Mas, os mesmos questionamentos feitos ao programador solitrio continuam sendo feitos quando
modernos sistemas baseados em computador esto
sendo construdos:
Por que se leva tanto tempo para concluir um
software?
Por que os custos de desenvolvimento so to
altos?
Por que no 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?
O Produto Software
Na realidade atual, o software assume um duplo
papel: ele o produto e, ao mesmo tempo, o veculo
para entrega do produto. Esta afirmao 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 informaes em um amplo espectro
de aplicaes, das mais simples s mais complexas.
Essas perguntas so manifestaes da preocupao sobre o software e a maneira pela qual ele
10
Aplicaes do Software
desenvolvido. E, como vimos, questes como estas

levaram criao e adoo da Engenharia de Software.
O software pode ser aplicado em qualquer situao para a qual um conjunto previamente especializado de procedimentos (um algoritmo) tenha sido
definido.
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 diferenas entre os projetos
de software, assim os modelos definidos no
so aplicveis a todos os projetos;
Existe uma estreita relao entre o processo
de desenvolvimento e manuteno, e o produto de software, sendo a escolha do processo
fundamental para o alcance das caractersticas
desejadas do produto;
Para uma boa visibilidade do processo essencial o estabelecimento de critrios de medio
apoiados em objetivos e modelos apropriados;
O software um processo experimental, no
qual o aprendizado com realimentao para o
processo de desenvolvimento e manuteno
dos produtos atividade natural;
Avaliao e realimentao repetitiva so necessrias para o aprendizado e incluso de melhorias, alm do controle individual de projetos;
Gerir, registrar e distribuir corretamente as experincias (ou cases) permitir a construo de
uma competncia de software na organizao;
Uma variedade de experincias em relao ao
processo, produto, recursos, defeitos e modelos de qualidade podem formar uma base de
experincias atualizvel;
O processo de desenvolvimento e manuteno
de software deve considerar a reutilizao de
experincias com definies de quando, como
e onde reutilizar;
As experincias podem ser armazenadas e disponibilizadas de formas variadas e integradas
em repositrios de informaes relacionando a
similaridade de projetos, produtos, caractersticas, fenmenos e outros.
Exemplos de reas de aplicaes de software so:

Software de sistema: coleo de programas
para servir outros programas (compiladores,
editores, utilitrios para gesto de arquivos,
componentes de sistemas operacionais, etc).
Estes tipos de programas se caracterizam por
manterem uma interao 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 restries
de tempo e sejam gerenciados da forma mais
eficiente possvel. 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 aplicao
de software. Esto na categoria de software de
aplicao que resolvem necessidades especficas do negcio, como controle de reservas de
11
voos, sistemas de pagamento, de controle de

estoque, etc.
Software cientfico e de engenharia: caracterizado por algoritmos que processam nmeros e realizam operaes matemticas e
clculos mais complexos (astronomia, anlise
automotiva de tenses, manufatura automatizada, previso de tempo, simuladores, etc).
dados e diversas caractersticas que fazem as

pginas HTML estticas 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, aplicaes grficas, aplicaes multimdia, etc.
Software para inteligncia artificial: faz
uso de algoritmos no numricos para resolver
problemas complexos, como sistemas de reconhecimento de padres (de imagem e de voz),
redes neurais artificiais, sistemas de controle
de robs, etc.
Software embutido: produtos inteligentes.

So programas armazenados em ROMs Read
Only Memories, como controle de teclado para
um forno de microondas, funes digitais em
um automvel controle de combustvel, mostradores do painel, sistemas de frenagem, etc.
Estes programas so chamados de firmware,
que so programas gravados no hardware que
controlam as funes dos dispositivos eletrnicos.
Software para web: as pginas da web recuperadas por um browser constituem software
que incorpora instrues executveis na forma
de scripts, permitindo a incluso de elementos dinmicos, animaes, acesso a banco de
12
Mitos do Software
- O manual existe. Mas usado?

- Os profissionais sabem da sua existncia?
- Ele reflete as prticas mais modernas de engenharia de software?
- completo?
- Est voltado p/ melhorar o prazo de entrega focado na qualidade?
Na maioria dos casos a resposta no.
Mito:
Meu pessoal tem ferramentas de software de
ltima gerao; afinal de contas lhes compramos os mais novos computadores.
Realidade:
necessrio mais do que computadores de
ltima gerao para fazer um desenvolvimento de software de alta qualidade. Ferramentas
Case so mais importantes. Contudo, a maioria
dos desenvolvedores no as usam ainda, ou
subutilizam-nas.
Muitas crenas ou mitos foram criados acerca de

acontecimentos ligados ao processo de desenvolvimento de software, desde os primeiros programas.
Mas so informaes, muitas vezes, traioeiras. Os
mitos podem parecer verdadeiros, trazer informaes sobre fatos razoveis e muitas vezes serem divulgados por pessoas que entendem do assunto.
Hoje os profissionais que conhecem a Engenharia de
Software reconhecem os mitos pelo o que eles so
na realidade: afirmaes enganosas que j causaram
prejuzo a diversos profissionais.
Mito:
Se ns estamos atrasados nos prazos, podemos
adicionar mais programadores e tirar o atraso.
Realidade:
Desenvolvimento de software no um processo mecnico. Quando novas pessoas so
adicionadas, pessoas que estavam trabalhando devem gastar tempo educando os novatos.
Pessoas podem ser adicionadas, mas de um
modo planejado e bem coordenado.
Para que voc, caro aluno, no seja enganado pelos mitos, pois eles ainda esto presentes em nosso
meio, vamos apresent-los a voc nesta seo, com
base na abordagem de Pressman (2010).
Mitos Administrativos ou Gerenciais
Mito:
Se decidirmos terceirizar um projeto vamos poder relaxar e deixar que a empresa o elabore.
Realidade:
Se uma organizao no sabe como gerir e
controlar seus projetos de software, terceiriz-los certamente trar outros problemas, talvez
maiores.
Gerentes esto frequentemente sob presso para

manter o oramento, cumprir prazos e aumentar a
qualidade. Devido a isso, comum agarrarem-se a
mitos que diminuem (temporariamente) essa presso.
Mito:
J temos o manual repleto de padres e procedimentos para a construo do software. Isso
no oferecer ao meu pessoal tudo o que eles
precisam saber?
Realidade:
13
Mitos do Cliente
Mitos do Profissional
Um cliente que encomenda um software pode ser

uma pessoa na mesa vizinha, um grupo tcnico em
outra sala, o departamento de promoo/vendas ou
uma empresa que encomendou software sob contrato.
Os mitos que ainda tm crdito entre os profissionais de software sobreviveram a mais de 50 anos de
cultura de programao. No incio a programao era
vista como uma forma de arte.
Mito:
Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho estar completo.
Realidade:
Estudos mostram que, entre 60% a 80%, de
todo o esforo gasto em um programa sero
despendidos depois dele ter sido entregue,
pela primeira vez, para o usurio.
O cliente acredita em mitos de software, geralmente porque os gerentes e profissionais de software

fazem pouco para corrigir essa desinformao. Mitos
levam a falsas expectativas (pelo cliente) e insatisfao com o desenvolvedor.
Mito:
Uma declarao geral dos objetivos suficiente
para se comear a escrever programas podemos preencher os detalhes mais tarde.
Realidade:
Uma definio inicial ruim a principal causa
de falhas nos esforos de software. essencial uma descrio formal do domnio da informao, funo, comportamento, performance,
interface, restries de projeto e critrios de
validao. Necessria intensa comunicao entre cliente e desenvolvedor.
Mito:
Enquanto no tiver o programa funcionando,
eu no 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 incio a Reviso Tcnica Formal
(um filtro de qualidade).
Mito:
Os requisitos de projeto modificam-se continuamente, mas as mudanas podem ser facilmente acomodadas, porque o software flexvel.
Realidade:
verdade que os requisitos de software mudam, mas o impacto das mudanas varia de
acordo com o momento na qual ela ocorre. Em
termos de custos, na fase de definio (x1), na
fase de desenvolvimento (1,5 a 6x) e na fase
de manuteno (60 a 100x). Deve ser dada
muita ateno s definies iniciais.
Mito:
A nica coisa a ser entregue em um projeto
bem-sucedido o programa funcionando.
Realidade:
O programa executvel uma das partes da
configurao do software. A documentao
um fator importante tambm (alicerce para o
desenvolvimento e guia para a manuteno).
Mito:
A engenharia de software vai nos fazer criar
documentao volumosa e desnecessria que
certamente nos atrasar.
Realidade:
A engenharia de software no se relaciona
criao de documentos. Refere-se criao de
qualidade. Melhor qualidade leva reduo de
14
retrabalho. E menor retrabalho resulta em tempos de entrega mais rpidos.

Concluso sobre os Mitos:
Profissionais de software devem reconhecer a falcia dos mitos. O reconhecimento das realidades do
software o primeiro passo em direo formulao
de solues prticas e eficientes para a Engenharia de
Software.
15
1) Qual das questes abaixo no mais uma das grandes preocupaes de um engenheiro
de software?
a) Por que normalmente se gasta tanto tempo para desenvolver software?
b) Por que, via de regra, software custa to caro?
c) Por que quase sempre no se consegue remover todos os erros do software antes da sua entrega?
d) Por que hardware to 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 invs de se desgastar porque:
a) Software sofre quando exposto a ambientes hostis
b) Defeitos so mais provveis de surgir quando o software usado vrias vezes
c) Mudanas frequentes aumentam a probabilidade de se introduzir erros no software
d) Componentes de reposio de sofware so difceis de se encontrar no mercado
4) Atividades guarda-chuva de engenharia de software so aplicadas somente durante
as fases iniciais do desenvolvimento de software:
a) Verdadeiro
b) Falso
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 produo de software. Seu principal objetivo fornecer uma
estrutura metodolgica para a construo de software com alta qualidade. O que necessrio para que isso acontea?
7) Normalmente, para o leigo, software se constitui no cdigo fonte + cdigo executvel. 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 diferenas fundamentais em
relao ao hardware. Cite algumas dessas diferenas.
9) Faa um esboo das curvas de taxa de falhas do hardware e do software. Explique as
diferenas entre as curvas.
16
Processo de Software
Caro aluno, neste captulo descreveremos o que um processo de software, mostraremos as
camadas em que a Engenharia de Software se divide, descreveremos os padres de processo, a
avaliao e as ferramentas que apoiam o processo.
Conceitos Bsicos de Processo de

Software
Podemos definir Engenharia de Software como

um processo que envolve a criao e a utilizao de
slidos princpios de engenharia a fim de obter software com as caractersticas:
Caro aluno, todo projeto de software inicia-se a

partir de alguma necessidade do negcio. Assim que
esta necessidade identificada, esta costuma ser expressa de forma informal, atravs de uma conversa.
Mas esta informalidade deve parar por a. At mesmo
a especificao da necessidade do cliente abrangida
pelos mtodos e tcnicas da Engenharia de Software.
E este um processo bastante complexo. Ento vamos comear a entend-lo, conhecendo exatamente
do que se trata um processo de software.
DDde alta qualidade

DDproduzido de maneira econmica
DDque seja confivel
DDque trabalhe eficientemente em mquinas reais
DDque seja entregue no prazo
DDque satisfaa o cliente
A Engenharia de Software uma tecnologia em
camadas, apoiada fundamentalmente num compromisso organizacional com a qualidade, como mostra
a figura 3. Nesta abordagem, podemos observar que
o alicerce da Engenharia de Software a camada de
processo, que funciona como um adesivo que mantm unidas as camadas ligadas tecnologia.
Para que as necessidades da empresa ou de um

cliente possa se transformar numa soluo de software, todo o dilogo e a interao entre usurios,
projetistas, ferramentas de desenvolvimento e tecnologias devem ser transformados num processo.
Assim, processo de software um arcabouo
(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 so a mesma
coisa?
A resposta sim e no. Processo de software
define a abordagem que adotada quando o software elaborado. A Engenharia de Software engloba
tambm as tecnologias que constituem um processo,
como mtodos, tcnicas e ferramentas de desenvolvimento. Assim, a Engenharia de Software engloba
os processos de software.
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 mtodos e as tcnicas so
aplicados, os produtos do trabalho so produzidos, os
marcos so estabelecidos, a qualidade assegurada e
as modificaes adequadamente geridas.
17
como os detalhes procedimentais devem ser

implementados
como as interfaces devem ser caracterizadas
como o projeto deve ser traduzido em uma linguagem de programao
como o teste vai ser realizado
Os mtodos fornecem as tcnicas de como fazer

a construo de software. Abrangem um amplo conjunto de tarefas que incluem comunicao, anlise de
requisitos, modelagem de projeto, construo de programas, testes e manuteno.
As ferramentas fornecem apoio automatizado ou
Nesta fase, 3 etapas tcnicas especficas ocorrero:

i. Projeto do Software
ii. Gerao de Cdigo
iii. Teste de Software
semi-automatizado para o processo e seus mtodos.
Para que a Engenharia de Software possa ser aplicada como uma abordagem disciplinada para o desenvolvimento, operao e manuteno de um software, um processo deve ser definido. De uma forma
geral, um processo caracterizado por fases:
3. Fase de Manuteno: esta fase tem como

alvo as modificaes e manutenes que o software
sofrer. Quatro tipos de modificaes so encontradas durante essa fase:
1. Fase de Definio
2. Fase de Desenvolvimento
3. Fase de Manuteno
Manuteno Corretiva: modifica o software

para corrigir defeitos
Manuteno Adaptativa: modifica o software
para acomodar mudanas no seu ambiente externo (processador, sistema operacional, etc)
Manuteno de Aperfeioamento: aprimora o
software alm dos requisitos funcionais originais (cliente/usurio reconhece e solicita funcionalidades adicionais que traro benefcios,
medida que o software usado).
Manuteno Preventiva: faz modificaes nos
programas de modo que eles possam ser mais
facilmente corrigidos, adaptados e melhorados.
1. Fase de Definio: esta fase se concentra

no qu o sistema de software ir realizar, isto ,
identifica:
que informao deve ser processada
que funo e desempenho so desejados
que comportamento deve ser esperado do sistema
que interfaces devem ser estabelecidas
que restries de projeto existem
que critrios de validao so necessrios
Nessa fase, os requisitos-chave do sistema e do
software so identificados. Esta fase engloba 3 importantes etapas:
Estas 3 fases so complementadas por atividades guarda-chuva:

DDControle e Rastreamento do Projeto
DDGesto de Riscos
DDRevises Tcnicas Formais
DDGarantia de Qualidade
DDGesto de Configurao de Software
DDProduo e Preparao de Produtos do Trabalho (documentos)
DDGesto de Reusabilidade
DDMedio
i. Engenharia de sistemas ou de informao

ii. Planejamento do projeto
iii. Anlise de requisitos
2. Fase de Desenvolvimento: esta fase focaliza como o desenvolvimento ser realizado, isto
, define:
como os dados devem ser estruturados
como as funes devem ser implementadas
18
Inteno do padro: descreve o que o padro faz, qual a sua inteno e qual problema o
padro se prope a resolver.
Tambm conhecido como: um outro nome
pelo qual o padro conhecido, caso exista.
Motivao: um exemplo de problema de projeto e como a utilizao do padro resolve este
problema.
Aplicabilidade: condies em que o padro
pode ser aplicado, exemplo de situao em que
o padro aplicado e como identificar essas
situaes.
Estrutura: uma representao grfica das
classes no padro utilizando uma linguagem de
modelagem, em que possam ser representados
os relacionamentos entre os objetos e sequncias de requisies.
Participantes: apresenta as classes e objetos
que fazem parte do padro e quais as suas responsabilidades.
Colaboraes: como os participantes colaboram para atender as suas responsabilidades.
Consequncias: descreve como o padro alcana seus objetivos, quais as decises e resultados de usar o padro e que aspectos da
estrutura do sistema podem ser variados independentemente.
Implementao: que detalhes de implementao devem ser observados se o padro for
implementado. Deve ser observado se existem
detalhes especficos para uma determinada linguagem.
Exemplo de cdigo: um exemplo de cdigo
que mostre como o padro deve ser implementado em alguma linguagem.
Usos conhecidos: exemplos do padro encontrados em sistemas reais.
Padres relacionados: padres que se assemelham a este padro e quais as diferenas.
Apresenta tambm outros padres que podem
ser utilizados em conjunto.
Essas atividades so aplicadas ao longo do processo de software.
Padres, Avaliao e Tecnologias

de Processo
De acordo com Pressman (2010), um processo de
software pode ser definido como uma coleo de padres que definem um conjunto de atividades, aes,
tarefas de trabalho e produtos de trabalho necessrios para o desenvolvimento de software de computador.
Em termos gerais, um padro de processo nos
fornece um gabarito que permite que sejam listadas
as caractersticas mais importantes do processo de
software. Mas interessante notar, caro aluno, que
uma equipe de desenvolvimento pode construir, pela
combinao de padres, um processo que melhor satisfaa s necessidades do projeto.
Descrever um padro de projeto uma tarefa muito importante, pois permite se identificar particularidades que facilitem a comparao entre os padres,
auxiliando na deciso de escolha por um padro especfico. Gamma et al (1994) propem um gabarito
para esta definio, dividido em sees, como apresentado a seguir:
Nome do padro e Classificao: o nome
muito importante para um padro, pois deve
indicar a essncia do padro em poucas palavras.
19
A existncia ou a simples escolha de um processo de software no garante que o software ser entregue
no prazo, que ele atenda as necessidades do projeto e possua as caractersticas tcnicas que garantiro sua
qualidade no longo prazo. Os padres de processo precisam estar ligados de forma slida s prticas da
Engenharia de Software. Alm disso, o processo em si deve ser avaliado para garantir que ele satisfaa a um
conjunto de critrios essenciais para o desenvolvimento bem sucedido. O relacionamento entre o processo
de software e os mtodos aplicados para sua avaliao e melhoria mostrado na figura 4.
Figura 4
Processo de Software, Avaliao e Melhoria de Processo
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 organizaes a analisar o processo que utiliza, organizar as tarefas de trabalho, controlar e monitorar
o progresso do desenvolvimento e ainda gerenciar
sua qualidade tcnica.
Como vimos neste captulo, a Engenharia de Software uma disciplina que integra processo, mtodos
e ferramentas para o desenvolvimento de projetos de
software. H diversos modelos de processo, mas todos
possuem algumas caractersticas em comum, definindo
um conjunto de atividades de arcabouo, uma coleo
de tarefas para que se consiga realizar as atividades,
produtos de trabalho produzidos nas tarefas e um conjunto de atividades guarda-chuva que apiam as ativi-
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 tambm 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.
dades de todo o processo.

Vimos, tambm, que padres de processo podem
ser utilizados para definir as caractersticas de um processo.
20
1) Processos de software podem ser construdos de modelos pr-existentes objetivando
se adequar s necessidades de um determinado projeto
a) Verdadeiro
b) Falso
2) A essncia da prtica da engenharia de software pode ser resumida em compreender o
problema, planejar a soluo, executar o plano e examinar o resultado.
a) Verdadeiro
b) Falso
3) Qual dos itens listados abaixo no se constitui numa das camadas da engenharia de
software?
a) Processo
b) Manufatura
c) Mtodos
d) Ferramentas
4) Cite que tipos de manuteno um software pode sofrer.
5) As atividades guarda-chuva do cobertura para as fases envolvidas na produo de
software. Cite algumas dessas atividades.
6) H uma iluso 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.
21
Modelos de Processo
Caro aluno, neste captulo definiremos o que ciclo de vida de software, quais suas principais
etapas e descreveremos os principais modelos de processo de software: Modelo em Cascata, Modelos Evolucionrios (Modelo de Prototipagem, Modelo Espiral e Modelo Concorrente), Modelos
Incrementais (Modelo RAD e Modelo Incremental), Modelo Baseado em Componentes, Modelo de
Mtodos Formais, Processo Unificado e Mtodos geis de Desenvolvimento.
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 concepo at
a descontinuidade de seu uso. O conceito de ciclo de vida de um software muitas vezes confundido com o
de modelo de processo, mas so conceitos bem diferentes, como veremos a seguir.
Existem vrias propostas e denominaes para as
fases do ciclo de vida de um software. Nesta nossa
abordagem, vamos trabalhar com 4 fases, que so
as mais tpicas em diversos ciclos de vida, de acordo
com a proposta de Leite (2007). Cada fase inclui um
conjunto de atividades ou disciplinas que devem ser
realizadas pelas pelos envolvidos no processo de desenvolvimento. Essas fases so:
1. Fase
2. Fase
3. Fase
4. Fase
de
de
de
de
Viabilidade, incluindo a Anlise de Custo-Benefcio,

para se decidir qual soluo ser a escolhida.
O resultado desta atividade deve incluir a deciso
se o sistema ser adquirido ou desenvolvido, indicando informaes sobre necessidades de hardware,
ferramentas de software, pessoal, procedimentos, informao e documentao.
Caso haja uma deciso pelo desenvolvimento do
sistema, no escopo da Engenharia de Software, torna-se essencial elaborar o documento de Proposta de
Desenvolvimento de Software, que pode ser a base
de um Contrato de Desenvolvimento.
Definio
Desenvolvimento
Operao
Retirada
Nesta fase, os profissionais devem realizar uma

tarefa de extrema importncia, que fazer o levantamento dos Requisitos de Software e Modelos de
Domnio. Os requisitos so fundamentais para que o
engenheiro de software possa elaborar um Plano de
Desenvolvimento de Software, indicando em detalhes os recursos necessrios (humanos e materiais),
bem como as estimativas de prazos e custos (cronograma e oramento).
1. Fase de Definio
A fase de definio do software ocorre em conjunto com outras atividades como a BPM Business
Process Modeling ou Modelagem de Processos de
Negcios e Anlise de Sistemas. Nestas atividades,
diversos profissionais fazem o levantamento da situao atual em busca da identificao de problemas,
para que possam elaborar propostas de soluo de
sistemas computacionais que os resolvam. Dentre as
propostas apresentadas, deve-se fazer um Estudo de
22
2. Fase de Desenvolvimento
quadas. A codificao deve refletir a estrutura e

o comportamento descrito no projeto da arquitetura do software. Os testes podem ser iniciados durante a fase de implementao. A depurao de erros ocorre durante a programao
utilizando tcnicas e ferramentas adequadas.
fundamental que se adote um controle e gerenciamento de verses para que se tenha total
controle de tudo o que est sendo codificado.
A fase de desenvolvimento ou de produo do software inclui todas as atividades que tm por objetivo
a construo do produto. Esta fase inclui as atividades de projeto, implementao, verificao e validao do software.
DDProjeto
A atividade de projeto compreende todo o esforo de concepo e modelagem que tem por
objetivo descrever como o software ser implementado. O projeto inclui:
Projeto conceitual: envolve a elaborao das
ideias e conceitos bsicos que determinam os
elementos fundamentais do software a ser desenvolvido.
Projeto da interface com o usurio: envolve
a elaborao das formas como o usurio vai
interagir para realizar suas tarefas, a escolha
dos objetos de interfaces (botes, menus, caixas de texto, etc.), o layout de janelas e telas,
dentre outros; a interface deve garantir uma
usabilidade satisfatria do software e um fator fundamental de sucesso do software.
Projeto da arquitetura do software: se refere
elaborao de uma viso macroscpica do software em relao aos componentes que interagem entre si. So exemplos de vises arquitetnicas, a viso conceitual, viso de mdulos,
viso de cdigo e viso de execuo.
Projeto dos algoritmos e estruturas de dados:
objetiva determinar, de maneira independente
da linguagem de programao a ser adotada,
as solues algortmicas e as estruturas de dados associados.
DDVerificao e Validao
So atividades que se destinam a mostrar que
o sistema est de acordo com a especificao
e que ele atende s expectativas de clientes e
usurios. A validao visa assegurar que o programa est fazendo o que foi definido na sua
especificao. A verificao visa certificar se o
programa est correto, isto , se no possui
erros de execuo e est fazendo de forma correta suas funcionalidades. Existem diferentes
formas de verificao e validao. Os testes de
correo, desempenho, confiabilidade, robustez, usabilidade, dentre outros, podem ser usados para avaliar diversos fatores de qualidade
a partir da execuo do software.
3. Fase de Operao
A fase de operao envolve diferentes tipos de atividades:

DDImplementao
A implementao envolve as atividades de codificao, compilao, integrao e testes. A
codificao visa traduzir o projeto num programa utilizando linguagens e ferramentas ade-
23
Distribuio e entrega
Instalao e configurao
Utilizao
Manuteno
A distribuio 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.
uma empresa sempre uma deciso difcil: como se

desfazer daquilo que confivel e ao qual os funcionrios esto acostumados, aps anos de treinamento
e utilizao?
O processo de instalao e configurao, normalmente, pode ser feito com a ajuda de software de
instalao disponibilizados pelos fabricantes dos ambientes operacionais.
Nestes casos, processos de reengenharia podem

ser aplicados para viabilizar a transio ou a migrao de um software legado para um novo software
de forma a proporcionar uma retirada mais suave.

A utilizao a efetiva entrada em operao
do software. A qualidade da utilizao reflete a usabilidade do software.
Para resolver problemas reais, um engenheiro de

software deve incorporar uma estratgia de desenvolvimento que abrange as camadas de processo,
mtodos e ferramentas e as fases genricas da Engenharia de Software. Essa estratgia definida
como Modelo de Processo.
A manuteno normalmente ocorre de forma corretiva, adaptativa, de aperfeioamento e evolutiva.

As manutenes podem ser relativas resoluo de
problemas referentes qualidade do software (falhas, baixo desempenho, baixa usabilidade, falta de
confiabilidade, etc.), produo de novas verses
do software de forma a atender aos novos requisitos dos clientes, ou adaptar-se s novas tecnologias
que surgem (hardware, plataformas operacionais,
novas linguagens e paradigmas, etc). Mudanas no
domnio de aplicao implicam em novos requisitos e
incorporao de novas funcionalidades. Surgimento
de novas tecnologias de software e hardware e mudanas para uma plataforma mais avanada tambm
requerem evoluo.
O modelo de processo escolhido com base:

na natureza do projeto e da aplicao a ser
desenvolvida
nos mtodos e ferramentas a serem utilizados
nos controles e produtos que precisam ser entregues
Alguns Modelos de Processo incluem:

Modelo em Cascata
Modelo de Prototipao
Modelo RAD
Modelo Incremental
Modelo Espiral
Modelo de Desenvolvimento Baseado em Componentes
Modelos de Processos geis
4. Fase de retirada
A fase de retirada ou desuso de um software um
grande desafio para os tempos atuais. H diversos
sistemas que esto em funcionamento em empresas, que possuem timos nveis de confiabilidade e
de correo. No entanto, estes sistesmas precisam
evoluir para novas plataformas operacionais ou para
permitirem a incorporao de novos requisitos e funcionalidades. A retirada desses sistemas legados em
No que se segue estes modelos sero agrupados

em categorias e detalhados, de forma que voc, caro
aluno, possa conhecer suas caractersticas, potencialidades, limitaes e aplicaes mais adequadas.
24
Modelos Prescritivos de Processo
tos explcitos de tarefas explcitas para o desenvolvimento. Cada modelo prescritivo de processo tambm
prescreve um fluxo de trabalho ou maneira como os
elementos se inter-relacionam.
Processos prescritivos so uma categoria que engloba os processos que possuem pontos observveis
que a cada passo podem ser verificados e classificados como vlidos ou sujeitos a ajustes.
H vrios modelos que so classificados nesta categoria:
Enquanto um modelo descritivo retrata como um

processo executado, um modelo prescritivo retrata
como um processo deveria ser executado. Assim, um
modelo prescritivo uma recomendao que pode
ser adaptada ou melhorada pela empresa/equipe de
software que for adot-la.
Modelo em Cascata
Modelos Evolucionrios
o Modelo de Prototipagem
o Modelo Espiral
o Modelo Concorrente
Modelos Incrementais
o Modelo RAD
o Modelo Incremental
Modelo Baseado em Componentes
Processo Unificado
Os instrumentos prescritivos do processo de planejamento estratgico explicitam o que deve ser feito pela organizao para se direcionar o esforo de
desenvolvimento de software. Um modelo prescritivo
de processo atua como complemento com conjun-
Modelo em Cascata
No modelo em cascata, tambm conhecido como ciclo de vida clssico, o processo de desenvolvimento
de software visto como uma abordagem sistemtica e sequencial que comea com a especificao dos
requisitos do cliente e progride seguindo as etapas de planejamento, modelagem, construo e implantao
do sistema, conforme ilustra a figura 5, culminando na manuteno progressiva do produto entregue.
Figura 5
Modelo em Cascata
Este modelo o paradigma mais antigo da Engenharia de Software e bastante criticado em funo
dos problemas encontrados nos projetos em que
aplicado. A realidade tem mostrado que num projeto
raramente se segue o fluxo sequencial que o modelo
prope, gerando problemas futuros que oneram os
custos e prazos. Uma das causas mais comuns deste
problema a dificuldade do cliente em declarar claramente todas as suas necessidades e expectativas,
ou seja, de definir todos os requisitos inicialmente. O

foco incorreto ou no claro pode gerar uma distoro
que reflete diretamente na percepo de qualidade
por parte do prprio cliente. Isso pode levar a entregas parciais do produto, o que exige que o cliente
tenha muita pacincia durante os aceites parciais que
so formalizados em um Documento de Encerramento do Projeto com observaes no campo Restries
Entrega Parcial de Projeto, que contm detalhes
25
quanto aceitao condicional do projeto por parte

do cliente.
de software. apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software,
mas no identificou requisitos de entrada, processamento e sada com detalhes.
Os trabalhos de desenvolvimento de software atuais seguem ritmos muito rpidos, sujeitos a diversas
modificaes, o que torna o modelo em cascata inadequado para estes tipos de projeto. Mas, cumpre
ressaltar, caro aluno, que embora o Modelo em Cascata ou Ciclo de Vida Clssico tenha fragilidades, ele
significativamente melhor do que uma abordagem
casual para o desenvolvimento de software.
Envolve o desenvolvimento de uma verso inicial

do sistema baseada no atendimento dos requisitos
ainda pouco definidos. Este processo permite a descoberta de falhas difceis de serem encontradas na
comunicao verbal, servindo de apoio fase de
levantamento de requisitos prevenindo as possveis
falhas no sistema.
Modelos Evolucionrios de
Processo
O objetivo principal de um prottipo simular a

aparncia e funcionalidade do software permitindo
que os clientes, analistas, desenvolvedores e gerentes compreendam plenamente os requisitos do sistema interagindo, avaliando, alterando e aprovando as
caractersticas mais relevantes que o produto deva
ter. A figura 6 ilustra este processo.
So modelos que consideram a natureza evolutiva

do software. Os modelos evolucionrios so iterativos. So implementados de forma a permitir o desenvolvimento de verses cada vez mais completas do
software. Suas caractersticas incluem:
So usados quando o deadline (limite de tempo) no adequado para o desenvolvimento
do software, ou seja, a data de trmino no
realstica (por exemplo, prazos reduzidos de
mercado face competitividade).
Uma verso limitada pode ser introduzida para
atender a essa competitividade e s presses
do negcio.
So liberados produtos core (ncleo dos produtos) ao longo do desenvolvimento.
Os detalhes e extenses do projeto so definidos ao longo do desenvolvimento.
Figura 6
Modelo de Prototipao
Certamente a reduo de custos no desenvolvimento um dos grandes ganhos de da prototipao,

pois envolve diretamente o usurio final permitindo
um desenvolvimento mais prximo dos desejos do
cliente priorizando a facilidade de uso. Assim, pode-se obter um nvel de satisfao maior em funo
do menor nmero de erros ou falhas de desenvolvimento comuns na passagem de informao entre o
analista (que fez o levantamento de requisitos) e o
desenvolvedor (equipe de desenvolvimento).
Os modelos que so agrupados nesta categoria

so: Prototipao, Modelo Espiral e Modelo Concorrente, que so apresentados no que se segue.
Prototipao
um modelo de processo que possibilita que o

desenvolvedor crie um modelo do software que deve
ser construdo. Idealmente, o modelo (prottipo) serve como um mecanismo para identificar os requisitos
26
Um dos riscos envolvidos neste modelo o descomprometimento com a anlise do produto, visto que os envolvidos podem se apoiar totalmente no modelo prototipado gerando uma expectativa muitas vezes irrealista de desempenho, em funo do prottipo ser muito mais enxuto do que o produto final e estar em ambiente controlado.
Alm disso, o cliente no sabe que o software que ele v no considerou, durante o desenvolvimento, a qualidade
global e a manutenibilidade a longo prazo. Ele pode, tambm, no aceitar facilmente a ideia de que a verso final
do software est sendo construda e tentar forar a utilizao do prottipo como produto final.
Outro risco deste modelo que o desenvolvedor frequentemente faz uma implementao comprometida (utilizando partes de programas existentes, geradores de relatrios, geradores de janelas) com o objetivo de produzir
rapidamente um prottipo executvel. Depois de um tempo ele se familiariza com essas escolhas, e pode se esquecer que elas no so apropriadas para o produto final.
Figura 7 Outra viso do Modelo de Prototipao
Ainda que possam ocorrer problemas, a prototipao um modelo eficiente. A chave para seu sucesso
definirem-se as regras do jogo logo no comeo. O cliente e o desenvolvedor devem ambos concordar que o
prottipo seja construdo para servir como um mecanismo a fim de se definir os requisitos do projeto. A figura
7 traz uma outra viso deste processo.
Modelo Espiral
Desenvolvido para abranger as melhores caractersticas do Modelo em Cascata e da Prototipao, acrescentando, ao mesmo tempo, um novo elemento: a anlise de riscos.
27
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 iteraes tm uma durao tpica de seis meses a dois anos. Cada fase inicia-se
com um objetivo esperado e termina como uma reviso pelo cliente do progresso (que deve ser interna) e
assim por diante. Esforos de anlise e engenharia so aplicados em cada fase do projeto, tendo sempre o
foco no objetivo do projeto. A figura 8 ilustra este processo.
As principais caractersticas deste modelo so:
Nas iteraes mais adiantadas so produzidas

verses incrementais mais completas e melhoradas.
Engloba a natureza iterativa da Prototipao

com os aspectos sistemticos e controlados do
Modelo em Cascata.
Fornece potencial para o desenvolvimento rpido de verses incrementais do software.
O processo se inicia com a equipe de desenvolvimento movendo-se em volta da espiral, no
sentido horrio, a partir do centro.
O primeiro circuito em torno da espiral pode
resultar na especificao do produto.
Nas primeiras iteraes, a verso incremental
pode ser um modelo em papel ou um prottipo.
uma abordagem realstica para o desenvolvimento de software de grande porte. Como o software evolui na medida em que o processo avana, o
cliente e o desenvolvedor entendem melhor e reagem aos riscos em cada nvel evolucionrio. Para pequenos projetos, os conceitos de desenvolvimento de
software gil tornam-se uma alternativa mais vivel.
Como vantagens deste modelo, podemos citar as
estimativas realsticas dadas identificao de pro-
28
blemas importantes logo no incio do processo, versatilidade para lidar com mudanas (quando inevitveis), desenvolvimento antecipado por parte dos
engenheiros de software que tm visibilidade das
necessidades por fases, Usa prototipagem (em qualquer estgio de evoluo do produto) como mecanismo de reduo de risco.
De acordo com Pressman (2010), o modelo de

Desenvolvimento Concorrente, tambm chamado de
Engenharia Concorrente, pode ser representado, esquematicamente, como uma srie de atividades de
arcabouo, aes e tarefas da Engenharia de Software e seus estados associados.
No entanto, o uso do modelo Espiral exige considervel experincia na determinao de riscos e

depende dessa experincia para ter sucesso. Alm
disso, pode ser difcil convencer os clientes que uma
abordagem evolutiva controlvel.
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
Transies 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 inspeo, aguardando
modificaes, etc) a qualquer tempo. O modelo define uma srie de eventos que vo disparar transies
de um estado para outro, para cada uma das atividades, aes ou tarefas da Engenharia de Software. Por
exemplo, suponha que durante os estgios da etapa
de projeto, descobre-se uma inconsistncia no modelo de anlise. Isso geraria o evento correo no
modelo de anlise, que, por sua vez, implicaria na

passagem da atividade de anlise do estado pronto
para o estado aguardando modificaes
De forma geral, as principais caractersticas deste
modelo so:
Todas as atividades ocorrem em paralelo, mas
esto em diferentes estados.
29
Modelos Incrementais de Processo
O modelo define uma srie de eventos que vo

disparar transies de estado para estado, para
cada uma das atividades.
Em vez de usar uma sequncia 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 transies entre estados de uma atividade
Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma viso exata
de como est o estado do projeto.
Em vrios projetos pode existir uma simultaneidade (concorrncia) entre as vrias atividades
de desenvolvimento e de gesto de projetos.
representado como uma srie de grandes
atividades tcnicas, tarefas e seus estados associados (fornece um panorama preciso do estado atual do projeto).
Caro aluno, h diversas situaes em que os requisitos iniciais do software esto 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 usurios e depois refinar, melhorar e expandir
aquela funcionalidade em verses mais avanadas
do software. Nestes casos, os modelos de processo
que produzem software em incrementos so os mais
indicados.
Os processos incrementais que discutiremos aqui
incluem o Modelo Incremental e o Modelo RAD Rapid Application Development (Desenvolvimento Rpido de Aplicao).
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.
O software moderno caracterizado por modificaes contnuas, prazos muito curtos e por uma necessidade premente de satisfazer o usurio ou cliente.
Os modelos evolucionrios de processo foram criados
com o objetivo de resolver estes problemas, mas tambm tm suas fragilidades. Uma delas que a prototipagem pode trazer problemas para o planejamento
Esse modelo muito til quando a empresa no

possui mo de obra disponvel, num dado perodo,
para uma implementao completa, dentro do prazo
estipulado.
do projeto em funo do nmero impreciso de ciclos

necessrios para se concluir o produto. Outra se refere
ao foco dado flexibilidade e extensibilidade ao invs
da alta qualidade. Se o foco for centrado na qualidade,
o projeto pode resultar em atraso, o que pode comprometer a competitividade do empreendimento.
30
Figura 10
Modelo de Processo Incremental
[2] Segundo Incremento: adicionaria capacidade

de edio e de produo de documentos mais
sofisticadas
[3] Terceiro Incremento: incluiria a verificao
sinttica e gramatical
[4] Quarto Incremento: adicionaria a capacidade
avanada de disposio de pgina
De uma forma geral, o Modelo Incremental apresenta as caractersticas:

Combina elementos do Modelo em Cascata
(aplicado repetitivamente) com a filosofia iterativa da Prototipao.
Aplica sequncias lineares de uma forma racional medida que o tempo passa.
Cada sequncia linear produz um incremento
do software e pode gerar uma entrega parcial
do produto.
Os primeiros incrementos so verses simplificadas do produto final.
O primeiro incremento chamado de ncleo
do produto (core).
Note que todo o processo pode se repetir at que

um produto completo seja produzido.
Modelo RAD - Rapid Application Development
O modelo RAD - Rapid Application Development
(Desenvolvimento Rpido de Aplicao) uma adaptao do modelo em Cascata, mas que enfatiza um
desenvolvimento extremamente rpido. A alta velocidade conseguida atravs de uma abordagem
de construo baseada em componentes, ou seja, o
sistema modularizado.
Um exemplo clssico de aplicao 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 funes de controle de verses de arquivos, edio e produo de documentos
Se os requisitos forem bem definidos e o objetivo

do projeto for restrito, a equipe pode criar um sistema plenamente funcional em pouco tempo.
31
O RAD enquadra-se no modelo de atividades de arcabouo do Modelo em Cascata:

Especificao: atividade em que se entende o problema de negcio, as caractersticas das informaes
e realizado o levantamento de requisitos.
Planejamento: atividade essencial. Vrias equipes trabalham em paralelo em diferentes funes.
Modelagem: estabelece representaes de projeto que servem como base para a atividade de construo. Abrange trs fases:
o Modelagem de negcio
o Modelagem de dados
o Modelagem de processo
Construo: faz uso de componentes de software preexistentes e gerao de cdigos.
Implantao: estabelece a base para iteraes subsequentes, se necessrias.
A figura 10 apresenta a representao esquemtica do modelo RAD em relao ao modelo sequencial
tradiconal.
Figura 11 Modelo RAD x Modelo Tradicional

Fonte: http://www.etondigital.com/services/rapid-application-development/
As situaes de desenvolvimento mais adequadas

para se utilizar o Modelo RAD incluem:
Projetos em que h fortes restries de tempo

impostas pelo cliente .
Aplicaes que podem ser modularizadas de
forma que cada funo principal possa ser
completada em menos de 3 meses.
Projetos em que cada funo principal possa
ser alocada para uma equipe distinta e depois
integradas para formar o todo do produto.
Projetos em que os requisitos esto bem definidos, o objetivo do sistema restrito e se deseja
criar um sistema plenamente funcional dentro de perodos muito curtos (por exemplo, de
60 a 90 dias, como a figura 11 sugere)
32
mente estes componentes oferecem funcionalidades

com interfaces bem definidas que podem ser facilmente integrados no software sendo desenvolvido.
Mas, a utilizao do modelo RAD tambm pode

implicar em problemas. Para projetos grandes, mas
mensurveis, o RAD requer um nmero elevado de
recursos humanos que sejam suficientes para criar
um nmero adequado de equipes. Alm disso, o RAD
requer um comprometimento entre desenvolvedores
e clientes para que as atividades possam ser realizadas rapidamente e o sistema seja concludo em um
tempo curto. Se o comprometimento for abandonado
por qualquer das partes, o projeto falhar. O uso do
RAD tambm no apropriado quando os riscos tcnicos so grandes (por exemplo, quando a aplicao
faz uso de uma nova tecnologia).
O mtodo de Desenvolvimento Baseado em Componentes incorpora as caractersticas de construo

de componentes de biblioteca ao Modelo Espiral.
De natureza evolucionria, adota uma abordagem
iterativa para a criao de software. Assim, o modelo constri aplicaes a partir de componentes de
software previamente preparados. As atividades de
modelagem e construo comeam com a identificao de componentes candidatos. Esses componentes podem ser projetados como mdulos de software
convencional ou como classes ou pacotes de classes
orientadas a objeto.
Desenvolvimento Baseado em
Componentes
No paradigma orientado a objetos uma classe

encapsula dados e algoritmos, que tambm podem
ser utilizados para manipular os dados. Atravs desta abordagem, uma biblioteca de classes pode ser
construda com as classes identificadas no desenvolvimento do software e a partir de ento toda iterao
da espiral dever verificar o contedo da biblioteca
que pode ser reutilizado. A figura 12 ilustra este processo.
O Desenvolvimento Baseado em Componentes ou

CBD- Component-based Development, tambm 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
so encontrados em bibliotecas de uso gratuito ou
mesmo disponveis para compra. Estes componentes
so conhecidos como COTS Commercial-Off-The-Shelf, ou software comercial de prateleira. Geral-
Figura 12
Modelo do Desenvolvimento Baseado em Componentes
33
O modelo de Desenvolvimento Baseado em Componentes leva ao reuso de

software, e a reusabilidade fornece aos engenheiros vrios benefcios. Com base
nesta reusabilidade, estudos relatam uma reduo de 70% no prazo do ciclo de
desenvolvimento e de 84% no custo dos projetos desenvolvidos neste modelo de
processo, com ndices de produtividade em torno de 26.2, superior ao ndice padro de 16.9 da indstria. [PRESSMAN, 2006].
O reuso de software se refere utilizao de software existente para o desenvolvimento de um novo software. A deciso quanto utilizao de componentes reutilizveis envolve comparaes entre o investimento
necessrio para a sua aquisio e os gastos para o desenvolvimento de uma soluo customizada. Devem ser
estimados os custos e benefcios lquidos no investimento em reuso de software e serem avaliados os ganhos
com a adoo do reuso.
Muitos mtodos para o reuso esto em prtica no mercado atual, sendo sua escolha determinada pela sua
adequao ao modelo de negcio ou s tecnologias utilizadas.
O RiSE - Reuse in Software Engineering, por exemplo, um esforo em direo a um efetivo framework de
mtodos, processos, ferramentas e boas prticas relacionados ao reuso de software que compreende aspectos
tcnicos e no tcnicos.
O CRUISE - Component Reuse in Software Engineering, no formato de livro on line e livre com foco em
reuso de software, um dos primeiros esforos em mapear o reuso de software que cita as reas chave, desenvolvimento baseado em componentes, reengenharia, ferramentas, qualidade de componentes de software,
mtricas para reuso, repositrios, engenharia de domnio, 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 considervel no reuso para se atingir um prazo to justo tornando-o uma tcnica de
quarta gerao que reutiliza componentes de programas existentes ou cria componentes reutilizveis.
vez que executam anlises matemticas apropriadas.

No entanto, o alto custo do uso de mtodos formais
restringe o seu uso ao desenvolvimento de sistemas
de alta integridade, no qual h alta probabilidade das
falhas conduzirem perda de vidas ou srios prejuzos (como nas misses espaciais e no controle de
vos, por exemplo).
Os mtodos formais so tcnicas baseadas em formalismos matemticos que podem ser usados para a
especificao, desenvolvimento e verificao de sistemas de software. Seu uso para o desenvolvimento
de software motivado pela base que fornecem garantindo confiabilidade e robustez a um projeto, uma
34
No modelo de Mtodos Formais, tambm conhecido como Engenharia de Software Cleanroom (Sala
Limpa), uma questo fundamental garantir que o
software realmente uma soluo para o problema
proposto. Para realizar tal tarefa, deve-se primeiro
construir um modelo da soluo (especificao) utilizando uma linguagem formal. Tendo este modelo
formal como base, o mtodo permite:
Como poucos desenvolvedores possuem o conhecimento necessrio para utiliz-lo, so requeridos

muitos cursos e treinamentos. difcil usar tais modelos matemticos formais como meio de comunicao com a maioria dos clientes. Assim, como j
dissemos, sua rea de aplicao muito restrita,
abrangendo, principalmente, aplicaes crticas.
Links Interessantes
realizar provas matemticas que garantem que

este modelo possui as propriedades requisitadas (verificao);
analisar se a soluo proposta aceitvel do
ponto de vista de desempenho, indicando quais
as melhores estratgias para implementao a
serem seguidas;
validar o modelo atravs de simulaes;
realizar o desenvolvimento do software podendo-se provar que a implementao est correta
(gerao de cdigo correto).
Caro aluno,
Para mais informaes sobre os Mtodos Formais,
consulte o link:
http://www.tiosam.org/enciclopedia/index.
asp?q=Mtodos_formais
Para entender como funciona o controle de trfego
areo (projeto crtico), assista ao filme:
http://youtu.be/7wsrs3a-y3M
Processo Unificado
Dentre os vrios mtodos de especificao formal

existentes, destacam-se o mtodo Z, que j foi utilizado em vrias aplicaes prticas, e o mtodo de
gramticas de grafos, por possuir uma linguagem visual de representao e descrever com naturalidade
fenmenos de sistemas concorrentes.
O Processo Unificado (PU) ou Unified Process (UP)

surgiu como um processo para o desenvolvimento de
software visando construo 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 conduo de
um projeto.
De uma maneira mais abrangente, podemos caracterizar assim o modelo de Mtodos Formais:
Permite especificar, desenvolver e verificar um
software atravs de uma rigorosa notao matemtica.
Fornece um mecanismo para eliminar muitos
problemas encontrados nos outros modelos,
como por exemplo, ambiguidade, incompletude e inconsistncia, que podem ser descobertos e corrigidos mais facilmente atravs de
anlise matemtica.
Promete o desenvolvimento de software livre
de defeitos.
Consome muito tempo de desenvolvimento e
muito caro.
O PU utiliza uma abordagem evolucionria 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 iterao, procura-se incrementar um pouco
mais o produto, baseando-se na experincia obtida
nas iteraes anteriores e no feedback do usurio.
Cada iterao pode ser considerada um miniprojeto
de durao fixa, sendo que cada um destes inclui
suas prprias atividades de anlise de requisitos,
projeto, implementao e testes.
35
Fases
O PU foi modelado usando o Software Process

Engineering Model (SPEM) que um padro para
modelagem de processos baseado em UML- Unified
Modeling Language. O processo tem duas estruturas, ou duas dimenses, a saber:
Uma fase definida como a dimenso de tempo entre duas maiores marcas (major milestones) de
processos, durante a qual um conjunto bem definido
de objetivos encontrado, artefatos so completados e a deciso tomada no sentido de ir para a
prxima fase ou no. 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.
- Estrutura dinmica - representa a dimenso do

tempo no processo.
- Estrutura esttica - descreve como elementos do
processo so agrupados em disciplinas.
A estrutura que representa o tempo denominada fase e a estrutura que representa os elementos
do processo so as disciplinas, conforme mostra a
figura 13.
Figura 13
Fonte: http://isosoftware.blogspot.com/2010/02/processo-unificado-pu-unified-process.html
36
O Processo Unificado organiza suas iteraes em

quatro fases principais:
aperfeioamentos; assegurar que o cliente, o

usurio final e os desenvolvedores possuam a
mesma compreenso da empresa; produzir os
requisitos de sistemas necessrios para suportar os objetivos da organizao.
DDRequisitos: estabelecer e manter o consentimento entre clientes e stakeholders sobre o
que o sistema deve fazer; fornecer uma melhor
compreenso dos requisitos aos desenvolvedores; definir os limites do sistema; fornecer as
bases para o planejamento das iteraes, estimativas de custo e tempo de desenvolvimento;
definir as interfaces do sistema baseado nas
necessidades e objetivos dos usurios.
DDAnlise 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 implementao.
DDImplementao: preparar a organizao do
cdigo em termos de implementao 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 executvel.
DDTeste: verificar a interao entre os objetos;
verificar a integrao 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.
DDImplantao: descrever as atividades associadas verificao para que o produto esteja
disponvel ao usurio final.
DDGerenciamento de Configurao e Mudana: identificar itens de configurao; restringir alteraes para aqueles itens; auditar as
alteraes neles feitas; definir e gerenciar as
alteraes daqueles itens.
DDGerenciamento de Projeto: fornecer uma
estrutura para gerenciamento de projeto de
software; fornecer um guia prtico para plane-
[1] Concepo ou Iniciao: o objetivo desta

fase levantar, de forma genrica e pouco precisa, o escopo do projeto. No deve existir aqui
a pretenso de especificar de forma detalhada
os requisitos, a ideia ter uma viso inicial do
problema, estimar de forma vaga o esforo e
os prazos e determinar se o projeto vivel e
merece uma anlise mais profunda.
[2] Elaborao: na fase de elaborao todos
(ou a grande maioria dos requisitos) so levantados em detalhes. Numa primeira iterao um
ou dois requisitos, os de maior risco e valor arquitetural, so especificados em detalhes. Estes so implementados e servem como base de
avaliao junto ao usurio e desenvolvedores
para o planejamento da prxima iterao. Em
cada nova iterao na fase de elaborao pode
haver um seminrio de requisitos, onde requisitos antigos so melhor esclarecidos e novos
so detalhados. Ao fim desta fase, deseja-se
que 90% dos requisitos tenham sido levantados em detalhes, o ncleo do sistema tenha
sido implementado com alta qualidade, os principais riscos tenham sido tratados e haja condies para se fazer estimativas mais realistas.
[3] Construo: implementao iterativa dos
elementos restantes de menor risco e mais fceis e preparao para a implantao.
[4] Transio: testes finais e implantao.
Disciplinas
Uma disciplina uma coleo de atividades relacionadas que esto ligadas maior rea de interesse
dentro do processo em geral. Cada disciplina possui,
resumidamente, os seguintes objetivos especficos:
DDModelagem de Negcios: entender a estrutura e a dinmica da organizao para a qual
o produto ser desenvolvido; identificar problemas correntes na organizao e possveis
37
Desenvolvimento gil
jamento, recrutamento, execuo e monitoramento de projeto; fornecer uma estrutura para

o gerenciamento de riscos.
DDAmbiente: identificar as atividades necessrias para configurar o processo para o projeto;
descrever as atividades requeridas para desenvolver as guias mestras no suporte ao projeto;
fornecer para a organizao de desenvolvimento de software, o ambiente de processos e ferramentas que suportaro a equipe de desenvolvimento.
As definies modernas de desenvolvimento de

software gil evoluram a partir de meados de 1990
como parte de uma reao contra mtodos caracterizados por uma regulamentao complexa e rgida
e contra a regimentao e sequenciamento usados
no modelo em cascata. O objetivo era desburocratizar os procedimentos que tornavam as etapas dos
processos lentas, o que era contrrio ao modo de
trabalho usual dos engenheiros de software.
De uma maneira geral, podemos assim caracterizar o Processo Unificado:
Inicialmente, os mtodos geis foram denominados de mtodos leves. Em 2001, Kent Beck e 16 outros notveis profissionais da rea de Engenharia de
Software se reuniram, adotaram o nome mtodos
geis, e publicaram o Manifesto gil, documento
que rene os princpios e prticas desta metodologia de desenvolvimento. Esses veteranos formaram
a Agile Alliance ou Aliana gil, uma organizao no
lucrativa que promove e fomenta o desenvolvimento
gil.
um framework genrico de um processo de

desenvolvimento;
baseado em componentes;
utiliza toda a definio 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 prope uma
abordagem realstica para a conduo de um projeto.
Ao contrrio do modelo em cascata, em que cada
etapa do ciclo de vida deve ser realizada integral e
sequencialmente, no PU as atividades so repetidas
quantas vezes forem preciso, em ciclos organizados.
No h um plano detalhado para todo um projeto. H
um plano de alto nvel (chamado Plano de Fases) que
estima a data de trmino do projeto e outros marcos
de referncia principais, mas ele no detalha os passos
de granularidade fina para se atingir tais marcos.
Um plano detalhado (chamado Plano de Iteraes)
somente planeja a iterao a ser feita em seguida. O
planejamento detalhado feito de forma adaptativa,
de iterao para iterao.
Os membros da Aliana gil, declararam assim os

princpios da metodologia em seu manifesto:
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando
outros a faz-lo. Atravs desse trabalho, passamos a
valorizar:
Indivduos e interao entre eles mais que processos e ferramentas;

Software em funcionamento mais que documentao abrangente;
Colaborao com o cliente mais que negociao
de contratos;
Responder a mudanas mais que seguir um plano.
Ou seja, mesmo havendo valor nos itens direita,
valorizamos mais os itens esquerda.
38
figura 14. A iterao tpica envolve o desenvolvimento

em fases curtas, de 1 a 4 semanas, envolvendo todas
as tarefas necessrias para implantar uma funcionalidade. Considerando-se o perodo curto de cada iterao, a comunicao mantida entre os stakeholders
em tempo real sendo, preferencialmente, tratada
por meio verbal (embora documentada), ou face-a-face, visando minimizar entendimentos parciais ou
errneos. Para tanto necessrio estabelecer-se um
local fsico (uma sala) onde toda a equipe necessria
ficar focada no projeto.
Os principais modelos baseados na concepo 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 Programao
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 perodos ou iteraes, como mostra a
Figura 14 Etapas do Desenvolvimento gil Fonte: http://www.sstecnologia.com.br/
Alguns crticos do processo gil afirmam que o maior risco deste tipo de abordagem a baixa qualidade
ou mesmo inexistncia de documentao do projeto devido interao humana face-a-face que, se por um
lado traz agilidade na comunicao, por outro traz a informalidade nas definies. Assim sendo, necessrio
um bom acompanhamento do 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 antecedncia quais requisitos vo persistir e quais sero modificados, bem
como prever quais prioridades dos clientes sofrero mudanas ao longo do projeto;
Intercalao das etapas de projeto e construo, que vo sendo realizadas juntas de modo que os
modelos de projeto vo sendo comprovados na medida em que so criados;
Anlise, projeto, construo e testes no so to previsveis, do ponto de vista do planejamento, como
seria desejado.
39
Caro aluno, em defesa dos mtodos geis e fazendo uma crtica ao chamado desenvolvimento tradicional, encontramos a seguinte comparao na pesquisa que fizemos na internet:
Fonte: http://icarovinicius.com.br/blog/tag/metodologias-ageis/
A metodologia gil vem gerando grande debate, fazendo muitos desenvolvedores apaixonados e muitos
outros crticos ferrenhos. Mas temos que manter a imparcialidade profissional e questionarmos o que realmente tem que ser observado, como:
Qual a melhor forma de se alcanar a agilidade nos processos e prticas do desenvolvimento de software?
Como construir softwares que satisfaam s necessidades do cliente e possua caractersticas de qualidade que permitam sua extenso e ampliao para satisfazer as necessidades do cliente no longo
prazo?
40
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 so algumas metodologias geis que esto em voga no momento.
Elas refletem o esprito deste manifesto gil?
Com a nossa cultura de fast food, de querer achar uma receita mgica para tudo, o mundo gil ganhou fora
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 no funciona. Tem gente que at discute se o pico
recente de Scrum no foi mais negativo que positivo, porque muita gente est aplicando e no atinge os resultados,
simplesmente porque usa o raciocnio antigo com ferramentas novas. Os valores no 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 dirio, e essas coisas chamadas retrospectiva e backlog. Ele te d nomes e elementos
que voc aplica. Mas no s aplicar e ponto. Isso s o comeo. A grande mensagem da forma gil de pensar
que o procedimento no importante. irrelevante se eu chamo o meu tempo de trabalho de sprint ou o dono
do projeto de product owner. absolutamente irrelevante, se eu no entendi os valores que so entregar valor ao
cliente, criar uma organizao de aprendizado, acreditar nas pessoas e dar suporte a elas. Esses princpios que so
importantes, mas no so explcitos. Em vez disso eu tenho papis, cargos e atividades. No se explicam os porqus
e no entendendo os porqus 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/
Coletnea de artigos sobre Desenvolvimento gil
http://www.fernandocosta.com.br/category/desenvolvimento-agil/
41
1) Em relao ao modelo Em Cascata podemos afirmar que :
a) Uma abordagem razovel quando os requisitos esto 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 so as 5 atividades gerais da Engenharia de Software, tambm caracterizadas no
modelo Em Cascata?
a) Especificao, gerenciamento de risco, medida, produo, reviso
b) Anlise, projeto, implementao, testes, manuteno
c) Especificao, planejamento, modelagem, construo, implantao (entrega)
d) Anlise, planejamento, projeto, programao, anlise de risco
3) Podemos dizer que o modelo incremental :
b) Uma boa abordagem quando um produto de trabalho ncleo requerido rapidamente
c) A melhor abordagem para se usar quando se tem uma grande equipe de desenvolvimento
d) Um modelo revolucionrio que normalmente no utilizado para desenvolver produtos comerciais
4) Podemos afirmar que modelos de processo evolucionrios:
a) So iterativos por natureza
b) Podem facilmente acomodar mudanas de requisitos
c) Quase sempre no produzem produtos descartveis
d) Todas as alternativas anteriores esto corretas
5) O modelo de prototipagem :
a) Uma abordagem razovel quando os requisitos esto bem definidos
b) A melhor abordagem para usar em projetos com grandes equipes de desenvolvimento
c) Uma abordagem razovel quando o cliente no consegue definir os requisitos claramente
d) Um modelo de alto risco que raramente produz software de qualidade
6) O modelo espiral de desenvolvimento de software:
a) Finaliza com a entrega do software
b) mais catico que o modelo incremental
c) Inclui avaliao de riscos a cada iterao
d) Todas as afirmativas anteriores esto corretas
42
7) O modelo de desenvolvimento concorrente:

a) outro nome para engenharia concorrente
b) Define eventos que podem desencadear transies de estados dentro de cada fase de desenvolvimento
c) Somente usado para desenvolver sistemas distribudos
d) usado sempre que um grande nmero de solicitaes de alterao de requisitos previsto
e) Somente a e b so verdadeiras
8) Podemos dizer que o modelo de desenvolvimento baseado em componentes:
a) Somente apropriado para projetos ligados a hardware
b) No capaz de suportar o desenvolvimento de componentes reusveis
c) Depende da tecnologia de objetos como suporte
d) No se mostra rentvel quando quantificado por mtricas de software
9) O modelo de mtodos formais faz uso de mtodos matemticos para:
a) Definir a especificao de requisitos
b) Desenvolver sistemas livres de defeitos
c) Verificar a corretude de sistemas baseados em computador
d) Todas as alternativas anteriores so corretas
10) Qual dos nomes abaixo no representa uma das fases do modelo de processo unificado?
a) Fase de iniciao
b) Fase de validao
c) Fase de elaborao
d) Fase de construo
11) O que se entende por ciclo de vida?
12) Qual a diferena entre um modelo descritivo e um modelo prescritivo de processo?
13) O que caracteriza os modelos evolucionrios de processo?

14) Em que situaes os modelos incrementais so mais indicados?
15) Cite uma das principais diferenas entre o Modelo Incremental e o Modelo de Prototipagem.
16) Cite quais so as duas dimenses do Processo Unificado.
17) Quais so as fases e as disciplinas do Processo Unificado?
43
18) Quais so as principais caractersticas do Processo Unificado?

19) Quais so os princpios das metodologias geis?
20) Nos modelos de processos geis o nico produto de trabalho gerado o programa de
trabalho.
a) Verdadeiro
b) Falso
44
Engenharia de Requisitos
Caro aluno, neste captulo definiremos o que so requisitos de software e a sua importncia dentro da
Engenharia de Requisitos. Todas as etapas, conceitos e definies ligadas ER sero apresentadas.
Requisitos e Engenharia de
Requisitos
Na figura 15, a fase de Anlise, corresponde

anlise de requisitos. Como pode ser visto, o custo
aumenta com o tempo de descoberta do erro e os
erros mais caros so aqueles cometidos na Anlise
de Requisitos. Muitas vezes estes erros so descobertos pelo prprio cliente, mesmo antes da entrega
do produto, quando ele participa ativamente. Assim,
os requisitos deficientes so considerados uma das
maiores causas de falhas nos projetos de software.
Caro aluno, a Engenharia de Requisitos (ER) pode

ser vista como uma sub-rea da Engenharia de Software, cujo principal objetivo a obteno de uma
especificao correta e completa dos requisitos de
um sistema de software.
A Engenharia de Requisitos tem se tornado cada
vez mais necessria para resolver os problemas encontrados nas organizaes com relao definio
de sistemas. De acordo com estudos realizados pelas
empresas GTE, TRW e IBM (na dcada de 1970), foi
mostrado que o custo relativo de um erro localizado
durante a anlise de requisitos seria 0.1, um erro
localizado na fase de implementao 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 manuteno. Apesar de este estudo ser antigo, os dados
atuais ainda o confirmam, como pode ser visto na
figura 15.
Mas, afinal, o que so os requisitos?

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

Uma condio ou capacidade que um usurio necessita para resolver um problema ou alcanar um objetivo.
Uma condio ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um
padro.
De acordo com Sommerville:
Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem restries
sobre sua operao e implementao.
De acordo com o dicionrio, requisito :
Condio necessria para a obteno 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 ao de engenharia de software que comea
durante a atividade de Especificao e continua durante a atividade de modelagem.
Figura 15 - Custo do Erro em Software

Fonte: https://www.mar.mil.br/sdms/0050-apresentacao.ppt
Para que o processo de desenvolvimento de software seja bem sucedido fundamental que haja
uma compreenso completa dos requisitos de sof-
45
tware. Tanto o desenvolvedor como o cliente desempenham um papel ativo na anlise e especificao
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.
os ou funes por ele providas. Sua classificao

mostrada na figura 16.
Podem ser categorizados em:
Requisitos de Produto
So requisitos que especificam o comportamento

do produto, como por exemplo:
Requisitos de Facilidade de Uso ou de Usabilidade: referem-se ao esforo para utilizar ou
aprender a utilizar o produto. Esto relacionados com a interao do usurio junto ao sistema.
Requisitos de Confiabilidade: referem-se frequncia de ocorrncia de falhas e recuperabilidade em caso de falha, como: tempo mdio de
falhas; probabilidade de indisponibilidade; taxa
de ocorrncia de falhas; tempo de reincio aps
falha; percentual de eventos causando falhas;
probabilidade de corrupo de dados aps falha.
Requisitos de Eficincia: referem-se ao desempenho do sistema e esto associados eficincia, uso de recursos e tempo de resposta da
aplicao, como: transaes processadas/segundo; tempo de resposta do usurio/evento, entre outros.
Requisitos de Portabilidade: so relativos capacidade de transferir o produto para outros
ambientes
Objetivos e Classificao dos

Requisitos
Os requisitos tm por objetivo:
Estabelecer e manter concordncia com os
clientes e outros envolvidos sobre o que o sistema deve fazer;
Oferecer aos desenvolvedores uma compreenso 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
so classificados como funcionais, no funcionais, de
domnio, do usurio e do sistema. Mas algumas destas classes ainda apresentam uma subclassificao.
Uma breve descrio destas categorias apresentada no que se segue.
1. Requisitos Funcionais
Requisitos Organizacionais
So requisitos que descrevem a funcionalidade

(funes que o sistema deve realizar) ou os servios
que se espera que o sistema faa. Exemplos de requisitos funcionais: cadastro de cliente; emisso de
nota fiscal; consulta ao estoque; gerao de pedido.
So requisitos derivados das polticas organizacionais do cliente e do desenvolvedor, como por exemplo:
Requisitos de Implementao: ligados s regras de codificao e restries de software e
hardware usados para desenvolver ou executar
o sistema
Requisitos de Padres: referem-se definio
da linguagem de programao e s normas que
2. Requisitos No-Funcionais
So requisitos que no dizem respeito diretamente funcionalidade do sistema, mas expressam propriedades do sistema e/ou restries sobre os servi-
46
referentes aos direitos autorais, alguns documentos

devem ser excludos imediatamente ao serem fornecidos.
devem ser seguidas pelo sistema ou no processo de desenvolvimento

Requisitos de entrega: referem-se ao modo
como ser implantada a soluo como configuraes necessrias e ordem de instalao dos
pacotes
3. Requisitos de Domnio
So requisitos derivados do domnio da aplicao
do sistema. Ao invs de serem obtidos a partir das
necessidades especficas dos usurios do sistema,
eles podem se transformar em novos requisitos funcionais, ou serem regras de negcios especfica do
domnio do problema. Por exemplo:
DDUtilizao de uma interface padro utilizando a
norma Z39.50;
DDDisponibilizao de arquivos somente para leitura devido aos direitos autorais;
Requisitos Externos
So requisitos procedentes de fatores externos

ao sistema e ao seu processo de desenvolvimento,
como por exemplo:
Requisitos ticos
Requisitos Legais (como poltica de privacidade
e direitos autorais)
Requisitos de Interoperabilidade
4. Requisitos do Usurio
Exemplos: o sistema no dever revelar aos operadores nenhuma informao pessoal sobre os clientes, alm de seus nomes e o nmero de referncia
(legislao de privacidade); em razo das restries
So os requisitos funcionais e no funcionais do

sistema sob o ponto de vista do usurio. Em geral
apresentam problemas como falta de clareza, confuso e fuso, ou seja, requisitos diferentes escritos como
um nico requisito.
5. Requisitos do Sistema
So descries mais detalhadas dos requisitos do usurio. So a base para que os engenheiros de software possam fazer o projeto do sistema. Servem como base para um contrato destinado implementao
do sistema.
Figura 16 Classificao dos requisitos no-funcionais

Fonte: http://evertongomede.blogspot.com/2010/09/taxonomiados-requisitos-nao-funcionais.html
47
Stakeholders (Influenciadores/Envolvidos)
So as partes interessadas no projeto, ou seja,
so pessoas e organizaes envolvidas no projeto ou que possuem interesses que podem ser
afetados pelo projeto, podendo exercer influncia sobre os resultados do projeto.
Baseline
Conjunto de artefatos de software que servem
A Engenharia de Requisitos rene as primeiras atividades a serem realizadas nos diversos modelos de
processo de software. Seu objetivo definir o que
deve ser feito e no a forma como ser implementado o sistema. Serve como ponte entre o projeto e a
construo do software e define as bases do contrato
entre o desenvolvedor e o cliente. Realiza a aquisio, o refinamento e a verificao das necessidades do sistema. A meta sistematizar o processo de
definio dos requisitos, obtendo uma especificao
correta e completa do sistema para elaborao do
DERS.
de base para o seu desenvolvimento.
DERS - Documento de Especificao de Requisitos de Software

De acordo com o IEEE este documento deve ser
completo e no ambguo, sendo responsvel por
auxiliar os clientes de software a descrever com
preciso o que eles desejam obter, e desenvolvedores de software a entender exatamente o
que o cliente deseja. Para os clientes, desenvolvedores e outros indivduos ligados ao projeto,
um bom DERS deve prover diversos benefcios,
tais como:
Estabelecer a base de acordo entre os

clientes e a empresa fornecedora sobre o
que o software ir fazer;
Reduzir o esforo de desenvolvimento;
Prover uma base para estimativas de custo
e prazos;
Prover uma base para validao e verificao do produto;
Facilitar a manuteno do produto de software final.
Um DERS conta com alguns padres indicados
para sua elaborao. O IEEE elaborou um documento que contm padres e prticas recomendadas para a criao do DERS chamado IEEE
Recommended Practice for Software Requirements Specification - Prticas Recomendadas
para a Especificao de Requisitos de Software. Este documento est disponvel em: http://
www6.conestogac.on.ca/~set/courses/year1/
sef/documents/IEEE830-1998Standard.pdf
48
entender os ambientes operacionais do cliente

e aplicar solues de hardware e/ou software
aos ambientes do cliente
comunicar-se bem nas formas escrita e verbal
A Engenharia de Requisitos possibilita que:

O engenheiro de sistemas:
DD especifique a funo e o desempenho do software
O analista ou engenheiro de requisitos executa ou

coordena as tarefas associadas anlise de requisitos de software. O analista deve estabelecer a comunicao com a atividade de anlise. Ele estabelece
o contato com os stakeholders, quais sejam, pessoas
da administrao e da equipe tcnica da organizao
do cliente e a equipe de desenvolvimento do software. A meta do analista identificar os elementos bsicos dos problemas da organizao, 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 operao comportamental do sistema a
ser construdo. Este modelo servir como base para
o projeto de software e para a criao de sua especificao. O analista geralmente o responsvel pelo
desenvolvimento de uma Especificao de Requisitos
de Software e participa de todas as revises.
DD indique a interface do software com outros elementos do sistema

DD estabelea quais so as restries de projeto
que o software deve enfrentar.
O engenheiro de software:
DD aprimore a alocao de software e construa modelos do processo, dos dados e dos domnios
comportamentais que sero tratados pelo software
O projetista de software:
DD tenha uma representao da informao e da
funo que pode ser traduzida em projeto procedimental, arquitetnico e de dados
O desenvolvedor e o cliente:
DD definam os critrios para avaliar a qualidade
logo que o software seja construdo.
O perfil dos stakeholders, ou pessoas envolvidas

na definio dos requisitos, pode ser assim definido:
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 divises lgicas e sintetizar solues
baseadas em cada diviso
absorver fatos pertinentes de fontes conflitantes ou confusas
49

Leia a descrio do sistema automtico de emisso de passagens.
Um sistema automtico de emisso de passagens vende passagens de nibus. Os usurios escolhem

seu destino e apresentam um carto de crdito e um nmero de identificao pessoal. A passagem
emitida e o custo dessa passagem includo em sua conta do carto de crdito. Quando o usurio pressiona o boto para iniciar, uma tela de menu com os possveis destinos ativada, juntamente com uma
mensagem para que o usurio selecione o destino. Uma vez selecionado um destino, pede-se que os
usurios insiram o carto de crdito. A validao do carto checada e o usurio, ento, deve fornecer
um nmero de identificao pessoal. Quando a transao de crdito validada, a passagem emitida.
Responda:
a) Aponte as ambiguidades e omisses.
b) Descreva os requisitos funcionais.
c) Descreva os requisitos no-funcionais.
d) Identifique os Stakeholders.
Tarefas da Engenharia de
Requisitos
DDO sistema pode ser implementado com a utilizao de tecnologia atual dentro das restries
de custo e prazo?
DDO sistema pode ser integrado com outros sistemas j em operao?
DDAps responder essas questes necessrio
questionar as fontes de informao (stakeholders). Para isso, so recomendadas algumas
perguntas, como:
DD Como a empresa se comportaria, se esse sistema no fosse implementado?
DDQuais so os problemas com os processos atuais e como um novo sistema ajudaria a diminuir
esses problemas?
DDQue contribuio direta o sistema trar para os
objetivos da empresa?
DDAs informaes podem ser transferidas para
outros sistemas e tambm podem ser recebidas a partir deles?
DDO sistema requer tecnologia que no tenha
sido utilizada anteriormente na empresa?
DDO que precisa e o que no precisa ser compatvel com a empresa?
DDQuem vai usar o sistema?
A Engenharia de Requisitos fornece um mecanismo adequado para entender o que o cliente deseja,
analisar as suas necessidades, negociar uma soluo
adequada ao seu problema, validar a especificao
e administrar os requisitos medida que eles so
transformados em um sistema em operao. Para
isso, o processo de ER realizado por meio de 7 etapas distintas, que sero explicadas no que se segue,
com base em Pressman (2006).
1. Concepo ou Estudo de Viabilidade do
Sistema
O estudo de viabilidade um estudo breve, direcionado, que se destina a responder a algumas perguntas:
DDO sistema contribui para os objetivos gerais da
empresa?
50
Aps obter essas respostas, deve-se preparar um

relatrio de viabilidade.
As etapas de Levantamento e Anlise de Requisitos so conhecidas em conjunto como Elicitao de Requisitos e envolvem:
2. Levantamento dos Requisitos
DD Compreenso do domnio: Os analistas devem

desenvolver sua compreenso do domnio da
Aps os estudos iniciais de viabilidade, o prximo

passo o levantamento dos requisitos. Nesta etapa
deve-se descobrir mais informaes sobre o domnio
da aplicao, que servios 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 no sabem na realidade o que querem do
sistema computacional, a no ser em termos muito
gerais. Costumam expressar os requisitos utilizando
seus prprios termos e com o conhecimento implcito
de sua rea de atuao. Diferentes stakeholders tm
em mente diferentes requisitos e podem express-los
de maneiras distintas. Alm disso, fatores polticos
podem influenciar os requisitos do sistema. O ambiente econmico e de negcios, no qual a anlise
de requisitos ocorre, dinmico, ou seja, inevitavelmente, o ambiente se modifica durante o projeto.
Como consequncia, a importncia dos requisitos especficos pode mudar. Assim, novos requisitos podem
surgir por parte dos novos stakeholders, que no haviam sido consultados inicialmente.
aplicao. Por exemplo, se for um sistema para

uma loja, o analista dever descobrir como operam as lojas de varejo.
DD Coleta de requisitos: o processo de interagir
com os stakeholders do sistema para descobrir
seus requisitos. Certamente a compreenso do
domnio se desenvolve mais durante essa atividade.
DD Classificao: Essa atividade considera o conjunto no estruturado dos requisitos e os organiza
em grupos coerentes.
DD Resoluo
de
conflitos:
Quando
mltiplos
stakeholders esto envolvidos, os requisitos

podem apresentar conflitos. Essa atividade se
ocupa em encontrar e solucionar esses possveis
conflitos.
DD Definio das prioridades: Em qualquer conjunto de requisitos, alguns sero mais importantes
do que outros. Esse estgio envolve a interao
com os stakeholders, para descobrir os requisitos mais importantes.
DD Verificao de requisitos: Os requisitos so verificados, a fim de se descobrir se eles so comple-
3. Anlise de Requisitos
tos e consistentes e se esto em concordncia

com o que os stakeholders realmente desejam
As informaes obtidas do cliente durante a concepo e o levantamento so expandidas e refinadas durante a anlise (ou elaborao) de requisitos.
Esta atividade da ER tem por objetivo desenvolver
um modelo tcnico refinado das funes, caractersticas e restries do software. guiada pela criao
e refinamento de cenrios do usurio que descrevem
como o usurio final (e outros atores) vo interagir
com o sistema.
do sistema.
51
requisitos realmente definem o sistema que o cliente

deseja. So realizadas diversas verificaes, como:
DDVerificaes de validade: Um usurio pode pensar que um sistema necessrio para realizar
certas funes, mas mais estudos e anlises
podem identificar funes adicionais ou diferentes necessrias.
DDVerificaes de consistncia: Os requisitos em
um documento no devem ser conflitantes, ou
seja, no devem existir restries contraditrias ou descries diferentes para uma mesma
funo do sistema.
DDVerificaes de completeza: O documento de
requisitos (DERS) deve incluir requisitos que
definam todas as funes e restries exigidas
pelo usurio do sistema.
DDVerificaes de realismo: Utilizando o conhecimento da tecnologia existente, os requisitos
devem ser verificados, a fim de assegurar que
eles realmente podem ser implementados. Essas verificaes devem tambm levar em conta
o oramento e os prazos para o desenvolvimento do sistema.
DDFacilidade de verificao: Para reduzir o potencial de divergncias entre cliente e desenvolvedor, os requisitos do sistema devem sempre ser
escritos de modo que possam ser verificados.
Isso significa que um conjunto de verificaes
pode ser projetado para mostrar que o sistema
entregue cumpre com esses requisitos.
DDO requisito realmente passvel de ser
testado, como foi definido?
DDO requisito pode ser adequadamente
compreendido pelos compradores ou
usurios finais do sistema?
DDA origem do requisito claramente definida?
DD O requisito adaptvel?
DDEle pode ser modificado sem que isso
provoque efeitos em grande escala em
outros requisitos do sistema?
4. Negociao dos Requisitos

A negociao categoriza e organiza os requisitos
em subconjuntos relacionados. Neste passo as seguintes perguntas devem ser respondidas:
DDCada requisito est consistente com o objetivo
global do sistema?
DDTodos os requisitos foram especificados no nvel de abstrao adequado?
DDO requisito realmente necessrio ou representa uma caracterstica adicional que pode
no ser essencial para o objetivo do sistema?
DDCada requisito limitado e no-ambguo?
DDCada requisito tem atribuio? (Ser utilizado
por algum)
DDAlgum requisito conflita com outros requisitos?
DDCada requisito realizvel no ambiente tcnico?
DDCada requisito pode ser testado, quando estiver implementado?
DDQual a prioridade desse requisito?
5. Especificao dos Requisitos
Especificao de Requisitos, geralmente um documento escrito, que contm o detalhamento do sistema, os requisitos funcionais e no-funcionais e os
modelos do sistema que podem ser representados
atravs 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 sequncia e prototipao.
6. Validao dos Requisitos
A validao de requisitos examina a especificao
de requisitos para garantir que todos os requisitos
do sistema tenham sido identificados e detalhados,
que as inconsistncias, omisses e erros tenham sido
detectados e corrigidos e que as prioridades tenham
sido estabelecidas. Tem a funo de mostrar que os
Um dos mecanismos de validao de requisitos

a RTF- Reviso Tcnica Formal (Captulo 26, item
52
26.4.1. Pressman, 2006). Em uma RTF com esse propsito, a equipe de desenvolvimento deve conduzir
o cliente pelos requisitos do sistema, explicando as
implicaes de cada requisito. A equipe de reviso
deve verificar cada requisito, em termo de sua consistncia 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. Gesto de Requisitos
Gesto de Requisitos um conjunto de atividades
que ajuda a equipe de projeto a identificar, controlar
e rastrear requisitos e modificaes de requisitos a
qualquer momento no desenvolvimento do sistema.
Para auxiliar na gesto de requisitos tabelas de rastreamento so criadas com o objetivo de verificar as
relaes entre requisitos e o impacto da mudana
de requisitos. Os requisitos mudam e h uma srie
de razes para isso, como: os problemas podem ser
muito intricados, as especificaes podem ficar incompletas, o aumento do entendimento do sistema
ocorre ao longo do projeto, como h vrios usurios,
h vrias vises, quem paga pelo sistema geralmente diferente de quem o usa, a empresa e o ambiente se modificam e, na medida em que os usurios se
familiarizam com o sistema, novos requisitos surgem.
A gesto de requisitos precisa de apoio automatizado
como ferramentas CASE - Computer Aided Software
Engineering para:
DDArmazenamento de requisitos: os requisitos
devem ser mantidos em um depsito de dados
seguro, gerenciado, que seja acessvel por todos os envolvidos no processo de engenharia
de requisitos.
DDGerenciamento de mudanas: esse processo
pode ser simplificado se o apoio de ferramentas estiver disponvel.
DDGerenciamento de facilidade de rastreamento:
o apoio de ferramentas para a rastreabilidade
permite que sejam descobertos requisitos relacionados.
Com base na animao 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 so:
Em primeiro lugar evite perguntar ao cliente o
que ele quer que o novo sistema faa
Entenda, primeiro, como so atualmente os
processos do seu cliente
Pergunte ao cliente quais processos que ele
sabe que funcionam bem no sistema atual.
Faa o cliente explicar porque ele acha que funcionam bem. Faa o mesmo com os processos
que existem e funcionam mal.
Descubra quais so os processos atuais que
existem, mas que ningum usa e porque no
so usados.
Baseado nessas informaes, desenvolva uma
lista ou um prottipo do que voc acredita que
o cliente precisa. Quanto mais claramente esse
prottipo puder ser compreendido pelo cliente
melhor. Por exemplo, se for um cliente da rea
tcnica voc poder lhe mostrar os casos de
uso ou usar diagramas mais tcnicos. Se for
um cliente de negcio, voc vai precisar de
algo mais visual, ento faa desenhos ou crie
uma animao
Faa o cliente analisar o seu prottipo ou sua
lista, mesmo que seja difcil para ele. Procure
estar sempre cara-a-cara com seu cliente enquanto ele estiver fazendo a anlise.
53
Assinale os requisitos que o cliente concorda e

aqueles que ele discorda. Baseado nessas informaes descubra se ainda existem pontos
do processo que voc no entendeu corretamente.
Faa um novo prottipo 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 concordncia no
fcil, mas deve haver uma sensao de comprometimento e de entendimento entre voc e
seu cliente aps este processo.
sitos rene as atividades de definir e gerenciar

as expectativas do cliente.
Entrevistas
Uma entrevista um meio que pode ser formal
ou informal de se descobrir informaes dos
stakeholders por meio de conversas diretas.
Normalmente feita por meio de perguntas
preparadas ou espontneas e do registro das
respostas. So frequentemente conduzidas individualmente, mas podem envolver mltiplos
entrevistadores e/ou entrevistados. Entrevistar
participantes experientes, stakeholders e especialistas no assunto do projeto pode auxiliar na
identificao e definio das caractersticas e
funes das entregas desejadas.
Documentao
Os componentes da documentao podem incluir, mas no esto limitados a:
DDA necessidade do negcio ou oportunidade a ser aproveitada, descrevendo as
limitaes da situao atual e por que o
projeto foi empreendido
DDObjetivos do negcio e do projeto para
permitir rastreamento
DDRequisitos funcionais descrevendo processos de negcio, informaes e interao com o produto de forma apropriada a
ser documentada textualmente
DDRequisitos no funcionais, tais como nvel
de servio, desempenho, cuidados, segurana, atendimento a leis e regulamentos, etc
DD Impactos em outras reas organizacionais
DDImpactos em outras entidades internas
ou externas organizao
Elicitao de Requisitos
De acordo com o PMBoK Project Management
Body of Knowledge, um guia que rene o conjunto
de Melhores Prticas em Gerenciamento de Projetos
produzido pelo PMI - Project Management Institute
(2008), o processo de elicitao de requisitos envolve:
Coleta
Processo de definir e documentar as funes e
funcionalidades do projeto e do produto necessrias para atender s necessidades e expectativas dos stakeholders. O sucesso do projeto
diretamente influenciado pela ateno 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
execuo do projeto se inicie. Coletar os requi-
A figura 17 ilustra o fluxo ao qual submetida

uma anlise de requisitos toda vez que o cliente manifesta uma (nova) necessidade.
54
Figura 17 Fluxo da anlise de requisitos

Fonte: http://blogbohm.com/2010/10/18/analise-de-requisitos-como-ferramenta-de-planejamento/
55
Para que este processo ocorra com sucesso, os requisitos devem ser claros, completos, sem ambiguidade,
implementveis, consistentes e testveis como mostra a tabela 1. Os requisitos que no apresentem estas
qualidades so problemticos: eles devem ser revistos e renegociados com os clientes e usurios.
No ambguo
todo requisito tem apenas uma interpretao possvel.
Correto
todo requisito representa algo requerido ao sistema/funcionalidade a ser construdo.
Completo
contm tudo o que o software deve fazer e atender em todas as situaes possveis.
Compreensvel
todas as pessoas podem facilmente compreender o significado de todos os requisitos

com um mnimo de explicao.
Verificvel
atendem ao conjunto de tcnicas que podem ser usadas para verificar que todo requisito est implementado pelo sistema.
Internamente Consistente
no h requisitos conflitantes entre si.
Externamente Consistente
no h requisitos conflitantes com outra documentao de projeto j definida.
Realizvel
possibilita que um projeto seja implementado corretamente com todos os requisitos

declarados.
Conciso
to pequeno quanto possvel, sem afetar qualquer outra qualidade que deva atender.
Rastrevel
escrito de modo que facilite o referenciamento de cada requisito individualmente.
Modificvel
sua estrutura e estilo so tais que qualquer mudana pode ser feita facilmente, completamente e consistentemente.
Anotado por Importncia Relativa
permite que se possa facilmente determinar qual requisito mais importante para os
clientes.
Anotado por Estabilida- permite que se possa facilmente determinar qual requisito mais suscetvel mudande Relativa
a.
Organizado
permite que se possa facilmente localizar informaes e relacionamentos lgicos entre

sees adjacentes.
Tcnicas de Coleta de Requisitos
[1] Planejamento da Entrevista:

DDDeve-se decidir quem ser entrevistado.
DDPreparar os entrevistados (agendar data e
hora, comentar sobre o assunto).
DDPreparar a lista de questes de diversos tipos:
o Abertas: Explique como esse relatrio
produzido.
o Fechadas: Quantos relatrios desse tipo
so gerados?
o Sequenciais: Por qu? D um exemplo.
deve-se preocupar em dar continuidade
a uma questo.
o Preparar mais de uma questo para um
tpico a fim de confirmar a resposta e
deix-la mais completa.
A coleta ou extrao de requisitos feita atravs

de tcnicas. Nesta etapa, os requisitos so documentados medida em que so coletados e deste processo resulta um documento preliminar dos requistos do sistema. No que se segue sero apresentadas
as principais tcnicas utilizadas.
Entrevistas
Refere-se a uma srie de encontros com os clientes ou usurios 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 so
estendidas equipe de desenvolvimento. Os 4 passos de uma entrevista so:
[2] Conduo da Entrevista:

DDPirmide: Comea com questes fechadas e expande para questes abertas dirigidas. uma
56
abordagem importante quando o entrevistado

parece relutante em falar do assunto.
DDFunil: Comea obtendo detalhes e d continuidade obtendo respostas diretas. Muitas questes fechadas e sequenciais tornam-se desnecessrias.
DDDiamante: Combina as duas abordagens anteriores. A entrevista fica menos cansativa, pois
varia o tipo de questo. Na entrevista no deve-se induzir respostas, como O relatrio deveria ser gerado semanalmente?
Questionrios
uma forma rpida de se obter dados de uma
grande quantidade de usurios que podem estar em
lugares geograficamente distintos. Os tipos de dados
que podem ser coletados atravs de questionrios
so:
DDDados sobre a utilizao do sistema atual
DD Problemas e dificuldades que os usurios enfrentam em seu trabalho
DDExpectativa dos usurios em relao ao novo
sistema
[3] Finalizao da Entrevista:

Deve-se reservar um tempo, o menor possvel, que seja adequado para sumarizar as informaes recebidas. O analista deve explicar
os prximos passos ao cliente e apresentar a
importncia da entrevista, agradecendo o entrevistado.
As questes devem ser claras e objetivas. Deve-se

preparar mais de uma questo para um tpico a fim
de confirmar a resposta e deix-la mais completa.
Os tipos de questes que compem os questionrios so:
Abertas-dirigidas: Antecipam o tipo de
resposta. Devem ser utilizadas quando no
possvel ou no deve-se criar alternativas. Por
exemplo: Por que voc acha que os manuais
do usurio do sistema financeiro no funcionam?
Fechadas: Utilizadas quando possvel listar as possveis alternativas. Por exemplo: Os
dados sobre vendas so entregues com que
frequncia? Alternativas: diariamente, semanalmente, quinzenalmente, mensalmente, trimestralmente.
[4] Anlise de Resultados:

Deve-se produzir um documento da entrevista e descobrir ambiguidades, conflitos e omisses. As informaes devem ser consolidadas
e documentadas.
Mas a tcnica de entrevista apresenta diversos
problemas:
Observao: pessoas diferentes se concentram em diferentes aspectos e podem
ver coisas diferentes.
Interpretao: o entrevistador e o entrevistado podem estar interpretando palavras comuns de maneira diferente, tais
como pequena quantidade de dados ou
caracteres especiais.
Ambiguidades: h ambigidades inerentes maioria das formas de comunicao, especialmente em linguagem natural.
Conflitos: entrevistador e entrevistado
podem ter opinies conflitantes sobre um
determinado problema e a tendncia
registrar o ponto de vista do entrevistador.
Na elaborao do questionrio, os seguintes cuidados devem ser tomados:

DDQuestes mais importantes devem vir primeiro.
DDQuestes com contedo semelhante e relacionadas devem estar prximas.
DDQuestes que podem gerar controvrsias devem ser deixadas para depois.
Brainstorming
uma tcnica bsica para gerao de ideias. Devem ser realizadas uma ou vrias reunies que per-
57
mitam que as pessoas sugiram e explorem ideias sem

que sejam criticadas ou julgadas. Deve existir um lder responsvel por conduzir a reunio sem restringi-la. especialmente til no comeo do processo de
extrao de requisitos. Mas apresenta uma desvantagem, j que no uma tcnica no muito estruturada, pode no produzir a mesma qualidade ou nvel
de detalhe que se consegue com outras tcnicas. O
brainstorming (ou tempestade cerebral) basicamente
dividido em duas etapas:
JAD - Joint Application Development

Tcnica utilizada para promover a cooperao, o
entendimento e o trabalho em grupo entre usurios
e desenvolvedores. baseada em quatro princpios:
1. Dinmica em grupo: utilizao de sesses de
grupo (encontros de usurios e desenvolvedores).
2. Uso de tcnicas visuais: utilizao de data-show, projetor, vdeos, etc.
3. Manuteno do processo organizado e racional: controle da sesso atravs de um lder que
tem o objetivo final de identificar um conjunto
preliminar de requisitos.
4. Utilizao de documentao padro: criao de
um documento com os requisitos identificados.
[1] Gerao das ideias:

So as reunies que tem como objetivo fornecer ideias, sem discusses sobre o mrito
delas. Existem 4 regras:
DD proibido criticar ideias.
DDIdeias no convencionais ou estranhas
so encorajadas.
DDNmero de ideias geradas deve ser bem
grande.
DDOs participantes devem ser encorajados
a enriquecer as ideias dos outros participantes.
Geralmente existem seis papis (responsabilidades) divididas entre a equipe de desenvolvimento e

usurios, que so: lder da sesso, engenheiro de
requisitos, executor, representantes dos usurios,
representantes de produtos de software e especialistas.
5W1H
A tcnica 5W1H mundialmente difundida e utilizada em diversos tipos de situaes, sendo muito
til na coleta de requisitos. Vamos ver o que so os
5 Ws e o nico H, assim como algumas perguntas
comumente aplicadas nestas fases.
[2] Consolidao das ideias:

As ideias geradas so discutidas, revisadas, organizadas, avaliadas, consolidadas, descartadas e priorizadas.
58
How (Como) refere-se aos mtodos

DDComo planejado o processo?
DDComo executado?
DDComo avaliado?
DDComo as informaes so registradas e
disseminadas?
DDComo avaliada a satisfao do cliente?
DDComo so as medidas especficas associadas ao sistema, caso existam?
Who (Quem) refere-se s responsabilidades

DD Quem o cliente / usurio do sistema?
DD Quem executa?
DDQuem gerencia?
DDQuem fornece?
DDQuem participa das decises?
What (O Que) refere-se s etapas
DDQuais so as entradas do sistema?
DDQuais so as sadas?
DDQuais so os indicadores?
DDQuais so as metas?
DDQuais so os recursos?
DDQuais so os problemas?
DDQuais so os mtodos / tecnologias empregados?
DDQue informaes ou insumos so necessrios para o trabalho? Quem as fornecem?
DD Quais so as regras que determinam
como o trabalho ser feito?
DDH alguma coisa que possa parar, atrasar
ou impedir o processo?
DDH espera para completar o processo?
DDQuais so as excees?
DD Quais so as alternativas, caso o sistema
no funcione conforme as expectativas?
DDQual ao tomada quando uma etapa
falha?
When (Quando) refere-se ao tempo
DDQuando planejado o processo?
DDQuando executado?
DDQuando avaliado?
DDQuanto tempo leva o processo?
DDCom que frequncia a atividade executada?
Where (Onde) refere-se aos locais
DDOnde planejado o processo?
DDOnde executado?
DDOnde avaliado?
Why (Porque) refere-se s justificativas
DDPorque / para que esse processo existe?
DDQuais so os fatores que determinam
quando um produto aceitvel?
PIECES - Performance, Informao, Economia,

Controle, Eficincia, Servios
Quando o desenvolvedor inexperiente apresenta
dificuldades em determinar como comear e o que
perguntar para extrair os requisitos do cliente,
interessante utilizar a tcnica PIECES, pois ela ajuda a resolver esse problema. A tcnica fornece um
conjunto de categorias de problemas que ajudam o
engenheiro de requisitos a estruturar o processo de
extrao de requisitos. Em cada categoria existem
vrias questes que o desenvolvedor deve explorar
com os usurios. Pode ser adaptada para domnios
de aplicao especficos.
As seis categorias de questes so:
1) Performance: reflete o que usurio espera
2) Informao (e dados): refere-se ao tipo de
acesso s informaes: relatrios, funes on-line; inclui a quantidade de informao oferecida pelo software: na medida certa, no tempo
propcio e em forma utilizvel
3) Economia: relaciona-se ao custo de usar um
produto de software: processadores, armazenagem, conexes de rede, etc
4) Controle: inclui as restries de acesso ao sistema, acesso a algumas informaes e habilidade de monitorar o comportamento do sistema
5) Eficincia: procura evitar coletar o mesmo
dado mais de uma vez e armazen-lo em espaos mltiplos
6) Servios: refere-se a que tipo de servios os
usurios necessitam que o software realize
59
Prototipao
Na gerao do documento preliminar dos requisitos

extrados em qualquer tcnica, pode-se utilizar Modelo
Tcnica que tem como objetivo extrair, entender

e validar os requisitos. baseada no conceito do
processo de desenvolvimento de software de prototipao, j estudado anteriormente. Um prottipo do
produto pode ser construdo. Atravs do prottipo,
os usurios podem descobrir quais so as suas reais
necessidades. benfica somente se prottipo puder
ser construdo de forma mais rpida que o sistema
real. especialmente til para superar dificuldades
de comunicao de necessidades por parte dos usurios.
de Caso de Uso da UML para se ter uma ideia geral

do escopo do produto de software. Geralmente esse
no o modelo final, mas serve como subsdio para a
prxima etapa da Engenharia de Requisitos referente
anlise e negociao de requisitos.
Coleo de artigos sobre Engenharia de Requisitos

http://analiserequisitos.blogspot.com/
Consideraes sobre as Tcnicas de Coleta de

Requisitos
Estudo de caso na rea mdica:

h t t p : / / w w w. s c i e l o. b r / s c i e l o. p h p ? p i d = S 0 1 0 3 -
Caro aluno, as tcnicas apresentadas visam superar as dificuldades inerentes ao processo de extrao dos requisitos. Nenhuma tcnica suficiente
por si s. Voc, como desenvolvedor, deve escolher
um conjunto de tcnicas que melhor se adaptem ao
produto a ser desenvolvido. Mas podemos elencar alguns procedimentos gerais que podem fazer parte de
qualquer processo de extrao de requisitos e ajud-lo neste processo:
DD Voc deve perguntar e identificar as pessoas
apropriadas para responder quais so os requisitos
DDVoc deve observar o comportamento dos usurios de um produto existente e inferir suas necessidades a partir de seu comportamento
DDVoc deve discutir com os usurios suas necessidades e junto com eles formular um entendimento comum dos requisitos
DD importante voc negociar com os usurios,
a partir de um conjunto-padro de requisitos,
quais sero includos, excludos ou modificados
DDVoc deve estudar e identificar os problemas,
isso ajuda a identificar os requisitos que podem
melhorar o produto
-17592009000400014&script=sci_arttext
Manual em Portugus sobre Certificao PMI em Gerenciamento de Projetos PMBok:
http://www.pmi.org/~/media/PDF/Certifications/PT_
PMP_Handbook_Full_Portuguese.ashx
60

1) Stakeholder qualquer pessoa que v comprar o software em desenvolvimento.
a) Verdadeiro
b) Falso
2) relativamente comum para diferentes usurios propor requisitos conflitantes, cada
qual argumentando que sua verso a mais adequada ou melhor.
a) Verdadeiro
b) Falso
3) Na validao de requisitos, o modelo de requisitos revisto para assegurar sua viabilidade tcnica.
a) Verdadeiro
b) Falso
4) Faa a associao e assinale a resposta correta sobre a tcnica PIECES:
i-Performance ii-Informao iii-Economia iv-Controle v-Eficincia vi-Servios
A- relaciona-se ao custo de usar um produto de software: processadores, armazenagem, conexes de rede, etc
B- inclui as restries de acesso ao sistema, acesso a algumas informaes e habilidade de monitorar o comportamento do sistema
C- reflete o que usurio espera
D- refere-se a que tipo de servios os usurios necessitam que o software realize
E- refere-se ao tipo de acesso s informaes: relatrios, funes on-line; inclui a quantidade de
informao oferecida pelo software: na medida certa, no tempo propcio e em forma utilizvel
F- procura evitar coletar o mesmo dado mais de uma vez e armazen-lo em espaos mltiplos
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
5) Qual o principal objetivo da Engenharia de Requisitos?
6) Qual a definio de requisitos segundo o IEEE?
7) Defina Requisitos Funcionais e Requisitos No-Funcionais.

8) O que se entende por stakeholder?
61
9) Quais os benefcios que se espera de um documento de especificao de requisitos?

10) Um dos principais pontos a se considerar em qualquer projeto o chamado estudo de
viabilidade. Para projetos de software no diferente. Relacione as principais questes que se deve considerar no estudo de viabilidade de um projeto de software.
11) Cite algumas tcnicas de levantamento de requisitos estudadas na disciplina.
62
Consideraes Finais
Caro aluno, essa disciplina introduziu muitos aspectos essenciais para a prtica 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 contri um sistema. Os modelos tambm mostram a cada membro da equipe quais
atividades ocorrem, quando e por quem elas so realizadas, de modo a tornar clara a diviso de tarefas.
Vimos que os requisitos podem ser modificados at mesmo enquanto analisamos o problema e desenvolvemos a soluo. E que a soluo deve estar bem documentada e ser flexvel, devendo-se documentar as
suposies e os algoritmos utilizados, de tal modo que seja fcil 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 anlise de
requisitos, projeto, implementao, teste, gerncia de configurao, garantia da qualidade, dentre outras
atividades. Voc e outras pessoas de sua equipe podem desempenhar vrios papis, e o sucesso do projeto
depende em larga escala da comunicao e coordenao entre os membros da equipe.
Vimos tambm que voc pode ajudar no sucesso de seu projeto, selecionando um processo de desenvolvimento apropriado ao tamanho da equipe, ao nvel de risco do projeto e ao domnio do aplicativo, bem
como utilizando ferramentas bem integradas que apiem o tipo de comunicao necessria ao seu projeto.
No andamento do nosso curso, vrios aspectos fundamentais estudados nesta disciplina sero abordados
em maiores detalhes, proporcionando a voc, caro aluno, um entendimento e um conhecimento maior dos
conceitos, mtodos, tcnicas e ferramentas da Engenharia de Software que auxiliam na obteno de um
produto de qualidade, respeitando os prazos, custos e escopo estabelecidos.
Prof. Marcelo Pintaud e Profa. Elisamara
63
Respostas Comentadas dos Exerccios

Captulo 1
1) Qual das questes abaixo no mais uma das grandes preocupaes de um engenheiro
de software?
d) Por que hardware to 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 invs de se desgastar porque:
c) Mudanas frequentes aumentam a probabilidade de introduzir erros no software
4) Atividades guarda-chuva de engenharia de software so 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 dcada de 1960. A complexidade dos problemas, a ausncia de tcnicas bem estabelecidas e a crescente demanda por novas aplicaes comeavam a se tornar um problema srio. Essa crise
teve como origem a introduo de computadores mais poderosos. Mas a caracterizao 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 aqum do esperado.
6) Conforme vimos, Engenharia de Software uma disciplina da Engenharia que se ocupa
de todos os aspectos da produo de software. Seu principal objetivo fornecer uma estrutura
metodolgica para a construo de software com alta qualidade. O que necessrio para que
isso acontea?
DDaplicar teorias, mtodos e ferramentas nas situaes apropriadas nas diversas etapas do desenvolvimento
DDtrabalhar de acordo com as restries organizacionais e financeiras procurando solues que estejam
dentro dessas restries
DDgerenciar os projetos de software para que o resultado final esteja dentro do escopo, custo e prazos
planejados
DD adotar uma abordagem sistemtica e organizada (maneira mais eficaz de produzir software de alta
qualidade)
7) Normalmente, para o leigo, software se constitui no cdigo fonte + cdigo executvel.
Vimos que para a Engenharia de Software, o conceito de software algo mais abrangente.
Como Pressman conceitua software?
64
Instrues (programas de computador) que, quando executadas, produzem a funo e o desempenho

desejados; (2) Estruturas de dados que possibilitam que os programas manipulem adequadamente a informao; (3) Documentos que descrevem a operao e o uso dos programas.
8) O processo de desenvolvimento do software apresenta diferenas fundamentais em relao ao hardware. Cite algumas dessas diferenas.
DDO processo criativo do hardware gera algo fsico (por exemplo, placas de circuitos). O desenvolvimento
de software resulta em um elemento pertencente a um sistema lgico, intangvel;
DDO software geralmente desenvolvido sob medida, ao contrrio do hardware, no qual o projetista tem
acesso a componentes existentes que executam tarefas definidas.
DDO projetista do software nem sempre ter acesso a mdulos prontos para utilizao e quando o faz,
pode elevar o risco do produto devido a questes de segurana;
DDOs custos do software esto concentrados no desenvolvimento e no no processo de manufatura. Isto
significa que no pode ser gerido como projeto de manufatura;
DDAo longo do tempo, o produto de software no se desgasta, mas se deteriora em funo da introduo
de erros oriundos de atividades de manuteno ou evolues implcitas no processo que devem ser
reconsideradas no modelo original.
9) Faa um esboo das curvas de taxa de falhas do hardware e do software. Explique as diferenas entre as curvas.
Hardware:
Software:
Diferenas: no caso do hardware, h um alto ndice de falhas no incio do seu ciclo de vida originadas de
defeitos de fabricao e projeto; depois os defeitos so corrigidos dando estabilidade nas falhas; no final do
ciclo de vida do produto podem surgir problemas relacionados ao desgaste do uso. Diferentemente da curva
terica de falhas do hardware, o software no sofre processos de envelhecimento como o hardware, pois
o software no algo fsico. No incio do ciclo de vida do software, h problemas que sero ajustados no
decorrer do desenvolvimento e se estabilizaro gerando uma tendncia de achatamento da curva; durante o
processo de refinamento do produto ou mudanas aumenta-se a probabilidade de insero de novos erros,
gerando picos na curva de falhas; as sucessivas alteraes do software tendem a introduzir mais erros antes
da estabilizao dos erros de alteraes anteriores, ocasionando a tendncia crescente do ndice de falhas.
65
Captulo 2
1) Processos de software podem ser construdos de modelos pr-existentes objetivando se
adequar s necessidades de um determinado projeto
a) Verdadeiro
2) A essncia da prtica da engenharia de software pode ser resumida em compreender o
problema, planejar a soluo, executar o plano e examinar o resultado.
a) Verdadeiro
3) Qual dos itens listados abaixo no se constitui numa das camadas da engenharia de software?
b) Manufatura
4) Cite que tipos de manuteno um software pode sofrer.
DDManuteno Corretiva: modifica o software para corrigir defeitos
DDManuteno Adaptativa: modifica o software para
acomodar mudanas no seu ambiente externo
(processador, sistema operacional, etc)
DDManuteno de Aperfeioamento: aprimora o software alm dos requisitos funcionais originais (cliente/
usurio reconhece e solicita funcionalidades adicionais que traro benefcios, medida que o software
usado).
DDManuteno Preventiva: faz modificaes nos programas de modo que eles possam ser mais facilmente
corrigidos, adaptados e melhorados.
5) As atividades guarda-chuva do cobertura para as fases envolvidas na produo de
software. Cite algumas dessas atividades.
DDControle e Rastreamento do Projeto
DDGesto de Riscos
DDRevises Tcnicas Formais
DDGarantia de Qualidade
DDGesto de Configurao de Software
DDProduo e Preparao de Produtos do Trabalho (documentos)
DDGesto de Reusabilidade
DDMedio
6) H uma iluso 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 existncia ou a simples escolha de um processo de software no garante que o software ser entregue
no prazo, que ele atenda as necessidades do projeto e possua as caractersticas tcnicas que garantiro sua
qualidade no longo prazo. Os padres de processo precisam estar ligados de forma slida s prticas da
Engenharia de Software. Alm disso, o processo em si deve ser avaliado para garantir que ele satisfaa a um
conjunto de critrios essenciais para o desenvolvimento bem sucedido.
66
Captulo 3
1) Em relao ao modelo Em Cascata podemos afirmar que :
2) Quais so as 5 atividades gerais da Engenharia de Software, tambm caracterizadas no
modelo Em Cascata?
c) Especificao, planejamento, modelagem, construo, implantao (entrega)
3) Podemos dizer que o modelo incremental :
b) Uma boa abordagem quando um produto de trabalho ncleo requerido rapidamente
4) Podemos afirmar que modelos de processo evolucionrios:
d) Todas as alternativas anteriores esto corretas
5) O modelo de prototipagem :
c) Uma abordagem razovel quando o cliente no consegue definir os requisitos claramente
6) O modelo espiral de desenvolvimento de software:
c) Inclui avaliao de riscos a cada iterao
7) O modelo de desenvolvimento concorrente:
e) Somente a e b so verdadeiras
8) Podemos dizer que o modelo de desenvolvimento baseado em componentes:
c) Depende da tecnologia de objetos como suporte
9) O modelo de mtodos formais faz uso de mtodos matemticos para:
d) Todas as alternativas anteriores so corretas
10) Qual dos nomes abaixo no representa uma das fases do modelo de processo unificado?
b) Fase de validao
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 concepo at
a descontinuidade de seu uso.
12) Qual a diferena 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 recomendao que pode ser
adaptada ou melhorada pela empresa/equipe de software que for adot-la.
13) O que caracteriza os modelos evolucionrios de processo?
67
So modelos que consideram a natureza evolutiva do software. Os modelos evolucionrios so iterativos.

So implementados de forma a permitir o desenvolvimento de verses cada vez mais completas do software.
Suas caractersticas incluem:
DDSo usados quando o deadline (limite de tempo) no adequado para o desenvolvimento do software,
ou seja, a data de trmino no realstica (por exemplo, prazos reduzidos de mercado face competitividade).
DDUma verso limitada pode ser introduzida para atender a essa competitividade e s presses do negcio.
DDSo liberados produtos core (ncleo dos produtos) ao longo do desenvolvimento.
DDOs detalhes e extenses do projeto so definidos ao longo do desenvolvimento.
14) Em que situaes os modelos incrementais so mais indicados?
Em situaes em que os requisitos iniciais do software esto 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 usurios e depois refinar, melhorar e expandir aquela funcionalidade em verses mais
avanadas do software. Nestes casos, os modelos de processo que produzem software em incrementos so
os mais indicados.
15) Cite uma das principais diferenas 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 so as duas dimenses do Processo Unificado.
- Estrutura dinmica - representa a dimenso do tempo no processo.
- Estrutura esttica - descreve como elementos do processo so agrupados em disciplinas.
17) Quais so as fases e as disciplinas do Processo Unificado?
Fases : Concepo ou Iniciao, Elaborao, Construo, Transio
Disciplinas: Modelagem de Negcios, Requisitos, Anlise e Design, Implementao, Teste, Implantao,
Gerenciamento de Configurao e Mudana, Gerenciamento de Projeto, Ambiente
18) Quais so as principais caractersticas do Processo Unificado?
DD um framework genrico de um processo de desenvolvimento;
DD baseado em componentes;
DDutiliza toda a definio da UML;
DD dirigido pelos use cases, centrado na arquitetura, iterativo e incremental (conceitos-chave).
19) Quais so os princpios das metodologias geis?
DDValorizar indivduos (e a interao entre eles) mais que processos e ferramentas;
DDValorizar o software em funcionamento mais do que documentao abrangente;
DDValorizar a colaborao com o cliente mais do que negociao de contratos;
DDValorizar responder a mudanas mais que seguir um plano.
68
20) Nos modelos de processos geis o nico produto de trabalho gerado o programa de
trabalho.
b) Falso
Captulo 4 Parte 1
a) Aponte as ambiguidades e omisses.
DDO texto est mal formulado.
DD dito duas vezes que o usurio deve apresentar um carto de crdito e um nmero de identificao.
DDTambm dito primeiro que "o carto deve ser apresentado" e posteriormente que "o usurio insira
um carto de crdito". "Apresentar", "inserir", o que se quer dizer com isso?
DDMesma coisa para o nmero de identificao, sendo que no fica claro o que quer se dizer com as palavras "apresentar" e "fornecer".
DD Inicialmente dito que o usurio escolhe seu destino, mas no diz como isso feito. Posteriormente,
dito que o usurio pressiona o boto iniciar e uma tela de menu apresentada com possveis destinos.
DDUm usurio pode comprar vrias passagens para o mesmo destino ao mesmo tempo ou deve comprar
uma de cada vez?
DDUm usurio pode cancelar uma compra?
DDO sistema acusar caso um carto invlido seja inserido?
b) Descreva os requisitos funcionais.
DDO sistema emitir passagens de nibus
DDO usurio poder escolher seu destino atravs de um menu
DDO sistema incluir o preo da passagem no carto de crdito do usurio
c) Descreva os requisitos no-funcionais (e de interface).
DDDever haver um boto para iniciar
DDUma mensagem deve ser apresentada solicitando que o usurio selecione o destino
DDUma mensagem ser apresentada solicitando que o usurio insira o carto de crdito
d) Identifique os stakeholders.
DDUsurios
DDDesenvolvedores
DDoutros stakeholders podem ser supostos, mas no esto identificados no texto
Captulo 4 Parte 2
1) Stakeholder qualquer pessoa que v comprar o software em desenvolvimento.
a) Falso
69
2) relativamente comum para diferentes usurios propor requisitos conflitantes, cada qual
argumentando que sua verso a mais adequada ou melhor.
a) Verdadeiro
3) Na validao de requisitos, o modelo de requisitos revisto para assegurar sua viabilidade
tcnica.
b) Falso
4) Faa a associao e assinale a resposta correta sobre a tcnica PIECES:
a) i-C ii-E iii-A iv-Bv-F vi-D
5) Qual o principal objetivo da Engenharia de Requisitos?
O principal objetivo da ER a obteno de uma especificao correta e completa dos requisitos de um
sistema de software.
6) Qual a definio de requisitos segundo o IEEE?
Uma condio ou capacidade que um usurio necessita para resolver um problema ou alcanar um objetivo. Uma condio ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um
padro.
7) Defina Requisitos Funcionais e Requisitos No-Funcionais.
Requisitos Funcionais: So requisitos que descrevem a funcionalidade (funes que o sistema deve realizar) ou os servios que se espera que o sistema faa. Exemplos de requisitos funcionais: cadastro de cliente;
emisso de nota fiscal; consulta ao estoque; gerao de pedido.
Requisitos No-Funcionais: So requisitos que no dizem respeito diretamente funcionalidade do sistema, mas expressam propriedades do sistema e/ou restries sobre os servios ou funes por ele providas.
8) O que se entende por stakeholder?
So as partes interessadas no projeto, ou seja, so pessoas e organizaes envolvidas no projeto ou que
possuem interesses que podem ser afetados pelo projeto, podendo exercer influncia sobre os resultados do
projeto.
9) Quais os benefcios que se espera de um documento de especificao de requisitos?
DDQue estabelea a base de acordo entre os clientes e a empresa fornecedora sobre o que o software
ir fazer;
DDQue reduza o esforo de desenvolvimento;
DDQue fornea uma base para estimativas de custo e prazos;
DDQue fornea uma base para validao e verificao do produto;
DDQue facilite a manuteno 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 no diferente. Relacione as principais questes 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:
DDO sistema contribui para os objetivos gerais da empresa?
70
DDO sistema pode ser implementado com a utilizao de tecnologia atual dentro das restries de custo
e prazo?
DDO sistema pode ser integrado com outros sistemas j em operao?
Aps responder essas questes necessrio questionar as fontes de informao (stakeholders). Para isso,
so recomendadas algumas perguntas, como:
DDComo a empresa se comportaria, se esse sistema no fosse implementado?
DDQuais so os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses
problemas?
DDQue contribuio direta o sistema trar para os objetivos da empresa?
DDAs informaes podem ser transferidas para outros sistemas e tambm podem ser recebidas a partir
deles?
DD O sistema requer tecnologia que no tenha sido utilizada anteriormente na empresa?
DDO que precisa e o que no precisa ser compatvel com a empresa?
DDQuem vai usar o sistema?
11) Cite algumas tcnicas de levantamento de requisitos estudadas na disciplina.
Entrevistas, Prototipao, JAD, Brainstorming, PIECES.
71
Glossrio de Siglas
ASD - Adaptive Software Development (Desenvolvimento de Software Adaptativo)
BPM Business Process Modeling (Modelagem de Processos de Negcio)
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 Especificao de Requisitos de Software
DSDM - Dynamic Systems Development Method (Mtodo de Desenvolvimento de Sistemas Dinmico)
FDD- Feature Driven Development (Desenvolvimento Dirigido por Caracterstica)
IDEF0 - Integration Definition for Function Modeling (Definio Integrada para Modelagem de Funo)
IEEE - Institute of Electrical and Electronics Engineers (Instituto de Engenheiros Eletricistas e Eletrnicos)
JAD - Joint Application Development (ou Design)(Desenvolvimento de Aplicaes em Equipe)
PMI - Project Management Institute (Instituto de Gerenciamento de Projetos)
PMBoK Project Management Body of Knowledge. (Conjunto de Melhores Prticas em Gerenciamento de Projetos)
UML Unified Modeling Language (Linguagem de Modelagem Unificada)
RAD Rapid Application Development (Desenvolvimento Rpido de Aplicao).
RiSE - Reuse in Software Engineering (Reuso em Engenharia de Software)
ROM Read Only Memory (Memria Somente de Leitura)
RTF- Reviso Tcnica Formal
XP eXtreme Programming (Programao Extrema)
72
Referncias Bibliogrficas
ANDRADE, Adriana; ROSSETTI, Jos P. Governana Corporativa. So Paulo: Atlas, 2007.
LEITE, Jair C. Ciclo de vida de Software. 2007.

Disponvel em: http://engenhariadesoftware.blogspot.com/2007/02/ciclo-de-vida-do-software-parte-1.
html. Acesso em: 11 nov. 2011.
BLAHA, Michael. Modelagem e projetos baseados em objetos com UML. Rio de Janeiro: Elsevier, 2006.
PAULA FILHO, Wilson P. Engenharia de software: fundamentos, mtodos e padres. 3.ed.

Rio de Janeiro: LTC, 2009.
BOEHM, Barry W. A Spiral Model of Software

Development and Enhancement. Computer, vol.
21, no. 5. May, 1988. p. 61-72.
PETERS, J. F.; PEDRYC, W. Engenharia de software: teoria e prtica. Rio de Janeiro: Campus,
2001.
BOOCH, G., RUMBAUGH, J., JACOBSON, I. UML

guia do usurio. Rio de Janeiro: Editora Campus,
2006.
PMI - Project Management Institute. Um guia

do Conjunto de Melhores Prticas em gerenciamento de Projetos (Guia PMBOK) Quarta
Edio. Atlanta: PMI Book Service Center, 2008.
BLOOGS, Wendy. Mastering UML com Rational

Rose 2002: A Bblia. Rio de Janeiro: Alta Books,
2002.
PMI- Project Management Institute. PMBOK

Guia do Conjunto de Conhecimentos. 2010.
CRUZ, Mrcia; GONSALES, Samuel. 2010. Disponvel em http://blogbohm.com/2010/10/18/analise-de-requisitos-como-ferramenta-de-planejamento/.

Acesso em 03 dez. 2011.
PRESSMAN, R. S. Engenharia de Software.

7.ed. So Paulo: McGraw-Hill, 2010.
FONSECA, Ijar M. Princpios Fundamentais

da Anlise de Requisitos. Disponvel em: http://
www2.dem.inpe.br/ijar/AnalEstr.html. Acesso em 01
dez. 2011.
PRESSMAN, R. S. Engenharia de Software.

6.ed. So Paulo: McGraw-Hill, 2006.
RUMBAUGH, James; et al. Modelagem e Projeto baseados em objetos. Rio de Janeiro: Campus,
2006.
GASTALDO, Denise L.; MIDORIKAWA, Edson T.

Processo de Engenharia de Requisitos Aplicado a Requisitos No-Funcionais de Desempenho Um Estudo de Caso. 2002.
Disponvel em: http://wer.inf.puc-rio.br/wer03/artigos/denise_gastaldo.pdf. Acesso em 30 nov. 2011.
SCHACH, Stephen. Engenharia de Software:

os paradigmas clssico e orientado a objetos.
So Paulo: McGrawHill, 2008.
SHORE, James; WARDEN, Shane. A Arte do
Desenvolvimento gil. Porto Alegre: Alta Books,
2008.
HERITAGE. Dicionrio web. Disponvel em: http://

www.thefreedictionary.com/information+technology.
Acesso em: 13 nov. 2011.
73
SOMMERVILLE, Ian. Engenharia de Software.

So Paulo: Addison-Wesley, 2007.
THE STANDISH GROUP. The Standish Group Report Chaos. 1995. Disponvel em: http://www.projectsmart.co.uk/docs/chaos-report.pdf. Acesso em
02 nov. 2011.
74

Engenharia Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia Software

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Softwares e Engenharia de Requisitos

Engenharia de Softwares e Engenharia de Requisitos

Software e Engenharia de Software

Antecedentes Histricos da Engenharia de Software

Definies e Conceitos de Software e Engenharia de Software

Conceitos Bsicos de Processo de Software

Padres, Avaliao e Tecnologias de Processo

Ciclo de Vida e Modelos de Processo

Modelos Prescritivos de Processo

Modelos Evolucionrios de Processo

Modelo de Desenvolvimento Concorrente

Modelos Incrementais de Processo

Desenvolvimento Baseado em Componentes

Modelo de Mtodos Formais

Requisitos e Engenharia de Requisitos

Objetivos e Classificao dos Requisitos

Tarefas da Engenharia de Requisitos

Exerccios do Captulo 4 - Parte 1

Tcnicas de Coleta de Requisitos

Consideraes sobre as Tcnicas de Coleta de Requisitos

Exerccios do Captulo 4 - Parte 2

Respostas Comentadas dos Exerccios

Engenharia de Softwares e Engenharia de Requisitos

Engenharia de Softwares e Engenharia de Requisitos

Qual a necessidade de uma disciplina de Engenharia para o desenvolvimento de software?

Engenharia de Softwares e Engenharia de Requisitos

Software e Engenharia de Software

software e buscar maneiras de dar um tratamento de

Um sistema de software complexo caracterizado

A denominao da Engenharia de Software surgiu em 1968, em uma conferncia organizada para

Engenharia de Softwares e Engenharia de Requisitos

Engenharia de Softwares e Engenharia de Requisitos

Observando estes nmeros, fica claro que de 1960

ficao do sistema at a manuteno desse sistema,

Grady Booch, um dos criadores da UML Unified

Engenharia de Softwares e Engenharia de Requisitos

As normas de gesto de qualidade e garantia da

Software: Criao intelectual compreendendo

Software (palavra inglesa, de soft, mole + ware,

Software uma sequncia de instrues a serem

Como podemos observar, o conjunto de conceitos

namento ou modificao de um dado/informao ou

Software considerado um bem de capital. (Wikipedia, http://pt.wikipedia.org/wiki/Software, 2011)

Pressman (2010) conceitua o software como:

Engenharia de Softwares e Engenharia de Requisitos

Comparar o software com produtos de hardware

Figura 1 - Curva de falhas do hardware

Figura 2 - Curva de falhas do software

Engenharia de Softwares e Engenharia de Requisitos

Isso nos remete a uma realidade bastante complicada

A importncia do software na nossa sociedade

Engenharia de Softwares e Engenharia de Requisitos

desenvolvido. E, como vimos, questes como estas

Assim, caro aluno, o desenvolvimento de software

Exemplos de reas de aplicaes de software so:

Software de tempo real: monitora, analisa

Engenharia de Softwares e Engenharia de Requisitos

voos, sistemas de pagamento, de controle de

dados e diversas caractersticas que fazem as

Software para computadores pessoais:

Software embutido: produtos inteligentes.

Engenharia de Softwares e Engenharia de Requisitos

- O manual existe. Mas usado?

Muitas crenas ou mitos foram criados acerca de