ENGENHARIA DE SOFTWARE

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

__MACOSX/._ENGENHARIA DE SOFTWARE
ENGENHARIA DE SOFTWARE/EngSoft(2).pdf
AULA 2 
ENGENHARIA DE SOFTWARE 
Prof. Emerson Antonio Klisiewicz 
 
 
02 
CONVERSA INICIAL 
 Nessa segunda aula estudaremos sobre os modelos clássicos de cálculo 
de esforço para o desenvolvimento de sistemas que fazem parte do processo de 
Engenharia de Software. 
CONTEXTUALIZANDO 
 As métricas para se fornecer os esforços para a 
construção/desenvolvimento de um projeto de software mais utilizadas pela 
indústria são as seguintes: Pontos de Função (PF), Linhas de Código (LOC – Line 
of Code) e Pontos por Casos de Uso (UCP). Vamos a elas. 
TEMA 1 – MÉTODO GUSTAV KARNER? 
 Criado por Gustav Karner, o método serve para informar o esforço que será 
gasto em projetos de software orientados a objetos. Ele baseia-se em casos de 
uso, o que permite ser possível, já no início dos projetos, verificar qual será o 
esforço desprendido para o desenvolvimento. Isso ocorre já na fase do 
levantamento de requisitos. Para utilizar esse método, necessitamos seguir 4 
passos no nosso desenvolvimento: 
Os 4 passos do Método de Gustav Karner. 
1. Avaliar o Ator. 
2. Avaliar o Fluxo (Path). 
3. Fazer o ajuste do UCP pelos fatores técnicos (TF) e pela Equipe EV. 
4. Calcular o Esforço. 
TEMA 2 – USE CASE POINT – CALCULANDO O ESFORÇO 
2.1 Os 4 passos do método de Gustav Karner 
2.1.1 Avaliar o ator: pessoa, sistema ou tempo 
 Pessoa é o ator complexo e vale 3 pontos. 
 Sistema é ator médio e vale 2 pontos. 
 Tempo é ator simples e vale 1 ponto. 
 
 
 
03 
2.1.2 Avaliar o fluxo (path) 
 Conta-se cada fluxo principal e cada fluxo alternativo. Fluxos de exceção 
não são contados: 
 De 1 a 3 fluxos – fluxo SIMPLES - 5 pontos. 
 De 4 a 7 fluxos – fluxo MÉDIO - 10 pontos. 
 De 8 ou acima – fluxo COMPLEXO - 15 pontos. 
 UUCP = soma de pontos dos atores + soma de pontos dos fluxos 
2.1.3 Ajuste do UCP 
 Fazer o ajuste do UCP pelos fatores técnicos (TF) e da Equipe EV, sendo 
UCP = UUCP * TF * EF. 
2.1.3.1 Fatores técnicos 
 Nesse momento, o analista deve responder a 13 perguntas relacionadas a 
questões técnicas do projeto ou do sistema que está sendo desenvolvido. Para 
todas as perguntas, o analista atribuirá um valor de 0 a 5 ao nível de influência 
que tal questão tem dentro do contexto de desenvolvimento. Em cada pergunta, 
existe um peso atribuído que será multiplicado pelo valor de influência atribuída 
pelo analista a tal quesito. Ao final, o analista deve somar os resultados de todas 
as respostas às perguntas e colocar o valor na seguinte fórmula: TCF = (0,6 + 
(0,01 * SOMA DAS RESPOSTAS AS PERGUNTAS)). O resultado dessa conta 
será o valor do fator técnico em nosso processo. 
 As 13 perguntas podem ter variações de empresa para empresa, mas, 
normalmente, seguem o modelo abaixo descrito: 
Quadro 1 – Perguntas técnicas sobre o projeto 
 
 
 
04 
 
2.1.3.2 Fatores ambientais 
 Para este fator, o analista deve responder a 8 perguntas relacionadas a 
questões ambientais do projeto ou do sistema que está sendo desenvolvido. Esse 
fator leva em conta questões relacionadas à equipe que trabalhará no 
desenvolvimento. Seguindo a mesma ideia dos fatores técnicos, para todas as 
perguntas o analista deve atribuir um valor de 0 a 5 ao nível de influência que tal 
questão tem dentro do contexto de desenvolvimento. Em cada pergunta, existe 
um peso fixo atribuído, o qual deve ser multiplicado pelo valor de influência 
atribuída a aquele quesito. Ao final, o analista precisa somar os resultados de 
todas as respostas às perguntas e colocar o valor na seguinte fórmula: EF = (1,4 
+ (-0,03 * SOMA DAS RESPOSTAS AS PERGUNTAS)). 
 As 8 perguntas podem ter variações de empresa para empresa, mas, 
normalmente, seguem o modelo abaixo descrito: 
Quadro 2 – Modelo de perguntas 
 
 
 
05 
 
 
É importante salientar que, no TF, quanto maior o valor encontrado, maior 
será o esforço gasto no desenvolvimento do sistema. No EF é o contrário. Quanto 
maior o valor encontrado, menor será o esforço para o desenvolvimento. 
 Com os fatores calculados, obtém-se o valor dos Use Case Ajustados: UCP 
= UUCP * TF * EF. 
2.1.4 Calcular o esforço 
 Com o UCP calculado, faremos a multiplicação dos pontos UCP pelo fator 
de produtividade (homem.hora por UCP). A produtividade média recomendada é 
entre 15 e 30 homem.hora por UCP, sendo 20 a média internacional. 
 Esforço (homem.hora) = UCP * produtividade 
 Abaixo há um exemplo do esforço calculado levando-se em consideração 
o esquema de fluxos mostrados. Note que os fatores de TC e EF têm os 
respectivos valores: 0,98 e 1,01. 
Quadro 3 – Cálculo de esforço 
 
05
Motivação
São os programadores motivados para trabalhar no projeto? 
Instabilidade no projeto vai sempre levar para as pessoas que 
saem no meio do caminho através do seu código-fonte. E a mão 
sobre torna-se realmente difícil. 
1 none 0 0
06
Requisitos estáveis
É ao usuário clara sobre o que ele quer? Tenho visto as 
expectativas dos clientes são o fator mais importante na 
estabilidade dos requisitos. Se o cliente é de uma natureza 
altamente mudar, colocar esse valor máximo. 
2 none 0 0
07
Part-time trabalhadores
Há pessoal em tempo parcial no projeto, como consultores, etc? -1 none 0 0
08
Difícil linguagem de programação
Qual é a complexidade da linguagem, Assembly, VB 6.0, C + + 
e C ou Framework? 
-1 none 0 0
0
1,4
Efactor
EF - Enviroment Factor = ( 1,4 + ( -0,03 * Efactor) )
 
 
06 
TEMA 3 – ANÁLISE POR PONTOS DE FUNÇÃO 
3.1 NESMA – A associação 
 Para se associar à NESMA (Netherlands Software Metrics Association), a 
composição de custos varia em 250 € por ano. Sem fins lucrativos, ao associar-
se você terá os benefícios de acesso ilimitado ao site, obter uma cópia gratuita de 
cada novo produto da NESMA, poder participar nas comissões e conferências que 
essa associação oferece, ter descontos em atividades (conferências, simpósios, 
workshops etc.) e produtos (estudos, relatórios e manuais) que ela disponibiliza. 
Muitas grandes empresas são sócias da NESMA, como ABN-AMRO Bank NV, 
IBM Nederland e BV. 
3.2 Para que serve a APF? 
 A Análise por Pontos de Função (FPA) é um técnica de medição do 
tamanho de softwares que tenta relacionar a complexidade inerente ao 
processamento com as funcionalidades solicitadas/oferecidas ao usuário por meio 
do software. 
3.3 Quais os objetivos da APF? 
 Os pontos de função têm alguns objetivos. Dentre eles, podemos destacar: 
a. Medir a funcionalidade que o usuário solicita e recebe. 
b. Medir o desenvolvimento e a manutenção de software de forma 
independente da tecnologia utilizada na implementação. 
c. Ser simples o suficiente para minimizar o trabalho adicional envolvido no 
processo de medição e informação da condução do desenvolvimento. 
d. Ser uma medida consistente entre vários projetos e organizações. 
3.4 Como usar a APF nas Organizações? 
 A análise por ponto de função também pode ser usada para verificar o 
tamanho de softwares adquiridos ou já existentes em uma empresa. Também 
pode ser utilizada para dar apoio à análise no desenvolvimento de softwares, 
visando mais qualidade no produto final (software). E, ainda, pode ser utilizada 
como uma ferramenta de apoio à manutenção de software, bem como no controle 
 
 
07 
de custos do desenvolvimento, ajudando nas negociações de contratos nas áreas 
de TI junto aos usuários. 
3.5 Etapas da APF 
 O cálculo da análise de pontos de função terá os seguintes passos para a 
sua obtenção: 
a. Identificação do tipo de contagem a ser utilizado. 
b. Definição da fronteira da aplicação. 
c. Contagem de pontos de função não ajustados. 
d. Cálculo do fator de ajuste. 
e. Contagem de pontos
de função ajustados. 
3.5.1 Identificação do tipo de contagem a ser utilizado 
 Consiste na identificação do objeto a ser medido, como sendo um projeto 
de desenvolvimento, manutenção ou produção. Ou seja, faremos a pergunta: “O 
que medirei?” 
3.5.2 Definição da fronteira da aplicação 
 Esta é a etapa em que se estabelece o escopo do sistema objeto da 
avaliação, sob a visão do usuário. Nesse momento, fazemos a pergunta: “Até 
onde medirei?” Essa situação é de extrema importância para definirmos qual será 
o escopo do desenvolvimento, e de onde e para onde irão as informações do 
sistema/manutenção/desenvolvimento. Tudo isso é preciso prever. 
3.5.3 Contagem de pontos de função não ajustados 
 Para essa etapa, iniciaremos o processo de cálculo propriamente dito, 
levando em consideração os seguintes itens: 
 Arquivo Lógico Interno (ALI). 
 Arquivo de Interface Externa (AIE). 
 Entradas Externas (EE). 
 Saídas Externas (SE). 
 Consultas Externas (CE). 
 Esses itens podem ter a sua dimensão analisada pela figura abaixo: 
 
 
