Engenharia de software I Unid IV

Prévia do material em texto

118
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
Unidade IV
7 PRÁTICAS DA ENGENHARIA DE SofTwARE
7.1 Conceitos preliminares
No capítulo 1 do livro Engenharia de Software na Prática, de Hélio Engholm Júnior, encontra-se o 
seguinte texto:
Com base na importância cada vez maior do software no dia a dia das 
empresas, devemos nos preocupar com a maneira com que ele agrega valor 
aos negócios das mesmas, aumentando a produtividade e diminuindo custos. 
Com a finalidade de atender a esses objetivos, a área de engenharia de 
software destina parte de sua atenção ao quesito qualidade na construção 
de software, utilizando a definição de modelos e processos para melhoria 
da qualidade e diminuição de custos no desenvolvimento e na manutenção 
de sistemas. Existem hoje em dia várias propostas de modelo, buscando 
melhorar o processo de desenvolvimento de software e a qualidade envolvida 
(ENGHOLM JÚNIOR, 2010, p. 44). 
Todos esses modelos se baseiam no conceito de melhores práticas do mercado acumuladas ao longo 
de dezenas de anos. O que tem sido demonstrado é que não adiantará saber o que o produto de 
software deverá fazer se não houver um ótimo time de desenvolvedores de software e a participação 
ativa do usuário. Mas, também, ter pessoas qualificadas, por si só, não resolve a complexidade inerente 
ao desenvolvimento de sistemas de informação. É preciso que essas pessoas trabalhem em time, 
usando as melhores práticas de engenharia de software. Dentre estas, encontram-se as boas práticas 
da comunicação, do planejamento de projetos, da modelagem de sistemas, das melhores soluções na 
construção e das melhores práticas na colocação do produto em produção ou para implantação.
7.2 Princípios centrais
Para tratar o tema dos princípios envolvidos com as práticas de engenharia de software torna-se 
necessário caracterizar o conceito de práticas:
•	 práticas	podem	ser	definidas	como	uma	coleção	de	conceitos,	princípios,	métodos	e	ferramentas	
de que um engenheiro de software faz uso nas suas atividades do dia a dia;
•	 outra	 definição	 pode	 ser	 que	 as	 práticas	 preenchem	ou	 determinam	um	modelo	 de	 processo	
de software que inclui as receitas técnicas e gerenciais necessárias para fazer as tarefas do 
desenvolvimento de um software.
119
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
De acordo com Pressman (2006) e Sommerville (2007), pode-se compreender a essência da prática 
das maneiras a seguir. 
•	 Entenda	 o	 problema	 (comunicação	 e	 análise):	 a	 essência	 de	 um	 software correto está no 
entendimento do problema a ser resolvido ou das necessidades do negócio ou dos usuários 
finais. De acordo com Souza, G. ([s.d.]), diversas questões devem ser consideradas no 
entendimento do problema: quem tem interesse na solução do problema, isto é, quem é 
considerado como interessado? Quais são os dados, quais são as funções, quais características 
e comportamentos são necessários para resolver o problema em análise? É possível representar 
problemas menores para facilitar a compreensão? O problema pode ser representado 
graficamente?
•	 Planeje	uma	solução	 (modelagem	e	projeto):	a	partir	das	necessidades	e	do	entendimento	
do problema, os desenvolvedores deverão transformar essas necessidades em modelos 
sistêmicos e montar um projeto de desenvolvimento que inclui todas as fases, etapas e 
atividades do ciclo de vida do software. Souza, G. ([s.d]) diz que diversas questões devem ser 
consideradas no planejamento da solução: Já viu problemas parecidos? Já resolveu algum 
problema semelhante? É possível subdividir os problemas? É possível definir um modelo que 
possa ser implementado? 
•	 Execute	o	plano	(geração	do	código):	diversas	metodologias,	técnicas	e	ferramentas	podem	ser	
usadas para que o planejamento e o desenvolvimento se tornem efetivos e para que o produto de 
software atinja seus objetivos. A execução do plano vai depender das escolhas que uma equipe ou 
a própria organização escolher para implementá-lo. O que importa nesse momento é saber qual 
é o melhor caminho a seguir, que métodos serão aplicados, as exigências legais ou dos usuários, e 
que ferramentas serão úteis durante o projeto. De acordo com Souza, G. ([s.d.]), diversas questões 
devem ser consideradas na execução do plano: a solução está de acordo com o plano? Cada 
componente da solução está correto?
•	 Examine	 o	 resultado	 quanto	 à	 precisão	 (teste	 e	 garantia	 de	 qualidade):	 diversos	modelos	
de qualidade surgiram na década de 1990 e, a partir dos preceitos da qualidade de outras 
engenharias e da qualidade total, propõem conjuntos de práticas da qualidade para o ciclo de 
vida do software. Outro fator importante são os testes para a garantia da qualidade. Diversas 
alternativas foram surgindo e, dependendo do processo de desenvolvimento e de qualidade, 
os testes podem ser realmente um fator de diferenciação no resultado das organizações 
de software. De acordo com Souza, G. ([s.d.]), diversas questões devem ser consideradas no 
exame do resultado: foi elaborada uma estratégia de teste? O software foi avaliado de acordo 
com os requisitos?
Dentre os diversos princípios centrais que os autores indicam para as práticas da engenharia de 
software, podem ser citados:
•	 um	software deve sempre fornecer valor para o cliente, o usuário final ou a área de negócio; essa 
deve ser a razão para que ele exista;
120
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
•	 todo	projeto	deve	ser	simples,	pois	a	simplicidade	facilita	o	entendimento,	o	uso	e	a	evolução	ao	
longo do tempo; pode-se propor que os desenvolvedores mantenham o produto de software o 
mais simples possível; 
•	 é	essencial	manter	uma	visão	clara	do	que	deve	ser	construído;	clareza	indica	uma	forma	fácil	de	
todos os envolvidos entenderem da mesma maneira o que deve ser feito;
•	 os	produtos	de	software têm como característica serem consumidos por todos os tipos de usuários, 
tanto	com	relação	ao	conhecimento	quanto	com	relação	à	quantidade;	daí	a	importância	de	o	
produto ser especificado, projetado e implementado sabendo-se que outras pessoas terão de 
entender o que foi feito, para poder dar continuidade ao longo da evolução deste; 
•	 todo	gestor	de	projetos	de	software tem de planejar com antecedência as possibilidade de reusar 
códigos ou soluções já existentes, já que o reúso permite a redução de custo do projeto e a 
qualidade;
•	 pense	e	estude	os	problemas	e	as	possíveis	soluções	completamente,	antes	de	iniciar	o	projeto;	
as práticas mostram que raciocinar de forma clara antes da ação quase sempre produz melhores 
resultados.
 Saiba mais
