Resumo+Prova-QualidadeDeSoftware

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

PROVA QUALIDADEDESOFTWARE.doc
		1a Questão (Ref.: 201301781086)
		Pontos: 0,0  / 0,5
		Podemos entender qualidade de software, como:
(i) Uso de métricas para desenvolver estratégias para a melhoria de processo de software;
(ii) Conjunto de atividades que garante que cada produto de trabalho da engenharia de software exiba adequada qualidade;
(iii) Atividades de segurança em cada projeto de software;
(iv) Conformidade de requisitos funcionais a padrões de desenvolvimento.
		
		
		apenas i e iv são incorretos.
		 
		apenas i; ii e iv são corretos.
		 
		apenas i e iv são corretos.
		
		apenas i e iii são corretos.
		
		apenas i; ii e iii são corretos.
		
		�
		 ��2a Questão (Ref.: 201301790270)
		Pontos: 0,5  / 0,5
		Assinale a alternativa CORRETA para a lacuna do texto a seguir: ____________________ é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos.
		
		
		Desenvolvimento de software
		 
		Qualidade de Software
		
		Documentação de software
		
		Manutenção de software
		
		Análise de software
		
		�
		 ��3a Questão (Ref.: 201301819859)
		Pontos: 0,5  / 0,5
		McCall agrupou fatores que afetam a qualidade do software em categorias. Uma dessas categorias é a Revisão, que, segundo ele, agrupa três fatores a saber: Manutenibilidade; Flexibilidade; Testabilidade.
Os conceitos desses fatores, na sequência, são:
I. Esforço para se modificar um programa operacional;
II. Tempo necessário para se testar um programa, a fim de garantir que ele execute a função pretendida;
III. Capacidade de reparação de erros no programa de forma a torná-lo disponível para uso;
IV. Controle de acesso ao software ou a dados de forma controlada.
		
		 
		III, I, II.
		
		III, II, IV.
		
		II , III, IV.
		
		I, II, III.
		
		III, IV, II.
		
		�
		 ��4a Questão (Ref.: 201301820118)
		Pontos: 0,5  / 0,5
		O fator de qualidade Portabilidade significa:
		
		
		Esforço exigido para se acoplar um sistema a outro.
		
		Controle de acesso ao software ou a dados de forma controlada.
		
		O quanto um programa executa a função pretendida com a precisão exigida.
		 
		Demanda de esforço para transferir um programa de um ambiente de hardware e/ou software para outro.
		
		O quanto um programa é capaz de trocar informações entre instâncias.
		
		�
		 ��5a Questão (Ref.: 201302005811)
		Pontos: 1,0  / 1,0
		Pressman (2004), destaca alguns passos necessários para realizar a SQA estatística e criar um processo adaptativo de engenharia de software no qual são feitas modificações para aprimorar os elementos do processo que promovem erro. Marque a opção que possui todos os elementos deste processo:
		
		
		Coletar e categorizar os defeitos de software encontrados; Rastrear o defeito até sua causa subjacente; Corrigir os problemas que causaram os defeitos.
		
		Rastrear o defeito até sua causa subjacente; Considerar que 20% do código têm 80% dos defeitos; Corrigir os problemas que causaram os defeitos.
		 
		Coletar e categorizar os defeitos de software encontrados; Rastrear o defeito até sua causa subjacente; Considerar que 20% do código têm 80% dos defeitos; Corrigir os problemas que causaram os defeitos.
		
		Coletar e categorizar os defeitos de software encontrados; Rastrear o defeito até sua causa subjacente; Considerar que 20% do código têm 80% dos defeitos.
		
		Coletar e categorizar os defeitos de software encontrados;Considerar que 20% do código têm 80% dos defeitos; Corrigir os problemas que causaram os defeitos.
		
		�
		 ��6a Questão (Ref.: 201301917999)
		Pontos: 1,0  / 1,0
		A Garantia Estatística da Qualidade (Software Quality Assurance - SQA) está baseada no que se denomina "poucas causas vitais" dos problemas. Assinale a opção que explica corretamente esse conceito.
		
		 
		São as poucas causas que são responsáveis pela maioria dos problemas.
		
		São as poucas causas que são responsáveis por todo os problemas.
		
		São as poucas causas irrelevantes.
		
		São as muitas causas que são responsáveis pela maioria dos problemas.
		
		São as poucas causas mais importante
		
		�
		 ��7a Questão (Ref.: 201301820266)
		Pontos: 1,0  / 1,0
		A qualidade do produto de software pode ser avaliada pela medição dos ................... ou pela medição dos .................., ou pela medição dos...............................
Escolha a resposta na qual as opções completam corretamenta as lacunas.
		
		
		atributos internos, fatores, atributos de qualidade em uso.
		
		critério, atributos externos, atributos de qualidade em uso.
		
		critérios, atributos externos, fatores.
		
		testes, critérios e fatores.
		 
		atributos internos, atributos externos, atributos de qualidade em uso.
		
		�
		 ��8a Questão (Ref.: 201301820268)
		Pontos: 0,0  / 1,0
		Marque a opção que melhor completa a afirmativa:
¿... na visão do usuário do software é percebida as necessidades de qualidade em uso do produto de software no contexto especificado para uso. Essas necessidades identificadas, por sua vez, podem ser usadas quando se especifica.....¿
		
		
		os testes a serem realizados para manter o padrão determinado.
		
		qualidade do projeto e interna.
		 
		qualidade externa e interna.
		
		qualidade externa e do produto.
		 
		qualidade de projeto e produto.
		
		�
		 ��9a Questão (Ref.: 201301790692)
		Pontos: 0,0  / 1,0
		Pela ISO/IEC 9241-11 a usabilidade dos computadores depende do contexto de uso e  afirma que o nível de usabilidade alcançado dependerá das circunstâncias específicas nas quais o produto é usado. Osrecursos gastos em relação à acurácia e abrangência com as quais usuários atingem objetivos são definidos como:
		
		
		eficácia
		
		satisfação
		 
		eficiência
		
		durabilidade
		 
		usabilidade
		
		�
		 ��10a Questão (Ref.: 201301790684)
		Pontos: 0,0  / 1,0
		Pela ISO/IEC 9241-11 a usabilidade dos computadores depende do contexto de uso e  afirma que o nível de usabilidade alcançado dependerá das circunstâncias específicas nas quais o produto é usado. Acompletude com as quais usuários alcançam objetivos específicos é definida por:
		
		
		usabilidade
		 
		satisfação
		 
		eficácia
		
		eficiência
		
		durabilidade
QDS - Diretrizes de revis�o.doc
Diretrizes de revisão: estabelecidas antecipadamente e distribuídas aos revisores 
para a concordância de todos e, assim, ser encaminhada mantendo a 
organização no processo de revisão técnica formal. 
 
Requer um conjunto de diretrizes necessárias para a perfeita realização do 
processo: 
 
• Revisar o produto, não o produtor - responsabilidade do líder de 
revisão conduzir o encontro a fim de garantir que o tom e a atitude 
comportamental dos participantes sejam mantidos de forma cordial e 
respeitosa, mas, em situação
oposta, deve interromper imediatamente 
uma revisão, caso tenha saído do controle. 
• Fixe e mantenha uma agenda – a orientação para o líder de revisão é 
evitar a divagação, o desvio no cumprimento do cronograma previamente 
definido para a reunião; caso isso aconteça, o líder de revisão é o 
responsável pela chamada de atenção dos participantes. 
• Limite ao debate e a refutação – questões levantadas que não 
obtenham concordância geral devem ser registradas para posterior 
discussão offline, ou seja, em outro momento à parte da reunião. 
• Foco nas áreas problemáticas – nem todos os problemas serão 
resolvidos em uma única sessão e, por isso, é interessante enunciar 
somente as áreas problemáticas, mas não tentar resolver cada problema 
anotado. A resolução de problemas deve ser transferida para depois do 
encontro da revisão. 
• Registre as anotações por escrito – a intenção é compartilhar a 
redação das anotações entre todos a fim de se avaliarem e se 
determinarem prioridades em conjunto. 
• Reduzir número de participantes – o líder de revisão deve manter o 
número de pessoas envolvidas ao mínimo necessário e solicitar a 
preparação antecipada de todos. 
• Definir uma lista de conferência (checklist) para cada produto 
revisado – uma lista de conferência ajuda o líder da revisão a estruturar 
o encontro de FTR e ajuda cada revisor a se concentrar em questões mais 
importantes. 
• Atribuir recursos e uma programação de tempo para as FTRs - a 
efetividade das revisões requer a programação de tempo para as 
modificações que serão realizadas durante o processo de desenvolvimento 
de software e os resultados findos da FTR. 
• Realizar treinamento para os revisores – capacitar formalmente os 
revisores para melhor desempenho tanto em processos como em relações 
humanas. 
• Rever antigas revisões – as diretrizes da revisão devem ser revistas a 
fim de desvendar problemas gerados pelo próprio processo de revisão. 
QUALIDADE DE SOFTWARE PARTE 2.doc
Aula 6 : ISO/IEC 14598 AVALIAÇÃO DE PRODUTO
A norma ISO/IEC 14598 oferece uma visão geral dos processos de avaliação de produtos de software e fornece guias para a avaliação, baseados na utilização prática da norma ISO/IEC 9126.
Pela Norma, podem existir três enfoques diferentes para a avaliação da qualidade de produto:
- Processo para Desenvolvedores
- Processo para Avaliadores
- Processo para Compradores
Partes da Norma:
ISO/IEC 14598-1 – Visão geral – fornece uma visão completa das outras partes da norma, as relações entre si e com o modelo de qualidade da norma ISO/IEC 9126. 
 ISO/IEC 14598-2 – Planejamento e gestão - fornece requisitos, recomendações e diretrizes para uma função de suporte e apoio responsável pela gestão da avaliação de produto de software e pelas tecnologias necessárias para a avaliação de produto de software. 
 ISO/IEC 14598-3 – Processo para desenvolvedores – Seleção e registro de indicadores que possam ser medidos e avaliados a partir dos produtos intermediários obtidos nas fases de desenvolvimento para a tomada de decisões estratégicas e gerenciais.
 ISO/IEC 14598-4 - Processo para adquirentes - contém requisitos, recomendações e orientações para a medição, julgamento e avaliação sistemática da qualidade de produto de software durante a aquisição de produtos de software de prateleira, produtos de software sob encomenda ou modificações em produtos de software existentes.
 ISO/IEC  14598-5– Processo para avaliadores – descreve um processo para avaliação de produtos de software. 
 ISO/IEC  14598-6 – Documentação de módulos de avaliação – estabelece requisitos e instruções a respeito de como testar um pacote de software em relação aos requisitos estabelecidos para o pacote.
