engenharia_de_software_Unyleya

Prévia do material em texto

Brasília-DF. 
EngEnharia dE SoftwarE 
Elaboração
João Gilberto Pinho
Produção
Equipe Técnica de Avaliação, Revisão Linguística e Editoração
Sumário
APRESENTAÇÃO .................................................................................................................................. 5
ORGANIZAÇÃO DO CADERNO DE ESTUDOS E PESQUISA ..................................................................... 6
INTRODUÇÃO ..................................................................................................................................... 8
UNIDADE I
OBJETIVO DA ENGENHARIA DE SOFTWARE .......................................................................................... 11
CAPÍTULO 1
CONCEITOS DE SOFTWARE E ENGENHARIA DE SOFTWARE ...................................................... 11
CAPÍTULO 2
EVOLUÇÃO DO SOFTWARE.................................................................................................... 16
CAPÍTULO 3
PROCESSO ........................................................................................................................... 22
CAPÍTULO 4
ENGENHARIA DE REQUISITOS ................................................................................................. 28
CAPÍTULO 5
PROCESSO DE ENGENHARIA DE REQUISITOS .......................................................................... 33
CAPÍTULO 6
MODELOS ÁGEIS .................................................................................................................. 35
UNIDADE II
GESTÃO DA ENGENHARIA DE SOFTWARE ............................................................................................ 39
CAPÍTULO 1
MANUTENÇÃO E REENGENHARIA .......................................................................................... 39
CAPÍTULO 2
PROJETOS DE SOFTWARE ...................................................................................................... 42
CAPÍTULO 3
MÉTRICAS DE SOFTWARE ....................................................................................................... 45
CAPÍTULO 4
VALIDAÇÃO .......................................................................................................................... 50
CAPÍTULO 5
DEFEITOS E FALHAS DE SOFTWARE ......................................................................................... 57
CAPÍTULO 6
GARANTIA DE QUALIDADE DE SOFTWARE ............................................................................... 61
PARA (NÃO) FINALIZAR ...................................................................................................................... 66
REFERÊNCIAS .................................................................................................................................... 69
5
Apresentação
Caro aluno
A proposta editorial deste Caderno de Estudos e Pesquisa reúne elementos que se entendem 
necessários para o desenvolvimento do estudo com segurança e qualidade. Caracteriza-se pela 
atualidade, dinâmica e pertinência de seu conteúdo, bem como pela interatividade e modernidade 
de sua estrutura formal, adequadas à metodologia da Educação a Distância – EaD.
Pretende-se, com este material, levá-lo à reflexão e à compreensão da pluralidade dos conhecimentos 
a serem oferecidos, possibilitando-lhe ampliar conceitos específicos da área e atuar de forma 
competente e conscienciosa, como convém ao profissional que busca a formação continuada para 
vencer os desafios que a evolução científico-tecnológica impõe ao mundo contemporâneo.
Elaborou-se a presente publicação com a intenção de torná-la subsídio valioso, de modo a facilitar 
sua caminhada na trajetória a ser percorrida tanto na vida pessoal quanto na profissional. Utilize-a 
como instrumento para seu sucesso na carreira.
Conselho Editorial
6
Organização do Caderno 
de Estudos e Pesquisa
Para facilitar seu estudo, os conteúdos são organizados em unidades, subdivididas em capítulos, de 
forma didática, objetiva e coerente. Eles serão abordados por meio de textos básicos, com questões 
para reflexão, entre outros recursos editoriais que visam a tornar sua leitura mais agradável. Ao 
final, serão indicadas, também, fontes de consulta, para aprofundar os estudos com leituras e 
pesquisas complementares.
A seguir, uma breve descrição dos ícones utilizados na organização dos Cadernos de Estudos 
e Pesquisa.
Provocação
Textos que buscam instigar o aluno a refletir sobre determinado assunto antes 
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor 
conteudista.
Para refletir
Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa e reflita 
sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. É importante 
que ele verifique seus conhecimentos, suas experiências e seus sentimentos. As 
reflexões são o ponto de partida para a construção de suas conclusões.
Sugestão de estudo complementar
Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo, 
discussões em fóruns ou encontros presenciais quando for o caso.
Praticando
Sugestão de atividades, no decorrer das leituras, com o objetivo didático de fortalecer 
o processo de aprendizagem do aluno.
Atenção
Chamadas para alertar detalhes/tópicos importantes que contribuam para a 
síntese/conclusão do assunto abordado.
7
Saiba mais
Informações complementares para elucidar a construção das sínteses/conclusões 
sobre o assunto abordado.
Sintetizando
Trecho que busca resumir informações relevantes do conteúdo, facilitando o 
entendimento pelo aluno sobre trechos mais complexos.
Exercício de fixação
Atividades que buscam reforçar a assimilação e fixação dos períodos que o autor/
conteudista achar mais relevante em relação a aprendizagem de seu módulo (não 
há registro de menção).
Avaliação Final
Questionário com 10 questões objetivas, baseadas nos objetivos do curso, 
que visam verificar a aprendizagem do curso (há registro de menção). É a única 
atividade do curso que vale nota, ou seja, é a atividade que o aluno fará para saber 
se pode ou não receber a certificação.
Para (não) finalizar
Texto integrador, ao final do módulo, que motiva o aluno a continuar a aprendizagem 
ou estimula ponderações complementares sobre o módulo estudado.
8
Introdução
Ao passar do tempo, ninguém imaginava que o software se tornaria um elemento muito 
importante para o mundo e teria a capacidade de manipular a informação. Muitos elementos 
computacionais tiveram mudanças e continuam tendo. Com este crescimento computacional, 
eleva-se a criação de sistemas perfeitos e problemas para quem desenvolve softwares complexos. 
As preocupações dos engenheiros de software para desenvolverem os softwares sem defeitos e 
entregarem estes produtos no tempo marcado leva à aplicação da disciplina de engenharia de 
software. Com o crescimento desse segmento, muitas empresas possuem mais especialistas em 
TI, em que cada um tem sua responsabilidade no desenvolvimento de software e é diferente 
de antigamente que era um único profissional de software que trabalhava sozinho numa sala 
(PRESSMAN, 2006).
O software é o conjunto de vários artefatos e não apenas o código fonte (SOMMERVILLE, 2003).
Realizando uma comparação entre o software e hardware chegamos à seguinte conclusão: O 
software apenas pode ser desenvolvido e realizar a manutenção (mudança) no software é uma 
tarefa complicada, exige grande esforço da equipe de engenheiro de software. Ao passar do tempo 
o software fica deteriorado. Já para o hardware apenas pode ser fabricado e realizar a manutenção 
no hardware é simplesmente trocar à peça que esta em desgaste. Ao passar do tempo o hardware 
desgasta por vários motivos (PRESSMAN, 2006).
Engenharia de software é uma abordagem sistemática e disciplinada para o desenvolvimento de 
software (PRESSMAN, 2006).
Uma das grandes dificuldades da engenharia do software é resolver o problema e deixar o cliente 
satisfeito com o software(JALOTE, 2005).
A engenharia de software foca no software como produto. Não entra neste escopo o softwares 
construídos apenas para passarem o tempo dos programadores (PAULA FILHO, 2009).
No desenvolvimento de um projeto de software quanto mais complexo é o software, maior 
é o empenho que o engenheiro de software deve fazer para desenvolver e tem que ter maior 
gerenciamento (JALOTE, 2005).
Objetivos
 » Promover a formação de profissionais com ética capazes de produzir e manter 
software de alta qualidade e disponibilidade.
9
 » Analisar as necessidades do mercado e identificar as melhores opções abordadas 
pela Engenharia de Software visando projetar, implementar e manter as aplicações 
disponíveis e sem falhas.
 » Compreender os padrões que estabelecem uma identificação de processos e 
atividades a serem executados para o desenvolvimento de software.
11
UNIDADE I
OBJETIVO DA 
ENGENHARIA DE 
SOFTWARE
CAPÍTULO 1
Conceitos de software e engenharia de 
software
O estabelecimento e uso dos princípios da Engenharia a fim de obter software de 
baixo custo que seja confiável e trabalhe com eficiência em máquinas reais.
Fratz Bauer, 1969.
Por que não construir um software como se fosse uma ponte?
Introdução
Ao passar do tempo, ninguém imaginava que o software se tornaria um elemento muito importante 
para o mundo e teria a capacidade de manipular a informação e como muitos elementos 
computacionais tiveram mudanças até hoje e continuam tendo. Com este crescimento computacional 
leva-se à criação de sistemas perfeitos e problemas para quem desenvolve softwares complexos. 
As preocupações dos engenheiros de software para desenvolverem os softwares sem defeitos e 
entregarem estes produtos no tempo marcado, leva à aplicação da disciplina de engenharia de 
software. Com o crescimento desse segmento muitas empresas possuem mais especialistas em 
TI, em que cada um tem sua responsabilidade no desenvolvimento de software,o que é diferente 
de antigamente,em que era um único profissional de software que trabalhava sozinho numa sala 
(PRESSMAN, 2006).
Software 
O software é o conjunto de vários artefatos e não apenas o código fonte (SOMMERVILLE, 2003).
Realizando uma comparação entre o software e hardware, chegamos à seguinte conclusão.
12
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
O software apenas pode ser desenvolvido e realizar a manutenção (mudança) no software é uma 
tarefa complicada, exige grande esforço da equipe de engenheiro de software. Ao passar do tempo 
o software fica deteriorado. Já o hardware apenas pode ser fabricado e realizar a manutenção neste 
é simplesmente trocar a peça que está em desgaste. Ao passar do tempo o hardware desgasta por 
vários motivos (PRESSMAN, 2006).
De acordo Pressman (2006) o software está categorizado nos seguintes tipos, tais como:
 » Software de sistema: São programas que apóiam outros programas, como 
