NBR ISO 12207 - Tecnologia de Informacao - Processos de Ciclo de Vida de Software

Cpia no autorizada
NBR ISO/IEC 12207 Tecnologia de informao - Processos de ciclo de vida de software

OUT 1998
ABNT-Associao Brasileira de Normas Tcnicas
Sede: Rio de Janeiro Av. Treze de Maio, 13 - 28 andar CEP 20003-900 - Caixa Postal 1680 Rio de Janeiro - RJ Tel.: PABX (021) 210 -3122 Fax: (021) 220-1762/220-6436 Endereo Telegrfico: NORMATCNICA
Origem: Projeto 21:101.03.002:1997 CB-21 - Comit Brasileiro de Processamento de Dados CE-21:101.03 - Processos de Ciclo de Vida de Software NBR ISO/IEC 12207 - Information technology - Software life cycle process Descriptors: Data processing. Data processing equipment. Computers. Computer software. Life cycle Esta Norma equivalente ISO/IEC 12207:1995 Vlida a partir de 30.11.1998 Palavras-chave: Processamento de dados. Equipamento de processamento de dados. Computadores. Software. Ciclo de vida. Informao tecnolgica 35 pginas
Copyright 1998, ABNTAssociao Brasileira de Normas Tcnicas Printed in Brazil/ Impresso no Brasil Todos os direitos reservados
Sumrio
Prefcio Introduo 1 Objetivo e campo de aplicao 2 Referncias normativas 3 Definies 4 Aplicao desta Norma 5 Processos fundamentais de ciclo de vida 5.1 Processo de aquisio 5.2 Processo de fornecimento 5.3 Processo de desenvolvimento 5.4 Processo de operao 5.5 Processo de manuteno 6 Processos de apoio de ciclo de vida 6.1 Processo de documentao 6.2 Processo de gerncia de configurao 6.3 Processo de garantia da qualidade 6.4 Processo de verificao 6.5 Processo de validao 6.6 Processo de reviso conjunta 6.7 Processo de auditoria 6.8 Processo de resoluo de problema 7 Processos organizacionais de ciclo de vida 7.1 Processo de gerncia 7.2 Processo de infra-estrutura 7.3 Processo de melhoria 7.4 Processo de treinamento ANEXOS A Processo de adaptao B Orientao para a adaptao C Orientaes sobre processos e organizaes D Bibliografia
Prefcio
A ABNT - Associao Brasileira de Normas Tcnicas - o Frum Nacional de Normalizao. As Normas Brasileiras, cujo contedo de responsabilidade dos Comits Brasileiros (CB) e dos Organismos de Normalizao Setorial (ONS), so elaboradas por Comisses de Estudo (CE), formadas por representantes dos setores envolvidos, delas fazendo parte: produtores, consumidores e neutros (universidades, laboratrios e outros). Os Projetos de Norma Brasileira, elaborados no mbito dos CB e ONS, circulam para Votao Nacional entre os associados da ABNT e demais interessados. A NBR ISO/IEC 12207 foi preparada pela CE-21:101.03 Processos de Ciclo de Vida de Software, do CB-21 - Comit Brasileiro de Processamento de Dados. Esta Norma contm o anexo A, que normativo, e os anexos B e C, que so apenas informativos.
Introduo
Software uma parte fundamental da tecnologia de informao e de sistemas convencionais, tais como sistemas de transporte, militares, da rea mdica e financeiros. Tem havido uma proliferao de normas, procedimentos, mtodos, ferramentas e ambientes de desenvolvimento e de gerncia de software. Esta proliferao tem criado
Cpia no autorizada
NBR ISO/IEC 12207:1998
dificuldades na gerncia e engenharia de software, principalmente na integrao de produtos e servios. A disciplina de software necessita migrar desta proliferao para uma estrutura comum que possa ser usada por profissionais de software para falar a mesma lngua na criao e gerncia de software. Esta Norma prov tal estrutura comum. A estrutura cobre o ciclo de vida de software desde a concepo de idias at a descontinuao do software, e consiste nos processos de aquisio e fornecimento de produtos e servios de software. Adicionalmente, a estrutura prov o controle e a melhoria destes processos. Os processos desta Norma formam um conjunto abrangente. Uma organizao, dependendo de seu objetivo, pode selecionar um subconjunto apropriado para satisfaz-lo. Esta Norma , portanto, projetada para ser adaptada para uma organizao, projeto ou aplicao especficos. Tambm projetada para ser utilizada quando o software uma entidade independente ou embutida ou integrada a um sistema.
Esta Norma foi escrita para adquirentes de sistemas e produtos e servios de software, e para fornecedores, desenvolvedores, operadores, mantenedores, gerentes, gerentes de garantia da qualidade e usurios dos produtos de software. 1.3 Adaptao desta Norma Esta Norma contm um conjunto de processos, atividades e tarefas projetado para ser adaptado de acordo com cada projeto de software. O processo de adaptao consiste na supresso de processos, atividades e tarefas no aplicveis.
NOTA - Processos, atividades e tarefas, especficos ou especiais, podem ser adicionados ao contrato.
1.4 Conformidade A conformidade a esta Norma definida como a execuo de todos os processos, atividades e tarefas, selecionados desta Norma no processo de adaptao (anexo A), para o projeto de software. A execuo de um processo ou uma atividade concluda quando todas as suas tarefas requeridas so executadas de acordo com os critrios preestabelecidos e com os requisitos especificados no contrato, quando aplicvel. Qualquer organizao (por exemplo, estatal ou privada) que exija o cumprimento desta Norma como uma condio de negcio, responsvel por especificar e disponibilizar o conjunto mnimo de processos, atividades e tarefas requeridos, que constitui a conformidade dos fornecedores a esta Norma. 1.5 Limitaes Esta Norma descreve a arquitetura dos processos de ciclo de vida de software, mas no especifica os detalhes de como implementar ou executar as atividades e tarefas includas nos processos. Esta Norma no pretende prescrever o nome, formato ou contedo explcito da documentao a ser produzida. Esta Norma pode requerer o desenvolvimento de documentos de mesma categoria ou tipo; por exemplo, diferentes planos. Esta Norma, contudo, no sugere que tais documentos sejam desenvolvidos ou emitidos separadamente ou combinados de alguma forma. Estas decises so deixadas para o usurio desta Norma. Esta Norma no prescreve um modelo especfico de ciclo de vida ou mtodo de desenvolvimento de software. As partes envolvidas com esta Norma so responsveis pela seleo de um modelo de ciclo de vida para o projeto de software e pelo mapeamento dos processos, atividades e tarefas desta Norma dentro deste modelo. As partes envolvidas so tambm responsveis pela seleo e aplicao dos mtodos de desenvolvimento de software e pela execuo das atividades e tarefas adequadas ao projeto de software. Esta Norma no pretende entrar em conflito com quaisquer polticas, normas ou procedimentos j existentes na organizao. Entretanto, qualquer conflito necessita ser resolvido e quaisquer condies e situaes de sobreposio precisam ser citadas por escrito como excees para a aplicao desta Norma.
1 Objetivo e campo de aplicao

1.1 Objetivo Esta Norma estabelece uma estrutura comum para os processos de ciclo de vida de software, com terminologia bem definida, que pode ser referenciada pela indstria de software. A estrutura contm processos, atividades e tarefas que servem para ser aplicadas durante a aquisio de um sistema que contm software, de um produto de software independente ou de um servio de software, e durante o fornecimento, desenvolvimento, operao e manuteno de produtos de software. O termo software inclui a parte de software de firmware. Esta Norma tambm prov um processo que pode ser utilizado para definir, controlar e melhorar os processos de ciclo de vida de software. 1.2 Campo de aplicao Esta Norma aplica-se aquisio de sistemas, produtos e servios de software, para o fornecimento, o desenvolvimento, a operao e a manuteno de produtos de software, e para a parte de software de firmware, quer sejam executados interna ou externamente a uma organizao. Alguns aspectos necessrios de definio de sistemas, para prover o contexto a produtos e servios de software, esto includos.
NOTA - Os processos utilizados durante o ciclo de vida de software necessitam ser compatveis com os processos utilizados durante o ciclo de vida de sistema.
Esta Norma destinada para ser utilizada em uma relao entre duas partes e pode ser igualmente aplicada quando as duas partes forem da mesma organizao. A relao pode ser desde um acordo informal at um contrato legal. Esta Norma pode ser utilizada por uma nica parte por meio de tarefas impostas a ela mesma. Esta Norma no foi concebida para produtos de software de prateleira, a menos que eles estejam incorporados dentro de um produto encomendado.
Cpia no autorizada
Ao longo desta Norma, deve utilizado para expressar uma obrigao entre duas ou mais partes; dever para expressar uma declarao de objetivo ou inteno de uma das partes; deveria para expressar uma recomendao entre vrias possibilidades; e pode para indicar uma ao permitida dentro dos limites desta Norma. Nesta Norma, as listas definidas para as tarefas no pretendem ser exaustivas, porm usadas como exemplos.
3.4 auditoria: Processo conduzido por uma pessoa autorizada, com o objetivo de prover um julgamento independente de produtos e processos de software, a fim de avaliar a conformidade com seus requisitos. 3.5 linha bsica (baseline): Verso formalmente aprovada de um item de configurao, independente de mdia, formalmente definida e fixada em um determinado momento durante o ciclo de vida do item de configurao. 3.6 item de configurao: Entidade dentro de uma configurao que satisfaz uma funo de uso final e que pode ser identificada de forma nica em um determinado ponto de referncia. 3.7 contrato: Acordo realizado entre duas partes, respaldado pela lei, ou acordo interno similar restrito a uma organizao, para o fornecimento de servios de software ou para o fornecimento, desenvolvimento, produo, operao ou manuteno de um produto de software. 3.8 desenvolvedor: Organizao que executa atividades de desenvolvimento (incluindo anlise de requisitos, projeto, testes at aceitao) durante o processo de ciclo de vida de software. 3.9 avaliao: Determinao sistemtica do grau de atendimento de uma entidade em relao aos critrios para ela estabelecidos. 3.10 firmware : Combinao de um dispositivo de hardware e instrues ou dados de computador que residem como um software somente para leitura no dispositivo de hardware. Este software no pode ser diretamente modificado por um programa. 3.11 modelo de ciclo de vida: Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operao e manuteno de um produto de software, abrangendo a vida do sistema desde a definio de seus requisitos at o trmino de seu uso. 3.12 mantenedor: Organizao que executa atividades de manuteno. 3.13 monitorao: Exame da situao das atividades de um fornecedor e dos seus resultados, efetuado pelo adquirente ou uma terceira parte. 3.14 item que no ser entregue: Hardware ou produto de software cuja entrega no exigida em contrato, mas pode ser utilizado no desenvolvimento do produto de software. 3.15 produto de prateleira: Produto j desenvolvido e disponvel para utilizao na forma em que se encontra ou com modificao. 3.16 operador: Organizao que opera o sistema. 3.17 processo: Conjunto de atividades inter-relacionadas, que transforma entradas em sadas.
NOTA - O termo atividades engloba a utilizao de recursos. [Ver NBR ISO 8402:1994, 1.2]
2 Referncias normativas
As normas relacionadas a seguir contm disposies que, ao serem citadas neste texto, constituem prescries para esta Norma. As edies indicadas estavam em vigor no momento desta publicao. Como toda norma est sujeita a reviso, recomenda-se queles que realizam acordos com base nesta que verifiquem a convenincia de se usarem as edies mais recentes das normas citadas a seguir. A ABNT possui a informao das normas em vigor em um dado momento. ISO/AFNOR:1989 - Dictionary of computer science ISO/IEC 2382-1:1993 - Information technology Vocabulary - Part 1: Fundamental terms ISO/IEC 2382-20:1990 - Information technology Vocabulary - Part 20: System development NBR ISO 8402:1994 - Gesto da qualidade e garantia da qualidade - Terminologia NBR ISO 9001:1994 - Sistema da qualidade - Modelo para garantia da qualidade em projeto, desenvolvimento, produo, instalao e servios associados ISO/IEC 9126:1991 1) - Information technology Software product evaluation - Quality characteristics and guidelines for their use.
3 Definies
Para os propsitos desta Norma as definies contidas nas NBR ISO 8402, ISO/IEC 2382-1 e ISO/IEC 2382-20 aplicam-se em conjunto com as seguintes definies:
NOTA - Um produto pode ser entendido como uma parte de um sistema, quando aplicvel.
3.1 adquirente: Uma organizao que adquire ou obtm um sistema, produto de software ou servio de software de um fornecedor.
NOTA - O adquirente poderia ser: comprador, cliente, proprietrio ou usurio.
3.2 aquisio: Processo de obteno de um sistema, produto de software ou servio de software. 3.3 acordo: Definio de termos e condies sob a qual o relacionamento de trabalho entre as partes dever ser conduzido.
1)
Para efeitpo de norma brasileira utilizar a NBR 13596:1996.
Cpia no autorizada
3.18 qualificao: Processo de demonstrar se uma entidade capaz de atender os requisitos especificados. [Ver NBR ISO 8402:1994, 2.13] 3.19 requisito de qualificao: Conjunto de critrios ou de condies que, quando atendido, qualifica um produto de software quanto conformidade s suas especificaes e quanto sua utilizao no seu ambiente-alvo. 3.20 teste de qualificao: Teste conduzido pelo desenvolvedor e testemunhado pelo adquirente (quando apropriado), para demonstrar que o produto de software atende as suas especificaes e est pronto para utilizao no seu ambiente-alvo. 3.21 garantia da qualidade: Conjunto de atividades planejadas e sistemticas, implementadas no sistema da qualidade e demonstradas como necessrias, para prover confiana adequada de que uma entidade atender os requisitos para a qualidade.
NOTAS 1 A garantia da qualidade visa, simultaneamente, aos objetivos internos e externos: a) Garantia da qualidade interna: dentro de uma organizao, a garantia da qualidade prov confiana administrao; b) Garantia da qualidade externa: em situaes contratuais ou outras, a garantia da qualidade prov confiana aos clientes ou a outros. 2 Algumas aes do controle da qualidade e da garantia da qualidade so inter-relacionadas. 3 Se os requisitos para a qualidade no refletirem inteiramente as necessidades do usurio, a garantia da qualidade pode no prover a confiana adequada. [NBR ISO 8402:1994, 3.5]
3.26 produto de software: Conjunto de programas de computador, procedimentos e possvel documentao e dados associados. 3.27 servio de software: Execuo de atividades, trabalho ou obrigaes relacionados ao produto de software, tais como seu desenvolvimento, manuteno e operao. 3.28 unidade de software: Parte de cdigo compilvel separadamente. 3.29 descrio de tarefas: Documento utilizado pelo adquirente como um meio para descrever e especificar as tarefas a serem executadas conforme o contrato. 3.30 fornecedor: Organizao que firma um contrato com o adquirente para fornecimento de um sistema, produto de software ou servio de software conforme os termos do contrato.
NOTAS 1 O termo fornecedor sinnimo de contratado, produtor, vendedor ou distribuidor. 2 O adquirente pode designar uma parte de sua organizao como fornecedor.
3.31 sistema: Conjunto integrado que consiste em um ou mais processos, hardware, software, recursos e pessoas, capaz de satisfazer uma necessidade ou objetivo definido. 3.32 cobertura de teste: Extenso em que os casos de teste dos requisitos de um sistema ou produto de software so testados. 3.33 testabilidade: Extenso em que um teste objetivo e factvel pode ser projetado para determinar se um requisito atendido. 3.34 usurio: Indivduo ou organizao que utiliza um sistema em operao para executar uma funo especfica.
NOTA - O usurio pode executar outros papis, tais como adquirente, desenvolvedor ou mantenedor.
3.22 liberao (release): Verso particular de um item de configurao que colocada disposio para um propsito especfico (por exemplo, liberao para teste). 3.23 pedido de proposta: Documento utilizado pelo adquirente como meio para divulgar aos potenciais fornecedores sua inteno de adquirir um sistema, produto de software ou servio de software especificado. 3.24 descontinuao: Cancelamento do suporte ativo pela organizao de operao e manuteno, substituio total ou parcial por um novo sistema, ou instalao de um sistema atualizado. 3.25 segurana: Proteo de informaes e dados de modo que pessoas ou sistemas no autorizados no possam l-los ou modific-los e que pessoas ou sistemas autorizados no tenham acesso negado a eles.
3.35 validao: Confirmao, por exame e fornecimento de evidncia objetiva, de que os requisitos especficos, para um determinado uso pretendido, so atendidos.
NOTAS 1 Nas atividades de projeto e desenvolvimento, a validao se refere ao processo de examinar um produto para determinar sua conformidade com as necessidades do usurio. 2 A validao feita normalmente no produto final sob condies de operao definidas, podendo, contudo, tornar-se necessria em fases anteriores. 3 O termo validado usado para designar o estado aps a validao. 4 Validaes mltiplas podem ser realizadas se existirem diferentes usos pretendidos. [NBR ISO 8402:1994, 2.18]
Cpia no autorizada
3.36 verificao: Confirmao, por exame e fornecimento de evidncia objetiva, do atendimento aos requisitos especificados.
NOTAS 1 Nas atividades de projeto e desenvolvimento, a verificao refere-se ao processo de examinar o resultado de dada atividade para determinar sua conformidade com os requisitos estabelecidos para a mesma atividade. 2 O termo verificado usado para designar o estado aps a verificao. [NBR ISO 8402:1994, 2.17]
4) Processo de operao (subseo 5.4). Define as atividades do operador, organizao que prov servio de operao de um sistema computacional, no seu ambiente de funcionamento, para seus usurios. 5) Processo de manuteno (subseo 5.5). Define as atividades do mantenedor, organizao que prov o servio de manuteno do produto de software, isto , gerenciando as modificaes no produto de software para mant-lo atualizado e em perfeita operao. Este processo inclui a migrao e a descontinuao do produto de software.
4.1.1.2 Processos de apoio de ciclo de vida
3.37 verso: Instncia identificada de um item.

