Trade off analysis in systems engineering

Decisões de compensação no design do sistema.
Compre este livro.
ISBN 978-3-319-43710-1 Envio gratuito para pessoas em todo o mundo Normalmente despachado dentro de 3 a 5 dias úteis.
Este livro é cerca de três aspectos principais do design do sistema: tomada de decisões sob incerteza, estudos de trade-off e análises de risco formal. Reconhecendo que o tratamento matemático desses tópicos é semelhante, os autores generalizam técnicas matemáticas existentes para cobrir as três áreas. Os pontos comuns a estes tópicos são pesos importantes, combinando funções, funções de pontuação, métricas quantitativas, priorização e análises de sensibilidade. Além disso, as atividades e problemas de tomada de decisão humana usam essas mesmas ferramentas. Portanto, esses problemas também são tratados uniformemente e modelados usando a teoria da perspectiva. Destinado a profissionais de engenharia e negócios e estudantes interessados ​​em engenharia de sistemas, análise de risco, gerenciamento operacional e modelagem de processos de negócios, Tradeoff Decisions no System Design explica como os seres humanos podem superar vieses cognitivos e evitar erros mentais ao realizar estudos de trade-off e análises de risco em uma ampla gama de domínios. Com o uso generoso de exemplos como um fio comum nos capítulos deste livro.
"Este livro fornece um excelente roteiro para projetar e produzir produtos competitivos. "
Dr. Terry Bahill é Professor Emérito de Sistemas e Engenharia Industrial na Universidade do Arizona, Tucson e autor de seis livros de engenharia e 250 artigos. O Dr. Bahill trabalhou com dezenas de empresas técnicas apresentando seminários sobre engenharia de sistemas e assessorando equipes de desenvolvimento de sistemas na descrição de seus processos de engenharia de sistemas. Membro eleito do IEEE, do Conselho Internacional de Engenharia de Sistemas (INCOSE) e do AAAS, seus interesses de pesquisa estão nos campos de design de sistemas, modelagem de sistemas fisiológicos, coordenação olho-mão-cabeça, tomada de decisão humana e engenharia de sistemas Aplicação e teoria.
O Dr. Azad M. Madni é Professor de Engenharia Astronáutica e Diretor Técnico de Arquitetura e Engenharia de Sistemas da Universidade do Sul da Califórnia. Ele é o fundador e presidente da Intelligent Systems Technology, Inc., uma empresa especializada em simulações educacionais, métodos, processos e ferramentas baseados em jogos para engenharia de sistemas complexos. Membro eleito do AAAS, do Instituto Americano de Aeronáutica e Astronáutica, do IEEE e do Conselho Internacional de Engenharia de Sistemas (INCOSE), seus prêmios recentes incluem o Prêmio Lifetime Achievement 2014 do INCOSE-LA e o Prêmio Inovação no Currículo de 2013 o Instituto de engenheiros industriais. Os seus interesses de pesquisa incluem métodos formais e probabilísticos em engenharia de sistemas, arquitetura e engenharia baseadas em modelos, sistemas resilientes de engenharia e exploração da convergência disciplinar e tecnológica para aprimorar a engenharia de sistemas.

