SlideShare uma empresa Scribd logo
1 de 10
Baixar para ler offline
Norma ISO/IEC 12207
Aluno: Leonardo Teles de Almeida
Disciplina: Qualidade de Software
Professor: Silvio Sergio Strauss Varques
Introdução
A norma ISO/IEC 12207 estabelece uma arquitetura de alto nível
do ciclo de vida de software que é construída a partir de um
conjunto de processos e seus inter-relacionamentos. Os
processos são descritos tanto em nível de propósito/saídas
como em termos de atividades.
O que é um processo?
Um processo é uma seqüência de passos realizados para um
determinado propósito [IEEE 610.12, 1690]; o processo de software
envolve métodos, técnicas, ferramentas e pessoas.
– A descrição por propósito ou resultado é utilizada quando não há necessidade de
detalhar o processo, apenas indicar o objetivo e o resultado.
– A descrição por atividade é a abordagem mais conhecida e intuitiva. Nela são
descritas as atividades com as inter-relações e o algoritmo de execução de cada
atividade. As atividades devem atingir o propósito do processo.
Estrutura da Norma
Os processos na ISO/IEC 12207 são de responsabilidade de uma organização,
mas não são exclusivos desta, ou seja, uma organização pode executar um ou
mais processos e um processo pode ser executado por uma ou mais
organizações. Neste caso, uma das organizações será a responsável pelo
processo total, mesmo que tarefas individuais sejam realizadas por pessoas
diferentes. Os processos são agrupados, por uma questão de organização, de
acordo com a sua natureza, ou seja, o seu objetivo principal no ciclo de vida de
software. Esse agrupamento resultou em 4 diferentes classes de processos,
que são:
– Processos fundamentais;
– Processos de apoio;
– Processos organizacionais;
– Processos de adaptação.
Estrutura da Norma(continuação)
Algumas características
A ISO/IEC 12207 não possui nenhuma ligação com métodos, ferramentas,
treinamentos, métricas ou tecnologias empregadas. Ela pode ser utilizada com
qualquer modelo de ciclo de vida, método ou técnica de engenharia de
software e linguagem de programação.
Sua flexibilidade é uma característica importante, pois as atividades e tarefas do
processo de ciclo de vida do software especificam "o que fazer" e não "como
fazer "
Ela também é aplicável a qualquer setor de atividade (aeroespacial, equipamentos
médicos, telecomunicações, comercial, militar, etc.) ou a qualquer cultura
nacional ou organizacional.
O âmbito da norma inclui vários tipos de software: novo, reutilização de software já
existente com algumas alterações, software embebido, "firmware" mas não
inclui produtos comerciais "off-the-shelf" como por exemplo, processadores de
texto, folhas de cálculo ou jogos.
A norma estabelece uma arquitetura de alto nível para o ciclo de vida do
software que abrange desde a concepção até a descontinuidade do
mesmo. Essa arquitetura é baseada em processos chave e no inter-
relacionamento entre eles e segue dois princípios básicos:
- Modularidade: Os processos têm alta coesão e baixo acoplamento, ou seja, todas as
partes de um processo são fortemente relacionadas e o número de interfaces entre os
processos é mantido ao mínimo.
- Responsabilidade: Cada processo na norma é de responsabilidade de uma “Parte
envolvida”, que pode ser uma organização ou parte dela. As partes envolvidas podem ser
da mesma organização ou de organizações diferentes.
Os processos da ISO/IEC 12207 são modulares, ou seja, são fortemente
coesos e fracamente acoplados. Isto significa que todas as partes de
um processo são fortemente relacionadas, mas a quantidade de
interfaces entre os processos é mínima.
As regras listadas a seguir 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 esta 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
CONCLUSÃO
Todas as normas e modelos de qualidade para software têm por objetivo
buscar organização e melhoria continua no processo de
desenvolvimento de software. Com os processos de desenvolvimento
de software controlados, documentados e gerenciados o
desenvolvedor poderá assumir projetos de alta complexidade, aliados
a técnica e criatividade, pois terá mais chance de sucesso. Melhor
capacitado e provedor de metodologias que levam ao
desenvolvimento de software com qualidade, o desenvolvedor poderá
criar soluções que atendam as necessidades e os requisitos da
empresa, contribuindo para criação de vantagens competitivas,
sustentando as bases estratégicas das organizações.
Referências
http://pt.wikipedia.org/wiki/ISO/IEC_12207
http://www.reocities.com/ResearchTriangle/Node/8639/ISO12207.html
http://paulo-bezerra.com/blog/wp-content/uploads/2012/09/ISO-12207-Artigo.pdf
http://www.itpac.br/hotsite/revista/artigos/44/5.pdf