NOTA - Modificaes em uma verso de produto de software, resultando em uma nova verso, requerem uma ao de gerncia de configurao.
4 Aplicao desta Norma

Esta seo apresenta os processos de ciclo de vida de software que podem ser empregados para adquirir, fornecer, desenvolver, operar e manter produtos de software. O objetivo prover um guia para os usurios desta Norma para que eles possam orientar-se na mesma e aplic-la criteriosamente. 4.1 Organizao desta Norma
4.1.1 Processos de ciclo de vida
Os processos de apoio de ciclo de vida (seo 6) constituem um conjunto de oito processos. Um processo de apoio auxilia um outro processo como uma parte integrante, com um propsito distinto, e contribui para o sucesso e qualidade do projeto de software. Um processo de apoio empregado e executado, quando necessrio, por outro processo. Os processos de apoio so: 1) Processo de documentao (subseo 6.1). Define as atividades para registro da informao produzida por um processo de ciclo de vida. 2) Processo de gerncia de configurao (subseo 6.2). Define as atividades de gerncia de configurao. 3) Processo de garantia da qualidade (subseo 6.3). Define as atividades para garantir objetivamente que os produtos e processos de software esto em conformidade com seus requisitos especificados e aderem aos seus planos estabelecidos. Revises conjuntas, auditorias, verificao e validao podem ser utilizadas como tcnicas para garantia da qualidade. 4) Processo de verificao (subseo 6.4). Define as atividades (para o adquirente, o fornecedor, ou uma parte independente) para verificao dos produtos de software, em profundidade varivel, dependendo do projeto de software. 5) Processo de validao (subseo 6.5). Define as atividades (para o adquirente, o fornecedor ou uma parte independente) para validao dos produtos de software do projeto de software. 6) Processo de reviso conjunta (subseo 6.6). Define as atividades para avaliao da situao e produtos de uma atividade. Este processo pode ser empregado por qualquer uma das duas partes, onde uma delas (parte revisora) revisa a outra parte (parte revisada) em um frum conjunto. 7) Processo de auditoria (subseo 6.7). Define as atividades para determinar a conformidade com requisitos, planos e contrato. Este processo pode ser empregado por qualquer uma das duas partes, onde uma delas (parte auditora) audita os produtos de software ou atividades da outra parte (parte auditada). 8) Processo de resoluo de problema (subseo 6.8). Define um processo para anlise e remoo dos problemas (incluindo no-conformidades), independente da sua natureza ou origem, que forem descobertos durante a execuo dos processos de desenvolvimento, de operao, de manuteno ou de outros processos.
Esta Norma agrupa as atividades que podem ser executadas durante o ciclo de vida de software em cinco processos fundamentais, oito processos de apoio e quatro processos organizacionais. Cada processo de ciclo de vida dividido em um conjunto de atividades; cada atividade ento dividida em um conjunto de tarefas. Uma seo numerada por a.b denota um processo, a.b.c uma atividade e a.b.c.d uma tarefa. Estes processos de ciclo de vida so introduzidos a seguir e ilustrados na figura 1.
4.1.1.1 Processos fundamentais de ciclo de vida
Os processos fundamentais de ciclo de vida (seo 5) constituem um conjunto de cinco processos que atendem as partes fundamentais (pessoa ou organizao) durante o ciclo de vida de software. Uma parte fundamental aquela que inicia ou executa o desenvolvimento, operao ou manuteno dos produtos de software. Estas partes fundamentais so o adquirente, o fornecedor, o desenvolvedor, o operador e o mantenedor do software. Os processos fundamentais so: 1) Processo de aquisio (subseo 5.1). Define as atividades do adquirente, organizao que adquire um sistema, produto de software ou servio de software. 2) Processo de fornecimento (subseo 5.2). Define as atividades do fornecedor, organizao que prov o sistema, produto de software ou servio de software ao adquirente. 3) Processo de desenvolvimento (subseo 5.3). Define as atividades do desenvolvedor, organizao que define e desenvolve o produto de software.
Cpia no autorizada
5. Processos fundamentais de ciclo de vida 5.1 Aquisio
6. Processos de apoio de ciclo de vida 6.1 Documentao
5.2 Fornecimento
6.2 Gerncia de configurao
6.3 Garantia de qualidade 5.4 Operao 6.4 Verificao
5.3 Desenvolvimento
6.5 Validao
5.5 Manuteno
6.6 Reviso conjunta
6.7 Auditoria
6.8 Resoluo de problema
7. Processos organizacionais de ciclo de vida 7.1 Gerncia 7.2 Infra-estrutura
7.3 Melhoria
7.4 Treinamento
Figura 1 - Estrutura desta Norma

4.1.1.3 Processos organizacionais de ciclo de vida
Os processos organizacionais de ciclo de vida (seo 7) constituem um conjunto de quatro processos. Eles so empregados por uma organizao para estabelecer e implementar uma estrutura subjacente, constituda de processos de ciclo de vida e pessoal associados, e melhorar continuamente a estrutura e os processos. Eles so tipicamente empregados fora do domnio de projetos e contratos especficos; entretanto, ensinamentos destes projetos e contratos contribuem para a melhoria da organizao. Os processos organizacionais so: 1) Processo de gerncia (subseo 7.1). Define as atividades bsicas da gerncia, incluindo gerncia de projeto, durante um processo de ciclo de vida. 2) Processo de infra-estrutura (subseo 7.2). Define as atividades bsicas para o estabelecimento da estrutura de apoio de um processo de ciclo de vida.
3) Processo de melhoria (subseo 7.3). Define as atividades bsicas que uma organizao (isto , adquirente, fornecedor, desenvolvedor, operador, mantenedor, ou o gerente de outro processo) executa para estabelecer, medir, controlar e melhorar seu processo de ciclo de vida. 4) Processo de treinamento (subseo 7.4). Define as atividades para prover pessoal adequadamente treinado.
4.1.2 Processo de adaptao
O anexo A define as atividades bsicas necessrias para executar as adaptaes desta Norma. O anexo B contm orientao para a adaptao dos requisitos desta Norma; ele relaciona os fatores-chave sobre os quais as decises de adaptao podem ser feitas.
Cpia no autorizada
4.1.3 Relacionamento entre os processos e as organizaes
5.1.1 Iniciao - Esta atividade consiste nas seguintes
tarefas: Esta Norma contm vrios processos que so aplicados ao longo de ciclo de vida de software por vrias organizaes, dependendo de suas necessidades e objetivos. Para melhor esclarecimento, o anexo C apresenta os relacionamentos entre os processos de ciclo de vida e as partes envolvidas.
5.1.1.1 O adquirente inicia o processo de aquisio pela
descrio de um conceito ou de uma necessidade em adquirir, desenvolver ou melhorar um sistema, produto de software ou servio de software.
5.1.1.2 O adquirente dever definir e analisar os requisitos
5 Processos fundamentais de ciclo de vida

Este captulo define os seguintes processos fundamentais de ciclo de vida: 1) Processo de aquisio; 2) Processo de fornecimento; 3) Processo de desenvolvimento; 4) Processo de operao; 5) Processo de manuteno. As atividades e as tarefas em um processo fundamental so de responsabilidade da organizao que inicia e executa este processo. Esta organizao assegura a existncia e a funcionalidade do processo. 5.1 Processo de aquisio O processo de aquisio contm as atividades e tarefas do adquirente. Inicia-se com a definio da necessidade de adquirir um sistema, um produto de software ou um servio de software. O processo continua com a preparao e emisso de pedido de proposta, seleo de fornecedor e gerncia do processo de aquisio atravs da aceitao do sistema, produto de software ou servio de software. A organizao individual, que tem a necessidade, pode ser chamada de proprietria. O proprietrio pode contratar algumas ou todas as atividades de aquisio junto a um agente que, por sua vez, conduzir estas atividades de acordo com o processo de aquisio. O adquirente nesta subseo pode ser tanto o proprietrio quanto o agente contratado por ele. O adquirente gerencia o processo de aquisio em nvel de projeto, seguindo o processo de gerncia (7.1), o qual passa a existir nesse processo; estabelece uma infraestrutura sob o projeto, seguindo o processo de infraestrutura (7.2); adapta o processo para o projeto, seguindo o processo de adaptao (anexo A); e gerencia o processo em nvel organizacional, seguindo o processo de melhoria (7.3) e o processo de treinamento (7.4). Lista de atividades - Este processo consiste nas seguintes atividades: 1) Iniciao; 2) Preparao de pedido de proposta; 3) Preparao e atualizao do contrato; 4) Monitorao do fornecedor; 5) Aceitao e concluso.
do sistema. Estes requisitos devem incluir requisitos de negcio, organizacionais e de usurio, bem como de segurana, proteo e outros requisitos crticos relacionados s atividades de projeto, testes e aderncia a padres e procedimentos.
5.1.1.3 Se o adquirente mantiver acordo com um fornecedor para a execuo da anlise dos requisitos de um sistema, o adquirente dever aprovar estes requisitos. 5.1.1.4 O adquirente pode executar a definio e a anlise
dos requisitos do software por conta prpria ou pode manter acordo com um fornecedor para executar essa tarefa.
5.1.1.5 O processo de desenvolvimento (5.3) deveria ser
usado para executar as tarefas de 5.1.1.2 e 5.1.1.4.

5.1.1.6 O adquirente dever considerar opes para aquisio atravs de uma anlise, com critrios apropriados, incluindo risco, custo e benefcios para cada opo. As opes incluem:
a) Comprar um produto de software de prateleira que satisfaa os requisitos; b) Internamente desenvolver o produto de software ou obter o servio de software; c) Atravs de contrato, desenvolver o produto de software ou obter o servio de software; d) Uma combinao dos itens a, b e c acima; e) Melhorar um produto ou servio de software existente.
5.1.1.7 Para a aquisio de um produto de software de
prateleira, o adquirente dever assegurar que as seguintes condies sejam satisfeitas: a) Os requisitos do produto de software sejam satisfeitos; b) A documentao esteja disponvel; c) Os direitos de propriedade, de uso, de autoria, de garantia e de licena sejam satisfeitos; d) O suporte futuro para o produto de software esteja planejado.
Cpia no autorizada
5.1.1.8 O adquirente deveria preparar, documentar e executar um plano de aquisio. O plano deveria conter o seguinte:
5.1.3 Preparao e atualizao do contrato. Esta atividade
consiste nas seguintes tarefas:

5.1.3.1 O adquirente deveria estabelecer um procedi-
a) Requisitos para o sistema; b) Emprego planejado para o sistema; c) Tipo de contrato a ser empregado; d) Responsabilidades das organizaes envolvidas; e) Conceito de suporte a ser usado; f) Riscos considerados, assim como mtodos para gerenci-los.
5.1.1.9 O adquirente deveria definir e documentar a estratgia e condies (critrios) de aceitao. 5.1.2 Preparao de pedido de proposta. Esta atividade
mento para selecionar o fornecedor, incluindo critrios de avaliao de proposta e ponderao da aderncia aos requisitos.
5.1.3.2 O adquirente deveria selecionar um fornecedor
baseado na avaliao das propostas dos fornecedores, capacidades e outros fatores que precisam ser considerados.
5.1.3.3 O adquirente pode envolver outras partes, incluindo fornecedores potenciais, antes do fechamento do contrato, durante a adaptao desta Norma ao projeto. Entretanto, o adquirente dever tomar a deciso final sobre esta adaptao. O adquirente dever incluir ou referenciar a Norma adaptada no contrato. 5.1.3.4 O adquirente dever, ento, preparar e negociar

5.1.2.1 O adquirente deveria documentar os requisitos de
aquisio (exemplo: pedido de proposta) cujo contedo depende da opo de aquisio selecionada em 5.1.1.6. A documentao de aquisio deveria incluir, quando apropriado: a) Requisitos do sistema; b) Declarao do escopo; c) Instrues para os proponentes; d) Lista de produtos de software; e) Termos e condies; f) Controle dos subcontratos; g) Restries tcnicas (exemplo: ambiente-alvo).
5.1.2.2 O adquirente deveria determinar quais processos,
um contrato com o fornecedor que trate dos requisitos de aquisio, incluindo o custo e cronograma do produto ou servio de software a ser entregue. O contrato dever tratar direitos de uso, de propriedade, de autoria, de garantia e de licena, associados com os produtos de software de prateleira reusveis.
5.1.3.5 Estando o contrato em andamento, o adquirente
dever controlar alteraes no contrato atravs de negociao com o fornecedor, como parte do mecanismo de controle de alterao. Alteraes no contrato devero ser investigadas quanto ao impacto nos planos, custos, benefcios, qualidade e cronograma do projeto.
NOTA - O adquirente determina se o termo contrato ou acordo ser utilizado na aplicao desta Norma. 5.1.4 Monitorao do fornecedor. Esta atividade consiste
nas seguintes tarefas:

5.1.4.1 O adquirente dever monitorar as atividades do
fornecedor de acordo com o processo de reviso conjunta (6.6) e com o processo de auditoria (6.7). O adquirente deveria complementar a monitorao com o processo de verificao (6.4) e com o processo de validao (6.5), quando necessrio.
5.1.4.2 O adquirente dever cooperar com o fornecedor
atividades e tarefas desta Norma so apropriados para o projeto e deveria adapt-los, quando necessrio. Especialmente, o adquirente deveria especificar os processos de apoio aplicveis (seo 6) e suas organizaes executoras, incluindo responsabilidades (se outras alm do fornecedor), para que os fornecedores possam, em suas propostas, definir como abordar cada um dos processos de apoio especificados. O adquirente dever definir o escopo daquelas tarefas que referenciam o contrato.
5.1.2.3 A documentao de aquisio tambm dever
para prover toda a informao necessria no momento oportuno e resolver todos os itens pendentes.
5.1.5 Aceitao e concluso. Esta atividade consiste nas
seguintes tarefas:
5.1.5.1 O adquirente deveria preparar-se para aceitao
definir no contrato os pontos de controle nos quais o progresso do fornecimento dever ser revisado e auditado como parte da monitorao da aquisio (ver 6.6 e 6.7).
5.1.2.4 Os requisitos de aquisio deveriam ser fornecidos
baseado na estratgia e nos critrios de aceitao definidos. A preparao de casos de teste, dados de teste, procedimentos de teste e ambiente de teste deveria estar includa. A abrangncia do envolvimento do fornecedor deveria ser definida.
5.1.5.2 O adquirente dever conduzir a reviso de
organizao selecionada para executar as atividades de aquisio.
aceitao e teste de aceitao do produto ou servio de software a ser entregue e dever aceit-lo do fornecedor quando todas as condies de aceitao forem satisfeitas. O procedimento de aceitao deveria obedecer ao estabelecido em 5.1.1.9.
Cpia no autorizada
5.1.5.3 Aps a aceitao, o adquirente deveria assumir a
5.2.3 Contrato. Esta atividade consiste nas seguintes
responsabilidade pela gerncia de configurao do produto de software entregue (ver 6.2).

NOTA - O adquirente pode instalar o produto de software ou executar o servio de software de acordo com as instrues definidas pelo fornecedor.
tarefas:
5.2.3.1 O fornecedor deve negociar e firmar o contrato
com a organizao adquirente para fornecer o produto ou servio de software.