Análise de sistema.
A análise do sistema permite aos desenvolvedores realizar objetivamente avaliações quantitativas de sistemas para selecionar e / ou atualizar a arquitetura do sistema mais eficiente e gerar dados de engenharia derivados. Durante a engenharia, as avaliações devem ser realizadas sempre que escolhas técnicas ou decisões são tomadas para determinar a conformidade com os requisitos do sistema.
A análise do sistema fornece uma abordagem rigorosa para a tomada de decisões técnicas. Ele é usado para realizar estudos de trade-off, e inclui modelagem e simulação, análise de custos, análise de riscos técnicos e análise de eficácia.
Princípios que regem a análise do sistema.
Uma das principais tarefas de um engenheiro de sistemas é avaliar os dados e artefatos de engenharia criados durante o processo de engenharia de sistemas (SE). As avaliações estão no centro da análise do sistema, fornecendo meios e técnicas.
definir critérios de avaliação com base nos requisitos do sistema; avaliar as propriedades de design de cada solução candidata em comparação a esses critérios; pontuar globalmente as soluções candidatas e justificar as pontuações; e decidir sobre a (s) solução (s) apropriada (s).
O artigo Análise e Seleção entre Soluções Alternativas na Abordagem de Sistemas Aplicados à Área de Conhecimento de Sistemas de Engenharia (KA) da Parte 2 descreve atividades relacionadas à seleção entre possíveis soluções de sistema para um problema ou oportunidade identificado. Os seguintes princípios gerais de análise de sistemas são definidos:
A análise de sistemas baseia-se em critérios de avaliação baseados em uma descrição do sistema de problema ou oportunidade. Esses critérios basear-se-ão em torno de uma descrição ideal do sistema, o que pressupõe que um contexto do problema do sistema rígido possa ser definido. Os critérios devem considerar o comportamento e as propriedades do sistema necessários na solução completa, em todos os contextos e ambientes possíveis do sistema. Estes devem considerar problemas não funcionais, como segurança do sistema, segurança, etc. (consulte Engenharia de sistemas e Engenharia de especialidades para discussão adicional sobre a incorporação de elementos não funcionais). Essa descrição do sistema "ideal" pode ser suportada por descrições de sistemas suaves, de que critérios adicionais "soft" podem ser definidos. Por exemplo, uma preferência de partes interessadas em relação a determinados tipos de soluções, convenções sociais, políticas ou culturais relevantes a serem consideradas, etc. Os critérios de avaliação devem incluir, no mínimo, as restrições às escalas de custo e tempo aceitáveis ​​para as partes interessadas. Os estudos de comércio fornecem um mecanismo para a realização de análises de soluções alternativas. Um estudo de comércio deve considerar um conjunto de critérios de avaliação, com consciência adequada das limitações e dependências entre os critérios individuais. Os estudos de comércio precisam lidar com critérios objetivos e subjetivos. Deve-se ter cuidado para avaliar a sensibilidade da avaliação geral a critérios específicos.
Estudos de trade-off.
No contexto da definição de um sistema, um estudo de trade-off consiste em comparar as características de cada elemento do sistema e de cada arquitetura de sistema candidato para determinar a solução que melhor equilibra globalmente os critérios de avaliação. As várias características analisadas são coletadas em análise de custos, análise de riscos técnicos e análise de eficácia (NASA 2007).
Orientações sobre a condução de estudos de comércio para todos os tipos de contexto do sistema são caracterizadas nos princípios acima e descritas com mais detalhes no tópico Análise e Seleção entre Soluções Alternativas. De particular interesse para a análise SE são a eficácia técnica, o custo e a análise técnica de risco.
Análise de Eficácia.
A eficácia de uma solução de sistema de engenharia inclui várias características essenciais que geralmente são coletadas na seguinte lista de análises, incluindo (mas não limitado a): desempenho, usabilidade, confiabilidade, fabricação, manutenção ou suporte, ambiente, etc. Essas análises destacam o candidato soluções sob vários aspectos.
É essencial estabelecer uma classificação que limita o número de análises aos aspectos realmente significativos, como os principais parâmetros de desempenho. As principais dificuldades da análise de eficácia são classificar e selecionar o conjunto certo de aspectos de eficácia; por exemplo, se o produto for feito para um único uso, a manutenção não será um critério relevante.
Análise de custos.
Uma análise de custos considera os custos do ciclo de vida completo. Uma linha de base de custo pode ser adaptada de acordo com o projeto e o sistema. O custo global do ciclo de vida (LCC), ou custo total de propriedade (TOC), pode incluir itens de custo de mão-de-obra e não relacionados ao trabalho, como os indicados na Tabela 1.
Os métodos para determinar o custo são descritos no tópico Planejamento.
Análise de riscos técnicos.
Toda análise de risco em relação a cada domínio é baseada em três fatores:
Análise de ameaças potenciais ou eventos indesejáveis ​​e sua probabilidade de ocorrência. Análise das consequências dessas ameaças ou eventos indesejáveis ​​e sua classificação em escala de gravidade. Mitigação para reduzir as probabilidades de ameaças e / ou os níveis de efeito prejudicial para valores aceitáveis.
Os riscos técnicos aparecem quando o sistema não pode satisfazer os requisitos do sistema por mais tempo. As causas residem nos requisitos e / ou na própria solução. Eles são expressos sob a forma de eficácia insuficiente e podem ter múltiplas causas: avaliação incorreta das capacidades tecnológicas; superestimação da maturidade técnica de um elemento do sistema; falha de peças; separação; ruptura, obsolescência de equipamentos, peças ou software, fraqueza do fornecedor (peças não conformes, atraso no fornecimento, etc.), fatores humanos (treinamento insuficiente, ajustes incorretos, manipulação de erros, procedimentos inadequados, malícia), etc.
Os riscos técnicos não devem ser confundidos com os riscos do projeto, mesmo que o método para gerenciá-los seja o mesmo. Embora os riscos técnicos possam levar a riscos do projeto, os riscos técnicos abordam o próprio sistema, e não o processo para seu desenvolvimento. (Consulte Gestão de Riscos para mais detalhes.)
Processo de abordagem.
Objetivo e Princípios da Abordagem.
O processo de análise do sistema é usado para: (1) fornecer uma base rigorosa para a tomada de decisões técnicas, resolução de conflitos de requisitos e avaliação de soluções físicas alternativas (elementos do sistema e arquiteturas físicas); (2) determinar o progresso na satisfação dos requisitos do sistema e requisitos derivados; (3) apoiar o gerenciamento de riscos; e (4) assegurar que as decisões sejam tomadas somente após a avaliação do custo, cronograma, desempenho e efeitos de risco na engenharia ou reengenharia de um sistema (ANSI / EIA, 1998). Esse processo também é chamado de processo de análise de decisão pela NASA (2007, 1-360) e é usado para ajudar a avaliar problemas técnicos, alternativas e suas incertezas para apoiar a tomada de decisões. (Consulte Gerenciamento de Decisão para obter mais detalhes.)
A análise do sistema suporta outros processos de definição do sistema:
A definição dos requisitos das partes interessadas e os processos de definição dos requisitos do sistema usam a análise do sistema para resolver problemas relacionados a conflitos entre o conjunto de requisitos; em particular, relacionadas aos custos, riscos técnicos e eficácia (desempenhos, condições operacionais e restrições). Os requisitos do sistema sujeitos a riscos elevados, ou aqueles que exigem arquiteturas diferentes, são discutidos. Os processos de desenvolvimento de modelos de arquitetura lógica e desenvolvimento de modelos de arquitetura física usam-na para avaliar características ou propriedades de projeto de arquiteturas lógicas e físicas candidatas, fornecendo argumentos para selecionar o mais eficiente em termos de custos, riscos técnicos e eficácia (por exemplo, performances, confiabilidade , fatores humanos, etc.).
Como qualquer processo de definição do sistema, o processo de análise do sistema é iterativo. Cada operação é realizada várias vezes; cada passo melhora a precisão da análise.
Atividades do Processo.
Principais atividades e tarefas realizadas dentro deste processo incluem.
Planejando os estudos de trade-off: determine o número de soluções candidatas a analisar, os métodos e procedimentos a serem utilizados, os resultados esperados (exemplos de objetos a serem selecionados: arquitetura / cenário comportamental, arquitetura física, elemento do sistema, etc.) e os itens de justificação. Agende as análises de acordo com a disponibilidade de modelos, dados de engenharia (requisitos do sistema, propriedades de projeto), pessoal qualificado e procedimentos. Definir o modelo de critérios de seleção: Selecione os critérios de avaliação de requisitos não funcionais (desempenhos, condições operacionais, restrições, etc.) e / ou de propriedades de projeto. Classifique e ordene os critérios de avaliação. Estabelecer uma escala de comparação para cada critério de avaliação e pesar cada critério de avaliação de acordo com o seu nível de importância relativa com os demais. Identifique soluções candidatas, modelos relacionados e dados. Avaliar soluções candidatas usando métodos ou procedimentos previamente definidos: Realizar análise de custos, análise de riscos técnicos e análise de eficácia, colocando cada solução candidata em cada escala de comparação de critérios de avaliação. Marque cada solução candidata como uma pontuação de avaliação. Fornecer resultados ao processo de chamada: critérios de avaliação, escalas de comparação, pontuação das soluções, seleção de avaliação e possivelmente recomendações e argumentos relacionados.
Artefatos e elementos de Ontologia.
Este processo pode criar vários artefatos, como.
Um modelo de critérios de seleção (lista, escalas, pesagem) Relatórios de custos, riscos e análise de eficácia Relatórios de justificação.
Este processo lida com os elementos da ontologia da Tabela 2 na análise do sistema.
Identificador; nome; descrição; peso relativo; peso escalar.
Identificador; nome; descrição; valor.
Identificador; nome; descrição; montante; tipo (desenvolvimento, produção, utilização, manutenção, eliminação); intervalo de confiança; período de referência; técnica de estimação.
Identificador; descrição do nome; status.
Verificação da exatidão da análise do sistema.
Os principais itens a serem verificados dentro da análise do sistema para obter argumentos validados são.
Relevância dos modelos e dados no contexto do uso do sistema, Relevância dos critérios de avaliação relacionados ao contexto de uso do sistema, Reprodutibilidade de resultados de simulação e de cálculos, Escala de precisão de comparações, Confirmação de estimativas e Sensibilidade das pontuações das soluções relacionadas aos pesos dos critérios de avaliação.
Veja Ring, Eisner e Maier (2010) para uma perspectiva adicional.
Métodos e técnicas de modelagem.
Uso geral dos modelos: Vários tipos de modelos podem ser usados ​​no contexto da análise do sistema: Os modelos físicos são modelos em escala que permitem a simulação de fenômenos físicos. Eles são específicos para cada disciplina; ferramentas associadas incluem mock-ups, tabelas de vibração, bancadas de teste, protótipos, câmara de descompressão, túneis de vento, etc. Os modelos de representação são usados ​​principalmente para simular o comportamento de um sistema. Por exemplo, diagramas de blocos de fluxo funcional aprimorados (eFFBDs), diagramas de estados, diagramas de máquinas de estados (baseados em linguagem de modelagem de sistemas (SysML)), etc. Os modelos analíticos são usados ​​principalmente para estabelecer valores de estimativas. Podemos considerar os modelos determinísticos e os modelos probabilísticos (também conhecidos como modelos estocásticos) para serem de natureza analítica. Modelos analíticos usam equações ou diagramas para se aproximar do funcionamento real do sistema. Eles podem ser muito simples (adição) a incrivelmente complicado (distribuição probabilística com várias variáveis). Use modelos certos dependendo do progresso do projeto No início do projeto, os primeiros estudos usam ferramentas simples, permitindo aproximações aproximadas que têm a vantagem de não exigir muito tempo e esforço. Essas aproximações são muitas vezes suficientes para eliminar soluções de candidatos não realistas ou extrovertidos. Progressivamente com o progresso do projeto, é necessário melhorar a precisão dos dados para comparar as soluções candidatas ainda concorrentes. O trabalho é mais complicado se o nível de inovação for alto. Um engenheiro de sistemas sozinho não pode modelar um sistema complexo; ele tem que ser apoiado por pessoas qualificadas de diferentes disciplinas envolvidas. Expertise especializada: Quando os valores dos critérios de avaliação não podem ser dados de maneira objetiva ou precisa, ou porque o aspecto subjetivo é dominante, podemos pedir especialistas para especialistas. As estimativas procedem em quatro etapas: selecione os entrevistados para coletar a opinião de pessoas qualificadas para o campo considerado. Elaborar um questionário; um questionário preciso permite uma análise fácil, mas um questionário que está muito fechado corre o risco de negação de pontos significativos. Entreviste um número limitado de especialistas com o questionário, incluindo uma discussão aprofundada para obter opiniões precisas. Analise os dados com várias pessoas diferentes e compare suas impressões até que um acordo sobre uma classificação de critérios de avaliação e / ou soluções candidatas seja alcançado.
Os modelos analíticos frequentemente utilizados no contexto da análise do sistema estão resumidos na Tabela 3.
Os modelos que contêm estatísticas estão incluídos nesta categoria. O princípio consiste em estabelecer um modelo baseado em uma quantidade significativa de dados e número de resultados de projetos anteriores; eles podem se aplicar apenas a elementos / componentes do sistema cuja tecnologia já existe. Modelos por analogia também usam projetos anteriores. O elemento do sistema em estudo é comparado com um elemento de sistema já existente com características conhecidas (custo, confiabilidade, etc.). Então, essas características são ajustadas com base na experiência dos especialistas. As curvas de aprendizagem permitem prever a evolução de uma característica ou de uma tecnologia. Um exemplo de evolução: "Cada vez que o número de unidades produzidas é multiplicado por dois, o custo desta unidade é reduzido com uma certa porcentagem, geralmente constante".
Considerações práticas.
As principais armadilhas e boas práticas relacionadas à análise do sistema são descritas nas próximas duas seções.
Algumas das principais dificuldades encontradas no planejamento e na análise do sistema são fornecidas na Tabela 4.
Práticas comprovadas.
Algumas das práticas comprovadas retiradas das referências são fornecidas na Tabela 5.
Referências.
Trabalhos citados.
ANSI / EIA. 1998. Processos para Engenharia de um Sistema. Filadélfia, PA, EUA: American National Standards Institute (ANSI) / Electronic Industries Association (EIA), ANSI / EIA-632-1998.
NASA. 2007. Manual de Engenharia de Sistemas. Washington, D. C .: Administração Nacional de Aeronáutica e do Espaço (NASA), NASA / SP-2007-6105.
Ring, J, H. Eisner e M. Maier. 2010. "Questões-chave da engenharia de sistemas, Parte 3: provando seu projeto". INCOSE Insight 13 (2).
Referências primárias.
ANSI / EIA. 1998. Processos para Engenharia de um Sistema. Filadélfia, PA, EUA: American National Standards Institute (ANSI) / Electronic Industries Association (EIA), ANSI / EIA 632-1998.
Blanchard, B. S., e W. J. Fabrycky. 2010. Engenharia e Análise de Sistemas, 5ª ed. Prentice-Hall International Series em Engenharia Industrial e de Sistemas. Englewood Cliffs, NJ, EUA: Prentice-Hall.
NASA. 2007. Manual de Engenharia de Sistemas. Washington, DC, EUA: Administração Nacional de Aeronáutica e do Espaço (NASA), NASA / SP-2007-6105.
Referências adicionais.
Ring, J, H. Eisner e M. Maier. 2010. "Questões-chave da engenharia de sistemas, Parte 3: provando seu projeto". INCOSE Insight. 13 (2).
Discussão do SEBoK.
Por favor, forneça seus comentários e feedback sobre o SEBoK abaixo. Você precisará fazer login no DISQUS usando uma conta existente (por exemplo, Yahoo, Google, Facebook, Twitter, etc.) ou criar uma conta DISQUS. Basta digitar seu comentário no campo de texto abaixo e DISQUS irá guiá-lo através das etapas de login ou registro. O feedback será arquivado e usado para futuras atualizações do SEBoK. Se você forneceu um comentário que não está mais listado, esse comentário foi julgado. Você pode ver a adjudicação para comentários enviados antes do SEBoK v. 1.0 na Revisão e Adjudicação do SEBoK. Os comentários posteriores são abordados e as alterações são resumidas na Carta do Editor e Reconhecimentos e Histórico de Liberação.
Se você gostaria de fornecer edições neste artigo, recomendar novos conteúdos ou fazer comentários sobre o SEBoK como um todo, consulte o SEBoK Sandbox.

