Livro-Texto - Unidade IV

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.
118
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;
119
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 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).
120
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;
121
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.
122
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
Multimídia não
interativa
Escrita não
interativa
Formas de comunicação
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 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).
123
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
124
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;
125
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 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;
126
• 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).
127
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
128
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 Planejamento Execução Verificação Fim
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.
Processos de
monitoramento e controle
Processos de
planejamento
Processo de Processo de
iniciação encerramento
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.
129
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
130
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.
131
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
Terreno
Estrutura
Energia elétrica
Projetos
Hidráulica
Compra
Edifício principal Sistemas Iluminação
Instalação
Som
Implantação da Inspeção/testes
escola Climatização
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
132
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).
133
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.
999 Tri 3 1999 Tri 4 !99 Tri 1

Id Atividade Duração Início
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 Dependência
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 Marcos
12 Pisos 20 dias 06/01/2000
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.
134
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.
135
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>.
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.
136
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.
137
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.
138
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
Processos
Atributos
Dados
Operações
Foco no sistema Foco no objeto
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.
139
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
Borda da classe
Classes e objetos
Borda da instância (objeto)
Atributos
Atributos
Conexão entre
objetos
Mensagens
Serviços
Serviços
Estruturas
Assuntos Assunto
Figura 42 – Estrutura do modelo AOO
140
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 Id_assinatura
Det_assinante 1 1 Estado_assinatura
Id_endereço Detalhes_assinatura
Entrar_assinante Entrar_assinatura
Informar_endereço Renovar_assinatura
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:
141
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.
142
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
143
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
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
Diagramas
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.
144
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.
Funcionário 0..* Trabalha para 1..* Empresa

Nome Nome
Rg Endereço
Endereço
Gerência 0..*
Trabalha para
Salário
Gerência Cargo
Grau de Admite _funcionário ()

desempenho
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.
145
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 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.
class SPMM
Lane Atividade Evento-fim

paciente
<<Pool>>
Paciente
Envia pedido Recebe pedido Envia Recebe

médico sintomas sintomas receita
Ocorre
doença Fluxo de
Eu quero ver o médico Eu me sinto doente mensagem
Evento Pegue sua receita para

Consultório médico
O médico pede sintomas Fluxo de

início comprar remédios sequência
<<Pool>>
Envia pedido Solicita Recebe Envia receita

médico sintomas sintomas médica
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.
146
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;
Outros
modelos
Modelo
Mecanismo para
executar transformações
Transformação Código-fonte
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;
147
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.
148
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 definir medidas e critérios para determinar se o sistema
está em um nível satisfatório de aceitação. O desenvolvimento iterativo permite a realização de testes
contínuos, tanto nos processos tradicionais quanto nos métodos ágeis.
A figura a seguir apresenta uma visão da aplicação dos testes ao longo do ciclo de desenvolvimento,
usando o desenvolvimento iterativo.
Iteração 1 Iteração 2 Iteração 3
R R R
A/P A/P A/P
I I I
T/I T/I T/I
Teste Teste Teste

Tempo
Figura 47 – Desenvolvimento de software iterativo com UML
149
Unidade IV
Na figura, as atividades das iterações são: requisitos (R); análise de projeto (A/P); implementação (I);
testes e implantação (T/I).
Os testes se desenvolvem ao longo dos componentes que vão sendo liberados; são os de unidade e
os de integração. A homologação se dá com o sistema completo ou por módulos, conforme o cliente
vai recebendo.
8.6.3 Controle de mudanças
Um dos problemas mais complexos no processo de desenvolvimento de sistemas é controlar as

mudanças que os softwares sofrem ao longo do tempo. Os problemas mais comuns são: atualização
simultânea, notificação incompleta e múltiplas versões.
Uma das formas de se minimizar o controle das mudanças é o uso de ferramentas para gerenciar
versões e pedidos de mudança.
8.7 Práticas de implantação
De acordo com Souza (2009), o propósito do processo de implantação é garantir a utilização do

software pelo usuário final, de forma que venha a cumprir os objetivos para o qual foi construído ou
adquirido. O autor propõe um projeto específico que deve obedecer a algumas práticas ou disciplinas
descritas nos modelos de gerenciamento de projetos, tais como:
• o ambiente organizacional oferece condições de início para um processo de implantação do

software, com toda a infraestrutura de hardware e software disponível, usuários para os sistemas
e um gestor de negócio para cada módulo do sistema integrado;
• um plano de implantação foi desenvolvido e validado junto ao patrocinador do projeto;
• os usuários-chave são identificados e mobilizados para o processo de implantação;
• um contrato que expresse claramente as expectativas, as responsabilidades e as obrigações de