o software que realiza a comunicação com o hardware (sistema operacional) e 
software que ajuda na construção de outro software (compiladores).
 » Software de aplicação: São programas que são desenvolvidos para serem 
executados no negócio de uma empresa determinada.
 » Software científico e de engenharia: São algoritmos que processam números.
 » Software embutido: São programas construídos para executarem dentro de um 
produto específico como as teclas digitais de um forno micro-ondas.
 » Software para linhas de produtos: São os softwares conhecidos como software 
de prateleiras.
 » Software de web: São aplicativos que são executados via internet.
 » Software de inteligência artificial: São softwares que fazem usos de algoritmos 
não numéricos. Estes tipos de software se encaixam na robótica.
 » Computação ubíqua: São softwares que realizam a verdadeira computação 
distribuída. 
 » Software aberto: São softwares que disponibilizam a visualização do código fonte 
da aplicação para o engenheiro de software modificar da maneira que desejar.
 » Software legado: Um programa de computador que foi desenvolvido há muito 
tempo.
Aplicações do software
Segundo sua aplicação, podemos caracterizar o software em categorias sendo:
 » Embutido (Embarcado), quando utilizado para controlar produtos e sistemas para 
os mercados industriais e de consumo.
 » Computador pessoal, quando envolve processamento de textos, planilhas 
eletrônicas, diversões etc.
13
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
 » Web, páginas de internet, hipertexto, imagens, áudio e vídeo.
 » Inteligência artificial, quando faz uso de algoritmos não numéricos para resolver 
problemas que não sejam favoráveis à computação ou à análise direta.
Figura 1. Inteligência Artificial.
Figura adaptada e disponível em: <http://zonadigital.pacc.ufrj.br/ /foto-inteligencia-artificial/>. Acesso em: 1 Set. 2013.
Evolução do software
Para analisarmos a evolução do software podemos dividir sua evolução em quatro fases:
1950 – 1965 (início) 
Hardware com contínuas mudanças poucos métodos sistemáticos aplicações específicas, distribuição 
limitada e nenhuma documentação.
1965 – 1975 (Segunda Era)
Inicia a multiprogramação e sistema multiusuário, propiciando técnicas interativas; aplicações em 
tempo real, banco de dados e produto Software – software houses. 
1975 – 1985 (Terceira Era)
Por meio da evolução e padronização dos processos de comunicação, surgem os sistemas distribuídos, 
interligados pelas redes locais, permitindo a criação de produtos inteligentes que passam a ser mais 
populares pela redução de custo do hardware.
14
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
4a Geração (1985 – ... )
Sistemas desktop poderosos com maior capacidade de processamento e armazenamento, tecnologia 
orientada a objetos, surgem sistemas especialistas, redes neurais artificiais, computação paralela, 
redes de alta velocidade, impacto do consumidor que se torna usuário dos recursos computacionais.
Engenharia de software
Engenharia de software envolve a aplicação prática de conhecimento científico para o projeto e 
construção de programas de computador e a documentação associada necessária para desenvolvê-
los, operá-los e mantê-los. É uma abordagem sistemática e disciplinada para o desenvolvimento de 
software (PRESSMAN, 2006).
Engenharia de software é uma abordagem sistemática para o desenvolvimento, operação, 
manutenção de software, que como já vimos, são programas de computador, procedimentos, regras, 
documentação possivelmente associada, e dados sobre sua operação.
A engenharia de software abrange um conjunto de três elementos fundamentais: 
 » Métodos.
 » Ferramentas.
 » Procedimentos.
Metas: melhorar a qualidade de produtos de software, aumentar a produtividade do pessoal técnico 
e aumentar a satisfação do cliente.
Métodos proporcionam os detalhes de como fazer para construir o software:
 » Planejamento e estimativa de projeto. 
 » Análise de requisitos de software e de sistemas. 
 » Projeto da estrutura de dados. 
 » Algoritmo de processamento. 
 » Codificação. 
 » Teste. 
 » Manutenção.
Ferramentas dão suporte automatizado aos métodos, existem atualmente ferramentas para 
sustentar cada um dos métodos, quando as ferramentas são integradas é estabelecido um sistema de 
suporte ao desenvolvimento de software chamado CASE - Computer Aided Software Engineering.
15
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
Procedimentos constituem o elo entre os métodos e ferramentas:
 » Sequência em que os métodos serão aplicados. 
 » Produtos que se exige que sejam entregues. 
 » Controles que ajudam a assegurar a qualidade e coordenar as alterações. 
 » Marcos de referência que possibilitam administrar o progresso do software.
Ciclo de Vida de Software ou Processo de Software é o conjunto de etapas que envolve, Métodos, 
Ferramentas e Procedimentos. 
Figura 2. Impacto da Mudança.
Fonte: Pressman, Roger S. Software Engineering 5th Edition. New York: McGraw-Hill, 2001. 
O software é o fator de diferenciação de muitos produtos e sistemasbaseados em 
computador. Identifique exemplos de dois ou três produtos e de pelo menos um 
sistema em que o software, não o hardware, é o elemento que faz a diferença.
16
CAPÍTULO 2
Evolução do software
Ciência - Conjunto organizado de conhecimentos relativos a um determinado 
objeto, especialmente os obtidos mediante a observação, a experiência dos fatos e 
um método próprio.
Engenharia - Arte de aplicar conhecimentos científicos e empíricos e certas 
habilitações específicas à criação de estruturas, dispositivos e processos que se 
utilizam para converter recursos naturais em formas adequadas ao atendimento das 
necessidades humanas.
Vê-se que, pelas definições acima, a Ciência focaliza acumulação do conhecimento 
por meio do método científico, com base em experimentos e observações. Já 
a Engenharia aplica esses conhecimentos “ao atendimento das necessidades 
humanas”. Embora o conhecimento seja certamente uma necessidade humana, 
trata-se de uma entre várias outras, sejam necessidades materiais, como alimentação, 
moradia, segurança, ou imateriais, como afeição ou autoestima. A tudo aquilo que 
satisfaz as necessidades, atribui-se um valor. A Engenharia está, portanto, ligada à 
noção de valor, e a Engenharia de Software busca gerar valor com o processamento 
de informação. A noção de valor tem muitas consequências práticas importantes, 
e, de fato, a teoria conhecida como “Engenharia de Software Baseada em Valor” 
representa uma importante escola de pensamento dentro da área.
Evolução
A Engenharia de Software visa a criação de produtos de software que atendam às necessidades 
de pessoas e instituições, e portanto, tenham valor econômico. Para isso, usam-se conhecimentos 
científicos, técnicos e gerenciais, tanto teóricos quanto empíricos. Eles atingem seus objetivos de 
produzir software com alta qualidade e produtividade quanto é praticado por profissionais treinados 
e bem informados, utilizando tecnologias adequadas, dentro de processos que tirem proveito tanto 
da criatividade quanto da racionalização do trabalho.
Primeiros anos - características
No início o desenvolvimento do software era feito virtualmente, sem administração, até que os 
prazos começassem a se esgotar e os custos a subir abruptamente, utilizando a orientação batch 
(em lote) para a maioria dos sistemas.
17
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
Na maior parte, entretanto, o hardware dedicava-se à execução de um único programa que, por 
sua vez, dedicava-se a uma única aplicação específica, o software, por outro lado, era projetado sob 
medida para cada aplicação e tinha uma distribuição relativamente limitada.
No ambiente de software personalizado o projeto era processo implícito realizado no cérebro de 
alguém e a documentação muitas vezes não existia.
Segunda Era – características
Por meio da multiprogramação e dos sistemas multiusuários surgiram novos conceitos de interação 
homem-máquina, avanços da armazenagem on-line levaram à primeira geração de sistemas de 
gerenciamento de banco de dados.
Com o surgimento das “software houses” as aplicações passam a ser distribuídas com maior 
facilidade popularizando sua utilização em um mercado em expansão, fornecendo programas para 
mainframes e minicomputadores. 
Surge a “manutenção de software”.
Terceira Era – características
Surgem as redes globais, as comunicações digitais de largura de banda elevada e a crescente demanda 
de acesso “instantâneo” a dados exigem muito dos desenvolvedores de software. 
 A terceira Era é caracterizada pelo advento e o generalizado uso de microprocessadores, 
computadores pessoais e poderosas estações de trabalho “workstations” de mesa, conceitos de 
interação do homem. 
Quarta Era – características
As tecnologias orientadas a objetos, orientadas a documentos, estão ocupando o lugar das abordagens 
mais convencionais para o desenvolvimento de software em muitas áreas de aplicação.
As técnicas de “quarta geração” para o desenvolvimento de software já estão mudando a maneira 
segundo a qual alguns segmentos da comunidade de software constroem programas de computador.
Os sistemas especialistas e o software de inteligência artificial finalmente saíram do laboratório para 
a aplicação prática em problemas de amplo espectro do mundo real.
Classificação de software
Segundo Verzello podemos classificar software em três tipos, sendo: 
18
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
 » Software de sistema - programas escritos para controlar e coordenar o software.
 » Software de linguagens - são programas que traduzem outros programas 
escritos em linguagens de programação mais ou menos semelhantes à língua inglesa, 
para a forma binária que é a linguagem utilizada pelos componentes do sistema 
computacional e, além disso, os programas escritos para ajudar os desenvolvedores 
a escrever seus programas e a manter os programas já escritos a salvo, em bancos 
de dados especiais.
 » Software de aplicação - são programas escritos para resolver problemas 