Negociar análise em engenharia de sistemas
Design e análise de trade-off.
Instituto de Pesquisa de Sistemas,
Universidade de Maryland, College Park.
Requisitos do Projeto, [2012] [2013]
A aula introduz os alunos de Engenharia de Sistemas para os conceitos subjacentes, metodologias profissionais e recursos de software na engenharia de requisitos, no projeto de nível de sistema, otimização e análise de trade-off. Os alunos completarão um projeto focado no desenvolvimento de requisitos e sua rastreabilidade para o sistema de nível de projeto de um sistema de engenharia.
Este curso será baseado no material abordado no ENSE 621 System Concepts, Issues and Processes.
Os tópicos serão os seguintes: revisão rápida do ENSE 621: conceitos, problemas e processos do sistema. Engenharia de Sistemas Baseada em Modelos. Sistema de sistemas. Modelos e processos organizacionais. Engenharia de requisitos; gestão de requisitos; implementação e aplicações de rastreabilidade. Recursos de ferramentas de engenharia de requisitos comerciais. Design de nível do sistema.
Geração de projetos de nível de arquitetura (lógica) e de nível de tecnologia (físico). Métodos de design baseados em componentes e interfaces. Princípios do design modular. Aperfeiçoamento do conceito de design através de matrizes de estrutura de design. Análise de tradeoff multi-objetivos para o projeto de sistemas de engenharia. Princípios de design baseado em plataforma.
Os alunos completarão um projeto focado no desenvolvimento de requisitos e sua rastreabilidade para o sistema de nível de projeto de um sistema de engenharia.
PRÉ-REQUISITOS DO CURSO Nível de graduação em engenharia. ENSE 621 / ENPM 641 do semestre de outono 2009-2012. Um bom conhecimento de matemática de engenharia (por exemplo, cálculo, álgebra linear, equações diferenciais).
HORA E LOCALIZAÇÃO DAS HORAS DE CLASSE / ESCRITÓRIO Classe. M, das 19h às 21h40, Sala 2121, Edifício JPM. Horas de escritório. Mark Austin. Por nomeação. Para uma resposta rápida aos seus problemas, envie-me um e-mail.
Notas da aula As notas da aula estarão disponíveis em John MacCarthy, Rm 2175, A. V. Williams.
O custo é de US $ 40,00. Faça um check-out da "Universidade de Maryland".
Material de suporte Eu distribuirei um volume significativo de material de suporte (200 Mbytes) para as classes ENSE 621 e ENSE 622.
Traga seu laptop para a aula e vou passar o material para você por meio de um CD-ROM e / ou memory stick.
Textos recomendados Hull E., Jackson K. e Dick J., Engenharia de Requisitos (Segunda Edição), Springer, junho de 2004.
Modelagem Visual de Sistemas No Magic cria o ambiente MagicDraw com plugins SysML.
Para mais informações, consulte o site No Magic.
Nós temos o MagicDraw com os plugins SysML e Paramagic rodando nos PCs no SEIL Lab (A. V. Williams, Rm. 2250). Visio Professional / Enterprise 2000 Faça o download de uma cópia de demonstração do software Rational.
Software de otimização O CPLEX é um opimizador interativo para programação inteira e mista.
Está disponível no cluster de PCs no SEIL Lab (A. V. Williams, Rm 2250).
Clique aqui para obter detalhes sobre o trabalho passo a passo através de um exemplo básico. Faça o download gratuito das versões de estudante / avaliação do MPL / CPLEX e OptiMax 2000.
O OptiMax 2000 é uma biblioteca de componentes orientada a objetos, especificamente projetada para incorporar modelos de otimização em aplicativos de usuários finais.
AVALIAÇÃO DO CURSO E CALENDÁRIO DE EXAME.
Haverá dois exames: Trabalho de casa (20%): incidirá no desenvolvimento de requisitos, modelos de estrutura e comportamento do sistema e desenvolvimento de um projeto de nível de sistema. Intermediário (25%): XX de abril, 2 horas de duração.
O exame será livro aberto e notas abertas. Projeto de curso (30%): Você pode trabalhar em um projeto de design ou em um projeto de pesquisa.
Por favor envie-me um pdf do seu projeto final,
Devido em 16 de maio de 2014. Final (25%): maio YY, 7-9 pm em nossa sala de aula regular.
2 horas, mais 5 minutos para ler o papel.
O exame será livro aberto e notas abertas. Nenhum computador.
Nota. Não haverá exames de maquiagem de meio termo ou final. Os alunos podem soltar o escore de meio termo se eles forem melhores no final (ou seja, o exame final pode contar até 50% do grau). O limite entre um grau B e um grau A será de 80%.
Última modificação: 21 de janeiro de 2015.
Direitos autorais e cópia; 2002-2015, Institute for Systems Research, Universidade de Maryland.