Avaliar a qualidade de um produto de software é:
Verificar, através de técnicas e atividades operacionais, o quanto os requisitos são atendidos. Tais requisitos, de uma maneira geral, expressam as necessidades explicitadas em termos quantitativos ou qualitativos e apresentam como objetivo a definição das características de um software, a fim de permitir o exame de seu entendimento.
Deve-se avaliar a qualidade do produto liberado por diversas razões:
Identificar e entender: As razões técnicas para as deficiências e limitações do produto, que podem manifestar-se através de problemas operacionais e problemas de manutenção;
Comparar: Um produto com outro, mesmo que indiretamente;
Formular: Um plano de ação de como fazer o produto de software evoluir.
Pontos relevantes das partes
Segundo a ISO/IEC 14598-2, a função de apoio à avaliação deve fornecer um suporte abrangente à organização para projetos de desenvolvimento de software, aquisição de software e avaliação de software. Ela pode ser interna ou externa à organização que está avaliando o software.
Alguns papéis são relevantes, tais como:
Criação de critérios para benchmark.
Avaliação da eficácia e qualidade de qualquer aquisição.
Obtenção de padrões e de informações técnicas.
Desenvolvimento de padrões e ferramentas.
Desenvolvimento de software.
Coleta e análise de resultados de avaliações
Distribuição dos resultados de avaliação
Facilitação da transferência de tecnologia e suporte a projetos de avaliação
A função suporte à avaliação pode ser pensada no setor da organização encarregada de desenvolver, adquirir ou avaliar o software.
As responsabilidades de avaliação e de garantia da qualidade  devem constar em um plano que vise ao uso e melhoria da tecnologia de avaliação, implementação, transferência e avaliação da tecnologia de avaliação usada e, por fim, o gerenciamento da experiência de avaliar.
Por outro lado, a função pode ser direcionada para o projeto de avaliação suportado pela organização. 
O suporte incluiu o planejamento da avaliação quantitativa e a promoção desse plano de avaliação e tecnologia utilizadas para outros projetos dentro da organização.
A estrutura de um plano de avaliação quantitativa deve conter :
Introdução
Objetivos
Características da qualidade aplicáveis
Lista de prioridades
Objetivos da qualidade
Cronograma
Definição de responsabilidades
Categorias de medição
Uso e análise de dados
Relatórios
Demais requisitos de interesse
O plano pode ser divulgado por meio de palestras e reuniões técnicas.
A ISO/IEC 14598-4 ao referenciar o processo de aquisição definido pela ISO/IEC 12207 ressalta a existência das seguintes atividades:
Iniciação - O adquirente inicia o processo de aquisição ao considerar a necessidade de obter, desenvolver ou melhorar um sistema, produto ou serviço de software.
Preparação do pedido de proposta - Elaboração dos documentos de requisitos de aquisição bem como determinados os pontos de controle para revisão e auditoria do progresso do fornecimento.
Preparação e atualização do controle - Seleção de fornecedores e suas capacidades firmadas em contrato e, negociado o custo, cronograma de execução. As mudanças no contrato devem ser controladas pelo adquirente.
Monitoração do fornecedor - Consiste em atividades de avaliação durante a execução do contrato levando à aceitação e entrega do produto de software.
Aceitação e conclusão - Aceitação e entrega do produto de software final, obedecidos aos critérios de aceitação previamente definidos durante a atividade de iniciação.
A ISO/IEC 14598-5 – processo para o avaliador que visa fornecer requisitos e recomendações para a correta implementação prática de avaliação de produto de software. Conta com a participação de avaliadores de laboratório, fornecedores e adquirentes de software, usuários e entidades certificadoras que defendem objetivos diferentes.
Os avaliadores podem ser especificamente:
- Os laboratórios de testes
- As equipes de testes integradas de organizações de produção ou de distribuição de software
- Os compradores ou usuários de software ou de integradoras de sistemas
- As organizações que realizam comparações de softwares
Pode ser aplicada tanto para produto existente como para produtos em desenvolvimento.
Além das partes envolvidas no processo, a norma descreve um procedimento passo a passo dos requisitos de avaliação expressos com as devidas características de qualidade.
São gerados vários documentos que passam a ser considerados como parte do produto de software, tais como:
documentos de projeto
relatórios de teste e validação
código fonte
documentação de usuário
O processo de avaliação envolve um conjunto de atividades conduzidas pelo requisitante da avaliação e pelo avaliador que iniciam o trabalho a partir do uso dos dados fornecidos pelo requisitante, pelo avaliador ou por outros meios e atividades do conjunto.
As atividades do processo de avaliação são as seguintes:
Estabelecimento de requisitos de avaliação → Descrição dos objetivos da avaliação coerentes com o produto de software e possíveis riscos associados. As percepções dos usuários do produto, fornecedores, compradores, desenvolvedores, operadores e mantenedores do produto devem ser levados em consideração.
Especificação da avaliação → Definição do escopo da avaliação e as medições a que o produto será submetido. Dependente dos requisitos de avaliação previamente definidos pelo requisitante.
Projeto de avaliação → Preparo de um plano de ação de acordo com a especificação do avaliador e com base nos métodos a serem usados para a realização das medições estabelecidas na especificação. Um documento guarda, portanto, as especificações da avaliação, o cronograma, os recursos necessários e disponíveis para realizar a avaliação.  
Execução da avaliação → Consiste na inspeção, medição e teste dos produtos e de seus componentes aplicados de acordo com as orientações do plano. Aplicadas as ações de medição, segue-se para as interpretações dos resultados registrados e depurados durante a avaliação. Ao final da execução, uma versão preliminar é gerada do relatório de avaliação.
Conclusão da avaliação → Revisão do relatório de avaliação e liberação dos dados de avaliação, bem como a devolução, pelo avaliador, do produto avaliado e seus componentes.
No final do processo, os resultados esperados da avaliação de produto devem ser compreensíveis, aceitáveis e confiáveis por quaisquer partes interessadas nos papéis de requisitante de uma avaliação ou de avaliador. Dessa forma, espera-se obter um alto nível de objetividade da avaliação.
De acordo com a ISO/IEC 14598-5, as características esperadas do Processo de Avaliação são:
Repetitividade → Avaliação repetida de um mesmo produto, com mesma especificação de avaliação, realizada pelo mesmo avaliador, deve produzir resultados que podem ser aceitos como idênticos.
Reprodutividade → A avaliação do mesmo produto, com mesma especificação de avaliação, realizada por um avaliador diferente, deve produzir resultados que podem ser aceitos como idênticos.
Imparcialidade → A avaliação não deve ser influenciada frente a nenhum resultado particular.
Objetividade → Os resultados da avaliação devem ser factuais, ou seja, não influenciados pelos sentimentos ou opiniões do avaliador.
Considera-se que as avaliações de um mesmo produto podem ser executadas a partir de diferentes especificações e, portanto, não comparáveis e com resultados diferentes.
A documentação do processo de avaliação de um produto de software, representado pela ISO/IEC 14598-5, deve englobar um conjunto de métricas que fornecem informações importantes sobre as propriedades do software e devem ser utilizadas de maneira eficiente de tal forma que possibilite a troca de informações sobre avaliações e entre avaliadores. Para tanto, requer que haja uma padronização na forma de documentação o que é feito pela aplicação de módulos de avaliação (M.A.).
Aula teletransmitida:
ISO/IEC 14698 – AVALIAÇÃO do produto de software
 *Correlação com norma 9126. (Baseada na utilização prática dessa norma)