comerciais ou prestar outros serviços de processamento de dados aos usuários.
Já Pressman, amplia esta classificação de software para sete categorias, comentando ser uma tarefa 
um tanto difícil desenvolver categorias genéricas para aplicações de software, pois à medida que a 
complexidade do software cresce, desaparece a clara visão em compartimentos.
Seguem-se as categorias sugeridas:
Software básico – é uma coleção de programas escritos para dar apoio a outros programas. A área 
do software básico é caracterizada por:
Forte interação com o hardware de computador; intenso uso por múltiplos usuários;
Operações concorrentes que exigem escalonamento “schedule”; compartilhamento de recursos e 
sofisticada administração do processo;
Estruturas de dados complexas e múltiplas interfaces externas.
Software de tempo real – monitora, analisa e controla eventos do mundo real. 
Entre os elementos do software de tempo real incluem-se: um componente de coleta de dados 
que obtém as informações provenientes de um ambiente externo, um componente de análise que 
transforma as informações conforme a aplicação exige; um componente de controle / saída que 
responde ao ambiente externo e um componente de monitoração que coordena todos os demais 
componentes de forma a resposta em tempo real.
Software comercial – é a maior área particular de software. As aplicações dessa área reestruturam 
os dados de uma forma que facilita as operações comerciais e as tomadas de decisões administrativas. 
Além da aplicação de processamento de dados convencional, as aplicações de software comerciais 
abrangem a computação interativa.
Software científico e de engenharia – tem sido caracterizado por algoritmos de processamento 
de números. As aplicações variam da astronomia à vulcanologia da análise de fadiga mecânica de 
automóveis, à dinâmica orbital de naves espaciais recuperáveis e da biologia molecular à manufatura 
automatizada.
Software embutido – é usado para controlar produtos e sistemas para os mercados industriais e 
de consumo.
19
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
O software embutido (“embedded Software”) reside na memória só de leitura “read only” e 
pode executar funções limitadas e particulares (por exemplo, controle de teclado para fornos de 
microondas) ou oferecer recursos funcionais de controle significativos (por exemplo, funções 
digitais em automóveis, tais como controle, mostradores no painel, sistemas de freio etc.).
Software de computador pessoal – são os softwares para computadores pessoais que entraram 
em efervescência na última década, tais como processamento de textos, planilhas eletrônicas, 
computação gráfica, diversões,gerenciamento de dados, aplicações financeiras pessoais e comerciais, 
redes externas ou acesso a banco de dados, são apenas algumas das centenas de aplicações.
Software de inteligência artificial – faz uso de algoritmos não numéricos para resolver 
problemas complexos que não sejam favoráveis à computaçãoou à análise direta.
Figura 3. Categorias de Software
Outras categorias:
 » Software para rede de computadores. 
 » Software de controle de tráfego aéreo. 
 » Software “Robô”, que são os sistemas desenvolvidos para navegar na rede mundial 
de computadores, a Internet, em que a sua principal atividade é sair vasculhando 
os computadores de todo o mundo, procurando trabalhos desenvolvidos por 
pesquisadores ou profissionais para depois poder referenciá-los em uma busca 
qualquer, por exemplo, o site da “Google” ou “Yahoo”, que tem vários “robosoft” 
que saem pela rede “Internet” buscando assuntos para depois poder fazer referência 
em suas pesquisas.
 » Software aplicativo, efetuar tarefas que sirvam diretamente ao usuário, tipos de 
Software Aplicativo:
 › Processador de textos. 
 › Dicionários eletrônicos. 
 › Desenhos técnicos e artísticos. 
 › Editoração eletrônica (publisher). 
20
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
 › Edição de imagens. 
 › Administração/Contabilidade. 
 › Matemática. 
 › Engenharia e Arquitetura. 
 › Planilhas Eletrônicas. 
 › Medicina. 
 › Jogos. 
 › Periódicos.
 » Software utilitário, tem como função administrar o ambiente, fornece ao usuário 
ferramentas para organizar os discos de dados, verificar disponibilidade de memória, 
corrigir falhas de processamento, úteis ao sistema computacional, Exemplos de 
utilitários:
 › Compactadores. 
 › Formatadores. 
 › Backup. 
 › Desfragmentadores. 
 › Antivírus.
 » Software básico, tem como função fornecer uma interface básica entre hardware e 
usuário, exemplos:
 › MSDOS 
 › OS2, Unix, AIX, Linux, Android. 
 › Windows 3.11, Windows 95, Windows 98, Windows NT, Windows XP, 
Windows 7, Windows 8. 
Linguagem de máquina
A linguagem de máquina é uma representação simbólica do conjunto de instruções da Unidade 
Central de Processamento (CPU). 
21
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
Figura 4. Processador Intel Core I7.
Figura adaptada e disponível em: <http://www.intel.com.br/content/www/br/pt/processors/core/core-i7-processor.html/>. 
Acessado em: 10 Out. 2013.
As linguagens de alto nível permitem que o desenvolvedor de software e o programa sejam 
independentes da máquina. 
Exemplo: Pascal, C, C++, C#, JAVA etc.
No decorrer da última década, um grupo de linguagens de quarta geração ou não procedimentais 
foi introduzido.
Em vez de exigir que o desenvolvedor de software especifique detalhes de procedimentos, a 
linguagem não procedimental subentende um programa especificando o resultado desejado em vez 
de especificar a ação exigida para se conseguir esse resultado. 
O software de apoio converte a especificação do resultado num programa executável em máquina.
22
CAPÍTULO 3
Processo
Existem vários processos de desenvolvimento de software, porém algumas 
atividades fundamentais são comuns a todos eles (SOMMERVILE, 2007). 
A engenharia de software baseada em componentes baseia-se na existência de um 
numero significativo de componentes reusáveis. O processo de desenvolvimento 
do sistema foca a integração desses componentes, em vez de desenvolvê-los a 
partir do zero. Ela tem a vantagem óbvia de reduzir a quantidade de software a ser 
desenvolvido e, desta maneira, reduzir os custos e riscos. Isto também leva a uma 
entrega mais rápida de software. No entanto, compromissos com os requisitos são 
inevitáveis e isso pode levar a um sistema que não atenda às reais necessidades 
dos usuários. Além disso, algum controle sobre a evolução do sistema será perdido 
se novas versões dos componentes reusáveis não estiverem sob controle da 
organização que os utiliza (SOMMERVILLE, 2007).
O Processo do software
A Engenharia de Software engloba o processo do software e as tecnologias utilizadas neste processo. 
O Processo do software é a base para a definição das tarefas requeridas para “construir” um software 
de alta qualidade.
Tecnologia em camadas
Tecnologia em camadas é a aplicação de uma abordagem sistemática, disciplinada e quantitativa 
para o desenvolvimento, operação e manutenção do software (IEEE Standards Collection: Software 
Engineering, IEEE Standard 610.12-1990, IEEE, 1993) , Engenharia de Software é uma tecnologia 
em camadas como podemos ver na figura a seguir:
Figura 5. Tecnologia em Camadas
23
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
Tecnologia em camadas
Foco em qualidade:
 » É a base fundamental da Engenharia de Software.
Processo:
 » Estabelece as fundações. 
 » Une as camadas tecnológicas. 
 » Define um conjunto de Áreas Chave do Processo – KPAs (KPA – Key Process Area). 
 » KPAs formam a base do controle de gerenciamento do projeto do software.
 » KPAs definem. 
 » Contexto da aplicação dos métodos. 
 » Como os Produtos são produzidos (modelos, documentos etc.). 
 » Quais bases são estabelecidas. 
 » Como a qualidade é garantida. 
 » Gerenciamento das mudanças.
Métodos:
 » Detalhes de como fazer. 
 » Definem as características de cada etapa do desenvolvimento do software.
Ferramentas:
 » Apoio automatizado ou semi-automatizado para as camadas de Processo e Métodos. 
 » Sistema de apoio ao desenvolvimento de software: CASE – Computer-Aided 
Software Engineering. 
 » Ferramenta integrada cuja informação criada pode ser utilizada por outra 
ferramenta. 
 » Combina hardware e Software. 
 » Similar as ferramentas CAD/CAE (Computer-Aided Design/Engineering).
24
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
Engenharia é Análise, Projeto, Construção, Verificação e Gerenciamento.
Figura 6. Fases do Processo
 » Qual o problema a ser resolvido?
 » Quais as características do software que será utilizado para resolver o 
problema?
 » Como o software (solução) será obtido?
 » Como o software será construído?
 » Qual método será utilizado para corrigir erros de projeto e construção do 
software?
 » Como o software será mantido (manutenção) a longo prazo quando 
correções, adaptações e melhorias serão solicitadas pelos usuários?
Reengenharia de software
O software se deteriora devido às mudanças do ambiente em que é aplicado, para antecipar estes 
problemas temos a manutenção preventiva também chamada Reengenharia de Software, podemos 
dividir sua atuação em:
 » Revisões Técnicas - garantia de qualidade.
 » Documentação - garantir informações completas.
 » Controle de Mudança - aprovação e acompanhamento.
Para mantermos a qualidade no processo de software é preciso observar os problemas comuns do 
software:
 » Complexidade.
25
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
 » Conformidade. 
 » Invisibilidade.
Como forma de garantira melhoria do processo podemos utilizar os seguintes modelos:
 » CMM.
 » ISO 9000.
 » ISO/IEC 15504 (SPICE).