5.2.3.2 O fornecedor pode solicitar modificao no contrato como parte do mecanismo de controle de alterao. 5.2.4 Planejamento.
5.2 Processo de fornecimento O processo de fornecimento contm as atividades e as tarefas do fornecedor. O processo pode ser iniciado tanto por uma deciso de preparar uma proposta para responder a um pedido de proposta de um adquirente quanto pela assinatura e celebrao de um contrato com o adquirente para fornecer o sistema, produto de software ou servio de software. O processo continua com a determinao dos procedimentos e recursos necessrios para gerenciar e garantir o projeto, incluindo o desenvolvimento e a execuo dos planos de projeto at a entrega do sistema, produto de software ou servio de software para o adquirente. O fornecedor gerencia o processo de fornecimento em nvel de projeto, seguindo o processo de gerncia (7.1), o qual passa a existir nesse processo; estabelece uma infra-estrutura sob o processo, seguindo o processo de infra-estrutura (7.2); adapta o processo para o projeto, seguindo o processo de adaptao (anexo A); e gerencia o processo em nvel organizacional, seguindo o processo de melhoria (7.3) e o processo de treinamento (7.4). Lista de atividades. Este processo consiste nas seguintes atividades: 1) Iniciao; 2) Preparao de resposta; 3) Contrato; 4) Planejamento; 5) Execuo e controle; 6) Reviso e avaliao; 7) Entrega e concluso.
5.2.1 Iniciao. Esta atividade consiste nas seguintes
Esta atividade consiste nas seguin-
tes tarefas:
5.2.4.1 O fornecedor deve conduzir uma reviso dos requisitos de aquisio, para definir a estrutura para gerenciar e garantir o projeto e para garantir a qualidade do produto ou servio de software a ser entregue. 5.2.4.2 Se no estiver estipulado no contrato, o fornecedor
deve definir ou selecionar um modelo de ciclo de vida de software apropriado para o escopo, magnitude e complexidade do projeto. Os processos, atividades e tarefas desta Norma devem ser selecionados e mapeados no modelo de ciclo de vida.
5.2.4.3 O fornecedor deve estabelecer requisitos para os
planos, para gerenciar e garantir o projeto e para garantir a qualidade do produto ou servio de software a ser entregue. Requisitos para os planos deveriam incluir necessidades de recursos e o envolvimento do adquirente.
5.2.4.4 Uma vez estabelecidos os requisitos de plane-
jamento, o fornecedor deve considerar as opes para o desenvolvimento do produto de software ou proviso do servio de software, a partir de uma anlise dos riscos associados a cada uma das opes. As opes incluem: a) Desenvolver o produto de software ou prover o servio de software usando recursos internos; b) Desenvolver o produto de software ou prover o servio de software atravs de subcontratao; c) Obter produtos de software de prateleira a partir de fontes internas ou externas; d) Uma combinao de a, b e c anteriores.
5.2.4.5 O fornecedor deve desenvolver e documentar o(s)
tarefas:
5.2.1.1 O fornecedor conduz uma reviso dos requisitos
que constam no pedido de proposta, levando em considerao polticas e outros regulamentos da organizao.
5.2.1.2 O fornecedor deveria decidir entre propor ou aceitar o contrato. 5.2.2 Preparao de resposta. Esta atividade consiste na
plano(s) de gerncia do projeto de acordo com os requisitos de planejamento e as opes selecionadas em 5.2.4.4. Os itens a serem considerados no plano no se limitam a, mas incluem o seguinte: a) Estrutura organizacional do projeto, autoridade e responsabilidade de cada unidade organizacional, incluindo organizaes externas; b) Ambiente de engenharia (para desenvolvimento, operao ou manuteno, quando aplicvel), incluindo ambiente de teste, biblioteca, equipamento, instalaes, padres, procedimentos e ferramentas;
seguinte tarefa:
5.2.2.1 O fornecedor deveria definir e preparar uma
proposta em resposta ao pedido de proposta, incluindo sua recomendao da adaptao desta Norma.
Cpia no autorizada
10
c) Estrutura de diviso de trabalho dos processos e atividades de ciclo de vida, incluindo os produtos de software, servios de software e itens que no sero entregues, a ser executada de acordo com os oramentos, pessoal, recursos fsicos, tamanho do software e cronogramas associados s tarefas; d) Gerenciamento das caractersticas da qualidade dos produtos ou servios de software. Planos para qualidade podem ser desenvolvidos em separado; e) Gerenciamento de proteo, segurana e outros requisitos crticos dos produtos ou servios de software. Planos para proteo e segurana podem ser desenvolvidos em separado; f) Gerenciamento do subcontratado, incluindo a sua seleo e o seu envolvimento com o adquirente, se houver; g) Garantia da qualidade (ver 6.3); h) Verificao (ver 6.4) e validao (ver 6.5) incluindo a abordagem para a interao com o agente de verificao e validao, se especificado; i) Envolvimento do adquirente, isto , atravs de revises conjuntas (ver 6.6), auditorias (ver 6.7), reunies informais, relatrios, modificao e alterao; implementao, aprovao, aceitao e acesso s instalaes; j) Envolvimento do usurio, atravs de exerccios de consolidao de requisitos, demonstraes de prottipos e avaliaes; k) Gerenciamento de risco: gerenciamento das reas do projeto que envolvem potenciais riscos tcnicos, de custo e de cronograma; l) Poltica de segurana: as regras para gesto e acesso s informaes em cada nvel organizacional do projeto; m) Aprovao requerida atravs de regulamentos, certificaes, direitos de propriedade, de uso, de autoria, de garantia e de licena; n) Meios para elaborar cronogramas, realizar acompanhamento e elaborar relatrios; o) Treinamento de pessoal (ver 7.4).
5.2.5 Execuo e controle.
5.2.5.3 O fornecedor deve monitorar e controlar o pro-
gresso e a qualidade dos produtos ou servios de software do projeto atravs do ciclo de vida contratado. Esta deve ser uma tarefa contnua e iterativa que deve servir para: a) Monitorao do progresso do desempenho tcnico, de custos e de cronogramas, e o relato da situao do projeto; b) Identificao, registro, anlise e resoluo de problema.
5.2.5.4 O fornecedor deve gerenciar e controlar os subcon-
tratados de acordo com o processo de aquisio (5.1). O fornecedor deve verificar todos os requisitos contratuais necessrios, para assegurar que o produto ou servio de software entregue ao adquirente foi desenvolvido ou executado de acordo com os requisitos do contrato original.
5.2.5.5 O fornecedor deve
interagir com os agentes independentes de verificao, validao ou testes, conforme especificado no contrato e nos planos do projeto.
5.2.5.6 O fornecedor deve interagir com outras partes,
conforme especificado no contrato e nos planos do projeto.

5.2.6 Reviso e avaliao. Esta atividade consiste nas se-
guintes tarefas:
5.2.6.1 O fornecedor deveria coordenar as atividades de
reviso do contrato, interaes e comunicao com a organizao do adquirente.

5.2.6.2 O fornecedor deve conduzir ou dar suporte s reunies informais, reviso de aceitao, teste de aceitao, revises conjuntas e auditorias com o adquirente conforme especificado no contrato e planos do projeto. As revises conjuntas devem ser conduzidas de acordo com 6.6 e as auditorias de acordo com 6.7. 5.2.6.3 O fornecedor deve executar a verificao e a
Esta atividade consiste nas
seguintes tarefas:
5.2.5.1 O fornecedor deve implementar e executar o(s)
validao, de acordo com 6.4 e 6.5, respectivamente, para demonstrar que os produtos ou servios de software e os processos satisfazem completamente os seus respectivos requisitos.
5.2.6.4 O fornecedor deve disponibilizar ao adquirente os relatrios de avaliao, revises, auditorias, testes e resoluo de problemas, conforme especificado no contrato. 5.2.6.5 O fornecedor deve prover ao adquirente acesso
plano(s) de gerenciamento do projeto desenvolvido(s) em 5.2.4.

5.2.5.2 O fornecedor deve:
a) Desenvolver o produto de software de acordo com o processo de desenvolvimento (5.3); b) Operar o produto de software de acordo com o processo de operao (5.4); c) Manter o produto de software de acordo com o processo de manuteno (5.5).
aos recursos do fornecedor e dos subcontratados, para a reviso dos produtos ou servios de software, conforme especificado no contrato e planos do projeto.
5.2.6.6 O fornecedor deve executar atividades de garantia
da qualidade, de acordo com 6.3.
Cpia no autorizada
11
5.2.7 Entrega e concluso.
Esta atividade consiste nas
5.3.1.2 O desenvolvedor deve:
seguintes tarefas:
5.2.7.1 O fornecedor deve entregar o produto ou servio
de software, conforme especificado no contrato.

5.2.7.2 O fornecedor deve prover assistncia ao adquirente
a) Documentar os resultados, de acordo com o processo de documentao (6.1); b) Colocar os resultados sob o processo de gerncia de configurao (6.2) e executar controle de alteraes, de acordo com ele; c) Documentar e resolver problemas e no-conformidades encontrados nos produtos de software e tarefas, de acordo com o processo de resoluo de problema (6.8); d) Executar os processos de apoio (seo 6), conforme especificado no contrato.
5.3.1.3 O desenvolvedor deve selecionar, adaptar e utilizar
no suporte do produto ou servio de software entregue, conforme especificado no contrato. 5.3 Processo de desenvolvimento O processo de desenvolvimento contm as atividades e tarefas do desenvolvedor. O processo contm as atividades para anlise de requisitos, projeto, codificao, integrao, testes, instalao e aceitao relacionada aos produtos de software. Pode conter atividades relacionadas ao sistema, se estipulado no contrato. O desenvolvedor executa ou apia as atividades neste processo, de acordo com o contrato. O desenvolvedor gerencia o processo de desenvolvimento em nvel de projeto, seguindo o processo de gerncia (7.1), o qual passa a existir nesse processo; estabelece uma infra-estrutura sob o processo, seguindo o processo de infra-estrutura (7.2); adapta o processo para o projeto, seguindo o processo de adaptao (anexo A); e gerencia o processo em nvel organizacional, seguindo o processo de melhoria (7.3) e o processo de treinamento (7.4). Quando o desenvolvedor o fornecedor do produto de software desenvolvido, o desenvolvedor executa o processo de fornecimento (5.2). Lista de atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Anlise dos requisitos do sistema; 3) Projeto da arquitetura do sistema; 4) Anlise dos requisitos do software; 5) Projeto da arquitetura do software; 6) Projeto detalhado do software; 7) Codificao e testes do software; 8) Integrao do software; 9) Teste de qualificao do software; 10) Integrao do sistema; 11) Teste de qualificao do sistema; 12) Instalao do software; 13) Apoio aceitao do software.
5.3.1 Implementao do processo. Esta atividade consiste
estes padres, mtodos, ferramentas e linguagens de programao de computador (se no estipulados no contrato) que sejam documentados, apropriados e estabelecidos pela organizao, para executar as atividades do processo de desenvolvimento e dos processos de apoio (seo 6).
5.3.1.4 O desenvolvedor deve desenvolver planos para
conduzir as atividades do processo de desenvolvimento. Os planos deveriam incluir padres especficos, mtodos, ferramentas, aes e responsabilidades associados com o desenvolvimento e qualificao de todos os requisitos, incluindo proteo e segurana. Se necessrio, planos em separado podem ser elaborados. Estes planos devem ser documentados e executados.
5.3.1.5 Itens que no sero entregues podem ser empre-
gados no desenvolvimento ou manuteno do produto de software. Entretanto, deve ser assegurado que a operao e manuteno do produto de software a ser entregue, depois de sua liberao ao adquirente, so independentes daqueles itens; caso contrrio, estes itens deveriam ser considerados como a ser entregues.
5.3.2 Anlise dos requisitos do sistema. Esta atividade consiste nas seguintes tarefas, as quais o desenvolvedor deve executar ou apoiar conforme especificado no contrato: 5.3.2.1 O uso especfico pretendido do sistema a ser de-
na seguinte tarefa:
5.3.1.1 Se no estipulado no contrato, o desenvolvedor
senvolvido deve ser analisado para especificar os requisitos do sistema. A especificao dos requisitos do sistema deve descrever: funes e capacidades do sistema; requisitos de negcio, organizacionais e de usurios; requisitos de proteo, de segurana, de engenharia de fatores humanos (ergonomia), de interface, de operaes e de manuteno; restries de projeto e requisitos de qualificao. A especificao dos requisitos do sistema deve ser documentada.
5.3.2.2 Os requisitos do sistema devem ser avaliados,
deve definir ou selecionar um modelo de ciclo de vida de software apropriado ao escopo, magnitude e complexidade do projeto. As atividades e tarefas do processo de desenvolvimento devem ser selecionadas e mapeadas no modelo de ciclo de vida.
NOTA - Estas atividades e tarefas podem se sobrepor ou interagir e podem ser executadas iterativa ou recursivamente.
considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados. a) Rastreabilidade para as necessidades de aquisio; b) Consistncia com as necessidades de aquisio;
Cpia no autorizada
12
c) Testabilidade; d) Viabilidade do projeto da arquitetura do sistema; e) Viabilidade da operao e manuteno.

5.3.3 Projeto da arquitetura do sistema. Esta atividade
e) Especificaes de segurana, incluindo aquelas relacionadas com o comprometimento de informaes sigilosas; f) Especificaes de engenharia de fatores humanos (ergonomia), incluindo aquelas relacionadas com operaes manuais, interaes entre homemmquina, restries a pessoal e reas que necessitam de maior ateno humana, que so sensveis a erros humanos e treinamento; g) Definio de dados e requisitos de bases de dados; h) Requisitos de instalao e aceitao do produto de software entregue no(s) local(ais) de operao e manuteno; i) Documentao do usurio; j) Requisitos do usurio para execuo e operao; k) Requisitos do usurio para manuteno.
5.3.4.2 O desenvolvedor deve avaliar os requisitos do software considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados.
consiste nas seguintes tarefas, as quais o desenvolvedor deve executar ou apoiar conforme especificado no contrato:
5.3.3.1 Uma arquitetura de alto nvel do sistema deve ser
estabelecida. A arquitetura deve identificar itens de hardware, software e operaes manuais. Deve ser assegurado que todos os requisitos do sistema sejam alocados entre os itens. Itens de configurao de hardware, itens de configurao de software e operaes manuais devem ser subseqentemente identificados, a partir destes itens. A arquitetura do sistema e os requisitos do sistema alocados aos itens devem ser documentados.
5.3.3.2 A arquitetura do sistema e os requisitos para os
itens devem ser avaliados, considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados. a) Rastreabilidade para os requisitos do sistema; b) Consistncia com os requisitos do sistema; c) Adequao dos mtodos e padres de projeto utilizados; d) Viabilidade de os itens de software atenderem seus requisitos alocados; e) Viabilidade da operao e da manuteno.
5.3.4 Anlise dos requisitos do software. Esta atividade
a) Rastreabilidade para os requisitos do sistema e projeto do sistema; b) Consistncia externa com os requisitos do sistema; c) Consistncia interna; d) Testabilidade; e) Viabilidade do projeto do software; f) Viabilidade da operao e manuteno.
5.3.4.3 O desenvolvedor deve conduzir reviso(es)
deve ser realizada para cada item de software (ou item de configurao de software, se identificado) e consiste nas seguintes tarefas:
5.3.4.1 O desenvolvedor deve estabelecer e documentar
os requisitos do software, incluindo as especificaes das caractersticas de qualidade descritas a seguir. Um guia para especificar as caractersticas de qualidade pode ser encontrado na ISO/IEC 9126 2) - Information technology - Software product evaluation - Quality characteristics and guidelines for their use. a) Especificaes funcionais e de capacidade, incluindo desempenho, caractersticas fsicas e condies do ambiente sob o qual o item de software ser executado; b) Interfaces externas ao item de software; c) Requisitos de qualificao;
conjunta(s), de acordo com a seo 6.6. Sendo bem sucedidas as concluses da(s) reviso(es), uma linha bsica (baseline) para os requisitos do item de software deve ser estabelecida.
5.3.5 Projeto da arquitetura do software. Esta atividade
deve ser realizada para cada item de software (ou item de configurao de software, se identificado) e consiste nas seguintes tarefas:
5.3.5.1 O desenvolvedor deve transformar os requisitos
para o item de software em uma arquitetura que descreve sua estrutura de alto nvel e identifica os componentes de software. Deve ser garantido que todos os requisitos do item de software sejam alocados aos seus componentes de software e, mais adiante, sejam refinados para facilitar o projeto detalhado. A arquitetura do item de software deve ser documentada.
5.3.5.2 O desenvolvedor deve desenvolver e documentar
d) Especificaes de proteo, incluindo aquelas relacionadas aos mtodos de operao e manuteno, influncias do ambiente e danos pessoais;
2)
um projeto de alto nvel para as interfaces externas ao item de software e entre os componentes de software do item de software.
Utilizar a NBR 13596.
Cpia no autorizada
13
5.3.6.6 O desenvolvedor deve atualizar os requisitos de
um projeto de alto nvel para a base de dados.

5.3.5.4 O desenvolvedor deveria desenvolver e documentar verses preliminares da documentao do usurio. 5.3.5.5 O desenvolvedor deve definir e documentar os
teste e o cronograma para a integrao do software.

5.3.6.7 O desenvolvedor deve avaliar o projeto detalhado
do software e requisitos de teste, considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados. a) Rastreabilidade para os requisitos do item de software; b) Consistncia externa com o projeto da arquitetura; c) Consistncia interna entre componentes e unidades de software; d) Adequao dos mtodos e padres de projeto utilizados; e) Viabilidade dos testes;
requisitos preliminares de teste e o cronograma para a integrao do software.

5.3.5.6 O desenvolvedor deve avaliar a arquitetura do item
de software e os projetos de interface e base de dados, considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados. a) Rastreabilidade para os requisitos do item de software; b) Consistncia externa com os requisitos do item de software; c) Consistncia interna entre os componentes de software; d) Adequao dos mtodos e padres utilizados; e) Viabilidade do projeto detalhado; f) Viabilidade da operao e manuteno.
5.3.5.7 O desenvolvedor deve conduzir reviso(es) conjunta(s), de acordo com a seo 6.6. 5.3.6 Projeto detalhado do software. Esta atividade deve
f) Viabilidade da operao e manuteno.

5.3.6.8 O desenvolvedor deve conduzir reviso(es)
conjunta(s), de acordo com a seo 6.6.