Mais conteúdo relacionado

Semelhante a idoc.pub_iso-iec-12207.pdf

Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trataRoni Reis
 
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdfa29398
 
Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?Priscilla Aguiar
 
Aula_4_e_5_-_RUP_Rapid_Unified_Process_Software_Engineering
Aula_4_e_5_-_RUP_Rapid_Unified_Process_Software_EngineeringAula_4_e_5_-_RUP_Rapid_Unified_Process_Software_Engineering
Aula_4_e_5_-_RUP_Rapid_Unified_Process_Software_Engineeringbaitolakaike
 
Processos de software
Processos de softwareProcessos de software
Processos de softwareDann Volpato
 
O Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de SoftwareO Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de SoftwareCamilo de Melo
 
Trabalho qualidade de_software
Trabalho qualidade de_softwareTrabalho qualidade de_software
Trabalho qualidade de_softwarestefaniak2004
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de softwareFelipe Bugov
 
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdfPDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdfpedrina4
 
Resumo capítulo 1 livro Engenharia de Software Moderna
Resumo capítulo 1 livro Engenharia de Software ModernaResumo capítulo 1 livro Engenharia de Software Moderna
Resumo capítulo 1 livro Engenharia de Software ModernaLucasBastos305659
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascatawilsonguns
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREKéllyson Gonçalves da Silva
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosJosé Vieira
 

Semelhante a idoc.pub_iso-iec-12207.pdf (20)

Aula2 processos sw
Aula2 processos swAula2 processos sw
Aula2 processos sw
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?
 
Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2
 
Aula_4_e_5_-_RUP_Rapid_Unified_Process_Software_Engineering
Aula_4_e_5_-_RUP_Rapid_Unified_Process_Software_EngineeringAula_4_e_5_-_RUP_Rapid_Unified_Process_Software_Engineering
Aula_4_e_5_-_RUP_Rapid_Unified_Process_Software_Engineering
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
O Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de SoftwareO Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de Software
 
Trabalho qualidade de_software
Trabalho qualidade de_softwareTrabalho qualidade de_software
Trabalho qualidade de_software
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de software
 
iso
isoiso
iso
 
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdfPDSI.INT- S01 Introdução a Eng Software e Processo.pdf
PDSI.INT- S01 Introdução a Eng Software e Processo.pdf
 
Resumo capítulo 1 livro Engenharia de Software Moderna
Resumo capítulo 1 livro Engenharia de Software ModernaResumo capítulo 1 livro Engenharia de Software Moderna
Resumo capítulo 1 livro Engenharia de Software Moderna
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
 
Modelo cascata
Modelo cascataModelo cascata
Modelo cascata
 
4 usabilidade - y
4   usabilidade - y4   usabilidade - y
4 usabilidade - y
 
Os aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de RequisitosOs aspectos mais relevantes da Engenharia de Requisitos
Os aspectos mais relevantes da Engenharia de Requisitos
 