Ciclos de vida de software
Ciclos de vida de software, os ciclos de vida mais conhecidos são: 
Ciclo de vida clássico (Cascata), modelo mais antigo e o mais amplamente usado na engenharia 
de software, modelado em função do ciclo da engenharia convencional, requer uma abordagem 
sistemática, sequencial ao desenvolvimento de software.
Figura 7. Ciclo de Vida Clássico (Cascata)
Prototipação, processo que possibilita que o desenvolvedor crie um modelo do software que deve 
ser construído, idealmente, o modelo (protótipo) serve como um mecanismo para identificar os 
requisitos de software apropriado para quando o cliente definiu um conjunto de objetivos gerais 
para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes. 
26
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
Figura 8. Prototipação
Ciclo de vida em espiral; Evolução dos Ciclos de Vida Clássico e Prototipação com acréscimo da 
Análise de Risco, o processo é representado por uma espiral de atividades, cada contorno da espiral 
representa uma fase do processo.
Cada fase é precedida de alternativas e análise de risco seguida de avaliação e planejamento para a 
próxima fase.
Figura 9. Ciclo de Vida em Espiral
Ciclo de vida em espiral – Atividades. 
Planejamento- determinação dos objetivos, alternativas e restrições.
Análise de Risco - análise das alternativas e identificação/resolução dos riscos.
Construção (Protótipos) - desenvolvimento do produto no nível seguinte.
Avaliação do Cliente - avaliação do produto e planejamento de novas fases.
27
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
Modelo baseado em componentes, direcionado para o reuso de software propiciando a redução no 
tempo do ciclo de desenvolvimento, redução no custo total do projeto; aumento da produtividade, 
os benefícios são obtidos em função da robustez da biblioteca de componentes.
O UP – Unified Process é o representante de inúmeros processos baseados em componentes que:
 » Usam a UML – Unified Modeling Language. 
 » Uma combinação de desenvolvimento Iterativo e Incremental. 
 » Baseiam-se em uma abordagem de cenários. 
 » Associam funções com um framework de arquitetura.
Técnicas de 4a Geração (4GT)
Ferramentas de software que possibilitam:
Especificar o sistema em uma linguagem de alto nível. 
Gerar o código fonte automaticamente a partir das especificações. 
Escolha de um ciclo de vida
Diferentes modelos de ciclo de vida, cada um tem suas vantagens, cada um tem suas 
desvantagens, os critérios para escolher um modelo incluem:
 » A organização. 
 » Seu gerenciamento. 
 » Capacitação da equipe do projeto. 
 » Natureza do produto.
 » Melhor Sugestão. 
 » Modelo de Processo “Misture-e-Ajuste”. 
28
CAPÍTULO 4
Engenharia de requisitos
Análise de requisitos
Processo de descobrir, analisar, documentar e verificar serviços requeridos para um 
sistema e suas restrições operacionais. 
Desenvolver software é uma atividade complexa por natureza. Uma das 
razões para esta afirmação é que não existe uma única solução para cada 
cenário de desenvolvimento. Além disso, lidamos o tempo todo com pessoas, 
o que torna o sucesso do projeto bastante relacionado à competência da 
equipe e à forma como trabalham, e, para dificultar ainda mais, muitas vezes 
não fazemos uso de um processo bem definido para apoiar as atividades do 
projeto.
Cada vez mais procuramos o apoio dos fundamentos da engenharia de software no 
desenvolvimento de sistemas. Entendemos engenharia de software como sendo, 
de acordo com o IEEE, a aplicação de uma abordagem sistemática, disciplinada e 
quantificável no desenvolvimento, operação e manutenção de software. Sistemática 
porque parte do princípio de que existe um processo de desenvolvimento definindo 
as atividades que deverão ser executadas. Disciplinada porque parte do princípio 
de que os processos definidos serão seguidos. Quantificável porque se deve definir 
um conjunto de medidas a serem extraídas do processo durante o desenvolvimento 
de forma que as tomadas de decisão relacionadas ao desenvolvimento do software 
(por exemplo, melhoria de processo) sejam embasadas em dados reais, e não em 
“achismos”.
Requisito
O requisito pode variar de uma declaração abstrata de alto nível de um serviço ou de uma restrição 
de sistema para uma especificação matemática funcional, isto é inevitável quando os requisitos 
podem servir uma função dual.
Pode ser a base para uma proposta de um contrato – portanto deve ser aberta para interpretação.
Pode ser a base para o contrato em si – portanto deve ser definido em detalhe.
Ambas as declarações podem ser chamadas requisitos. 
29
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
Tipos de requisitos
Requisitos de usuário
Declarações em linguagem natural mais diagramas de serviços que o sistema fornece e suas restrições 
operacionais. Escritos para os usuários.
Requisitos de sistema
Um documento estruturado estabelecendo descrições detalhadas das funções, serviços e restrições 
operacionais do sistema. Define o que deve ser implementado e assim, pode ser parte de um contrato 
entre o cliente e o desenvolvedor.
O sistema libsys
Sistema de biblioteca que fornece uma interface única para uma série de banco de dados de artigos 
em bibliotecas diferentes.
Os usuários podem pesquisar, baixar e imprimir estes artigos para estudo pessoal.
30
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
Classificação dos requisitos
Requisitos funcionais e não funcionais.
Requisitos funcionais são declarações de serviços que o sistema deve fornecer, como o sistema 
deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações, 
descrevem a funcionalidade ou serviços de sistema, dependem do tipo de software, dos usuários 
esperados e o tipo de sistema em que o software é usado, requisitos funcionais de usuário podem ser 
declarações de alto nível do que o sistema deve fazer mas os requisitos funcionais de sistema devem 
descrever os serviços de sistema em detalhe.
Exemplo de requisito funcional:
O usuário deve ser capaz de pesquisar em todo o conjunto inicial de banco de dados ou selecionar 
um subconjunto a partir dele. O sistema deve fornecer telas apropriadas para o usuário ler os 
documentos no repositório de documentos, para todo pedido deve ser alocado um identificador 
único (ORDER_ID) no qual o usuário deve ser capaz de copiar para a área de armazenamento 
permanente da sua conta.
Requisitos não funcionais, são restrições sobre serviços ou funções oferecidas pelo sistema tais 
como restrições de timing, restrições sobre o processo de desenvolvimento, padrões; definem 
propriedades e restrições de sistema, por exemplo, confiabilidade, tempo de resposta e requisitos 
de armazenamento, restrições são capacidade de dispositivos de E/S, representações de sistema, 
podem ainda estar relacionados à portabilidade de SO e de BD.
Requisitos de processo podem também ser especificados impondo uma ferramenta CASE particular, 
linguagem de programação ou método de desenvolvimento, requisitos não funcionais podem ser 
mais críticos do que os requisitos funcionais, se estes não forem atendidos, o sistema é inútil.
Exemplo de requisito não funcional:
31
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
Requisitos de domínio: requisitos que vêm do domínio de aplicação do sistema e que refletem as 
características desse domínio, são derivados do domínio de aplicação e descrevem características de 
sistema que refletem o domínio. Podem restringir os requisitos funcionais existentes ou estabelecer 
como cálculos específicos devem ser realizados, se os requisitos de domínio não forem satisfeitos, o 
sistema pode não funcionar.
Documento de requisitos de software
O documento de requisitos do software deve ser composto por sentenças em linguagem natural, 
seguindo determinados padrões:
1. Use ‘deve’ para requisitos obrigatórios, e ‘deveria’ para requisitos desejáveis.
Exemplo:
“O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 
486 DX ou superior.”
1. Os requisitos devem estar organizados logicamente, como por exemplo, inicialmente 
todos os requisitos de entrada, depois os de processamento e por último os requisitos 
de saída, o documento de requisitos do software deve ser composto por sentenças 
em linguagem natural, seguindo determinados padrões. 
2. Cada requisito deve ter um identificador único, por exemplo, um identificador 
numérico, para posterior referência.
3. Os requisitos do software devem estar divididos em requisitos funcionais e não 
funcionais (de qualidade).
4. Evitar o uso de jargões de computação. 
Existem vários padrões de especificações de requisitos.
Um exemplo:
I. Visão Geral do Sistema. 
II. Requisitos Funcionais. 
III. Requisitos de Qualidade. 
IV. Apêndice. 
Padrão IEEE/ANSI 830/1998.
A Especificação pode ser acompanhada de um PROTÓTIPO executável (ou em papel).
32
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
Formato sugerido pelo padrão IEEE
1. Introdução:
 › Propósito do documento de requisitos. 
 › Escopo do produto. 
 › Definições, acrônimos e abreviaturas. 
 › Referências. 
 › Visão geral do restante do documento. 
2. Descrição geral:
 › Perspectiva do produto.› Funções do produto. 
 › Características dos usuários. 
 › Restrições gerais. 
 › Suposições de dependências. 
3. Requisitos específicos (requisitos funcionais e não funcionais):
 › Apêndices. 
 › Índice. 
1. A análise de requisitos de software é inquestionavelmente a etapa mais 
intensiva em termos de comunicação no processo de engenharia de 
software. Por que a rota de comunicação frequentemente se fecha?
2. Frequentemente existem graves repercussões políticas quando a 
análise de requisitos de software (e/ou análise de sistemas) se inicia. Por 
exemplo, os trabalhadores podem achar que a segurança do emprego 
está ameaçada por um novo sistema automatizado. O que causa tais 
problemas? Como a tarefa de análise pode ser realizada de forma que o 
aspecto político seja minimizado?
3. O que é um requisito e qual a função da análise de requisitos?
33
CAPÍTULO 5
Processo de engenharia de requisitos
Processo de engenharia de requisitos
Usuário sabe pedir o quê realmente quer? 
1. Como saber se vale a pena ou não gastar tempo e esforço com o sistema 
proposto.
Engenharia de requisitos
Quatro fases:
Estudo de viabilidade. 
Elicitação e análise de requisitos. 
Validação dos requisitos. 
Gerenciamento dos requisitos.
Estudo de viabilidade
Um estudo de viabilidade decide se vale a pena ou não gastar tempo e esforço com o sistema proposto. 
É um estudo breve e focalizado que verifica:
Se o sistema contribui para os objetivos da organização. 
Se o sistema pode ser implementado usando tecnologia atual e dentro do orçamento. 
Se o sistema pode ser integrado a outros. 
Elicitação e análise de requisitos
Engenheiros de software, clientes e usuários finais do sistema e outros envolvidos (stakeholders) 
trabalham para aprender:
 » Sobre o domínio da aplicação. 
 » Quais serviços/funcionalidades o sistema deve fornecer. 