ambos (grupo de implantação e organização a ser capacitada) é elaborado;
• a infraestrutura necessária à utilização do software é disponibilizada;
• os ambientes de treinamento e de uso em produção são disponibilizados;
• um repositório é disponibilizado, e todos os documentos gerados durante o projeto são guardados

digitalmente nesse repositório;
• os demais usuários são identificados e classificados quanto ao uso;
• o treinamento é realizado, e a documentação de uso dos sistemas é disponibilizada;

150
• a utilização do software em produção em um departamento, como plano-piloto, é realizada e

certificada (homologação);
• a utilização do software em produção nas demais dependências da organização é planejada,
implementada e certificada;
• o acompanhamento do uso do sistema por um período de confirmação é realizado;
• uma certificação de uso do sistema em ambiente de produção é emitida pelo implantador e
homologada pelo usuário.
Saiba mais
Encontra-se disponível para consulta o texto:
SOUZA, E. J. Metodologia de implantação de software corporativo.

Recife: ATI, 2009. Disponível em: <http://www2.ati.pe.gov.br/c/document_
library/get_file?p_l_id=144654&folderId=144374&name=DLFE-15402.
pdf>. Acesso em: 2 abr. 2014.
O autor apresenta uma metodologia de práticas para a implantação de

sistemas ou softwares nas corporações.
Resumo
Esta unidade começa mostrando o que o autor Hélio Engholm Júnior,

em seu livro de engenharia de software, apresenta sobre os modelos de
melhores práticas da área.
Logo, é discutido que as melhores práticas na engenharia de software

estão na comunicação, no planejamento dos projetos, na produção dos
sistemas e na colocação deste para o uso dos clientes ou usuários finais, e,
às vezes, para uso da sociedade.
Inicialmente são apresentados os princípios centrais das práticas e

seus conceitos envolvidos (o que são as práticas? Como essas práticas são
apresentadas para as pessoas envolvidas com o processo de software?).
A seguir, é apresentada a prática da comunicação, bem como o

envolvimento das pessoas e suas interações. O texto deixa claro que
a comunicação é um processo humano de interação, de linguagens e,
principalmente, de informações. Os autores Pressman (2006) e Sommerville
151
Unidade IV
(2007) deixam explícito que a comunicação é difícil, principalmente, quando

se pretende entender um problema, e tem-se tornado uma das atividades
mais desafiadoras para o engenheiro de software. A partir de uma imagem,
o texto mostra que a comunicação mais efetiva se dá face a face e que,
quanto mais escrita for, pior ficará a comunicação efetiva das pessoas.
Depois são detalhadas as práticas de planejamento, que têm como

objetivo estabelecer direção para um projeto e aumentar a probabilidade
de se obter melhores resultados ao final da empreitada. O texto mostra que
deve haver sinergia de esforços para que o empreendimento tenha sucesso.
Com base nas práticas do PMBOK (2008) são discutidos o plano de projetos
e algumas das técnicas mais importantes envolvidas nesse plano, tais como
a estrutura analítica do projeto, os recursos que serão necessários e depois
gerenciados, as responsabilidades dos participantes e a confecção dos
cronogramas do projeto.
Em seguida, são discutidas as práticas de modelagem, que, de acordo

com os autores e modelos, fazem o desenvolvimento ser mais produtivo e
ágil. Essa agilidade vai depender, também, das ferramentas de automação
que farão parte do processo de desenvolvimento e de gestão. Diversas
modelagens são apresentadas, com ênfase na linguagem unificada UML.
Ao final do texto, são abordadas as práticas de construção e de

implantação do produto de software, sem esquecer a importância do
controle de mudanças, um dos mais complexos problemas na área de
desenvolvimento de software.
Exercícios
Questão 1. Existem hoje várias propostas de modelos buscando melhorar o processo de
desenvolvimento de software, e todos esses modelos se baseiam no conceito das melhores práticas de
mercado. A partir dessa constatação, têm-se as seguintes afirmativas:
I – O entendimento do problema, por parte dos desenvolvedores de software, é a essência na busca

