Fundamentos Da Engenharia De Software-1

Prévia do material em texto

Fundamentos daFundamentos da
Engenharia de SoftwareEngenharia de Software
AUTORIA
Ricardo Bortolo Vieira
Bem vindo(a)!
Seja muito bem-vindo(a)! 
Olá prezado(a) aluno(a), este é o livro Fundamentos de Engenharia de Software, sou
o professor Ricardo Vieira, autor deste material, e o assunto que abordarei no
decorrer do nosso estudo poderá auxiliá-lo em sua carreira e abrir caminho para o
mundo dos negócios, mostrando-lhe um lado mais gerenciar do processo de
desenvolvimento de software. Com o passar do tempo, você irá se adaptar aos
jargões.
Meu objetivo principal com este livro é apresentar os conceitos mais importantes da
engenharia de software e discutir técnicas para gerenciar o processo de
desenvolvimento de software. Este processo vai auxiliar você a levantar as
necessidade de cada empresa e produto e analisar cada necessidade apresentada e
escolher o melhor processo. Além disso, pretendo deixar claro que o uso correto dos
conceitos de engenharia de software podem ajudá-lo a alcançar os objetivos
estratégicos de sua empresa ou auxiliá-lo a colocar em prática uma nova ideia.  
Este livro está organizado em quatro unidades, além da apresentação e conclusão.
Cada uma delas correspondendo a uma das partes importante do processo de
desenvolvimento de software.
Na primeira unidade você irá estudar os conceitos básicos da engenharia de
software, revisar um pouco da história desta engenharia tão recente em relação às
demais e introduzir os processos de software que serão detalhados em outras
unidades. 
Já na unidade II você poderá constatar que a ela está totalmente focada em
projetos, e assim estudaremos desde o projeto arquitetural, passando pelos projetos
de componentes, interface de usuário, e WebApps e não deixando de discutir um
pouco sobre padrões de projetos.
Depois, na terceira unidade, falaremos sobre os processos da qualidade, aprendendo
sobre os conceitos básicos da qualidade e as técnicas de revisão de código e
artefatos. Além disso, vamos discutir sobre a garantia da qualidade de software e
apresentar estratégias de teste de software, que devem se adaptar ao processo
criado para cada necessidade discutida na unidade I. Na última unidade, vamos
entender melhor sobre o gerenciamento de projetos e as métricas de processo e
projeto. Pois sem indicadores não é possível gerenciar. Vamos também discutir
sobre estimativas de projeto de software e manutenção e reengenharia como
processos necessários em alguns projetos.
Agora, mãos à obra! Tenha uma boa e agradável leitura! 
Unidade 1
Introdução da Engenharia
de Software
AUTORIA
Ricardo Bortolo Vieira
Introdução
Caro(a) aluno(a), neste capítulo, trataremos de assuntos iniciais importantes paro o
bom entendimento dos demais capítulos desta apostila. Para tanto, conceitos
genéricos serão explicados (como software, dados, informações, engenharia de
software), fornecendo uma visão geral, do funcionamento do processo até chegar a
de�nição de engenharia de software propriamente dito e as atividades que são
essenciais para esse processo, desde a engenharia de requisitos até os testes e
evolução do software. 
Vamos estudar também o modelo de processo de software e discutir o que
essencialmente todo o processo de software deve ter, que são as 4 atividades
principal: Especi�cação de Software, Projeto e Implementação de software,
Validação de Software e Evolução do Software. Neste tópico vamos também
trabalhar o conceito de cada um deles.
No tópico sobre desenvolvimento dirigido a plano, estudaremos a sequência de
atividades que cada um dos modelos que seguem esse conceito trabalham. Os 
modelos estudados neste tópico serão: Modelo Cascata, modelo espiral e modelo
incremental. 
Já no tópico sobre desenvolvimento ágil iremos estudar o manifesto que deu
origem a todos estes tipos de processo o chamado manifesto ágil. Neste tópico
iremos estudar 2 modelos: o modelo XP (eXtreme Programming) e o modelo
SCRUM.
Além disso, será apresentado a Linguagem de Modelagem Uni�cada (UML) que
representa uma linguagem visual extremamente poderosa e não ambígua. Esta
linguagem é muito importante para o engenheiro de software pois assim ele pode
desenhar o processo de software baseado nas regras de negócio, independente da
linguagem de desenvolvimento. Ainda neste tópico conheceremos alguns exemplos
de software CASE baseadas em UML para apoiar o processo da engenharia de
software e torná-la mais e�ciente e reutilizável. 
Então vamos lá! 
Bons estudos! 
Introdução a Engenharia
de Software
AUTORIA
Ricardo Bortolo Vieira
A maior parte dos serviços e infraestruturas são controladas atualmente por
software (SOMMERVILLE, 2011). Ele é importante porque afeta quase todos os
aspectos da nossa vida e está incorporado no comércio, na cultura e nas atividades
cotidianas (PRESSMAN, 2011).  Por isso o mundo moderno não poderia existir sem o
software (SOMMERVILLE, 2011). 
O Software, produto �nal e objeto principal de todo o trabalho desenvolvimento
dentro da engenharia de software, cada dia mais é indispensável a qualquer
atividade, seja ela industrial, comercial ou até pessoal. As atividades que ainda não
tem nenhum ou pouco tipo de automação de software, estão em vias de fazê-lo.
Para essa atividade de desenvolver o produto, aplica-se o mesmo paradigma para
um produto bem-sucedido da indústria, ou seja, adaptar o processo e torná-lo ágil
para conduzir a um resultado de alta qualidade, atendendo as necessidades do
cliente e do usuário �nal. Para o estudo deste conceito, apresentamos a engenharia
de software (PRESSMAN, 2011). 
Mas o que seria um
Software?
AUTORIA
Ricardo Bortolo Vieira
"Software de computador é o produto que pro�ssionais de software desenvolvem e
ao qual dão suporte no longo prazo. Abrange programas executáveis em um
computador de qualquer porte ou arquitetura, conteúdos (apresentados à medida
que os programas são executados), informações descritivas tanto na forma impressa
como na virtual, abrangendo praticamente qualquer mídia eletrônica." (PRESSMAN,
2011, p.29) 
Com base nessa de�nição, a engenharia de software pode de�nir processos
abrangentes, métodos (práticas) e um leque de ferramentas que possibilitam aos
pro�ssionais desenvolverem software de altíssima qualidade.
Outra questão que é importante ressaltar é que, do ponto de vista de um
engenheiro de software, o software é um conjunto de programas, conteúdo (dados)
e outros artefatos. Porém, do ponto de vista do usuário, o artefato consiste em
informações resultantes que, de alguma forma, tornam a vida dele melhor.
Ainda segundo Pressman (2011), software consiste em: 
1. Instruções (programas de computador), que, durante sua execução, podem
fornecem características, funções e desempenho desejados;
2. Estruturas de dados que permitem aos programas buscar e alterar 
informações da forma como os programas precisam; e 
3. Informação descritiva, tanto na forma impressa como na virtual, e tanto para o
foco técnico como para o usuário �nal, descrevendo a operação e o uso dos
programas.
O software distribui basicamente informação. Ele transforma dados de modo que
possam ser mais úteis num determinado contexto, gerencia informações comerciais
para aumentar a competitividade, fornece um portal para redes mundiais de
informação e os meios para obter informações de todas as formas (PRESSMAN, 2011).
Os sistemas de software são abstratos e intangíveis, não há limites naturais para o
potencial do software, sejam pelas propriedades naturais, leis da física ou processos
da manufatura (SOMMERVILLE, 2011).
Segundo Pressman (2011), software é mais um elemento lógico do que físico. Desta
maneira há algumas características que o diferencia de hardware:
1. Software é desenvolvido ou passa por um processo de engenharia, ele não é
fabricado no sentido clássico.
2. Software não se desgasta, ele não é suscetível aos males ambientais que fazem
com que o hardware se desgaste. Não existem peças de reposição de software,
cada defeito indica um erro no projeto;
3. A maioria dos softwares continuaa ser construído de forma personalizada.
Todo projeto de software se inicia por alguma necessidade de negócios, seja ela de
corrigir algum defeito de uma aplicação já existente, a necessidade de estender as
funções e ou recursos ou a de criar um novo produto, serviço ou sistema
(PRESSMAN, 2011).
Para Sommerville (2011), um software é um programa de computador e a
documentação associada. E os produtos de software podem ser desenvolvidos para
um cliente especí�co ou para o mercado em geral. Assim, produtos de software que
podem ser classi�cados em dois tipos:
1. Produtos genéricos: existem sistemas que são feitos e colocados no mercado
para qualquer cliente que esteja interessado em comprá-los.
2. Produto sob-encomenda: diferente dos genéricos, estes são encomendados
por um cliente em particular de acordo com suas necessidades.
Engenharia de Software
AUTORIA
Ricardo Bortolo Vieira
Fazer software não é uma tarefa fácil, software de qualidade é ainda mais difícil.
Todavia, mesmo apresentando baixa qualidade, o interesse das organizações pelo
desenvolvimento de sistemas tem aumentado. Isso porque as organizações
reconhecem que software é fonte de importantes vantagens competitivas (SILVA;
VIDEIRA, 2001).
Segundo Sommerville (2011), os diversos relatos de software que deram errado e
resultaram em “falhas de software” são conseqüências de dois fatores:
1. Aumento da demanda: Os sistemas devem ser construídos e entregues mais
rapidamente e esses sistemas são maiores e até mais complexos. A engenharia
de software não consegue lidar com isso, novas técnicas de engenharia de
software precisam ser criadas para atender essas novas demandas.
2. Expectativas baixas: As empresas eram obrigadas a desenvolver software à
medida que suas necessidades continuavam aumentando. O que torna seu
software menos con�ável e mais caro do que devia ser. Por isso é necessário
educação e treinamento em engenharia de software para solucionar esses
problemas.
Segundo Pressman (2011), existem inúmeros desa�os que os desenvolvedores de
software devem estar preparados para enfrentar no século XXI, por exemplo:
Software tornou-se incorporado em todos os sentidos da nossa vida, o número
de pessoas interessadas no que o software pode oferecer tem crescido
signi�cantemente;
Os requisitos da tecnologia da informação demandados estão cada vez mais
complexos;
Pessoas, governos e negócios dependem cada vez mais de software para
decisões estratégicas e táticas;
Software deve ser passível de manutenção para tolerar as mudanças
necessárias.
A engenharia de software é uma disciplina da engenharia que tem foco desde os
estágios iniciais da especi�cação de um sistema até a manutenção de um software.
A engenharia de software é importante por dois motivos, segundo (SOMMERVILLE,
2011):
1. Cada vez mais os indivíduos dependem de software avançado. Por isso eles
devem ser produzidos de forma con�ável, econômica e rápida;
2. Em longo prazo, é mais barato usar métodos e técnicas de engenharia de
software para sistema de software.
Uma das primeiras de�nições da Engenharia de Software foi dada por Fritz Bauer no
�nal dos anos 60: “a de�nição e utilização de princípios de engenharia sólidos, de
modo a desenvolver software econômico, con�ável e que trabalha e�cientemente
em máquinas reais. Inclui um conjunto de métodos, de ferramentas e de
procedimentos” (BAUER, 1971, p. 524).
Outra de�nição, mais comumente usado foi proposta por Potts na IEEE em 1993: "a
Engenharia de Software é a aplicação de um processo sistemático, disciplinado e
quanti�cado ao desenvolvimento, operação e manutenção de software, ou seja, e
Engenharia de Software é a aplicação de técnicas da Engenharia de Software"
(POTTS, 1993, p. 20). 
Todos os tipos de sistemas precisam da engenharia de software, independente do
�m ou da complexidade, o que diferencia são as técnicas utilizadas para chegar ao
objetivo �nal (SOMMERVILLE, 2011).
A engenharia de software é importante porque ela nos capacita para o
desenvolvimento de sistemas complexos, dentro do prazo e com alta qualidade,
atendendo as necessidades daqueles que usarão o produto. Necessidade essa que
normalmente é expressa no início de qualquer projeto com uma simples conversa
entre as partes (cliente e desenvolvedor) (PRESSMAN, 2011).
De acordo com Sommerville (2011), a maior parte do desenvolvimento de software é
pro�ssional, com um propósito especí�co de negócio e é normalmente criado,
mantido e alterado por equipes. A engenharia de software busca apoiar esse
desenvolvimento com técnicas que auxiliam na especi�cação, projeto e evolução de
programas.
Quando falamos na engenharia de software, estamos falando também de toda
documentação envolvida e con�gurações necessárias para o bom funcionamento
do programa (SOMMERVILLE, 2011).
Segundo Sommerville (2011) existem fundamentos da engenharia de software que
se aplica independentemente do tipo de sistema de software:
1. Devem ser desenvolvidos em um processo gerenciado e compreendido;
2. Con�ança e desempenho são importantes para todos os tipos de sistema;
3. É importante entender o que os clientes esperam do sistema;
4. Deve-se fazer o melhor uso possível dos recursos existentes.
A engenharia de software é dividida em camadas, cada uma delas é descrita por
Pressman (2011) da seguinte maneira: 
A peça fundamental que sustenta a Engenharia de Software é o Foco na Qualidade,
qualquer abordagem de engenharia deve estar fundamentada em um
comprometimento organizacional de qualidade.
 Em seguida, a Camada de Processos mantém as camadas de tecnologia coesas e
possibilita o desenvolvimento de software de forma racional e dentro do prazo. Para
que isso ocorra, uma metodologia é estabelecida, com uma base de controle de
gerenciamento de projetos, gerenciamento de mudanças e controle de qualidade,
para entrega efetiva dos produtos concebidos na engenharia de software
(PRESSMAN, 2011).
Os Métodos fornecem as informações técnicas, com uma gama de tarefas, como
comunicação, análise de requisitos, construção do programa, teste e suporte, para
desenvolver o software.
Por �m, as Ferramentas dão suporte automatizado ou semiautomatizado para os
processos e métodos.
O posicionamento das camadas descritas anteriormente é ilustrado na Figura 1. 
Figura 1 - Camadas da Engenharia de Software.
Ferramentas
Métodos
Processo
Foco na qualidade
Fonte: Pressman (2011)
Modelos de Processo de
Software
AUTORIA
Ricardo Bortolo Vieira
Um software não pode ser desenvolvido de qualquer jeito, sem seguir critérios, sem
que se saiba qual o próximo passo a ser dado. Por isso que os conceitos relacionados
à engenharia de software devem ser utilizados. Hoje em dia, a empresa precisa
de�nir qual o seu processo de software.
Esta engenharia é realizada por pessoas (como engenheiros de software e gerentes)
de amplo conhecimento que precisam adaptar um processo de software de acordo
com as demandas do mercado de modo que �que apropriado aos produtos
desenvolvidos e com suas necessidades (PRESSMAN, 2011).
Processo é um conjunto de atividades, ações e tarefas realizadas na criação de
algum produto (PRESSMAN, 2011; SOMMERVILLE, 2011). Essas atividades podem ser a
partir do zero em determinada linguagem de programação, ou por meio de
alterações/incrementos em sistemas já existentes (SOMMERVILLE, 2011).
 No contexto de engenharia de software, esse processo não é uma “receita” rígida e
restrita de como desenvolver um software. É uma abordagem adaptável que
possibilita a equipe de software realizar o trabalho de solucionar o conjunto
apropriado de ações e tarefas. Ou seja, signi�ca a abordagem adotada conforme um
software é elaborado pela engenharia que pode estabilizar e organizar uma
atividade que pode ser bastante caótica (PRESSMAN, 2011).
Tarefa é um objetivo pequeno, porém bem de�nido que produz um resultado
tangível (PRESSMAN, 2011).
Uma ação pode ser de�nida como um conjunto de tarefas que resultam num
artefato de software fundamental (PRESSMAN, 2011). 
Segundo Pressman (2011),a metodologia de processo é o alicerce para um processo
de engenharia de software completo. 
Para Sommerville (2011), existem muitos processos de software diferentes, mas todos
eles incluem pelo menos quatro atividades fundamentais para a Engenharia de
Software. 
Especi�cação de Software: É necessário que o cliente de�na as funcionalidades do
software que será desenvolvido, e que o software tenha suas restrições operacionais
bem levantadas;
Projeto e Implementação de software: O software deve ser produzido de acordo
com as especi�cações;
Validação de Software: Depois de produzido, o software deve ser validado para
garantir que a demanda do cliente tenha sido atendida;
Evolução do Software: As funcionalidades de�nidas pelo cliente durante o
desenvolvimento podem mudar e o software deve evoluir para atender tanto as
necessidades de mudança do cliente, como do mercado.
Essas atividades genéricas podem ser usadas para o desenvolvimento de sistemas
simples até os mais complexos. Para muitos projetos de software, essas atividades
são aplicadas repetidamente conforme as iterações do projeto (PRESSMAN, 2011).
Diversas outras atividades apóiam as atividades fundamentais para o
desenvolvimento de um software, são elas: controle e acompanhamento do projeto,
administração de riscos, garantia de qualidade de software, gerenciamento da
usabilidade, entre outras (PRESSMAN, 2011).
Em geral, os processos de software incluem atividades complexas, que como todo
processo intelectual e criativo, depende de pessoas para tomar decisões e fazer
julgamentos, desta maneira, não existe processo ideal, as empresas os adaptam
conforme sua necessidade (SOMMERVILLE, 2011). Para alguns sistemas, como os
críticos, é necessário um processo de desenvolvimento bem estruturado, já para um
sistema de negócios, com requisitos que se alteram constantemente, um processo
menos formal e mais �exível seria o mais indicado (SOMMERVILLE, 2011).
Mas o que acontece é que nem sempre as empresas aproveitam as boas técnicas da
engenharia de software em seu desenvolvimento de software. E, normalmente, o
software não atende aos requisitos do usuário, acaba demorando mais tempo para
ser desenvolvido do que o previsto, aumentando assim, o valor do custo do software. 
Princípios que orientam a
prática dos modelos de
processo de software
AUTORIA
Ricardo Bortolo Vieira
Todos os modelos de processos de software podem acomodar as atividades
essenciais descritas no tópico anterior, porém cada um deles dá uma ênfase
diferente a essas atividades e de�ne um �uxo de processo que invoca essas
atividades de diferentes formas (PRESSMAN, 2011).
Os processos de software podem ser categorizados como modelo dirigido a plano
ou como um modelo ágil. Todas as atividades planejadas com antecedência e que o
progresso é avaliado por comparação com o projeto inicial se caracterizam por um
modelo dirigido a plano. Já em um modelo ágil, o planejamento é gradativo, e por
isso é mais fácil alterar o processo de maneira a re�etir as necessidades de
mudanças dos clientes. (SOMMERVILLE, 2011). 
Cada abordagem é indicada para diferentes tipos de software, e é necessário
encontrar um equilíbrio entre eles.
A Figura 2 mostra as diferenças entre as abordagens dirigidas a planos e ágil para a
especi�cação do sistema. Na primeira maneira, ocorrem interações nas atividades
com documentos formais, usados para estabelecer a comunicação entre os estágios
do processo, então os requisitos evoluem e depois será produzida uma especi�cação
de requisitos, que é entrada para o projeto e implementação. Em uma abordagem
ágil, iterações ocorrem em todas as atividades, portanto, os requisitos e o projeto são
produzidos em conjunto (SOMMERVILLE, 2011). 
Figura 2 - Especi�cações dirigidas a planos e ágil.
Desenvolvimento baseado em planos
Desenvolvimento ágil
Engenharia
de requisitos
Engenharia
de requisitos
Projeto e
implementação
Projeto e
implementação
Especificação
de requisitos
Solicitação de mudança
de requisitos
Fonte: Sommerville (2011)
Existem vários tipos de modelos de processos de software, e inclusive os artigos
cientí�cos continuam a propor novas adaptações. Vamos apresentar aqui, três tipos
de modelos baseados no conceito dirigidos a plano e segundo Sommerville (2011): 
Modelo Cascata: Considera as atividades de especi�cação, desenvolvimento,
validação, e evolução, fundamentais ao processo e as representa como fases
separadas;
Desenvolvimento Incremental: Intercala as atividades de especi�cação,
desenvolvimento e validação. Um sistema é rapidamente desenvolvido através
de especi�cações abstratas e a partir dele várias versões são entregues com
re�namento contínuo;
Modelo Espiral: Processo dirigido a riscos, onde cada volta da espiral
representa uma fase do processo de software. Estas voltas são concêntricas e
partem do centro para a marginal. A espiral mais interna pode ser o processo
de estudo de viabilidade do software e a próxima de�ne os requisitos, e assim
por diante.
Modelos de
desenvolvimento dirigidos
a plano
AUTORIA
Ricardo Bortolo Vieira
Modelo Cascata 
Modelo de processo prescritivo, proposto para trazer ordem ao caos existente no
desenvolvimento de software, fornecendo um roteiro razoavelmente e�caz para as
equipes de desenvolvimento de software. O modelo cascata sugere uma
abordagem seqüencial e sistemática, começando com levantamento de requisitos
com o cliente e passando pelas fases de planejamento, modelagem, construção e
entrega. É normalmente utilizado quando os requisitos são bem compreendidos ou
quando adaptações ou aperfeiçoamento são bem de�nidos (PRESSMAN, 2011). 
Figura 3: Modelo Cascata.
Requerimento
Projeto
Especificação
de requisitos
Especificação
de requisitos
Especificação
de requisitos
Fonte: Adaptado de Sommerville (2011)
Modelo Incremental 
Também é um modelo prescritivo, em que os requisitos iniciais são razoavelmente
bem de�nidos, no entanto, um processo puramente linear não é usado. O
fornecimento de partes do sistema ao usuário é necessário para que se possa re�nar
e expandir suas funcionalidades em versões posteriores (PRESSMAN, 2011). 
Figura 4 - Modelo Incremental.
Comunicação
Incremento n
Fu
nc
io
na
lid
ad
es
 e
 c
