U3 - TÓPICO 1.

GERENCIAMENTO DE QUALIDADE
DE SOFTWARE - PADRÕES, NORMAS
E MODELOS

Prof. Anelice Cajado Aguiar

Nesta videoaula, veremos o TÓPICO 1 da Unidade 3
do livro de estudos da disciplina de Engenharia e
Projeto de Software sobre GERENCIAMENTO DE
QUALIDADE DE SOFTWARE - PADRÕES, NORMAS E
MODELOS.

2
• O objetivo principal da gerência de qualidade é obter assertividade
e produtividade durante a execução de nossas atividades.

• Em desenvolvimento de software, a qualidade deve ser entendida

nos aspectos da correta compreensão dos requisitos do cliente,
quando se desenvolve o projeto com zero defeito, quando se obtêm
aumento de produtividade e redução de custos e, por fim, uma boa
usabilidade do sistema.

http://blogdoscursos.com.br/wp-content/uploads/5-
ti/2013/10/CAPA3.jpg http://www.go2web.com.br/fotos/30072014_113122_qualidade-software.png

3
• Na área de Engenharia de Software, Roger Pressman (2011) define qualidade
como “Conformidade a requisitos funcionais e de desempenho explicitamente
declarados, a padrões de desenvolvimento claramente documentados e a
características implícitas que são esperadas de todo software profissionalmente
desenvolvido”.

https://www.prosystemnet.com.br/wp-content/uploads/2018/02/noticia_113917.jpg

4
TOTAL QUALITY MANAGEMENT (TQM)

O gerenciamento da qualidade de software teve origem no Total Quality

Management (TQM), à medida que as organizações começaram a buscar na sua
cultura aplicar a melhoria de processos, produtos e serviços, a fim de obter maior
eficácia, eficiência e satisfação organizacional.

https://www.6sigma.us/wp-
content/uploads/2017/02/TQM-new-768x576.jpg

5
Os seguintes elementos-chave do TQM podem ser resumidos em:

• Foco no cliente: consiste em analisar os desejos e necessidades, bem como

definir os requisitos do cliente, além de medir e gerenciar a satisfação do cliente.
• Melhoria de processo: o objetivo é reduzir a variação do processo e atingir a
melhoria contínua do processo.
• Aspecto humano: nesse contexto, as áreas-chave incluem liderança, gerência,
compromisso, participação total e outros fatores sociais, psicológicos e humanos.
• Medição e análise: o objetivo é gerenciar a melhoria contínua em todos os
parâmetros de qualidade por um sistema de medição orientado a metas.
FIGURA 54 – ELEMENTOS-CHAVE DO TQM
FONTE: Adaptado de: Kan (1995)

6
 QUALIDADE DE SOFTWARE

• Para produzir um produto de software com qualidade, deve-se ter

processos formais que visem à prevenção e à detecção de
defeitos durante o desenvolvimento.
• A origem do produto se dá pela implementação de um processo
consistente e em constante melhoria contínua.
FIGURA 55 – DESENVOLVIMENTO DE PRODUTO DE SOFTWARE

7
GARANTIA E CONTROLE DA QUALIDADE DE SOFTWARE

Na gestão da qualidade de software, existem diversas atividades voltadas à garantia

da qualidade e ao controle de qualidade de software.

Garantia da Qualidade é para a definição padronizada das atividades voltadas à

prevenção de defeitos e problemas, que podem surgir nos produtos de trabalho.
Área que define padrões, metodologias, técnicas e ferramentas de apoio ao
desenvolvimento, tendo como entrada o plano de qualidade de software e os
resultados de medições de qualidade.

https://www.researchgate.net/profile/Wilma_Araujo/publication/240972026/figure/fig1/AS:46
4585326108677@1487777181916/Figura-1-Relacao-entre-sistema-de-gestao-garantia-e- 8
controle-da-qualidade.png
Controle de qualidade é voltada para o monitoramento de resultados
específicos do projeto, ou seja, a detecção de defeitos, executada pelo
uso de técnicas que incluem revisões por pares, teste e análise de
tendências, entre outras.

https://www.researchgate.net/profile/Wilma_Araujo/publication/24097202
6/figure/fig1/AS:464585326108677@1487777181916/Figura-1-Relacao-
entre-sistema-de-gestao-garantia-e-controle-da-qualidade.png
9
PADRÕES, NORMAS E MODELOS DE QUALIDADE DE
SOFTWARE

• Diversos padrões e normas de qualidade de software vêm sendo

propostos ao longo dos anos. Essas normas têm sido fortemente
adotadas nos processos de software das organizações em todo o
mundo.