idoc.pub_iso-iec-12207.pdf

  • 1. Norma ISO/IEC 12207 Aluno: Leonardo Teles de Almeida Disciplina: Qualidade de Software Professor: Silvio Sergio Strauss Varques
  • 2. Introdução A norma ISO/IEC 12207 estabelece uma arquitetura de alto nível do ciclo de vida de software que é construída a partir de um conjunto de processos e seus inter-relacionamentos. Os processos são descritos tanto em nível de propósito/saídas como em termos de atividades.
  • 3. O que é um processo? Um processo é uma seqüência de passos realizados para um determinado propósito [IEEE 610.12, 1690]; o processo de software envolve métodos, técnicas, ferramentas e pessoas. – A descrição por propósito ou resultado é utilizada quando não há necessidade de detalhar o processo, apenas indicar o objetivo e o resultado. – A descrição por atividade é a abordagem mais conhecida e intuitiva. Nela são descritas as atividades com as inter-relações e o algoritmo de execução de cada atividade. As atividades devem atingir o propósito do processo.
  • 4. Estrutura da Norma Os processos na ISO/IEC 12207 são de responsabilidade de uma organização, mas não são exclusivos desta, ou seja, uma organização pode executar um ou mais processos e um processo pode ser executado por uma ou mais organizações. Neste caso, uma das organizações será a responsável pelo processo total, mesmo que tarefas individuais sejam realizadas por pessoas diferentes. Os processos são agrupados, por uma questão de organização, de acordo com a sua natureza, ou seja, o seu objetivo principal no ciclo de vida de software. Esse agrupamento resultou em 4 diferentes classes de processos, que são: – Processos fundamentais; – Processos de apoio; – Processos organizacionais; – Processos de adaptação.
  • 6. Algumas características A ISO/IEC 12207 não possui nenhuma ligação com métodos, ferramentas, treinamentos, métricas ou tecnologias empregadas. Ela pode ser utilizada com qualquer modelo de ciclo de vida, método ou técnica de engenharia de software e linguagem de programação. Sua flexibilidade é uma característica importante, pois as atividades e tarefas do processo de ciclo de vida do software especificam "o que fazer" e não "como fazer " Ela também é aplicável a qualquer setor de atividade (aeroespacial, equipamentos médicos, telecomunicações, comercial, militar, etc.) ou a qualquer cultura nacional ou organizacional. O âmbito da norma inclui vários tipos de software: novo, reutilização de software já existente com algumas alterações, software embebido, "firmware" mas não inclui produtos comerciais "off-the-shelf" como por exemplo, processadores de texto, folhas de cálculo ou jogos.
  • 7. A norma estabelece uma arquitetura de alto nível para o ciclo de vida do software que abrange desde a concepção até a descontinuidade do mesmo. Essa arquitetura é baseada em processos chave e no inter- relacionamento entre eles e segue dois princípios básicos: - Modularidade: Os processos têm alta coesão e baixo acoplamento, ou seja, todas as partes de um processo são fortemente relacionadas e o número de interfaces entre os processos é mantido ao mínimo. - Responsabilidade: Cada processo na norma é de responsabilidade de uma “Parte envolvida”, que pode ser uma organização ou parte dela. As partes envolvidas podem ser da mesma organização ou de organizações diferentes. Os processos da ISO/IEC 12207 são modulares, ou seja, são fortemente coesos e fracamente acoplados. Isto significa que todas as partes de um processo são fortemente relacionadas, mas a quantidade de interfaces entre os processos é mínima.
  • 8. As regras listadas a seguir 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 esta 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
  • 9. CONCLUSÃO Todas as normas e modelos de qualidade para software têm por objetivo buscar organização e melhoria continua no processo de desenvolvimento de software. Com os processos de desenvolvimento de software controlados, documentados e gerenciados o desenvolvedor poderá assumir projetos de alta complexidade, aliados a técnica e criatividade, pois terá mais chance de sucesso. Melhor capacitado e provedor de metodologias que levam ao desenvolvimento de software com qualidade, o desenvolvedor poderá criar soluções que atendam as necessidades e os requisitos da empresa, contribuindo para criação de vantagens competitivas, sustentando as bases estratégicas das organizações.