08 
Figura 1 – Contagem de pontos de função não ajustados 
 
 Iniciaremos o nosso processo de cálculo fazendo a atribuição da 
complexidade de cada item. Vamos a eles. 
3.5.3.1 Atribuindo complexidade a um ALI/AIE 
 Antes da atribuição, vamos entender o que é um ALI e um AIE. 
 Arquivo Lógico Interno (ALI) são dados (arquivos, tabelas ou entrada de 
dados realizadas no sistema) logicamente relacionados que serão utilizados ou 
sofrerão algum tipo de manutenção e que estão dentro das fronteiras do software. 
Podem ser identificados pelos critérios (dados armazenados dentro da fronteira 
da aplicação que sofrem manutenção por meio de um processo padrão da 
aplicação e são identificados pelo usuário como sendo um requerimento da 
aplicação). 
 Exemplo: dados da aplicação, arquivos mestres, como cadastro de clientes 
ou cadastro de funcionários, arquivos de dados de segurança da aplicação, 
arquivos de dados de auditoria, arquivos de mensagens de auxílio, arquivos de 
mensagens de erro. 
 Os Arquivos de Interface Externa (AIE) representam as informações 
necessárias externas à aplicação. Contribuem para o cálculo dos Pontos por 
Função com base na quantidade e complexidade funcional relativa de cada um 
deles. Podemos identificá-los usando critérios, como verificar se são dados 
armazenados fora da fronteira da aplicação, se não sofrem manutenção por meio 
de um processo padrão da aplicação e se são também identificados pelos 
usuários como sendo requerimentos do software. Exemplo: informações de 
referência (dados externos utilizados pela aplicação, mas que não têm sua 
 
 
09 
manutenção realizada pela aplicação), arquivos de mensagens de auxilio e 
arquivos de mensagens de erro. 
 Com essas definições, vamos iniciar o processo de atribuição da 
complexidade. 
3.5.3.1.1 Identificar os TERs e TEDs 
a. TER – Tipo de elemento de registro. É a quantidade de tipos de registros, 
no caso de um arquivo, ou de tabelas, no caso da utilização de um banco 
de dados. Podemos dizer que é um subgrupo de dados dentro de um 
ALI/AIE reconhecível pelo usuário. 
b. TED – Tipo de elemento de dado. É a quantidade de campos de um arquivo 
ou de uma tabela utilizados na aplicação. Podemos dizer que, nesse caso, 
é um campo único, não repetitivo e reconhecível pelo usuário. 
c. Feita essa análise, atribuímos a complexidade dos ALI e AIE usando a 
tabela abaixo: 
Tabela 1 – Complexidade dos ALI e AIE 
 
 
Seguindo a mesma lógica, faremos agora a identificação dos quesitos SE, 
CE e EE, mas antes apontaremos suas definições: 
a. ENTRADAS EXTERNAS (EE): São as atividades realizadas pelos usuários 
por meio de um processo dentro do sistema, como inserção, modificação 
ou exclusão de dados nos arquivos lógicos internos (ALI). 
b. SAÍDAS EXTERNAS: São as atividades realizadas pelo sistema/programa, 
que resultam na extração de dados da aplicação, dados que estão 
presentes nos ALI´s. 
c. CONSULTAS EXTERNAS: São as atividades que, por meio de uma 
requisição de dados (entrada), geram exibições imediatas dos dados 
(saída) contidas nos ALI´s. 
 Com essas definições, apresentaremos a mesma definição dos processos 
do ALI e AIE. 
 
 
010 
a. TAR – Tipos de arquivos/tabelas referenciados na aplicação. É a 
quantidade de ALI/AIE mantida ou referenciada (utilizada) pelas transações 
do sistema. 
b. TED – São os elementos de dados; campos reconhecíveis pelo usuário, 
que podem também cruzar a fronteira da aplicação durante as transações 
realizadas pela aplicação. 
 Seguindo as definições acima, apresentamos as complexidades usando as 
tabelas abaixo: 
Tabela 2 – Complexidade EE 
 
Tabela 3 – Complexidade SE e CE 
 
 Com a definição da complexidade dos itens (Baixa, Média e Alta), a tabela 
de pontuação para os itens seguirá a relação abaixo: 
Tabela 4 – Nível de complexidade 
 
 Dessa forma, fechamos o cálculo de pontos não ajustados. Agora veremos 
a questão do ajuste a ser realizado (Opcional) aos pontos calculados até aqui. 
 
 
 
011 
TEMA 4 – ANÁLISE DE PONTOS DE FUNÇÃO – CÁLCULO DO FATOR DE 
AJUSTE 
 O valor do FATOR DE AJUSTE, similar ao UCP, é calculado com base 
em 14 características que envolvem o desenvolvimento do software e 
permitem uma avaliação geral da funcionalidade da aplicação. Estas 
características são: 
1. Comunicação de Dados; 
2. Processamento Distribuído; 
3. Performance; 
4. Utilização do Equipamento; 
5. Volume de Transações; 
6. Eficiência do Usuário Final; 
7. Entrada de dados “on-line”; 
8. Atualização “on-line”; 
9. Processamento Complexo; 
10. Reutilização de Código; 
11. Facilidade de Implantação; 
12. Facilidade Operacional; 
13. Múltiplos Locais; 
14. Facilidade de Mudanças. 
 É atribuída uma nota de 0 a 5 a cada uma das Características Gerais 
do Sistema, correspondendo aos seguintes critérios: nenhuma influência, 
influência incidental, moderada, média, significante, essencial. Após isso, 
usamos a seguinte fórmula do fator de ajuste: 
 
 Em que Nt(total) é a soma dos níveis de influência atribuída às 
perguntas. 
 Com isso, calculamos o valor final, que é TPF = PFB * VAF, em que 
PFB é o total de pontos de função bruto calculado. 
 
 
012 
 Exemplo de um cálculo sem fazer o ajuste: 
Tabela 5 – Transações (campos e arquivos referenciados) 
 
Tabela 6 – Contagem: entradas externas 
 
Tabela 7 – Contagem: saídas externas 
 
 
 
 
013 
Tabela 8 – Contagem: consultas externas 
 
Tabela 9 – Contagem: Arquivos Lógicos Internos 
 
Tabela 10 – Contagem: Arquivos de Interface Externa 
 
Tabela 11 – Contagem final de PF (não ajustados) 
 
 
 
 
014 
TEMA 5 – ANÁLISE POR PONTOS DE FUNÇÃO SIMPLIFICANDO COM O 
NESMA 
 Há formas simplificadas de realizar o cálculo do APF por meio de 
métodos simplificados criados pelo NESMA. Nessa versão, existem 3 tipos 
de contagem: Indicativa, Estimativa e Detalhada. Vamos a elas. 
5.1 Contagem indicativa 
 A contagem Indicativa traz o valor da quantidade de pontos de função 
sem saber os detalhes do modelo e sem ter um detalhamento do processo. 
 Ela possibilita, dessa forma, medir um software já no início do processo 
de desenvolvimento, mesmo não possuindo todas as informações. Assim, 
podemos usá-la na fase inicial do desenvolvimento. A contagem indicativa 
realiza-se da seguinte forma: Determina-se a quantidade de ALIs e AIEs. O 
tamanho é calculado contando-se 35 PFs para cada ALI identificado e 15 PFs 
para cada AIE. Essa estimativa baseia-se somente na quantidade de arquivos 
lógicos (ALIs e AIEs), calculando-se o total de pontos de função não ajustados 
da seguinte forma: tamanho indicativo (pf) = 35 x número de ALIs + 15 x 
número
de AIEs. 
 Exemplo: 
Tabela 12 – Contagem indicativa 
 
 ALI – Arquivos Lógicos Internos 
 AIE – Arquivos de Interface Externas 
 (pf) = 35 x número de ALIs + 15 x número de AIEs 
 35 x 2 + 15 x 1 = 70 + 15 = 85 pf 
 
 
 
015 
5.2 Contagem estimativa 
 É utilizada na fase inicial da proposta de desenvolvimento, quando não 
se possuem dados detalhados do processo, apenas informações preliminares 
sobre os processos e o modelo de dados. São necessárias informações um 
pouco mais detalhadas sobre a funcionalidade da aplicação, levantadas a 
partir das exigências do usuário. Para usar essa contagem, temos os 
seguintes passos: 
 1º PASSO: 
Encontram-se todos os tipos (ALI, AIE, EE, SE, CE). Não é necessário 
a identificação dos TAR e TED de cada função. 
 2º PASSO: 
Todos os ALI e AIE têm sua complexidade avaliada como baixa. Todos 
os EE, SE, CE são avaliados como de complexidade. 
 3º PASSO: 
Calcula-se o total de pontos de função não ajustados, utilizando a 
classificação de complexidade. A diferença à contagem usual de 
pontos de função é que a complexidade não é determinada 
individualmente, mas pré-definida para todos. 
 Exemplo: 
 O usuário deseja adicionar, alterar, excluir e consultar dados de 
Clientes, necessita de 4 diferentes tipos de relatórios contendo dados 
calculados; deseja adicionar, alterar, excluir e consultar dados de Produtos, 
necessita de um relatório de produtos; deseja consultar o Fornecedor por 
meio de seu número e precisa de um relatório sobre Fornecedor com 
totalização de resultados. Veja como ficariam essas requisições: 
 
 
 
016 
Quadro 3 – Requisições 
 
 
5.3 Contagem Detalhada 
 É utilizada na fase em que se possui um grande conhecimento da 
proposta de desenvolvimento (dados detalhados do processo). Saber 
somente o número de funções de cada tipo (EE, SE, CE, ALI, AIE) não é o 
suficiente, também é necessário determinar a complexidade funcional (Baixa, 
Média, Alta) de cada função individualmente. 
 Os requisitos dos usuários precisam ser analisados com mais detalhes: 
é preciso identificar quais elementos de dados e arquivos lógicos são usados 
por cada função transacional, e quais grupos lógicos e elementos de dados 
compõem cada função. 
FINALIZANDO 
 O surgimento de sistemas de software complexos resultou na 
