Saltar para o conteúdo

ISO/IEC 12207

Origem: Wikipédia, a enciclopédia livre.
(Redirecionado de ISO 12207)

A ISO/IEC 12207 é a norma ISO/IEC que define processo de Engenharia de Software, atividades e tarefas que são associados com os processos do ciclo de vida do software desde sua concepção até a retirada/descontinuação do software.[1]

A norma internacional ISO/IEC 12207 tem como objetivo principal estabelecer uma estrutura comum para os processos de ciclo de vida e de desenvolvimento de softwares visando ajudar as organizações a compreenderem todos os componentes presentes na aquisição, desenvolvimento e fornecimento de software e, assim, conseguirem firmar contratos e executarem projetos de forma mais eficaz.[2][3] Para isso é necessário que compradores, fornecedores, desenvolvedores, mantenedores, operadores, gerentes e técnicos envolvidos no desenvolvimento de software usem uma linguagem/framework comum.

Visa ser o padrão que define as tarefas necessárias para o desenvolvimento e manutenção de software.

O padrão ISO/IEC 12207 define ao todo 25 processos, 95 atividades e 325 tarefas.

Uma tarefa é uma ação com entradas e saídas. Pode ser um requisito (deve, shall), recomendação (deveria, should) ou permissão (pode, may).

Uma atividade é um conjunto de tarefas.

Um processo é um conjunto de atividades relacionadas. É uma sequência de passos realizados para um determinado propósito/resultado [IEEE 610.12, 1690]; o processo de software envolve métodos, técnicas, ferramentas e pessoas. Um processo pode ser descrito de duas formas: por propósito ou resultado e por atividade.

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. Essa abordagem poderá ser utilizada na avaliação do processo em relação aos modelos de maturidade de software como, por exemplo, o modelo CMMI e o modelo da ISO/IEC 15504.

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. Para isso deve adotar as premissas:

  • Que procedimentos e métodos serão usados para a execução das atividades;
  • Que ferramentas e equipamentos suportarão a realização das atividades, de forma a simplificar e automatizar o trabalho;
  • Qual o perfil adequado de quem irá executar as atividades e qual o treinamento requerido nos procedimentos, métodos, ferramentas para que se possam realizar as atividades de forma adequada;
  • Quais as métricas de processo que poderão ser empregadas para que a execução do processo possa ter a qualidade avaliada.

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.

A ISO/IEC 12207 não possui nenhuma ligação com métodos, ferramentas, treinamentos, métricas ou tecnologias empregadas. Esta determinação é útil para permitir que a norma seja utilizada mundialmente e possa acompanhar a evolução da Engenharia de Software nas diversas culturas organizacionais. 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, as atividades e tarefas do processo de ciclo de vida do software especificam "o que fazer" e não "como fazer".

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 fundamentais para identificação, escopo e estruturação dos processos.

  • 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.

Os processos, atividades e tarefas da ISO/IEC 12207 foram projetados para serem adaptados de acordo com cada projeto de software. Essa adaptação consiste no mapeamento de processos/atividades/tarefas relevantes/adequados ao projeto e, ao mesmo tempo, à supressão de processos/atividades/tarefas não aplicáveis.

Os processos são agrupados/categorizados, 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;
  • Processo de apoio;
  • Processos organizacionais;
  • Processos de adaptação.

Processos Fundamentais

[editar | editar código-fonte]

Os processos fundamentais são necessários para que um software seja executado. Eles iniciam o ciclo de vida e comandam outros processos. São eles:

  • Aquisição: obter o produto e/ou serviço que satisfaça suas necessidades;
  • Fornecimento: prover um produto e/ou serviço;
  • Desenvolvimento: transformar um conjunto de requisitos em um produto ou sistema de software;
  • Operação: operar o produto no seu ambiente e prover suporte aos usuários;
  • Manutenção: modificar o produto de software e depois liberá-lo para uso.

Processos de Apoio

[editar | editar código-fonte]

Os processos de apoio auxiliam outros processos. Eles são usados para garantir a qualidade, mas não são fundamentais. São eles:

  • Documentação: prover e manter registros de informações do software;
  • Gerência de Configuração: estabelecer e manter a integridade de todos os produtos de trabalho (artefato) de um processo do projeto;
  • Garantia da Qualidade: prover garantia de que os produtos e processos estão em conformidade com o requisitos (padrões/normas) pré-definidos;
  • Verificação: confirmar que os produtos e/ou serviços refletem os requisitos especificados;
  • Validação: confirmar que os requisitos para o uso específico de um produto e/ou serviço são atendidos;
  • Revisão Conjunta: manter o entendimento (gerencial comum com os stakeholders);
  • Auditoria: determinar independentemente a conformidade dos produtos e processos contra os requisitos definidos;
  • Resolução de Problema: assegurar que todos os problemas levantados sejam analisados e resolvidos;
  • Usabilidade: aumentar a facilidade do uso dos produtos e/ou serviços;
  • Gerência de Solicitação de Mudanças: Prover e manter processos de gerencia de mudanças;
  • Avaliação do Produto: garantir, através de exame e medição sistemáticos, que o produto e/ou serviços atende às necessidades especificadas (explícitas) e implícitas dos usuários.