No portal da Softex é possível encontrar a descrição do modelo MPS, 
bem como sua estrutura e aplicabilidade.
Disponível em: <http://www.softex.br/mpsbr/>. Acesso em: 7 mar. 2014.
7.3 Práticas de comunicação
A natureza interdisciplinar da comunicação atesta os empréstimos tomados das ciências sociais, 
das humanidades e das ciências físicas, tanto de conceitos e teorias como de metodologias. Não existe 
uma teoria da comunicação humana, mas a maioria das teorias propostas inclui substância dos campos 
da psicologia, sociologia, antropologia, linguística e cibernética. O fenômeno da comunicação pode ser 
examinado em um sentido muito amplo, que trata da matéria como qualquer forma de interação que 
possa ocorrer desde o mundo inorgânico até o mundo superorgânico ou cultural, passando pelas diversas 
formas de interestimulação de seres vivos uns com os outros e com o ambientefísico. Ele é fundamental 
no desenvolvimento da personalidade humana, na emergência da vida grupal e no surgimento e na 
elaboração da cultura. Embora não haja consenso entre os cientistas sociais a respeito de como definir 
comunicação, eles estão de acordo em considerá-la como forma de interação e em destacar-lhe pelo 
menos os seguintes elementos: o emissor, a mensagem, o receptor, o contexto e o efeito (MENDES; 
TREVISAN; NOGUEIRA, 1987).
121
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Sobre a comunicação, outros conceitos a associam como forma que procura a fluidez de mensagens 
entre os membros de uma organização, assim como entre esta e seu meio, afetando opiniões, atitudes 
e condutas, tanto para os receptores internos quanto para os externos, a fim de poder alcançar, com 
a maior eficácia, seus objetivos, baseando-se na investigação para conseguir as oportunidades nas 
diferentes áreas, em razão do conhecimento das problemáticas e de distintas necessidades. Já num 
nível gerencial, a comunicação determina a eficiência tanto para a solução de problemas quanto para o 
fortalecimento das relações entre aqueles que a conformam, estruturando, dessa forma, o planejamento 
e o controle.
As práticas da comunicação na engenharia de software já são evidentes durante a coleta das 
necessidades dos stakeholders. Essas necessidades são denominadas de requisitos, e todo o levantamento 
destes é feito por meio de uma atividade de comunicação chamada de levantamento de requisitos.
De acordo com Pressmann (2006) e Sommerville (2007), a comunicação para o entendimento de um 
problema, normalmente, é difícil. A comunicação é considerada uma das atividades mais desafiadoras 
encontradas por um engenheiro de software.
Com relação aos princípios da comunicação, os autores definem dez, que podem ser descritos 
da seguinte forma: escute; prepare-se antes de se comunicar; alguém deve facilitar a atividade; 
comunicação face a face é melhor; faça anotações e documente as decisões; busque colaboração; 
conserve-se focado; se algo não estiver claro, desenhe uma figura; quando concordar com algo ou não, 
prossiga; e negociação não é um concurso ou jogo.
•	 primeiro	 princípio	 –	 escute:	 concentre-se	 nas	 respostas	 do	 interlocutor,	 peça	 esclarecimentos	
quando algo estiver obscuro, evitando fazer interrupções constantes, sacudir a cabeça, virar os 
olhos e influenciar a resposta do interlocutor; 
•	 segundo	princípio	–	prepare-se	antes	de	se	comunicar:	gaste	tempo	para	entender	o	problema	e,	
se necessário, pesquise para entender o jargão do negócio; 
•	 terceiro	princípio	–	alguém	deve	facilitar	a	atividade:	toda	reunião	deve	ter	um	facilitador	para	
conduzir a conversa, a fim de que seja sempre produtiva, bem como para que possa mediar 
possíveis conflitos e garantir que os outros princípios sejam seguidos; 
•	 quarto	princípio	–	comunicação	face	a	face:	considerada	a	melhor	forma	de	comunicação,	mas	
o uso de outra forma é sempre bem-vinda; por exemplo, o uso de documentos ou desenhos, 
gráficos ou diagramas também é aceito como forma efetiva de comunicação; 
•	 quinto	princípio	–	faça	anotações	e	documente	as	decisões:	alguém	que	participe	da	comunicação	
deve anotar todos os pontos e decisões importantes; 
•	 sexto	princípio	–	busque	colaboração:	 é	 importante	que	os	outros	membros	da	equipe	 façam	
colaborações, mesmo que sejam pequenas, pois estas aumentam a confiança entre os membros; 
122
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
•	 sétimo	princípio	–	 conserve-se	 focado:	o	 facilitador	da	 comunicação	deve	manter	 a	 conversa	
modular, abandonando um tópico apenas depois que tiver sido resolvido; 
•	 oitavo	princípio	–	caso	algo	não	esteja	claro,	desenhe	uma	figura:	quando	a	comunicação	por	
palavras não conseguir esclarecer, normalmente, um desenho o fará; 
•	 nono	princípio	–	quando	concordar	com	algo,	ou	não,	prossiga:	fazer	isso,	às	vezes,	é	a	melhor	
forma de conseguir agilidade na comunicação; 
•	 décimo	princípio	–	negociação	não	é	um	concurso	ou	um	jogo:	em	uma	negociação,	as	coisas	
funcionam melhor quando ambas as partes ganham; muitas vezes, os clientes e os desenvolvedores 
precisam negociar, o que exige compromisso de todos.
Com	relação	à	comunicação	nas	organizações	(um	dos	focos	dos	sistemas	de	software), Kunsck 
(2003) afirma que a comunicação-ação é o efeito ou o meio de comunicar-se; ato ou efeito de 
emitir, transmitir e receber mensagens por meio de métodos e/ou processos, quer por meio da 
linguagem falada ou escrita, quer por outros sinais ou aparelhamento técnico especializado, sonoro 
e/ou visual. 
Já para Silva, Nascimento e Nogueira (2007), é particularmente importante na função de direção, 
pois representa o intercâmbio de pensamento e de informações, para proporcionar compreensão mútua 
e confiança, além de boas relações humanas, que devem ser transmitidas e compreendidas dentro da 
empresa, envolvendo, portanto, troca de ideias, fatos, opiniões ou emoções entre duas ou mais pessoas. 
É uma ponte de significados entre elas.
Ainda para Kunsck (2003), a comunicação empresarial/organizacional é a soma de todas as atividades 
de comunicação da empresa; é uma atividade multidisciplinar que envolve métodos e técnicas de 
relações públicas, jornalismo, assessoria de imprensa, lobby, propaganda, promoções, endomarketing e 
marketing.	O	público	a	que	se	destina	pode	ser	dividido	em	externo	–	sociedade	de	modo	geral;	e	interno	
–	colaboradores	da	empresa,	funcionários,	fornecedores	e	parceiros.	
 Saiba mais
Para saber mais sobre os conceitos envolvidos na comunicação dentro 
das empresas, acesse o artigo:
SILVA, S. S. F.; NASCIMENTO, T. C. C.; NOGUEIRA, V. B. Diagnóstico 
da comunicação interna e desenvolvimento de um plano estratégico de 
comunicação empresarial. Qualitas, Monteiro, v. 6, n. 1, 2007. Disponível 
em: <http://revista.uepb.edu.br/index.php/qualitas/article/viewFile/95/76>. 
Acesso em: 2 abr. 2014. 
123
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
A próxima figura mostra um gráfico em que se apresentam resultados de pesquisas mostrando a 
comunicação efetiva versus as formas de comunicação.
Interação 
face a face
Interação 
somente de voz
Interação escrita
Formas de comunicação
Multimídia não 
interativa
Escrita não 
interativa
Figura 36	–	Comunicação	efetiva	de	acordo	com	as	formas	de	comunicação
Uma análise da figura mostra que a mais efetiva forma de comunicação entre as pessoas, apontada 
pelas pesquisas na área de desenvolvimento de sistemas, é a interação face a face, e que quanto mais as 
formas são escritas, pior fica a comunicação efetiva da pessoas. Esse é um dos grandes argumentos dos 
métodos ágeis em prol de menos documentos e mais interação dos times de desenvolvimento. Todavia, 
como já foi mostrado, os extremos não são bons. 
Em muitos casos, não é possível ficar sem as descrições ou os documentos formais exigidos tanto 
pelos clientes quanto pelas legislação em vigor. Revisando-se os dez princípios da comunicação, vê-se, 
no quinto princípio, a necessidade de anotações nas comunicações, e, no oitavo princípio, o uso de 
desenhos ou diagramas para garantir o entendimento da comunicação entre seus participantes.
Dentre as técnicas de comunicação na engenharia de software, temos as reuniões denominadas 
de walkthrough e JAD, que são usadas para a obtenção das informações necessárias e do 
entendimento de um problema, ou para a revisão de descrições ou documentos construídosno 
processo de software. 
7.3.1 A técnica de reunião walkthrough
Essa técnica de reunião pode ser aplicada em diversos momentos do desenvolvimento de software e 
a diversas atividades do processo, tanto no levantamento de informações junto aos clientes e usuários 
quanto nas revisões técnicas de produtos de software e, também, na aprovação do cliente aos produtos 
construídos etc.
A técnica walkthrough pode ser considerada como mais informal do que um Joint Application 
Development (JAD) ou uma reunião de inspeção. Essa técnica foi detalhada na norma IEEE 1028 (2008).
124
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
Em geral, a norma apresenta uma explicação passo a passo e tem dois grandes objetivos: obter 
feedback sobre a qualidade técnica ou o conteúdo de um documento e/ou familiarizar o público presente 
com o conteúdo. Um passo a passo é normalmente organizado e dirigido pelo autor do documento 
técnico. Qualquer combinação de pessoal interessado ou tecnicamente qualificado (de dentro ou de fora 
do projeto) pode ser incluída conforme parecer adequado.
A IEEE 1028 (2008) recomenda três papéis especializados em um passo a passo:
•	 o	 autor,	 que	 apresenta	 o	 produto	 de	 software passo a passo na reunião walkthrough e, 
provavelmente, seja responsável por completar a maioria dos itens de ação pós-reunião;
•	 o	líder	do	walkthrough, que conduz a reunião passo a passo, lida com tarefas administrativas e 
garante a realização ordeira dessa reunião (muitas vezes, é o próprio autor que faz esse papel);
•	 o	escriba,	que	observa	todas	as	anomalias	(defeitos	potenciais),	as	decisões	e	todos	os	itens	de	
ação identificados durante as reuniões de passo a passo.
Já Yourdon e Argila (1998) afirma que walkthrough é uma revisão, por pares ou em grupo, de 
qualquer produto técnico em um processo de desenvolvimento de software. O autor argumenta que essa 
revisão pode incluir tanto outros engenheiros de software quanto usuários, programadores, analistas, 
projetistas e operadores que possam estar envolvidos nos vários aspectos de um software.
A técnica de comunicação ou reunião walkthrough é prática, simples e bem-aceita para a melhoria da 
qualidade do software. Oslon (1999) argumenta que essa técnica é basicamente informal, mas Yourdon 
e Argila (1998) defende que as reuniões podem ser levadas a termo em qualquer nível de formalidade. 
A ideia da aplicação de walkthroughs em diversos níveis de formalidade apresenta aspectos temporais 
relativos a cada nível. 
 observação