necessidade de reavaliar a forma de desenvolver sistemas. A técnica tem 
evoluído de forma impressionante, notavelmente no que tange ao seu 
 
 
017 
desenvolvimento. A precisão da estimativa do tamanho de uma aplicação 
varia de acordo com o grau de conhecimento adquirido sobre ela, ou, em 
outras palavras, da fase em que se encontra o projeto. Segundo a empresa 
Software Produtivity Research, “ao final da fase de desenho do sistema é 
possível se fazer estimativas com margem de erro de +/- 10%.” Nesta aula, 
apresentamos técnicas em que pudemos mensurar os esforços que teremos 
no desenvolvimento de nossas apresentações. Tais métodos fazem parte da 
Engenharia de Software como ferramentas que auxiliam o analista a tomar 
decisões sobre condução e controle do desenvolvimento das aplicações em 
TI. 
 
 
 
 
018 
REFERÊNCIAS 
ANÁLISE de pontos de função inicial. Nesma. Disponível em: 
<http://nesma.org/freedocs/analise-de-pontos-de-funcao-inicial/>. Acesso em: 19 
set. 2017. 
AZEVEDO, D. J. P. de. FPA – Function point analysis – sistemática de métrica. 
Bate Byte, 2009. Disponível em: 
<http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=415>. 
Acesso em: 19 set. 2017. 
__MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(2).pdf
ENGENHARIA DE SOFTWARE/EngSoft(3).pdf
ENGENHARIA DE SOFTWARE 
Prof. Emerson Antonio Klisiewicz 
AULA 3
 
 
2 
CONVERSA INICIAL 
Olá! Nesta aula, vamos estudar sobre as metodologias ágeis e seus tipos, 
pois elas também fazem parte do processo de engenharia de software. 
TEMA 1 – PROCESSOS ÁGEIS 
 No fim da década de 90, novos modelos começaram a surgir, assumindo 
que, com as ferramentas e práticas adequadas, era simplesmente mais rentável 
escrever o código rapidamente, avaliá-lo com o usuário e, em caso de erros, 
arrumá-lo rapidamente, que tentar antecipar e documentar todos os requisitos 
primeiro. Nesse contexto, surgem os processos ágeis. 
1.1 Criação do manifesto ágil 
O manifesto ágil foi redigido em uma reunião por um grupo de 17 
indivíduos, todos criadores de diversas metodologias: Kent Beck (XP), Mike 
Beedle, Arie van Bennekum, Alistair Cockburn (Cristal/Clear), Ward Cunningham 
(XP), Martin Fowler, James Grenning, Jim Highsmith (ASD), Andrew Hunt, Ron 
Jeffries (XP), Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken 
Schwaber (SCRUM), Jeff Sutherland (SCRUM) e Dave Thomas. Nessa reunião, 
foram discutidos temas relacionados à metodologia para o desenvolvimento de 
software. 
1.2 O manifesto ágil 
1.2.1 Valores 
Estamos descobrindo maneiras melhores de desenvolver software 
fazendo-o e ajudando os outros fazê-lo. Por meio deste trabalho, concluímos os 
seguintes valores: 
 os indivíduos na equipe e as interações no desenvolvimento são mais 
importantes que processos e ferramentas; 
 software entregue e funcionando é mais importante que ter uma 
documentação completa e totalmente detalhada; 
 a colaboração com o cliente naquilo que ele necessita é mais 
importante que a realização da negociação de contratos; 
 
 
3 
 a adaptação a mudanças do sistema tem uma maior importância que 
seguir um plano inicial. 
1.2.2 Princípios 
 A maior prioridade sempre é satisfazer o cliente por meio da entrega 
antecipada e contínua de software. 
 As mudanças nos requisitos não são problemas, mesmo no final do 
desenvolvimento. Os processos ágeis asseguram que a mudança gerará 
vantagem competitiva para o cliente. 
 As entregas do software funcionando devem ser realizadas com maior 
frequência, a partir de um par de semanas ou meses, com preferência em 
uma escala curta de tempo. 
 Equipes de negócios e desenvolvedores trabalhando juntos diariamente 
durante o desenvolvimento do projeto. 
 A construção de projetos com equipes motivadas. Fornecer o ambiente e 
o apoio de que necessitam, além da confiança necessária para fazer o 
trabalho. 
 O Ágil é um método eficiente e eficaz para transmitir informações para 
dentro da equipe de desenvolvimento. Usa-se a conversa face a face. 
 Ter o software funcionando é a principal forma de se medir o progresso. 
 Os processos ágeis têm um desenvolvimento sustentável. 
Patrocinadores, desenvolvedores e usuários devem ser capazes de 
manter o ritmo constante e de forma indefinida. 
 Sempre deve possuir atenção máxima a excelência técnica e a um bom 
design, aumentando, assim, a agilidade. 
 Ser simples, ou seja, maximizar a importância do trabalho não feito. 
 Possuir equipes auto-organizadas. 
 A equipe de desenvolvimento deve parar e refletir de tempos em tempos 
sobre como se tornar mais eficaz e sintonizar e ajustar seu 
comportamento de acordo com essa reflexão. 
 
 
 
4 
 
Leitura obrigatória 
 Para ampliar seus estudos, leia o capítulo 5, itens 1 a 3 do livro: 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
TEMA 2 – EXTREME PROGRAMMING 
 Nos anos 1990, o engenheiro Kent Beck, ao procurar formas mais 
simples e eficientes para o desenvolvimento de software, identificou o que o 
tornava simples e o que dificultava no desenvolvimento de software. Nesse 
caminho, iniciou a eXtreme Programmin, uma metodologia ágil muito 
utilizada na atualidade. 
 Essa metodologia foi desenvolvida para ser utilizada em equipes 
médias e pequenas (2 a 12 pessoas) e para trabalhar com requisitos vagos 
e em constante
evolução. Também tem um conjunto de valores e práticas 
para nortear o desenvolvimento de software. 
2.1 Princípios 
2.1.1 Comunicação 
 Todos os membros da equipe, sejam clientes, sejam gerentes, sejam 
programadores, devem se relacionar pessoalmente uns com os outros, 
agilizando a comunicação. Se possível, devem trabalhar em um mesmo 
ambiente para se reunirem pessoalmente. 
2.1.2 Simplicidade 
 O projeto do software é simplificado continuamente e o processo de 
desenvolvimento deve ser adaptado, caso essa situação não esteja 
ocorrendo. 
2.1.3 Feedback 
 O cliente deverá estar presente no desenvolvimento do sistema. 
 Testes unitários e de homologação devem fornecer o entendimento sobre 
o desenvolvimento do software. 
 
 
5 
 Questões de oportunidades ou aquelas relacionadas a problemas do 
desenvolvimento devem ser informadas o mais rápido possível. 
2.1.4 Coragem 
 Os membros da equipe de desenvolvimento devem ter coragem para 
indicar situações de problemas encontrados no projeto e para solicitar 
ajuda quando necessário. 
 Informar ao cliente – o mais rápido possível – que não será possível 
implementar um requisito no prazo estimado. 
2.2 O processo 
Figura 1 – Desenvolvimento de software 
 
 Dessa forma, tem-se uma metodologia interessante para usar no 
desenvolvimento de software, porém pode haver possíveis barreiras para o 
sucesso de um projeto XP, como: 
 cultura – pode ser que a organização tenha uma cultura fortemente 
tradicional, com ênfase em metodologias clássicas, muita documentação, 
modelagem etc.; 
 tamanho das equipes – as equipes devem ser pequenas, com no máximo 
12 pessoas, mas nem sempre isso é possível; 
 espaço físico – o local de trabalho deve servir para aproximar as equipes, 
facilitando a comunicação; 
 
 
6 
 cliente: no XP, o cliente deve trabalhar ou estar com equipe de 
desenvolvimento. 
 
Leitura obrigatória 
Para ampliar seus estudos, leia o capítulo 5, item 4. 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
TEMA 3 – SCRUM 
Trata-se de um framework utilizado para organizar times e entregar 
resultados de maneira mais produtiva e com alta qualidade. O Scrum foi 
fundamentado no empirismo, com o emprego de um desenvolvimento iterativo e 
incremental para otimizar a previsibilidade e também controlar os riscos. 
É uma alternativa para utilizar métodos ágeis na gerência de projetos, 
sendo aplicável a qualquer tipo de projeto. Trabalha de forma simples com 
processo, artefatos e regras, que são poucas e fácil entendimento. 
É fundamentado em 3 pilares: 
1. Transparência – A equipe de desenvolvimento deverá ter uma visão clara 
e objetiva de todo o processo. Para isso, o fundamental será a 
comunicação; 
2. Inspeção – Com frequência, os artefatos (backlog do produto, backlog do 
sprint, burndown…) deverão ser verificados, sendo informado assim os 
progressos do projeto; 
3. Adaptação – Se o responsável pela verificação identificar que algum 
processo não está de acordo com o planejado e que o resultado não será 
favorável ao produto, deverá relatar e realizar o ajuste o mais rápido 
possível, a fim de que não haja mais desvios. 
No Scrum, temos 3 papéis de trabalho dentro da equipe: 
I. Product owner – É a pessoa responsável por apresentar os interesses 
de todos os stakeholders. Definirá os planos iniciais do projeto, os 
objetivos e o que será entregue na versão a ser desenvolvida. É 
responsável pela lista de requisitos (product backlog) e por verificar se 
as atividades com maior valor para o negócio serão desenvolvidas 
primeiramente. 
 
 
7 
II. Scrum master – É o responsável pelo sucesso do Scrum, ensinando-o 
para a equipe de projeto. Deverá verificar se cada pessoa envolvida no 
projeto está seguindo os papéis e as regras do Scrum, a fim de garantir 
que aquelas não responsáveis pelo processo interfiram no 
desenvolvimento. 
III. Time – É a equipe. Serão os responsáveis por escolher as 
funcionalidades a serem desenvolvidas em cada interação e 
desenvolvê-las. A equipe de se autogerenciar. Todos os membros são 
coletivamente responsáveis pelo sucesso de cada entrega do 
desenvolvimento. 
3.1 O processo 
Figura 2 – SCRUM 
 
Fonte: Elaborado com base em Agile Software Development with Scrum (Schraber & Beedle). 
 
