Engenharia de Software_unid_II

Prévia do material em texto

85
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
Unidade II
11 ENGENHARIA DE REQUISITOS
11.1 Introdução
Em um ambiente competitivo e de mudança cada vez mais complexo, a gestão adequada da 
informação assume uma importância decisiva no processo de tomada de decisão nas organizações.
Tratando‑se de um tema simultaneamente abrangente e especializado, a adoção da Engenharia de 
Requisitos como linha base da Gestão da Informação possibilitará não só desenvolver e consolidar os 
conhecimentos no desenvolvimento de software, bem como preparar os micro, os pequenos e os médios 
desenvolvedores para encarar com confiança os novos desafios no mundo dos negócios e também 
reforçar as competências profissionais, mantendo‑se atualizado em relação ao potencial dos sistemas 
de informação e das novas tecnologias em uma perspectiva empresarial e competitiva globalmente.
A partir do conhecimento adquirido da Engenharia de Requisitos de Software, o desenvolvedor será 
elemento multiplicador de soluções, contribuindo e agregando valor aos sistemas novos e para os já 
existentes, com aplicação de metodologias e tecnologias adequadas, capazes de gerir com sucesso as 
informações relevantes aos negócios aplicáveis, trazendo às organizações vantagens competitivas.
No estudo da Engenharia de Software, o autor Roger S. Pressman (2002) demonstra preocupação 
com a “crise do software” que, atualmente, ele intitula como “aflição crônica”, chegando a determinar 
números expressivos sobre a não finalização de projetos de sistemas começados e não terminados.
Em um mundo cada vez mais com recursos financeiros escassos, como é possível aceitar tal 
desperdício de tempo e dinheiro? O mesmo autor também aponta para o possível problema causador 
de tal absurdo: “A falta de adoção de métodos, ferramentas e procedimentos no desenvolvimento de 
software e a difícil relação de entendimento entre o usuário com o analista desenvolvedor”.
Existem várias técnicas de levantamento de requisitos e modelagem de software e o analista 
desenvolvedor que não as implementa tem dificuldades de realizar um projeto de sistemas livre de 
manutenções e retrabalhos, condenando diretamente a qualidade do produto.
A implementação da Engenharia de Requisitos, pelo micro, pelo pequeno e pelo médio desenvolvedor 
de software, direciona como realizar uma especificação de requisitos que estruture a fase de análise 
do desenvolvimento do software, proporcionando método sistemático de levantamento dos requisitos 
acompanhando todo o processo, permitindo que o software represente a realidade da empresa modelada 
para geração de um sistema customizado, atendendo as necessidades dessa empresa, obtendo qualidade 
no software, bem como criar a real possibilidade de extrair de um sistema informações relevantes que 
86
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
venham não só contribuir com a decisão, mas ser um fator de excelência empresarial, permitindo novos 
negócios, permanência e sobrevivência em um mercado atuante.
11.2 Relevância
Segundo o Ministério da Ciência e Tecnologia (2002), a participação de mercado das micro, das 
pequenas e das médias empresas desenvolvedoras de software corresponde a 65,1% do total (tabela 
1). Diante da dimensão desse mercado ainda em franca expansão, motivou a prestar atenção especial 
para esse tema.
Tabela 5 – Porte das organizações, segundo comercialização bruta anual (2002)
Porte das organizações
Portes %
Micro 16,5
Pequena 25,3
Média 23,3
Grande 34,9
Atualmente, com a visão global permitindo a participação nas exportações de software para outros 
países, cada vez mais a qualidade no processo de desenvolvimento e do produto de software ganha 
maior observação e adoção das melhores práticas e soluções tecnológicas que atendam aos requisitos 
estabelecidos.
Considerado por Brooks (1987) como problema essencial:
“A parte mais difícil do desenvolvimento de software é decidir precisamente o que será desenvolvido. 
Nenhuma outra parte do trabalho é tão difícil quanto estabelecer (definir) os detalhes técnicos 
necessários incluindo todas as interfaces para pessoas, máquinas e para outros sistemas de software. 
Nenhuma outra parte do trabalho é tão possível de ocasionar erros no sistema como essa. Nenhuma 
outra parte é tão difícil de ser posteriormente consertada.”
Para compreender melhor a engenharia de requisitos, veremos alguns conceitos e objetivos a seguir 
da Engenharia de Software.
11.3 Engenharia de software
Segundo Rezende (1999), “Engenharia é a arte das construções, embasada no conhecimento 
científico e empírico, adequada ao atendimento das necessidades humanas”.
Engenharia de Software é a metodologia de desenvolvimento e a manutenção de sistemas modulares, 
com as seguintes características (REZENDE, 1999):
87
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
— Adequação aos requisitos funcionais do negócio do cliente e seus respectivos procedimentos 
pertinentes.
— Efetivação de padrões de qualidade e produtividade em suas atividades e produtos.
— Fundamentação na tecnologia da informação disponível, viável e oportuna.
— Planejamento e gestão de atividades, recursos, custos e datas.
Segundo Pressman (2002), Engenharia de Software é:
— “O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter 
economicamente um software que seja confiável e que funcione eficientemente em máquinas 
reais.”
— “Descendente da engenharia de sistemas e de hardware. Abrange um conjunto de três 
elementos fundamentais (métodos, ferramentas e procedimentos), que possibilita ao gerente o 
controle do processo de desenvolvimento do software e oferece ao profissional uma base para 
a construção de software de alta qualidade.”
Segundo Martin (1991), Engenharia de Software é:
– “É o estudo dos princípios e sua aplicação no desenvolvimento e na manutenção de sistemas 
de software.”
– “Tanto a engenharia de software como as técnicas estruturadas são coleções de metodologias 
de software e ferramentas.”
Como conclusão, pode‑se relatar que Engenharia de Software é um conjunto de práticas para 
desenvolvimento de soluções de software, ou seja, roteiro que pode utilizar diversas técnicas.
A sequência de passos preestabelecidos permite optar e variar de técnicas e ferramentas nas suas 
diversas fases (REZENDE, 1999).
11.4 Objetivos da engenharia de software
De um modo geral, considera‑se que os objetivos primários da Engenharia de Software são o 
aprimoramento da qualidade dos produtos de software e o aumento da produtividade dos engenheiros de 
software, além do atendimento aos requisitos de eficácia e eficiência, ou seja, efetividade (MAFFEO, 1992).
A Engenharia de Software visa a sistematizar a produção, a manutenção, a evolução e a recuperação de 
produtos intensivos de software, de modo que ocorra dentro de prazos e custos estimados, com progresso 
controlado e utilizando princípios, métodos, tecnologia e processos em contínuo aprimoramento. Os 
produtos desenvolvidos e mantidos, seguindo um processo efetivo e segundo preceitos da Engenharia 
88
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
de Software asseguram, por construção, qualidade satisfatória, apoiando adequadamente os seus 
usuários na realização de suas tarefas, operam satisfatória e economicamente em ambientes reais e 
podem evoluir continuamente, adaptando‑se a um mundo em constante evolução (FIORINI, 1998).
Associando a esses objetivos, o termo engenharia pretende indicar que o desenvolvimento de 
software deve submeter‑se a leis similares às que governam a manufatura de produtos industriais em 
engenharias tradicionais, pois ambos são metodológicos (MAFFEO, 1992).
Com basenos objetivos da Engenharia de Software, fica evidente a necessidade da adoção de um 
modelo sistêmico para padronizar e gerenciar os processos de desenvolvimento de software.
11.5 Crise do software
Para generalizar o termo, ocorre quando o software não satisfaz seus envolvidos, sejam clientes 
e/ou usuários, desenvolvedores ou empresa (REZENDE, 1999).
A expressão “crise do software”, que começou a ser utilizada na década de 1960, tem historicamente 
aludido a um conjunto de problemas recorrentemente enfrentados no processo de desenvolvimento 
(construção, implantação e manutenção) de software (MAFFEO, 1992).
Esses problemas não se referem apenas a programas que não funcionam. Na verdade, a chamada 
“crise do software” abrange todos os problemas relacionados a (REZENDE, 1999):
— Como sistemas computacionais são construídos.
— Como sistemas computacionais são implantados, referindo‑se aqui ao processo de substituir 
sistemas antigos, desativando sistemas correntemente em operação, ou ao processo de instalar 
um sistema inteiramente novo.
— Como é provida a manutenção da quantidade crescente de software construído, associado a 
sistemas computacionais cada vez mais complexos.
— Como fazer face à crescente demanda para construção de software, visando a satisfazer ao 
conjunto enormemente variado de anseios por informatização, atualmente detectado na 
sociedade moderna.
— Como administrar as questões comportamentais, envolvendo os clientes e/ou usuários, a 
política, a cultura e a filosofia empresarial.
Apesar da enorme variedade de problemas que caracterizam a crise do software, engenheiros de 
software e gerentes de projetos para desenvolvimento de sistemas computacionais tendem a concentrar 
suas preocupações no seguinte aspecto: “A enorme imprecisão das estimativas de cronogramas e de 
custos de desenvolvimento” (tabelas 2, 3, 4 e 5) (LEE, 2002).
89
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
A não implementação da engenharia de requisitos permite erros no levantamento dos requisitos do 
sistema e somente percebidos na implantação do sistema, gerando, assim, uma fase de manutenção e 
correção do software interminável, excedendo no custo dessa fase (tabela 2) e alongando o prazo de 
término substancialmente (tabela 3).
Tabela 6 – Excedentes de custo (LEE, 2002) Tabela 3 – Excedente de prazo (LEE, 2002)
Excedentes de custo
% Excedente de custo % de respostas
<20% 15,5%
21% – 50% 31,5%
51% – 100% 29,6%
101% – 200% 10,2%
201% – 400% 8,8%
>400% 4,4%
Excedente de prazo
% Excedente de prazo % de respostas
<20% 13,9%
21% – 50% 18,3%
51% – 100% 20,0%
101% – 200% 35,5%
201% – 400% 11,2%
>400% 1,1%
O custo do desenvolvimento do software varia de acordo com cada fase de seu processo (tabela 4).
No entanto, com a implementação da engenhara de requisitos, os erros de levantamento de requisitos 
identificados na fase de análise do projeto de software reduzem o custo para correção (tabela 5).
Tabela 7 – Custos em projeto de software por fase de desenvolvimento (LEE, 2002)
Custos em projeto de software por fase de desenvolvimento
Etapa de trabalho %
Análise de requisitos 3
Desenho 8
Programação 7
Testes 15
Manutenção 67
90
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
Tabela 8 – Custos para correção de erros de software (LEE, 2002)
Custos para correção de erros de software
Fase de desenvolvimento
do software
% de
desvios ($) 
Erros
introduzidos (%)
Erros
encontrados (%)
Custo relativo para 
correção
Análise de requisitos 5 55 18 1,0
Desenho 25 30 10 1,0 – 1,5
Teste do código e da unidade 10 
Teste de integração 50 10 50 1,0 – 5,0
Validação e documentação 10 
Manutenção operacional 5 22 10 – 100
“Muitos desses erros poderiam ser evitados se as organizações dispusessem de um processo de 
engenharia de requisitos definido, controlado, medido e aprimorado. No entanto, percebe‑se que para 
muitos profissionais de informática esses conceitos não são muito claros, o que certamente dificulta a 
ação dos gerentes no sentido de aprimorar os seus processos de desenvolvimento.” (BLASCHEK, 2003)
11.6 Anticrise do software
Segundo Rezende (1999), pode‑se resumir que a anticrise é a união e o trabalho conjunto e 
harmonioso de três elementos: empresa (alta administração), cliente e/ou usuário e a unidade de 
informática (desenvolvedores de soluções).
Na prática, cabe, principalmente, à unidade de informática aceitar esse conceito e fazer o possível 
para a efetivação dessa tese (anticrise), utilizando‑se de todos os recursos disponíveis para tal.
A unidade de informática é um dos principais agentes de mudança nas organizações, preocupando‑se 
com o negócio empresarial, auxiliando efetivamente os gestores nos processos de tomada de decisão, 
tanto operacionais, como gerenciais e estratégicas.
11.7 Qualidade de software
Atingir um alto nível de qualidade de produto ou serviço é o objetivo da maioria das organizações. 
Atualmente, não é mais aceitável entregar produtos com baixa qualidade e reparar os problemas 
e as deficiências depois que os produtos foram entregues ao cliente (SOMMERVILLE, 2003).
Segundo Machado (2001), para muitos engenheiros de software, a qualidade do processo de 
software é tão importante quanto à qualidade do produto. Assim, na década de 1990 houve uma grande 
preocupação com a modelagem e as melhorias no processo de software. Abordagens importantes como 
as normas ISO 9000 e a ISO/ IEC 12207, o modelo CMM (Capability Maturity Model) e o SPICE (Software 
Process Improvement and Capability dEtermination) sugerem que, melhorando o processo de software, 
podemos melhorar a qualidade dos produtos.
91
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
A qualidade é consequência dos processos, das pessoas e da tecnologia. A relação entre a 
qualidade do produto e cada um desses fatores é complexa. Por isso, é muito mais difícil controlar o grau 
de qualidade do produto do que controlar os requisitos (PÁDUA, 2003).
Prevê‑se que na primeira década dos anos 2000, após ajustarem seus processos para a produção de 
software de qualidade dentro de prazos e orçamentos confiáveis, as organizações foram pressionadas 
por seus concorrentes a reduzir substancialmente os prazos para a entrega de produtos. Organizações 
que sejam capazes de integrar, harmonizar e acelerar seus processos de desenvolvimento e manutenção 
de software terão a primazia do mercado (MACHADO, 2001).
A globalização da economia vem influenciando as empresas produtoras e prestadoras de serviços 
de software a alcançar o patamar de qualidade e produtividade internacional para enfrentarem a 
competitividade cada vez maior. A norma internacional NBR ISO/IEC 12207 – Tecnologia da Informação 
– Processos de Ciclo de Vida de Software (ISO12207, p. 97) é usada como referência em muitos países, 
inclusive no Brasil, para alcançar esse diferencial competitivo (MACHADO, 2001).
A norma ISO/IEC 12207 trata os requisitos do software como fator fundamental no processo de ciclo 
de vida do software, gerando documentação para a fase de desenvolvimento do software, possibilitando 
que o produto seja verificado e validado posteriormente, atendendo as necessidades do adquirente.
Diante desse fato, podemos afirmar que, por falta de utilização de métodos e modelos de 
gerenciamento da qualidade de software com base em requisitos, produzimos softwares de qualidade 
contestável e participando efetivamente da “crise do software” (PRESSMAN, 2002).
11.8 Produto de software
Quando entregamos a um cliente um pacote bem delimitado e identificado, podemos dizer que 
entregamos um produto (SPINOLA, 1998).
A definição para produto de software, segundo a norma IEEE‑STD‑610 (IEEE, 1990), é:
“O conjunto completo, ou qualquer dos itens individuaisdo conjunto, de programas de computador, 
procedimentos e documentação associada e dados designados para liberação para um cliente ou usuário 
final.” (PAULK, 1995)
11.9 Processo de software
O conceito de processo de software se baseia no conceito generalizado de processo, que pode ser 
definido como uma sequência de estados de um sistema que se transforma (SPINOLA, 1998).
O SEI (Software Engineering Institute), da Carnegie Melon University, propõe o seguinte:
“Um processo é uma sequência de passos realizados para um dado propósito. Colocado de 
maneira mais simples, processo é aquilo que você faz. Processo é aquilo que as pessoas fazem, usando 
92
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
procedimentos, métodos, ferramentas e equipamentos, para transformar matéria‑prima (entradas) em 
produto (saída) que tenha valor para o cliente.” (PAULK, 1995)
“O processo de software pode ser definido como um conjunto de atividades, métodos, práticas e 
transformações que as pessoas empregam para desenvolver e manter software e os produtos associados 
(exemplo: planos de projeto, documentos de projeto [design], código, casos de teste e manual do 
usuário).” (PAULK, 1995)
11.10 Requisitos
Os problemas que os engenheiros de software têm para solucionar são, muitas vezes, imensamente 
complexos. Compreender a natureza dos problemas pode ser muito difícil, especialmente se o sistema 
for novo. Consequentemente, é difícil estabelecer com exatidão o que o sistema deve fazer. As descrições 
das funções e das restrições são os requisitos para o sistema (SOMMERVILLE, 2003).
Os requisitos (requirements) podem ser definidos como as necessidades básicas do cliente, geralmente 
explicitadas como condição de negócio no contrato com o fornecedor. São características, tais como 
especificações técnicas, prazo de entrega e garantia que o cliente “requer” do produto (MCT, 2002).
“Uma condição ou capacidade necessitada por um usuário, para resolver um problema ou alcançar 
um objetivo.” (IEEE, 1990)
Segundo Tonsig (2003), os requisitos compõem o conjunto de necessidades estabelecidas pelo cliente/
usuário do sistema que definem a estrutura e o comportamento do software que será desenvolvido.
Segundo Pádua (2003), o fluxo de requisitos reúne as atividades que visam a obter o enunciado 
completo, claro e preciso dos requisitos de um produto de software. Esses requisitos devem ser 
levantados pela equipe do projeto, em conjunto com representantes do cliente, usuários chave e outros 
especialistas da área de aplicação.
Os requisitos de sistema de software são, frequentemente, classificados como funcionais ou não 
funcionais ou como requisitos de domínio (SOMMERVILLE, 2003):
• Requisitos funcionais: são declarações de funções que o sistema deve fornecer, como o sistema 
deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em 
alguns casos, os requisitos funcionais podem também explicitamente declarar o que o sistema 
não deve fazer. Exemplo: o software deve permitir ampla consulta sobre os dados dos pedidos do 
cliente, inclusive via internet (TONSIG, 2003).
• Requisitos não funcionais: são restrições sobre os serviços ou as funções oferecidas pelo sistema. 
Entre eles destacam‑se restrições de tempo, restrições sobre o processo de desenvolvimento, 
padrões, entre outros. Exemplo: o acesso aos recursos do software deve ser restrito a pessoas 
autorizadas (TONSIG, 2003).
93
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
• Requisitos de domínio: são requisitos que se originam do domínio de aplicação do sistema e 
que refletem características desse domínio. Podem ser requisitos funcionais ou não funcionais. 
Exemplo: deve haver uma interface‑padrão com o usuário para todos os bancos de dados, que 
terá como base o padrão X (SOMMERVILLE, 2003).
11.11 Engenharia de requisitos
“O processo de descobrir, analisar, documentar e verificar as funções e as restrições do sistema é 
chamado de engenharia de requisitos.” (SOMMERVILLE, 2003)
Engenharia de requisitos, uma subárea da engenharia de software, tem por objetivo tratar o processo 
de definição dos requisitos de software. Para isso, estabelece um processo pelo qual o que deve ser feito 
é elicitado, modelado e analisado. Esse processo deve lidar com diferentes pontos de vista e usar uma 
combinação de métodos, ferramentas e pessoal. O produto desse processo é um modelo, do qual um 
documento chamado “requisitos’” é produzido. Esse processo é perene e acontece em um contexto 
previamente definido e que chamamos de “universo de informações” (LEITE, 2001).
“O conjunto de técnicas empregadas para levantar, detalhar, documentar e validar os requisitos de 
um produto forma a engenharia de requisitos.” (PÁDUA, 2003)
A engenharia de requisitos fornece um mecanismo adequado para entender o que o cliente deseja, 
analisar as necessidades, avaliar a exequibilidade, negociar uma solução razoável, especificar a solução 
de maneira não ambígua, validar a especificação e administrar os requisitos à medida que eles são 
transformados em um sistema em operação. O processo da engenharia de requisitos pode ser descrito 
em seis passos distintos (PRESSMAN, 2002):
• elicitação de requisitos;
• análise e negociação de requisitos;
• especificação de requisitos;
• modelagem do sistema;
• validação de requisitos;
• gestão de requisitos.
11.11.1 Elicitação de requisitos
Certamente, parece muito simples – pergunte ao cliente, aos usuários e a outros quais são os 
objetivos do sistema ou do produto, o que precisa ser conseguido, como o sistema ou o produto se 
encaixa nas necessidades do negócio e, finalmente, como o sistema ou o produto vai ser usado no dia a 
dia. Mas não é simples – é muito difícil.
94
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
“Na indústria de software, as necessidades dos clientes são muito difíceis de serem acessadas ou 
descobertas. Geralmente, devem‑se deixar margens nos sistemas para futuras mudanças. Os requisitos, 
geralmente, são vagos” (FREITAS, 2000).
A seguir, vários problemas que nos ajudam a compreender por que a elicitação de requisitos é difícil 
(PRESSMAN, 2002):
• Problemas de escopo: o limite do sistema é mal definido. Detalhes técnicos desnecessários que 
podem confundir, em vez de esclarecer, os objetivos globais do sistema.
• Problemas de entendimento: os clientes não estão completamente certos do que é 
necessário, têm pouca compreensão das capacidades e das limitações de seu ambiente 
computacional e têm dificuldade de comunicar as necessidades ao engenheiro de sistemas, 
omitem informações que acreditam serem “óbvias”, especificam requisitos que são ambíguos 
ou impossíveis de testar.
• Problemas de volatilidade: os requisitos mudam ao longo do tempo.
Para ajudar a contornar esses problemas, os engenheiros de sistemas devem abordar a atividade de 
coleta de requisitos de um modo organizado.
Sommerville (2003) sugere um conjunto de diretrizes detalhadas para a elicitação de requisitos, que 
são resumidas nos seguintes passos:
• Avalie a viabilidade técnica e de negócios do sistema proposto.
• Identifique as pessoas que vão ajudar a especificar os requisitos e compreenda seu viés 
organizacional.
• Defina o ambiente técnico no qual o sistema ou produto vai ser colocado.
• Identifique “restrições de domínio” que limitam a funcionalidade ou o desempenho do sistema ou 
do produto a ser construído.
• Defina um ou mais métodos de elicitação de requisitos (entrevistas, reuniões etc.).
• Solicite a participação de muitas pessoas de modo que os requisitos sejam definidos de diferentes 
pontos de vista e certifique‑se de identificar a razão de cada requisito que é registrado.
• Identifique requisitos ambíguos como candidatos para prototipagem.• Crie cenários de uso para ajudar clientes/usuários a melhor identificar requisitos chave.
95
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
Os produtos de trabalho produzidos como consequência das atividades de elicitação de requisitos 
vão variar de acordo com o tamanho do sistema ou do produto a ser construído. Para a maioria dos 
sistemas, os produtos de trabalho incluem:
• uma declaração da necessidade e da viabilidade;
• uma declaração delimitada de escopo do sistema ou do produto;
• uma lista de usuários e interessados que participaram da atividade de elicitação de requisitos;
• uma descrição do ambiente técnico do sistema;
• uma lista de requisitos e as restrições do domínio que se aplicam a cada um;
• um conjunto de cenários de utilização que fornece entendimento do uso do sistema ou do produto 
em diferentes condições de operação;
• quaisquer protótipos desenvolvidos para melhor definir os requisitos.
Cada um desses produtos de trabalho é revisado por todo o pessoal que participou da elicitação de 
requisitos.
11.11.2 Análise e negociação de requisitos
Uma vez reunidos os requisitos, os produtos de trabalho mencionados anteriormente 
formam a base para a análise de requisitos. A análise categoriza os requisitos e os organiza 
em subconjuntos relacionados, explora cada um em relação aos demais, examina‑os quanto 
à consistência, omissões e ambiguidade; e ordena‑os com base nas necessidades dos clientes/
usuários (PRESSMAN, 2002).
À medida que a análise de requisitos começa, as seguintes perguntas são formuladas e respondidas:
• Cada requisito está consistente com o objetivo global do sistema/produto?
• Todos os requisitos foram especificados no nível de abstração adequado?
• O requisito é realmente necessário, ou pode ser essencial para o objetivo do sistema?
• Cada requisito é limitado e não ambíguo?
• Cada requisito tem atribuição? Isto é, uma fonte está associada a cada requisito?
• Algum requisito conflita com outros requisitos?
96
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
• Cada requisito é realizável no ambiente técnico que vai alojar o sistema ou o produto?
• Cada requisito pode ser testado, quando estiver implementado?
Não é incomum que os clientes/usuários peçam mais do que pode ser conseguido, considerando os 
recursos limitados do negócio.
O engenheiro de sistemas precisa reconciliar esses conflitos por intermédio de um processo de 
negociação. Os riscos associados a cada requisito são identificados e analisados. Estimativas grosseiras 
do esforço de desenvolvimento são feitas e usadas para avaliar o impacto de cada requisito no custo do 
projeto e no prazo de entrega. Usando uma abordagem iterativa, requisitos são eliminados, combinados 
ou modificados de modo que cada parte alcance algum grau de satisfação.
11.11.3 Especificação de requisitos
No contexto de sistemas baseados em computador, o termo especificação significa coisas diferentes 
para pessoas diferentes. Uma especificação pode ser um documento escrito, um modelo gráfico, um 
modelo matemático formal, uma coleção de cenários de uso, um protótipo ou qualquer combinação 
desses elementos. Para sistemas grandes, um documento escrito, combinando descrições em linguagem 
natural, e modelos gráficos podem ser a melhor abordagem. Cenários de uso podem, entretanto, ser 
tudo que é necessário para produtos ou sistemas pequenos que residem em ambientes técnicos bem 
entendidos (PRESSMAN, 2002).
11.11.4 Modelagem do sistema
Cada sistema baseado em computador pode ser modelado como uma transformação de informação, 
usando um gabarito entrada – processamento – saída. Essa visão pode ser estendida para incluir duas 
características adicionais dos sistemas – processamento e manutenção de interface com o usuário e 
autoteste (PRESSMAN, 2002).
11.11.5 Validação de requisitos
Os produtos de trabalho produzidos como consequência da engenharia de requisitos são avaliados 
quanto à qualidade durante o passo de validação. A validação de requisitos examina a especificação 
para garantir que todos os requisitos do sistema tenham sido declarados de modo não ambíguo; que 
as inconsistências, as omissões e os erros tenham sido detectados e corrigidos e que os produtos 
de trabalho estejam de acordo com as normas estabelecidas para o processo, o projeto e o produto 
(PRESSMAN, 2002).
11.11.6 GESTÃO DE REQUISITOS
Gestão de requisitos é um conjunto de atividades que ajuda a equipe de projeto identificar, controlar 
e rastrear requisitos e modificações de requisitos em qualquer época, à medida que o projeto prossegue 
(PRESSMAN, 2002).
97
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
“Geralmente, requisitos corretos no início do projeto são mudados posteriormente.” (FREITAS, 2000)
11.12 Ergonomia cognitiva
A Ciência Cognitiva, segundo Peters (2001), é o estudo de como o conhecimento é adquirido, representado 
na memória e utilizado na resolução de problemas. A abordagem da ciência cognitiva à programação 
de computadores enfoca como os programadores representam o conhecimento, como as estruturas dos 
programas são aprendidas e como o conhecimento é aplicado no desenvolvimento de software.
A ergonomia cognitiva é o estudo das habilidades de resolução de problemas, análise de informações 
e procedurais relativas à influência dos fatores humanos. As questões dos fatores humanos relativos a 
estruturas de linguagem de programação, programação de computadores e interação homem‑computador 
são respondidas de forma cognitiva em termos de esforço mental exigido.
A limitação da memória de curto prazo é o grave obstáculo ao desenvolvimento de programas de 
computador em grande escala. Isso significa que não é possível compreender tantos elementos ao mesmo 
tempo a ponto de controlarem as várias conexões existentes entre os componentes de um sistema de 
software. O agrupamento é visto como uma forma de combater esse problema. O agrupamento é o 
processo de reunir itens com atributos semelhantes ou relacionados para formar um item único.
O agrupamento fornece a base para os modelos de compreensão de programas úteis na manutenção 
de software, ou seja, a compreensão do software é auxiliada por representações internas de um sistema 
com planos e esquemas. O processo de entendimento coincide documentos do sistema, como requisitos, 
aos planos de programação utilizando regras do discurso para selecionar planos. O resultado de cada 
coincidência de um documento externo com um plano é a representação mental atualizada, que é 
armazenada como um novo plano.
Concluindo, podemos detectar que a dificuldade de compreender e especificar requisitos em diferentes 
níveis de abstração vai defrontar com a nossa capacidade cognitiva de adquirir o conhecimento para 
criar soluções de software. O estudo da ergonomia cognitiva, sua aplicação e a implementação da 
engenharia de requisitos serão fatores críticos de sucesso no desenvolvimento de software.
11.13 Conclusão
É importante que os desenvolvedores de software reconheçam que não é possível desenvolver 
sistemas com qualidade, cumprir prazos e custos e atender às expectativas dos usuários sem ter um 
processo de desenvolvimento de requisitos definido, compreendido e utilizado por toda a equipe.
Quanto à engenharia de requisitos, podemos acrescentar:
— Adequação aos princípios e aos objetivos da Engenharia de Software.
— O nível de complexidade da sua implementação pode ser dimensionado de acordo com o porte 
do sistema, viabilizando para as pequenas organizações desenvolvedoras de software.
98
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
— Possibilita ser fator crítico para o sucesso no desenvolvimento de software.
— Pode serutilizada alinhada às normas ISO de qualidade de software 12207, 9000‑3.
— Com a sua implementação, é possível contribuir para o fim da “crise do software”.
— Alinhada à ciência cognitiva, permite transformar problemas em agrupamentos menores, 
facilitando a compreensão e a criação de solução.
— Permite para micro, pequenas e médias empresas que possuem recursos humanos e financeiros 
limitados à possibilidade de competir com as empresas de maior porte.
— Com os processos de desenvolvimento de software controlados, documentados e gerenciados; 
o pequeno desenvolvedor poderá assumir projetos de alta complexidade, aliados a técnica e a 
criatividade, pois terá mais chance de sucesso.
— Melhor capacitado e provedor de metodologias que levam ao desenvolvimento de software 
com qualidade, o desenvolvedor poderá criar soluções que atendam as necessidades e os 
requisitos da empresa, contribuindo para criação de vantagens competitivas, sustentando as 
bases estratégicas das organizações.
11.14 Referências bibliográficas
BLASCHEK, José Roberto. Gerência de Requisitos, o principal problema dos projetos de software. 
Artigo Universidade Federal do Rio de Janeiro. Rio de Janeiro, 2003.
BROOKS, F. Essence and accidents to software engineering. Los Alamos, California, IEEE Computer 
Society, v. 4, n. 3, 1987.
FILHO, Wilson de Pádua Paula. Engenharia de Software. Rio de Janeiro: Ed. LTC, 2003.
FIORINI, Soeli T. et al. Engenharia de Software com CMM. Rio de Janeiro: Ed. Brasport, 1998.
FREITAS, Luís Ricardo Napolitano. Projetos em Tecnologia da Informação – Como acertar através da 
análise dos erros. Dissertação de Mestrado. São Paulo: USP, 2000.
IEEE STD. 610 12‑1990, IEEE Standard Glossary of Software Engineering Terminology. IEEE, 
Piscataway, NJ, 1997.
LEE, Richard C.; TEPFENHART, William M. UML e C++ – Guia de desenvolvimento orientado a objeto. 
São Paulo: Ed. Makron Books, 2002.
LEITE, Julio Cesar Sampaio do Prado. In WEBER, Kival Chaves et al. Qualidade e Produtividade em 
Software. São Paulo: Ed. Makron Books, 2001.
99
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
MACHADO, Cristina Ângela Filipak. In WEBER, Kival Chaves et al. Qualidade e Produtividade em 
Software. São Paulo: Ed. Makron Books, 2001.
MAFFEO, Bruno. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro: Ed. Campus, 
1992.
MARTIN, James. Engenharia da Informação. Rio de Janeiro: Ed. Campus, 1991.
MINISTÉRIO DA CIÊNCIA E TECNOLOGIA. Secretaria de Política de Informática, Qualidade e 
Produtividade no Setor de Software Brasileiro. Brasília, n. 4, 2002.
NBR ISO/IEC 12207:1997. Tecnologia de Informação – Processos de Ciclo de Vida de Software. Rio de 
Janeiro: ABNT – Associação Brasileira de Normas Técnicas.
PAULK, M. C. et al. The Capatibility Maturity Model – Guidelines for improving the software process. 
Addison Wesley, SEI series, 1995.
PETERS, James F. et al. Engenharia de Software. Rio de Janeiro: Ed. Campus, 2001.
PRESSMAN, Roger S. Engenharia de Software. Rio de Janeiro: Ed. McGraw‑Hill, 2002.
REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informações. Rio de Janeiro: Ed. 
Brasport, 1999.
SEI – Software Engineering Institute. Carnegie Melon University, http://www.sei.cmu.edu.
SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Ed. Pearson Education, 2003.
SPINOLA, Mauro de Mesquita. Diretrizes para o desenvolvimento de software de sistemas 
embutidos. Tese de Doutorado. São Paulo: USP, 1998.
TONSIG, Sérgio Luiz. Engenharia de Software. São Paulo: Ed. Futura, 2003.
12 QUAlIDADE DE SOfTwARE
12.1 Introdução
Em um ambiente competitivo e de mudança cada vez mais complexo, a gestão adequada da 
informação assume uma importância decisiva no processo de tomada de decisão nas organizações.
Tratando‑se de um tema simultaneamente abrangente e especializado, a adoção da Engenharia de 
Software como linha base da Gestão da Informação, possibilitará, não só desenvolver e consolidar os 
conhecimentos no desenvolvimento de software, bem como preparar os micro, os pequenos e os médios 
100
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
desenvolvedores para encarar com confiança os novos desafios no mundo dos negócios e também 
reforçar as competências profissionais, mantendo‑se atualizado em relação ao potencial dos sistemas 
de informação e das novas tecnologias em uma perspectiva empresarial e competitiva globalmente.
A partir do conhecimento adquirido da Engenharia de Requisitos de Software, o desenvolvedor será 
elemento multiplicador de soluções, contribuindo e agregando valor aos sistemas novos e para os já 
existentes, com aplicação de metodologias e tecnologias adequadas, capazes de gerir com sucesso as 
informações relevantes aos negócios aplicáveis, trazendo às organizações vantagens competitivas.
No estudo da Engenharia de Software, o autor Roger S. Pressman (2002) demonstra preocupação 
com a “crise do software” que, atualmente, ele intitula como “aflição crônica”, chegando a determinar 
números expressivos sobre a não finalização de projetos de sistemas começados e não terminados.
Em um mundo cada vez mais com recursos financeiros escassos, como é possível aceitar tal 
desperdício de tempo e dinheiro? O mesmo autor também aponta para o possível problema causador 
de tal absurdo: “A falta de adoção de métodos, ferramentas e procedimentos no desenvolvimento de 
software e a difícil relação de entendimento entre o usuário com o analista desenvolvedor”.
Várias técnicas de modelagem foram criadas e o analista desenvolvedor, mesmo assim, ainda 
tem dificuldades de realizar um projeto de sistemas livre de manutenções e retrabalhos, condenando 
diretamente a qualidade do produto.
A adoção da norma ISO/IEC 12207:1997 pelo micro, pelo pequeno e pelo médio desenvolvedor 
de software direciona como estruturar e gerenciar o ciclo de desenvolvimento, proporcionando 
acompanhamento de todo o processo, permitindo que o software venha representar a realidade da 
empresa modelada para geração de um sistema customizado, atendendo seus requisitos e as necessidades 
dessa empresa.
Adotar a norma permite padronizar os processos de desenvolvimento de software, aumentando 
a aderência a uma ferramenta de apoio a modelagem do software, agregando a elas facilidades de 
relacionamento e compreensão do usuário e do desenvolvedor, utilizando métodos sistêmicos que 
diminuirão erros na modelagem e, por consequência, a manutenção exagerada, eliminação de custos 
indevidos, extinção do tempo desnecessário dedicado ao retrabalho, obtendo qualidade no software, 
bem como criar a real possibilidade de extrair de um sistema informações relevantes que venham não 
só para contribuir com a decisão, mas para ser um fator de excelência empresarial, permitindo novos 
negócios, permanência e sobrevivência em um mercado atuante.
12.2 Relevância
Segundo o Ministério da Ciência e Tecnologia (2002), a participação de mercado das micro, das 
pequenas e das médias empresas desenvolvedoras de software corresponde a 65,1% do total (tabela 1). 
Diante da dimensão desse mercado ainda em franca expansão, motivou a prestar atenção especial para 
esse tema.
101
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
Tabela 9 – Porte das organizações, segundo comercialização bruta anual (2002)
Porte das organizações
Portes %
Micro 16,5
Pequena 25,3
Média 23,3
Grande 34,9
Atualmente, com a visão global permitindo a participação nas exportações de software para outros 
países, cada vez mais a qualidade no processo de desenvolvimento e do produto de software ganha 
maior observação e adoção das melhores práticas e soluções tecnológicas que atendam aos requisitos 
estabelecidos.
12.3 Engenharia de software
Segundo Rezende (1999), “Engenharia é a arte das construções,embasada no conhecimento 
científico e empírico, adequada ao atendimento das necessidades humanas”.
Engenharia de Software é a metodologia de desenvolvimento e a manutenção de sistemas modulares, 
com as seguintes características (REZENDE, 1999):
— Adequação aos requisitos funcionais do negócio do cliente e seus respectivos procedimentos 
pertinentes.
— Efetivação de padrões de qualidade e produtividade em suas atividades e produtos;
— Fundamentação na tecnologia da informação disponível, viável e oportuna.
— Planejamento e gestão de atividades, recursos, custos e datas.
Segundo Pressman (2002), Engenharia de Software é:
— “O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter 
economicamente um software que seja confiável e que funcione eficientemente em máquinas 
reais.”
— “Descendente da engenharia de sistemas e de hardware. Abrange um conjunto de três 
elementos fundamentais (métodos, ferramentas e procedimentos), que possibilita ao gerente o 
controle do processo de desenvolvimento do software e oferece ao profissional uma base para 
a construção de software de alta qualidade.”
102
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
Segundo Martin (1991), Engenharia de Software é:
– “É o estudo dos princípios e sua aplicação no desenvolvimento e na manutenção de sistemas 
de software.”
– “Tanto a engenharia de software como as técnicas estruturadas são coleções de metodologias 
de software e ferramentas.”
Como conclusão, pode‑se relatar que Engenharia de Software é um conjunto de práticas para 
desenvolvimento de soluções de software, ou seja, roteiro que pode utilizar diversas técnicas.
A sequência de passos preestabelecidos permite optar e variar de técnicas e ferramentas nas suas 
diversas fases (REZENDE, 1999).
12.4 Objetivos da engenharia de software
De um modo geral, considera‑se que os objetivos primários da Engenharia de Software são 
o aprimoramento da qualidade dos produtos de software e o aumento da produtividade dos 
engenheiros de software, além do atendimento aos requisitos de eficácia e eficiência, ou seja, 
efetividade (MAFFEO, 1992).
A Engenharia de Software visa a sistematizar a produção, a manutenção, a evolução e a recuperação de 
produtos intensivos de software, de modo que ocorra dentro de prazos e custos estimados, com progresso 
controlado e utilizando princípios, métodos, tecnologia e processos em contínuo aprimoramento. Os 
produtos desenvolvidos e mantidos, seguindo um processo efetivo e segundo preceitos da Engenharia 
de Software asseguram, por construção, qualidade satisfatória, apoiando adequadamente os seus 
usuários na realização de suas tarefas, operam satisfatória e economicamente em ambientes reais e 
podem evoluir continuamente, adaptando‑se a um mundo em constante evolução (FIORINI, 1998).
Associando a esses objetivos, o termo engenharia pretende indicar que o desenvolvimento de 
software deve submeter‑se a leis similares às que governam a manufatura de produtos industriais em 
engenharias tradicionais, pois ambos são metodológicos (MAFFEO, 1992).
Com base nos objetivos da Engenharia de Software, fica evidente a necessidade da adoção de um 
modelo sistêmico para padronizar e gerenciar os processos de desenvolvimento de software.
12.5 Crise do software
Para generalizar o termo, ocorre quando o software não satisfaz seus envolvidos, sejam clientes 
e/ou usuários, desenvolvedores ou empresa (REZENDE, 1999).
A expressão “crise do software”, que começou a ser utilizada na década de 1960, tem historicamente 
aludido a um conjunto de problemas recorrentemente enfrentados no processo de desenvolvimento 
(construção, implantação e manutenção) de software (MAFFEO, 1992).
103
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
Esses problemas não se referem apenas a programas que não funcionam. Na verdade, a chamada 
“crise do software” abrange todos os problemas relacionados a (REZENDE, 1999):
— Como sistemas computacionais são construídos.
— Como sistemas computacionais são implantados, referindo‑se aqui ao processo de substituir 
sistemas antigos, desativando sistemas correntemente em operação, ou ao processo de instalar 
um sistema inteiramente novo.
— Como é provida a manutenção da quantidade crescente de software construído, associado a 
sistemas computacionais cada vez mais complexos.
— Como fazer face à crescente demanda para construção de software, visando a satisfazer ao 
conjunto enormemente variado de anseios por informatização, atualmente detectado na 
sociedade moderna.
— Como administrar as questões comportamentais, envolvendo os clientes e/ou usuários, a 
política, a cultura e a filosofia empresarial.
Apesar da enorme variedade de problemas que caracterizam a crise do software, engenheiros de 
software e gerentes de projetos para desenvolvimento de sistemas computacionais tendem a concentrar 
suas preocupações no seguinte aspecto: “A enorme imprecisão das estimativas de cronogramas e de 
custos de desenvolvimento” (tabelas 2, 3, 4 e 5) (LEE, 2002).
Tabela 10 – Custos em projeto de software por fase de desenvolvimento (LEE, 2002)
Custos em projeto de software por fase de desenvolvimento
Etapa de trabalho %
Análise de requisitos 3
Desenho 8
Programação 7
Testes 15
Manutenção 67
Tabela 11 – Custos para correção de erros de software (LEE, 2002)
Custos para correção de erros de software
Fase de desenvolvimento
do software
% de desvios 
($) 
Erros 
introduzidos (%)
Erros 
encontrados (%) 
Custo relativo 
para correção
Análise de requisitos 5 55 18 1,0
Desenho 25 30 10 1,0 – 1,5
Teste do código e da unidade 10 
Teste de integração 50 10 50 1,0 – 5,0
104
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
Validação e documentação 10 
Manutenção operacional 5 22 10 – 100
Tabela 12 – Excedentes de custo (LEE, 2002)
Excedentes de custo
% Excedente de custo % de Respostas
<20% 15,5%
21% – 50% 31,5%
51% – 100% 29,6%
101% – 200% 10,2%
201% – 400% 8,8%
>400% 4,4%
Tabela 13 – Excedente de prazo (LEE, 2002)
Excedente de prazo
% Excedente de prazo % de respostas
<20% 13,9%
21% – 50% 18,3%
51% – 100% 20,0%
101% – 200% 35,5%
201% – 400% 11,2%
>400% 1,1%
12.6 Anticrise do software
Segundo Rezende (1999), pode‑se resumir que a anticrise é a união e o trabalho conjunto e 
harmonioso de três elementos: empresa (alta administração), cliente e/ou usuário e a unidade de 
informática (desenvolvedores de soluções).
Na prática, cabe, principalmente, à unidade de informática aceitar esse conceito e fazer o possível 
para a efetivação dessa tese (anticrise), utilizando‑se de todos os recursos disponíveis para tal.
A unidade de informática é um dos principais agentes de mudança nas organizações, preocupando‑se 
com o negócio empresarial, auxiliando efetivamente os gestores nos processos de tomada de decisão, 
tanto operacionais, como gerenciais e estratégicas.
12.7 Qualidade de software
Atingir um alto nível de qualidade de produto ou serviço é o objetivo da maioria das organizações. 
Atualmente, não é mais aceitável entregar produtos com baixa qualidade e reparar os problemas e as 
deficiências depois que os produtos foram entregues ao cliente (SOMMERVILLE, 2003).
105
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
Segundo Machado (2001), para muitos engenheiros de software, a qualidade do processo de 
software é tão importante quanto à qualidade do produto. Assim, na década de 1990 houve uma grande 
preocupação com a modelagem e as melhorias no processo de software. Abordagens importantes como 
as normas ISO 9000 e a ISO/ IEC 12207, o modelo CMM (Capability Maturity Model) e o SPICE (Software 
Process Improvement and Capability dEtermination)sugerem que, melhorando o processo de software, 
podemos melhorar a qualidade dos produtos.
A qualidade é consequência dos processos, das pessoas e da tecnologia. A relação entre a qualidade 
do produto e cada um desses fatores é complexa. Por isso, é muito mais difícil controlar o grau de 
qualidade do produto do que controlar os requisitos (PÁDUA, 2003).
Prevê‑se que na primeira década dos anos 2000, após ajustarem seus processos para a produção de 
software de qualidade dentro de prazos e orçamentos confiáveis, as organizações foram pressionadas 
por seus concorrentes a reduzir substancialmente os prazos para a entrega de produtos. Organizações 
que sejam capazes de integrar, harmonizar e acelerar seus processos de desenvolvimento e manutenção 
de software terão a primazia do mercado (MACHADO, 2001).
Segundo o Ministério da Ciência e Tecnologia (2002), ainda que divulgados na década de 1990, o 
conhecimento, a utilização das normas e os modelos para qualidade de software estão distantes de se 
tornar realidade nas empresas desenvolvedoras de software (tabelas 6, 7, 8 e 9).
Tabela 14 – Conhecimento da Norma ISO/IEC 12207 (MCT, 2002)
Conhecimento da Norma NBR ISO/IEC 12207
 – Processos de ciclo de vida de software–