de se produzir software de alta qualidade e produtividade.
II – Um software deve sempre fornecer valor ao cliente ou agregar valor ao negócio ou à área de
negócio. Este é um princípio para as práticas da ES.
III – Um produto de software é caracterizado por ser consumido por todos os tipos de usuários.
IV – As melhores práticas de mercado e da engenharia de software não têm como foco a manutenção
de sistemas, e sim o desenvolvimento desses sistemas.
152
V – Os dez princípios das práticas de comunicação são: escute, prepare-se para comunicar, use
um facilitador; comunique-se mais por escrita formal; faça anotações durante as reuniões; busque a
colaboração; fique focado; use desenhos; prossiga, mesmo quando não concordar; e negocie.
Assinale a alternativa correta:
A) As afirmativas II, III e V estão corretas.
B) As afirmativas I e IV estão corretas.
C) A afirmativa IV está correta.
D) As afirmativas I, II e III estão corretas.
E) A afirmativa V está correta.
Resposta correta: alternativa D.
Análise das afirmativas
I) Afirmativa correta.
Justificativa: o autor Souza ([s.d.]) afirma que, para entender um problema, diversas questões devem
ser consideradas, tais como os interessados, os dados envolvidos, as funções do software, as regras
de negócio envolvidas e quais comportamentos são necessários para resolver o problema. Daí sua
importância e sua essência no processo de software.
II) Afirmativa correta.
Justificativa: agregar valor ao negócio ou fornecer valor para o cliente é considerado um dos
princípios centrais da área de desenvolvimento de software.
III) Afirmativa correta.
Justificativa: um software ou produto de software raramente é desenvolvido para um único cliente

ou um único usuário final e, dessa forma, deve ser idealizado para atender a demandas e tipos de
usuários diferentes, tanto em conhecimento quanto em quantidade de usuários.
IV) Afirmativa incorreta.
Justificativa: as práticas encontradas nos modelos de processos de software atuam tanto no ciclo
de desenvolvimento quanto ao longo da vida do produto de software. O ciclo de evolução do software
exige que as práticas também sejam aplicáveis à manutenção deste.
153
Unidade IV
V) Afirmativa incorreta.
Justificativa: o quarto princípio é exatamente o contrário, já que a comunicação face a face é

considerada a mais efetiva de todas.
Questão 2. O gerenciamento de risco em projetos de software é importante, pois esses projetos

estão sempre expostos a incertezas inerentes às suas características diferenciadas, com relação a outros
produtos de outras áreas do conhecimento humano. A partir dessa constatação, têm-se as seguintes
afirmativas:
I– O risco somente existirá se as pessoas envolvidas não se envolverem com os objetivos do projeto.
II – É fundamental que os gerentes de projetos e seus clientes ou patrocinadores compreendam que

os projetos de software são exercícios de riscos.
III – Os riscos em projetos de software somente acontecem em relação aos requisitos, que são
levantados e entendidos no início do processo.
IV – Uma das principais técnicas de identificação de riscos é a técnica de brainstorming.
V – O uso de desenhos ou diagramas facilita a participação das pessoas durante o levantamento dos
riscos envolvidos no projeto.
Assinale a alternativa correta:
A) As afirmativas I e III estão corretas.
B) As afirmativas II, III, IV e V estão corretas.
C) As afirmativas II, IV e V estão corretas.
D) As afirmativas III, IV e V estão corretas.
E) As afirmativas I, II, IV, V estão corretas.
Resolução desta questão na plataforma.
154
Figuras e ilustrações
Figura 1
PRESSMAN, R. Engenharia de software. 6. ed. Porto Alegre: McGraw Hill, 2006. p. 17.
Figura 2
Grupo Unip-Objetivo.
Figura 3
SOMMERVILLE, I. Software engineering. Nova Iorque: Addison-Wesley, 2007. p. 644.
Figura 8
Figura 9
Adaptada de: CÔRTES, M. L. Modelos de qualidade de software. Cap. 6. Campinas: Unicamp, [s.d.].
Disponível em: <http://www.ic.unicamp.br/~cortes/inf326/transp/cap6.pdf>. Acesso em: 5 mar. 2014.
p. 6-8.
Figura 10
Figura 11
KOSCIANSKI, A; SOARES, M. S. Qualidade de software. São Paulo: Novatec, 2007. p. 68.
Figura 12
GORDON S. R.; GORDON, J. R. Sistemas de informação: uma abordagem gerencial. São Paulo: LTC,
2006. p. 31.
Figura 14
PERES, L. M.; LASKOSKI, F. C.; RADAELLI, L. F. Desenvolvimento de software: modelo incremental.

Paraná, 2014, p. 2. Disponível em: <http://www.inf.ufpr.br/lmperes/ciclos_vida/ModeloIncremental.
pdf>. Acesso em: 13 fev. 2014.
155
Figura 15

Paraná, 2014, p. 8. Disponível em: <http://www.inf.ufpr.br/lmperes/ciclos_vida/ModeloIncremental.
pdf>. Acesso em: 13 fev. 2014.
Figura 16
RAMOS, R. A. Processos de desenvolvimento de software. Univasf, Juazeiro, 2009. p. 35. Disponível em:
<http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula02.pdf>. Acesso em: 13 fev. 2014.
Figura 17
RAMOS, R. A. Processos de desenvolvimento de software. Univasf, Juazeiro, 2009. p. 22. Disponível em:
<http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula02.pdf>. Acesso em: 13 fev. 2014.
Figura 18
Figura 23
Adaptada de: AGILECRITERIA2010VALUE.JPEG. Disponível em: <http://www.ambysoft.com/artwork/