Beedle citou que “O Scrum pressupõe o caos...”, mas, na verdade, 
capacita as equipes de desenvolvimento a trabalhar em processos que 
normalmente não são livres da incerteza. 
Leitura obrigatória 
Para ampliar seus estudos, leia o capítulo 5, item 2. 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
 
 
8 
TEMA 4 – ESTIMATIVAS 
Nas metodologias ágeis, estimativas de esforço e tempo são calculadas a 
partir de estórias (requisitos). Essa atividade é de responsabilidade de toda a 
equipe técnica, e isso por alguns motivos, alguns dos quais são citados a seguir. 
 Quando se está planejando o desenvolvimento, normalmente não se sabe 
exatamente quem vai implementar quais partes dos requisitos. 
 Estórias normalmente envolvem diversas pessoas com diferentes 
conhecimentos (design de interface de usuário, codificação, teste etc.). 
 Para realizar uma estimativa, a equipe precisa de algum tipo de 
compreensão de cada estória. Um maior entendimento do contexto 
aumenta as chances dos membros da equipe se ajudarem durante a 
iteração. Isso também ajuda a aumentar a probabilidade de que questões 
importantes sobre a estória/requisito surjam cedo. 
 Quando todos da equipe estimam uma estória/requerimento, é frequente 
que se encontrem desconexões onde mais de um membro da equipe 
tenha estimativa bastante diferente para a mesma estória/requerimento. 
É necessário discutir essas situações antes do início da iteração. 
Nas metodologias ágeis, as estimativas seguem um questionamento 
relacionado a uma grandeza, e não especificamente a um número, como no 
exemplo abaixo. 
Figura 3 – Tamanhos/estimativas 
 
Os tamanhos/estimativas estão sendo dados por uma grandeza, e não 
por um número/valor. 
Leitura obrigatória 
Para ampliar seus estudos, leia o capítulo 33, item 9. 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
 
 
9 
TEMA 5 – PLANNING POKER 
É uma técnica de estimativa que busca o consenso. Apesar de 
usualmente ser utilizada no processo de planejamento ágil, não se trata da única. 
No Scrum, o planning poker é realizado durante o sprint planning metting. Nessa 
forma de estimativa, cada integrante tem à sua disposição um baralho de 13 
cartas, numeradas em uma sequência encontrada nos números de Fibonacci. 
Figura 4 – Planning poker 
 
 
O objetivo de utilizar esses números não lineares é que o intervalo entre os 
valores permite visualizar melhor as diferenças de complexidade entre as 
funcionalidades sugeridas pelo requisito/estória dessa forma, evitando a 
impressão falsa de precisão na estimativa. Exemplo: se para um item foi dada 
uma estimativa de 20 pontos, não faz muita diferença se pudesse ser dado um 
valor próximo. Portanto, esse valor trata-se de um palpite aproximado. 
Valores acima de 20 são considerados altos e, portanto, trata-se de uma 
estória/requerimento com um tamanho maior, que pode não ser completamente 
finalizada numa única iteração. 
O recomendável é que, ao final da estimativa, usando o planning poker, seja 
possível fazer com que as estórias/requerimentos da iteração tenham algum 
valor no intervalo de 1∕2 a 13. 
No baralho do planning poker, podemos encontrar algumas cartas com 
propósitos especiais: 
 carta com valor 0 (zero), indicando que uma estória
está finalizada ou é 
muito pequena, podendo ser resolvida rapidamente; 
 
 
10 
 carta com ? (interrogação), indicando que o membro da equipe não tem o 
conhecimento apropriado para estimar/opinar sobre o esforço necessário 
para a estória/requerimento. 
Durante o planning poker, devem ser realizadas rodadas para obter a 
estimativa da estória/requerimento com base nesses valores. As diferenças que 
surgirem durante essas rodadas deverão ser mediadas por um coordenador. No 
Scrum, esse papel é de responsabilidade do scrum master. 
5.1 Planning poker – Jogando 
As estórias/requerimentos são apresentadas uma por vez. O product 
owner as descreve para a equipe Scrum de desenvolvimento e fornece 
informações a respeito do seu valor de negócio. A seguir, o coordenador 
pergunta aos membros da equipe o esforço necessário para desenvolvê-la. 
Cada membro da equipe reflete a respeito do tempo e do esforço 
necessários para implementar a estória/requerimento apresentado. 
 
Os membros da equipe estimam considerando todas as tarefas 
envolvidas no desenvolver (testar, criar design etc.). Então, o membro da equipe 
escolhe uma carta no baralho correspondente ao valor dessa estimativa e 
coloca-a virada para baixo. Quando todos fizerem o procedimento acima, 
revelam-se as cartas escolhidas simultaneamente. 
 
 
 
 
 
 
 
 
 
11 
Isso faz com que cada membro da equipe pense por si próprio na hora de 
uma decisão da estimativa. Todos avaliam os resultados e verificam se houve 
convergência entre as cartas mostradas, ou seja, todas as estimativas têm 
valores aproximados para a mesma estória/requerimento. 
Se não houver essa convergência, o scrum master solicita aos membros 
que mostraram o menor e o maior valor que expliquem o motivo que os levou a 
tal decisão. Isso faz com que os integrantes reflitam sobre alguns pontos da 
estória/requerimento, o que pode fazer com que mudem os valores propostos 
para as estimativas. Então, uma nova rodada é realizada até que as estimativas 
cheguem a uma convergência. 
 
A estimativa final será o valor que tiver maior ocorrência ou a média entre 
as estimativas informadas. Então, começa uma nova rodada com a leitura da 
próxima estória/requerimento pelo product owner. O processo se repete até que 
tenha sido concluída a estimativa das estórias dos itens do product backlog. 
Leitura obrigatória 
Para ampliar seus estudos, leia o capítulo 33, item 9. 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
FINALIZANDO 
As metodologias ágeis seguem o parâmetro de sempre ter equipes de 
desenvolvimento que se autogerenciem, que tenham controle sobre o que estão 
desenvolvendo e tenham uma grande comunicação não só entre os membros 
das equipes para também com os clientes que recebem o produto desenvolvido, 
pois a ênfase aqui é que o cliente esteja recebendo constantemente entregas do 
desenvolvimento que agreguem ao seu negócio, trazendo, assim, sua 
satisfação. 
 
 
12 
REFERÊNCIAS 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
__MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(3).pdf
ENGENHARIA DE SOFTWARE/EngSoft(4).pdf
AULA 4 
ENGENHARIA DE SOFTWARE 
Prof. Emerson Antonio Klisiewicz 
 
 
02 
CONVERSA INICIAL 
Olá, aluno. Nesta aula, vamos estudar as métricas em projetos de testes 
para o desenvolvimento de sistemas que também fazem parte do processo de 
engenharia de software. Bons estudos! 
CONTEXTUALIZANDO 
“O teste consiste em executar o programa com a intenção de encontrar 
erros (bugs)”, Myers, 1979. Por que temos que testar os softwares? Será que 
alguém se sentiria confortável, tranquilo em ser o passageiro de um avião que 
nunca tivesse decolado antes? Itens como qualidade de software, corretitude, 
confiabilidade são vitais para um software, e todos eles são construídos a partir 
de um excelente programa de testes. 
TEMA 1 – TERMINOLOGIAS 
1.1 Garantia de qualidade de software 
É um conjunto de atividades técnicas que devem ser aplicadas durante todo 
o processo de desenvolvimento de um software. O objetivo é garantir que tanto o 
processo de desenvolvimento do software quanto o produto que será entregue 
tenham os padrões de qualidade especificados. 
1.2 Validação 
Garantirá que o produto final desenvolvido corresponda plenamente aos 
requisitos solicitados pelo usuário. 
1.3 Verificação 
Visa assegurar a consistência, a completude e a corretude do software 
desenvolvido em cada fase do projeto e entre as fases consecutivas do ciclo de 
vida do software. 
1.4 Teste 
Visa garantir o funcionamento do software pelo exame do comportamento 
do produto por meio da sua execução. 
 
 
03 
 
1.5 Defeito 
Deficiência mecânica ou algorítmica encontrada no software que, se 
ativada, pode levar o produto a ter uma falha. 
1.6 Erro 
É um item da informação ou estado de execução do produto de software 
inconsistente. 
1.7 Falha 
É a situação encontrada em que o sistema desenvolvido viola suas 
especificações. 
TEMA 2 – DETALHANDO ITENS DA TERMINOLOGIA 
2.1 Defeitos 
A principal causa encontrada nas ocorrências de defeitos é a tradução 
incorreta das informações. No projeto de desenvolvimento, quanto menor o 
tempo para esse defeito for revelado, menor também será o custo de correção 
e probabilidade da correção ocorrer de forma correta. A solução é 
introduzirmos pontos de verificação, validação e testes ao longo de todo o 
ciclo de desenvolvimento. 
2.2 Teste 
É o processo de execução de um programa com o objetivo de revelar 
a presença de erros. Contribui para aumentar a confiança de que o software 
desempenha as funções especificadas. Deve-se ter um conjunto de passos 
ao qual seja possível alocar técnicas de projeto de casos de teste e 
estratégias de teste específicos durante o desenvolvimento. 
2.3 Depuração 
 
 
04 
É uma situação não previsível ocorrida no teste. Depois de revelada a 
presença do erro, ele deve ser corrigido. O processo de depuração é a parte 
mais imprevisível do processo de teste. 
2.4 Falha 
Incapacidade do software desenvolvido de realizar a função 
requisitada. 
2.5 Erro 
Trata-se do estado de instabilidade. Veja, abaixo, a relação entre as 
questões de falhas em sistemas. 
 
O processo de teste deve ser revisto continuamente, a fim de ampliar sua 
atuação para possibilitar aos profissionais uma maior visibilidade e organização 
dos seus trabalhos, resultando em uma maior agilidade e controle operacional dos 
projetos de testes. 
Conhecendo-se o funcionamento interno de um produto, testes podem ser 
realizados para garantir que “todas as engrenagens”, ou seja, que a operação 
interna de um produto tenha um desempenho de acordo com as especificações e 
que os componentes internos foram adequadamente postos à prova. 
TEMA 3 – TÉCNICA ESTRUTURAL: CAIXA BRANCA 
É um método de projeto de testes que usa a estrutura de controle do projeto 
procedimental para derivar casos de teste. Baseia-se no exame dos detalhes 
procedimentais em que os caminhos do software são testados, porém não é viável 
testar todos os caminhos lógicos de um programa. 
Na Técnica de Caixa Branca, o engenheiro de software, por meio dos casos 
de teste, vai: 
 Garantir que todos os caminhos lógicos, independentes do módulo, tenham 