Categorias Total Micro Pequena Média Grande
Conhece e usa sistematicamente 3,9 1,4 3,8 2,6 9,1
Conhece e começa a usar 8,3 6,1 6,8 7,7 14,8
Conhece, mas não usa 55,1 48,6 51,1 64,1 67,0
Não conhece 32,7 43,9 38,3 25,6 9,1
Tabela 15 – Conhecimento da Norma ISO 9000 (MCT, 2002)
Conhecimento das Normas ISO 9000 – Gestão da qualidade
Categorias Total Micro Pequena Média Grande
Conhece e usa sistematicamente 19,4 3,4 16,3 34,1 44,0
Conhece e começa a usar 14,8 14,1 18,5 12,2 12,1
Conhece, mas não usa 52,4 62,4 50,4 43,9 41,8
Não conhece 13,4 20,1 14,8 9,8 2,2
106
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
Tabela 16 – Conhecimento do modelo CMM (MCT, 2002)
Conhecimento do modelo CMM – Capability Maturity Model
Categorias Total Micro Pequena Média Grande
Conhece e usa sistematicamente 3,9 0,7 2,9 2,5 11,4
Conhece e começa a usar 17,1 3,4 20,4 30,0 29,5
Conhece, mas não usa 53,7 62,2 48,9 47,5 48,9
Não conhece 25,3 33,8 27,7 20,0 10,2
Tabela 17 – Conhecimento do projeto SPICE (MCT, 2002)
 Conhecimento do projeto SPICE – Software Process Improvement