ar
ac
te
rí
st
ic
as
 d
o 
pr
oj
et
o
Tempo do projeto
Incremento 2
Incremento 1
Entrega n
Entrega 2
Entrega 1
núcleo do produto
Planejamento
Modelagem
Construção
Implantação
Comunicação
Planejamento
Modelagem
Construção
Implantação
Comunicação
Planejamento
Modelagem
Construção
Implantação
Fonte: Adaptado de Sommerville (2011)
Modelo Espiral 
O software é desenvolvido de maneira que possa evoluir ao longo do tempo. Acopla
iteratividade e prototipação com os aspectos sistemáticos e controlados do modelo
cascata (PRESSMAN, 2011).  
Figura 5 - Modelo Espiral.
Determinar
objetivos
Planejar próxima
interação
Desenvolver
e testar
Identificar e
resolver riscos
Fonte: Adaptado de Sommerville (2011)
Existe também o chamado processo uni�cado, que é uma metodologia para
engenharia de software orientada a objetos usando a UML e reúne as melhores
práticas dos modelos já existentes (PRESSMAN, 2011).  
Modelos de
desenvolvimento ágil
AUTORIA
Ricardo Bortolo Vieira
Em 2001, Kent Beck e outros dezesseis renomados desenvolvedores, autores e
consultores da área de software assinaram o "Manifesto para o Desenvolvimento Ágil
de Software”. Normalmente, um manifesto é associado a um movimento político
emergente: atacando a velha guarda e sugerindo uma mudança revolucionária. De
certa forma, é exatamente do que trata o desenvolvimento ágil (PRESSMAN, 2011).
Por que Scrum? Criei o Scrum, junto com Ken Schwaber, há vinte anos,
como um jeito mais rápido, con�ável e e�ciente de desenvolver
softwares na indústria de tecnologia. Até aquele momento — e até
2005 —, a maior parte do desenvolvimento de softwares era executada
com base no método em cascata, de acordo com o qual um projeto era
concluído em etapas distintas e levado passo a passo até o lançamento
paraOs consumidores ou usuários. O processo era lento, imprevisível, e
muitas vezes não resultava em um produto que as pessoas quisessem
ou pelo qual se dispusessem a pagar. Atrasos de meses, ou até mesmo
anos, eram endêmicos. Os antigos planos passo a passo,
confortavelmente detalhados em diagramas de Gantt, davam à
gerência uma sensação de que se tinha total controle sobre o
desenvolvimento de um projeto. No entanto, na maioria esmagadora
dos casos, em pouco tempo os atrasos em relação ao cronograma
começavam e o orçamento era ultrapassado em uma escala
desastrosa. 
Para superar essas falhas, inventei, em 1993, um novo jeito de fazer as
coisas: o Scrum. Trata-se de uma mudança radical em relação às
metodologias prescritivas e hierarquizadas empregadas na gerência de
projetos no passado. Ao contrário delas, o Scrum se assemelha a
sistemas evolucionários, adaptativos e autocorretivos. Desde seu
nascimento, a estrutura do Scrum se tornou a maneira como o setor de
tecnologia cria novos softwares e produtos. Porém, apesar de ter obtido
muito sucesso no gerenciamento de projetos de software e hardware
no Vale do Silício, o Scrum permanece relativamente desconhecido no
mundo dos negócios em geral." (SUTHERLAND, 2016) 
Embora as ideias básicas que norteiam o desenvolvimento ágil já existam a muitos
anos, só a duas décadas que se consolidaram como um “movimento”. Dentre estes
métodos ágeis, existentes na literatura, vou abordar aqui, de forma sucinta, somente
duas delas:
Modelo eXtreming Programming (XP): Representa uma metodologia ágil de
desenvolvimento de software voltada para times de pequeno a médio porte,
no qual os requisitos são vagos e mudam frequentemente. Desenvolvido por
Kent Beck, Ward Cunningham e Ron Jeffries. O XP tem como principal tarefa a
codi�cação com ênfase menor nos processos formais de desenvolvimento e
com uma maior disciplina de engenharia ágil de software para codi�cação e
testes. Tem como valores a comunicação, a simplicidade, o feedback, a
coragem e o respeito. O XP valoriza a automatização de testes, sendo estes
criados antes, durante e depois da codi�cação. É �exível para a mudanças de
requisitos, valorizando o feedback com o usuário e a qualidade do código-fonte
�nal. A ideia principal do XP é a criação de software de alta qualidade, e
orientada explicitamente às pessoas. Seu método é melhor apresentado na
Figura 6 (WILDT, 2015); 
Modelo SCRUM: O nome provém de uma atividade que ocorre durante a
partida de 'rugby'. Este método foi criado por Jeff Sutherland e sua equipe de
desenvolvimento, conforme relato dele no início deste tópico. Os princípios do
Scrum são baseados no manifesto ágil e são usados para orientar as atividades
de desenvolvimento dentro de um processo que incorpora as seguintes
atividades estruturais: requisitos, análise, projeto, evolução e entrega. Em cada
atividade metodológica, ocorrem tarefas a realizar dentro de um padrão de
processo chamado sprint. O trabalho realizado dentro de um sprint é adaptado
ao problema em questão e de�nido, e muitas vezes modi�cado em tempo real,
pela equipe Scrum. O �uxo geral do processo Scrum é ilustrado na Figura 7
(PRESSMAN, 2011).
Figura 6 - Modelo Extreme Programming.
Planning/Feedback Loops
Release Plan
Code
Interation plan
Months
Weeks
Days
One day
Hours
Minutes
Seconds
Acceptance Test
Stand Up Meeting
Pair Negotiation
Pair programming
Unit Test
Fonte: Teles (2017)
Figura 7 - Modelo SCRUM.
SCRUM
feedback
Incremento
Potencialmente
Estragável
Product
Owner
Quadros
de tarefas
Objetivos
da sprint
Time Scrum
Sprint
( 1 - 4 semanas)
Product Backlog Objetivo da
Sprint
Ações de
melhoria
Sprint
Backlog
Planejamento da Sprint
Refinamento
ideias Clientes Mercado Inovações
Product
Backlog
Gestores CompetidoresResultados
Retrospectiva
Reunião diária
Scrum
Master
Time de
Desenvolvimento
Clientes, gestores, stakeholders...
Fonte: Adaptado de Sutherland (2016)
UML e orientação a objetos
AUTORIA
Ricardo Bortolo Vieira
A UML (Uni�ed Modeling Language ou Linguagem de Modelagem Uni�cada) é
uma linguagem grá�ca, utilizada para a elaboração da estrutura de projetos de
software. Constrói modelos concisos, precisos, completos e sem ambiguidades,
tendo, de maneira geral, as seguintes características, segundo Pereira (2011):
Modela os aspectos estruturais (estáticos) e comportamentais (dinâmicos) do
sistema. Em outras palavras, a UML provê elementos de notação para modelar
dados, funções de transformação dos dados e as restrições aplicáveis aos dados
e às funções;
Provê uma linguagem que permite o entendimento e a utilização por
humanos e a leitura por máquinas; 
Provê elementos de notação para modelar todos os tipos de sistemas de
computação;
Permite a modelagem do conceito ao artefato executável, utilizando técnicas
Orientadas a Objeto (OO);
A linguagem é extensível e adaptável a necessidades especí�cas; palavras-
chave permitem que se modi�que a semântica de elementos da linguagem;
Contempla as necessidades de produção de modelos pequenos e simples a
grandes e complexos;
Modela processos manuais ou automatizados, estes independentemente da
tecnologia que usam;
É uma linguagem para visualização do modelo, facilitando o entendimento
pelas equipes de análise de negócio, desenvolvimento de sistemas e pelos
clientes;
Serve para construir código de computador, embora não seja uma linguagem
de programação de computadores;
Está em evolução, mesmo após mais de dez anos da publicação da versão
inicial.
De acordo com Guedes (2011), a UML é uma linguagem de modelagem e é
independente de processo de software, podendo ser utilizada em modelo cascata,
desenvolvimento evolucionário, ou qualquer outro processo que esteja sendo
utilizado para o desenvolvimento de software.
Esta linguagem utiliza diversos símbolos grá�cos, e possui uma semântica bem
de�nida para cada um deles, sendo possível elaborar diversos modelos. A UML tem
sido empregada de maneira efetiva em sistemas cujos domínios abrangem:
sistemas de informações corporativos, serviços bancários e �nanceiros, transportes,
serviços distribuídos baseados na Web entre outros. Porém, a UML, não se limita à
modelagem de software, podendo modelar sistemas como o �uxo de trabalho no
sistema legal, a estrutura e o comportamento de sistemas de saúde e o projeto de
hardware. 
Ela surgiu da junção de 3 grandes métodos: Método Booch de Grady Boock, Método
OMT (Object Modeling Technique) de Rumbaugh e do método OOSE (Object-
Oriented Software Engineering) de Jacobson. Esses eram, até meados da década de
1990, as três metodologias de modelagem orientada a objetos mais populares entre
os engenheiros de software (GUEDES, 2011).
A UML é baseada no paradigma de orientação a objetos (OO), que está ligado a nove
conceitos (JONES, 2001): 
Em sua última versão vigente, 2.5, a UML possui 14 diagramas vigentes apresentados
na Figura 8. 
1. Encapsulamento; 
2. Ocultação de informação e Implementações;
3. Retenção de Estado;
4. Identidade de Objeto;
5. Mensagens;
6. Classes;
7. Herança;
8. Polimor�smo; e 
9. Generalização.
Figura 8 - Organograma da UML 2.5.
Diagrama de
classes
Diagrama de
perfil
Diagrama de
sequência
Diagrama de
comunicação
Diagrama de
tempo
Diagrama de
implantação
Diagrama de
pacotes
Diagrama de
interação
Diagrama de
estruturas
compostas
Diagrama de
visão geral
de interação
Diagrama de
máquina de
estados
Diagrama de
componentes
Diagrama de
objetivos
Diagrama de
atividades
Diagrama de
casos de uso
Diagrama de
comportamentos
Diagrama de
estruturas
Diagrama
Fonte: Adaptado de Pereira (2011)
Ferramentas Case
AUTORIA
Ricardo Bortolo Vieira
Uma ferramenta CASE (Computer-Aided Software Engineering - Engenharia
de Software Auxiliada por Computador) é um software que, de alguma forma,
colabora na realização de uma ou mais atividades da engenharia de software.
Ou segundo Terry (1990, p. 349), “CASE designa um conjunto de ferramentas que
auxiliam um programador ou gestor de projetos durante uma ou mais fasesdo
processo de desenvolvimento de software, incluindo a manutenção”.
Outra de�nição, dada por Silva e Videira (2011, p. 326) é:
"Um conjunto de técnicas e ferramentas informáticas que auxiliam o
engenheiro de software no desenvolvimento de aplicações, com o
objetivo de diminuir o respectivo esforço e complexidade, de melhorar
o controle do projeto, de aplicar sistematicamente um processo
uniformizado e de automatizar algumas atividades e veri�cação da
consistência e qualidade do produto �nal e geração de artefatos." 
Para a modelagem de sistemas usando a UML, normalmente usamos as
ferramentas CASE, as mais conhecidas são descritas a seguir: 
Astah Community é um software para modelagem UML (Uni�ed Modeling
Language – Linguagem de Modelagem Uni�cada) com suporte a UML 2,
desenvolvido pela Change Vision, Inc e disponível para sistemas operacionais
Windows 64 bits. Anteriormente conhecido por JUDE, um acrônimo de Java and
UML Developers Environment (Ambiente para Desenvolvedores UML e Java). 
Astah Community disponibiliza para desenvolvimento, os diagramas de Classes,
Casos de Uso, Sequência, Comunicação, Máquina de Estados, Atividade,
Componentes, Implantação e Diagrama de Estrutura Composta. 
Rational Rose é uma ferramenta CASE, mais especi�camente, uma ferramenta UML
que auxilia nos processos de construção de um software pro�ssional. Hoje em dia
essa ferramenta tem um peso no mercado sendo usada por diversos pro�ssionais e
grandes empresas. Foi criada pela Rational que, posteriormente foi adquirida pela
IBM em 20 de fevereiro de 2003 e a ferramenta não é gratuita. Permite a
modelagem com os quatorze diagramas da UML. Permite também a construção de
modelos de Dados com possibilidade de exportação para construção da base de
dados ou realização de engenharia reversa de uma base de dados existente. Dá
suporte ao Visual Studio (pacote de programas para desenvolvimento de software
da Microsoft). Foi sucedido pelo IBM Rational Architect. 
Figura 9 - Logotipo do Software Astah Community
Fonte: ASTAH (2006)
Enterprise Architect é uma ferramenta paga com recursos de ponta e um rico
conjunto de recursos para ajudar a gerenciar informações e inovar no ambiente
complexo e exigente de hoje. Em conjunto com o UML 2.0 é possivel modelar,
projetar e construir um software ou projeto comercial. Ele suporta MDA (Model-
Driven Architecture) e geração de códigos em linguagem Java, C#, C++, VB.NET, VB,
Python e DLL (Dynamic-Link Library) para um movimento rápido da análise para o
projeto e construção. Além disso, é possível criar relatórios, gerenciar testes, recursos
e muito mais. Enterprise Architect suporta o ciclo de vida UML 2.0 com ótimos
recursos de fóruns de discussão, construção, execução de códigos, suporte a MOF
(Microsoft Operations Framework), WSDL (Web Services Description Language -
Linguagem de Descrição de Serviços Web) e XML (Extensible Markup Language).
Figura 10 - Logotipo do Software Rational Rose
Fonte: IBM (2001)
Figura 11 - Logotipo do Software Enterprise Architect
Fonte: SPARK (2000)
Visual Paradigm for UML é uma ferramenta CASE com várias opções de
modelagem com os diagramas da UML 2.0 e que também oferece suporte a
diagramas de requisitos SysML e a diagramas ER (Entidade Relacionamento). A
ferramenta possui um bom ambiente de trabalho, o que facilita a visualização e
manipulação do projeto de modelagem. É uma ferramenta comercial e também
oferece suporte a transformações especí�cas para códigos-fonte de algumas
linguagens de programação como, por exemplo, C++ e Java. 
Figura 12 - Logotipo do Software Visual Paradigm
Fonte: VISUAL-PARADIGM (2002)
SAIBA MAIS
Segundo Mellor (1994), na Guerra do Golfo, em 1991, um míssil Scud
passou pelo escudo antimísseis Patriot e atingiu um acampamento
militar próximo de Dhahran, na Arábia Saudita. Ao todo, morreram 28
soldados americanos e 98 �caram feridos. O software para o míssil
Patriot continha uma falha de contagem de tempo acumulativa. O
Patriot havia sido projetado para operar apenas por algumas horas por
vez, após o que o contador de tempo era reiniciado. Como resultado, a
falha jamais havia tido um efeito signi�cativo e, consequentemente,
não fora detectada. Na Guerra do Golfo, entretanto, a bateria de mísseis
Patriot em Dhahran �cou operando por mais de 100 horas
ininterruptas. Isso fez com que a discrepância de tempo acumulado se
tornasse su�cientemente grande para fazer com que o sistema se
tornasse impreciso. 
Durante a Guerra do Golfo, os Estados Unidos enviaram mísseis Patriot
a Israel para proteção contra mísseis Scud. As forças israelenses
detectaram o problema da contagem de tempo apenas após 8 horas e
relataram o problema imediatamente para o fabricante nos Estados
Unidos. O fabricante corrigiu a falha o mais rápido possível, porém,
tragicamente, o novo software chegou somente um dia depois de o
acampamento ter sido atingido pelo Scud (MELLOR, 1994). 
Esta é uma das várias situações relatadas pelo autor Peter Mellor em
seu artigo "computer-aided disaster" publicado em 1994. Peter é
professor na University of Northampton, em Londres. Este e muitos
outros relatos de tragédias com falhas de software nos mostram como
é importante investir tempo e dinheiro em engenharia de software para
minimizar estes impactos que as falhas de software trazem para as
operações das empresas e para nossas vidas.  
REFLITA
“As pessoas apostam seus empregos, seu conforto, sua segurança, sua
diversão, suas decisões e suas próprias vidas nos softwares de
computadores. Eles precisam estar certos”. 
Roger S. Pressman - Presidente da R. S. Pressman & Associates, Inc.,
uma consultoria especializada em treinamentos e métodos em
engenharia de software 
Nesta primeira unidade foram apresentados alguns conceitos básicos sobre
engenharia de software que serão utilizados no decorrer de todo o livro, por isso, é
muito importante que esses conceitos �quem bem claros para você.
A engenharia de software foi proposta para tentar levar a precisão da  engenharia
para o desenvolvimento de software, pois até aquela época, desenvolver um software
era algo que não podia ser mensurado, nem em relação ao custo, levando-se,
normalmente, muito mais tempo do que o previsto. E o que acontecia era que não se
tinha uma regra, uma sequência de atividades para o desenvolvimento. Você vai ver
nas próximas unidades que, para tentar solucionar esse problema, os estudiosos da
engenharia de software propuseram vários modelos de processos de software, sendo
que a empresa pode escolher o que melhor se adequa a ela. Isso tem ajudado muito
o desenvolvimento de software. Você vai perceber isso durante o estudo deste livro.
Não se preocupe, pois estaremos juntos nas próximas unidades. 
Até lá!      
Conclusão - Unidade 1
A "View of 20th and 21st Century Software Engineering" consiste de uma
visão do passado e do futuro da engenharia de software. É uma ótima
referência para traçar um paralelo entre a origem da engenharia de
software e como ela está se renovando e se adaptando a uma sociedade
que cada vez mais exige e�ciência dos software e além disso, se tornam
cada vez mais dependentes dos aplicativos e programas.   
ACESSAR
Livro
Filme
Leitura complementar
Acesse o link
https://www.researchgate.net/publication/221554200_A_view_of_20th_and_21st_century_software_engineering
Referências 
ASTAH (2006). Astah Community - Free UML Modeling tool I Astah.net.
http://astah.net/editions/community, <acessado em 18/07/2019> 
BAUER, F. L. (1971). Appendix SOFTWARE ENGINEERING. 
https://link.springer.com/content/pdf/bbm%3A978-3-540-37502-9%2Fl.pdf, <acessado 
em 12/07/2019>. 
GUEDES, G. T. A. UML: Uma abordagem prática. 2. ed.: Novatec, 2011. 
IBM (2001). Modelo Rational Rose. 
https://www.ibm.com/su pport/knowledgecenter/pt-
br/SS4J E2_ 7.5.5/com.i bm.xtools.sa m ple.rose.model.doc/topics/sa m ple_rose_i ntro.htm 1 
<acessado em 18/07/2019> 
MELLOR, Peter. CAD: computer-aided disaster. HIGH INTEGR SYST, v. l, n. 2, p.101-156, 
1994. 
PAGE-JONES, M. Fundamentosdo Desenho Orientado a Objeto com UML. São 
Paulo: Makron, 2001. 
PEREIRA, L. A. de M. Análise e Modelagem de Sistemas com UML. Rio de Janeiro, 
2011. 
POTTS, C. Software-Engineering Research Revisited. IEEE Software, v. 10, n. 5, p. 19-
28.1993. 
PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Porto 
Alegre: Me Graw Hill, 2011. 
SILVA, A.; VIDEIRA, C. UML Metodologias e Ferramentas CASE. Lisboa: Centro 
Atlântico, 2001 
SOMMERVILLE, 1. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011. 
SPARK Systems Pty Ltd. (2000). Enterprise Architect Downloads I Sparx Systems.
https://spa rxsystems.com/prod ucts/ea/down loads.htm 1 <acessado em 18/07 /2019> 
SUTHERLAND, Jeff. Scrum: a arte de fazer o dobro do trabalho na metade do 
tempo. Leya, 2016. 
TELES, Vinícius Manhães. Extreme Programming: Aprenda como encantar seus 
usuários desenvolvendo software com agilidade e alta qualidade. Novatec Editora, 
2017. 
TERRY, B. LOGEE, D. Terminology for Software Engineering and Computer-Aided 
Software Engineering. Software Engineering Notes, 1990. 
VISUAL-PARADIGM (2002). Ideal Modeling & Diagramming Tool for Agile Team 
Collaboration. https://www.visual-paradigm.com/ <acessado em 18/07/2019> 
WILDT, Daniel et ai. extreme Programming: Práticas para o dia a dia no 
desenvolvimento ágil de software. Editora Casa do Código, 2015. 
Unidade 2
Projetos de Software
AUTORIA
Ricardo Bortolo Vieira
Introdução
Olá Caro(a) aluno(a)! Neste capítulo meu objetivo é introduzir os conceitos de projeto
de software, proporcionando as seguintes discussões:
Decisões necessárias sobre a arquitetura de sis tema durante o processo de
projeto de arquitetura;
Os padrões de arquitetura, bem como as maneiras já experimentadas de
organizar as arquiteturas de siste ma, que podem ser reusadas em projetos de
sistemas;
Conhecerá os padrões de arquiteturas que muitas vezes são usados em
diferentes tipos de sistemas de aplicações, incluindo sistemas de
processamento de transações e os sistemas de processamento de linguagens;
Que a engenharia de software baseada em componen tes está preocupada
com o desenvolvimento dos componentes padronizados baseados em
modelos de componentes, além da composição destes em sistemas de
aplicações;
compreenderá o que se entende por um componente e um mo delo de
componente;
Que o projeto de interface busca identi�car objetos e ações em interfaces e
criar um layout de tela adaptado a essa necessidade. Este processo é baseado
em protótipo;
Que o desenvolvimento de software baseado em padrão de projetos é focado
em encontrar problemas e apresentar propostas a este tipo de problema
(solução). Assim, os padrões são apresentado conforme novos problemas são
encontrados durante o desenvolvimento e o levantamento da arquitetura do
sistema.
Além disso, será apresentado a importância de cada um destes projetos, bem como
os processos e artefatos necessários para o desenvolvimento destes projetos. 
Então vamos lá!  Bons estudos! 
Projeto de arquitetura de
software
AUTORIA
Ricardo Bortolo Vieira
Introdução (H1)
É um processo criativo no qual de�ne-se uma organização de um sistema para
satisfazer aos requisitos funcionais e não funcionais. Aspectos que in�uenciam a
arquitetura:
Tipo de sistema a ser desenvolvido;
Experiência do arquiteto de sistemas;
Requisitos especí�cos para o sistema.
O projeto de arquitetura está preocupado com a compreensão de como um sistema
deve ser organizado e com a estrutura geral desse sistema. No modelo do processo
de desenvolvimento de software, o projeto de arquitetura é o primeiro estágio no
processo de projeto de software. Este projeto é o elo crítico entre o projeto e a
engenharia de requisitos, pois identi�ca os principais componentes estruturais de
um sistema e os relacionamentos entre eles. Os produtos dessa fase do projeto de
arquitetura serão dois artefatos: o modelo de arquitetura, que descreve como o
sistema está organizado, e o conjunto de componentes de comunicação
(SOMMERVILLE, 2011). 
Para exempli�car a arquitetura que estou descrevendo aqui apresento a Figura 13
que mostra a arquitetura de repositório de uma determinada IDE (Integrated
Development Environment - Ambiente de Desenvolvimento Integrado) . Este tipo
de arquitetura é usada para sistemas com grandes volumes de dados a serem
armazenados ou em sistemas baseados em informação, pois quando algo é
adicionado ou removido do repositório uma ação ou tarefa pode ser realizada.
Figura 1 - Exemplo de arquitetura de um sistema de repositório de código fonte.
Tradutor
de projeto
Editores
UML
Geradores
de código
Gerador
de relatório
Repositório do projeto
Analisador 
de projeto
Editores
java
Editor
Python
Fonte: Adaptado de Sommerville, 2011.
Em geral, as arquiteturas de sistema são modeladas por meio de diagramas de
blocos simples, como na Figura 13. No diagrama, cada caixa representa um
componente. Caixas dentro de caixas indicam que o componente foi decomposto
em sub-componentes. As setas signi�cam que os dados e/ou sinais de controle são
passados de um componente a outro na direção das setas. 
Diagramas de bloco são uma forma adequada de, durante o processo de projeto,
descrever a arquitetura do sistema. Estes diagramas representam uma boa maneira
de apoiar a comunicação entre as pessoas envolvidas no processo. Em muitos
projetos, eles são a única documentação de arquitetura que existe. No entanto, se a
arquitetura de um sistema deve ser bem documen tada, é melhor usar uma notação
com semântica bem de�nida para a descrição de arquitetura.  
Visão da arquitetura
Os modelos de arquitetura de um sistema de software podem ser usados para focar
a discussão sobre os requisitos de software ou de projeto. Além disso, podem ser
usados para documentar um projeto para que este possa ser usado como base para
um projeto e uma implementação mais detalhados e para a futura evolução do
sistema. 
É impossível representar todas as informações relevantes sobre a arquitetura de um
sistema em um único mo delo de arquitetura, pois cada modelo mostra apenas uma
visão ou perspectiva do sistema. Pode mostrar como um sistema é decomposto em
módulos, como os processos de run-time interagem, ou as diferentes formas como
são distribuídos os componentes do sistema através de uma rede. Tudo isso é útil
em momentos diferentes, por tanto, para ambos, projeto e documentação,
geralmente é preciso apresentar múltiplas visões da arquitetura de software.
Existem 4 visões de arquitetura discutidas no livro de Sommerville (2011) e
conceitualmente mais aceitas como válidas. São elas:
1. A visão lógica, que mostra as abstrações fundamentais do sistema como
objetos ou classes de objetos. Nessa visão, deveria ser possível relacionar os
requisitos de sistema com as entidades.
2. A visão de processo, que mostra como, no tempo de execução, o sistema é
composto de processos interativos. Essa visão é útil para fazer julgamentos
sobre as características não funcionais do sistema, como desempenho e
disponibilidade.
3. A visão de desenvolvimento, que mostra como o software é decomposto para
o desenvolvimento, ou seja, apresenta a distribuição do software em
componentes que são implementados por um único desenvolvedor ou por
uma equipe de desenvolvimento. Essa visão é útil para gerentes de software e
programadores.
4. Uma visão física, que mostra o hardware do sistema e como os componentes
de software são distribuídos en tre os processadores. Essa visão é útil para os
engenheiros de sistemas que estão planejando uma implantação do sistema. 
Na prática, as visões conceituais são, quase sempre, desenvolvidas durante o
processo de projeto e são usadas para apoiar a tomada de decisões de arquitetura.
Elas são uma maneira de comunicar a essência de um sistema para os diferentes
stakeholders (as partes envolvidas no projeto). Durante o processo de projeto,
quando diferentes aspectos do sistema são discu tidos, outras visões também
podem ser desenvolvidas, mas não há necessidade de uma descriçãocompleta de
todas as perspectivas. Também pode ser possível associar os padrões de arquitetura,
com as diferentes visões de um sistema (SOMMERVILLE, 2011). 
Padrões de arquitetura 
Um padrão de arquitetura é uma descrição genérica de uma organização do
sistema:
Estrutura dos Padrões;
Nome;
Descrição;
Quando é usado;
Vantagens;
Desvantagem.
Iremos estudar 3 tipos de arquiteturas: MVC, Repositório e Cliente-Servidor 
MVC 
Repositório
Tabela 1 - O padrão modelo-visão-controle (MVC).
Nome Característica
Descrição
Acrônimo para Model View and Controller. Separa a
apresentação e a interação dos dados do sistema. O
sistema é estruturado em três componentes lógicos que
interagem entre si. O componente Modelo gerencia o
sistema de dados e as operações associadas a esses dados.
0 componente Visão de�ne e gerencia como os dados são
apresentados ao usuário. O componente Controlador
gerencia a interação do usuário (por exemplo, teclas,
cliques do mouse etc.) e passa essas interações para a
Visão e o Modelo. 
Quando é
usado
É usado quando existem várias maneiras de se visualizar e
interagir com dados. Também quando são desconhecidos
os futuros requisitos de interação e apresentação de
dados. 
Vantagens
Permite que os dados sejam alterados de forma
independente de sua representação, e vice-versa. Apoia a
apresentação dos mesmos dados de maneiras diferentes,
com as alterações feitas em uma representação
aparecendo em todas elas. 
Desvantagens
Quando o modelo de dados e as interações são simples,
pode envolver código adicional e complexidade de
código. 
Fonte: Sommerville (2011)
Cliente-Servidor 
Tabela 2 - O padrão Repositório.
Nome Característica
Descrição
Todos os dados em um sistema são gerenciados em um
repositório central, acessível a todos os componentes do
sistema. Os componentes não interagem diretamente,
apenas por meio do repositório. 
Quando é
usado
Você deve usar esse padrão quando tem um sistema no
qual grandes volumes de informações são gerados e
precisam ser armazenados por um longo tempo. Você
também pode usá-lo em sistemas dirigidos a dados, nos
quais a inclusão dos dados no repositório dispara uma
ação ou ferramenta. 
Vantagens
Os componentes podem ser independentes — eles não
precisam saber da existência de outros componentes. As
alterações feitas a um componente podem propagar-se
para todos os outros. Todos os dados podem ser
gerenciados de forma consistente (por exemplo, backups
feitos ao mesmo tempo), pois tudo está em um só lugar. 
Desvantagens
0 repositório é um ponto único de falha, assim, problemas
no repositório podem afetar todo o sistema. Pode haver
ine�ciências na organização de toda a comunicação
através do repositório. Distribuir o repositório através de
vários computadores pode ser difícil. 
Fonte: Sommerville (2011)
Tabela 3 - O padrão Cliente-Servidor.
Nome Característica
Descrição
Em uma arquitetura cliente-servidor, a funcionalidade do
sistema está organizada em serviços — cada serviço é
prestado por um servidor. Os clientes são os usuários
desses serviços e acessam os servidores para fazer uso
deles. 
Quando é
usado
é usado quando os dados em um banco de dados
compartilhado precisam ser acessados apartir de uma
série de locais. Como os servidores podem ser replicados,
também pode ser usado quando a carga em um sistema
é variável. 
Vantagens
A principal vantagem desse modelo é que os servidores
podem ser distribuídos através de uma rede. A
funcionalidade geral (por exemplo, um serviço de
impressão) pode estar disponível para todos os clientes e
não precisa ser implementada por todos os serviços. 
Desvantagens
Cada serviço é um ponto único de falhas suscetível a
ataques de negação de serviço ou de falha do servidor. O
desempenho, bem como o sistema, pode ser imprevisível
pois depende da rede. Pode haver problemas de
gerenciamento se os servidores forem propriedade de
diferentes organizações. 
Fonte: Sommerville (2011)
Projeto de componentes de
software
AUTORIA
Ricardo Bortolo Vieira
Caro(a) aluno(a), neste tópico, irei descrever uma abordagem sobre o reúso de
software baseado na composição de componentes reusáveis, padro nizados. E
segundo Sommerville (2011), muitos novos sistemas de negócios são desenvolvidos
pela con�gura ção de sistemas disponíveis no mercado. No entanto, quando uma
empresa não pode usar um "sistema de pratelei ra", porque eles não atendem a seus
requisitos, o software de que necessitam precisa ser especialmente desenvolvido.
Para o desenvolvimento de software customizado, a engenharia de software
baseada em componentes é uma forma e�caz, orientada ao reúso, de desenvolver
novos sistemas corporativos. 
Ainda segundo Sommerville (2011), a engenharia de software baseada em
componentes (CBSE, do inglês component-based software engineering) surgiu na
década de 1990 como uma abordagem para softwares de desenvolvimento de
sistemas com base no reúso de compo nentes de softwares. Sua criação foi motivada
pela frustração de projetistas, pois o desenvolvimento orientado a objetos não levou
a um amplo reúso, como se havia sugerido. As classes de objetos foram muito
detalhadas e especí�cas e muitas vezes precisavam ser associadas com uma
aplicação em tempo de compilação. Era preciso ter conhecimento detalhado das
classes para usá-las e isso geralmente signi�cava que era necessário ter o código-
fonte do componente, o que signi� cava que vender ou distribuir objetos como
componentes reusáveis individuais era praticamente impossível.
Os fundamentos da engenharia de software baseada em componentes, segundo
Sommerville (2011), são:
1. Os componentes independentes que são completamente especi�cados por
suas interfaces. Deve haver uma se paração clara entre a interface de
componente e sua implementação. Isso signi�ca que a implementação de um
componente pode ser substituída por outra, sem que se alterem outras partes
do sistema.
2. Os padrões de componentes que facilitam a integração destes. Essas normas
são incorporadas a um modelo de componentes. Eles de�nem, no mínimo,
como interfaces de componentes devem ser especi�cadas e como os
componentes se comunicam. Alguns modelos vão muito mais longe e
de�nem as interfaces que devem ser imple mentadas por todos os
componentes. Se os componentes estão em conformidade com os padrões,
sua operação é independente de sua linguagem de programação.
Componentes escritos em linguagens diferentes podem ser integrados ao
mesmo sistema.
3. O middleware que fornece suporte de software para a integração de
componentes. Para tornar independentes, os componentes distribuídos
trabalham juntos; você precisa de suporte de middleware que lide com as
comunicações de componentes. O middleware para suporte ao componente
lida, com e�ciência, com questões de nível inferior e permite que você se
concentre nos problemas relacionados com a aplicação. Além disso, o
middleware para su porte de componentes pode fornecer suporte para
alocação de recursos, gerenciamento de transações, proteção e concorrência.
4. Um processo de desenvolvimento que é voltado para a engenharia de software
baseada em componentes. Você precisa de um processo de desenvolvimento
que permita que os requisitos evoluam, dependendo da funcionalida de dos
componentes disponíveis. 
A CBSE apoia-se nos seguintes princípios de projeto na construção de softwares
compreensíveis e passíveis de manutenção:
1. Componentes são independentes, então eles não interferem na operação uns
dos outros. Detalhes de implemen tação são ocultados. Implementação dos
componentes pode ser alterada sem afetar o restante do sistema.
2. Os componentes comunicam-se por meio de interfaces bem de�nidas. Se
essas interfaces forem mantidas, um componente poderá ser substituído por
outro, que forneça funcionalidade adicional ou aumentada.
3. As infraestruturas dos componentes oferecem uma gama de serviços-padrão
que podem ser usados em sistemas de aplicações, o que reduz a quantidade
de códigos novos a serem desenvolvidos. 
Modelo de Componentes 
ParaSommerville (2011), a Tabela 4 mostra o que deve ser considerado como
característica para um componentes seguindo os preceitos da CBSE.
Tabela 4 - Característica de um componente.
Característica
do
componente
Descrição
Padronizado
A padronização de componentes signi�ca que um
componente usado em um processo CBSE precisa
obedecer a um modelo de componentes padrão. Esse
modelo pode de�nir as interfaces de componentes,
metadados de componente, documentação, composição
e implantação. 
Independente
Um componente deve ser independente, deve ser
possível compor e implantá-lo sem precisar usar outros
componentes especí�cos. Nessas situações, em que o
componente precisa dos serviços prestados
externamente, estes devem ser explicitamente de�nidos
em uma especi�cação de interface 'requires'. 
Passível de
composição
Para um componente ser composto, todas as interações
externas devem ter lugar por meio de interfaces
publicamente de�nidas. Além disso, ele deve
proporcionar acesso externo a informações sobre si
próprio, como seus métodos e atributos. 
Implantável
Para ser implantável, um componente dever ser
autocontido. Deve ser capaz de operar como uma
entidade autônoma em uma plataforma de componentes
que forneça uma implementação do modelo de
componentes, o que geralmente signi�ca que o
componente é binário e não tem como ser compilado
antes de ser implantado. Se um componete é implantado
como um serviço, ele não precisa ser implantado por um
usuário de um componente. Pelo contrário, é implantado
pelo prestador do serviço. 
Documentado
Os componentes devem ser completamente
documentados para que os potenciais usuários possam
decidir se satisfazem a suas necessidades. A sintaxe e,
idealmente, a semântica de todas as interfaces de
componentes devem ser especi�cadas. 
Fonte: Sommerville (2011)
Os componentes têm duas interfaces relacionadas, como mostrado na Figura 14.
Essas interface re�etem os serviços que o componente fornece e os serviços de que
o componente necessita para funcionar corretamente:
A interface 'provides' de�ne os serviços prestados pelo componente. Essa
interface, essencialmente, é uma API (Application Programming Interface -
Interface de Programação de Aplicativo) de componente. Ela de�ne os
métodos que podem ser chamados por um usuário do componente. 
A interface 'requires' especi�ca quais serviços devem ser fornecidos por outros
componentes no sistema se um componente deve funcionar corretamente. Se
eles não estiverem disponíveis, o componente não funcionará. Isso não
compromete a independência ou a capacidade de implantação de um
componente, pois a interface 'requires' não de�ne como esses serviços deverão
ser prestados.
Figura 14 - Interface de componentes.
Interface ‘requires’
Define os serviços
que são requeridos
e que deveriam ser
fornecidos por
outros componentes
Interface ‘provides’
Componentes
Define os serviços
que são providos pelo
componente para
outros componentes
Fonte: Sommerville (2011)
Os elementos básicos de um modelo ideal de componentes são apresentados na
Figura 15, em um diagrama que mostra os elementos de um modelo de
componentes e domo eles de�nem a utilização e a processo de implantação
(SOMMERVILLE, 2011).
1. Interfaces. Os componentes são de�nidos pela especi�cação de suas
interfaces. O modelo de componente especi�ca como as interfaces devem ser
de�nidas e os elementos, como nomes de operação, parâmetros e exceções,
que devem ser incluídos na de�nição de interface. O modelo também deve
especi�car a linguagem usada para de�nir as interfaces de componente.
Alguns modelos de componentes exigem interfaces especí �cas que devem ser
de�nidas por um componente. Esses modelos são usados para compor o
componente com a infraestrutura de modelo de componente, que fornece
serviços padronizados, como gerenciamento de proteção e transação.
2. Uso. Para que componentes sejam distribuídos e acessados remotamente, eles
precisam ter um nome exclu sivo ou identi�cador associado a eles. Isso deve ser
globalmente exclusivo — por exemplo, no EJB, um nome hierárquico é gerado
com a raiz baseada em um nome de domínio de Internet. Os serviços têm um
único URI (Uniform Resource Identi�er).
Figura 15 - Elementos básicos de um modelo de componentes.
Composição Convençãode nomes Customização
Modelos de componentes
Documentação
Definição
de interfaces
Interfaces
específicas
Interfaces Informaçõesde uso
Implantação
e uso
Acesso a
metadados
Suporte a
evoluçãoEmbalagem
Fonte: Sommerville (2011)
Processos CBSE
Os processos CBSE são processos de software que oferecem suporte a engenharia
de software baseada em componentes. Consideram as possibilidades de reúso e as
diferentes atividades do processo envolvidas no de senvolvimento e uso de
componentes reusáveis. A Figura 16 apresenta uma visão geral dos processos CBSE. 
Desenvolvimento para reúso. Esse processo está interessado no
desenvolvimento de componentes ou serviços que serão reusados em outras
aplicações. Esse processo geralmente envolve generalizar os componentes
exis tentes.
Desenvolvimento com reúso. Esse é o processo de desenvolvimento de novas
aplicações usando componentes e serviços existentes.
Esses processos têm objetivos diferentes e, portanto, incluem atividades diferentes.
No desenvolvimento por processo de reúso, o objetivo é produzir um ou mais
componentes reusáveis. Você conhece os com ponentes com os quais trabalhará,
além de ter acesso a seu código-fonte para generalizá-lo. Em desenvol vimento com
reúso, você não sabe quais componentes estão disponíveis, por isso você precisa
descobrir esses componentes e projetar seu sistema para fazer o uso mais e�ciente
deles. Você não pode ter acesso ao código-fonte do componente.
Na Figura 16, você pode ver que os processos básicos CBSE com e para reúso apoiam
os processos que estão preocupados com a aquisição de componente,
gerenciamento de componente e certi�cação de componente. 
Figura 16 - Processos CBSE.
CBSE
para reúso
Certificação
de componentes
Repositório
de componentes
myri
Aquisição de
componentes
CBSE
com reúso
Analista de domínio,
Projetista,
Implementador,
Mantenedor,
Analista de mercado.
Certificador
local ou externo
Bibliotecário
Fonte externa
Bibliotecário,
Vendedor,
Agente
Especificador,
projetista,
Integrador,
Mantenedor
PROCESSOS CBSE
Fonte: Sommerville (2011)
Projeto de interface de
usuário
AUTORIA
Ricardo Bortolo Vieira
Caro(a) aluno(a), neste capítulo, iremos discutir sobre a Interface com o Usuário e a
importância dela para os softwares e aplicativos da atualidade. 
Conforme PFLEIGER (2004), o tipo de projeto Interface de Usuário,  produz uma
parte fundamental de um software. Ele é a parte do sistema visível para o usuário,
através da qual, ele se comunica para realizar suas tarefas. Pode se tornar uma fonte
de motivação e até, dependendo de suas características, uma grande ferramenta
para o usuário, ou então, se mal projetada, pode se transformar em um ponto
decisivo na rejeição de um sistema. 
As interfaces atuais têm como objetivo fornecer uma interação pessoa-computador
o mais "amigável" possível (pois na verdade não são). Dessa forma, ela deve ser fácil
de ser usada pelo usuário, fornecendo seqüências simples e consistentes de
interação, mostrando claramente as alternativas disponíveis a cada passo da
interação sem confundir nem deixar o usuário inseguro. Ela deve passar
despercebida para que o usuário possa se �xar somente no problema que deseja
resolver utilizando o sistema. 
Visando tornar a interação com o usuário mais natural e menos hostil, às interfaces
passaram a ser constituídas, entre outros itens, por elementos grá�cos, onde
imagens representando dados e tarefas disponíveis são manipuladas diretamente
pelo usuário. Na realidade, tais itens não constituem os dados nem as tarefas; são
apenas seus signos, isto é tudo que possa ser assumido como um substituto
signi�cante de outra coisa qualquer.
Segundo Mandel (1997) as três regras de ouro dos projetos de interface deusuário
são:
1. Deixar o usuário no comando;
2. Reduzir a carga de memória do usuário;
3. Tornar a interface consistente.
Essas regras formam, na verdade, a base para um conjunto de princípio para o
projeto de interface do usuário que orienta esse importante aspecto do projeto de
software. 
Usuário no Comando 
A maioria das restrições de interface impostas por um designer tem a intenção de
simpli�car o modo de interação. Mas para quem?
Como designer, você pode se sentir tentado a introduzir restrições e limitações para
simpli�car a implementação da interface. O resultado pode ser uma interface fácil
de construir, mas frustrante de usar. Mandel (1997) de�ne vários princípios de design
que permitem ao usuário manter este controle tão desejado:
De�na os modos de interação de uma maneira que não force o usuário a ações
desnecessárias ou indesejadas;
Providencie interação �exível. Como usuários diferentes têm diferentes
preferências de interação, as opções devem ser fornecidas;
Permitir que a interação do usuário seja interrompível e que possa ser desfeita;
Agilize a interação à medida que os níveis de habilidade avançam e permitem
que a interação seja personalizada;
Ocultar internos técnicos do usuário casual. A interface do usuário deve mover
o usuário para o mundo virtual do aplicativo; 
Design para interação direta com objetos que aparecem na tela.  
Reduzir a carga de memória do usuário 
Quanto mais um usuário tiver de se lembrar, mais sujeita a erros será a interação
com o sistema. É por essa razão que uma interface do usuário bem desenhada não
exaure a memória do usuário. Sempre que possível, o sistema deve "se lembrar” de
informações pertinentes e auxiliar o usuário em um cenário de interação que o
ajude a recordar-se. Mandel (1997) de�ne princípios de projeto que possibilitam a
uma interface reduzir a carga de memória do usuário:
Reduza a demanda de memória recente;
Estabeleça defaults signi�cativos;
De�na atalhos intuitivos;
O layout visual da interface deve se basear na metáfora do mundo real;
Revele as informações de maneira progressiva. A interface deve ser organizada
hierarquicamente. 
Tornar a interface consistente
A interface deve apresentar e obter informações de forma consistente. Isso implica: 
1. Todas as informações visuais são organizadas de acordo com regras de projeto
mantidas ao longo de todas as exibições de telas; 
2. Mecanismos de entrada são restritos a um conjunto limitado que é usado de
forma consistente por toda a aplicação;
3. Mecanismos de navegação para passar de uma tarefa a outra são de�nidos e
implementados de maneira consistente. 
Mandel (1997) de�ne um conjunto de princípios de projeto que ajudam a tornar a
interface consistente:
Permita ao usuário inserir a tarefa atual em um contexto signi�cativo. Muitas
interfaces implementam camadas de interações complexas com dezenas de
imagens de tela;
Mantenha a consistência ao longo de uma família de aplicações;
Se modelos interativos anteriores tiverem criado expectativa nos usuários, não
faça alterações a menos que haja uma forte razão para isso.
Padrões de projeto
AUTORIA
Ricardo Bortolo Vieira
Caro(a) aluno(a), neste capítulo, trataremos de padrões de projeto. Este assunto 
trata sobre soluções gerais para um problema que ocorre com frequência dentro do
contexto de projetos de software.
Segundo Pressman (2011), O projeto baseado em padrões cria uma nova aplicação
através da busca de um conjunto de soluções comprovadas para um conjunto de
problemas claramente delineados. Cada problema é descrito por um padrão de
projeto que foi catalogado e investigado por outros engenheiros de software que
depararam com o problema e implementaram a solução ao projetarem outras
aplicações. Cada padrão de projeto nos oferece uma abordagem comprovada para
parte do problema a ser resolvido. 
Ainda segundo Pressman (2011), um engenheiro de software examina cada
problema que surge para uma nova aplicação e tenta encontrar uma solução
relevante por meio de pesquisa em um ou mais repositórios de padrões. Ao usarmos
padrões de projeto, podemos encontrar uma solução comprovada para um
problema especí�co. À medida que cada padrão é aplicado, são integradas soluções,
e a aplicação a ser construída se aproxima cada vez mais de um projeto completo.
Os melhores projetistas, de qualquer área, têm uma habilidade excepcional de
visualizar padrões que caracterizam um problema e padrões correspondentes que
podem ser combinados para criar a solução. 
Embora o projeto baseado em padrões seja relativamente novo no campo de
desenvolvimento de software, a tecnologia industrial tem usado projeto baseado em
padrões há décadas, talvez há séculos. Catálogos de mecanismos e con�gurações
padronizadas fornecem elementos de projeto que são usados para criar automóveis,
aeronaves, máquinas-ferramenta e robôs. A aplicação de projeto baseado em
padrões ao desenvolvimento de software promete os mesmos benefícios para o
software como os já proporcionados à tecnologia industrial: previsibilidade, redução
de riscos e maior produtividade. 
Contexto do projeto baseado em padrões 
Ao longo do processo de projeto, e segundo Pressman (2011), devemos buscar toda
oportunidade de aplicar padrões de projeto existentes em vez de criar novos.
O projeto baseado em padrões não é utilizado isoladamente. Os conceitos e as
técnicas discutidas para projeto da arquitetura, de componentes e para interfaces
do usuário são usados em conjunto com uma abordagem baseada em padrões. O
conjunto de diretrizes e atributos de qualidade serve como base para todas as
decisões de projeto de software. As próprias decisões são in�uenciadas por um
conjunto de conceitos de projeto fundamentais que são atingidos usando-se
heurística que evoluiu ao longo de várias décadas e práticas melhores propostas
para fazer com que o projeto seja mais fácil de ser realizado e mais efetivo como
base para a construção (PRESSMAN, 2011).
O papel do projeto baseado em padrões está ilustrado na Figura 17. Um projetista de
software inicia com um modelo de requisitos que apresenta uma representação
abstrata do sistema. O modelo de requisitos descreve o conjunto de problemas,
estabelece o contexto e identi�ca o sistema de forças que exerce domínio. Talvez
sugira o projeto de maneira abstrata, mas o modelo de requisitos faz pouco para
representar o projeto explicitamente.
Ao iniciar seu trabalho como projetista, é sempre importante manter os atributos de
qualidade como foco principal. Esses atributos estabelecem uma maneira de avaliar
a qualidade do software, mas pouco fazem para ajudar a atingi-lo efetivamente. 
Figura 17 - Contexto do projeto baseado em padrões.
Modelo de
requisitos
Considerar
conceitos
de projeto
Iniciar tarefas de
projeto baseado
em padrões
Modelo de
projeto
Aplicar outros
métodos e
notações de
projeto
Extrair contexto
das forças e
do problema
Considerar
atributos
de qualidade
do projeto
Tratado pelo
padrão?
O projeto é iniciado
Sim Não
Fonte: Pressman (2011)
Consequentemente, devemos aplicar técnicas comprovadas para traduzir as
abstrações contidas no modelo de requisitos de maneira mais concreta que é o
projeto de software. Para tanto, usaremos os métodos e as ferramentas de
modelagem disponíveis para projeto da arquitetura, de componentes e para
interfaces. Mas apenas quando depararmos com um problema, um contexto e um
sistema de forças que ainda não foram resolvidos anteriormente. Se já existir uma
solução, devemos usá-la, e isso signi�ca aplicar uma abordagem de projeto baseado
em padrões. 
Padrões de Projeto de Arquitetura 
Conforme Pressman (2011), os padrões de arquitetura para software de�nem uma
abordagem especí�ca para tratar alguma característica do sistema e de�nem uma
série de domínios de padrões de arquitetura. Exemplos representativos são
apresentados por Pressman (2011):
Controle de acesso. Há várias situações em que o acesso a dados, recursos e
funcionalidade fornecidos por uma aplicação é limitado a usuários �nais
especi�camentede�nidos. Do ponto de vista da arquitetura, o acesso a alguma
parte da arquitetura de software deve ser rigorosamente controlado.
Concorrência. Muitas aplicações têm de tratar múltiplas tarefas em um modo que
simule paralelismo (isso ocorre sempre que vários componentes ou tarefas
“paralelas” são administradas por um único processador). Há uma série de maneiras
diferentes com a qual uma aplicação pode tratar a concorrência, e cada uma delas
pode ser apresentada por um padrão de arquitetura distinto. Por exemplo, uma
abordagem é usar um padrão Operating System Process Management (Sistema
Operacional de Gerenciamento de processos) que fornece recursos embutidos no
sistema operacional que permitem aos componentes executarem de forma
concorrente. O padrão também incorpora funcionalidade que gerencia a
comunicação entre processos, agendamento e outras capacidades exigidas para
alcançar a concorrência. 
Distribuição. O problema da distribuição trata a maneira pela qual os sistemas ou
componentes nos sistemas se comunicam entre si em um ambiente distribuído.
São considerados dois subproblemas: (1) a maneira pela qual as entidades se
conectam entre si e (2) a natureza da comunicação que ocorre. O padrão de
arquitetura mais comum estabelecido para tratar o problema de distribuição é o
padrão Broker (agente). Um agente atua com um “intermediário” entre o
componente-cliente e o componente-servidor. O cliente envia uma mensagem ao
agente (contendo todas as informações apropriadas para a comunicação a ser
efetuada) e o agente completa a conexão.
Persistência. Os dados persistem se sobreviverem depois da execução do processo
que o criou. Os dados persistentes armazenados em um banco de dados ou arquivo
podem ser lidos ou modi�cados por outros processos posteriormente. Em
ambientes orientados a objetos, a ideia de um objeto persistente estende um pouco
mais o conceito de persistência. Os valores de todos os atributos do objeto, o estado
geral do objeto e outras informações complementares são armazenados para
recuperação e uso futuro. Em geral, usam-se dois padrões de arquitetura para obter
a persistência — o padrão Database Management System (sistema de
gerenciamento de bancos de dados), que aplica o recurso de armazenamento e
recuperação de um DBMS à arquitetura da aplicação, ou o padrão Application Level-
Persistence (persistência no nível de aplicação) que constrói recursos de persistência
na arquitetura da aplicação.
Antes que qualquer um dos padrões de arquitetura citados anteriormente possa ser
escolhido, ele deve ser avaliado em termos de sua adequação para a aplicação e
estilo de arquitetura geral, bem como o contexto e o sistema de forças que ele
especi�ca. 
Padrões de Projeto de Componentes 
Ainda conforme Pressman (2011), os padrões de projeto de componentes nos dão
soluções comprovadas que tratam um ou mais subproblemas extraídos do modelo
de requisitos. Em muitos casos, os padrões de projeto desse tipo se concentram em
algum elemento funcional de um sistema. Por exemplo, em uma aplicação web
temos o seguinte subproblema de projeto: Como podemos obter especi�cações de
um determinado produto e suas informações relacionadas para um site de vendas?
Tendo enunciado o subproblema que deve ser resolvido, devemos considerar agora
o contexto e o sistema de forças que afetam uma solução. Assim, podemos perceber
que a solução para o subproblema envolve uma pesquisa. Como pesquisar é um
problema muito comum, não deve ser nenhuma surpresa a existência de muitos
padrões relacionados à pesquisa. Pressman (2011) apresenta alguns destes padrões: 
AdvancedSearch. Os usuários precisam encontrar um item especí�co em um
grande conjunto de itens.
HelpWizard. Os usuários precisam de ajuda sobre certo tópico relativo ao site
ou quando eles precisam encontrar uma página especí�ca dentro deste site.
SearchArea. Os usuários precisam encontrar uma página Web.
SearchTips. Os usuários precisam saber como controlar o mecanismo de
busca.
SearchResults. Os usuários têm de processar uma lista de resultados de uma
busca.
SearchBox. Os usuários têm de encontrar um item ou informações especí�cas.
Padrões de Projeto de Interface de Usuário 
Foram propostas centenas de padrões para interfaces do usuário nos últimos anos.
A maior parte deles cai em uma das seguintes categorias de padrões apresentados
a seguir. Toda a Interface com o Usuário fornece orientação para estrutura de alto
nível e navegação por toda a interface. Pressman (2011) apresenta algumas
categorias de padrões na Tabela 5. 
Tabela 5 - Tipos de Padrões de Projeto de Interface de Usuário.
Padrão Descrição Detalhes
TopLevelNavigation
Usada quando um
site ou uma aplicação
implementa uma
série de funções
principais. Oferece
um menu de alto
nível, geralmente
acoplado a um logo
ou imagem
identi�cadora, que
possibilita a
navegação direta
para qualquer uma
das principais
funções do sistema.
Funções principais (em
geral limitadas a quatro a
sete nomes de função)
são listadas na parte
superior da tela (possível
também formatos de
colunas verticais) em uma
linha horizontal de texto.
Cada nome fornece um
link para uma fonte de
informações ou função
apropriada. Geralmente,
usada com o padrão
BreadCrumbs discutido
mais à frente.
CardStack
Usado quando uma
série de subfunções
ou categorias de
conteúdo especí�cas
relacionadas com um
recurso ou função
deve ser selecionada
em ordem aleatória.
Dá a aparência de
uma pilha de �chas
indexadoras, cada
uma delas
selecionável com um
clique de mouse e
cada qual
representando
subfunções ou
categorias de
conteúdo especí�cas.
As �chas indexadoras são
uma metáfora bem
compreendida e fácil para
o usuário manipular. Cada
�cha indexadora
(separador) pode ter um
formato ligeiramente
diverso. Alguns poderão
exigir entrada de dados e
possuir botões ou outros
mecanismos de
navegação. Poderiam ser
combinados com outros
padrões como
DropDownList e Fill-in-
the-Blanks.
Fill-in-the-Blanks Possibilita que dados
alfanuméricos sejam
introduzidos em uma
“caixa de texto.”
Os dados poderiam ser
introduzidos em uma
caixa de texto e são
validados e processados
após a seleção de algum
indicador de texto ou
grá�co (por exemplo, um
botão contendo “avançar”,
“submeter”, “próximo”).
Em muitos casos, esse
padrão pode ser
“combinado com uma
lista suspensa ou outros
padrões (por exemplo,
SEARCH <drop down list>
FOR <�ll-in-the-blanks
text box>).
SortableTable
Mostra uma longa
lista de registros que
podem ser ordenados
através da seleção de
um mecanismo
comutador para
qualquer rótulo de
coluna.
Cada linha da tabela
representa um registro
completo. Cada coluna
representa um campo no
registro. Cada título de
coluna é um botão
selecionável que pode ser
comutado para iniciar
uma ordem crescente ou
decrescente para todos os
registros exibidos. Em
geral a tabela é
redimensionável e poderá
ter um mecanismo de
rolagem caso o número
de registros seja maior
que o espaço de janela
disponível.
BreadCrumbs
Fornece um caminho
de navegação
completo quando o
usuário está
trabalhando com
uma hierarquia de
páginas ou telas
complexa.
É atribuído um
identi�cador exclusivo a
cada página ou tela. O
caminho de navegação
para O local atual é
especi�cado em um local
prede�nido para qualquer
tela. O caminho assume a
forma: homepage>página
de tópico
principal>página de
subtópico>página
especí�ca>página atual.
EditinPlace Fornece um recurso
de edição simples
para certos tipos de
conteúdo no local em
que é exibido.
O usuário vê o conteúdo
na tela que deve ser
alterado. Um clique duplo
com o mouse sobre o
conteúdo indica ao
Uma discussão completa para interfaces do usuário vai além do escopo deste livro,
assim, recomendo os seguintes livros para mais informações: Borchers (2001) e
Duyne (2002). 
Nenhuma
necessidade de o
usuário introduzir
explicitamente uma
função ou modo de
edição de texto.
sistema que se deseja
editar. O conteúdo é
realçado para signi�car
que o modo de edição
está disponível e o usuário
faz as mudanças
apropriadas.
SimpleScarch
Oferece a capacidadede pesquisar em um
site ou fonte de
dados persistentes
para um dado
simples descrito em
uma string
alfanumérica.
Oferece a capacidade de
pesquisar local ou
globalmente no site. Gera
uma lista de “acertos” em
ordem de probabilidade
para atender às
necessidades do usuário.
Não oferece buscas de
itens múltiplos ou
operações booleanas
especiais.
Wizard
Conduz o usuário,
passo a passo, através
de uma tarefa
complexa, dando
orientação para a
�nalização da tarefa
por meio de uma
série de telas de
janelas simples.
O exemplo clássico é um
processo de registro em
quatro etapas. O padrão
Wizard gera uma janela
para cada etapa,
solicitando informações
especí�cas do usuário,
para cada uma das
etapas.
ShoppingCart
Fornece uma lista de
itens selecionados
para compra.
Lista informações de itens,
quantidade, código de
produto, preço, frete e
regras de entrega.
Também oferece a
funcionalidade de alterar
o item da lista, removendo
e alterando a quantidade
ou os dados de entrega.
Fonte: Pressman (2011)
SAIBA MAIS
Um bom software, segundo Sommerville (2011), tem quatro atributos
essenciais:
Manutenibilidade: o software precisa ser feito de maneira que
possa evoluir para atender as necessidades dos clientes.
Con�ança e Proteção: inclui características como con�abilidade,
proteção e segurança. Um software con�ável não deve causar
prejuízos físicos nem econômicos em caso de falha do sistema.
E�ciência: o software não deve desperdiçar os recursos do
sistema, como memória e capacidade do processador.
Aceitabilidade: o software deve ser aceitável para o tipo de
usuário o qual foi projetado. Por isso, deve ser compreensível,
usável e compatível
REFLITA
“Toda vez que pensar ‘não temos tempo para a engenharia de software’,
pergunte para si mesmo, ‘teremos tempo para fazer de novo?’”
Roger S. Pressman – Presidente da R. S. Pressman & Associates, Inc.,
uma consultoria especializada em treinamentos e métodos em
engenharia de software. 
Como podemos constatar, os projetos são a estrutura básica do desenvolvimento do
projeto. Ele estrutura o desenvolvimento, guia os testes e alinha a visão do usuário e
do proprietário do software com toda a cadeia de desenvolvimento e manutenção do
software. Ainda nesta unidade discutimos e estudamos sobre outros projetos:
O projeto de arquitetura é uma descrição de como um sistema de software é
organizado. As propriedades de um sistema, como desempenho, proteção e
disponibilidade, são in�uenciadas pela arquitetura adotada. As decisões de projeto de
arquitetura incluem decisões sobre o tipo de aplicação, a distribuição do sistema, os
estilos da arquitetura a serem utilizados e as formas como a arquitetura deve ser
documentada e avaliada. 
O projeto de interface do usuário é discutivelmente o elemento mais importante de
um produto ou sistema computacional. Se a interface for mal projetada, a capacidade
de o usuário aproveitar todo o poder computacional e conteúdo de informações de
uma aplicação pode ser seriamente afetada. Na realidade, uma interface fraca pode
fazer com que uma aplicação, em outros aspectos bem projetada e solidamente
implementada, falhe.
Três importantes princípios orientam o projeto de interfaces do usuário e�cazes: (1)
deixar o usuário no comando, (2) reduzir a carga de memória do usuário e (3) tornar a
interface consistente. Para alcançar uma interface que observe esses princípios, deve
ser realizado um processo de projeto organizado.
O projeto de componentes abrange uma sequência de atividades que reduz
lentamente o nível de abstração com o qual um software é representado. Em última
instância, o projeto de componentes representa o software em um nível de abstração
próximo do código. 
Os padrões de projeto fornecem um mecanismo codi�cado para descrever
problemas e suas soluções de maneira que permita à comunidade da engenharia de
software capturar conhecimento de projeto para que possa ser reutilizado. Um
padrão descreve um problema, indica o contexto, permitindo ao usuário
Conclusão - Unidade 2
compreender o ambiente em que o problema reside e listar um sistema de forças
que indicam como o problema pode ser interpretado no seu contexto e como uma
solução pode ser aplicada. No trabalho de engenharia de software, identi�camos e
documentamos padrões generativos que descrevem um aspecto importante e
repetível de um sistema, dando-nos então uma forma de construir esse aspecto em
um sistema de forças que seja único a um dado contexto.
Na próxima unidade falaremos sobre Qualidade de Software e todos os processos e
técnicas que envolvem essa importante e polêmica etapa do desenvolvimento.
Aguardo vocês lá!!! 
Grande Abraço e até a próxima unidade! 
Livro
Filme
Acesse o link
https://www.youtube.com/watch?v=J-lHpiu-Twk
Unidade 3
Qualidade e Técnicas de
Revisão
AUTORIA
Ricardo Bortolo Vieira
Introdução
Olá Caro(a) aluno(a)! Neste capítulo meu objetivo é introduzir os conceitos de
qualidade de software, tratando sobre:
O processo de gerenciamento de qualidade e o por que o planejamento de
qualidade é importante;
A importância dos padrões no processo de geren ciamento de qualidade e
saberá como os padrões são usados a �m de garantir a qualidade;
Maneiras como as revisões e inspeções são usadas como mecanismo de
garantia de qualidade de software;
Medição de software e como ela pode ser útil na avalia ção de atributos de
qualidade de software; 
Estágios de teste durante o desenvolvimento para os testes de aceitação por
parte dos usuários de sistema;
Compreender o desenvolvimento test-�rst, em que você projeta testes antes
de escrever o código e os executa automaticamente;
Conhecer as diferenças importantes entre teste de componentes, de sistemas
e de release, e téc nicas de teste de usuário. 
Conceito de Qualidade
AUTORIA
Ricardo Bortolo Vieira
No desenvolvimento de software, a qualidade de um projeto engloba o grau de
atendimento às funções e características especi�cadas no modelo de requisitos. A
qualidade de conformidade focaliza o grau em que a implementação segue o
projeto e o sistema resultante atende suas necessidades e as metas de
desempenho. Mas estas são as únicas questões que o engenheiro de software deve
considerar? (PRESSMAN, 2011)
Conforme Sommerville (2011), os fundamentos do gerenciamento de qualidade
foram estabelecidos pela indústria manufatureira em um es forço para melhorar a
qualidade dos produtos em produção. Como parte disso, eles desenvolveram uma
de�nição de "qualidade" (bem especí�ca para o ambiente de manufatura e não
adequado aos padrões atuais de engenharia de software), baseada na conformidade
com uma especi�cação detalhada e na noção de tolerân cias. Normalmente, os
produtos não cumprem todas as especi�cações, então admiti-se alguma tolerância
sendo classi�cado como aceitável. 
A qualidade de software não é diretamente comparável à qualidade na manufatura.
A ideia de tolerâncias não é aplicável aos sistemas digitais e, pelas razões
apresentadas a seguir, pode ser impossível concluir objetivamente se um sistema de
software cumpre ou não suas especi�cações (SOMMERVILLE, 2011):
Como existe uma grande di�culdade em escrever especi�cações de software
completas e precisas, os clientes e desenvolvedores de software podem
interpretar os requisitos de maneiras diferentes e pode ser impossível chegar a
um acordo sobre se o software cumpre ou não suas especi�cações.
Geralmente, as especi�cações integram requisitos de várias classes de
stakeholders. Esses requisitos são, inevita velmente, um compromisso e podem
não incluir os requisitos de todos os grupos de stakeholders.
É impossível medir determinadas características de qualidade diretamente,
assim, elas não podem ser especi�cadas de forma não ambígua.
Ainda conforme Sommerville (2011), Devido a esses problemas, a avaliação da
qualidade de software é um processo subjetivo, em que a equipe de gerenciamento
de qualidade precisa usar seu julgamento para decidir se foi alcançado um nível
aceitável de qualidade. Trata-se de responder a algumas perguntas sobreas
características do sistema:
1. Durante o processo de desenvolvimento os padrões de programação e
documentação foram seguidos? 
2. O software foi devidamente testado?
3. O software é su�cientemente con�ável para ser colocado em uso?
4. Software é compreensível e útil?
Portanto, entende-se que a qualidade de software não implica apenas se a
funcionalidade de software foi cor retamente implementada, mas também depende
dos atributos não funcionais do sistema. Sommerville (2011), apresenta 15 atributos
que de�nem a qualidade de um software. Esses atributos estão descritos na Tabela
6. 
Um processo de fabricação envolve con�gurar e operar as máquinas envolvidas no
processo. Uma vez que as máquinas estão funcionando corretamente, a qualidade
de produto segue normalmente. Você mede a qualidade do produto e altera o
processo até atingir o nível de qualidade requerida. A Figura 18, retirada do livro de
Sommerville (2011), ilustra essa abordagem baseada em processos para atingir a
qualidade esperada do produto.
Figura 18 - Qualidade baseada em processos.
Definir processo
Melhorar
processo
Não Sim Padronizar
processo
Qualidade
OK
Desenvolver
produto
Avaliar qualidade
de produto
Fonte: Sommerville (2011)
Dessa forma, Sommerville (2011) discute que existe uma clara ligação entre a
qualidade de processo e de produto na manufatura porque o processo é
relativamente fácil de ser padronizado e monitorado. Uma vez que sistemas de
manufatura sejam calibrados, eles podem ser executados várias vezes para produzir
Tabela 6 - Atributos de qualidade de software.
Segurança Compreensibilidade Portabilidade
Proteção Testabilidade Usabilidade
Con�abilidade Adaptabilidade Reusabilidade
Resiliência Modularidade E�ciência
Robustez Complexidade Capacidade de aprendizado
Fonte: Sommerville (2011)
produtos de alta qualidade. No entanto, o software não é manu faturado, ele é criado.
No desenvolvimento de software a relação entre a qualidade de processo e de
produto é mais complexa e por isso a padronização do processo é importante para
auxiliar nesta tarefa. 
Padrões de Software 
Os padrões de software desempenham um papel muito importante no
gerenciamento da qualidade de software. Como já discutido, uma parte importante
da garantia de qualidade é a de�nição ou seleção de padrões que devem ser
aplicados no processo de desenvolvimento de software ou produtos de software.
Como parte desse processo, devem ser escolhidas ferramentas e métodos para
suportar o uso desses padrões. Os padrões de software são importantes por três
razões, conforme descrito por Sommerville (2011):
1. Capturam sabedoria, que é valiosa para a organização. Eles são baseados em
conhecimentos sobre a prática do que é melhor ou mais adequado para a
empresa. 
2. Fornecem um framework para a de�nição do signi�cado de qualidade em
uma determinada organização. 
3. Ajudam a dar continuidade ao trabalho realizado por uma pessoa, quando
retomado e continuado por outra. 
Existem dois tipos de padrões de engenharia de software que podem ser de�nidos e
usados no gerenciamento de qualidade de software: 
1. Padrões de produto. Aplicam-se ao produto de software que está sendo
desenvolvido. Eles incluem padrões de documentos (para usuário �nal), padrões de
documentação (para os engenheiros de software) e padrões de codi�cação.
2. Padrões de processo. De�nem os processos que devem ser seguidos durante o
desenvolvimento de software. Eles devem encapsular as boas práticas de
desenvolvimento.
As equipes de gerenciamento de qualidade que estão desenvolvendo padrões para
uma empresa devem, em geral, basear seus padrões em padrões nacionais e
internacionais. Ao usar padrões internacionais como ponto de partida, a equipe de
garantia de qualidade deve elaborar um manual de padrões que de�nirá os padrões
necessários para sua organização. Exemplos de padrões que poderiam ser incluídos
nesse manual são mostrados na Tabela 5.  
Técnicas de Revisão
AUTORIA
Ricardo Bortolo Vieira
Conforme Pressman (2011), à medida que desenvolvemos o trabalho de engenharia
de software, cometemos erros, isso é aceitável, desde que sejamos capazes de criar
processos para detectar isso antes do usuário �nal. Assim, as revisões técnicas são o
mecanismo mais efetivo para encontrar estes erros. Dessa forma, os engenheiros de
software realizam as revisões técnicas, também chamadas revisões paritárias,
juntamente com seus colegas.
Ao se descobrir um erro logo no início do processo, �ca menos caro corrigi-lo. Além
disso, os erros podem aumentar à medida que o processo continua. Assim, as
revisões minimizam o tempo devido à redução do número de reformulações que
serão necessárias ao longo do projeto. A abordagem em relação às revisões irá variar
dependendo do grau de formalidade escolhido. Em geral, são empregadas seis
etapas, embora nem todas sejam usadas para todo tipo de revisão. São elas, o
planejamento, a preparação, a estruturação da reunião, as anotações de erros, a
realização das correções (feita fora da revisão) e a veri�cação se as correções foram
feitas apropriadamente. Para garantir que o trabalho foi realizado corretamente
deve-se escolher o tipo de revisão apropriado para o seu ambiente de
desenvolvimento (Pressman, 2011). 
Revisões Informais 
Como exemplos de revisões informais, Pressman (2011) cita: 
Teste de mesa de um artefato de engenharia de software; 
Reunião informal com a �nalidade de revisar um artefato;
 Revisões da programação em pares.