5.3.7 Codificao e testes do software. Esta atividade deve
de projeto
ser realizada para cada item de software (ou item de configurao de software, se identificado) e consiste nas seguintes tarefas:
o seguinte: a) Cada unidade de software e base de dados; b) Procedimentos de teste e dados para testar cada unidade de software e base de dados.
5.3.7.2 O desenvolvedor deve testar cada unidade de
ser realizada para cada item de software (ou item de configurao de software, se identificado) e consiste nas seguintes tarefas:
5.3.6.1 O desenvolvedor deve desenvolver um projeto
software e base de dados, garantindo que sejam atendidos seus requisitos. Os resultados dos testes devem ser documentados.
5.3.7.3 O desenvolvedor deve atualizar a documentao
detalhado para cada componente de software do item de software. Os componentes de software devem ser refinados em nveis mais baixos, contendo unidades de software que possam ser codificadas, compiladas e testadas. Deve ser garantido que todos os requisitos do software sejam alocados para unidades de software a partir dos componentes de software. O projeto detalhado deve ser documentado.
do usurio, quando necessrio.

5.3.7.4 O desenvolvedor deve atualizar os requisitos de
teste e o cronograma, para integrao do software.

5.3.7.5 O desenvolvedor deve avaliar o cdigo do
software e os resultados dos testes, considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados. a) Rastreabilidade para os requisitos e projeto do item de software; b) Consistncia externa com os requisitos e projeto do item de software; c) Consistncia interna entre os requisitos da unidade; d) Cobertura de teste das unidades; e) Adequao dos mtodos e padres de codificao utilizados; f) Viabilidade da integrao e testes do software; g) Viabilidade da operao e manuteno.
um projeto detalhado das interfaces externas ao item de software, entre os componentes de software e entre as unidades de software. O projeto detalhado das interfaces deve permitir a codificao sem a necessidade de informao adicional.
um projeto detalhado para a base de dados.


5.3.6.5 O desenvolvedor deve definir e documentar os
requisitos de teste e o cronograma para testar unidades de software. Os requisitos de teste deveriam incluir testes de estresse da unidade de software, at o limite de seus requisitos.
Cpia no autorizada
14
5.3.8 Integrao do software. Esta atividade deve ser realizada para cada item de software (ou item de configurao de software, se identificado) e consiste nas seguintes tarefas: 5.3.8.1 O desenvolvedor deve desenvolver um plano de

5.3.9.3 O desenvolvedor deve avaliar o projeto, cdigo,
integrao para integrar as unidades de software e componentes de software no item de software. O plano deve incluir requisitos de teste, procedimentos, dados, responsabilidades e cronograma. O plano deve ser documentado.
5.3.8.2 O desenvolvedor deve integrar as unidades e
testes, resultados dos testes e a documentao do usurio, considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados. a) Cobertura de teste dos requisitos do item de software; b) Conformidade com os resultados esperados; c) Viabilidade da integrao e testes do sistema, se conduzidos; d) Viabilidade da operao e manuteno.
5.3.9.4 O desenvolvedor deve apoiar auditorias, de acordo
componentes de software e testar essas agregaes medida que forem sendo integradas, de acordo com o plano de integrao. Deve ser garantido que cada agregao atenda os requisitos do item de software e que o item de software esteja integrado na concluso da atividade de integrao. Os resultados da integrao e dos testes devem ser documentados.

5.3.8.4 O desenvolvedor deve desenvolver e documentar,
com 6.7. Os resultados das auditorias devem ser documentados. Se ambos, hardware e software, esto sendo desenvolvidos e integrados, as auditorias podem ser adiadas at o teste de qualificao do sistema.
5.3.9.5 Uma vez bem sucedida a concluso das auditorias,
para cada requisito de qualificao do item de software, um conjunto de testes, casos de teste (entradas, sadas e critrios de teste) e procedimentos de teste, para conduzir o teste de qualificao do software. O desenvolvedor deve garantir que o item de software integrado est pronto para o teste de qualificao do software.
5.3.8.5 O desenvolvedor deve avaliar o plano de inte-
se conduzidas, o desenvolvedor deve: a) Atualizar e preparar o produto de software a ser entregue para a integrao do sistema, teste de qualificao do sistema, instalao do software ou apoio aceitao do software, quando aplicvel; b) Estabelecer uma linha bsica (baseline) para o projeto e cdigo do item de software.
NOTA - O teste de qualificao do software pode ser utilizado no processo de verificao (6.4) ou no processo de validao (6.5). 5.3.10 Integrao do sistema. Esta atividade consiste nas
grao, projeto, cdigo, testes, resultados dos testes e a documentao do usurio, considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados. a) Rastreabilidade para os requisitos do sistema; b) Consistncia externa com os requisitos do sistema; c) Consistncia interna; d) Cobertura de teste dos requisitos do item de software; e) Adequao dos mtodos e padres de teste utilizados; f) Conformidade com os resultados esperados; g) Viabilidade do teste de qualificao do software; h) Viabilidade da operao e manuteno.
5.3.8.6 O desenvolvedor deve conduzir reviso(es) conjunta(s), de acordo com a seo 6.6. 5.3.9 Teste de qualificao do software. Esta atividade deve ser realizada para cada item de software (ou item de configurao de software, se identificado) e consiste nas seguintes tarefas: 5.3.9.1 O desenvolvedor deve conduzir o teste de quali-
seguintes tarefas, as quais o desenvolvedor deve executar ou apoiar conforme especificado no contrato.
5.3.10.1 Os itens de configurao de software devem ser integrados ao sistema com itens de configurao de hardware , com operaes manuais e com outros sistemas, quando necessrio. As agregaes devem ser testadas, quando forem integradas, de acordo com seus requisitos. A integrao e resultados dos testes devem ser documentados. 5.3.10.2 Para cada requisito de qualificao do sistema,
um conjunto de testes, casos de teste (entradas, sadas e critrios de teste) e procedimentos de teste para conduzir o teste de qualificao do sistema deve ser desenvolvido e documentado. O desenvolvedor deve garantir que o sistema integrado est pronto para o teste de qualificao do sistema.
5.3.10.3 O sistema integrado deve ser avaliado, considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados.
a) Cobertura de teste dos requisitos do sistema; b) Adequao dos mtodos e padres de teste utilizados; c) Conformidade com os resultados esperados;
ficao de acordo com os requisitos de qualificao para o item de software. Deve ser garantido que a implementao de cada requisito do software seja testada para conformidade. Os resultados do teste de qualificao devem ser documentados.
Cpia no autorizada
15
d) Viabilidade do teste de qualificao do sistema; e) Viabilidade da operao e manuteno.

5.3.11 Teste de qualificao do sistema. Esta atividade
5.3.12.2 O desenvolvedor deve instalar o produto de
consiste nas seguintes tarefas, as quais o desenvolvedor deve executar ou apoiar conforme especificado no contrato.
5.3.11.1 O teste de qualificao do sistema deve ser conduzido de acordo com os requisitos de qualificao especificados para o sistema. Deve ser garantido que a implementao de cada requisito do sistema seja testada, para conformidade, e que o sistema est pronto para ser entregue. Os resultados do teste de qualificao devem ser documentados. 5.3.11.2 O sistema deve ser avaliado considerando os critrios listados a seguir. Os resultados das avaliaes devem ser documentados.
software de acordo com o plano de instalao. Deve ser assegurado que o cdigo do software e as bases de dados sejam iniciados, executados e finalizados, conforme especificado no contrato. Os eventos e resultados da instalao devem ser documentados.
5.3.13 Apoio aceitao do software. Esta atividade

5.3.13.1 O desenvolvedor deve apoiar a reviso de aceitao do adquirente e testes do produto de software. A reviso de aceitao e testes deve considerar os resultados de revises conjuntas (6.6), auditorias (6.7), teste de qualificao do software e teste de qualificao do sistema (se executado). Os resultados da reviso de aceitao e teste devem ser documentados. 5.3.13.2 O desenvolvedor deve concluir e entregar o
produto de software, conforme especificado no contrato.

5.3.13.3 O desenvolvedor deve prover treinamento inicial
a) Cobertura de teste dos requisitos do sistema; b) Conformidade com os resultados esperados; c) Viabilidade da operao e manuteno.
5.3.11.3 O desenvolvedor deve apoiar auditorias, de
e contnuo e suporte ao adquirente, conforme especificado no contrato. 5.4 Processo de operao O processo de operao contm as atividades e as tarefas do operador. O processo cobre a operao do produto de software e o suporte operacional aos usurios. Como a operao do produto de software est integrada operao do sistema, as atividades e tarefas deste processo se referem ao sistema. O operador gerencia o processo de operao em nvel do projeto, seguindo o processo de gerncia (7.1), o qual passa a existir nesse processo; estabelece uma infraestrutura sob o processo, seguindo o processo de infraestrutura (7.2); adapta o processo para o projeto, seguindo o processo de adaptao (anexo A); e gerencia o processo em nvel organizacional, seguindo o processo de melhoria (7.3) e o processo de treinamento (7.4). Quando o operador o fornecedor do servio de operao, o operador executa o processo de fornecimento (5.2). Lista de atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo;
acordo com 6.7. Os resultados das auditorias devem ser documentados.

NOTA - Esta tarefa no aplicvel para aqueles itens de configurao de software cujas auditorias foram conduzidas previamente. 5.3.11.4 Uma vez bem sucedida a concluso das auditorias, se conduzidas, o desenvolvedor deve:
a) Atualizar e preparar o produto de software a ser entregue para a instalao do software e para o apoio aceitao do software; b) Estabelecer uma linha bsica (baseline) para o projeto e cdigo de cada item de configurao de software.
NOTA - O teste de qualificao do sistema pode ser utilizado no processo de verificao (6.4) ou no processo de validao (6.5). 5.3.12 Instalao do software. Esta atividade consiste nas
seguintes tarefas:
5.3.12.1 O desenvolvedor deve desenvolver um plano
2) Teste operacional; 3) Operao do sistema; 4) Suporte ao usurio.

para instalar o produto de software no ambiente-alvo, conforme designado no contrato. Os recursos e informaes necessrios para instalar o produto de software devem ser determinados e estar disponveis. Quando especificado no contrato, o desenvolvedor deve auxiliar o adquirente com as atividades de preparao. Onde o produto de software a ser instalado estiver substituindo um sistema existente, o desenvolvedor deve apoiar qualquer atividade em execuo paralela, conforme especificado no contrato. O plano de instalao deve ser documentado.

5.4.1.1 O operador deve desenvolver um plano e um conjunto de padres de operao para executar as atividades e tarefas deste processo. O plano deve ser documentado e executado.
Cpia no autorizada
16
5.4.1.2 O operador deve estabelecer procedimentos para
receber, registrar, resolver e rastrear problemas, e prover realimentao (feedback). Sempre que os problemas forem encontrados, eles devem ser registrados e includos no processo de resoluo de problema (seo 6.8).
5.4.1.3 O operador deve estabelecer procedimentos para
As atividades providas nesta seo so especficas para o processo de manuteno. Entretanto, o processo pode utilizar outros processos desta Norma. Se o processo de desenvolvimento (seo 5.3) utilizado, o termo desenvolvedor interpretado como mantenedor. O mantenedor gerencia o processo de manuteno em nvel de projeto, seguindo o processo de gerncia (7.1), o qual passa a existir nesse processo; estabelece uma infra-estrutura sob o processo, seguindo o processo de infra-estrutura (7.2); adapta o processo para o projeto seguindo o processo de adaptao (anexo A); e gerencia o processo em nvel organizacional seguindo o processo de melhoria (7.3) e o processo de treinamento (7.4). Quando o mantenedor o fornecedor do servio de manuteno, o mantenedor executa o processo de fornecimento (5.2). Lista de atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Anlise do problema e da modificao; 3) Implementao da modificao;
testar o produto de software no seu ambiente de operao, para inserir os relatrios de problemas e pedidos de modificao no processo de manuteno (5.5) e para liberar o produto de software para uso operacional.
5.4.2 Teste operacional. Esta atividade consiste nas
seguintes tarefas:
5.4.2.1 Para cada liberao do produto de software, o operador deve executar o teste operacional e, satisfazendo os critrios especificados, liberar o produto de software para uso operacional. 5.4.2.2 O operador deve garantir que o cdigo de
software e as bases de dados sejam iniciados, executados e finalizados, como descrito no plano.
5.4.3 Operao do sistema. Esta atividade consiste na
seguinte tarefa:
5.4.3.1 O sistema deve ser operado no ambiente para o
4) Reviso/aceitao da manuteno; 5) Migrao; 6) Descontinuao do software.

qual foi pretendido, de acordo com a documentao do usurio.

5.4.4 Suporte ao usurio. Esta atividade consiste nas

5.5.1.1 O mantenedor deve desenvolver, documentar e
seguintes tarefas:
5.4.4.1 O operador deve prover assistncia e consultoria
aos usurios quando solicitado. Estas solicitaes e aes subseqentes devem ser registradas e monitoradas.
5.4.4.2 O operador deve encaminhar as solicitaes do
executar planos e procedimentos para a conduo das atividades e tarefas do processo de manuteno.
5.5.1.2 O mantenedor deve estabelecer procedimentos
usurio, quando necessrio, para resoluo no processo de manuteno (5.5). Estas solicitaes devem ser encaminhadas e as aes que foram planejadas e executadas devem ser relatadas aos solicitantes. Todas as resolues devem ser monitoradas at a concluso.
5.4.4.3 Se um problema relatado tiver uma soluo tem-
para receber, registrar e rastrear relatrios de problemas e pedidos de modificao dos usurios, e prover realimentao (feedback) para os usurios. Sempre que problemas forem encontrados, eles devem ser registrados e includos no processo de resoluo de problema (seo 6.8).
5.5.1.3 O mantenedor deve implementar (ou estabelecer
porria antes que uma soluo definitiva possa ser liberada, deve ser dada, ao solicitante, a opo de usla. Correes definitivas, liberaes que incluem funes ou caractersticas previamente omitidas e melhorias do sistema devem ser aplicadas ao produto de software em operao, utilizando o processo de manuteno (5.5). 5.5 Processo de manuteno O processo de manuteno contm as atividades e tarefas do mantenedor. Este processo ativado quando o produto de software submetido a modificaes no cdigo e na documentao associada devido a um problema, ou necessidade de melhoria ou adaptao. O objetivo modificar um produto de software existente, preservando a sua integridade. Este processo inclui a migrao e a descontinuao do produto de software. O processo termina com a descontinuao do produto de software.
interface organizacional com) o processo de gerncia de configurao (6.2), para gerenciar modificaes no sistema existente.
5.5.2 Anlise do problema e da modificao. Esta atividade

5.5.2.1 O mantenedor deve analisar o relatrio de problema ou pedido de modificao segundo o seu impacto na organizao, no sistema existente e nos sistemas com os quais interage, com relao ao seguinte:
a) Tipo: por exemplo, corretivo, melhoria, preventivo, ou adaptativo para um novo ambiente; b) Escopo: por exemplo, tamanho da modificao, custo envolvido, prazo para modificar; c) Criticidade: por exemplo, impacto no desempenho, proteo ou segurana.
Cpia no autorizada
17
5.5.2.2 O mantenedor deve reproduzir ou verificar o
d) Execuo da migrao; e) Verificao da migrao;
problema.
5.5.2.3 Baseado na anlise, o mantenedor deve desen-
volver alternativas para a implementao da modificao.

5.5.2.4 O mantenedor deve documentar o problema/pe-
f) Suporte para o ambiente antigo.

5.5.5.3 Usurios devem receber notificao dos planos e
dido de modificao, os resultados da anlise e as alternativas de implementao.

5.5.2.5 O mantenedor deve obter aprovao para a al-
atividades de migrao. Notificaes devem conter o seguinte: a) Explicao do porqu o ambiente antigo no ser mais suportado; b) Descrio do novo ambiente com sua data de disponibilizao; c) Descrio de outras opes de suporte disponveis, se existirem, uma vez que o suporte para o ambiente antigo seja descontinuado.
5.5.5.4 Operaes paralelas dos ambientes antigo e novo
ternativa de modificao selecionada, conforme especificado no contrato.

5.5.3 Implementao da modificao. Esta atividade

5.5.3.1 O mantenedor deve conduzir a anlise e determinar que documentao, unidades de software e verses destas necessitam ser modificadas. Estas devem ser documentadas. 5.5.3.2
O mantenedor deve utilizar o processo de desenvolvimento (5.3) para implementar as modificaes. Os requisitos do processo de desenvolvimento devem ser complementados, como segue: a) Devem ser definidos e documentados critrios de teste e de avaliao para testar e avaliar as partes modificadas e as no modificadas do sistema (unidades de software, componentes e itens de configurao). b) Deve ser garantida a implementao completa e correta dos requisitos novos e dos modificados. Tambm deve ser garantido que os requisitos originais no modificados no foram afetados. Os resultados dos testes devem ser documentados.
podem ser conduzidas para a transio gradual ao novo ambiente. Durante este perodo, deve ser provido o treinamento necessrio, conforme especificado no contrato.
5.5.5.5 Quando a migrao programada ocorrer, devem
ser enviadas notificaes a todos os interessados. Toda documentao, histricos (logs) e cdigo associados ao ambiente antigo deveriam ser arquivados.
5.5.5.6 Aps a migrao, uma reviso deve ser executada
para avaliar o impacto da mudana para o novo ambiente. Os resultados da reviso devem ser enviados s autoridades apropriadas para informao, orientao e providncias.
5.5.5.7 Dados utilizados ou associados com o ambiente
5.5.4 Reviso/aceitao da manuteno. Esta atividade