and Capability dEtermination (Technical Report ISO/IEC TR 15504)
Categorias Total Micro Pequena Média Grande
Conhece e usa sistematicamente 1,0 2,0 ‑ ‑ 1,1
Conhece e começa a usar 3,2 1,4 3,0 5,1 5,7
Conhece, mas não usa 56,7 49,0 50,4 59,0 77,3
Não conhece 39,1 47,6 46,6 35,9 15,9
Diante desse fato, podemos afirmar que, por falta de utilização de normas ou modelos de qualidade 
de software, produzimos softwares de qualidade contestável e participando efetivamente da “crise do 
software” (PRESSMAN, 1995).
12.7.1 Produto de software
Quando entregamos a um cliente um pacote bem delimitado e identificado, podemos dizer que 
entregamos um produto (SPINOLA, 1998).
A definição para produto de software, segundo a norma IEEE‑STD‑610 (IEEE, 1990), é:
“O conjunto completo, ou qualquer dos itens individuais do conjunto, de programas de computador, 
procedimentos e documentação associada e dados designados para liberação para um cliente ou usuário 
final.” (PAULK, 1995)
12.7.2 Processo de software
O conceito de processo de software se baseia no conceito generalizado de processo, que pode ser 
definido como uma sequência de estados de um sistema que se transforma (SPINOLA, 1998).
O SEI (Software Engineering Institute), da Carnegie Melon University, propõe o seguinte:
“Um processo é uma sequência de passos realizados para um dado propósito. Colocado de 
maneira mais simples, processo é aquilo que você faz. Processo é aquilo que as pessoas fazem, usando 
107
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
procedimentos, métodos, ferramentas e equipamentos, para transformar matéria‑prima (entradas) em 
produto (saída) que tenha valor para o cliente.” (PAULK, 1995)
“O processo de software pode ser definido como um conjunto de atividades, métodos, práticas e 
transformações que as pessoas empregam para desenvolver e manter software e os produtos associados 
(exemplo: planos de projeto, documentos de projeto (design), código, casos de teste e manual do 
usuário).” (PAULK, 1995)
12.8 ISO/IEC 12207
Segundo Machado (2001), a globalização da economia vem influenciando as empresas produtoras e 
prestadoras de serviços de software a alcançar o patamar de qualidade e produtividade internacional para 
enfrentarem a competitividade cada vez maior. A norma internacional NBR ISO/IEC 12207 – Tecnologia 
da Informação – Processos de Ciclo de Vida de Software (ISO12207: 97) é usada como referência em 
muitos países, inclusive no Brasil, para alcançar esse diferencial competitivo.
Figura 7 – Arquitetura da norma NBR ISO 12207 (MACHADO, 2001)
Ela tem por objetivo auxiliar os envolvidos na produção de software a definir seus papéis, por meio 
de processos bem definidos e proporcionar às organizações que a utilizam um melhor entendimento das 
atividades a serem executadas nas operações que envolvem, de alguma forma, o software.
A arquitetura descrita na norma (figura anterior) (MACHADO, 2001) utiliza uma terminologia bem 
definida e é composta de: processos, atividades e tarefas para aquisição, fornecimento, desenvolvimento, 
operação e manutenção do software.
A norma estabelece uma arquitetura de alto nível para o ciclo de vida do software que abrange 
desde a concepção até a descontinuidade dele. Essa arquitetura é baseada em processos‑chave e no 
inter‑relacionamento entre eles e segue dois princípios básicos:
108
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
— Modularidade: os processos têm alta coesão e baixo acoplamento, ou seja, todas as partes 
de um processo são fortemente relacionadas e o número de interfaces entre os processos é 
mantido ao mínimo.
— Responsabilidade: cada processo na norma é de responsabilidade de uma “parte envolvida”, 
que pode ser uma organização ou parte dela. As partes envolvidas podem ser da mesma 
organização ou de organizações diferentes.
Segundo Machado (2001), na norma ISO/IEC 12207, os processos que envolvem o ciclo de vida 
do software são agrupados em três classes que representam sua natureza. Cada processo é definido 
em termos de suas próprias atividades e cada atividade é adicionalmente definida em termos de suas 
tarefas (figura).
Figura 8 – Processos de ciclo de vida do software (ISO12207: 97)
12.8.1 Processos fundamentais
Os processos fundamentais atendem, no início, à contratação entre o adquirente e o fornecedor e a 
execução do desenvolvimento, da operação ou da manutenção de produtos de software durante o ciclo 
de vida do software (MACHADO, 2001).
109
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
Nas pequenas empresas de desenvolvimento, os processos fundamentais acontecem ainda que não 
estruturados pela adoção de uma norma, mas pela necessidade da realização da prestação de serviço ou 
do desenvolvimento dentro da própria empresa.
O planejamento é feito de modo precário pela ausência constante de documentação entre o 
desenvolvedor e o adquirente. Existe resistência em ambas as partes interessadas em gerar documentação, 
pois, normalmente, acreditam estar “perdendo tempo” na especificação dos requisitos e no planejamento 
em um todo do projeto. Muitos desenvolvedores partem direto para o desenvolvimento (codificação) 
e depois são levados a um processo de correção e manutenção interminável, provocando desgaste da 
relação comercial estabelecida, com o não cumprimento de prazos de entrega e o custo do projeto que 
foi orçadopor uma estimativa aleatória, acumulando prejuízos intangíveis.
12.8.2 Processos de apoio
Os processos de apoio auxiliam o sucesso e a qualidade do projeto de software e contribuem para eles.
Um processo de apoio é empregado e executado quando necessário para documentação, gerência 
de configuração, garantia da qualidade, processo de verificação, processo de validação, revisão conjunta, 
auditoria e resolução de problemas (MACHADO, 2001).
A documentação do software será a última tarefa que o desenvolvedor irá se preocupar, sendo 
tratado como se não tivesse que acontecer antes do desenvolvimento propriamente dito, a fim de ser 
possível acompanhar se os requisitos do projeto foram atendidos ou se nem foram especificados no 
momento oportuno. Os processos de verificação e validação ocorrem unilateralmente, ou seja, “esse 
requisito era óbvio, nem precisava mencionar” e para atender as necessidades do adquirente, esse 
processo será repetido inúmeras vezes, alongando a manutenção e atrasando o funcionamento e o 
atendimento das necessidades do negócio.
12.8.3 Processos organizacionais
Os processos organizacionais são empregados por uma organização para estabelecer e implementar 
uma estrutura constituída pelos processos de ciclo de vida e pelo pessoal envolvido no desenvolvimento 
do software. Eles são, geralmente, empregados fora do domínio de projetos e contratos específicos; 
entretanto, os ensinamentos desses projetos e contratos contribuem para a melhoria da organização, 
são eles: processos de gerência, infraestrutura, melhoria e treinamento (MACHADO, 2001).
O processo de gerência depende diretamente do porte da empresa. Em alguns casos existirá a pessoa 
responsável; em outros, o próprio desenvolvedor assumirá o papel, mas não a função, ou seja, 
aparecerá como responsável, mas devido à carência de tempo e de recursos humanos fará todo 
o trabalho e não praticará a gerência do projeto.
Para implementar os processos de infraestrutura, melhoria e treinamento, é fundamental a figura 
de gerência que exercerá acompanhamento das necessidades do projeto e seus devidos ajustes quanto 
à estrutura necessária para um desenvolvimento dentro dos requisitos do projeto, do dinamismo 
110
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
necessário para melhoria contínua do processo e os devidos treinamentos para adequação das 
tecnologias especificadas nos requisitos.
12.8.4 Processos de adaptação
O processo de adaptação define as atividades necessárias para adaptar a norma para sua aplicação 
na organização ou em projetos. A adaptação deve ser executada com base em alguns fatores que 
diferenciam uma organização ou projeto de outros, dentre os quais a estratégia de aquisição, modelos 
de ciclo de vida de projeto, características de sistemas, software e cultura organizacional. A existência 
desse processo permite que a norma seja adaptável a qualquer projeto, organização, modelo de ciclo de 
vida, cultura e técnica de desenvolvimento (MACHADO, 2001).
A adaptação inicia‑se com a disseminação da norma, promovendo o conhecimento de sua estrutura, 
a necessidade de sua adoção e os principais benefícios e medindo os impactos que ela trará a partir de 
sua implantação. Diante da realidade e do “caos” em que as pequenas empresas de desenvolvimento 
vivem com a falta de estrutura e planejamento, os empresários desenvolvedores se voltarão para o 
processo de desenvolvimento de software com qualidade, observando a “fatia” de mercado que poderá 
expandir seus negócios e ser ponto de referência no mercado de software brasileiro.
Atualmente, já existe um movimento das empresas para adoção de normas e modelos de 
maturidade do processo de desenvolvimento de software, buscando melhor produtividade e com 
ênfase em promover uma reengenharia nos processos de desenvolvimento de software, que até então 
eram, basicamente, vindos da experiência dos “desenvolvedores de código” e não de gestores de projetos 
de grande expressão, e que assumem papel de alta relevância nas empresas para se obter vantagens 
competitivas em um mercado que busca a informação certa no momento certo.
12.9 Conclusão
Todas as normas e os modelos de qualidade para software têm por objetivo buscar organização e 
melhoria contínua no processo de desenvolvimento de software, porém fica identificado que a ISO/IEC 
12.207 possui pontos importantes a serem ressaltados:
— Adequação aos princípios e aos objetivos da Engenharia de Software.
— Possibilita ser fator crítico para o sucesso no desenvolvimento de software.
— Adaptabilidade na inexistência de alguns processos, dependendo do porte da empresa 
desenvolvedora de software (ISO/IEC 12207: 97).
— Com a sua adoção é possível contribuir para o fim da “crise do software”.
— Permite para micro, pequenas e médias empresas que possuem recursos humanos e financeiros 
limitados à possibilidade de competir com as empresas de maior porte.
111
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
— Com os processos de desenvolvimento de software controlados, documentados e gerenciados, 
o pequeno desenvolvedor poderá assumir projetos de alta complexidade, aliados à técnica e à 
criatividade, pois terá mais chance de sucesso.
— Melhor capacitado e provedor de metodologias que levam ao desenvolvimento de software 
com qualidade, o desenvolvedor poderá criar soluções que atendam as necessidades e os 
requisitos da empresa, contribuindo para criação de vantagens competitivas, sustentando as 
bases estratégicas das organizações.
12.10 Referências bibliográficas
FILHO, Wilson de Pádua Paula. Engenharia de Software. Rio de Janeiro: Ed. LTC, 2003.
FIORINI, Soeli T. et al. Engenharia de Software com CMM. Rio de Janeiro: Ed. Brasport, 1998.
IEEE STD. 610 12‑1990, IEEE Standard Glossary of Software Engineering Terminology. IEEE, 
Piscataway, NJ, 1997.
LEE, Richard C.; TEPFENHART, William M. UML e C++ – Guia de desenvolvimento orientado a objeto. 
São Paulo: Ed. Makron Books, 2002.
MACHADO, Cristina Ângela Filipak. In WEBER, Kival Chaves et al. Qualidade e Produtividade em 
Software. São Paulo: Ed. Makron Books, 2001.
MAFFEO, Bruno. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro: Ed. Campus, 
1992.
MARTIN, James. Engenharia da Informação. Rio de Janeiro: Ed. Campus, 1991.
MINISTÉRIO DA CIÊNCIA E TECNOLOGIA. Secretaria de Política de Informática. Qualidade e 
Produtividade no Setor de Software Brasileiro. Brasília, n. 4, 2002.
NBR ISO/IEC 12207:1997, Tecnologia de Informação – Processos de Ciclo de Vida de Software. Rio de 
Janeiro: ABNT – Associação Brasileira de Normas Técnicas.
PAULK, M. C. et al. The Capatibility Maturity Model – Guidelines for improving the software process. 
Addison Wesley, SEI series, 1995.
PRESSMAN, Roger S. Engenharia de Software. São Paulo: Ed. Makron Books, 1995.
PRESSMAN, Roger S. Engenharia de Software. Rio de Janeiro: Ed. McGraw‑Hill, 2002.
REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informações. Rio de Janeiro: Ed. 
Brasport, 1999.
112
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
SEI – Software Engineering Institute. Carnegie Melon University, http://www.sei.cmu.edu.
SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Ed. Pearson Education, 2003.
SPINOLA, Mauro de Mesquita. Diretrizes para o desenvolvimento de software de sistemas 
embutidos. Tese de Doutorado. São Paulo: USP, 1998.
13 GERêNCIA DE CONfIGURAçãO E mUDANçAS
13.1 Introdução
Em um ambiente de desenvolvimento de software altamente complexo, a gerência de 
configuração de software tem caráter essencial quando as modificações e as alterações são 
inevitáveis durante todo o ciclo de vida do software. Essas alterações geram confusão aos 
desenvolvedores. A confusão aparece quando essas alterações não são analisadasantes de serem 
feitas, não são registradas antes de serem codificadas e não são relatadas aos envolvidos no 
sentido de controlar e evitar erros.
Tratando‑se de sistemas, em que a confiabilidade é fator de sucesso em sua utilização, a falta de 
controle nas alterações pode trazer transtornos de ordem humana, cumprimento de objetivos e prejuízos 
nos negócios.
A gerência de configuração de software é um tema, simultaneamente, abrangente e 
especializado, dentro das melhores práticas da Engenharia de Software que possibilita consolidar 
os conhecimentos no desenvolvimento de software, bem como preparar os micro, os pequenos 
e os médios desenvolvedores para encarar com confiança os novos desafios no mundo dos 
negócios e também reforçar as competências profissionais, mantendo‑se atualizado em relação 
ao potencial dos sistemas de informação e das novas tecnologias em uma perspectiva empresarial 
e competitiva globalmente.
A partir do conhecimento adquirido, o desenvolvedor será elemento multiplicador de soluções, 
contribuindo e agregando valor aos sistemas com aplicação de metodologias e tecnologias adequadas, 
capazes de gerir com sucesso as informações relevantes aos negócios aplicáveis, trazendo às organizações 
vantagens competitivas.
No estudo da Engenharia de Software, o autor Roger S. Pressman (2002) demonstra preocupação 
com a “crise do software” que, atualmente, ele intitula como “aflição crônica”, chegando a determinar 
números expressivos sobre a não finalização de projetos de sistemas começados e não terminados. As 
tabelas 1 e 2 mostram os números de tal problema.
113
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
Tabela 18 – Excedentes de custo (LEE, 2002) Tabela 2 – Excedentes de prazo (LEE, 2002)
Excedentes de prazo
% Excedente de prazo % de respostas
<20% 13,9%
21% – 50% 18,3%
51% – 100% 20,0%
101% – 200% 35,5%
201% – 400% 11,2%
>400% 1,1%
Excedentes de custo
% Excedente de custo % de respostas
<20% 15,5%
21% – 50% 31,5%
51% – 100% 29,6%
101% – 200% 10,2%
201% – 400% 8,8%
>400% 4,4%
Em um mundo cada vez mais com recursos financeiros escassos, como é possível aceitar tal 
desperdício de tempo e dinheiro? O mesmo autor também aponta para o possível problema causador 
de tal absurdo: “A falta de adoção de métodos, ferramentas e procedimentos no desenvolvimento de 
software e a difícil relação de entendimento entre o usuário com o analista desenvolvedor”.
Várias técnicas de gestão de projetos foram criadas e o desenvolvedor, mesmo assim, ainda tem 
dificuldades de realizar projetos de sistemas livres de manutenções e correções constantes, condenando 
diretamente a qualidade do produto entregue.
A adoção da Gerência de Configuração de Software no desenvolvimento de sistemas, pelo micro, pelo 
pequeno e pelo médio desenvolvedor de software, direciona como estruturar, gerenciar e controlar por 
todo o ciclo de vida do software, proporcionando acompanhamento de todo o processo, permitindo que 
o software venha representar a realidade da empresa modelada para geração de um sistema adequado, 
atendendo seus requisitos e as necessidades dessa empresa.
Adotar modelos de gestão permite padronizar os processos de desenvolvimento de software, 
aumentando a aderência a uma ferramenta de apoio, agregando a elas facilidades de relacionamento 
e compreensão do usuário e do desenvolvedor, utilizando métodos sistêmicos que diminuirão erros 
e, por consequência, a manutenção exagerada, a eliminação de custos indevidos e a extinção do 
tempo desnecessário dedicado ao retrabalho, obtendo qualidade no software, bem como criar a real 
possibilidade de extrair de um sistema informações relevantes que venham não só para contribuir com 
a decisão, mas para ser um fator de excelência empresarial, permitindo novos negócios, permanência e 
sobrevivência em um mercado atuante.
114
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
13.2 Relevância
Segundo o Ministério da Ciência e Tecnologia (2002), a participação de mercado das micro, das 
pequenas e das médias empresas desenvolvedoras de software corresponde a 65,1% do total (tabela). 
Diante da dimensão desse mercado ainda em franca expansão, motivou a prestar atenção especial para 
esse tema.
Tabela 19 – Porte das organizações, segundo comercialização bruta anual (2002)
Porte das organizações
Portes %
Micro 16,5
Pequena 25,3
Média 23,3
Grande 34,9
Atualmente, com a visão global permitindo a participação nas exportações de software para outros 
países, cada vez mais a qualidade no processo de desenvolvimento e do produto de software ganha 
maior observação e adoção das melhores práticas e soluções tecnológicas.
Outro fator motivador é o baixo índice de utilização das normas e dos modelos de qualidade de 
software, em que o processo de gerência de configuração de software está inserido. Conclui‑se que, 
consequentemente, a sua adoção também está comprometida. As tabelas 4, 5, 6 e 7 mostram esses 
índices.
Tabela 20 – Conhecimento da norma ISO/IEC 12207 (MCT, 2002)
Conhecimento da Norma NBR ISO/IEC 12207
 – Processos de ciclo de vida de software – 