graphs/agileCriteria2010Value.jpg>. Acesso em: 11 mar. 2014.
Figura 25
PRESSMAN, R. Engenharia de software. 6. ed. Porto Alegre: McGraw Hill, 2006. p. 70.
Figura 27
BARBOSA, V.; LIBARDI, P. L. O. Métodos ágeis. 2010. 12 f. Monografia (Pós-graduação) – Faculdade de

Tecnologia, Universidade de Campinas, Campinas, 2010. p. 13. Disponível em: <http://www.ft.unicamp.
br/liag/Gerenciamento/monografias/monogafia_metodos_ageis.pdf>. Acesso em: 13 fev. 2014.
Figura 28
Adaptada de: ROSEMBERG, D.; STEPHES, M.; COLLINS-COPE, M. Agile development with iconix process.
EUA: Appress, 2005, p. 21.
Figura 29
156
Figura 30
Figura 31
EUA: Appress, 2005. p. 45.
Figura 32
Figura 40
ABE, M. T. MS Project. São Paulo: Escola Politécnica da Universidade de São Paulo, 2000. Disponível
em: <http://www.lem.ep.usp.br/Pef411/~Marcel%20Abe/Ms%20Project98.htm>. Acesso em: 17 abr.
2014.
Figura 42
Adaptada de: YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos. São Paulo: Makron
Books, 1998. p. 8.
Figura 43
Adaptada de: YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos. São Paulo: Makron
Books, 1998. p. 8.
Figura 46
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. p. 40. Disponível em: <http://www.teses.usp.br/teses/disponiveis/55/55134/
tde-02092009-140533/>. Acesso em: 5 mar. 2014.
Figura 47
157
Referências
ABE, M. T. MS Project. São Paulo: Escola Politécnica da Universidade de São Paulo, 2000. Disponível
em: <http://www.lem.ep.usp.br/Pef411/~Marcel%20Abe/Ms%20Project98.htm>. Acesso em: 17 abr.
2014.
AMBLER, S. W. Modelagem ágil. São Paulo: Bookman, 2004.
AMBYSOFT. How agile are you? 2010 survey results. Ambysoft, 2010. Disponível em: <http://www.
ambysoft.com/surveys/howAgileAreYou2010.html>. Acesso em: 13 fev2014.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). Norma ABNT NBR ISO/IEC 12207: engenharia
de sistemas e software – processos de ciclo de vida de software. Rio de Janeiro: ABNT, 2000.
BARBOSA, V.; LIBARDI, P. L. O. Métodos ágeis. 2010. 12 f. Monografia (Pós-graduação) – Faculdade de

Tecnologia, Universidade de Campinas, Campinas, 2010. Disponível em: <http://www.ft.unicamp.br/
liag/Gerenciamento/monografias/monogafia_metodos_ageis.pdf>. Acesso em: 13 fev. 2014.
BARR, A; FEIGENBAUM, E. The handbook of artificial intelligence. Los Altos: William Kaufmann, 1981. v.
I-II.
BARRETO, L. R.; PREZOTO, M. G. Introdução a sistemas especialistas 2010. Monografia para conclusão
de matéria (Mestrado em Tecnologia para Sistemas e Fenômenos Complexos) – Faculdade de
Tecnologia, Universidade Estadual de Campinas, Campinas, 2010. Disponível em: <http://www.
ft.unicamp.br/liag/wp/monografias/monografias/2010_IA_FT_UNICAMP_sistemasEspecialistas.pdf>.
BECK, K. Extreme programming explained. Boston: Addison-Wesley, 2001.
BLEAKLEY, G.; COLLYER, K.; SCOULER, J. Best practices for software development teams. IBM, Armonk,
17 sept. 2013. Disponível em: <http://www.ibm.com/developerworks/rational/library/systems-
software-lifecycle-development/systems-software-lifecycle-development-pdf.pdf>. Acesso em: 31
mar. 2014.
BOEHM, B. Cocomo® II. Los Angeles, [s.d.]. Disponível em: <http://csse.usc.edu/csse/research/COCOMOII/

cocomo_main.html>. Acesso em: 31 mar. 2014.
BRANCO, I. V. C. Modelagem de processos organizacionais integrada às aplicações práticas de

aprendizagem organizacional e competências conversacionais. 2007. 183 p. Dissertação (Mestrado
em Gestão do Conhecimento e Tecnologia da Informação) – Universidade Católica de Brasília, Brasília,
2007.
BROCKA, B. M.; BROCKA, S. Gerenciamento da qualidade. São Paulo: Makron Books, 1994.
158
CAETANO, C. Dividir, conquistar e integrar: conceitos de integração contínua para testadores ágeis.
Linha de Código, [s.d.]. Disponível em: <http://www.linhadecodigo.com.br/artigo/1252/dividir-
conquistar-e-integrar-conceitos-de-integracao-continua-para-testadores-ageis.aspx>. Acesso em: 3
fev. 2014.
CAPOVILLA, I. G. G. Elementos intrínsecos do software e sua influência na qualidade do processo