5.5.4.1 O mantenedor deve conduzir reviso(es) com a
antigo devem estar acessveis, de acordo com os requisitos do contrato para preservao e auditoria dos dados.
5.5.6 Descontinuao do software. Esta atividade consiste
organizao que autorizou a modificao para determinar a integridade do sistema modificado.

5.5.4.2 O mantenedor deve obter aprovao para a con-

NOTA - O produto de software dever ser descontinuado a pedido do proprietrio. 5.5.6.1 Um plano de descontinuao, para remover o su-
cluso satisfatria da modificao, conforme especificado no contrato.

5.5.5 Migrao. Esta atividade consiste nas seguintes
tarefas:
5.5.5.1 Se um sistema ou produto de software (incluindo dados) migrado de um ambiente de operao antigo para um novo, deve ser assegurado que qualquer produto de software ou dados produzidos ou modificados durante a migrao estejam de acordo com esta Norma. 5.5.5.2 Um plano de migrao deve ser desenvolvido,
porte ativo pelas organizaes responsveis pela operao e manuteno, deve ser desenvolvido e documentado. As atividades de planejamento devem incluir os usurios. O plano deve conter os itens listados a seguir. O plano deve ser executado. a) Cessao total ou parcial de suporte aps um certo perodo de tempo; b) Arquivamento do produto de software e sua documentao associada; c) Responsabilidade por quaisquer questes futuras de suporte residual; d) Transio para o novo produto de software, se aplicvel; e) Disponibilidade de cpias de arquivos de dados.
documentado e executado. As atividades de planejamento devem incluir os usurios. Os itens includos no plano devem conter o seguinte: a) Anlise e definio dos requisitos de migrao; b) Desenvolvimento de ferramentas de migrao; c) Converso de produto de software e dados;
Cpia no autorizada
18
5.5.6.2 Os usurios devem receber notificao dos planos
6.1 Processo de documentao O processo de documentao um processo para registrar informaes produzidas por um processo ou atividade do ciclo de vida. O processo contm o conjunto de atividades que planeja, projeta, desenvolve, produz, edita, distribui e mantm aqueles documentos necessrios a todos os interessados, tais como gerentes, engenheiros e usurios do sistema ou produto de software. Lista das atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Projeto e desenvolvimento; 3) Produo; 4) Manuteno.
e atividades de descontinuao. Notificaes devem incluir o seguinte: a) Descrio da substituio ou atualizao com sua data de disponibilidade; b) Explicao do porqu o produto de software no receber mais suporte; c) Descrio de outras opes de suporte disponveis, uma vez que o suporte seja descontinuado.
5.5.6.3 Operaes paralelas do produto de software em descontinuao e do novo deveriam ser conduzidas para transio gradual ao novo sistema. Durante este perodo, deve ser provido treinamento de usurio, conforme especificado no contrato. 5.5.6.4 Quando a descontinuao programada ocorrer, devem ser enviadas notificaes a todos os interessados. Toda documentao, histricos (logs) e cdigo associados ao desenvolvimento deveriam ser arquivados, quando apropriado. 5.5.6.5 Dados utilizados ou associados com o produto de

6.1.1.1 Um plano, identificando os documentos a serem
software descontinuado devem estar acessveis, de acordo com os requisitos do contrato para preservao e auditoria dos dados.
produzidos durante o ciclo de vida do produto de software, deve ser desenvolvido, documentado e implementado. Para cada documento identificado, o seguinte deve ser definido: a) Ttulo ou nome;
6 Processos de apoio de ciclo de vida

Este captulo define os seguintes processos de apoio de ciclo de vida: 1) Processo de documentao; 2) Processo de gerncia de configurao; 3) Processo de garantia da qualidade; 4) Processo de verificao; 5) Processo de validao; 6) Processo de reviso conjunta; 7) Processo de auditoria; 8) Processo de resoluo de problema. As atividades e tarefas em um processo de apoio so de responsabilidade da organizao que o executa. Essa organizao garante que o processo existe e funcional. A organizao que utiliza e executa um processo de apoio o gerencia em nvel de projeto, seguindo o processo de gerncia (7.1); estabelece uma infra-estrutura sob este processo, seguindo o processo de infra-estrutura (7.2); adapta o processo para o projeto, seguindo o processo de adaptao (anexo A); e gerencia o processo em nvel organizacional, seguindo o processo de melhoria (7.3) e o processo de treinamento (7.4). Revises conjuntas, auditorias, verificao e validao podem ser utilizadas como tcnicas de garantia da qualidade. e) Cronograma das verses intermedirias e final.
6.1.2 Projeto e desenvolvimento. Esta atividade consiste
b) Propsito; c) Pblico-alvo; d) Procedimentos e responsabilidades pelas entradas, desenvolvimento, reviso, alterao, aprovao, produo, armazenamento, distribuio, manuteno e gerncia de configurao.

6.1.2.1 Cada documento identificado deve ser projetado
de acordo com os padres de documentao aplicveis no que se refere ao formato, descrio de contedo, numerao de pgina, localizao de figuras/tabelas, marcas de propriedade/segurana, empacotamento, e outros itens de apresentao.
6.1.2.2 A fonte e a adequao dos dados de entrada para
os documentos devem ser confirmadas. Ferramentas para a automatizao da documentao podem ser utilizadas.
6.1.2.3 Os documentos preparados devem ser revisados
e editados em comparao com os seus padres de documentao no que se refere ao formato, contedo tcnico e estilo de apresentao. Eles devem ser aprovados quanto sua adequao, pelo pessoal autorizado, antes de sua emisso.
Cpia no autorizada
19
6.1.3 Produo. Esta atividade consiste nas seguintes
6.2.2 Identificao da configurao. Esta atividade consiste
tarefas:
6.1.3.1 Os documentos devem ser produzidos e fornecidos
na seguinte tarefa:
6.2.2.1 Uma sistemtica para o projeto deve ser estabe-
de acordo com o plano. A produo e a distribuio dos documentos podem utilizar papel, meio eletrnico ou outra mdia. As matrizes devem ser armazenadas de acordo com os requisitos para guarda de registro, segurana, manuteno e cpia de segurana.
6.1.3.2 Controles devem ser estabelecidos, de acordo com
lecida para a identificao dos itens de software e suas verses a serem controladas. Para cada item de software e suas verses deve ser identificado o seguinte: a documentao que estabelece a linha bsica (baseline); as referncias de verso e outros detalhes de identificao.
6.2.3 Controle da configurao. Esta atividade consiste
o processo de gerncia de configurao (6.2).

6.1.4 Manuteno. Esta atividade consiste na seguinte ta-
na seguinte tarefa:
6.2.3.1 Deve ser executado o seguinte: identificao e
refa:
6.1.4.1 Quando a documentao est para ser alterada,
as tarefas necessrias devem ser executadas (5.5). Para aqueles documentos que esto sob a gerncia de configurao, as alteraes devem ser gerenciadas, de acordo com o processo de gerncia de configurao (6.2). 6.2 Processo de gerncia de configurao O processo de gerncia de configurao um processo de aplicao de procedimentos administrativos e tcnicos, por todo o ciclo de vida de software, destinado a: identificar e definir os itens de software em um sistema, e estabelecer suas linhas bsicas (baseline); controlar as modificaes e liberaes dos itens; registrar e apresentar a situao dos itens e dos pedidos de modificao; garantir a completeza, a consistncia e a correo dos itens; e controlar o armazenamento, a manipulao e a distribuio dos itens.
NOTA - O termo item de software pode ser empregado para outros produtos de software ou entidades.
registro dos pedidos de alterao; anlise e avaliao das alteraes; aprovao ou rejeio do pedido; e implementao, verificao e liberao do item de software modificado. Devem existir registros de auditoria, de tal forma que, para cada modificao, a sua razo e a sua autorizao possam ser rastreadas. Deve ser realizado controle e auditoria de todos os acessos aos itens de software controlados que tratam de funes crticas de proteo ou segurana.
6.2.4 Relato da situao da configurao. Esta atividade
consiste na seguinte tarefa:

6.2.4.1 Devem ser preparados registros de gerenciamento
e relatrios de situao que mostrem a situao e o histrico dos itens de software controlados, incluindo a linha bsica (baseline). Os relatrios de situao deveriam incluir o nmero de alteraes em um projeto, as ltimas verses do item de software, identificadores de liberao, a quantidade de liberaes e as comparaes entre elas.
6.2.5 Avaliao da configurao. Esta atividade consiste
na seguinte tarefa:
6.2.5.1 Deve ser determinado e garantido o seguinte: a
Lista das atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Identificao da configurao; 3) Controle da configurao; 4) Relato da situao da configurao; 5) Avaliao da configurao; 6) Gerncia de liberao e distribuio.
completeza funcional dos itens de software em relao aos seus requisitos e a completeza fsica dos itens de software (ou seja, se seu projeto e cdigo refletem uma descrio tcnica atualizada).
6.2.6 Gerncia de liberao e distribuio. Esta atividade

6.2.6.1 A liberao e a distribuio de produtos de
software e documentao devem ser formalmente controladas. Cpias matrizes do cdigo e da documentao devem ser mantidas durante a vida do produto de software. O cdigo e a documentao que contenham funes crticas de proteo ou segurana devem ser manipulados, armazenados, empacotados e distribudos de acordo com as polticas das organizaes envolvidas. 6.3 Processo de garantia da qualidade
na seguinte tarefa:
6.2.1.1 Um plano de gerncia de configurao deve ser
desenvolvido. O plano deve descrever: as atividades da gerncia de configurao; procedimentos e cronograma para executar estas atividades; as organizaes responsveis pela execuo destas atividades; e seu relacionamento com outras organizaes, como por exemplo a de desenvolvimento ou manuteno de software. O plano deve ser documentado e implementado.
NOTA - O plano pode ser parte do plano de gerncia de configurao do sistema.
O processo de garantia da qualidade um processo para fornecer garantia adequada de que os processos e produtos de software, no ciclo de vida do projeto, estejam em conformidade com seus requisitos especificados e sejam aderentes aos planos estabelecidos. Para ser imparcial, a garantia da qualidade necessita ter autoridade e autonomia organizacional, independente das pessoas diretamente responsveis pelo desenvolvimento do produto de software ou pela execuo do processo no projeto.
Cpia no autorizada
20
A garantia da qualidade pode ser interna ou externa, dependendo da necessidade da qualidade do produto ou do processo ser evidenciada para a gerncia do fornecedor ou do adquirente. A garantia da qualidade pode utilizar os resultados de outros processos de apoio tais como: verificao, validao, revises conjuntas, auditorias e resoluo de problema. Lista das atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Garantia do produto; 3) Garantia do processo; 4) Sistemas de garantia da qualidade.
6.3.1.5 Registros das atividades e tarefas de garantia da
qualidade devem ser disponibilizados ao adquirente, como especificado no contrato.

6.3.1.6 Deve ser assegurado que pessoas responsveis
por garantir a conformidade aos requisitos do contrato tenham autonomia, recursos e autoridade organizacionais, para possibilitar avaliaes objetivas e para iniciar, efetuar, resolver e verificar resolues de problemas.
6.3.2 Garantia do produto. Esta atividade consiste nas
seguintes tarefas:
6.3.2.1 Deve ser garantido que todos os planos exigidos
pelo contrato sejam documentados, estejam de acordo com o contrato, sejam mutuamente consistentes e sejam executados quando requerido.
6.3.2.2 Deve ser garantido que os produtos de software e

6.3.1.1 Um processo de garantia da qualidade adaptado
a documentao relacionada estejam de acordo com o contrato e aderentes aos planos.

6.3.2.3 Na preparao da entrega dos produtos de software deve ser garantido que os produtos de software tenham seus requisitos contratuais inteiramente satisfeitos e sejam aceitveis pelo adquirente. 6.3.3 Garantia do processo. Esta atividade consiste nas
ao projeto deve ser estabelecido. Os objetivos do processo de garantia da qualidade devem ser determinados, para garantir que os produtos de software e os processos empregados para fornec-los estejam conforme os seus requisitos estabelecidos e sejam aderentes aos seus planos estabelecidos.
6.3.1.2 O processo de garantia da qualidade deveria ser
seguintes tarefas:
6.3.3.1 Deve ser garantido que aqueles processos do ciclo
coordenado com os processos de verificao (6.4), validao (6.5), reviso conjunta (6.6) e auditoria (6.7).
6.3.1.3 Um plano para conduzir as atividades e tarefas do
processo de garantia da qualidade deve ser desenvolvido, documentado, implementado e mantido durante a vigncia do contrato. O plano deve incluir o seguinte: a) Padres de qualidade, metodologias, procedimentos e ferramentas para executar as atividades de garantia da qualidade (ou referncias na documentao oficial da organizao); b) Procedimentos para reviso de contrato e sua coordenao; c) Procedimentos para identificao, coleta, arquivamento, manuteno e disponibilizao dos registros da qualidade; d) Recursos, cronograma e responsabilidades para conduzir as atividades de garantia da qualidade; e) Atividades e tarefas selecionadas dos processos de apoio, tais como verificao (6.4), validao (6.5), reviso conjunta (6.6), auditoria (6.7) e resoluo de problema (6.8).
6.3.1.4 Atividades e tarefas de garantia da qualidade
de vida do sofware (fornecimento, desenvolvimento, operao, manuteno e os processos de apoio, incluindo garantia da qualidade) empregados no projeto estejam de acordo com o contrato e aderentes aos planos.
6.3.3.2 Deve ser garantido que as prticas internas de
engenharia de software, ambiente de desenvolvimento, ambiente de teste e bibliotecas estejam de acordo com o contrato.
6.3.3.3 Deve ser garantido que os requisitos aplicveis
ao contrato original sejam passados para o subcontratado e que os produtos de software do subcontratado satisfaam os requisitos do contrato original.
6.3.3.4 Deve ser garantido que o adquirente e outras
partes envolvidas sejam providos do apoio e da cooperao requeridos, de acordo com o contrato, negociaes e planos.
6.3.3.5 Deveria estar garantido que as medies do produto e do processo de software estejam de acordo com padres e procedimentos estabelecidos. 6.3.3.6 Deve ser garantido que a equipe alocada tenha a
qualificao e o conhecimento necessrios para atender os requisitos do projeto e recebam todo treinamento necessrio.
6.3.4 Sistemas de garantia da qualidade. Esta atividade
agendadas e em andamento devem ser executadas. Quando problemas ou no-conformidades aos requisitos do contrato so detectados, devem ser documentados e servem de entrada ao processo de resoluo de problema (seo 6.8). Registros destas atividades e tarefas, sua execuo, problemas e resolues de problemas devem ser gerados e mantidos.

6.3.4.1 Atividades adicionais de gerncia da qualidade
devem ser garantidas de acordo com as clusulas da NBR ISO 9001, como especificado no contrato.
Cpia no autorizada
21
6.4 Processo de verificao O processo de verificao um processo para determinar se os produtos de software de uma atividade atendem completamente os requisitos ou condies impostas a eles nas atividades anteriores. Para a eficcia de custo e desempenho, a verificao deveria ser integrada, o quanto antes, com o processo que a utiliza (tais como fornecimento, desenvolvimento, operao ou manuteno). Este processo pode incluir anlise, reviso e teste. Este processo pode ser executado com variados graus de independncia. O grau de independncia pode variar da mesma pessoa ou outra pessoa da organizao, para uma pessoa de outra organizao, com variados graus de envolvimento. No caso em que o processo executado por uma organizao independente do fornecedor, desenvolvedor, operador ou mantenedor, chamado de processo de verificao independente. Lista das atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Verificao.
6.4.1.5 Baseado nas tarefas de verificao determinadas
anteriormente, um plano de verificao deve ser desenvolvido e documentado. O plano deve indicar as atividades do ciclo de vida e produtos de software sujeitos a verificao, as tarefas de verificao requeridas para cada atividade do ciclo de vida e produto de software; e recursos, responsabilidades e cronograma associados. O plano deve indicar procedimentos para enviar relatrios de verificao ao adquirente e outras organizaes envolvidas.
6.4.1.6 O plano de verificao deve ser implementado.
Problemas e no-conformidades detectados pelo esforo de verificao devem ser includos no processo de resoluo de problema (6.8). Todos os problemas e noconformidades devem ser resolvidos. Os resultados das atividades de verificao devem ser disponibilizados para o adquirente e outras organizaes envolvidas.
6.4.2 Verificao. Esta atividade consiste nas seguintes
tarefas:
6.4.2.1 Verificao do contrato. O contrato deve ser
verificado considerando os seguintes critrios: a) O fornecedor tem a capacidade de atender os requisitos. b) Os requisitos esto consistentes e cobrem as necessidades do usurio. c) Procedimentos adequados, para tratar alteraes nos requisitos e priorizao de problemas, esto estipulados. d) Procedimentos e sua abrangncia para interao e cooperao entre as partes so estipulados, incluindo propriedade, garantia, direitos autorais e confidencialidade. e) Critrios e procedimentos de aceitao esto estipulados de acordo com os requisitos.
NOTA - Esta atividade pode ser usada na reviso do contrato (ver 6.3.1.3 b). 6.4.2.2 Verificao do processo. O processo deve ser