Categorias Total Micro Pequena Média Grande
Conhece e usa sistematicamente 3,9 1,4 3,8 2,6 9,1
Conhece e começa a usar 8,3 6,1 6,8 7,7 14,8
Conhece, mas não usa 55,1 48,6 51,1 64,1 67,0
Não conhece 32,7 43,9 38,3 25,6 9,1
Tabela 21 – Conhecimento da norma ISO 9000 (MCT, 2002)
Conhecimento das normas ISO 9000 – Gestão da qualidade
Categorias Total Micro Pequena Média Grande
Conhece e usa sistematicamente 19,4 3,4 16,3 34,1 44,0
Conhece e começa a usar 14,8 14,1 18,5 12,2 12,1
Conhece, mas não usa 52,4 62,4 50,4 43,9 41,8
Não conhece 13,4 20,1 14,8 9,8 2,2
115
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
Tabela 22 – Conhecimento do modelo CMM (MCT, 2002)
Conhecimento do modelo CMM – Capability Maturity Model
Categorias Total Micro Pequena Média Grande
Conhece e usa sistematicamente 3,9 0,7 2,9 2,5 11,4
Conhece e começa a usar 17,1 3,4 20,4 30,0 29,5
Conhece, mas não usa 53,7 62,2 48,9 47,5 48,9
Não conhece 25,3 33,8 27,7 20,0 10,2
Tabela 23 – Conhecimento do projeto SPICE (MCT, 2002)
 Conhecimento do projeto SPICE – Software Process Improvement