de desenvolvimento. 1999. 108 p. Dissertação (Mestrado em Qualidade) – Instituto de Matemática,
Estatística e Computação Científica, Universidade de Campinas, Campinas, 1999.
CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introdução à engenharia de software. São Paulo: Editora da

Unicamp, 2001.
CLEANROON software engineering. University of Texas, Arlington, [s.d.]. Disponível em: <http://www.
uta.edu/cse/levine/fall99/cse5324/cr/clean/page.html>. Acesso em: 31 mar. 2014.
COCKBURN, A. Crystal Clear: A Human-powered methodology for small teams. EUA: Addison-Wesley,
2004.
COMPUTER dictionary online. 2014. Disponível em: <http://www.computer-dictionary-online.org/

index.asp?q=methodology>. Acesso em: 17 abr. 2014.
CONCEIÇÃO SILVA, M. A.; RORIZ FILHO, H.; NUNES SILVA, H. F. Análise do Ba durante o processo Scrum.
In: SIMPÓSIO DE ENGENHARIA DE PRODUÇÃO, 17, 2010, Bauru. Anais... Bauru, 2010. Disponível em:
<http://massimus.com/download/analise-do-ba-durante-o-processo-scrum/>. Acesso em: 17 abr.
2014.
COSTA, I et al. Qualidade em tecnologia da informação. São Paulo: Atlas, 2013.
CUSUMANO, M. Extreme programming compared with microsoft-style iterative development. CACM, v.

50, n. 10, p. 15-8, out. 2007.
DUGGAN, E. W; THACHENKARY, C. S. Integrating nominal group technique and joint application

development for improved systems requirements determination. I&M, Amsterdam, v. 41, p. 399-411,
2004.
ENGELMORE, R. S.; FEIGENBAUM, E. Expert systems and artificial intelligence. WTEC Hyper-Librarian,
1993.
ENGHOLM JÚNIOR., H. Engenharia de software na prática. São Paulo: Novatec, 2010.
FALCONI, C. V. TQC: controle da qualidade total (no estilo japonês). Belo Horizonte: UFMG, 1992.
FAZANO, C. A. Qualidade: a evolução de um conceito. São Paulo: Banas Qualidade, 2006. n. 172.
159
FERNANDES, A. A.; KUGLER, J. L. C. Gerência de projetos de sistemas. Rio de Janeiro: Livros Técnicos e
Científicos, 1989.
FERNANDES, J. H. C. Qual a prática do desenvolvimento de software? Ciência e Cultura, Campinas, v.

55, n. 2, p. 29-33, abr./maio/jun. 2003. Disponível em: <http://www.cic.unb.br/~jhcf/MyBooks/ic/1.
Introducao/SoftwareSistemas/PraticaDeSoftware.pdf>. Acesso em: 13 fev. 2014.
______. Natureza do software e dos sistemas. Disponível em: <http://www.cic.unb.br/~jhcf/MyBooks/

iess/Intro/NaturezadoSoftwareeSistemas.pdf>. Acesso em: 12 fev. 2014.
FERREIRA, A. B. H. Dicionário Aurélio básico da língua portuguesa. Rio de Janeiro: Nova Fronteira,
1988.
FIGUEIREDO, I. L. Tipos de sistemas de informação na empresa, Oficina da Net, Santa Cruz do Sul, 5 jan.
2011. Disponível em: <http://www.oficinadanet.com.br/artigo/738/tipos_de_sistemas_de_informacao_
na_empresa>. Acesso em: 3 abr. 2014.
FINLAY, P. N. Introducing decision support systems. Oxford: NCC Blackwell, 1994.
FURLAN, J. D. Modelagem de objetos através da UML. São Paulo: Makron Books, 1998.
GASNIER, D. G. Gerenciamento de projetos. São Paulo: Instituto IMAM, 2000.
GORDON S. R.; GORDON, J. R. Sistemas de informação: uma abordagem gerencial. São Paulo: LTC,
2006.
HAAG, C.; DONOVAN, P. Management information systems: for the information age. Nova Iorque:
McGraw-Hill, 2000. p. 136-40.
HÄTTENSCHWILER, P. Neue Konzepte der Entscheidungsunterstützung. Freiburg: Liuf, 1999.
HOUAISS, A. Grande dicionário da língua portuguesa. 2012. Disponível em: <https://acesso.uol.com.br/

