Text page

Os processos de ciclo de vida de software

O que representam os sistemas habilitadores? Quais são os processos do ciclo de vida para o sistema de software? Por que fazer a adoção em nível de projeto e organização? Qual é o modelo de ciclo de vida para o sistema de software? Essas interrogações estão sendo apresentadas na NBR ISO/IEC-IEEE 12207 de 08/2021 - Engenharia de sistemas e software - Processos de ciclo de vida de software.

08/09/2021 - Equipe Target

NBR ISO/IEC-IEEE 12207 de 08/2021 - Engenharia de sistemas e software - Processos de ciclo de vida de software

A NBR ISO/IEC-IEEE 12207 de 08/2021 - Engenharia de sistemas e software - Processos de ciclo de vida de software estabelece uma estrutura comum para processos de ciclo de vida de software, com terminologia bem definida, que pode ser referenciada pela indústria de software. Ele contém processos, atividades e tarefas que são aplicáveis durante a aquisição, fornecimento, desenvolvimento, operação, manutenção ou desativação de sistemas, produtos e serviços de software.

Estes processos de ciclo de vida são executados com sucesso por meio do envolvimento de stakeholders, com o objetivo final de alcançar a satisfação do cliente. Este documento é aplicável à aquisição, fornecimento, desenvolvimento, operação, manutenção e desativação de sistemas de software, produtos e serviços, e a parte de software de qualquer sistema (executados tanto interna como externamente a uma organização).

O software inclui a parte de software do firmware. Os aspectos de definição de sistema necessários para prover o contexto para produtos e serviços de software estão incluídos. Este documento também fornece os processos que podem ser empregados na definição, controle e melhoria dos processos de ciclo de vida de software dentro de uma organização ou projeto.

Os processos, atividades e tarefas deste documento também podem ser aplicados durante a aquisição de um sistema que contenha software, seja individualmente ou em conjunto com a ISO/IEC 15288:2015 - Systems and software engineering – System life cycle processes. No contexto deste documento e da ISO/IEC/IEEE 15288, há um continuum de sistemas desenvolvidos por humanos desde os que usam pouco ou nenhum software, até aqueles nos quais o software é o principal componente.

É raro encontrar um sistema complexo sem software e todos os sistemas de software exigem que os componentes do sistema físico (hardware) funcionem, ou seja, como parte do sistema de software de interesse. Assim, a escolha de quando aplicar este documento para os processos de ciclo de vida de software, ou a ISO/IEC/IEEE 15288: 2015 - Systems and software engineering–System life cycle processes, depende do sistema de interesse.

Os processos em ambos os documentos têm os mesmos propósitos e resultados de processo, mas diferem em atividades e tarefas para executar a engenharia de software ou a engenharia de sistemas, respectivamente. Assim, o propósito deste documento é fornecer um conjunto definido de processos para facilitar a comunicação entre adquirentes, fornecedores e outros stakeholders no ciclo de vida de um sistema de software.

Este documento foi escrito para adquirentes, fornecedores, desenvolvedores, integradores, operadores, mantenedores, gestores, gerentes de garantia de qualidade e usuários de sistemas, produtos e serviços de software. Ele pode ser usado por uma única organização de forma autoimposta ou em uma situação que envolva várias organizações. As partes podem ser da mesma organização ou de diferentes organizações, podendo variar para a realização de um acordo informal a um acordo formal.

Os processos neste documento podem ser usados como base para estabelecer ambientes de negócios, por exemplo, métodos, procedimentos, técnicas, ferramentas e pessoal treinado. O Anexo A fornece orientação normativa para a adaptação destes processos de ciclo de vida de software. Este documento é aplicável a todo o ciclo de vida de sistemas, produtos e serviços de software, incluindo concepção, desenvolvimento, produção, utilização, suporte e desativação, e à sua aquisição e fornecimento, sejam estes processos executados interna ou externamente a uma organização.

Os processos do ciclo de vida deste documento podem ser aplicados de forma concorrente, iterativa e recursiva a um sistema de software e de forma incremental aos seus elementos. Há uma grande variedade de sistemas de software em termos de propósito, domínio de aplicação, complexidade, tamanho, novidade, adaptabilidade, quantidade, localizações, vida útil e evolução.

Este documento descreve os processos que compõem o ciclo de vida de sistemas de software criados pelo homem. Portanto, aplica-se aos sistemas de software únicos, sistemas de software para ampla distribuição comercial ou pública e sistemas de software adaptáveis e customizados. Também se aplica a um sistema de software independente completo e aos sistemas de software que são incorporados e integrados a sistemas maiores, mais complexos e completos.