Processos Organizacionais

[editar | editar código-fonte]

Os processos organizacionais auxiliam a organização e gerência geral dos processos e podem ser empregados fora do domínio de projetos e contratos específicos, servindo para toda a organização. São eles:

  • Gerência: organizar, monitorar e controlar a iniciação e o desempenho dos processos;
  • Infraestrutura: manter uma infraestrutura estável e confiável;
  • Melhoria: estabelecer, avaliar, controlar e melhorar um processo de ciclo de vida de software;
  • Recursos Humanos: prover e manter recursos humanos adequados mantendo as suas capacitações consistentes com o negócio.

Processos de Reúso de Software

[editar | editar código-fonte]

São os processos específicos no desenvolvimento de software, processos estes da atualização da ISO/IEC 12207 - 2008.

  • Gestão de Ativos: gerenciar a vida dos ativos (reusáveis) desde a concepção até a desativação;
  • Gestão de Programa de Reúso: planejar, estabelecer, controlar, monitorar os programas de reúso;
  • Engenharia de Domínio: desenvolver e manter modelos, arquiteturas e ativos deste domínio.

Processos de Adaptação

[editar | editar código-fonte]

Definem as atividades básicas necessárias para executar as adaptações.

Os processos são adaptáveis a:

  • Projeto;
  • Organização;
  • Cultura;
  • Modelo de ciclo de vida, métodos e técnicas, e linguagens.

Atividades do Desenvolvimento

[editar | editar código-fonte]

Algumas atividades importantes para o desenvolvimento de software serão descritas a seguir. São elas:

  • Elicitação de requisitos;
  • Análise dos requisitos do software;
  • Projeto da arquitetura do software;
  • Projeto detalhado do software;
  • Implementação;
  • Codificação e testes do software;
  • Integração do software;
  • Teste de qualificação do software;
  • Instalação do software;
  • Testagem e aprovação do software.

Elas foram descritas com base na norma ISO/IEC 12207.

Elicitação dos requisitos

[editar | editar código-fonte]

A elicitação dos requisitos consiste em entender os requisitos e solicitações do sistema; obter e definir os requisitos e solicitações do cliente através de sua solicitação direta ou através de outras entradas como revisão da proposta de negócio, objetivos operacionais, ambiente de hardware e outros documentos.

É imprescindível entender as expectativas do cliente e assegurar que tanto o cliente quanto o fornecedor entendam os requisitos da mesma forma. Isso pode ser feito através do processo de apoio "Revisão Conjunta" descrito na norma ISO/IEC 12207. É necessário acordar os requisitos e obter um acordo entre as equipes que desenvolverão o trabalho em relação aos requisitos do cliente.

É importante gerenciar todas as mudanças feitas nos requisitos do cliente em relação à linha-base definida assegurando que o resultado de mudanças tecnológicas e de necessidades do cliente são identificados e os impactos de introdução dessas mudanças são avaliados.

Análise dos requisitos do sistema

[editar | editar código-fonte]

Após a elicitação, segue para a especificação dos requisitos do sistema. Esta especificação deve descrever:

  • Funções e capacidades do sistema;
  • Requisitos de negócio, organizacionais e de usuários;
  • Requisitos de proteção, de segurança, de engenharia de fatores humanos (ergonomia), de interface, de operações e de manutenção;
  • Restrições de projeto e requisitos de qualificação.

Os requisitos precisam ser avaliados. Por isso, para formalizar e facilitar a avaliação, os critérios listados a seguir devem ser seguidos:

  • Rastreabilidade com os requisitos do cliente e necessidades de aquisição;
  • Consistência com as necessidades de aquisição e com a elicitação dos requisitos;
  • Testabilidade;
  • Viabilidade do projeto da arquitetura do sistema;
  • Viabilidade da operação e manutenção.

Após a avaliação é importante estabelecer mecanismos de comunicação para disseminar os requisitos do sistema e suas atualizações para todas as partes interessadas.

Projeto da arquitetura do sistema

[editar | editar código-fonte]

Com os requisitos elaborados e validados, pode-se estabelecer uma arquitetura de alto nível para o sistema. A arquitetura deve identificar itens de hardware, software e operações manuais. Após a arquitetura ser estabelecida, é necessário avaliá-la, considerando os critérios listados a seguir:

  • Rastreabilidade para os requisitos do sistema;
  • Consistência com os requisitos do sistema;
  • Adequação dos métodos e padrões de projeto utilizados;
  • Viabilidade dos itens de software atenderem seus requisitos alocados;
  • Viabilidade da operação e da manutenção.

