ISO/IEC 15504: diferenças entre revisões
Aspeto
Conteúdo apagado Conteúdo adicionado
m A migrar 11 interwikis, agora providenciados por Wikidata em d:q1196809 |
texto trocado por 'Eita \o' Etiqueta: Remoção considerável de conteúdo |
||
Linha 1: | Linha 1: | ||
Eita \o |
|||
A ISO/IEC 15504, também conhecida como '''SPICE''', é a norma [[Organização Internacional para Padronização|ISO]]/[[Comissão Eletrotécnica Internacional|IEC]] que define '''processo de desenvolvimento de software'''. Ela é uma evolução da [[ISO/IEC 12207]] mas possui níveis de capacidade para cada processo assim como o '''[[CMMI]]'''. |
|||
== Histórico Projeto SPICE == |
|||
IMPORTANTE: A NORMA ISO/IEC 15504 AINDA NÃO PASSOU POR NENHUMA REVISÃO. |
|||
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; 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-2003: Transformação em Norma ISO/IEC 15504. |
|||
Em outubro de 2003, a Norma ISO/IEC 15504 (SPICE) para a avaliação de processos de software foi oficialmente publicada pela ISO |
|||
== Sobre a Norma ISO/IEC 15504 == |
|||
A ISO/IEC 15504, também conhecida como '''SPICE''', é a norma [[Organização Internacional para Padronização|ISO]]/[[Comissão Eletrotécnica Internacional|IEC]] que define '''processo de desenvolvimento de software'''. Ela é uma evolução da [[ISO/IEC 12207]] mas possui níveis de capacidade para cada processo assim como o '''CMMI'''. |
|||
Em outubro de 2003, a Norma ISO/IEC 15504 para a avaliação de processos de software foi oficialmente publicada pela ISO. A Norma ISO/IEC 15504 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 (Software Process Improvement and Capability Determination) 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, seqüenciais e cumulativos que podem ser utilizados como uma métrica para avaliar como uma organização está realizando um determinado processo e também podem ser utilizados como um guia para a melhoria. |
|||
A ISO/IEC 15504 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 seqüenciais, 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 == |
|||
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 == |
|||
=== SUP.1: Documentação === |
|||
* 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 === |
|||
* 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 === |
|||
* 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 === |
|||
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 peer reviews, provas formais e análise de rastreabilidade. |
|||
=== SUP.5 – Validação === |
|||
* 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 === |
|||
* 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 pré-estabelecidas 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 === |
|||
* 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 === |
|||
* 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. |
|||
{{Engenharia de software}} |
|||
{{mínimo}} |
|||
{{DEFAULTSORT:Iso/Iec 15504}} |
|||
[[Categoria:Normas ISO]] |
Revisão das 17h49min de 8 de maio de 2013
Eita \o