Visão geral: Fornece uma visão geral dos processos de avaliação de software.
Aula 7: Modelos de Melhoria e Avaliação de Processos de Software ISO 9000-3
Melhoria de processo de software
Para o avanço das organizações intensivas em software (desenvolvimento/aquisição), a prática da melhoria de processo de software tem se mostrado viável, eficaz e eficiente.
Consiste a abordagem na prática de ações orientadas para alteração dos processos aplicados para:
- Aquisição
- Fornecimento 
- Desenvolvimento
- Manutenção e/ou suporte de sistemas de software
Atualmente, a melhoria de processo de software faz parte da disciplina da engenharia de processo de software com uma forte tendência em atender concomitantemente aos sistemas. Inicialmente, dois conceitos são fundamentais para a melhoria de processo de software, tais como processo e capacidade de processo*.
* Por processo considera-se a definição como sendo “o que as pessoas fazem, utilizando tecnologias, métodos e ferramentas para produzir um resultado desejado”. O conceito de processo de software fica, portanto, atrelado ao “o que as pessoas fazem, por meio de atividades, métodos, práticas e transformações para desenvolver, manter e melhorar software e produtos associados”
(adaptado de Paulk (1993)).
* Por capacidade de processo entende-se a habilidade do processo em ser executado de forma eficiente e eficaz com a presença de algumas características importantes:
 	→ Execução consistente e sempre que necessária.
	→ Flexibilidade no processo de execução para melhor adaptação das necessidades específicas.
	→ Documentação com uma notação representativa de processo identificado por meio de texto, figuras, fluxos, etc.
	→ Deve ser apropriado para que as pessoas possam realizar o trabalho.
	→ Treinamento para as pessoas inseridas nas atividades do processo de forma a obterem conhecimento, habilidade e experiência.
	→ Manutenção para garantir a evolução contínua.
	→ Controle de mudanças para garantir a integridade e disponibilidade dos artefatos.
	→ Apoio de equipes, ferramentas e recursos apropriados para realização do processo.
A capacidade de processo determina que uma organização tenha processos executados de forma que sejam gerenciados, definidos, medidos, controlados, efetivos e melhorados continuamente.
Torna-se importante considerar que o grau de formalização do processo e a complexidade da comunicação em um projeto deve ser equilibrado, ou seja, uma formalização do processo adequada e uma comunicação correta para a efetividade de processo (capacidade).
A estrutura do guia ISO 9000-3
As normas da série ISO 9000 representam outro marco na utilização de processo. As normas foram desenvolvidas para apoiar organizações de todos os tipos e tamanhos, na implementação e operação de sistemas da qualidade eficazes. Especificamente a ISO 9000-3, interesse desse estudo, define diretrizes para facilitar a aplicação da norma ISO 9001 a organizações que desenvolvem, fornecem e mantém software. Destina-se a fornecer orientação quando um contrato entre duas partes exigir a demonstração da capacidade do fornecedor em desenvolver, fornecer  e manter produtos de software.
De fato, a ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software. As diretrizes propostas na ISO 9000-3 cobrem questões como:
Entendimento dos requisitos funcionais entre contratante e contratado;
Uso de metodologias consistentes para o desenvolvimento de software;
Gerenciamento de projeto desde a
concepção até a manutenção.
Relevante destacar que uma das limitações da ISO 9000-3 é o fato de não tratar de aspectos como a melhoria contínua do processo de software (SPI – Software Process Improvement). Dessa forma, a ISO 9000-3 considera apenas quais processos a organização deve ter e manter, mas não orienta quanto aos passos que devem ser seguidos para chegar a desenvolvê-los e nem de como aperfeiçoá-los.
A documentação do processo de avaliação de um produto de software, representado pela ISO/IEC 14598-5, deve englobar um conjunto de métricas que fornecem informações importantes sobre as propriedades do software e devem ser utilizadas de maneira eficiente de tal forma que possibilite a troca de informações sobre avaliações e entre avaliadores. Para tanto, requer que haja uma padronização na forma de documentação o que é feito pela aplicação de módulos de avaliação (M.A.).
As diretrizes da ISO  9000-3
A ISO 9001 baseia-se em 20 diretrizes (ou critérios) que englobam vários aspectos da garantia da qualidade. 
A ISO 9000-3 engloba somente 12 desses elementos. O ponto central dos critérios de um sistema de gestão da qualidade baseada nas normas ISO 9000 é a apropriada documentação desse sistema. 
A norma brasileira equivalente à ISO 9000-3 é a ISO 9000-3 de 1993, baseada na edição de 1991, e agrupa as diretrizes em três partes principais:
 
> Estrutura – descreve aspectos organizacionais relacionados ao sistema de qualidade.
> Atividades do ciclo de vida: descreve atividades de desenvolvimento de software.
> Atividades de suporte: descreve atividades que apoiam as atividades do ciclo de vida.
A estrutura, nomenclatura e arranjo da atual ISO 9000-3, de 1997, seguem exatamente a estrutura da ISO 9001 e suas diretrizes têm o mesmo nome.
ATENÇÃO!!!	A ISO 9000-3 apoia a aquisição da certificação da qualidade pelas organizações intensas no desenvolvimento de software, assim como as ISO 9001, 9002 E 9003.
RESPONSABILIDADES DA GERENCIA
A política de qualidade deve ser definida, documentada, comunicada, implementada e mantida por uma gerência. 
Por meio da política, o gerente descreve a atitude da organização em relação à qualidade. → Define a estrutura organizacional necessária para o melhor gerenciamento da qualidade. → No momento da definição, o gerente identifica as autoridades e atribui responsabilidades ao pessoal do sistema de qualidade que deve cumprir e assegurar que a interação entre as pessoas envolvidas esteja claramente especificada.
Desta forma, o gerente assume as seguintes responsabilidades:
- Identificar e fornecer os recursos adequados para a execução do trabalho do sistema de qualidade. 
- Indicar um executivo experiente com a devida autoridade para gerenciar o sistema de qualidade.
- Possibilitar que os gerentes possam usar os procedimentos e aprimorar a eficiência do sistema de qualidade.
- Revisar periodicamente o sistema de qualidade para o seu aprimoramento.
- Manter os registros de todas as revisões.
REQUISITOS DO SISTEMA DE QUALIDADE
O sistema de qualidade deve ser documentado na forma de um manual e, assim, implementado.
Para tanto, o desenvolvimento de um Plano de Qualidade torna-se necessário sempre que for preciso controlar a qualidade de um projeto, de um produto, ou de um contrato específico com clientes.
O plano deve especificar detalhadamente os procedimentos para controlar a gerência de configuração, a verificação do produto, a validação do produto, a não conformidade do produto e as ações corretivas. Os procedimentos devem ser consistentes com a política de qualidade.
O plano deve mostrar como cumprir os requisitos do sistema de qualidade que, por sua vez, devem estar integrados às atividades do ciclo de vida, para assegurar que a qualidade está sendo construída ao longo de todo o projeto.
O plano de qualidade aplica-se ao controle dos projetos de desenvolvimento de software.
REVISÃO DOS REQUISITOS DE CONTRATO
Nesse item, os requisitos contratuais precisam ser completos e bem definidos para garantir que a organização atenda às exigências contratuais. Deve ser feita uma cuidadosa análise crítica do contrato.  
 
Procedimentos devem ser criados para que a coordenação de atividades de revisão do contrato de desenvolvimento de software possa ser feita junto ao cliente. A participação do cliente na revisão do contrato garante que os requisitos contratuais estabelecidos entre as partes são aceitáveis no correto fornecimento de produtos e/ou serviços. As revisões dos contratos firmadas junto ao cliente devem ser mantidas para consultas posteriores.
Atenção!!! Procedimentos devem ser desenvolvidos e especificados – como os contratos com os usuários devem ser corrigidos (emendados) – e que assegurem que as alterações serão comunicadas a toda organização.
Assim, investigue se as partes envolvidas no contrato (contratada e contratante) concordam:
Como os termos são definidos.
Como será feita a aceitação dos produtos.
Como o cliente irá participar.
Como os usuários do software serão treinados.
Como as atualizações de software (upgrades) serão feitas.
Como os melhoramentos do software serão feitos.
Como as mudanças nos requerimentos do cliente serão tratadas.
Como os problemas serão tratados após a aceitação do produto.
Que o projeto é viável.
Que os direitos legais de terceiros serão respeitados.
Que o cliente pode cumprir todas as obrigações contratuais.
Que um cronograma apropriado para o projeto foi estabelecido.
Que os riscos significativos e seus planos de contingência foram identificados.
Que todas as obrigações contratuais e respectivas penalidades foram especificadas. 
Que os procedimentos de desenvolvimento de software foram definidos.
Que os recursos estarão definidos quando necessário.
Que a extensão das suas responsabilidades para com subcontratos foi definida.
REQUISITOS DA FASE DE PROJETO DO PRODUTO
As atividades referentes a projetos como planejamento, métodos para revisão, mudanças e verificações ocorridas, no decorrer do desenvolvimento do produto, devem ser documentadas para assegurar que todos os requisitos do produto foram cumpridos.
 