sido exercitados pelo menos uma vez; 
 Executar todas as decisões lógicas em seus lados verdadeiro e falso; 
 
 
05 
 Executar todos os ciclos nos seus limites e dentro de seus intervalos 
operacionais; 
 Executar as estruturas de dados internas. 
Nessa ideia, temos o Teste do Caminho Básico. Trata-se de uma técnica 
que vai permitir a definição
de um conjunto-base de caminhos de testes a serem 
executados. Ele é baseado no fluxo de controle e no conceito da complexidade 
ciclomática. 
Antes, porém, vamos ver uma notação para representar o fluxo de controle. 
3.1 Grafos 
Grafos mostram o fluxo de controle. O Nós vai representar um ou mais 
processos; as Arestas, o fluxo de controle do programa ou estrutura do programa. 
Figura 1 – Fluxo de controle 
 
A definição de regiões do grafo são áreas limitadas pelas arestas e nós. 
Nelas, podemos ter a seguinte notação: 
 
 
06 
Figura 2 – Regiões de grafo 
 
 
 
 
 
 
Exemplo: 
 
 
3.2 Teste do caminho básico 
 
 
07 
Para criarmos um teste do caminho básico, precisamos executar as 
seguintes situações: 
 Construir um grafo para o módulo do programa em teste; 
 Fazer o cálculo do valor da complexidade ciclomática; 
 Optar por um conjunto de caminhos básicos; 
 Fazer a criação de um caso de teste para cada caminho básico; 
 Executar todos os casos de testes. 
3.2.1 Complexidade ciclomática 
É fundamentada na teoria dos grafos, fornecendo uma métrica de cálculo 
para testes muito interessante. Ela nos dá um limite de número de casos de testes 
que deveriam ser executados para que se garanta que cada comando/caminho 
de execução de um programa tenha sido passado ao menos uma vez. Isso é 
realmente útil para quando temos módulos com tendências maiores a erros. Ela 
pode ser calculada usando-se a seguinte fórmula: 
V(G) = E – N + 2, onde: 
 E: número de ramos do grafo; 
 N: número de nós do grafo. 
 
Ex.: Usando a figura abaixo, teríamos: 
 
V(G) = 17 arestas – 13 nós + 2 = 6. 
 
Portanto, a complexidade para o exemplo acima seria 6. Esse será o 
número de caminhos a serem seguidos pela estrutura do programa, conforme 
descrito abaixo: 
 
 
08 
Caminho 1: 1-2-10-11-13 
Caminho 2: 1-2-10-12-13 
Caminho 3: 1-2-3-10-11-13 
Caminho 4: 1-2-3-4-5-8-9-2-... 
Caminho 5: 1-2-3-4-5-6-8-9-2-... 
Caminho 6: 1-2-3-4-5-6-7-8-9-2-... 
Nos caminhos 4, 5 e 6, as reticências indicam que se pode tomar qualquer 
caminho no restante da estrutura que não comprometerá o resultado do teste. 
Com isso, os testes devem ser realizados para que façam esses caminhos ao 
menos 1 vez. 
TEMA 4 – TÉCNICA FUNCIONAL: CAIXA-PRETA 
Primeiramente, usamos o particionamento de equivalências, técnica que se 
adequa aos testes com valores típicos de uma entrada em um programa. Os casos 
de teste são elaborados sabendo-se quais serão as entradas, de forma 
sistemática e direta. Para acharmos essas equivalências, siga estes passos: 
a. Definir as chamadas condições de entrada, qualquer intervalo de entradas 
válidas em um programa. Ex.: Faixa de valores 1 < CODIGO<99, vetores 
com X número de elementos, etc.; 
b. Definir as classes de equivalência, que podem ser válidas ou inválidas. São 
definidas pela condição de entrada. Ex: 1< CODIGO < 99 Classe válida : 1 
<CODIGO< 99. Classes inválidas: CODIGO <= 1 e CODIGO >= 99; 
c. Para cada classe que for inválida, será criado um caso de teste. As classes 
declaradas válidas, os casos de teste serão gerados para atender a maior 
quantidade possível de entradas válidas. 
Exemplo: 
 
 
 
 
09 
Nessa técnica, podemos ter alguma dificuldade em quantificar os 
testes e acontecer de deixarmos partes essenciais críticas do sistema sem os 
devidos testes. Também podemos citar como uma dificuldade nessa técnica 
a questão da automatização dos testes. 
TEMA 5 – TEST DRIVEN DEVELOPMENT (TDD) 
Sobre os testes, temos uma metodologia chamada de ágil, que está 
crescendo no mercado em que os testes são vitais para o desenvolvimento. A 
Test Driven Development, ou simplesmente TDD, é um desenvolvimento guiado 
por testes. O primeiro livro sobre esse assunto foi escrito por Kent Beck. Trata-se 
de um método de desenvolvimento fácil de explicar, porém difícil de aprender, 
mas de retorno garantido. 
Essa forma de desenvolvimento deixa o código mais claro, os testes são 
documentações executáveis que garantem funcionalidades do domínio do 
problema. Nesse tipo de desenvolvimento, se algum teste parou de rodar, 
sabemos que algo deu errado. Isso trará economia de tempo e dinheiro em 
manutenção, e a escrita de testes ajuda na melhoria do design do código. Outras 
vantagens são: 
 Com a utilização do método ganhando experiência, já no início da 
implementação de um método, o desenvolvedor poderá refletir sobre como 
fará para testá-lo; 
 Ao iniciar mais cedo, os testes são feitos, aumentam as chances de que 
erros sejam encontrados na sua fase inicial de desenvolvimento, evitando 
que se espalhem pela aplicação, tornando-os mais simples de serem 
resolvidos. 
A base do TDD é a seguinte: os testes serão escritos antes do código. 
Ele é uma técnica para desenvolvimento de software formado por pequenas 
iterações para o desenvolvimento de uma nova funcionalidade, sempre iniciando 
pela construção do caso de teste para depois construir o código para fazer o 
teste passar e, finalmente, pela realização da refatoração do código visando 
melhorá-lo, incluindo as mudanças realizadas. O TDD vem da ideia de “test-first 
programming” do XP (Extreme Programming). 
Os passos da construção com TDD são os seguintes: 
a. Crie o teste; 
b. Compile-o e execute-o (com certeza não irá – vermelho); 
 
 
010 
c. Então, codifique o requisito e faça-o passá-lo pelo o teste (verde); 
d. Realize a refatoração do código para melhorá-lo. 
A metodologia TDD é conduzida por “testes do programador” ou testes 
unitários. É de se destacar que não se tratam dos testes de sistema nem os 
de homologação (feitos pelo usuário final). Siga estes princípios: 
1. Construa testes isolados uns dos outros: um caso de teste não deve 
depender do sucesso de outro para funcionar. Deve ser possível executar 
um caso de testes isoladamente, sem executar nenhum outro; 
2. Comece definindo uma “Test List”: de modo geral, para uma mesma 
classe ou método que será testado, existirão diferentes casos de teste. 
Devem-se listar todos primeiro; 
3. Primeiro o teste: é chance de refletir sobre o projeto das classes do 
sistema e controlar o escopo. A codificação deve atender somente o 
necessário para o teste corrente; 
4. Primeiro a assertiva: é necessário refletir sobre o que significará se o teste 
executar com sucesso antes de seguirmos adiante. 
5. Dados para teste: para realizar o teste, procure não escolher números 
complexos caso eles não tenham algum significado para o teste. Seja 
simples. Não passe os mesmos valores para diferentes parâmetros. Ex.: 
Ao fazer o teste de um método Operacao (int x, int y), não o faça utilizando 
valores iguais Operacao (2,2). O método “Operacao” poderá inverter o “x” 
e o “y” fazendo o teste passar assim mesmo, dificultando sua análise. 
Procure usar informações do mundo real em seu sistema. 
6. Dados com significado evidente: procurar codificar de forma explicativa 
(comentar), pois vale lembrar que estamos escrevendo testes para outras 
pessoas lerem, e não apenas para ser executados pelo computador. 
FINALIZANDO 
Qualquer conjunto de testes tem a missão de encontrar em um programa 
ou sistema o máximo de bugs possíveis utilizando o mínimo de esforço. Nessa 
aula, vimos como os testes são importantes e a existência de métodos e técnicas 
para que seja possível implementar um plano de testes que garanta a qualidade 
daquilo que se está entregando ao usuário. Os testes nunca finalizam. Mesmo 
após a implantação e, por consequente, seu uso pelo usuário, o sistema será 
 
 
011 
constantemente testado; nesse caso, pelo cliente. E ninguém deseja que ele 
encontre algum tipo de erro. 
 
 
 