Análise e seleção entre soluções alternativas.
Este tópico faz parte da área de conhecimento de Sistemas Aplicados para Sistemas de Engenharia (KA). Ele descreve o conhecimento relacionado à análise e seleção de uma solução preferencial das possíveis opções, que podem ter sido propostas pela Synthesizing Possible Solutions. As opções de solução selecionadas podem formar o ponto de partida para implementar e provar uma solução. Qualquer uma das atividades descritas abaixo também pode precisar ser considerada concorrentemente com outras atividades na abordagem de sistemas em um ponto específico da vida de um sistema de interesse (SoI).
As atividades descritas abaixo devem ser consideradas no contexto da Visão Geral do tópico Abordagem de Sistemas no início deste KA. O tópico final nesta KA, Aplicando a Abordagem de Sistemas, considera os aspectos dinâmicos de como essas atividades são usadas como parte da abordagem de sistemas e como isso se relaciona detalhadamente com elementos de engenharia de sistemas (SE).
Análise de sistema.
A análise do sistema é uma atividade na abordagem de sistemas que avalia um ou mais artefatos do sistema criados durante as atividades envolvidas na Sintetização de Soluções Possíveis, tais como:
Definição de critérios de avaliação com base nas propriedades e no comportamento requeridos de um problema identificado ou situação do sistema de oportunidade. Acessando as propriedades e o comportamento de cada solução candidata em comparação com os critérios. Comparando as avaliações das soluções candidatas e a identificação de qualquer uma que possa resolver o problema ou explorar as oportunidades, juntamente com a seleção de candidatos que devem ser explorados.
Conforme discutido no tópico Sintetizar soluções possíveis, o contexto do problema para um sistema de engenharia incluirá uma descrição lógica ou ideal da solução do sistema. Supõe-se que a solução que "melhor" corresponde à ideal será a solução mais aceitável para as partes interessadas. Observe, conforme discutido abaixo, a "melhor" solução deve incluir uma compreensão dos custos e riscos, bem como a eficácia. O contexto do problema pode incluir um modelo conceitual de soft system descrevendo os elementos lógicos de um sistema para resolver a situação problemática e como eles são percebidos por diferentes partes interessadas (Checkland, 1999). Essa visão de contexto suave proporcionará critérios adicionais para o processo de análise, que pode se tornar o problema crítico na seleção entre duas alternativas de solução igualmente eficazes.
Portanto, a análise muitas vezes não é um processo único de seleção de solução; Em vez disso, ele é usado em combinação com a compreensão do problema e a síntese da solução para avançar no sentido de uma compreensão mais completa dos problemas e das soluções ao longo do tempo (ver Aplicação do tópico Approach Systems para uma discussão mais completa sobre a dinâmica desse aspecto da abordagem).
Análise de Eficácia.
Estudos de eficácia usam o contexto do sistema de problemas ou oportunidades como ponto de partida.
A eficácia de uma solução de sistema sintetizada incluirá critérios de desempenho associados às funções primária e de ativação do sistema. Estes são derivados do propósito do sistema, para permitir a realização das necessidades dos interessados ​​em um ou mais contextos de sistema mais amplos.
Para um sistema de produto, existem um conjunto de qualidades genéricas não funcionais associadas a diferentes tipos de padrões de soluções ou tecnologia, por exemplo, segurança, segurança, confiabilidade, manutenção, facilidade de uso, etc. Esses critérios são explicitamente explicados como partes do conhecimento de domínio de disciplinas técnicas relacionadas em domínios de tecnologia.
Para um sistema de serviço ou sistema empresarial, os critérios serão mais diretamente vinculados às necessidades de usuários identificadas ou aos objetivos da empresa. As qualidades típicas para tais sistemas incluem agilidade, resiliência, flexibilidade, capacidade de atualização, etc.
Além das avaliações da eficácia absoluta de um determinado sistema de solução, os engenheiros de sistemas também devem ser capazes de combinar a eficácia com as limitações de custo e prazos incluídos no contexto do problema. Em geral, o papel da análise do sistema é identificar as soluções propostas que podem proporcionar alguma eficácia dentro do custo e tempo alocados em qualquer iteração dada da abordagem de sistemas (ver Aplicação da Abordagem de Sistemas para detalhes). Se nenhuma das soluções puder fornecer um nível de eficácia que justifique o investimento proposto, é necessário retornar ao enquadramento original do problema. Se pelo menos uma solução é avaliada como suficientemente eficaz, então uma escolha entre soluções pode ser proposta.
Estudos de Trade-Off.
No contexto da definição de um sistema, um estudo de trade-off consiste em comparar as características de cada elemento do sistema candidato com as de cada arquitetura do sistema candidato, a fim de determinar a solução que equilibra globalmente os critérios de avaliação da melhor maneira possível. As várias características analisadas são coletadas em análise de custos, análise de riscos técnicos e análise de eficácia (NASA 2007). Para realizar um estudo de desvantagem, há uma variedade de métodos, geralmente apoiados por ferramentas. Cada classe de análise é o assunto dos seguintes tópicos:
Os critérios de avaliação são utilizados para classificar as várias soluções candidatas. São absolutos ou parentes. Por exemplo, o custo máximo por unidade produzido é c $, a redução de custo deve ser x%, a melhoria da eficácia é y% ea mitigação de risco é z%. Os limites identificam e limitam as características ou critérios a serem considerados no momento da análise (por exemplo, o tipo de custos a serem considerados, os riscos técnicos aceitáveis ​​e o tipo e nível de eficácia). As escalas são usadas para quantificar as características, propriedades e / ou critérios e fazer comparações. Sua definição requer conhecimento dos limites mais altos e mais baixos, assim como o tipo de evolução da característica (linear, logarítmica, etc.). Um escore de avaliação é atribuído a uma característica ou critério para cada solução candidata. O objetivo do estudo de trade-off é conseguir quantificar as três variáveis ​​(e sua decomposição em sub-variáveis) de custo, risco e eficácia para cada solução candidata. Essa operação geralmente é complexa e requer o uso de modelos. A otimização das características ou propriedades melhora a pontuação de soluções interessantes.
Um processo de tomada de decisão não é uma ciência precisa; ergo, os estudos de trade-off têm limites. As seguintes preocupações devem ser levadas em consideração:
Critérios Subjetivos - viés pessoal do analista; por exemplo, se o componente tem que ser bonito, o que constitui um componente “bonito”? Dados incertos - por exemplo, a inflação deve ser levada em consideração para estimar o custo de manutenção durante o ciclo de vida completo de um sistema, como um engenheiro de sistemas pode prever a evolução da inflação nos próximos cinco anos? Análise de Sensibilidade - Uma pontuação de avaliação global designada para cada solução candidata não é absoluta; portanto, recomenda-se que uma seleção robusta seja coletada através da realização de uma análise de sensibilidade que considere pequenas variações dos valores dos critérios de avaliação (pesos). A seleção é robusta se as variações não alteram a ordem dos escores.
Um estudo de trade-off completo especifica os pressupostos, as variáveis ​​e os intervalos de confiança dos resultados.
Princípios de Sistemas de Análise de Sistemas.
Nas discussões acima, os seguintes princípios gerais de análise de sistemas podem ser definidos:
A análise de sistemas é uma atividade iterativa consistindo em estudos de comércio realizados entre várias opções de solução da atividade de síntese de sistemas. A análise de sistemas utiliza critérios de avaliação baseados em uma descrição do sistema de problemas ou de oportunidades. Esses critérios basear-se-ão em torno de uma descrição ideal do sistema que pressupõe que um contexto do problema do sistema rígido possa ser definido. Os critérios devem considerar o comportamento do sistema e as propriedades necessárias da solução completa em todos os possíveis contextos e ambientes do sistema. Os estudos de comércio exigem consideração igual ao sistema primário e ao sistema de habilitação que funciona como um único sistema para atender às necessidades do usuário. Essas negociações precisam considerar os requisitos do sistema para os KPPs, segurança dos sistemas, segurança e acessibilidade durante todo o ciclo de vida. Essa descrição ideal do sistema pode ser suportada por descrições de sistema flexíveis a partir das quais critérios “soft” adicionais podem ser definidos , uma preferência das partes interessadas a favor ou contra certos tipos de soluções e convenções sociais, políticas ou culturais relevantes a serem consideradas no provável ambiente de solução, etc.). No mínimo, os critérios de avaliação devem incluir os constrangimentos nas escalas de custo e tempo aceitáveis ​​para as partes interessadas. Os estudos de comércio fornecem um mecanismo para a realização de análises de soluções alternativas. Um estudo de comércio deve considerar um "sistema de critérios de avaliação", designando atenção especial às limitações e dependências entre os critérios individuais. Os estudos de comércio precisam lidar com critérios objetivos e subjetivos. Deve-se ter cuidado para avaliar a sensibilidade da avaliação geral a critérios específicos.
Referências.
Trabalhos citados.
Checkland, P. B. 1999. Sistemas de Pensamento, Sistemas de Prática. Chichester, Reino Unido: John Wiley & amp; Sons Ltd.
NASA. 2007. Manual de Engenharia de Sistemas, Revisão 1. Washington, DC, EUA: Administração Nacional de Aeronáutica e do Espaço (NASA). NASA / SP-2007-6105.
Referências primárias.
ISO / IEC / IEEE. 2015. Engenharia de sistemas e software - Processos do ciclo de vida do sistema. Genebra, Suíça: Organização Internacional de Normalização / Comissões Eletrotécnicas Internacionais / / Instituto de Engenharia Elétrica e Eletrônica. ISO / IEC / IEEE 15288: 2015.
Jackson, S., D. Hitchins e H. Eisner. 2010. "Qual é a abordagem dos sistemas?" INCOSE Insight. 13 (1) (abril de 2010): 41-43.
Referências adicionais.
SEBoK v. 1.9 lançado em 17 de novembro de 2017.
Discussão do SEBoK.
Por favor, forneça seus comentários e feedback sobre o SEBoK abaixo. Você precisará fazer login no DISQUS usando uma conta existente (por exemplo, Yahoo, Google, Facebook, Twitter, etc.) ou criar uma conta DISQUS. Basta digitar seu comentário no campo de texto abaixo e DISQUS irá guiá-lo através das etapas de login ou registro. O feedback será arquivado e usado para futuras atualizações do SEBoK. Se você forneceu um comentário que não está mais listado, esse comentário foi julgado. Você pode ver a adjudicação para comentários enviados antes do SEBoK v. 1.0 na Revisão e Adjudicação do SEBoK. Os comentários posteriores são abordados e as alterações são resumidas na Carta do Editor e Reconhecimentos e Histórico de Liberação.
Se você gostaria de fornecer edições neste artigo, recomendar novos conteúdos ou fazer comentários sobre o SEBoK como um todo, consulte o SEBoK Sandbox.

