ENGENHARIA DE SOFTWARE I -Livro-Texto Unidade 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 ambiente físico. Ele é fundamental 
no desenvolvimentoda 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ídos no 
processo de software. 
7.3.1 A técnica de reunião walkthroughEssa 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, uma reuniã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 deruí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
ab
io
 -
 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çãoou 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, executam processos 
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ê omundo 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 IV
Um 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 umprocesso 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 e que possam 
ser reutilizados.
Devem-se usar modelos visuais ou a modelagem visual, tais como o modelo de classes de objetos e 
os modelos de sequência, que facilitam o entendimento, facilitam a comunicação da equipe, diminuem 
a ambiguidade e permitem a rastreabilidade dos códigos construídos.
8.6.2 Verificação da qualidade
A qualidade na fase de construção envolve