De forma geral, os walkthroughs tendem a ocorrer nos pontos de 
controle definidos pelo processo de desenvolvimento de software que está 
sendo aplicado ao projeto, conforme relata o autor Yourdon e Argila (1998). 
Cabe ressaltar que os walkthroughs não são as únicas formas de 
detecção de problemas no processo de software, e sim complementos a 
revisões individuais, inspeções e outras técnicas, inclusive, as efetuadas via 
ferramentas automatizadas.
7.3.2 A técnica de reunião Joint Application Development/Design (JAD)
Tradicionalmente, a técnica de reunião JAD tem sido utilizada por profissionais de desenvolvimento 
de sistemas e usuários para a descoberta e a definição de requisitos de sistemas. Tem sido adotada 
125
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
também por todos os que desejam trabalhar em projetos, sejam da área de informática ou não, ou que 
queiram tomar decisões que afetem múltiplas áreas da organização, buscando tratar os usuários-chave 
como coautores do trabalho, transformando-os em clientes integrados ao projeto.
De acordo com Duggan e Thachenkary (2004):
A técnica de reunião JAD é um processo de grupo onde os participantes 
interagem livremente, o que substitui a técnica de empregar entrevistas 
com usuários para determinar requisitos de um sistema. JAD é considerada 
best practice para aumentar o comprometimento como usuário e um 
investimento que reduz riscos associados ao desenvolvimento de software. 
Segundo os autores, participam das reuniões: um facilitador; usuários; 
gerentes e desenvolvedores; um secretário; e um observador. Uma sessão 
JAD tem cinco fases: definição do tema; pesquisa; preparação; reunião; 
elaboração do documento final (DUGGAN; THACHENKARY, 2004). 
Práticas de uma reunião JAD que leva aos objetivos traçados (WOOD; SILVER, 1995):
•	 todos	 sabem	 para	 que	 estão	 ali;	 as	 reuniões	 são	 marcadas	 com	 antecedência,	 e	 todos	 são	
comunicados;
•	 há	uma	agenda	objetiva,	que	é	montada	nas	reuniões	de	preparo	do	JAD;
•	 as	pessoas	certas	estão	presentes;	a	ausência	de	pessoas-chave	pode	comprometer	o	atendimento	
dos objetivos da reunião;
•	 as	pessoas	presentes	não	têm	compromissos	paralelos;	as	reuniões	exigem	total	dedicação	dos	
participantes, e as entradas e saídas não são permitidas, nem atendimentos de problemas fora da 
reunião;
•	 as	 pessoas	presentes	 estão	 envolvidas	 com	os	 assuntos	que	 são	objeto	da	 reunião;	 todos	 são	
interessados e participam a fim de resolver algum tipo de problema ou propor soluções para ele; 
•	 há	um	responsável	pela	condução	da	reunião	(líder);	este	deve	ser	experiente	em	conduzir	reuniões	
objetivas;
•	 há	horário	preestabelecido	para	início	e	término;	os	horários	são	fundamentais	para	o	sucesso	da	
reunião;
•	 as	sessões	da	reunião	duram	de	90	a	120	minutos;	podem	existir	JADs	que	duram	mais	de	um	dia;	
isso vai depender do assunto, do número de participantes e da pauta predefinida;
•	 há	intervalos	para	café	de	5	a	15	minutos;	são	importantes	paradas	programadas,	para	que	as	
pessoas possam decidir assuntos particulares e para outras necessidades pessoais;
126
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
•	 os	 intervalos	 para	 refeições	 são	 de	 90	 a	 150	minutos;	 as	 refeições	 normalmente	 ocorrem	no	
mesmo local da reunião, para evitar dispersões nos outros períodos.
Diversas outras formalidades devem ocorrer a fim de que a reunião seja efetiva e de que se proporcione 
um ambiente ideal para a integração:
•	 sala	 de	 reuniões:	 a	 preocupação	 com	 a	 escolha	 do	 local	 deve	 ser	 um	 item	 de	 planejamento	
importante; deve ser escolhido um local “isento de influências”;
•	 quadro	branco:	utilizado	para	rascunhar	modelos,	sequência	de	atividades,	segmentação	de	papéis	
e quaisquer outros recursos que facilitem a compreensão do tema exposto;
•	 flip-chart: utilizado para oficializar (formalizar, publicar) as principais decisões do grupo; deve ser 
lembrado que as anotações de cada um são de uso particular;
•	 como	são	várias	cabeças	interpretando	uma	situação	fictícia,	cada	um	tem	uma	forma	de	vê-la;	
visualizá-la em um único formato auxilia no entendimento (uso de padrões de documentação);
•	 paredes:	tudo	o	que	for	publicável	(charts) deve ficar afixado na sala de reuniões durante todo o 
tempo que durar o levantamento;
•	 o	 pessoal	 de	 limpeza	 deve	 ser	 avisado	 de	 que	 esse	material	 deve	 permanecer	 afixado	 de	
um dia para o outro (se a duração da reunião ultrapassar um dia); esse material é fator 
extremamente produtivo, principalmente, quando se necessita resgatar algum ponto já 
discutido e acordado; a estratégia é escrever no flip-chart, destacá-lo e afixá-lo em seguida; 
deve-se ter cuidado com o excesso de poluição visual, pois os participantes não conseguem 
se concentrar nas discussões; 
•	 mesa	grande	ou	montagem	em	U:	o	objetivo	é	que	 todos	estejam	o	mais	próximos	e	 visíveis	
possível;	vale	 lembrar	que,	antes	de	tudo,	umareunião	é	um	encontro	de	pessoas	–	e	pessoas	
próximas fomentam o comprometimento;
•	 ambiente	confortável:	boa	 iluminação,	ventilação	adequada	e	baixo	nível	de	 ruído	são	pontos	
importantes para aumentar a produtividade dos trabalhos.
A	convocação	dos	participantes	deve	ser	antecipada.	Cada	um	deve	receber	a	convocação	junto	à	
agenda de reunião da qual está sendo solicitado a participar. A agenda deve ser produzida com base no 
enfoque	do	levantamento	–	overview, macro, detalhe etc.; deve também considerar todos os tópicos 
que	serão	abordados	durante	as	sessões	da	reunião	–	passos,	necessidades,	modelos,	problemas	etc.
Cada sessão deve ter horário de início, duração, intervalos e fim preestabelecidos. Na convocação 
com antecedência devem constar:
•	 os	objetivos	da	reunião;
127
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
•	 as	etapas	intermediárias	para	atingir	os	objetivos;
•	 indicação	de	como	os	participantes	podem	esclarecer	possíveis	dúvidas.
A reunião, normalmente, é estruturada em três partes, conforme segue: 
•	 Abertura:	 é	 quando	 são	 feitas	 as	 apresentações	 dos	 participantes.	 Essa	 poderá	 ser	 a	 primeira	
oportunidade para que os usuários e analistas venham a se encontrar. Caso seja a primeira 
reunião do grupo, esse momento é oportuno para apresentar os participantes e a metodologia da 
reunião, assim como definir a conduta do grupo. Depois das apresentações, devem-se estabelecer 
os horários de desenvolvimento da reunião, e a agenda deve ser apresentada. 
•	 Desenvolvimento:	nessa	parte,	ocorre	o	levantamento	das	informações	propriamente	dito.	Cada	
tópico da agenda deve ser detalhado, sempre um por vez. Não se parte para o próximo tópico 
sem se ter esclarecido tudo a respeito do anterior. Aqui estão incluídas, também, as aprovações 
necessárias. 
•	 Fechamento:	não	é	o	“fim	da	reunião;	deve-se	começar	essa	parte	com	tempo	suficiente	para	se	
atingir o horário de fim preestabelecido na agenda. É quando são feitos os resumos do que se 
discutiu e se aprovou. Se algo tiver ficado pendente, é nesse ponto que deverá ser esclarecido. 
Nesse momento também se distribuem tarefas para as próximas reuniões e se estabelecem suas 
futuras datas (se for o caso).
 Saiba mais
