ISO/IEC 15504

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Question book.svg
Esta página ou secção não cita fontes confiáveis e independentes, o que compromete sua credibilidade (desde fevereiro de 2014). Por favor, adicione referências e insira-as corretamente no texto ou no rodapé. Conteúdo sem fontes poderá 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.

A norma ISO/IEC 15504, também conhecida como SPICE (Software Process Improvement and Capability Determination), define processo de desenvolvimento de software. É uma evolução da ISO/IEC 12207, mas possui níveis de capacidade para cada processo assim como o CMMI.

Histórico Projeto SPICE[editar | editar código-fonte]

  • Janeiro de 1992: estudo da ISO sobre as necessidades e os requisitos de um padrão internacional para avaliação de processos de SW;
  • 1993-1994: criação do projeto SPICE e elaboração da versão inicial;
  • 1995: realização de trials - Fase 1 (35 avaliações);
  • 1996: versão PDTR (Previous Draft Technical Report);
  • 1997: versão DTR, Trials - Fase 2 (70 avaliações);
  • 1998: versão TR2, Início dos Trials - Fase 3;
  • 1999-out/2003: transformação em Norma ISO/IEC 15504.

Sobre a Norma ISO/IEC 15504[editar | editar código-fonte]

Em outubro de 2003, a norma ISO/IEC 15504 para a avaliação de processos de software foi oficialmente publicada pela ISO. Ela define um modelo bi-dimensional que tem por objetivo a realização de avaliações de processos de software com o foco da melhoria dos processos (gerando um perfil dos processos, identificando os pontos fracos e fortes, que serão utilizados para a elaboração de um plano de melhorias) e a determinação da capacidade dos processos, viabilizando a avaliação de um fornecedor em potencial.

Esta norma está sendo desenvolvida desde 1993 pela ISO em conjunto com a comunidade internacional através do projeto SPICE com base nos modelos já existentes como ISO 9000 e CMM.

Segundo a norma, uma avaliação de processo de software é uma investigação e análise disciplinada de processos selecionados de uma unidade organizacional em relação a um modelo de avaliação de processo.

A ISO/IEC 15504 define um modelo de referência de processo que identifica e descreve um conjunto de processos considerados universais e fundamentais para a boa prática da Engenharia de Software, e define seis níveis de capacidade, sequenciais e cumulativos, que podem ser utilizados tanto como métrica para avaliar como uma organização está realizando um determinado processo, quanto um guia para a melhoria.

A norma define também um guia para a 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. Este guia sugere 8 etapas sequenciais, que inicia com a identificação de estímulos para a melhoria e o exame das necessidades da organização.

Em seguida existem ciclos de melhoria, nos quais um conjunto de melhoria são identificadas, uma avaliação das práticas correntes em relação à melhoria é realizada, um planejamento da melhoria é feito, seguido pela implementação, confirmação, manutenção e acompanhamento da melhoria.

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

O SPICE inclui um modelo de referência, que serve de base para o processo de avaliação. Este modelo define duas dimensões:

  • Dimensão de Processo: corresponde à definição de um conjunto de processos considerados universais e fundamentais para a boa prática da engenharia de software; Atualmente, um modelo de referência de processo no domínio de software é a ISO 12207;
  • Dimensão de Capacidade: um modelo de avaliação, baseado na ISO 12207, é o definido na ISO 15504; Neste último, os processos são agrupados em cinco grandes categorias de processo:
    • Cliente-Fornecedor;
    • Engenharia;
    • Suporte;
    • Gerência;
    • Organização.

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.

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.