Aulas - Engenharia de Software

AULA 1
ENGENHARIA DE SOFTWARE
Prof. Emerson Antonio Klisiewicz

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.
02
 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.
03
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.
04
 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,
incluiremos novos profissionais na equipe e, com isso, tiraremos o atraso.
 Verdade: Desenvolver um software é diferente de produzir um produto em
um processo industrial. Incluir mais pessoas em um projeto pode torná-lo
mais atrasado ainda. Há que se ter um critério bem definido e planejado
para a inclusão de novos profissionais em uma equipe de projeto.
 Lenda: Ter uma visão superficial dos objetivos para o desenvolvimento de
determinado software é o suficiente para começar a desenvolver os
programas. O detalhamento pode ser feito posteriormente.
 Verdade: Uma pobre definição inicial dos requisitos é a grande vilã e,
talvez, a maior causa de fracassos dos projetos de desenvolvimento de
software. Ter uma descrição formal e detalhada de toda a informação,
funcionalidade, desempenho, interfaces internas e externas, restrições e
validações dos sistemas desenvolvidos são vitais para o sucesso do
projeto.
 Lenda: O nosso usuário, constantemente, sugere mudanças em nosso
projeto. Sem problemas, pois qualquer mudança pode ser facilmente
implementada, porque o nosso projeto é totalmente flexível.
 Verdade: Pequenas alterações, solicitadas quando o projeto já está em
desenvolvimento avançado, podem causar problemas muito maiores do
que uma grande alteração solicitada durante as fases iniciais do
desenvolvimento. Tal feito pode ocasionar consideráveis prejuízos à
qualidade final do produto e do projeto.
05
 Lenda: A partir do momento em que o programa/sistema entrar em
funcionamento, o trabalho de nossa equipe de desenvolvimento estará
encerrado.
 Verdade: É errado pensar dessa forma. Pelas estatísticas das empresas
de desenvolvimento de software, serão usados, após a entrega do
programa aos usuários, de 50% a 70% do tempo e esforço gastos com o
seu desenvolvimento.
 Lenda: Sem ter em mãos o sistema já funcionando, não é possível avaliar
a sua qualidade.
 Verdade: Hoje em dia, ter o programa funcionando é apenas uma parte da
configuração de Software. Além do mais, com novas formas de
desenvolvimento, com as metodologias ágeis, temos sempre a entrega de
artefatos agregando funcionalidades aos programas em que a qualidade é
vital.
TEMA 3 – ENGENHARIA DE SOFTWARE
3.1 Métodos
 Proporcionam os detalhes de como fazer para construir o software.

 Mostram o planejamento e a estimativa de projeto.
 Desenvolvem a análise de requisitos de software e de sistemas.
 Modelam o projeto da estrutura de dados.
 Dizem como codificar algoritmo de processamento.
 Trazem a forma da codificação.
 Informam como deve ser a fase de teste.
 Trará as normas a serem seguidas na manutenção.
3.2 Ferramentas
Suportam de forma automatizada os métodos de desenvolvimento.

Atualmente, existem ferramentas específicas para cada método. Quando
integradas, é possível estabelecer um sistema de suporte ao processo de
desenvolvimento de software, o que chamamos de CASE - Computer Aided
Software Engineering.
3.3 Procedimentos
06
Constituem o elo entre os métodos e as ferramentas. São as sequências
em que os métodos serão aplicados. Informam quais produtos devem ser
entregues. Definem os controles que ajudam assegurar a qualidade e a coordenar
as alterações. Trazem as referências que ajudam a administrar o progresso do
software.
O conjunto das etapas que envolvem métodos, ferramentas e
procedimentos é conhecido como componente de Ciclos de Vida de software.
Para a escolha de um Ciclo de Vida de software, devemos levar em conta
a natureza do projeto e da aplicação, os métodos e as ferramentas a serem
usados e saber quais controles e produtos precisam ser entregues.
TEMA 4 – CICLO DE VIDA CLÁSSICO (CASCATA)
Figura 1 – Ciclo de vida em cascata
4.1 Análise e engenharia de sistemas
Nessa fase, é preciso realizar a coleta dos requisitos ao nível de sistema,

já desenvolvendo uma pequena quantidade do projeto e da análise para a criação
do software/sistema em questão.
Essa fase é de suma importância, principalmente quando o software fizer
interface com hardware, pessoas ou banco de dados.
4.2 Análise de requisitos de software
O processo de levantamento dos requisitos, nessa fase, é reforçado e

concentrado especificamente no que será desenvolvido.
07
Deve-se compreender o funcionamento do software e todo o domínio da
informação, como também saber quais interfaces serão exigidas pelo sistema.
Esses requisitos devem ser documentados, revistos e validados junto aos
usuários/clientes.
4.3 Projeto
É nessa fase que fazemos a transformação dos requisitos do software para

representações avaliadas antes que a codificação propriamente dita comece.
Concentra-se em 4 atributos do programa:
a. Estrutura de dados.
b. Arquitetura de software.
c. Detalhes procedimentais.
d. Caracterização de interfaces.
4.4 Codificação
Trata-se da passagem de todas as representações do projeto de