login.html?skin=houaiss&dest=REDIR|http://houaiss.uol.com.br/busca?palavra=metodologia>. Acesso
em: 17 abr. 2014.
IEEE 1028. IEEE standard for software reviews and audits. EUA: Institute of Electrical Electronic
Engineers Standards, 2008.
JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified modeling language: user guide. Massachusetts:
Addison Wesley, 1999.
KEEN, P. G. W. Decision support systems: a research perspective. In: FICK, G.; SPRAGUE JUNIOR, R. H.
Decision support systems: issues and challenges. Oxford: Pergamon, 1980.
160
KOSCIANSKI, A; SOARES, M. S. Qualidade de software. São Paulo: Novatec, 2007.
KROENKE, D. M. Banco de dados: fundamentos, projetos e implementação. Rio de Janeiro: LTC, 1998.
KRUCHTEN, P. The nature of software: what’s so special about software engineering? developerWorks,
Armonk, 29 Apr. 2004. Disponível em: <https://www.ibm.com/developerworks/rational/library/4700-
pdf.pdf>. Acesso em: 3 abr. 2014.
KUNSCK, M. M. K. Planejamento de relações públicas. São Paulo: Summus, 2003.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e
ao processo unificado. 2. ed. Porto Alegre: Bookman, 2004.
LAUDON, C. K; LAUDON, J. D. Sistemas de informação gerenciais. 5. ed. São Paulo: Pearson Prentice
Hall, 2004.
LINGER, R. C.; TRAMMELL, C. J. Cleanroom software engineering reference model: version 1.0. nov.
1996. Disponível em: <http://resources.sei.cmu.edu/asset_files/technicalreport/1996_005_001_16502.
pdf>. Acesso em: 31 mar. 2014.
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.
MALDONADO, J. C.; FABBRI, S. C. P. F. Verificação e validação de software: qualidade de software. São

Paulo: Prentice Hall, 2001.
MARAKAS, G. M. Decision support systems in the twenty-first century. Upper Saddle River: Prentice
Hall, 1999.
MEDEIROS, E. Desenvolvendo software com UML. São Paulo: Makron Books, 2004.
MEDEIROS, H. Modelos de desenvolvimento especializados. [s.d.]. Disponível em: <http://www.

devmedia.com.br/modelos-de-processo-especializado-conceitos-e-principios/29898>. Acesso em: 13
fev. 2014.
MENDES, I. A. C.; TREVISAN, M. A.; NOGUEIRA, M. S. Definições teórica e operacional do conceito de

comunicação. Rev. Gaúcha Enf., v. 8, n. 2, p. 204-19, 1987. Disponível em: <http://gepecopen.eerp.usp.
br/files/artigos/Artigo369fin.html>. Acesso em: 17 abr. 2014.
MEYER, B. Object-oriented software construction. 2. ed. Rio de Janeiro: Prentice Hall, 1997.
161
MICHAELIS. Dicionário de português online. 2009. Disponível em: <http://michaelis.uol.com.br/
moderno/portugues/index.php?lingua=portugues-portugues&palavra=metodologia>. Acesso em 17
abr. 2014.
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.
NONAKA, I.; TAKEUCHI, H. The new product development game. Harvard Business Review, Harvard, 1º
Jan. 1986.
OMG. Business process model and notation (BPMN). EUA: OMG, 2011. Disponível em: <http://www.
omg.org/spec/BPMN/2.0/PDF/>. Acesso em: 17 abr. 2014.
OSLON, T. How to improve your software inspection process. In: SEPG CONFERENCE, 99., 1999, EUA.
Proceedings... EUA: SEPG, 1999.
PALADINI, E. P. et al. Gestão da qualidade: teoria e casos. Rio de Janeiro: Elsevier, 2005.
PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. São Paulo: LTC, 2003.

Paraná, 2014. Disponível em: <http://www.inf.ufpr.br/lmperes/ciclos_vida/ModeloIncremental.pdf>.
Acesso em: 13 fev. 2014.
PEROTTONI, R. et al. Sistemas de informações: um estudo comparativo das características