Documento sobre a técnica de reunião JAD, de Mauro Vianna, com 
diversos conceitos mais abrangentes sobre a aplicação da reunião: 
VIANNA, M. Reuniões de levantamento: como torná-las produtivas? 
Linha de Código, Rio de Janeiro, [s.d.]. Disponível em: <http://www.
linhadecodigo.com.br/artigo/159/reunioes-de-levantamento-como-torna-
las-produtivas.aspx>. Acesso em: 2 abr. 2014. 
7.4 Práticas de planejamento
A atividade de planejamento é um esforço sistemático e formal que visa estabelecer direção e 
aumentar a probabilidade da ocorrência dos resultados desejados; esforço, porque implica razoável 
trabalho; sistemático, porque existe uma metodologia universal; formal, porque pressupõe que 
registremos, rigorosamente, o que deverá ser realizado, de forma que haja uma referência para 
verificação posterior, bem como um oportuno processo de comunicação. Finalmente, o termo 
probabilidade pretende ressaltar que o empreendimento não tem sucesso garantido. De fato, o risco 
de fracasso é inerente, porque incertezas existem (GASNIER, 2000).
128
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
Esta figura apresenta uma visão de esforços e sinergia em projetos de qualquer natureza.
Esforços dispersos Sinergia de esforços
Figura 37	–	Contraste	entre	esforços	dispersos	e	sinergia	de	esforços	
Como mostra a figura, o sucesso de um empreendimento ou projeto estará diretamente 
vinculado aos esforços que serão despendidos, e quanto mais sinergia, melhores serão os resultados 
obtidos. 
Quando se trata de práticas de planejamento, invariavelmente, trabalha-se com o conceito de 
projeto, independentemente da área do conhecimento em que este se encontra. Mas o que é um 
projeto? 
Essa pergunta será respondida a partir dos conceitos e definições apresentados no Guia PMBOK 
(Project Management Body of Knowledge) ou conjunto de conhecimentos em gerenciamento de 
projetos, do Project Management Institute PMI (2008):
Um projeto é um esforço temporário empreendido para criar um produto, 
serviço ou resultado exclusivo. A sua natureza temporária indica um 
início é um término definidos. O término [será] alcançado quando os 
objetivos tiverem sido atingidos ou quando se concluir que esses objetivos 
não serão ou não poderão ser atingidos e o projeto for encerrado, ou 
quando o mesmo não for mais necessário. Temporário não significa 
necessariamente de curta duração. Além disso, o termo temporário 
não se aplica ao produto, serviço ou resultado criado pelo projeto; a 
maioria dos projetos é realizada para criar um resultado duradouro. Por 
exemplo, um projeto para a construção de um monumento nacional 
criará um resultado que deve durar séculos. Os projetos também podem 
ter impactos sociais, econômicos e ambientais com duração mais longa 
que a dos próprios projetos. Um projeto pode criar: um produto que 
pode ser um item final ou um item componente de outro item; uma 
capacidade de realizar um serviço, como funções de negócio que dão 
suporte	à	produção	ou	à	distribuição;	ou	um	resultado,	como	um	produto	
129
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
ou um documento (por exemplo, um projeto de pesquisa desenvolve um 
conhecimento que pode ser usado para determinar se uma tendência 
está presente ou se um novo processo beneficiará a sociedade) (PMBOK, 
2008, p. 10).
Ainda de acordo com o PMBOK (2008), cada projeto cria um produto, serviço ou resultado exclusivo. 
Embora elementos repetitivos possam estar presentes em algumas entregas do projeto, essa repetição 
não muda a singularidade fundamental do trabalho do projeto. Por exemplo, prédios de escritórios são 
construídos	com	materiais	idênticos	ou	similares,	ou	pela	mesma	equipe,	mas	cada	um	é	exclusivo	–	
com diferentes projetos, circunstâncias, fornecedores etc.
Quando se trata de planejamento, imagina-se viajar no tempo, rumo ao futuro. Trata-se de um 
exercício de criatividade, em que se procura antecipar o que se estará fazendo e o que poderá acontecer. 
Como diversos outros, esse hábito se aperfeiçoa com a prática. Na perspectiva tradicional, o planejamento 
é visto como algo estanque ou limitado, com começo, meio e fim, como mostra a figura a seguir.
Início FimPlanejamento Execução Verificação
Figura 38	–	Sequência	tradicional	de	ciclo	de	vida	do	projeto	
Em contraste, na administração moderna, entende-se o planejamento como um processo que deve 
melhorar continuamente, inclusive, por meio do aprendizado, como mostra a próxima figura.
Processo de 
iniciação
Processos de 
monitoramento e controle
Processo de 
encerramento
Processos de 
planejamento
Processos de 
execução
Figura 39	–	Sequência	tradicional	de	ciclo	de	vida	do	projeto	
Aprofundando-se no guia PMBOK do PMI (2008), esse modelo considera que o gerenciamento de 
projetos é realizado pela execução de processos que podem ser agrupados em: iniciação; planejamento; 
execução; monitoramento e controle; e encerramento. Esses processos são executados de forma inter-
relacionada, e a gestão do projeto abrange todos os outros processos, inclusive, o de planejamento, que 
é apresentado no guia como processos de monitoramento e controle.
130
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
Depois de submetida e aprovada a proposta do projeto, inicia-se o processo de planejamento, que é 
fundamental para o sucesso do projeto, na medida em que previne a perda de tempo e recursos.
De acordo com o guia PMBOK (2008), o planejamento envolve um grupo de processos realizados 
para estabelecer o escopo total do esforço, definir e refinar os objetivos e desenvolver o curso de ação 
necessário para alcançar esses objetivos. O processo de planejamento abrange o plano de gerenciamento, 
ou plano do projeto, bem como os documentos que serão usados para executá-lo.
A natureza multidimensional do gerenciamento de projetos cria realimentações periódicas de 
feedback para análise adicional. À medida que mais informações ou características do projeto são 
coletadas e entendidas, pode ser necessário um planejamento adicional. Mudanças significativas 
ocorridas ao longo do ciclo de vida do projeto acionam uma necessidade de revisitar um ou mais dos 
processos de planejamento e, possivelmente, alguns dos processos de iniciação do projeto.
De acordo com o PMBOK (2008):
O planejamento organizacional impacta o projeto através de uma priorização 
de projetos baseada em risco, financiamento e no plano estratégico da 
organização. O planejamento organizacional pode orientar o financiamento 
e dar suporte aos projetos componentes com base nas categorias de risco, 
linhas específicas de negócios ou tipos gerais de projetos, como infraestrutura 
e melhoria de processos internos (PMBOK, 2008, p. 12).
No caso do projeto, o cenário favorável para um gerente de projetos pode ser descrito em termos 
de cliente satisfeito com o resultado do projeto, prazo cumprido e teto orçamentário não ultrapassado. 
Numa empresa estruturada por projetos (por exemplo, uma instituição de pesquisa ou uma firma de 
consultoria), pode-se falar de planejamento em distintos níveis: planejamento estratégico da própria 
empresa; planejamento agregado dos projetos; planejamento das áreas de apoio aos projetos; e o 
planejamento de cada projeto em si.
A seguir, serão detalhadas diversas práticas envolvidas no planejamento de projetos, que serão 
baseadas no Guia PMBOK de 2008 e no livro Gerenciamento de Projetos, de 2000, (PMBOK, 2008; 
GASNIER, 2000).
Para um planejamento eficaz de projetos, conforme o guia PMBOK e conforme intensamente utilizado 
em projetos de software, propõem-se algumas práticas clássicas que podem ser organizadas da seguinte 
forma: plano de projetos, estrutura analítica do projeto, recursos, cronogramas e gerenciamento de 
riscos.
7.4.1 Plano de projetos
O plano de projetos reúne toda a documentação gerada durante o ciclo de vida do projeto, 
de forma que as ideias, os cálculos, as análises, as avaliações, as conclusões e os compromissos 
sejam registrados e comunicados aos envolvidos, assegurando disciplina e sistematização dos 
131
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
processos. Todos os processos geram documentos que são arquivados na respectiva pasta, manual 
ou automatizada, mas é no processo de planejamento que o plano começa a ser efetivamente 
detalhado.
De acordo com os guias práticos em gerenciamento de projetos (PMBOK, 2008; GASNIER, 2000), 
um plano de projeto deverá incluir itens que deixem claros os objetivos e as responsabilidades 
envolvidas no projeto, que podem ser agrupados da seguinte forma: objetivos do projeto; premissas, 
obstáculos, estratégias, análise de viabilidade; escopo do projeto; recursos envolvidos; responsabilidades; 
cronogramas; gerenciamento de riscos; orçamento; prontuário do projeto; e outros documentos 
gerenciais envolvidos.
7.4.2 Estrutura Analítica do Projeto (EAP) ou Work Breakdown Structure (WBS)
A EAP define o escopo do projeto, relacionando hierarquicamente o conjunto de atividades necessárias 
e suficientes para que seus objetivos sejam atingidos.
De acordo com o guia PMBOK (2008), para se criar a estrutura analítica do projeto (EAP), torna-se 
necessário realizar as seguintes atividades ou passos: desenhar a estrutura analítica; criar um dicionário 
da EAP; criar uma linha de base do escopo (baseline); e atualizar os documentos do projeto.
Para Gasnier (2000), a EAP é uma aplicação prática do princípio analítico de Descartes: decomponha 
um problema complexo em pequenos problemas mais simples, fáceis de serem resolvidos; então, 
administre	os	pequenos	problemas	progressivamente	em	direção	à	solução	do	todo;	finalmente,	sintetize	
(recomponha) o conjunto com uma integração lógica.
Servindo ao propósito de comunicar tudo o que deve ser realizado desde o início até a conclusão 
do projeto, a EAP pode ser representada de forma esquemática ou por meio de uma lista de atividades 
indentadas,	 similar	 à	 estrutura	 de	 diretórios	 de	 arquivos	 utilizada	 em	 computadores	 e	 sistemas	
operacionais.
A elaboração de uma EAP é feita pela decomposição sucessiva do projeto em:
•	 nível	0:	nível	geral	do	projeto;
•	 nível	1:	uma	série	de	produtos	decompostos	do	nível	0;
•	 nível	2:	uma	série	de	módulos	decompostos	dos	produtos	do	nível	1;
•	 nível	3:	uma	série	de	componentes	decompostos	do	nível	2;
•	 nível	4:	discriminam-se	as	atividades	necessárias	à	realização	de	cada	um	dos	componentes	do	
nível 3.
Cada uma dessas atividades, perfeitamente definidas, constituirá um pacote de serviços, no original, 
work control package, individualmente controlável. 
132
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
O	método	assemelha-se	à	conhecida	técnica	de	supor	o	problema	resolvido,	ou	seja,	imagina-se	o	
projeto completado e vai-se destrinchando nível por nível.
A figura apresenta um exemplo de EAP. O modelo representa a visão da implantação de uma escola, 
com somente algumas opções preenchidas.
Quadro 5 – Exemplo de uma EAP em formato de tabela
Nível 0 Nível 1 Nível 2 Nível 3 Nível 4
Implantação da 
escola
Terreno
Edifício principal
Estrutura
Sistemas
Energia elétrica
Hidráulica
Iluminação
Som
Climatização
Projetos
Compra
Instalação
Inspeção/testes
Equipamentos
Auditório
Programa acadêmico
Operação e 
manutenção
Administração do 
projeto
A EAP é basicamente um instrumento de comunicação entre os personagens envolvidos no 
projeto (gerente do projeto e seu staff, gerentes funcionais, supervisores, direção da empresa, clientes, 
subcontratados etc.). É com base nesse instrumento que poderão ser estabelecidas as atribuições de 
tarefas e responsabilidades, a identificação de interfaces e eventos (eventos-chave), a programação e 
o controle do projeto, a programação e o controle dos recursos e o fluxo de informações que pode ser 
utilizado como instrumento de marketing pelo gerente do projeto junto ao cliente.
A alteração da EAP, uma vez necessária, deverá ser feita com os mesmos cuidados da versão original 
(inclusive	no	que	se	refere	à	divulgação	geral).
7.4.3 Recursos
Para o planejamento de projetos, denomina-se recurso qualquer variável capaz de definir aquilo 
que será necessariamente requerido para a execução de uma atividade que possa, de alguma forma, 
restringir o progresso do projeto.
Alguns tipos de recursos são: pessoas, equipamentos, materiais, capital, instalações etc. Todavia, 
não necessariamente todos os recursos devem ser registrados nos documentos ou softwares de 
agendamento, mas apenas aqueles que preenchem determinados requisitos, como qualquer recurso 
133
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
abio
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
que possa restringir, impedir ou atrasar o progresso de uma tarefa e qualquer recurso que tenha um 
custo	associado	à	sua	utilização	ou	ao	consumo.
Gasnier (2000) propõe um processo de planejamento de recursos envolvendo a identificação dos 
recursos e de suas respectivas quantidades, por meio de:
•	 levantamento	das	necessidades:	cada	atividade	deve	ser	avaliada	quanto	à	sua	identificação,	no	
que se refere aos recursos necessários e suficientes, quantificando-se o esforço requerido em 
dedicação para executá-la; 
•	 julgamento	de	especialistas:	pessoas	com	experiências	anteriores	podem	contribuir	para	o	projeto,	
procurando validar e ajustar as necessidades apuradas;
•	 identificação	de	alternativas:	por	meio	de	processos	criativos,	exploramos	diferentes	possibilidades	
de designação dos recursos e de regimes de trabalho;
•	 tomada	de	decisão:	escolha	da	melhor	alternativa	no	que	se	refere	à	sua	composição	nos	requisitos	
de qualidade, prazo e custo, objetivando o sucesso do projeto.
7.4.4 Responsabilidades
A atribuição de responsabilidades é outra ferramenta importante que visa formalizar quem (pessoa ou 
departamento) será responsável por quais etapas ou atividades do projeto. A distribuição dos trabalhos é 
um processo de negociação pelo qual o gerente do projeto obtém o comprometimento das pessoas para 
a realização das atividades do projeto. As ferramentas de automação de agendamento de programação 
permitem registrar as responsabilidades nas atividades do projeto. Normalmente, são determinadas nas 
reuniões de kick-off do projeto, e as assinaturas são tomadas nas atas da reunião.
De acordo com Gasnier (2000), o organograma linear é uma das maneiras de se organizar e 
documentar as responsabilidades de cada pessoa envolvida em relação a cada processo de um ou mais 
projetos.
O quadro a seguir apresenta um exemplo de organograma linear de responsabilidades:
Quadro 6 – Exemplo de organograma linear
Comitê Presidente Marketing Operações
Relações com acionistas e conselho Suporte Principal
Lançamentos de novos produtos Aprova Notificado Principal Suporte
Controlar orçamentos Aprova Aprova Suporte
Programa de treinamento Aprova Notificado Notificado Principal
.......................................... ................... ................ ................. .............
Fonte: Adaptado de Gasnier (2000). 
134
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
7.4.5 Cronogramas
A prática mais utilizada para se desenhar e manter cronogramas de projeto é o cronograma de 
barras ou Diagrama de Gantt. Esse gráfico apresenta as atividades do projeto na forma esquematizada 
de barras horizontais, cujos comprimentos são proporcionais aos respectivos tempos de execução, em 
folhas nas quais o cabeçalho é uma linha de tempo. Assim, é possível comunicar o plano de ação e o 
progresso de forma intuitiva, bem como identificar problemas, riscos e oportunidades rapidamente.
A próxima figura apresenta um exemplo do uso do Diagrama de Gantt desenvolvido na ferramenta 
Project da Microsoft.
Id Atividade Duração Início
999 Tri 3 1999 Tri 4 !99 Tri 1
Maio Jun. Jul. Ago. Set. Out. Nov. Dez. Jan.
0 Projeto novo 200 dias 24/05/1999
1 Fase 1 40 dias 24/05/1999
2 Levantamento do terreno 10 dias 24/05/1999
3 Terraplanagem 15 dias 07/06/1999
4 Fundações 3 sems 28/06/1999
5 Fase 2 165 dias 22/07/1999
6 Construção 165 dias 22/07/1999
7 Alvenaria 90 dias 22/07/1999
8 Telhado 3 sems 25/11/1999
9 Acabamentos 75 dias 25/11/1999
10 Instalações hidráulicas 30 dias 25/11/1999
11 Instalações elétricas 20 dias 25/11/1999
12 Pisos 20 dias 06/01/2000
Marcos
Dependência
Figura 40	–	Exemplo	de	um	gráfico	de	Gantt
No Diagrama de Gantt, as setas indicam as dependências entre as atividades, isto é, a obrigatoriedade 
de uma atividade sucessora se iniciar após a conclusão de uma atividade predecessora.
Marcos são eventos com duração nula, servindo como referência, meta ou pontos de controle 
(checkpoints) com relação ao progresso do projeto.
7.4.6 Gerenciamento de riscos
Risco é o efeito acumulado das chances de ocorrências incertas que vão afetar negativamente os 
objetivos do projeto; está relacionado com o grau de exposição do projeto a eventos negativos e suas 
prováveis consequências, sempre se tratando de uma ocorrência futura.
A incerteza representa uma oportunidade de ganhar ou perder. Assim, é fundamental que os gerentes 
de projetos e seus patrocinadores compreendam que projetos são exercícios de riscos.
135
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
De acordo com Gasnier (2000), outro aspecto interessante de se ressaltar é que o risco depende do 
prazo de que se dispõe para lidar com a sua causa. O autor ressalva que a avaliação dos riscos pode 
ser realizada na transição de cada etapa do projeto, mas, principalmente, deve ser observada logo ao 
final do processo de planejamento, antes do início efetivo da execução, pois, nessa ocasião, já se tem 
quantidade de informações suficiente, e a maior parte dos recursos ainda não foi comprometida.
Existem diversas técnicas ou práticas para a identificação dos riscos de um projeto, dentre as quais 
se destacam:
•	 lições	aprendidas	de	projetos	anteriores;
•	 entrevistas	para	capitalizar	o	conhecimento	das	pessoas	na	identificação	dos	riscos;
•	 fluxogramas	 (ilustrações,	 cronogramas,	 redes	 de	 atividades,	 árvores	 de	 decisão,	 diagramas	 de	
causa e efeito), que facilitam a compreensão e a participação das pessoas;
•	 checklists montados a partir das lições aprendidas de projetos anteriores que funcionam como 
instrumentos para prevenir a repetição das causas dos riscos identificadas;
•	 aplicação	da	 análise	de	modos	 e	 falhas	 e	 efeitos	 (FMEA),	 que	podem	contribuir	muito	para	o	
processo de gerenciamento de riscos, desde a identificação do evento;
•	 uso	 da	 técnica	 de	brainstorming, que é eficaz, principalmente, quando é necessário garimpar 
riscos desconhecidos, consistindo em reunir a equipe do projeto e desenvolver um brainstorming 
com o tema.
Após a identificação dos riscos do projeto, estes precisam ser quantificados, visando a compreender, 
com mais detalhes, suas implicações e, a partir daí, estar mais bem-preparado para decidir como tratar 
esses riscos. A abordagem mais utilizada para isso é a análise do impacto e da probabilidade.
8 PRÁTICAS DE MoDELAGEM
8.1 Conceitos preliminares
Existe uma crença, entre os que trabalham com desenvolvimento de software, de que, de alguma 
maneira, a modelagem pode ser aplicada para facilitar essa atividade. Todavia, ao longo do tempo, 
a prática da modelagem de software vem sendo criticada, em virtude da percepção de que é uma 
atividade que precede o desenvolvimento real e que tem como foco a documentação. 
Outros autores insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento 
central importante, e não como uma atividade enfocada principalmente em documentação. Quando 
os modelos são considerados artefatos de desenvolvimento de primeira classe, os desenvolvedores 
geram menos código convencional, uma vez que abstrações de aplicativo mais poderosas podem ser 
empregadas. 
136
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
Assim, o desenvolvimento dirigido por modelo é inerentemente mais produtivo e ágil. Além disso, outros 
participantes no desenvolvimento, como analistas de negócios, arquitetos e gerentes de projetos,reconhecerão 
a	modelagem	como	um	adicional	de	valor	às	tarefas	pelas	quais	são	responsáveis.	
Quando os modelos abrangem as atividades de desenvolvimento (e em tempo de execução), a 
comunicação entre as pessoas pode ser otimizada, e a capacidade de rastreamento, ativada no ciclo 
de vida em qualquer direção. Acredita-se que tornar a modelagem uma corrente predominante possa 
alterar a economia do desenvolvimento de software e garantir que os sistemas de software atendam 
às	 necessidades	 de	 uma	 empresa.	 De	 acordo	 com	 a	Microsoft,	 em	 seu	 documento	 denominado	 de	
Estratégia de Modelagem (2005), essa abordagem do desenvolvimento dirigido por modelo é parte de 
uma iniciativa chamada fábricas de software.
 Saiba mais