6.4.1.1 Deve ser determinado se o projeto justifica um
esforo de verificao e o grau de independncia organizacional. Os requisitos do projeto devem ser analisados em funo dos fatores crticos. Estes fatores podem ser aferidos nos seguintes termos: a) O potencial de que um erro no detectado em um requisito do sistema ou software possa causar morte ou dano pessoal, no alcance de objetivos, perda ou dano financeiro ou de equipamento; b) A maturidade e riscos associados com a tecnologia de software a ser utilizada; e c) A disponibilidade financeira e de recursos.
6.4.1.2 Se o projeto justifica um esforo de verificao, um
processo de verificao deve ser estabelecido para verificar o produto de software.

6.4.1.3 Se o projeto justifica um esforo de verificao
verificado considerando os seguintes critrios: a) Os requisitos de planejamento do projeto esto adequados e oportunos. b) Os processos selecionados para o projeto esto adequados, implementados, sendo executados como planejados e conforme o contrato. c) Os padres, procedimentos e ambientes para os processos do projeto esto adequados. d) O projeto dispe de equipe e pessoal capacitado, como requerido no contrato.
independente, deve ser selecionada uma organizao qualificada responsvel para conduzi-la. Esta organizao deve ter assegurada a independncia e autoridade para executar as atividades de verificao.
6.4.1.4 Baseado no escopo, magnitude, complexidade e
anlise dos fatores crticos mencionados anteriormente, devem ser determinadas as atividades do ciclo de vida e os produtos de software que requerem verificao. As atividades e tarefas de verificao definidas no item 6.4.2, incluindo mtodos, tcnicas e ferramentas associados para executar as tarefas, devem ser selecionadas para as atividades do ciclo de vida e produtos de software em questo.
Cpia no autorizada
22
6.4.2.3 Verificao dos requisitos. Os requisitos devem
6.4.2.7 Verificao da documentao. A documentao
ser verificados considerando os seguintes critrios: a) Os requisitos do sistema so consistentes, viveis e testveis. b) Os requisitos do sistema foram distribudos apropriadamente para os itens de hardware, itens de software e operaes manuais, de acordo com os critrios do projeto. c) Os requisitos de software so consistentes, viveis, testveis e refletem precisamente os requisitos do sistema. d) Os requisitos de software relacionados proteo, segurana e aos fatores crticos esto corretos, conforme demonstrado por mtodos adequadamente rigorosos.
6.4.2.4 Verificao de projeto. O projeto deve ser verificado
deve ser verificada, considerando os seguintes critrios: a) A documentao est adequada, completa e consistente. b) A preparao da documentao est oportuna. c) A gerncia de configurao dos documentos segue procedimentos especificados. 6.5 Processo de validao O processo de validao um processo para determinar se os requisitos e o produto final, sistema ou produto de software construdo, atendem ao uso especfico pretendido. A validao pode ser conduzida nos estgios iniciais. Este processo pode ser conduzido como parte da atividade de apoio aceitao do software (5.3.13). Este processo pode ser executado com variados graus de independncia. O grau de independncia pode variar da mesma pessoa ou outra pessoa da organizao, para uma pessoa de outra organizao, com variados graus de envolvimento. No caso em que o processo executado por uma organizao independente do fornecedor, desenvolvedor, operador ou mantenedor, chamado de processo de validao independente. Lista das atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Validao.
considerando os seguintes critrios: a) O projeto est correto e consistente com os requisitos e rastrevel aos mesmos. b) O projeto implementa uma seqncia adequada de eventos, entradas, resultados, interfaces, fluxo lgico, alocao de tempo e de oramentos, e definio, isolamento e recuperao de erro. c) O projeto selecionado pode ser originado a partir dos requisitos. d) O projeto implementa proteo, segurana e outros requisitos crticos corretamente, conforme demonstrado por mtodos adequadamente rigorosos.
6.4.2.5 Verificao do cdigo. O cdigo deve ser verificado,

6.5.1.1 Deve ser determinado se o projeto justifica um
considerando os seguintes critrios: a) O cdigo rastrevel para o projeto e para os requisitos, testvel, correto e aderente aos requisitos e padres de codificao. b) O cdigo implementa a seqncia de eventos apropriada, interfaces consistentes, dados e fluxo de controle corretos, completeza, alocao de tempo e de oramentos apropriada, e definio, isolamento e recuperao de erros. c) O cdigo selecionado pode ser originado a partir do projeto ou dos requisitos. d) O cdigo implementa proteo, segurana e outros requisitos crticos corretamente, conforme demonstrado por mtodos adequadamente rigorosos.
6.4.2.6 Verificao da integrao. A integrao deve ser
esforo de validao e o grau de independncia organizacional.

6.5.1.2 Se o projeto justifica um esforo de validao, um
processo de validao deve ser estabelecido para validar o sistema ou o produto de software. As tarefas de validao definidas a seguir, incluindo mtodos, tcnicas e ferramentas associados para executar as tarefas, devem ser selecionadas.
6.5.1.3 Se o projeto justifica um esforo de validao
independente, deve ser selecionada uma organizao qualificada responsvel para conduzi-la. O condutor deve ter assegurada a independncia e autoridade para executar as tarefas de validao.
6.5.1.4 Um plano de validao deve ser desenvolvido e
verificada considerando os seguintes critrios: a) Os componentes de software e unidades de cada item de software foram completa e corretamente integrados dentro do item de software. b) Os itens de hardware, de software e operaes manuais do sistema foram completa e corretamente integrados ao sistema. c) As tarefas de integrao foram executadas de acordo com um plano de integrao.
documentado. O plano deve incluir, mas no estar limitado ao seguinte: a) Itens sujeitos validao; b) Tarefas de validao a serem executadas; c) Recursos, responsabilidades e cronograma para validao; e d) Procedimentos para encaminhar relatrios de validao ao adquirente e outras partes envolvidas.
Cpia no autorizada
23
6.5.1.5 O plano de validao deve ser implementado. Problemas e no-conformidades detectados pelo esforo de validao devem ser includos no processo de resoluo de problema (6.8). Todos os problemas e noconformidades devem ser resolvidos. Os resultados das atividades de validao devem ser disponibilizados para o adquirente e outras organizaes envolvidas. 6.5.2 Validao. Esta
6.6.1.2 Todos os recursos requeridos para conduzir as
revises devem ser acordados pelas partes. Estes recursos incluem pessoal, local, instalaes, hardware, software e ferramentas.
6.6.1.3 As partes deveriam concordar com os seguintes
atividade consiste nas seguintes
tarefas:
6.5.2.1 Preparar os requisitos de teste, casos de teste e
itens em cada reviso: agenda da reunio, produtos de software (resultados de uma atividade) e problemas a serem revisados; escopo e procedimentos; e critrios para incio e trmino da reviso.
6.6.1.4 Problemas detectados durante as revises devem
especificaes de teste selecionados para anlise dos resultados dos testes.

6.5.2.2 Assegurar que estes requisitos de teste, casos de
ser registrados e includos no processo de resoluo de problema (6.8), conforme requerido.

6.6.1.5 Os resultados da reviso devem ser documentados
teste e especificaes de teste reflitam os requisitos particulares para o uso especfico pretendido.
6.5.2.3 Conduzir os testes nos itens 6.5.2.1 e 6.5.2.2,
incluindo: a) Teste de estresse, limites e entradas especficas. b) Teste do produto de software para verificar sua habilidade em isolar e minimizar efeitos de erros; isto , degradao suave em caso de falha, pedido de assistncia do operador em caso de estresse, de exceder limites e de condies especficas. c) Teste para que usurios representativos possam executar, com sucesso, suas tarefas pretendidas usando o produto de software.
6.5.2.4 Validar que o produto de software satisfaa seu uso pretendido. 6.5.2.5 Testar o produto de software, quando apropriado,
e distribudos. A parte revisora apresentar parte revisada a adequabilidade (por exemplo: aprovao, desaprovao ou aprovao condicional) dos resultados da reviso.
6.6.1.6 As partes devem concordar com os resultados da
reviso e quaisquer responsabilidades pelo item de ao e critrios de encerramento.

6.6.2 Revises de gerenciamento do projeto. Esta atividade
consiste na seguinte tarefa.

6.6.2.1 A situao do projeto deve ser avaliada em relao
aos planos, cronogramas, padres e diretrizes aplicveis ao projeto. O resultado da reviso deveria ser discutido entre as duas partes e deveria fornecer subsdios para o seguinte: a) Fazer com que as atividades progridam de acordo com o plano, baseado em uma avaliao da situao da atividade ou do produto de software; b) Manter o controle geral do projeto atravs da alocao adequada de recursos; c) Redirecionar o projeto ou determinar a necessidade de um planejamento alternativo; e d) Avaliar e gerenciar as situaes de risco que possam comprometer o sucesso do projeto.
6.6.3 Revises tcnicas. Esta atividade consiste na seguinte
nas reas selecionadas do ambiente-alvo. 6.6 Processo de reviso conjunta O processo de reviso conjunta um processo para avaliar a situao e produtos de uma atividade de um projeto, se apropriado. As revises conjuntas so feitas tanto nos nveis de gerenciamento do projeto como nos nveis tcnicos e so executadas durante a vigncia do contrato. Este processo pode ser empregado por qualquer das duas partes, onde uma parte (parte revisora) revisa a outra parte (parte revisada). Lista das atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Revises de gerenciamento do projeto; 3) Revises tcnicas.
tarefa:
6.6.3.1 Revises tcnicas devem ser promovidas para avaliar os produtos ou servios de software em considerao e prover evidncia de que:
a) Eles esto completos; b) Eles esto aderentes aos seus padres e especificaes; c) Suas alteraes esto implementadas adequadamente e afetam somente aquelas reas identificadas pelo processo de gerncia de configurao (6.2);

6.6.1.1 Revises peridicas devem ser promovidas em
marcos predeterminados, como especificado no(s) plano(s) do projeto. Revises ad hoc deveriam ser realizadas quando julgadas necessrias por quaisquer das partes.
Cpia no autorizada
24
d) Eles esto aderentes aos cronogramas aplicveis; e) Eles esto prontos para a prxima atividade; e f) O desenvolvimento, operao ou manuteno esto sendo conduzidos de acordo com os planos, cronogramas, padres e diretrizes do projeto. 6.7 Processo de auditoria O processo de auditoria um processo para determinar adequao aos requisitos, planos e contrato, quando apropriado. Este processo pode ser empregado por quaisquer das duas partes, onde uma parte (parte auditora) faz a auditoria nos produtos de software ou nas atividades da outra parte (parte auditada). Lista das atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo;
c) Dados de teste estejam aderentes especificao; d) Os produtos de software sejam testados com sucesso e atendam s suas especificaes; e) Os relatrios de teste estejam corretos e discrepncias entre o resultado real e o esperado sejam resolvidos; f) A documentao do usurio esteja aderente aos padres, conforme o especificado; g) As atividades sejam conduzidas de acordo com os requisitos, planos e contrato aplicveis; e h) Os custos e cronogramas adiram aos planos estabelecidos. 6.8 Processo de resoluo de problema
2) Auditoria.
6.7.1. Implementao do processo. Esta atividade consiste

6.7.1.1 As auditorias devem ser promovidas em marcos
predeterminados, conforme especificado no(s) plano(s) do projeto.

6.7.1.2 O pessoal da auditoria no deve ter nenhuma
responsabilidade direta pelos produtos de software e atividades que eles auditam.

6.7.1.3 Todos os
O processo de resoluo de problema um processo para analisar e resolver os problemas (incluindo noconformidades), de qualquer natureza ou fonte, que so descobertos durante a execuo do desenvolvimento, operao, manuteno ou outros processos. O objetivo prover os meios em tempo adequado e de forma responsvel e documentada para garantir que todos os problemas encontrados sejam analisados e resolvidos e tendncias sejam identificadas. Lista das atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Resoluo de problema.
recursos requeridos para conduzir a auditoria devem ser acordados pelas partes. Esses recursos incluem pessoal de apoio, local, instalaes, hardware, software e ferramentas.
6.7.1.4 As partes deveriam concordar com os seguintes
itens em cada auditoria: agenda; produtos de software (e resultados de uma atividade) a serem revisados; escopo e procedimentos da auditoria; e critrios de incio e trmino da auditoria.
6.7.1.5 Problemas detectados durante as auditorias
na seguinte tarefa:
6.8.1.1 Um processo de resoluo de problema deve ser
devem ser registrados e includos no processo de resoluo de problema (6.8), quando requerido.
6.7.1.6 Aps a concluso de uma auditoria, os resultados
estabelecido para tratar todos os problemas (incluindo no-conformidades) detectados nos produtos de software e atividades. O processo deve atender aos seguintes requisitos: a) O processo deve ser de ciclo fechado (closedloop), garantindo que: todos os problemas detectados sejam prontamente relatados e includos no processo de resoluo de problema; a ao seja iniciada nos problemas detectados; as partes relevantes sejam alertadas da existncia do problema, quando apropriado; as causas sejam identificadas, analisadas e, quando possvel, eliminadas; a resoluo e sua aplicao sejam alcanadas; a situao seja rastreada e relatada; e os registros dos problemas sejam mantidos, conforme estipulado no contrato; b) O processo deveria conter um esquema para categorizar e priorizar os problemas. Cada problema deveria ser classificado por categoria e prioridade para facilitar a anlise de tendncia e resoluo de problema;
da auditoria devem ser documentados e entregues parte auditada. A parte auditada deve apresentar parte auditora quaisquer problemas encontrados na auditoria e o planejamento das resolues dos problemas relatados.
6.7.1.7 As partes devem concordar com o resultado da
auditoria e quaisquer responsabilidades pelo item de ao e critrios de encerramento.

6.7.2. Auditoria. Esta atividade consiste na seguinte tarefa: 6.7.2.1 As auditorias devem ser conduzidas para asse-
gurar que: a) Produtos de software codificados (tais como item de software) reflitam a documentao do projeto; b) A reviso de aceitao e requisitos de teste prescritos pela documentao estejam adequados para aceitao dos produtos de software;
Cpia no autorizada
25
c) A anlise deve ser executada para detectar tendncias nos problemas relatados; d) As resolues de problemas e suas aplicaes devem ser avaliadas para: verificar se os problemas foram resolvidos, se as tendncias adversas foram revertidas e se as alteraes foram implementadas corretamente nos produtos de software e atividades apropriados; e determinar se problemas adicionais foram introduzidos.
6.8.2 Resoluo do problema. Esta atividade consiste na
7.1.1 Iniciao e definio do escopo. Esta atividade

7.1.1.1 O processo de gerncia deve ser iniciado pelo
estabelecimento dos requisitos do processo a ser empreendido.

7.1.1.2 Tendo estabelecido os requisitos, o gerente deve
seguinte tarefa:
6.8.2.1 Quando problemas (incluindo no-conformidades)
estabelecer a viabilidade do processo, verificando se os recursos (de pessoal, materiais, tecnolgicos e de ambiente) requeridos para executar e gerenciar o processo esto disponveis, adequados e apropriados e se os prazos para concluso podem ser atingidos.
7.1.1.3 Quando necessrio, e com a concordncia de
forem detectados em um produto de software ou em uma atividade, um relatrio de problema deve ser preparado para descrever cada problema detectado. O relatrio de problema deve ser usado como parte do processo de ciclo fechado (closed-loop) descrito acima: a partir da deteco do problema, ao longo da investigao, anlise e resoluo do problema e sua causa, e para detectar tendncias.
todas as partes envolvidas, os requisitos do processo podem ser modificados neste ponto para atingir os critrios de concluso.
7.1.2 Planejamento. Esta atividade consiste na seguinte
tarefa:
7.1.2.1 O gerente deve preparar os planos para execuo
7 Processos organizacionais de ciclo de vida

Este captulo define os seguintes processos organizacionais de ciclo de vida: 1) Processo de gerncia; 2) Processo de infra-estrutura; 3) Processo de melhoria; 4) Processo de treinamento. As atividades e tarefas em um processo organizacional so de responsabilidade da organizao que o utiliza. Essa organizao garante que o processo existe e funcional. 7.1 Processo de gerncia O processo de gerncia contm as atividades e tarefas genricas que podem ser empregadas por quaisquer das partes que tm que gerenciar seu(s) respectivo(s) processo(s). O gerente responsvel pelo gerenciamento de produto, gerenciamento de projeto e gerenciamento de tarefa do(s) processo(s) aplicvel(eis), tais como aquisio, fornecimento, desenvolvimento, operao, manuteno ou processos de apoio. Lista de atividades. Este processo consiste nas seguintes atividades: 1) Iniciao e definio do escopo; 2) Planejamento; 3) Execuo e controle; 4) Reviso e avaliao; 5) Concluso.
do processo. Os planos associados execuo do processo devem conter descries das tarefas e atividades associadas e identificao dos produtos de software que sero providos. Esses planos no se limitam a, mas devem incluir o seguinte: a) Cronogramas para a concluso oportuna das tarefas; b) Estimativa de esforo; c) Recursos adequados necessrios para executar as tarefas; d) Alocao das tarefas; e) Atribuio de responsabilidades; f) Quantificao de riscos associados com as tarefas ou com o prprio processo; g) Medidas de controle de qualidade a serem empregadas durante o processo; h) Custos associados com a execuo do processo; i) Proviso de ambiente e infra-estrutura.
7.1.3 Execuo e controle. Esta atividade consiste nas
seguintes tarefas:
7.1.3.1 O gerente deve iniciar a implementao do plano
para atender o conjunto de objetivos e critrios, exercendo controle sobre o processo.