012 
REFERÊNCIA 
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma
abordagem 
profissional. 8. ed. Porto Alegre: AMGH, 2016. 
__MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(4).pdf
ENGENHARIA DE SOFTWARE/EngSoft(5).pdf
 
 
AULA 5 
 
 
 
 
 
 
 
 
 
 
ENGENHARIA DE SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Emerson Antonio Klisiewicz 
 
 
02 
CONVERSA INICIAL 
Nesta quinta aula, estudaremos a Qualidade de Software para o 
desenvolvimento de sistemas, que também fazem parte do processo de 
Engenharia de Software. 
CONTEXTUALIZANDO 
É também por meio da Engenharia de Software que objetivamos garantir 
uma qualidade do software, definindo e normatizando os processos durante o 
desenvolvimento dentro de um prazo condizente com a necessidade apresentada 
pelo usuário. 
TEMA 1 – CONCEITOS 
1.1 Qualidade 
Trata-se de uma visão do desenvolvedor que se une à ideia de que o 
software sempre deve atender às necessidades do usuário. Para o usuário, 
qualidade é a ideia do valor, sua utilidade e o cumprimento de todos os requisitos 
por ele solicitados. 
1.2 Funcionalidade 
Tratam-se dos atributos, das funções e propriedades particulares do 
software que vão satisfazer as necessidades impostas pelos requisitos do usuário. 
1.3 Resumindo 
Figura 1 – Resumo dos conceitos 
 
 
 
 
03 
Leitura complementar 
Engenharia de Software – Uma abordagem profissional. 8.ª edição. Por 
Roger Pressman e Bruce Maxim. Capítulo 21. 
TEMA 2 – QUAL A NECESSIDADE DE SE MEDIR A QUALIDADE? 
É necessário ter um valor para comparação. Ao medir e realizar uma 
comparação do software com alguma informação (dado) é possível ter, desse 
modo, um indicador de qualidade. 
Mas, então, o que vamos medir? Nesse caso, teremos opções como o 
processo e o próprio produto desenvolvido. Nesse procedimento, teremos vários 
fatores que afetaram a qualidade e que podemos dividir em dois segmentos: os 
que podem ser medidos diretamente como tempo, custos e produção; e os que 
não podem ser medidos de forma direta, como questões de usabilidade e 
manutenção, que são muito subjetivos e difíceis de mensurar. 
A qualidade necessita ser medida de forma comparativa com padrões e 
também critérios que devem ser pré-definidos. Por exemplo: medir e comparar o 
software desenvolvido com alguma informação padrão e obter um indicador de 
qualidade. 
2.1 Mas o que é necessário medir? 
Podemos decidir medir diversas situações dentro do ciclo de 
desenvolvimento do software, como o tempo e custo do processo, o desempenho 
do software e os resultados obtidos por ele. Poderemos também medir a produção 
da equipe e também quais os recursos que foram usados efetivamente no 
processo. Dessa forma, poderemos criar padrões, estimativas e com elas aplicar 
correções, sejam elas corretivas ou preventivas diante dos riscos encontrados. 
2.2 Fatores de qualidade 
Vamos encontrar diversos fatores que afetarão a qualidade do software, 
como características de operação, capacidade em agregar mudanças, sua 
adaptação a novos contextos. Essas situações podem ser agrupadas nas 
seguintes categorias: revisão do software, operação do software e transição do 
software. 
 
 
04 
2.2.1 Revisão 
Dentro desse item, nós teremos três situações: a questão da manutenção, 
que visa verificar quanto o software foi desenvolvido, já prevendo futuras 
alterações; da flexibilidade, que mostrará quanto de esforço deveremos gastar 
para realizar qualquer alteração; e da testabilidade, que empregará testes para 
verificar se o software foi desenvolvido conforme suas especificações. 
2.2.2 Operação 
Nesse quesito, atenderemos aos seguintes itens: corretagem, que 
atenderá a especificações e objetivos definidos pelo usuário; confiabilidade, que 
verificará se o software sempre executa do mesmo jeito e com a precisão exigida; 
eficiência, que trará a quantidade de recursos necessários para o programa 
executar; integridade, que verificará se o controle de acesso é controlado; e 
usabilidade, que traz o esforço para aprender a trabalhar com o software. 
2.2.3 Transição 
Na transição, vemos questões como a portabilidade, que mede o esforço 
para transferir o programa a outro ambiente de produção, bem como a questão 
da reusabilidade, que demonstrará como usar o software ou parte dele em outras 
aplicações, e também a interoperabilidade, que verificará o esforço para fazer a 
união de um sistema a outro, integrando, assim, soluções. 
TEMA 3 – ELEMENTOS DE GARANTIA DE SOFTWARE 
Engloba preocupações e atividades que se concentram na gestão da 
qualidade do software. Dentre elas, podemos sintetizar as seguintes. 
3.1 Padrões 
O IEEE, a ISSO e outras padronizações possuem grande quantidade de 
padrões e documentos que ajudam no gerenciamento da qualidade do software. 
3.2 Revisões e auditorias 
Formalizará e controlará todas as solicitações de mudança no software 
tanto no desenvolvimento como após sua implantação e posterior manutenção. 
 
 
05 
3.3 Testes 
Detectarão possíveis falhas e erros no desenvolvimento e manutenção do 
software, mas somente isso não é o suficiente. 
3.4 Coleta e análise de erros/defeitos 
Coleta é um conjunto de medidas técnicas e orientadas à administração 
das especificações do software. Dessa forma, com dados em mãos é possível 
compreender como os erros surgem e quais soluções dentro da engenharia de 
software podemos usar para sua eliminação. 
Leitura complementar 
Engenharia de Software – Uma abordagem profissional, 8.ª edição, por 
Roger Pressman e Bruce Maxim – capítulo 21, itens 1 e 2. 
TEMA 4 – SQA: PROCESSOS 
A garantia da qualidade de software (Software Quality Assurance – SQA) 
deve ser aplicada em todo o processo de engenharia de software. Avaliações, 
auditorias e revisões vão definir padrões para o projeto, procedimentos para a 
geração de relatórios de acompanhamento de erros e também a criação de uma 
documentação necessária que vai instruir a equipe com conclusões a respeito do 
projeto do software. Dentre elas, podemos sintetizar nos itens a seguir. 
4.1 Revisões de software 
Métodos de validação de qualidade usados pela equipe de 
desenvolvimento do software. Eles filtrarão erros e inconsistências no processo 
de desenvolvimento, tendo como objetivos reportar melhorias no produto ou parte 
dele e tornar o trabalho técnico de desenvolvimento mais administrável. 
4.1.1 Tipos de revisões 
 Inspeções de projeto ou programa, que vão detectar erros nos requisitos, 
projeto ou código. 
 Revisões de progresso, que informarão para os GPs do projeto o progresso 
geral do desenvolvimento (planejamento, custos e prazos). 
 
 
06 
 Revisões de qualidade, que farão uma análise técnica do produto ou 
documentação para verificar se existem inconsistências entre a 
especificação e o projeto, entre o código e documentação e também 
assegurar se padrões de qualidade foram seguidos. 
4.2 Revisão técnica formal 
Trata-se da principal atividade de um SQA, que tem por objetivos verificar 
se o software atende a todos os requisitos. Também visa garantir que o software 
está de acordo com padrões pré-definidos pelo usuário. Obter um software 
desenvolvido de forma uniforme e tornar os projetos de desenvolvimento mais 
administráveis também está entre os objetivos dessa técnica. Cada uma dessas 
revisões é conduzida na forma de uma reunião que segue os seguintes padrões: 
 Restrições à reunião (duração de até 2h). 
 Participação de 3 a 5 pessoas, com preparação antecipada. Foco: um 
produto ou um componente de software que se está desenvolvendo. 
Ao final da reunião, o objetivo será todos aceitarem ou rejeitarem, ou ainda, 
aceitarem temporariamente o que foi apresentado. 
Leitura complementar 
Engenharia de Software – Uma abordagem profissional. 8. ed. Por Roger 
Pressman e Bruce
Maxim. Capítulo 21, item 3. 
TEMA 5 – NORMAS: NBR ISO 
Um sistema de garantia da qualidade pode ser definido como a estrutura 
organizacional com responsabilidades, procedimentos, processos e recursos para 
implementação da gestão (ANS, 87). 
O controle de qualidade e o uso dos padrões baseados em normas ISO 
estão influenciando a forma como a qualidade está sendo usada nas últimas 
décadas, mas historicamente o assunto é muito antigo. 
Em relatos existentes há mais de quatro mil anos, os egípcios já 
estabeleciam um padrão de medida de comprimento conhecido como cúbito, que 
correspondia ao comprimento do braço do faraó reinante. Era utilizado assim 
como a unidade de medida nas construções egípcias. Porém, havia um problema 
quando um novo faraó assumia o poder, pois, assim, a unidade de medida 
 
 
07 
também se modificava. Interessante também era a punição para quem não 
aceitava a mudança: a morte. 
A ISO 9000 descreve elementos de garantia da qualidade em termos gerais 
que podem ser aplicados a qualquer empresa, independentemente do tipo de 
produtos ou serviços oferecidos. A necessidade das organizações se tornarem 
competitivas passa a ser enfatizada como motivo para a adoção de sistemas que 
resultem na qualidade. A ISO tem como princípios: 
 Descrever elementos de garantia em termos genéricos, que podem ser 
aplicados aos negócios (produto ou serviço). 
 Ter um modelo de qualidade que define responsabilidades, crie 
procedimentos e processos, capacite recursos para realização de uma 
gestão da qualidade. 
A empresa, ao adotar essa norma, com certeza vai ganhar produtividade e 
credibilidade, aumentando sua competitividade no mercado, podendo ser uma 
diferenciação e, desse modo, possibilitar à empresa buscar novas oportunidades 
em um mercado global. 
A certificação é possível seguindo-se os passos: 
1. Empresa contrata consultoria específica. 
2. Empresa se qualifica para a auditoria de acreditação da ISO. 
3. É feita uma avaliação da conformidade do sistema de garantia da qualidade 
e não se certifica o SOFTWARE e sim a capacidade de desenvolvimento. 
Geralmente certifica-se por área de atividade da empresa (não na 
totalidade). 
4. Uma vez qualificada (auditoria de validade), a empresa recebe o certificado. 
5. Começam as auditorias de vigilância – semestrais ou anuais. 
A ISO 9000 surge como alternativa para melhoria do processo de 
desenvolvimento das empresas, gerando produtos e serviços mais competitivos 
nos mercados nacional e internacional. A certificação ISO surge como um 
diferencial para que a empresa consiga atingir melhores patamares e 
oportunidades num mercado que hoje se apresenta na forma global. 
5.1 NBR 13596 
A seguir mostramos quais são as características das normas NBR 13596, 
que são uma versão brasileira da ISO 9126. 
 
 
08 
Quadro 1 – Características da norma NBR 13596 
 