Este documento fornece um modelo de referência de processo caracterizado em termos de propósito e resultados de processo, que são consequência da execução bem-sucedida das tarefas da atividade. O Anexo B lista exemplos de artefatos e itens de informação que podem estar associados a vários processos. Este documento pode, portanto, ser usado como um modelo de referência para apoiar a avaliação de processo, conforme especificado na ISO/IEC 33002:2015.

O Anexo C fornece informações sobre o uso dos processos de ciclo de vida do software como um modelo de referência de processo. O Anexo D descreve os construtos do processo para uso no modelo de referência de processo. O Anexo I fornece a correspondência entre este documento e a ISO/IEC/IEEE 12207:2009 no nível de nome e resultado de processo.

Este documento não prescreve um modelo específico de ciclo de vida de software, metodologia de desenvolvimento, método, abordagem de modelagem ou técnica. Os usuários deste documento são responsáveis por selecionar um modelo de ciclo de vida para o projeto e por mapear os processos, atividades e tarefas deste documento naquele modelo. As partes também são responsáveis pela seleção e aplicação de metodologias, métodos, modelos e técnicas apropriados para o projeto.

Este documento não estabelece um sistema de gestão ou requer o uso de qualquer norma de sistema de gestão. No entanto, destina-se a ser compatível com o sistema de gestão da qualidade especificado pela NBR ISO 9001, com o sistema de gestão de serviços especificado pela NBR ISO/IEC 20000-1 (IEEE Std 20000-1) e com o sistema de gestão de segurança da informação especificado pela ISO/IEC 27000. Este documento não detalha itens de informação em termos de nome, formato, conteúdo explícito e mídia de registro. A ISO/IEC/IEEE 15289 aborda o conteúdo dos itens de informação de processo de ciclo de vida (documentação).

Acesse algumas questões relacionadas a essa norma GRATUITAMENTE no Target Genius Respostas Diretas:

O que representam os sistemas habilitadores?

Quais são os processos do ciclo de vida para o sistema de software?

Por que fazer a adoção em nível de projeto e organização?

Qual é o modelo de ciclo de vida para o sistema de software?

A complexidade dos sistemas de software aumentou a um nível sem precedentes. Isto levou a novas oportunidades, mas também aumentou os desafios para as organizações que criam e utilizam os sistemas. Estes desafios existem ao longo do ciclo de vida de um sistema e em todos os níveis de detalhes arquiteturais.

Este documento fornece uma estrutura de processo comum para descrever o ciclo de vida de sistemas criados por seres humanos, adotando uma abordagem de engenharia de software que é uma abordagem interdisciplinar e propicia a produção bem-sucedida de sistemas de software.

Ela foca a definição das necessidades dos stakeholders e a funcionalidade requerida no início do ciclo de desenvolvimento, a documentação dos requisitos, a execução da síntese do design e a validação do sistema, considerando o problema completo. Ela integra todas as disciplinas e grupos de especialidade em um esforço de equipe, formando um processo de desenvolvimento estruturado que passa do conceito à produção, operação e manutenção.

Ela considera tanto as necessidades de negócio quanto técnicas de todos os stakeholders, com o objetivo de fornecer um produto de qualidade que atenda às necessidades dos usuários e outros stakeholders aplicáveis. Este ciclo de vida abrange da concepção de ideias até a desativação de um sistema. Ela provê os processos para aquisição e fornecimento de sistemas.

Ela ajuda a melhorar a comunicação e a cooperação entre as partes que criam, utilizam e gerenciam sistemas de software modernos para que possam trabalhar de forma integrada e coerente. Além disso, a estrutura proposta contribui para a avaliação e melhoria dos processos do ciclo de vida.

Os processos neste documento formam um conjunto abrangente a partir do qual uma organização pode construir modelos de ciclo de vida de software apropriados para seus produtos e serviços. Uma organização, dependendo da sua finalidade, pode selecionar e aplicar um subconjunto apropriado para alcançar este propósito.

Este documento pode ser usado de uma ou mais das seguintes formas: por uma organização - para ajudar a estabelecer um ambiente de processos desejados. Estes processos podem ser sustentados por uma infraestrutura de métodos, procedimentos, técnicas, ferramentas e pessoal treinado. A organização pode então empregar este ambiente para executar e gerenciar seus projetos e evoluir sistemas de software ao longo as fases do ciclo de vida.

