Escolar Documentos
Profissional Documentos
Cultura Documentos
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:
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.
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.
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
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)
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
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.
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
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.
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
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
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.
36
Na área de testes, existem diversos tipos que são aplicados em
estágios diferentes.
37
Os testes de software são executados em diferentes níveis (ou
estágios) do desenvolvimento de um software.
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.
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
• 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
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).
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.
51
Então o CobiT:
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.
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.
58
A ITIL descreve três tipos de provedores:
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