Quadro 2 – Mais características da norma NBR 13596 
 
 
Mas como podemos aplicar as normas ISO/NBR? 
Para avaliar um software segundo uma norma, deve-se tentar atribuir 
valores (notas ou conceitos) a cada uma das subcaracterísticas. Porém, é difícil 
aplicar uma norma sem se estar familiarizado com todo o processo de avaliação 
de software. Guias para a avaliação da qualidade descrevem, detalhadamente 
todos os passos para se avaliar um software. 
5.2 ISO 9000-3 
Trata-se de um guia, criada em 1993, para a aplicação da ISO 9001 voltada 
ao desenvolvimento, fornecimento e manutenção de um software. Ela especifica 
 
 
09 
os requisitos mínimos para assegurar a qualidade de produtos de software e 
serviços, porém não define modelos ou impõe sistemas de qualidade. 
Ela agrupa as atividades do ciclo de vida em nove categorias: análise crítica 
do contrato, especificação dos requisitos do comprador, planejamento do 
desenvolvimento, planejamento da qualidade, projeto e implementação, ensaios 
e validação, aceitação, cópia, entrega e instalação, manutenção. 
Ela agrupa as atividades relacionadas a suporte em nove situações: gestão 
de configuração, controle de documentos, registros da qualidade, medição, 
regras, práticas e convenções, ferramentas e técnicas, aquisição, produto de 
software incluído e treinamento. 
A seguir, o fluxo do processo para a certificação. 
Figura 2 – Fluxo do processo para certificação 
 
 
A seguir, um quadro com mais algumas normas ISO e as suas 
características. 
 
 
010 
Quadro 3 – Normas ISO e características 
 
Leitura complementar 
Engenharia de Software – Uma abordagem profissional 8. ed. Por Roger 
Pressman e Bruce Maxim. Capítulo 21, item 8. 
FINALIZANDO 
No desenvolvimento de softwares, a qualidade no processo deve existir 
desde o início. Possuir aferições em cada fase, com métricas, fatores de qualidade 
e padrões é de vital importância para o sucesso. Buscar inconsistências ter um 
bom SQA – Software Quality Assurance, realizar avaliações, auditorias, revisões 
constantemente e ter atividades de controle das mudanças fará toda a diferença 
no sucesso do desenvolvimento. Num mundo tão competitivo em que estamos, 
ter uma boa documentação e qualidade no produto que se está entregando 
selecionará a empresa, que crescerá ou não no mercado de software. 
 
 
 
011 
REFERÊNCIAS 
PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem 
profissional. 8. ed. Porto Alegre: McGraw-Hill, 2016. 
__MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(5).pdf
ENGENHARIA DE SOFTWARE/EngSoft(6).pdf
 
 
AULA 6 
 
 
 
 
 
 
 
 
 
ENGENHARIA DE SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Emerson Antonio Klisiewicz 
 
 
 
02 
CONVERSA INICIAL 
Nesta aula 6, estudaremos o gerenciamento da configuração de software e 
sobre as questões envolvidas na segurança da informação. 
CONTEXTUALIZANDO 
Tanto a configuração de software que envolve questões críticas no 
desenvolvimento, por exemplo, o versionamento de aplicações, como as questões 
sobre segurança no tratamento das informações fornecidas e processadas pelos 
softwares são vitais termos o controle no mundo competitivo de desenvolvimento 
que temos hoje. 
TEMA 1 – GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE: 
PROBLEMAS 
1.1 Problema dos dados compartilhados 
Figura 1 – Dados compartilhados 
 
Na situação anterior, o desenvolvedor A modifica um software que está 
compartilhado. Posteriormente, o desenvolvedor B realiza algumas alterações no 
mesmo software e, ao tentar compilá-lo, erros são apontados pelo compilador, 
mas nenhum deles ocorre na parte que B alterou, deixando o desenvolvedor B 
sem a menor ideia da causa do problema. 
Uma solução simples seria cada desenvolvedor trabalhar em uma cópia 
“local” do software. Isso resolve o problema dos softwares compartilhados, porém, 
cria um novo problema. 
 
 
03 
1.2 Problema da manutenção múltipla 
Figura 2 – Manutenção múltipla 
 
Ocorre quando cada desenvolvedor trabalha com uma cópia “local” do que 
seria o mesmo software. Isso dificultará a identificação das funcionalidades que 
foram implementadas e em quais versões, bem como quais erros foram corrigidos. 
Podemos evitá-lo por intermédio do uso de uma biblioteca central com o software. 
Nessa proposta, cada software é copiado para a biblioteca sempre que for 
alterado. Contudo, ainda não é o ideal. 
1.3 Problema da atualização simultânea 
Figura 3 – Atualização simultânea 
 
Nesse caso, o desenvolvedor A encontra e faz a correção de um erro na 
sua versão do software. Depois de corrigido, o software modificado é copiado para 
a biblioteca central. O desenvolvedor B encontra-o e faz a correção do mesmo 
defeito na sua versão do software, por não saber que A já tinha feito, 
desperdiçando todo o trabalho de A.
Em outra situação, o desenvolvedor A encontra e corrige um defeito em 
sua versão compartilhada. Uma vez corrigido, ele copia para a biblioteca central. 
 
 
04 
O desenvolvedor B encontra o software e corrige outro erro em sua versão do 
componente, sem saber do defeito corrigido por A. O desenvolvedor B copia sua 
versão do componente para a biblioteca central. Além do trabalho de A ser 
desperdiçado, a versão que está na biblioteca central continua apresentando erro, 
sendo que o desenvolvedor A pensa que o problema foi resolvido. 
Para resolver essa situação, precisamos ter um mecanismo de controle 
para gerenciar a entrada e saída das versões da biblioteca central. 
Leitura complementar 
Engenharia de Software: uma abordagem profissional. 8. Ed. Por Roger 
Pressman e Bruce Maxim. Capítulo 29. 
TEMA 2 – GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE: POR QUE 
USAR 
A aplicação do gerenciamento de configuração de software dentro das 
empresas oferece um ambiente de desenvolvimento de software estável, porque 
qualquer alteração sem controle de softwares torna todo o desenvolvimento 
caótico. 
O gerenciamento de configuração de software nos oferece uma “memória” 
da situação do desenvolvimento dos softwares em nossa empresa. Quando 
muitas pessoas estão trabalhando no mesmo projeto, esse gerenciamento vai 
coordenar o acesso às alterações a serem feitas nos softwares que estão sendo 
desenvolvidos. 
Dentre as tarefas que um gerenciamento de configuração possui, podemos 
citar os descritos a seguir. 
 
 
05 
Quadro 1 – Tarefas de um gerenciamento de configuração de software 
 
 
 
TEMA 3 – REPOSITÓRIO DOS ITENS DE CONFIGURAÇÃO 
Um repositório de itens de configuração é um local com controle de onde 
são armazenados os itens de configuração de software depois de liberados pelo 
desenvolvimento. Todos os itens de configuração devem ser identificados, 
analisados, corrigidos, aprovados e armazenados no repositório de itens de 
configuração, para posteriormente serem enviados para as áreas de produção. 
Todos os módulos de um repositório de itens de configuração só poderão 
ser alterados após uma solicitação de alteração formalmente aprovada pelo 
gerente de configuração. Isso é importante para que somente pessoas realmente 
autorizadas possam acessar o módulo. Essa também é uma forma para garantir 
o controle sobre cada um dos itens de configuração, evitando alguma 
inconsistência. 
 
 
06 
3.1 Check in/Check out 
Check in/check out é o método utilizado para trabalhar com itens de 
configuração que já estão no repositório, ou seja, trata-se de uma conferência na 
entrada e uma conferência na saída do software do repositório central. Quando 
for necessária a alteração em algum item de configuração do repositório, uma 
cópia do item é colocada numa área de trabalho do desenvolvedor (“check out”). 
Nessa área exclusiva, o desenvolvedor tem total liberdade de trabalho e poderá 
realizar as alterações necessárias no módulo. Veja a figura a seguir: 
Figura 4 – Check out 
 
Após o final das alterações no módulo, ele será revisado e recolocado no 
repositório (“check in”). Uma nova data de alteração será criada para o módulo 
(versão), de modo que uma nova configuração contendo o módulo alterado será 
formada e congelada no repositório. A seguir, essa situação: 
Figura 5 – Check in/check out 
 
 
 
07 
TEMA 4 – CONTROLE DE MUDANÇAS 
Durante o processo de desenvolvimento de software, mudanças 
descontroladas podem levar rapidamente o projeto ao caos. Assim, devemos 
instituir na organização um processo que combine procedimentos humanos e 
ferramentas automatizadas para proporcionar um mecanismo de controle das 
mudanças. 
O processo de controle de mudanças deve ser implementado depois que 
temos as datas em que serão implantadas as modificações realizadas nos 
módulos. A seguir, um exemplo para ilustrar um processo de controle de 
mudanças que pode ser implementado. 
Figura 5 – Exemplo: organograma de processo de controle de mudanças 
 
Os procedimentos de controle das mudanças asseguram que as mudanças 
em um software sejam feitas de modo controlado, permitindo-se prever o efeito 
delas em todo o sistema. Procedimentos formais de organização e de controle das 
mudanças permitem que os pedidos de alteração possam ser considerados em 
conjunto com outros pedidos e isso não afete o ambiente produtivo dos sistemas. 
Também permite a organização e controle das mudanças de pedidos 
incompatíveis entre si ou que possam ser atribuídas prioridades aos pedidos e, 
de acordo com essas prioridades, possam ser gerados cronogramas. 
 
 
08 
4.1 Ferramentas de GCS 
Existem algumas ferramentas de software que podem auxiliar as atividades 
de gerenciamento de configuração de software. Exemplos de ferramentas: 
 CVS (Concurrent Versions System) : <http://www.cvshome.org/>; 
 RCS (Revision Control System): 
<http://www.gnu.org/software/rcs/rcs.html>; 
 SCCS (Source Code Control System): 
<http://www.cvshome.org/cyclic/cyclicpages/sccs.html>; 
 Source Forge (Web Pages Versions Management): 
<http://versionweb.sourceforge.net/>. 
Leitura complementar 
Engenharia de Software: uma abordagem profissional. 8. ed. Por Roger 
Pressman e Bruce Maxim. Capítulo 29. 
TEMA 5 – SEGURANÇA DA INFORMAÇÃO 
Segurança da Informação (SI) é a proteção de sistemas de informação 
contra desastres, erros e manipulação de modo a minimizar a probabilidade e 
impacto de incidentes. Se divide em duas categorias: 
 Ameaças: É a intenção da parte de alguém em causar dano a um 