O Teste de mesa, pelo fato de não haver nenhum planejamento ou preparação
antecipada, tem sua e�cácia criticada pois não registra nenhum acompanhamento
sobre os erros encontrados. Porém, um simples teste de mesa pode realmente
encontrar erros que, de outra forma, poderiam se prolongar e aumentar o seu efeito
ao longo do processo de desenvolvimento.
Uma forma de aumentar a e�cácia de uma revisão do tipo teste de mesa é
desenvolver um conjunto de listas de veri�cação simples para cada artefato
produzido pela equipe de software. As questões levantadas na lista de veri�cação
são genéricas, mas servirão como guia para os revisores veri�carem o produto
resultante. Segue alguns exemplos destas questões: 
O layout é projetado usando convenções padronizadas? 
Da esquerda para a direita? De cima para baixo?
A apresentação precisa de barra de rolagem?
A cor e o posicionamento, o tipo e o tamanho dos elementos são usados
efetivamente?
Todas as opções de navegação ou funções representadas estão no mesmo
nível de abstração?
Todas as opções de navegação são claramente identi�cadas?
Quaisquer erros ou problemas veri�cados pelos revisores são registrados pelo
projetista para resolução futura. Poderiam ser programados testes de mesa de
forma ad hoc ou eles seriam compulsórios, como parte da boa prática de
engenharia de software. Em geral, a quantidade de material a ser revisada é
relativamente pequena e o tempo total gasto em um teste de mesa vai um pouco
além de uma ou duas horas. 
A programação em pares é uma técnica originada do método ágil “XP (eXtreme
Programming) e recomenda que duas pessoas trabalhem juntas em uma mesma
estação de trabalho para criar código. Isso disponibiliza um mecanismo para a
resolução de problemas em tempo real, pois um deles terá como foco a qualidade
do código. A programação em pares pode ser caracterizada como um teste de mesa
contínuo. O benefício é a descoberta imediata de erros e, consequentemente, o erro
não se propagará ao longo da cadeia de desenvolvimento.
Alguns engenheiros de software sustentam que a redundância inerente da
programação em pares é um desperdício de recursos. A�nal de contas, por que
alocar duas pessoas para um trabalho que uma única é capaz de realizar? O fato é
que a economia signi�cativa com a qualidade total justi�cam essa "redundância".
Revisões Formais 
Conforme Pressman (2011), Revisão Técnica Formal (RTF) é uma atividade de
controle da qualidade de software realizada por engenheiros de software e outros
pro�ssionais. Os objetivos de uma RTF são: 
Descobrirerros na função, lógica ou implementação para qualquer
representação do software; 
Veri�car se o software que está sendo revisado atende aos requisitos; 
Garantir que o software foi representado de acordo com padrões prede�nidos; 
Obter software que seja desenvolvido de maneira uniforme;  
Tornar os projetos mais gerenciáveis. 
A RTF permite promover conhecimento sobre o produto de software e reusabilidade
para o contínuo processo de teste, e uma classe de revisões que inclui passos
detalhados para um teste especí�co e inspeções. Cada RTF é realizada como uma
reunião e apenas será bem-sucedida se for apropriadamente planejada, controlada
e tiver a participação de todos os envolvidos.  
Uma reunião de revisão 
Independentemente do formato de RTF escolhido, cada reunião de revisão deve
observar os seguintes aspectos:
Devem estar envolvidas de três a cinco pessoas em uma revisão (tipicamente);
Deve ocorrer uma preparação antecipada;
A duração da reunião de revisão deve ser de menos de duas horas.
Assim, uma RTF se concentra em uma parte especí�ca (e pequena) do software. Por
exemplo, em vez de tentar revisar um projeto inteiro, os passos detalhados são
realizados para cada componente ou para um pequeno grupo de componentes. 
O foco da RTF é um artefato resultante, por exemplo, parte de um modelo de
requisitos, o projeto detalhado de um componente, o código-fonte de um
componente. O revisor deste artefato deve gastar de uma a duas horas revisando o
artefato, tomando notas e, de alguma forma, se familiarizando com o trabalho
realizado. 
Após este processo, uma reunião de revisão tem a participação de um líder de
revisão, todos os revisores e o produtor. Um dos revisores assume o papel de
registrador, isto é, o indivíduo que registra (por escrito) todas as questões
importantes surgidas durante a revisão. No �nal da revisão, todos os participantes da
RTF devem decidir se: 
1. Aceitam o artefato sem as modi�cações adicionais;
2. Rejeitam o artefato devido a erros graves (uma vez corrigidos, deve ser
realizada outra revisão); 
3. Aceitam o artefato provisoriamente (foram encontrados erros secundários que
devem ser corrigidos, mas não haverá nenhuma outra revisão).
Após uma tomada de decisão, todos os participantes da RTF assinam um
documento de aprovação, indicando sua participação na revisão e sua concordância
com as descobertas da equipe de revisão. 
Revisões por amostragem 
Em um ambiente ideal, todo artefato de engenharia de software deveria passar por
uma revisão técnica formal. No mundo real dos projetos de software, os recursos são
limitados e o tempo é escasso. Como consequência, as revisões são muitas vezes
esquecidas.
Pressman (2011), sugerem um processo de revisão por amostragem em que
amostras de todos os artefatos da engenharia de software sejam inspecionadas para
determinar quais são mais suscetíveis a erro. Recursos completos de RTF são, então,
direcionados apenas para os artefatos com maior probabilidade de ser suscetíveis a
erro.
Para ser e�caz, o processo de revisão por amostragem deve tentar quanti�car
aqueles produtos de trabalho que são alvos primários para as RTFs completas, Para
conseguir isso, são sugeridas as seguintes etapas:
1. Inspecionar uma fração a, de cada artefato de software resultante i Registrar o
número de falhas f, encontradas em a;
2. Desenvolver uma estimativa total do número de falhas contido no artefato i
multiplicando f por 1/a;
3. Classi�car os artefatos em ordem decrescente, de acordo com a estimativa
total do número de falhas contidas em cada um deles;
4. Concentrar recursos de revisão disponíveis naqueles artefatos que possuem o
maior número estimado de falhas.
Garantia da Qualidade de
Software
AUTORIA
Ricardo Bortolo Vieira
"A principal responsabilidade de uma pessoa do Software Quality Assurance (SQA) é
examinar e medir o processo de desenvolvimento de software atual e encontrar
maneiras de melhorá-lo com o objetivo de evitar que os erros ocorram." (PATTON,
2006, p. 520)
Ainda discute Patton (2006), se a de�nição de garantia da qualidade de software é
"uma garantia" ou "estar livre de dúvidas". Portanto, o papel de um grupo de SQA é
garantir, sem sombra de dúvidas, que o produto é de alta qualidade. Pode-se
perceber que esta atribuição não é muito agradável, se você participa de um grupo
de teste, você não quer assumir este título supostamente mais "prestigioso" e assim
permitir que um erro, de qualquer tipo, seja encontrado por um cliente e você falhe
no seu trabalho. 
Elementos de garantia da qualidade de
software 
Assim, segundo Pressman (2011), para buscar essa "garantia" discutida por Patton
(2006), precisamos estudar um amplo espectro de preocupações e atividades da
gestão da qualidade de software:
Padrões - o IEEE (Institute of Electrical and Electronic Engineers - Instituto de
Engenharia Elétrica e Eletrônica), a ISO (International Organization for
Standardization ou Organização Internacional para Padronização) e outras
organizações de padronização produziram uma gama enorme de documentação
que pode ser adotada voluntariamente pelas empresas de software e o papel de um
SQA é garantir que estes padrões adotados sejam seguidos. 
Revisões e auditorias. As revisões técnicas são uma atividade de controle de
qualidade realizada entre pro�ssionais do desenvolvimento e busca erros nos
artefatos. Auditorias são um tipo de revisão efetuado pelo pessoal de SQA com o
intuito de assegurar-se de que as diretrizes de qualidade estejam sendo seguidas no
trabalho de engenharia de software. 
Testes. Os testes de software são uma função de controle de qualidade com um
objetivo principal — descobrir erros. O papel da SQA é garantir que os testes sejam
planejados apropriadamente e conduzidos e�cientemente de modo que se tenha a
maior probabilidade possível de alcançar seu objetivo primário.
Coleta e análise de erros/defeitos. A única forma de melhorar é medir o nosso
desempenho. A SQA reúne e analisa dados de erros e defeitos para melhor
compreender como os erros são introduzidos e quais atividades de engenharia de
software podem reduzir estes números.
Gerenciamento de mudanças. As mudanças são um dos aspectos mais negativos
de qualquer projeto de software. Se não forem administradas apropriadamente,
podem gerar confusão, e confusão quase sempre leva a uma qualidade
inadequada. 
Educação. Toda organização de software quer melhorar suas práticas de engenharia
de software, Um fator fundamental para o aperfeiçoamento é a educação dos
pro�ssionais envolvidos no processo de software. 
Gerência dos fornecedores. Adquirem-se três categorias de fornecedores externos
de software — pacotes prontos (Microsoft Of�ce, Adobe Acrobat, etc), um shell
personalizado que fornece um conjunto básico de software conforme a
necessidade do comprador, e software sob encomenda que é projetado e
construído de forma personalizada a partir de especi�cações fornecidas pela
empresa-cliente. O papel do grupo de SQA é garantir software de alta qualidade por
meio da sugestão de práticas especí�cas de garantia da qualidade que o fornecedor
deve (sempre que possível) seguir.
Administração da segurança. Com o aumento dos ataques de hackers e novas
regulamentações governamentais referentes à privacidade, toda organização de
software deve instituir políticas que protejam os dados em todos os níveis. A SQA
garante o emprego de processos e tecnologias apropriadas para ter a segurança de
software desejada. 
Proteção. O fato de o software ser quase sempre um componente fundamental de
sistemas que envolvem vidas humanas, o impacto de defeitos ocultos pode ser
catastró�co. A SQA pode ser responsável por avaliar o impacto de falhas de software.
Além de cada uma dessas preocupações e atividades, a SQA trabalha para garantir
que atividades de suporte ao software sejam realizadas ou produzidas tendo a
qualidade como preocupação dominante. A prerrogativa do grupo de SQA é ajudar
a equipe de software a obter um produto �nal de alta qualidade. Essas ações,
apresentadaspor Pressman(2011), são realizadas (ou facilitadas) por um grupo de
SQA que:
Prepara um plano de SQA para um projeto. O plano é desenvolvido como parte do
planejamento de projeto e é revisado pelos engenheiros de software. Porém, as
ações de garantia da qualidade devem ser realizadas por toda a equipe como uma
ação de TQM (veremos com mais detalhes em tópico futuro).
Participa no desenvolvimento da descrição da gestão de qualidade do projeto. A
equipe de software seleciona um processo para o trabalho a ser realizado. O grupo
de SQA revisa a descrição de processos para conformidade com a política
organizacional
Revisa as atividades de engenharia de software para veri�car sua conformidade
com a gestão de qualidade de�nida. O grupo de SQA identi�ca, documenta e
acompanha desvios do processo e veri�ca se as correções foram feitas.
Garante que os desvios no trabalho de software e produtos resultantes sejam
documentados e tratados de acordo com um procedimento documentado.
Podem ser encontrados desvios no plano de projeto, na descrição do processo,
padrões aplicáveis ou no artefato da engenharia de software.
Registra qualquer não aderência e relata ao gerenciamento superior. Itens com
problemas (que não atendem às especi�cações) são acompanhados até que tais
problemas sejam resolvidos.
Além dessas ações, o grupo de SQA coordena o controle e o gerenciamento de
mudanças e ajuda a coletar e analisar métricas de software. As ações de SQA são
realizadas para atingir um conjunto de metas pragmáticas: 
Qualidade dos requisitos. A correção, a completude e a consistência do modelo de
requisitos terão forte in�uência sobre a qualidade de todos os produtos seguintes. A
SQA deve assegurar-se de que a equipe de software tenha revisto apropriadamente
o modelo de requisitos para a obtenção de um alto nível de qualidade.
Qualidade do projeto. Todo elemento do modelo de projeto deve ser avaliado pela
equipe de software para garantir que apresente alta qualidade e que o próprio
projeto esteja de acordo com os requisitos. A SQA busca atributos do projeto que
sejam indicadores de qualidade.
Qualidade do código. O código-fonte e os produtos relacionados (por exemplo,
outras informações descritivas) devem estar em conformidade com os padrões
locais de codi�cação e apresentar características que irão facilitar a manutenção. A
SQA deve isolar esses atributos que permitem uma análise razoável da qualidade do
código.
E�cácia do controle de qualidade. A equipe de software deve aplicar os recursos
limitados de forma a obter a maior probabilidade possível de atingir um resultado
de alta qualidade. A SQA analisa a alocação de recursos para revisões e realiza testes
para veri�car se eles estão ou não sendo alocados da maneira mais efetiva. 
Capability Maturity Model (CMMI)
Segundo Patton (2006), a integração do Modelo de Capacidade de Maturidade de 
Software (CMMI) é um modelo padrão do setor para de�nir e medir a maturidade do
processo de desenvolvimento de uma empresa de software e para fornecer
orientação sobre o que eles podem fazer para melhorar sua qualidade de software.
Foi desenvolvido pela comunidade de desenvolvimento de software juntamente
com o Software Engineering Institute (SEI) e a Carnegie Mellon University, sob a
direção do Departamento de Defesa dos EUA.
O que torna o CMMI especial é que ele é genérico e se aplica igualmente a empresas
de software de qualquer tamanho, desde a maior empresa de software do mundo
até uma consultoria de uma única pessoa. Seus cinco níveis, apresentados na Figura
9, fornecem um meio simples para avaliar a maturidade de desenvolvimento de
software de uma empresa e determinar as principais práticas que podem adotar
para passar para o próximo nível de maturidade. 
Figura 19 - Os 5 níveis de maturidade do CMMI.
Otimização5
4
3
2
1
Quantativamente
gerenciado
Definido
Foco continuo na
melhoria dos processos
Processos são medidos
e controlados
processos são caracterizados por
projeto e as ações são
frequentemente reativas
Processos são imprevisíveis,
pouco controlados e reativos
Processos são caracterizados
para organização e são proativos
Gerenciado
Inicial
Fonte: ISDBRASIL (2019)
Ao estudar a Figura 19, extraída do site ISD BRASIL (Integrated System Diagnostic
Brasil), pense no seguinte: Se você tomar todo o universo das empresas de software
hoje, a maioria está no Nível de Maturidade 1, muitos estão no Nível de Maturidade 2
e menos no Nível de Maturidade 3, um punhado está no nível de maturidade 4, e
uma elite de poucos estão no nível de maturidade 5. 
É importante perceber que não é papel do testador de software defender o avanço
de uma empresa na maturidade do desenvolvimento de software. Isso precisa ser
feito em nível corporativo, instituído de cima para baixo. Quando você inicia um
novo trabalho de teste, deve avaliar onde a empresa e sua nova equipe estão nos
diferentes níveis de maturidade. Saber em que nível eles operam, ou em que nível
eles estão se esforçando, o ajudará a de�nir suas expectativas e a entender melhor o
que eles esperam de você. 
ISO 9000 
Ainda buscando inspiração em Patton (2006), apresento outro conjunto popular de
padrões relacionados à qualidade de software que é a International Organization for
Standardization (ISO) 9000. A ISO é uma organização internacional que de�ne
padrões para tudo, desde porcas e parafusos até, no caso da ISO 9000,
gerenciamento de qualidade e garantia de qualidade.
Você pode ter ouvido falar da ISO 9000 ou notado em propagandas de produtos ou
serviços de uma empresa. Geralmente é um pequeno logotipo ou nota ao lado do
nome da empresa. É um grande negócio ter a certi�cação ISO 9000 e uma empresa
que a tenha alcançado quer tornar esse fato conhecido de seus clientes,
especialmente se seus concorrentes não são certi�cados.
A ISO 9000 é uma família de padrões em gerenciamento de qualidade e garantia de
qualidade que de�ne um conjunto básico de boas práticas que ajudarão uma
empresa a fornecer produtos (ou serviços) consistentes que atendam aos requisitos
de qualidade de seus clientes. Não importa se a empresa é uma o�cina ou está
fazendo software, ou entregando pizza. Boas práticas de gestão se aplicam
igualmente a todas elas. 
A ISO 9000 funciona bem pois tem como alvo o processo de desenvolvimento, não o
produto. Preocupa-se com a maneira como uma organização realiza seu trabalho,
não com os resultados do trabalho. Ele não tenta de�nir os níveis de qualidade dos
aplicativos que saem da linha de montagem ou do software no CD (Compact Disk).
Como você aprendeu, a qualidade é relativa e subjetiva. O objetivo de uma empresa
deve ser criar o nível de qualidade que seus clientes desejam. Ter um processo de
desenvolvimento de qualidade ajudará a conseguir isso.
A ISO 9000 determina apenas quais são os requisitos do processo e não como eles
devem ser alcançados. Realizar revisões de projeto é um bom exercício que uma
equipe de projeto responsável deve fazer (e é por isso que está na ISO 9000), mas
exatamente como a revisão de projeto deve ser organizada e executada depende da
equipe individual que cria o produto. A ISO 9000 diz o que fazer, mas não como fazê-
lo.
Gestão da Qualidade Total 
E novamente conforme Patton (2006), existe uma abordagem de qualidade
conhecida como Gerenciamento de Qualidade Total (Total Quality Management -
TQM) ou Controle Total de Qualidade (Total Qualit Control - TQC) cuja �loso�a básica
é questionar a existência  de um grupo de garantia de qualidade centralizado que
seja responsável pela qualidade. Estas abordagens indicam que não é viável porque
as pessoas que fazem o trabalho de escrever o código ou criar os aplicativos não são
responsáveis pela qualidade e, portanto, não tentarão alcançá-lo. Para criar produtos
de qualidade, uma cultura de qualidade precisa ser instituída a partir da base da
cadeia produtiva, para que todos compartilhem a responsabilidade pela qualidade.
Embora o TQM/TQC tenha grandes implicações para a missão de um grupo de
Garantia de Qualidade existente,ele não elimina a necessidade de testes de
software. Muito pelo contrário, a função de teste de software em tal ambiente é mais
claramente de�nida. Apesar dos melhores esforços de qualquer processo, o software
ainda é criado por pessoas e as pessoas cometem erros. Ainda há uma necessidade
de um grupo se concentrar em procurar por erros. Eles podem não encontrar
muitos, mas isso é uma coisa boa! 
Estratégias de Teste de
Software
AUTORIA
Ricardo Bortolo Vieira
Conforme Pressman (2011) estabelece muito bem, estratégia de teste de software
fornece um roteiro que descreve os passos a serem executados como parte do teste,
de�ne quando esses passos são planejados e então executados, e quanto trabalho,
tempo e recursos serão necessários. Portanto, qualquer estratégia de teste deve
incorporar planejamento dos testes, projeto de casos de teste, execução dos testes,
coleta e avaliação dos dados resultantes.
Uma estratégia de teste de software deve ser �exível o bastante para promover uma
abordagem de teste personalizada. Ao mesmo tempo, deve ser rígida o bastante
para estimular um planejamento razoável e o acompanhamento, à medida que o
projeto progride. 
Uma estratégia de teste de software deve acomodar testes de baixo nível,
necessários para veri�car se um pequeno segmento de código fonte foi
implementado corretamente, bem como testes de alto nível, que validam as
funções principais do sistema de acordo com os requisitos do cliente. Uma
estratégia deverá fornecer diretrizes para o pro�ssional e uma série de metas para o
gerente. Devido ao fato de os passos da estratégia de teste ocorrerem no instante
em que as pressões pelo prazo começam a aumentar, deve ser possível medir o
progresso no desenvolvimento e os problemas devem ser revelados o mais cedo
possível. Essa de�nição de estratégia de teste foi bem apresentada por Pressman
(2011). 
Test-Case Design 
Os testes, conforme Myers (2004), por mais criativos e aparentemente completos,
não podem garantir a ausência de todos os erros. O design de casos de teste é tão
importante porque testes completos são impossíveis. Em outras palavras, um teste
de qualquer programa deve ser necessariamente incompleto. A estratégia óbvia,
então, é tentar fazer testes tão completos quanto possível. Dadas as restrições de
tempo e custo, a questão-chave do teste torna-se: Qual subconjunto de todos os
possíveis casos de teste tem a maior probabilidade de detectar a maioria dos erros?
O estudo de metodologias de design de casos de teste, sugeridas por Myers (2004),
fornece respostas para esta questão.
Em geral, a metodologia menos e�caz de todos é o teste de entrada aleatória - o
processo de testar um programa selecionando, aleatoriamente, algum subconjunto
de todos os possíveis valores de entrada. Em termos da probabilidade de detectar a
maioria dos erros, uma coleção de casos de teste selecionada aleatoriamente tem
pouca chance de ser um subconjunto ótimo, ou até mesmo próximo do ideal.
Portanto, neste capítulo, queremos desenvolver um conjunto de processos de
pensamento que permita selecionar dados de teste de maneira mais inteligente.
Você pode desenvolver um teste razoavelmente bom usando determinadas
metodologias de design de caso de teste orientadas por caixa preta e, em seguida,
complementando esses casos de teste examinando a lógica do programa, usando
métodos de caixa branca. 
Teste de Caixa Branca 
O teste de caixa branca, discutida por Myers (2004), está relacionado com o grau em
que os casos de teste se exercitam ou cobrem a lógica (código-fonte) do programa.
O último teste de caixa branca é a execução de todos os caminhos do programa;
mas o teste completo do caminho não é uma meta realista para um programa com
loops.
Esta estratégia de teste permite examinar a estrutura interna do programa. White-
Box (Caixa Branca) deriva os dados de teste de um teste da lógica do programa. O
objetivo neste momento é fazer com que todas as declarações do programa sejam
executadas pelo menos uma vez pode parecer a resposta, mas não é difícil mostrar
que isso é altamente inadequado. 
Esta estratégia é geralmente considerada como um teste de caminho exaustivo. Ou
seja, se você executar, por meio de casos de teste, todos os caminhos possíveis do
�uxo de controle através do programa, possivelmente o programa foi
completamente testado. Existem duas falhas nesta declaração, no entanto. Uma é
que o número de caminhos lógicos únicos através de um programa pode ser
astronomicamente grande. 
Naturalmente, em programas reais, cada decisão não é independente de todas as
outras decisões, o que signi�ca que o número de possíveis caminhos de execução
seria um pouco menor. Por outro lado, os programas reais são muito maiores do que
os exemplos didáticos apresentados em livros de engenharia de software. Assim,
testes de caminho, como testes exaustivos de entrada, parecem ser impraticáveis, se
não impossíveis.
A segunda falha na declaração "teste exaustivo de caminho signi�ca um teste
completo" é que cada caminho em um programa pode ser testado, mas o programa
ainda pode estar carregado de erros. Existem três explicações para isso.
A primeira é que um teste de caminho exaustivo não garante de modo algum que
um programa corresponda à sua especi�cação. Por exemplo, se você fosse solicitado
a escrever uma rotina de classi�cação de ordem crescente, mas produzisse
erroneamente uma rotina de classi�cação de ordem decrescente, o teste de
caminho exaustivo seria de pouco valor; o programa ainda tem um bug: é o
programa errado, pois não atende a especi�cação.
Em segundo lugar, um programa pode estar incorreto devido a caminhos ausentes.
O teste do caminho exaustivo, é claro, não detectaria a ausência de caminhos
necessários. 
Terceiro, um teste de caminho exaustivo pode não revelar erros de sensibilidade aos
dados. Suponha que em um programa você tenha que comparar dois números para
convergência, isto é, para ver se a diferença entre os dois números é menor do que
algum valor predeterminado. Naturalmente, a instrução contém um erro porque
deve comparar c ao valor absoluto de a-b. A detecção desse erro, no entanto,
depende dos valores usados para a e b e não seria necessariamente detectada
apenas pela execução de todos os caminhos do programa. 
Teste de Caixa Preta 
Outra importante estratégia de teste é o teste de caixa preta (também conhecido
como teste orientado a dados ou baseado em entrada/saída). Para Myers (2004),
usar esse método, permite visualizar o programa como uma caixa preta. Seu
objetivo é estar completamente despreocupado com o comportamento interno e a
estrutura do programa. Em vez disso, concentre-se em encontrar circunstâncias em
que o programa não se comporte de acordo com suas especi�cações.
Nesta abordagem, os dados de teste são derivados apenas das especi�cações (ou
seja, sem tirar proveito do conhecimento da estrutura interna do programa).
Se você quiser usar essa abordagem para encontrar todos os erros no programa, o
critério é um teste de entrada exaustivo, fazendo uso de todas as condições de
entrada possíveis como um caso de teste. Por quê? Se você tentou três casos de
teste de triângulo equilátero para o programa de triângulo, isso não garante de
forma alguma a detecção correta de todos os triângulos equiláteros. Como o
programa é uma caixa preta, a única maneira de ter certeza de detectar a presença
de tal declaração é tentar todas as condições de entrada.
Para testar exaustivamente o programa do triângulo, você teria que criar casos de
teste para todos os triângulos válidos até o tamanho inteiro máximo da linguagem
de desenvolvimento. Isso em si é um número astronômico de casos de teste, mas
não é de forma alguma exaustivo. Para ter certeza de encontrar todos esses erros,
você deve testar usando não apenas todas as entradas válidas, mas todas as
entradas possíveis. Assim, para testar exaustivamente o programa do triângulo, você
teria que produzir virtualmente um número in�nito de casos de teste, o que, é claro,
não é possível.
Assim podemosdemonstrar que testes exaustivos de entrada são impossíveis.
Assim, duas implicações devem ser consideradas: 
1. Você não pode testar um programa para garantir que esteja livre de erros; 
2. Uma consideração fundamental no teste de programas é uma questão de
economia. 
Como os testes exaustivos estão fora de questão, o objetivo deve ser maximizar o
rendimento do investimento em testes maximizando o número de erros
encontrados por um número �nito de casos de teste. Fazer isso envolverá, entre
outras coisas, ser capaz de procurar dentro do programa e fazer certas suposições
razoáveis sobre o programa. 
SAIBA MAIS
Para apoiar os pro�ssionais da qualidade na gestão de seus processos e
problemas diários foram criados associações e organizações que criam,
discutem e organizam padrões e fontes de informação gerais e
especí�cas para a gestão de todo o processo da qualidade. Veja aqui os
sites que são um bom ponto de partida para ter acesso a essas
associações: 
American Society for Quality (ASQ) Software Division 
ACESSAR
Association for Computer Machinery 
ACESSAR
Data and Analysis Center for Software [DACS) 
ACESSAR
Software Engineering Institute 
ACESSAR
Testes de Software e Engenharia da Qualidade 
ACESSAR
Gestão da Qualidade Total (TQM, Total Quality Management) 
ACESSAR
http://www.%20asq.org/software
http://www.acm.org/
http://www.dacs.dric.mil/
http://www.sei.cmu.edu/
http://www.stickyminds.com/
http://www.gslis.utexas.edu/-rpollock/tqm.html
REFLITA
"As pessoas esquecem quão rápido um trabalho foi realizado - mas elas
sempre lembram quão bem ele foi realizado"
Howard Newton - Professor de Neurociência Computacional e
Neurocirurgia Funcional na Universidade de Oxford, onde dirige o
Laboratório de Neurociência Computacional de Oxford. 
O conceito de Qualidade de Software é um processo subjetivo, em que a equipe de
gerenciamento de qualidade precisa usar seu julgamento para decidir se foi
alcançado um nível aceitável de qualidade ou não, assim estes pro�ssionais tentam
responder a algumas perguntas como: (1) Durante o processo de desenvolvimento os
padrões de programação e documentação foram seguidos? (2) O software foi
devidamente testado? (3) Software é compreensível e útil? Entre outras discutidas no
tópico. Além disso, estudamos os 15 atributos da qualidade que podem ser usados
como guia para estabelecer grupos de testes para os sistemas tratados. Outro ponto
importante neste tópico fundamental é o estudo dos padrões de projeto, que
auxiliam muito na criação de estratégias para os testes.
A Técnica de Revisão é o processo pela qual buscamos rever o que foi desenvolvido
em busca de erros para serem corrigidos, pois cometemos erros, isso é aceitável,
desde que sejamos capazes de criar processos para detectar isso antes do usuário
�nal. Assim, as revisões técnicas são divididas em duas partes: as revisões formais e as
revisões informais. As formais possuem um grande formalismo e envolve um
processo descrito no tópico, já as revisões informais são muito pontuais e utilizadas
pelos desenvolvedores para casos especí�cos do dia a dia do desenvolvimento. Além
disso discutimos também a necessidade da revisão baseada em amostragem, pois na
vida real temos milhões de linhas de código desenvolvidas para cada sistema de
criamos.
A Garantia da Qualidade de Software é um tempo polêmico, pois o próprio título
passa uma mensagem errada, que todo o código será coberto pelos testes. Esta
discussão foi tratada no tópico para apresentar a expectativa correta para os 
pro�ssionais da qualidade. Além disso, apresentamos padrões para auxiliar nesta
busca incessante pela Garantia da qualidade. Os padrões estudados foram: CMMI, ISO
e TQM.
Sobre estratégias de Teste de software discutimos sobre os testes exaustivos, testes
completos e testes aleatórios por mais sejam hipoteticamente possíveis para cobrir
todo o código, são ine�cientes por vários motivos que foram discutidos na unidade.
Conclusão - Unidade 3
Dessa forma, o Design de caso de teste busca encontrar formas para juntar técnicas
de teste e formas de ajustar as técnicas para encontrar o melhor resultado possível
usando o menor esforço destinado e esta atividade.  
É isso ai pessoal, mais uma Unidade termina, com muito conhecimento e propostas
de estudos futuros pois a área de qualidade possui muito conteúdo além do que
vimos até aqui e oferece uma carreira muito proeminente. Espero que aqueles que se
interessaram pela área busquem mais conhecimento e oportunidades como
pro�ssionais da qualidade. Na próxima Unidade falaremos sobre outra  grande área
de conhecimento, que é a área de Gerenciamento de Projetos. 
Aguardo vocês na próxima Unidade! Até lá 
Livro
Filme
Acesse o link
https://www.youtube.com/watch?v=XiG_Gz-sv48
Referências 
ISO BRASIL, O que é CMMI: CONSULTORIA EM CMMI, QUALIDADE, COVERNANÇA, 
E-LEARNINC, CERTIFICAÇÕES ([S.d.]). http://www.isdbrasil.eom.br/o-que-e-cmmi.php,
<acessado em 03/07/2018>. 
MYERS, Glenford J. et ai. The art of software testing. Chichester: John Wiley & Sons, 
2004. 
PATTON, Ron. Software testing. Pearson Education lndia, 2006. 
PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 7. ed. 
Porto Alegre: Me Graw Hill, 2017. 
SOMMERVILLE, 1. Engenharia de Software. 9. ed. São Paulo: Pearson, 2017. 
Unidade 4
Gerenciamento de Projetos
AUTORIA
Ricardo Bortolo Vieira
Introdução
Nesta Unidade você aprenderá as técnicas de gerenciamento necessárias para
planejar, organizar, monitorar e controlar projetos de software. Estes estudam visam
resolver as seguintes questões:
Como as pessoas, os processos e os problemas devem ser gerenciados durante
um projeto de software?
Como as métricas de software podem ser usadas para gerenciar um projeto de
software e o processo de software?
Como uma equipe de software pode gerar estimativas con�áveis de trabalho,
custo e duração do projeto?
Por que a manutenção e a reengenharia são tão importantes para o ciclo de
vida de um software?
Uma vez respondidas essas questões, estaremos mais preparados para os desa�os
do dia a dia da gestão de projetos, mais especi�camente a gestão de projetos de
software. 
Então vamos aos estudos! 
Conceitos de
Gerenciamento de Projetos
AUTORIA
Ricardo Bortolo Vieira
O conhecimento sobre projetos, acumulado até o presente momento (pela nossa
civilização moderna), permite notar que, por mais diferentes que sejam o propósito e
a dimensão dos projetos em diferentes organizações, eles são baseados nos mesmo
conceitos comuns (SABBAG, 2013). Vamos discutir alguns deles:
Singularidade
Percebe-se que projeto tem algo de inusitado ou desconhecido, diríamos único, e
por isso se torna tão desa�ador. 
Temporariedade
A expectativa do prazo norteia estes projetos. Ora, se há este tipo de meta, logo os
projetos são temporários. E caso sejam temporários, possuem um ciclo de vida a
considerar. Projetos são concebidos, evoluem até sua maturidade, apresentam
declínio e, são concluídos. A data de término é crucial para todo o projeto e como
isto se torna um problema para as organizações.
Gerenciamento de Projetos
Podemos descrevê-lo como a aplicação de conhecimento, habilidades, ferramentas
e técnicas às atividades do projeto buscando atender às suas demandas, sendo
realizado por meio da integração dos seguintes processos: iniciação, planejamento,
execução, encerramento e monitoramento e controle. Conforme o PMBOK (Project
Management Body Of Knowledge) do PMI (Project Management Institute) (2017).
Teoria da Tripla Restrição
Veremos mais adiante que o gerenciamento de projeto possui várias áreas que
devem ser acompanhadas para aumentar a probabilidade de sucesso do projeto.
Porém, dependendo das características do projeto, ou dos recursos �nanceiros
dedicados a gestão do projeto, o GP (Gerente de Projetos) tem que decidir quais
aspectos do projeto ele dará maior atenção. Deste modo, as áreas que são
geralmente escolhidas são aquelas que fazem parte do fator crítico de sucesso do
projeto e que geralmente são: Escopo,Tempo e Custo. Conforme Figura 20.
Figura 20 - Triplice Restrição.
QUALITY
Cost
Sc
op
e Tim
e
Fonte: BEWARE (2000)
Aprendizado por meio dos erros
Provavelmente hoje, no momento em que você está lendo este livro, vários projetos
estão sendo iniciados e outros tantos estão sendo encerrados, sejam eles por
sucesso ou não, interrompidos ou não. E outros tantos projetos já foram
desenvolvidos e suas histórias estão disponíveis, no âmbito público ou no privado,
onde você agora pode estar inserido. Neste ponto, o gerenciamento de projetos
trata uma área especi�ca de trabalho, as lições aprendidas, que tem grande
contribuição para a coleta, armazenamento e distribuição das informações de
sucesso e fracasso dos projetos.
Progressividade dos Projetos
Outra característica importante dos projetos é a elaboração progressiva, que
possibilita o seu desenvolvimento em etapas incrementais. Essa abordagem
progressiva se re�ete também na diferença entre projetos e trabalhos operacionais,
que veremos a seguir.
Diferença entre Projetos e Processos
Ambos, projetos e processos operacionais, são desenvolvidos pelas empresas para
atingir um conjunto de objetivos. Embora sejam diferentes, compartilham de
algumas semelhanças que geram confusão nos estudiosos de primeira viagem. Os
projetos são descontínuos, ou seja, não exigi uma ordem certa para a execução de
seus processos, embora existe uma linha de base, dependendo das escolhas do
gerente de projetos. Já o processo é estritamente contínuo, e a alteração de suas
etapas pode gerar sérios problemas para a organização que a gerencia. Além disso,
os projetos são únicos e desa�adores, diferentemente dos processos que tem o
objetivo de gerar produtos extremamente iguais (quanto mais melhor) e devem
gerar o mínimo de desa�o a seus operadores e gestores.
Organizações de Gerenciamento de Projetos
Muitas instituições foram criadas com o propósito de discutir boas práticas e
gerenciar documentos técnicos sobre a área de gerenciamento de projetos. Dentre
estas organizações temos o Project Management Institute (PMI), que mantem o
guia PMBOK e oferece a certi�cação PMP. Temos também a International Project
Management Association (IPMA) que oferece a certi�cação 4-L-C (four Level
Certi�cation) e o Of�ce of Government Commerce (OCG) que mantem sua versão
de um guia de boas práticas de gerenciamento de projeto chamado, em sua última
edição, de Prince2.  
Project Management Body Of Knowledge
(PMBOK) 
Desenvolvido pelo PMI, e já em sua sexta edição (lançada em setembro de 2017), que
o de�ne (PMI, 2017, p. 1-2) como:
"um termo que descreve o conhecimento dentro da pro�ssão de gerenciamento de
projetos. O corpo de conhecimento do gerenciamento de projetos inclui práticas
tradicionais comprovadas que são amplamente aplicadas, bem como práticas
inovadoras que estão surgindo na pro�ssão. Esse corpo de conhecimento está em
constante evolução. Este guia PMBOK® identi�ca um subconjunto do corpo de
conhecimento do gerenciamento de projetos que geralmente é reconhecido como
uma boa prática."
O PMBOK trata o gerenciamento de projetos dividindo a gestão em 10 áreas de
conhecimento – Escopo, Cronograma, Integração, Qualidade, Risco, Aquisição,
Recursos, Custo, Stakeholders e Comunicação - e separados em 49 processos
(vinculados as áreas de conhecimento) que estão espalhados por 5 grandes grupos
de processos – Iniciação, Planejamento, Execução, Encerramento e Monitoramento e
Controle. 
Figura 21 – Distribuição dos Processos do PMBOK por grupo de Processos.
Fonte: BEWARE (2000)
Métricas de Processo,
Projeto e Produto
AUTORIA
Ricardo Bortolo Vieira
Métricas de processo são coletadas através de todos os projetos e sobre longos
períodos de tempo. Sua �nalidade é proporcionar uma série de indicadores de
processo que levam à melhoria do processo de software no longo prazo. Métricas de
projeto permitem ao gerente de projeto de software (1) avaliar o estado de um
projeto em andamento, (2) rastrear os riscos em potencial, (3) descobrir áreas
problemáticas antes que elas se tornem críticas, (4) ajustar o �uxo de trabalho ou
tarefas, e (5) avaliar a habilidade da equipe de projeto para controlar a qualidade dos
produtos �nais de software. Estas de�nições são estabelecidas por Pressman (2011). 
Diferentemente das métricas de processo de software que são usadas para �ns
estratégicos, as medidas de projeto de software são táticas. Isto é, métricas de
projeto e os indicadores derivados delas são usados por um gerente de projeto e
uma equipe de software para adaptar o �uxo de trabalho do projeto e as atividades
técnicas.
Conforme Pressman (2011), a primeira aplicação das métricas de projeto na maioria
dos projetos de software ocorre durante as estimativas. Métricas coletadas de
projetos passados são usadas como base a partir da qual são feitas as estimativas de
esforços e tempo para o trabalho atual de software. Na medida em que um projeto
progride, medidas de esforço e tempo despendidos são comparadas com as
estimativas originais (e com o cronograma do projeto). O gerente de projeto usa
esses dados para monitorar e controlar o progresso.
O objetivo das métricas de projeto é duplo. Primeiro, essas métricas são usadas para
minimizar o cronograma de desenvolvimento fazendo os ajustes necessários para
evitar atrasos e mitigar problemas e riscos em potencial. Segundo, as métricas de
projeto são usadas para avaliar a qualidade do produto de forma contínua e, quando
necessário, modi�car a abordagem técnica para melhorar a qualidade.
A medição atribui números ou símbolos a atributos de entidades no mundo real.
Para tanto, é necessário um modelo de medição abrangendo um conjunto
consistente de regras e vale estabelecer uma estrutura fundamental e um conjunto
de princípios básicos para orientar a de�nição e assim estabelecer as métricas de
produto para software.
Já a medição ocorre, conforme Pressman (2011) indica, como resultado da coleção
de um ou mais pontos de dados (por exemplo, um conjunto de revisões de
componente e testes de unidade são investigados para coletar medidas do número
de erros para cada um). Uma métrica de software relaciona as medidas individuais
de alguma maneira (por exemplo, o número médio de erros encontrados por revisão
ou o número médio de erros encontrados por teste de unidade).
Um engenheiro de software coleta medidas e desenvolve métricas para obter
indicadores. Um indicador é uma métrica ou combinação de métricas que
proporcionam informações sobre o processo de software, em um projeto de
software ou no próprio produto. 
Além disso, Pressman (2011) também trata sobre as medidas no mundo físico e
como devem ser classi�cadas de duas maneiras: medidas diretas (por exemplo, o
comprimento de um parafuso) e medidas indiretas (por exemplo, a qualidade dos
parafusos produzidos, medida contando os rejeitos). As métricas de software podem
ser classi�cadas de maneira similar.
Medidas diretas do processo de software incluem custos e trabalho aplicado.
Medidas diretas do produto incluem linhas de código (lines of code - LOC)
produzidas, velocidade de execução, tamanho de memória e defeitos relatados
durante um determinado período de tempo. Medidas indiretas do produto incluem
funcionalidade, qualidade, complexidade, e�ciência, con�abilidade,
manutenibilidade, e muitas outras. 
Métricas orientadas a tamanho 
Métricas de software orientadas a tamanho são criadas, conforme Pressman (2011),
normalizando-se as medidas de qualidade e/ou produtividade considerando o
tamanho do software que foi produzido. Se uma organização de software mantém
registros simples, pode ser criada uma tabela de medidas orientadas a tamanho
com 12.100 linhas de código, 24 pessoas-mês de trabalho a um custo de $168.000,
criadas 365 páginas de documentação, foram registrados 134 erros antes da entrega
do software e foram encontrados 29 defeitos após a entrega para o cliente durante o
primeiro ano de operação. A partir dos dados rudimentares contidos na tabela, pode
ser desenvolvido um conjunto de métricassimples orientadas a tamanho para cada
projeto:
Erros por kLOC (mil linhas de código);
Defeitos por kLOC;
$ por kLOC;
Páginas de documentação por kLOC;
Erros por pessoa-mês;
kLOC por pessoa-mês;
S$ por página de documentação;
Métricas orientadas por tamanho não são aceitas universalmente como a melhor
maneira de medir os processos de software. A maior parte da controvérsia gira em
torno do uso de linhas de código como medida principal. Os defensores da medida
LOC (linhas de código) argumentam que LOC é um “item” de todos os projetos de
desenvolvimento de software que pode ser facilmente contado. Por outro lado, os
oponentes argumentam que as medidas LOC são dependentes da linguagem de
programação, que quando é considerada a produtividade, elas penalizam
programas bem projetados, mas menores; que elas não podem facilmente
acomodar linguagens não procedurais; e que seu uso nas estimativas requerem um
nível de detalhe que pode ser difícil de alcançar.
Métricas orientadas a função 
Métricas de software orientadas a função, conforme Vazquez (2013), usam uma
medida da funcionalidade fornecida pela aplicação como um valor de normalização.
A métrica orientada a função mais amplamente usada é a pontos de função
(function point — FP). O cálculo de pontos de função é baseada nas características
de domínio de informação e complexidade do software.
A métrica ponto de função pode ser usada efetivamente como um meio para medir
a funcionalidade fornecida por um sistema. Por meio de dados históricos, a métrica
FP pode ser empregada para (1) estimar o custo ou trabalho necessário para
projetar, codi�car e testar o software; (2) prever o número de erros que serão
encontrados durante o teste; e (3) prever o número de componentes e/ou o número
de linhas projetadas de código-fonte no sistema implementado.
Pontos de função são derivados por meio de uma relação empírica baseada em
medidas calculáveis (diretas) do domínio de informações do software e avaliações
qualitativas da complexidade do software. valores do domínio de informações são
de�nidos conforme segue os próximos parágrafos.
Número de entradas externas (number of external inputs - EEs). Cada entrada
externa é originada de um usuário ou transmitida de outra aplicação e fornece
dados distintos orientados a aplicação ou informações de controle. Entradas
são muitas vezes usadas para atualizar Arquivos Lógicos Internos (internal
logical �les — ALI). As entradas devem ser diferenciadas das consultas, que são
contadas separadamente.
Número de saídas externas (number of external outputs - SE). Cada saída
externa é formada por dados derivados da aplicação e fornece informações
para o usuário. Nesse contexto, as saídas externas se referem a relatórios, telas,
mensagens de erro etc. Itens individuais de dados em um relatório não são
contados separadamente.
Número de consultas externas (number of external inquiries - CS). Uma
consulta externa é de�nida como uma entrada on-line que resulta na geração
de alguma resposta imediata do software na forma de uma saída on-line.
Número de ALI`s. Cada Arquivo Lógico Interno é um agrupamento lógico de
dados que reside dentro das fronteiras do aplicativo e é mantido através de
entradas externas.
Número de arquivos de Arquivos de Interface Externos (number of external
interface �les - AIE). Cada arquivo de interface externo é um agrupamento
lógico de dados que reside fora da aplicação, mas fornece informações que
podem ser usadas pela aplicação.
Uma vez coletados esses dados, é associado um valor de complexidade com cada
contagem. Organizações que usam métodos ponto de função desenvolvem critérios
para determinar se determinada entrada é simples, média ou complexa. No entanto,
a determinação da complexidade é de certo modo subjetivo.
Para calcular Pontos de Função (PF), usa-se a seguinte relação: 
em que a contagem total é a soma de todas as entradas PF obtidas.
Os F(i= 1 a 14) são fatores de ajuste de valor (value adjustment factors - VAF)
baseados em respostas à questões de ajustes que são feitas ao �nal da medição
direta.
O ponto de função, assim como a medida LOC, é controverso. Os proponentes
argumentam que essa função é independente da linguagem de programação,
tornando-a ideal para aplicações que usam linguagens convencionais e não
procedurais, e que é baseada em dados que têm maior probabilidade de ser
conhecidos na evolução de um projeto, tornando a PF mais atraente como
abordagem de estimativa. Os oponentes argumentam que o método requer um
pouco de “jeitinho”, porque o cálculo é baseado em dados subjetivos ao invés de
objetivos, que as contagens do domínio de informações (e outras dimensões)
podem ser difíceis de coletar. 
Métricas orientadas a objeto 
Conforme Sommerville (2011), métricas de projeto de software convencional (LOC ou
FP) podem ser usadas para estimar projetos de software orientados a objeto. No
entanto, essas métricas não fornecem granularidade su�ciente para os ajustes de
cronograma e esforço que são necessários na medida em que você passa por
iterações por meio de um processo evolucionário ou incremental. Assim, as
seguintes métricas são utilizadas com melhor e�ciência para esse contexto:
Número de scripts de cenário (Number of scenario scripts). Um script de cenário é
uma sequência detalhada de passos que descrevem a interação entre o usuário e a
aplicação. Cada script é organizado em trios da forma (iniciador, ação, participante)
onde iniciador é o objeto que solicita algum serviço (que inicia uma mensagem),
ação é o resultado da solicitação, e participante é o objeto servidor que satisfaz a
solicitação. 
Figura 22 - Fórmula para calcular Ponto de Função.
Fonte: Vazquez (2013)
PF = contagem total x [0, 65 + 0, 01 x Σ(Fi)]
Número de classes-chave (Number of key classes). Classes-chave (Key classes) são
os “componentes altamente independentes “ que são de�nidos logo no início em
uma análise orientada a objeto. Como as classes-chave são essenciais ao domínio do
problema, a quantidade dessas classes é uma indicação da quantidade de esforço
necessário para desenvolver o software.
Número de classes de apoio (Number of support classes). Classes de apoio
(Support classes) são necessárias para implementar o sistema, mas não estão
imediatamente relacionadas com o domínio do problema. Como exemplos
podemos citar as classes de interface de usuário (GUI), classes de acesso e
manipulação de bases de dados, e classes de cálculo. O número de classes de apoio
é uma indicação da quantidade de esforço necessário para desenvolver o software.
Métricas orientadas a casos de uso
Os casos de uso são amplamente usados como método para descrever requisitos no
nível dos clientes ou domínio de negócio que sugerem características e funções de
software. Conforme Pressman (2011), seria considerado razoável usar o caso de uso
como uma métrica similar a LOC ou FP. Assim como a FP, o caso de uso é de�nido
no início no processo de software, permitindo que ele seja usado para estimativas
antes de iniciar atividades signi�cativas de modelagem e construção. Os casos de
uso descrevem (indiretamente, pelo menos) funções e características visíveis ao
usuário que são requisitos básicos para um sistema. O caso de uso é independente
da linguagem de programação. Além disso, o número de casos de uso é
diretamente proporcional ao tamanho do aplicativo em LOC e ao número de casos
de testes que terão de ser projetados para exercitar completamente o aplicativo.
Como os casos de uso podem ser criados em níveis muito diferentes de abstração,
não há um “tamanho” padrão para um caso de uso. Sem uma medida padronizada
do que é um caso de uso, sua aplicação como medida de normalização (por
exemplo, esforço gasto por cada caso de uso) é suspeita.
Os pesquisadores têm sugerido os pontos de casos de uso (UCPs) como um
mecanismo para estimar trabalho de projeto e outras características. O UCP é uma
função do número de atores e transações deduzidas pelos modelos de casos de uso
e é análogo ao FP em alguns aspectos. 
Estimativasde Projeto de
Software
AUTORIA
Ricardo Bortolo Vieira
Segundo o PMBOK (PMI, 2017) as atividades de estimativa são realizadas dentro do
processo de planejamento e são feitas para as áreas de conhecimento: custo,
cronograma e recursos, e contemplam o plano de gerenciamento do projeto - que
servirá como base de consulta para o GP (Gerente de Projeto) tomar suas decisões
durante o projeto. Dentro desse contexto e segundo, as boas práticas de gestão, as
estimativas estão sendo empregadas para criar uma linha de base do projeto, que
servirá de indicador para a gestão do monitoramento e controle do projeto, ou seja,
são estimativas que são usadas internamente para o GP conduzir seu projeto. 
E quando o cliente deseja saber qual o custo do projeto que ele pretende aprovar?
Neste caso, o PMBOK (PMI, 2017) recomenda uma visão de projeto chamada de
estimativa de ordem de grandeza (utilizada na fase de Iniciação), onde temos uma
precisão de -25% para menos e + 75% para cima. Isso ainda não é bom para um
tomador de decisão em nível mais baixo dentro da cadeia de decisão de uma
empresa. 
Para o ambiente de projetos aos moldes do PMI, o plano de viabilidade, que é
desenvolvimento antes de iniciar o projeto e feito na fase de gestão de portfólio de
projetos, já é su�ciente para os tomadores de decisão de alto nível na cadeia
empresarial, decidirem qual projeto será colocado em execução, porém, para nós da
computação este não é um ambiente muito favorável, já que nosso contexto muda.
Normalmente nosso cliente desse uma estimativa rápida e precisa para tomada de
decisão rápida na cadeia intermediária de tomada de decisão, quando estamos
falando de desenvolvimento de software e principalmente de incrementos em
sistema já consolidados e em produção.
Dentro desse contexto, mais especí�co da gerência de projetos de software vamos
utilizar os estudos de Huzita (2015), para apresentar algumas abordagens referentes
ao critério custo: 
Além disso, Huzita (2015) ainda discute a estimativa de custos como um processo do
planejamento e que deve levar em consideração, principalmente, os recursos que
serão utilizados em um projeto de software. A estimativa possui riscos inerentes e
pode ser realizada com maior grau de certeza, quanto maior for a experiência do GP,
quanto maior é o acesso às informações históricas e quanto maior for o empenho
em efetuar previsões quantitativas, mesmo que se tenham apenas dados
qualitativos. 
Além disso, a estimativa de custos deve considerar:
custos de hardware e software;
custos de viagem e treinamento;
custos relativos ao esforço humano empregado.
Modelagem algorítmica: é desenvolvido um modelo, utilizando-se
dados históricos que relacione alguma medida de desempenho ao
custo de projeto.
Julgamento de um especialista: são consultados diversos especialistas,
os quais estimam o custo de um projeto. Posteriormente, essas
estimativas são comparadas entre si e discutidas até se chegar a um
consenso.
Estimativa por analogia: aplicável quando outros projetos no mesmo
domínio de aplicação tenham sido concluídos.
Lei de Parkinson: de�ne que o trabalho se amplia para preencher o
tempo disponível. Se o software tiver de ser entregue em 12 meses e 5
pessoas estiverem disponíveis, o esforço requerido é estimado em 60
homens-mês.
Preço de�nido para ganhar: o custo do software é estimado para ser o
que o cliente tiver disponível para gastar no projeto. O esforço de
estimativa depende do orçamento do cliente e não da funcionalidade
do software.
COCOMO II: (Constructive Cost Model) é um modelo paramétrico,
criado pela USC - University of Southern California, que permite calcular
o custo de um projeto através de equações matemáticas complexas
que levam em consideração particularidades de cada projeto como:
características do Produto, Processo, Experiência da Equipe e
Plataforma de Desenvolvimento. 
Agora conforme Pressman (2011), embora estimar seja mais arte do que ciência, não
precisa ser conduzida de maneira aleatória. Existem técnicas úteis para estimar
tempo e esforço. As métricas de projeto e processo podem proporcionar
perspectivas históricas e valiosas informações para gerar estimativas quantitativas.
As estimativas de recursos, custos e cronograma para um trabalho de engenharia de
software requerem experiência, acesso a boas informações históricas (métricas), e a
coragem de se comprometer com as previsões quantitativas quando tudo o que
existe são apenas informações qualitativas. 
A complexidade do projeto tem um forte efeito sobre a incerteza inerente ao
planejamento. No entanto, é uma medida relativa afetada pela familiaridade com
esforços passados. O tamanho do projeto é outro fator importante que pode afetar a
precisão e a e�cácia das estimativas. À medida que o tamanho aumenta, a
interdependência entre os vários elementos do software cresce.  
Técnicas de decomposição 
Ainda conforme Pressman (2011), a estimativa de projeto de software é uma forma
de solução de problema e, na maioria dos casos, o problema a ser resolvido é muito
complexo para ser considerado em uma única parte. Por essa razão, você deve
decompor o problema, rede�nindo-o como uma série de problemas menores.
A decomposição pode ser feito abordando o problema ou o processo. As estimativas
usam uma ou ambas as formas de particionamento. Mas antes de fazer uma
estimativa, entenda o escopo do software a ser criado e gere uma estimativa de seu
tamanho.
Na Unidade anterior, falamos sobre métricas de software e tratamos sobre as
métricas de produtividade baseadas em linhas de código (Lines Of Code - LOC) e
Pontos de Função (PF). Dados de LOC e FP são usados de duas maneiras durante a
estimativa do projeto de software: (1) como variáveis de estimativa para
“dimensionar " cada elemento do software e (2) como métricas de referência
coletadas de projetos anteriores e utilizadas em conjunto com variáveis de
estimativa para desenvolver projeções de custo e esforço.
Estimativas LOC e FP são técnicas distintas. No entanto, ambas têm muitas
características em comum. Inicia-se com uma de�nição delimitada do escopo do
software e daí tenta-se decompor a de�nição em funções de problemas que podem
ser estimados individualmente. LOC ou FP (a variável de estimativa) é então
estimada para cada função. Como alternativa, pode-se escolher um outro
componente para dimensionamento como classes ou objetos, alterações ou
processos de negócio afetados.
Métricas de produtividade de referência, por exemplo, LOC/pm (LOC por mês) ou
FP/pm (LOC por mês), são aplicadas à variável apropriada de estimativa e, assim, se
obtém o custo ou esforço para a função. As estimativas de função combinam-se
para produzir uma estimativa geral para todo o projeto. 
É importante observar, porém, que muitas vezes há uma dispersão substancial em
métricas de produtividade para uma organização, não sendo aconselhável o uso de
uma única métrica
de produtividade de referência. Em geral, médias LOC/pm ou FP/pm deverão ser
computadas por domínio de projeto. Os projetos deverão ser agrupados por
tamanho de equipe, por área de aplicação, complexidade e outros parâmetros
relevantes. Deverão ser calculadas as médias locais de domínio. Quando é estimado
um novo projeto, esse deverá primeiro ser alocado a um domínio e, depois, à média
de domínio apropriada para produtividade anterior deverá ser usada para gerar a
estimativa.
As técnicas de estimativa LOC e PF diferem em nível de detalhe requerido para a
decomposição e no alvo do particionamento. Quando é usada a LOC como variável
de estimativa, a decomposição é absolutamente essencial e muitas vezes é adotada
com níveis consideráveis de detalhes. Quanto maior o grau de particionamento,
maior a probabilidade de serem desenvolvi das estimativas LOC razoavelmente
precisas.
Para estimativas PF, a decomposição funciona de forma diferente. Em vez de
focalizar-se na função, é estimada cada uma das características do domínio de
informação — entradas, saídas, arquivos de dados, consultas e interfaces externas. As
estimativasresultantes podem então ser usadas para derivar um valor de FP que
pode ser relacionado a dados anteriores e usado para gerar uma estimativa. 
Manutenção e
Reengenharia
AUTORIA
Ricardo Bortolo Vieira
Manutenção
Independentemente do domínio de aplicação, tamanho ou complexidade, o
software continuará a evoluir com o tempo. Pressman (2011) estabelece que as
mudanças dirigem esse processo. No âmbito do software, ocorrem alterações
quando são corrigidos erros, quando há adaptação a um novo ambiente, quando o
cliente solicita novas características ou funções e quando a aplicação passa por um
processo de reengenharia para proporcionar benefício em um contexto moderno. 
A manutenção começa quase imediatamente. O software é liberado para os
usuários �nais, e em alguns dias, os relatos de bugs começam a chegar à
organização de engenharia de software. Em algumas semanas, uma classe de
usuários indica que o software deve ser mudado para se adaptar às necessidades
especiais de seus ambientes. E em alguns meses, outro grupo corporativo, ainda não
interessado no software quando foi lançado, agora reconhece que pode lhes trazer
alguns benefícios. Eles precisarão de algumas melhorias para fazer o software
funcionar em seu mundo.
Tanto a análise quanto o projeto levam a uma importante característica do software
que chamamos de manutenibilidade, que, essencialmente, é uma indicação
qualitativa da facilidade com que o software pode ser corrigido, adaptado ou
melhorado. Grande parte das funções da engenharia de software é criar sistemas
que apresentem alta manutenibilidade.
Software "manutenível" apresenta uma modularidade e�caz. Utiliza padrões de
projeto  que permitem entendê-lo facilmente. Foi construído usando padrões e
convenções de codi�cação bem de�nidos, levando a um código-fonte auto-
documentado e inteligível. Passou por uma variedade de técnicas de garantia de
qualidade que descobriu potenciais problemas de manutenção antes que o
software fosse lançado. 
Para suportar efetivamente software de classe industrial, a organização (ou seus
projetistas) deve ser capaz de fazer correções, adaptações e melhorias inerentes à
atividade de manutenção. Além disso, a organização deve executar outras atividades
importantes que incluem suporte operacional continuado, suporte ao usuário �nal e
atividades de reengenharia durante toda a vida útil do software. Uma de�nição
razoável da suportabilidade do software, apresentada por Pressman (2011), é a
capacidade de suportar um sistema de software durante toda a vida útil do produto.
Isso implica satisfazer quaisquer necessidades ou requisitos, mas também a
provisão do equipamento, infraestrutura de suporte, software adicional, serviços de
conveniências, mão de obra ou qualquer outro recurso necessário para manter o
software operacional e capaz de satisfazer suas funções.
Essencialmente, a suportabilidade é um dos muitos fatores de qualidade que devem
ser considerados durante a análise e projeto na gestão da qualidade. Ela deve ser
tratada como parte do modelo de requisitos (ou especi�cações) e considerada
conforme o projeto evolui e a construção inicia.
Embora os erros encontrados em uma aplicação sejam um problema crítico de
suporte, a suportabilidade também exige que sejam providenciados recursos para
resolver os problemas diários dos usuários �nais. A função do pessoal de suporte é
responder às dúvidas dos usuários sobre instalação, operação e uso da aplicação. 
Reengenharia 
Reengenharia é um sistema estratégico de reestruturação organizacional e
administrativa, com o objetivo de reformular as atividades de determinada empresa
para que possa se tornar mais competitiva no mercado. A ideia central da
reengenharia é a "reinvenção” (não necessáriamente, mas o processo de repensar e
propor ajustes) da organização, eliminando práticas e costumes que se tornaram
obsoletos e, a partir de estudos e planos, adequar-se aos novos mecanismos de
produção, novas atividades, processos e até mesmo novos produtos.
Essa estratégia foi desenvolvida pelos estadunidenses Michael Hammer e James
Champy, ambos do Instituto Tecnológico de Massachusetts (MIT), em meados dos
anos 1990 e também é conhecida por reengenharia de processos de negócio
(business process reengineering — BPR) se estende muito além do escopo das
tecnologias de informação e da engenharia de software.  
Reengenharia de Software 
Um sistema foi desenvolvido para atender as necessidades de negócio de uma
empresa e perdurou por 20 anos em produção. Durante esse tempo, ele foi
corrigido, adaptado e aperfeiçoado muitas vezes. Pro�ssionais realizaram esse
trabalho com as melhores intenções, mas as boas práticas de engenharia de
software foram sempre deixadas de lado, devido à pressão por aspectos de prazo.
Agora o sistema está instável. Ainda funciona, mas sempre que se tenta fazer uma
alteração, ocorrem efeitos colaterais sérios e inesperados. No entanto, o sistema deve
continuar evoluindo. O que fazer?
A ênfase cada vez maior sobre a reengenharia de software foi motivada pelos
problemas de manutenção criados por mais de quatro décadas de esforço de
pesquisa e desenvolvimento de técnicas e processos de desenvolvimento de
software (engenharia de software). 
Um modelo de processo de reengenharia
de software 
Para Pressman (2011), reengenharia toma tempo, tem um custo signi�cativo em
dinheiro e absorve recursos que poderiam de outra forma ser usados em
necessidades mais imediatas. Por todas essas razões, a reengenharia não é realizada
em alguns meses ou mesmo anos. A reengenharia dos sistemas de informação é
uma atividade que absorverá recursos da tecnologia de informação por muitos anos.
Todas as organizações precisam de uma estratégia pragmática para reengenharia
de software.
Uma estratégia prática faz parte de um modelo de processo de reengenharia.
Discutiremos o modelo mais tarde nesta seção, mas primeiro, vejamos alguns
princípios básicos.
A reengenharia é um trabalho de reforma. Para melhor entendê-la, considere uma
atividade análoga: o conserto de uma parte da sua casa. Comprou uma casa por um
preço extremamente baixo e precisa fazer pequenas ajustes e reformas. Podemos
conduzir este processo da seguinte forma:
Antes de iniciar a reforma, seria razoável inspecionar a casa. Para determinar se
precisa de reforma, você (ou um pro�ssional de construção) criaria uma lista de
critérios para que a inspeção fosse sistemática.
Antes de começar a reconstrução, veri�que como está a estrutura. Se a casa
estiver com a estrutura em bom estado, pode ser possível “remodelar” sem
reformar (a um custo bem mais baixo e em menos tempo).
Antes de começar a reforma, procure entender como a casa original foi
construída. Dê uma olhada atrás das paredes. Veri�que a �ação elétrica, a
tubulação hidráulica e as partes internas da estrutura. Mesmo que você resolva
descartar tudo, as informações obtidas terão utilidade quando iniciar a
reconstrução.
Na reforma, use somente os materiais mais modernos e mais duráveis. Isso
pode custar um pouco mais agora, mas ajudará a evitar uma manutenção cara
e demorada mais tarde.
Se você decide reformar, seja disciplinado. Use práticas que resultarão na mais
alta qualidade — hoje e no futuro.
Embora esses princípios concentrem-se na reforma de uma casa, eles se aplicam da
mesma forma para à reengenharia de software.
Para implementarmos esses princípios, podemos usar um modelo de processo de
reengenharia de software, apresentado na Figura 12. As atividades descritas nesta
imagem nem sempre podem ocorrer sequencialmente. Como este é um processo
cíclico cada etapa pode ser revisada bem como o ciclo pode ser concluído em
qualquer etapa. 
Figura 23 - Um modelo de processo de reengenharia de software.
Análise do
inventário
Reestruturação
de documentos
Engenharia
reversa
Reestruturação
dos dados
Engenharia
avante
Reestruturação
do código
Fonte: Pressman (2011)
SAIBA MAIS
Quando testes e inspeções no Projeto falham
Por Mariela Aranda 
Todo projeto inicia ou se materializa por meioda necessidade de
alguém, um cliente interno ou externo à organização, ou uma
necessidade da própria área. Cada um poderá trazer mais ou menos
complexidade quando tratamos de comunicação, terceirização de
riscos e contratações. Sabíamos, pelas linhas teóricas, que deveríamos
realizar um business case que validasse a probabilidade técnica e
econômica de sucesso, para, depois, passarmos à fase de planejamento
e, assim, transitar pelas fases e áreas do conhecimento.
Um projeto de desenvolvimento de um novo equipamento (eu o
considero uma inovação) estava indo sob controle em todas as suas
fases, até que chegamos nos testes. Quando planejamos um projeto
que tem, como fase, os testes dos projetos mecânicos e eletrônicos, é
comum colocar uma duração mais conservadora, pois sempre temos
algum tipo de retrabalho. Mas assim, como somos mais conservadores,
nossos clientes são mais ansiosos pelo prazo e o que normalmente é
cortado é o prazo dos testes, sem perceberem os grandes riscos destas
ações.
Muitos problemas acontecem e irão acontecer nessa fase,
especialmente pelas características de projetos únicos e irrepetíveis.
Geralmente, quando temos projetos de interface mecânica e eletrônica,
os problemas ainda aumentam, seja porque a parte mecânica não
contemplou espaço para cabeamento e sensores da eletrônica ou
porque a parte eletrônica embarcada �cou com mais peso do que o
esperado e o coe�ciente de segurança de dimensionamento dos
motores mecânicos não o suporta.
A questão é que, até hoje, não conseguimos encontrar uma forma de
otimizar o processo de monitoramento e controle de testes nos
cronogramas. Sim, podemos colocar informações paliativas, reabrir
atividades que estão concluídas e reprogramar aumentando a duração,
mas essa fase tão interativa tem sido um verdadeiro desa�o nos
projetos de desenvolvimento tecnológico hard. Em software, podemos
falar em Scrum ou Agile, mas, em projetos de montagem de máquina,
ainda temos o waterfall para aplicar. Podemos aplicar, sim, modelos
híbridos, mas, ainda assim, temos inúmeros loops que se traduzem em
retrabalho, perdas e aumento de custo.
Quanto a esse tipo de sintomas ou doenças, ainda não identi�quei em
qual estágio da medicina de projetos se encontra, mas é fator comum e
problemático em empresas startups, onde os custos são reduzidos e,
provavelmente, onde os projetos estão vinculados a algum edital de
fomento, embora as empresas com maior maturidade encontrem o
mesmo problema.
Então, o que fazer? Devemos aprender a negociar prazos com os nossos
clientes e, aos poucos, mudar o mindset de que projetos com fase de
teste reduzida serão, com certeza, bem-sucedidos.
REFLITA
“Não se pode administrar o que não se pode medir”, diz Morris A.
Cohen, professor da Wharton e co-diretor do Centro Fishman-Davidson
de Gestão de Serviços e Operações [Fishman-Davidson Center for
Service and Operations Management]. 
http://www.wharton.upenn.edu/faculty/cohen.html
http://grace.wharton.upenn.edu/fd/
Ao �nal desta unidade, podemos relembrar tópicos e informações importante que 
foram estudadas ao longo da mesma. Durante estes estudos aprendemos conceitos 
de gestão de projetos, que na verdade podem ser aplicados não somente no contexto 
de desenvolvimento de TI, mas em um espectro muito mais abrangente. 
Sobre os conceitos de Gerenciamento de Projetos estudamos sobre singularidade, 
temporariedade, gestão de projetos, teoria da tripla restrição,  aprendizado por meio 
dos erros, progressividade dos projetos, diferença entre projetos e processos, 
organizações de gerenciamento de projetos. Outro tópico importante que vimos foi 
um guia de boas práticas conhecida como PMBOK.
Além disso, discutimos também sobre as métricas de processos e projetos, neste 
caso, abordando ferramentas e técnicas especí�cas para os projetos de software…
Outro assunto discutido nesta unidade foi o processo de estimativa de projeto, que 
muitas vezes é menosprezado, porém uma estimativa mal feita pode impactar 
seriamente os prazos e custos de um projeto.
Por último, tratamos sobre a manutenção de um produto resultado do projeto de 
software e o processo de reengenharia, muitas vezes usado para levantar requisitos 
de um sistema antigo que servirá como base em um novo projeto de software.
Durante todo este material, estudamos sobre várias etapas, processos, ferramentas e 
técnicas que contemplam o grande arcabouço da Engenharia de Software. Este 
material é apenas um conjunto de tópicos dos itens mais importantes dessa grande 
área de trabalho. Como �cou evidente, independente de sua área de atuação na TI, é 
imprescindível que todos tenham este conhecimento para desenvolverem melhor 
suas atividades.  
Espero poder ter sido importante em sua caminhada em busca do conhecimento 
necessário para sua evolução na carreira. Assim, recomendo que este seja apenas o 
ponto de partida de sua longa jornada em busca de conhecimento. E lembrem-se, 
devemos sempre aprender a aprender…
Grande abraço a todos e muito sucesso em seus projetos! 
Conclusão - Unidade 4
Livro
Filme
Prezado(a) aluno(a),
Neste material, buscamos trazer para você os principais conceitos a respeito da
Programação para Internet. Para tanto abordamos as questões históricas, de�nições
teóricas e, neste aspecto acreditamos que tenha ajudado a assimilar os conceitos
pilares dessa linguagem de programação PHP.
Destacamos também a importância da criação de unidades de código mais próxima
da forma como pensamos e agimos. Você também pode ver uma introdução a
vários conceitos e aplicações tais como Funções, Passagem de Argumentos, que
todos foram tratados de maneira especial, em capítulo especí�co no decorrer dos
estudos.
Levantamos também aspectos sobre o recebimento de formulários HTML e PHP
utilizando Campos Hidden, Campos Text e Textarea, Campos Checkbox que
determinam a forma como os formulários serão construídos, de acordo com a
necessidade. Além disso, falamos também sobre a validação dos formulários
fazendo comparativos  dos métodos de validação utilizados como o  HTML5,
Javascript e também falamos sobre a personalização da mensagem de validação.
Ao pensarmos em uma organização de código estruturado segundo os preceitos da
Orientação à Objetos com PHP, não poderíamos deixar de falar sobre construtores,
destruidores, herança e  encapsulamento. Um ponto muito importante abordado
neste livro foi uma introdução à banco de dados, em especí�co com MySQL e
utilizando os métodos de acesso a banco de dados utilizando a linguagem de
programação PHP. Podemos ver alguns dos padrões de servidores web e como
transferir dados com o auxílio de ferramentas Rest e Frameworks em PHP. 
A partir de agora acreditamos que você já está preparado para seguir em frente
desenvolvendo ainda mais suas habilidades para criar e desenvolver produtos e
marcas de sucesso no mercado e realizar bons negócios. Mas não pare por aqui,
Considerações Finais
continue estudando e buscando conhecimento. Em nossa área de atuação, sempre
estão sendo lançadas novas ferramentas e técnicas para otimizar e desenvolver
melhor nosso código fonte. 
Até uma próxima oportunidade. Muito Obrigado! 
	00-capa
	01-Introdução 1
	02-Introdução a Engenharia de Software
	03-Mas o que seria um Software_
	04-Engenharia de Software
	05-Modelos de Processo de Software
	06-Princípios que orientam a prática dos modelos de processo de software
	07-Modelos de desenvolvimento dirigidos a plano
	08-Modelos de desenvolvimento ágil
	09-uml e orientação a objetos
	10-Ferramentas Case
	11-Conclusão 1
	12-Introdução 2
	13 - Projeto de arquitetura de software
	14 - Projeto de componentes de software
	15 - Projeto de interface de usuário
	16 - Padrões de projeto
	17 - Conclusão 2
	18 - Introdução 3
	19 - Conceito de Qualidade
	20 - Técnicas de Revisão
	21 - Garantia da Qualidade de Software
	22 - Estratégias de Teste de Software
	23 - Conclusão 3
	24 - Introdução 4
	25 - Conceitos de Gerenciamento de Projetos
	26 - Métricas de Processo, Projeto e Produto
	27 - Estimativas de Projetode Software
	28 - Manutenção e Reengenharia
	29 - Conclusão 4
	30 - Considerações Finais