Trade-off Analytics: criando e explorando o sistema Tradespace.
Gregory S. Parnell PhD (Editor)
Descrição.
Apresenta informações para criar uma estrutura de análise de compromisso para uso em ambientes de aquisição governamentais e comerciais.
Este livro apresenta um processo de gerenciamento de decisão baseado na teoria da decisão e nas melhores práticas de análise de custos alinhadas com o ISO / IEC 15288, o Manual de Engenharia de Sistemas e o Sistema de Conhecimento de Engenharia de Sistemas. Fornece uma estrutura de análise de trade-off de som para gerar o espaço comercial e avaliar valor e risco para apoiar a tomada de decisões do sistema ao longo do ciclo de vida. Análise de compensação e técnicas de análise de risco são examinadas. Os autores apresentam um quadro integrado de trade-off e análise de risco baseado na teoria da decisão. Esses conceitos de análise de compromisso são ilustrados nos diferentes estágios do ciclo de vida usando vários exemplos de defesa e domínios comerciais.
Fornece técnicas para identificar e estruturar os objetivos das partes interessadas e alternativas criativas e factíveis Apresenta as vantagens e desvantagens das técnicas de criação e exploração de tradespace para análise de conceitos, arquiteturas, projeto, operações e aposentadoria Abrange as fontes de incerteza no ciclo de vida do sistema e examina como identificar, avaliar e modelar a incerteza usando a probabilidade. Ilustra como realizar uma análise de trade-off usando o processo de Gerenciamento de Decisão INCOSE usando técnicas determinísticas e probabilísticas.
Trade-off Analytics: Criando e Explorando o Sistema O Tradespace é escrito para estudantes de graduação e pós-graduandos que estudam projeto de sistemas, engenharia de sistemas, engenharia industrial e gerenciamento de engenharia. Este livro também serve como um recurso para praticar designers de sistemas, engenheiros de sistemas, gerentes de projetos e gerentes de engenharia.
Gregory S. Parnell, PhD, é professor de pesquisa no Departamento de Engenharia Industrial da Universidade de Arkansas. Ele também é um diretor sênior com Decisões Inovadoras, Inc., uma empresa de análise de risco e decisão e atuou como Presidente do Conselho de Administração. Dr. Parnell publicou mais de 100 artigos e capítulos de livros e foi editor líder de tomada de decisão para engenharia de sistemas e gerenciamento, Wiley Series em engenharia de sistemas (2ª edição, Wiley 2011) e principal autor do manual de análise de decisão (Wiley 2013) . Ele é membro do INFORMS, do INCOSE, do MORS e da Society for Decision Professionals.
Recursos relacionados.
Instrutor.
Permissões.
Solicite permissão para reutilizar o conteúdo deste site.
Lista de Contribuintes xix.
Sobre os autores xxi.
Sobre o site do Companion xlv.
1 Introdução à análise de trade-off 1.
Gregory S. Parnell Matthew Cilli Azad M. Madni e Garry Roedler.
1.1 Introdução 2.
1.2 Análises de Trade-off ao longo do ciclo de vida 3.
1.3 Análise de trade-off para identificar o valor do sistema 3.
1.4 Análise de Trade-off para Identificar Incertezas e Riscos do Sistema 6.
1.5 As análises de trade-off podem integrar análise de valor e risco 6.
1.6 Análise de trade-off no processo de gerenciamento de decisão de engenharia de sistemas 8.
1.7 Análise do trade-off Erros de omissão e da Comissão 9.
1.8 Visão geral do livro 20.
1.9 Termos-chave 24.
1.10 Exercícios 25.
2 Um quadro conceitual e fundação matemática para análise de trade-off 29.
Gregory Parnell Azad M. Madni e Robert F. Bordley.
2.1 Introdução 29.
2.2 Termos de Análise de Trade-Off 30.
2.3 Diagrama de Influência do Espaço Trades 31.
2.4 Exploração do espaço de trabalho 46.
2.6 Palavras-chave 47.
2.7 Exercícios 48.
3 Quantificando a Incerteza 51.
Robert F. Bordley.
3.1 Fontes de Incerteza na Engenharia de Sistemas 51.
3.2 Regras de Probabilidade e Intuição Humana 52.
3.3 Distribuições de Probabilidade 56.
3.4 Probabilidades de estimativa 66.
3.5 Modelagem Usando Probabilidade 72.
3.7 Principais Termos 81.
3.8 Exercícios 83.
4 ANALISANDO OS RECURSOS 91.
Edward A. Pohl Simon R. Goerger e Kirk Michealson.
4.1 Introdução 91.
4.2 Recursos 92.
4.3 Análise de custos 99.
4.4 Análise de Acessibilidade 135.
4.5 Termos-chave 147.
4.6 Exercícios 149.
5 Compreendendo o Gerenciamento de Decisão 155.
Matthew Cilli e Gregory S. Parnell.
5.1 Introdução 155.
5.2 Contexto do processo de decisão 156.
5.3 Atividades do processo de decisão 157.
5.5 Termos Chave 199.
5.6 Exercícios 200.
6 Identificando Oportunidades 203.
Donna H. Rhodes e Simon R. Goerger.
6.1 Introdução 203.
6.2 Conhecimento 205.
6.3 Armadilhas de Decisão 207.
6.4 Técnicas 210.
6.6 Exemplos ilustrativos 223.
6.7 Termos principais 228.
6.8 Exercícios 230.
7 Identificando Objetivos e Medidas de Valor 233.
Gregory S. Parnell e William D. Miller.
7.1 Introdução 233.
7.2 Pensamento com Foco no Valor 234.
7.3 Valor do Acionista e das partes interessadas 236.
7.4 Desafios na identificação dos objetivos 238.
7.5 Identificando os Objetivos de Decisão 239.
7.6 O Objetivo Financeiro ou de Custo 241.
7.7 Desenvolvimento de medidas de valor 243.
7.8 Estruturando Múltiplos Objetivos 243.
7.9 Exemplos ilustrativos 248.
7.10 Resumo 250.
7.11 Termos principais 252.
7.12 Exercícios 253.
8 DESENVOLVIMENTO E AVALIAÇÃO DE ALTERNATIVAS 257.
C. Robert Kenley Clifford Whitcomb e Gregory S. Parnell.
8.1 Introdução 257.
8.2 Visão geral da criatividade e equipes de decisão 258.
8.3 Técnicas de desenvolvimento alternativas 263.
8.4 Avaliação de técnicas alternativas de desenvolvimento 275.
8.5 Técnicas alternativas de avaliação 276.
8.6 Avaliação de técnicas alternativas de avaliação 290.
8.7 Termos principais 290.
8.8 Exercícios 290.
9 Um modelo integrado para análise de trade-off 297.
Alexander D. MacCalman Gregory S. Parnell e Sam Savage.
9.1 Introdução 297.
9.2 Exemplo de Design Conceptual 298.
9.3 Diagrama de Influência da Abordagem Integrada 300.
9.4 Outros tipos de análise de trade-off 322.
9.5 Ferramentas de Simulação 322.
9.7 Termos principais 330.
9.8 Exercícios 331.
10 EXPLORANDO O CONCEITO COMERCIAL 337.
Azad M. Madni e Adam M. Ross.
10.1 Introdução 337.
10.2 Definição do Conceito Conceito de Espaço e Sistema de Operações 345.
10.3 Explorando o espaço conceitual 346.
10.4 Quadros de análise de trade-off 348.
10.5 Ciclo de vida do espaço de operações e do sistema 349.
10.6 Do Point Trade-offs para o Tradespace Exploration 351.
10.7 Análise Tradespace Multiatributo Baseada em Valor 351.
10,8 Exemplo ilustrativo 359.
10.9 Conclusões 369.
10.10 Termos-chave 371.
10.11 Exercícios 372.
11 Framework de avaliação da arquitetura 377.
11.1 Introdução 377.
11.2 Principais considerações na avaliação de arquiteturas 385.
11.3 Elementos de avaliação da arquitetura 389.
11.4 Passos em um processo de avaliação de arquitetura 396.
11.5 Exemplo de Taxonomia de Avaliação 398.
11.6 Resumo 400.
11.7 Termos-chave 400.
11.8 Exercícios 402.
12 Explorando o espaço de design 405.
Clifford Whitcomb e Paul Beery.
12.1 Introdução 405.
12.2 Exemplo 1: Elevador 406.
12.3 Exemplo 2: Design do navio de cruzeiro 411.
12.4 Exemplo 3: Navio Combatente de Superfície Naval da NATO 417.
12.5 Termos-chave 431.
12.6 Exercícios 433.
13 MODELOS RELACIONADOS COM O SUSTENTAMENTO E ESTUDOS DE COMÉRCIO 437.
John E. MacCarthy e Andres Vargas.
13.1 Introdução 437.
13.2 Estudos de Modelagem e Comércio de Disponibilidade 439.
13.3 Modelos de Ciclo de Vida de Sustentação e Estudos de Comércio14 454.
13.4 Otimização na disponibilidade Estudos comerciais 464.
13.5 Modelagem Monte Carlo 471.
13.6 Resumo do Capítulo 475.
13.7 Termos-chave 476.
13.8 Exercícios 478.
14 Execução de Análises programáticas de trade-off 483.
Gina Guillaume-Joseph e John E. MacCarthy.
14.1 Introdução 483.
14.2 Decisões de aceitação do sistema e estudos de comércio 485.
14.3 Estudo de comércio de decisão de cancelamento de produto 512.