Análise dos requisitos do software

[editar | editar código-fonte]

Para garantir a qualidade do produto entregue, as características de qualidade descritas a seguir devem ser observadas nos requisitos de software:

  • Especificações funcionais e de capacidade, incluindo desempenho, características físicas e condições do ambiente sob o qual o item de software será executado;
  • Interfaces externas ao item de software;
  • Requisitos de qualificação;
  • Especificações de proteção, incluindo aquelas relacionadas aos métodos de operação e manutenção, influências do ambiente e danos pessoais;
  • Especificações de segurança, incluindo aquelas relacionadas com o comprometimento de informações sigilosas;
  • Especificações de engenharia de fatores humanos (ergonomia), incluindo aquelas relacionadas com operações manuais, interações entre homem-máquina, restrições a pessoal e áreas que necessitam de maior atenção humana, que são sensíveis a erros humanos e treinamento;
  • Definição de dados e requisitos de bases de dados;
  • Requisitos de instalação e aceitação do produto de software entregue nos locais de operação e manutenção;
  • Documentação do usuário;
  • Requisitos do usuário para execução e operação;
  • Requisitos do usuário para manutenção.

Após a análise de requisitos de software é necessário fazer a avaliação desses requisitos considerando os critérios listados a seguir:

  • Rastreabilidade para os requisitos do sistema e projeto do sistema;
  • Consistência externa com os requisitos do sistema;
  • Consistência interna;
  • Testabilidade;
  • Viabilidade do projeto do software;
  • Viabilidade da operação e manutenção.

Pode-se conduzir uma ou mais revisões conjuntas e estabelecer as baselines.

Projeto da arquitetura do software

[editar | editar código-fonte]

O projeto de arquitetura de software busca transformar os requisitos em uma arquitetura que descreve sua estrutura de alto nível e identifica os componentes de software. As versões preliminares da documentação do usuário, dos requisitos preliminares e de testes devem ser garantidas e documentadas. O cronograma para a Integração do Software deve ser criado. A avaliação da arquitetura do item de software e os projetos de interface e base de dados, considerando os critérios listados a seguir:

  • Rastreabilidade para os requisitos do item de software;
  • Consistência externa com os requisitos do item de software;
  • Consistência interna entre os componentes de software;
  • Adequação dos métodos e padrões de projeto utilizados;
  • Viabilidade do projeto detalhado;
  • Viabilidade da operação e manutenção.

Pode-se conduzir uma ou mais revisões conjuntas e estabelecer as baselines.

Projeto detalhado do software

[editar | editar código-fonte]

Após o projeto de arquitetura, desenvolve-se um projeto detalhado de software para cada componente do software. Os componentes de software devem ser refinados em níveis mais baixos, contendo unidades de software que possam ser codificadas, compiladas e testadas. O projeto detalhado das interfaces deve permitir a codificação sem a necessidade de informação adicional. Durante o detalhamento de software, se for necessário, deve ser feita a atualização da documentação do usuário. É importante definir e documentar os requisitos de teste e o cronograma para testar unidades de software.

Após detalhamento do projeto de software é necessário fazer a avaliação deste detalhamento, considerando os critérios listados a seguir:

  • Rastreabilidade para os requisitos do item de software;
  • Consistência externa com o projeto da arquitetura;
  • Consistência interna entre os componentes e unidades de software;
  • Adequação dos métodos e padrões de projeto utilizados;
  • Viabilidade dos testes;
  • Viabilidade da operação e manutenção.

Pode-se conduzir uma ou mais revisões conjuntas e estabelecer as baselines.

Implementação

[editar | editar código-fonte]

A implementação consiste na definição ou seleção de um modelo de ciclo de vida de software apropriado ao escopo, magnitude e complexidade do projeto e na execução de documentação dos resultados, de acordo com o processo de documentação; colocação dos resultados sob o processo de gerência de configuração; execução do controle de alterações, de acordo com ele; documentação e resolução de não-conformidades e problemas encontrados nos produtos de software e tarefas, de acordo com o processo de resolução de problema; execução dos processos de apoio, conforme especificado no contrato; seleção, adaptação e utilização de padrões, métodos, ferramentas e linguagens de programação de computador; desenvolvimento dos planos para conduzir as atividades do processo de desenvolvimento.

Codificação e testes do software

[editar | editar código-fonte]