https://isomaisfacil.com/wp-
content/uploads/2016/11/Normas.png https://avanziquimica.com.br/wp-
content/uploads/2019/06/Selo-de-
10
qualidade.png
A tabela a seguir apresenta algumas normas ISO aplicadas à
qualidade de software, focadas em produto ou processo de software.

TABELA 15 – NORMAS ISO PARA SUPORTE AO DESENVOLVIMENTO DE SOFTWARE

Fonte: O autor

Mostrar a tabela na hora da gravação

do vídeo para eu explica-la.
11
 MODELOS CMMI E MPS.BR

A seguir, serão apresentados sobre o CMMI e MPS.BR, os modelos mais

difundidos nas indústrias de software no Brasil.

CMMI (CAPABILITY MATURITY MODEL INTEGRATION):

INTEGRAÇÃO DOS MODELOS DE CAPACITAÇÃO E MATURIDADE
DE SISTEMAS

MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO (MPS.BR)

O MPS.BR é um programa, criado em 2003, pela própria Softex, para melhorar a

capacidade de desenvolvimento de software nas empresas brasileiras.

https://microio.pt/wp-
https://www.primecontrol.com.br/wp-content/uploads/2016/08/mps-br-636x375.gif
content/uploads/2017/07/CMMI-L2-566x372.jpg
12
O principal propósito do CMMI é fornecer diretrizes baseadas em
melhores práticas para a melhoria dos processos e habilidades
organizacionais, cobrindo o ciclo de vida de produtos e serviços
completos, nas fases de concepção, desenvolvimento, aquisição,
entrega e manutenção.

https://microio.pt/wp-content/uploads/2017/07/CMMI-L2-566x372.jpg

13
 CMMI

No CMMI, os níveis de maturidade fornecem uma maneira de prever

o desempenho da organização dentro de cada disciplina ou conjunto de
disciplinas.
São estágios evolutivos bem definidos em busca de um processo
maduro. Cada nível estabelece uma parte importante do processo da
empresa. Nos modelos CMMI com representação em estágios que
caracterizam o nível de capacidade do processo, existem cinco níveis
de maturidade designados pelos números de 1 a 5.

O CMMI foi criado e é mantido pelo SEI –

Software Engineering Institute da Universidade
Carnagie Mellon.

14
 TABELA 17 – ÁREAS-CHAVE DE PROCESSOS DE ENGENHARIA DE SOFTWARE QUE
UTILIZAM O MODELO CMMI

15

FONTE: O autor
MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO (MPS.BR)

O MPS.BR tem as seguintes metas:

a) definir e implementar o Modelo de Referência para Melhoria de Processos de

Software;
b) criar cursos em diversos locais do país para capacitar e formar consultores do
modelo;
c) credenciar instituições e centros tecnológicos capacitados a implementar e
avaliar o modelo com foco em grupo de empresas.

https://www.primecontrol.com.br/wp-content/uploads/2016/08/mps-br-636x375.gif

16
O MPS.BR é dividido em sete níveis de maturidade, processos e
atributos.
Mostrar esta figura na hora que estou gravando para eu
poder explica-la.

FIGURA 64 – NÍVEIS MPS.BR

FONTE: Fumsoft. Disponível em: <http://www.fumsoft.org.br/qualidade/modelo_mpsbr>.
Acesso em: 26 set. 2015. 17
 TABELA 18 – 7 NÍVEIS DE MATURIDADE, PROCESSOS E ATRIBUTOS

18
FONTE: Antonioni (2007)
COMPARAÇÃO CMMI
E MPS.BR

Ambos os modelos têm

níveis de maturidade que
definem a capacidade de
as empresas trabalharem
com projetos grandes e
complexos.
O CMMI, por sua vez,
tem os níveis do 1 ao 5 e
o MPS.BR, níveis do G ao
A.

TABELA 19 – CORRELAÇÃO ENTRE OS MODELOS CMMI E MPS.BR CMMI

FONTE: Franciscani (2015) 19
TABELA 20 – COMPARATIVO ENTRE OS MODELOS CMMI E MPS.BR

20
Unidade 3 - TÓPICO 2
MÉTODOS ÁGEIS
Prof. Anelice Cajado Aguiar
Nesta videoaula, discutiremos o TÓPICO 2 da Unidade 3
do livro de estudos da disciplina de Engenharia e Projeto de
Software sobre MÉTODOS ÁGEIS.

23
• A indústria de software, a partir da metade de década de 1990,
observando a burocratização e a demora no desenvolvimento,
inflexibilidade e falta de qualidade no software, repensou e
discutiu a possibilidade de criar uma metodologia que usasse
uma forma ágil de desenvolver, diminuindo os custos e
minimizando erros no software.
• Em 2001, surgiram, pelo manifesto ágil que traz as principais
regras, princípios e práticas das metodologias ágeis.