Dessa forma, este documento é usado para avaliar a conformidade de um ambiente declarado e estabelecido em relação ao que ele provê. Também pode ser usado por um projeto - para ajudar a selecionar, estruturar e utilizar os elementos de um ambiente estabelecido para fornecer produtos e serviços. Dessa forma, este documento é usado na avaliação da conformidade do projeto em relação ao ambiente estabelecido e declarado.

Pode ser utilizado por um adquirente e um fornecedor - para ajudar a desenvolver um acordo relativo a processos e atividades. Por meio desse acordo, os processos e atividades deste documento são selecionados, negociados, acordados e executados. Dessa forma, este documento é usado para orientar o desenvolvimento do acordo.

Pode ser usado por avaliadores de processo – para servir como um modelo de referência de processo utilizado na execução de avaliações de processo, que podem ser usadas para apoiar a melhoria do processo organizacional. Este documento fornece os requisitos para uma variedade processos adequados para uso durante o ciclo de vida de um sistema ou produto de software.

É reconhecido que projetos ou organizações específicos podem não precisar usar todos os processos fornecidos por este documento. Portanto, a implementação deste documento geralmente envolve a seleção e a declaração de um conjunto de processos adequados à organização ou projeto. Existem duas formas de reivindicar a conformidade com as disposições deste documento ? conformidade total e conformidade personalizada.

Existem dois critérios para reivindicar a conformidade total. Atingir qualquer destes critérios é suficiente para conformidade, embora o critério (ou critérios) escolhido (s) deva (m) ser declarado (s) na reivindicação. Reivindicar conformidade total com as tarefas afirma que todos os requisitos das atividades e tarefas do conjunto declarado de processos são alcançados.

Alternativamente, reivindicar conformidade total com os resultados afirma que todos os resultados requeridos do conjunto declarado de processos são alcançados. A conformidade total com resultados permite maior liberdade na implementação de processos e pode ser útil para implementar processos a serem usados no contexto de um modelo inovador de ciclo de vida.

Opções para conformidade são fornecidas para a flexibilidade necessária na aplicação deste documento. Cada processo tem um conjunto de objetivos (expressos como resultados) e um conjunto de atividades e tarefas que representam uma maneira de alcançar os objetivos. Os usuários que implementam as atividades e tarefas do conjunto declarado de processos podem afirmar conformidade total com as tarefas dos processos selecionados.

Alguns usuários, no entanto, podem ter variantes inovadoras de processos que atinjam os objetivos (ou seja, os resultados) do conjunto declarado de processos sem implementar todas as atividades e tarefas. Estes usuários podem afirmar conformidade total com os resultados do conjunto declarado de processos.

Os dois critérios - conformidade com tarefa e conformidade com resultado - não são necessariamente equivalentes, pois a execução específica de atividades e tarefas pode requerer, em alguns casos, um nível mais alto de capacidade do que apenas o alcance de resultados. Quando este documento é usado para auxiliar o desenvolvimento de um acordo entre um adquirente e um fornecedor, seções deste documento podem ser selecionadas para incorporação ao acordo, com ou sem modificação.

Neste caso, é mais apropriado que o adquirente e o fornecedor reivindiquem a conformidade com o acordo do que com este documento. Uma organização (por exemplo, pública, associação industrial, corporação) que impõe este documento, como condição comercial, pode especificar e tornar público o conjunto mínimo de processos, resultados, atividades e tarefas exigidos, que constituem a conformidade dos fornecedores com as condições do negócio.

Os requisitos deste documento são assinalados pelo uso do verbo deve. As recomendações são assinaladas pelo uso da expressão convém que. As permissões são assinaladas pelo uso do verbo pode. No entanto, apesar do termo usado, os requisitos de conformidade são selecionados conforme descrito anteriormente.

Uma reivindicação de conformidade total declara o conjunto de processos com os quais a conformidade é requerida. A conformidade total com resultados é alcançada pela demonstração que todos os resultados do conjunto declarado de processos foram alcançados. Nesta situação, as disposições para atividades e tarefas do conjunto declarado de processos são orientações e não requisitos, independentemente da expressão ou forma verbal usada na disposição.

Um uso pretendido deste documento é facilitar a avaliação e a melhoria do processo. Para este fim, os objetivos de cada processo são escritos na forma de resultados compatíveis com as disposições da ISO/IEC 33002 que fornece a avaliação dos processos deste documento, fornecendo uma base para melhorias. Os usuários que pretendem avaliar e melhorar processos podem usar os resultados de processo escritos no presente documento como o modelo de referência de processo requerido pela ISO/IEC 33002.