and Capability dEtermination (Technical Report ISO/IEC TR 15504)
Categorias Total Micro Pequena Média Grande
Conhece e usa sistematicamente 1,0 2,0 ‑ ‑ 1,1
Conhece e começa a usar 3,2 1,4 3,0 5,1 5,7
Conhece, mas não usa 56,7 49,0 50,4 59,0 77,3
Não conhece 39,1 47,6 46,6 35,9 15,9
13.3 Engenharia de software
Segundo Pressman (2002), Engenharia de Software é:
— “O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter 
economicamente um software que seja confiável e que funcione eficientemente em máquinas 
reais.”
— “Descendente da engenharia de sistemas e de hardware. Abrange um conjunto de três 
elementos fundamentais (métodos, ferramentas e procedimentos), que possibilita ao gerente o 
controle do processo de desenvolvimento do software e oferece ao profissional uma base para 
a construção de software de alta qualidade.”
Engenharia de Software é a metodologia de desenvolvimento e a manutenção de sistemas modulares, 
com as seguintes características (REZENDE, 1999):
• Adequação aos requisitos funcionais do negócio do cliente e seus respectivos procedimentos 
pertinentes.
• Efetivação de padrões de qualidade e produtividade em suas atividades e produtos.
• Fundamentação na tecnologia da informação disponível, viável e oportuna.
• Planejamento e gestão de atividades, recursos, custos e datas.
116
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
Como conclusão, pode‑se relatar que Engenharia de Software é um conjunto de práticas paradesenvolvimento de soluções de software, ou seja, roteiro que pode utilizar diversas técnicas.
A Engenharia de Software visa a sistematizar a produção, a manutenção, a evolução e a recuperação de 
produtos intensivos de software, de modo que ocorra dentro de prazos e custos estimados, com progresso 
controlado e utilizando princípios, métodos, tecnologia e processos em contínuo aprimoramento. Os 
produtos desenvolvidos e mantidos, seguindo um processo efetivo e segundo preceitos da Engenharia 
de Software asseguram, por construção, qualidade satisfatória, apoiando adequadamente os seus 
usuários na realização de suas tarefas, operam satisfatória e economicamente em ambientes reais e 
podem evoluir continuamente, adaptando‑se a um mundo em constante evolução (FIORINI, 1998).
Com base nos objetivos da Engenharia de Software, demonstra a necessidade da adoção de gestão 
sistêmica do processo de desenvolvimento de software com princípios de qualidade para padronizar e 
gerenciar todas as tarefas e fases do projeto.
13.4 Qualidade de software
Atingir um alto nível de qualidade de produto ou serviço é o objetivo da maioria das organizações. 
Atualmente, não é mais aceitável entregar produtos com baixa qualidade e reparar os problemas e as 
deficiências depois que os produtos foram entregues ao cliente (SOMMERVILLE, 2003).
Segundo Machado (2001), para muitos engenheiros de software, a qualidade do processo de 
software é tão importante quanto à qualidade do produto. Assim, na década de 1990 houve uma grande 
preocupação com a modelagem e as melhorias no processo de software. Abordagens importantes como 
as normas ISO 9000 e a ISO/ IEC 12207, o modelo CMM (Capability Maturity Model) e o SPICE (Software 
Process Improvement and Capability dEtermination) sugerem que, melhorando o processo de software, 
podemos melhorar a qualidade dos produtos.
A qualidade é consequência dos processos, das pessoas e da tecnologia. A relação entre a qualidade 
do produto e cada um desses fatores é complexa. Por isso, é muito mais difícil controlar o grau de 
qualidade do produto do que controlar os requisitos (PÁDUA, 2003).
Segundo Machado (2001), a globalização da economia vem influenciando as empresas produtoras 
e prestadoras de serviços de software a alcançar o patamar de qualidade e produtividade internacional 
para enfrentarem a competitividade cada vez maior.
Organizações que sejam capazes de integrar, harmonizar e acelerar seus processos de desenvolvimento 
e manutenção de software terão a primazia do mercado (MACHADO, 2001).
Diante desse fato, podemos afirmar que, por falta de utilização das normas ou dos modelos de 
qualidade de software, produzimos softwares de qualidade contestável e participando efetivamente da 
“crise do software” (PRESSMAN, 2002).
117
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
EngEnharia dE SoftwarE
13.5 Gerência de configuração de software (GCS)
Segundo Babich (1986), gerência de configuração de software é:
“A arte de coordenar o desenvolvimento de software para minimizar a confusão é chamada de 
gerência de configuração. A gerência de configuração é a arte de identificar, organizar e controlar 
modificações de software que está sendo construído por uma equipe de programação. O objetivo é 
maximizar a produtividade pela minimização dos erros.”
Segundo Sommerville (2003), o gerenciamento de configuração (Configuration Management – CM) 
é o desenvolvimento e a aplicação de padrões e procedimentos para gerenciar um produto de sistema 
em desenvolvimento. É necessário gerenciar os sistemas em desenvolvimento, porque, à medida que eles 
se desenvolvem, são criadas muitas versões diferentes de software. Essas versões incorporam propostas 
de mudanças, correções de defeitos e adaptações para diferentes hardwares e sistemas operacionais. É 
possível que haja várias versões em desenvolvimento e em uso ao mesmo tempo. É necessário manter 
o controle das mudanças que foram implementadas e de como essas mudanças foram incluídas no 
software.
O processo de gerência de configuração é um processo de aplicação de procedimentos administrativos 
e técnicos, por todo o ciclo de vida de software, destinado a identificar e definir os itens de software em 
um sistema e estabelecer suas linhas básicas (baseline), controlar as modificações e as liberações dos 
itens, registrar e apresentar a situação dos itens e dos pedidos de modificação, garantir a completeza, a 
consistência e a correção dos itens; e controlar o armazenamento, a manipulação e a distribuição dos 
itens (ISO12207: 97).
Segundo Pressman (2002), a gerência de configuração de software (Software Configuration 
Management – SCM) é uma atividade guarda‑chuva que é aplicada ao longo de todo o processo 
de software. Como modificações podem ocorrer em qualquer época, as atividades de SCM são 
desenvolvidas para identificar as modificações, controlar modificações, garantir que as modificações 
sejam adequadamente implementadas e relatar as modificações a outros interessados.
As mudanças descontroladas em software, geralmente, levam ao caos e/ou à crise de software 
(REZENDE, 1999).
Segundo Pádua (2003), na engenharia de software, os artefatos que devem ser controlados incluem 
a documentação, os modelos e o próprio código (fontes e executável). Mesmo para projetos de porte 
muito pequeno, um mínimo de controle de versões é necessário para evitar o desperdício de trabalho. 
Com o controle de versões conservam‑se versões antigas dos artefatos, que contém material que pode 
vir a ser novamente aproveitado, mas evita‑se que versões mais antigas venham de forma inadvertida, 
a tomar o lugar de versões mais novas. Esse tipo de erro é comum mesmo em projetos individuais e essa 
espécie de desperdício é facilmente evitada.
118
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr
am
ad
or
 -
 d
