ISO/IEC 12207
Tecnologia da Informação
-
Processos do Ciclo de Vida do Software
É a primeira norma internacional que fornece um conjunto de processos para aquisição e fornecimento de produtos e serviços de software. Estes processos podem também ser empregues para gerir, desenvolver, usar e melhorar o software através do seu ciclo de vida. A sua arquitectura permite contemplar os métodos, técnicas, ferramentas e ambientes actuais e em evolução.
Proposta em 1988 e publicada em Agosto de 1995 pretende ser a base para o comércio internacional de produtos e serviços de software pois fornece um enquadramento comum para os processos do ciclo de vida do software, com uma terminologia bem definida, que pode ser referenciada pela indústria do software. Pretende substituir o conjunto de normas, procedimentos, métodos, ferramentas e ambientes de desenvolvimento e gestão de software que têm proliferado e criado dificuldades à gestão e engenharia do software especialmente na integração de produtos e serviços.
A norma ISO/IEC 12207 fornece uma arquitectura para o ciclo de vida do software e um quadro completo para a aquisição, fornecimento, desenvolvimento, operação e manutenção do software. Adicionalmente a norma contem um enquadramento para a gestão, controle e melhoramento das actividades do ciclo de vida do software.
Esta norma foi adaptada pelos Estados Unidos como a norma IEEE/EIA 12207 e é considerada uma norma estratégica que fornece a base para adopção, a nível organizacional, dos processos de software adequados a projectos dos vários sectores de actividade (comerciais, militares e outros) quer para clientes internos quer internacionais.
Foi adoptada pelo Department of Defense (DoD), em substituição
da norma MIL-STD-498, em Maio de 1998.
Principais Processos
A norma agrupa as actividades que fazem parte do ciclo de vida do software em três principais processos:
Processos primários
São os processos que servem as partes que iniciam o ciclo de
vida do software (quem adquire, quem fornece, quem desenvolve, quem opera
e quem mantém), ou seja:
Processos de suporte
São os processos que suportam outros processos como partes integrantes,
embora com diferentes propósitos, e que contribuem para o sucesso
do projecto de software. São eles:
Processos organizacionais
São os processos empregues para estabelecer e implementar uma
estrutura subjacente feita a partir de processos associados, são
as pesoas e é o melhoramento contínuo da estrutura e dos
processos. É independente dos projectos e dos contractos. São
os seguintes:
Visão Geral
A norma é aplicável a qualquer sector de actividade (aeroespacial, equipamentos médicos, telecomunicações, comercial, militar, etc.) ou e a qualquer cultura nacional ou organizacional.
Os utilizadores alvo são os adquirentes e fornecedores com elevados conhecimentos técnicos e envolvidos em projectos com grandes riscos a nível de custos, prazos, qualidade ou técnicos.
A norma limita-se ao ciclo de vida do software dum sistema e não ao ciclo de vida do sistema total.
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 decálculo ou jogos.
A norma descreve os principais componentes dos processos dum ciclo de vida completo do software, os seus interfaces e as relações de alto nível que regulam essas interacções.
Para cada um dos processos são definidas, detalhadamente, em termos de responsabilidades, as tarefas e actividades, bem como os respectivos outputs. No entanto não especifica como implementar ou executar essas tarefas e actividades.
A norma não obriga à adopção de qualquer modelo específico de ciclo de vida ou metodologia de desenvolvimento.
Estabelece que o responsável pelo desenvolvimento deve definir ou seleccionar um modelo de ciclo de vida apropriado ao âmbito, dimensão e complexidade do projecto. As actividades e tarefas do processo de desenvolvimento devem ser seleccionadas e mapeadas no modelo do ciclo de vida. O objectivo é existir flexibilidade na ordenação das actividades e escolher o modelo de desenvolvimento mais adequado às características do projecto.
A norma não pretende entrar em conflito com as políticas, normas ou procedimentos já em uso na organização. Contudo qualquer conflito existente precisa de ser ultrapassado e no caso de não estar de acordo com a norma tem de ser citado como excepção.
Na norma são indicadas algumas listas de tarefas. Nenhuma delas pretende ser exaustiva e apenas pretende servir como exemplo. No caso do processo de desenvolvimento são 12 as actividades previstas:
Em relação à documentação não
prescreve qualquer nome, formato, conteúdo explícito ou suporte.
Requer apenas que seja registado todo o trabalho que possa interessar aos
gestores, técnicos e utilizadores. Pressupõe a documentação
de todos os outputs de todas as actividades e tarefas dos processos seleccionados.
É neutro em relação à utilização
de ferramentas CASE como alternativa aos documentos tradicionais.
Conceitos Básicos
Relação Adquirente - Fornecedor
A norma baseia-se na perspectiva de que existe uma entidade, o adquirente que precisa dum produto ou dum serviço de software e que existe um fornecedor para esse produto ou serviço. A cada um são atribuídas actividades e tarefas distintas.
Essas entidades podem pertencer a organizações diferentes
ou pertencer à mesma organização.
Contrato
O contrato é definido como qualquer tipo de acordo entre as
partes.
Princípios da Engenharia de software
Baseia-se nos princípios da engenharia do software em que os componentes básicos são: análise, desenho, fabrico (codificação), avaliação, teste, integração, controlo e garantia de qualidade, distribuição, etc.
Quanto à especificação das caraceterísticas
de qualidade do software remete para a norma ISO/IEC 9126.
Arquitectura do ciclo de vida do software
A norma estabelece uma arquitectura de alto nível do ciclo de vida do software. O ciclo inicia-se com uma ideia ou necessidade que pode ser satisfeita no total ou em parte pelo software e termina com a reforma do software. A arquitectura é construída com um conjunto de processos e interrelações entre esses processos. A derivação dos processos é baseada em dois princípios :
Estrutura de um processo do ciclo de vida
Cada processo é concebido em termos das actividades que o constituem e por sua vez cada actividade é concebida em termos das suas tarefas.
Por exemplo, uma das actividades do processo de desenvolvimento é o teste qualificativo do software. Esta actividade é então decomposta nas suas tarefas, sob responsabilidade de quem desenvolve, a saber:
Natureza das tarefas
Uma tarefa é um conjunto de acções elementares. Uma tarefa tem um input e produz um output. Pode ser expressa nos seguintes termos conforme o verbo que usa:
Natureza das Avaliações
A avaliação é um função elementar
e usada de várias maneiras pelos processos. As avaliações
são conduzidas sobre várias entidades, com objectivos
e critérios definidos. Uma entidade pode ser um processo, uma actividade
ou uma tarefa, um plano, um acordo, um relatório, etc. Um objectivo
pode ser verificado, revisto, auditado, validado, melhorado sempre que
o motivo e objectivo que deu origem à avaliação varie.
Gestão da Qualidade Total
Implementa os princípios da gestão da qualidade total. Trata todas as actividades, incluindo as relacionadas com a qualidade, como parte integrante do ciclo de vida do software.
As actividades do ciclo de vida relacionadas com a qualidade estão adaptadas a cada processo. Cada processo está equipado com o ciclo PDCA (Plan-Do-Check-Act). A intenção é que o output de uma tarefa seja verificado antes de servir como input da tarefa seguinte.
Adicionalmente, existem dois processos especiais: verificação
e validação que complementam as avaliações
inerentes a cada processo com o devido grau de independência e objectividade.
Ligação entre sistema e software
A norma estabelece uma forte ligação entre sistema e software.
O software é tratado como uma parte integrante do sistema total
e que desempenha certas funções naquele sistema. Esse sistema
satisfará determinados objectivos e é tipicamente constituído
por hardware, telecomunicações e pessoas.
Aplicabilidade a organizações
Os processos nesta norma funcionam como um enquadramento para servir em várias organizações. Uma organização pode seleccionar um subconjunto de processos que considere adequado para atingir os seus propósitos.
A norma pretende ser aplicada numa situação em que existem duas partes, quer essas duas partes representem organizações distintas, quer pertençam à mesma organização. A situação pode variar entre um acordo informal até um contrato legalmente registado. Também pode ser usada apenas por uma parte como tarefas auto impostas.
Os termos "organização" e "parte" são quase sinónimos. Uma organização é um corpo de pessoas organizadas para atingir determinados fins. Quando uma organização entra num acordo (na totalidade ou em parte) passa a ser uma parte. As organizações são corpos separados mas as partes podem ser da mesma organização ou de diferentes organizações.
Uma organização ou uma parte passa a chamar-se pelo nome do processo pelo qual é responsável; por exemplo, chama-se adquirente quando desempenha o processo de aquisição.
Os processos e organizações (ou partes) estão relacionados apenas em termos funcionais. O seu nome depende da função que executa e não implica qualquer estrutura para a organização (ou parte).
Uma organização pode executar um ou vários processos e um processo pode ser executado por uma ou várias organizações. No entanto, sob um contracto uma dada parte não pode executar, em simultâneo, o processo aquisição e o processo fornecimento, embora possa executar outros processos.
A norma pretende ser aplicada por uma organização quer
internamente quer contratualmente por duas ou mais organizações.
Por isso as tarefas estão expressas em termos contratuais.
Aplicabilidade a projectos
A norma está escrita para um projecto de software geral, grande e complexo. Contudo foi concebida para ser adaptada ou ajustada a projectos de menor dimensão e/ou complexidade. Está também concebida para contemplar o software quer como entidade isolada quer como embebido ou parte integral dum sistema total.
O conjunto de processos, tarefas e actividades foi concebido para ser ajustável a projectos de software concretos. Este processo de ajustamento (tailoring) consiste na eliminação de processos, actividades e tarefas não aplicáveis. No entanto o processo de aquisição e o processo de fornecimento não são ajustáveis.
Num projecto a norma pode ser aplicada mais que uma vez. Po exemplo,
num dado projecto de software um adquirente contrata um fornecedor para
desenvolver software e este fornecedor por sua vez subcontrata outro fornecedor
para executar todo ou parte do software. No primeiro caso o adquirente
e o fornecedor aplicam uma parte da norma. No último caso o fornecedor
(como adquirente) e o seu subcontratado (como fornecedor) aplicam outra
parte separada da norma.
Processo de ajustamento (Tailoring)
Este processo baseia-se na ideia de que é possível especificar num contracto e a partir da norma quais as actividades e tarefas necessárias para produzir determinado produto de software ou para prestar determinado serviço numa situação particular.
Esse proceso não pode comprometer a integridade, as intençoes ou a arquitectura da norma.
No entanto, o processo de ajustamento, definido no Anexo A, exige requisitos obrigatórios. Nomeadamente:
Capacidade de resposta a tecnologias emergentes
Para responder à rápida evolução da tecnologia a norma fornece uma arquitectura do ciclo de vida aberta e de alto nível.
A norma é independente de qualquer tecnologia.
Os processos, actividades e tarefas descritas referem-se "ao que fazer" mas a norma não dá qualquer indicação a "como fazer". Permite ao fornecedor ser criativo e empregar os métodos, técnicas e ferramentas mais apropriadas para produzir o produto ou fornecer o serviço.
Pode ser usado qualquer modelo de ciclo de vida (waterfall, incremental,
evolucionário, espiral, etc), assim como qualquer método
de engenharia de software (object-oriented, estruturada, top-down, ou outra)
ou qualquer linguagem de programação (Ada, Cobol, etc.).
Todas estas questões estão relacionadas com o tipo de projecto
e com o estado da arte da tecnologia do software e a sua selecção
é deixada ao utilizador da norma.
Não prescrição de eventos e marcos (milestones)
Na norma os processos com as respectivas actividades e tarefas estão
combinadas na sua sequência natural. Esta sequência não
impõe qualquer sequência dependente do tempo. Por falta de
consenso ou universalidade em relação a uma sequência
dependente do tempo, o utilizador da norma tem a opção de
seleccionar, ajustar e ordenar os processos, actividades e tarefas como
considerar ser mais apropriado e efectivo. A norma encoraja a interacção
entre as actividades e a recursão dentro de uma actividade para
anular os efeitos de qualquer sequência implicita de actividades
e tarefas.
Documentação dos outputs
A norma requer que alguns outputs sejam documentados. No entanto, não
especifica o formato, conteúdo ou suporte desses documentos. Uma
organização pode usar o conjunto de formulários já
existentes. Apenas terá de fazer a correspondência entre a
documentação exigida pela norma e as normas de documentação
da organização.
Definição da linha de partida (baselining)
A norma requer que sejam estabelecidas "baselines" no tempo adequado
como planeado para os requisitos, desenho e codificação.
O baselining, quando usado judiciosamente, é um meio efectivo para
estabelecer confiança nos marcos (milestones) e no controlo dos
custos e do calendário através da inibição
não necessária e não planeada de alterações
aos requisitos, desenho e codificação. O baselining deve
ser feito durante uma revisão conjunta ou numa auditoria de forma
a expedir e solidificar a compreensão da relação adquirente-fornecedor.
Contudo, um projecto pode escolher não efectuar o baselining. A
responsabilidade do baselining é atribuída ao processo de
desenvolvimento ( e ao processo de manutenção) e não
ao processo de gestão das configurações.
Métricas de software
Não é uma norma de métricas de software. Requer
a especificação de indicadores de gestão e de atributos
de software mas não os define nem prescreve. Referencia a norma
ISO/IEC 9126 para guia das características de software. Os detalhes
de tais especificações são deixados aos utilizadores
da norma.
Perspectivas (Views)
A norma possibilita diferentes visões conforme as perspectivas e objectivos de quem a utiliza. O anexo C, "Guia sobre os processos e organizações" descreve como os processos podem ser usados com diferentes perspectivas pelas diferentes organzações ou partes com pontos de vista e objectivos diferentes.
As perspectivas básicas previstas são: o contracto, a gestão, a operação, a engenharia e o suporte.
Por exemplo, a perspectiva da gestão da qualidade, incluída
na perspectiva básica de suporte, tem cinco processos no ciclo de
vida: garantia de qualidade, verificação, validação,
revisão conjunta e auditoria.
Conformidade com a norma
Fornece conformidade a nível do projecto e a nível organizacional.
A conformidade é definida como a execução de todos
os processos, actividades e tarefas seleccionadas para o projecto de software.
A execução dum processo ou duma actividade é considerada
completa quando todas as tarefas requeridas são executadas de acordo
com os critérios e os requisitos especificados no contracto.
Certificação
A norma não se refere à certificação da
organização em relação aos processos do ciclo
de vida nem define qualquer critério de certificação.
Não é realistico para uma organização ter todos
os processos da norma.
Limitações
A norma não substitui uma gestão sistemática e
disciplinada dos sistemas de informação. É meramente
um instrumento para enquadramento em que os processos, actividades e tarefas
relativas ao software estão razoavelmente identificadas.
Pré-requisitos ao uso da norma
A norma cobre todo o ciclo de vida dum sistema de software e reconcilia os objectivos, por vezes conflituosos, das fases do ciclo e das partes envolvidas.
Para um uso efectivo e produtivo devem existir os seguintes pré
requisitos respeitando a ordem:
1- pessoal treinado
2- familiaridade com as políticas da organização
3- familiaridade com o ambiente do projecto
4- compreensão da norma
Índice da norma ISO/IEC 12207
Anexo A - Processo de ajustamento (tailoring)Introdução Ãmbito Referências normativas Definições Aplicação desta norma internacional Processos primários do ciclo de vida Aquisição Fornecimento Desenvolvimento Operação Manutenção Processos de suporte do ciclo de vida Documentação Gestão da configuração Garantia de qualidade Verificação Validação Revisão conjunta Auditoria Resolução de problemas Processos organizacionais do ciclo de vida Gestão Infraestrutura Melhoramento Formação
A norma IEEE/EIA 12207 tem ainda os seguintes anexos:
E - Conceitos Básicos
F - Conformidade
G - Objectivos dos processos do ciclo de vida
H - Objectivos dos dados sobre o ciclo de vida
I - Relacionamentos
Tarefas por Actividade
Processo de Aquisição
Iniciação |
|
Preparação para o pedido de proposta |
|
Preparação e actualização do contracto |
|
Monitorar o fornecedor |
|
Aceitação e finalização |
|
Processo de Fornecimento
Iniciação |
|
Preparação da resposta |
|
Contracto |
|
Planeamento |
|
Execução e controlo |
|
Revisão e avaliação |
|
Entrega e finalização |
|
Processo de Desenvolvimento
Implementação do processo |
|
Análise do requisitos do sistema |
|
Desenho da arquitectura do sistema |
|
Análise dos requisitos do software |
|
Desenho da arquitectura do software |
|
Desenho detalhado do software |
|
Codificação e teste do software |
|
Integração do software |
|
Teste qualificativo do software |
|
Integração do sistema |
|
Teste qualificativo do sistema |
|
Instalação do software |
|
Suporte à aceitação do software |
|
Processo de Operação
Implementação |
|
Teste operacional |
|
Operação do sistema |
|
Apoio ao utilizador |
|
Processo de Manutenção
Implementação |
|
Análise de problemas e alterações |
|
Implementação das alterações |
|
Revisão/aceitação da alterações |
|
Migração |
|
Reforma do software |
|
Processos de Apoio
Processo de Documentação
Implementação |
|
Desenho e desenvolvimento |
|
Produção |
|
Manutenção |
|
Gestão das Configurações
Implementação | Desenvolver o Plano da gestão das configurações |
Identificação da configuração | Estabelecer o esquema para identificar os itens de software e suas versões |
Controlo da configuração | Registar, avaliar, aprovar e implementar os pedidos de alteração |
Estado da configuração | Manter os registos e os relatórios sobre o estado |
Avaliação da configuração | Assegurar a integridade funcional |
Gestão da entrega | Controlar a entrega do produto e respectiva documentação |
Garantia de Qualidade
Implementação |
|
Garantir o produto |
|
Garantir o processo |
|
Garantir o sistema de qualidade |
|
Verificação
Implementação |
|
Verificação |
|
Validação
Implementação |
|
Validação |
|
Revisão conjunta
Implementação |
|
Revisão da gestão do projecto |
|
Revisões Técnicas |
|
Processo de Auditoria
Implementação |
|
Auditoria |
|
Resolução de Problemas
Implementação | Estabelecer o processo de resolução de problemas |
Resolução de Problemas | Rastrear os problemas através da detecção, análise e resolução |
Processos Organizacionais
Gestão
Início e definição do âmbito |
|
Planeamento |
|
Execução e controlo |
|
Revisão e avaliação |
|
Fecho |
|
Infraestruturas
Implementação |
|
Estabelecimento da infraestrutura |
|
Manter a infraestrutura |
|
Melhoramento
Estabelecimento do proceso |
|
Avaliação do processo |
|
Melhoramento do processo |
|
Formação
Implementação |
|
Desenvolver os materiais de formação |
|
Implementar o plano de formação |
|
Definições
Adquirente - organização que adquire o sistema, produto ou serviço de software. Pode ser um comprador, um cliente, um proprietário, ou um utilizador.
Auditoria - conduzida por uma pessoa autorizada com o fim de fornecer uma avaliação independente dos produtos e processos do software de forma a garantir conformidade com os requisitos.
Avaliação - determinação sistemática da extensão com que uma entidade obedece a critérios especificados.
Baseline - uma versão oficialmente aprovada dum item da configuração, formalmente designada e registada num tempo específico durante a configuração dos itens do ciclo de vida.
Cobertura dos testes - a extensão com que os casos de teste testam os requisitos do sistema ou produto de software.
Contracto - um acordo fixado entre duas partes, registado legalmente ou um acordo semelhante feito internamente numa organização, para o fornecimento dum serviço de software ou para o fornecimento, desenvolvimento, produção, operação ou manutenção dum produto de software.
Firmware - a combinação dum dispositivo de hardware com instruções computorizadas ou dados computorizados que residem como software só de leitura num dispositivo de hardware. O software não pode ser alterado rapidamente através dum programa de controlo.
Fornecedor - uma organização que faz um contracto com um adquirente para o fornecimento dum sistema, produto ou serviço de software nos termos desse contracto.
Item da configuração - uma entidade dentro duma configuração que satisfaz uma função do utilizador final e que pode ser identificada univocamente num dado ponto de referência.
Produto off-the-shelf - produto já desenvolvido e disponível para ser usado como está ou com modificações.
Produto de software - o conjunto de programas de computador, procedimentos e possivelmente os dados e documentação associados.
Requisito de qualificação - um conjunto de critérios ou condições que tem de ser obedecidos de forma a poder-se qualificar um produto de software como conforme com as suas especificações e estar pronto a ser usado no seu ambiente alvo.
Serviço de software - desempenho de actividades, trabalho ou obrigações ligadas a um produto de software tais como o desenvolvimento, manutenção e operação.
Sistema - uma composição integrada que consiste num ou mais processos, hardware, software, facilidades e pessoas, que fornecem a capacidade de satisfazer uma necessidade ou objectivo explicitado.
Teste qualificativo - teste, conduzido por quem desenvolve e
testemunhado pelo adquirente, para demonstrar que o produto de software
obedece às suas especificações e está pronto
a ser usado no seu ambiente alvo.
LINKS, que serviram de base ao texto
ISO/IEC 12207 Software Lifecycle Processes, de Lewis Gray
U.S. Software Lifecycle Process Standards, de Jim Moore
Concepts and Key Definitions, de Stan Magee
IEEE/EIA 12207, de Jim Wells
ISO 12207 and Related Software Life-Cycle Standards, de Jim Moore
The Frameworks Quagmire, a Brief Look, de Sarah Sheard
International Standard ISO/IEC 12207 Software Life Cycle Processes, de Raghu Singh, PDF
A Comparison of IEEE/EIA 12207, ISO/IEC 12207, J-STD-016, and MIL-STD-498 for Acquirers and Developers, Lewis Gray, PDF
Coordinating the SEI CMMs with IEEE/EIA 12207, Lewis Gray, PDF
Software Process Improvement with ISO/IEC 12207, J-STD-016-1995, and MIL-STD-498, Lewis Gray, PDF
An introduction to
International Standard ISO/IEC 12207 Software Life Cycle Processes,
Raghu Singh, PDF
Em Francês
NORMES
- Qualité des processus du cycle de vie
Visitas:
Última actualização: 12 de Novembro de 1999