Uma reivindicação de conformidade total declara o conjunto de processos para os quais a conformidade é reivindicada. A conformidade total com tarefas é alcançada pela demonstração que todos os requisitos das atividades e tarefas do conjunto declarado de processos foram satisfeitos. Nesta situação, as disposições para os resultados do conjunto declarado de processos são orientações e não requisitos, independentemente da expressão ou forma verbal usada na disposição.

Uma reivindicação de conformidade total com tarefas pode ser apropriada em situações contratuais em que um adquirente ou um regulador requer um entendimento detalhado dos processos dos fornecedores. Quando este documento é utilizado como base para estabelecer um conjunto de processos que não se qualificam para conformidade total, as seções deste documento são selecionadas ou modificadas de acordo com o processo de adaptação prescrito no Anexo A.

O texto adaptado, para o qual a conformidade personalizada é reivindicada, é declarado. A conformidade personalizada é obtida pela demonstração de que foram alcançados os resultados, atividades e tarefas, conforme adaptados. As elaborações adicionais destes conceitos relativos à aplicação do gerenciamento do ciclo de vida podem ser encontradas nas ISO/IEC TS 24748-1, ISO/IEC TR 24748-2 e ISO/IEC TR 24748-3.

Os sistemas de software considerados neste documento são feitos, criados e utilizados por pessoas para fornecer produtos ou serviços em ambientes definidos para o benefício dos usuários e de outros stakeholders. Estes sistemas de software podem incluir os seguintes elementos de sistema: hardware, software, dados, pessoas, processos (por exemplo, processos para fornecer serviços aos usuários), procedimentos (por exemplo, instruções do operador), instalações, serviços, materiais e entidades.

Conforme vistos pelo usuário, eles são considerados produtos ou serviços. Este documento se aplica a sistemas para os quais o software é de primordial importância para os stakeholders. Este documento é baseado nos princípios gerais da engenharia de sistemas e engenharia de software.

É uma premissa fundamental deste documento que o software sempre exista no contexto de um sistema. Como o software não opera sem hardware, o processador no qual o software é executado pode ser considerado como parte do sistema. Como alternativa, o hardware ou serviços que hospedam o sistema de software e lidam com as comunicações com outros sistemas também podem ser vistos como sistemas habilitadores ou sistemas externos no ambiente operacional.

A percepção e a definição de um sistema de software específico, sua arquitetura e seus elementos dependem dos interesses e responsabilidades de um stakeholder. O sistema de interesse de um stakeholder pode ser visto como um elemento do sistema de interesse de outro stakeholder. Além disso, pode ser visto também como parte do ambiente de um sistema de interesse de outro stakeholder.

A seguir, são apresentados os principais pontos sobre as características de sistemas de interesse. Os limites definidos encapsulam necessidades significativas e soluções práticas; existem hierarquias ou outros relacionamentos entre os elementos do sistema. Uma entidade em qualquer nível no sistema de interesse pode ser vista como um sistema.

Um sistema compreende um conjunto integrado e definido de elementos de sistema subordinados e as pessoas podem ser vistas como usuários externos a um sistema e como elementos internos ao sistema (isto é, operadores); e um sistema pode ser visto isoladamente como uma entidade, isto é, um produto; ou como um conjunto de funções capazes de interagir com o ambiente ao seu redor, isto é, um conjunto de serviços. Quaisquer que sejam os limites escolhidos para definir o sistema, os conceitos neste documento são genéricos e permitem correlacionar ou adaptar instâncias individuais dos ciclos de vida aos princípios de sistema de um profissional.

Os processos do ciclo de vida neste documento são descritos em relação a um sistema de software que é composto por um conjunto de elementos que interagem (incluindo elementos de software), cada um dos quais pode ser implementado para satisfazer os respectivos requisitos especificados (figura abaixo). A responsabilidade pela implementação de qualquer elemento do sistema pode, portanto, ser delegada a outra parte por meio de um acordo.

Clique na imagem acima para uma melhor visualização

 

O relacionamento entre o sistema de software e o conjunto completo de seus elementos geralmente pode ser representado mostrando os relacionamentos entre os elementos ? frequentemente descritos como uma hierarquia para o mais simples dos sistemas de interesse. A decomposição é uma abordagem para algumas atividades de software.

Outras abordagens incluem a orientação a objetos, na qual os elementos do sistema são dispostos em um mesmo plano (não hierárquica), como em um diagrama de rede. Para sistemas de interesse de software mais complexos, pode ser necessário considerar um futuro elemento como um sistema (que por sua vez é composto por outros elementos) antes que um conjunto completo possa ser definido de forma confiável.