34
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
 » O desempenho esperado. 
 » As restrições de hardware, do ambiente, do negócio.
 » Processo interativo com realimentação contínua (cíclico).
Atividades:
 » Obtenção de requisitos (coleta de dados). 
 » Classificação e organização de requisitos. 
 » Priorização e negociação de requisitos. 
 » Documentação de requisitos.
Validação dos requisitos
Dedica-se a mostrar que os requisitos definem o sistema que o cliente realmente deseja, custos de 
erros de requisitos são altos e, desse modo, a validação é muito importante, o custo da reparação de 
um erro de requisitos depois da entrega pode equivaler a 100 vezes o custo de reparação de um erro 
de implementação. 
Gerenciamento dos requisitos
Gerenciamento de requisitos é o processo de gerenciamento de mudanças de requisitos, novos 
requisitos surgem durante o processo, à medida que as necessidades de negócio mudam e uma 
melhor compreensão do sistema é desenvolvida, os diferentes pontos de vista têm requisitos 
diferentes e estes são frequentemente contraditórios.
A validação de requisitos está relacionada às verificações de validade, consistência, completeza, 
realismo e facilidade de verificação.
Mudanças de negócio levam, inevitavelmente, às mudanças de requisitos.
O gerenciamento de requisitos inclui planejamento e gerenciamento de mudanças.
1. Um analista de sistemas pode prover de uma de três áreas: de 
desenvolvimento de sistemas, de uma área usuária ou de alguma 
organização externa. Discuta os prós e contras de cada área. Descreva o 
analista “ideal”.
2. Elementos de sistema comuns são hardware, software e pessoas. 
Quais outros elementos são frequentemente encontrados em sistemas 
baseados em computador? 
35
CAPÍTULO 6
Modelos ágeis
Metodologia ágil para equipes pequenas e médias desenvolvendo software com 
requisitos vagos ou que mudam constantemente.
O que podemos aprender com os modelos ágeis?
Modelos ágeis
Os modelos ágeis fazem parte de um movimento global de profissionais, empresas e instituições, 
chamado de “Manifesto Ágil”, que buscam estabelecer os novos paradigmas para as empresas 
fornecedoras de software, em que a “entrega rápida do software encomendado” é o principal objetivo 
desta abordagem.
Os modelos ágeis surgem como uma reação natural à expansão do CMMI no mercado mundial, 
atingindo não apenas as grandes organizações, mas também as pequenas e médias empresas de 
TI. Dessa forma, estas passam também a conviver com a pressão de organizarem toda sua cadeia 
produtiva, sob o risco de serem simplesmente excluídos do mercado.
As constantes fusões corporativas favoreceram o surgimento das megacorporações globalizadas, 
que necessitam de fornecedores que consigam garantir níveis de serviços em escalas nunca antes 
imaginadas. Sem possuir tantos recursos financeiros disponíveis e prevendo uma dificuldade de 
adequar-se aos padrões estabelecidos pelo mercado mundial, as pequenas e médias empresas 
observam suas oportunidades no mercado serem gradativamente reduzidas.
Trabalhando com modelos ágeis
Neste cenário, a abordagem ágil torna-se uma interessante estratégia de sobrevivência das 
pequenas e médias organizações que não conseguem adequar-se aos rígidos padrões de excelência 
estabelecidos pelo mercado mundial. Para isto, é necessário convencer o mercado de que seguir 
os “métodos tradicionais” tornarão suas empresas mais lentas e caras, que a área de TI segue um 
processo evolutivo diferente de outros setores da economia, e que adotar padrões industriais é um 
grande equívoco estratégico.
De certa forma, os modelos ágeis ressuscitam a ideia da área de desenvolvimento como o centro 
da organização TI. Na abordagem ágil, tudo passa a girar em torno dos desenvolvedores, tudo é 
organizado para dar poder de decisão a estes profissionais que irão encontrar os meios mais 
36
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
adequados para implementar as mudanças no código-fonte e gerar os benefícios esperados no 
projeto, no menor prazo e custo possível.
As abordagens ágeis chamam atenção de muitas empresas e profissionais pela sua simplicidade de 
implementação, pois suas regras são simples de serem seguidas. O sucesso da adoção do modelo 
ágil está intimamente ligado ao comprometimento dos profissionais, pois sua forma de condução 
dos trabalhos possui um alto grau de informalidade.
A abordagem ágil possui um discurso leve, pautado na redução drástica da complexidade dos projetos 
de desenvolvimento e de toda a estrutura da TI, reduzindo em poucos elementos gerenciáveis e 
trabalhando com profissionais com atuação multidisciplinar.
Sua filosofia reforça e incentiva a atuação livre dos profissionais para decidirem como será a melhor 
forma de implementação, apesar de existirem poucas, mas rígidas regras de controle sobre o projeto. 
Incentiva a simplicidade do software e uma estrutura mínima para mantê-lo em funcionamento, 
adicionando flexibilidade e eliminando complexidades ao longo de todo o ciclo de vida deste.
Desta maneira, a abordagem ágil torna-se então um modelo viável de atuação no mercado mundial. 
Possibilitando criar um novo nicho de oportunidades, atraindo investidores que estarão dispostos a 
enfrentar os riscos e as condições impostas pelo modelo ágil.
Os pontos fracos dos modelos ágeis
O modelo ágil possui algumas fraquezas que impedem sua adoção de forma corporativa e podem 
comprometer sua credibilidade e implementação no mercado mundial.
Falta de uma avaliação para atestar empresas com 
abordagens ágeis
A abordagem ágil não possui um modelo de avaliação que garanta ao mercado que os projetos serão 
efetivamente guiados por esta filosofia. Isto significa que qualquer empresa pode pleitear o título de 
empresa ágil, sem necessariamente seguir esta abordagem em seus projetos.
Mesmo que no futuro exista um modelo de avaliação para empresas ágeis, a informalidade do modelo 
tornará qualquer avaliação altamente subjetiva, sem quaisquer evidências de que determinadas 
ações estão realmente acontecendo dentro da filosofia ágil.
As certificações existentes apenas atestamque determinados profissionais estão aptos a aplicar 
as técnicas estabelecidas pelos modelos ágeis. Porém, não existem garantias que estes as aplicam 
adequadamente dentro dos projetos das empresas, ou mesmo se esta filosofia é seguida como 
uma estratégia empresarial ou apenas uma iniciativa isolada de uma equipe dentro da empresa, 
acentuando ainda mais a fragilidade deste modelo.
37
OBJETIVO DA ENGENHARIA DE SOFTWARE │ UNIDADE I
Foco excessivo nos prazos e custos inviabiliza o modelo 
financeiro de longo prazo
Nos modelos controlados, o valor da organização é medida pelo total de controles operacionais 
que uma empresa efetivamente consegue gerenciar em seus projetos, possibilitando que esta 
seja auditada e facilmente avaliada nestes requisitos. Quanto mais controles forem efetivamente 
gerenciados, maior será o valor da organização no mercado.
Nos modelos ágeis, o valor de uma organização é medida por meio de sua capacidade em realizar 
entregas rápidas a um baixo custo operacional. Para destacarem-se no mercado, as empresas irão 
concorrer de forma cada vez mais agressiva, oferecendo prazos e custos sucessivamente mais 
apertados.
No médio e longo prazo, a lucratividade dos projetos será gradualmente reduzida e a pressão no 
aumento da produtividade das equipes será cada vez maior. Além disso, os salários deverão ser 
reduzidos para manter uma margem de lucro que compense as organizações seguirem este modelo. 
Há cada novo projeto, as empresas estarão trabalhando mais próximas de seu limite operacional e 
financeiro, devendo necessariamente rever sua estratégia de posicionamento no mercado.
Portanto, as abordagens ágeis possuem uma inconsistência estratégica que impedem que suas 
organizações sejam viáveis financeiramente no longo prazo. Isto não significa que os princípios ágeis 
não são bons nem interessantes, porém demonstram apenas que, a ênfase exclusiva na agilidade 
pode levar as organizações a uma estratégia equivocada.
O pensamento enxuto para o desenvolvimento ágil
Uma das recentes discussões que habitam as organizações que desenvolvem ou consomem software 
é o seguinte: “Esse negócio de processos ágeis realmente funciona? Ou então, como iniciar um 
projeto, usando as ideias de modelo ágil?”
 Muitos de nós já usamos processos ágeis, porém, muitas vezes, o fazemos sem uma filosofia maior, 
