Você está na página 1de 62

ENGENHARIA E PROJETO DE

SOFTWARE
UNIDADE 3 GERENCIAMENTO DE QUALIDADE DE
SOFTWARE: PADRÕES, NORMAS E MODELOS; MÉTODOS
ÁGEIS; VERIFICAÇÃO, VALIDAÇÃO E TESTES DE
SOFTWARE; GOVERNANÇA DE TECNOLOGIA DA
INFORMAÇÃO
OBJETIVOS:

• Entender os conceitos sobre os principais padrões,


normas e modelos de qualidade de software;
• Entender a importância dos métodos ágeis e suas
principais metodologias de desenvolvimento de
softwares;
• Compreender as áreas de testes software;
• Conhecer a importância da governança de TI nas
organizações. 3
• TÓPICO 1 – GERENCIAMENTO DE QUALIDADE DE SOFTWARE:
PADRÕES, NORMAS E MODELOS

• TÓPICO 2 – MÉTODOS ÁGEIS

• TÓPICO 3 – VERIFICAÇÃO, VALIDAÇÃO E TESTES DE SOFTWARE

• TÓPICO 4 – GOVERNANÇA DE TECNOLOGIA DA INFORMAÇÃO

4
• TÓPICO 1 GERENCIAMENTO DE QUALIDADE DE SOFTWARE:
PADRÕES, NORMAS E MODELOS
O termo Qualidade, está relacionado a uma série de aspectos, algo difícil de ser definido e
ainda mais difícil de ser garantido em qualquer necessidade.

Qualidade é a efetividade dos nossos produtos e serviços em satisfazer os nossos clientes. É


“O que” nós fornecemos ao cliente, julgado certo ou errado somente pelo cliente, baseado
nas suas expectativas e percepções.

O objetivo principal da gerência de qualidade é obter assertividade e produtividade durante a


execução de nossas atividades. Portanto, produtividade pode ser definida com a eficiência
com a qual se prove a qualidade requerida pelos clientes. É o “Como” fornecemos serviços e
produtos de qualidade.

5
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”.

Para entender melhor a abordagem da qualidade implantada há quase 70 anos nas indústrias seguem
algumas das principais características conforme alguns idealizadores da qualidade (VASCONCELOS, 2006):
• Armand Feigenbaum era estudante de doutorado no Massachusetts Institute of Technology nos anos
1950, quando introduziu o conceito de Controle da Qualidade Total que representa um sistema efetivo
que integra a qualidade do desenvolvimento, qualidade de manutenção e esforços de melhoria da
qualidade de vários grupos em uma organização.

• Joseph M. Juran foi um educador chave em gerência da qualidade para os japoneses, que difundiram
sua teoria. Ele fundamentou sua abordagem em três processos básicos: Planejamento da Qualidade,
Controle da Qualidade, Melhoria da Qualidade.

• Philip B. Crosby iniciou seus estudos na década de 1960 e defendeu que a qualidade pode ser vista em
quatro “certezas” do gerenciamento da qualidade: qualidade significa atendimento aos requisitos;
qualidade vem através de prevenção; padrão para desempenho da qualidade e “defeitos zero”; e a
medida de qualidade é o preço da não conformidade. 6
Na fase Plan, o foco está na
identificação do problema, análise
do processo atual e definição do
plano de ação para melhoria do
processo em questão. Na fase Do, o
plano de ação definido deve ser
executado e controlado. Em Check,
verificações devem ser realizadas, a
fim de subsidiar ajustes e se tirar
lições de aprendizagem. Finalmente,
em Action, deve-se atuar
corretivamente para fundamentar
um novo ciclo, garantindo a
melhoria contínua (VASCONCELOS et
al., 2006).
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.

Kan (1995) descreve os seguintes elementos-chave do TQM, conforme demonstrado graficamente na


figura a seguir:
• 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.
Processos incluem tanto processos de negócio quanto
processo de desenvolvimento de produtos;
• 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.
Qualidade de software está relacionada a entregar ao cliente o produto final que
satisfaça suas expectativas, dentro daquilo que foi acordado inicialmente por meio dos
requisitos do projeto. Nesse contexto, qualidade de software que objetiva garantir essa
qualidade pela definição de processos de desenvolvimento (ENGHOLM JR., 2010).

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


qualidade e ao controle de qualidade de software.
• A primeira é para a definição padronizada das atividades voltadas a 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.
• A segunda é voltada para o monitoramento de resultados específicos do projeto, ou
seja, a detecção de defeitos, executadas através do uso de técnicas que incluem
revisões por pares, teste e análise de tendências, entre outras. (VASCONCELOS et al.,
2006).
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. As normas da International Organization for Standardization (ISO, 2015) são padrões
internacionais que “especificam requisitos para um sistema gerencial de qualidade de uma
organização”.

Além dos Padrões e Normas listadas, a área de qualidade possui diversos modelos de qualidade nas empresas
de tecnologia, sobre o CMMI e MPS.BR, os modelos mais difundidos nas indústrias de software no Brasil.
10
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.

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.

