ISO/IEC 15504

Origem: Wikipédia, a enciclopédia livre.
(Redirecionado de ISO 15504)
Saltar para a navegação Saltar para a pesquisa
Question book.svg
Este artigo ou secção não cita fontes confiáveis e independentes (desde fevereiro de 2014). Ajude a inserir referências.
O conteúdo não verificável pode ser removido.—Encontre fontes: Google (notícias, livros e acadêmico)
Wikitext.svg
Esta página ou seção precisa ser wikificada (desde fevereiro de 2014).
Por favor ajude a formatar esta página de acordo com as diretrizes estabelecidas.

ISO / IEC 15504, também conhecida como Spice, é um modelo que possui como foco a melhoria dos processos de desenvolvimento de software e a determinação da capacidade de processos de uma organização [1]. Além dos processos, a SPICE define também os seis níveis de capacitação de cada processo (Executado, gerenciado, estabelecido, previsível e otimizado)[2].

História[editar | editar código-fonte]

O início da norma 15504 remonta ao ano de 1991, quando o JTCI iniciou um estudo sobre a necessidade de uma norma para avaliação de processo de software. Em 1993, teve início o projeto SPICE(Software Process Improvement and Capability Determination), com três objetivos básicos: auxiliar o inicio do projeto de norma, executar testes de campo, para obter dados de experiências praticas e despertar o mercado para o surgimento da futura norma.[3]

A envergadura do projeto SPICE acabou associando definitivamente o acrônimo à norma ISO/IEC 15504. Esse projeto foi oficialmente encerrado em março de 2003, sendo substituído pelo SPICE Network.[3]


Atualmente a norma ISO 15504 representa um padrão internacional que estabelece um Framework para construção de processos de avaliação e melhoria do processo de software.[4]

O Projeto[editar | editar código-fonte]

A norma ISO/IEC 15504 propõe uma estrutura para realização de avaliações de processos em organizações. A mesma pode ser aplicada em empresas que buscam uma melhoria e performasse interna ou terceiros que utilizam a prestação de serviços e fornecimento de produtos.[5]

Se o objetivo for a melhoria de processos, a organização pode realizar a avaliação gerando um perfil dos processos que será usado para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a empresa tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu perfil de capacidade. [5]

O perfil de capacidade permite ao contratante estimar o risco associado à contratação daquele fornecedor em potencial para auxiliar na tomada de decisão de contratá-lo ou não.[5]

A norma visa ainda orientar a organização para uma melhoria contínua do processo. Ela cobre todos os aspectos da Qualidade do Processo de Software e está sendo elaborada num esforço conjunto de cinco centros técnicos espalhados pelo mundo: EUA, Canadá/América Latina, Europa, Pacífico Norte e Pacífico Sul.[6]

                                   

Modelo de referência SPICE[editar | editar código-fonte]

O SPICE presta-se à realização de avaliações de processos de software com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de uma organização. Se o objetivo for a melhoria de processos, a organização pode realizar a avaliação gerando um perfil dos processos que será usado para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos.[7]

O SPICE inclui um modelo de referência, que serve de base para o processo de avaliação. Este modelo é um conjunto padronizado de processos fundamentais, que orientam para uma boa engenharia de software. Este modelo é dividido em cinco grandes categorias de processo: Cliente-Fornecedor, Engenharia, Suporte, Gerência e Organização. Cada uma destas categorias é detalhada em processos mais específicos. Tudo isso é descrito em detalhes pela norma ISO/IEC 15504.[5]

Processos[editar | editar código-fonte]

A dimensão do processo define os processos divididos em cinco categorias[4]:

·        Fornecedor do cliente

·        Engenharia

·        Suporte

·        Gestão

·        Organização


Com as novas partes sendo publicadas, as categorias de processo serão expandidas, principalmente para categorias de processo de serviços de TI e categorias de processos corporativos.

Níveis de capacidade e atributos do processo[editar | editar código-fonte]

Para cada processo, o ISO / IEC 15504 define um nível de capacidade na seguinte escala: [8]


Rating scale of process atributes[editar | editar código-fonte]

Cada atributo do processo é avaliado em uma escala de classificação de quatro pontos (NPLF):

·        Não atingido (0 - 15%)

·        Parcialmente atingido (> 15% - 50%)

·        Em grande parte alcançado (> 50% - 85%)

·        Totalmente alcançado (> 85% - 100%).


A classificação é baseada em evidências coletadas contra os indicadores da prática, que demonstram o cumprimento do atributo do processo.[9]

Processo de Avaliação[editar | editar código-fonte]