7.1.3.2 O gerente deve monitorar a execuo do processo, provendo relatrios internos do progresso do processo e relatrios externos para o adquirente, conforme definido no contrato. 7.1.3.3 O gerente deve investigar, analisar e resolver os
problemas descobertos durante a execuo do processo. A resoluo de problema pode resultar em alteraes dos planos. responsabilidade do gerente garantir que o impacto de quaisquer alteraes seja determinado, controlado e monitorado. Os problemas e suas resolues devem ser documentados.
Cpia no autorizada
26
7.1.3.4 O gerente deve reportar em pontos acordados o
7.2.2.2 A infra-estrutura deve ser instalada a tempo para a
progresso do processo, demonstrando aderncia aos planos e resolvendo casos de necessidade de progresso. Isto inclui relatrios internos e externos, conforme requerem os procedimentos organizacionais e o contrato.
7.1.4 Reviso e avaliao. Esta atividade consiste nas
execuo do processo relevante.

7.2.3 Manuteno da infra-estrutura. Esta atividade

7.2.3.1 A infra-estrutura deve ser mantida, monitorada e
seguintes tarefas:
7.1.4.1 O gerente deve garantir que o software e os planos sejam avaliados para satisfazer requisitos. 7.1.4.2 O gerente deve verificar os resultados da avaliao
modificada quando necessrio, para garantir que ela continue a satisfazer os requisitos do processo que emprega este processo. Como parte da manuteno da infraestrutura, deve ser definido at que ponto a infra-estrutura est sob controle da gerncia de configurao. 7.3 Processo de melhoria O processo de melhoria um processo para estabelecer, avaliar, medir, controlar e melhorar um processo de ciclo de vida de software. Lista de atividades: Este processo consiste nas seguintes atividades: 1) Estabelecimento do processo; 2) Avaliao do processo; 3) Melhoria do processo.
7.3.1 Estabelecimento do processo. Esta atividade consiste
dos produtos de software, atividades e tarefas finalizados durante a execuo do processo para atingir os objetivos e para concluir os planos.
7.1.5 Concluso. Esta atividade consiste nas seguintes
tarefas:
7.1.5.1 Quando todos os produtos de software, atividades
e tarefas estiverem completos, o gerente deve determinar se o processo est completo, levando em considerao os critrios especificados no contrato ou como parte de um procedimento da organizao.
7.1.5.2 Para finalizar, o gerente deve verificar os resultados e registros dos produtos de software, atividades e tarefas empregados. Estes resultados e registros devem ser arquivados em um ambiente adequado, conforme especificado no contrato.
7.2 Processo de infra-estrutura O processo de infra-estrutura um processo para estabelecer e manter a infra-estrutura necessria para qualquer outro processo. A infra-estrutura pode incluir hardware, software, ferramentas, tcnicas, padres e recursos para o desenvolvimento, operao ou manuteno. Lista de atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Estabelecimento da infra-estrutura; 3) Manuteno da infra-estrutura.

7.3.1.1 A organizao deve estabelecer um conjunto de
processos organizacionais para todos os processos de ciclo de vida de software que se aplicam para suas atividades de negcio. Os processos e suas aplicaes para casos especficos devem ser documentados em publicaes da organizao. Quando apropriado, um mecanismo de controle de processo deveria ser estabelecido para desenvolver, monitorar, controlar e melhorar o(s) processo(s).
7.3.2 Avaliao do processo. Esta atividade consiste nas
seguintes tarefas:
7.3.2.1 Um procedimento de avaliao de processo deveria ser desenvolvido, documentado e aplicado. Registros de avaliao deveriam ser guardados e preservados. 7.3.2.2 A organizao deve planejar e executar revises

7.2.1.1 A infra-estrutura deveria ser definida e documentada de acordo com os requisitos do processo que emprega este processo, considerando os procedimentos, padres, ferramentas e tcnicas aplicveis. 7.2.1.2 O estabelecimento da infra-estrutura deveria ser
dos processos em intervalos apropriados para garantir sua contnua adequao e eficincia, considerando os resultados da avaliao.
7.3.3 Melhoria do processo. Esta atividade consiste nas
planejado e documentado.
7.2.2 Estabelecimento da infra-estrutura. Esta atividade

7.2.2.1 A configurao da infra-estrutura deveria ser pla-
seguintes tarefas:
7.3.3.1 A organizao deve efetuar tais melhorias nos seus processos se for determinada esta necessidade, como resultado da avaliao e reviso do processo. A documentao do processo deveria ser atualizada para refletir a melhoria dos processos organizacionais.
nejada e documentada. Deveriam ser considerados: a funcionalidade, o desempenho, a proteo, a segurana, a disponibilidade, os requisitos de espao, os equipamentos, os custos e as restries de tempo.
Cpia no autorizada
27
7.3.3.2 Dados histricos, tcnicos e de avaliao de-
veriam ser coletados e analisados para aumentar um entendimento dos pontos fortes e fracos dos processos empregados. Estas anlises deveriam ser usadas como realimentao (feedback) para melhorar estes processos, para recomendar alteraes nas diretrizes dos projetos (ou projetos subseqentes), e para determinar necessidades de avanos tecnolgicos.
7.3.3.3 Dados de custo de qualidade deveriam ser cole-
na seguinte tarefa:
7.4.1.1 Uma reviso dos requisitos do projeto deve ser
tados, mantidos e usados, para melhorar os processos da organizao como uma atividade gerencial. Estes dados devem servir ao propsito de estabelecer o custo de preveno e resoluo de problemas e no-conformidade em produtos e servios de software. 7.4 Processo de treinamento O processo de treinamento um processo para prover e manter pessoal treinado. A aquisio, o fornecimento, o desenvolvimento, a operao ou a manuteno de produtos de software extremamente dependente de pessoal com conhecimento e qualificao. Por exemplo: pessoal de desenvolvimento deveria ter treinamento bsico em gerncia de software e engenharia de software. , portanto, imperativo que o treinamento de pessoal seja planejado e implementado com antecedncia para que o pessoal treinado esteja disponvel quando o produto de software for adquirido, fornecido, desenvolvido, operado ou mantido. Lista de atividades. Este processo consiste nas seguintes atividades: 1) Implementao do processo; 2) Desenvolvimento do material de treinamento; 3) Implementao do plano de treinamento.
conduzida para estabelecer e providenciar, oportunamente, a aquisio ou o desenvolvimento de recursos e conhecimentos necessrios ao pessoal tcnico e gerencial. Os tipos e nveis de treinamento e categorias de pessoal que necessitam de treinamento devem ser determinados. Um plano de treinamento deveria ser desenvolvido e documentado, de acordo com os cronogramas de implementao, requisitos de recurso e necessidades de treinamento.
7.4.2 Desenvolvimento do material de treinamento. Esta
atividade consiste na seguinte tarefa:

7.4.2.1 Manuais de treinamento, incluindo materiais de
apresentao utilizados para prover treinamento, deveriam ser desenvolvidos.

7.4.3 Implementao do plano de treinamento. Esta
atividade consiste nas seguintes tarefas:

7.4.3.1 O plano de treinamento deve ser implementado
para prover treinamento ao pessoal. Registros de treinamento deveriam ser preservados.

7.4.3.2 Deveria ser assegurado que uma equipe ade-
quadamente treinada esteja disponvel, oportunamente, para as atividades e tarefas planejadas. Esta equipe deveria ser formada por uma composio e categorias corretas de pessoal.
/ANEXOS
Cpia no autorizada
28
Anexo A (normativo) Processo de adaptao

O processo de adaptao um processo para realizar a adaptao bsica desta Norma para um projeto de software. Este anexo fornece requisitos para adaptar esta Norma. Lista de atividades. Este processo consiste nas seguintes atividades: 1) Identificao do ambiente do projeto; 2) Solicitao de informaes; 3) Seleo de processos, atividades e tarefas; 4) Documentao de decises e motivos da adaptao.
A.3 Seleo de processos, atividades e tarefas.

Esta atividade consiste nas seguintes tarefas: A.3.1 Os processos, atividades e tarefas que sero executados devem ser determinados. Isto inclui a documentao a ser desenvolvida e quem ser responsvel por ela. Para este propsito, esta Norma deveria ser avaliada em relao aos dados relevantes reunidos em A.1 e A.2. A.3.2 Os processos, atividades e tarefas que foram determinados em A.3.1, mas no providos nesta Norma, devem ser especificados no prprio contrato. Processos organizacionais do ciclo de vida (seo 7) deveriam ser avaliados para determinar se eles poderiam dar sustentao a estes processos, atividades e tarefas. A.3.3 Nesta Norma, requisitos so indicados pelas tarefas que contm deve ou dever. Deveria ser cuidadosamente considerado se estas tarefas devem ser mantidas ou suprimidas para um determinado projeto ou setor de negcio. Os fatores a serem considerados no se limitam a, mas incluem: risco, custo, cronograma, desempenho, tamanho, criticabilidade e interface humana.
A.1 Identificao do ambiente do projeto. Esta atividade consiste na seguinte tarefa: A.1.1 As caractersticas do ambiente do projeto que influenciaro na adaptao devem ser identificadas. Algumas das caractersticas podem ser: modelo de ciclo de vida; atividade atual de ciclo de vida de sistema; requisitos do sistema e do software; polticas, procedimentos e estratgias organizacionais; tamanho, criticabilidade e tipos do sistema, produto ou servio de software; e quantidade de pessoas e partes envolvidas.
A.2 Solicitao de informaes. Esta atividade consiste na seguinte tarefa: A.2.1 As informaes das organizaes que so afetadas pelas decises de adaptao devem ser solicitadas. Usurios, pessoal de suporte, gerentes de contrato e potenciais proponentes deveriam ser envolvidos na adaptao.
A.4 Documentao de decises e motivos da adaptao. Esta atividade consiste na seguinte tarefa:
A.4.1 Todas as decises de adaptao devem ser documentadas juntamente com seus motivos.
/ANEXO B
Cpia no autorizada
29
Anexo B (informativo) Orientao para adaptao

Nenhum projeto idntico a outro. Variaes nas polticas e procedimentos organizacionais, mtodos e estratgias de aquisio, tamanho e complexidade do projeto, requisitos e mtodos de desenvolvimento do sistema, entre outras coisas, influenciam na forma como um sistema adquirido, desenvolvido, operado e mantido. Para acomodar essas variaes, tanto quanto possvel, esta Norma foi escrita para um projeto genrico. Portanto, no interesse de reduo de custo e melhoria da qualidade, esta Norma deveria ser adaptada para um projeto especfico. Todas as partes envolvidas no projeto deveriam ser envolvidas na adaptao. b) Verificao (6.4) e validao (6.5) so conduzidas pelo adquirente, pelo fornecedor ou por uma parte independente, para verificar e validar os produtos em nveis variveis de detalhamento, dependendo do projeto. Estas avaliaes no so redundantes nem substituem outras avaliaes, apenas as complementam. c) Revises conjuntas (6.6) e auditorias (6.7) so conduzidas em um frum conjunto pelas partes revisora e revisada, para avaliar o estado e a conformidade de produtos e atividades, em relao aos cronogramas previamente acordados. d) Garantia da qualidade (6.3) conduzida por pessoal independente do pessoal diretamente responsvel pelo desenvolvimento do produto de software ou pela execuo do processo. O objetivo garantir, com independncia, a conformidade dos produtos de software e processos com os requisitos do contrato e aderncia aos planos estabelecidos. Este processo pode utilizar os resultados de a, b e c, descritos anteriormente, como entradas. Este processo pode coordenar suas atividades com as de a, b e c. e) Melhoria (7.3) conduzida por uma organizao para o gerenciamento eficiente e automelhoria de seu processo. Esta conduzida independentemente do projeto ou requisitos do contrato.
B.1 Orientao geral de adaptao

Esta seo prov orientao na adaptao desta Norma e no exaustiva. Esta seo pode ser usada para realizar um primeiro nvel de adaptao desta Norma para uma determinada organizao ou rea de negcio. Por exemplo, aeronutica, nuclear, mdica, militar, agropecuria, comercial. Um segundo nvel de adaptao deveria ser realizado para cada projeto ou contrato especfico.
B.2 Adaptao do processo de desenvolvimento

O processo de desenvolvimento (5.3) necessita de ateno especial, porque este processo pode ser utilizado por diferentes partes, com objetivos diferentes. Como um primeiro nvel de adaptao deste processo, recomendado o seguinte: a) Para um produto de software que esteja embutido ou integrado ao sistema: todas as atividades do processo deveriam ser consideradas e deveria ser esclarecido se o desenvolvedor requerido para executar ou dar suporte s atividades do sistema. b) Para um produto de software independente, as atividades do sistema (5.3.2, 5.3.3, 5.3.10 e 5.3.11) podem no ser requeridas, mas deveriam ser consideradas.
B.4 Consideraes de adaptao e aplicao

Os pargrafos desta seo fornecem uma viso geral de consideraes de adaptao e aplicao para as caractersticas chave do projeto. As consideraes e as caractersticas no so exaustivas e representam apenas a forma atual de pensar. A figura B.1 fornece um exemplo da aplicao desta Norma. Polticas organizacionais. Determina quais polticas organizacionais so relevantes e aplicveis, tais como: linguagens de computador, proteo e segurana, requisitos do hardware e gerenciamento de risco. As sees desta Norma, relacionadas com estas polticas organizacionais, deveriam ser mantidas. Estratgia de aquisio. Determina quais estratgias de aquisio so relevantes e aplicveis para o projeto, tais como: tipos de contrato, mais de um contratado, envolvimento de subcontratados e agentes de verificao e validao, nvel de envolvimento do adquirente com os contratados e avaliao da capacidade dos contratados. As sees desta Norma, relacionadas com estas estratgias, deveriam ser mantidas. Conceito de suporte. Determina quais conceitos de suporte so relevantes e aplicveis, tais como: durao esperada de suporte, grau de alterao e se o suporte ser fornecido pelo adquirente ou pelo fornecedor. Para um produto de software que venha a ter uma vida longa de suporte ou para o qual se espere mudanas significativas, todos os requisitos de documentao deveriam ser considerados. aconselhvel ter a documentao automatizada.
B.3 Adaptao das atividades relacionadas com avaliao