tradicionais às atuais. Revista Eletrônica de Administração, Porto Alegre, v. 7, n. 3, p. 1-28, maio/
jun. 2001. Disponível em: <http://www.lume.ufrgs.br/bitstream/handle/10183/19461/000308562.
pdf?sequence=1>. Acesso em: 11 mar. 2014.
PEZZÉ, M.; YOUNG, M. Teste e análise de software: processos, princípios e técnicas. Porto Alegre:
Bookman, 2008.
PMBOK. Um guia do conhecimento em gerenciamento de projetos. 4. ed. Filadélfia: PMI, 2008.
POWER, D. J. Web-based and model-driven decision support systems: concepts and issues. In:
AMERICAS CONFERENCE ON INFORMATION SYSTEMS, 2000, California. Proceedings… California:
AMCIS, 2000.
PRADO, J. C. S. Gerenciando a qualidade de software com base em requisitos. Rio de Janeiro, [s.d.].
Disponível em: <http://www-di.inf.puc-rio.br/~julio/Slct-pub/Livro-qualidade.pdf>. Acesso em: 31 mar.
2014.
PRESSMAN, R. Engenharia de software. São Paulo: Makron Books, 1995.
162
______. Engenharia de software. 6. ed. Porto Alegre: McGraw Hill, 2006.
PSP. Personal software process. Body of Knowledge, version 2.0, 2009. Disponível em: <http://
resources.sei.cmu.edu/asset_files/SpecialReport/2009_003_001_15029.pdf>. Acesso em: 15 abr. 2014.
RAMOS, R. A. Processos de desenvolvimento de software. Univasf, Juazeiro, 2009. Disponível em:

<http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula02.pdf>. Acesso em: 13 fev.
2014.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de software: teoria e prática. São Paulo:
ROCHA, F. G. Introdução ao FDD – feature driven development. [s.d.]. Disponível em:<http://www.

devmedia.com.br/introducao-ao-fdd-feature-driven-velopment/27971>. Acesso em: 13 fev. 2014.
REED JÚNIOR, P. R. Desenvolvendo aplicativos com Visual Basic e UML. São Paulo: Makron Books,
2000.
ROSEMBERG, D.; STEPHES, M.; COLLINS-COPE, M. Agile Development with Iconix Process. EUA:
Appress, 2005.
ROUILLER, A. C. Gerência de projetos de software. Apostila. Lavras: Ufla/Faepe, 2008. Disponível em:
<https://gerpro2008.googlecode.com/files/Apostila_GERENCIA_DE_PROJETOS_DE_Software.pdf>.
SCHWABER, K. Agile software development with Scrum. EUA: Prentice Hall, 2002.
______. Agile software management with Scrum. EUA: Microsoft Press, 2004.
SENGE, P. M. A quinta disciplina: arte, teoria e prática da organização de aprendizagem. São Paulo:
Best Seller, 1990.
SHIBA, S. TQM: quatro revoluções na gestão da qualidade. Porto Alegre: Bookman, 1997.
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.
SOMMERVILLE, I. Software engineering. Nova Iorque: Addison-Wesley, 2007.
SOUZA, E. J. Metodologia de implantação de software corporativo. Recife: ATI, 2009. Disponível em:
<http://www2.ati.pe.gov.br/c/document_library/get_file?p_l_id=144654&folderId=144374&name=D
LFE-15402.pdf>. Acesso em: 2 abr. 2014.
163
SOUZA, G. R. Práticas da engenharia de software. IFRN, João Câmara, [s.d.]. Disponível em: <http://
docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/
praticas-de-engenharia-de-software>. Acesso em: 13 fev. 2014.
SPRAGUE, R. H.; CARLSON, E. D. Building effective decision support systems. Englewood Cliffs:
Prentice-Hall, 1982.
STEPHENS, M.; ROSENBERG, D. Extreme programming refactored: the case against SP. EUA: Apress, 2003.
TELES, V. M. Um estudo de caso da adoção das práticas e valores do extreme programming. 2005. 90 f.
Dissertação (Mestrado em Informática) – Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2005.
Disponível em: <http://desenvolvimentoagil.com.br/xp/dissertacaoXP.pdf>. Acesso em: 16 abr. 2014.
TREVISANI, A. T. et.al. Gerenciando qualidade, prazos e custos em projetos de SI. In: SEMEAD, 7,
2004, São Paulo. Anais... São Paulo: FEA/USP, 2004. Disponível em: <http://www.ead.fea.usp.br/
Semead/7semead/paginas/artigos%20recebidos/mqi/MQI09_-_Gerenciando_qualidade.PDF>. Acesso
em: 13 fev. 2014.
TSP. Team software process. Body of Knowledge (BOK). EUA. Software Engineering Institute. 2010:
Disponível em: <http://resources.sei.cmu.edu/asset_files/TechnicalReport/2010_005_001_15254.pdf>.
TURBAN, E. Decision support and expert systems: management support systems. Englewood Cliffs:
TURBAN, E.; MCLEAN, E.; WETHERBE, J. Tecnologia da informação para gestão. 3. ed. Porto Alegre:
Bookman, 2004.
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.
VIEIRA, R. B. Business Intelligence: um apoio à tomada de decisão. 2011. Monografia (Especialização

em Gestão Empresarial) – Universidade Candido Mendes, Rio de Janeiro 2011. Disponível em: <http://
www.avm.edu.br/docpdf/monografias_publicadas/k216209.pdf>. Acesso em: 7 abr. 2014.
WEBER, K. C. et al. MPS.BR – Melhoria de processo de software brasileiro: resultados alcançados