https://miro.medium.com/max/1313/0*boSsDk34JXd8M0yj.gif
https://encrypted-
tbn0.gstatic.com/images?q=tbn%3AANd9GcQYU3ehXbBgFOuIpyfjuyb2AYJWN2ovh41gH1
Ua6VAsWlhyoJc6

24
O manifesto contém quatro principais valores:

• A capacidade de respostas às mudanças e flexibilidade do software acima de um

plano preestabelecido.

• A colaboração e participação dos clientes acima das negociações e contratos.

• Os indivíduos e suas interações acima das ferramentas e procedimentos.

• O cumprimento dos requisitos e funcionamento do software acima de

documentação complexa.

https://s3.amazonaws.com/blog-geek-midia/wp-
content/uploads/2019/12/20213352/productivity-1995786_1280-
750x410.jpg

25
A equipe que criou o “Manifesto de Desenvolvimento Ágil” de
Software partiu da seguinte premissa, ou seja, se neste trabalho
passaram a valorizar:
• Indivíduos e interações mais que processos e ferramentas.
• Software funcionando mais que documentação abrangente.
• Colaboração com o cliente mais que negociação de contratos.
• Responder à mudança mais que seguir um plano.

https://lh3.googleusercontent.com/proxy/WgSFi5ouuk3ik4bn6roCAC4ue3ypEvYOqXO7bxp7VlkU4X04sHwteSUWx
LygRRoeJNWTpKehRISnqUOL6oFQdGqD5AsVEUoBsLiExdk9PFPu1fh80ElLX6ttE5mZmYfYZzHqzO0DqpeNIOt
3aKns 26
Entre todos os métodos ágeis, podem-se citar como
exemplo:
• Scrum.
• Extreme Programming.
• Adaptative Software Development (ASD-
Desenvolvimento de software adaptativo).
• Dynamic System Development Method (DSDM- Método
de Desenvolvimento de Sistema Dinâmico).
• Crystal Clear.
• Feature-Driven Development (FDD- Desenvolvimento
baseado em recursos), entre outros.

27
 SCRUM

• No Scrum, não se desperdiça tempo criando documentações extensas e

detalhadas. É o método mais utilizado hoje em dia, servindo como base para uma
gerência de sucesso.

• No Scrum, as equipes trabalham com Sprints.

• São realizadas reuniões curtas, nas quais o time verifica as decisões que devem
ser tomadas e os recursos do product backlog que entram nos sprints. Elas
também decidem quem trabalha nos sprints e quanto tempo dura cada tarefa.

https://lh3.googleusercontent.com/52i-JkaY-
jyDeHcUS40B4skNRCLyrefe2zraZ_JRMbEroEe72OZ4S2EAiLASVbQcJJILreg4VDoNR5z0tyNZmEd 28
Cl60mqOHW7gk3dGzdyuRbYQGAMYOx_KX9kmi0EEUlmm4FwLAC
• Um líder de equipe, chamado Scrum Master, conduz a reunião e avalia as
respostas de cada integrante. A reunião Scrum, realizada diariamente, ajuda a
equipe a revelar problemas potenciais o mais cedo possível.

• Outro papel fundamental no Scrum é o Product Owner, ele é o dono do

produto. Fornece o requisito do negócio para a equipe, ajuda a definir a ordem
de execução das atividades, conforme a necessidade do cliente, definindo
também o cronograma para a liberação e fazendo as devidas validações.

https://lh3.googleusercontent.com/52i-JkaY-
jyDeHcUS40B4skNRCLyrefe2zraZ_JRMbEroEe72OZ4S2EAiLASVbQcJJILreg4VDoNR5z0tyNZmEdCl
29
60mqOHW7gk3dGzdyuRbYQGAMYOx_KX9kmi0EEUlmm4FwLAC
• No Scrum, a cada dia, é realizada uma reunião, analisando o que
foi produzido no dia anterior, e o que será produzido no dia atual.
Essa reunião é chamada de Daily Scrum e acontece normalmente
no início da manhã.
• Ao fim de um Sprint, a equipe apresenta os requisitos e
funcionalidades desenvolvidos em uma Sprint Review Meeting.
Após uma retrospectiva, a equipe de desenvolvimento passa para o
planejamento do próximo Sprint. E, assim, segue o ciclo.

https://lh3.googleusercontent.com/52i-JkaY-
jyDeHcUS40B4skNRCLyrefe2zraZ_JRMbEroEe72OZ4S2EAiLASVbQcJJILreg4VDoNR5z0tyNZmEdCl60mqOHW7gk3dGzdyuRbY
30
QGAMYOx_KX9kmi0EEUlmm4FwLAC
 EXTREME PROGRAMMING (XP)

• A XP valoriza o trabalho em equipe, em que todos precisam estar dispostos a