e acabamos apenas usando o caráter operacional dos processos ágeis existentes e isso limita o 
resultado que o processo em questão pode oferecer, pois enquanto as ideias inerentes não forem 
institucionalizadas, em todos os níveis de uma organização (operacional, tático e estratégico), 
haverá um forte descompasso de resultados.
Na verdade, existe uma solução proposta para isso, imagine uma empresa alinhada às ideias dos 
processos ágeis para área de desenvolvimento de software e para as demais áreas, seus pensamentos 
estejam alinhados como os ideais de modelo enxuto de trabalho, semelhante ao proposto pela 
Toyota, isso seria um verdadeiro paraíso ou então uma grande utopia para quem almeja bons 
resultados para sua companhia.
Bem, isso não é nada do outro mundo, nem impossível de acontecer, uma vez que existe uma 
grande correlação entre os processos ágeis e modelos gerenciais enxutos que muitas organizações 
têm usado (Just-in-time, Lean, kaizen)
38
UNIDADE I │ OBJETIVO DA ENGENHARIA DE SOFTWARE
Pensado dessa forma, fica muito fácil para visualizar a aplicação da mesma linha de ideias em 
todos os níveis da empresa, criando uma forte cultura ágil na organização voltada para soluções 
efetivamente que agreguem valor ao universo da corporação.
1. O que é a metodologia ágil e como ela se enquadra no mercado hoje?
2. Em sua opinião quais são as vantagens e desvantagens da metodologia 
ágil?
39
UNIDADE II
GESTÃO DA 
ENGENHARIA DE 
SOFTWARE
CAPÍTULO 1
Manutenção e reengenharia
A manutenção, a última fase do processo de engenharia de software, é responsável 
pela maior parte de todos os gastos em software de computador.
À medida que mais programas são desenvolvidos, uma perturbadora tendência 
tem aparecido, a quantidade do esforço e recursos despendidos em manutenção de 
software tem crescido. 
Manutenção em sistemas
Quatro tipos de manutenção são executados no software de computador. A manutenção corretiva 
atua no sentido de corrigir erros que aparecem depois que o software encontra-se em uso. A 
manutenção adaptativa é aplicada quando mudanças no ambiente externo precipitam modificações 
no software. A manutenção perfectiva incorpora ampliações que são solicitadas pela comunidade 
de usuários. Finalmente, a manutenção preventiva melhora a manutenibilidade e confiabilidade 
futuras, e constitui uma base para as próximas ampliações.
As abordagens técnicas e administrativas à fase de manutenção podem ser implementadas com pouca 
sublevação. Porém, as tarefas executadas durante o processo de engenharia de software definem 
a manutenibilidade e causam um importante impacto sobre o sucesso de qualquer abordagem à 
manutenção.
Manutenção de software é, sem dúvida, mais do que consertar erros.
Ela pode ser definida pela identificação de quatro diferentes atividades:
Manutenção corretiva. 
Manutenção adaptativa. 
40
UNIDADE II │ GESTÃO DA ENGENHARIA DE SOFTWARE
Manutenção perfectiva ou de melhoria. 
Manutenção preventiva ou reengenharia. 
Atividades típicas do mantenedor:
 » Estudar especificações e projetos do sistema. 
 » Interagir com os usuários. 
 » Examinar programas e sua documentação. 
 » Descobrir erros e deficiências nos programas fontes. 
 » Projetar uma alteração em programa. 
 » Modificar um programa. 
 » Revalidar um programa. 
 » Atualizar a documentação do programa.
Reengenharia 
As ferramentas e técnicas de engenharia reversa e de reengenharia tornar-se-ão uma parte 
significativa do processo de manutenção no decorrer da década de 1990. A engenharia reversa 
extrai informações de projeto do código-fonte quando nenhuma outra documentação encontra-se 
à disposição. A reengenharia pega as informações obtidas e reestrutura o programa para conseguir 
uma qualidade mais alta e, por conseguinte, melhor manutenibilidade para o futuro.
Os métodos e técnicas apresentados neste livro têm muitas metas, mas uma das mais importantes 
é construir um software que seja receptivo à mudança. Poucas pessoas/hora serão empregadas em 
cada pedido de modificação ou manutenção. As pessoas serão liberadas para desenvolver os novos 
softwares que serão exigidos nos sistemas cada vez mais complexos do século XXI.
O software é frequentemente a realização das regras de negócio. À medida que essas regras se 
modificam, o software também deve ser modificado.
À medida que os gerentes trabalham para modificar as regras, a fim de conseguir maior eficiência e 
competitividade, o software deve acompanhar o ritmo.
Em alguns casos, isso significa a construção de novos sistemas importantes baseados em computador. 
Mas em muitos outros, significa a modificação ou a reconstrução de aplicações existentes.
Razões para reengenharia:
 » Frequentes falhas de produção. 
 » Problemas de desempenho. 
41
GESTÃO DA ENGENHARIA DE SOFTWARE │ UNIDADE II
 » Tecnologia obsoleta. 
 » Problemas de integração de sistemas. 
 » Qualidade técnica ruim. 
 » Dificuldades para testar e caro para manter. 
 » Problemas crescentes no sistema.
Engenharia progressiva X reversa
Engenharia progressiva, processo tradicional de engenharia de software, caracterizado pelas 
atividades progressivas do ciclo de vida, que partem de um alto nível de abstração, para um baixo 
nível de abstração.
Engenharia reversa, o processo inverso à engenharia progressiva, caracterizado pelas atividades 
retroativas do ciclo de vida, que partem de um baixo nível de abstração para um alto nível de 
abstração.
1. Manutenção corretiva e depuração são a mesma coisa? Explique a sua 
resposta.
2. Discuta o impacto das linguagens de alto nível sobre a manutenção 
adaptativa. Sempre é possíveladaptar um programa?
3. Os custos de manutenção devem ser incorporados ao passo de 
planejamento do software? Eles são incorporados?
42
CAPÍTULO 2
Projetos de software
O planejamento é uma atividade de administração de projetos de software que 
combina as técnicas de métricas e os métodos de estimativa discutidos nos 
capítulos anteriores com a analise de riscos, determinação de um cronograma e 
outras atividades de tomada de decisão.
A decisão de produzir ou comprar um software pode ser abordada por meio de 
um conjunto de diretrizes simples que são ampliadas com técnicas de tomada de 
decisão. 
Planejamento
O planejamento é uma atividade de administração de projetos de software que combina as técnicas 
de métricas e os métodos de estimativa discutidos nos capítulos anteriores com a análise de riscos, 
determinação de um cronograma e outras atividades de tomada de decisão.
O risco é parte inerente de todos os projetos de software e, por essa razão, deve ser analisado e 
administrado. A análise dos riscos inicia-se com a definição e é seguida pela projeção e avaliação. 
Essas atividades definem cada risco, sua probabilidade de ocorrência e seu impacto projetado. 
Assim que essas informações são definidas, as atividades de administração e a monitoração dos 
riscos podem ser levadas a efeito, ajudando a controlar os riscos.
Usando o esforço humano que foi estimado para o projeto, inicia-se a determinação do plano com 
a criação de uma rede que represente cada etapa de desenvolvimento, sua dependência de outras 
tarefas e a duração projetada. A rede de tarefas é usada para computar o caminho crítico do projeto, 
o gráfico de Gantt e uma variedade de informações sobre projeto. Usando o cronograma como guia, 
o gerente de projetos pode rastrear e controlar cada passo do processo de engenharia de software.
O Plano de Projetos de Software combina informações geradas como consequência de todas as 
atividades de estimativas e planejamento. Ele oferece um “mapa rodoviário” para a administração 
de projetos.
Gerenciamento do projeto 
O gerenciamento de projeto preocupa-se com atividades envolvidas em garantir que o software 
será entregue no tempo e no prazo determinados, e de acordo com os requisitos das organizações 
desenvolvendo e adquirindo o software.
43
GESTÃO DA ENGENHARIA DE SOFTWARE │ UNIDADE II
O gerenciamento do projeto é necessário, pois o desenvolvimento de software é sempre assunto 
de restrições de orçamento e cronograma que são estabelecidos pela organização desenvolvendo o 
software.
Objetivos:
 » Introduzir o gerenciamento de projeto de software e descrever suas características 
distintivas. 
 » Discutir o planejamento de projeto e o processo de planejamento. 
 » Mostrar como representações gráficas de cronograma são usados pelo gerenciamento 
do projeto. 
 » Discutir a noção de riscos e o processo de gerenciamento de risco.
Atividades de Gerenciamento:
 » Escrita da proposta. 
 » Planejamento e cronograma do projeto. 
 » Custos do projeto. 
 » Monitoramento do projeto e revisões. 
 » Seleção e avaliação de pessoal. 
 » Relatório escrito e apresentações.