11
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.

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

13
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.

14
O MPS.BR é dividido em sete níveis de maturidade, processos e
atributos.

15
TABELA 18 – 7 NÍVEIS DE MATURIDADE, PROCESSOS E ATRIBUTOS

16
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.

17
TABELA 20 – COMPARATIVO ENTRE OS MODELOS CMMI E MPS.BR

18
X

X
19
X

X 20
TÓPICO 2 MÉTODOS ÁGEIS
Os modelos ágeis surgem como uma reação natural à expansão do CMMI no mercado mundial, atingindo não
apenas as grandes organizações, mas também pequenas e médias empresas de TI (BARTIE, 2015).

As Metodologias Ágeis de Desenvolvimento de Software são indicadas como sendo uma opção às abordagens
tradicionais para desenvolver softwares: produzem pouca documentação, é recomendado documentar somente
o que será útil. Em essência, as Metodologias Ágeis foram desenvolvidas com o objetivo de vencer as fraquezas
percebidas e reais da Engenharia de Software (PRESSMAN, 2010).

São recomendadas para projetos que: existem muitas mudanças; os requisitos são passíveis de alterações; a
recodificação do programa não acarreta alto custo; a equipe é pequena; as datas de entrega curtas acarretam
alto custo; o desenvolvimento rápido é fundamental (SOUZA, 2015).

A modelagem ágil é um conjunto de práticas guiado por princípios e valores para profissionais de software
aplicarem no dia a dia e tem como objetivos definir e mostrar como colocar em prática um conjunto de valores,
princípios e práticas relativas a uma modelagem eficaz e leve. Lida com a questão de como aplicar técnicas de
modelagem em projetos de software adotando uma perspectiva ágil. Discute como é possível melhorar as
atividades de modelagem.
21
Segundo Souza (2015), os 12 princípios do Manifesto Ágil são:
1. Garantia da satisfação do consumidor com entrega rápida e contínua de softwares funcionais.
2. Mudanças de requisitos, mesmo no fim do desenvolvimento, ainda são bemvindas.
3. Frequentemente são entregues softwares funcionais (semanas, ao invés de meses).
4. Desenvolvedores e pessoas relacionadas aos negócios devem trabalhar, em conjunto, até o fim
do projeto.
5. Construir projetos com indivíduos motivados, dar-lhes ambiente e suporte necessários e confiar
que farão seu trabalho.
6. Uma conversa face a face é o método mais eficiente e efetivo de transmitir informações para e
dentro de uma equipe de desenvolvimento.
7. Software em funcionamento é a principal medida de progresso.
8. Desenvolvimento sustentável, de modo a manter um ritmo constante indefinidamente.
9. Atenção contínua para com a excelência técnica e para com bons projetos aumenta a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho não efetuado – é essencial.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes autoorganizáveis.
12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficiente.
Entre todos os métodos ágeis podem-se citar como exemplo o Scrum, Extreme Programming, Adaptative Software
Development (ASD), Dynamic System Development Method (DSDM), Crystal Clear, Feature-Driven Development (FDD) entre
outros. 22
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.
23
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.
24
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.
25
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.

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.
26
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.

27
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.

28
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.

29
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.

30
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.

31
X

X X

32
X

33
TÓPICO 3 VERIFICAÇÃO, VALIDAÇÃO E TESTES DE SOFTWARE

Sommerville (2011) destaca que o teste de software serve para evidenciar que o programa faz o que ele
realmente deve fazer e para evidenciar os defeitos que existem antes do uso. No processo de teste existem dois
objetivos distintos que são demonstrar que o software atende seus requisitos e descobrir em que situação o
software se comporta de forma incorreta.

O teste busca descobrir a maior quantidade de defeitos possível, é importante saber onde os defeitos podem
estar. Saber como os defeitos são criados nos dá pistas sobre onde procurá-los durante o teste do sistema
(PFLEEGER, 2004).

A atividade de teste de software possui uma série de limitações, dificuldades e características únicas as quais
necessitam serem tratadas durante a sua execução a fim de garantir o seu sucesso. Com isso, planejar e controlar
essas atividades se torna fundamental para ter um bom resultado. Definir prazos e gerenciar os riscos se torna
imprescindível.

34
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.

35
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.

36
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.

37
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)

38
• 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.

• 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.

39
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.

40
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á”.
41
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.
• 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.
• 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
42
do conhecimento acerca do software e da criação de bons códigos.
43
44
45
46
47
X

X
48
X

X
TÓPICO 4 GOVERNANÇA DE TECNOLOGIA DA INFORMAÇÃO

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.

49
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.

50
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.

51
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.

52
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.

A figura
mostra os
domínios do
COBIT:

53
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.

54
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.

55
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.
56
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:

57
FIGURA 77 – COMPOSIÇÃO DE UMA ATIVIDADE
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)

58
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.

59
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.

60
X

X ITIL
X

61
X

Você também pode gostar