Veja o artigo da Microsoft que discute a estratégia de desenvolvimento 
por modelos: 
MICROSOFT. Estratégia de modelagem. Microsoft, maio 2005. Disponível 
em: <http://msdn.microsoft.com/pt-br/library/ms379623(v=vs.80).aspx>. 
Acesso em: 2 abr. 2014.
Ainda de acordo com a Microsoft (2005), um modelo deve ser um artefato de primeira classe em um 
projeto, e não apenas uma documentação aguardando para se tornar desatualizada. 
O autor Senge (1990) define que modelos são mentais e que são pressupostos profundamente 
arraigados, generalizações ou mesmo imagens que influenciam a forma de ver o mundo e de nele 
agir. Muitas vezes, não estamos conscientes de nossos modelos mentais ou de seus efeitos sobre 
nosso comportamento. O trabalho com esses modelos inclui, também, a capacidade de realizar 
conversas ricas em aprendizados, que equilibrem indagação e argumentação, em que as pessoas 
exponham	de	forma	eficaz	seus	próprios	pensamentos	e	estejam	abertas	à	influência	dos	outros.
Os modelos possuem uma sintaxe precisa, geralmente são mais bem-editados e mais bem-
visualizados com uma ferramenta gráfica e contêm semânticas que determinam como conceitos 
específicos de domínio mapeiam para outros artefatos de implementação, como código, estruturas 
de projeto e arquivos de configuração. Dessa maneira, um modelo se parece muito com um arquivo 
de código-fonte, e os mecanismos que o sincronizam com outros artefatos de implementação são 
muito semelhantes a compiladores. Um modelo representa um conjunto de abstrações que dá 
suporte a um desenvolvedor, num aspecto de desenvolvimento bem-definido. Como os modelos 
podem abstrair e agregar informações de uma série de artefatos, podem dar suporte de modo 
mais rápido a verificações de consistência e outras formas de análise. 
137
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
 observação