Quadro 1. Tipos de Planos de Projeto
44
UNIDADE II │ GESTÃO DA ENGENHARIA DE SOFTWARE
Cronograma do projeto
O cronograma do projeto busca dividir o projeto em tarefas e estimar tempo e recursos necessários 
para completar cada tarefa, organizar as tarefas concomitantemente para um uso otimizado da 
força de trabalho, minimizar as dependências de tarefas pra evitar atrasos causados por uma tarefa 
esperando pela finalização de outra.
1. O risco de projeto é apenas um dos muitos tipos de riscos que 
são encontrados quando sistemas baseados em computador são 
desenvolvidos e usados no mundo real. Relacione categorias genéricas 
adicionais de risco que devem ser consideradas quando são usados 
sistemas para atividades comerciais, pessoais e governamentais.
2. Por que é “útil tentar eliminar o risco”? Considere isso, primeiramente, 
a partir de um ponto de vista técnico e, a partir de um ponto de vista 
econômico.
45
CAPÍTULO 3
Métricas de software
A medição possibilita que gerentes e profissionais entendam melhor o processo de 
engenharia de software e o produto que ele produz.
O risco é a parte inerente de todos os projetos de software e, por essa razão, deve ser 
analisado e administrado. 
Medição
Quanto tempo leva para construir uma casa? Qual o tamanho da casa? Quais são as características 
da casa? Qual será o custo da casa? Estas são perguntas importantes a serem feitas no projeto de 
construção de uma casa ou apartamento. No desenvolvimento de software não é muito diferente 
da construção civil, ao se iniciar um projeto de desenvolvimento de software é extremamente 
importante ter conhecimento destas variáveis, o tempo de desenvolvimento do projeto, o tamanho 
do projeto, os requisitos do projeto e o custo do projeto; neste ponto que entra a técnica de métricas 
de software.
Métricas de software 
O gerenciamento de projetos de software representa a primeira camada do processo de engenharia 
de software. O gerenciamento de projetos compreende atividades que envolvem medição, estimativa, 
análise de erros, programação de atividades, monitoração e controle.
A medição possibilita que gerentes e profissionais entendam melhor o processo de engenharia de 
software e o produto (software) que ele produz.
Usando medidas diretas e indiretas, as métricas de produtividade e qualidade podem ser definidas.
Métricas orientadas tanto ao tamanho quanto à função são usadas em toda a indústria de software. 
As métricas orientadas ao tamanho fazem uso das linhas de código como fator normalizante para 
outras medidas, tais como as medidas de pessoas-mês ou defeitos. O ponto-por-função deriva de 
medidas do domínio da informação e da avaliação subjetiva da complexidade do problema.
Métricas de qualidade de software, como a métrica de produtividade, concentram-se tanto no 
processo como no produto. Ao desenvolver e analisar uma linha básica para a qualidade, uma 
organização pode tomar providências para corrigir aquelas áreas do processo de engenharia de 
software que são a causa principal dos defeitos do software. Neste capítulo, quatro métricas da 
46
UNIDADE II │ GESTÃO DA ENGENHARIA DE SOFTWARE
qualidade-corretitude, manutenibilidade, integridade e usabilidade – foram discutidas. Métricas 
adicionais de qualidade serão descritas posteriormente neste livro.
A medição resulta em mudança cultural. A coleta de dados, computação das métricas e avaliação dos 
dados são os três passos que devem ser implementados para se começar um programa de métricas. 
Ao criar uma linha básica (um banco de dados contendo medições do processo e do produto), os 
engenheiros de software e seus gerentes podem obter uma melhor visão do trabalho que realizam e 
do produto que produzem.
O controle é impossível sem medições e feedback. Não se pode controlar o que não se pode medir, 
a extensão do controle depende da precisão da medição, qualquer coisa que não se pode medir está 
fora de controle.
Medições e métricas ajudam a entender:
 » O processo técnico usado para se desenvolver um produto. 
 » O próprio produto.
 » Produto, medido para avaliar a sua qualidade.
 » Processo, medido para melhorá-lo.
 » Medição, documentação de efeitos passados.
 » Uso, previsão de quantificação de efeitos futuros (as estatísticas não podem prever, 
mas podem deduzir). 
A medição e a inferência estatística são usadas em várias áreas para projetar o desempenho futuro.
Medição pode levar a controvérsias e discussões: 
 » Que métricas usar?
 » Como os dados compilados devem ser usados?
 » É justo usar medições para se comparar pessoas, processos e produtos? 
Estimativa é uma das principais atividades do planejamento de software, estima-se: 
 » Esforço humano exigido.
 » Duração cronológica do projeto.
 » Custo.
Estimativa é a essência da dificuldade em controlar projetos de software. 
47
GESTÃO DA ENGENHARIADE SOFTWARE │ UNIDADE II
Causas de estimativas de software mal feitas:
 » Falta de especialização em estimativas (falta de treino).
 » Falta de se fazer provisões adequadas para contrabalançar o efeito das distorções.
 » É preciso muito pouco envolvimento do ego para estimativas mais realistas.
 » Falta de conhecimento exato sobre o que vem a ser uma estimativa.
 » Falta de habilidade com os problemas políticos.
 » Norma: estimativas devem ser usadas para criarem incentivos.
 » Falta de informações úteis para o processo de estimativas.
Atributos comuns de técnicas de estimativas:
 » O escopo do software deve ser estabelecido antecipadamente.
 » Métricas de software são utilizadas.
 » Histórico de medidas passadas é usado como uma base.
 » O projeto é particionado em pequenas partes que são estimadas individualmente.
A métrica de software, é uma técnica fundamental para o planejamento do desenvolvimento do 
software, com as métricas consegue-se mensurar o custo e prazo, além de ser uma boa partida para 
realizar os contratos de software.
Existem vários tipos de métricas, porém neste artigo irei focar somente na técnica de Pontos de 
Função. Os Pontos de Função têm como objetivo medir o tamanho funcional do software, ou seja, 
é a medida das funcionalidades do software que foram descobertas a partir do levantamento de 
requisitos, assim pode-se apresentar um feedback palpável para o usuário.
Supondo que depois de termos levantados todos os requisitos e realizado a contagem de pontos de 
função, descobrimos que a aplicação tem o valor de 130PF. A partir desse valor pode-se realizar 
outras estimativas, por exemplo, se existe uma equipe de 6 desenvolvedores que trabalham por 8 
horas por dia, então a partir desta fórmula consegue-se obter o tempo estimado de desenvolvimento 
da aplicação:
ESFORÇO = PF * HORAS/PF = 130/6 = 21,66 HORAS
(ESFORÇO/HORAS TRABALHADAS)/RECURSOS = (21,66/8)/6 = 0,45 dias
Agora que se sabe o tempo estimado para o desenvolvimento do projeto, podemos calcular o preço 
por hora, também existe outra possibilidade de calcular o preço do desenvolvimento de um software, 
que é a partir dos pontos de função. Defini-se um valor por ponto, neste exemplo cada ponto de 
48
UNIDADE II │ GESTÃO DA ENGENHARIA DE SOFTWARE
função valerá 50 reais, então é só realizar a multiplicação do total de pontos de função pelo valor de 
cada ponto de função, como no exemplo abaixo:
PF*valor= 130 * 50 = 6.500,00 reais
Análise dos riscos
A análise dos riscos inicia-se com a identificação e é seguida pela projeção e avaliação. Essas 
atividades definem cada risco, sua probabilidade de ocorrência e seu impacto projetado. Assim que 
essas informações são definidas, as atividades de administração e a monitoração dos riscos podem 
ser levadas a efeito, ajudando a controlar os riscos.
Usando o esforço humano que foi estimado para o projeto, inicia-se a determinação do plano com 
a criação de uma rede que represente cada etapa de desenvolvimento, sua dependência de outras 
tarefas e a duração projetada. A rede de tarefas é usada para computar o caminho crítico do projeto, 
o gráfico de Gantt e uma variedade de informações sobre o projeto. Usando o cronograma como guia, 
o gerente de projetos pode rastrear e controlar cada passo do processo de engenharia de software.
Em certos casos, talvez seja possível adquirir um pacote de software existente ou subcontratar 
seu desenvolvimento em vez de construí-lo in-house. A decisão de produzir ou comprar pode ser 
abordada por meio de um conjunto de diretrizes simples que são ampliadas com técnicas de tomada 
de decisão.
O plano de projeto de software combina informações geradas como consequência de todas as 
atividades de estimativa e planejamento. Ele oferece um “mapa rodoviário” para a administração 
de projetos.
Aspecto crucial para um bom gerenciamento de projeto de software:
 » Riscos técnicos. 
 » Riscos em extrapolar o tempo previsto. 
 » Desvio do cronograma e custo.
Gerenciamento de projeto eficaz envolve identificar as áreas de risco e administrá-las adequadamente:
 » Avaliação dos riscos. 
 » Colocá-los em ordem de prioridade. 
 » Estabelecer estratégias de administração dos riscos. 
 » Resolução dos riscos. 
 » Monitoração dos riscos. 
49
GESTÃO DA ENGENHARIA DE SOFTWARE │ UNIDADE II
Determinação de prazos
Determinação de prazos determina o objetivo das tarefas de forma que se possa acompanhar o 
andamento da execução das várias atividades envolve os seguintes tópicos:
 » Planejamento da programação a ser realizada. 
 » Identificação do conjunto de tarefas de projeto. 
 » Estabelecimento das interdependências entre as tarefas. 
 » Estimativa do esforço associado a cada tarefa. 
 » Atribuição de pessoas e outros recursos para a realização e tarefas específicas.