ajudar, quando necessário, sendo sua principal característica a
PROGRAMAÇÃO EM PARES. Baseia-se em cinco princípios fundamentais:
comunicação, simplicidade, feedback, respeito e coragem

Existem características próprias de testes que são:

• Desenvolvimento em test-first: são escritos, primeiramente, os testes, depois os

códigos.
• Desenvolvimento de teste incremental a partir de cenários: os cenários ou
estórias são os requisitos de sistema, e quem os prioriza para serem desenvolvidos é
o usuário.
• Envolvimento dos usuários no desenvolvimento de testes e validação.
• Uso de frameworks de testes automatizados escritos como componentes
executáveis antes que a tarefa seja implementada.
https://miro.medium.com/max/1000/0*Urf_SzeJzTkCP1gM

31
• Com o projeto em mãos, começa a codificação em dupla: dois
desenvolvedores sentam lado a lado e concentram-se no código − além de
uma técnica de escrever código, ainda precisa de um aprendizado social e
isso leva um tempo para ser aperfeiçoado; o desenvolvedor sempre precisa
ter em mente que a refatoração do código precisa ser constante, quando algo
não é mais usado, deve ser removido e, quando parte do código é antiga, ela
deve ser renovada.

https://miro.medium.com/max/1000/0*Urf_SzeJzTkCP1gM

32
ADAPTATIVE SOFTWARE DEVELOPMENT (ASD) - Desenvolvimento
Adaptativo de Software
• Foi criado para auxiliar no desenvolvimento de sistemas e softwares
grandes e complexos. Concentra-se na colaboração humana e na auto-
organização da equipe, com o cliente sempre presente, sendo que o
software será iterativo e incremental.

É caracterizado por seis principais propriedades:

• Orientado a missões.
• Baseado em componentes.
• Iterativo.
• Prazos prefixados.
• Tolerância a mudanças.

https://0901.static.prezi.com/preview/v2/mmkjrmkbpb2isgaxe3xujp767p6jc3sachvcdoaizecfr3d
nitcq_3_0.png

33
O ASD é incorporada por três fases:
• Especulação:
• Declara a missão do projeto.
• Identifica as restrições do projeto.
• Realiza o levantamento dos requisitos básicos.
• Colaboração:
• Filosofia de que pessoas motivadas trabalhando juntas
multiplicam seus talentos e resultados.
• Aprendizado:
• Clientes/usuários informam feedback.
• Revisão dos componentes de software desenvolvidos.
• Avaliação do desempenho da equipe.

34
 DYNAMIC SYSTEM DEVELOPMENT
METHOD (DSDM)
A metodologia de desenvolvimento de Sistemas Dinâmicos
É uma metodologia incremental que enfatiza principalmente a participação do
usuário final.

Possui cinco fases definidas em três ciclos iterativos: pré-projeto, ciclo de vida e
pós-projeto.

https://newline.tech/wp-content/uploads/2018/03/Illustration_for_nlt_blog_dsdm.jpg

https://image2.slideserve.com/4048989/ciclo-de-vida-l.jpg

35
 CRYSTAL CLEAR
• Tem foco na gestão de pessoas, possibilitando a adaptação a diversos
projetos, focando nas habilidades e talentos de cada pessoa envolvida.
• Apresenta valores comuns a outras metodologias ágeis, como a
comunicação eficaz, a entrega frequente, papéis predefinidos e equipes com
especialistas.
• Está voltada para equipes de dois a oito membros que estejam na mesma
sala. Ela não é feita para empresas padronizadas, pois sua metodologia não é
completamente especificada, muda de acordo com os pontos fortes e fracos
da organização.

https://0701.static.prezi.com/preview/v2/ughvfb3teiiu2pfour7pmwewmh6jc3sachvcdoaizecfr
3dnitcq_3_0.png
36
 FEATURE-DRIVEN DEVELOPMENT (FDD) –
Desenvolvimento Guiado por Funcionalidade

• Quando aplicado o FDD, a equipe precisa estar preparada para trabalhar com
funcionalidades como o objeto primário. O primeiro passo é criar um modelo
abrangente, o qual irá identificar os fundamentos do projeto, que consequentemente
sofrerá alterações no decorrer do andamento.
• Com o modelo base pronto, precisa-se construir uma lista de funcionalidades a
serem desenvolvidas, coordenadas pelo arquiteto e identificar os recursos que o
Software deve ter. Os próximos passos no FDD são conhecidos como “Design by
feature” e “Build by feature”, e estão relacionados com a maior parte do projeto,
envolvendo designer, desenvolvedor, testadores e qualquer outro membro necessário
para a conclusão do projeto.

37
 U3 - TÓPICO 3