Realizar avaliações é o assunto das partes 2 e 3 da ISO / IEC 15504.[10] A parte 2 é a parte normativa e a parte 3 fornece uma orientação para atender aos requisitos da parte 2.

Um dos requisitos é usar um método de avaliação em conformidade para o processo de avaliação. O método real não é especificado no padrão, embora o padrão insira requisitos no método, desenvolvedores de métodos e avaliadores usando o método.[11] A norma fornece orientação geral aos avaliadores e isso deve ser complementado por treinamento formal e orientação detalhada durante as avaliações iniciais.[11]

O processo de avaliação pode ser generalizado conforme as etapas a seguir:

·        iniciar uma avaliação (patrocinador da avaliação)

·        selecionar assessor e equipe de avaliação

·        planejar a avaliação, incluindo os processos e a unidade organizacional a ser avaliada (assessor principal e equipe de avaliação)

·        briefing de pré-avaliação

·        coleção de dados

·        data de validade

·        avaliação de processo

·        reportando o resultado da avaliação


Um avaliador pode coletar dados sobre um processo por vários meios, incluindo entrevistas com pessoas que executam o processo, coleta de documentos e registros de qualidade e coleta de dados estatísticos do processo. O avaliador valida esses dados para garantir que seja preciso e cobre completamente o escopo da avaliação. O avaliador avalia esses dados (usando sua opinião especializada) com base nas práticas de base de um processo e as práticas genéricas da dimensão de capacidade na etapa de classificação do processo. A classificação do processo requer algum exercício de julgamento especializado por parte do avaliador e esta é a razão pela qual há requisitos sobre as qualificações e competência do avaliador. A classificação do processo é então apresentada como uma descoberta preliminar para o patrocinador (e preferencialmente também para as pessoas avaliadas) para garantir que eles concordem que a avaliação é precisa.[12]

Modelo de Avaliação[editar | editar código-fonte]

O modelo de avaliação de processos (PAM) é o modelo detalhado usado para uma avaliação real. Esta é uma elaboração do modelo de referência de processo (PRM) fornecido pelos padrões de ciclo de vida do processo.[13]

O modelo de avaliação de processo (PAM) na parte 5 é baseado no modelo de referência de processo (PRM) do software: ISO / IEC 12207.[14]

O modelo de avaliação de processo na parte 6 é baseado no modelo de referência de processo para sistemas: ISO / IEC 15288.[9]

A norma permite que outros modelos sejam usados, caso atendam aos critérios da ISO / IEC 15504, que incluem uma comunidade de interesse definida e atendem aos requisitos de conteúdo (ou seja, propósito do processo, resultados do processo e indicadores de avaliação).[9]

Ferramentas usadas na avaliação[editar | editar código-fonte]

Existem várias ferramentas de avaliação. O mais simples compreende ferramentas baseadas em papel. Em geral, eles são definidos para incorporar os indicadores do modelo de avaliação, incluindo os indicadores de práticas básicas e os indicadores de práticas genéricas. Os avaliadores anotam os resultados da avaliação e as notas que apoiam o julgamento da avaliação.[15]

Há um número limitado de ferramentas baseadas em computador que apresentam os indicadores e permitem que os usuários insiram o julgamento de avaliação e anotações em telas formatadas, além de automatizar o resultado da avaliação intercalada (ou seja, as classificações de atributo do processo) e criar relatórios.[15]

Suporte[editar | editar código-fonte]

SUP.1: Documentação[editar | editar código-fonte]

Objetivo: desenvolver e manter documentos que registrem informações produzidas por um outro processo ou atividade.

Envolve a produção, controle, manutenção, revisão, aprovação e publicação de documentos e seu acesso.

SUP.2: Gestão de configuração[editar | editar código-fonte]

Objetivo: estabelecer e manter a integridade de todos os produtos de trabalho de algum processo ou do projeto.

Envolve a definição de uma estratégia de gestão de configuração, a identificação de itens de configuração, o controle de acesso e de mudanças de itens, o registro da situação de todos os itens e o seu armazenamento e manuseio de forma controlada.

SUP.3: Garantia de qualidade[editar | editar código-fonte]

Objetivo: assegurar que os produtos de trabalho e atividades de um processo ou projeto estão de acordo com os requisitos especificados e satisfazem aos planos e regras estabelecidas.

Devem ser estabelecidos os procedimentos para o tratamento de desvios a não-conformidades com relação a regras, procedimentos e padrões.

Deve ser coordenada com os processos de verificação, validação, revisão conjunta, auditoria e resolução de problemas.

As pessoas responsáveis pela garantia da qualidade devem ter autonomia organizacional e autoridade para realizarem as suas tarefas sem interferências dos responsáveis pelo desenvolvimento do software.