Monitoração e controle
Monitoração e controle são atividades de acompanhamento que iniciam logo após o estabelecimento 
da programação de desenvolvimento, propiciando o rastreamento de cada tarefa no programa de 
desenvolvimento, apontando o impacto do não cumprimento dos prazos, desta forma podemos 
redirecionar recursos, reorganizar tarefas, atendendo os compromissos de entrega.
A medição torna as questões de estimativas de projeto, a garantia de qualidade e produtos mais 
econômicos e desenvolvidos no prazo mais administrável. A nível técnico, medições são importantes 
para determinar parâmetros como quantidade de teste necessário e impacto de mudanças.
Figura 10. Monitoração e Controle
Suponhamos que você seja o gerente de uma empresa de projetos de uma empresa 
que constrói software para produtos de consumo. Você foi contratado para construir 
o software para um sistema de segurança doméstico sofisticado. Desenvolva um 
esboço detalhado (seja tão específico quanto possível) dos passos que deveria 
realizar para administrar esse projeto. Suponhamos que você ainda tenha de se 
reunir com seu cliente. Qual paradigma de engenharia de software escolheria? 
50
CAPÍTULO 4
Validação
O objetivo principal da validação é derivar um conjunto de testes que tenha uma 
alta probabilidade de revelar defeitos no software. 
Por meio da validação podemos antecipar qualquer problema na aplicação?
Validação
O objetivo principal do projeto de casos de testes é derivar um conjunto de testes que tenha 
uma alta probabilidade de revelar defeitos no software. Para atingir esse objetivo, duas categorias 
diferentes de técnicas de projeto de casos de teste são usadas: o teste de caixa preta e o teste de 
caixa branca.
Os testes de caixa branca focalizam a estrutura de controle do programa. Os casos de teste são 
derivados para garantir que todas as instruções do programa tenham sido exercitadas pelo menos 
uma vez durante os testes e que todas as condições lógicas tenham sido exercitadas também. 
Os testes de caminho básico, uma técnica de caixa branca, fazem uso de grafos programa (ou matrizes 
de grafo) para derivar o conjunto de testes linearmente independentes que garantirão cobertura. 
Os testes de fluxo de dados e das condições põem à prova a lógica do programa, e os testes de laços 
complementam outras técnicas de caixa branca ao proporcionar um procedimento para exercitar 
laços de vários graus de complexidade.
Os testes de caixa branca são aplicados a componentes de programa pequenos (por exemplo, os 
módulos ou pequenos grupos de módulos). Os testes de caixa preta, por outro lado, ampliam o 
nosso foco e poderiam ser denominados “testes em grande porte” (testing in the large).
Os testes de caixa preta são projetados para validar os requisitos funcionais, sem se preocupar com 
o funcionamento interno de um programa. As técnicas de teste de caixa preta concentram-se no 
domínio de informações do software, derivando os casos de teste ao dividir a entrada e saída de uma 
maneira que proporcione uma satisfatória cobertura de teste. O particionamento de equivalência 
divide o domínio de entrada em classes de dados que provavelmente exercitarão umafunção de 
software específica. A análise do valor de fronteira prova a capacidade que um programa tem de 
manipular dados nos limites da aceitabilidade. O grafo de causa-efeito é uma técnica que possibilita 
que o analista valide conjuntos complexos de ações e condições.
51
GESTÃO DA ENGENHARIA DE SOFTWARE │ UNIDADE II
Verificação 
Verificação do software, o aplicativo cumpre com suas especificações.
Inspeções de software - preocupadas com a análise estática das representações do sistema para 
descobrir problemas (verificação estática), podem ser complementadas por alguma análise 
automática do texto de origem de um sistema ou dos documentos associados.
Teste de software - preocupado com a execução e observação do comportamento do produto 
(verificação dinâmica).
O sistema é executado com dados de teste e o seu comportamento operacional é observado.
Figura 11. Verificação
Testes de programas: 
 » Podem revelar a presença de erros e NÃO a ausência.
 » Um teste bem sucedido é um teste que descobre um ou mais erros.
 » Os testes de defeito:
 » Testes projetados para descobrir inconsistências entre o programa e sua 
especificação.
 » Um teste bem sucedido é aquele que revela a presença de defeitos em um sistema.
Testes estatísticos:
 » Usado para testar o desempenho e a confiabilidade do programa.
 » Confiabilidade: número de falhas no sistema etc.
 » Desempenho: Tempo de execução, tempo de resposta etc.
52
UNIDADE II │ GESTÃO DA ENGENHARIA DE SOFTWARE
 » Deve ser usado em conjunto com a verificação estática para uma cobertura total das 
atividades.
Metas de V & V
Verificação e validação devem estabelecer a confiança de que o software é “adequado a seu propósito”. 
Isso não significa que o programa tenha que ser livre de defeitos. Ao invés disso, significa que o 
sistema deve ser suficientemente bom para o uso pretendido. O tipo de uso irá determinar o grau de 
confiança que será necessário.
Confiança de V & V
Depende do propósito do sistema, as expectativas do usuário e o ambiente de mercado.
Função do software, o nível de confiança depende do tipo de sistema e o quanto é importante para 
a organização. 
Expectativas do usuário, usuários tinham poucas expectativas de certos tipos de software, hoje eles 
são mais exigentes. 
Ambiente de mercado, colocar um produto no mercado pode ser mais importante do que encontrar 
todos os defeitos no programa. 
Testes e depuração. Testar e depurar um programa são atividades distintas.
Verificação e validação de teste estão preocupadas em estabelecer a existência de defeitos em um 
programa.
Depuração está preocupada com a localização e remoção desses defeitos.
Depuração envolve a formulação de uma hipótese sobre o comportamento do programa e testar 
essa hipótese para encontrar o erro no sistema.
O teste ocorre antes e descobre a ocorrência do erro. 
Figura 12. Depuração
53
GESTÃO DA ENGENHARIA DE SOFTWARE │ UNIDADE II
Planejamento de V & V
Planejamento cuidadoso é necessário para obter sucesso nos processos de inspeção e teste.
O planejamento deve iniciar no começo do processo de desenvolvimento.
O processo de planejamento deve decidir sobre o equilíbrio entre as abordagens estáticas e dinâmicas.
O planejamento de testes se ocupa em estabelecer os padrões para o processo de testes.
Estrutura de um plano de testes
 » O processo de teste. 
 » Facilidade de rastreamento dos requisitos:
 › Testar individualmente os requisitos. 
 » Itens a serem testados:
 › O que vai ser testado. 
 » Cronograma de testes. 
 » Procedimentos de registros de testes: 
 › Como o resultado dos testes vai ser documentado. 
 » Requisitos de hardware e de software. 
 » Restrições. 
Inspeções x testes
 » Inspeções e testes são técnicas de verificação complementares. 
 » Ambas devem ser utilizadas no processo de V&V. 
 » Inspeções podem verificar a conformidade com uma especificação, mas não a 
conformidade com os reais requisitos do usuário. 
 » Inspeções não podem verificar as características não funcionais tais como 
desempenho, usabilidade etc.
Inspeções no programa
 » Revisão cuidadosa, linha por linha, do código fonte do programa. 
 » Objetivo é a Detecção de defeitos (não correção). 
54
UNIDADE II │ GESTÃO DA ENGENHARIA DE SOFTWARE
 » Defeitos podem ser erros lógicos, anomalias no código que podem indicar uma 
condição errônea (por ex. uma variável não inicializada) ou a não conformidade 
com padrões organizacionais.
Pré-condições para a inspeção de programa
 » Uma especificação precisa deve estar disponível. 
 » Os membros da equipe de inspeção devem estar familiarizados com os padrões 
organizacionais. 
 » Código sintaticamente correto deve estar disponível. 
 » Uma lista de erros deve ser preparada. 
 » Gerente deve aceitar que a inspeção aumentará os custos no começo do processo de 
software.
Checklist de inspeção de programa
 » Lista de erros comuns deve ser usada para dirigir a inspeção. 
 » Listas de erros são dependentes da linguagem de programação. 
 » Quanto mais “fraca” é a checagem de tipos pela linguagem, maior é a lista de erros 
mais comuns. 
 » Exemplos: inicialização, nomeação de constantes, término de laços, limites de 
vetores etc.
Taxa de inspeção (IBM)
 » Cerca de 500 declarações/hora durante revisão geral. 
 » 125 declarações/hora durante preparação individual. 
 » 90-125 declarações/hora podem ser inspecionadas durante a reunião. 
 » Inspeção é portanto, um processo caro. 
 » Contudo, o esforço requerido para a inspeção é menor do que a metade o esforço de 
teste exigido para defeitos equivalentes.
Análise estática automatizada
 » Analisadores estáticos são ferramentas de software para o processamento do código 
fonte. 
 » Percorrem o texto do programa e tentam descobrir potenciais condições erradas e 
chamar a atenção da equipe de v&v. 
55
GESTÃO DA ENGENHARIA DE SOFTWARE │ UNIDADE II
 » São bastante eficazes como um auxílio às inspeções de programas. É um 
complemento, porém não substitui as inspeções.
Quadro 2. Checagem da Análise Estática
Uso da análise estática
 » Útil quando a linguagem não faz checagem adequada de tipos e, por isso, muitos 
erros não são detectados pelo compilador (C). 
 » Menos eficaz para linguagens que possui forte checagem de tipos e podem, portanto, 
detectar muitos erros durante a compilação (Java).
Desenvolvimento de Software Cleanroom
 » Filosofia de desenvolvimento que tem como base evitar defeitos pelo uso de um 
rigoroso processo de inspeção.
 » Objetivo: conseguir um software sem nenhum defeito.
 » Processo de desenvolvimento baseado em:
 › Especificação formal.
 › Desenvolvimento incremental.
 › Programação estruturada.
 › Verificação estática usando rigorosas inspeções de software.
 › Teste estatístico do sistema.
56
UNIDADE II │ GESTÃO DA ENGENHARIA DE SOFTWARE
Especificação formal e inspeções
 » O modelo baseado em estados é a especificação e o processo de inspeção checa o 
programa com relação a esse modelo.
 » A abordagem utilizada para o desenvolvimento tem como base transformações 
bem definidas, que tentam preservar a exatidão em cada transformação, para uma 
representação mais detalhada.
 » Argumentos matemáticos (não provas) são usados para aumentar a confiança no 
processo de inspeção.
Equipes no processo Cleanroom 
 » Equipe de especificação. Responsável pelo desenvolvimento e pela manutenção da 
especificação do sistema.
 » Equipe de desenvolvimento. Responsável por desenvolver e verificar o software. O 
software não é executado durante esse processo.
 » Equipe de certificação. Responsável pelo desenvolvimento de um conjunto de testes 
estatísticos para exercitar o software após o seu desenvolvimento (certificação da 
confiabilidade do software).
Avaliação do processo Cleanroom 
 » Resultados na IBM têm mostrado que os softwares possuem bem menos erros (2,3 
erros para mil linhas de código). 
 » Avaliação mostra que o processo não é mais caro do que outras abordagens.
 » Menos erros do que