desenvolvimento para uma linguagem de programação definida pela equipe de
projeto, resultando nas instruções/comandos executáveis pelo computador.
4.5 Testes
Concentram-se, principalmente:
 Nas características lógicas do software, garantindo que todas as

instruções/comandos tenham sido testadas ao menos uma vez.
 Nos quesitos funcionais, os testes visam descobrir erros e garantir que as
entradas definidas em projeto produzam resultados considerados corretos
pelos requisitos dos usuários.
4.6 Manutenção
É certo que o software sofrerá mudanças depois de entregue/implantado

no cliente/usuário.
As prováveis situações que podem provocar mudanças são: erros,
adaptação no software para aceitar determinadas mudanças, alterações de
08
ambiente, solicitações dos usuários para que sejam incluídas alterações
funcionais e de melhora do desempenho.
Podemos citar várias situações-problema na utilização desse modelo,
como:
 Projetos reais raramente seguem o fluxo sequencial que o modelo propõe.

 Logo no início, é difícil estabelecer explicitamente todos os requisitos, pois,
no começo dos projetos sempre existe uma incerteza natural.
 O cliente deve ter paciência.
 Uma versão executável do software só fica disponível numa etapa
avançada do desenvolvimento.
TEMA 5 – CICLO DE VIDA EM ESPIRAL
Figura 2 – Prototipação
Esse processo clássico de desenvolvimento une suas melhores

características com o processo de Prototipação, incluindo um novo item
importantíssimo: a Análise de Risco. Ele segue os passos sistemáticos do Ciclo
de Vida Clássico, incluindo-os em uma organização iterativa que refletirá, de
forma mais próxima, o mundo real. O processo de Prototipação pode ser usado
em qualquer etapa do desenvolvimento, como forma de reduzir os riscos do
desenvolvimento.
5.1 Etapas do Ciclo de Vida em Espiral
 Planejamento: determinará os objetivos, as alternativas e as restrições

quanto ao desenvolvimento do software.
09
 Análise de risco: realizará uma análise de alternativas e identificação /
resolução dos possíveis riscos. Normalmente, há 3 alternativas.
 Construção: codificação dos requisitos, passando-os para a linguagem
computacional propriamente dita.
 Avaliação do cliente: homologação do que foi entregue/implantado pelos
usuários/clientes, para que se efetue o planejamento dos novos passos.
Esta é, atualmente, a abordagem mais realística para o desenvolvimento

de software em grande escala. Capacita o desenvolvedor e o cliente a entenderem
e reagirem aos riscos em cada etapa evolutiva. Pode ser difícil convencer os
clientes que uma abordagem "evolutiva" é controlável. Também exige
considerável experiência na determinação de riscos e depende dessa experiência
para ter sucesso.
FINALIZANDO
O surgimento de sistemas complexos de software 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 desenvolvimento. A
engenharia de software apareceu como o processo ideal para solucionar
problemas definidos pela crise de software. Independentemente de ser uma crise
ou um problema crônico, o fato é que as dificuldades persistem, “sendo o
desenvolvimento de software tarefa árdua que leva muitos desenvolvedores a
derrota”. (Pressman; Maxim, 2002). Essas situações aumentam o interesse de
toda a comunidade de desenvolvedores em buscar metodologias que possam
ajudar, eliminar e minimizar as dificuldades enfrentadas no desenvolvimento dos
projetos.
Deste modo, formalidade, documentação, cumprimento das fases
estabelecidas e produtos definidos, que fazem parte da abordagem tradicional, e
em qualquer projeto de desenvolvimento de aplicações, sempre buscarão a
qualidade final do produto e, consequentemente, a satisfação do cliente.
010
REFERÊNCIAS
PAULA FILHO, W. de P. Engenharia de software: fundamentos, métodos e

padrões. 3 ed. São Paulo: LTC, 2009.
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem

profissional. Trad. João Eduardo Nóbrega Tortello. 8. ed. Porto Alegre, RS:
AMGH, 2016.
SOFTWARE. Michaelis. Dicionário Brasileiro da Língua Portuguesa. Disponível

em: <http://michaelis.uol.com.br/busca?id=EZ5mx>. Acesso em: 13 set. 2017.
011
AULA 2

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.
02
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
03
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
04
Motivação
São os programadores motivados para trabalhar no projeto?
05 Instabilidade no projeto vai sempre levar para as pessoas que 1 none 0 0
saem no meio do caminho através do seu código-fonte. E a mão
sobre torna-se realmente difícil.
Requisitos estáveis
É ao usuário clara sobre o que ele quer? Tenho visto as
06 expectativas dos clientes são o fator mais importante na 2 none 0 0
estabilidade dos requisitos. Se o cliente é de uma natureza
altamente mudar, colocar esse valor máximo.
Part-time trabalhadores
07 Há pessoal em tempo parcial no projeto, como consultores, etc? -1 none 0 0
Difícil linguagem de programação

08 Qual é a complexidade da linguagem, Assembly, VB 6.0, C + + -1 none 0 0
e C ou Framework?
Efactor 0
EF - Enviroment Factor = ( 1,4 + ( -0,03 * Efactor) ) 1,4
É 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
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
06
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:
07
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
08
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.
09
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.
010
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.
011
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
012
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)
013
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
014
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:
015
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
016
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.
017
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.
018
AULA 3

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;
2
 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.