As pessoas envolvidas em qualquer atividade de um processo ou de ciclo de vida de um projeto, conduzem avaliaes de produto de software e atividades, prprios ou de outros. Esta Norma agrupa estas avaliaes em cinco categorias, as quais esto listadas abaixo. As quatro primeiras categorias de avaliao esto em nvel de projeto; a ltima est em nvel organizacional. Estas avaliaes deveriam ser selecionadas e adaptadas de acordo com o escopo, magnitude, complexidade e criticabilidade do projeto ou da organizao. Os relatrios de problema, de no-conformidade e de melhoria destas avaliaes alimentam o processo de resoluo de problema (6.8). a) Avaliaes internas de processos (tarefas de avaliao de 5.1 a 5.5) so conduzidas pelo pessoal que executa as tarefas atribudas, dentro do processo, durante as suas atividades dirias.
Cpia no autorizada
30
Modelo(s) de ciclo de vida. Determina qual(is) modelo(s) de ciclo de vida (so) relevante(s) e aplicvel(is) para o projeto, tais como cascata, evolucionrio, construtivo, incremental e espiral. Todos estes modelos prescrevem certos processos e atividades que podem ser executados em seqncia, repetidamente e em combinao; nestes modelos as atividades de ciclo de vida desta Norma deveriam ser mapeadas para o(s) modelo(s) selecionado(s). Para os modelos evolucionrio, construtivo e incremental, os resultados de uma atividade do projeto alimentam a prxima. Nestes casos, a documentao deveria estar completa ao final de uma atividade ou tarefa. Partes envolvidas. Determina ou identifica a quantidade de pessoas e quais partes esto envolvidas no projeto, tais como: adquirente, fornecedor, desenvolvedor, subcontratado, agente de verificao, agente de validao, mantenedor. Todos os requisitos relacionados com as interfaces organizacionais entre duas partes esto sob considerao; por exemplo, adquirente com desenvolvedor, e fornecedor com agente de verificao ou de validao. Um grande projeto envolvendo muitas pessoas (dezenas ou centenas) necessita de significativa superviso e controle gerenciais. Ferramentas, tais como: avaliaes internas e independentes, revises, auditorias, inspees e coleta de dados so importantes para um grande projeto. Para projetos pequenos, estes controles podem ser excessivos. Atividade de ciclo de vida de sistema. Determina quais atividades correntes de ciclo de vida de sistema so relevantes e aplicveis, tais como: incio do projeto pelo adquirente; desenvolvimento pelo fornecedor e manuteno. Alguns cenrios: O adquirente est iniciando ou definindo os requisitos do sistema. Estudos de viabilidade e prototipao de requisitos e projeto podem ser conduzidos. Cdigo do software para prottipos pode ser desenvolvido, o qual pode ou no ser utilizado, mais tarde, no desenvolvimento dos produtos de software realizado sob contrato. Requisitos do sistema e requisitos preliminares do software podem ser desenvolvidos. Nestes casos, o processo de desenvolvimento (5.3) pode ser usado mais como um guia do que como requisito; o rigor na qualificao e avaliao pode no ser necessrio; e revises conjuntas e auditorias podem no ser necessrias. O desenvolvedor est produzindo produtos de software sob contrato. Neste caso todos os requisitos do processo de desenvolvimento (5.3) deveriam ser considerados durante a adaptao. O mantenedor est modificando produtos de software. O processo de manuteno (5.5) est sob considerao. Partes do processo de desenvolvimento (seo 5.3) podem ser usadas como miniprocessos. Caractersticas do nvel de sistema. Determina quais as caractersticas do nvel de sistema so relevantes e aplicveis, tais como: a quantidade de subsistemas e itens de configurao. Se o sistema tiver muitos subsistemas ou itens de configurao, o processo de desenvolvimento (5.3) deveria ser cuidadosamente adaptado para cada subsistema e item de configurao. Todos os requisitos de interface e de integrao deveriam ser considerados.
Caractersticas do nvel de software. Determina quais as caractersticas do nvel de software so relevantes e aplicveis, tais como: quantidade de itens de software, tipos, tamanho e criticabilidade dos produtos de software, e riscos tcnicos. Se o produto de software tiver muitos itens de software, componentes e unidades, o processo de desenvolvimento (5.3) deveria ser cuidadosamente adaptado para cada item de software. Todos os requisitos de interface e de integrao deveriam ser considerados. Determina quais tipos de produto de software esto envolvidos, pois tipos diferentes de software podem requerer diferentes decises de adaptao. Alguns exemplos: a) Novo desenvolvimento. Todos os requisitos, particularmente o processo de desenvolvimento (5.3), deveriam ser considerados b) Uso de produto de software de prateleira na forma em que se encontra. Todo o processo de desenvolvimento (5.3) pode ser excessivo. Desempenho, documentao, direitos de propriedade, de uso, de autoria, de garantia e de licena e suporte futuro relacionado ao produto de software, deveriam ser avaliados. c) Modificao do produto de software de prateleira. A documentao pode no estar disponvel. Dependendo da criticabilidade e alteraes futuras esperadas, o processo de desenvolvimento (5.3) deveria ser utilizado via processo de manuteno (5.5). Desempenho, documentao, direitos de propriedade, de uso, de autoria, de garantia e de licena e suporte futuro relacionado ao produto de software, deveriam ser avaliados d) Produto de software ou firmware embutido ou integrado a um sistema. Desde que tal produto de software uma parte de um sistema maior, as atividades relacionadas ao sistema no processo de desenvolvimento (5.3) deveriam ser consideradas e determinado se sero executadas ou suportadas. Se o produto de software ou firmware no tende a ser modificado no futuro, necessidades de documentao extensa deveriam ser examinadas cuidadosamente. e) Produto de software que independente. Desde que tal produto de software no parte de um sistema, as atividades relacionadas ao sistema no processo de desenvolvimento (5.3) no necessitam ser consideradas. As necessidades de documentao, especialmente para manuteno, deveriam ser examinadas cuidadosamente. f) Produto de software que no ser entregue. J que nenhum item est sendo adquirido, fornecido ou desenvolvido, nenhuma proviso nesta Norma, com exceo da atividade 5.3.1.5 no processo de desenvolvimento (5.3), deveria ser considerada. Entretanto, se o adquirente decide adquirir uma parte deste produto de software para futura operao e manuteno, ento este produto de software deveria ser tratado como nos itens b) ou c), descritos anteriormente.
Cpia no autorizada
31
Outras consideraes Quanto maior a dependncia do sistema em relao ao prazo de entrega e operao correta do produto de software, maior controle gerencial deveria ser imposto via testes, revises, auditorias, verificao, validao e outros. Por outro lado, um controle gerencial excessivo para um produto de software no-crtico ou de pequeno porte pode no ser apropriado em termos de custo. Outras entradas Tempo
O desenvolvimento do produto de software pode envolver riscos tcnicos. Se a tecnologia de software utilizada no estiver amadurecida, ou se o produto de software a ser desenvolvido complexo e sem precedentes, ou se o produto de software contm requisitos crticos de proteo, segurana ou outros, ento, especificao, projeto, testes e avaliaes rigorosos podem ser necessrios. Verificao e validao independentes podem ser importantes. Modelos e mtodos
Requisitos Legislao Segurana Proteo
Normas de processos de ciclo de vida de software
Cascata
Espiral
E M P R E S A
Mtodo
Credenciais (NBR 9001 ....)
Ambiente
Capacidade organizacional Aplicao Adaptao Avaliao Teste ETC
Manual da qualidade
Procedimentos
O que Quem Adquirente Fornecedor Aquisio Fornecimento Desenvolvimento Operao Manuteno
Contrato
Desenvolvedor
Plano de qualidade Plano de projeto
Operadores
Manutenedores
Projeto iniciado
Figura B.1 - Um exemplo de aplicao desta Norma /ANEXO C
Cpia no autorizada
32
Anexo C (informativo) Orientaes sobre processos e organizaes

Para proporcionar um melhor entendimento, este anexo apresenta uma discusso sobre os processos, as organizaes e seus relacionamentos sob pontos de vista relevantes. processo de desenvolvimento e um processo de manuteno. Em cada processo so apresentadas suas atividades. O processo de desenvolvimento empregado por engenheiros de desenvolvimento para produzir produtos de software. O processo de manuteno empregado pelos engenheiros de manuteno para modificar o software e mant-lo atualizado. A viso de operao tem um processo de ciclo de vida (ver o quadro sombreado mais abaixo direita, dentro dos processos fundamentais de ciclo de vida): um processo de operao e suas respectivas atividades. O processo de operao empregado para operar o software para seus usurios. A viso da gerncia da qualidade tem cinco processos de ciclo de vida (ver o quadro sombreado dentro dos processos de apoio de ciclo de vida): processo de garantia da qualidade; processo de verificao; processo de validao; processo de reviso conjunta; e processo de auditoria. Suas atividades constituintes no so mostradas. Esses processos relacionados qualidade so empregados para gerenciar qualidade ao longo do ciclo de vida de software. Os processos de verificao, validao, reviso conjunta e auditoria podem ser empregados separadamente por diferentes partes e tambm como tcnicas do processo de garantia da qualidade. A viso de gerncia tem um processo (ver quadro sombreado dentro dos processos organizacionais de ciclo de vida): um processo de gerncia que utilizado por qualquer organizao para gerenciar seu respectivo processo. Suas atividades constituintes so apresentadas.
C.1 Processos sob pontos de vista relevantes

Esta Norma contm os processos que so aplicveis ao longo do ciclo de vida de software. Entretanto, estes processos podem ser utilizados de diferentes formas, por diferentes organizaes e partes, com diferentes vises e objetivos. Esta seo apresenta os processos e seus relacionamentos sob pontos de vista relevantes. Ver 4.1.1 para sinopses dos processos. A figura C.1 representa os processos de ciclo de vida de software e seus relacionamentos sob diferentes vises de utilizao desta Norma. As vises bsicas mostradas so: contrato, gerncia, operao, engenharia e apoio. Sob a viso de contrato, as partes adquirente e fornecedor negociam e celebram um contrato, empregando respectivamente o processo de aquisio e o processo de fornecimento. Sob a viso de gerncia, o adquirente, fornecedor, desenvolvedor, operador, mantenedor ou outra parte, gerencia seu respectivo processo. Sob a viso de operao, o operador prov servio de operao de software para os usurios. Sob a viso de engenharia, o desenvolvedor ou mantenedor conduz suas respectivas tarefas de engenharia para produzir ou modificar produtos de software. Sob a viso de apoio, as partes (tais como gerncia de configurao, garantia da qualidade) provem servios de apoio a outros, atendendo s tarefas especficas. Tambm so mostrados os processos organizacionais (veja o quadro em segundo plano); que so empregados por uma organizao em nvel corporativo para estabelecer, implementar e continuamente melhorar uma estrutura subjacente constituda de processo(s) de ciclo de vida e pessoal associado. A figura C.2 apresenta os processos de ciclo de vida fundamentais (no alto, quadro esquerdo), de apoio (no alto, quadro direito) e organizacionais (quadro de baixo) e os nomes de suas atividades constituintes sob diferentes vises. Um numeral, prefixado a um processo, refere-se ao nmero da seo nesta Norma. A viso de contrato tem dois processos de ciclo de vida (ver quadro sombreado no alto, dentro dos processos fundamentais de ciclo de vida): um processo de aquisio para o adquirente e um processo de fornecimento para o fornecedor. Em cada processo so apresentadas suas atividades. Esses processos definem as tarefas para o adquirente e para o fornecedor, respectivamente, do ponto de vista contratual. A viso da engenharia tem dois processos de ciclo de vida (ver o quadro sombreado mais abaixo esquerda, dentro dos processos fundamentais de ciclo de vida): um
C.2 Processos, organizaes e relacionamentos

Os processos e organizaes (ou partes) se relacionam apenas funcionalmente. Eles no impem uma estrutura para uma organizao (ou uma parte). Nesta Norma, os termos organizao e parte so quase sinnimos. Uma organizao um grupo de pessoas organizado para um propsito especfico, como um clube, sindicato, corporao ou sociedade. Quando uma organizao, como um todo ou uma parte, celebra um contrato, ela uma parte. Organizaes so entidades separadas, mas as partes podem ser da mesma organizao ou de organizaes distintas. Uma organizao ou uma parte denominada pelo processo que executa. Por exemplo, chamada de adquirente quando executa o processo de aquisio. Uma organizao pode executar um ou mais processos; um processo pode ser executado por uma ou mais organizaes. Sob um contrato ou aplicao desta Norma, uma determinada parte no deveria executar ambos os processos de aquisio e de fornecimento, mas pode executar outros processos.
Cpia no autorizada
33
Nesta Norma, os relacionamentos entre os processos so estticos. importante ressaltar que os relacionamentos dinmicos e efetivos entre os processos, entre as partes e entre os processos e as partes so estabelecidos automaticamente quando a Norma aplicada nos projetos de software. Cada processo (e a parte que o executa) contribui para o projeto de software de sua maneira prpria e nica. O processo de aquisio (e o adquirente) contribui definindo o sistema, o qual conteria o produto de software. O processo de fornecimento (e o fornecedor) contribui provendo o produto de software ou servio do qual aquele sistema dependeria.
O processo de desenvolvimento (e o desenvolvedor) contribui examinando o sistema para uma correta definio do produto de software, pelo desenvolvimento do produto de software e pelo apoio integrao apropriada do produto de software ao sistema. O processo de operao (e o operador) contribui operando o produto de software no ambiente do sistema em benefcio dos usurios, do negcio, e do objetivo do sistema. O processo de manuteno (e o mantenedor) contribui mantendo e sustentando o produto de software para adequao operacional e fornecendo apoio e orientao aos usurios. Cada processo de apoio ou organizacional contribui fornecendo funes especializadas para outros processos, quando necessrio. Viso de contrato
emprega
Processo de aquisio
Processo de fornecimento
. Adquirente .Fornecedor
Viso de gerncia
emprega
emprega Processo de gerncia
Gerente
emprega emprega emprega Viso de operao emprega Processo de operao Operador/ usurio
emprega Viso de engenharia emprega Processo de manuteno Processo de desenvolvimento
. Desenvolvedor . Mantenedor
Viso de apoio Encarregado dos processos de suporte
Processos de apoio Documentao Gerncia de configurao Resoluo de problema Garantia da qualidade
Verificao Validao Reviso conjunta Auditoria
. Infra-estrutura . Melhoria . Treinamento
Processos organizacionais
Figura C.1 - Processos de ciclo de vida de software - Regras e relacionamentos
Cpia no autorizada
34
5. Processos fundamentais de ciclo de vida
6. Processos de apoio de ciclo de vida
Viso d e co ntrato
5.1 Processo de aquisio
Iniciao Preparao de pedido de proposta Preparao e atualizao do contrato Monitorao do fornecedor Aceitao e concluso
6.1 Processo de documentao
5.2 Processo de fornecimento

Iniciao Preparao Contrato Planejamento Execuo e controle Reviso e avaliao Entrega e concluso
6.2 Processo de gerncia de configurao
de resposta
V is so de g er rnc nci a da da qu ua aliida ade
Viso d e eng enh aria

5.3 Processo de desenvolvimento
Viso d e o pe rao
5.4 Processo de operao
Implementao do processo Teste operacional Suporte ao usurio
6.3 Processo de garantia da qualidade 6.4 Processo de verificao
Implementao do processo
Instalao do software
Apoio aceitao do software
Operao do sistema
Anlise de requisitos do sistema
Projeto da arquitetura do sistema
Integrao
do sistema
Teste de qualificao do sistema
6.5 Processo de validao 6.6 Processo de reviso conjunta 6.7 Processo de auditoria 6.8 Processo de resoluo de problema
5.5 Processo de manuteno

Anlise de requisitos do software Projeto da arquitetura do software Projeto detalhado do software Integrao do software Teste de qualificao do software Implementao do processo Anlise dos problemas e da modificao Reviso/ aceitao da manuteno
Implementao da modificao Codificao e integrao do software
Migrao
Descontinuao do software
7. Processos organizacionais de ciclo de vida
7.1 Processo de gerncia

Iniciao e definio do escopo Execuo e controle Reviso e avaliao Planejamento
7.2 Processo de infra-estrutura
7.4 Processo de treinamento
7.3 Processo de melhoria

Estabelecimento do processo Avaliao do processo Melhoria do processo
Concluso
A ordem de posio das atividades no significa ordem temporal. Os nomes das atividades no processo de desenvolvimento no so os nomes das fases de desenvolvimento.
Figura C.2 - Processos, vises e atividades de ciclo de vida de software
/ANEXO D
Cpia no autorizada
35
Anexo D (informativo) Bibliografia
NBR ISO/IEC 12119:1994, Tecnologia de informao Pacotes de software - Teste e requisitos de qualidade

NBR ISO 12207 - Tecnologia de Informacao - Processos de Ciclo de Vida de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NBR ISO 12207 - Tecnologia de Informacao - Processos de Ciclo de Vida de Software

Uploaded by

Copyright:

Available Formats

Cpia no autorizada

NBR ISO/IEC 12207 Tecnologia de informao - Processos de ciclo de vida de software

NBR ISO/IEC 12207:1998

1 Objetivo e campo de aplicao

NBR ISO/IEC 12207:1998

Para efeitpo de norma brasileira utilizar a NBR 13596:1996.

NBR ISO/IEC 12207:1998

NBR ISO/IEC 12207:1998

3.37 verso: Instncia identificada de um item.

4 Aplicao desta Norma

NBR ISO/IEC 12207:1998

5. Processos fundamentais de ciclo de vida 5.1 Aquisio

6. Processos de apoio de ciclo de vida 6.1 Documentao

6.2 Gerncia de configurao

6.3 Garantia de qualidade 5.4 Operao 6.4 Verificao

6.6 Reviso conjunta

6.8 Resoluo de problema

7. Processos organizacionais de ciclo de vida 7.1 Gerncia 7.2 Infra-estrutura

Figura 1 - Estrutura desta Norma

NBR ISO/IEC 12207:1998

4.1.3 Relacionamento entre os processos e as organizaes

5.1.1 Iniciao - Esta atividade consiste nas seguintes

5 Processos fundamentais de ciclo de vida

usado para executar as tarefas de 5.1.1.2 e 5.1.1.4.

NBR ISO/IEC 12207:1998

5.1.3 Preparao e atualizao do contrato. Esta atividade

consiste nas seguintes tarefas:

consiste nas seguintes tarefas:

nas seguintes tarefas:

organizao selecionada para executar as atividades de aquisio.

NBR ISO/IEC 12207:1998

5.1.5.3 Aps a aceitao, o adquirente deveria assumir a

5.2.3 Contrato. Esta atividade consiste nas seguintes

responsabilidade pela gerncia de configurao do produto de software entregue (ver 6.2).

com a organizao adquirente para fornecer o produto ou servio de software.

Esta atividade consiste nas seguin-

NBR ISO/IEC 12207:1998

5.2.5.3 O fornecedor deve monitorar e controlar o pro-

5.2.5.6 O fornecedor deve interagir com outras partes,

conforme especificado no contrato e nos planos do projeto.

reviso do contrato, interaes e comunicao com a organizao do adquirente.

Esta atividade consiste nas

plano(s) de gerenciamento do projeto desenvolvido(s) em 5.2.4.

da qualidade, de acordo com 6.3.

NBR ISO/IEC 12207:1998

5.2.7 Entrega e concluso.

Esta atividade consiste nas

5.3.1.2 O desenvolvedor deve:

de software, conforme especificado no contrato.

NBR ISO/IEC 12207:1998

c) Testabilidade; d) Viabilidade do projeto da arquitetura do sistema; e) Viabilidade da operao e manuteno.

Utilizar a NBR 13596.

NBR ISO/IEC 12207:1998

5.3.5.3 O desenvolvedor deve desenvolver e documentar

5.3.6.6 O desenvolvedor deve atualizar os requisitos de

um projeto de alto nvel para a base de dados.

teste e o cronograma para a integrao do software.

requisitos preliminares de teste e o cronograma para a integrao do software.

f) Viabilidade da operao e manuteno.

conjunta(s), de acordo com a seo 6.6.

do usurio, quando necessrio.

teste e o cronograma, para integrao do software.

um projeto detalhado para a base de dados.

do usurio, quando necessrio.