SUP.4: Verificação[editar | editar código-fonte]

Objetivo: confirmar que cada produto de trabalho ou serviço resultado de um processo reflete corretamente às especificações de entrada do processo.

Envolve a definição de uma estratégia de verificação, de critérios de verificação para todos os produtos de trabalho e para as atividades de verificação.

Deve assegurar que os defeitos encontrados serão removidos dos produtos de trabalho e que os resultados serão disponibilizados para os clientes

Normalmente envolve a realização de testes e está relacionado aos processos ENG.1.6 e ENG.1.7.

Pode também fazer uso de técnicas como revisão em pares (peer reviews), provas formais e análise de rastreabilidade.

SUP.5: Validação[editar | editar código-fonte]

Objetivo: confirmar que estão satisfeitos os requisitos para o uso pretendido de cada produto de trabalho ou serviço resultado de um processo.

Envolve a definição de uma estratégia de validação, de critérios de validação para todos os produtos de trabalho e para as atividades de validação.

Deve assegurar que os problemas encontrados serão resolvidos, que os resultados serão disponibilizados para os clientes e para outras organizações internas e que os produtos são adequados para o uso pretendido.

Normalmente está relacionado ao processo de teste de integração e teste de software ENG.1.7.

SUP.6: Revisão Conjunta[editar | editar código-fonte]

Objetivo: permitir ao cliente a visibilidade do andamento do desenvolvimento quando comparado ao especificado no contrato.

As revisões formais dever tratar, ao longo de todo o ciclo de vida de desenvolvimento, tanto dos aspectos técnicos quanto administrativos.

Envolve: revisões periódicas em datas preestabelecidas da situação de produtos e atividades por todas as partes interessadas, da solução de todas as pendências, problemas e desvios encontrados.

SUP.7: Auditoria[editar | editar código-fonte]

Objetivo: determinar, de forma independente, a conformidade de produtos identificados e atividades com planos, requisitos e com o contrato.

Deve ser definida a estratégia de programação da auditoria, especificando quais itens serão auditados contra quais regras.

A auditoria deve ser conduzida por pessoal independente àquele que executa o desenvolvimento e os problemas encontrados deverão ser comunicados aos responsáveis para a devida ação corretiva.

SUP.8: Resolução de Problemas[editar | editar código-fonte]

Objetivo: assegurar que todos os problemas encontrados sejam analisados, resolvidos (ação corretiva) e que tendências sejam observadas visando o planejamento e execução de ações preventivas.

Referência[editar | editar código-fonte]

  1. «E5I19 – PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DE ACORDO COM A NORMA ISO/IEC 15504 | Pós em Revista». Consultado em 11 de junho de 2019 
  2. REZENDE, DENIS (2012). Engenharia de software e sistemas de informação. [S.l.]: BRASPORT 
  3. a b KOSCIANSKI, ANDRÉ (2007). Qualidade de Software – 2 edição. [S.l.]: NOVATEC EDITORA 
  4. a b VASCONCELOS, ROUILLER, MACHADO, MEDEIROS, Marcos,Ana, Cristina, Tereza. Introdução à engenharia de software e à qualidade de software. [S.l.: s.n.] 
  5. a b c d Salviano (2001). Qualidade de Software: Teoria e Prática. São Paulo: [s.n.] 
  6. IAHN, Anísio (1999). .Avaliação de processos de software utilizando a norma ISO/IEC 15504. [S.l.: s.n.] 
  7. A. Oliveira, Luiz Carlos (14052019). «Modelo de Referência para Melhoria de Processo de Software: uma abordagem brasileira» (PDF). Joao. Consultado em 14052019  line feed character character in |titulo= at position 47 (ajuda); Verifique data em: |acessodata=, |data= (ajuda)
  8. ISO / IEC 15504-2 Cláusula 5. [S.l.: s.n.] 
  9. a b c ISO / IEC TR 15504-6. [S.l.: s.n.] 
  10. ISO / IEC PDTR 15504-8. [S.l.: s.n.] 
  11. a b ISO / IEC TS 15504-9. [S.l.: s.n.] 
  12. ISO / IEC TS 15504-10. [S.l.: s.n.] 
  13. ISO 15504-2 Clause 6.2. [S.l.: s.n.] 
  14. ISO/IEC 15504-2 Clause 6.3 and ISO/IEC 15504-5. [S.l.: s.n.] 
  15. a b «ISO/IEC 15504». Wikipedia (em inglês). 1 de abril de 2019 
Wiki letter w.svg Este artigo é um esboço. Você pode ajudar a Wikipédia expandindo-o. Editor: considere marcar com um esboço mais específico.