Um	 modelo	 de	 conectividade	 de	 aplicativos	 poderá	 dar	 suporte	 à	
validação de protocolo de contrato, análise de segurança ou análise de 
desempenho.
Um modelo é uma representação ou interpretação simplificada da realidade, ou uma interpretação 
de um fragmento de um sistema, segundo uma estrutura de conceitos. Um modelo apresenta “apenas” 
uma visão ou um cenário de um fragmento do todo. Normalmente, para estudar um determinado 
fenômeno complexo, criam-se vários modelos. Por exemplo, podem-se citar obras da engenharia 
civil, tais como uma grande obra hidráulica, uma ampliação de praia artificial ou mesmo uma usina 
hidrelétrica. Estas não são projetadas sem estudos detalhados, em vários tipos de modelos matemáticos, 
de diversas categorias, como modelos de hidrologia, hidráulica e mecânica dos solos.
Segundo o autor Branco (2007), um modelo aplicado a processos oferece:
•	 um	meio	para	discussão:	o	modelo	de	processos	ajuda	a	situar	as	questões	relevantes	ao	permitir	
a abstração do mundo real, salientando os objetos e relacionamentos que são de interesse, 
ignorando detalhes que possam contribuir para aumentar a complexidade;
•	 um	meio	para	comunicação:	permite	que	outras	pessoas,	que	não	as	implicadas	no	desenvolvimento	do	
modelo, possam utilizá-lo como base para a sua implementação ou para a concepção de novos modelos;
•	 uma	base	para	análise:	a	análise	de	um	modelo	pode	revelar	os	pontos	fortes	e	os	pontos	fracos	
do processo, com especial relevância para os fracos, como ações que acrescentam pouco valor ou 
são potenciais focos de problemas;
•	 a	análise	por	simulação	e	animação	do	modelo	permite,	ainda,	estudar	os	efeitos	que	possíveis	
alterações podem causar em um dado processo;
•	 uma	base	para	concepção	de	novos	processos;
•	 uma	base	para	melhoria	contínua:	as	sugestões	para	a	mudança	podem	ser	expressas	em	alterações	
ao modelo e sua análise, sendo possível, ainda, sugerir métricas para avaliar o seu desempenho;
•	 uma	base	para	controle:	quando	suficientemente	formal,	para	ser	automatizado,	o	modelo	pode	
ser utilizado para controlar a execução do sistema modelado, como em um sistema de gestão de 
workflow. 
•	 além	de	garantir	o	correto	funcionamento,	permite	efetuar	medições	quanto	ao	desempenho	do	
processo.
A modelagem de sistemas de informação (software) é a atividade de construir modelos que 
expliquem as características ou o comportamento de um software, ou aplicativo, ou de um sistema 
de software. 
138
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
Na construção do software, os modelos podem ser usados na identificação das características e 
funcionalidades que este deverá prover e no planejamento de sua construção.
Frequentemente, a modelagem usa algum tipo de notação gráfica e é apoiada pelo uso de 
ferramentas de apoio denominadas de Computer-Aided Software Engineering (CASE). Ferramentas 
CASE correspondem a uma classificação que abrange todas as ferramentas baseadas em computadores 
que auxiliam em atividades de engenharia de software, desde análise de requisitos e modelagem até 
programação e testes; podem ser consideradas como ferramentas automatizadas que têm como objetivo 
auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software.
A modelagem de software normalmente implica a construção de modelos gráficos que simbolizam 
os artefatos dos componentes utilizados e os seus inter-relacionamentos. Uma forma comum de 
modelagem de programas procedurais (não orientados a objeto) é por meio de fluxogramas, enquanto a 
modelagem de programas orientados a objeto normalmente usa a linguagem gráfica de modelos UML.
 Saiba mais
É interessante, para quem ainda não conhece ou não utilizou uma 
ferramenta CASE, fazer o download de uma ferramenta free, como a JUDE 
ou a Umbrello UML, e verificar uma série de propriedades e facilidades que 
ajudam na documentação, facilitam a comunicação e, ainda, aumentam 
de forma considerável a produtividade dos desenvolvedores de software. 
Algumas são tão sofisticadas que chegam a gerar o código diretamente dos 
modelos construídos.
O JUDE pode ser baixado gratuitamente por meio da Astah community, 
no endereço: <http://astah.net/download#community>. Já o software 
Umbrello UML pode ser baixado, sem custos, no endereço: <http://umbrello-
uml-modeller.soft112.com/>.
A seguir serão detalhadas diversas práticas fundamentais e envolvidas com a modelagem de sistemas 
de informação, as denominadas práticas de modelagem.
8.2 Modelagem orientada a objetos
De acordo com Pressman (2006) e Sommerville (2007), há muito tempo se busca um padrão de 
construção de software	orientado	a	objetos	e	sua	representação	à	semelhança	da	planta	utilizada	por	
outras áreas da engenharia, tal como a planta de uma casa ou a arquitetura de um prédio da engenharia 
civil.
O enfoque tradicional de modelagem para a construção de sistemas de informação é baseado na 
compreensão desse sistema como um conjunto de programas, que, por sua vez, executamprocessos 
sobre dados. 
139
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
O enfoque de modelagem por objetos vê o mundo como uma coletânea de objetos que interagem 
e apresentam características próprias, que são representadas pelos seus atributos (dados) e operações 
(processos) (FURLAN, 1998).
A próxima figura mostra o enfoque baseado em sistema versus o enfoque baseado em objetos.
Programa Classe
Foco no sistema Foco no objeto
Processos
Atributos
Dados
Operações
Figura 41	–	Enfoque	baseado	em	sistemas	versus enfoque baseado em objetos 
Um programa, no sentido tradicional, é um conjunto de objetos que se relacionam para executar 
as funcionalidades ou os processos do sistema aplicativo. Portanto, o programa é representado por 
classes; os processos, por operações ou métodos; e os dados, por atributos dos objetos. Essa mudança de 
enfoque se justifica pelo fato de que os objetos existem na natureza muito antes de o homem criar os 
computadores e os seus programas de software. 
Carros, equipamentos, pessoas, bancos etc. apresentam características próprias que podem ser 
representadas por seus atributos e seus comportamentos no mundo real.
Furlan (1998) informa que essa abordagem oferece como principais benefícios:
•	 manter	 a	 modelagem	 do	 sistema	 e	 sua	 automação	 o	 mais	 próximos	 possível	 de	 uma	 visão	
conceitual do mundo real;
•	 servir	de	base	à	decomposição	e	modelagem	do	sistema	nos	dados,	que	é	o	elemento	mais	estável	
de todos aqueles que compõem um sistema de informação;
•	 oferecer	maior	transparência	na	passagem	de	modelagem	para	construção	por	meio	da	introdução	
de detalhes, não requerendo uma reorganização do modelo.
 Lembrete