VERIFICAÇÃO, VALIDAÇÃO E
TESTES DE SOFTWARE
PROFESSORA: ANELICE CAJADO AGUIAR
Nesta videoaula, veremos o TÓPICO 3 da Unidade 3 do
livro de estudos da disciplina de Engenharia e Projeto de
Software sobre VERIFICAÇÃO, VALIDAÇÃO E
TESTES DE SOFTWARE.

40
 • O principal objetivo do teste de software é auxiliar na busca de
um produto de software com o mínimo de erros possível.

• No processo de teste, existem dois objetivos distintos:

demonstrar que o software atende seus requisitos e descobrir em
que situação o software se comporta de forma incorreta, ou seja,
evidenciar os defeitos que existem antes do uso.

A extração de requisitos é o processo

de transformar o conhecimento tácito,
que está na mente dos usuários, em
conhecimento explícito via
documentação formal. A saída do
processo de extração de requisitos é
um documento de especificação do
sistema que deve dizer o que o
https://assets.xtechcommerce.com/uploads/images/full/771ffde67b9201615fb6c67ca802de7f.jpg produto a ser desenvolvido deverá
fazer, e não como deve ser feito.

41
 Requisitos não funcionais
A norma ISO/IEC 9126 (2015) caracteriza os requisitos não funcionais referentes
à qualidade dos produtos usando os seguintes conjuntos:
• Funcionalidade: Adequação; Acurácia; Interoperabilidade; Segurança de acesso.
• Confiabilidade: Maturidade; Tolerância a falhas; Recuperabilidade.
• Usabilidade: Inteligibilidade; Operacionalidade; Atratividade.
• Eficiência: Comportamento em relação ao tempo; Comportamento em relação
aos recursos.
• Manutenibilidade: Analisabilidade; Modificabilidade; Estabilidade;
Testabilidade.
• Portabilidade: Adaptabilidade; Capacidade para ser instalado; Coexistência;
Capacidade de ser substituído.

42
 A utilização de técnicas de levantamento de requisitos é recomendada por diversos autores de
engenharia de requisitos e personalidades da área Engenharia de Software. Algumas das principais
técnicas serão apresentadas a seguir, de forma resumida:

• Brainstorming: consiste em uma “tempestade de ideias”, sem julgamentos ou análises, que

ocorre em um ambiente descontraído e informal. É ideal para buscar ideias de novos
produtos.
• JAD: técnica utilizada para promover cooperação, entendimento e trabalho em grupo entre
usuários e desenvolvedores.
• Análise de documentos quantitativos: consiste na análise de documentos, como
formulários e relatórios.
• Reunião: é utilizada para licitação de requisitos em grupo, com o objetivo de promover o
intercâmbio de ideias, sugestões e opiniões entre os participantes, visando à aceitação de um
ponto de vista.
• Prototipagem: utilizado para atrair aspectos críticos quando se tem domínio mínimo da
aplicação.
• Entrevista: conversa com o usuário para extrair tópicos importantes.
• Questionários: extrair respostas através de questões subjetivas e objetivas.

43
• Observação: observar o comportamento e o ambiente do indivíduo que toma
decisões pode ser uma forma bastante eficaz de levantar informações que,
tipicamente, passam despercebidas usando outras técnicas.
• Levantamento Orientado a Ponto de Vista: tem como objetivo captar pontos
de vista dos usuários, analisar as diferenças e similaridades, formando, assim, o
requisito do sistema.
• Etnografia: forma utilizada para entender a organização, sua cultura e o
objetivo que o sistema deve alcançar.
• Caso de Uso: especifica um comportamento externo de um sistema descrevendo
um conjunto de sequências de ações realizadas pelo sistema para produzir um
resultado de valor observável por um ator, realizado através de uma interação
típica entre um ator (usuário, outro sistema computacional ou um dispositivo) e
um sistema.

44
45
 Etapas de teste de Software: VALIDAÇÃO X VERIFICAÇÃO

• A validação checa se o software tem todos os itens necessários para atender o

cliente. O sistema que será entregue ao cliente deve ajudá-lo, para que ele fique
contente. A pergunta da validação é “Fizemos o software correto?”.

• A verificação buscar e prever erros entre os requisitos. Verificar se todas as

etapas de desenvolvimento foram realizadas, e da melhor forma, conforme
planejado. A pergunta de Verificação é “Fizemos o software corretamente?”.

• Verifica-se se as tecnologias para o desenvolvimento, como banco de dados, a

linguagem, as interfaces etc., foram utilizadas de forma correta.

https://encrypted-
tbn0.gstatic.com/images?q=tbn%3AANd9GcQTto3ZCfgaRusEx
VdySNI7m_Rfd60UTU2p7mqMJrpycW-I3GV5
46
• Realizar os testes nada mais é que entrar com vários dados de maneira diferente
e analisar os dados de saída e seu comportamento.