3
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.
4
 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;
5
 cliente: no XP, o cliente deve trabalhar ou estar com equipe de
desenvolvimento.
Para ampliar seus estudos, leia o capítulo 5, item 4.
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.
6
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.
7
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.
8
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;
9
 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.
10
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.
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.
11
REFERÊNCIAS

12
AULA 4

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.
02
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
03
É 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;
04
 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:
05
Figura 2 – Regiões de grafo
Exemplo:
3.2 Teste do caminho básico

06
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:
07
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:
08
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);
09
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á
010
constantemente testado; nesse caso, pelo cliente. E ninguém deseja que ele
encontre algum tipo de erro.
011
REFERÊNCIA
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem

profissional. 8. ed. Porto Alegre: AMGH, 2016.
012
AULA 5

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
02
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.
03
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.
04
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.
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).
05
 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.
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
06
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.
07
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
08
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.
09
Quadro 3 – Normas ISO e características
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.
010
REFERÊNCIAS
PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem

profissional. 8. ed. Porto Alegre: McGraw-Hill, 2016.
011
AULA 6

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.
02
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.
03
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.
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.
04
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.
05
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
06
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.
07
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/>.
Engenharia de Software: uma abordagem profissional. 8. ed. Por Roger
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.
08
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
09
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;
010
 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.
Engenharia de Software: uma abordagem profissional. 8. ed. Por Roger
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.
011
REFERÊNCIAS
PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem

profissional. 8. ed. Porto Alegre: McGraw-Hill, 2016.
012

Aulas - Engenharia de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aulas - Engenharia de Software

Enviado por

Direitos autorais:

Formatos disponíveis

AULA 1

Prof. Emerson Antonio Klisiewicz

Nessa aula 1, estudaremos sobre os modelos clássicos de

O que são softwares?

“Software”, segundo o Dicionário Michaelis, consiste em “qualquer

O que são Sistemas?

 O sistema telefônico no Brasil foi implantado em 1877.

Considerando as afirmações acima, podemos definir que os sistemas têm

 Instruções: quando executadas, produzem a função e o desempenho

1.1 Características do Software

a. Desenvolvido ou projetado por engenharia, não manufaturado no sentido

1.2 Aplicações do software

a. Básico: programas escritos para dar apoio a outros programas.

1.3 Evolução do software

Conjunto de problemas encontrados no desenvolvimento de software.

1. As estimativas de prazo e de custo frequentemente são imprecisas.

Diante desse cenário, as seguintes situações acabaram acontecendo:

 estimativas de prazo e de custo ;

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

2.1.2 Falhas das pessoas responsáveis pelo desenvolvimento do software

Gerentes sem conhecimento ou nulas experiências em softwares.

2.1.3 Mitos do software

Propagaram desinformação e confusão.

TEMA 3 – ENGENHARIA DE SOFTWARE

 Proporcionam os detalhes de como fazer para construir o software.

Suportam de forma automatizada os métodos de desenvolvimento.

TEMA 4 – CICLO DE VIDA CLÁSSICO (CASCATA)

Figura 1 – Ciclo de vida em cascata

4.1 Análise e engenharia de sistemas

Nessa fase, é preciso realizar a coleta dos requisitos ao nível de sistema,

4.2 Análise de requisitos de software

O processo de levantamento dos requisitos, nessa fase, é reforçado e

É nessa fase que fazemos a transformação dos requisitos do software para

Trata-se da passagem de todas as representações do projeto de

 Nas características lógicas do software, garantindo que todas as

É certo que o software sofrerá mudanças depois de entregue/implantado

 Projetos reais raramente seguem o fluxo sequencial que o modelo propõe.

TEMA 5 – CICLO DE VIDA EM ESPIRAL

Esse processo clássico de desenvolvimento une suas melhores

5.1 Etapas do Ciclo de Vida em Espiral

 Planejamento: determinará os objetivos, as alternativas e as restrições

Esta é, atualmente, a abordagem mais realística para o desenvolvimento

O surgimento de sistemas complexos de software resultou na necessidade

PAULA FILHO, W. de P. Engenharia de software: fundamentos, métodos e

PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem

SOFTWARE. Michaelis. Dicionário Brasileiro da Língua Portuguesa. Disponível

Prof. Emerson Antonio Klisiewicz

Nessa segunda aula estudaremos sobre os modelos clássicos de cálculo

As métricas para se fornecer os esforços para a

TEMA 1 – MÉTODO GUSTAV KARNER?

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.

Conta-se cada fluxo principal e cada fluxo alternativo. Fluxos de exceção

2.1.3 Ajuste do UCP

2.1.3.1 Fatores técnicos

Nesse momento, o analista deve responder a 13 perguntas relacionadas a

Quadro 1 – Perguntas técnicas sobre o projeto

Para este fator, o analista deve responder a 8 perguntas relacionadas a

Quadro 2 – Modelo de perguntas

Difícil linguagem de programação