Embora a expressão orientação a objetos tenha sido usada de formas 
distintas, deveria sugerir uma associação entre coisas do mundo real e 
trechos de programas de computador ou objetos.
140
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
Os autores Jacobson, Booch e Rumbaugh (1999) definem a orientação a objetos como:
Uma nova maneira de pensar os problemas, utilizando modelos organizados, a partir de conceitos do 
mundo real. O componente fundamental é o objeto que combina estrutura e comportamento em uma 
única entidade (JACOBSON; BOOCH; RUMBAUGH, 1999). 
Uma das características mais importantes da modelagem orientada a objetos é a reusabilidade. 
As técnicas orientadas a objetos (OO) permitem reutilizar muito mais do que o código. Com 
os modelos OO se podem reutilizar requisitos, análise, projeto, testes, interfaces de usuários e 
arquiteturas (frameworks).
De acordo com Yourdon e Argila (1998), o modelo de análise orientada a objetos (AOO) serve para 
dois propósitos: 
•	 formalizar	a	visão	do	mundo	real	em	que	o	sistema	de	software será construído;
•	 estabelecer	a	maneira	pela	qual	um	dado	conjunto	de	objetos	colabora	para	executar	o	trabalho	
do sistema de software que está sendo especificado.
Na AOO de Yourdon e Argila (1998), existem cinco camadas ou visões, conforme a figura a seguir, 
que permitem visualizá-la de perspectivas distintas.
Nome da camada Símbolos
Classes e objetos
Borda da instância (objeto)
Borda da classe
Atributos
Conexão entre 
objetos
Atributos
Serviços
Serviços
Mensagens
Estruturas
Assuntos Assunto
Figura 42	–	Estrutura	do	modelo	AOO	
141
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
A camada de classes e objetos apresenta os blocos básicos de construção do sistema proposto. Os 
objetos são abstrações de conceitos do domínio de aplicação do mundo real. 
O coração de qualquer AOO é o processo denominado modelagem de informações. Na modelagem 
AOO, os autores consideram como parte difícil do problema estabelecer o que são as coisas do mundo 
real. 
No	caso	de	métodos	orientados	a	objetos,	tem	sido	dada	mais	ênfase	à	modelagem	de	informações	
como um procedimento formal no processo de engenharia de software (YOURDON; ARGILA, 1998).
A figura a seguir apresenta um exemplo de aplicação da modelagem AOO com o uso da notação de 
Edward Yourdon. Serão representadas as entidades envolvidas em um domínio de prestação de serviços 
por assinatura, por exemplo, uma assinatura de TV fechada, uma assinatura telefônica etc. 
O exemplo apresenta somente alguns atributos e alguns serviços de um domínio de aplicação 
qualquer.
Assinante Assinatura
Id_assinante
Det_assinante
Id_endereço
Id_assinatura
Estado_assinatura
Detalhes_assinatura
Entrar_assinante
Informar_endereço
Entrar_assinatura
Renovar_assinatura
1 1
Figura 43	–	Exemplo	de	uma	aplicação	da	AOO	
Após a modelagem completa do sistema, com todas as entidades, seus atributos, seus serviços e 
suas estruturas comportamentais definidas (relacionamentos), deve ser construído o projeto orientado 
a objetos (POO) como uma extensão do modelo AOO, e, a partir dos modelos do POO, são construídos 
os códigos das transações. 
Na proposta de Edward Yourdon, o modelo POO contém as mesmas cinco camadas e usa 
a mesma notação do modelo AOO, mas é estendido para conter: componente de interação 
humana (interface homem-máquina), componente de gerenciamento de tarefas e componente 
de gerenciamento de dados.
O componente de interação humana modela a tecnologia de interface que será usada para uma 
implementação específica do sistema. O componente de gerenciamento de tarefas especifica os 
itens operacionais que serão estabelecidos para implementar o sistema. Por fim, o componente de 
gerenciamento de dados define aqueles objetos necessários para fazer interface com a tecnologia de 
banco de dados que está sendo usada.
Além da abordagem de Edward Yourdon, outros métodos e modelagens orientados a objetos 
apareceram, desde a década de 1970 até 1995. A seguir, algumas iniciativas desse período:
142
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
•	 Sally	Shlaer	e	Stephen	Mellor	escreveram	livros	sobre	análise	e	desenho	orientado	a	objetos	no	
final da década de 1980 e início da década de 1990;
•	 Jim	Odell	 e	 James	Martin	basearam	 seus	 enfoques	na	 longa	 experiência	 adquirida	por	 ambos	
no uso e na divulgação da engenharia da informação; em 1994 e 1996, lançaram os livros mais 
conceituais da época;
•	 Peter	Coad	e	Edward	Yourdon	escreveram	livros	que	propuseram	um	enfoque	de	desenho	recursivo	
em 1997, propondo a AOO e o POO;
•	 James	Rumbaugh	liderou	uma	equipe	de	pesquisadores	nos	laboratórios	da	General	Electric,	o	que	
levou ao livro sobre métodos chamados Object Modeling Technique (OMT), em 1991;
•	 Grady	Booch	desenvolveu	um	método	na	Rational	Software para análise de sistemas intensivos 
em engenharia que foram apresentados em seus livros publicados em 1994 e 1995;
•	 Ivar	Jacobson	produziu	seus	livros	a	partir	de	sua	experiência	em	sistemas	na	Ericsson	e	desenvolveu	
o método Object-Oriented Software Engineering (OOSE), que se tornou a base do processo UP e 
do processo RUP.
 Saiba mais
Vale a pena ler o livro: 
MEYER, B. Object-Oriented Software Construction. 2. ed. Rio de Janeiro: 
Prentice Hall, 1997.
Essa obra se tornou um clássico na área da tecnologia OO. O livro, apesar 
de ter sua primeira ediçao em 1988, já apresenta um conjunto de conceitos 
sobre a reusabilidade, técnicas de projeto e programação orientada a objetos 
e aplicação das técnicas OO a outros ambientes de desenvolvimento.8.3 Modelagem de sistemas com a linguagem unificada de modelos ou 
Unified Modeling Language (UML)
Antes da UML, havia diversidade improdutiva de abordagens de modelagem. Sua convergência na 
UML	1.0	foi	um	passo	à	frente	significativo	para	a	utilização	de	modelos	no	desenvolvimento	de	software. 
Cada desenvolvedor usava a abordagem do autor de sua preferência, e nem sempre suas opiniões em 
torno do tema convergiam. Outro problema era a proliferação de ferramentas gráficas específicas para 
uma determinada notação, bem como para uma metodologia OO também específica, ambas, na maioria 
das vezes, proprietárias.
143
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Ivar Jacobson, Grady Booch e James Rumbaugh, em 1995, tiveram a iniciativa de unificar os métodos 
OOSE, o método Booch’93 e o método Object Modeling Technique (OMT) e deram ao resultado dessa 
unificação o nome de Unified Modeling Language (UML), uma ferramenta para modelagem de sistemas 
de todas as complexidades (MEDEIROS, 2004). 
Em 1999, na versão 1.3, a UML passou a ser mantida pela Object Management Group (OMG), que 
é um grupo americano responsável pela padronização do uso da orientação a objetos nos Estados 
Unidos. A UML firma-se, então, no mercado e passa a ser um padrão internacional para especificação e 
modelagem de sistemas aplicativos em todas as áreas de abrangência, de informática ou TI.
A finalidade da UML é proporcionar um padrão para especificação e arquitetura de projetos de 
sistemas, desde os aspectos conceituais até as soluções concretas, tais como classes de objetos, esquemas 
de banco de dados e componentes de software reusáveis (JACOBSON; BOOCH; RUMBAUGH, 1999).
A UML foi criada para ser independente de processo de software. Os desenvolvedores podem adotar 
da UML algo que seja apropriado ao seu projeto e ao seu processo, usando-a para registrar os resultados 
de suas decisões de análise e design.
Para garantir ser um padrão internacional, a UML foi adotada pela OMG, que especifica e mantém o 
metamodelo UML. A especificação, na OMG, é definida usando-se uma abordagem de metamodelo, isto 
é, este é usado para especificar o modelo que compreende a UML, que adota técnicas de especificação 
formal. A UML não é um modelo de processo/metodologia de software, mas sim uma notação, um 
mecanismo para “mostrar o problema”, de forma que exponha a essência do domínio de um aplicativo. 
A combinação da UML com um bom processo, como o RUP ou o Scrum, resulta em uma poderosa 
combinação para a criação de aplicativos bem-sucedidos (REED JÚNIOR, 2000).
A linguagem de modelos UML tem dois objetivos: proporcionar consistência informando o cliente 
ou patrocinador do projeto de que o domínio do problema está bem-entendido pela equipe de 
desenvolvedores; e proporcionar um modelo de consistência para a equipe de implementação (arquitetos 
e programadores), que, assim, poderá implementar adequadamente o software.
 Lembrete
Deve ficar claro que somente os diagramas apresentados na UML não são 
suficientes para garantir o processo de desenvolvimento. Outros elementos, 
como um plano de projeto e profissionais preparados, são fundamentais 
para que o projeto não falhe.
A UML propõe 13 diagramas que estão divididos em três categorias: estático, dinâmico e arquitetural.
•	 Os	diagramas	estáticos	mostram	a	estrutura	do	sistema	e	as	responsabilidades;	demonstram	a	
estrutura física dos elementos e não envolvem a passagem do tempo, isto é, não mostram a 
144
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
dinâmica das coisas, mas simplesmente sua organização. Os três principais diagramas estáticos da 
UML são: modelo de caso de uso; modelo de classes; e modelo de objetos.
•	 Os	diagramas	dinâmicos	mostram	a	interação	ativa	que	o	sistema	suporta;	detalham	a	interação	
dos elementos estruturais dos diagramas estáticos. Essas interações dinâmicas são descobertas, 
nos casos de uso, como caminhos executados em resposta a alguns estímulos externos ao sistema. 
Os diagramas dinâmicos mostram o comportamento pretendido do sistema. Os principais são: 
atividades, comunicação, sequência e estado.
•	 Os	 diagramas	 arquiteturais	 mostram	 a	 realização	 do	 sistema	 em	 componentes	 funcionais	 e	
executáveis. Também diferenciam a localização física da execução e os nós de armazenamento, 
bem como uma estrutura na qual podem interagir. Os principais diagramas estruturais são: 
componentes e implantação. 
Quadro 7 – Diagramas da UML da versão 1.X e da versão UML 2.3
Diagramas
Número UML 1.X UML 2.3
1 Atividade Atividade
2 Caso de uso Caso de uso
3 Classe de objetos Classe de objetos
4 Objetos Objetos
5 Sequência Sequência
6 Colaboração Comunicação
7 Estado Estado
8 Componentes Componentes
9 Implantação Implantação (deployment)
10 ------------- Pacotes
11 ------------- Interação
12 ----------- Tempo
13 ---------- Estrutura composta
Cada diagrama da UML ou modelo pode ser usado em um determinado momento do ciclo de 
desenvolvimento de software. Deve ser utilizado para resolver ou mostrar aspectos específicos 
do problema sendo modelado, ou, ainda, para especificar artefatos diversos em atividades 
diferentes do processo de software. Por exemplo, o diagrama de atividade pode ser usado para 
detalhar uma funcionalidade, como mostrar um determinado fluxo do problema que está sendo 
estudado etc.
145
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Na figura, vemos um exemplo de aplicação do diagrama de classes de objetos da UML 2.3. Desse 
diagrama, podem ser derivadas as estruturas do banco de dados e as classes de objetos programadas.
Gerência
Funcionário
Nome
Rg
Endereço
Gerência
Grau de 
desempenho
Empresa
Nome
Endereço
Trabalha para0..*
0..*
1..*
Trabalha para
Salário
Cargo
Admite _funcionário ()
Figura 44	–	Exemplo	de	um	diagrama	de	classes	de	objetos	da	UML	
8.4 Modelagem de processos de negócio com Business Process Modeling 
Notation (BPMN) 
A	notação	BPMN	surgiu	como	um	padrão	alternativo	à	linguagem	UML	com	relação	à	modelagem	
dos	processos	de	negócio	–	também	sendo	gráfica	–,	porém	seus	símbolos	são	um	pouco	diferentes,	
pois a BPMN foi criada especificamente para modelar processos de negócio. Essa notação não oferece 
nenhum suporte para modelar dados, atores, estados de ciclo de vida ou sistemas. 
A notação BPMN foi desenvolvida pela Business Process Management Initiative (BPMI), iniciativa 
oriunda da OMG (2011), que lançou a especificação 1.0 ao público, em maio de 2004. Tanto a UML 
quanto a BPMN são notações mantidas pela OMG (2011). 
Os objetivos do esforço do grupo que desenvolveu o BPMN são:
•	 fornecer	uma	notação	que	seja	facilmente	entendida	pelos	analistas	de	negócios;
•	 ser	compreensível	por	todos	os	usuários	de	negócios;	
•	 envolver	os	analistas	de	negócios,	os	desenvolvedores,	os	técnicos	responsáveis	pela	aplicação	dos	
sistemas que irão executar os processos e as pessoas de negócios. 
A BPMN define um Business Process Diagram (BPD), que é baseado em um fluxograma adaptado 
para a criação de modelos gráficos de tarefas dos processos de negócio. Para ela, um modelo de processo 
de negócios é uma rede de objetos gráficos, denominados de atividades, e do fluxo de controle que 
define a ordem de execução.
146
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IVUm BPD é formado por um conjunto com quatro elementos gráficos, que são:
•	 objetos	de	fluxo:	evento,	atividade	e	gateway; estes definem o comportamento de um processo 
de negócio; 
•	 objetos	de	conexão:	são	os	objetos	de	conexão	que	interconectam	os	objetos	de	fluxo	para	criar	
o esqueleto estrutural básico de um processo de negócio; no BPD, podem ser utilizados três tipos 
de objetos de conexão (fluxo de sequência, fluxo de mensagens e associação); 
•	 raias	(swimlanes): são um mecanismo para organizar as atividades em categorias visuais separadas, 
que ordenam as diversas capacidades e responsabilidades e são arrumadas em pool e lane;
•	 artefatos:	 a	notação	BPMN	permite	 aos	modeladores	usar	 extensões	de	notação;	um	número	
qualquer de artefatos pode ser adicionado ao diagrama conforme as necessidades apropriadas 
ao contexto de negócio sendo modelado; a versão corrente do BPMN predefine três tipos de 
artefatos BPD (objeto de dados, grupo e anotação). 
Um exemplo de BPD simples, em que a maioria dos objetos da BPMN é utilizada, pode ser visualizado 
na figura a seguir.
Ocorre 
doença
class SPMM
Eu quero ver o médico
Pegue sua receita para 
comprar remédiosO médico pede sintomas
Pa
ci
en
te
Co
ns
ul
tó
rio
 m