O desenvolvimento de planos de procedimentos na fase de elaboração do projeto de software sugere que seja executado de forma disciplinada, e o mesmo deve ocorrer durante o desenvolvimento de software com vistas a assegurar que é cumprido de forma sistemática.
O plano deve conter alguns requisitos necessários com a devida documentação e aprovação dos envolvidos antes de ser implementado. O plano deve:
Definir o projeto.
Listar os objetivos do projeto.
Apresentar o cronograma do projeto.
Definir as entradas e saídas do projeto.
Identificar planos e projetos relacionados.
Explicar como o projeto será organizado.
Discutir riscos de projeto assumidos.
Identificar todas as estratégias de controle relevantes.
Por outro lado, o plano de desenvolvimento de software precisa definir:
 
A responsabilidade dos participantes no desenvolvimento do software. 
Os meios como as informações técnicas serão compartilhadas e transmitidas entre todos os participantes.
O comprometimento do cliente em aceitar, cooperar e dar suporte ao projeto de desenvolvimento de software.
A agenda de revisões do projeto para avaliar as atividades e os resultados alcançados por todos os participantes.
ATENÇÃO!!!
Desenvolver procedimentos para assegurar que todos os requisitos de entrada da fase de projeto são identificados, documentados e revistos, e que todas as falhas, ambiguidades, contradições e deficiências são resolvidas.
 
Os requisitos de entrada da fase de projeto devem ser especificados pelo cliente, apesar
de ocorrer, em alguns casos, uma expectativa do cliente de que os mesmos sejam especificados pelos responsáveis da fase de projeto. Nesse caso, torna-se prudente trabalhar junto ao cliente de forma que evite um mau entendimento e, assim, assegure que a especificação está de acordo com as necessidades e expectativas do cliente. Uma validação durante a aceitação do produto é recomendada, bem como a aprovação do resultado da especificação das entradas da fase de projeto. 
 
Da mesma forma, procedimentos padronizados devem ser especificados para controlar as saídas da cada estágio da fase de projeto e desenvolvimento do produto de forma assegurar que estão corretos e completos. As revisões, demonstrações e testes devem ser frequentes e devidamente mantidas e registradas na fase de projeto. 
 
Por fim, manter o registro das validações da fase do projeto e do desenvolvimento que confirmam a avaliação do produto por parte do cliente. 
 
Procedimentos devem também ser desenvolvidos para o garantir o controle das alterações no projeto do software que possam ocorrer durante todo o ciclo de vida.
CONTROLE DE DOCUMENTOS E DADOS
A ISO 9000-3, de 1994, classifica como Controle de documentos e dados toda geração, distribuição, mudança e revisão em todos os documentos.
 
O controle da norma orienta para que se desenvolvam procedimentos para identificar todos os documentos e dados que devam ser controlados e definir a forma de acesso dos funcionários da organização a esses documentos, assim como desenvolver procedimentos para revisar, aprovar e manter todos os documentos e dados do sistema de qualidade, mesmo que ocorram mudanças.
REQUISITOS DE AQUISIÇÃO (COMPRA)
Para esse item da norma, considera-se que todos os produtos e serviços adquiridos atendam às exigências especificadas (requisitos) e, para tanto, deve haver procedimentos para a avaliação de fornecedores tanto de produtos como de serviços.
Os procedimentos devem visar:
> à seleção,
> à avaliação,
> ao monitoramento,
> ao controle dos subcontratados e fornecedores, bem como a verificação de produtos comprados.
IMPORTANTE - Os registros dos subcontratados tornam-se essenciais e devem ser acompanhados do aceite destes, além da certificação de que os documentos de compra descrevem corretamente o que de fato se deseja comprar.
PRODUTOS FORNECIDOS POR CLIENTES OU FORNECEDORES
Procedimentos devem ser desenvolvidos para assegurar que os produtos fornecidos por clientes e/ou fornecedores sejam adequados ao uso e devidamente mantidos.
 
> ISO 9000-3:1991 - Produto de software incluído.
> ISO 9000-3:1994 chama de Customer-supplied products
Algumas preocupações relevantes: 
> Examinar o produto para confirmar se todos os itens estão presentes e não danificados.
> Armazenar o produto de forma apropriada e segura para evitar perdas ou danos.
> Registrar e comunicar ao cliente no caso de perda ou dano de qualquer produto.
> Estabelecer quem é responsável pela manutenção e controle dos produtos enquanto eles estiverem em sua posse.   
> Controlar produtos, serviços, documentos e dados fornecidos pelo cliente.
IDENTIFICAÇÃO E CONTROLE DE PRODUTOS 
Necessidade de procedimentos para a identificação do produto por item, série ou lote durante todos os estágios da produção, entrega e instalação. O produto deve poder ser rastreado através dessa identificação.
A coerência nos procedimentos possibilita que todos os passos do caminho do produto (manipulação, armazenamento, produção, envio, instalação e serviço) sejam devidamente controlados por meio de identificadores únicos com o registro mantido apropriadamente.
A identificação do produto de software ou de seus componentes pode ser mantida não só durante a fase de definição do produto, mas também durante todo o seu ciclo de vida.
O acompanhamento do produto de software e seus componentes durante o ciclo de vida também se faz necessário. Para tanto, métodos de gerência de configuração (configuration management) podem ser usados para identificar e acompanhar o software e seus componentes.
PROCESSO DE CONTROLE DE REQUISITOS
Requer que todas as fases de processamento de um produto sejam controladas (por procedimentos, normas, etc.) e documentadas. Os procedimentos para planejar, monitorar e controlar seu processo de produção, instalação e manutenção devem ser devidamente documentados.
 
Um bom sistema pode manter registros que monitorem e controlem processos, pessoal e equipamentos. Da mesma forma, procedimentos desenvolvidos podem controlar os processos de reprodução, liberação e instalação do software (software replication, reliase and intallation).
TESTES E INSPEÇÕES DO PRODUTO
Todas as atividades de teste e inspeção do produto devem ser devidamente controladas por meio de registros.
→ Requer que as matérias-primas sejam inspecionadas  (por procedimentos documentados) antes de sua utilização.
→ Antes de utilizar matérias-primas, elabore procedimentos para inspecionar, testar e verificar se o produto cumpre todos os requisitos especificados. 
→ Os planos de teste do software (software test plans) devem ser documentados.
→ No caso de produtos adquiridos por terceiros (fornecedores ou o próprio cliente) os requisitos devem ser verificados antes de disponibilizados para o uso no processo de desenvolvimento.
→ O mesmo deve ser considerado para o produto final, ou seja, verificar se ele cumpre todos os requisitos antes de disponibilizado para o comércio.
CONTROLE DE EQUIPAMENTOS DE INSPEÇÃO
Requer o desenvolvimento de procedimentos para controlar, calibrar e manter equipamentos (hardware e software) de inspeção, medida e teste usados para demonstrar que seu produto cumpre os requisitos especificados.
 
Considera-se, também, o uso de ferramentas, técnicas e equipamentos para testar se o produto de software está de acordo com os requerimentos especificados.
AVALIANDO O APRENDIZADO
		1.
		
		Producibilidade, rastreabilidade, geração de relatórios, controle de mudanças são razões para criar _______________.
		Quest.: 1
		
		
		
		
		um repositório de backup
		
		
		um protótipo
		
		 
		um baseline
		
		
		uma fábrica de software
		
		
		uma fábrica de testes
		
		
		2.
		A ISO 9000-3 trata de modelos de melhoria e avaliação de processo de software. A opção que não representa uma característica para execução de forma eficiente e eficaz para capacidade de processo é?
		Quest.: 2
		
		
		
		
		Manutenção
		
		
		Execução
		
		 
		Operação
		
		
		Controle
		
		
		Treinamento
		
		
		3.
		Segundo a Norma ISO 9000-3, devem ser estabelecidos programas de treinamento para manter, atualizar e ampliar os conhecimentos e as habilidades dos funcionários e, assim, garantir a qualidade. Os programas devem assegurar que:
I. As necessidades de treinamento em qualidade são identificadas.
II. Treinamento em qualidade é fornecido para aqueles que precisam dele.
III. Pessoas são capacitadas a executar as tarefas do sistema de qualidade.
IV. Registros acurados e apropriados dos treinamentos são dispensados.
		Quest.: 3
		
		
		
		 
		Apenas I, II e III
		
		
		Apenas II, III e IV
		
		
		Apenas II e III
		
		
		Apenas I, II e IV
		
		
		Apenas I, III e IV