indivíduo/organização. Nesse item, podemos incluir sabotagem de software 
ou hardware, roubo de informações, ataques a infraestrutura, ataques de 
hackers, incêndio e inundação. Nas ameaças, temos ações em potenciais 
que seguem o caminho de menor resistência, ou seja, mais vulnerável. 
Nesse caso, o risco é medido por meio da probabilidade de que uma 
ameaça pode acontecer e o dano que pode ser gerado à pessoa/empresa. 
 Vulnerabilidade: Aqui é a deficiência na infraestrutura e organização que 
expõem riscos a eventos imprevistos/indesejáveis. Isso pode ocorrer por 
má configuração do sistema operacional, sistema de banco de dados com 
defeito, falha em um programa de acesso a dados, firewall desatualizado e 
falta de um nobreak. 
Na prevenção dentro de SI, temos as seguintes situações. 
 
 
09 
5.1 Confidencialidade 
É a garantia de que a informação é acessível somente por pessoas 
autorizadas para não acontecer a divulgação intencional (ou não) de informações 
reservadas. Questões de confidencialidade surgem porque processos e 
informação sensíveis do negócio só devem ser divulgados para 
pessoal/programas autorizados. Para isso, é imprescindível um controle de 
acesso. 
5.2 Integridade 
Trata-se da garantia da exatidão e completude da informação e dos 
métodos de processamento da informação. As informações não devem ser 
modificadas por pessoas/processos desautorizados. As informações também não 
devem ser inconsistentes e o sistema deve garantir que elas são precisas e 
completas. 
5.3 Disponibilidade 
Nesse item, temos a garantia de que usuários autorizados obtenham 
acesso à informação e aos ativos correspondentes sempre que necessário. A 
informação e os serviços do negócio devem estar disponíveis sempre que forem 
solicitados. Para isso, existe a necessidade de controles para garantir 
confiabilidade dos serviços informatizados. 
5.4 Classificação dos riscos 
5.4.1 Financeiros 
São os riscos envolvidos no relacionamento entre uma organização e o seu 
ativo. Nessa situação, temos o indivíduo ou a organização, que estão expostos a 
riscos, ativos ou receitas, cuja destruição ou perda poderá causar prejuízo 
financeiro ou uma ameaça que possa causar
algum tipo de perda à empresa. 
5.4.2 Não financeiros 
São os riscos representados por perdas não passíveis de mensuração 
financeira. Por exemplo, uma inundação em que milhões de acres de fazendas 
 
 
010 
foram destruídas, causando bilhões de dólares em perdas financeiras para os 
proprietários. Não há como mensurar as perdas financeiras resultantes da 
destruição de fauna e flora selvagem. 
5.5 Exemplos de falta de segurança 
 
 
5.6 Alguns cuidados que devemos ter 
 Utilizar senhas distintas e seguras para cada site ou serviço; 
 Não instalar softwares de fontes duvidosas; 
 Manter seus sistemas sempre atualizados, incluindo antivírus; 
 Evitar conectar pendrives e outros meios de armazenamento de terceiros; 
 Não acessar sites de origem duvidosa; 
 Proteger seus arquivos pessoais em HDs, pendrives e outros dispositivos 
de armazenamento usando soluções que impeçam que seus arquivos 
caiam em mãos erradas, mesmo que o dispositivo eletrônico seja perdido 
ou mesmo roubado; 
 Não clicar em links suspeitos como aqueles recebidos por e-mail ou vistos 
em sites como os de redes sociais; 
 
 
011 
 Não salvar senhas de acesso em navegadores; 
 Ter controle de acesso aos sistemas; 
 Ter logs para saber quem acessou o sistema e o porquê; 
 Trocas automáticas de senha de tempos em tempos. 
 Ter controle de acesso aos locais de desenvolvimento. 
Leitura complementar 
Engenharia de Software: uma abordagem profissional. 8. ed. Por Roger 
Pressman e Bruce Maxim. Capítulo 27. 
FINALIZANDO 
Os computadores são utilizados para realizar inúmeras tarefas, tais como 
transações financeiras, sejam elas bancárias ou mesmo compra de produtos e 
serviços para comunicação, por exemplo; por meio de e-mails e redes sociais 
também armazenamento de dados, sejam eles pessoais ou comerciais, etc. 
Muitos se perguntam o porquê de alguém tentar acessar os nossos computadores 
e sistemas. Sim há muitos motivos: utilizar seu computador em alguma atividade 
ilícita, para esconder a real identidade e localização do invasor, utilizar seu 
computador para lançar ataques contra outros computadores, utilizar seu disco 
rígido como repositório de dados, furtar dados do seu computador. Só por isso 
vemos o quanto é importante a questão da segurança da informação e como 
devemos trabalhar para implementá-la. Uma das formas de fazê-la também é 
termos um consistente sistema de configuração de software em que qualquer 
mudança seja bem implementada e segura dentro do contexto em que ela foi 
solicitada. 
 
 
 
012 
REFERÊNCIAS 
PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem 
profissional. 8. ed. Porto Alegre: McGraw-Hill, 2016. 
 
__MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(6).pdf
ENGENHARIA DE SOFTWARE/EngSoft(1).pdf
 
 
AULA 1 
 
 
 
 
 
 
 
 
 
ENGENHARIA DE SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Emerson Antonio Klisiewicz 
 
 
 
 
 
02 
CONVERSA INICIAL 
 Nessa aula 1, estudaremos sobre os modelos clássicos de 
desenvolvimento de sistemas e a introdução à Engenharia de Software. 
CONTEXTUALIZANDO 
O que são softwares? 
 “Software”, segundo o Dicionário Michaelis, consiste em “qualquer 
programa ou grupo de programas que instrui o hardware sobre a maneira como 
ele deve executar uma tarefa, inclusive sistemas operacionais, processadores de 
texto e programas de aplicação.” (Software, 2017). 
O que são Sistemas? 
 Observe as frases: 
 O sistema telefônico no Brasil foi implantado em 1877. 
 O sistema de coleta de lixo funciona bem. 
 O sistema de avaliação é rigoroso para os professores. 
 O sistema circulatório de Tadeu está comprometido. 
 O sistema de vendas em seu relatório mostrou uma desaceleração no 
mercado. 
 Considerando as afirmações acima, podemos definir que os sistemas têm 
sempre o seu objetivo, logo, o objetivo declarado de um sistema é, a priori, a razão 
de sua existência. 
 Hoje, qualquer país, seja desenvolvido ou não, depende de softwares. 
Precisamos, portanto, desenvolver sistemas confiáveis, com um desenvolvimento 
que se dê de forma econômica e em um curto espaço de tempo. 
 Aí fica uma pergunta: “Existe uma diferença entre ser um artista e um 
engenheiro”? 
TEMA 1 – SOFTWARES 
 Instruções: quando executadas, produzem a função e o desempenho 
desejados. 
 
 
03 
 Estruturas de dados: possibilitam que os programas manipulem 
adequadamente a informação. 
 Documentos: descrevem a operação e o uso dos programas. 
1.1 Características do Software 
a. Desenvolvido ou projetado por engenharia, não manufaturado no sentido 
clássico. 
b. Não se desgasta, mas se deteriora. 
c. A maioria é feita sob medida. 
1.2 Aplicações do software 
a. Básico: programas escritos para dar apoio a outros programas. 
b. De tempo real: software que monitora, analisa e controla eventos do 
mundo real. 
c. Comercial: sistemas de operações comerciais e tomadas de decisões 
administrativas. 
d. Científico: caracterizado por algoritmos de processamento de números. 
1.3 Evolução do software 
(1950 – 1965) 
 O hardware sofreu contínuas mudanças. 
 O software arte "secundária" para poucos métodos. 
 O hardware era de propósito geral. 
 O software específico para cada aplicação. 
 Sem documentação. 
(1965 – 1975) 
 Multiprogramação e sistemas multiusuários. 
 Sistemas tempo real. 
 Primeira geração de SGBD’s. 
 Bibliotecas de Software. 
 Cresce o número de sistemas baseado em computador. 
 Manutenção quase impossível. 
 
 
 
04 
TEMA 2 – CRISE DE SOFTWARE 
 Conjunto de problemas encontrados no desenvolvimento de software. 
1. As estimativas de prazo e de custo frequentemente são imprecisas. 
2. A produtividade das pessoas da área de software não acompanha a 
demanda por seus serviços. 
3. A qualidade de software, às vezes, não é adequada. 
4. O software existente é muito difícil de manter. 
Diante desse cenário, as seguintes situações acabaram acontecendo: 
 estimativas de prazo e de custo ; 
 produtividade das pessoas ; 
 qualidade de software ; 
 software difícil de manter . 
2.1 Problemas associados à Crise de Software 
2.1.1 Próprio caráter do software 
 Podemos dizer que Software é a parte lógica do computador. Por 
consequência, determinaremos o seu sucesso pela medição da qualidade de 
apenas uma entidade. O software não sofrerá, como algo físico, um desgaste com 
o passar do tempo, mas, certamente, será corroído pelo tempo, necessitando de 
alterações (manutenções). 
2.1.2 Falhas das pessoas responsáveis pelo desenvolvimento do software 
 Gerentes sem conhecimento ou nulas experiências em softwares. 
Profissionais da área que não recebem novos treinamentos ou especializações 
técnicas de desenvolvimento. Também podemos encontrar, dentro das empresas, 
grande resistência na implementação de mudanças. 
2.1.3 Mitos do software 
 Propagaram desinformação e confusão. 
 
 
05 
 Lenda: Em nossa empresa, possuímos um manual com todos os padrões 
para desenvolvimento de um software. Minha equipe terá tudo o que é 
necessário em termos de conhecimento? 
 Verdade: Esse material é usado pela equipe? Todos os profissionais têm 
conhecimento da sua existência? Nele já estão contidas as formas 
modernas de desenvolvimento? O material está completo? 
 Lenda: Minha equipe usa ferramentas de última geração para o 
desenvolvimento dos sistemas. Recentemente, também adquirimos novas 
máquinas para o desenvolvimento. 
 Verdade: É necessário possuir mais que apenas novos computadores para 
produzir software com qualidade. Todo o conhecimento, aqui também, deve 
estar incluso. 
 Lenda: Como nosso projeto de desenvolvimento de software está atrasado,