• Muitas organizações deixam para montar e realizar os testes apenas quando o

produto final estiver pronto. Contudo, essa etapa leva bastante tempo e,
dependendo do resultado, a correção pode trazer mais transtornos para a equipe
de desenvolvimento.

https://arquivo.devmedia.com.br/marketing/img/guia
-testes-de-software-34403.png 47
• De acordo com um estudo do Standish Group, no ano de 2014, cinco dos oito
principais fatores de falhas em projetos estão relacionados a requisitos (Tabela
1). Estes são: requisitos incompletos, baixo envolvimento do cliente,
expectativas não realistas, mudanças nos requisitos e requisitos desnecessários.

https://arquivo.devmedia.com.br/marketing/img/guia
-testes-de-software-34403.png 48
• Carvalho e Chiossi (2001) apontam algumas dificuldades no
processo de obtenção de requisitos:

• Falta de conhecimento do usuário das suas reais necessidades e

do que o produto de software pode lhe oferecer;
• Falta de conhecimento do desenvolvedor do domínio do
problema;
• Comunicação inadequada entre desenvolvedores e usuários;
• Dificuldade do usuário em tomar decisões;
problemas de comportamento;

49
• Embora seja óbvio, é importante que se chame a atenção para o fato de que os
requisitos são a base sobre a qual serão apoiadas todas as demais atividades do
processo de software.
• Se os requisitos não forem devidamente especificados, o sucesso do projeto poderá
estar comprometido desde seu início.

• Simpoi publicou em 2008 que 70% dos problemas encontrados em softwares são
de especificação, ou da falta dela, sendo que apenas 60% das informações formais
e informais estão documentadas.

• Uma das principais razões para isso encontra-se no perfil dos desenvolvedores, de
modo geral, definido por pessoas talentosas, que não têm interesse em seguir
disciplinas ou normas, consideram seu trabalho como algo artístico e criativo, ao
invés de algo sujeito a procedimentos de engenharia de requisitos.

50
Na área de testes, existem diversos tipos que são aplicados em estágios diferentes.

• Teste Caixa Preta: visa a verificar a funcionalidade e a aderência aos requisitos,

em uma ótica externa ou do usuário, sem se basear em qualquer conhecimento do
código e da lógica interna do componente testado.

• Teste Caixa Branca: visa a avaliar as cláusulas de código, a lógica interna do

componente codificado, as configurações e outros elementos técnicos.

https://image.slidesharecdn.com/testesdesoftware-131109134520-phpapp01/95/testes-
de-software-15-638.jpg?cb=1384004808
51
Para cada um desses fatores, ou dimensões de qualidade, como
denomina o referido processo, existe um ou mais tipos de teste
associado:

52
Os testes de software são executados em diferentes níveis (ou
estágios) do desenvolvimento de um software.

FIGURA 68 – OS QUATRO PRINCIPAIS NÍVEIS TÍPICOS DE TESTE DE SOFTWARE

FONTE: Adaptado de: Craig (2002)

53
• Teste de Unidade: é realizado em cada componente do programa isoladamente,
para verificar se ele funciona de forma adequada aos tipos de entradas esperadas.
Normalmente, é realizado em um ambiente controlado, verificando as estruturas de
dados internas, a lógica e as condições limite para os dados de entrada e saída.

• Teste de Integração: tem o objetivo de provocar falhas associadas às interfaces

entre os módulos, quando eles são integrados para construir a estrutura do software.
FIGURA 68 – OS QUATRO PRINCIPAIS NÍVEIS TÍPICOS DE TESTE DE SOFTWARE
FONTE: Adaptado de: Craig (2002)

54
• Teste de Sistema: avalia o software em busca de falhas utilizando o mesmo como
se fosse um usuário final. É neste estágio que são realizados os testes de carga,
performance, usabilidade, compatibilidade, segurança e recuperação.

• Teste de Aceitação: é realizado em conjunto com os clientes, quando o sistema é

verificado em comparação com a descrição dos requisitos do cliente.

FIGURA 68 – OS QUATRO PRINCIPAIS NÍVEIS TÍPICOS DE TESTE DE SOFTWARE

FONTE: Adaptado de: Craig (2002)

55
 EQUIPE DE TESTE

• É importante ter uma equipe treinada para utilizar o teste de software.

• Os membros não podem ser apenas programadores, deve também haver
membros que entendam as regras de negócio, onde o software vai trabalhar, ou
seja, funcionários que tenham a mesma lógica do usuário final. Dessa forma,
fica mais fácil identificar os erros do sistema.

https://image.slidesharecdn.com/testedesoftwareenvio-141101095011-conversion-gate02/95/teste-de- 56
software-palestra-corporativa-28-638.jpg?cb=1414835550
 ERROS DE SOFTWARE