AULA 8 – MODELO DE QUALIDADE DO PROCESSO E CICLO DE VIDA DO SOFTWARE
NBR ISO/IEC 12207
Qualidade em uso
A NBR ISO/IEC 12207 – Processos de Ciclo de Vida de Software  tem como objetivo o estabelecimento de uma estrutura comum para os processos de ciclo de vida de software como forma de ajudar as organizações a compreenderem todos os componentes presentes na aquisição e fornecimento de software e, assim, conseguirem firmar contratos e executarem projetos de forma eficaz. 
 
As pesquisas em torno da engenharia de software mostram a relevância da resolução de problemas de falhas em projetos basear-se em modelos de melhoria e processo que permeiam três variáveis de suma importância e nenhuma mais importante que a outra, mas conjuntamente expressivas no contexto de desenvolvimento de software:
PROCESSO			PESSOAS			TECNOLOGIA
É evidente a influência de uma na outra, como os processos imaturos (Processo) que fazem com que se tenha uma deficiência no estabelecimento do perfil técnico adequado para exercer uma atividade (Pessoa) que, por sua vez, não consiga usufruir o melhor da tecnologia oferecida (Tecnologia).
(
Dessa forma, a comunidade de software entende, então, a importância de criar normas, modelos e métodos para regular e orientar a definição de processos de software.
Vamos, então, concentrar nossos estudos em duas partes:
O significado do processo
Escopo da Norma NBR ISO/IEC 12207
O SIGNIFICADO DO PROCESSO:
Quando é fornecido um serviço ou criado um produto, no caso específico de um software:
Para Pfleeger (2004), um processo envolve um conjunto de métodos, técnicas, ferramentas e pessoas de forma a prescrever todas as suas principais atividades. Complementa que cada atividade do processo tem critérios de entrada e saída, de modo que seja possível saber quando o processo começa e termina.
Considera-se que o processo de criação de um produto pode ser concebido como um ciclo de vida composto por procedimentos. Da mesma maneira, pode-se considerar que o processo de desenvolvimento de software constitui-se ser o ciclo de vida do software.
Vantagens do gerenciamento por processos:
Alinha estrategicamente a organização.
Foca a organização no cliente.
Obriga a organização a prestar contas pelo desempenho dos seus processos.
Alinha a força de trabalho com os processos.
Evidencia a necessidade de alocação de recursos.
Melhora a eficiência.
Modularidade e responsabilidade
Os processos da ISO/IEC 12207 são fortemente coesos, ou seja, todas as partes de um processo são fortemente relacionadas. Porém, os processos são fracamente acoplados quanto à quantidade de interfaces entre os processos.
ESCOPO DA NORMA NBR ISO/IEC 12207
A NBR ISO/IEC 12207 estabelece uma arquitetura de ciclo de vida de software construída a partir de uma estrutura de processos e seus inter-relacionamentos descritos tanto em nível de propósito/saída como em termos de processos, atividades, tarefas, propósito e resultados que servem para ser aplicados:
durante a aquisição de software, de um produto de software independente ou de um serviço de software.
durante o fornecimento, desenvolvimento, operação e manutenção de produtos de software.
A proposta da norma é a sua utilização desde a concepção até a descontinuidade do produto de software ressaltando a importância do envolvimento de todos aqueles responsáveis pela produção, manutenção e operação do software tais como adquirentes, fornecedores, operadores, desenvolvedores, mantenedores, gerentes, profissionais de qualidade e usuários.
- FUNDAMENTAL:
Os processos fundamentais iniciam o ciclo de vida do software e comandam a execução de todos os outros processos.  Eles constituem um conjunto de cinco processos que são:
• Aquisição – inicia o ciclo de vida de software
• Fornecimento – responde pela execução dos processos de desenvolvimento, operação e manutenção
• Desenvolvimento – contém as atividades e tarefas que devem ser executadas pelo desenvolvedor
• Operação – contém as atividades e tarefas do operador com a cobertura do software e o suporte operacional dos usuários
• Manutenção – torna-se ativo quando o produto de software é submetido a modificações no código e na documentação associada devido a um problema, necessidade de melhoria ou adaptação.
Atividades do desenvolvimento
Algumas atividades importantes para o desenvolvimento de software serão descritas com base na norma ISO/IEC 12207. São elas:
• Implementação. 
• Levantamento de requisitos. 
• Análise dos requisitos do software. 
• Projeto da arquitetura do software. 
• Projeto detalhado do software. 
• Codificação e testes do software. 
• Integração do software. 
• Teste de qualificação do software. 
• Instalação do software.
- APOIO:
Os processos de apoio são de responsabilidade da organização que o executa.
O objetivo é proporcionar qualidade aos outros processos, pois através de sua execução acredita-se que eles terão garantia de qualidade e uma maior organização.
Podem ser utilizados pelos processos fundamentais de apoio organizacional.
- ORGANIZACIONAL:
• Os processos organizacionais são chamados pelos outros processos e devem existir independentemente do projeto que está sendo executado.
• As atividades e tarefas em um processo organizacional são de responsabilidade da organização que o utiliza.
• Os processos organizacionais são instanciados nos processos fundamentais porque eles são gerenciados de forma diferente.
- ADAPTAÇÃO:
O propósito do processo de adaptação é realizar a adaptação básica da norma para um projeto de software.
• É interessante reforçar a característica da norma por meio das atividades e tarefas do processo de ciclo de vida do software; somente especificar “o que fazer” e não “como fazer”. 
• Outra característica que diz respeito à norma é possibilitar a modularidade do processo, a forte coesão entre os processos fundamentais de apoio e organizacionais. Isso significa  que todas as partes de um processo estão fortemente relacionadas, porém a quantidade de interfaces entre os processos é mínima.
Algumas regras são importantes para identificação, escopo e estruturação dos processos e devem ser seguidas.
Um processo deve ser modular, isto é, convém que um processo execute uma e somente uma função dentro do ciclo de vida e é conveniente que as interfaces entre dois processos quaisquer sejam mínimas.
Cada processo é invocado na arquitetura.
Se um processo A é invocado por um processo B e somente por ele, então A pertence a B.
Se uma função é invocada por mais de um processo, então essa função torna-se um processo.
Deve ser possível verificar qualquer função dentro do modelo de ciclo de vida.
Convém que cada processo tenha uma estrutura interna suficientemente definida para que possa ser executável.
Avaliando o aprendizado:
		1.
		
		A "Auditoria", um dos processos de qualidade de software pertencentes à natureza de apoio dos processos, tem como objetivo determinar de forma independente, a conformidade dos produtos e processo selecionados com os requisitos, planos e contratos, quando apropriado. O resultado da auditoria requer que os problemas detectados e identificados sejam comunicados aos responsáveis pelo (a) _____________________.
		Quest.: 1
		
		
		
		 
		ação corretiva e sua respectiva resolução
		
		
		provedor de acesso
		
		
		administração dos negócios
		
		
		administração dos negócios
		
		 
		gerência de produção
		
		
		2.
		A "Documentação", um dos processos de qualidade de software pertencentes à natureza de apoio aos
processos, tem como objetivo:
I. Desenvolver e manter registradas as informações do software produzidas por um processo.
II. Criar uma documentação técnica contemplando diagramas, modelos de dados, relatórios e especificação de requisitos produzidos pelo processo de desenvolvimento.
III. Evitar a distribuição da documentação de desenvolvimento de software.
		Quest.: 2
		
		
		
		
		Somente I está correta
		
		
		Somente II e III estão corretas
		
		 
		Somente I e II estão corretas
		
		
		Somente III está correta
		
		
		Somente I e III estão corretas
		
		
		3.
		São atributos para avaliação da manutenibilidade:
		Quest.: 3
		
		
		
		 
		Analisabilidade, estabilidade, inteligibilidade, apreensibilidade e conformidade
		
		
		Apreensibilidade, estabilidade, estabilidade, testabilidade e confiabilidade
		
		
		Analisabilidade, modificabilidade, inteligibilidade, testabilidade e confiabilidade
		
		
		Analisabilidade, estabilidade, inteligibilidade, testabilidade e conformidade
		
		 
		Analisabilidade, modificabilidade, estabilidade, testabilidade e conformidade
AULA 9 – MODELOS DE QUALIDADE DE PROCESSO DE SOFTWARE ISO/IEC 15504 – (SPICE - AVALIAÇÃO), CMMI E MPS.BR
A ISO/IEC 15504, conhecida também como SPICE (Software Process Improvement and Capability Determination), consiste em uma norma para definição de processos de desenvolvimento de software. Os requisitos da norma são uma evolução da norma ISO/IEC 12207, porém apresenta níveis de capacidade para cada processo. Por muito tempo, a norma manteve-se em estudo e, somente em 1993, a ISO tornou pública a norma ISO/IEC 15504 (SPICE) para avaliação de processos de software.
Trata-se de um modelo bidimensional com objetivo de realizar avaliações dos mesmos com foco na sua otimização no que tange aos pontos fortes e oportunidades de melhoria, e a determinação da capacidade dos processos por meio da avaliação de um fornecedor em potencial.
A norma considera a avaliação de processo como uma investigação e análise organizada de processos selecionados de uma unidade organizacional em relação a um modelo de avaliação de processo.
O modelo de avaliação de processo é organizado em uma arquitetura com dois níveis, sendo o primeiro composto por três categorias de processo:
FUNDAMENTAIS		ORGANIZACIONAIS		DE APOIO
O segundo nível é composto por dez grupos de processo que são alocados em cada uma das categorias de processo. Cada um é definido por seis níveis de capacidade sequenciais e cumulativos que podem ser utilizados como uma métrica para avaliar como uma organização está realizando um determinado processo. Também podem ser utilizados como um guia para a melhoria cuja utilização tem como referência um modelo de processo que enfatiza a realização de uma avaliação de processo.
O guia apresenta oito etapas sequenciais que inicia com a identificação de estímulos para a melhoria e o exame das necessidades da organização. 
A norma ISO/IEC 15504 define, também, um ciclo de melhorias a fim de identificar novas melhorias, avaliar as práticas correntes em relação à melhoria realizada.
O processo é composto por:
PLANEJAMENTO 									 ACOMPANHAMENTO 
	DA	 (IMPLEMENTAÇÃO(CONFIRMAÇÃO(MANUTENÇÃO( 		DA
 MELHORIA										 MELHORIA
Dimensão de Processos
A norma ISO/IEC 15504 relaciona as três categorias, os dez grupos e quarenta e oito processos dos modelos de avaliação de processo. A tabela em pdf apresenta detalhadamente cada um desses componentes.
Os seis níveis básicos para descrição de cada categoria de processo da norma ISO/IEC 12207 são:
- Identificação do processo (process identifier).
- Nome do processo (process name).
- Propósito (process purpose).
- Resultados (outcomes). - descreve os resultados esperados de uma implementação com sucesso deste processo (produção de um artefato; uma mudança significativa de estado; atendimentos aos requisitos e objetivos).
- Práticas base (base practice). - atividade que, quando executada de forma consistente, contribui para o atendimento do propósito de um processo. Para cada prática base estão relacionados os resultados (outcomes) que a prática ajuda a alcançar.
- Produtos de trabalho (work-products). - Os produtos de trabalho de um processo são aqueles esperados de serem utilizados e/ou produzidos pela execução do processo.  A lista de produtos de trabalho para cada processo deve ser utilizada como orientação para avaliação ou melhoria do processo.
Veja a seguir, um exemplo prático da aplicação dos níveis básicos no Processo de Aquisição do grupo de categorias dos processos fundamentais:
Identificação: ACQ.1
Nome: Prepara para aquisição (Acquisition preparation ) 
Propósito: Estabelecer as necessidades e objetivos da aquisição e comunicá-los aos potenciais fornecedores.
Resultados:
R1 - O conceito ou a necessidade de aquisição, desenvolvimento ou melhoria é estabelecido.
R2 - Os requisitos de aquisição necessários, definindo as necessidades do projeto, são definidos e validados.
R3 - Os requisitos conhecidos do cliente são definidos e validados.
R4 - Uma estratégia de aquisição é desenvolvida.
R5 - Os critérios de seleção do fornecedor são definidos.
Práticas Base:
ACQ.1.BP1: Estabelecer a necessidade. Estabelecer  uma necessidade de adquirir, desenvolver ou aprimorar um sistema, produto de software ou serviço. Resultado [1] 
ACQ.1.BP2: Definir os requisitos. Identificar o cliente / exigências das partes interessadas de um sistema e / ou produto de software ou serviço. [Resultados: 2, 3] 
ACQ.1.BP3: Regras de Revisão. Analisar e validar os requisitos definidos em relação às necessidades identificadas. Validar os requisitos para reduzir o risco de incompreensão por parte dos fornecedores potenciais. [Resultado: 3]
ACQ.1.BP4: Desenvolver estratégia de aquisição. Desenvolver uma estratégia para a aquisição do produto de acordo com as necessidades de aquisição. [Resultado: 4] 
Nota 1: A estratégia pode incluir uma referência ao modelo de ciclo de vida, cronograma e critérios de seleção.
Dimensão de Capacidade de Processo
Em uma organização, vários processos podem ter níveis de capacidade diferentes. A ISO/IEC  15504 define 6 níveis de capacidade sequenciais e cumulativos. Os  níveis podem ser usados para avaliar como uma organização está realizando um determinado processo  e como um  guia para a melhoria de processo. Cada nível de capacidade é descrito basicamente por um nome, definição e atributos.
A escala representa a capacidade de crescimento do processo implementado, desde não atender ao propósito do processo até atender aos objetivos atuais e projetados do negócio. Trata-se, portanto, de uma métrica para avaliação e um roteiro para melhoria baseados na capacidade do processo.
A medida da capacidade está baseada em atributos de processo que medem um aspecto específico da capacidade do processo requerida, conforme apresenta a tabela:
Veja a seguir, uma descrição detalhada dos atributos de processos:
Avaliação de Processo com a ISO/IEC 15504
Para executar uma avaliação correta, uma organização deve selecionar um modelo de processo compatível (no caso aplicação da norma ISO/IEC 15504), definir um processo de avaliação, identificar o perfil de capacidade de processo (PCP) com os respectivos níveis de capacidade e, acima de tudo, escolher um bom avaliador. Com todas essas etapas realizadas tendo por base o alcance dos objetivos de negócio, a análise dos resultados visando à melhoria contínua deve
gerar aspectos negativos e positivos, assim como os riscos associados aos processos.
Com isso, a evidência do alcance dos objetivos de negócio será determinada pela efetividade da prática da avaliação do processo em conformidade com os processos da norma ISO/IEC 15504. A figura 3.1 ilustra a interação do processo de avaliação com outros elementos importantes.
Todo processo de avaliação deve ser bem documentado e conter, no mínimo, as atividades de planejamento, coleta de dados, validação dos dados, pontuação dos atributos de processo e representação dos resultados.
O planejamento deve contemplar os seguintes elementos:
As atividades a serem executadas na avaliação.
Os recursos e cronogramas referentes às atividades.
A identidade e as responsabilidades dos participantes da avaliação.
Os critérios para verificar se os requisitos da norma foram atendidos.
Uma descrição dos resultados planejados.
A coleta de dados deve ser de forma sistemática, utilizando o seguinte:
A estratégia e técnica para seleção, coleta, análise dos dados e justificativas para atribuição de notas devem ser identificadas e demonstradas.
Correspondência entre os processos das unidades organizacionais identificados no escopo da avaliação e os elementos do Modelo de Avaliação de Processo.
Cada evidência objetiva deve satisfazer o escopo e objetivo da avaliação, bem como  deve ser registrada e mantida para futuras verificações da medição dos atributos.
A validação dos dados coletados de acordo com:
Confirmação de que as evidências coletadas são objetivas.
Garantia de que são suficientes e representativos para cobrir o escopo e propósito da avaliação.
Garantia que os dados coletados são consistentes.
Representação dos resultados
Os resultados da avaliação, incluindo as saídas especificadas, precisam ser documentados e comunicados ao patrocinador da avaliação ou a um dos seus representantes.
Melhoria de processo com a ISO/IEC 15504
Trata-se de descrever um guia para orientação da melhoria de processo, tendo como referência um modelo de processo e como uma das etapas a realização de uma avaliação de processo. 
O guia sugere 8 etapas sequenciais, conforme ilustra a figura:
A ISO/IEC 15504 não pressupõe modelos de ciclo de vida de software, tecnologias de software ou metodologias de desenvolvimento. Também não define um método explícito de avaliação, mas define os requisitos para o Método de Avaliação de Processos. Na prática, uma avaliação de processos de software é conduzida utilizando o Modelo de Avaliação de Processos e não o Modelo de Referência de Processos.
CMMI (Capability Maturity Model Integration)
É intenso o desenvolvimento de softwares produzidos sem a orientação padronizada de uma norma. Isso acontece por conta de os fabricantes se preocuparem em atender às necessidades iniciais do cliente, negligenciando aspectos de manutenção e durabilidade. O resultado dessa visão é a produção de softwares de baixa qualidade.
Definição, Características e Objetivos do CMMI
Tomado como modelo de referência, o CMMI é capaz de fornecer uma orientação para o desenvolvimento de processos de softwares.
O objetivo do modelo é:
Eliminar as inconsistências.
Aumentar a clareza e entendimento.
Fornecer uma terminologia comum e um estilo consistente.
Estabelecer regras de construção uniformes e assegurar consistência com a ISO/IEC 15504.
Assim como os demais modelos definem, não é proposta do CMMI definir como o processo deve ser implementado, mas determinar como as características estruturais e semânticas em termos de objetivos e de grau de qualidade devem ser realizadas no trabalho.
Representações do CMMI
O CMMI possui duas representações que possibilitam que a organização utilize diferentes caminhos para a melhoria de acordo com seu interesse, que são:
MPS.BR
O objetivo do MPS.BR sintetiza a descrição de Melhoria de Processo do Software Brasileiro. Participam da criação as universidades, os grupos de pesquisas e as empresas sob coordenação da SOFTEX.
Para isso, o MPS.BR desenvolve uma série de atividades cobrindo a elaboração de modelos de referência (MRMPS), elaboração de métodos de avaliação (MA-MPS), elaboração de guia de negócios (MN-MPS) para aquisição, desenvolvimento e aplicação de diversos cursos para capacitação, credenciamento de pessoas e instituições como implementadoras e avaliadoras, ações de disseminação para incentivo a utilização pelas empresas, e outras. A Figura 6.1 demonstra os modelos MPS.BR.
O MPS. BR baseia-se nas melhores práticas de engenharia de software, sendo compatível com o CMMI e em conformidade com as normas ISO/IEC 12207 e ISO/IEC 15504.
A versão 1.0 do modelo MR-MPS define 23 processos baseados em processos selecionados da ISO/IEC 12207 e ISO/IEC 15504-5 e nas áreas de processo do CMMI-SE/SW. Na estrutura do modelo são definidos sete níveis de capacidade ou maturidade de processo, expressos em termos de processos e de cinco atributos de processo (AP). Cada nível introduz alguns processos, mantendo todos os processos dos níveis inferiores e, eventualmente, acrescenta novos atributos de processo a todos os processos.
A figura a seguir demonstra a hierarquia dos níveis de maturidade do Modelo MPS.BR:
As vantagens na prática do modelo se justificam pela compatibilidade com o CMMI e com as demais normas, além de considerar uma implantação mais gradual e adequada a pequenas e médias empresas, uma possiblidade de obtenção do certificado, uma avaliação bienal das empresas e uma integração universidade-empresa.  
Por outro lado, apesar do foco do MPS.BR ser um meio das médias e pequenas empresas alcançarem a qualidade nos processos e nos produtos desenvolvidos, servindo como uma alternativa para o CMMI, a certificação não é competitiva o suficiente para tornar a empresa competitiva internacionalmente.
No contexto de micro e pequenas empresas de software, alguns métodos de avaliação para melhoria de processo estão sendo desenvolvidos, incluindo, por exemplo, QuickLocus [Kohan, 2003], RAPID [Rout 2000], MARES/15504, MPE [Anacleto, et. Al 2005], MA-MPS [SOFTEX 2005]. Basicamente, todos esses métodos enfocam em avaliações para orientar a melhoria usando vários modelos de referência, incluindo CMMI-SE/SW, ISO/IEC 15504 ou MR-MPS.
Avaliando o aprendizado:
		
		
		1.
Com o propósito de produzir software com qualidade, segundo o CMMI, a Garantia de Qualidade de Software (SQA) tem o objetivo de
		Quest.: 1
		
		
		
		 
		fornecer à gerência a visibilidade da eficácia dos processos utilizados pelo projeto de desenvolvimento de software e da qualidade dos artefatos que estão sendo criados.
		
		
		estabelecer e manter a integridade dos produtos do projeto de software ao longo do ciclo de vida de software.
		
		
		estabelecer planos exequíveis para desenvolver um determinado software, bem como para gerenciar o projeto de desenvolvimento do software segundo esses planos.
		
		
		fornecer uma visão realista do efetivo progresso do projeto, permitindo que a gerência de desenvolvimento possa tomar ações eficazes quando o desempenho do projeto desviar-se de forma significativa dos planos de software.
		
		
		estabelecer a responsabilidade organizacional para as atividades do processo de software, que melhoram, como um todo, a capacitação do processo de software da organização.
		
		
		2.
		Considerando as áreas de processo no CMMI, assinale a opção correta.
		Quest.: 2
		
		
		
		
		No nível de maturidade 3, uma área de processo relaciona-se à gerência quantitativa dos
processos visando possibilitar que sejam atingidos objetivos de qualidade e desempenho estabelecidos.
		
		
		No nível de maturidade 1, uma área de processo relaciona-se à gerência de requisitos, uma outra área de processo relaciona-se ao acompanhamento do projeto e identificação de ações corretivas.
		
		
		No CMMI, as pessoas diretamente responsáveis pelo gerenciamento e execução das atividades do processo são, normalmente, as que avaliam a aderência.
		
		
		No nível de maturidade 2, uma área de processo visa o desenvolvimento dos talentos e dos conhecimentos das pessoas na organização, uma outra área de processo visa à gerência de riscos.
		
		 
		As áreas de processo podem ser organizadas em categorias como gerência de processos e de projetos. Na gerência de processos, uma área visa possibilitar que as organizações entendam quantitativamente os seus processos.
		
		
		3.
		A dimensão de capacidade de processo apresenta 6 níveis. O processo executado e gerenciado com uma adaptação de um processo padrão definido, eficaz e eficiente é definição do nível:
		Quest.: 3
		
		
		
		 
		Estabelecido
		
		
		Gerenciado
		
		
		Otimizado
		
		
		Previsível
		
		
		Executado
_1462723914.unknown
_1462727400.unknown
_1462727404.unknown
_1462727406.unknown
_1462727408.unknown
_1462727405.unknown
_1462727402.unknown
_1462727403.unknown
_1462727401.unknown
_1462723918.unknown
_1462727396.unknown
_1462727398.unknown
_1462727399.unknown
_1462727397.unknown
_1462723920.unknown
_1462727394.unknown
_1462727395.unknown
_1462723921.unknown
_1462727393.unknown
_1462723919.unknown
_1462723916.unknown
_1462723917.unknown
_1462723915.unknown
_1462716495.unknown
_1462723909.unknown
_1462723912.unknown
_1462723913.unknown
_1462723911.unknown
_1462716498.unknown
_1462723907.unknown
_1462723908.unknown
_1462716499.unknown
_1462723906.unknown
_1462716497.unknown
_1462716491.unknown
_1462716493.unknown
_1462716494.unknown
_1462716492.unknown
_1462716489.unknown
_1462716490.unknown
_1462716487.unknown
_1462716488.unknown
_1462716485.unknown
_1462716486.unknown
_1462716483.unknown
QUALIDADE DE SOFTWARE.doc
 Matéria: Qualidade de Software
Aula 1 – Conceito de Qualidade
	O conceito de Qualidade de Software pode ser considerado como um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos especificados, prevenindo e eliminando defeitos.
	Qualidade é:	- estar em conformidade com os requisitos dos clientes
			- antecipar e satisfazer os desejos do cliente
			- escrever tudo que se deve fazer e fazer tudo o que foi escrito
	* O aumento de qualidade sempre é acompanhado por aumento de produtividade e redução de custos na forma de menos retrabalho e menor índice de perdas.
	No caso de software, isto pode significar reaproveitamento de códigos de programa, menor prazo de entrega, menor custo de manutenção e maior satisfação do cliente, que vai refletir em maior participação no mercado.
Aula teletransmitida
Qualidade é algo subjetivo, cujos parâmetros de avaliação variam de produto para produto.
Software é algo subjetivo, intangível, pode-se ver as linhas de código apenas, por isso é mais difícil aferir qualidade.
A Qualidade no Processo interfere diretamente na Qualidade do Produto.
Slide 1: A preocupação com Qualidade de Software
Período		Características
Anos 50		- erros conhecidos, após o término do programa.
Anos 70		- análise/programação estruturada
			- falta de consenso: teste antes do término.
Anos 80		- primeiras preocupações e padrões com Qualidade de Software
Anos 90		- primeiros processos de testes
			- motivação: Bug do Milênio
Anos 2000		- estruturação dos procedimentos de testes dentro do processo de desenvolvimento.
			- surgem excelentes ferramentas de testes
- qualidade total no processo de desenvolvimento e produto de software.
Anos 50: Programação em linguagem de baixo nível, linguagem de máquina, um pouco depois em Assembler.
Tratava o erro (eram erros conhecidos), após o término do programa.
Anos 70: Começo da organização de processos; as técnicas começaram a emergir.
Houve a necessidade de se estabelecer critérios para se programar de maneira que os programas pudessem ser lidos por outras pessoas.
Início da programação estruturada.
Estudo do problema.
Qualidade era a ausência de erro.
Entre os Anos 70 e 80: Crise do Software:
As empresas tinham dificuldade em colocar os produtos no mercado a tempo, havia também a dificuldade em manter os custos nos valores tratados. O mercado ficou abalado.
Anos 80: Primeiras preocupações com qualidade. Necessidade do surgimento de um padrão.
Qualidade do software durante o processo de desenvolvimento.
Anos 90: Bug do Milênio:
As datas eram armazenadas apenas com 2 dígitos, não se sabia como o programa se comportaria internamente ao somar o 99 com mais 1 ano (se ele colocaria o ano 2000 ou i ano 100). Todos os programas importantes dessa época passaram por uma bateria de testes, que visavam verificar como os programas se comportariam na soma do ano de 99 com mais 1 ano, e realizar as correções necessárias.
Percebeu-se na prática, a importância da previsão do que se deve fazer.
Anos 2000: Teste começa a ser visto como uma fase, e a importância do teste em todas as fases do processo de desenvolvimento.
Surgimento de ferramentas de teste.
Incorporou-se ao processo de desenvolvimento, o conceito de qualidade total.
 	Slide 2: A crise do Software
	FATOS REAIS – PROJETOS DE SOFTWARE
	+ 30% dos projetos – Cancelados
	+ 70% dos projetos – Falha nas funcionalidades
	CUSTOS E PRAZOS EXTRAPOLAM A PREVISÃO
Custos – em mais de 180%
Prazos – em mais de 200%
CUSTOS DE DESENVOLVIMENTO
80% - Identificar e corrigir defeitos de programação
Faltavam técnicas de mensuração do tempo de projeto.
	Slide 3: Aspectos relevantes sobre software e processo de desenvolvimento
Software não é tangível. Requer muita abstração para desenvolvê-lo.
O processo de desenvolvimento é executado e gerenciado por pessoas, sendo portanto subjetivo.
Discute-se idéias, necessidades e desejos dos usuários (também pessoas).
Abstração e subjetividade conferem dificuldades ao processo de desenvolvimento.
O software em si, é conseqüência direta da forma (processo) pelo qual foi desenvolvido. Processo manufaturado.
Processo de Desenvolvimento Eficiente = Software Eficiente
 À medida que os softwares crescem em tamanho e complexidade, abstração e complexidade conferem cada vez mais dificuldades ao processo de desenvolvimento.
		QUALIDADE → PADRONIZAÇÃO
	Hoje em dia, lidamos com softwares super complexos.
	Slide 4: Processo de Desenvolvimento de Software (PDS)
Conjunto de atividades, métodos, práticas e tecnologias que as pessoas usam para desenvolver e manter softwares.
- O processo adequado garante que o software será desenvolvido de maneira organizada, disciplinada e previsível.
O processo descreve formalmente e de forma organizada as atividades que devem ser seguidas. Para a obtenção segura de
um produto de software.
- A dificuldade está no gerenciamento do processo (existem vários modelos), que geralmente está dividido em fases.
Independente do processo utilizado num desenvolvimento de software, sempre existirão fases como CONCEPÇÃO, ANÁLISE, DESIGN, IMPLEMENTAÇÃO, TESTES E IMPLANTAÇÃO.
			→ pode ser junto numa única fase.
Slide 5: Processo de Desenvolvimento de Software
ANÁLISE: analista com usuários. 
Requisitos: Interesses → Soluções para usuário.
PROJETO (DESIGN): projetista usa a tecnologia.
Requisitos: Tecnológicos → Tecnologia para usuário.
IMPLEMENTAÇÃO: programados usa a Linguagem de Programação
Escrita do código → Lógica de programação.
TESTES: testadores com programas/sistema
Buscar defeitos e falhas no sistema.
HOMOLOGAÇÃO (OU ACEITAÇÃO): com usuários.
Usuário deve aprovar o sistema (deve participar de tudo).
IMPLANTAÇÃO: instalação e treinamento.
Entrega o sistema.
Fim do ciclo de desenvolvimento.
A fase de testes já se inicia na implementação e continua até o fim do processo de desenvolvimento. 
Na fase de homologação, o usuário deve testar o programa para verificar se atende as necessidades ( ao que foi pedido), é importante para que na implantação, onde seu produto “já entrou no mercado”, não haja reclamações sujando seu nome ou de sua empresa. 
Slide 6: Onde estão os defeitos?
A maior dificuldade está na fase inicial, de entendimento do sistema. Requisitos: Alto grau de abstração + Comunicação com pessoas.
A segunda maior abrangência está na modelagem. Requisitos: Alto grau de abstração + Domínio das técnicas.
Os erros de codificação em si, representam um percentual pequeno, mostrando que o foco do problema não é a implementação.
46% Requisitos
27% Modelagem
10% Outros
07% Código
	83% dos problemas estão na fase de modelagem e projetos.
	Slide 7: Software com Qualidade
O que é um software com Qualidade?
Atender aos requisitos dos usuários.
Satisfazer aos desejos* dos usuários.
Escrever tudo o que se deve fazer e fazer tudo que foi escrito.
O que é Qualidade de Software?
Processo sistemático que:
→ Focaliza todas as etapas e artefatos. (Modelos, diagramas, programas, módulos de software, classes, etc)
→ Com objetivo de garantir conformidade dos processos e produtos especificados. Prevenindo e eliminando defeitos.
* Vai além da necessidade, alem dos requisitos.
	Slide 8: Software com Qualidade
Qualidade de software é conformidade com:
Requisitos funcionais – base para medir qualidade
Requisitos de desempenho – critérios de desempenho definidos
Características implícitas (esperadas)
Fácil de usar (usuário)
Código legível, fácil de manter (equipe de desenvolvimento)
A qualidade do software depende da qualidade de seu processo de desenvolvimento.
Slide 9: Qualidade no Processo x Qualidade no Produto
A qualidade do produto é o que buscamos.
A qualidade do processo é o meio para conseguirmos.
A qualidade do produto é fortemente influenciada pela qualidade dos processos utilizados no seu desenvolvimento.
Slide 10: A qualidade é mais uma fase no processo de desenvolvimento de software?
No processo de desenvolvimento de software, a qualidade não atua como uma fase especifica, ela está em todas as fases.
						TESTE
	↓			↓		 ↓			↓			↓
CONCEPÇÃO	REQUISITOS		DESIGN	CODIFICAÇÃO	IMPLANTAÇÃO
Qualidade é atuar em todas as fases virificando conformidade com os padrões e definições.
Slide 11: As visões da qualidade
Usuário → Facilidade de uso, desempenho, confiabilidade dos resultados, preço do software, etc.
Desenvolvedor → Taxa de defeitos, facilidade de manutenção e conformidade em relação aos requisitos do usuário.
Organização → Cumprimento do prazo, boa previsão de custo, boa produtividade.
Slide 12: Gerenciamento da Qualidade (Sommerville)
Garantia → Padrões que garantam a qualidade do software.
Planejamento → Seleção de procedimentos e padrões adequados para o projeto.
Controle → Assegurar que o desenvolvimento tenha seguido os procedimentos e padrões de qualidade do projeto.
A documentação do software torna-se um instrumento fundamental para o controle da qualidade.
Slide 13: O custo com o processo de qualidade de paga?
Esforços (recursos) pela qualidade nos mais diversos setores organizacionais já provaram que:
a qualidade não tem custo
se paga em pouco tempo
Slide 14: Concluindo
O aumento da qualidade no processo acarreta:
→ garantia de estarmos fazendo o software certo
→ aumento na produtividade
→ redução de custos: menos retrabalho e menos perdas
→ menos prazo de entrega
Aumento na qualidade do produto acarreta:
→ reaproveitamento de código de programa
→ programas mais eficientes
→ menor custo e mais facilidade de manutenção
** É mais fácil fazer um software correto do que consertá-lo.**
REFLEXO GLOBAL: Maior satisfação dos clientes, refletindo em maior participação no mercado.
No ciclo de vida do sistema (criação até substituição), 70% é manutenção.
- No Brasil, o INMETRO é o órgão responsável pelo credenciamento e supervisão de organismos de certificação, organismos de inspeção e laboratórios de ensaios nas empresas.
Exercícios de fixação: 
1. No gerenciamento da qualidade de software, são esperadas algumas atividades. Quais são estas atividades?
 
I. Apenas garantia da qualidade
II. Garantia, controle, custo e planejamento da qualidade
III. Apenas controle e custo da qualidade
IV. Apenas planejamento da qualidade
Apenas garantia da qualidade e planejamento da qualidade
Resposta: II
2. Qualidade de Software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos. Existem diversas definições para qualidade de software e, numa visão simples, quais das definições a seguir estão corretas?
 
I. Qualidade é estar em conformidade com os requisitos dos clientes.
II. Qualidade é antecipar e satisfazer os desejos dos clientes.
III. Qualidade é postergar as mudanças em caso de problemas corriqueiros.
IV. Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito.
Resposta: I, II E IV
3. Na visão de Sommerville (2007), os padrões exigidos devem englobar boas práticas para que sejam gerados produtos de alta qualidade. Dessa forma, acredita que há muito mais gerenciamento de qualidade do que padrões e burocracia associada para assegurar que os padrões foram seguidos. A documentação de qualidade deve variar de acordo com o tamanho do software tendo como propósito a comunicação entre a equipe que participa do desenvolvimento do software. Sommerville (Engenharia de Software, 2007) diz ainda que o gerenciamento de qualidade está estruturado em três atividades principais. Quais são estas três atividades?
I. Garantia de qualidade - padrões que conduzem a um software de alta qualidade.
II. Planejamento de qualidade - seleção de procedimentos e padrões apropriados adaptados para um projeto de software específico.
III. Controle de qualidade - aprovação de processos que assegurem que o desenvolvimento de software tenha seguido corretamente os procedimentos e padrões de qualidade de projeto.
IV. Custo de qualidade - custos envolvidos na procura da qualidade
Resposta: I, II, E III
LISTA