Livro-Processos de Software

99576-CAPA_UNIASSELVI_978-85-68075-89-0.
pdf - PG-1 - 04:47:50 - August 22, 2014
UNIASSELVI
Processos
de software
PROCESSOS DE SOFTWARE
ISBN 978-85-68075-89-0
C M Y K CL ML LB LLB
99576-CAPA_UNOPAR_978-85-68075-89-0.pdf - PG-1 - 04:56:04 - August 22, 2014
UNOPAR
Processos
de software
PROCESSOS DE SOFTWARE
ISBN 978-85-68075-89-0
C M Y K CL ML LB LLB
99576-MIOLO_978-85-68075-89-0.pdf, page 61 @ Preflight - 04:40:43 - August 22, 2014 - PG-1
Processos
de software
Processos
de software
Polyanna Pacheco Gomes Fabris

Luis Cludio Perini
2014 by Editora e Distribuidora Educacional S.A.
Todos os direitos reservados. Nenhuma parte desta publicao poder ser reproduzida
ou transmitida de qualquer modo ou por qualquer outro meio, eletrnico ou mecnico,
incluindo fotocpia, gravao ou qualquer outro tipo de sistema de armazenamento e
transmisso de informao, sem prvia autorizao, por escrito, da Editora
e Distribuidora Educacional S.A.
Diretor editorial e de contedo: Roger Trimer

Gerente de produo editorial: Kelly Tavares
Supervisora de produo editorial: Silvana Afonso
Coordenador de produo editorial: Srgio Nascimento
Editor: Casa de Ideias
Editor assistente: Marcos Guimares
Reviso: Luciane Gomide e Marina Sousa
Capa: Katia Megumi Higashi, Fernanda Caroline de Queiroz Costa
e Mariana Batista de Souza
Diagramao: Casa de Ideias
Dados Internacionais de Catalogao na Publicao (CIP)
Fabris, Polyanna Pacheco Gomes

F128p Processos de software / Polyanna Pacheco Gomes
Fabris, Luis Cludio Perini. Londrina: Editora e
Distribuidora Educacional S.A., 2014.
192 p.
ISBN 978-85-68075-89-0
1. Engenharia. 2. Negocio. 3. Gerenciamento. I. Perini ,

Luis Cludio. II. Ttulo.
CDD 005
Sumrio
Unidade 1 Processos de negcio................................1

Seo 1 Viso geral sobre as reas de negcio....................................3
1.1 O que negcio?..................................................................................3
1.2 E processos de negcio?........................................................................3
Seo 2 Noes sobre modelagem de processos de negcio...............6
2.1 Introduo modelagem de processos.................................................6
2.2 O que so os modelos de processo?......................................................7
2.3 Quais so os contedos de um modelo de processo?............................7
2.4 Nveis de representao de processo....................................................7
2.5 Componentes de processo e ferramentas..............................................8
2.6 Arquitetura de processos e arquitetura de negcio................................9
2.7 Notaes de modelagem de processos..................................................9
Seo 3 Introduo modelagem organizacional e ao mtodo
Enterprise Knowledge Development (EKD)..........................31
3.1 Modelos de EKD.................................................................................33
Unidade 2 Engenharia de software ..........................43

Seo 1 Natureza do software e da engenharia de software.............44
1.1 Evoluo do software..........................................................................50
1.2 Software..............................................................................................53
1.3 Engenharia de software.......................................................................57
1.4 Crise do software................................................................................61
1.5 Causas da crise de software................................................................61
1.6 Consequncias da crise de software....................................................62
1.7 Causas dos problemas associados crise de software.........................63
1.8 Mitos relativos ao software..................................................................63
vi P R O C E S S O S D E S O F T WA R E
Seo 2 Modelos de processos de software.......................................67

2.1 Modelos geis.....................................................................................69
2.2 Modelo evolucionrio.........................................................................77
Unidade 3 Engenharia de requisitos e gerenciamento

de projeto de software ...........................93
Seo 1 Requisitos de software.........................................................95
1.1 Requisitos de software........................................................................95
Seo 2 Engenharia de requisitos....................................................108
2.1 Engenharia de requisitos...................................................................108
2.2 Estudos de viabilidade......................................................................109
2.3 Elicitao e anlise de requisitos.......................................................111
2.4 Validao de requisitos.....................................................................117
2.5 Gerenciamento de requisitos............................................................119
Seo 3 Gerenciamento de projetos de software............................123
3.1 Gerenciamento de projetos...............................................................123
3.2 Atividades de gerenciamento............................................................124
3.3 Planejamento de projeto...................................................................125
Unidade 4 Noes sobre modelagem de sistemas..143

Seo 1 Introduo modelagem estruturada de sistemas.............145
1.1 Introduo .......................................................................................145
1.2 Introduo modelagem estruturada de sistemas.............................145
Seo 2 Introduo modelagem orientada a objeto e para web.........149
2.1 Introduo .......................................................................................149
2.2 Introduo modelagem orientada a objeto e para web...................149
Unidade 1
Processos de negcio
Objetivos de aprendizagem: Nesta unidade, voc ser levado a

compreender conceitos importantes sobre as reas de negcio, noes
sobre modelagem de processos de negcio, modelagem organizacional
o mtodo Enterprise Knowledge Development (EKD), bem como seus
principais modelos.
Seo 1: Viso geral sobre as reas de negcio

Caro aluno, nesta seo, vamos apresentar uma viso
geral sobre as reas de negcio, a definio do que
negcio e processos de negcio. E, para reforar o con-
tedo estudado, voc ter atividades de aprendizagem.
Seo 2: Noes sobre modelagem de processos

de negcio
Esta seo apresenta os conceitos presentes na mode-
lagem de processos de negcio e alguns mtodos que
auxiliam nesta atividade. E, para reforar o contedo
estudado, voc ter atividades de aprendizagem.
Seo 3: Introduo modelagem organizacional

e ao mtodo Enterprise Knowledge
Development (EKD)
Caro aluno, nesta seo, abordaremos um contedo
sobre a modelagem organizacional e o mtodo En-
terprise Knowledge Development (EKD), que enfoca
a importncia de uma organizao trabalhar de
forma integrada e no setorizada, ou seja, todos vi-
sando ao crescimento organizacional. E assim como

foi realizado nas sees anteriores teremos, ao final
desta, atividades de aprendizagem para reforar o
contedo estudado.
Processos de negcio 3
Introduo ao estudo
Caro aluno, esta unidade apresentar uma viso geral sobre as reas de negcio,
noes sobre modelagem de processos de negcio e como esses modelos podem
contribuir para o entendimento dos negcios organizacionais, proporcionando um
entendimento comum dentro da organizao, possibilitando medio de possveis
problemas e tambm contribuindo para tomada de decises.
Com base nesses processos definidos, os colaboradores de uma organizao co-
nhecem claramente seus papis, bem como as atividades a serem desenvolvidas. A
execuo e a reviso desses processos que possibilita o crescimento organizacional,
em que a organizao passa a depender de processos, e no de pessoas.
Ainda nesta unidade faremos uma introduo modelagem organizacional e ao
mtodo Enterprise Knowledge Development (EKD) e seus modelos.
Seo 1 Viso geral sobre as reas de negcio

Caro aluno, em meio s frequentes variaes de mercado, as organizaes buscam
solues de integrao dos seus processos para melhorar a interao com seus clientes
internos ou externos e oferecer qualidade aos seus servios prestados, resultando
em padronizao e eficincia na execuo de seus processos de negcio. Esta seo
apresenta uma viso detalhada sobre os processos de negcio.
1.1 O que negcio?

Segundo ABPMP (2013), o termo negcio corresponde interao de pessoas
para executar um conjunto de atividades de entrega de valor para os clientes e gerar
retorno s partes interessadas. Negcio compreende todos os tipos de organizaes
com ou sem fins lucrativos, pblicas ou privadas, de qualquer porte e segmento de
negcio.
1.2 E processos de negcio?

Segundo Moreira (2014), um processo a introduo de insumos de entrada em
um ambiente formado por procedimento, normas e regras, que, ao processarem tais
insumos, resultam em produtos de sada aos clientes do processo. Alm dos insumos
de entrada e os produtos de sada, um processo composto por mais dois elemen-
tos essenciais para sua execuo: os recursos e o controle. Desta forma, pode-se
afirmar que um processo tpico formado por quatro elementos:
Entradas: so materiais ou informaes que contribuiro para que o processo
seja executado.
Sadas: representa o resultado obtido com a execuo do processo, podem ser
produtos ou servios.
4 P R O C E S S O S D E S O F T WA R E
Controle: responsvel pelo monitoramento e verificao do cumprimento dos

mtodos, diretrizes, objetivos, procedimentos e padres na execuo do processo.
Recurso: representa a proviso de elementos que se fazem necessrias para a
execuo do processo, tais como: humanos, materiais, financeiros entre outros.
Portanto, o processo de negcio uma associao de atividades e procedimentos
executados por humanos ou mquinas para entregar valor para clientes ou apoiar/
gerenciar outros processos.
Os processos de negcio podem ser classificados, segundo ABPMP (2013); Ca-
pote (2014):
a) Processos primrios: so os processos que ultrapassam qualquer fronteira
funcional corporativa, representando as atividades essenciais que uma orga-
nizao executa para cumprir sua misso. Suas caractersticas so: entrega
de valor ao cliente, viso ponta a ponta e interfuncional, criao e percepo
de valor, podem percorrer organizaes funcionais, setores, departamentos
ou outras organizaes, e tendem a traduzir a cadeia de valor (agrupamento
corporativo estruturado entre atividades primrias e atividades de suporte).
b) Processos secundrios: so os processos definidos formalmente na organizao
e que visam a dar suporte aos processos primrios. Possuem como caracte-
rsticas a ausncia de relacionamento direto com os clientes, e tambm, o
vnculo viso funcional tradicional, mas processos de suporte tambm podem
ser interfuncionais. Possuem impacto direto na capacidade de realizao e
entrega dos processos primrios.
c) Processos de gesto: so processos estabelecidos formalmente e com o intuito
de coordenar as atividades dos processos de apoio e dos processos prim-
rios. Deve buscar garantir que os processos atinjam suas metas operacionais,
financeiras, regulatrias e legais.
Para saber mais

Nesta seo, foram abordados os conceitos de processos de negcio e as suas possveis classi-
ficaes. E agora, voc sabe descrever o que um processo de negcio? Para mais informaes
acesse: <http://www.abpmp-br.org/>.
P r o c e s s o s d e n e g c i o 5
Atividades de aprendizagem
1. Assinale V para verdadeiro e F para falso.
( ) Entradas representam o resultado obtido com a execuo do processo,
podem ser produtos ou servios.
( ) Sadas so materiais ou informaes que contribuiro para que o
processo seja executado.
( ) Processos secundrios so os processos definidos formalmente na
organizao e que visam dar suporte aos processos primrios.
( ) Processos primrios so os processos que ultrapassam qualquer fron-
teira funcional corporativa, representando as atividades essenciais que
uma organizao executa para cumprir sua misso.
( ) Controle responsvel pelo monitoramento e verificao do cumpri-
mento dos mtodos, diretrizes, objetivos, procedimentos e padres
na execuo do processo e so definidos como sadas.
2. O que processo de negcio e quais so suas classificaes?
Questes para reflexo

Com base no contedo estudado, pense em uma organizao e defina para
ela os quatro elementos tpicos de um processo.
Seo 2 Noes sobre modelagem

de processos de negcio
A modelagem de processos de negcio vista como uma ferramenta fundamen-
tal, a modelagem de processos tornou-se uma das principais estratgias modernas
degesto. Organizaes pequenas, mdias e grandes utilizam esse mecanismo com
resultados cada vez mais satisfatrios (CAMPOS, 2014a).
A modelagem de processos fornece mecanismos para constituir e aperfeioar a
operao e controle das organizaes, e tambm, para viabilizar o atingimento dos
objetivos estratgicos dessas organizaes (CAMPOS, 2014b).
2.1 Introduo modelagem de processos

A modelagem de processos pode ser definida como um conjunto de atividades
envolvidas na criao de representaes de um processo de negcio existente ou
proposto. Ela expressa uma perspectiva ponta a ponta de processos primrios, de
suporte e gerenciamento de uma organizao (MPF, 2014). Requer um conjunto de
habilidades e tcnicas para permitir que os componentes de processos sejam com-
preendidos, comunicados e gerenciados.
O objetivo da modelagem gerar uma representao do processo de maneira
completa e precisa sobre seu funcionamento. Desta forma, o nvel de detalhamento
e o tipo especfico de modelo so baseados no que esperado da iniciativa de mo-
delagem (ABMP, 2013).
A aplicao da modelagem de processos promove a identificao de todas as
reas envolvidas no negcio, de todos os passos necessrios para a execuo de um
processo e documentao utilizada.
Veja, a seguir, alguns dos seus principais objetivos:
Entendimento da estrutura e a dinmica das reas da organizao.
Entendimento dos problemas atuais da organizao e identificar potenciais
melhorias.
Garantir que os usurios e engenheiros de software tenham entendimento
comum da organizao.
Auxlio na identificao de competncias (DEVMEDIA, 2014).
Dentre os motivos para uma organizao modelar seus processos esto (ELOGROUP,
2014):
Documentar claramente um processo existente.
Auxlio nos treinamentos por meio da definio das atribuies
de cada ator presente no processo.
Capacidade de avaliao das normas e cumprimentos das
obrigaes.
Compreenso do comportamento do processo.
Base para anlise na identificao de oportunidades de
melhoria.
Suporte ao design de um novo ou nova abordagem para um

processo existente.
Prover uma base para a comunicao e discusso organizacionais.
Descrio de requisitos para uma nova operao da empresa.
2.2 O que so os modelos de processo?

Um modelo de processo uma representao simplificada de uma coisa, um con-
ceito ou uma atividade que suporta os seus estudos e desenhos. Os modelos podem
ser matemticos, grficos, fsicos ou narrativos na sua forma ou em alguma combi-
nao de elementos. Possuem ampla srie de aplicaes, que incluem: organizao
(estruturao), heurstica (descoberta, aprendizado), previses (predies), medio
(quantificao), explanao (ensino, demonstrao), verificao (experimentao,
validao) e controle (restries, objetivos).
Podem conter um ou mais diagramas, informao sobre objetos no diagrama,
informao sobre relacionamento entre objetos, informao sobre como objetos re-
presentados se comportam ou desempenham. Assim, podem ser expressos por meio
de vrios nveis de detalhe, desde uma viso contextual abstrata at uma viso deta-
lhada, representando diversas perspectivas e propsitos (ABPMP, 2013; MPF, 2014).
2.3 Quais so os contedos de um modelo de processo?

Um modelo de processo possui cones que representam as atividades, os eventos,
as decises, condies e outros elementos. Pode conter ilustraes sobre:
cone (representa os elementos do processo).
Relacionamentos entre os cones.
Relacionamentos entre os cones e ambiente.
Como os cones se comportam ou o que executam (ABPMP, 2013).
2.4 Nveis de representao de processo

Diagrama, mapa e modelo so trs nveis de representao de processos, e
muitas vezes so utilizados de forma intercambivel ou como sinnimos. Contudo,
eles se diferem em nveis de abstrao, informao, utilidade, preciso, complexi-
dade, padronizao de elementos do fluxo, evoluo e amadurecimento do desenho
proposto (ABPMP, 2013; IPROCESS, 2014).
Para saber mais

Vamos ver a diferena entre diagrama, mapa e modelo de processos?
Acesse: <http://blog.iprocess.com.br/2014/02/modelagem-de-processos-de-negocio-diferencas-
-entre-diagrama-mapa-e-modelo-de-processos/> (IPROCESS, 2014).
2.4.1 Resumo da comparao entre diagrama, mapa e modelo

de processo
Para facilitar seu entendimento dos nveis de representao do processo, observe
a Tabela 1.1 a seguir.
Tabela 1.1 Comparao entre nveis de representao de processos
Diagrama ou mapa de processo Modelo de processo

Notao ambgua. Conveno padronizada da notao.
Maior preciso e detalhamento, conforme
Baixa preciso.
necessidade.
Menos detalhado. Mais detalhado.
cones (representao de componentes do pro-
cones definidos e padronizados.
cesso) vagamente definidos e sem padronizao.
Relacionamentos dos cones definidos e explica-
Relacionamentos dos cones retratados. dos em notaes, glossrios do modelo de pro-
cessos e especificao detalhada do processo.
Limitado a uma representao simples ou um
Representa a complexidade adequada.
contexto de alto nvel.
Limitado a retratar um momento especfico da Possibilidade de crescimento, evoluo e
realidade. amadurecimento.
Gerado com ferramentas simples de diagramao. Gerado com ferramenta adequada ao objetivo.
Simples de utilizar, mas no permite a navegao Fornece a possibilidade de uma simulao
em um nvel mais detalhado. manual ou automatizada do processo.
Ligaes verticais e horizontais, mostrando os
Dificuldade de conexo com outros modelos
relacionamentos entre processo e diferentes
existentes.
nveis de processo.
Utiliza estruturas comuns de gerenciamento de
Utiliza repositrio de modelos.
arquivos.
Adequado para certas capturas rpidas de Apropriado para qualquer nvel de captura de
ideias. processos, anlise e desenho.
No adequado para automatizao de pro-
Adequado para automatizao de processos.
cessos.
Fonte: ABPMP (2013).
2.5 Componentes de processo e ferramentas

Os componentes de processo especificam as propriedades, os comportamentos, o
objetivo e outros elementos do processo. Algumas ferramentas de modelagem podem
ser usadas com a finalidade de capturar e catalogar os componentes de processo e
informaes associadas de forma que sejam organizadas, analisadas e o portflio de
processos seja gerenciado.
Dentre os componentes de processo e informaes que os modelos de processo
podem capturar, podemos citar: entradas e sadas, padres de chegada e distribuies,
eventos e resultados, custos, valor agregado, regras de entrada, papis e organizaes,

regras de sada, dados e informao, regras de deciso, regras de juno, enfileira-
mento, tempo de trabalho e manuseio, tempo de transmisso, agrupamento, tempo de
espera e nmero de pessoas com disponibilidade para executar tarefas (ABPMP, 2013).
2.6 Arquitetura de processos e arquitetura de negcio

Durante a modelagem de processo, as pessoas envolvidas podem se questionar
sobre o que diferencia a arquitetura de processos da arquitetura de negcio.
A Tabela 1.2, a seguir, apresenta um comparativo entre essas duas arquiteturas
(ABPMP, 2013).
Tabela 1.2 Arquitetura de processos e arquitetura de negcios
Arquitetura de processos Arquitetura de negcios

Especificao da estrutura geral de um sistema
de processos. Pode ser um conceito aplicvel
a diversos campos tais como informtica,
modelo conceitual e lida com O QUE
gesto de processos de negcio, gesto estra-
no negcio.
tgica etc. (WIKIPDIA, 2014). A arquitetura
de processos lida com o COMO do negcio e
definem com um entregvel.
Relaciona as atividades necessrias e est
Foco nas atividades fsicas e seu gerenciamento.
preocupada com a eficcia.
Fonte: Do autor (2014).
Contudo, podemos afirmar que essas disciplinas se complementam e visam a

entregar melhoria de negcio e ambas podem faz-lo. No so similares e no h
concorrncia entre elas.
2.7 Notaes de modelagem de processos

Segundo o ABPMP (2013), notao pode ser definida como um conjunto padro-
nizado de smbolos e regras que determinam o significado desses smbolos. Existem
muitos padres de notao de modelagem, porm, a escolha de um padro que siga
normas e convenes oferece vantagens, tais como:
Conjunto de smbolos, linguagem e tcnicas comuns, possibilitando um
idioma comum entre os envolvidos.
Consistncia em forma e significado dos modelos de processos.
Possibilidade de importar e exportar os modelos entre ferramentas.
Gerar aplicaes a partir dos modelos.
Dentre as notaes de modelagem de processos usualmente encontrada, podemos

citar BPMN (Business Process Model and Notation), fluxograma, ARIS, UML (Unified
Modeling Language), IDEF (Integrated Definition Language) entre outras.
2.7.1 BPMN (Business Process Model and Notation)

Segundo BPMN (2014) e TUDO SOBRE BPMN (2013), a meta primria da nota-
o BPMN fornecer uma notao que possa ser entendida por todos os usurios
do negcio (analistas de processos/negcios que criam a verso inicial do processo),
desenvolvedores responsveis por implementar a tecnologia que auxiliar os processos
e, finalmente, as pessoas que iro gerenciar e monitorar os processos.
Esta notao cria uma ponte padro para a anlise de aderncia entre o desenho
do processo de negcio e a implementao do processo. Outra meta garantir que
a linguagem XML concebida para a execuo de processos de negcio possa ser
visualizada com uma notao orientada ao negcio.
A inteno do BPMN padronizar a notao para modelagem de processos de
negcio das diferentes notaes de modelagem e pontos de vista, proporcionando
um meio simples de comunicao de informaes a outros utilizadores de negcio,
implementadores de processo, clientes e fornecedores.
A interoperao dos processos de negcio, em um nvel humano, pode ser re-
solvida com a padronizao, e essa notao da modelagem que fornece um dia-
grama o qual desenhado para o uso das pessoas que implementam e gerenciam
os processos de negcio. Tambm fornece um mapeamento para uma linguagem de
execuo para sistemas, resultando na gerao de um mecanismo de visualizao
padro para processos de negcio, definido em uma linguagem de execuo otimi-
zada de processos de negcio.
Essa notao prover s organizaes uma capacidade de compreenso de seus
procedimentos internos do negcio em uma notao grfica e fornecer para as or-
ganizaes a habilidade de comunicar esses procedimentos em um padro uniforme
(BPMN, 2014; TUDO SOBRE BPMN, 2014).
Apoiando os conceitos de modelagem, a notao BPMN exclui de seu escopo
outros tipos de modelagens feitas por organizaes sem o foco no negcio, tais
como: estruturas organizacionais e recursos, modelos de funes de departamentos,
modelos de dados e informaes, modelos de estratgia empresarial, modelos regras
de negcios (ELOGROUP, 2014).
A notao visa a cobrir muitos tipos de modelagem e a permitir a criao de
processos de negcio fim a fim. Existem trs tipos de modelos bsicos para a mode-
lagem BPMN; veja a seguir.
2.7.1.1 Processos de negcio privado (internos)

Especficos de uma organizao e so os tipos de processos que geralmente so
chamados de workflow ou processos BPM (Figura 1.1). Para sua modelagem, sero
usadas raias de executores ou suporte. O fluxo de atividades est contido apenas em
uma nica raia mas, tratando-se de fluxo de informao, permite a travessia entre
raias, de maneira que demonstre as interaes existentes entre processos privados de
negcio diferentes (ELOGROUP, 2014; BPMN, 2014; TUDO SOBRE BPMN, 2014).
Figura 1.1 Exemplo de processo de negcio privado
Fonte: BPMN (2014).
2.7.1.2 Processos abstratos (pblicos)

Representam a interao entre um processo de negcio privado e outro processo
ou participante. Apenas as atividades que so utilizadas para a comunicao externa
ao processo de negcio privado, mais o mecanismo adequado de fluxo de controle,
esto includos nos processos abstratos. Demais processos internos no so apre-
sentados nos processos abstratos. Desta forma, este tipo mostra ao mundo exterior
a sequncia de mensagens que so necessrias na interao com outro processo ou
entidade externa. A Figura 1.2, a seguir, apresenta um exemplo de processo abstrato.
Figura 1.2 Exemplo de processo de negcio abstrato
Fonte: BPMN (2014).
2.7.1.3 Processos de colaborao (global)

Representa as interaes entre duas ou mais entidades que so definidas como
uma sequncia de atividades que mostram a troca de mensagens entre os padres
das entidades envolvidas. Esse modelo pode ser realizado em um ou mais processo,
apontando os locais de comunicao entre eles. Caso seja um nico modelo, cada
raia de executor ou suporte retratar cada um dos participantes. Se for tratar de um
processo privado e que esteja sendo modelado no mesmo diagrama BPMN, a associa-
o das atividades que so compartilhadas por ambos os processos dever ser feita.
Confira na Figura 1.3 um exemplo de processo de colaborao.
Figura 1.3 Exemplo de processo de colaborao
Fonte: BPMN (2014).
Dentro e entre esses trs modelos BPMN, diversos tipos de digramas podem ser
criados. A seguir, listamos os tipos de processos de negcio que podem ser modelos
com o BPMN:
Alto nvel das atividades dos processos privados.
Processos de negcio privado detalhados (AS IS ou processos de negcio antigos
e TO BE ou processos de negcio novos).
Processo de negcios privados detalhados com interaes para um ou mais
entidades externas.
Dois ou mais processos privados detalhados interagindo entre si.
Relao detalhada do processo de negcio privado para o processo abstrato.
Relao detalhada do processo de negcio privado para o processo colaborativo.
Dois ou mais processos abstratos.
Relao do processo abstrato para o processo colaborativo.
Processo colaborativo.
Dois ou mais processos de negcio privado detalhados interagindo por meio
do seu processo abstrato.
do seu processo colaborativo.
do seu processo abstrato e processo colaborativo.
importante ressaltar que a notao BPMN tem como direcionador a criao de

um simples mecanismo para gerar modelos de processo de negcio e que tambm
apto a lidar com a complexidade intrnseca aos processos de negcio. A aborda-

gem usada para tratamento desses dois requisitos conflitantes foi a organizao dos
aspectos grficos em categorias especficas, fornecendo um pequeno conjunto de
categorias para que, ao consultar, possamos reconhecer rapidamente os tipos bsicos
dos elementos e compreender o diagrama.
Na categoria dos elementos bsicos, podem ser adicionadas variaes e infor-
maes complementares para suportar os requisitos de complexidade sem mudar o
visual e sentimentos bsicos do diagrama (ELOGROUP, 2014; BPMN, 2014; TUDO
SOBRE BPMN, 2014).
As categorias bsicas de elementos so:
a) Objetos de fluxo
Representam os principais elementos grficos para definir o comportamento dos
processos de negcio.
A entrada de sequncia de fluxo pode ser vinculada para qualquer local em um
objeto de fluxo (esquerda, direita, em cima ou em baixo). Do mesmo modo ocorre
com uma sada de sequncia de fluxo, que pode ser conectada de qualquer lugar em
um objeto de fluxo (esquerda, direita, em cima ou em baixo).
Para saber mais

Para saber mais sobre os 3 fluxos desta categoria (Evento, Atividade e Gateway):
Aprofunde seus conhecimentos em BPMN acessando os links:

<http://www.cin.ufpe.br/~processos/TAES3/slides-2012.2/Introducao_BPMN.pdf>;
<http://www.omg.org/spec/BPMN/2.0/PDF>;
<http://www.tudosobrebpm.com.br/p/bpmn-business-process-modeling-notation.html>;
<www.teclogica.com.br/web/consultoria/bpm/vantagens>;
<http://planningit.wordpress.com/2012/10/24/bpmn-tecnicas-de-modelagem>;
<http://www.informazione4.com.br/cms/opencms/desafio21/artigos/gestao/organizando
/0017.html>.
b) Dados
Os dados so representados pelos seguintes elementos:
Objetos de dados.
Entrada de dados.
Sada de dados.
Armazenamento de dados.
Na Tabela 1.3 a seguir, visualize os elementos da categoria dados (ELOGROUP,

2014; BPMN, 2014; TUDO SOBRE BPMN, 2014).
Tabela 1.3 Dados
Objetos de dados Tipos de dados
Representao singular de dados
Representao de uma coleo

de dados
Dados de Entrada
Os objetos de dados no tm nenhum efeito

direto no fluxo de sequncia ou no fluxo de Dados de Entrada
mensagem do processo, mas fornecem a in-
formao sobre o que as atividades requisitam
para serem executadas e/ou o que geram.
Armazenamento de dados
Mensagem
Fonte: BPMN (2014).
c) Objetos de conexo
Para conectar os fluxos dos objetos entre si ou a outra informao, existem trs
objetos de conexo:
Fluxo de sequncia.
Fluxo de mensagem.
Associao.
A seguir, temos a Tabela 1.4 contendo mais detalhes sobre esses objetos
(ELOGROUP, 2014; BPMN, 2014; TUDO SOBRE BPMN, 2014).
Tabela 1.4 Objetos de conexo
Fluxo de sequncia Tipos de fluxo de sequncia (descrio e exemplos)
O fluxo de sequncia normal refere-se ao fluxo ori-

Fluxos de sequncia so utilizados para ginado pelo evento de incio e continua nas ativida-
mostrar a ordem em aque as atividades des seguintes via caminhos alternativos e paralelos
devem ser executadas em um processo. at o seu trmino no evento fim.
Um fluxo descontrolado representa um fluxo que

no afetado por nenhuma condio ou no passa
em nenhum gateway. Como exemplo, citamos um
nico fluxo de sequncia conectando duas ativida-
des.
O fluxo condicional pode ter expresses de condi-

o que so avaliados em tempo para determinar se
o fluxo ser ou no utilizado.
Para as decises exclusivas ou decises inclusivas

ser utilizado este tipo de fluxo. Ser utilizado so-
mente se todos os fluxos condicionais de sada no
forem verdadeiros no tempo de execuo.
continua
continuao
Fluxo de Mensagem
Um fluxo de mensagem usado para mostrar mensagens entre entidades que so preparadas
para emiti-las e receb-las. Em BPMN, duas piscinas separadas no diagrama representam as
duas entidadades.
Associao (e exemplo)
Uma associao usada como link de informao e artefatos com outros elementos grficos
BPMN. Anotaes de texto e artefatos podem ser associados com outros elementos grficos.
Uma associao tipo seta indica uma direo de fluxo ou, tambm, um artefato.
Fonte: BPMN (2014).
A Figura 1.4 a seguir demonstra quando os elementos podem ser conectados com
o fluxo de sequncia. O smbolo indica que o objeto listado na linha (From De)
pode ser conectar com o objeto listado na coluna (To Para).
Figura 1.4 Conexo entre objetos com fluxo de sequncia
Fonte: BPMN (2014).
d) Swinlanes
H o agrupamento dos elementos primrios de modelagem atravs das Swinlanes
(Tabela 1.5). So mecanismos de organizao das atividades em categorias visuais
separadas (ELOGROUP, 2014; BPMN, 2014; TUDO SOBRE BPMN, 2014).
Piscinas (pools).
Raias (lanes).
Tabela 1.5 Swinlanes
Piscinas
Representa um participante em um processo, atuando como um container grfico para

dividir um conjunto de atividades de outros pools.
Raias
Representa uma subpartio pertencente. So utilizadas para organizar e categorizar

atividades.

e) Artefatos
Usados para fornecer informao adicional sobre o processo. Existem artefatos
padro, porm, durante a modelagem, podem ser adicionados outros artefatos com-
plementares. O conjunto de artefatos padro inclui:
Grupo.
Anotao.
Confira na Tabela 1.6, a seguir, o detalhe de cada conjunto de artefatos (ELO-
GROUP, 2014; BPMN, 2014; TUDO SOBRE BPMN, 2014).
Tabela 1.6 Artefatos
Grupo
Caixa em volta de um conjunto de objetos em uma mesma categoria. Esse agrupamento no

afeta a sequncia do fluxo ou as suas atividades. O nome da categoria aparece como o rtulo
do grupo. Essas categorias podem ser usadas para a documentao ou anlise de efeitos. Os
grupos so compostos com o objetivo de destacar visualmente as categorias de objetos no fluxo.
Anotao
um mecanismo utilizado pelo modelador do processo com a finalidade de fornecer informaes

adicionais ao leitor do diagrama em BPMN.
Por todas as caractersticas apresentadas anteriormente, podemos concluir que a

notao BPMN est construda sobre trs pilares de sucesso. O primeiro representa o
fato de ser uma linguagem visual de fcil compreenso para todos os participantes do
processo. O segundo representa a srie de recursos que torna possvel uma modelagem
de processos simples at os mais complexos. Por ltimo, citamos a base slida em
fundamentao matemtica, construda no conceito de Pi-Calculus, uma derivao
do clculo de processos para representao de processos de forma dinmica e mvel
(ELOGROUP, 2014; BPMN, 2014; TUDO SOBRE BPMN, 2014).
2.7.2 Fluxogramas
Segundo Ticontrole (2014), os fluxogramas tm como propsito fornecer uma
representao grfica dos elementos, componentes ou tarefas associadas com um pro-
cesso. Auxiliam na documentao de objetivos, padronizao de smbolos, promovem
o entendimento comum de passos de um processo e os relacionamentos/dependncias
entre eles. Eles podem ser modelados em alto nvel para leitores/usurios que no
esto familiarizados com a terminologia de especificao de processos. Tambm,
podem ser modelados em nvel detalhado para uma organizao que possua leitores/
usurios com conhecimento em processo (ELOGROUP, 2014).
Um fluxograma tpico pode ter tipos de smbolos descritos a seguir:
Smbolos de incio e fim representados por retngulos com bordas arredondadas.
Normalmente, contm a palavra Incio ou Fim ou uma frase simbolizando
o comeo ou trmino de um processo.
Setas que indicam que o controle passa de um smbolo para outro.
Passos de processamento representados por retngulos.
Dados de entrada e sadas representadas por paralelogramos.
Condio ou deciso representada por losango.
Para saber mais

Sobre as caractersticas do fluxograma, quando usar, como usar e suas vantagens e des-
vantagens, acesse os links:
<http://www.informazione4.com.br/cms/opencms/desafio21/artigos/gestao/organizando/0017.html>;
<http://office.microsoft.com/pt-br/visio-help/criar-um-fluxograma-basico-HA010357088.
aspx>;
<http://producaoindustrialequalidade.blogspot.com.br/2011/02/fluxograma.html>.
2.7.3 IDEF
IDEF (Integration Definition) um mtodo de modelagem de processos para um
desenvolvimento seguro e sustentado, que de forma grfica descreve todo o ciclo
de vida de desenvolvimento de um sistema. uma orientao atravs de padres e
critrios de anlise (MODELAGEM DE PROCESSOS IDEF, 2014).
A notao aplica um conjunto simples de smbolos, que consistem em caixas de
processos com setas composto por entradas, sadas, controles e mecanismos. Embora
cada nvel do modelo deva ser lido da esquerda para a direita e de cima para baixo,
o sistema de numerao utilizado para os passos representado de maneira que
possibilite a associao entre nveis de pais e filhos no processo.
Apresenta uma estratgia abrangente, permitindo a representao empresarial e
organizacional de maneira integrada e tem se transformado em um dos principais
padres (ELOGROUP, 2014; MODELAGEM DE PROCESSOS IDEF, 2014).
A proposta dos mtodos e descries auxiliar na tomada de deciso. Cada tipo

de mtodo ou descrio est focado em um conjunto estreito de relacionamento e
caractersticas de sistemas, compreende um ponto de vista ou perspectiva global do
sistema. Buscam um balanceamento favorvel entre os mtodos especiais de apli-
caes efetivas limitadas a tipos de problemas especficos e modelos que incluem
tudo que necessrio. Prov mecanismos explcitos para integrao de resultados
de aplicaes de mtodos individuais.
O foco das descries a seguir ser no mtodo IDEF0 e IDEF3 (MODELAGEM DE
PROCESSOS IDEF, 2014).
2.7.3.1 IDEF0 Modelagem funcional

Representa o primeiro conjunto de padres do IDEF, utilizando mtodos estru-
turados para compreenso e melhoria dos processos de um sistema. Esse padro de
modelagem til para estabelecer o escopo de anlise, especialmente em anlise
funcionais. Sendo uma ferramenta de comunicao, ajuda o modelador de processos
a identificar quais as funes so realizadas, quais so as necessidades para a rea-
lizao de determinadas funes e identifica em que o sistema atual est acertando
e em que est errando.
O diagrama contm um nvel de decomposio de um processo. No processa-
mento de uma coleo de atividades e outras aes est presente um conjunto cha-
mado de ICOMs (Inputs Control Output Mechanisms), setas e caixas (ELOGROUP,
2014; IDEF, 2014). Observe a Figura 1.5.
Figura 1.5 IDEF0
Fonte: IDEF0 (2014).
Input recebe o dado a ser convertido pela atividade.

Control responsabilidade de como e quando a entrada deve ser processada
e executada.
Output resultado do processamento da entrada.
Mechanism representa quem deve executar esta atividade (pessoa, equipa-

mento, mquina ou outras organizaes).
Dentre os principais objetivos do IDEF0, esto:

Fornecimento de recursos de maneira completa para a modelagem de funes
(atividades, processos, operaes e aes) requeridas.
Tcnica de modelagem independente de mtodos ou ferramentas, mas que
possam trabalhar em conjunto.
Possibilidade de anlise de sistemas com diversas finalidades, escopos ou
complexidades.
Facilidade de compreenso, comunicao, consenso e validao.
Representao dos requisitos das funes fsicas ou implementaes organiza-
cionais.
Flexibilidade para suportar as vrias fases do ciclo de vida de um projeto (ELOGROUP,
2014; IDEF, 2014a).
Para saber mais

Veja algumas vantagens e desvantagens sobre IDEF0.
Acesse os links:
<http://www.idef.com/IDEF0.htm>;
<http://www.idef.com/pdf/idef0.pdf>;
<http://graco.unb.br/alvares/pub/idef0/idef0_cefet.pdf>.
2.7.3.2 IDEF3 Modelagem para a descrio e captura de processos

Este mtodo fornece um mecanismo para coleta e documentao dos processos.
A captura de precedncia e causalidade das relaes entre situaes e eventos feita
uma forma natural de especialistas de domnio, fornecendo um mtodo estruturado
para expressar o conhecimento sobre como um sistema, processo ou organizao
executa suas atividades. O IDEF3 permite:
Gravao dos dados brutos resultantes de atividades de anlise em sistemas de
averiguao.
Determinao de impacto dos recuros de informao de uma organizao sobre
os principais cenrios de operao da organizao.
Documentao dos processos de deciso que afetam os estados e do ciclo de
vida de dados crticos compartilhados.
Gerenciamento de configurao de dados e definio de polticas de controle.
Gerao de modelos de simulao.
Gerar a concepo de um sistema e o design de anlise de trade-offs.
Tem a capacidade de compreender os aspectos comportamentais de um sistema

existente ou sugerido e captura todas as informaes temporais, inclusive de prece-
dncia e causalidade associadas aos processos empresariais.
As descries resultantes fornecem uma base de conhecimento estruturada para
a construo de modelos de anlise e design.
Existem dois modos para a descrio do IDEF3: fluxo de processos, transio da
rede do estado do objeto. A descrio de um fluxo de processo captura o conheci-
mento de como as coisas funcionam.
O segundo modo permite a transio completa de um objeto para um determinado
processo. A descrio do fluxo de processo captura a descrio de um processo e a
rede de relaes existente entre os processos dentro de um contexto.
A finalidade apresentar como as coisas esto funcionando em determinada
organizao, quando so visualizadas como parte de um problema especfico, resol-
vendo ou demonstrando uma situao recorrente. O desenvolvimento de um processo
deste tipo consiste na demonstrao de fatos, capturados a partir do domnio de um
especialista (IDEF3, 2014).
Para saber mais

Veja algumas vantagens e desvantagens sobre IDEF3:
Acesse o link: <http://www.idef.com/IDEF3.htm>.
Para conhecer os elementos do IDEF3:
Acesse os links: <http://www.idef.com/IDEF3.htm>;
<http://paginas.fe.up.pt/~ee95027/idef3.pdf>;
<http://juno.unifei.edu.br/bim/0037603.pdf> tabela IDEF3 [28].
2.7.4 ARIS
A metodologia ARIS foi desenvolvida com o objeto de integrar os processos de
negcio de uma organizao. suportada pela ferramenta Aris Toolset.
Como primeiro passo para a criao dessa arquitetura, foi gerado um modelo
composto por caractersticas para descrio de um processo. Assim, a diviso em
vistas foi criada. Essas vistas so inter-relacionadas de maneira que permita que os
modelos sejam analisados holisticamente e sem ambiguidades (ELOGROUP, 2014;
TICONTROLE, 2014). As vises do ARIS so:
Viso funcional: permite a construo de modelos que definem de maneira
hierrquica todas as funes da empresa, iniciando pelas macro e, aps,
decompondo-as at o nvel de detalhe que especifique as funes de progra-
mao dentro do sistema.
Viso dos dados: usada para definir os modelos de dados, iniciando pelas
definies de informao mais complexas, passando pelo modelo de dados e
seus relacionamentos, esquemas, at a definio da prpria base de dados.
Viso organizacional: permite a especificao e detalhamento da estrutura or-
ganizacional da empresa (divises e unidades de negcios, estrutura de cargos
e seus ocupantes, estrutura fsica com equipamentos).
Viso de controle: permite o relacionamento entre as trs vises anteriores.
Nesta viso, existem mtodos de modelagem especficos para a definio de
relacionamentos entre as funes e dados, funes e organizao, organizao
e dados e, principalmente, a integrao das trs funes.
Esta metodologia tem como principais modelos: Cadeia de Valor Agregado (VAC),
Diagrama de Objetivos (DO), Organograma (ORG), Diagrama de Alocao de Fun-
o (FAD) e Cadeia de Processos Orientada por Eventos (EPC) (ELOGROUP, 2014;
TICONTROLE, 2014).
Nos prximos tpicos, apresentaremos maiores detalhes sobre cada um desses
modelos citados.
2.7.4.1 Organograma
Descreve as unidades organizacionais, representadas por retngulos, e a hierar-
quia, por linhas. Fornece a descrio da empresa que ser convertida em objetos do
modelo e conhecimento de organizao e responsabilidades (TICONTROLE, 2014).
Como exemplo de organograma, podemos observar a Figura 1.6 e a Tabela 1.7 a seguir.
Figura 1.6 Exemplo de organograma
Fonte: Ticontrole (2014).

Tabela 1.7 Elementos de um organograma
Elemento Descrio Representao grfica
Pode representar departamentos, setores,

Unidade organizacional
sees, diretorias etc.
Corresponde aos postos de trabalho

Cargo
existentes na organizao.
Pessoa interna Corresponde aos funcionrios da organizao.
Pessoa externa Representa pessoa ou organizao externa.
Corresponde ao grupo de funcionrios que

Grupo trabalham em conjunto com o objetivo de
realizar atividades relacionadas entre si.
2.7.4.2 Cadeia de Valor Agregado VAC

O modelo VAC tem como objetivo identificar funes dentro da organizao
que so envolvidas diretamente nos valores estratgicos da instituio. Estas funes
podem ser inter-relacionadas pela criao de uma sequncia de funes (TICON-
TROLE, 2014).
Os processos podem ser relacionados aos seus respectivos objetivos e indicadores.
Um modelo VAC pode ter um detalhamento em outros macroprocessos do mesmo
tipo. No seu diagrama, as funes podem ser dispostas de uma forma hierrquica ou
similar a uma rvore de funo. A orientao do processo subordinado ou superior
sempre apresentada (DBD, 2014).
Este modelo composto pelos seguintes objetos: unidade organizacional, funo
e cluster. O objeto de unidade organizacional tem a mesma definio que apresen-
tamos anteriormente em outra notao. O objeto funo tem diferenciao entre
processos com predecessoras e processos iniciais. J o cluster pode ser definido como
um conjunto de dados e informaes (ELOGROUP, 2014).
Confira na Tabela 1.8 a representao grfica destes objetos.
Tabela 1.8 Objetos de um modelo VAC
Representao grfica Descrio
Representa processos com predecessoras
Representa processos iniciais (sem predecessoras)
Cluster conjunto de dados ou informaes utilizadas para

execuo de atividades/processos (entradas inputs) e o itens
resultantes deles (sadas outputs)
Fonte: Afonso (2004).
2.7.4.3 Diagrama de Objetivos (DO)

Antes de iniciar a modelagem, anlise ou otimizao dos processos de negcio,
necessrio definir quais so os objetivos que a organizao deseja alcanar com
a modelagem.
Um objetivo define quais so objetivos de negcios futuros que devem ser atingi-
dos durante a implementao dos novos processos. Os fatores que podem ser crticos
para alcanar os objetivos podem ser especificados, organizados em uma hierarquia e
relacionados s suas metas. Os fatores de sucesso que so necessrios ao considerar
como determinado objetivo de negcio ser atingido estaro presentes no diagrama
de objetivo (ARIS, 2014)
Os principais objetos utilizados neste modelo esto listados na Tabela 1.9; observe
que os relacionamentos so limitados e no podem ser customizados.
Tabela 1.9 Objetos de um diagrama de objetivos
Representao grfica Objeto Descrio
Corresponde s metas a serem alcanadas pela

organizao. Pode ser decomposto em subob-
Objetivo
jetivos e deve estar relacionado a um processo
(ELOGROUP, DBD, 2014).
continua
continuao
Um processo pode conter um ou mais objetivos

Processo
relacionados.
Define os aspectos que devem ser considerados

Fator crtico para que um objetivo especfico seja alcanado
(ELOGROUP, 2014).
Define os elementos que servem de insumo ou

Produto ou servio
so resultados do processamento de uma funo.
2.7.4.4 Cadeia de Processos Dirigida por Eventos (EPC)

Este mtodo utilizado para modelagem de processo e tem grande aceitao no
mundo (TICONTROLE, 2014). o modelo central para toda modelagem de negcio,
sendo um modelo dinmico que traz os recursos estticos do negcio (sistemas, or-
ganizaes e dados). Possui caractersticas similares ao modelo gerado pelo uso da
notao BPMN (DBD, 2014).
Representa a integrao das vrias vises do ARIS, tais como: funo, dados, orga-
nizao e sadas. uma modelagem que contm detalhes do processo da organizao
e seus diagramas so encadeados em atividades sequenciais, sendo que seus fluxos,
normalmente, so evento-funo-evento e baseados em regras (ELOGROUP, 2014).
Este modelo pode conter diagramas bem simples e at os de complexidade muito
alta (ABPMP, 2013). A Tabela 1.10, a seguir, mostra a lista de alguns dos possveis
objetos em um diagrama EPC.
Tabela 1.10 Objetos EPC VISUAL
Objeto Descrio
Evento descreve em quais circunstncias uma funo ou pro-
cesso so executados ou quais so os resultados deles.
Funo descreve as transformaes de um estado inicial a um

estado resultante.
Operador E (And) descreve que todas as sadas previstas, obriga-
toriamente, geradas de um dado de entradas ou que todas as entra-
das so necessrias para que uma determinada sada seja gerada.
Operador Ou (Or) corresponde ativao de um ou mais cami-
nhos entre os fluxos de controle.
Operador Ou Exclusivo (XOr) corresponde tomada de deci-

so de qual o caminho escolher entre vrios fluxos de controle.
Unidade Organizacional determina uma pessoa ou organi-

zao que responsvel por uma funo especfica dentro da
estrutura de uma empresa.
continua
continuao
Um fluxo de controle conecta eventos com a funo, caminhos do

processo ou operadores de sequncia cronolgica e a interdepen-
dncia lgica entre eles.
Caminha mostra a ligao para outros processos.
Para saber mais

Sobre EPC, acesse os links:
<http://bpmquotes.wordpress.com/2012/01/21/02-estrategia-e-processos-cadeia-de-valor/>;
<http://www.visual-paradigm.com/VPGallery/bpmodeling/epc.html#event>.
2.7.4.5 Diagrama de Alocao de Funes

O modelo FAD (Function Allocation Diagram) representa a transformao dos
dados de entrada em dados de sada, identifica os responsveis pela execuo da
atividade (papis/unidade organizacional), e tambm os sistemas e recursos usados
na execuo das atividades (TICONTROLE, 2014). Possui as informaes sobre uma
atividade do ponto de vista operacional, reduzindo a complexidade dos processos
com a representao de elementos, tais como, as funes, reas, sistemas de apoio,
entradas e sadas, artefatos e riscos inerentes s atividades (DBD, 2014).
Uma das diretrizes para a modelagem torn-la de fcil leitura, evitando carregar
o diagrama com muita informao. Uma opo, neste caso, o desmembramento
dos modelos em unidades menores (ELOGROUP, 2013). Os objetos deste tipo de
diagrama so os mesmos do EPC. O exemplo mostrado na Figura 1.7 ilustra o dia-
grama de alocao de funes.
Figura 1.7 Diagrama de alocao de funes
Fonte: Afonso (2004).

Para saber mais

Veja algumas vantagens e desvantagens sobre ARIS.
Acesse o link: <http://www.ariscommunity.com/>.
2.7.5 UML (Linguagem de Modelagem Unificada)

A notao utilizada pela UML padronizada pela OMG (Object Management
Group) e facilita a compreenso de cada parte do sistema que est sendo modelado
por qualquer pessoa que tenha conhecimento sobre a linguagem (CONNALEN, 2003).
As principais caractersticas so:
Utilizar atores e casos de uso para mostrar estruturas e fronteiras de um sistema
e suas principais funes e funcionalidades.
Utilizar diagrama de classes, no qual demonstra atributos, operaes e rela-
cionamentos para representar a estrutura esttica.
Representar a estrutura dinmica com os diagramas de estado, sequncia,
colaborao e atividades.
Revelar a arquitetura de implementao fsica (hardware ou pacote software)
com os diagramas de componentes e implementao.
Estender sua funo por meio de esteretipos.
Assim a linguagem de modelagem indicada para especificar, visualizar, construir

e documentar um sistema.
Com todas essas caractersticas, possvel a representao de partes do sistema com
os vrios diagramas e a unio destes diagramas representa o sistema como um todo.
Diagramas so recursos grficos para a visualizao de um sistema de diferentes
perspectivas e geralmente por itens e relacionamentos. Esses diagramas podem ser
divididos em trs categorias (MACORATTI, 2014).
Diagrama de estrutura: representam a construo de blocos de recursos de
sistemas que no mudam com o tempo. Dentre eles, esto: classe, objetos,
estrutura composta, implantao, componentes e pacotes.
Diagramas comportamentais: mostram com o processo responde s alteraes
ou como evolui ao longo do tempo; entre eles esto: atividades, casos de uso
e diagrama de mquina.
Diagramas de interao: descrevem as trocas de mensagem em processos
colaborativos, sendo eles: diagrama overview, sequncia, comunicao e
tempo.
Para saber mais

Para aprofundar seus conhecimentos em UML e ficar ligado nas atualizaes, acesse os links:
<http://www.uml.org/>;
<http://www.macoratti.net/vb_uml2.htm>;
<http://www.wthreex.com/rup/portugues/process/modguide/md_seqdm.htm>;
<http://msdn.microsoft.com/pt-br/library/dd409360.aspx>;
<http://www.wthreex.com/rup/portugues/process/modguide/md_bactd.htm>.
Veja tambm algumas bibliografias:
GUEDES, G.T. UML 2: Uma abordagem prtica. 2. ed. So Paulo: Novatec, 2011.
FOWLER, Martin; Scott, Kendal. UML essencial. Porto Alegre: Bookman, 2000.
FURLAN, Jos Davi. Modelagem de objetos atravs da UML. So Paulo: Makron Books, 1998.

Voc conhece os 3 amigos da UML, ou seja, os principais responsveis por
sua existncia?
1. Dentre as notaes de modelagem de processos, apresentamos o BPMN
(Business Process Model and Notation), cujo intuito padronizar a co-
municao entre os usurios do negcio. E, para apoiar essa notao, so
apresentados 3 tipos de modelos bsicos.
Com base nesta afirmativa, analise os itens a seguir e marque a alternativa
CORRETA.
a) Processos de negcio privado (global),processos abstratos (internos) e
processos de colaborao (privado).
b) Processos de negcio privado (internos), processos abstratos (pblicos)
e processos de colaborao (global).
c) Processos de negcio internos, processos concretos (internos) e pro-
cessos de colaborao (global).
d) Processos de negcio pblicos (global), processos concretos (internos)

e processos de colaborao (privado).
e) Processos de negcio colaborativo (global), processos abstratos (inter-
nos) e processos de colaborao (privado)
2. O IDEF0 representa o primeiro conjunto de padres do IDEF, utilizando
mtodos estruturados para compreenso e melhoria dos processos de um
sistema. Esse padro de modelagem til para estabelecer o escopo de
anlise, especialmente em anlise funcionais.
Dentre os principais objetivos do IDEF0, podemos destacar:
I. Fornecimento de recursos de maneira completa para a modelagem de
funes (atividades, processos, operaes e aes) requeridas.
II. Tcnica de modelagem independente de mtodos ou ferramentas, mas
que possam trabalhar em conjunto.
III. Flexibilidade para suportar as vrias fases do ciclo de vida Interativo
de um projeto orientado a objetos e estruturado.
Com base nas afirmativas, assinale a alternativa CORRETA.
a) Somente o item I.
b) Somente o item II.
c) Somente o item III.
d) Somente os itens I e II.
e) Somente os itens II e III.
Seo 3 Introduo modelagem

organizacional e ao mtodo
Enterprise Knowledge
Development (EKD)
Caro aluno, segundo Pdua (2000), EKD uma tcnica de modelagem organi-
zacional que facilita a compreenso do ambiente empresarial e conhecida como
uma atividade valiosa para a engenharia de requisitos, e que tem como objetivo
estreitar os laos entre as reas de negcio e de tecnologia da informao dentro
de uma organizao.
A necessidade de flexibilidade nas organizaes decorrente de um mercado cada
vez mais competitivo torna imprescindvel o uso da tecnologia de informao. As
constantes mudanas provocadas por essas tecnologias foram as empresas a fazerem
parte do processo de informatizao para que continuem no negcio, uma vez que
a informao tornou-se fundamental no contexto mercadolgico. Entretanto, possuir
informaes no o bastante. Uma empresa deve possuir mtodos geis capazes de
analisar essas informaes, buscando a confeco de uma base de conhecimento que
lhe servir para reconhecer as mudanas e possibilitando sua antecipao aos eventos.
Isso lhe garantir sustentabilidade e competitividade em relao aos concorrentes.
Como tratar essas informaes? Como tirar proveito dessas mudanas? Os proces-
sos de modelagem organizacional so os mecanismos capazes de contribuir com tais
tarefas. Eles apresentam a finalidade de descrever os processos de negcios visando
otimizao das informaes que circulam entre os setores de uma empresa.
Dessa forma, a modelagem tem a funo de representar como uma organizao
realmente funciona, no somente apresentando os elementos da empresa de forma
separada, mas tambm a interao existente entre os diversos setores para construo
de um todo.
Como exemplo de metodologia utilizada para a modelagem organizacional,
podemos citar a EKD (Enterprise Knowledge Development). A modelagem em si
desenvolvida para garantir uma forma estruturada de representar o conhecimento orga-
nizacional, criando um ambiente tecnolgico capaz de buscar aspectos relacionados
funcionalidade dos processos de negcios, descrever os elementos envolvidos nos
processos e apresentar de maneira detalhada as etapas que constitui tais processos.
Um ponto importante a se destacar em relao a modelagem EKD que ela ainda
apresenta a caracterstica de agregar informaes como objetivos da organizao,
restries e regras de negcio a serem seguidas.
Podemos tambm caracterizar o objetivo do EKD como o fornecimento de uma
descrio eficaz e no ambgua de como a organizao trabalha, quais as condies
e as razes para mudanas, quais as alternativas podem ser tomadas e quais critrios
so utilizados para avaliao dessas alternativas (EKD_MOeMRN). Dessa forma, o
EKD auxilia na especificao de requisitos e na construo de modelo organizacional
que remete organizao e seus requisitos. Verificando-se como cada requisito
relacionado aos objetivos, pessoas e atividades possvel a criao de um processo

de conhecimento organizacional, que fornece diversas vises da organizao.
A organizao deve criar e manter organizado todo o conhecimento adquirido,
recorrendo a ele quando uma necessidade de mudana reconhecida. De acordo
com Kirikova (EKD_MO-Burbenko), a modelagem EKD pode ser usada em diferentes
situaes com diversas finalidades, como pode ser observado a seguir:
Na engenharia de requisitos para a criao e especificao de requisitos.
Na deteco de problemas usando a anlise do negcio.
Na criao de novos sistemas de negcio por meio da reengenharia de processos
do negcio.
No gerenciamento de conhecimento organizacional ou aprendizagem organi-
zacional para formar a base de propagao e ampliao de conhecimento.
Todos esses aspectos resultaram em um modelo que poder ser usado na definio
de novas diretrizes a serem tomadas pela organizao.
Na modelagem EKD, as tarefas so desenvolvidas por equipes, divididas por ativida-
des, por usurios, engenheiros de requisitos e stakeholders. A denominao stakeholder
dada a todo membro que est envolvido no projeto, seja direta ou indiretamente.
Tambm so aqueles que mesmo no possuindo poder de deciso ou que no conhecem
profundamente o projeto, tm interesse em que esse seja desenvolvido. Exemplos de
stakeholders diretos so os gerente e usurios finais e os indiretos so os fornecedores,
alguns clientes, a concorrncia e at mesmo a sociedade (EKD_Helc-bubenko).
Como de se esperar, a modelagem EKD permeia por todos os nveis de uma
organizao, isto , passa pelo setor responsvel pela estratgia, pelos gerentes e
funcionrios responsveis pelo nvel operacional at chegar ao facilitador, cuja funo
liderar e advertir durante as reunies de modelagem. De acordo com EKD_Silvia
todos contribuem com o cumprimento das seguintes tarefas:
Diagnstico: modela a situao atual da organizao e os requisitos de
mudanas.
Entendimento ou compreenso: proposio de mudanas e discusso sobre a
viabilidade de cada uma delas.
Projeto: apresenta e modela as situaes alternativas e os possveis cenrios.
Assim sendo, o modelo EKD proporciona que essas trs tarefas sejam discutidas
por diferentes pontos de vista, envolvendo participantes de todos os setores da or-
ganizao, cada qual fornecendo experincias e habilidades diferentes. As sees
destinadas modelagem devem ser abertas, construtivas e requerer a participao
de todos. Dessa forma, o conhecimento organizao se apresenta dependente dos
participantes e no somente dos facilitadores.
Segundo Pdua (2000), o EKD traz os seguintes benefcios para as organizaes:
Entender melhor o negcio.
Facilitar a aprendizagem e comunicao organizacional sobre questes essenciais.
Ajudar atender e promover as capacidades e processos da organizao.
Melhorar a comunicao e o entendimento dos envolvidos sob o enfoque de

sistemas e de tecnologias.
Descrever os objetivos da organizao, de seus processos, o papel dos atores
(que so as pessoas envolvidas nos processos de tarefas) e dos conceitos que
a organizao adota.
Chegar a um documento chamado repositrio de conhecimento, utilizado para
um raciocnio sobre o negcio; discutir mudanas em situaes futuras e traar
a cadeia de componentes das decises formalizadas e adotadas.
Para saber mais

Para aprofundar seus conhecimentos sobre EKD, acesse os links:
<http://crinfo.univ-paris1.fr/EKD-CMMRoadMap/index.html>;
<http://people.dsv.su.se/~js/ekd_user_guide.html>;
<http://www.prod.org.br/doi/10.1590/S0103-65132008000200005>.
O modelo organizacional resultante da modelagem proposta pelo EKD usado

pelas pessoas responsveis por tomar decises sobre as futuras estratgias da empresa,
tticas e objetivos. Tal modelo formado por submodelos que respresentam alguns
aspectos do organizao.
3.1 Modelos de EKD
3.1.1 Modelo de Objetivos (MO)

Destaca a importncia da descrio dos objetivos da organizao. Nesse submo-
delo so descritos o que a empresa e seus empregados desejam alcanar ou evitar.
Tambm tem a finalidade de esclarecer alguns pontos importantes da gerncia da
organizao como por exemplo:
Qual a prioridade dos objetivos e quais so os mais importantes?
Qual a relao entre os objetivos?
Existe algum impedimento para a realizao de um objetivo?
3.1.2 Modelo de Regra de Negcio (MRN)

Este submodelo destina-se a afirmar e manter as regras de negcios estabelecidas
pelo modelo e que estejam de acordo com o Modelo de Objetivos. tambm funo
desse submodelo responder a perguntas como:
Quais regras prejudicam os objetivos da organizao?
Quais so as polticas utilizadas?
Como a relao de cada regra com os objetivos?
Como cada objetivo ser adotado pelas regras?
3.1.3 Modelo de Conceitos (MC)

Seu uso restringido define que esse submodelo atua somente definindo fenmenos
e coisas relacionadas a outros submodelos. responsvel por representar conceitos,
atributos e relaes. Os conceitos so usados para definir estritamente expresses
do Modelo de Objetivos, assim como o contedo do conjunto de informaes do
Modelo de Processos do negcio. Cabe ao Modelo de Conceitos:
Demonstrar as entidades ou conceitos que so identificados na organizao
levando-se em conta o relacionamento entre os objetivos, atividades e processos
e atores;
Como as entidades so estabelecidas;
Definio de quais regras de negcios e restries sero atribudas aos objetivos
e conceitos.
3.1.4 Modelo de Processo de Negcio (MPN)

Este modelo tem como objetivo definir os processos organizacionais, mostrando
a forma de interao e manuseio das informaes e materiais. Outra finalidade
apresentar quais so as entradas necessrias em termos de informao ou material.
A elaborao do modelo de processo de negcios permite esclarecer [43]:
Quais so as atividades e processos reconhecidos na organizao em concor-
dncia com as metas?
De que forma os processos deveriam ser realizados e quais as informaes
necessrias [43] [44]?
3.1.5 Modelo de atores e recursos

Este modelo define os tipos de atores e recursos envolvidos na atividade da em-
presa. Descreve como diferentes atores e recursos se relacionam uns com os outros
e como ele se relacionam com os componentes do modelo de objetivos. Atores e
recursos podem ser:
Indivduos:representando uma pessoa na empresa;
Unidade organizacional: representa toda a estrutura organizacional da empresa;
Recursos materiais;
Funes: atribuies para indivduos e unidades organizacionais [43] [44].
3.1.6 Modelo de requisitos e componentes tcnicos

Define a estrutura e propriedades do sistema de informao para apoiar as ativida-
des de negcio. Os modelos de Objetivos, Regras de Negcio, Processo de Negcios
e Atores e Recursos representam uma descrio inicial para a empresa, entretanto,
para desenvolver um sistema de informao que suporte esses processos, existe a
necessidade de direcionamento da ateno para o sistema tcnico que necessrio
para apoiar os objetivos, processos e atores da organizao [43] [44].
1. A tcnica de Modelagem Organizacional EKD facilita a compreenso do
ambiente empresarial e conhecida como uma atividade valiosa para a en-
genharia de requisitos, sendo organizada com seis submodelos, sendo estes:
a) Objetivos; Regras de Negcio; Conceitos; Processos de Negcio; Atores
e Recursos; Modelo de Requisitos e Componentes Tcnicos.
b) Objetivos; Regras de Negcio; Teste; Processos de Negcio; Atores e
Recursos; Modelo de Requisitos e Componentes Tcnicos.
c) Objetivos; Regras de Negcio; Concepo; Processos de Negcio;
Atores e Recursos; Modelo de Requisitos e Componentes Tcnicos.
d) Objetivos; Regras de Negcio; Transio; Processos de Negcio; Atores
e) Objetivos; Regras de Negcio; Conceitos; Transio de Negcio; Atores
2. Com base nos Benefcios de EKD, analise as afirmativas abaixo:
I. Entender melhor o negcio, para que a organizao vise aos interesses
setorizados e no ao todo;
II. Facilitar a aprendizagem e comunicao organizacional sobre questes
essenciais;
III. Ajudar a atender e promover as capacidades e processos da organizao;
IV. Melhorar a comunicao e o entendimento dos envolvidos sob o en-
foque de sistemas e de tecnologias.
Assinale a alternativa CORRETA:
a) Somente I, II.
b) Somente I, III.
c) Somente II, III, IV.
d) Somente III.
e) Somente V.

Conforme estudamos, o objetivo do EKD apresentar uma viso da organizao
como um todo. E por que no trabalhar de forma setorizada? No seria mais
rpido utilizar a modelagem do processo?
Fique ligado!
Caro aluno, chegamos ao final de nossa unidade. Vamos lembrar, aqui, as prin-
cipais questes abordadas? Foram elas:
Uma viso geral sobre as reas de negcio.
Abordamos o conceito de negcio e processos de negcio, bem como
sua classificao.
Nos aprofundamos em modelagem de processos de negcio, onde
abordarmos algumas notaes que tem como objetivo criar uma forma
de comunicao padronizada.
Abordamos tambm a modelagem organizacional, EKD, que visa
organizao como um todo.
E, com o intuito de reforar o contedo estudado, tivemos algumas
atividades de aprendizagem.
Para concluir o estudo da unidade

Parabns, voc chegou ao final da Unidade 1.
Alguns dos contedos estudados serviro de base para os demais captulos e
outros para os demais semestres. Como, por exemplo, a UML (Unified Modeling
Language, ou no portugus, Linguagem de Modelagem Unificada), que ser um
contedo abordado nos prximos semestres, sendo de extrema importncia para
a padronizao na modelagem de sistemas orientados a objetos. Esta linguagem
conhecida mundialmente, ou seja, uma vez que voc tenha aprendido seus con-
ceitos no existem barreiras para sua aplicao, bastando apenas a definio dos
modelos a serem trabalhados dentro da equipe de desenvolvimento e tambm,
claro, muita disciplina.
Sobre a camada de negcio, atravs dos modelos apresentados, foi possvel iden-
tificar a importncia em ter solues que visam integrar os processos organizaes,
ou seja, perde-se o conceito do trabalho setorizado para dar lugar ao integrado,

proporcionando um grande crescimento organizacional.
As organizaes que optam por investir em seus processos passam a oferecer
aos seus clientes mais qualidade nos produtos e servios.
E, para todo processo definido, exige-se disciplina na execuo e reviso,
ou seja, necessria a melhoria contnua, onde a organizao depende de
processos e no de pessoas.
Atividades de aprendizagem da unidade

1. Com base nas tcnicas de modelagem, apresentamos alguns objetos gerados
por elas. Relacione os objetos de modelagem apresentados na coluna da
esquerda com a coluna da direita.
OBJETOS DE MODELAGEM TCNICAS DE MODELAGEM

a)
I. BPMN
b)
II. UML
c)
III. IDF0
Assinale a alternativa CORRETA:

a) a III, b II, c I
b) a II, b III, c I
c) a I, b II, c III
d) a I, b III, c II
e) a III, b I, c II
2. A respeito de BPMN, podemos afirmar que:

a) uma linguagem de programao utilizada somente para software
comercial.
b) uma notao para criar diagrama da UML, representando apenas os
diagramas de caso de uso e classe.
c) As empresas adotam BPMN para atender somente s metodologias geis.
d) uma notao padro para o desenho de fluxogramas em processos de
negcios. Sendo um conjunto de regras e convenes que determinam
como os fluxogramas devem ser desenhados.
e) uma notao adotada para representar somente os diagramas orien-
tados a objetos.
3. Modelagem de processos pode ser definida como um conjunto de atividades
envolvidas. A respeito dos seus objetivos, analise as seguintes sentenas:
I. Entendimento da estrutura e a dinmica das reas da organizao.
II. Entendimento dos problemas atuais da organizao e identificar po-
tenciais melhorias.
III. Garantir que os usurios e engenheiros de software trabalhem de forma
individualizada, visando ao bem comum apenas de sua equipe.
IV. Auxlio na identificao de competncias.
Agora, assinale a alternativa CORRETA.
a) Somente o item I est correto.
b) Somente o item II est correto.
c) Somente o Item III est correto.
d) Somente os itens I, II, III esto corretos.
e) Somente os itens I, II, IV esto corretos.
4. Complete afirmativa: __________________ uma tcnica de modelagem
organizacional que facilita a compreenso do ambiente empresarial e
conhecida como uma atividade valiosa para a ________________________,
e que tem como objetivo estreitar os laos entre as reas de negcio e a
de tecnologia da informao dentro de uma organizao.
a) EKD, Engenharia de Requisitos.
b) UML, Engenharia de Software.
c) EKD, Elicitao de Requisitos.
d) IDEF, Elicitao de Requisitos.
e) BPMN, Anlise de Sistemas.

( ) Sadas so materiais ou informaes que contribuiro para que o
processo seja executado;
( ) Entradas representam o resultado obtido com a execuo do processo,
podem ser produtos ou servios.
( ) Controle responsvel pelo monitoramento e verificao do cumpri-
mento dos mtodos, diretrizes, objetivos, procedimentos e padres
na execuo do processo;
( ) Recurso representa a proviso de elementos que se fazem necessrios
para a execuo do processo, tais como: humanos, materiais, finan-
ceiros entre outros.
Referncias
ABPMP. BPM CBOK. Association of Business Process Management. Brasil, 2013.
AFONSO, Fernanda Chalhoub. Avaliao do Supply-Chain Operations Reference-Model
(SCOR) como um modelo de referncia de processos voltado para o gerenciamento de
cadeias de suprimentos: aplicao em um estudo de caso no setor de leo & gs. Rio de
Janeiro, 2004.
ARIS. ARIS Method. Disponvel em: <http://documentation.softwareag.com/aris/
platform_72sr2e/method_manual_aris_s.pdf>. Acesso em: 22 mar. 2014.
BPMN. BPMN Tcnicas de Modelagem. Disponvel em: <http://planningit.wordpress.
com/2012/10/24/bpmn-tecnicas-de-modelagem/>. Acesso em: 19 mar. 2014.
BPMN. Business Process Model and Notation (BPMN). Disponvel em: <http://www.omg.
org/spec/BPMN/2.0/PDF/>. Acesso em: 19 mar. 2014.
BPMQUOTES. 02 Estratgia e Processos (Cadeia de Valor). Disponvel em: <http://
bpmquotes.wordpress.com/2012/01/21/02-estrategia-e-processos-cadeia-de-valor/>. Acesso
em: 21 mar. 2014.
CAMPOS, Andr. Modelagem de Processos: Notaes. Disponvel em: <http://www.
tiespecialistas.com.br/2013/01/modelagem-de-processos-notacoes/>. Acesso em: 19 mar.
2014.
CAMPOS, Andr. Modelagem de Processos: Notaes. Disponvel em: <http://www.
tiespecialistas.com.br/2013/03/modelagem-de-processos-o-que-nao-devo-fazer/>. Acesso
em: 19 mar. 2014.
CAPOTE, Gart. Conceitos Fundamentais de BPM | Tipos de Processos de Negcio.
Disponvel em: <http://www.mundobpm.com/2011/07/conceitos-fundamentais-de-bpm-
tipos-de.html>. Acesso em: 19 mar. 2014.
CONNALEN, J. Desenvolvendo aplicaes Web com UML. 2. ed. Rio Janeiro: Campus,
2003.
DBD. Marco Terico. Disponvel em: <http://www2.dbd.puc-rio.br/pergamum/
tesesabertas/1012645_2012_cap_2.pdf >. Acesso em: 21 mar. 2014.
DEVMEDIA. Modelagem de processos: um caminho para o sucesso da organizao.
Disponvel em: <http://www.devmedia.com.br/modelagem-de-processos-um-caminho-
para-o-sucesso-da-organizacao/4785 >. Acesso em: 19 mar. 2014.
ELOGROUP. Modelagem. Disponvel em: <http://www.elogroup.com.br/wikibpm_
modelagemprocessos/wikibpm_modelagem_de_processos.pdf>. Acesso em: 19 mar. 2014.
EPC. EPC Diagram. Disponvel em: <http://www.visual-paradigm.com/VPGallery/
bpmodeling/epc.html#event>. Acesso em: 22 mar. 2014.
FLUXOGRAMA/PRODUO INDUSTRIAL E QUALIDADE. Fluxograma. Disponvel em:
<http://producaoindustrialequalidade.blogspot.com.br/2011/02/fluxograma.html>. Acesso
em: 20 mar. 2014.
IDEF. IDEF. Disponvel em: <http://sylverio.com.br/blog/2013/08/idef/>. Acesso em: 20

mar. 2014.
IDEF. Integration Definition for Function Modeling (IDEF0). Disponvel em: <http://www.
idef.com/pdf/idef0.pdf>. Acesso em: 20 mar.. 2014.
IDEF3. IDEF3 Process Description Capture Method. Disponvel em: <http://www.idef.com/
IDEF3.htm>. Acesso em: 21 mar. 2014.
IPROCESS. Modelagem de Processos de Negcio: Diferenas entre diagrama, mapa e
modelo de processos. Disponvel em: <http://blog.iprocess.com.br/2014/02/modelagem-
de-processos-de-negocio-diferencas-entre-diagrama-mapa-e-modelo-de-processos/>.
Acesso em: 19 mar. 2014.
IVNET. Fluxogramas. Disponvel em: <http://www.ivnet.com.br/educacional/osm/
fluxogramas.pdf>. Acesso em: 20 mar. 2014.
JUNO. Anlise da aplicabilidade da tcnica de modelagem IDEF-SIM nas etapas de um
projeto de simulao a eventos discretos. Disponvel em: <http://juno.unifei.edu.br/
bim/0037603.pdf tabela idef3>. Acesso em: 21 mar. 2014.
MACORATTI. UML Conceitos Bsicos. Disponvel em: <http://www.macoratti.net/vb_uml2.
htm>. Acesso em: 22 mar. 2014.
MELO, I. S. Administrao de sistemas de informao. So Paulo: Pioneira Thomson
Learning, 2006.
MODELAGEM DE PROCESSOS IDEF. Modelagem de Processos IDEF: Modelo Descritivo
da Cadeia Produtiva do Biodiesel. Disponvel em: <http://revistas.utfpr.edu.br/pg/index.
php/revistagi/article/view/525/482>. Acesso em: 20 mar. 2014.
MOREIRA, Marcelo dos Santos. Processos de negcios otimizados pelas tecnologias ECM.
Disponvel em: <http://www.revistasapere.inf.br/download/terceira/PROCESSOS.pdf>.
MPF. Modelagem de Processos de Negcio. Disponvel em: <http://www.modernizacao.
mpf.mp.br/bpm/modelagem-de-processos/elementos-da-notacao-bpmn>. Acesso em: 19
mar. 2014.
MSDN. Diagramas de atividade UML: referncia. Disponvel em: <http://msdn.microsoft.
com/pt-br/library/dd409360.aspx>. Acesso em: 23 mar. 2014.
OFFICE. Criar um fluxograma bsico. Disponvel em: <http://office.microsoft.com/pt-br/
visio-help/criar-um-fluxograma-basico-HA010357088.aspx>. Acesso em: 20 mar. 2014.
PDUA, S. I. D. Investigao do processo de desenvolvimento de software a partir da
modelagem organizacional, enfatizando regras do negcio. So Carlos. 144p. Dissertao
(Mestrado) Escola de Engenharia de So Carlos, Universidade de So Paulo, rea:
Engenharia de Produo, So Carlos, 2000. Cap. 4.
PGINAS. IDEF3 Process Description Capture Method. Disponvel em: <http://paginas.
fe.up.pt/~ee95027/idef3.pdf>. Acesso em: 21 mar. 2014.
REDE GESTO. Por que Usar BPMN. Disponvel em: <http://www.informazione4.com.br/
cms/opencms/desafio21/artigos/gestao/organizando/0017.html>. Acesso em: 19 mar. 2014.
TECLOGICA. Vantagens BPM. Disponvel em: <http://www.teclogica.com.br/consultoria/

web/bpm/vantagens>. Acesso em: 19 mar. 2014.
TICONTROLE. Padres para Modelagem de Processos no TCU. Disponvel em: <http://
www.ticontrole.gov.br/portal/page/portal/TCU/comunidades/gestao_processos_trab/padrao_
modelagem/padrao_para_modelagem_processos.pdf>. Acesso em: 21 mar. 2014.
TUDO SOBRE BPMN. BPMN Business Process Modeling Notation. Disponvel em:
<http://www.tudosobrebpm.com.br/p/bpmn-business-process-modeling-notation.html>.
UNB. IDEF0 Mtodo de Representao de Processos em Forma de Fluxo. Disponvel
em: <http://graco.unb.br/alvares/pub/idef0/idef0_cefet.pdf>. Acesso em: 20 mar. 2014.
VALENA, George. BPMN (Business Process Modeling Notation). Disponvel em: <http://
www.cin.ufpe.br/~processos/TAES3/slides-2012.2/Introducao_BPMN.pdf>. Acesso em: 19
mar. 2014.
WIKIPDIA. Arquitetura de processos. Disponvel em: <http://pt.wikipedia.org/wiki/
Arquitetura_de_processos>. Acesso em: 19 mar. 2014.
WTHREEX. Diagramas de atividade UML: referncia. Disponvel em: <http://www.wthreex.
com/rup/portugues/process/modguide/md_bactd.htm>. Acesso em: 23 mar. 2014.
WTHREEX. Diretrizes: Diagrama de Sequncia. Disponvel em: <http://www.wthreex.com/
rup/portugues/process/modguide/md_seqdm.htm>. Acesso em: 23 mar. 2014.
Unidade 2
Engenharia de
software
Luis Cludio Perini
Objetivos de aprendizagem:
Compreender a natureza e tipos de software.
Entender o que engenharia de software e por que ela importante.
Saber as respostas para as questes-chave da engenharia de software.
Entender as questes profissionais e ticas da engenhariade software.
Entender o que um processo de software.
Compreender quais as atividades genricas que esto presentes em
todos os processos de software.
Compreender os conceitos e modelos de processos de software.
Identificar os modelos de processos prescritivos bem como seus
pontos fortes e fracos.
Seo 1: Natureza do software da engenharia

de software
Nesta seo, abordaremos uma discusso inicial sobre
os conceitos iniciais de software e da engenharia de
software. Abordaremos tambm sobre o que foi a
crise de software e como delineou os objetivos da
engenharia de software.
Seo 2: Modelos de processo de software

Nesta seo, abordaremos uma discusso sobre os
conceitos de processos de software bem como os
tipos de modelos existentes no mercado.
Introduo ao estudo
Segundo Pressmann (2011), atualmente o software assume um duplo papel, em
que primeiro ele um produto e segundo, ao mesmo tempo torna-se um meio para
distribuir um produto. Analisando o mesmo como sendo um produto, ele fornece o
potencial computacional representado pelos dispositivos de hardware ou por uma
rede de computadores independentemente de onde estiver instalado, seja em um
celular ou dentro de um mainframe, software um transformador de informaes,
isto , produzindo, gerenciando, adquirindo, modificando, exibindo ou transmitindo
informaes que podem ser to simples quanto um nico bit ou to complexas
quanto uma apresentao multimdia derivada de dados obtidos de dezenas de fontes
independentes.
Conforme Pressmann (2011), vendo o software como veculo de distribuio, ele
atua como a base para o controle do computador (sistemas operacionais), a comunicao
de informaes (redes) e na criao e controle de outros programas (ferramentas de
software e ambientes). O software distribui o produto mais importante de nossa era a
informao, ou seja, transformando dados pessoais ou corporativos (exemplo, transa-
es financeiras de um indivduo) de uma maneira que possam ser mais teis em uma
determinada situao ou contexto, gerenciando informaes comerciais no intuito de
aumentar a competitividade, fornecendo um portal para redes mundiais de informao
(Internet) e os meios para obter informaes sob todas as suas formas.
Sob esse prisma, o papel desempenhado pelo software tem passado por grandes
mudanas ao longo das ltimas dcadas, com aperfeioamentos significativos no
desempenho do hardware, mudanas profundas nas arquiteturas computacionais,
grande aumento na capacidade de memria e armazenamento, e uma vasta varie-
dade de opes de dispositivos de entrada e sada, tudo isso resultando em sistemas
computacionais mais sofisticados e complexos.
Seo 1 Natureza do software e da

engenharia de software
Hoje o software uma tecnologia nica e importantssima no cenrio mundial.
Ningum 50 anos atrs poderia prever que o software se tornaria uma tecnologia in-
dispensvel tanto para os negcios, para a cincia e engenharia e que pudesse permitir
a criao e extenso de novas tecnologias tais como as ligadas engenharia gentica,
s telecomunicaes entre outras e tambm a mudana radical nas tecnologias mais
antigas (por exemplo, indstria grfica), que se tornaria a fora motriz da revoluo
do computador pessoal, que uma empresa de software fosse se tornar maior e mais
influente que a maioria das empresas da era industrial, que uma enorme rede (inter-
net) orientada por um software pudesse evoluir e modificar tudo desde pesquisas, a
E n g e n h a r i a d e s o f t w a r e 45
forma de as pessoas efetuarem compras e at mesmo a forma de marcar encontros e

de se relacionar com outras pessoas
Praticamente todos os pases, hoje em dia, dependem de sistemas complexos
baseados em computadores desde infraestruturas e servios que contam com sis-
temas baseados em computadores, e a maioria dos produtos eltricos/eletrnicos
possui embutido um computador e um software de controle, a manufatura industrial
est completamente automatizada bem como os sistemas financeiros. Dessa forma,
produzir e manter o software dentro de custos adequados essencial para o funcio-
namento da economia nacional e internacional.
Assim sendo a engenharia de software um ramo da engenharia em que o foco
o desenvolvimento de sistemas de software dentro de custos, prazo e qualidade
adequados. Uma vez que o software abstrato e intangvel, no sendo limitado por
materiais ou controlado por leis da fsica ou por processos de manufatura. Dessa
forma no existem limitaes fsicas no potencial de software, porm, a falta de res-
tries significa que o software pode facilmente se tornar extremamente complexo
e, portanto, difcil de ser compreendido.
Seria quase impossvel prever que o software estaria embutido em sistemas em
varias reas tais como transportes, mdica, telecomunicaes, militar, industrial,
entretenimento etc. e tambm que milhes de programas de computador tivessem
que ser corrigidos, adaptados e aperfeioados e que o nus de prestar tal servio
(manuteno) absorveria mais pessoas e recursos que todo o trabalho de desenvol-
vimento de novos softwares.
Atualmente, com a web 2.0 e a computao pervasiva, que vem surgindo com
fora, estamos por ver uma gerao completamente diferente de software. Ele ser
distribudo via internet e parecer estar residente nos dispositivos do computador de
cada usurio... Porm, estar residente em um servidor bem distante.
Conforme aumenta a importncia do software, a comunidade da rea tenta de-
senvolver tecnologias que tornem mais fcil, mais rpido e mais barato desenvolver
e manter programas de computador de alta qualidade. Algumas dessas tecnologias
so direcionadas a um campo de aplicao especfico (por exemplo, projeto e im-
plementao de sites); outras so focadas em um campo de tecnologia (por exemplo,
sistemas orientados a objetos ou programao orientada a aspectos); e ainda outras
so de bases amplas (por exemplo, sistemas operacionais, fanticos por tecnologia
Linux). Entretanto, ns ainda temos de desenvolver uma tecnologia de software que
faa tudo isso, embora a probabilidade de surgir tal tecnologia no futuro seja pequena.
Ainda assim, as pessoas apostam seus empregos, seu conforto, sua segurana, seu
entretenimento, suas decises e a prpria vida em software.
Historicamente o conceito de engenharia de software foi de incio proposto em
1968, no intuito de discutir a crise de software, que resultava diretamente da intro-
duo de novo hardware de computador baseado em circuitos integrados, cujo poder
fez das aplicaes de computador, consideradas at ento no realizveis, propostas
viveis e o software resultante era de ordem de grandeza maior e mais complexo que
sistemas at ento criados.
No incio a construo desses sistemas mostrou que o desenvolvimento informal
de software no era suficiente, pois alguns projetos importantes apresentavam, geral-
mente, anos de atraso e o custo do software superava as previses, no era confivel,
era difcil de manter e seu desempenho era insatisfatrio. Assim sendo o desenvol-
vimento de software estava em crise, pois os custos de hardware estavam caindo,
enquanto os custos de software aumentavam rapidamente. Para fazer frente a esses
novos problemas, novas tcnicas e mtodos tornaram-se necessrios para controlar
a complexidade no desenvolvimento de grandes sistemas de software.
Essas tcnicas tornaram-se parte da engenharia de software e so amplamente
usadas hoje; contudo, da mesma forma que aumentou a habilidade de produzir
software, cresceu tambm a necessidade por sistemas de software mais complexos.
O surgimento de novas tecnologias resultantes da convergncia de computadores e
sistemas de comunicao, e as complexas interfaces com o usurio impuseram novos
desafios aos engenheiros de software. Como muitas empresas ainda no aplicam as
tcnicas de engenharia de software de forma efetiva, muitos projetos de software so
produzidos com baixa confiabilidade, em atraso e com custo alm do oramento.
Penso que fizemos enormes progressos desde 1968, entendemos melhor as
atividades envolvidas no desenvolvimento de software. Criamos mtodos eficazes
de especificao, projeto e implementao de software e essas novas notaes e
ferramentas tm por objetivos reduzir o esforo necessrio para produzir sistemas
complexos e de grande porte. Agora sabemos que no existe uma abordagem nica
ideal para a engenharia de software, pois, com a diversidade de tipos de sistemas
e organizaes que usam esses sistemas, precisamos de uma gama de abordagens
para o desenvolvimento de software, porm noes fundamentais de processo e de
organizao de sistemas constituem a base de todas essas tcnicas que formam a
essncia da engenharia de software. Sem softwares complexos, no seria possvel a
explorao do espao, a Internet e os modernos sistemas de telecomunicaes no
existiriam e todos os meios de viagem seriam mais perigosos e caros.
No Quadro 2.1, resumimos alguns questionamentos sobre software citados por
Pressmann (2011, p. 29) e Sommerville (2007, p. 4-10).
Quadro 2.1 Questionamentos sobre software
Questionamentos Descrio
Software o produto que profissionais desenvolvem e ao qual
do suporte no longo prazo e que abrange programas execut-
veis, seja em um computador de qualquer porte ou arquitetura,
seus contedos, suas informaes tanto na forma impressa como
na virtual e abrangendo praticamente qualquer mdia eletr-
nica. Considerando a rea de engenharia de software, o mesmo
abrange um processo, um conjunto de mtodos (prticas) e um
leque de ferramentas que possibilitam aos profissionais desenvol-
verem software de altssima qualidade. J um sistema de software
consiste em um conjunto de programas separados, de arquivos de
configurao que so utilizados para configurar esses programas,
a documentao do sistema que descreve a estrutura do sistema,
O que um software? a documentao do usurio que explica como usar o sistema e
sites web onde os usurios obtm informaes sobre o produto.
Existem dois tipos fundamentais de produtos de software:
Produtos genricos. So sistemas produzidos por uma organiza-
o de desenvolvimento e vendidos no mercado para qualquer
cliente disposto a compr-los.
Produtos sob encomenda (ou personalizados). So os sistemas enco-
mendados por um determinado cliente, sendo o software desenvol-
vido especialmente para aquele cliente por uma empresa de software.
A diferena entre esses tipos que nos produtos genricos a organi-
zao que desenvolve o software controla sua especificao; j nos
produtos encomendados, a especificao desenvolvida e contro-
lada pela organizao que compra o software e os desenvolvedores
de software devem trabalhar de acordo com tal especificao.
Quem produz um software? So engenheiros de software que criam e do suporte a ele.
Ele importante pois afeta a quase todos os aspectos de nossa
Qual a importncia de um vida e incorporou-se no comrcio, na cultura, no entretenimento
software? e em nossas atividades cotidianas. J o software na engenharia de
software importante porque ela nos d condies de desenvol-
ver sistemas complexos dentro do prazo e com alta qualidade.
Um software criado da mesma forma que qualquer produto bem-
Como se produz um
-sucedido: aplica-se um processo que conduza a um resultado de
software?
alta qualidade e que atenda s necessidades daqueles que o solici-
taro, para tal aplicando uma abordagem de engenharia de software.
Na viso de um engenheiro de software, um conjunto de
O que um artefato de programas, contedo (dados) e outros dispositivos que compem
software? o ambiente de um software. J na viso do usurio, consiste em
informaes que de alguma forma tornam a vida dele melhor.
continua
continuao
A engenharia de software uma disciplina de engenharia relacio-

O que engenharia de
nada com todos os aspectos da produo de software, desde os
software?
estgios iniciais de especificao do sistema at sua manuteno,
depois que este entrar em operao.
Essencialmente, a cincia da computao diz respeito s teorias e
Qual a diferena entre
aos mtodos que constituem a base de computadores e sistemas
engenharia de software e
de software, por outro lado a engenharia de software se dedica
cincia da computao?
aos problemas prticos da produo de software.
A engenharia de sistemas diz respeito a todos os aspectos do
desenvolvimento e da evoluo de sistemas complexos, nos quais
o software desempenha um papel importante. Est relacionada ao
Qual a diferena entre
desenvolvimento de hardware, projeto de polticas e de processos e
engenharia de software e
implantao do sistema, assim como com a engenhana de software.
engenharia de sistemas?
Os engenheiros de sistemas se envolvem com a especificao do
sistema, com a definio da arquitetura geral e com a integrao de
diferentes partes do sistemas. Porm esto menos envolvidos com a en-
genharia dos componentes do sistema (como hardware, software etc.).
um framework e resultados associados que produzem um
produto de software. Existem quatro atividades fundamentais de
O que processo de
processo que so comuns a todos os processos de software. So
software?
elas: especificao de software; desenvolvimento de software;
validao de software e evoluo de software.
Um modelo de processo de software uma descrio simpli-
ficada que apresenta uma viso dele. Os modelos de processo
incluem as atividades, que fazem parte do processo de software,
os produtos de software e os papis das pessoas envolvidas na
engenharia de software. A maior parte dos modelos de processo
se baseia em um dos trs paradgimas de desenvolvimento a
seguir: modelo em cascata que representa as atividades citadas
O que um modelo de
acima em fases separadas de processo, como especificao de
processo de software?
requisitos, projeto de software, implementao e teste; desen-
volvimento iterativo intercala as atividades de especificao,
desenvolvimento e validao e engenharia de software baseada
em componentes (CBSE Component Based Software Engineer-
ing) supe que panes do sistema j existam e, assim sendo, o
processo de desenvolvimento concentra-se mais na integrao
dessas partes do que no seu desenvolvimento a partir do incio.
continua
continuao
A distribuio do custo ao longo das diferentes atividades no pro-
cesso de software depende do processo e do tipo de software que
est sendo desenvolvido, pois na abordagem cascata os custos de
especificao, projeto, implementao e integrao so medidos
separadamente. Na abordagem iterativa, no existe uma linha
precisa entre especificao, projeto e desenvolvimento. Na enge-
nharia de software baseada em componentes tem sido aplicada
intensamente porem ainda no h valores precisos dos custos de
diferentes atividades de desenvolvimento de software. Sabe-se
que os custos de desenvolvimento so menores que os custos de
integrao e de teste.
Alm dos custos de desenvolvimento, os custos tambm ocor-
rem na manuteno no software apos sua liberao para uso.
Quais so os custos da
Os custos de evoluo variam muito, dependendo do tipo de
engenharia de software?
sistema, pois para sistemas de software de vida longa, ou seja,
em sistemas que podem ser usados por dez anos ou mais, esses
custos provavelmente excedem de trs a quatro vezes os custos
de desenvolvimento.
Essas distribuies de custo so vlidas para software sob enco-
menda, conforme especificado pelo cliente e desenvolvido por
um fornecedor. Esses produtos so geralmente desenvolvidos a
partir de um esboo de especificao, usando uma abordagem
evolucionria de desenvolvimento e, desta forma, portanto, os
custos de especificao so relativamente baixos.
Os custos de evoluo para os produtos genricos de software
so particularmente difceis de serem estimados, em vrios casos,
existe uma pequena evoluo formal de um produto.
Um mtodo de engenharia de software uma abordagem estru-
turada para desenvolvimento de software, cujo objetivo faci-
litar a produo de software de alta qualidade dentro de custos
adequados. Mtodos tais como Anlise Estruturada (DcMarco,
1978) foram desenvolvidos inicialmente na dcada de 1970. Nas
O que so mtodos de dcadas de 1980 e 1990, os mtodos orientados a funes foram
engenharia de software? suplementados por mtodos orientados a objetos (OO), como os
propostos por Booch (1994) e Rumbaugh et al. (1991). No existe
um mtodo ideal, e diferentes mtodos possuem diferentes reas
onde so mais aplicveis. Todos os mtodos esto baseados na
ideia de modelos de desenvolvimento de um sistema, que pode
ser representado graficamente, e na ideia de uso desses modelos
como especificao e projeto de um sistema.
O acrnimo CASE corresponde a Computer-Aided Software
Engineering, ele abrange uma larga faixa de diferentes tipos de
programas que so usados para dar apoio s atividades do pro-
O que CASE? cesso de software, tais como anlise de requisitos, modelagem de
sistema, depurao e teste. As ferramentas CASE podem tambm
incluir um gerador de cdigo que gera automaticamente o c-
digo-fonte com base no modelo do sistema, e algumas orienta-
es sobre o processo para os engenheiros de software.
continua
continuao
Assim como os servios que ele fornece, os produtos de software
possuem outros atributos associados que demonstram a quali-
Quais so os atributos de dade do software. Esses no esto relacionados diretamente com
um bom software? o que o software faz, mas, em vez disso, refletem o comporta-
mento do software, enquanto est em execuo, e a estrutura e
a organizao do programa-fonte bem como a documentao
associada.
Fonte: Adaptado de Pressmann (2011) e Sommerville (2007).
Sommerville (2007) coloca os seguintes desafios para a engenharia de software:

1. O desafio da heterogeneidade: cada vez mais necessrio que os sistemas de
software operem como sistemas distribudos, atravs de redes, que incluem
diferentes tipos de computadores, com diferentes tipos de sistemas de apoio.
O desafio de heterogeneidade consiste em desenvolver tcnicas para cons-
truo de software confivel que seja flexvel o suficiente para adaptar-se a
essa heterogeneidade.
2. O desafio da entrega: muitas tcnicas tradicionais de engenharia de software
demandam tempo, tempo esse necessrio para obter a qualidade do software.
Porm levando em conta o atual ambiente de negcios h necessidade de
apresentar respostas geis e mudar rapidamente. O software de apoio deve
acompanhar a velocidade da mudana. O desafio da entrega consiste em
diminuir os tempos de entrega dos sistemas grandes e complexos, sem com-
prometer a sua qualidade.
3. O desafio da confiana: como o software est entrelaado com todos os as-
pectos da nossa vida, essencial que possamos confiar nele. O desafio da
confiana desenvolver tcnicas que demonstrem que o software pode ter a
confiana dos seus usurios.
1.1 Evoluo do software

Para que um software possua uma ampla utilidade, ele necessita de centenas ou
milhares de algoritmos. Atualmente os softwares so bastante complexos e podem
ser formados por diversos programas.
O software evoluiu bastante na segunda metade do sculo XX quando surgiram
os primeiros computadores. Na primeira era, que teve incio na dcada de 1950 at
meados dos anos 1960, o hardware sofreu contnuas mudanas em computadores de
baixa capacidade (embora ocupassem salas enormes), com o processamento de dados
em lote (sem interao com o usurio no decorrer da interao), e os softwares eram
feitos e executados para clientes especficos com distribuio limitada, no havendo
preocupao com a documentao.
J na segunda era, que ocorreu entre os anos 1960 a meados dos 1970, surgiram
sistemas de tempo real de grande porte multiusurios e as primeiras aplicaes de
banco de dados. Teve incio a comercializao de softwares genricos (criao das

primeiras software-houses) que atendiam s necessidades de diversos clientes, bem
como o surgimento de bibliotecas de software, visto que ocorreu um crescimento
no nmero de sistemas baseados em computador, pois o acesso aos computadores
tornou-se mais fcil por parte das mdias e grandes empresas. Alm do crescimento
do uso e comercializao do software, ainda se verificava a pouca importncia dada
manuteno, que era difcil de ser feita. No Brasil, softwares com essas caractersticas
foram utilizados at meados dos anos 1980. Linguagens de programao de alto nvel
facilitaram em parte a construo de software nessa segunda era.
A terceira era comeou em meados dos anos 1970 com o surgimento de hardware
de baixo custo baseado em microprocessadores (surgimento dos PCs) e estendeu-
-se at incio dos anos 1990 e com o aumento dos sistemas distribudos e das redes
locais e globais, com o hardware a cada dia mais em conta, possibilitando assim s
empresas adquirirem mini e microcomputadores. Com esse impacto no consumo,
consequentemente, houve uma grande demanda por software. E por conta do aumento
do consumo, devido tambm ao uso generalizado de microprocessadores por parte
da indstria, gerando produtos inteligentes (micro-ondas, TV com controle remoto
etc.), foi sentida a falta de mo de obra especializada, de tcnicas e ferramentas
de desenvolvimento de software, e de planejamento e gerenciamento do processo
para atender a esse impacto de consumo levando crise do software. Essa crise do
software levou ao surgimento de tcnicas de programao como modularizao e
refinamentos sucessivos e metodologias para desenvolvimento de software como a
Anlise e Projetos Estruturados e o Mtodo de Jackson, que buscavam resolver os
problemas de desenvolvimento de software.
A quarta era, a partir do final dos anos 1990 e incio do sculo XXI, caracteriza-se
pelo surgimento de tecnologias orientadas a objeto. Grandes empresas optaram por
trocar computadores de grande porte por sistemas distribudos num fenmeno deno-
minado de downsizing, em que se iniciou o uso de sistemas especialistas e software
de inteligncia artificial e de redes neurais agora usados na prtica. A popularizao
dos microcomputadores de baixo custo levou ao surgimento de inmeros softwares
aplicativos de prateleira comprados por pequenas e microempresas e tambm por
usurios comuns. Tambm o surgimento e a popularizao da Internet e o surgimento
da World Wide Web (www), em meados da dcada de 1990, causaram uma revolu-
o na forma como as aplicaes so desenvolvidas, utilizadas e comercializadas. O
surgimento de linguagens voltadas para esses ambientes, como Java, e de plataformas
de interoperabilidade para sistemas de software distribudos, como CORBA, vm
indicando que estamos entrando numa nova era.
Apesar de toda essa evoluo do software, alguns problemas persistem e outros
se intensificaram, tais como:
A habilidade em construir software deixa a desejar em relao ao potencial

do hardware.
Hoje o potencial do hardware, devido s constantes atualizaes tecnolgi-
cas, superior capacidade dos softwares, pois o hardware manufaturado
e o software no, isto , depende dos conhecimentos dos profissionais acerca
das novas tecnologias disponveis no mercado, sejam elas novas verses de
linguagens de programao, banco de dados etc.
A construo de software no rpida o suficiente para atender as necessi-
dades do mercado.
Como o software depende de pessoas para a realizao dos projetos e tambm
devido ao aumento da complexidade das aplicaes, o tempo exigido para o
desenvolvimento do produto de software muitas vezes no rpido o suficiente
para atender s necessidades dos usurios, sejam eles pessoa fsica, empresas
ou rgos governamentais.
A sociedade depende cada vez mais de software confivel; quando ele falha, po-
dem ocorrer gastos enormes e desgaste de muitos profissionais para arrum-lo.
A falta de documentao e o uso por parte dos desenvolvedores de metodo-
logias para desenvolvimento e testes de software tm levado muitos projetos
a ser liberados para o usurio com algumas falhas; quando isso ocorre, os
custos e o tempo para solucionar tais problemas so grandes, muitas vezes
sendo necessitrio alocar profissionais de outros projetos para a realizao da
manuteno do sistema.
O esforo para construir software confivel e de qualidade muito grande.
O suporte aos programas existentes apoiado por projetos pobres e recursos
inadequados.
Uma vez que boa parte dos projetos foi desenvolvida sem uma base slida
de qualidade de software, em virtude do tempo em que seu projeto inicial foi
criado, e pelas sucessivas manutenes realizadas sem a devida documentao,
o suporte a esses projetos fica comprometido.
Pressmann (2011, p. 30) diz que hoje uma enorme indstria de software tornou-se
um fator dominante na economia mundial, com equipes de especialistas em software,
cada qual concentrando-se numa parte da tecnologia necessria para distribuir uma
aplicao complexa, havendo a substituio do programador solitrio para um mais
atuante e ligado com as novas tecnologias. Porm, as questes levantadas por esse
programador solitrio ainda continuam as mesmas feitas hoje, quando no desenvol-
vimento de novos e modernos sistemas computacionais:
Por que concluir um software leva tanto tempo?
Por que os custos de desenvolvimento so to altos?
Por que no conseguimos encontrar todos os erros antes de entregarmos o
software aos clientes?
Por que gastamos tanto tempo e esforo mantendo programas existentes?
Engenharia de software 53
Por que continuamos a ter dificuldade em medir o progresso enquanto o soft-

ware est sendo desenvolvido e mantido?
Tom de Marco (1995 apud PRESSMANN, 2011, p. 31) afirma:
Em vez de perguntar por que software custa tanto, precisamos
comear perguntando o que fizemos para tomar possvel que o
software atual custe to pouco? A resposta a essa pergunta nos
ajudar a continuarmos com o extraordinrio nvel de realizao
que sempre tem distinguido a indstria de software.
A preocupao em resolver essas questes tem levado adoo das prticas da

engenharia de software
1.2 Software
Pressmann (2011, p. 32) conceitua software como (1) instrues (programas de
computador) que. quando executadas, fornecem caractersticas, funes e desem-
penho desejados; (2) estruturas de dados que possibilitam aos progra mas manipular
informaes adequadamente; e (3) informao descritiva, tanto na forma impressa
como na virtual, descrevendo a operao e o uso dos programas.
Ainda conforme Pressmann (2011), o software mais um elemento de sistema
lgico do que fsico e, dessa forma, possui caractersticas que so diferentes das do
hardware, como mostra o Quadro 2.2.
Quadro 2.2 Caractersticas do hardware
Caracterstica Descrio
Mesmo havendo algumas similaridades entre o desen-
volvimento de software e a fabricao de hardware,
as duas atividades so diferentes. Pois, em ambas, alta
qualidade obtida por meio de bom projeto, mas a
fase de fabricao de hardware pode gerar problemas
de qualidade inexistentes ou facilmente corrigveis
Software desenvolvido ou passa por para software. Tambm se verifica que ambas as
um processo de engenharia, ele no atividades so dependentes de pessoas, mas a rela-
fabricado no sentido clssico. o entre pessoas envolvidas e trabalho realizado
completamente diferente. Ambas requerem a constru-
o de um produto, entretanto, as abordagens so
diferentes. Os custos de software concentram-se no
processo de engenharia, isso significa que projetos
de software no podem ser geridos como se fossem
projetos de fabricao.
continua
continuao
A Figura 2.1 mostra a taxa de defeitos em funo do
tempo para hardware. Essa relao indica que o hard-
ware apresenta taxas de defeitos relativamente altas
no incio de sua vida devido a falhas de projeto ou de
fabricao e, uma vez corrigidos esses efeitos, a taxa
cai para um nvel estvel (felizmente, bastante baixo)
por certo perodo. Resumindo, o hardware comea a
desgastar-se. J o software no suscetvel aos males
ambientais que fazem com que o hardware se desgaste.
Porm a curva da taxa de defeitos para software deve-
ria assumir a forma da curva idealizada, conforme
a Figura 2.2. A curva idealizada uma simplificao
grosseira de modelos de defeitos reais para software.
Mas a implicao clara: software no se desgasta,
Software no se desgasta.
mas sim se deteriora, pois, durante sua vida, passar
por vrias alteraes e, medida que estas ocorram,
provvel que sejam introduzidos erros, fazendo com
que a curva de taxa de defeitos se acentue, conforme
mostrado na curva real. Outro aspecto de desgaste
ilustra a diferena entre hardware e software: quando
um componente de hardware se desgasta, ele substi-
tudo por uma pea de reposio. No existem peas
de reposio de software. Cada defeito de software
indica um erro no projeto ou no processo pelo qual o
projeto foi traduzido em cdigo de mquina execut-
vel. Portanto, as tarefas de manuteno de software,
que envolvem solicitaes de mudanas, implicam
complexidade consideravelmente maior do que a de
manuteno de hardware.
medida que a disciplina da engenharia evolui, uma
coleo de componentes de projeto padronizados
criada. Os componentes reutilizveis foram criados
para que o engenheiro possa se concentrar nos ele-
mentos realmente inovadores de um projeto, isto ,
nas partes que representam algo novo. No mundo do
Embora a indstria caminhe para a
hardware, a reutilizao de componentes uma parte
construo com base em componen-
natural do processo de engenharia. J quando falamos
tes, a maioria dos softwares continua
no mundo do software, algo que, em larga escala,
a ser construda de forma personali-
apenas comeou a ser alcanado, pois um componente
zada, sob encomenda.
de software deve ser projetado e implementado de
modo que possa ser reutilizado em muitos programas
diferentes. Os modernos componentes reutilizveis
encapsulam tanto dados quanto o processamento
aplicado a eles, possibilitando criar novas aplicaes a
partir de partes reutilizveis.
Fonte: Adaptado de Pressmann (2011, p. 32-34).
Figura 2.1 Curva de defeito de hardware Figura 2.2 Curva de defeito de software
Fonte: Adaptada de Pressmann (2011, p. 32). Fonte: Pressmann (2011, p. 33).
Pressmann (2011) ainda subdivide o campo de aplicao do software em cate-

gorias que apresentam grandes desafios para os engenheiros de software, conforme
podemos ver no Quadro 2.3.
Quadro 2.3 Categorias de software
Categoria Descrio
um conjunto de programas feito para atender a ou-
tros programas (compiladores, editores, utilitrios etc.)
que processam complexas estruturas de informao. J
Software de sistema
outras aplicaes de sistema (componentes de sistema
operacional, drivers, software de rede etc.) processam
dados amplamente indeterminados.
So programas desenvolvidos sob medida que solucio-
Software de aplicao
nam uma necessidade especfica de negcio do cliente.
So caracterizados por possuir algoritmos para proces-
samento numrico pesado (number crunching). Porm,
modernas aplicaes na rea de engenharia/cientfica
esto se afastando dos algoritmos numricos convencio-
Software cientfico/de engenharia
nais, esto sendo usados para projetos com o auxlio de
computador, simulao de sistemas e outras aplicaes
interativas que possuam caractersticas de sistemas em
tempo real e at mesmo de software de sistemas.
So aplicaes que residem num produto ou sistema,
usa-se para controlar e implementar caractersticas e
funes tanto para o usurio final como para o prprio
Software embutido sistema. Executa funes limitadas e especficas (con-
trole do painel de um forno micro-ondas, por exemplo)
ou fornece funo significativa e capacidade de controle
(como funes digitais de automveis).
continua
continuao
So softwares projetados para prover um necessidade

especfica para o uso de muitos clientes diferentes.
Pode ser dirigido a um mercado limitado e particula-
rizado (como software para controle de estoques) ou
Software para linhas de produtos ser dirigido a mercados de consumo de massa (proces-
samento de texto, planilhas eletrnicas, computao
grfica, multimdia, entretenimento, gerenciamento de
bancos de dados e aplicaes financeiras pessoais e
comerciais).
Tambm conhecidas como WebApps, e, em sua forma
mais simples, as WebApps podem ser pouco mais que
um conjunto de arquivos de hipertexto interconectados,
apresentando informaes por meio de texto e informa-
es grficas limitadas. Mas, com o aparecimento da
Aplicaes Web Web 2.0, essas aplicaes evoluram e se transformaram
em sofisticados ambientes computacionais que no ape-
nas fornecedores de recursos especializados, de funes
computacionais e de contedo para o usurio final, mas
tambm esto integradas a bancos de dados corporati-
vos e aplicaes comerciais.
Usa algoritmos no numricos para solucionar proble-
mas complexos que no so passveis de computao
ou de anlise direta. As aplicaes de IA se destinam
Software de inteligncia artificial
s reas de robtica, sistemas especialistas, reconheci-
mento de padres (de imagem e de voz), redes neurais
artificiais, prova de teoremas, jogos etc.
1.2.1 Qualidades do software

Como qualquer produto, o software deve ter qualidade, mas vrias so as quali-
dades do software a serem avaliadas, sendo necessrio examinar tanto a qualidade
do produto em si como a do processo de desenvolvimento. No Quadro 2.4 a seguir
descrevemos algumas das qualidades que podem ser avaliadas.
Quadro 2.4 Qualidades a serem avaliadas em um software
Qualidade Descrio
Um software precisa funcionar corretamente. Um software correto
Corretude
aquele que satisfaz a sua especificao e que no possui falhas ou erros.
Um software vlido aquele cuja especificao satisfaz aos requi-
Validade sitos dos usurios e da organizao, isto , est de acordo com as
necessidades dos usurios.
O software deve prever que o usurio pode agir de forma no es-
Robustez perada e deve ser capaz de resistir a essas eventuais situaes inco-
muns sem apresentar falhas.
continua
continuao
Um software correto e robusto ganha a confiana dos usurios,
Confiabilidade uma vez que ele deve se comportar como esperado e no falha em
situaes inesperadas.
O software deve realizar suas tarefas em um tempo adequado
complexidade de cada uma delas. A utilizao dos recursos de
Eficincia
hardware (memria, disco, trfego de rede) tambm deve ser feita de
forma eficiente.
O software precisa ser fcil de aprender e de usar, permitir maior
Usabilidade produtividade do usurio, flexibilidade de utilizao, flexibilidade
de aplicao e proporcionar satisfao de uso.
Todo software precisa de manuteno, seja para corrigir erros ou
Manutenibilidade atender a novos requisitos. O software deve ser fcil de manter para
que essas correes ou atualizaes sejam feitas com sucesso.
Todo software precisa evoluir para atender a novos requisitos, para
Evolutibilidade incorporar novas tecnologias ou para expanso de sua funcionali-
dade.
O software deve poder ser executado no maior nmero possvel de
Portabilidade
equipamentos de hardware.
Softwares em diferentes plataformas devem poder interagir entre si.
Essa qualidade essencial em sistemas distribudos, uma vez que o
software pode estar sendo executado em diferentes computadores
Interoperabilidade e sistemas operacionais. interessante que diferentes elementos de
softwares distintos possam ser utilizados em ambos. Por exemplo,
certo arquivo com uma imagem feita num aplicativo deve poder ser
vista em outros aplicativos.
Diversos componentes de um software devem poder ser reutilizados
Reusabilidade por outras aplicaes. O reso de funes e objetos facilita bastante
o desenvolvimento de software.
1.3 Engenharia de software

Pressmann (2011) apresenta alguns fatos reais que os desenvolvedores de softwares
devem enfrentar no sculo XXI:
1. A incorporao do software no nosso dia a dia traz como consequncia um
nmero de pessoas interessadas nos recursos e nas funes oferecidas pelos
softwares. Quando no desenvolvimento de um software, muitos usurios
devem ser ouvidos, pois cada um deles possui pontos de vista (ideias) dife-
rentes de funes, recursos e dispositivos que o software deve incorporar.
Assim sendo, desprenda-se do conceito de que a engenharia um esfoo
concentrado para compreender o problema antes de desenvolver uma solu-
o de software. Dessa forma devemos fazer um esforo concentrado para
compreender o problema antes de desenvolver uma soluo.
2. Boa parte dos requisitos de TI (Tecnologia de Informao) so solicitados por
indivduos, empresas e rgos governamentais e esto se tornando cada vez
mais complexos a cada dia. Atualmente, o desenvolvimento de sistemas, que

antes era realizado por vrias pessoas, realizado por um nico indivduo.
Antes, um software sofisticado era implementado de forma independente e
previsvel em um ambiente computacional; hoje, est incorporado em tudo,
desde produtos eletrnicos de consumo a equipamentos mdicos e sistemas
de armamentos, em que a complexidade desses novos produtos e sistemas
exige uma maior ateno para com as interaes de todos os elementos do
sistema. Ento, conclui-se que projetar tornou-se uma atividade fundamental.
3. A cada dia que passa ns pessoas, empresas, governo estamos mais
dependentes de um software para decises estratgicas e tticas, bem como
para o controle das atividades do dia a dia e, dessa maneira, se o software
falhar, ns poderemos vivenciar desde pequenos inconvenientes at falhas
catastrficas. Assim sendo um software deve apresentar qualidade elevada.
4. medida que a importncia de um software especfico aumente, a probabi-
lidade de que o nmero de usurios e seu tempo de vida tambm cresam.
Com esse crescimento, tanto de usurios como da longevidade, a demanda
por manuteno tambm crescer, por isso um software deve ser passvel de
manuteno.
Apenas com essas simples constataes podemos concluir que:

Um software, em todas as suas formas e em todos os seus campos de aplicao,
deve passar pelos processos de engenharia
Figura 2.3 Camadas da engenharia de software
Fonte: Adaptada de Pressmann (2011, p. 39).
Bauer (apud PRESSMANN, 2011, p. 29) define a engenharia de software como o

estabelecimento e o emprego de slidos princpios de engenharia de modo a obter
software de maneira econmica, que seja confivel e funcione de forma eficiente
em mquinas reais .
J o IEEE Institute of Electrical and Electronic Engineers (apud PRESSMANN,
2011, p. 29) define engenharia de software como a aplicao e o estudo de uma
abordagem sistemtica, disciplinada e quantificvel no desenvolvimento, na operao
e na manuteno de software; isto , a aplicao de engenharia ao software.
Com base nessas definies, Figura 2.3, Pressmann (2011) afirma que a engenharia
de software uma tecnologia em camadas, e refere que ela deve estar fundamentada
num compromisso com a qualidade. A sua gesto a pedra fundamental que sustenta a
engenharia de software o foco na qualidade. J a base para a engenharia de software
a camada de processos, ou seja, a liga que mantm as camadas de tecnologia
unidas e possibilita o desenvolvimento de software de forma racional e dentro do
prazo. Dessa maneira, o processo define uma metodologia que deve ser estabelecida
para a entrega efetiva de tecnologia de engenharia de software constituindo a base
para o controle do gerenciamento de projetos de software, estabelecendo o contexto
de onde mtodos tcnicos sero aplicados e, quais modelos, documentos, dados,
relatrios, formulrios sero produzidos e, tambm com o estabelecimento de marcos,
a qualidade garantida e mudanas so geridas de forma apropriada. Os mtodos
fornecem as informaes tcnicas para desenvolver software, envolvendo uma ampla
gama de tarefas, que incluem a comunicao, anlise de requisitos, modelagem de
projeto, construo de programa, testes e suporte. Os mtodos se baseiam em um
conjunto de princpios bsicos que governam cada rea da tecnologia e inserem
atividades de modelagem e outras tcnicas descritivas. J ferramentas fornecem su-
porte automatizado ou semiautomatizado para o processo e para os mtodos e, uma
vez integradas, de modo que as informaes criadas por uma ferramenta possam ser
usadas por outra, estabelecido um sistema para o suporte ao desenvolvimento de
software, denominado engenharia de software com o auxlio do computador (CASE).
Para saber mais

No intuito de fixar melhor seus conhecimentos sobre processos de software, acesse os links:
<http://www.devmedia.com.br/processos-de-software/21977>.
<http://www.devmedia.com.br/introducao-aos-processos-de-software-e-o-modelo-
incremental-e-evolucionario/29839>.
1.3.1 Processo de software

um conjunto de atividades, aes e tarefas realizadas na criao de algum
projeto de trabalho (workproduct). Uma atividade tem por fim atingir um objetivo
e utilizada independentemente da aplicao, do tamanho e da complexidade do
projeto, dos esforos ou do grau de rigor com que a engenharia de software ser
aplicada. Uma ao envolve um conjunto de tarefas que resultam num artefato de
software. J uma tarefa se concentra em um objetivo pequeno, porm bem definido
e produz um resultado tangvel.
Na engenharia de software, um processo no uma prescrio rgida de como
desenvolver um software, mas sim uma abordagem adaptvel que possibilita s pessoas
realizar o trabalho de selecionar e escolher o conjunto apropriado de aes e tarefas.
A inteno a de sempre entregar software dentro do prazo, a um custo e com

qualidade suficiente para satisfazer queles que patrocinaram sua criao e queles
que vo utiliz-lo.
Uma metodologia de processo (framework) estabelece a base para um processo
de engenharia de software completo, por meio da identificao de um pequeno
nmero de atividades estruturais aplicveis a todos os projetos, independentemente
de tamanho ou complexidade. Alm disso, a metodologia de processo engloba um
conjunto de atividades de apoio, tambm conhecidas como atividades guarda-chuva,
aplicveis em todo o processo de software; uma metodologia de processo genrica
para engenharia de software compreende cinco atividades: comunicao, planeja-
mento, modelagem, construo e emprego.
Essas atividades metodolgicas genricas podem ser utilizadas tanto para o de-
senvolvimento de programas pequenos e simples, como para a criao de grandes
aplicaes para a internet e para a engenharia de grandes e complexos sistemas
baseados em computador. Os detalhes do processo de software podero ser bem
diferentes em cada caso, porm as atividades permanecero as mesmas.
Para muitos projetos de software, as atividades metodolgicas so aplicadas itera-
tivamente conforme o projeto se desenvolve. Ou seja, comunicao, planejamento,
modelagem, construo e emprego so aplicados repetidamente quantas forem as
iteraes do projeto, sendo que cada iterao produzir um incremento de software.
Este disponibilizar uma parte dos recursos e funcionalidades do software. A cada
incremento, o software torna-se mais e mais completo.
As atividades lgicas do processo de engenharia de software so complementadas
por uma srie de atividades de guarda-chuva (Quadro 2.5), geralmente aplicadas
ao longo de um projeto, auxiliando a equipe a gerenciar, a controlar o progresso, a
qualidade, as mudanas e os riscos.
Quadro 2.5 Atividades guarda-chuva tpicas
Atividade Descrio
Controle e acompanha- Possibilita que a equipe avalie o progresso em relao ao plano do
mento do projeto projeto e tome as medidas necessrias para cumprir o cronograma.
Avalia riscos que possam afetar o resultado ou a qualidade do
Administrao de riscos
produto/projeto.
Garantia da qualidade de Define e conduz as atividades que garantem a qualidade do
software software.
Avaliam artefatos da engenharia de software, tentando identificar e
Revises tcnicas
eliminar erros antes que se propaguem para a atividade seguinte.
Define e coleta medidas (do processo, do projeto e do produto).
Medio Auxilia na entrega do software de acordo com os requisitos; pode
ser usada com as demais atividades (metodolgicas e de apoio).
Gerenciamento da configu-
Gerencia os efeitos das mudanas ao longo do processo.
rao de software
continua
continuao
Define critrios para o reso de artefatos (inclusive componentes

Gerenciamento da recusa-
de software) e estabelece mecanismos para a obteno de compo-
bilidade
nentes reutilizveis.
Preparo e produo dos Engloba as atividades necessrias para criar artefatos, por exem-
artefatos de software plo, modelos, documentos, logs, formulrios e listas.
1.4 Crise do software

Em meados dos anos 1970, surgiu o termo crise do software, quando a engenha-
ria de software praticamente inexistia, e estava relacionada s dificuldades enfrentadas
no desenvolvimento de software, pelo aumento das demandas e da complexidade
delas, aliado inexistncia de tcnicas apropriadas para resolver tais desafios.
A crise se referia aos softwares desenvolvidos na poca, que apresentavam em sua
maioria uma qualidade inferior e custos superiores ao previsto: de fato, entre 50%
e 80% dos softwares desenvolvidos no apresentavam as configuraes desejadas e
cerca de 90% tinham seu custo final entre 150% a 400% maior que o previsto.
Esses fatos fizeram aparecer o conceito de crise do software, podendo ser verifi-
cada por vrios sintomas, tais como:
software de baixa qualidade;
projetos com prazos e custos maiores que os planejados;
software no atendendo aos requisitos dos stakeholders;
custos e dificuldades no processo de manuteno.
Para saber mais

Aprofundando seu conhecimento, assista ao vdeo:
<www.youtube.com/watch?v=EbTo14jSJ6Y>.
1.5 Causas da crise de software

Com base nos sintomas expostos e no que vemos hoje, podemos chegar concluso
de que a crise ainda est presente. Apesar de dispormos de tcnicas apropriadas, ainda
presenciaremos esses problemas hoje e em um futuro prximo. Mesmo as empresas
que tm conhecimento das tcnicas propostas s vezes no conseguem pratic-las
por presso do prprio cliente, por exemplo, em relao a prazos, custos e qualidade.
Podemos dizer ainda que a crise se refere a um conjunto de problemas encon-
trados no desenvolvimento de software, tais como:
1. As estimativas de prazo e de custo so frequentemente imprecisas

Pelo fato de no dedicarmos tempo para coletar dados sobre o processo de
desenvolvimento de software e tambm por no haver nenhuma indicao
slida de produtividade, no podemos avaliar com preciso a eficcia de
novas ferramentas, mtodos ou padres.
2. A produtividade das pessoas da rea de software no tem acompanhado a
demanda por seus servios
Os projetos de desenvolvimento de software normalmente so efetuados
apenas com um vago indcio das exigncias do cliente.
3. A qualidade de software s vezes menos que adequada
S recentemente comeam a surgir conceitos quantitativos slidos de garantia
de qualidade de software.
4. O software existente muito difcil de manter
A tarefa de manuteno devora o oramento destinado ao software, uma vez
que a facilidade de manuteno no foi enfatizada como um critrio importante.
Na atualidade, tambm encontramos uma crise de desenvolvimento de software
que, alm de englobar os sintomas relacionados crise do software, est relacionada
com os pontos a seguir:
grande insatisfao de clientes;
custos relativos ao desenvolvimento de sistemas aumentando, enquanto os rela-
tivos a hardware diminuem;
prazo de desenvolvimento de software tornando-se mais longo enquanto os custos
de manuteno tornam-se maiores;
erros de software tornando-se mais frequentes, refletindo em custos de manu-
teno e de retrabalho;
processos estruturados de desenvolvimento sendo inflexveis e ainda muito utilizados;
desenvolvimento de aplicativos/sistemas com alto custo, baixa qualidade e com
demanda cada vez maior, aliados a uma complexidade tambm cada vez maior;
presso das empresas clientes para entregas rpidas dos sistemas.
1.6 Consequncias da crise de software

Uma das consequncias da crise foi o surgimento de diversos mtodos de
desenvolvimento de software, os quais, por sua grande quantidade, caracterizaram-se
por se tornar mais um problema ante a inexistncia de um mtodo genrico e con-
fivel. Outro aspecto est ligado aceitao desses novos mtodos tanto por parte
dos desenvolvedores como das empresas produtoras de software, uma vez que, pela
imaturidade no mercado, eles dificilmente so incorporados no dia a dia por causa da
pouca confiabilidade que os desenvolvedores tm em relao aos mesmos, preferindo
usar mtodos antigos, porm que tm eficincia garantida pela experincia de uso.
Contudo a maior consequncia da crise foi o surgimento da engenharia de soft-

ware, a qual visa ao desenvolvimento de tecnologias que facilitem e permitam a
obteno de softwares eficientes e baratos; sua importncia a fez tornar-se um novo
campo de pesquisa na computao.
1.7 Causas dos problemas associados crise de software

Dentre as causas dos problemas que levaram crise do software podemos destacar:
1. O prprio carter do software: uma vez que o software um elemento de sis-
tema lgico e no fsico, seu sucesso medido pela quantidade de uma nica
entidade e no pela quantidade de entidades manufaturadas (implantadas).
2. Falhas das pessoas responsveis pelo desenvolvimento de software: gerentes
sem nenhum background, falta de treinamento para os profissionais da rea em
novas tcnicas para o desenvolvimento de software e tambm pela resistncia
mudanas, tanto por parte dos clientes como por parte dos desenvolvedores.
3. Mitos do software que propagaram desinformao e confuso e esto subdi-
vididos em mitos administrativos, de clientes e de profissionais.
1.8 Mitos relativos ao software

Algumas crenas (mitos) infundadas em relao aos softwares e ao processo usado
para cri-los remontam aos primrdios da computao. As crenas, tambm chamadas
de mitos, possuem uma srie de atributos que as tornam uma cilada, por exemplo,
esses atributos parecem ser afirmaes razoveis e tm uma sensao intuitiva e fre-
quentemente so promulgados por praticantes profissionais que se julgam experientes.
Hoje, boa parte dos engenheiros de software reconhece os mitos por aquilo que
eles representam, ou seja, atitudes enganosas que provocaram srios problemas tanto
para gerentes quanto para os profissionais da rea. Porm, antigos hbitos e atitudes
so difceis de ser modificados e resqucios de mitos de software permanecem. Os
mitos podem ser classificados como mitos administrativos, de clientes e profissionais.
1.8.1 Mitos administrativos

A presso para manter oramentos, cumprir os cronogramas e elevar a qualidade
est levando tanto os gerentes de software como de outras reas a se agarrar crena
num mito de software para aliviar tal presso, mesmo que temporariamente.
O Quadro 2.6 mostra alguns mitos que os gerentes enfrentam no desenvolvimento
de software.
Quadro 2.6 Mitos administrativos
Mitos Realidade
Um manual pode at existir, porm, usado? As
pessoas da rea sabem que ele existe? Este manual
Uma vez que temos um manual cheio de
reflete a prtica moderna da engenharia de sof-
padres e procedimentos para desenvolver
tware? Ele completo? adaptvel? Est alinhado
software, ento ele suficiente para o meu
para melhorar o tempo de entrega, mantendo ainda
pessoal com tudo que eles precisam saber.
o foco na qualidade? Em muitos casos, a resposta
para todas essas perguntas no.
O desenvolvimento de software no um processo
Se o cronograma atrasar, s colocar mais mecnico como o de fbrica, pois acrescentar pes-
programadores e ficarmos em dia (tambm soas num projeto atrasado s o tornar mais atrasado
chamado de conceito da horda mongol). ainda. Podem-se adicionar pessoas ao projeto, desde
que seja de forma planejada e bem coordenada.
Se terceirizar o projeto de software, posso Se uma empresa no souber gerenciar e controlar
simplesmente relaxar e deixar essa em- seus projetos de software, provavelmente enfrentar
presa realiz-lo. dificuldades ao terceiriz-los.
Meu pessoal tem ferramentas de
preciso muito mais do que os mais recentes
desenvolvimento de software de ltima
computadores para se fazer um desenvolvimento de
gerao; afinal compramos os mais novos
software de alta qualidade.
computadores.
Fonte: Adaptado de Pressman (2011, p. 46).
1.8.2 Mitos dos clientes

O usurio de um software pode ser algum ao seu lado, um grupo tcnico, um
departamento da empresa ou mesmo uma empresa externa que encomendou o pro-
jeto por contrato. Na maioria das vezes, o cliente acredita em mitos sobre o software
porque gerentes e profissionais da rea pouco fazem para corrigir falsas informaes.
Mitos esses que conduzem a falsas expectativas (do cliente) e, em ltima instncia,
insatisfao com o desenvolvedor, como podemos observar no Quadro 2.7.
Quadro 2.7 Mitos dos clientes
Mitos Realidade
Uma definio inicial ruim a principal causa de fracassos
preciso muito mais do que os
dos esforos de desenvolvimento de software.
mais recentes computadores para
fundamental uma descrio formal e detalhada do
se fazer um desenvolvimento de
domnio da informao, funo, desempenho, interfaces,
software de alta qualidade.
restries de projeto e critrios de validao.
verdade que os requisitos de software mudam, mas o
impacto da mudana varia dependendo do momento em
que ela foi introduzida. Quando as mudanas dos requisitos
Os requisitos de projeto modificam-se
so solicitadas antes de o projeto ou a codificao terem
continuamente, mas as mudanas
comeado, o impacto sobre os custos relativamente pe-
podem ser facilmente acomodadas,
queno. Porm, conforme o tempo passa, os recursos foram
porque o software flexvel.
comprometidos, uma estrutura de projeto j foi estabelecida
e mudar isso pode causar uma revoluo que exija recursos
adicionais e modificaes fundamentais no projeto.
Fonte: Adaptado de Pressmann (2011, p. 46).
1.8.3 Mitos dos profissionais

Mitos que ainda sobrevivem entre os profissionais da rea tm resistido por mais
de 50 anos de cultura de programao. Durante seus primrdios, a programao era
vista como uma forma de arte, pois modos e atitudes antigos dificilmente morrem.
No Quadro 2.8 podemos verificar alguns mitos profissionais.
Quadro 2.8 Mitos dos profissionais
Mitos Realidade
Assim que escrevermos o programa Dados da indstria de software indicam que entre
e o colocarmos em funcionamento 60% e 80% de todo o esforo ser despendido aps a
nosso trabalho estar completo. entrega do software pela primeira vez ao cliente.
Um programa funcionando somente uma parte de
At que o programa entre em funcio-
uma configurao de software que inclui todos os
namento, no h maneira de avaliar
itens de informao produzidos durante a construo
sua qualidade.
e manuteno do software.
Um programa funcionando somente uma parte
de uma configurao de software que inclui muitos
O nico produto passvel de entrega elementos. Uma variedade de produtos derivados (por
o programa em funcionamento. exemplo, modelos, documentos, planos) constitui
uma base para uma engenharia bem-sucedida e, mais
importante, uma orientao para suporte de software.
A engenharia de software no trata de criao de docu-
A engenharia de software nos far criar
mentos, trata da criao de um produto de qualidade.
documentao volumosa e desnecessria
Melhor qualidade conduz reduo do retrabalho, e
e, invariavelmente, ir nos retardar.
menos retrabalho resulta em maior rapidez na entrega.
Muitos profissionais de software reconhecem os enganos sobre os mitos que aca-

bamos de descrever. Mas, infelizmente, mtodos e atitudes habituais estimulam tanto
o gerenciamento quanto as medidas tcnicas deficientes, mesmo quando a realidade
exige uma abordagem mais eficiente. Ter conscincia das realidades do software o
primeiro passo para buscar solues prticas na engenharia de software.

Analisando a evoluo do software bem como da engenhara de software,
reflita se voc est preparado para fazer a aplicao da engenharia de soft-
ware em suas atividades cotidianas.
Analisando a crise do software bem como as suas causas, reflita se os proble-
mas que ocorreram na dcada de 1970 no so os mesmos encontrados hoje.
1. Cite e explique duas atividades guarda-chuva.
2. Quais so as camadas da engenharia de software?
3. Cite e explique pelo menos um mito administrativo, de cliente e profissional.
Seo 2 Modelos de processos de software

Um processo de software um framework (conjunto de atividades) que leva
produo de um produto de software de qualidade, sendo que essas atividades podem
envolver o prprio desenvolvimento de software, fazendo uso de uma linguagem de
programao. No entanto, cada vez mais, o novo software desenvolvido com a
ampliao e/ou modificao de sistemas j existentes, de configurao e integrao
de software comercial ou de um componente de sistema.
Como todos os processos intelectuais e criativos, os processos de software so
complexos e dependem de julgamento humano. E pela necessidade de utilizar o
julgamento e a criatividade, as tentativas de automatizao desses processos tm um
sucesso limitado, pois as ferramentas CASE (Computer-Aided Software Engineering)
podem apoiar apenas algumas atividades de processo. Entretanto no existe possibi-
lidade no momento de uma automao mais extensa, em que o software assuma o
projeto criativo, liberando os engenheiros envolvidos no processo.
A limitao das ferramentas CASE vem da imensa gama de processos de software.
No h um processo ideal, uma vez que vrias organizaes desenvolveram aborda-
gens inteiramente diferentes para o desenvolvimento de software.
Os processos de desenvolvimento evoluram no intuito de explorar as capacidades
das pessoas em uma empresa e tambm as caractersticas especficas dos sistemas que
esto sendo desenvolvidos. No caso dos sistemas crticos, necessrio um processo
de desenvolvimento muito mais estruturado. J nos sistemas de comerciais, em que os
requisitos mudam rapidamente, um processo flexvel e gil provavelmente mais eficaz.
Embora existam vrios tipos de processos de software, algumas atividades funda-
mentais so comuns a todos eles, tais como:
1. Especificao de software: A funcionalidade do software e as restries sobre
sua operao devem ser definidas.
2. Projeto e implementao de software: deve atender especificao deve ser
produzido.
3. Validao de software: deve ser validado para garantir que faa o que o
cliente deseja.
4. Evoluo de software: deve evoluir para atender s necessidades mutveis
do cliente.
Essas atividades fazem parte de todo processo de software, so atividades comple-

xas que incluem subatividades, como validao de requisitos, projeto de arquitetura,
testes unitrios, teste de integrao e teste de carga.
Validao de requisitos uma atividade pela qual se verifica se os requisitos
definem o sistema que o cliente realmente quer.
Projeto de arquitetura o primeiro estgio no processo de projeto de soft-

ware e est preocupado com a compreenso de como um sistema deve ser
organizado e com a estrutura geral desse sistema.
Teste unitrio o processo de testar os componentes do programa, como
mtodos ou classes de objeto.
Teste de integrao envolve a integrao de componentes para criao de
uma verso do sistema e, em seguida, o teste do sistema integrado.
Teste de carga deve ser projetado para assegurar que o sistema possa pro-
cessar a carga a que se destina.
H atividades de extrema importncia que do apoio ao processo, como as de
documentao e gerenciamento de configurao, ao descrever e discutir os proces-
sos, como a especificao de um modelo de dados, o projeto de interface de usurio
bem como a organizao dessas atividades. No entanto, assim como as atividades,
as descries do processo tambm podem incluir:
Produtos: So os resultados de vrias atividades do processo.
Papis: Refletem as responsabilidades das pessoas envolvidas no processo.
Pr e ps-condies: So declaraes verdadeiras antes e depois de uma ati-
vidade do processo ou da produo de um produto.
Embora no exista um processo de software ideal, ainda h espao para apri-
moramento do processo de software em vrias organizaes. Os processos podem
incluir tcnicas obsoletas e/ou no tirar vantagem das melhores prticas na engenha-
ria de software. De fato, muitas empresas ainda no se beneficiam dos mtodos de
engenharia de software em seu desenvolvimento de software, pois boa parte delas
acha muito difcil sua implementaao e dessa forma no faz o uso delas.
Os processos de software podem ser aprimorados pela padronizao, onde a
diversidade de processos de software ao longo da organizao pequena e por esse
motivo, promove o aprimoramento da comunicao e reduo no tempo de treina-
mento e faz que o apoio ao processo automatizado seja mais econmico.
A padronizao tambm um passo inicial importante na introduo de novos
mtodos e tcnicas de engenharia de software e das boas prticas de engenharia de
software.
Um processo foi definido como um conjunto de atividades de trabalho, aes
e tarefas realizadas quando algum artefato de software deve ser criado. Cada uma
dessas atividades, aes e tarefas alocam-se dentro de uma metodologia ou modelo
que determina seu relacionamento com o processo e seu relacionamento umas com
as outras. Cada atividade do processo de software composta por um conjunto de
aes de engenharia de software. Cada ao definida por um conjunto de tarefas,
o qual identifica as tarefas de trabalho a ser completadas, os artefatos de software
que sero produzidos, os fatores de garantia da qualidade que sero exigidos e os
marcos utilizados para indicar progresso.
Uma metodologia de processo genrica para engenharia de software estabelece
cinco atividades metodolgicas: comunicao, planejamento, modelagem, construo
e entrega. Alm disso, um conjunto de atividades de apoio (atividades guarda-chuva),

conforme a Figura 2.4, so aplicadas ao longo do processo, como o acompanha-
mento e controle do projeto, a administrao de riscos, a garantia da qualidade, o
gerenciamento das configuraes, as revises tcnicas e outras.
Figura 2.4 Atividades guarda-chuva
Para saber mais

Para aprimorar seus conhecimentos sobre o assunto, acesse e leia:
<http://www.dominiopublico.gov.br/download/texto/cp010140.pdf>
e
<http://www.dominiopublico.gov.br/download/texto/cp044363.pdf>.
2.1 Modelos geis

O desenvolvimento gil um fruto da constatao feita por diversos profissionais na rea
de engenharia de software, de que, apesar de terem aprendido segundo a cartilha tradicional,
s conseguiam minimizar os riscos associados ao desenvolvimento de software pensando e
agindo de forma muito diferente do que tradicionalmente est nos livros.
Embora cada envolvido tivesse sua prpria prtica e/ou teorias preferidas, todos concorda-
vam que em suas experincias prvias os projetos de sucesso tinham em comum um pequeno
conjunto de princpios. Com base nisso eles criaram o Manifesto para o Desenvolvimento
gil de Software, frequentemente chamado apenas de Manifesto gil.
No desenvolvimento gil, os projetos adotam o modelo iterativo e em espiral de
desenvolvimento, onde todas as fases descritas no modelo em cascata (anlise, design,
implementao, testes, implantao e manuteno) so executadas diversas vezes
ao longo do projeto, produzindo ciclos curtos que se repetem por todo o desenvol-
vimento, sendo que, ao final de cada ciclo, sempre se tem um software funcional,
testado e aprovado.
Os ciclos so chamados de iteraes e crescem em nmero de funcionalidades
a cada repetio, sendo que, no ltimo, todas as funcionalidades desejadas estaro
implementadas, testadas e aprovadas.
2.1.1 Manifesto gil de software

Segundo Pressmann (2011, p. 128), Kent Beck e 16 outros notveis desenvol-
vedores, produtores e consultores de software (conhecidos como a Aliana gil)
assinaram o Manifesto para o Desenvolvimento gil de Software, onde declararam:
[] estamos descobrindo melhores modos de desenvolvimento de
software fazendo-o e ajudando outros a faz-lo. Por meio desse
trabalho passamos a valorizar: indivduos e interaes em vez de
processos e ferramentas; softwares funcionando em vez de docu-
mentao abrangente; a colaborao do cliente em vez de nego-
ciao de contratos; a resposta a modificaes em vez de seguir
um plano. Isto , ainda que haja nos itens direita, valorizamos
mais os itens esquerda.
Um manifesto normalmente associado com um movimento poltico emergente,

isto , um movimento que sugira mudanas revolucionrias e, de certa forma, isso
exatamente o que desenvolvimento gil .
Embora as ideias que guiam o desenvolvimento gil existam h anos, somente na
dcada de 1990 que foram cristalizadas em um movimento. Essencialmente os
mtodos geis foram desenvolvidos num esforo para vencer as fraquezas detectadas e
reais da engenharia de software convencional. O desenvolvimento gil pode fornecer
importantes benefcios, porm no aplicvel a todos os projetos, produtos, pessoas
e situaes. Ele tambm no contrrio slida prtica de engenharia de software
e pode ser aplicado como uma filosofia prevalecente a todo o trabalho de software.
Hoje difcil ou impossvel prever como um sistema baseado em computador
evoluir com o passar do tempo, pois as condies de mercado mudam rapidamente,
necessidades dos usurios finais evoluem e as novas ameaas de competio surgem
sem alerta. E em muitas situaes, no h como definir completamente os requisitos
antes do incio do projeto, assim os engenheiros de software devem ser geis o sufi-
ciente para responder a um ambiente de negcios mutante.
Isso significa que um reconhecimento dessas causas realsticas modernas no nos
obriga a descartar princpios, conceitos, mtodos e ferramentas valiosos de engenharia
de software, visto que, como todas as atividades de engenharia, a de software conti-
nua a evoluir, podendo ser adaptada facilmente para encarar os desafios colocados
pela demanda por agilidade.
O que exatamente agilidade no contexto do trabalho de engenharia de software?
Na verdade o acolhimento de modificaes o principal guia para a agilidade. Os
engenheiros de software devem reagir rapidamente se tiverem de acomodar as rpidas
modificaes, seja no software que est sendo construdo, nos membros das equipes,
em modificaes por causa de novas tecnologias. Modificaes de todas as espcies

que podem ter impacto no produto ou no projeto que cria o produto.
Mas agilidade mais do que uma resposta efetiva modificao. Ela tambm en-
globa a filosofia apresentada no Manifesto para o Desenvolvimento gil de Software.
Encoraja estruturas e atitudes de equipe que tornam a comunicao mais fcil (entre
membros da equipe, entre pessoal de tecnologia e de negcios, entre engenheiro de
software e seus gerentes). Ela enfatiza a rpida entrega de software operacional e d
menos importncia para produtos de trabalho intermedirio; adota os clientes como
parte da equipe de desenvolvimento e trabalha para eliminar a atitude ns e eles
que continua a permear muitos projetos de software; ela reconhece que o planeja-
mento em um mundo incerto tem seus limites e que um plano deve ser flexvel. No
Quadro 2.9 podemos verificar os princpios da Aliana gil.
Quadro 2.9 Princpios da agilidade
Princpio Descrio
Nossa maior prioridade satisfazer ao cliente desde o incio por meio de entrega con-
1
tnua de software valioso.
Modificaes de requisitos so bem-vindas, mesmo que tardias no desenvolvimento.
2 Os processos geis aproveitam as modificaes como vantagens para a competitivi-
dade do cliente.
Entrega de softwares funcionando frequentemente, a cada duas semanas at dois
3
meses, de preferncia no menor espao de tempo.
O pessoal do negcio e os desenvolvedores devem trabalhar juntos diariamente du-
4
rante todo o projeto.
Construo de projetos em torno de indivduos motivados. Fornea-lhes o ambiente
5
e apoio que precisam e confie que eles faro o trabalho.
O mtodo mais eficiente e efetivo de levar informao para dentro de uma equipe de
6
desenvolvimento conversa face a face.
7 Software funcionando a principal medida de progresso.
Processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvol-
8
vedores e usurios devem ser capazes de manter um ritmo constante, indefinidamente.
9 Ateno contnua a excelncia tcnica e ao bom projeto facilita a agilidade.
10 Simplicidade a arte de maximizar a quantidade de trabalho no efetuado essencial.
11 As melhores arquiteturas, requisitos e projetos surgem de equipes auto-organizadas.
Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva, ento
12
sintoniza e ajusta adequadamente seu comportamento.
2.1.2 Caractersticas
O processo gil de software caracterizado de forma que atenda s seguintes
suposies-chave sobre a maioria dos projetos de software:
difcil prever quais requisitos de software vo persistir e quais sero modifi-
cados. igualmente difcil prever como as prioridades do cliente sero modi-
ficadas medida que o projeto evolui.
Como em vrios tipos de software, o projeto e a construo so intercalados,
ou seja, as duas atividades devem ser realizadas juntas de maneira que os
modelos de projeto sejam comprovados medida que so criados.
Anlise, projeto, construo e testes no so to previsveis (do ponto de vista
do planejamento) como gostaramos.
Dadas essas trs suposies, pergunta-se ento como criar um processo que
possa gerenciar a imprevisibilidade? A resposta est na adaptabilidade do processo.
Um processo gil, portanto, deve ser adaptvel. Assim, um processo gil de software
deve ser adaptado incrementalmente e para realizar a adaptao uma equipe gil
requer o feedback do cliente. Dessa forma, uma estratgia de desenvolvimento deve
ser instituda, na qual os incrementos de software prottipos executveis ou par-
tes um sistema operacional devem ser entregues em curtos perodos de tempo
de modo que a adaptao acerte o passo com as modificaes. Essa abordagem
iterativa habilita o cliente a avaliar o incremento de software regularmente, fornecer
o feedback necessrio equipe e influenciar as adaptaes do processo feitas para
acomodar o feedback.
2.1.3 Ciclo de vida

O ciclo de vida do desenvolvimento dos mtodos geis praticamente igual aos
demais mtodos, porm com a diferena de que so executados ciclos mais rpidos,
e estes executados diversas vezes. Sendo estas as etapas:
definir a necessidade do cliente e iniciar o projeto;
planejar o projeto, calculando o esforo;
executar o plano, construindo a soluo;
monitorar resultados e entregar ao cliente;
ciclos mais rpidos, executados diversas vezes.
2.1.4 Fatores humanos

Pressmann (2011, p. 86) comenta que os proponentes de desenvolvimento gil
de software sofrem muito para enfatizar a importncia dos fatores pessoais no de-
senvolvimento gil bem-sucedido. O ponto-chave dessa declarao que o processo
se molda s necessidades das pessoas e da equipe, e no o contrrio. Se os membros
de uma equipe de software tiverem de estabelecer as caractersticas do processo que
aplicado para construir softwares, uma certa quantidade de caractersticas-chave
(Quadro 2.10) deve existir entre as pessoas de uma equipe gil e na equipe em si.
Quadro 2.10 Caractersticas-chave entre os componentes de uma equipe gil
Caracterstica Descrio
Em um contexto de desenvolvimento gil, competncia inclui talento
nato, habilidades especficas relacionadas a software e conhecimento
Competncia global do processo que a equipe decidiu aplicar. Habilidade e conhe-
cimento do processo podem e devem ser ensinados a todas as pessoas
que servem como membros de equipes geis.
Embora os membros da equipe gil possam realizar diferentes tarefas e
trazer diferentes habilidades ao projeto, todos deveriam estar focados
em uma meta entregar um incremento de software em funciona-
Foco comum
mento ao cliente dentro do prazo prometido. Para atingir essa meta, a
equipe tambm vai concentrar-se em adaptaes contnuas (pequenas e
grandes) que faro o processo satisfazer s necessidades da equipe.
Engenharia de software (independentemente do processo) diz respeito
a avaliar, analisar e usar as informaes que so comuns equipe de
software, criar informaes que ajudaro o cliente e outros a entender
Colaborao o trabalho da equipe, e construir informaes (software de computador
e banco de dados relevantes) que forneam valor de negcio para o
cliente. Para realizar essas tarefas da equipe precisam colaborar uns
com os outros, com o cliente e com os gerentes de negcio.
Os gerentes de software devem reconhecer que uma equipe gil ter de
lidar continuamente com ambiguidades e ser continuamente con-
frontada por modificaes. Em alguns casos a equipe precisa aceitar
Habilidade de resol- o fato de que o problema que est sendo resolvido hoje pode no ser
ver problemas vagos o problema que precisar ser resolvido amanh. No entanto, as lies
aprendidas de qualquer atividade de soluo de problema (inclusive
aquelas que resolvem o problema errado) podem ser benficas para a
equipe mais adiante no projeto.
No contexto de desenvolvimento gil, a auto-organizao implica trs
coisas:
A equipe gil organiza-se para o trabalho a ser feito.
Auto-organizao A equipe organiza o processo para melhor acomodar seu ambiente
local.
A equipe organiza o cronograma de trabalho para conseguir melhor
entrega do incremento de software.
2.1.5 Modelos de processo geis

Dentro os modelos de processos geis, destacamos:
XP eXtremme Programming
Scrum
Mtodo de Desenvolvimento de Sistemas Dinmicos (DSDM)
Crystal
Desenvolvimento Dirigido a Funcionalidades (FDD)
2.1.5.1 XP eXtremmeProgramming
O mtodo XP talvez seja o mais usado dos mtodos de desenvolvimento geis.
Esse mtodo foi escrito por Kent Beck e recentemente foi refinado. Essa variao
foi denominada IXP (Industrial XP) que tende a ser o processo gil para grandes or-
ganizaes usarem. composto por um conjunto de cinco valores (Comunicao,
simplicidade, feedback, coragem e respeito) para estabelecer as bases para todo
trabalho realizado como parte da XP. Esses valores so usados como um direcionador
das atividades especficas da XP.
No mtodo XP, todos os requisitos so expressos como cenrios, que so im-
plementados diretamente como uma srie de tarefas. Os programadores trabalham
em pares e desenvolvem testes para cada tarefa antes da escrita do cdigo, assim
exercitando cada operao de acordo com sua funcionalidade especificada. Sempre
que um incremento entregue para o cliente, os casos de uso so usados para base
de testes de aceitao e geram uma forma de feedback. Conforme o surgimento de
novas necessidades, rapidamente a equipe informa o cliente sobre o impacto nos
custos e no cronograma do desenvolvimento do software.
Um preceito fundamental na engenharia de software que voc deve projetar
para a mudana, antecipando melhorias futuras para o software e projet-lo para que
seja facilmente implementado. A maioria das equipes de software argumentam que
projetar para o amanh poupar tempo e esforos no longo prazo. Uma equipe XP
gil deve ter disciplina (coragem) para projetar hoje, reconhecendo que as necessida-
des futuras podem mudar dramaticamente exigindo, consequentemente, substancial
retrabalho em relao ao projeto e ao cdigo implementado.
A XP emprega uma abordagem orientada a objetos como seu paradigma de de-
senvolvimento preferido, envolvendo um conjunto de regras e prticas constantes
no contexto de quatro atividades metodolgicas: planejamento, projeto, codificao
e testes.
2.1.5.2 Scrum
O Scrum definido como um framework no qual se podem tratar e resolver pro-
blemas complexos e adaptativos, enquanto entregam produtos com o mais alto valor
possvel; resumidamente, o Scrum : leve, simples de entender e difcil de dominar.
O Scrum um framework estrutural que est sendo usado para gerenciar o desen-
volvimento de produtos complexos, no um processo ou uma tcnica para construir
produtos e, sim, uma ferramenta na qual se pode empregar vrios processos ou tcni-
cas. Consiste em times associados a papis, artefatos, eventos e regras, em que cada
componente dentro do framework serve para um propsito especfico e essencial.
Obedece a algumas regras que integram os eventos, papis e artefatos.
Na teoria o Scrum fundamentado em controle de processo ou empirismo, o qual
afirma que o conhecimento vem da experincia e de tomada de decises baseadas
no que conhecido, emprega abordagem interativa e incremental para aperfeioar
a previsibilidade e o controle de riscos. Trs pilares apoiam a implementao de

controle de processo emprico:
o aspecto significativo do processo, que deve esta visvel aos responsveis

pelos resultados. Requer aspectos definidos por um padro comum para
Transparncia
que os observadores compartilhem um mesmo entendimento do que est
sendo visto.
Os artefatos Scrum devem ser inspecionados por causa de variaes, porm
essa inspeo no deve ser to frequente a ponto de atrapalhar a prpria
Inspeo
execuo das tarefas. As inspees so mais benficas quando realizadas de
forma diligente por inspetores especializados no trabalho a se verificar.
composto por ProductOwner, Time de Desenvolvimento e ScrumMaster.
Os times Scrum so auto-organizveis e multifuncionais. Auto-organizveis
por escolherem qual a melhor forma para completarem seu trabalho, em vez
Times Scrum
de serem dirigidos por outros de fora do time. Multifuncionais por possurem
todas as competncias necessrias para completar o trabalho sem depender
de outros que no fazem parte da equipe.
Integram produtos de forma interativa e incremental, assim maximizando as

oportunidades de realizao.
2.1.5.3 Mtodo de Desenvolvimento de Sistemas Dinmicos (DSDM)

uma metodologia de desenvolvimento de software baseada originalmente no
RAD (Desenvolvimento Rpido de Aplicao), uma metodologia de desenvolvimento
iterativo e incremental que enfatiza o envolvimento constante do usurio.
Segundo Pressmann (2011 p. 96), o DSDM uma abordagem gil de desenvol-
vimento de software que fornece um arcabouo para construir e manter sistemas
que satisfazem s restries de prazo apertado por meio do uso de prototipagem
incremental em um ambiente controlado de projeto.
O DSDM possui as seguintes caractersticas:
envolvimento ativo do usurio;
fora de equipe;
entrega frequente de produtos;
adequao para o propsito do negcio;
desenvolvimento iterativo e incremental;
todas as mudanas durante o desenvolvimento so reversveis.
Existe um grupo mundial de empresas que coletivamente assume o papel de

mantenedor do mtodo. Esse consrcio definiu um mtodo de processos geis,
chamado ciclo de vida DSDM que define trs ciclos iterativos diferentes precedidos
por duas atividades de ciclo de vida adicionais:
Estudo de viabilidade: estabelece os requisitos bsicos de negcio e restries
associados aplicao a ser construda e depois avalia se a aplicao ou no
um candidato vivel para o processo DSDM.
Estudo do negcio: estabelece os requisitos funcionais e de informao que

permitem aplicao agregar valor de negcio.
Iterao de modelos funcionais: produz um conjunto de prottipos que de-
mostram funcionalidade para o cliente.
Interao de projetos e desenvolvimentos: reviso de prottipos desenvolvidos
durante a iterao de modelos funcionais para assegurar-se de que cada um
tenha passado por um processo de engenharia para capacit-lo a oferecer, aos
usurios finais, valor de negcio em termos operacionais.
Implementao: aloca a ltima verso do incremento de software no ambiente
operacional. Deve-se notar que o incremento pode no estar 100% completo
ou alteraes podem vir a ser solicitadas conforme o incremento seja alocado.
2.1.5.4 Crystal
A famlia Crystal , na verdade, um conjunto de processos geis que se mostraram
efetivos para diferentes tipos de projeto. A inteno permitir que equipes geis sele-
cionem o membro da famlia Crystal mais apropriado para o seu projeto e ambiente.
Inclui grande nmero de mtodos diferentes que so selecionados de acordo com
as caractersticas do projeto a ser desenvolvido. Hoje, apenas dois dos quatro m-
todos propostos mantm o desenvolvimento de novas prticas para cobrir diferentes
tipos de projetos.
Os membros da famlia Crystal so identificados por cores que indicam a inten-
sidade do mtodo. Neste caso, quanto mais escura a cor, maior a complexidade
do projeto.
Existem algumas caractersticas comuns famlia Crystal, tais como o desen-
volvimento incremental com ciclos de no mximo quatro meses, nfase maior na
comunicao e cooperao das pessoas, no limitao de quaisquer prticas de de-
senvolvimento, ferramentas ou produtos de trabalho e incorporao de objetivos para
reduzir produtos de trabalho intermedirios e desenvolv-los como projetos evoludos.
O ciclo de vida composto pelos seguintes estgios: staging, edio e reviso,
monitoramento, paralelismo e fluxo, inspees de usurios, workshops refletivos,
local matters, produtos de trabalho (WorkProducts), padres (standards) e ferra-
menta (tools).
2.1.5.5 Desenvolvimento Dirigido a Funcionalidades (FDD)

Trata-se de um mtodo gil de abordagem adaptativa. O FDD foi originalmente
concebido por Peter Coad e seus colegas como um modelo prtico de processo para
a engenharia de software orientado a objetos.
No contexto do FDD, uma caracterstica uma funo valorizada pelo cliente
que pode ser implementada em duas semanas ou menos (PRESSMANN, 2011, p.
98). A nfase na definio de caractersticas fornece os seguintes benefcios:
Como as caractersticas so pequenos blocos de funcionalidade passveis de

entrega, os usurios podem descrev-las mais facilmente, entender como elas
se relacionam umas com as outras mais prontamente e revis-las melhor quanto
a ambiguidades, erros ou omisses.
As caractersticas podem ser organizadas em um argumento hierrquico rela-
cionado ao negcio.
Como uma caracterstica um incremento de software passvel de entrega do
FDD, a equipe desenvolve caractersticas operacionais a cada duas semanas.
Como as caractersticas so pequenas, suas representaes de projeto e de
cdigo so mais fceis de inspecionar efetivamente.
Planejamento de projeto, cronogramao e monitorao so guiados pela
hierarquia de caractersticas em vez de por um conjunto de engenharia de
software arbitrariamente adotado.
2.2 Modelo evolucionrio

Como o prprio nome j sugere, os modelos evolucionrios so projetados para
acomodar um produto que evolui conforme o tempo e a necessidade.
Uma vez que o software evolui ao longo do tempo e conforme o desenvolvimento
do software avana, tambm temos mudanas nas necessidades de negcio e de pro-
dutos que mudam frequentemente. Isso torna inadequado seguirmos um planejamento
em linha reta de um produto. Os modelos de processo evolucionrio tornaram-se
realidade para que possamos desenvolver um produto que evolua ao longo do tempo.
2.2.1 Caractersticas
Modelos evolucionrios so caracterizados por serem iterativos e apresentarem pro-
priedades que possibilitem desenvolvermos verses cada vez mais completas do software.
O software evolui ao longo do tempo e conforme o desenvolvimento avana,
tambm temos mudanas nas necessidades de negcio e de produtos que mudam
frequentemente. Isso torna inadequado seguirmos um planejamento em linha reta de
um produto. Os modelos de processo evolucionrio tornaram-se realidade para que
possamos desenvolver um produto que evolua ao longo do tempo.
Modelos evolucionrios so caracterizados por serem iterativos e apresentarem
caractersticas que possibilitem desenvolvermos verses cada vez mais completas
do software.
Em muitos casos, o tempo de colocao de um produto no mercado o requisito
mais importante a ser gerenciado. Se o momento oportuno de entrada no mercado
for perdido, o projeto de software pode ficar sem sentido. Os modelos de processo
evolucionrio foram concebidos para tratar dessas questes e, mesmo assim, como
uma classe genrica de modelos de processo, apresentam seus pontos fracos:
O primeiro que a prototipao (e outros processos evolucionrios mais sofis-
ticados) traz um problema para o planejamento do projeto pelo nmero incerto
de ciclos necessrios para construir o produto. A maior parte dessas tcnicas

de gerenciamento e de estimativas do projeto baseia-se em layouts lineares das
atividades, o que faz com que no se adequem completamente.
Segundo, os processos de software evolucionrios no estabelecem a velocidade
mxima da evoluo. Se as evolues ocorrerem numa velocidade excessiva-
mente rpida, sem um perodo de acomodao, certo que o processo cair
no caos. Por outro lado, se a velocidade for muito lenta, ento a produtividade
poderia ser afetada.
Terceiro, os processos de software devem manter seu foco mais na flexibilidade
e na extensibilidade do que na alta qualidade. Entretanto, deve-se priorizar
mais a velocidade de desenvolvimento do que a do desenvolvimento com zero
defeito. Prolongar o desenvolvimento em busca da alta qualidade pode resultar
em entrega tardia do produto, quando o nicho de oportunidade j desapareceu.
Essa mudana de paradigma imposta pela concorrncia em situaes em que
se est beira do caos.
O objetivo dos modelos evolucionrios desenvolver software de alta qualidade
de modo iterativo ou incremental. Entretanto, possvel usar um processo evolucion-
rio para enfatizar a flexibilidade, a extensibilidade e a velocidade do desenvolvimento.
O desafio para as equipes de software e seus gerentes ser estabelecer um equilbrio
apropriado entre esses parmetros crticos de projeto e produto e a satisfao do
cliente (o ltimo a aprovar a qualidade do software).
Tem como base a ideia de desenvolver uma implementao inicial, expor o re-
sultado ao usurio e fazer seu aprimoramento por meio de muitas verses, at que
tenha sido desenvolvido.
Figura 2.5 Atividades concorrentes
Especificao Verso inicial
Esboo de Verso
Desenvolvimento
descrio Intermediria
Validao Verso final

O modelo evolucionrio apresenta vantagens, como o fato de um sistema fun-

cional ser apresentado antecipadamente ou de o cliente se envolver na avaliao
do prottipo.
Contudo as desvantagens desse modelo tambm existem: uma delas que o pro-
cesso de desenvolvimento no visvel, pois, como o sistema desenvolvido rapida-
mente, no h tempo de documentar a verses. Alm disso, os sistemas tendem a ser
mal estruturados e sua mudana constante pode corromper a estrutura do software.
O modelo evolucionrio aplicvel a sistemas interativos de pequeno ou mdio
porte. Tambm aplicvel para partes de sistemas grandes, como a interface com o
usurio. Alm disso, tambm usado em sistemas de vida curta.
2.2.2 Modelos de processo evolucionrios

Dentro os modelos de processos evolucionrios, destacamos:
2.2.2.1 RUP RationalUnifiedProcess

O RUP (RationalUnifiedProcess) um exemplo de modelo de processo moderno,
derivado de trabalhos sobre a UML (ferramenta de Diagramas de Caso de Uso) e o
Unified Software DevelopmentProcess associado. Ele rene elementos de todos os
modelos de processo genrico, ilustra boas prticas na especificao e no projeto e
apoia a prototipao e a entrega incremental.
O RUP reconhece que os modelos de processo convencionais apresentam uma
viso nica do processo. Em contrapartida, ele normalmente descrito em trs
perspectivas:
Uma perspectiva dinmica, que mostra as fases do modelo ao longo do tempo.
Uma perspectiva esttica, que mostra as atividades realizadas no processo.
Uma perspectiva prtica, que sugere boas prticas a serem usadas durante o
processo.
A perspectiva prtica sobre o RUP descreve as boas prticas da engenharia de
software que so recomendadas para uso no desenvolvimento de sistemas. Seis boas
prticas fundamentais so recomendadas:
1. Desenvolver software iterativamente.
2. Gerenciar os requisitos.
3. Usar arquiteturas baseadas em componentes.
4. Modelar o software visualmente.
5. Verificar a qualidade do software.
6. Controlar as mudanas do software.
A maioria das descries do RUP tenta combinar as perspectivas esttica e dinmica

em um nico diagrama. Ele um modelo constitudo de fases que identifica quatro fa-
ses distintas no processo de software: concepo, elaborao, construo e transio.
No entanto, ao contrrio do modelo em cascata, no qual as fases so equalizadas

com as atividades do processo, as fases do RUP so estreitamente relacionadas ao
negcio, e no a assuntos tcnicos. Cada fase pode comportar vrias iteraes, e
cada iterao est organizada em workflows, que descrevem o que deve ser feito em
termos de atividades reponsveis e artefatos.
As iteraes tambm so finalizadas com milestones, que devem controlar se fo-
ram cumpridos os objetivos especficos da iterao, como a realizao de um grupo
de casos de uso, por exemplo. O RUP possui nove workflows, seis de engenharia de
software e trs de suporte. Os workflows de engenharia so modelagem de negcio,
requisitos, anlise e projeto, implementao, teste, distribuio. Os workflows de
suporte compreendem atividades necessrias para a execuo dos workflows de
engenharia. So eles: gerncia de projeto, gerncia de configurao e mudanas e
configurao do ambiente.
2.2.2.2 Cascata
O modelo cascata tornou-se conhecido na dcada de 1970 e referenciado na
maioria dos livros de engenharia de software ou manuais de padres de software.
Nele, as atividades do processo de desenvolvimento so estruturadas numa cascata
onde a sada de uma a entrada para a prxima.
As suas principais atividades (Figura 2.6) so:
engenharia de sistemas (estudo de viabilidade);
anlise (especificao de requisitos);
projeto (design e especificao);
codificao e testes de componentes;
teste do sistema e integrao;
entrega e instalao;
manuteno.
Figura 2.6 Ciclo de vida do modelo em cascata

Esse modelo, quando proposto, introduziu importantes qualidades ao desenvolvi-

mento. A primeira chama a ateno de que o processo de desenvolvimento deve ser
conduzido de forma disciplinada, com atividades claramente definidas, determinada
a partir de um planejamento e sujeitas a gerenciamento durante a realizao.
Outra qualidade define de maneira clara quais so essas atividades e quais os
requisitos para desempenh-las. Por fim, o modelo introduz a separao das atividades
da definio e design da atividade de programao que era o centro das atenes no
desenvolvimento de software.
O modelo Cascata tambm criticado por ser linear, rgido e monoltico. Inspi-
rados em modelos de outras atividades de engenharia, argumenta que cada atividade
apenas deve ser iniciada quando a outra estiver terminada e verificada. Ele consi-
derado monoltico por no introduzir a participao de clientes e usurio durante as
atividades do desenvolvimento, mas apenas aps o software ter sido implementado e
entregue. No existe como o cliente verificar antecipadamente qual o produto final
para detectar eventuais problemas.
2.2.2.3 Incremental
uma adaptao da forma de pensar o desenvolvimento de software como um de-
senvolvimento linear, pois se trata de um arranjo de vrios pequenos ciclos em cascata.
A diferena que cada verso do produto de software tem uma nova funciona-
lidade (incremento), definida no incio desse ciclo. Depois de desenvolvida cada
verso, ser entregue ao usurio para testes. Cada verso implementa uma nova
funcionalidade (incremento).
O modelo que a verso evolucionria do Modelo Sequencial Linear. O software de-
senvolvido pode sempre crescer e agregar novas funcionalidades, assim ser desenvolvido
por um incremento e esse incremento segue todas as etapas descritas no modelo linear.
O modelo incremental muito utilizado em projetos longos e que tendem a
crescer com o passar do tempo e o prazo de entrega curto. Como, ao final de cada
incremento, gerada uma verso do produto final, possvel mostrar ao cliente como
est o andamento do projeto e atingir as metas definidas no comeo.
Em cada incremento realizado todo o ciclo do desenvolvimento de software,
do planejamento aos testes do sistema j em funcionamento. Cada etapa produz um
sistema totalmente funcional, apesar de ainda no cobrir todos os requisitos. Alguns
projetos de software definem requisitos iniciais de software razoavelmente bem defini-
dos. Pode ser necessrio o rpido fornecimento de um determinado conjunto funcional
aos usurios, para que aps esse fornecimento possamos melhorar e expandir suas
funcionalidades em verses de software posteriores. Nesses casos, podemos optar
por um modelo de processo que desenvolve software de uma forma incremental.
Podemos notar pela Figura 2.7 que o modelo de processo incremental aplica
sequncias lineares (como no modelo cascata) de forma escalonada, medida que
o tempo for avanando. Cada uma das sequncias lineares gera um incremento do
software. Esses incrementos so entregveis e prontos para o cliente.
Figura 2.7 Ciclo de vida do modelo incremental
O modelo de processo incremental entrega um produto operacional a cada in-

cremento, ou seja, um produto sem erros e pronto para o usurio utilizar. Mesmo
que os primeiros incrementos sejam partes do produto, essas partes so operacionais
e funcionam sem as outras. Portanto, os incrementos possuem totais condies de
atender ao usurio.
2.2.2.4 Espiral
O objetivo do modelo espiral prover um modelo que pode acomodar diversos
processos especficos. Prev prototipao, desenvolvimento evolutivo e cclico, e as
principais atividades do modelo cascata.
Sua principal inovao guiar o processo de desenvolvimento gerado a partir
desse modelo com base em anlise de riscos e um planejamento que realizado
durante toda a evoluo do desenvolvimento.
Riscos so circunstncias adversas que podem surgir durante o desenvolvimento de
software impedindo o processo ou diminuindo a qualidade do produto. So exemplos
de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que
no podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que
sero utilizados no produto final etc. A identificao e o gerenciamento de riscos
hoje uma atividade importantssima no desenvolvimento de software por causa da
imaturidade da rea e da falta de conhecimento, tcnicas e ferramentas adequadas.
O modelo espiral descreve um fluxo de atividades cclico e evolutivo constitudo
de quatro estgios, em que no primeiro devem ser determinados objetivos, solues
alternativas e restries. No segundo devem ser analisados os riscos das decises do
estgio anterior. J o terceiro consiste nas atividades da fase de desenvolvimento,

incluindo design, especificao, codificao e verificao. Por fim o quarto estgio
compreende a reviso das etapas anteriores ao planejamento da prxima fase.
A Figura 2.8 mostra o modelo de ciclo de vida, o qual define quatro importantes
atividades:
Planejamento: determinao dos objetivos do sistema que ser desenvolvido,
restries impostas aplicao, tais como: desempenho, funcionalidade, ca-
pacidade de acomodar mudanas, meios alternativos de implementao.
Anlise de risco: anlise das alternativas e identificao/resoluo dos riscos.
Uma vez avaliados os riscos, podem-se construir prottipos para verificar se
so realmente robustos para servir de base para a evoluo futura do sistema.
Engenharia: desenvolvimento do produto do prximo nvel.
Avaliao do cliente: avaliao dos resultados de engenharia podem-se efetuar
a verificao e validao.
Figura 2.8 Ciclo de vida do modelo espiral
2.2.2.5 Prototipao
Prototipao uma abordagem baseada em uma viso evolutiva do desenvol-
vimento de software, afetando o processo como um todo. Envolve a produo de
verses iniciais prottipos de um sistema futuro com o qual possvel realizar
verificaes e experimentos, com o intuito de avaliar algumas de suas caractersticas
antes que o sistema venha realmente a ser construdo de forma definitiva.
Apesar de a prototipagem poder ser usada como um modelo de processo indepen-
dente, ela mais comumente usada como uma tcnica que pode ser implementada
dentro do contexto de qualquer processo (modelo cascata, espiral, por exemplo). In-
dependentemente da maneira como aplicado, o paradigma de prototipagem auxilia
o engenheiro de software e o cliente a entenderem melhor o que deve ser construdo

quando os requisitos esto confusos.
Utilizada como uma maneira de se obter informaes e apresentar essas infor-
maes aos usurios. O prottipo vai sendo melhorado at atingir o objetivo final,
ou seja, at que o mesmo atinja o sistema. A prototipagem pode ser:
Evolucionria: abordagem para o desenvolvimento do sistema em que um pro-
ttipo inicial produzido e refinado em vrios estgios at atingir o sistema
final. O objetivo da prototipao evolucionria fornecer aos usurios finais
um sistema funcionando.
Descartvel: um prottipo que usualmente uma implementao prtica do
sistema produzido para ajudar a levantar os problemas com os requisitos, e
depois descartado. O sistema ento desenvolvido usando algum outro pro-
cesso de desenvolvimento. O objetivo da prototipao descartvel validar
ou derivar os requisitos do sistema.

Reflita a respeito dos modelos de processos de desenvolvimento de software,
verificando qual modelo seria o melhor para uma empresa de desenvolvi-
mento de software nos dias de hoje.
1. De acordo com o que estudamos sobre modelos de processo, podemos
ento dizer que um exemplo de modelo de processo gil :
a) O modelo RAD.
b) A Programao Extrema.
c) O modelo incremental.
d) O Processo Unificado.
e) O modelo espiral.
2. Levando em considerao o ciclo de vida de um software, o qual descreve
sua existncia desde sua concepo at fim de sua utilizao e conside-
rando os mtodos de produo e dos processos de desenvolvimento de
software, analise os itens que se seguem.
I. A construo de um produto de software pressupe o compromisso

com um conjunto de requisitos antes do incio do desenvolvimento do
produto, seguido de um processo o qual finalizado com a implantao
do referido produto.
II. Em um modelo de processo de desenvolvimento em cascata, os testes
de software so realizados em todos estgios do desenvolvimento e
sua finalizao se d na fase de implementao.
III. Em uma empresa que tenha adotado um processo de desenvolvimento
de software em cascata, falhas no levantamento de requisitos tm maior
possibilidade de gerar grandes prejuzos do que naquelas que tenham
adotado desenvolvimento evolucionrio.
Considerando os itens anteriores, correto o que consta em:
a) I, II e III.
b) I, apenas.
c) II, apenas.
d) III, apenas.
e) I e II apenas
Fique ligado!
Nesta unidade, foram abordados os seguintes aspectos relativos aos requisitos
de software, engenharia de requisitos e ao gerenciamento de projetos rela-
cionados aos objetivos de aprendizagem:
Software o elemento-chave na evoluo de produtos e sistemas ba-
seados em computador e uma das mais importantes tecnologias no
cenrio mundial e, nos ltimos 50 anos, evoluiu de uma ferramenta
especializada em anlise de informaes e resoluo de problemas para
uma indstria propriamente dita. Porm, ainda temos problemas para
desenvolver software de boa qualidade dentro do prazo e do oramento
estabelecidos.
Softwares (programas, dados e informaes descritivas) contemplam
uma ampla gama de reas de aplicao e tecnologia. O software legado
continua a representar desafios especiais queles que precisam fazer
sua manuteno.
A engenharia de software engloba processos, mtodos e ferramentas

que possibilitam a construo de sistemas complexos baseados em
computador, dentro do prazo e com qualidade.
O processo de software incorpora cinco atividades estruturais: comu-
nicao, planejamento, modelagem, construo e emprego; e elas se
aplicam a todos os projetos de software. A prtica da engenharia de
software uma atividade de resoluo de problemas que segue um
conjunto de princpios bsicos.
Inmeros mitos em relao ao software continuam a levar gerentes e pro-
fissionais para o mau caminho, mesmo com o aumento do conhecimento
coletivo de software e das tecnologias necessrias para constru-los.
medida que for aprendendo mais sobre a engenharia de software, voc
comear a compreender por que esses mitos devem ser derrubados
toda vez que deparar com eles.
Um modelo de processo genrico para engenharia de software con-
siste num conjunto de atividades metodolgicas e de apoio (atividades
guarda-chuvas), aes e tarefas a realizar. Cada modelo de processo,
dentre os vrios existentes, pode ser descrito por um fluxo de processo
diferente, isto , descrio de como as atividades metodolgicas, aes
e tarefas so organizadas sequencial e cronologicamente.
Padres de processo so utilizados para resolver problemas comuns
encontrados como parte do processo de software.
Os modelos de processo sequenciais, tal como o de cascata, so os
paradigmas da engenharia de software mais antigos. Eles sugerem um
fluxo de processos linear que, frequentemente, inadequado para con-
siderar as caractersticas dos sistemas modernos (por exemplo, contnuas
alteraes, sistemas em evoluo, prazos apertados). Entretanto, tm,
realmente, aplicabilidade em situaes em que os requisitos so bem
definidos e estveis.
Modelos de processo incremental so iterativos por natureza e produzem
rapidamente verses operacionais do software. Modelos de processos
evolucionrios reconhecem a natureza iterativa e incremental da maioria
dos projetos de engenharia de software e so projetados para adequar
mudanas.
Esses modelos, como prototipao e o modelo espiral, produzem rapi-
damente artefatos de software incrementais (ou verses operacionais do
software). Podem ser adotados para ser aplicados por todas as atividades
de engenharia de software, desde o desenvolvimento de conceitos at
a manuteno do sistema a longo prazo.
O Processo Unificado um processo de software dirigido a casos pr-

ticos, centrado na arquitetura, iterativo e incremental, desenvolvido
como uma metodologia para os mtodos e as ferramentas da UML.
Uma filosofia gil na engenharia de software enfatiza a importncia
das equipes que se auto-organizam para que tenham o controle sobre
o trabalho realizado, sobre a comunicao e colaborao entre os
componentes da equipe e entre os desenvolvedores e seus clientes, o
reconhecimento de que as mudanas representam oportunidades e, por
fim, a nfase na entrega rpida do software para satisfazer o cliente.
O eXtremeProgramming (XP) o processo gil mais amplamente usado,
e que sugere um nmero de tcnicas inovadoras que possibilitam a
uma equipe gil criar verses de software rapidamente, priorizando os
envolvidos.

Concluindo a unidade podemos, ento, notar a importncia do software para a
sociedade, bem como a sua evoluo. Tambm notamos que nas ltimas dcadas
o desenvolvimento de produtos de software evoluiu muito e que vrios mtodos
de desenvolvimento foram criados, o que auxiliou muito para a adaptao das
mudanas ocorridas nas organizaes que produzem e consomem um software.
Podemos afirmar quer as Tecnologias de Informao so relativamente no-
vas, tm menos de 70 anos, e sua evoluo espantosa se compararmos com
outras tecnologias. Durante o seu desenvolvimento muitos mitos foram quebra-
dos, muitas atividades sofreram evoluo, tais como os modelos de processos
de software que at o incio da decada de 1980 eram ainda desconhecidos e
atualmente j temos um aparato muito grande e robusto de procedimentos que
auxiliam o desenvolvedor e/ou gerente de projeto em seu trabalho cotidiano.
H ainda espao para muitas mudanas que esto por vir, visto que o de-
sevolvimento web exige, agora, novas formas de atuao e de conheciemento
das tecnologias, pois esto centradas na conectividade e no compartilhamento
de tudo dados, som, vdeo em tempo real. Vendo isso, devemos encarar
como um novo e grande desafio para a criao de novos modelos de processos
que nos auxiliem nesta nova e desafiadora jornada.

1. Considerando o modelo de processo de desenvolvimento de software RUP,
e suas fases e artefatos, analise cada artefato com a sua respectiva fase em
que dever ser realizado:
FASES ARTEFATOS
Concepo I Avaliao de riscos iniciais
Elaborao II Relatrio de execuo (testes)
Construo III Modelo de projeto finalizado
Transio IV Modelo de negcio
V Projeto de arquitetura
De acordo com o quadro anterior, correto afirmar que:
a) I e IV correspondem fase de concepo e V fase de transio.
b) II corresponde fase de transio, III fase de construo e I, IV e V
fase de concepo.
c) I e IV correspondem fase de concepo, II fase de transio e III e
V de elaborao.
d) II corresponde fase de transio, V fase de elaborao, I e IV de
concepo e III de construo.
e) I e IV correspondem fase de elaborao, II fase de construo, III
fase de transio e V fase de concepo.
2. Na engenharia de software, qual o modelo de processo em que o cliente
deve declarar todos os requisitos explicitamente na primeira parte do
projeto, o qual gera insegurana, uma vez que eles s vezes no tm um
entendimento completo do mesmo. Para minimizar tal dificuldade, posta
em prtica uma tcnica utilizada para minimizar esse problema de defini-
o de requisitos conhecida como:
a) Modelo de processo em cascata.
b) Modelo de processo gil.
c) Modelo de processo unificado.
d) Modelo Scrum de projeto de software incremental.
e) Prototipao.
3. Um software que resida apenas na memria de leitura e que utilizado
para controlar produtos e sistemas para os mercados industriais e de con-
sumo chamado de:
a) Software bsico.
b) Software embutido.
c) Software de tempo real.
d) Software comercial.
e) Software de inteligncia artificial.
4. O modelo de processo de desenvolvimento de software em cascata, tam-
bm conhecido como modelo clssico do processo de desenvolvimento
de software, continua sendo usado para o desenvolvimento de sistemas
de informao. Analise as afirmativas que correspondam aos estgios do
modelo em cascata.
I. Anlise de Sistemas, Anlise de Negcio e Anlise tica.
II. Anlise de Sistemas, Programao e Testes.
III. Projeto de Sistemas, Testes e Manuteno.
IV. Projeto de Sistemas, Integrao e Terceirizao.
Est(o) correta(s) as afirmativas:
a) I e II.
b) I, II e III.
c) III apenas.
d) II e III.
e) III e IV.
5. De acordo com a evoluo histrica do software, podemos notar a ocor-
rncia da crise e a ocorrncia dos mitos de software. Sendo assim, analise
as sentenas a seguir e assinale a alternativa correta.
a) No que diz respeito crise do software correto afirmar que se refere
a problemas encontrados no desenvolvimento, tais como estimativas
de prazo e de custo frequentemente imprecisas; a produtividade das
pessoas da rea de software no tem acompanhado a demanda por seus
servios; e a qualidade de software s vezes menos que adequada.
b) Com relao aos mitos de software relacionados a cliente, certo
dizer: se ns estamos atrasados nos prazos, podemos adicionar mais
programadores e tirar o atraso, porm o que acontece na realidade
que o desenvolvimento de software no um processo mecnico
igual manufatura. Acrescentar pessoas a um projeto torna-o ainda
mais atrasado. Pessoas podem ser acrescentadas, mas somente de uma
forma planejada.
c) J em relao aos mitos administrativos, notamos que, enquanto no

tiver o programa funcionando, no teremos realmente nenhuma
maneira de avaliar sua qualidade, porm na realidade um programa
funcionando somente uma parte de uma configurao de software
que inclui todos os itens de informao produzidos durante a cons-
truo e manuteno.
d) Nos mitos profissionais, vimos que os requisitos de projeto modificam-
-se continuamente, mas as mudanas podem ser facilmente acomoda-
das, porque o software flexvel.
e) Ainda com relao ao mitos profissionais, podemos dizer que uma
declarao geral dos objetivos suficiente para se comear a escrever
programas podemos preencher os detalhes mais tarde.
Referncias
PRESSMANN, Roger S. Engenharia de software: uma abordagem profissional. 7. ed. Porto
Alegre: AMGH, 2011.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. So Paulo: Pearson, 2007.
Unidade 3
Engenharia
de requisitos e
gerenciamento de
projeto de software
Luis Cludio Perini
Objetivos de aprendizagem:
Compreender os conceitos dos requisitos de usurio e de sistema e
por que so escritos de forma diferente.
Saber a diferena entre requisitos funcionais e no funcionais.
Entender como os requisitos podem ser organizados em um docu-
mento de requisitos.
Compreender as principais atividades da engenharia de requisitos
e seus relacionamentos.
Entender as tcnicas de elicitao e anlise de requisitos.
Compreender a importncia da validao e das revises de requisitos.
Compreender por que o gerenciamento de requisitos necessrio e
como o mesmo apoia outras atividades da engenharia de requisitos.
Compreender as principais tarefas dos gerentes de projeto.
Compreender como a natureza do software torna o gerenciamento
de projeto mais difcil que o gerenciamento de projetos de outras
engenharias.
Descobrir a necessidade de planejamento de projetos.
Saber como as representaes grficas so usadas por gerentes de
projeto para representar cronogramas de projeto.
Ter a noo de gerenciamento de riscos e alguns riscos que podem
surgir em processos de software.
Seo 1: Requisitos de software

Nessa seo, abordaremos uma discusso sobre re-
quisitos de software bem como o processo de docu-
mentao e especificao de requisitos.
Seo 2: Engenharia de requisitos

Nessa seo, abordaremos as atividades envolvidas
no processo de engenharia de requisitos.
Seo 3: Gerenciamento de projetos de software

Nessa seo ser abordada uma viso geral do ge-
renciamento de projetos de software.
E n g e n h a r i a d e r e q u i s i t o s e g e r e n c i a m e n t o d e p r o j e t o d e s o f t w a r e 95
Introduo ao estudo
Talvez o maior problema que enfrentamos no desenvolvimento de sistemas de
software grandes e complexos seja o da engenharia de requisitos. Ela est relacionada
com a definio de que o sistema deve fazer suas propriedades emergentes desejveis
e essenciais e as restries quanto operao do sistema e quanto aos processos de
desenvolvimento de software. Voc pode, portanto, pensar na engenharia de requi-
sitos como o processo de comunicao entre os clientes e os usurios de software e
os desenvolvedores de software.
A engenharia de software no simplesmente um processo tcnico. Os requisitos
do sistema so influenciados pelas preferncias, recusas e preconceitos dos usurios,
alm das questes polticas e organizacionais. Esses fatores so caractersticas hu-
manas fundamentais, e novas tecnologias, como casos de uso, cenrios e mtodos
formais, no nos ajudam muito na resoluo desses difceis problemas.
Seo 1 Requisitos de software

Os requisitos de um sistema so as descries de tudo o que o sistema deve
realizar, ou seja, os servios que oferece bem como as restries em seu funciona-
mento. Os requisitos so o reflexo das necessidades dos clientes de como resolver
um determinado problema, de como controlar um dispositivo, controlar pedidos ou
encontrar determinadas informaes.
Nesta seo vamos ento aprender um pouco mais sobre o assunto.
Para saber mais

Iniciando nosso estudo sobre requisitos de software, acesse e leia: <http://www.devmedia.com.
br/introducao-a-requisitos-de-software/29580>.
1.1 Requisitos de software

Os requisitos de um sistema so descries dos servios fornecidos pelo sistema
bem como as suas restries operacionais. Requisitos esses que refletem as necessi-
dades dos clientes de um sistema que os ajude a resolver algum problema, tal como
controlar um dispositivo, enviar um pedido ou encontrar informaes. Esse processo
de descobrir, analisar, documentar e verificar esses servios e restries denominado
de engenharia de requisitos (RE Requirements Engineering).
O termo requisito no usado pelos desenvolvedores de software de forma consis-
tente, visto que em algumas situaes um requisito apenas uma declarao abstrata
de alto nvel de um servio que o sistema deve fornecer ou uma restrio do sistema.
J em outro extremo, uma definio formal e detalhada de uma funo do sistema.
Alguns dos problemas que surgem durante o processo de engenharia de requisitos

so resultantes da falta de uma separao entre esses diferentes nveis de descrio.
Sommerville (2007) faz distino entre eles usando o termo requisitos de usurio
para requisitos abstratos de alto nvel e requisitos de sistema para a descrio deta-
lhada do que o sistema deve fazer. Sommerville (2007, p. 80) diz que os requisitos
de usurio e de sistema podem ser definidos da seguinte maneira:
1. Requisitos de usurio so declaraes, em uma linguagem natu-
ral com diagramas, de quais servios so esperados do sistema
e as restries sob as quais ele deve operar.
2. Requisitos de sistema definem, detalhadamente, as funes, os
servios e as restries operacionais do sistema. O documento
de requisitos de sistema, tambm chamado de especificao
funcional, deve ser preciso. Ele deve definir exatamente o que
ser implementado. Pode ser parte do contrato entre o compra-
dor do sistema e os desenvolvedores de software.
A Figura 3.1 mostra o tipo de leitores para os requisitos de usurios e de sistemas;

os leitores de requisitos geralmente no se preocupam com o modo que o sistema ser
desenvolvido e tambm podem ser gerentes que no se interessam pelo detalhamento
dos recursos do sistema.
1.1.1 Requisitos funcionais e no funcionais

De acordo com Sommerville (2007) os requisitos de sistema de software so,
frequentemente, classificados em requisitos funcionais, requisitos no funcionais ou
requisitos de domnio:
1. Requisitos funcionais. So as declaraes de servios que o
sistema deve fornecer, como o sistema deve reagir a entradas
especficas e como o sistema deve se comportar em determinadas
situaes. Em alguns casos, os requisitos funcionais podem tam-
bm estabelecer explicitamente o que o sistema no deve fazer.
2. Requisitos no funcionais. So restries sobre os servios ou
as funes oferecidas pelo sistema. Eles incluem restries de
timing, restries sobre o processo de desenvolvimento e pa-
dres. Os requisitos no funcionais aplicam-se, frequentemente,
ao sistema como um todo. Em geral, eles no se aplicam s
caractersticas ou servios individuais de sistema.
3. Requisitos de domnio. So requisitos provenientes do domnio
da aplicao do sistema e que refletem as caractersticas e as
restries desse domnio. Podem ser requisitos funcionais ou
no funcionais.
Engenharia de requisitos e gerenciamento de projeto de software 97
Figura 3.1 Leitores de tipos de especificao
Gerentes de clientes
Usurios finais de sistemas
Requisitos de usurio Engenheiros de clientes
Gerentes de fornecedores
Arquitetos de sistemas
Usurios finais de sistemas

Engenheiros e clientes
Requisitos de sistemas
Arquitetos de sistemas
Desenvolvedores de software
Fonte: Adaptada de Sommerville (2007, p. 81).
1.1.1.1 Requisitos funcionais

Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Dependem
do tipo do software que est sendo desenvolvido, dos usurios aos quais o software
se destina e tambm da abordagem considerada pela organizao ao redigir os re-
quisitos. Os requisitos funcionais descrevem a funo do sistema detalhadamente,
suas entradas e sadas, excees etc.
Os requisitos funcionais de um sistema de software podem ser expressos de vrias
formas. Eles definem recursos especficos a serem fornecidos pelo sistema. Geral-
mente originaram do documento de requisitos de usurio e mostram que os requisitos
funcionais podem ser escritos em nveis diferentes de detalhes.
A impreciso na especificao de requisitos um dos motivos de muitos problemas
de engenharia de software. comum que um desenvolvedor de sistema interprete um
requisito ambguo de modo a simplificar sua implementao, pois frequentemente
isso no o que o cliente deseja. Novos requisitos necessitam ser definidos e mu-
danas devem ser projetadas no sistema. Com isso h atrasos na entrega do sistema
com um aumento dos custos.
Em princpio, a especificao de requisitos funcionais de um sistema deve ser
completa e consistente.
Completeza significa que todos os servios exigidos pelo usurio devem ser
definidos.
Consistncia significa que os requisitos no devem ter definies contraditrias.
Na prtica, em sistemas grandes e complexos, praticamente impossvel atingir
a consistncia e a completeza de requisitos. Uma razo para isso que fcil co-
meter erros e omisses quando se redigem especificaes para sistemas grandes e

complexos.
1.1.1.2 Requisitos no funcionais

Os requisitos no funcionais, como o prprio nome sugere, so aqueles no di-
retamente relacionados com as funes especficas fornecidas pelo sistema. Podem
estar relacionados com as propriedades do sistema tais como confiabilidade, tempo
de resposta e espao de armazenamento. Como resposta, os requisitos no funcionais
podem definir restries, como a capacidade dos dispositivos de E/S (entrada/sada)
e as representaes de dados usadas nas interfaces do sistema.
Os requisitos no funcionais esto raramente associados s caractersticas in-
dividuais do sistema; ao contrrio, eles especificam ou restringem as propriedades
emergentes de sistema. Assim sendo, podem especificar desempenho, proteo,
disponibilidade e outras.
Isso significa que eles so mais importantes do que os requisitos funcionais indi-
viduais, uma vez que os usurios do sistema em geral encontram meios de contornar
uma funo do sistema que no atenda s suas necessidades. Entretanto uma falha
no atendimento de um requisito no funcional pode significar que todo o sistema
intil. Por exemplo, se um sistema de controle de tempo real falhar em atender aos
requisitos de desempenho, as funes de controle no operaro corretamente.
Os requisitos no funcionais no esto relacionados apenas com o sistema de
software a ser desenvolvido; alguns deles podem restringir o processo que deve ser
usado para desenvolver o sistema. Eles surgem por causa das necessidades do usurio,
das restries de oramento, das polticas organizacionais, da necessidade de inte-
roperabilidade com outros sistemas de software ou hardware ou de fatores externos,
como regulamentos de segurana ou legislao a respeito da privacidade. A Figura 3.2
apresenta uma classificao de requisitos no funcionais
Voc pode observar, no diagrama, que os requisitos no funcionais podem vir de
caractersticas necessrias do software (requisitos de produto), da organizao que
desenvolve o software (requisitos organizacionais) ou de fontes externas.
Figura 3.2 Tipos de requisitos no funcionais
Facilidade de uso
Desempenho
Eciencia
Produto Espao
Conabilidade
Portabilidade
Entrega
Requisitos no
funcionais
Organizacionais Implementao
Padres
Interoperabilidade
Externos Dcos
Privacidade
Legais
Segurana
Sommerville (2007, p. 83) define os seguintes tipos de requisitos no funcionais:

Requisitos de produto.
Especificam o comportamento do produto, tais como os requisitos de desempe-
nho quanto rapidez com que o sistema deve operar e quanto de memria ele
requer; os requisitos de confiabilidade que definem a taxa aceitvel de falhas;
os requisitos de portabilidade e requisitos de usabilidade.
Requisitos organizacionais.
So oriundos de polticas e procedimentos da organizao do cliente e do de-
senvolvedor, incluindo padres de processo que devem ser usados, requisitos
de implementao, como a linguagem de programao, o mtodo de projeto
usado, e requisitos de entrega que especificam quando o produto e a sua do-
cumentao devem ser entregues.
Requisitos externos.
Abrangem todos os requisitos derivados de fatores externos ao sistema e seu
processo de desenvolvimento, incluindo: requisitos de interoperabilidade, o
qual define como o sistema interage com os sistemas em outras organizaes;
requisitos legais que devem ser seguidos para assegurar que o sistema funciona
dentro da lei; e requisitos ticos (aqueles includos no sistema para assegurar

que ele ser aceito por seus usurios e pelo pblico em geral).
Um requisito de produto restringe a liberdade dos projetistas na implementao
da interface com o usurio de sistema.
Um requisito organizacional especifica que o sistema deve ser desenvolvido
de acordo com um processo padro da empresa. O requisito externo derivado da
necessidade de o sistema estar em conformidade com a legislao de privacidade.
Um problema comum com os requisitos no funcionais que eles podem ser di-
fceis de verificar. Os usurios ou os clientes frequentemente definem esses requisitos
como metas gerais, como usabilidade, capacidade do sistema para se recuperar de
falhas ou resposta rpida ao usurio. Essas metas vagas causam problemas para os
desenvolvedores de sistema, pois eles deixam o escopo para interpretao e discusso
subsequentes, depois que o sistema entregue.
Sempre que possvel, voc deve escrever os requisitos no funcionais quanti-
tativamente, de modo que eles possam ser testados objetivamente. Na Tabela 3.1
podemos ver uma srie de mtricas possveis de serem utilizadas para especificar
as propriedades no funcionais do sistema. A voc pode medir essas caractersticas
quando o sistema estiver sendo testado para verificar se ele atendeu ou no aos re-
quisitos no funcionais; os clientes de um sistema podem considerar praticamente
impossvel traduzir suas metas em requisitos quantitativos. Para algumas metas, como
facilidade de manuteno, no existem mtricas. Eles no compreendem o que um
nmero que define a confiabilidade necessria, por exemplo, significa em termos de
sua experincia diria com sistemas de computador.
Tabela 3.1 Mtricas de especificao de requisitos no funcionais
Propriedade Medida
Transaes processadas por segundo
Velocidade Tempo de respostas de usurio por evento
Tempo de atualizao da tela
Kbytes
Tamanho
Nmero de memrias RAM
Tempo de treinamento
Facilidade de Uso
Nmero de frames de ajuda
Tempo mdio de falhas
Probabilidade de indisponibilidade
Confiabilidade
Taxa de ocorrncia de falhas
Disponibilidade
Tempo para reiniciar aps a falha
Robustez Porcentual de eventos que causam falhas
Probabilidade de corrupo de dados por falhas
Percentagem de declaraes dependentes
Portabilidade
Nmero de sistemas-alvo
Fonte: Sommerville (2007, p. 84).
Os requisitos no funcionais frequentemente entram em conflito e interagem com

outros requisitos funcionais e no funcionais.
Ser til se pudermos diferenciar os requisitos funcionais e no funcionais no
documento de requisitos, mas, na prtica, isso fcil de ser feito, uma vez que, se os
requisitos no funcionais forem definidos separadamente dos funcionais, ser difcil
verificar os relacionamentos entre eles. Porm, se eles forem definidos com os re-
quisitos funcionais, podemos ter dificuldade em separar as consideraes funcionais
e no funcionais e identificar os requisitos relacionados ao sistema como um todo.
Mas, devemos, ento, destacar explicitamente os requisitos claramente relacionados
com as propriedades do sistema, como o desempenho e a confiabilidade, e desse
modo colocar os requisitios em uma seo distinta do documento de requisitos ou
diferenciando-os, de alguma forma, dos demais requisitos de sistema.
1.1.1.3 Requisitos de domnio

Os requisitos de domnio so derivados do domnio de aplicao do sistema, em
vez das necessidades especficas dos usurios do sistema. Podem ser novos requisitos
funcionais em si, mas tambm restringir os requisitos funcionais existentes ou esta-
belecer como clculos especficos devem ser realizados. Como esses requisitos so
especializados, os engenheiros de software muitas vezes encontram dificuldade em
compreender como eles esto relacionados a outros requisitos do sistema.
Os requisitos de domnio so importantes porque refletem os fundamentos do
domnio da aplicao. Caso esses requisitos no sejam satisfeitos, pode ser difcil
fazer que o sistema funcione satisfatoriamente.
Sommerville (2007, p. 85) ilustra os requisitos de domnio por meio da especifi-
cao de requisitos de sistemas de proteo de trem automatizado, na qual clculos
devem ser realizados, pois esse sistema para automaticamente um trem caso ele ul-
trapasse um sinal vermelho. Com esse requisito definido como a desacelerao do
trem calculada pelo sistema, usando para isso a terminologia especfica do domnio;
para que seja compreensvel, necessrio algum conhecimento sobre operao de
sistemas ferrovirios e das caractersticas do trem. Tal exemplo ilustra um grande
problema com os requisitos de domnio: na maioria das vezes eles so redigidos na
linguagem de domnio da aplicao (equaes matemticas, nesse caso), e geralmente
os engenheiros de software tm dificuldade em compreend-los. Os especialistas de
domnio podem deixar determinadas informaes fora de um requisito, simplesmente
por serem muito bvias para eles.
1.1.2 Requisitos de usurio

Os requisitos de usurio de um sistema devem descrever os requisitos funcionais
e no funcionais, de uma maneira que sejam compreensveis pelos usurios que no
possuam um conhecimento tcnico do sistema. Esses requisitos devem especificar
apenas o comportamento externo e evitar caractersticas de projeto do sistema. Outro
cuidado que devemos ter enquanto escrevemos os requisitos de usurio no usar
jarges de software, notaes estruturadas ou formais ou descrever os requisitos por

meio da implementao do sistema. Devemos sempre que possvel ao escrever os
requisitos de usurio usar uma linguagem simples, com tabelas e formulrios simples
e diagramas intuitivos.
Entretanto, no meio do caminho alguns problemas podem surgir quando os requi-
sitos so redigidos em um documento com texto em linguagem natural, tais como:
a) Falta de clareza. s vezes, difcil usar a linguagem de maneira precisa e no
ambgua sem tornar o documento prolixo e difcil de ler.
b) Confuso de requisitos. Os requisitos funcionais, no funcionais, metas de
sistema e informaes de projeto podem no estar claramente diferenciados.
c) Fuso de requisitos. Vrios requisitos diferentes podem ser expressos juntos
como um nico requisito.
uma boa prtica separar os requisitos de usurio dos requisitos mais detalhados
do sistema em um documento de requisitos. De outro lado, os leitores no tcnicos
dos requisitos de usurio podem ser sobrecarregados por detalhes relevantes apenas
para os tcnicos. Os requisitos de usurio que incluem muitas informaes restringem
a liberdade do desenvolvedor do sistema de apresentar solues inovadoras para os
problemas de usurio e so difceis de ser compreendidos. Esse requisito de usurio
deve simplesmente enfocar os recursos principais a serem fornecidos.
Sempre que for possvel, devemos tentar associar uma justificativa lgica a cada
requisito do usurio. A justificativa deve esclarecer por que o requisito foi includo,
e particularmente til quando os requisitos so mudados.
Para minimizar os mal-entendidos ao redigir requisitos de usurio, Sommerville
(2007, p. 86) recomenda que devemos usar algumas diretrizes simples:
1. Invente um formato padro e assegure se de que todas as defi-
nies de requisitos aderiram a esse formato. A padronizao
de formato toma as omisses menos provveis e os requisitos
mais fceis de serem verificados. O formato que uso mostra o
requisito inicial em negrito, inclui uma declarao da justifi-
cativa lgica de cada requisito de usurio e uma referncia
especificao detalhada de requisitos do sistema. Voc pode
tambm incluir informaes sobre quem props o requisito de
modo que se saiba a quem consultar se o requisito tiver de ser
mudado.
2. Use a linguagem de forma consistente. Voc deve sempre fazer
distino entre requisitos obrigatrios e desejveis. Requisitos
obrigatrios so aqueles a que o sistema deve atender e so
escritos com o uso da palavra deve. Requisitos desejveis no
so essenciais e so escritos com o uso da palavra pode.
3. Use destaque no texto (negrito, itlico ou cor) para ressaltar as
partes principais do requisito.
4. Evitar, sempre que possvel, o uso de jarges de informtica.
Contudo, inevitavelmente aparecero termos tcnicos detalha-
dos nos requisitos de usurio.
1.1.3 Requisitos de sistema

Os requisitos de sistema so verses expandidas dos requisitos de usurio, agora
sendo utilizados pelos engenheiros de software como ponto de partida para o projeto
do sistema. Esses engenheiros de software adicionam detalhes e explicam como os
requisitos de usurio devem ser fornecidos pelo sistema e tambm podem ser usados
como parte do contrato para a implementao do sistema e devem, dessa forma, ser
uma especificao completa e consistente de todo o sistema.
Idealmente, os requisitos de sistema devem descrever o comportamento externo
do sistema bem como suas restries operacionais, no devendo ficar relacionados
com a forma na qual o sistema pode ser projetado ou implementado. Porm, para
especificar completamente um software complexo no nvel de detalhamento neces-
srio, impossvel, na prtica, excluir todas as informaes de projeto. Podemos
identificar algumas razes para tal:
a) A necessidade de projetar uma arquitetura inicial do sistema para auxiliar
na estruturao da especificao de requisitos, os quais so organizados de
acordo com os diferentes subsistemas que constituem o sistema.
b) Na maioria das vezes, os sistemas devem interoperar com outros sistemas
existentes, com isso restringindo o projeto; essas restries impem novos
requisitos ao novo sistema.
c) Utilizar uma arquitetura especfica para satisfazer os requisitos no funcionais
(tal como programao de n verses para conseguir a confiabilidade) pode
ser necessrio. Um rgo certificador externo que necessite certificar que o
sistema seguro pode especificar que um projeto de arquitetura que j tenha
sido certificado seja usado.
O uso de uma linguagem natural muito til para redigir especificaes de re-
quisitos de sistema bem como de usurio. Porm, como os requisitos de sistema so
mais detalhados que os de usurio, as especificaes em linguagem natural podem
ser difceis de ser compreendidas. Dessa forma:
a) A compreenso da linguagem natural depende do uso das mesmas palavras
para os mesmos conceitos pelos leitores e pelos elaboradores da especificao
e isso pode levar a mal-entendidos por causa de palavras com duplo sentido
da linguagem natural.
b) Especificar requisitos em linguagem natural flexvel demais, pois podemos
dizer a mesma coisa de maneiras completamente diferentes, ficando a cargo
do leitor descobrir quando os requisitos so ou no os mesmos.
c) No h uma forma fcil de padronizar os requisitos usando uma linguagem
natural. Pode ser difcil encontrar todos os requisitos relacionados e, para
descobrir as consequncias de uma mudana, s vezes necessrio verificar
todos os requisitos em vez de apenas um grupo de requisitos relacionados.
Por causa de problemas, as especificaes de requisitos escritas em linguagem

natural so propensas a mal-entendidos. Eles frequentemente no so descobertos at
as fases finais do processo de software e, portanto, sua soluo pode ser muito onerosa
1.1.3.1 Especificaes em linguagem estruturada

A linguagem natural estruturada uma forma de escrever os requisitos de sistema,
na qual a liberdade do elaborador de requisitos limitada e todos os requisitos so
redigidos de maneira padronizada. A vantagem dessa abordagem que ela mantm
a maior parte da facilidade de expresso e compreenso da linguagem natural, mas
assegura que algum grau de uniformidade seja imposto nas especificaes. As no-
taes de linguagem estruturada limitam a terminologia que pode ser usada e usa
templates para especificar os requisitos de sistema. Elas podem incorporar constru-
es de controle derivadas de linguagens de programao e destaques grficos para
dividir a especificao.
1.1.4 Documento de requisitos de software

O documento de requisitos de software tambm chamado de especificao de
requisitos de software ou SRS (Software Requirements Specification) a declarao
oficial do que os desenvolvedores de sistema devem implementar, devendo incluir
os requisitos de usurio de um sistema e uma especificao detalhada dos requisitos
de sistema; em alguns casos, os requisitos de usurio e de sistema podem estar in-
tegrados em uma nica descrio. J em algumas situaes, os requisitos de usurio
esto definidos em uma introduo especificao dos requisitos de sistema e, nesse
caso, se houver um grande nmero de requisitos, os requisitos detalhados de sistema
podem ser apresentados em um documento separado.
O documento de requisitos possui um conjunto diversificado de usurios, desde a
gerncia snior da organizao, que paga pelo sistema, at os engenheiros respons-
veis pelo desenvolvimento do software. A Tabela 3.2 apresenta os possveis usurios
do documento de requisitos e como fazem uso deles.
Tabela 3.2 Usurio de um documento de requisitos
Usurios Uso
Especificam e leem os requisitos para verificar se eles atendem s
Clientes de sistema suas necessidades
Os clientes especificam as mudanas nos requisitos
Usam o documento de requisitos para planejar um pedido de proposta
Gerentes
para o sistema e planejar o processo de desenvolvimento do sistema
Engenheiros de sistema Usam os requisitos para compreender qual sistema ser desenvolvido
Engenheiros de testes de
Usam os requisitos para desenvolver testes de validao para o sistema
sistema
Engenheiros de manu- Usam os requisitos para compreender o sistema e os relacionamentos
teno de sistema entre as partes
Fonte: Adaptada de Kotonya e Sommerville (1998 apud SOMMERVILLE, 2007, p. 91).
Como h uma grande diversidade de possveis usurios, isso nos leva a crer
que o documento de requisitos precisa ser um compromisso entre a comunicao
dos requisitos para os clientes, a definio dos requisitos em detalhes precisos para
os desenvolvedores e testadores e a incluso de informaes sobre uma possvel
evoluo do sistema. O nvel de detalhamento a ser includo em um documento de
requisitos depende do tipo de sistema que est sendo desenvolvido e do processo de
desenvolvimento usado. No caso de o sistema utilizar um desenvolvedor externo, as
especificaes de sistema crtico devem ser precisas e muito detalhadas. J se usar-
mos um processo de desenvolvimento interno e iterativo, o documento de requisitos
pode ser muito menos detalhado e qualquer ambiguidade ser resolvida durante o
desenvolvimento do sistema.
Para saber mais

Para saber mais sobre documentos de requisitos acesse:
<http://www.devmedia.com.br/artigo-engenharia-de-software-10-documento-
de-requisitos/11909>.
De acordo com Sommerville (2007), uma srie de grandes organizaes, dentre as

quais o Departamento de Defesa dos EUA e o IEEE, definiu padres para documentos
de requisitos. O padro do IEEE sugere a seguinte estrutura para os documentos de
requisitos:
1. Introduo
1.1 Propsito do documento de requisitos
1.2 Escopo do produto
1.3 Definies, acrnimos e abreviaturas
1.4 Referncias
1.5 Viso geral do restante do documento
2. Descrio geral
2.1 Perspectiva do produto
2.2 Funes do produto
2.3 Caractersticas dos usurios
2.4 Restries gerais
2.5 Suposies e dependncias
3. Requisitos especficos
Abrangem requisitos funcionais, no funcionais e de interface. Esta , obvia-
mente, a parte mais substancial no documento, mas, pela grande variao na
prtica organizacional, no apropriado definir uma estrutura-padro para
esta seo. Os requisitos podem documentar interfaces externas, descrever a
funcionalidade e o desempenho do sistema, especificar requisitos lgicos de

banco de dados, restries de projeto, propriedades emergentes do sistema
e caractersticas de qualidade.
4. Apndices
5. ndice
Naturalmente, as informaes includas em um documento de requisitos
devem depender do tipo de software que est sendo desenvolvido e da abor-
dagem usada para o desenvolvimento. Caso seja adotada uma abordagem
evolucionria para um produto de software, o documento de requisitos deixar
de fora vrios captulos detalhados sugeridos anteriormente e o foco ser a
definio dos requisitos de usurio e dos requisitos no funcionais de alto
nvel do sistema. Nesse caso, os projetistas e os programadores usam suas
avaliaes para decidir como atender aos requisitos de usurios delineados
para o sistema.
Por outro lado, quando o software parte de um grande projeto de engenharia
que inclui a interao de sistemas de hardware e de software, frequentemente
indispensvel definir os requisitos em um nvel refinado de detalhes. Para documen-
tos extensos, importante incluir uma tabela abrangente de contedo e ndice do
documento, para que os leitores possam encontrar as informaes de que precisam.
Os documentos de requisitos so indispensveis quando um fornecedor externo
est desenvolvendo o sistema de software, os mtodos geis de desenvolvimento
argumentam que os requisitos mudam to rapidamente que um documento de requi-
sitos fica desatualizado to logo seja redigido, por isso o esforo desperdiado. Ao
contrrio de um documento formal, abordagens como eXtreme Programming propem
que os requisitos de usurio sejam coletados de maneira incremental e escritos em
cartes. O usurio, ento, prioriza os requisitos a serem implementados no prximo
incremento do sistema.
Para saber mais

Para que voc possa fixar melhor os conhecimentos leia
<http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-
de-requisitos/8034>.

Finalizando esta seo, gostaria que voc refletisse sobre a importncia de co-
letar corretamente os requisitos com os usurios principalmente os requisitos
no funcionais, pois atravs deles que definimos as restries do sistema.
1. Anlise as seguintes afirmaes sobre a anlise de requisitos de software.
I. Deve-se dar uma maior nfase aos aspectos tecnolgicos de
implementao.
II. importante a participao do usurio para a correta definio do
escopo e dos critrios para a avaliao da qualidade do software.
III. Os desenvolvedores devem se concentrar na definio dos domnios
funcionais, comportamentais e de informao de um problema.
Sobre as afirmaes, pode-se dizer que est correta:
a) Apenas I.
b) Apenas I e II.
c) Apenas I e III.
d) Apenas II e III.
e) Todas as afirmaes.
2. Levando em considerao a lista de requisitos de um sistema que ser
desenvolvido, a seguir.
I. O sistema dever emitir relatrios de compras a cada 15 dias.
II. O sistema s permitir a visualizao do campo valor mximo para
gerentes.
III. O sistema dever fornecer diariamente o relatrio de despesas.
IV. O sistema no poder excluir um fornecedor do cadastro se o forne-
cedor estiver inadimplente.
V. O sistema no permitir acesso aos registros de compras aps as 17h.
Considerando os requisitos anteriores, correto afirmar que:
a) I e V so requisitos no funcionais e II, III e IV so requisitos funcionais.
b) somente o requisito V no funcional.
c) I e V so requisitos funcionais e II,III e IV so requisitos no funcionais.
d) so todos requisitos no funcionais.
e) so todos requisitos funcionais.
Seo 2 Engenharia de requisitos

Compreender os requisitos de um problema est entre as tarefas mais difceis que
um engenheiro de software tem pela frente, e, quanto mais pensa nisso, mais difcil
parece ser enfrent-lo. Pois o cliente no sabe geralmente o que necessrio em
um sistema, os usurios finais no tm um bom entendimento das caractersticas e
funes que o software vai oferecer.
Os clientes e usurios finais devem ser explcitos quanto s suas necessidades e
que vo se modificar ao longo do projeto, por isso a engenharia de requisitos difcil.
Nesta seo, vamos, ento, nos aprofundar um pouco mais sobre o assunto.
2.1 Engenharia de requisitos

O objetivo do processo de engenharia de requisitos criar e manter um documento
de requisitos de sistema. O processo geral inclui quatro subprocessos de alto nvel
de engenharia de requisitos, sendo o primeiro relacionado ao estudo de viabilidade,
ou seja, avaliao de se o sistema til para a empresa (estudo de viabilidade); o
segundo com a elicitao e anlise, isto com a obteno de requisitos; o terceiro
com especificao, ou seja, com a converso desses requisitos em alguma forma
padro; e por fim a validao, que a checagem se os requisitos realmente definem
o sistema que o cliente deseja
A Figura 3.3 mostra o relacionamento das atividades do processo de engenharia
de requisitos, bem como os documentos produzidos em cada estgio do processo.
Para saber mais

Para saber mais sobre tcnicas de levantamento de requisitos leia:
<http://www.devmedia.com.br/artigo-engenharia-de-software-10-documento-de-requisitos/
11909>.
Figura 3.3 Processo de engenharia de requisitos
Estudo de Elicitao e
viabilidade anlise de
requisitos
Especificao
de requisitos
Relatrio de Validao
viabilidade de requisitos
Modelos de
Sistema
Requisitos de
usurios e de
sistema
Documentos
e requisitos
As atividades mostradas na Figura 3.3 relacionam-se obteno, documentao

e validao de requisitos, sendo que na prtica todos esses requisitos se alternam, e
as pessoas desenvolvem um maior entendimento naquilo que desejam que o sistema
faa, a organizao que est comprando o sistema muda e, dessa forma, podero ser
feitas mudanas no hardware, no software e no prprio ambiente do sistema; a isso
que chamamos de gerenciamento de requisitos.
Algumas pessoas consideram a engenharia de requisitos um processo no qual se
aplica um mtodo estruturado de anlise (por exemplo, anlise orientada a objetos,
ou anlise estruturada). Porm isso fica com a parte de anlise de sistemas e no
desenvolvimento de um conjunto de modelos grficos de sistemas, como modelos
de Use Case (casos de uso), que tm como objetivo servir como uma especificao
de sistema. O conjunto de modelos descreve o comportamento do sistema e inclui
anotaes com descries adicionais de informaes, por exemplo, o desempenho
ou a confiabilidade necessria.
Embora os mtodos estruturados possuam um papel a desempenhar no processo
de engenharia de requisitos, a elicitao de requisitos, em particular, uma atividade
centrada em pessoas, e as pessoas no gostam das restries impostas pelos modelos
rgidos de sistema.
2.2 Estudos de viabilidade

No incio de todos os sistemas novos, o processo de engenhana de requisitos deve
comear com um estudo de viabilidade, em que a entrada dessa atividade consiste
de um conjunto inicial dos requisitos de negcios, de um esboo da descrio do
sistema e de como o sistema pretende apoiar os processos de negcios. Os resultados
do estudo de viabilidade devem estar descritos em um relatrio que recomenda ou
no prosseguir com os processos de engenharia de requisitos e de desenvolvimento

do sistema em questo.
O estudo de viabilidade um estudo breve e focado que procura responder s
seguintes questes:
a) O sistema contribui para os objetivos gerais da organizao?
b) O sistema pode ser implementado com tecnologia atual e dentro das restries
definidas de custo e prazo?
c) O sistema pode ser integrado a outros sistemas j implantados?
Como podemos verificar se o sistema contribui ou no para os objetivos da em-

presa? Se o sistema no apoia esses objetivos, ele no tem valor real para a empresa.
Mesmo que parea bvio, muitas empresas desenvolvem sistemas que no contribuem
para seus objetivos, porque muitas delas no possuem um perfil claro desses objeti-
vos, pois falham na definio dos requisitos de negcios para o sistema, ou porque
outros fatores (polticos ou organizacionais) influenciaram na compra do sistema.
Na realizao de um estudo de viabilidade, necessrio fazer uma avaliao de
informaes, sua coleta e montagem de um relatrio. Logo aps a identificao das
informaes, necessrio falar com as fontes de informaes no intuito de descobrir
as respostas a essas questes. Para a coleta de tais informaes algumas perguntas
poderiam ser feitas:
a) Como a organizao se comportaria se esse sistema no fosse implementado?
b) Quais so os problemas com os processos atuais e como o novo sistema po-
deria ajudar na reduo desses problemas?
c) Qual ser a contribuio direta do sistema para os objetivos e requisitos da
empresa?
d) As informaes podem ser integradas (trocadas) com outros sistemas da
organizao?
e) O sistema necessitar de tecnologias que a empresa ainda no possui?
f) Quais processos podem e devem ser apoiados pelo sistema e quais no pre-
cisam ser apoiados?
Em um estudo de viabilidade, conveniente consultar fontes de informaes

tais como os gerentes dos setores nos quais o sistema ser usado, os engenheiros de
software j familiarizados com o tipo de sistema proposto, os especialistas em TI e
os usurios finais do sistema. Normalmente, o tempo para concluir tal estudo varia
de duas ou trs semanas.
De posse dessas informaes, monte o relatrio de estudo de viabilidade, no qual
voc deve fazer uma recomendao se o desenvolvimento do sistema deve ou no
prosseguir. Ainda no relatrio, podem-se propor mudanas de escopo, no oramento
e no prazo e tambm sugerir requisitos de alto nvel adicionais para o sistema.
2.3 Elicitao e anlise de requisitos

Nessa atividade, os engenheiros de software trabalham com os clientes e os usu-
rios finais do sistema para aprender sobre o domnio da aplicao, quais servios o
sistema deve fornecer, o desempenho esperado do sistema, restries de hardware etc.
A elicitao e a anlise de requisitos podem envolver vrias pessoas de uma
organizao. O stakeholder qualquer pessoa ou grupo afetado pelo sistema, direta
ou indiretamente, incluindo os usurios finais que interagem com o sistema e todo
pessoal na empresa que possa ser afetado por ele. Tambm podemos entender como
outros stakeholders no sistema os engenheiros que esto desenvolvendo ou mantendo
sistemas relacionados, os gerentes de negcios, os especialistas do domnio e at os
representantes do sindicato.
As razes da dificuldade dos stakeholders na elicitao e na compreenso dos
requisitos decorrem de:
a) Frequentemente no sabem o que querem do sistema a no ser em termos
gerais.
b) Expressam os requisitos naturalmente em seus prprios termos e com o co-
nhecimento implcito de seu trabalho.
c) Vrios stakeholders possuem diferentes requisitos, expressos de diferentes
formas e os engenheiros de requisitos precisam considerar todas as fontes
potenciais de requisitos e descobrir pontos em comum e conflitos.
d) Fatores polticos podem influenciar os requisitos do sistema, pois os gerentes
podem solicitar requisitos especficos do sistema que poder aumentar sua
influncia na organizao.
e) O prprio ambiente econmico e de negcios sobre o qual a anlise realizada
dinmico, ou seja, muda inevitavelmente durante o processo de anlise e,
dessa forma, a importncia de determinado requisito pode mudar.
As atividades de processo de elicitao e anlise de requisitos so:
Atividades Descrio
o processo de interao com os stakeholders no intuito
de coletar seus requisitos, incluindo os requisitos de
Obteno de requisitos
domnio que tambm so descobertos durante essa ativi-
dade, provenientes dos stakeholders e da documentao.
Essa atividade envolve a coleta de requisitos no estru-
Classificao e organizao de requisitos turados, agrupando os requisitos relacionados e organi-
zando-os em conjuntos coerentes.
Quando vrios stakeholders participam do processo,
inevitavelmente os requisitos sero conflitantes. Essa
Priorizao e negociao de requisitos atividade est relacionada priorizao de requisitos,
procura e resoluo de conflitos de requisitos por
meio da negociao.
Os requisitos so documentados, podendo ser produzi-
Documentao de requisitos
dos documentos de requisitos formais ou informais.
A elicitao e anlise de requisitos um processo iterativo com realimentao

contnua de cada atividade para outras atividades. como um ciclo comeado com
a obteno de requisitos e terminando com a documentao de requisitos. O enten-
dimento dos requisitos pelo analista aumenta a cada volta do ciclo.
A classificao e a organizao de requisitos esto relacionadas principalmente
com a identificao da sobreposio de requisitos dos diferentes stakeholders e o
agrupamento de requisitos relacionados. O modo mais comum de agrupamento de
requisitos usar um modelo de arquitetura de sistema para identificar os subsistemas
e associar os requisitos a cada um deles. Dessa forma a engenharia de requisitos e o
projeto de arquitetura nem sempre podem estar separados.
Uma vez que os stakeholders possuem vises diferentes sobre a importncia e a
prioridade dos requisitos e essas vises entram em conflito, devemos organizar nego-
ciaes contnuas com os stakeholders, a fim de que possamos atingir os compromis-
sos definidos. quase impossvel satisfazer completamente a todos os stakeholders,
pois, se alguns deles perceberem que suas vises no foram consideradas de maneira
apropriada, eles podem tentar boicotar intencionalmente o processo de engenharia
de requisitos (RE Requirements Engineering).
J no estgio de documentao, os requisitos so documentados de uma forma
que possam ser usados para ajudar as prximas obtenes de requisitos.
2.3.1 Obteno de requisitos

A obteno de requisitos o processo em que reunimos as informaes sobre o
sistema proposto e os existentes no intuito de obter os requisitos de usurio e de sis-
tema com base nessas informaes. As fontes de informaes, nessa fase de obteno
de requisitos, incluem documentao, os stakeholders de sistema e especificaes
de sistemas similares. J a interao com os stakeholders ocorre por intermdio de
entrevistas e observaes, podendo fazer uso de cenrios e prottipos como auxlio
na obteno dos requisitos.
Alm dos stakeholders no sistema, os requisitos podem ser oriundos do domnio de
aplicao e de outros sistemas que interagem com o que est sendo especificado, onde
esses dados devem ser considerados durante o processo de elicitao de requisitos.
Todas essas fontes de requisitos (stakeholders, domnio, sistemas) podem ser re-
presentadas como pontos de vista do sistema, onde cada ponto de vista apresenta um
subconjunto de requisitos do sistema e cada ponto de vista fornece uma perspectiva
nova do sistema, porm, essas perspectivas no so completamente independentes
uma vez que elas geralmente se sobrepem de modo que haja requisitos comuns.
2.3.1.1 Pontos de vista

As abordagens orientadas a pontos de vista para engenharia de requisitos orga-
nizam o processo de elicitao e os prprios requisitos usando pontos de vista. Um
ponto forte da anlise orientada a pontos de vista que ela reconhece vrias pers-
pectivas e fornece um framework para descobrir conflitos nos requisitos propostos

por diferentes stakeholders.
Os pontos de vista podem ser usados como um meio de classificao de stake-
holders e de outras fontes de requisitos. Existem trs tipos genricos de pontos de vista:
1. Pontos de vista de interao: representam pessoas ou outros sistemas que
interagem diretamente com o sistema.
2. Pontos de vista indiretos: representam os stakeholders que no usam o sistema
diretamente, mas que influenciam os requisitos de alguma forma.
3. Pontos de vista de domnio: representam caractersticas e restries de domnio
que influenciam os requisitos de sistema.
Tipicamente, esses pontos de vista fornecem diferentes tipos de requisitos. Os

pontos de vista de interao fornecem requisitos de sistema detalhados que abrangem
as caractersticas e as interfaces do sistema. Os pontos de vista indiretos so os que
mais provavelmente fornecem requisitos e restries organizacionais de alto nvel.
Os pontos de vista de domnio fornecem normalmente as restries de domnio que
se aplicam ao sistema.
Os pontos de vista de engenharia de requisitos podem ser importantes por
duas razes: primeiro, os engenheiros que desenvolvem o sistema podem ter expe-
rincia com sistemas similares e, dessa forma, sugerem requisitos levando em conta
sua experincia; e, segundo, o pessoal tcnico que deve gerenciar e manter o sistema
pode ter requisitos que ajudaro a simplificar o apoio ao sistema.
Assim sendo, os pontos de vista que fornecem requisitos podem ser provenientes
dos departamentos de marketing ou de negcios externos em uma organizao.
importante em sistemas de e-commerce e softwares comerciais. Nos sistemas basea-
dos na web devem apresentar uma imagem favorvel da empresa, e ao mesmo tempo
oferecer funcionalidade ao usurio. J no que diz respeito a produtos de software, o
departamento de marketing deve conhecer as caractersticas que tornaro o sistema
mais atraente aos compradores.
Em qualquer sistema no trivial, h um grande nmero de possveis pontos de vista,
e quase impossvel elicitar os requisitos baseado em todos eles. Dessa maneira,
importante que voc organize e estruture os pontos de vista hierarquicacamente, onde
pontos de vista do mesmo ramo provavelmente compartilharo requisitos comuns e,
depois que os pontos de vista forem identificados e estruturados, podemos, ento,
identificar os mais importantes e iniciar com eles a obteno dos requisitos do sistema.
2.3.1.2 Entrevista
Nos processos de engenharia de requisitos, as entrevistas com os stakeholders so
corriqueiras, e podem ser formais ou informais. Nelas so formuladas questes para
os stakeholders sobre o sistema que eles usam e sobre o sistema a ser desenvolvido
e os requisitos so obtidos das respostas a essas questes. Podemos classificar as
entrevistas em dois tipos:
Entrevistas fechadas, nas quais o stakeholder responde a um conjunto de per-

guntas predefinidas.
Entrevistas abertas, nas quais no existe um roteiro predefinido; a equipe de
engenharia de requisitos explora vrios assuntos com os stakeholders no sistema
e desenvolve uma compreenso maior de suas necessidades.
Na prtica, as entrevistas com os stakeholders so uma combinao desses tipos.
As entrevistas so teis para obter um entendimento geral sobre o que os stakeholders
fazem, como eles podem interagir com o sistema e as dificuldades que enfrentam
com os sistemas atuais.
difcil elicitar o conhecimento de domnio durante as entrevistas por dois
motivos:
a) O uso de terminologia e jarges especficos por parte dos especialistas de do-
mnio. impossvel para os especialistas explicar os requisitos de domnio sem
usar tal terminologia. Em geral a usam de maneira precisa e especfica, o que
facilmente provoca mal-entendidos por parte dos engenheiros de requisitos.
b) A familiaridade por parte dos stakeholders com alguns conhecimentos de
domnio que so considerados difceis de explicar ou so to fundamentais
que no vale a pena mencion-los.
A entrevista no uma tcnica eficiente para elicitao de conhecimentos sobre

os requisitos e as restries organizacionais, pois existem relacionamentos sutis de
poder e influncia entre os stakeholders na organizao.
Com relao s caractersticas que podemos elencar a respeito dos entrevistadores
podemos citar:
1. Possuem mente aberta, ou seja, evitam ideias preconcebidas sobre os requisitos
e buscam ouvir os stakeholders. Se estes propuserem requisitos inovadores,
os entrevistadores esto dispostos a mudar de ideia sobre o sistema.
2. Ao mesmo tempo que induzem os entrevistados a iniciar as discusses com
uma questo, uma proposta de requisitos ou sugerindo um trabalho conjunto
em um prottipo do sistema, dizer s pessoas conte-me o que voc quer
provavelmente trar informaes teis como resultado.
2.3.1.3 Cenrios
Em geral as pessoas acham mais fcil citar exemplos da vida real do que abstrair
descries das funes. Elas podem compreender e criticar um cenrio de como in-
teragiriam com um determinado sistema. J os engenheiros de requisitos podem usar
as informaes obtidas nessa discusso para elaborar os requisitos reais do sistema.
Os cenrios podem ser particularmente teis para adicionar detalhes a um esboo
da descrio de requisitos, em que cada cenrio abrange uma ou mais interaes
possveis e diversos tipos de cenrios podem ser desenvolvidos, cada um dos quais
fornecendo diferentes tipos de informaes sobre o sistema em diferentes nveis de
detalhamento. Em mtodos geis, so usados cenrios para descrever seus requisitos,

como o caso do eXtremeProgramming.
O uso da descrio de um cenrio comea com um esboo da interao e, durante
a etapa de elicitao, os detalhes so adicionados no intuito de criar uma descrio
completa dessa interao.
De acordo como Sommerville (2007, p. 102), um cenrio deve incluir:
1. Uma descrio do que os usurios esperam do sistema no incio
do cenrio.
2. Uma descrio do fluxo normal de eventos no cenrio.
3. Uma descrio do que pode dar errado e como isso tratado.
4. Informaes sobre outras atividades que podem ocorrer
simultaneamente.
5. Uma descrio do estado de sistema no fim do cenrio.
A elicitao baseada em cenrios pode ser realizada informalmente. Os cenrios

podem ser escritos na forma de textos e complementados por diagramas, imagens
de computador etc.
2.3.1.4 Casos de uso (use case)

uma tcnica baseada em cenrios para elicitao de requisitos. Tornaram-se uma
caracterstica fundamental da notao UML para descrio de modelos de sistema
orientado a objetos e, em sua notao mais simples, um caso de uso identifica o tipo
da interao e os agentes envolvidos.
A Figura 3.4 mostra os elementos essenciais da notao de caso de uso, em que
os atores do processo so representados como bonecos, e cada caso de uso (classe de
interao) representada como uma elipse identificada. O conjunto de casos de uso
representa todas as possveis interaes a serem representadas nos requisitos de sistema.
Os casos de uso identificam as interaes individuais com o sistema, de forma
que eles podem ser documentados por meio de texto ou de links com os modelos
UML que desenvolvem o cenrio mais detalhadamente. J os diagramas de sequncia
so frequentemente usados para adicionar informaes ao caso de uso. Os diagramas
de sequncia mostram os agentes envolvidos na interao, os objetos com os quais
interagem e as operaes associadas a esses objetos.
Figura 3.4 Notao de caso de rso
Caso de uso Ator
Fonte: Adaptada Sommerville (2007, p. 103).

A UML um padro real para a modelagem orientada a objetos, e, assim sendo,

os casos de uso e a elicitao baseada em casos de uso tm sido cada vez mais usados
para elicitao de requisitos.
Cenrios e casos de uso so tcnicas eficazes para elicitao de requisitos segundo
pontos de vista de interao, onde cada tipo de interao pode ser representado como
um caso de uso especfico. Eles tambm podem ser usados em conjunto com alguns
pontos de vista indiretos, sendo que esses pontos de vista recebem alguns resultados
(como um relatrio gerencial) do sistema. Contudo, como eles enfocam as interaes,
no so eficazes para elicitar restries ou requisitos de negcios e no funcionais de
alto nvel com base nos pontos de vista indiretos ou para obter requisitos de domnio.
2.3.2 Etnografia
Os sistemas de software so usados dentro de um contexto social e organizacional,
no existindo isoladamente, e seus requisitos podem ser derivados ou restringidos
por esse contexto. Satisfazer a esses requisitos sociais e organizacionais essencial
para o sucesso do sistema, pois uma das razes pelas quais vrios sistemas de soft-
ware so entregues, porm nunca usados, que no dada a devida importncia a
esses requisitos.
Segundo Sommerville (2007, p. 104), a etnografia uma tcnica de observao
que pode ser usada para compreender os requisitos sociais e organizados, onde um
analista se insere no ambiente de trabalho onde o sistema ser usado, faz observaes
do dia a dia e anota as tarefas reais nas quais os participantes esto envolvidos.
O uso da etnografia presta uma ajuda aos analistas na descoberta de requisitos
implcitos de sistema que refletem os processos reais, e no os formais, com os quais
as peas esto envolvidas. Geralmente as pessoas consideram muito difcil definir
detalhes de seu trabalho dirio, pois para elas isso secundrio. Elas compreendem
seu prprio trabalho, porm, muitas vezes no compreendem o relacionamento do
seu trabalho com os de outros setores da empresa. Outros fatores tambm afetam o
trabalho, tais como fatores sociais e organizacionais, mas que no so bvios para as
pessoas, e que necessitam ser examinados por um observador imparcial para poderem
se tornar claros. A diferena entre o trabalho suposto e o real a razo mais importante
pela qual os sistemas de escritrio no tiveram efeito significativo na produtividade.
A etnografia particularmente eficaz para descobrir dois tipos de requisitos:
Requisitos derivados da maneira como as pessoas realmente trabalham em vez da
maneira pela qual as definies de processo dizem que elas deveriam trabalhar.
Requisitos derivados da cooperao e do conhecimento das atividades de outras
pessoas.
Na Figura 3.5 podemos observar como a etnografia pode ser combinada com a
prototipao, pois a etnografia informa o desenvolvimento do prottipo de forma que
poucos ciclos de refinamento de prottipo sejam requeridos. Alm disso, a prototi-
pao enfoca a etnografia, identificando os problemas e as questes que podem ser
discutidos com o etngrafo, que deve, ento, procurar as respostas a essas questes
durante a prxima fase do estudo de sistema (SOMMERVILLE, 2007).
Figura 3.5 Etnografia e prototipao
Os estudos de etnografia podem revelar detalhes importantes do processo fre-

quentemente ignorados por outras tcnicas de elicitao de requisitos. Entretanto por
causa de seu foco no usurio final essa abordagem no apropriada na obteno de
requisitos organizacionais e de domnio. Assim, estudos etnogrficos nem sempre
podem identificar novas caractersticas a serem acrescidas a um sistema. Portanto, a
etnografia no uma abordagem completa para elicitao de requisitos e deve ser
usada para complementar outras abordagens, como a anlise de casos de uso.
2.4 Validao de requisitos

A validao de requisitos dedica-se a mostrar que os requisitos de fato definem
o sistema que o usurio deseja. Ela se sobrepe anlise, pois est relacionada
descoberta de problemas com os requisitos.
A importncia da validao de requisitos est no fato de que os erros em um
documento de requisitos podem acarretar custos excessivos de trabalho quando so
descobertos durante o desenvolvimento ou depois que o sistema est em operao.
O custo de correo de um problema de requisitos, fazendo uma mudana de
sistema, muito maior do que a correo de erros de projeto e de codificao. Uma
mudana de requisitos significa geralmente que o projeto e a implementao do
sistema devem tambm ser mudados e o sistema deve ser novamente testado.
Durante o processo de validao de requisitos, devem ser realizadas verificaes
nos requisitos do documento de requisitos como podemos observar no Quadro 3.1
(SOMMERVILLE, 2007).
Quadro 3.1 Verificaes nos documentos de requisitos
Tipo Descrio
Um usurio pode pensar que um sistema necessrio para
Verificaes de validade
desempenhar determinadas funes.
Os requisitos em um documento no devem ser conflitantes. Isso
Verificaes de consistncia significa que no devem existir restries ou descries contraditrias
para a mesma funo do sistema.
O documento de requisitos deve incluir requisitos que definam
Verificaes de completeza
todas as funes e as restries desejadas pelo usurio do sistema.
Usando o conhecimento da tecnologia existente, os requisitos
devem ser verificados quanto a se realmente podem ser imple-
Verificaes de realismo
mentados. Essas verificaes tambm devem levar em considera-
o o oramento e o prazo para o desenvolvimento do sistema.
Para reduzir o potencial de divergncias entre cliente e fornece-
Facilidade de verificao dor, os requisitos do sistema devem sempre ser escritos de modo
que sejam verificveis.
Fonte: Adaptado de Sommerville (2007, p. 106).
Ainda segundo Sommerville (2007), uma srie de tcnicas de validao de requi-

sitos pode ser usada em conjunto ou individualmente, tais como:
Revises de requisitos. Os requisitos so analisados sistematicamente por uma
equipe de revisores.
Prototipao. Um modelo executvel do sistema apresentado para usurios
finais e clientes. Eles podem experimentar o modelo para verificar se atende
s suas necessidades reais.
Gerao de casos de teste. Os requisitos devem ser testveis; se os testes dos
requisitos forem criados como parte do processo de validao, geralmente
revelaro problemas de requisitos.
No podemos subestimar os problemas de validao de requisitos, visto que

difcil demonstrar que um conjunto de requisitos atende s necessidades do usurio.
Por outro lado, os usurios devem imaginar o sistema em uso e avaliar sua adequao
ao trabalho. Torna-se difcil para profissionais de informtica habilidosos realizar esse
tipo de anlise abstrata e ainda mais difcil para os usurios do sistema.
2.4.1 Revises de requisitos

A reviso de requisitos um processo manual que envolve pessoas de ambas as
empresas (do cliente e do fornecedor), onde verificado o documento de requisitos
em busca de anomalias e omisses. O processo de reviso pode ser gerenciado da
mesma maneira que as inspees de programa.
As revises de requisitos podem ser formais ou informais; as revises informais en-
volvem os fornecedores, sendo discutidos os requisitos com o maior nmero possvel
de stakeholders. Vrios problemas podem ser detectados simplesmente conversando

sobre o sistema com eles antes do comprometimento de uma reviso formal.
Na reviso formal de requisitos, a equipe de desenvolvimento deve levar o
cliente pelos requisitos de sistema, explicando as implicaes de cada um. Os revi-
sores podem tambm checar a:
facilidade de verificao;
facilidade de compreenso;
rastreabilidade;
adaptabilidade.
Conflitos, contradies, erros e omisses nos requisitos devem ser apontados

pelos revisores e registrados formalmente no relatrio de reviso. Dessa forma
de responsabilidade dos usurios, do adquirente de sistema e do desenvolvedor de
sistema negociar uma soluo para os problemas identificados.
2.5 Gerenciamento de requisitos

Os requisitos de sistemas de software de grande porte esto sempre mudando.
Como o problema no pode ser totalmente definido, os requisitos de software tendem
a ser incompletos. Durante o processo de software, o entendimento dos stakeholders
sobre o problema muda constantemente. Esses requisitos devem, ento, evoluir para
refletir essas novas vises do problema.
Quando os usurios adquirirem experincia com o sistema, eles descobriro novas
necessidades e prioridades:
1. Sistemas de grande porte geralmente tm uma comunidade diversificada de
usurios, sendo que esses usurios tm diferentes requisitos e prioridades, os
quais podem ser conflitantes ou contraditrios.
2. As pessoas que pagam por um sistema e os usurios de um sistema raramente
so as mesmas pessoas. Os clientes do sistema impem requisitos por causa
de restries organizacionais e de oramento.
3. O ambiente de negcios e tcnico do sistema muda aps a instalao, e essas
mudanas devem se refletir no sistema. Um novo hardware pode ser introdu-
zido, pode ser necessria uma interface com outros sistemas, as prioridades
de negcios podem mudar trazendo consequentes mudanas no apoio ao
sistema, e um nova legislao e regulamentos podem ser introduzidos devendo
ser implementados no sistema.
O gerenciamento de requisitos um processo para compreender e controlar as

mudanas dos requisitos de sistema. Voc precisa manter o acompanhamento dos
requisitos individuais e manter as ligaes entre os requisitos dependentes, de modo
que seja possvel avaliar o impacto das mudanas de requisitos.
2.5.1 Planejamento de gerenciamento de requisitos

O planejamento o primeiro estgio essencial no processo de gerenciamento de
requisitos. O gerenciamento de requisitos muito dispendioso. Durante o estgio de
gerenciamento de requisitos, voc deve decidir sobre:
1. Identificao de requisitos.
Cada requisito deve ser identificado unicamente de modo que possa ser feita a
referncia cruzada entre este e outros requisitos para que ele possa ser usado
nas avaliaes de rastreabilidade.
2. Processo de gerenciamento de mudanas.
o conjunto de atividades que avaliam o impacto e custo das mudanas.
3. Polticas de rastreabilidade.
4. Definem os relacionamentos entre os requisitos e entre os requisitos e o
projeto do sistema, que devem ser registrados, e como esses registros devem
ser mantidos.
5. Apoio de ferramentas CASE.
O gerenciamento de requisitos envolve o processamento de grandes quan-
tidades de informaes sobre os requisitos. As ferramentas que podem ser
usadas variam desde sistemas especializados de gerenciamento de requisitos
a planilhas e sistemas simples de banco de dados.
A rastreabilidade a propriedade de uma especificao de requisitos que reflete
a facilidade de encontrar os requisitos relacionados. H trs tipos de informaes de
rastreabilidade que podem ser mantidos:
1. Informaes de rastreabilidade da origem ligam os requisitos aos stakeholders
que propuseram os requisitos e aos motivos desses requisitos.
2. Informaes de rastreabilidade de requisitos ligam os requisitos dependentes
dentro do documento de requisitos.
3. Informaes de rastreabilidade de projeto ligam os requisitos aos mdulos de
projeto, nos quais esses requisitos so implementados.
2.5.2 Gerenciamento de mudanas de requisitos

O gerenciamento de mudanas de requisitos deve ser aplicado a todas as mu-
danas propostas aos requisitos. Ele traz a vantagem de usar um processo formal
para gerenciamento de mudanas uma vez que todas as propostas de mudana so
tratadas de forma consistente e as mudanas no documento de requisitos so feitas
de maneira controlada. No Quadro 3.2 so mostrados os principais estgios para um
processo de gerenciamento de mudanas.
Quadro 3.2 Estgio de processos de gerenciamento de mudanas
Estgios Descrio
Anlise do problema e O processo se inicia com um problema de requisitos identifi-
especificao da mudana cado ou, s vezes, com uma proposta de mudana especfica.
O efeito da mudana proposta avaliado usando as informaes
de rastreabilidade e o conhecimento geral sobre os requisitos do
Anlise da mudana e
sistema. O custo de realizar a mudana estimado em termos
estimativa de custo
de modificaes no documento de requisitos e, se adequado, do
projeto e da implementao do sistema.
O documento de requisitos e, quando necessrio, o projeto e a
implementao de sistema so modificados. Voc deve organi-
Implementao da mudana
zar o documento de requisitos de modo que possa realizar as
mudanas sem reescrita ou reorganizao extensivas.
Se uma mudana de requisitos do sistema solicitada com urgncia, existe sem-

pre uma propenso a realizar a mudana no sistema e, depois, retrospectivamente,
modificar o documento de requisitos. Isso leva defasagem entre o documento de
requisitos e a implementao do sistema. Geralmente, feitas as mudanas no sistema,
as mudanas no documento de requisitos podem ser esquecidas ou realizadas de
maneira no consistente com as no sistema.
Os processos iterativos de desenvolvimento, como extreme programming, foram
definidos para lidar com requisitos que mudam durante o processo de desenvolvimento.

Considerando o processo de engenharia de requisitos, reflita sobre os motivos
que ainda levam muitos desenvolvedores a no fazer o uso de tal processo
quando iniciam um projeto de software.
1. Com relao s atividades descritas na seo, assinale dentre as alternativas
a atividade que NO faz parte da engenharia de requisitos.
a) Estudo de viabilidade.
b) Anlise de risco.
c) Levantamento de necessidades do cliente.
d) Verificao.
e) Gerenciamento.
2. [...] uma restrio sobre os servios ou sobre as funes oferecidas pelo
sistema, podendo ser uma restrio de timing (tempo), sobre o processo
de desenvolvimento, sobre o desempenho ou sobre a confiabilidade do
sistema etc [...]. Lendo o trecho, podemos afirmar que se refere a
a) Um requisito no funcional.
b) Um requisito funcional.
c) Especificao de risco.
d) A iterao de processo.
e) Etnografia.
Seo 3 erenciamento de projetos de

G
software
O gerenciamento de projetos de software uma parte essencial da engenharia de
software. Um bom gerenciamento no pode garantir o sucesso de um projeto, porm,
um mau gerenciamento geralmente resulta em falha do projeto e como consequncia
o software entregue com atraso, custa mais do que foi originalmente estimado e
falha ao atender seus requisitos.
Para saber mais

Aprofundando seus conhecimentos sobre gerncia de projetos leia:
<http://www.devmedia.com.br/gestao-de-projetos-de-software/9143>.
A responsabilidade dos gerentes de software inicia-se pelo desenvolvimento de

planos e cronogramas do projeto: eles supervisionam o trabalho para assegurar que
ele esteja sendo realizado dentro dos padres exigidos e monitoram o progresso para
verificar se o desenvolvimento est no prazo e dentro do oramento.
3.1 Gerenciamento de projetos

A necessidade de gerenciamento de projetos de software est no fato de que a
engenharia de software profissional est sempre sujeita s restries de oramento e
de cronograma da organizao. Com isso o trabalho do gerente de projeto de software
assegurar que este atenda a essas restries e entregue um software que contribua
para as metas da empresa que est desenvolvendo o software.
O tipo de trabalho dos gerentes de software e dos outros gerentes de projetos de
outras reas da engenharia o mesmo, porm o que difere o engenheiro de software
que ele possui algumas distines que tornam seu gerenciamento mais difcil. O
Quadro 3.3 traz algumas destas diferenas.
Quadro 3.3 Diferenas entre o trabalho do gerente de software ou demais gerentes de projetos
Diferena Descrio
O gerente de um projeto de construo de edifcio pode ver o
produto que est sendo construdo e, se o cronograma atrasar, o
efeito sobre o produto visvel. Porm o software intangvel, no
O produto intangvel pode ser visto ou tocado, os gerentes de projetos de software tm
dificuldades de verificar seu progresso. Eles contam com outras
pessoas para produzir a documentao necessria para examinar
o progresso.
continua
continuao
O processo de engenharia de alguns tipos de sistema, como pon-

tes e prdios, bem compreendido. Entretanto, os processos de
software variam de uma empresa para a outra. Mesmo que nossa
No existem processos-
compreenso sobre esses processos tenha crescido, ainda no
-padro de software
podemos prever, confiavelmente, quando determinado processo
de software provavelmente apresentar problemas de desenvolvi-
mento.
Projetos de software de grande porte so diferentes de projetos
anteriores. Assim sendo, mesmo com a experincia que os geren-
Projetos de software de
tes possuem difcil prever problemas. Alm disso, as mudanas
grande porte so, frequen-
tecnolgicas podem tornar a experincia dos gerentes obsoleta, e
temente, projetos nicos.
lies anteriores aprendidas no podem ser reutilizadas em novos
projetos.
Levando em considerao esses problemas, no surpresa que alguns projetos

de software se atrasem, ultrapassem o oramento e estourem o prazo de entrega.
Sistemas de software so geralmente novos e inovadores.
Projetos inovadores de engenharia frequentemente apresentam problemas de
cronograma e, em face dessas dificuldades, surpreendente que tantos projetos de
software sejam entregues no prazo e dentro do oramento.
3.2 Atividades de gerenciamento

O trabalho do gerente de software varia muito sendo impossvel definir uma
descrio de suas atividades dependendo da empresa e do produto de software que
est em desenvolvimento. Porm boa parte dos gerentes assume a responsabilidade
por uma ou por todas as seguintes atividades.
impossvel fornecer uma descrio de trabalho-padro para um gerente de
software O trabalho varia muito, dependendo da organizao e do produto de sof-
tware que est sendo desenvolvido. No entanto, a maioria dos gerentes assume a
responsabilidade, em algum estgio, por algumas ou todas as seguintes atividades
definidas no Quadro 3.4.
Quadro 3.4 Atividades de gerenciamento
Atividades Descrio
A proposta descreve os objetivos do projeto e como ele ser reali-
zado, normalmente inclui a estimativa de custos e de cronograma
e justifica por que o contrato deve ser concedido a determinada
organizao ou equipe. A elaborao da proposta uma tarefa
Elaborao da proposta
crtica, visto que muitas organizaes de software dependem da
existncia de um nmero suficiente de propostas aceitas e contratos
concedidos. A elaborao da proposta uma habilidade adquirida
pela prtica e pela experincia.
continua
continuao
O planejamento de projeto est relacionado identificao das
Planejamento e
atividades, marcos e produtos gerados por um projeto. elaborado
desenvolvimento do
um plano para guiar o desenvolvimento em direo aos objetivos do
cronograma do projeto
projeto.
A estimativa de custos uma atividade relacionada com a estimativa
Custo do projeto
dos recursos necessrios para realizar o plano do projeto.
A monitorao do projeto uma atividade contnua. O gerente deve
manter o acompanhamento do progresso do projeto e comparar o
progresso com os custos reais e planejados. A monitorao informal
Monitorao e revises pode prever problemas potenciais do projeto, revelando dificulda-
do projeto des medida que elas ocorrem. Em vez de aguardar que um atraso
no cronograma seja relatado, o gerente de software poderia designar
algum especialista para o problema ou propor uma alternativa de
programao.
Os gerentes geralmente precisam selecionar pessoas para trabalhar
em seus projetos. O ideal que haja o pessoal habilitado com expe-
rincia adequada disponvel para trabalhar no projeto, mas na maio-
ria dos casos os gerentes precisam aceitar uma equipe de projeto
aqum do considerado ideal. As razes para isso so: o oramento
Seleo e avaliao de
do projeto pode no ser suficiente para contratar uma equipe muito
pessoal
bem remunerada; uma equipe com experincia adequada pode no
estar disponvel na organizao ou externamente e a organizao
pode querer desenvolver as habilidades de seus funcionrios.
O gerente de software precisa trabalhar dentro dessas restries ao
selecionar a equipe de projeto.
Os gerentes de projeto so geralmente responsveis pela preparao
de relatrios sobre o projeto para o cliente e para as organizaes
Elaborao de relatrios
contratantes. Eles devem redigir documentos concisos e coerentes
e apresentaes
que resumam as informaes fundamentais com base em relatrios
detalhados do projeto.
Fonte: Adaptado de Sommerville (2007, p. 62-63).
3.3 Planejamento de projeto

A eficincia da gerncia de um projeto de software depende de um planejamento
minucioso do progresso do projeto. Os gerentes devem prever os problemas que
podem ocorrer e elaborar solues. Um plano elaborado no incio de um projeto
deve ser usado como guia.
Esse plano inicial deve ser o melhor possvel em face das informaes disponveis,
devendo evoluir medida que o projeto progride e melhores informaes se tornem
disponveis. O Quadro 3.5 mostra um pseudocdigo que estabelece um processo de
planejamento de projeto para o desenvolvimento de software. Mostra que tal plane-
jamento um processo iterativo, que se encerra quando o projeto concludo, visto
que, medida que as informaes se tornam disponveis durante o projeto, o plano
deve ser regularmente revisado.
As metas da empresa constituem um importante fator que deve ser considerado

na formulao do plano do projeto. medida que essas metas mudam, as metas do
projeto tambm mudam e, portanto, so necessrias mudanas no plano do projeto.
Quadro 3.5 Pseudocdigo do processo de planejamento
Defina as restries do projeto.

Faa a avaliao inicial dos parmetros do projeto.
Defina os marcos do projeto e os produtos a serem entregues.
While projeto no foi concludo ou cancelado loop
Elabore um cronograma do projeto
Inicie as atividades de acordo com o cronograma
Aguarde (por um perodo)
Examine o progresso do projeto
Revise as estimativas de parmetros do projeto
Atualize o cronograma do projeto
Renegocie as restries do projeto e os produtos a serem entregues
If surgirem problemas, then
Inicie reviso tcnica e possvel nova reviso
endif
end loop
Analisando o pseudocdigo, no incio devem-se avaliar as restries data de

entrega definida, pessoal disponvel, oramento geral etc. que afetam o projeto.
Com base nessas informaes devemos estimar os parmetros do projeto, tal como sua
estrutura, tamanho e distribuio das funes. Logo aps devemos definir os marcos
de progresso e os produtos a serem entregues. Assim sendo, aps as definies ini-
ciais, o processo, ento, entra em um loop, onde deve ser elaborado um cronograma
estimado para o projeto e as atividades definidas no cronograma so iniciadas ou
liberadas para prosseguimento. Aps algum tempo necessrio para que as tarefas sejam
executadas, deve-se examinar o progresso e anotar as discrepncias em relao ao
cronograma. Verificam-se as estimativas iniciais dos parmetros do projeto por serem
experimentais, sempre ser necessrio modificar o plano original. medida que as
informaes se tornam disponveis, voc deve revisar as hipteses originais e o cro-
nograma do projeto. Se o projeto estiver atrasado, pode ser necessrio renegociar as
restries e os produtos a serem entregues com o cliente, mas, se essa renegociao
no for bem-sucedida e o cronograma no puder ser cumprido, devemos considerar
a necessidade de uma reviso tcnica, que dever ter como objetivo encontrar uma
abordagem alternativa que se limite s restries do projeto e cumpra o cronograma.
3.3.1 O plano de projeto

Estabelece os recursos disponveis para o projeto bem como a sua estrutura ana-
ltica e um cronograma para realizar o trabalho. Em alguns casos, o plano de projeto
est relacionado apenas ao processo de desenvolvimento. Os detalhes do plano de
projeto variam dependendo do tipo do projeto e da empresa. Entretanto, a maioria
dos planos deve incluir as seguintes sees:
Sees Descrio
Descreve brevemente os objetivos do projeto e estabelece as
1. Introduo restries (por exemplo, oramento, prazo etc.) que afetam o
gerenciamento do projeto.
Descreve o modo como a equipe de desenvolvimento est
2. Organizao do projeto
organizada, as pessoas envolvidas e seus papis na equipe.
Descreve os possveis riscos do projeto, a probabilidade da ocorrn-
3. Anlise de riscos
cia desses riscos e as propostas de estratgias de reduo de riscos.
Especificam o hardware e o software de apoio necessrios para
4. Requisitos de recursos de realizar o desenvolvimento. Se o hardware precisar ser com-
hardware e de software prado, podem ser includas as estimativas de preos e o prazo
de entrega.
Estabelece a estrutura analtica do projeto em atividades e identifica
5. Estrutura analtica
os marcos e os produtos a serem entregues com cada atividade.
Apresenta as dependncias entre as atividades, o prazo es-
6. Cronograma do projeto timado necessrio para atingir cada marco e a alocao de
pessoas nas atividades.
Definem os relatrios de gerenciamento que devem ser produ-
7. Mecanismos de monitorao
zidos, quando eles devem ser produzidos e os mecanismos de
e elaborao de relatrios
monitorao de projeto usados.
Durante o projeto, devemos revisar o plano constantemente, pois algumas panes

como o cronograma sofrem mudanas constantes, e para simplificar as revises voc
deve organizar o documento em sees separadas que podem ser individualmente
substitudas medida que o plano evolui.
3.3.2 Marcos e produtos a serem entregues

Os gerentes precisam de informaes para realizar seu trabalho. Como o soft-
ware e intangvel, essas informaes podem ser fornecidas apenas como relatrios
e documentos que descrevem o estado do software que desenvolvido. Sem elas,
impossvel avaliar quo bem o trabalho est progredindo e as estimativas de custos
e o cronograma no podem ser atualizados.
Ao planejar um projeto, voc deve estabelecer uma srie de marcos. A cada
marco, deve existir uma sada formal, como um relatrio, que possa ser apresentado
gerncia. Esses relatrios de marcos no precisam ser documentos extensos, podendo
ser simples e breves sobre a atividade concluda.
Um produto um resultado de projeto entregue ao cliente, sendo em geral dis-

ponibilizado no fim de alguma fase importante, como especificao ou design. Os
produtos so geralmente marcos, porm os marcos no precisam ser necessariamente
um produto, pois podem ser resultados internos de projeto usados pelo gerente para
verificar o progresso do projeto, embora no sejam entregues ao cliente.
Para saber mais

Um marco um ponto final reconhecvel de uma atividade do processo de software.
3.3.2.1 Cronograma do projeto

O desenvolvimento do cronograma do projeto um dos trabalhos mais difceis
para um gerente de projeto, pois estima o tempo e os recursos necessrios para con-
cluir atividades, organizando-as em uma sequncia coerente. A estimativa de crono-
grama mais complicada pelo fato de que projetos diferentes podem usar mtodos
e linguagens de implementao diferentes.
Os cronogramas, portanto, devem ser continuamente atualizados medida que
mais informaes sobre o progresso se tornem disponveis. O desenvolvimento do
cronograma de projeto (Figura 3.6) envolve a diviso do trabalho total de um projeto
em atividades separadas e a avaliao do tempo necessrio para completar essas
atividades.
Figura 3.6 Processo de desenvolvimento de cronograma de projeto

Para saber mais

Os diagramas de barras e as redes de atividades so notaes grficas usadas para ilustrar o
cronograma do projeto. Os diagramas de barras mostram quem responsvel por cada atividade
e quando as atividades esto programadas para serem iniciadas e terminadas. As redes de ati-
vidades mostram as dependncias entre as diferentes atividades que constituem um projeto.
Os diagramas de barras e os diagramas de atividades podem ser gerados automaticamente
baseados em um banco de dados de informaes do projeto, usando uma ferramenta de ge-
renciamento de projetos.
Em geral, algumas das atividades so realizadas simultaneamente, devendo o

gerente coordenar as atividades paralelas e organizar o trabalho de modo que a fora
de trabalho seja usada de maneira otimizada. importante evitar uma situao em
que todo o projeto fique atrasado pelo fato de a tarefa crtica no estar concluda.
As atividades de projeto devem durar pelo menos uma semana; ao estimar os
cronogramas, no devemos considerar que todo o estgio do projeto estar livre de
problemas. As pessoas que trabalham em um projeto podem ficar doentes ou podem
sair, o hardware pode apresentar defeito e o software ou o hardware de apoio essen-
cial podem ser entregues com atraso.
Uma boa regra prtica fazer a estimativa como se nada fosse dar errado e, ento,
aument-la para cobrir problemas no previstos. Um fator de contingncia adicional
para cobrir problemas no previstos pode tambm ser acrescentado estimativa.
Esse fator extra de contingncia depende do tipo de projeto, dos parmetros (prazo
final, padres etc.) e da qualidade e experincia dos engenheiros de software que
trabalham no projeto. Acrescento 40% minha estimativa original para problemas
no previstos e mais 25% para cobrir aspectos no imaginados.
Geralmente os cronogramas de projeto so representados como um conjunto
de diagramas que apresentam a estrutura analtica do projeto, as dependncias de
atividades e as alocaes de pessoal.
Para saber mais

No intuito de proporcionar um maior entendimento sobre o assunto, acesse o link: <http://
www.ebah.com.br/content/ABAAAgMuQAG/sommerville-engenharia-software-8-edicao#> e
faa a leitura das p. 66-68.
3.3.3 Gerenciamento de riscos

Uma das principais atividades dos gerentes de projeto o gerenciamento de riscos,
uma vez que consiste em prever os riscos que podem afetar tanto a organizao que
desenvolve os softwares como o cronograma do projeto ou a qualidade do produto que
est sendo desenvolvido, e tomar providncias para que esses riscos sejam evitados.
Os resultados da anlise de riscos devem ser registrados no plano de projeto
junto com uma anlise das consequncias de uma ocorrncia desse risco. Com um
gerenciamento eficiente de riscos, torna-se mais fcil lidar com os problemas e asse-
gurar que eles no conduzam a um oramento inaceitvel ou atraso no cronograma.
Simplificando, voc pode pensar em risco como algo que seria prefervel no
ocorrer, pois pode ameaar o projeto, o software que est sendo desenvolvido ou a
organizao. H, portanto, trs categorias de risco relacionadas:
1. Riscos de projeto: so aqueles que afetam o cronograma ou os recursos de
projeto. Por exemplo, perda de um programador experiente.
2. Riscos de produto: so aqueles que afetam a qualidade ou o desempenho do
software que est sendo desenvolvido. Por exemplo, um framework que no
funciona conforme esperado.
3. Riscos de negcio: so aqueles que afetam a organizao que desenvolve ou
adquire o software. Por exemplo, um concorrente que lana um produto antes
de voc, um produto mais inovador que o seu.
Obviamente, esses tipos de risco se sobrepem, uma vez que, se um programador

experiente deixa um projeto, isso acarreta um risco de projeto, pois a entrega do
sistema pode atrasar. Tambm pode ser um risco de produto, visto que um substituto
pode no ter tanta experincia e, por isso, cometer erros de programao. E por fim
pode tambm ser um risco de negcio, uma vez que a experincia do programador
desligado no est disponvel para ser oferecida em novos projetos.
Os riscos que podem afetar um projeto dependem do projeto e do ambiente
organizacional onde o software est sendo desenvolvido. No entanto, muitos deles
so universais. Sommervile aponta na Tabela 3.3 alguns dos riscos mais comuns em
um projeto.
Tabela 3.3 Risco de software
Risco Tipo de risco Descrio

Pessoal experiente vai deixar o projeto antes do
Rotatividade de pessoal Projeto
final.
Haver uma mudana na gerncia com novas
Mudana de gerncia Projeto
prioridades.
Haver um nmero maior de mudanas de requi-
Mudana de requisitos Projeto/Produto
sitos do que foi previsto.
continua

continuao
As especificaes das interfaces essenciais no

Atrasosde especificao Projeto/Produto
estaro disponveis dentro do prazo.
Tamanho subestimado Projeto/Produto O tamanho do sistema foi subestimado.
A tecnologia na qual o sistema foi construdo foi
Mudana de tecnologia Negcios
ultrapassada por novas tecnologias.
Um produto concorrente foi lanado no mercado
Concorrncia de produto Negcios
antes da conclusao do sistema.
As incertezas inerentes aos projetos fazem que o gerenciamento de riscos seja

essencial para os projetos de software. As incertezas se originam de requisitos mal
definidos, de dificuldades na estimativa de prazo e recursos necessrios para o desen-
volvimento de software, da dependncia de habilidades individuais e de mudanas
de requisitos por mudanas nas necessidades do cliente. Assim, necessrio prever
os riscos, compreender seu impacto no projeto, no produto e nos negcios, e tomar
providncias para evit-los. Dessa maneira, pode ser necessrio elaborar planos de
contingncia, a fim de poder tomar providncias imediatas para recuperao, caso
os riscos ocorram.
O processo de gerenciamento de riscos envolve os seguintes estgios:
identificao de riscos;
anlise de riscos;
planejamento de riscos;
monitorao de riscos.
O processo de gerenciamento de riscos, como todos os outros planejamentos

de projeto, um processo iterativo que prossegue ao longo do projeto. Uma vez
elaborado um conjunto inicial de planos, a situao monitorada. medida que
mais informaes sobre os riscos se tornarem disponveis, eles devero ser analisados
novamente e novas prioridades devero ser estabelecidas. Os planos de preveno
de riscos e de contingncia podem ser modificados medida que novas informaes
de risco surgirem.
primordial a documentao dos resultados do processo de gerenciamento de
riscos em um plano de gerenciamento de riscos. Esse plano deve incluir uma ex-
plicao dos riscos enfrentados pelo projeto, uma anlise desses riscos e os planos
necessrios para gerenci-los.
3.3.3.1 Identificao de riscos

A identificao de riscos o primeiro estgio do gerenciamento de riscos, e est
relacionada com a descoberta dos possveis riscos do projeto. A princpio, os riscos
no devem ser priorizados ou avaliados nesse momento, porm, na prtica, riscos
com consequncias muito pequenas ou com pouca probabilidade de ocorrer no
so considerados.
A identificao de riscos uma atividade realizada como um processo em equipe,

usando uma abordagem de brainstorming, ou ser baseada na experincia das pessoas
da equipe. Para auxiliar o processo de identificao deve ser elaborado um check-list
de diferentes tipos de risco como podemos ver a seguir:
1. Riscos de tecnologia. Derivam de tecnologias de software ou hardware usadas
para desenvolver o sistema.
2. Riscos de pessoal. Associados s pessoas da equipe de desenvolvimento.
3. Riscos organizacionais. Derivam do ambiente organizacional no qual o sof-
tware est sendo desenvolvido.
4. Riscos de ferramentas. Derivam de ferramentas CASE e outros softwares de
apoio, usados para desenvolver o sistema.
5. Riscos de requisitos. Derivam de mudanas de requisitos de cliente e do pro-
cesso de gerenciamento de mudana de requisitos.
6. Riscos de estimativas. Derivam de estimativas de gerenciamento das caracters-
ticas de sistema e estimativas de recursos necessrios para construir o sistema.
A Tabela 3.4 apresenta alguns exemplos dos possveis riscos em cada uma dessas
categorias. Aps concluir o processo de identificao, voc dever ter uma longa lista
de riscos que podem ocorrer e quais podem afetar o produto, o processo e os negcios.
Tabela 3.4 Tipos de riscos x riscos
Tipo de risco Riscos possiveis

Tecnologia Banco de dados no pode processar tantas operaes por segundo como desejado.
difcil recrutar pessoal com habilidades necessrias.
Pessoal O pessoal qualificado no est disponvel nos momentos crticos.
O treinamento necessrio para o pessoal no est disponvel.
A empresa reestruturada, com mudana de gerncia responsvel pelo projeto.
Organizacional
Redues no oramento do projeto por problemas financeiros da organizao.
As ferramentas CASE no podem ser integradas.
Ferramentas
O cdigo gerado pelas ferramentas CASE ineficiente.
Mudanas de requisitos que requerem retrabalho maior de projeto so propostas.
Requisitos
Cliente no entende os impactos das mudanas de requisitos.
O tamanho do software foi subestimado.
Estimativas O prazo para desenvolver o software foi subestimado.
Taxa de reparo foi subestimada.
3.3.3.2 Anlise de riscos

Na anlise de riscos, deve-se considerar cada risco identificado e fazer uma
avaliao de sua probabilidade e seriedade. No h uma maneira fcil de fazer isso
e para tanto devemos contar com a prpria avaliao e experincia das pessoas que
fazem tal anlise, fazendo que os gerentes de projetos experientes sejam as melhores
pessoas para auxiliar no gerenciamento de riscos.
Essas estimativas de risco geralmente no precisam ser avaliaes numricas
precisas, mas devero basear-se em um nmero de faixas:
A probabilidade do risco deve ser avaliada como muito baixa (< 10%), baixa
(10-25%), mdia (25-50%), alta (50-75%) ou muito alta (> 75%).
Os efeitos do risco podem ser avaliados como catastrficos, srios, tolerveis
ou insignificantes.
Assim, devemos computar os resultados desse processo de anlise usando uma
tabela ordenada de acordo com a gravidade do risco. A Tabela 3.5 ilustra isso. Ob-
viamente, a avaliao da probabilidade e da seriedade arbitrria nesse caso, porm,
na prtica, para fazer essa avaliao, necessrio possuir informaes detalhadas
sobre o projeto, o processo, a equipe de desenvolvimento e da organizao
Tabela 3.5 Anlise de riscos
Risco Probabilidade Efeitos

Problemas financeiros na empresa foram a reduo
Baixa Catastrficos
no projeto
Impossibilidade de recrutar pessoal habilitado para o
Alta Catastrficos
projeto
Funcionrio est doente nos momentos crticos do
Mdia Srios
projeto
So propostas mudanas de requisitos que requerem
Mdia Srios
maior retrabalho
Tempo necessrio para desenvolver o produto foi
Alta Serios
subestimado
Ferramentas CASE no podem ser integradas Alta Tolerveis
Os clientes no compreendem o impacto das
Mdia Tolerveis
mudanas de requisitos
O treinamento necessrio para os funcionrios no
Mdia Tolerveis
est disponvel no momento
O cdigo gerado pela feramenta CASE ineficiente Mdia Insignificantes
Fonte: Adaptada de Sommervile (2007, p. 72).
Aps os riscos terem sido analisados e classificados, necessrio avaliar quais so

os mais significativos. A avaliao deve depender da combinao da probabilidade
da ocorrncia do risco e de seus eleitos. Geralmente os riscos catastrficos devem
sempre ser considerados, assim como todos os riscos srios que tenham probabilidade
de ocorrncia acima da mdia.
3.3.3.3 Planejamento de riscos

O processo de planejamento de riscos considera cada um dos riscos importantes
identificados e define estratgias para gerenci-los. Outra vez, no h um processo
simples a ser seguido para definir os planos de gerenciamento de riscos. Ele conta com
a avaliao e a experincia do gerente do projeto. A Tabela 3.6 mostra as possveis
estratgias identificadas para os riscos principais da Tabela 3.5.
Essas estratgias dividem-se em trs categorias:
1. Estratgias de preveno. Significa que a probabilidade de que o risco ocorra
ser reduzida.
2. Estratgias de minimizao. Significa que o impacto do risco ser reduzido.
3. Planos de contingncia. Significa que voc est preparado para o pior e tem
uma estratgia para lidar com o problema.
Tabela 3.6 Estratgias de gerenciamento de riscos
Risco Estratgia
Preparar um documentos que mostre gerncia como
Problemas financeiros da empresa
o projeto est contribuindo para as metas da empresa.
Alertar o cliente das dificuldades potenciais e da
Problemas de recrutamento possibilidade de atrasos. Estudar a compra de compo-
nentes de software.
Reorganizar a equipe de maneira que possa ser feita a
Doena do pessoal da equipe
superposio de trabalho, desta forma fazendo que as
Componentes defeituosos
pessoas compreendam as tarefas umas das outras.
Efetuar a substituio dos componentes defeituosos
Mudanas de requisitos
por outros com confiabilidade reconhecida.
Preparar um documento que mostra a importncia do
Reestruturao da empresa
projeto para cumprimento das metas organizacionais.
Checar a possibilidade de adquirir um banco de
Desempenho de banco de dados
dados com melhor desempenho.
Estudar a possibilidade de aquisio de novos com-
Prazo de desenvolvimento subestimado ponentes de software e tambm a de um gerador de
programas (relatrios).
3.3.3.4 Monitorao de riscos

A monitorao de riscos envolve a avaliao de cada um dos riscos identificados
para decidir se est se tornando ou no mais ou menos provvel de acontecer e se
os efeitos sofreram alguma mudana. A Tabela 3.7 (SOMMERVILLE, 2007) apresenta
alguns fatores que podem ser teis na avaliao dos tipos de riscos.
A monitorao deve ser um processo contnuo e, a cada reviso feita pela gerncia,
deve-se considerar e discutir cada um dos principais riscos isoladamente.
Tabela 3.7 Fatores de riscos
Tipo de risco Indicadores potenciais

Entrega de hardware ou software de apoio com atraso, vrios problemas so
Tecnologia
relatados.
Baixo moral da equipe, relacionamentos precrios entre os membros, dispo-
Pessoal
nibilidade de emprego.
Organizacional Boatos na empresa e falta de ao da gerncia snior.
Relutncia das pessoas da equipe em utilizar ferramentas que melhorem a
Ferramentas produtividade, reclamaes sobre ferramentas CSASE, demandas por
hardware mais potentes.
Requisitos Vrias solicitaes de mudanas so feitas, reclamaes de clientes.
Falha no cumprimento do cronograma, falha em eliminar os defeitos
Estimativas
relatados.

1. Qual a importncia para o desenvolvedor de software do uso da enge-
nharia de requisitos bem como da documentao desse processo?
2. Levando em conta o gerenciamento de projeto de software, em sua opinio
por que o papel do engenheiro de software ainda um enigma tanto para
as empresas desenvolvedoras quanto para os prprios desenvolvedores?.
1. Levando em conta os conceitos sobre a gerenciamento de riscos INCORRETO
afirmar:
I. Pode-se responder ao risco de cinco formas diferentes: evitando, trans-
ferindo, reduzindo, aceitando e ignorando.
II. As ameaas precisam ser definidas quanto ao grau de exposio que
apresentam para o ativo em questo. Quando se define o grau da
ameaa, deseja-se determinar quanto existe daquela ameaa, inde-
pendentemente do ativo ao qual se est referindo para aquela ameaa.
III. A avaliao do risco propriamente dita nada mais do que comparar a

estimativa de risco contra os critrios de risco para determinar os nveis
de riscos de incidentes de segurana da informao. Normalmente,
quanto maiores o impacto e a probabilidade, maior ser o risco.
Assinale a alternativa que corresponda s afirmaes verdadeiras:
a) I, II e III
b) II e III
c) I e III
d) I e II
e) Somente a I
2. Assinale a alternativa que corresponda corretamente aos estgios de ge-
renciamento de riscos.
a) Projeto produto negcios.
b) Tecnologia organizacionais pessoas estimativa requisitos.
c) Elaborao da proposta planejamento e desenvolvimento do crono-
grama do projeto monitorao e revises do projeto elaborao
de relatrios e apresentaes.
d) Identificao de riscos anlise de riscos planejamento de riscos
monitorao de riscos.
e) Estratgias de minimizao estratgias de preveno plano de
contingncia.
Fique ligado!
Nesta unidade, foram abordados os seguintes aspectos relativos aos requi-
sitos de software, engenharia de requisitos e ao gerenciamento de projetos
relacionados aos objetivos de aprendizagem:
Os requisitos de um sistema de software definem o que o sistema deve
fazer e as restries.
Os requisitos funcionais so declaraes dos servios que o sistema
deve fornecer ou so descries de como algumas computaes devem
ser realizadas.
Os requisitos de domnio so requisitos funcionais derivados das carac-
tersticas do domnio da aplicao.
Os requisitos no funcionais restringem o sistema que est sendo desen-

volvido, bem como o processo de desenvolvimento que deve ser usado.
Os requisitos no funcionais podem ser requisitos de produto, organi-
zacionais ou externos e esto relacionados s propriedades emergentes
do sistema. Portanto, aplicam-se ao sistema como um todo.
Os requisitos de usurio destinam-se s pessoas envolvidas no uso e
na aquisio do sistema. Para tal, devem ser redigidos com o uso de
linguagem natural, tabelas e diagramas de fcil compreenso para seus
leitores.
Os requisitos de sistema destinam-se a comunicar, de maneira precisa,
as funes que o sistema deve fornecer. Podem ser escritos em lingua-
gem natural, de maneira estruturada, e complementados com tabelas e
modelos de sistemas, sendo destinados aos desenvolvedores de sistema.
O documento de requisitos de software a declarao aprovada dos
requisitos de sistema. Deve ser organizado de tal maneira que os clientes
de sistema e os projetistas de software possam us-lo.
O processo de engenharia de requisitos inclui um estudo de viabili-
dade, elicitao e anlise, especificao, validao e gerenciamento de
requisitos.
A elicitao e a anlise de requisitos constituem um processo iterativo
que pode ser representado como uma espiral de atividades tais como
obteno, classificao e organizao, negociao e documentao de
requisitos
Diferentes stakeholders no sistema tm diferentes requisitos. E em siste-
mas complexos devem ser analisados com base em uma srie de pontos
de vista.
Pontos de vista podem ser pessoas ou outros sistemas que interagem
com o sistema que est sendo especificado, stakeholders afetados pelo
sistema ou pontos de vista de domnio que restringem os requisitos.
Fatores sociais e organizacionais tm forte influncia nos requisitos do
sistema e podem determinar se o sistema realmente usado.
Validao de requisitos o processo para verificar os requisitos em
relao validade, consistncia, completeza, realismo e facilidade de
verificao.
Revises de requisitos e prototipao so as principais tcnicas usadas
para a validao de requisitos.
Mudanas de negcios, organizacionais e tcnicas levam, inevitavel-
mente, s mudanas dos requisitos de um sistema de software.
O gerenciamento de requisitos o processo para gerenciar e controlar
essas mudanas.
O processo de gerenciamento de requisitos inclui o planejamento de
gerenciamento, no qual polticas e procedimentos de gerenciamento
de requisitos so projetados, e o gerenciamento de mudanas, no qual

voc deve analisar as mudanas de requisitos propostas e avaliar seu
impacto.
Um bom gerenciamento de projeto de software essencial para que
os projetos de engenharia do software sejam desenvolvidos dentro do
cronograma e do oramento.
O gerenciamento de software diferente do gerenciamento em outras
reas da engenharia.
O software intangvel, assim os projetos podem ser novos ou inova-
dores, portanto, no existe um conjunto de experincias para guiar seu
gerenciamento. Os processos de software no so bem compreendidos.
Os gerentes de software possuem diversos papis. As atividades mais
significativas so planejamento, elaborao de estimativas e desenvol-
vimento de cronograma do projeto.
O planejamento e a elaborao de estimativas so processos iterativos
que continuam ao longo de um projeto e medida que mais informaes
se tornam disponveis os planos e os cronogramas devem ser revisados.
Um marco de projeto um resultado previsvel de uma atividade,
no qual algum relatrio formal de progresso deve ser apresentado
gerncia.
Os marcos devem ocorrer regularmente ao longo de um projeto de
software, sendo que um produto um marco disponibilizado para o
cliente do projeto.
O desenvolvimento do cronograma do projeto envolve a criao de v-
rias representaes grficas de partes do plano de projeto onde incluem
diagramas de atividades, que mostram os inter-relacionamentos entre
as atividades de projeto, e diagramas de barras, que mostram a durao
das atividades.
Os principais riscos do projeto devem ser identificados e avaliados para
definir sua probabilidade e as consequncias para o projeto. Sendo
assim devem-se elaborar planos para evitar, gerenciar ou lidar com os
provveis riscos se ou quando eles ocorrerem.
Os riscos devem ser explicitamente discutidos em cada reunio de
progresso do projeto.

Neste momento podemos refletir a importncia de se fazer um bom trabalho
de levantamento de requisitos, uma vez que, se no for efetuado corretamente,
invariavelmente poder levar o projeto a falhas que muitas vezes s sero per-
ceptveis em uma fase adiantada do desenvolvimento.
Sabe-se que buscar informaes com os usurios um processo rduo, pois
retirar informaes de um usurio que desconfia e/ou no acredita no processo
algo que exige grande dedicao do analista, visto que definir as funciona-
lidades que um sistema dever possuir muito fcil, porm, ter que definir as
restries do mesmo algo um pouco mais difcil, visto que devemos lidar com
medos, insegurana, conflitos, entre outros.
Torna-se essencial buscar nos processos de engenharia de requisitos os meios
para realizar tal levantamento bem como um bom gerenciamento do projeto,
gerenciando, dessa forma, os requisitos bsicos de um bom projeto de software,
custo, prazo e qualidade.

1. O levantamento de requisitos uma etapa fundamental do projeto de sis-
temas. Dependendo da situao encontrada, uma ou mais tcnicas podem
ser utilizadas para a elicitao dos requisitos. A respeito dessas tcnicas,
analise as afirmaes a seguir.
a) Workshop de requisitos consiste na realizao de reunies estruturadas
e delimitadas entre os analistas de requisitos do projeto e represen-
tantes do cliente.
b) Cenrio consiste na observao das aes do funcionrio na realizao
de uma determinada tarefa, para verificar os passos necessrios para
sua concluso.
c) As entrevistas so realizadas com os stakeholders e podem ser abertas
ou fechadas.
d) A prototipagem uma verso inicial do sistema, baseada em requisitos
levantados em outros sistemas da organizao.
e) As alternativas A e E esto corretas.
140 MODELAGEM DE SISTEMAS EMPRESARIAIS
2. Levando em considerao gerenciamento de riscos, significa que devemos

identificar riscos e traar planos para minimizar seus efeitos sobre o pro-
jeto. Assinale a opo que contenha a descrio de um exemplo de risco
de negcios.
a) O tamanho do sistema foi subestimado.
b) A tecnologia sobre a qual o sistema est sendo construdo foi superada
por nova tecnologia.
c) As especificaes de interface no estavam disponveis dentro do prazo.
d) Haver uma mudana no gerenciamento organizacional, com a defini-
o de prioridades diferentes.
e) Haver maior nmero de mudanas nos requisitos do que o previsto.
3. Com relao s polticas de rastreabilidade de requisitos, elas so definidas
e decididas durante o estgio de:
a) Agregao dos requisitos funcionais, apenas.
b) Implementao do sistema, apenas.
c) Gerenciamento de requisitos.
d) Implantao do sistema.
e) Eliminao dos requisitos no funcionais.
4. Assinale a alternativa que corresponda aos principais processos relativos
gerncia de risco do projeto:
a) O gerenciamento de recursos dos riscos, que tem como objetivo prin-
cipal garantir o contnuo fornecimento de recursos financeiros para dar
continuidade ao projeto.
b) A identificao dos riscos, que tem como foco definir as melhorias
necessrias para o aproveitamento de oportunidades e respostas s
ameaas.
c) A monitorao dos riscos, cuja finalidade analisar os resultados es-
pecficos do projeto para determinar se eles esto de acordo com os
padres de qualidade relevantes e identificar as formas para eliminar
as causas de desempenhos insatisfatrios.
d) O controle das respostas aos riscos, cuja tarefa responder s mudanas
nos riscos no decorrer do projeto.
e) A avaliao peridica do desempenho dos riscos, que tem como finali-
dade definir e avaliar o desempenho geral do projeto buscando assegurar
a satisfao dos padres relevantes de qualidade.
5. Considerando os componentes envolvidos em um projeto de desenvolvi-

mento de softwarare, considere:
I. Pessoa ou grupo que fornece os recursos financeiros para o projeto.
II. Pessoas que estejam ativamente envolvidas no gerenciamento ou na
execuo do projeto.
III. Pessoas e organizaes cujos interesses possam ser afetados de forma
positiva pelo projeto.
IV. Pessoas e organizaes cujos interesses possam ser afetados de forma
negativa pelo projeto.
Assinale a alternativa que corresponda a um stakeholder:
a) II, III e IV, apenas.
b) II e III, apenas.
c) II, apenas.
d) I, apenas.
e) I, II, III e IV.
Referncias
PRESSMANN, Roger S. Engenharia de software: uma abordagem profissional. 7. ed. Porto
Alegre: AMGH, 2011.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. So Paulo: Pearson, 2007.
Unidade 4
Noes sobre
modelagem de sistemas
Objetivos de aprendizagem: Caro aluno, voc ser levado a estudar

e conhecer conceitos importantes da modelagem de sistemas, aborda-
remos assuntos referentes modelagem estruturada e modelagem
orientada a objeto (OO), neste mundo da orientao a objetos traba-
lharemos conceitos bem relevantes para seu aprendizado e a prtica
da OO. Vamos abordar a linguagem de modelagem unificada UML,
bem como uma viso geral dos seus diagramas.
Seo 1: Introduo modelagem estruturada

de sistemas
Caro aluno, nesta seo vamos abordar o contedo
sobre modelagem estruturada. Conheceremos sua
histria, alguns diagramas como: diagrama entidade
relacionamento (DER) e diagrama de fluxo de dados
(DFD). E ao final da seo voc ter algumas atividades
para reforar seu aprendizado.
Tenha uma boa leitura!
Seo 2: Introduo modelagem orientada

a objeto e para web
Caro aluno, nesta seo voc conhecer um pouco
da histria da modelagem orientada a objeto, da
linguagem de programao orientada a objeto e
dentro do paradigma da orientao a objetos vamos
abordar alguns conceitos e caractersticas relevantes
para seu aprendizado e prtica. E para reforar o
contedo estudado voc ter alguns estudos de caso
e atividades de aprendizagem.
Tenha uma boa leitura!
N o e s s o b r e m o d e l a g e m d e s i s t e m a s 145
Introduo ao estudo
Caro aluno, vamos iniciar nosso aprendizado pela modelagem de dados.
Podemos dizer que modelos so abstraes que mostram a essncia de um pro-
blema, e a modelagem de dados um processo para a criao de um software, que
deve ser organizado, utilizando alguma tcnica predefinida, sendo que as etapas desse
processo compem o ciclo de vida do software. E na etapa de anlise de sistemas
que precisamos definir qual modelagem ser utilizada.
Mas afinal, o que anlise na informtica? Anlise quando estudamos uma
situao problema. Pense num cenrio em que um cliente apresenta suas necessida-
des ou desejos para resoluo de um problema de um determinado segmento de sua
empresa. Com base nessas informaes so necessrios estudos, ou seja, anlises
para identificao do real problema e como ele pode ser solucionado.
Os modelos so o resultado desses estudos e consistem em uma proposta do
sistema a ser implementado. Eles so criados pelo analista para auxiliar no entendi-
mento tanto do cliente que solicitou e receber o sistema, quanto da equipe que o
implementar.
Para concluir esta introduo no poderamos deixar de citar Confcio, filsofo chins,
que dizia: uma imagem vale mais que mil palavras. E essa a inteno ao representar
por meio de imagens (modelos) nosso entendimento sobre a necessidade do cliente.

estruturada de sistemas
1.1 Introduo
Dentro de um processo de desenvolvimento de software conhecemos todas as
fases para a construo de um software e uma delas a fase de anlise, fase essa de
extrema importncia para obtermos um software de qualidade, ou seja, um software
que atende principalmente as necessidades do cliente. E como apoio anlise rea-
lizamos a modelagem do nosso sistema e nesta seo vamos abordar a modelagem
estruturada.
1.2 Introduo modelagem estruturada de sistemas

Segundo Bezerra (2007), para o paradigma da modelagem estruturada seus ele-
mentos so dados e processos, nos quais os processos agem sobre os dados para que
um objetivo seja alcanado.
Essa modelagem teve seu incio na dcada de 1970, com uma abordagem siste-
mtica, utilizando tcnicas de construo de modelos, tendo a preocupao naquilo
que o sistema tem de fazer.
J na dcada de 1980, ela foi revista e teve um aprimoramento voltado para se

fazer uma anlise para satisfazer os requisitos do usurio, colocando uma viso mais
integrada das funes e dos dados do sistema.
Algumas fases da anlise estruturada so a coleta de requisitos de sistemas, iden-
tificao dos atores e eventos, criao de diagramas como o de fluxo de dados (DFD)
e diagrama de entidade-relacionamento (DER).
Antes de falarmos do DER, importante abordarmos o MER (Modelo de Entidade e
Relacionamento), que um modelo conceitual de alto nvel para apresentar as regras
de negcio e no a implementao, ou seja, as informaes obtidas no levantamento
de requisitos para representar o que devemos fazer e no como, este, o como
fazer, consiste na implementao do banco de dados. E a representao grfica do
MER o DER.
O DER tem como objetivo representar as entidades e seus relacionamentos. uma
ferramenta de modelagem que define informaes do modelo entidade-relaciona-
mento para o banco de dados relacional, diferente do diagrama de classes que modela
o mundo real. As entidades consistem nos dados concretos ou abstratos relevantes
da organizao para qual ser destinada o sistema. Seguindo o modelo proposto por
Peter Chen (2007), o DER composto de entidades (representadas por um retngulo)
e seus relacionamentos (representados por um losango), atributos (representados por
elipses) e as linhas de conexo indicando a cardinalidade.
Figura 4.1 Representao de um DER
Cdigo Tipo
(1,1) (1,N)
Pessoa Telefone
Nome Nmero
Fonte: Da autora (2014).
A cardinalidade a quantidade de ocorrncias de entidades que podem estar

associadas (1:1, 1:N, N:N), representando a regra de negcio obtida no levantamento
de requisitos.
Para saber mais

Cardinalidades utilizadas no DER propostas por Peter Chen (2007) so:
1..1 (l-se um para um) indica que as tabelas tm relacionamento unvoco entre si. Voc
escolhe qual tabela receber a chave estrangeira;
1..n (l-se um para muitos) a chave primria da tabela que tem o lado 1 vai para a tabela
do lado N. No lado N ela chamada de chave estrangeira;
Noes sobre modelagem de sistemas 147
n..n (l-se muitos para muitos) quando tabelas tm entre si relacionamento n..n,
necessrio criar uma nova tabela com as chaves primrias das tabelas envolvidas, ficando
assim uma chave composta, ou seja, formada por diversos campos-chave de outras tabelas.
O relacionamento ento se reduz para um relacionamento 1..n, sendo que o lado n ficar
com a nova tabela criada.
J o DFD tem como objetivo representar graficamente o fluxo dos dados sendo
uma etapa usada para criar uma viso geral do sistema, na qual podemos ver quais
tipos de informaes esto no sistema e onde os dados sero armazenados. Esse
diagrama tambm pode ser chamado de diagrama de bolhas ou diagrama de fluxo
de trabalho. Existem algumas regras para se criar um DFD: como todo o processo
deve ter um fluxo de entrada e de sada, e todo o fluxo de dado deve ter uma origem
e um destino, o objeto deve ter nome e a duplicao dos smbolos deve ser evitada.
O DFD deve ter nveis de detalhamento
O DFD uma boa ferramenta de comunicao e utilizado como auxlio ao projeto.
Figura 4.2 Smbolos usados no DFD
Incio/Trmino Fluxo de dados
Operao de Entrada de Dados

Atribuio
Operao de Sada de Dados Deciso

A qualidade de uma modelagem estruturada ter uma representao grfica de

fcil entendimento, ser particionada em uma rede de miniespecificaes e interao
permanente com o utilizador. Como problemas podem ser citados a manuteno, o
custo elevado do sistema e as mudanas nele, as quais podem demandar tempo e
recursos humanos.
A modelagem estruturada se utiliza de construo de modelos e faz uma notao
que prpria da anlise estruturada, com a finalidade de retratar o fluxo e o contedo
das informaes utilizadas pelo sistema, dividir o sistema em parties funcionais e
comportamentais e descrever a essncia do que ser construdo.
a) ( ) O DER identifica as entidades e seus relacionamentos.
b) ( ) O DER um diagrama de eventos.
c) ( ) o DFD representa o fluxo de dados.
d) ( ) O DFD e o DER so diagramas da modelagem estruturada.
2. A modelagem estruturada teve incio na dcada de 1970. Comente sobre
os principais diagramas dessa modelagem.

orientada a objeto e para web
2.1 Introduo
Na seo 1, abordamos a importncia da modelagem estruturada como apoio
a anlise de sistema para construo de um software com qualidade e nesta seo
vamos continuar abordando a modelagem mais com enfoque na orientao a objetos.
2.2 Introduo modelagem orientada a objeto

e para web
A modelagem orientada a objeto (MOO) teve seu incio na dcada de 1960, mas
devido limitao de hardware, ela ganhou fora somente nas ltimas duas dcadas.
A orientao a objeto (OO) possibilita uma melhor organizao e reutilizao de
cdigos-fonte, tornando mais fcil as atualizaes e melhorias nos sistemas.
interessante ressaltar que as linguagens de programao orientada a objeto
vieram antes da modelagem orientada a objeto, ou seja, a modelagem se adaptou
programao.
Acompanhe a seguir a evoluo histrica das Linguagens Orientadas a Objeto:
1966 SIMULA (KristenNygaard, Noruega);
1980 SMALLTALK (Xerox);
1983 linguagem C with Classes passa a ser C++;
1986 C++ (AT&T), SMALLTALK V , OBJECTIVE-C;
1988 EIFFEL (Meyer, Frana);
1989 Turbo Pascal 5.5 (Borland);
1995 JAVA;
2001 C#;
2002 VB.NET;
2014 ...
A linguagem que iniciou o conceito de classes foi a Simula 66, criada entre 1962
e 1968 por Kristen Nygaard e Ole-Johan Dahl. J a linguagem Smalltalk foi a primeira
linguagem de programao que possua suporte para a orientao a objeto. Mas a
linguagem que popularizou a orientao a objeto foi a C#, inicialmente conhecida
como C com classes.
Em 1991, a empresa Sun MicroSystem criou o Green Project, considerado o bero
do Java. A ideia que nasceu desse projeto, que era a interao entre o equipamento e
usurio, evoluiu e com o estouro da internet e em janeiro de 1995 ele foi batizado
de Java. As principais caractersticas do Java so: a orientao a objetos, sua portabi-
lidade, possui uma grande biblioteca de rotinas e a segurana para executar progra-
mas via rede com restrio de execuo. O Java no tem suporte para o conceito de
herana mltipla, podendo ocorrer falhas ao chamar este mtodo; uma possibilidade
de se usar herana mltipla no Java atravs de interfaces.
O C# ou C Sharp teve incio em 2001; ele uma linguagem visual dirigida por
eventos e orientada a objetos que foi criada pela Microsoft como parte da plataforma
.NET. Essa linguagem teve como base o C++, mas tambm possui influncias de
linguagens como object pascal e Java. Uma curiosidade sobre o smbolo #, usado
no nome C#, que ele se refere a um smbolo musical denominado sustenido, na
msica, ele significa que aumenta em meio tom uma nota musical. As principais ca-
ractersticas do C# so: ela uma linguagem simples, totalmente orientada a objetos,
fortemente tipada e flexvel.
A modelagem orientada a objeto surgiu por causa da incompatibilidade da mo-
delagem estruturada com a programao orientada a objeto. Alguns exemplos de
modelagem orientada a objeto so Coad (1991), OMT (1991), OOSE (1992), Fuso
(1995), UML (1996). Vamos comentar mais sobre a modelagem UML ainda nesta seo.
Outros motivos que influenciaram na criao da modelagem orientada a objeto
foram os avanos na tecnologia de arquiteturas de computadores, que suportam so-
fisticados ambientes de programao e interfaces homem-mquina; e as linguagens
de programao com recursos como modularizao e ocultamente de informao.
Alguns autores utilizam o termo crise do software para retratar os problemas asso-
ciados ao modo como o software criado e como feita sua manuteno.
Uma vantagem de se usar a tecnologia de orientao a facilidade de reutiliza-
o de cdigo. Os modelos refletem o mundo real de um modo mais aproximado,
descrevendo de maneira mais precisa os dados. Pequenas mudanas nos requisitos
no implicam grandes alteraes no sistema em desenvolvimento.
Neste momento voc pode estar se perguntando: mas o que a orientao a objeto?
Bom, orientao a objeto um paradigma para o desenvolvimento de sistemas, baseado
na utilizao de objetos que colaboram para construir sistemas mais complexos, essa
colaborao entre os objetos realizada por meio do envio de mensagens.
Para saber mais

Paradigma um conjunto de regras que delimitam fronteiras e descrevem como resolver pro-
blemas dentro dessa fronteira, o paradigma nos ajuda a organizar e coordenar a maneira como
olhamos o mundo.
2.2.1 Etapas da modelagem orientada a objeto

A anlise orientada a objetos um processo de construo de modelos em que
se identifica e especifica um conjunto de objetos que interagem e comportam-se
conforme os requisitos estabelecidos para o sistema.
Segundo Rumbaugh (1994), um modelo completo de sistema composto por

submodelos que expressam vises diferentes da mesma realidade, sendo elas divi-
didas em:
Viso de objetos: descreve estaticamente os objetos que compem o sistema
e seus relacionamentos por meio de diagramas de objetos;
Viso dinmica: descreve os aspectos do sistema que se modificam com o
passar do tempo;
Viso funcional: descreve as transformaes dos valores dos dados de um
sistema.
A modelagem visual um jeito de pensar sobre problemas, verificando ideias do
mundo real. As vantagens desse modelo so que facilitam a compreenso do pro-
blema e a comunicao entre tcnicos e usurios alm de montar a documentao
do sistema.
J um projeto orientado a objetos o processo em que existe uma especificao
detalhada do software a ser desenvolvido, de modo que essa especificao possa
levar direta implementao no ambiente-alvo.
E a programao orientada a objetos um modelo de programao que se baseia
em conceitos como classes, objetos, herana e polimorfismo. Tem como objetivo a
resoluo de problemas baseada na identificao de objetos e o processamento re-
querido por esses objetos, e ento na criao de simulaes desses objetos. Temos a
programao por meio da especificao de classes e criao de hierarquias, sendo que
propriedades comuns so transmitidas das superclasses para as subclasses pela herana.

Voc sabia que temos uma distino entre linguagens baseadas em objetos
e linguagens orientadas a objetos? Vamos entender um pouco como essa
distino se d.
Uma linguagem baseada em objetos quando ela fornece apoio somente ao

conceito de objetos. Temos como exemplo Ada e Visual Basic. J uma linguagem
orientada a objetos aquela que fornece apoio a objetos, solicita que objetos sejam
instncias de classes e oferecem um mecanismo de herana, como exemplo o C++,
Java e Smalltalk. Alm dessa classificao tambm temos as linguagens hbridas e
linguagens puras. Voc pode verificar mais detalhes sobre cada uma delas nos livros
de linguagem de programao.
Para saber mais

Acesse os links a seguir para encontrar mais detalhes do histrico das linguagens de
programao:
<http://pt.wikipedia.org/wiki/Java_(linguagem_de_programa%C3%A7%C3%A3o)>.
<http://pt.wikipedia.org/wiki/C%E2%99%AF>.
<http://www.oficinadanet.com.br/artigo/526/c_sharp_csharp_o_que_e_esta_linguagem>.
<https://www.portaleducacao.com.br/informatica/artigos/6137/historia-e-caracteristicas-
da-linguagem-c>.
<http://www.infoescola.com/informatica/historia-do-java/>.
<http://olhardigital.uol.com.br/noticia/linguagem-java-um-pouco-de-historia/35728>.
Alguns dos conceitos e caractersticas utilizados em orientao a objeto so: ob-

jetos, atributos, estados, polimorfismo, herana, encapsulamento, interaes, classes,
confiabilidade, reusabilidade, manutenibilidade, extensibilidade e outros que sero
detalhados ainda nesta unidade.
A reusabilidade uma das principais caractersticas da orientao a objeto,
sendo que ela faz a reutilizao dos componentes do sistema. Com ela dimi-
numos o custo do projeto reutilizando componentes e objetos fazendo com
que o desenvolvimento do software seja mais rpido sem diminuir a qualidade.
A manutenibilidade visa facilidade em fazer manuteno ou realizar alguma
customizao.
A confiabilidade vem do encapsulamento, pois permite um maior controle e
segurana s classes dos objetos.
Extensibilidade a medida da facilidade em se adicionar novas funcionalidades
(operaes) a um componente de uma modelagem existente. Alguns autores
dizem que a extensibilidade uma vantagem obtida com a herana e o
polimorfismo.
Segundo Rumbaugh (1994), a orientao a objeto trata-se de uma nova maneira de
pensar os problemas utilizando modelos organizados a partir de conceitos do mundo
real, sendo o principal componente o objeto, que combina dados e comportamento.
A orientao a objeto tem bases conceituais e origem no campo de estudo da
cognio, influenciando nas reas da inteligncia artificial e lingustica.
Uma linguagem visual utilizada para modelar sistemas orientados a objetos a UML
(do ingls Unified Modeling Language ou Linguagem de Modelagem Unificada). A UML
tem como objetivo descrever um sistema usando diagramas orientados a objetos.
A UML foi desenvolvida por Grady Booch, James Rumbaugh e Ivar Jacobson,
sendo que eles possuem um grande conhecimento na rea de modelagem orientada
a objeto, desenvolveram a UML, unindo seus conhecimentos e acrescentando novos

conceitos e vises de linguagens.
Para saber mais

Que Grady Booch, James Rumbaugh e Ivar Jacobson eram conhecidos como os trs amigos,
devido a unio do que havia de melhor nas trs metodologias orientadas a objetos mais con-
ceituada (Booch, OMT e OOSE).
A UML possui vrios diagramas, sendo os diagramas estruturais (classe, componen-

tes, pacotes, estrutura composta), diagramas comportamentais (caso de uso, estados,
atividade) e diagrama de interao (sequncia, interao, tempo, colaborao). A
seguir vamos descrever alguns destes diagramas:
Diagrama de Casos de Usos: um documento que descreve a sequncia de
eventos de um ator (que pode ser um humano ou entidade que interage com
o sistema) para completar um processo.
Diagrama de Classe: representa as relaes entre as classes. Ser detalhado no
item 1.2.11 desta seo.
Diagrama de Sequncia: representa a sequncia de processos (mensagens) em
um programa de computador.
Diagrama de Colaborao: mostra a interao de objetos e seus relacionamen-
tos, mostrando as mensagens que podem ser trocadas entre eles. Os diagramas
de sequncia e de colaborao so isomrficos.
Diagrama de Estados: pode ser denominado diagrama de transio de estados.
Representa o estado em que um objeto pode se encontrar no decorrer da exe-
cuo de processos de um sistema.
Diagrama de Atividades: representa os fluxos conduzidos por processamentos.
Diagrama de Componentes: mostra como as classes devero se encontrar or-
ganizadas por meio da noo de componentes de trabalho.
Diagrama de Implantao: pode ser denominado diagrama de instalao. Mos-
tra componentes de hardware e software e sua interao com outros elementos.
Diagrama de Estrutura Composta: descreve o relacionamento entre os elementos.
Diagrama de Tempo: pode ser denominado diagrama temporal. Mostra o com-
portamento dos objetos e sua interao em uma escala de tempo.
Diagrama de Pacotes: mostra os pacotes (representa um grupo de classes) di-
vididos em agrupamentos lgicos mostrando as dependncias entre eles.
Para saber mais

A UML foi uma tentativa de Jim Rumbaugh e Grady Booch de combinar dois mtodos de mo-
delagem orientada a objeto: Booch e OMT. E aps um tempo Ivar Jacobson se juntou a eles e
criaram a primeira verso da UML.
Vamos verificar como est seu conhecimento at agora?
1. correto sobre a orientao a objeto:
I. Orientao a objeto um paradigma para o desenvolvimento de sis-
temas, baseado na utilizao de objetos que colaboram para construir
sistemas mais complexos.
II. Todo o processo deve ter um fluxo de entrada e de sada.
III. Tem como caracterstica o polimorfismo e herana.
IV. Tem como caracterstica a criao de diagramas como o de fluxo de
dados (DFD) e diagrama de entidade relacionamento (DER).
a) Itens I e II e IV so verdadeiros.
b) Itens I e IV so verdadeiros.
c) Somente o item II falso.
d) Somente o III verdadeiro.
e) Itens I, III e IV so verdadeiros.
2. Na questo acima qual(is) o(s) item(ns) que no se refere(m) a modelagem
orientada a objeto, e por qu?
2.2.2 Objetos
Objetos so itens do mundo real, mas na computao consiste na ocorrncia da
classe. Todo objeto possui identidade prpria e um estado, o qual pode ser alterado
quando recebe uma mensagem ou evento.
Um objeto possui um estado, normalmente implementado por meio de seus atri-
butos. Uma identidade nica, ou seja, a propriedade de um objeto distingue-se de
outros objetos. Essa identidade no o nome do objeto, nem o endereo de memria
onde ele est armazenado, mas sim um conceito de linguagens de programao que
no visvel para os usurios. Trata-se de um comportamento que define como
ele reage s requisies de outros objetos, em termos de mudanas de estados e

passagem de mensagens.
A mensagem ocorre quando se realiza uma chamada a um objeto, invocando um
dos seus mtodos e ativando um comportamento de sua classe.
Os objetos so responsveis por atuar sobre os seus atributos e tambm sobre
outros objetos, para isso desempenham diversas operaes.
Podemos dizer tambm que os objetos so instncias de uma classe [ver item 2.2.5]
e a instncia cada ocorrncia de um objeto criado na memria a partir de uma
classe existente.Vamos trocar tudo isso em midos?
Exemplos:
Quadro 4.1 Exemplos da distino entre classes e instncias
Classe Objeto da Classe (Instncia)
Pessoa Thiago, Dominik, Nicole, Manuela, Erika, Leo, Isabela...
Animal Cachorro, gato, macaco...
Veculo Gol, HB20, Fiesta, Fusca, Ferrari...
Quando estamos identificando os possveis objetos ou as possveis classes, estamos

tratando do nosso poder de abstrao, ou seja, da habilidade mental que permite aos
seres humanos visualizar os problemas do mundo real com vrios graus de detalhe.
Podemos pensar no cenrio em que temos de fazer o levantamento de requisitos
para um novo projeto de sistema solicitado, seja por e-mail, telefone ou pessoal-
mente. E nesse momento nosso cliente nos apresentar suas necessidades, ou seja,
seus desejos para um novo sistema e ns temos de pensar em uma soluo em nvel
de sistema para atend-lo.
E importante salientar que nenhum objeto uma ilha, eles podem ser rela-
cionados a outros de forma direta ou indireta, forte ou fracamente. Segundo Mike
ODocherty (2005) os objetos podem ser relacionados por associao ou agregao.
A associao trata de uma conexo formal entre os objetos, sendo que no h
uma dependncia completa entre eles. Os objetos so parte de um grupo, porm no
so dependentes um do outro.
Exemplo: Considerando uma sala de aula, com professores e alunos, todos esto uni-
dos nesse ambiente, ou seja, associados, porm, um aluno pode deixar a sala de aula,
esse aluno no estar mais no grupo, porm, o grupo continua com os demais envolvidos.
Figura 4.3 Um aluno deixa a sala de aula, mas a aula continua com os demais,
podemos relacionar essa situao com uma associao
Fonte: Oliveira (2010).
A agregao une os objetos para criar um objeto maior, ela j estabelece uma
dependncia entre os objetos.
Exemplo: Considerando a estrutura fsica de uma sala de aula, a relao entre pa-
redes e porta, afinal, no possvel entrar em uma sala ou sair dela sem passar pela porta,
no mesmo?
Figura 4.4 Espao fsico de uma sala de aula, representado uma agregao, visto
a dependncia dos objetos na estrutura fsica
Fonte: Archideaphoto/Shutterstock (2014).

2.2.3 Atributos
Atributos so todas as variveis de um objeto. Descrevem as caractersticas dos
objetos, definindo os dados que devem ser armazenados (BEZERRA, 2007). Quando
colocamos um atributo na classe, devemos informar o tipo de visibilidade, nome do
atributo, tipos de dados e se eles tm um valor inicial ou no.
Notaes:
Visibilidade: Refere-se ao escopo de acesso permitido para um membro de uma
classe, definidas em pblica (+), protegida (#), privada (-) [ver item 2.2.10].
Nome do atributo: iniciar com letra minscula (quando a palavra for com-
posta, a segunda inicia com letra maiscula).
Tipo de dado: apresenta a espcie de informao que pode ser armazenada
no atributo. informado aps os dois pontos (:).
Exemplos:
Classe UML: <<visibilidade>> <<nomeAtributo>>: <<tipo de dado>>
#nomeCliente: String
- tipoCliente: String
Implementao Java: <<visibilidade>> <<tipo de dado>> <<nomeAtributo>>;

protected String nomeCliente;
private String tipoCliente;
Para saber mais

Voc lembra alguns tipos de dados?
Por exemplo, a linguagem de programao Java para fazer suas representaes para o compu-
tador possui oito tipos primitivos (por darem origem a todos os outros), sendo eles: boolean,
byte, char, double, float, int, long e short. E so divididos em:
Tipos inteiros: byte, char, int, long e short.
Tipos de ponto flutuante: double e float.
Tipo boleano: boolean.
Nota: Em Java esses tipos primitivos tambm so palavras reservadas e voc no pode, por
exemplo, criar uma varivel chamada double.
2.2.4 Operaes ou mtodos

A operao a definio do comportamento de uma classe, porm, sua ao s
ocorre quando essa operao chamada por um objeto. A implementao de uma
operao chamada de mtodo.
Notaes:
Visibilidade: Refere-se ao escopo de acesso permitido para um membro de uma
classe, definidas em pblica (+), protegida (#), privada (-) [ver item 2.2.10].
Nome: identifica um recurso comportamental especfico de uma classe de
objeto, para ser eficaz, dever ser o mais significativo e expressivo possvel.
Tipo de dado: apresenta a espcie de informao que pode ser armazenada
no atributo.
Tipo de retorno: a sada da operao, podendo retornar um tipo de dado
ou no possuir retorno e ser representado com a palavra reservada void.
Lista de parmetro: uma lista dos atributos que juntos definem a entrada
para uma operao.
Exemplos:
Classe UML: <<visibilidade>> <<nomeOperao (nome_parametro : tipo_dados)>>:
<<tipo de retorno>>
- setNome(novoNome : String): void
- getNome(): String
Implementao Java: <<tipo de acesso>> <<tipo de retorno>> <<nome>>
<<(tipo_parametro nome_parametro>> {Implementao do mtodo}
/**
* Mtodo responsvel por setar um novo nome para a varivel nome.
* @param novoNome ser o valor que a varivel nome receber.
*/
public void setNome(String novoNome){

nome= novoNome;
}
/**
* Mtodo responsvel por retornar o valor contido na varivel nome.
*/
public String getNome(){

return nome;
}
2.2.5 Classe
A classe um conjunto de objetos que possuem caractersticas e comportamentos
semelhantes, elas representam algo do mundo real, um objeto, definindo suas carac-
tersticas e comportamentos. As classes so implementadas por mtodos e atributos
(FURLAN, 1998) tendo uma identidade prpria e um estado, que pode ser alterado
por um evento. As classes so os blocos de construo mais importante de qualquer
sistema orientado a objetos. Traando um pequeno paralelo entre o mundo real e o
mundo computacional, temos:
Figura 4.5 Blocos de construo das classes
Caractersticas Atributos
Comportamentos Mtodos
Para atribuio dos nomes das classes, orientado seguir alguns padres, seja
por restrio da linguagem ou por questes de qualidade em que a orientao que
sejam adotados padres e que sejam seguidos dentro das fbricas de software.
Vejam algumas orientaes para criao das classes:
a primeira letra deve ter a inicial maiscula;
o nome deve estar no singular;
o nome no deve comear com nmeros, mas pode conter nmeros;
o nome no pode ser acentuado. A linguagem Java at far a compilao e no
acusar erros, mas aconselhvel a no acentuao;
em caso de nomes compostos, eles devem formar uma nica palavra, em que
a primeira e a segunda palavras tm a letra inicial maiscula.
Exemplo:
PessoaFisica PessoaJurica
Na UML, as classes so representadas por retngulos que contm seu nome,

atributos e mtodos. As classes podem ser classificadas como concretas ou abstratas.
A representao da classe feita por um retngulo subdividido em trs partes:
Nome da Classe, Atributo e Operao.
Exemplo:
Figura 4.6 Representao de classe
Nome da Classe
Atributos
Operao
Exemplo de uma classe:
Figura 4.7 Representao da classe cliente
Cliente
+ codigoCliente : int
# nomeCliente: String
# tipoCliente: String
+ incluirCliente (nome: String): void
# deletarCliente (codigo: int): void
- informarTipo (cdigo: int): int

Se no existisse a Orientao a Objetos seria possvel os trs amigos criarem
a UML?
2.2.5.1 Classe abstrata

A classe abstrata, tambm conhecida como classe genrica, desenvolvida para
representar entidades e conceitos abstratos, no gera objetos, porque ela tem, pelo
menos, uma operao abstrata definida. Uma operao tambm pode ser abstrata se
ela no possuir implementao. A classe abstrataservir como base para a criao
de outras classes, sendo que ela sempre uma superclasse que no possui instncias.
Ela define um modelo para uma funcionalidade e fornece uma implementao in-
completa, a parte genrica dessa funcionalidade, que compartilhada por um grupo
de classes derivadas. Cada uma das classes derivadas completa a funcionalidade da
classe abstrata adicionando um comportamento especfico.
As classes concretas implementam todos seus mtodos e permitem a criao
de instncias, esse tipo de classe no possui mtodos abstratos e podem ser classes
derivadas de uma classe abstrata.
Figura 4.8 Exemplo de classes abstratas e concretas
CLASSES CONCRETAS
CLASSE ABSTRATA
Na UML, as classes abstratas se diferem das concretas por serem representadas com
o nome em itlico. Por exemplo: A classe Cliente representada acima ficaria Cliente.
Exemplo de Classe abstrata em Java e C#:
abstract class NomeClasse{
}
Exemplo de Operao abstrata em Java e C#:
public abstract void nomeOperacao();
Para realizar a ligao entre as classes temos os relacionamentos: associao,
agregao, composio, dependncia e multiplicidade.
2.2.6 Relacionamento entre classes

Relacionamentos so as ligaes entre as classes. Os relacionamentos tm nome,
sentido da leitura, navegabilidade, papis, multiplicidade e tipo.
Figura 4.9 Exemplo de relacionamento

Associao: esse relacionamento permite a comunicao de um objeto de uma

classe com o objeto de outra classe. Ele representado por uma linha slida
entre duas classes.
Figura 4.10 Modelo de associao
Agregao: ela mostra que o objeto-parte faz parte do objeto-todo, e represen-

tada por uma linha com losango sem preenchimento no parte da classe dona.
Figura 4.11 Modelo de agregao
Generalizao: tambm conhecida como herana ou classificao, o rela-

cionamento entre a classe-me e as classes-filhas.
Dependncia: esse relacionamento indica que os objetos de uma classe usam de
servio de objetos de outra classe. Ao mudar o objeto da classe independente,
afetar o objeto da classe dependente.
Multiplicidade: a quantidade de instncia de uma classe relacionada com
a quantidade de instncia da outra classe; depende de pressupostos e de
como so definidas as fronteiras de um problema. Ela pode ser infinita nos

nmeros inteiros e no negativos. A Tabela 4.1 representa alguns exemplos de
multiplicidade.
Tabela 4.1 Multiplicidade entre as classes
Multiplicidade Significado
0..1 zero ou um
1 Somente um
0...* ou 0...n Maior ou igual a zero
* ou n Maior ou igual a zero
1...* ou 1...n Maior ou igual a 1
1...10 Intervalo de 1 a 10
1...5 , 10...15 Intervalo de 1 at 5 ou 10 at 15
2.2.7 Interfaces
A interface define a forma de comunicao entre duas entidades, podendo ser enten-
dida como uma abstrao, estabelecendo interao da entidade com o mundo exterior. Ela
pode oferecer um servio de traduo entre as entidades que no falam a mesma lngua.
Neste item vamos citar as interfaces do usurio e interface fsica, nos quais in-
terface fsica utilizada para conectar componentes de hardware, j a interface do
usurio utilizada na interao homem-mquina.
Figura 4.12 Exemplo de interface
Fonte: Carvalho (2014).

2.2.8 Encapsulamento
Podemos dizer que encapsular seria esconder do usurio os processos internos
de um objeto, classe ou mtodo. Dentro da linguagem orientada a objeto, podemos
encapsular o estado do objeto, ou seja, cada objeto de uma classe pode ter limitadores
de acesso. Esses limitadores so pblico (+), protegido (#), privado (-) e default(~)
que servem para os atributos e operaes (mtodos).
Pblico (public), quando acessado por qualquer classe, sendo que:
Uma classe pblica ficar visvel ou acessvel a todas as classes e compo-
nentes do sistema.
Uma operao ou atributo pblico tambm passam a ficar visveis ou acess-
veis para as demais classes do sistema, porm, s sero acessados por meio
de uma instncia de um objeto dessa classe.
Protegido (protected), quando os atributos e operaes so visveis ou acessveis
somente pela prpria classe e subclasses [ver item 2.2.11].
Privado (private), quando os atributos e operaes so visveis ou acessveis
somente pela sua classe.
Default, quando os atributos e operaes so visveis ou acessveis dentro de
um pacote (package) do sistema.
O encapsulamento permite um maior controle e segurana s classes de objetos,

tornando-o mais confivel.
Figura 4.13 Exemplo de encapsulamento
Fonte: Bezerra e Woszezenki (2014).

A visibilidade apresentada pode ser aplicada somente a atributos?
2.2.9 Herana
Herana quando uma classe (classe-filha ou subclasse) utiliza atributos e/ou
mtodos de outra classe (classe-me ou superclasse). Esse conceito eficiente em
tornar o cdigo-fonte, mas organizado e facilita quando alteraes so necessrias.
Vimos no item 2.2.5 sobre classes o conceito de classe abstrata e concreta, voc
se lembra desse conceito? Ele muito utilizado na herana. Vamos fazer um pequeno
exerccio para testar seu conhecimento.
1. Indique com V para verdadeiro e F para falso:
() Classe abstrata a superclasse (ou classe me).
() Classes concretas so as classes-filhas.
() Classe concreta permite a criao de instncias.
() Classes abstratas so desenvolvidas para representar entidades e con-
ceitos abstratos.
2. Uma propriedade, operao ou atributo representado no diagrama de classes
da UML, que poder ser visto e usado apenas pela classe na qual foi de-
clarado, bem como pelas suas classes descendentes, deve ser definido com
visibilidade descrita por meio da palavra-chave:
a) Protected.
b) Public.
c) Local.
d) Package.
e) Private.
Outro conceito importante na herana o de reusabilidade, que a reutilizao de

componentes de software e diminuio do tempo de desenvolvimento. A reusabilidade
facilita reaproveitar os cdigos, objetos encapsulados, componentes e frameworks;
tambm um dos conceitos abordados nas caractersticas da OO.
Figura 4.14 Representa a herana da classe Cliente para as subclasses

ClienteFisica e ClienteJuridica
Tambm podemos ter o conceito de herana mltipla, isso ocorre quando temos de
definir uma subclasse com mais de uma superclasse. Se pensarmos no nvel do conceito,
a herana mltipla utilizada para modelar o mundo real de um modo mais preciso, mas,
colocando em prtica, ela pode levar a problemas na implementao pois nem todas
as linguagens de programao orientadas a objetos tm base para a herana mltipla.
Vamos criar um exemplo para heranas mltiplas; nesse caso uma subclasse deve
herdar caractersticas e comportamentos de duas ou mais classes (superclasses).
Imagine que voc tenha uma classe para representar Filhote, porm, essa classe herda
caractersticas e comportamento de duas classes j existentes Cachorro e Gato. Nesse
caso a classe Filhote ser uma especializao das classes generalizadas Cachorro e Gato.
Figura 4.15 Exemplo de herana mltipla

Exemplo de herana em Java:

public class ClasseFilha extends ClassePai{
}
Usando o exemplo da Figura 4.13 teremos:
public class ClienteFisica extends Cliente{
}
Exemplo de herana em C#:
public class ClasseFilha : ClassePai{
}
Usando o exemplo da Figura 4.13 teremos:
public class ClienteFisica : Cliente{
}

Vamos supor que voc tenha uma classe Pai com um atributo Privado.
Pergunta: A classe-filha que herdar as suas caractersticas poder visualizar
esse atributo?
2.2.10 Polimorfismo
O polimorfismo caracterizado quando duas ou mais classes tm mtodos de
mesmo nome, de forma que uma funo possa utilizar um objeto de qualquer uma
das classes polimrficas, sem necessidade de tratar de forma diferenciada conforme
a classe do objeto.
Para saber mais

O termo polimorfismo tem origem grega e significa muitas formas? Vamos quebrar a palavra
(Poli = muitas e morphos = formas).
Podemos definir como sendo um cdigo que produz vrios comportamentos, ou

seja, esse cdigo pode ser aplicado a diferentes classes.
Alguns dos padres de projeto de software baseiam-se no uso de polimorfismo,
como: abstract factory, composite, observer, strategy e template method.
Existem alguns tipos de polimorfismo: Universal (incluso ou paramtrico) e

ad-hoc (sobrecarga quando duas funes/mtodos com o mesmo nome, mas as-
sinaturas diferentes).
Figura 4.16 Tipos de polimorfismo
Fonte: Kioskea.net (2014).
O polimorfismo a base para vrios padres de projeto, podemos destacar alguns:

Abstract factory. Strategy.
Composite. Template method.
Observer.
2.2.11 CRUD
O CRUD um termo utilizado em programao para representar as quatro ope-
raes bsicas. So elas: criar (create), ler (read), atualizar (update) e excluir (delete).
O termo CRUD foi inicialmente popularizado por James Martin em seu livro
Managing the Data-base Environment de 1983.
Podemos utilizar outros siglas para definir as mesmas operaes sendo:
ABCD: Add, Browse, Change e Delete
BREAD: Browse, Read, Edit, Add e Delete
VADE(R): View, Add, Delete, Edit (e Restore, para sistemas com processos
transacionais)
VEIA: Visualizar, Excluir, Inserir, Alterar
A matriz CRUD, ou matriz de interaes, pode ser utilizada para verificar as

relaes entre funcionalidades (ou atividades) e entidades (ou tipos de objetos de
dados) dentro de um sistema de informao.
Ela construda de forma que as funcionalidades so listadas num dos seus eixos, e
as entidades, no outro. As clulas de interseo denotam o tipo de interao existente, ou
seja, mostram que entidade ser afetada pela execuo de determinada funcionalidade e
explicita as propriedades CRUD para tal interseo. Portanto, cada uma das suas clulas
descreve as aes que uma atividade exerce sobre o tipo de objeto de dados associado,
que podem ser: Create (incluso), Read (leitura), Update (atualizao) e Delete (excluso).
Figura 4.17 Matriz CRUD
Fonte: Pluriverso (2014).
2.2.12 Diagrama de classe

Diagramas so representaes visuais de uma estrutura; o diagrama de classe
uma representao das estruturas e relacionamentos das classes. uma modelagem
importante para o desenvolvimento do software. O diagrama de classes o mais im-
portante diagrama da UML e a partir desse diagrama outros diagramas so elaborados.
Segundo Fowler e Kendal (2000, p. 57), um diagrama de classes descreve os
tipos de objetos no sistema e os vrios tipos de relacionamentos estticos que existem
entre eles. O diagrama de classe composto pelas classes e seus relacionamentos,
que podem ser associao, composio e dependncia.
Para organizar o diagrama de classes comum os analistas adotarem um padro
para nome-las.
Podemos classificar as classes em classe de negcio, classe de controle, classe
de interface:
Na classe de negcio ou de informaes lgicas, seus objetos possuem dados
que ficam disponveis por longos perodos de tempo.
Exemplo: Classe Cliente.
As classes de controle possuem os processos/algoritmos; elas incluem funcio-
nalidades que no podem ser atribudas s classes de interface ou s classes
de negcio. Ex.: Cotao.
Classes de Interface possuem os objetos tcnicos. Incluem funcionalidades
que so diretamente dependentes do ambiente de sistema. Essa classe altera
as entradas do ator nos eventos do sistema e apresenta as sadas. Ex.: Menu.

A orientao a objetos (OO) no tira a necessidade de implementar os siste-
mas, e nem est relacionada apenas fase de implementao. Ela tambm
no garante a reutilizao dos objetos, mas oferece mecanismos para que
ocorra e sempre ser funo do desenvolvedor garantir isso. Com base nisso,
voc consegue identificar vantagens e desvantagens na OO?
2.2.13 Resoluo de um estudo de caso

Vamos colocar em prtica o que vimos at o momento. Neste tpico teremos um
estudo de caso, em que vamos juntos encontrar um resultado. Lembrando que cada
analista que verificar a atividade poder encontrar respostas diferentes. Esse estudo
de caso trata de um sistema de matrcula.
A escola O Sabido deseja informatizar seu sistema de matrcula. Essa escola

oferece vrios cursos. O coordenador do curso define quais as disciplinas a serem
oferecidas no semestre. Cada curso tem vrias disciplinas, e cada disciplina pode
ter vrias turmas. Cada disciplina tem um professor.
O aluno solicita na matrcula o curso e o semestre a estudar. O sistema
verifica as informaes de matrcula e, se estiver correto, o sistema matricula o
aluno, caso tenha algo errado, o sistema gera um erro e solicita novo cadastro.
O aluno pode se matricular em mais de um curso.
O sistema deve informar dados como o nome e a titulao do professor, sala
e o turno das turmas, o nome e a matrcula do aluno e nome da disciplina.
Com base nessa descrio, vamos iniciar buscando pelas classes. De incio po-
demos citar as classes: aluno, disciplina, turma, professor e curso. Voc encontrou
mais alguma?
Figura 4.18 Classes encontradas no modelo de estudo de caso
As classes a seguir possuem atributos. Agora sua vez, olhando para essas classes
e o estudo de caso, quais atributos voc consegue identificar?
Figura 4.19 Classes com atributos
Verifique a multiplicidade no texto:

cada disciplina tem um professor,
o aluno pode se matricular em mais de um curso.
Vamos verificar como fica no diagrama?
Figura 4.20 Diagrama de classe do sistema de matrcula
Como seria a leitura desse diagrama? O curso possui uma ou vrias disciplinas.
Uma disciplina possui uma ou mais turmas. Continue a leitura do diagrama.
E voc achou outra soluo para esse estudo de caso? Onde colocaria as infor-
maes sobre o coordenador, teria uma classe coordenador ou um atributo na classe
professor que identificaria o atual coordenador do curso? Vamos fazer um teste para ver
como esse diagrama ficaria se fizssemos uma pequena alterao no texto? Vamos l...
Para o aluno, professor e coordenador, devemos gravar dados como seu nome,
telefone fixo e telefone mvel, endereo para correspondncia, e-mail, RG e CPF. Os
documentos devem ser validados. Para o professor e coordenador temos de gravar a
titulao. O coordenador tambm pode dar aulas.
Podemos utilizar aqui o conceito de herana? Como ficaria no diagrama? Vamos
a mais um exemplo.
Figura 4.21 Utilizao de herana no modelo de sistema

de matrcula

Verifiquem que mudar um detalhe que aparentemente simples pode fazer
uma grande diferena no sistema pronto, por isso importante dar uma aten-
o maior na fase de anlise.
2.2.14 Estudo de caso Advocacia

Nesta unidade, voc aprendeu o que uma classe, seus atributos, mtodos e o
relacionamento entre eles. Agora hora de colocar em prtica o que aprendeu. Neste
estudo de caso, voc ter a oportunidade de localizar as classes, fazer o relaciona-
mento, informar seus atributos e mtodos. Ento, mos obra...
O advogado Joo Carlos Saranza solicita um sistema para controle dos clientes
do seu escritrio. Ele comenta que tem clientes como pessoa fsica e tambm
atende a pessoas jurdicas. Para o cadastro de clientes necessrio anotar dados
como nome, endereo, telefones. Para a pessoa jurdica necessrio guardar o
CNPJ e o nome do responsvel. Para a pessoa fsica necessrio documentos
pessoais como RG e CPF e estado civil.
O advogado informa que costuma registrar vrios telefones do cliente, como o
da casa, celular, trabalho e ramal. Para o endereo tambm necessrio registrar
o da casa e do trabalho.
Vinculados aos clientes esto os contratos, cada caso/ao em que o advogado
atua, necessrio um novo contrato.
Exemplo: Se a cliente Valeska Houser o contratou para um dvida trabalhista,

ele faz um contrato para essa ao. Caso a mesma cliente precise do servio em
uma ao de penso, ele executa outro contrato com ela. Nesse cadastro ne-
cessrio informar o status da ao, ou seja, se est ativa, cancelada ou encerrada.
Ele cita que algumas aes so vinculadas a vrios clientes.
Seu escritrio possui vrias equipes de advogados, separados por tipo de ao,
sendo trabalhista, civil, famlia, previdencirio e ambiental.
Caro aluno, agora a sua vez. Voc o analista, ento, inicie identificando:
as classes;
os atributos;
os mtodos;
os relacionamentos entre as classes.
Lembrando que durante a anlise pode ser que voc identifique melhorias para
o sistema.
Agora que j lemos muito, vamos realizar mais atividades?
1. Voc lembra quais so as caractersticas da orientao a objeto? Das citadas
abaixo, qual a correta?
a) Confiabilidade: uma linguagem visual utilizada para modelar sistemas
orientados a objetos.
a) Reusabilidade: reutilizao dos componentes do sistema.
a) Extensibilidade: visa facilidade em dar manuteno ou realizar al-
guma customizao.
a) Manutenabilidade: permite um maior controle e segurana s classes.
a) Todas esto incorretas.
2. Relacionando as colunas
a) UML 1. reutilizao dos componentes do sistema.
b) Manutenibilidade 2. permite um maior controle e segurana s classes.
3. visa facilidade em dar manuteno ou realizar

c) Confiabilidade
alguma customizao.
4. uma linguagem visual utilizada para modelar
d) Reusabilidade
sistemas orientados a objetos.
5. a medida da facilidade em se adicionar novas
e) Extensibilidade
funcionalidades.
Assinale a alternativa que traz a combinao correta.

a) A4, B3, C5, D1, E2.
b) A1, B3, C2, D4, E5.
c) A4, B3, C2, D1, E5.
d) A4, B5, C2, D1, E3.
e) A2, B3, C4, D1, E5.
2.2.15 Estudo de caso Revenda de automveis

Vamos trabalhar com mais um estudo de caso para refinar seus conhecimentos?
Uma oficina de automveis quer modificar a forma de gerenciar seus registros

de servios de manuteno.
A responsvel pela oficina deseja criar um software para gerenciar esses itens,
e para realizar o desenvolvimento contratou um aluno do curso de Tecnologia
em Anlise e Desenvolvimento de Sistemas, o Marcos Firmino.
Esse aluno, lembrando-se dos ensinamentos da disciplina de anlise, disse
que inicialmente precisaria fazer um estudo do sistema existente e verificar quais
itens precisam ser ajustados. Firmino informou que desenvolver o sistema sendo
que inicialmente far uma boa documentao e as validaes com a cliente antes
de realizar as implementaes.
O aluno cria algumas perguntas para apoiar no levantamento de requisitos
e a partir delas descreve o seguinte cenrio:
A oficina Seu Carro Novo De Novo, solicita um novo sistema para controle
de manuteno de servios. A proprietria, a sra. Anaclesia Giacomo, apresenta
algumas funcionalidades que considera essenciais para o novo sistema, em que:
o sistema deve manter informaes sobre os carros e servios prestados
(como troca de peas, reviso etc.);
o sistema deve gerar relatrios de controle de servios, cadastro de clientes
e funcionrios e cadastro de carros.
Sobre os funcionrios, necessrio manter informaes como:
nome, endereo, telefone, data de admisso, nmero de registro, docu-
mentos pessoais como RG, CPF, nmero do PIS... , setor de lotao, cargo/
funo e no caso de ex-funcionrios tambm necessrio armazenar a data
de desligamento.
Para o registro do cliente, temos de armazenar:
nome, endereo, telefone, histrico de servios, documentos pessoais (RG
e CPF), local de trabalho e data de registro.
Para o histrico de servio, preciso guardar informaes como o cliente, o

carro, a data de realizao, qual funcionrio realizou o servio e a descrio do
que foi feito no veculo.
importante informar que vrios cadastros no podem ter dados excludos,
como o cadastro de cliente, carro, funcionrio e histrico. Mas em caso de lan-
amento incorreto a gerente poder cancel-lo.
Para todos os controles listados ao sistema dever permitir: incluir, alterar e
consultar dados.
Atualmente a oficina trabalha com carros das montadoras Ford, Fiat, GM, VW,
Toyota e Mitsubishi, mas a sra. Anaclesia j adianta que quer ampliar as marcas
a serem atendidas.
Para o controle de carro necessrio conter dados como:
montadora, o ano de fabricao, cor, modelo, placa e nome do proprietrio.
Existem vrios tipos de servios prestados, o cliente pode solicitar desde uma
reviso completa ou parcial nos veculos, o cliente tambm pode solicitar a parte
sobre esttica do veculo, com o servio do martelinho de ouro, instalao
de som, parte eltrica ou conserto em geral.
Um servio que a oficina oferece dar consultoria para o cliente, quando ele
resolve trocar ou comprar um novo carro. Eles verificam, entre outros, qual modelo
(sed, utilitrio, hatch, wagon e picape) o mais indicado para o cliente e, no
caso de compra de um usado, eles acompanham o cliente para avaliar o veculo.
Aps ouvir todas as necessidades da cliente, Firmino sugeriu que o sistema
tivesse seus controles realizados via web para que a sra. Anaclesia pudesse acessar
o sistema mesmo em uma viagem.
O aluno finaliza os registros e inicia a construo da modelagem do sistema.
Com base em suas anotaes ele solicita a ajuda para preencher algumas questes.
1. Podemos identificar algumas classes ao ler o estudo de caso. Marque quais
as alternativas so referentes a classes:
( ) funcionrio ( ) carro
( ) nome ( ) data de admisso
( ) cliente ( ) telefone
2. Relacione as classes com seus atributos
(A) funcionrio ( ) montadora

(B) cliente ( ) nome, endereo, telefone, data de registro
(C) carro ( ) nome, endereo, telefone, data de registro, local de trabalho
3. Verificando as classes funcionrio e cliente, podemos identificar alguns

atributos em comum, pensando em facilitar a manuteno do sistema,
o aluno resolve trabalhar com a caracterstica de herana. Para isso ele
identifica os atributos em comum, montando a tabela abaixo. Veja como
ficariam as classes:
Classe Funcionrio Classe Cliente

Nome Endereo Nome Endereo
Telefone Data de admisso Telefone Histrico servio
Nmero registro RG RG CPF
CPF PIS Local de trabalho Data registro
Lotao Cargo
Data desligamento
Verificamos que os atributos nome, endereo, telefone, RG, CPF se repe-
tem nas duas classes nesse caso podemos criar a classe Pessoa como a
superclasse, e Funcionrio e Cliente ficam como subclasses.
Como ficaria essa separao?
Pessoa (superclasse)
Nome
Endereo
Telefone
RG
CPF

Voc sabe qual das caractersticas da orientao a objetos a base para os
vrios padres de projeto?
Fique ligado!
Caro aluno, vamos lembrar aqui as principais questes abordadas nesta uni-
dade? Foram elas:
conceitos de modelagem de sistemas, tanto estruturada quanto orientada a
objetos (OO);
dentro da estruturada, abordamos o DER e o DFD;
dentro da OO, abordamos suas principais caractersticas e alguns conceitos
fundamentais;
a evoluo das linguagens orientadas a objetos;
alguns diagramas da UML;
alguns estudos de caso para trabalhar e despertar sua capacidade de abstrao
por meio de uma situao problema.

Vimos nesta unidade a modelagem estruturada e orientada a objeto, conhece-
mos sua histria e evoluo. Descrevemos sobre seus diagramas, colocando
uma nfase nos diagramas de fluxo de dados e entidade relacionamento no
item sobre modelagem estruturada e na modelagem de orientao a objeto.
Abordamos o diagrama de classe.
Aprendemos sobre os tipos de visibilidade (pblico, privado, protegido),
vimos as caractersticas da orientao a objeto como reusabilidade, objetos,
atributos, estados, interaes, classes, confiabilidade, reusabilidade, manuteni-
bilidade, extensibilidade, e como so importantes os conceitos de polimorfismo,
herana e encapsulamento.
E tivemos a oportunidade de resolver atividades para colocar em prtica o
que aprendemos.

1. A modelagem de dados um processo para a criao de um software.
Segundo Rumbaugh (1994), um modelo completo de sistema composto
por submodelos que expressam vises diferentes da mesma realidade. Na
viso de Rumbaugh, quais seriam esses submodelos?
a) Viso de objeto, viso dinmica, viso funcional.
b) Viso de objeto, viso de atributos, viso dinmica.
c) Viso de classe, viso dinmica, viso atributo.
d) Viso de objeto, viso classe, viso funcional.
e) Viso de classe, viso dinmica, viso esttica.
2. Em orientao um objeto muito utilizado o conceito de herana, que
quando uma classe (classe-filha ou subclasse) utiliza atributos e/ou m-
todos de outra classe (classe-me ou superclasse). Geralmente o usurio
de sistema no percebe esse conceito, voc conhece algum sistema que
se utiliza dele?
3. A linguagem orientada a objeto teve seu incio na dcada de 1960, antes
mesmo da modelagem orientada a objeto. Voc sabe o motivo que fez com
que surgisse a modelagem orientada a objeto?
4. Uma linguagem visual utilizada para modelar sistemas orientados a objetos
a UML unified modeling language. UML tem como objetivo descrever
um sistema, usando diagramas orientados a objetos. Durante esta unidade
falamos muito sobre um dos diagramas da UML. Voc saberia informar
quais so os diagramas da UML?
5. No diagrama de classe identificamos as visibilidades dos atributos e m-
todos. So elas pblica, protegida e privada. Descreva sobre cada uma e
identifique os smbolos.
6. Pelo texto abaixo, identifique qual a alternativa correta:
Temos uma classe pessoa, que possui os atributos endereo e telefone que
so protegidos, um atributo nome que pode ser visualizado por outras
classes, nenhuma outra classe pode ter acesso ao atributo RG. Essa classe
possui mtodos como incluir, alterar e consultar.
a) b)
c) d)
e)
Referncias
BEZERRA, Eduardo. Princpios da anlise e projeto de sistemas com UML. Rio de Janeiro:
Elsevier, 2007.
BEZERRA, E. A.; WOSZEZENKI, C. Encapsulamento. Linguagem de Programao C++.
Universidade Federal de Santa Catarina. Departamento de Engenharia Eltrica, CTC.
Disponvel em: <http://gse.ufsc.br/~bezerra/disciplinas/cpp/aulas/dia2_4.html>. Acesso em:
16 jul. 2014.
CARVALHO, U. W. O que significa Interface? Tecla Sap sua lngua falada em ingls.
2014. Disponvel em: <http://www.teclasap.com.br/o-que-significa-interface/>. Acesso em:
16 jul. 2014.
CHEN, Peter. Active conceptual modeling of learning: Next Generation Learning-Base
System Development. Editado por Leah Y. Wong. Springer, 2007.
COAD, Peter; YORDON, Edward. Anlise baseada em objetos. 2. ed. Rio de Janeiro:
Campus, 1998.
ODOCHERTY, Mike. Objwect-oriented analysis and design. Londres: John Wiley e sons, 2005.
FIGUEIREDO, Marcos Leandro; SOARES, Hlio Rubens. Comparao entre a modelagem
orientada a objeto e a modelagem estruturada relacional. Centro Universitrio do
Tringulo UNITRI Uberlndia MG. Disponvel em: <https://www.yumpu.com/
pt/document/view/12764245/comparacao-entre-a-modelagem-orientada-a-unicaldas-on-
line>. Acesso em: 24 maio. 2014.
FOWLER, Martin; SCOTT, Kendal. UML essencial. Porto Alegre: Bookman, 2000.
FURLAN, Jos Davi. Modelagem de objetos atravs da UML. So Paulo: Makron Books,
1998.
GUEDES, G.T. UML 2: Uma abordagem prtica. 2. ed. So Paulo: Novatec, 2011.
KIOSKEA.NET. POO O polimorfismo. 2014. Disponvel em: <http://pt.kioskea.net/
contents/416-poo-o-polimorfismo>. Acesso em: 16 jul. 2014.
MARTIN, James. Managing the data-base environment. So Paulo: Pearson Education, 1983.
MOREIRA, J. R. Anlise de programao. Disponvel em: <http://dc522.4shared.com/doc/
WJN2FOZz/preview.html>. Acesso em: 16 jul. 2014.
OLIVEIRA, Patrcia. Desenho Regrinhas de Convivncia. Blog Ricos e Desenhos. 2010.
Disponvel em: <http://www.riscosedesenhos.com.br/2010/09/17/desenhos-regrinhas-de-
convivencia/>. Acesso em: 16 jul. 2014.
PLURIVERSO. Matriz de Interaes (ou Matriz CRUD). 2014. Disponvel em: <http://
pluriverso.com.br/software/matriz-de-interac%C3%B5es-ou-matriz-crud>. Acesso em: 16
jul. 2014.
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de Janeiro:
Campus, 1994.
Anotaes
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
Anotaes
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
Anotaes
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
Anotaes
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
Anotaes
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
Anotaes
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________

Livro-Processos de Software

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Livro-Processos de Software

Transféré par

Droits d'auteur :

Formats disponibles

99576-CAPA_UNIASSELVI_978-85-68075-89-0.

pdf - PG-1 - 04:47:50 - August 22, 2014

Polyanna Pacheco Gomes Fabris

2014 by Editora e Distribuidora Educacional S.A.

Diretor editorial e de contedo: Roger Trimer

Dados Internacionais de Catalogao na Publicao (CIP)

Fabris, Polyanna Pacheco Gomes

1. Engenharia. 2. Negocio. 3. Gerenciamento. I. Perini ,

Unidade 1 Processos de negcio................................1

Unidade 2 Engenharia de software ..........................43

Seo 2 Modelos de processos de software.......................................67

Unidade 3 Engenharia de requisitos e gerenciamento

Unidade 4 Noes sobre modelagem de sistemas..143

Objetivos de aprendizagem: Nesta unidade, voc ser levado a

Seo 1: Viso geral sobre as reas de negcio

Seo 2: Noes sobre modelagem de processos

Seo 3: Introduo modelagem organizacional

sando ao crescimento organizacional. E assim como

Seo 1 Viso geral sobre as reas de negcio

1.1 O que negcio?

1.2 E processos de negcio?

Controle: responsvel pelo monitoramento e verificao do cumprimento dos

Para saber mais

Questes para reflexo

Seo 2 Noes sobre modelagem

2.1 Introduo modelagem de processos

Suporte ao design de um novo ou nova abordagem para um

2.2 O que so os modelos de processo?

2.3 Quais so os contedos de um modelo de processo?

2.4 Nveis de representao de processo

Para saber mais

2.4.1 Resumo da comparao entre diagrama, mapa e modelo

Tabela 1.1 Comparao entre nveis de representao de processos

Diagrama ou mapa de processo Modelo de processo

2.5 Componentes de processo e ferramentas

eventos e resultados, custos, valor agregado, regras de entrada, papis e organizaes,

2.6 Arquitetura de processos e arquitetura de negcio

Tabela 1.2 Arquitetura de processos e arquitetura de negcios

Arquitetura de processos Arquitetura de negcios

Contudo, podemos afirmar que essas disciplinas se complementam e visam a

2.7 Notaes de modelagem de processos

Dentre as notaes de modelagem de processos usualmente encontrada, podemos

2.7.1 BPMN (Business Process Model and Notation)

2.7.1.1 Processos de negcio privado (internos)

Figura 1.1 Exemplo de processo de negcio privado

Fonte: BPMN (2014).

2.7.1.2 Processos abstratos (pblicos)

Figura 1.2 Exemplo de processo de negcio abstrato

Fonte: BPMN (2014).

2.7.1.3 Processos de colaborao (global)

Figura 1.3 Exemplo de processo de colaborao

Fonte: BPMN (2014).

importante ressaltar que a notao BPMN tem como direcionador a criao de

apto a lidar com a complexidade intrnseca aos processos de negcio. A aborda-

Para saber mais

Aprofunde seus conhecimentos em BPMN acessando os links:

Na Tabela 1.3 a seguir, visualize os elementos da categoria dados (ELOGROUP,

Tabela 1.3 Dados

Objetos de dados Tipos de dados

Representao singular de dados

Representao de uma coleo

Os objetos de dados no tm nenhum efeito

Fonte: BPMN (2014).

Tabela 1.4 Objetos de conexo

1. Engenharia. 2. Negocio. 3. Gerenciamento. I. Perini ,