Medição do desafio confrontando o desenvolvimento do produto
A gama total de requisitos geralmente sobrecarrega o desenvolvimento do produto. Um programa aeroespacial em média começará com milhares de requisitos de clientes no nível do sistema, centenas de milhares no nível mais baixo de definição para os componentes e um número equivalente de itens e testes de verificação. Em um mundo perfeito, esses requisitos em cascata e suas informações relacionadas seriam definidos uma vez e usados durante o projeto.
Na realidade, os requisitos estão sempre mudando. Os clientes geralmente mudam suas preferências ou alcançam uma melhor compreensão de suas reais necessidades após olhar um projeto inicial. Os orientadores de mercado podem mudar durante o projeto de desenvolvimento ou as autoridades podem adicionar novas restrições geradas por considerações ambientais e de segurança. Às vezes, o projeto encontra um obstáculo que força uma revisão das metas iniciais. Em vigor, grandes projetos encaram centenas de alterações todos os dias e novas bases de requisitos podem ser criadas toda semana.
Essas demandas aumentam a necessidade absoluta de ferramentas de gerenciamento de requisitos para lidar diretamente com o gerenciamento de mudanças, a análise de impacto da mudança, revisões, opções, revisões e efetividades. Uma forte função de gerenciamento da configuração precisa ser providenciada.
Como um exemplo, uma importante empreiteira DoD dos EUA depende diretamente do desenvolvimento antecipado dos requisitos para controlar as mudanças contínuas encontradas no desenvolvimento do produto. Sem uma base definida anteriormente no esforço, aqueles em desenvolvimento geralmente instituem alterações para ajustes que eles simplesmente acham “bons”. Além disso, os clientes geralmente pensam em extensões com o tempo, muitas das quais podem representar bem boas ideias, mas infelizmente destroem todas as chances de atender às metas originais de tempo e orçamento. Historicamente, as tendências duplas dos desenvolvedores e clientes para alterar e adicionar ao escopo dos projetos levaram a requisitos progressivos, com mais projetos atrasando e ultrapassando o orçamento. Uma definição antecipada de requisitos durante a fase conceitual agora evita que os requisitos aumentem, para manter o esforço na programação e no orçamento, com um processo de ordem de alteração formal para aprovações oficiais estruturadas com a definição inicial da base.
As necessidades dos clientes representam a primeira entrada em um processo longo e complexo. Depois, os gerentes de programa e planejadores do produto desenvolvem seus próprios requisitos com base nessa entrada para especificar as necessidades funcionais. Essas necessidades e requisitos do subsistema serão a entrada para a fase seguinte de desenvolvimento dos requisitos ainda mais detalhados, em que até o nível mais baixo dos componentes cobrindo hardware, software ou equipamentos eletrônicos é totalmente especificado e projetado. Todas essas etapas do desenvolvimento de requisitos do produto acontecem em paralelo com a definição da verificação e plano de teste em cada etapa.
O processo dos seguintes requisitos termina com um esforço multidisciplinar, com cada área envolvida no detalhamento da definição de componentes nos domínios de hardware, software e equipamentos eletrônicos. Problemas que ultrapassam disciplinas são quase impossíveis de pegar com ferramentas de gerenciamento de requisitos que não são voltados a todos os esforços de desenvolvimento. Uma mudança na configuração do produto físico ou até mesmo a aplicação de regras de compatibilidade podem afetar uma versão a ser usada ou uma versão de software. Esse impacto pode ser detectado e analisado somente por meio de um link direto do sistema de gerenciamento de requisitos para os dados e processos dispostos para as disciplinas afetadas, com suporte da integração total com um sistema de gerenciamento de ciclo de vida do produto (PLM).
A recompensa e realidade de integrar o gerenciamento de requisitos com o PLM O PLM oferece uma base ou estrutura para oferecer suporte aos dados e consistência do processo em cada estágio do desenvolvimento do produto, começando com a definição antecipada de um produto ou serviço com base nas necessidades dos clientes. O impacto de qualquer alteração proposta nos requisitos deve ser analisado e acompanhado em diversas disciplinas. Em outra direção, o impacto de qualquer alteração em partes ou sistemas pode ser acompanhado e visualizado diretamente até os requisitos. Diversas disciplinas, que podem não conseguir traduzir o efeito das alterações diretamente de uma área para outra podem acompanhar e reconciliar o impacto de qualquer alteração em sua própria especialidade por meio da ajuda de uma estrutura de requisitos. A capacidade de acompanhar e visualizar o impacto representa um benefício principal de integrar totalmente o gerenciamento de requisitos com o PLM.
Citando uma recompensa substancial da integração total dos principais aplicativos, a empreiteira DoD, referida acima, acolheu a estratégia do PLM envolvendo todo o ciclo de vida do produto e integrando três aplicativos convencionais com o sistema PLM. A capacidade de gerenciamento do conhecimento empresarial do Teamcenter cria a estrutura detalhada do trabalho e gerencia o fluxo de esforços de desenvolvimento do produto. O aplicativo de engenharia do sistema e de gerenciamento de requisitos do Teamcenter mantém a rastreabilidade para acompanhar qualquer alteração até os requisitos e a estrutura detalhada de trabalho. As habilidades de requisitos definem a base da fase conceitual inicial, criando a declaração de trabalho, definindo o escopo de vários esforços e programando as tarefas. O gerenciamento do portfólio, do programa e do projeto do Teamcenter gerencia o custo e a programação, identificando os prazos críticos para todos. A integração total do gerenciamento de projeto e requisitos com o PLM permite que o desenvolvimento agrupe para rastrear o impacto das alterações até requisitos e tarefas para avaliar totalmente seus efeitos.
Em um contraste drástico, um importante fornecedor de equipamentos de teste automáticos focados totalmente na implantação da engenharia de sistemas e do gerenciamento de requisitos do Teamcenter para suportar a integração entre grupos de desenvolvimento mecânico, eletrônico e de software. O foco estreito reduz o tempo de implementação de “vários meses,” que, por sua vez, diminuiu o processo de alteração de um demorado ciclo de 55 dias para 12 dias e meio. Antes, eles simplesmente não conseguiam criar bons requisitos, gastando tempo e esforço significativos na área com um terço de saída desnecessária. O grupo de engenharia de sistemas e o escritório de gerenciamento do programa decidiram se concentrar em estabelecer uma abordagem de requisitos clara e concisa antecipadamente no esforço de desenvolvimento para oferecer suporte a bases importantes. Uma ferramenta e um processo devem ser aplicados entre disciplinas, incluindo hardware, equipamentos eletrônicos e software. O esforço recompensou mais no suporte da diminuição de requisitos e da rastreabilidade. No entanto, não é esperado que contribua efetivamente para o front end na tradução das necessidades qualitativas do cliente, com base no feedback e em pesquisas, em requisitos, que em seu ponto de vista sempre precisará de julgamento humano.
Com seu novo sistema, o gerenciamento de alterações se tornou muito mais eficiente, com controles mais precisos com base na integração com requisitos e suporte de processo melhorado. A rastreabilidade permite que todos os interessados entendam o impacto das alterações na redução de requisitos. Agora, todos os envolvidos podem estar certos de que todos os requisitos foram testados e o teste não é mais realizado para requisitos não
Para conseguir a recompensa total de um sistema comercial integrado, os requisitos nunca podem ser considerados isoladamente, uma vez que eles são associados ao plano de validação definido para garantir a implementação adequada. As informações combinadas precisam ser gerenciadas para suportar a solicitação e a prova de que a solicitação foi atendida.
O resultado dessas atividades combinadas entre diversas áreas apresenta uma rica e complexa rede de informações. O gerenciamento desse conteúdo deve sincronizar com todas as atividades de gerenciamento presentes na definição, no desenvolvimento, manufatura, entrega e suporte ao produto. Aliás, a função e contribuição do gerenciamento de requisitos se estende muito além da entrada inicial das necessidades dos clientes para conseguir iniciar um projeto. Os requisitos servem como o limite e linha de referência comum para todo o trabalho de engenharia na vida toda do produto, uma estrutura para promover a consistência e reconciliar alterações ou diferenças entre grupos.
Prioridades críticas para uma estrutura de gerenciamento de requisitos com o PLM O gerenciamento de requisitos exige um completo conjunto de habilidades que estabelece uma ligação forte entre diversas atividades de engenharia para desenvolvimento do produto:
• capturar necessidades e pesquisar requisitos para reutilização
• refinar, reduzir e validar requisitos
• alocar requisitos
• facilidade de uso para adoção geral
• verificar o projeto e produto em relação aos requisitos
• gerenciar e acompanhar os requisitos de impacto das alterações
A captura de necessidades
geralmente é realizada com documentos na forma de texto,que são facilmente analisados para destacar os requisitos significativos que podem ser extraídos. A maioria dos produtos ou sistemas de hoje contém muitos componentes ou subsistemas que são iguais ou semelhantes àqueles desenvolvidos por projetos anteriores. Raramente é mais de 20% do conteúdo de um produto ou sistema totalmente novo. Aliás, essa proporção de 20% geralmente gera boas inovações para reforçar o apelo aos clientes. A introdução de paradigmas totalmente novos, como o Apple iPhone, simplesmente não acontece com muita frequência.
Em geral, uma das mais importantes etapas ao iniciar um novo projeto está relacionada à pesquisa de requisitos existentes e estabelecidos que deve atender à nova necessidade para o cliente. Localizar esses requisitos não apenas economiza tempo do desenvolvimento de requisitos, como também oferece suporte ao pronto acesso às informações e resultados reutilizáveis. Isso pode incluir um plano de validação totalmente definido ou partes e softwares reutilizáveis, permitindo grandes economias. O maior nível de reutilização oferece maior recompensa.
Aliás, um fornecedor importante de equipamentos pesados obtém uma recompensa maior com o gerenciamento de requisitos da padronização que suporta a reutilização entre mais de trezentos produtos diferentes. Recursos comuns podem ser usados para sistemas eletrônicos controlar mecanismos hidráulicos, transmissões e outros mecanismos. Em vez de trezentos itens separados, uma série de famílias de produtos com recursos comuns foi definida e mantida pelo gerenciamento cuidadoso dos requisitos destacados. O Teamcenter oferece o banco de dados para organizar o detalhamento consistente do produto suportando a definição de recursos e a rastreabilidade. Os projetistas podem procurar posições de partes para componentes apropriados e acompanhar suas ligações para verificar onde e como os componentes são usados.
Para apresentar os dados ao gerente de requisitos, a ferramenta destacada deve ter pronto acesso aos planos de validação estabelecidos, a definição do produto para projetos antigos e estruturas do produto. Na verdade, a integração total com um sistema PLM se torna uma capacidade estratégica.
O refinamento, a redução e a validação de requisitos
envolvem funções específicas quedevem ser totalmente suportadas por uma ferramenta de gerenciamento de requisitos. Enquanto as funções relacionadas às etapas operacionais realizadas no gerenciamento de requisitos, elas definem e suportam fortes ligações em diversas atividades de engenharia como planejamento do produto, projeto do produto e simulação. Elas também oferecem a base para suportar a interação e colaboração com os clientes obtidos com os fornecedores. Como resultado, elas devem ser executadas em um ambiente suficientemente aberto, mas seguro para compartilhar o conteúdo apropriado. Os esforços relacionados envolvem o gerenciamento de acessos corretos, bases de criação, ilustrando o melhor possível a significância do requisito e a identificação das dependências com sua propagação para os níveis de projeto e disciplinas.
Alocar requisitos
para elementos da arquitetura do sistema ou da estrutura do produto estabelece e suporta a rastreabilidade entre requisitos e detalhes específicos e aborda que foi identificado para atender ao requisito. O planejador do produto, o arquiteto do sistema, o engenheiro de projeto, o analista, ou qualquer pessoa responsável por garantir que o requisito esteja alocado corretamente para uma solução técnica, deve ter acesso à ferramenta de gerenciamento de requisitos. Eles também devem ter acesso a qualquer ferramenta de gerenciamento de criação ou dados envolvida com esse requisito. Essa necessidade crítica apresenta claramente um dos principais benefícios de ter um sistema PLM implantado, ligando informações de diferentes fontes em diferentes contextos para criar uma rede de dados e processos consistente.Facilidade de uso para adoção geral:
Uma interface fácil de usar para uma gamaabrangente de usuários ocasionais, que não são especialistas no software especificado, é necessária, assim como atingir a recompensa total do gerenciamento de requisitos. A interface de usuário do Teamcenter será importante para o fornecedor de equipamentos de teste automático mencionado anteriormente, no próximo esforço planejado para integrar a verificação e o teste. Anteriormente, a programação e a atribuição de tarefas para teste eram completadas manualmente, iniciadas por e-mails sem estruturas. Foram necessários vários dias para pesquisar todos os grupos envolvidos para coordenar qualquer alteração no teste que poderia acontecer. A integração ativa do Teamcenter com o Excel que suporta fácil acesso documentará os requisitos e as alterações dinâmicas do suporte.
A capacidade de uso representa um adicional principal para a empreiteira DoD também, com o uso de interfaces ativas de aplicativos do Microsoft Office no front end para usuários da suite Teamcenter. Aproximadamente duzentos usuários atualmente confiam nas capacidades de requisitos sem envolver uma curva de aprendizagem significativa. Mais de seiscentos se beneficiam e possuem suporte por meio de interfaces e relatórios padrão fáceis de usar em diversos programas, com a integração total do Word e Excel.
A verificação de um projeto ou produto em relação aos requisitos
pode ser feita dediversas maneiras, de acordo com o nível da redução de requisitos envolvidos na validação e a natureza do item na estrutura do sistema ou produto que é alocada para o requisito. O software envolve funções de teste; as partes estruturais exigem simulação ou testes físicos; a manufatura acarreta a simulação do processo. Todas essas atividades são executadas com ferramentas específicas aplicando processos específicos. Todos gerenciam seus próprios conjuntos de dados. Para verificar se um requisito foi atendido, um plano de verificação específico ou plano de teste deve ser definido e associado ao requisito. Sua execução deve oferecer acesso aos meios de simular ou testar o sistema específico ou item do produto. Esse trabalho se torna complicado e demorado para produtos complexos. Sem o suporte de um sistema PLM para acompanhar todos os dados e criar as ligações corretas entre os elementos dispersos nos dados, a verificação é geralmente concluída apenas
Gerenciamento de requisitos
também representa uma tarefa complexa. Muitas ferramentas de gerenciamento de requisitos do passado negligenciavam esse aspecto, se concentrando principalmente nas capacidades de edição de textos para desenvolvimento de requisitos. Os requisitos apenas representam outra visão da estrutura do sistema ou do produto que deve ser gerenciado com as mesmas ferramentas e recursos. Isso inclui a organização de requisitos em estruturas com ligações e dependências, versão, bases, gerenciamento de alterações e gerenciamento de configurações. Como qualquer outro item na estrutura de um produto, o processo de alteração que direciona um projeto deve cobrir os requisitos e aplicar as regras de configuração em vigor. Se o projeto ou a engenharia solicitar uma alteração, seu impacto nos requisitos relacionados deve ser analisados. O processo de alteração deve incluir gerentes de requisitos na proposta de alteração e no processo de validação. Da mesma maneira, se uma alteração for solicitada em um requisito, o impacto total no sistema atual ou no projeto do produto deve ser analisado com engenheiros de projeto envolvidos ativamente na proposta de alteração e no processo de validação. A necessidade fundamental surge para unificar o processo de alteração em todas as disciplinas participantes no projeto de desenvolvimento de um produto, que, por sua vez, representa a justificativa principal para um sistema PLM.Esse documento é protegido por direitos autorais pela Collaborative Product Development Associates, LLC (CPDA) e está protegido pelas leis dos EUA e internacionais de direitos autorais e convenções. Este documento não pode ser copiado, reproduzido, armazenado em sistema recuperável, transmitido de nenhuma forma, publicado em um website público ou privado ou boletim, ou sublicenciado a terceiro sem o consentimento prévio da CPDA. Nenhum direito autoral pode ser oculto ou removido do documento. Collaborative Product Development Associates and CPDA são marcas registradas da Collaborative Product Development Associates, LLC. Todas as marcas registradas dos produtos e empresas referidas nesse documento estão protegidas.
Este documento foi desenvolvido com base em informações e fontes que acreditamos ser confiáveis. Este documento deve ser usado “como está”. A CPDA não oferece garantias ou representações a respeito e não será responsável pela precisão de dados, assunto, qualidade ou prazo do conteúdo.