éd
ic
o
<<
Po
ol
>>
<<
Po
ol
>>
Eu me sinto doente
Envia pedido 
médico
Lane 
paciente
Evento 
início
Atividade Evento-fim
Fluxo de 
mensagem
Fluxo de 
sequência
Envia pedido 
médico
Envia 
sintomas
Recebe 
sintomas
Recebe 
receita
Envia receita 
médica
Recebe pedido 
sintomas
Solicita 
sintomas
Figura 45	–	Exemplo	de	um	BPD	com	os	principais	objetos	da	BPMN	
8.5 outras práticas de modelagem de software
Um conceito de modelagem é o Model Driven Development (MDD), que surgiu com o objetivo de 
ajudar a resolver os problemas ainda vigentes com os modelos e as práticas atuais, principalmente, os 
do tipo UML, que são aplicados nos ciclos clássicos e interativos de desenvolvimento de software.
147
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
De acordo com Lucrédio (2009), a proposta do MDD é:
•	 fazer	que	o	engenheiro	de	software não precise interagir manualmente com todo o código-fonte, 
podendo se concentrar em modelos de mais alto nível, ficando protegido das complexidades 
requeridas para implementação nas diferentes plataformas;
•	 um	mecanismo	automático	é	responsável	por	gerar	o	código,	a	partir	dos	modelos;	nesse	cenário,	
modelos não são apenas um guia ou uma referência, mas fazem parte do software, assim como o 
código-fonte;
•	 automatizar	as	transformações	não	é	uma	tarefa	simples;	a	figura	mostra	os	principais	elementos	
necessários para essa abordagem e como eles são combinados;
Modelo
Outros 
modelos
Transformação Código-fonte
Mecanismo para 
executar transformações
Ferramenta 
para definir 
transformações
Figura 46	–	Principais	elementos	do	MDD	
•	 para	possibilitar	a	criação	de	modelos,	é	necessária	uma	ferramenta	de	modelagem;	utilizando	essa	
ferramenta, o engenheiro de software produz modelos que descrevem os conceitos do domínio;
•	 para	isso,	a	ferramenta	deve	ser	intuitiva	e	de	fácil	utilização,	e,	ao	mesmo	tempo,	os	modelos	
por ela criados precisam ser semanticamente completos e corretos, uma vez que devem poder 
ser compreendidos por um computador (e não por um ser humano) capaz de corrigir pequenos 
enganos ou de preencher lacunas por si só;
•	 o	elemento	que	implementa	essas	características	é	normalmente	uma	linguagem	específica	de	
domínio, ou Domain-Specific Language (DSL);
•	 os	modelos	servem	de	entrada	para	transformações	que	irão	gerar	outros	modelos	ou	o	código-
fonte;
•	 para	 definir	 as	 transformações,	 é	 necessária	 uma	 ferramenta	 que	 permita	 ao	 engenheiro	 de	
software construir regras de mapeamento de modelo para modelo, ou de modelo para código;
•	 idealmente,	 essa	 ferramenta	deve	possibilitar	que	as	 regras	de	mapeamento	 sejam	construídas	da	
forma mais natural possível, uma vez que a construção de transformadores é uma tarefa complexa;
148
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade IV
•	 finalmente,	é	necessário	um	mecanismo	que,	efetivamente,	aplique	as	transformações	definidas	
pelo engenheiro de software; esse mecanismo deve não só executar as transformações, mas 
também manter informações de rastreabilidade, possibilitando saber a origem de cada elemento 
gerado, seja no modelo, seja no código-fonte.
 Saiba mais
Para saber mais sobre as abordagens MDD, leia o trabalho acadêmico:
LUCRÉDIO, D. Uma abordagem orientada a modelos para reutilização de 
software. 2009.	138	p.	Tese	(Doutorado	em	Ciências)	–	Instituto	de	Ciências	
Matemáticas e de Computação, Universidade de São Paulo, São Carlos, 
2009. Disponível em: <http://www.teses.usp.br/teses/disponiveis/55/55134/
tde-02092009-140533/>. Acesso em: 5 mar. 2014.
Outros modelos praticados que podem ser citados são os de Carvalho e Chiossi (2001): 
•	 o	modelo	funcional	é	uma	forma	de	decompor	o	sistema	a	ser	desenvolvido	por	meio	de	suas	
principais funções e subfunções conectadas; cada conexão representa um duto por onde fluem 
os dados que serão recebidos, tratados, armazenados e enviados a outras funções, ou devolvidos 
para o mundo externo do sistema;
•	 o	modelo	 de	 dados	 representa	 os	 que	 deverão	 ser	 armazenados	 e	 acessados	 pelo	 sistema,	 o	
relacionamento entre os grupos de dados e como estes serão utilizados;
•	 os	 modelos	 formais	 utilizam	 notações	 matemáticas	 para	 especificar	 sistemas	 e	 podem	 ser	
empregados em qualquer estágio da especificação de um sistema;
•	 os	modelos	para	testes	de	programas	visam	representar	os	softwares abstraindo apenas o que for 
de interesse para a fase de teste. Esses modelos são bastante utilizados nas fases de teste unitário 
e de teste de integração.
8.6 Práticas de construção
A fase de construção, em um processo de desenvolvimento de software, na maioria dos modelos, 
vem logo após as fases de requisitos e especificação das soluções conceituais, tais como modelo de 
funcionalidades, prototipagem, modelagem dos dados, definição das regras de negócio etc. 
Diversas boas práticas são recomendadas pelos modelos de desenvolvimento, tais como o UP, o RUP 
e os modelos de qualidade, como o CMMI-DEV, o MPS.BR, as normas ISO etc. Dentre essas práticas, 
encontram-se o desenvolvimento iterativo (já abordado), a gerência de requisitos, a arquitetura baseada 
em componentes, a modelagem visual, a verificação de qualidade, o controle de mudanças, os testes 
durante o ciclo de desenvolvimento, o uso de práticas ágeis etc.
149
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Especificamente, serão abordadas algumas práticas específicas para a construção do software 
propriamente dito.
8.6.1 Arquitetura baseada em componentes
As práticas de arquitetura são o processo de tomada de decisão para estruturar o projeto ou o 
sistema que será construído, e, para isso, a decisão leva em conta tanto os requisitos funcionais quanto 
os não funcionais.
A arquitetura de um software abrange a definição dos elementos estruturais, bem como suas inter-
relações e seus comportamentos. 
As características fundamentais de uma boa arquitetura são as seguintes: 
•	 deverá	ser	flexível,	para	facilitar	a	manutenção	e	a	extensibilidade	do	software ao longo do seu 
ciclo de vida;
•	 baseada	em	componentes,	para	se	ter	os	módulos	o	mais	independentes	possível