e lições aprendidas (2004-2008). Softex, [s.d.]. Disponível em: <http://www.softex.br/wp-
content/uploads/2013/09/MPS.BR-Melhoria-de-Processo-do-Software-Brasileiro-resultados-
alcan%C3%A7ados-e-li%C3%A7%C3%B5es-aprendidas-2004-2008.pdf>. Acesso em: 11 mar. 2014.
WOOD, J.; SILVER, D. Joint application development. EUA: John Wiley & Sons, 1995.
YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos. São Paulo: Makron Books, 1998.
164
______. Walkthroughs and inspections. In: ______. Modern structured analysis. 6. ed. Upper Saddle
River: Prentice Hall, 2000.
Sites
<http://astah.net/download#community>.
<http://alistair.cockburn.us/crystal>.
<http://homepages.dcc.ufmg.br/~wilson/praxis/>.
<http://massimus.com>.
<http://umbrello-uml-modeller.soft112.com/>.
<http://www.abnt.org.br>.
<http://www.fnq.org.br/>.
<http: www.ibqts.com.br>.
<http://www.sei.cmu.edu/>.
<http://www.softex.br/mpsbr/>.
<http://www.swebok.org>.
<http://www.uml.org>.
165
166
167
168
Informações:
www.sepi.unip.br ou 0800 010 9000

Livro-Texto - Unidade IV

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Livro-Texto - Unidade IV

Загружено:

Авторское право:

Доступные форматы

Unidade IV

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

7.2 Princípios centrais

• Entenda o problema (comunicação e análise): a essência de um software correto está no

• Planeje uma solução (modelagem e projeto): a partir das necessidades e do entendimento

• Examine o resultado quanto à precisão (teste e garantia de qualidade): diversos modelos

• pense e estude os problemas e as possíveis soluções completamente, antes de iniciar o projeto;

No portal da Softex é possível encontrar a descrição do modelo MPS,

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,

As práticas da comunicação na engenharia de software já são evidentes durante a coleta das

De acordo com Pressmann (2006) e Sommerville (2007), a comunicação para o entendimento de um

• primeiro princípio – escute: concentre-se nas respostas do interlocutor, peça esclarecimentos

• sétimo princípio – conserve-se focado: o facilitador da comunicação deve manter a conversa

• décimo princípio – negociação não é um concurso ou um jogo: em uma negociação, as coisas

Já para Silva, Nascimento e Nogueira (2007), é particularmente importante na função de direção,

Ainda para Kunsck (2003), a comunicação empresarial/organizacional é a soma de todas as atividades

Para saber mais sobre os conceitos envolvidos na comunicação dentro

SILVA, S. S. F.; NASCIMENTO, T. C. C.; NOGUEIRA, V. B. Diagnóstico

A próxima figura mostra um gráfico em que se apresentam resultados de pesquisas mostrando a

Figura 36 – Comunicação efetiva de acordo com as formas de comunicação

Dentre as técnicas de comunicação na engenharia de software, temos as reuniões denominadas

7.3.1 A técnica de reunião walkthrough

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,

A técnica de comunicação ou reunião walkthrough é prática, simples e bem-aceita para a melhoria da

De forma geral, os walkthroughs tendem a ocorrer nos pontos de

Cabe ressaltar que os walkthroughs não são as únicas formas de

7.3.2 A técnica de reunião Joint Application Development/Design (JAD)

De acordo com Duggan e Thachenkary (2004):

A técnica de reunião JAD é um processo de grupo onde os participantes

• 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

• os intervalos para refeições são de 90 a 150 minutos; as refeições normalmente ocorrem no

• 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:

Documento sobre a técnica de reunião JAD, de Mauro Vianna, com

VIANNA, M. Reuniões de levantamento: como torná-las produtivas?

7.4 Práticas de planejamento

A atividade de planejamento é um esforço sistemático e formal que visa estabelecer direção e

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

Quando se trata de práticas de planejamento, invariavelmente, trabalha-se com o conceito de

Um projeto é um esforço temporário empreendido para criar um produto,

ou um documento (por exemplo, um projeto de pesquisa desenvolve um

Quando se trata de planejamento, imagina-se viajar no tempo, rumo ao futuro. Trata-se de um

Início Planejamento Execução Verificação Fim

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

Figura 39 – Sequência tradicional de ciclo de vida do projeto

Depois de submetida e aprovada a proposta do projeto, inicia-se o processo de planejamento, que é

A natureza multidimensional do gerenciamento de projetos cria realimentações periódicas de

De acordo com o PMBOK (2008):

O planejamento organizacional impacta o projeto através de uma priorização

7.4.1 Plano de projetos

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

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;