Nem todas as falhas são consideradas realmente bug, pois pode ser
um caso de má utilização do software por parte do usuário. Para que
um bug ocorra, de acordo com Molinari (2003), basta que uma ou
mais das quatro regras da indústria de software, apresentadas a
seguir, ocorram simultaneamente:
• Software não faz algo que a especificação do produto diz que faz.
• Software faz algo que na especificação diz que não é para fazer.
• Software faz algo que a especificação do produto não menciona.
• Software é difícil de entender, difícil de usar, lento ou,
simplesmente aos olhos do testador, “o usuário não gostará”.

https://thumbs.dreamstime.com/z/colaborador-do-erro-de-software-da-
aplica%C3%A7%C3%A3o-inform%C3%A1tica-do-problema-67902794.jpg
57
 PRÁTICAS DE DESENVOLVIMENTO
As práticas de desenvolvimento na área de testes são:

• TDD – Test Driven Development: o Desenvolvimento Guiado a Testes:

escrevem-se, primeiramente, os testes para, posteriormente, escrever o código.
(1) Escrever um teste, mesmo sem ter escrito o código real a ser testado; (2)
executar os testes e acompanhar a falha; (3) escrever a funcionalidade do
sistema que irá ser testada; (4) testar novamente, agora para passar; (5) refatorar
a funcionalidade e escrever por completo; (6) próxima estória ou caso de uso e
iniciar novo teste.

https://i0.wp.com/blog.sciensa.com/wp-content/uploads/2017/08/tdd_flow.gif?fit=489%2C511
58
• DDD – DOMAIN DRIVEN DESIGN: no desenvolvimento guiado ao
domínio, o foco é no propósito que o software deve atender, é a automatização
de um processo de negócio. O DDD traz abordagens de como fazer isso, como
atender a um domínio complexo de informações.

• BDD – Behavior Driven Development: o desenvolvimento guiado por

comportamento associa os benefícios de uma documentação formal, escrita e
mantida pelo negócio, com testes de unidade que demonstram que essa
documentação é efetivamente válida.
https://mk0mitraissited2cion.kinstacdn.com/wp-content/uploads/2018/03/Domain-Driven-
Design_cover.jpg

https://miro.medium.com/max/540/0*ryNBF8_dnh7Eihkz

59
• ATDD - Acceptance Test Driven Development: o
desenvolvimento guiado por testes de aceitação; o trabalho ocorre
em resposta a testes de aprovação.

• FDD - Feature Driven Development: desenvolvimento guiado

por funcionalidades serve para gerenciar e desenvolver projetos de
software por meio de um conjunto de atividades simplificadas, de
maneira a estimular o compartilhamento do conhecimento acerca
do software e da criação de bons códigos.

https://computerworld.com.br/wp-content/uploads/2018/06/software_5_0.jpg
60
 U3 - TÓPICO 4
GOVERNANÇA DE
TECNOLOGIA DA
INFORMAÇÃO
Prof. ANELICE
Nesta videoaula, falaremos sobre o TÓPICO 4 da Unidade
3 do livro de estudos da disciplina de Engenharia e Projeto
de Software sobre GOVERNANÇA DE TECNOLOGIA
DA INFORMAÇÃO.

63
Governança de TI é um conjunto de práticas, padrões e relacionamentos
estruturados, assumidos por executivos, gestores, técnicos e usuários de TIC de
uma organização, com a finalidade de garantir controles efetivos, ampliar os
processos de segurança, minimizar os riscos, ampliar o desempenho, otimizar a
aplicação de recursos, reduzir os custos, suportar as melhores decisões e
consequentemente alinhar TI aos negócios.

Auxilia os profissionais de TI – CIO a avaliar os rumos a serem tomados para o

alcance dos objetivos de sua organização, ajudando em planejamento, implantação,
controle e monitoramento de programas e projetos de governança sob os aspectos
operacionais e suas implicações legais.

64
• Um dos grandes desafios da Governança de TI, além de manter o alinhamento aos propósitos da
organização, é manter sincronizados os elementos componentes da própria TI, cuja
administração deve prezar pela melhor forma de utilizá-los e também estabelecer a garantia da
continuidade dos negócios da empresa.

• Dois modelos muito bem conhecidos pela área de Governança de TI são o COBIT (Control
Objectives for Information and Related Technology) e o ITIL (Information Technology
Infrastructure Library).

• O ITIL é responsável por fornecer as diretrizes para a implementação de uma infraestrutura

otimizada de TI. Já o COBIT é uma documentação para a gestão de TI suprida pelo ISACF
(Informations Systems Audit and Control Foundation), que visa a fornecer informações para
gerenciar os processos baseados em seus negócios.