Para finalmente executar a codificação e os testes é necessário desenvolver e documentar cada unidade de software com base em procedimentos a serem definidos. Os testes devem garantir que os requisitos documentados sejam atendidos. Os resultados dos testes devem ser documentados. Durante esta fase, a atualização e documentação do usuário pode ser feita, se necessário. Após a codificação e testes é importante fazer a avaliação do código do software e dos resultados dos testes, considerando os critérios listados a seguir:

  • Rastreabilidade para os requisitos e projeto do item de software;
  • Consistência externa com os requisitos e projeto do item de software;
  • Consistência interna entre os requisitos da unidade;
  • Cobertura de teste das unidades;
  • Adequação dos métodos e padrões de codificação utilizados;
  • Viabilidade da integração e testes do software;
  • Viabilidade da operação e manutenção.

Os resultados das avaliações devem ser documentados.

Integração do software

[editar | editar código-fonte]

Para poder homologar o sistema é necessário desenvolver um plano de integração para integrar as unidades e componentes de software. O plano deve incluir requisitos de teste, procedimentos, dados, responsabilidades e cronograma. Deve-se testar essas agregações à medida que forem sendo integradas, de acordo com o plano de integração. Durante esta fase, a atualização e documentação do usuário pode ser feita, se necessário.

Após a codificação e testes é importante fazer a avaliação do plano de integração, projeto, código, testes, resultados dos testes e a documentação do usuário, considerando os critérios listados:

  • Rastreabilidade para os requisitos do sistema;
  • Consistência externa com os requisitos do sistema;
  • Consistência interna;
  • Cobertura de teste dos requisitos do item de software;
  • Adequação dos métodos e padrões de teste utilizados;
  • Conformidade com os resultados esperados;
  • Viabilidade do teste de qualificação do software;
  • Viabilidade da operação e manutenção.

Pode-se conduzir uma ou mais revisões conjuntas e estabelecer as baselines.

Teste de Qualificação do software

[editar | editar código-fonte]

Deve-se desenvolver e documentar os requisitos de qualificação de software e elaborar casos de teste (entradas, saídas e critérios de teste) e procedimentos de teste para conduzir o Teste de Qualificação do Software de acordo com os requisitos de qualificação para o item de software. Após a codificação e testes é importante fazer a avaliação do projeto, códigos, testes, resultados dos testes e a documentação dos usuários, considerando os critérios listados a seguir:

  • Cobertura de teste dos requisitos do item de software;
  • Conformidade com os resultados esperados;
  • Viabilidade da integração e testes do sistema, se conduzidos;
  • Viabilidade da operação e manutenção.

É importante estar preparado para dar apoio às auditorias.

Integração do sistema

[editar | editar código-fonte]

A integração do sistema faz-se a partir da integração dos itens de configuração de software ao sistema. Após a integração deve-se conduzir ao teste de qualificação do sistema. Após a codificação e testes é importante fazer a avaliação do sistema, considerando os critérios listados a seguir:

  • Cobertura de teste dos requisitos do sistema;
  • Adequação dos métodos e padrões de teste utilizados;
  • Conformidade com os resultados esperados;
  • Viabilidade do teste de qualificação do sistema;
  • Viabilidade da operação e manutenção.

Teste de qualificação do sistema

[editar | editar código-fonte]

Para garantir a qualidade do produto entregue é importante conduzir o teste de qualificação do sistema e fazer a avaliação do sistema, considerando os critérios listados a seguir:

  • Cobertura de teste dos requisitos do sistema;
  • Conformidade com os resultados esperados;
  • Viabilidade da operação e manutenção.

É importante estar preparado para dar apoio às auditorias.

Instalação do software

[editar | editar código-fonte]

Na instalação do software deve-se executar um plano para instalar o produto de software no ambiente alvo, conforme designado no contrato. Deve ser assegurado que o código do software e as bases de dados sejam iniciados, executados e finalizados, conforme especificado no contrato. Os eventos e resultados da instalação devem ser documentados.

Apoio à aceitação do software

[editar | editar código-fonte]

No apoio à aceitação do software é preciso garantir o apoio à revisão de aceitação do adquirente e testes do produto de software. A revisão de aceitação e testes deve considerar os resultados de Revisões Conjuntas, Auditorias, Teste de Qualificação do Software e Teste de Qualificação do Sistema (se executado). Conclusão e entrega do produto de software deve ser feita, conforme especificado no contrato e o desenvolvedor deve prover treinamento inicial e contínuo e suporte ao adquirente, conforme especificado no contrato.

Referências

  1. ISO/IEC 12207:2008 Systems and software engineering – Software life cycle processes
  2. Mitchell H. Levine (2006). «Analyzing the Deliverables Produced in the Software Development Life Cycle». Audit Serve, Inc. Consultado em 28 de outubro de 2011 
  3. «SSC San Diego Process Asset Library». Consultado em 20 de julho de 2016. Arquivado do original em 24 de junho de 2006