Dessa forma, os processos apropriados de ciclo de vida de sistema são aplicados recursivamente a um sistema de interesse para resolver sua estrutura, até que elementos compreensíveis e gerenciáveis do sistema de software possam ser implementados (criados, adaptados, adquiridos ou reutilizados). Pode-se dizer que todo sistema de software tem um ciclo de vida. Um ciclo de vida pode ser descrito usando um modelo funcional abstrato que representa a conceituação de uma necessidade do sistema, sua realização, utilização, evolução e desativação.

Um sistema de software evolui no seu ciclo de vida como resultado de ações das atividades dos processos. Estas ações são executadas e gerenciadas por pessoas nas organizações. Os detalhes no modelo de ciclo de vida são expressos em termos destes processos, seus resultados, relacionamentos e sequência.

FONTE: Equipe Target

Anúncio fixo da norma NBRISO9001 Chegou o novo app Target GEDWeb!
Busque e visualize suas normas ABNT NBR NM
Recursos exclusivos de busca, leitura por voz,
acesso off-line, navegação por setor e muito mais!
Produto/Serviço relacionado à NBRISO9001

Baseado nos documentos visitados

Normas recomendadas para você

Engenharia de sistemas e software - Processos de ciclo de vida de software
NBRISO/IEC-IEEE12207 de 08/2021

Engenharia de sistemas e software - Processos de ciclo de vida de software

Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Guia e modelo de referência para medição
NBRISO/IEC25020 de 03/2009

Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Guia e modelo de referência para medição

Engenharia de Software - Perfis de ciclo de vida para micro-organizações (VSEs) -Parte 2: Estrutura e taxonomia
NBRISO/IEC29110-2 de 02/2012

Engenharia de Software - Perfis de ciclo de vida para micro-organizações (VSEs) -Parte 2: Estrutura e taxonomia

Engenharia de software e de sistemas - Gerenciamento de ciclo de vida - Orientações para descrição de processos
ABNT ISO/IEC TR24774 de 02/2010

Engenharia de software e de sistemas - Gerenciamento de ciclo de vida - Orientações para descrição de processos

Engenharia de software e sistemas - Perfis de ciclo de vida para micro-organizações (VSE) - Parte 4-1: Engenharia de software - Especificações de perfil: Grupo de perfil genérico
NBRISO/IEC29110-4-1 de 03/2020

Engenharia de software e sistemas - Perfis de ciclo de vida para micro-organizações (VSE) - Parte 4-1: Engenharia de software - Especificações de perfil: Grupo de perfil genérico

Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Formato comum da indústria (FCI) para relatórios de teste de usabilidade
NBRISO/IEC25062 de 04/2011

Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Formato comum da indústria (FCI) para relatórios de teste de usabilidade

Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Planejamento e gestão
NBRISO/IEC25001 de 03/2009

Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Planejamento e gestão

Engenharia de software - Avaliação de produto - Parte 6: Documentação de módulos de avaliação
NBRISO/IEC14598-6 de 10/2004

Engenharia de software - Avaliação de produto - Parte 6: Documentação de módulos de avaliação

Software de produto para saúde - Parte 1: Orientação sobre a aplicação da ABNT NBR ISO 14971 a software para produtos para a saúde
ABNT IEC/TR80002-1 de 10/2020

Software de produto para saúde - Parte 1: Orientação sobre a aplicação da ABNT NBR ISO 14971 a software para produtos para a saúde

Engenharia de sistemas e de software - Processo de medição
NBRISO/IEC15939 de 01/2009

Engenharia de sistemas e de software - Processo de medição

Engenharia de software - Requisitos e Avaliação da Qualidade de Produto de Software (SQuaRE) - Requisitos de qualidade
NBRISO/IEC25030 de 09/2008

Engenharia de software - Requisitos e Avaliação da Qualidade de Produto de Software (SQuaRE) - Requisitos de qualidade

Engenharia de sistemas e de software - Processos de ciclo de vida - Gerenciamento de projeto
NBRISO/IEC-IEEE16326 de 09/2012

Engenharia de sistemas e de software - Processos de ciclo de vida - Gerenciamento de projeto

Engenharia de software e sistemas - Teste de software - Parte 1: Conceitos e definições
NBRISO/IEC-IEEE29119-1 de 06/2014

Engenharia de software e sistemas - Teste de software - Parte 1: Conceitos e definições

Software de dispositivo médico - Parte 2: Validação de software para sistemas de qualidade de dispositivos médicos
ABNT ISO/TR80002-2 de 08/2021

Software de dispositivo médico - Parte 2: Validação de software para sistemas de qualidade de dispositivos médicos