at
a
Unidade II
13.5.1 Implementação da gerência de configuração de software
Implementar GCS implica adotar procedimentos que afetam todos os setores de uma organização, 
pois ela é um processo complexo que envolve aspectos técnicos, gerenciais e culturais. Seu sucesso 
depende mais de fatores culturais que de fatores técnicos e gerenciais. Seus conceitos são fáceis de 
serem entendidos, mas difíceis de serem colocados em prática (OLIVEIRA, 2001).
A norma IEEE 1042 (1987) descreve as atividades de GCS (IEEE, 1997):
1. Estabelecer baselines.
1.1 Atribuir um identificador exclusivo ao Item de Configuração (IC).
1.2 Criar o documento baseline.
2. Identificar diferentes versões internas.
3. Garantir documentação técnica completa e atualizada do produto.
4. Exigir padrões.
5. Usar o GCS para promover cada IC de uma fase de desenvolvimento ou de teste para outra.
6. Usar o GCS para identificar o envolvimento do cliente nas baselines internas.
Muitas empresas julgam, equivocadamente, que a simples compra de uma ferramenta adequada de 
GCS irá resolver os seus problemas. Pesquisas conduzidas pelo Gartner Group revelam que o custo da 
ferramenta representa apenas 10% no custo total de adoção de GCS. Os restantes 90% relacionam‑se 
com gastos com pessoal, equipamentos etc. (SATC, 1995).
Para assegurar uma solução efetiva de GCS, uma organização deve ater‑se às complexidades que 
surgem quando da implementação de uma modificação. Essas complexidades incluem (OLIVEIRA, 2001):
• Aspectos técnicos: qual ferramenta adotar, como configurá‑la, usabilidade etc.
• Aspectos gerenciais: como planejar o processo, acompanhar modificações, estabelecer prioridades, 
cronogramas etc.
• Aspectos organizacionais: infraestrutura da organização, autoridades e responsabilidades.
• Aspectos culturais: como as pessoas agem em busca dos seus objetivos, qual a cultura existente 
na organização e qual a maneira mais adequada de se fazer mudanças em tal cultura.
119
Re
vi
sã
o:
 N
om
e 
do
 re
vi
so
r -
 D
ia
gr
am
aç
ão
: N
om
e 
do
 d
ia
gr