65
• O COBIT é um framework voltado à governança de TI e se baseia
em indicadores de performance, podendo monitorar quanto a TI
está agregando em valores aos negócios da organização.

• A metodologia COBIT consiste em objetivos de negócio ligados a

objetivos de TI, provendo métricas e modelos de maturidade para
medir sua eficácia, e identificando as responsabilidades
relacionadas dos donos dos processos de negócios e de TI.

66
Então o CobiT:

• Estabelece relacionamentos com os requisitos do negócio.

• Organiza as atividades de TI em um modelo de processos

genérico.

• Identifica os principais recursos de TI, nos quais deve haver

mais investimento.

• Define os objetivos de controle que devem ser considerados

para a gestão.

67
 O modelo foi iniciado e estruturado em 34 processos que estão
inter-relacionados, atendendo quatro domínios e estão divididos
em: planejar e organizar; adquirir e implementar; entregar e dar
suporte; e monitorar e avaliar.
FIGURA 71 – FRAMEWORK DO COBIT
FONTE: Framework do COBIT. Disponível em: <http://www.teclogica.com.br/blog/wpcontent/
uploads/2012/10/governan%C3%A7a_ti_framework_cobit.png>. Acesso
em: 29 set. 2015.

A figura
mostra os
domínios do
COBIT:

68
• O COBIT está organizado em quatro domínios que podem ser
caracterizados pelos seus processos e pelas atividades executadas
em cada fase de implantação da Governança Tecnológica.
• Os domínios do COBIT são: (1) Planejamento e Organização, (2)
Aquisição e Implementação, (3) PDI (Plano Diretor de
Informática) e (4) Entrega e Suporte.

https://image.slidesharecdn.com/mod3introduoaocobit-110225154053-
phpapp02/95/curso-completo-cobit-41-78-638.jpg?cb=1428011186
69
• A ITIL fornece orientação para todos os tipos de provedores de serviço de
TI. É nada mais que um guia de boas práticas desenvolvido para auxiliar as
organizações que pretendem desenvolver melhorias em seus processos,
garantindo, ao provedor de serviços, entender os serviços que estão sendo
fornecidos, facilitando o alcance dos resultados que seus clientes querem
alcançar, visando aos custos e riscos.

• Cabe ressaltar que a ITIL oferece recomendações de como planejar, gerenciar,

controlar e melhorar os serviços de TI necessários para a diferenciação da
empresa em relação ao mercado externo.

70
A biblioteca ITIL foi criada na década na 1990, com base na qualidade dos serviços
de TI oferecidos pelo governo britânico, para habilitar o incremento da maturidade
do processo de gerenciamento de TI. Seu ciclo de vida do serviço compreende um
processo composto por: Estratégia, Desenho, Transição, Operação e Melhoria
Continuada.

71
• Cada processo envolve uma entrada e saída e, a partir da entrada
da informação, as atividades são desenvolvidas, gerando a
consequente saída.

• O modelo, a seguir, mostra como funciona uma atividade que se

compõe dentro de um processo:

72
Em ITIL, um serviço é um meio de entregar valor ao cliente,
facilitando os resultados que o cliente deseja alcançar, sem ter que
assumir custos e riscos. O serviço de TI se caracteriza por ser
fornecido por um provedor de serviços de TI, composto pela
combinação de Tecnologia, Pessoas e Processos.

FIGURA 74 – REPRESENTAÇÃO DE COMBINAÇÃO TECNOLÓGICA PROPOSTA PELA ITIL

FONTE: Adaptado de: Pinheiro (2011)

73
A ITIL descreve três tipos de provedores:

• Provedores de serviços internos – está localizado dentro de cada

unidade de negócio, podendo ser várias dentro da organização. Refere-
se às empresas com filiais; nesse modo, cada filial terá um núcleo de
TI dentro de cada unidade.
• Provedores de serviços compartilhados – fornece os serviços de TI
para várias unidades de negócio.
• Provedores de serviços externos – fornece serviços de TI para
clientes externos.

74
MATRIZ RACI (RESPONSIBLE, ACCOUNTABLE, CONSULTED, INFORMED)

A ITIL indica uma ferramenta para ajudar no controle de qualidade na

execução de cada projeto, conhecida em português como matriz RACI
(Responsável, Prestador de contas, Consultado, Informado). A matriz
estabelece quatro atribuições em relação a processos e atividades:
• R - Responsável: é o responsável por executar a atividade do
processo.
• P - Prestador de contas: é aquele que assume as responsabilidades
pelo resultado final do processo.
• C - Consultado: é a pessoa que fornece informações ao longo do ciclo
de vida do processo.
• I - Informado: é a pessoa que fica atualizada de todo o andamento do
processo.
75