Análise de trade-off na Engenharia de Sistemas Baseados em Modelos.
David W. Oliver.
Endereço de e-mail: dwoliverixcom Ballston Lake, N. Y. Procure por mais artigos deste autor.
Publicado pela primeira vez: julho de 1996 Histórico completo de publicação DOI: 10.1002 / j.2334-5837.1996.tb02019.x Ver / salvar citação Citado por (CrossRef): 0 artigos Verifique se há atualizações.
Este artigo considera a engenharia de sistemas baseada em modelos que produz requisitos e especificações executáveis. Ele descreve o passo de trade-off do processo técnico de engenharia de sistemas. Ele trata as entradas para a etapa de trade-off. Ele define um comportamento a ser seguido pelos engenheiros de sistemas na realização de análises de trade-off. Esse comportamento é descrito como um meta-processo executável e não como uma metodologia para torná-lo independente da infinidade de metodologias.
Um meta-processo descreve as etapas a serem tomadas no processo, a ordenação das etapas e as entradas e saídas para cada etapa. Esta é uma imagem comportamental. Também descreve as informações tratadas em cada etapa e as relações entre as informações. Esta é uma imagem estrutural estática, às vezes chamada de modelo de objeto ou modelo de informação. O meta-processo define as possíveis visualizações das informações que serão tratadas.
Uma metodologia, ao contrário, seleciona ordens particulares das etapas de engenharia e visualizações particulares de informações em notações específicas para uso de uma equipe de engenharia.
Informações do artigo.
Formato disponível.
&cópia de; 1996 Os autores.
História da publicação.
Edição on-line: 4 de novembro de 2014 Versão do registro on-line: 4 de novembro de 2014.
Conteúdo Relacionado.
Artigos relacionados ao que você está visualizando.
Citando Literatura.
Número de vezes citado: 0.
Direitos autorais e cópia; 1999 - 2018 John Wiley & amp; Sons, Inc. Todos os direitos reservados.