Thursday 15 March 2018

Engenharia de sistema trade off analysis


Análise de trade off de engenharia do sistema
Análise de Design e Trade-Off.
Instituto de Pesquisa de Sistemas,
Universidade de Maryland, College Park.
Requisitos do Projeto, [2012] [2013]
A turma apresenta aos alunos de Engenharia de Sistemas os conceitos subjacentes, metodologias profissionais e recursos de software em engenharia de requisitos, design de nível de sistema, otimização e análise de compromisso. Os alunos concluirão um projeto focado no desenvolvimento de requisitos e sua rastreabilidade para o projeto de nível de sistema 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 do sistema, problemas e processos. Engenharia de Sistemas Baseada em Modelos. Sistema de sistemas. Modelos Organizacionais e Processos. Engenharia de requisitos; gerenciamento 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ógico) e de nível de tecnologia (físico). Métodos de design baseados em componentes e interfaces. Princípios do design modular. Aprimoramento do conceito de design por meio de matrizes de estrutura de projeto. Análise de tradeoff multiobjetivo para projeto de sistemas de engenharia. Princípios do design baseado em plataforma.
Os alunos concluirão um projeto focado no desenvolvimento de requisitos e sua rastreabilidade para o projeto de nível de sistema de um sistema de engenharia.
PRÉ-REQUISITOS DO CURSO Estatuto de nível de pós-graduação em engenharia. ENSE 621 / ENPM 641 do segundo semestre de 2009 a 2012. Um bom conhecimento de matemática de engenharia (por exemplo, cálculo, álgebra linear, equações diferenciais).
TEMPO E LOCALIZAÇÃO DAS HORAS DE CLASSE / ESCRITÓRIO. M 19h - 21h40, Sala 2121, Edifício JPM. Horário de atendimento. Mark Austin. Por nomeação. Para uma rápida resposta 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 apoio 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., Requirements Engineering (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 de números inteiros e inteiros mistos.
Está disponível no cluster de PCs no Laboratório SEIL (A. V. Williams, Rm 2250).
Clique aqui para detalhes sobre como trabalhar 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, projetada especificamente para incorporar modelos de otimização em aplicativos do usuário final.
AVALIAÇÃO DO CURSO E CRONOGRAMA DE EXAME.
Haverá dois exames: Lição de casa (20%): incidirá sobre o desenvolvimento de requisitos, modelos de estrutura do sistema e comportamento e desenvolvimento de um design de nível de sistema. Meio período (25%): 20 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,
Até 16 de maio de 2014. Final (25%): May YY, 7-9 pm em nossa sala de aula regular.
2 horas mais 5 minutos para ler o artigo.
O exame será livro aberto e notas abertas. Sem computadores.
Nota. Não haverá exames de meio termo ou de maquiagem final. Os alunos podem perder a pontuação de médio prazo se fizerem melhor na final (ou seja, o exame final pode contar até 50% da nota). A fronteira entre uma nota B e uma nota A será de 80%.
Última modificação: 21 de janeiro de 2015.
Direitos autorais & copy; 2002-2015, Instituto de Pesquisa de Sistemas, Universidade de Maryland.

Análise de sistema.
A análise do sistema permite que os desenvolvedores realizem avaliações quantitativas de sistemas objetivamente para selecionar e / ou atualizar a arquitetura de sistema mais eficiente e para gerar dados de engenharia derivados. Durante a engenharia, as avaliações devem ser realizadas sempre que forem tomadas decisões ou decisões técnicas 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 compromisso e inclui modelagem e simulação, análise de custos, análise de riscos técnicos e análise de efetividade.
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 (ões) 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 é baseada em critérios de avaliação baseados em uma descrição do sistema de problemas ou oportunidades. Esses critérios serão baseados em uma descrição de sistema ideal, que pressupõe que um contexto de problema de sistema rígido pode ser definido. Os critérios devem considerar o comportamento e as propriedades do sistema requeridos da solução completa, em todos os contextos e ambientes de sistema mais amplos possíveis. Eles devem considerar problemas não funcionais, como segurança do sistema, segurança etc. (consulte Engenharia de sistemas e engenharia de especialidade para obter mais informações sobre a incorporação de elementos não funcionais.) Essa descrição do sistema "ideal" pode ser suportada por descrições de sistema flexíveis. quais critérios “soft” adicionais podem ser definidos. Por exemplo, uma preferência das partes interessadas a favor ou contra certos 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 de custo e escalas de tempo aceitáveis ​​para as partes interessadas. Estudos de comércio fornecem um mecanismo para a análise de soluções alternativas. Um estudo comercial deve considerar um conjunto de critérios de avaliação, com conhecimento adequado das limitações e dependências entre os critérios individuais. 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 reunidas na análise de custos, análise técnica de riscos 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 de 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 engenharia inclui várias características essenciais que geralmente são reunidas na seguinte lista de análises, incluindo (mas não limitadas a) desempenho, usabilidade, confiabilidade, fabricação, manutenção ou suporte, ambiente, etc. soluções sob vários aspectos.
É essencial estabelecer uma classificação que limite 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 Custo.
Uma análise de custo considera os custos totais do ciclo de vida. 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.
Cada análise de risco referente a cada domínio é baseada em três fatores:
Análise de ameaças potenciais ou eventos indesejados e sua probabilidade de ocorrência. Análise das conseqüências dessas ameaças ou eventos indesejados e sua classificação em uma escala de gravidade. Mitigação para reduzir as probabilidades de ameaças e / ou os níveis de efeitos prejudiciais a 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 na 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; quebra, obsolescência de equipamentos, peças ou software, fraqueza do fornecedor (peças não conformes, atraso no fornecimento, etc.), fatores humanos (treinamento insuficiente, afinações erradas, tratamento 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 de projeto, os riscos técnicos abordam o próprio sistema, não o processo para o seu desenvolvimento. (Veja Gerenciamento de Risco para mais detalhes.)
Processo de abordagem.
Finalidade 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ões para obter mais detalhes.)
A análise do sistema suporta outros processos de definição do sistema:
A definição de requisitos das partes interessadas e os processos de definição de requisitos do sistema usam a análise do sistema para resolver problemas relacionados a conflitos entre o conjunto de requisitos; em particular, aqueles relacionados a custos, riscos técnicos e eficácia (desempenho, condições operacionais e restrições). Os requisitos do sistema sujeitos a altos riscos, ou aqueles que exigiriam arquiteturas diferentes, são discutidos. Os processos de Desenvolvimento de Modelo de Arquitetura Lógica e Desenvolvimento de Modelos de Arquitetura Física utilizam-no 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 efetividade (por exemplo, desempenho, 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 etapa melhora a precisão da análise.
Atividades do Processo.
Principais atividades e tarefas realizadas dentro deste processo incluem.
Planejando os estudos de compromisso: Determine o número de soluções candidatas a serem analisadas, os métodos e procedimentos a serem usados, 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. Programe as análises de acordo com a disponibilidade de modelos, dados de engenharia (requisitos do sistema, propriedades do projeto), pessoal qualificado e procedimentos. Definir o modelo de critérios de seleção: Selecione os critérios de avaliação a partir de requisitos não funcionais (desempenhos, condições operacionais, restrições, etc.) e / ou das propriedades de design. Classifique e ordene os critérios de avaliação. Estabelecer uma escala de comparação para cada critério de avaliação e pesar todos os critérios de avaliação de acordo com 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. Pontuação de cada solução candidata como uma pontuação de avaliação. Forneça resultados para o processo de chamada: critérios de avaliação, escalas de comparação, pontuações de soluções, seleção de avaliação e possivelmente recomendações e argumentos relacionados.
Artefatos e Elementos de Ontologia.
Esse processo pode criar vários artefatos, como.
Um modelo de critérios de seleção (lista, balanças, pesagem) Relatórios de análise de custos, riscos e eficácia Relatórios de justificativa.
Esse processo manipula os elementos de 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, descarte); 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 na análise do sistema para obter argumentos validados são.
Relevância dos modelos e dados no contexto de uso do sistema, Relevância dos critérios de avaliação relacionados ao contexto de uso do sistema, Reprodutibilidade dos resultados da simulação e dos cálculos, Nível de precisão das escalas de comparação, Confiança das estimativas e Sensibilidade dos escores 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), gráficos de estado, diagramas de máquina de estado (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) como sendo de natureza analítica. Modelos analíticos usam equações ou diagramas para abordar a operação real do sistema. Podem ser muito simples (adição) a incrivelmente complicada (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 geralmente suficientes para eliminar soluções candidatas irreais ou de saída. Progressivamente, com o progresso do projeto, é necessário melhorar a precisão dos dados para comparar as soluções candidatas que ainda estão competindo. 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 seguem quatro etapas: Selecionar 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 é demasiado fechado corre o risco de negligenciar 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 usados ​​no contexto da análise do sistema estão resumidos na Tabela 3.
Modelos contendo 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 antigos. O elemento do sistema em estudo é comparado a um elemento do sistema já existente com características conhecidas (custo, confiabilidade, etc.). Em seguida, essas características são ajustadas com base na experiência dos especialistas. As curvas de aprendizado 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 armadilhas encontradas no planejamento e na execução da análise do sistema são fornecidas na Tabela 4.
Práticas comprovadas.
Algumas práticas comprovadas reunidas a partir 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) / Associação das Indústrias Eletrônicas (EIA), ANSI / EIA-632-1998.
NASA 2007. Manual de Engenharia de Sistemas. Washington, D. C .: Administração Nacional de Aeronáutica e 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 design." 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) / Associação das Indústrias Eletrônicas (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, D. C., EUA: 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 design." INCOSE Insight. 13 (2).
Discussão 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 do DISQUS. Basta digitar seu comentário no campo de texto abaixo e o DISQUS o guiará pelas etapas de login ou registro. O feedback será arquivado e usado para futuras atualizações no SEBoK. Se você forneceu um comentário que não está mais listado, esse comentário foi adjudicado. Você pode ver a adjudicação de comentários enviados antes do SEBoK v. 1.0 na Revisão e Adjudicação do SEBoK. Comentários posteriores são abordados e as alterações são resumidas na Carta do Editor e em Agradecimentos e Histórico de Lançamentos.
Se você deseja fornecer edições neste artigo, recomendar novos conteúdos ou fazer comentários no SEBoK como um todo, consulte o SEBoK Sandbox.

4.3.1 Framework de Processo de Estudo de Tradeoff de Engenharia de Sistemas.
Matthew V. Cilli,
E-mail: mcilli@stevens. edu Engenharia de Sistemas PhD Candidato Stevens Institute of Technology, Hoboken, NJ Procurar por mais artigos deste autor.
Gregory S. Parnell.
E-mail: gparnell@uark. edu Departamento de Engenharia Industrial, Universidade de Arkansas, Professor Visitante de Engenharia Industrial 4207 Bell Engineering Centre Procurar mais artigos deste autor.
Primeira publicação: julho de 2014 Histórico de publicação completo DOI: 10.1002 / j.2334-5837.2014.tb03151.x Ver / salvar citações Citado por (CrossRef): 0 articles Check for updates.
Os estudos de tradeoff são uma ferramenta crítica para fornecer informações para apoiar a tomada de decisões para engenheiros de disciplina, engenheiros de sistemas e gerentes de programas durante todo o ciclo de vida do sistema. Infelizmente, a qualidade dos estudos de comércio é inconsistente entre as organizações e dentro das organizações. Este documento relata parte de um esforço do INCOSE para melhorar os estudos de tradeoff e discute uma proposta de Processo de Gestão de Decisões INCOSE alinhada com a ISO / IEC 15288. O processo proposto discutido neste documento integra as melhores práticas de análise de decisão com atividades de engenharia de sistemas para criar uma linha de base a partir da qual Trabalhos futuros podem explorar possíveis inovações para melhorar ainda mais a qualidade do estudo de tradeoff. O processo permite que as empresas desenvolvam uma compreensão profunda do relacionamento complexo entre requisitos, as escolhas de design feitas para atender a cada requisito e as conseqüências no nível do sistema da soma das escolhas de design em todo o conjunto de requisitos de desempenho, além de outros elementos valor do stakeholder para incluir custo e cronograma. Por meio de técnicas de visualização de dados, os tomadores de decisão podem entender rapidamente e comunicar com clareza um espaço comercial complexo e convergir para recomendações robustas na presença de incerteza.
Informações sobre o artigo.
Formato disponível.
&cópia de; 2014 os autores.
Histórico de Publicações.
Emissão online: 31 de outubro de 2014 Versão do registro online: 31 de outubro de 2014.
Conteúdo Relacionado.
Artigos relacionados ao que você está vendo.
Citando Literatura.
Número de vezes citadas: 0.
Direitos autorais & copy; 1999 - 2018 John Wiley & amp; Sons, Inc. Todos os direitos reservados.

Estendendo a análise de trade-off de engenharia, integrando as preferências do usuário na análise conjunta.
As melhorias técnicas contínuas no projeto de arquitetura com recursos aprimorados de dispositivos móveis ou smartphones não garantem automaticamente a aceitação do usuário, porque os aspectos técnicos e comerciais impulsionam principalmente o desenvolvimento de sistemas e dispositivos de comunicação móvel. Especialmente nos estágios iniciais do desenvolvimento da tecnologia, as preferências e os valores do usuário não são considerados adequadamente, o que pode até ter um impacto negativo nos problemas de aceitação. O objetivo deste estudo foi a implementação de uma compreensão quantificada das necessidades do usuário em termos de valores no processo de design de sistema dos processadores de telefonia celular. Além disso, buscamos uma extensão da análise de trade-off da engenharia usando análise conjunta para investigar trade-offs entre características específicas do dispositivo. Finalmente, nosso objetivo foi a avaliação de métodos de pesquisa orientados para o usuário empiricamente baseados.
Os resultados do primeiro estudo revelaram que a duração da bateria, a qualidade da fala, a qualidade do sinal e a taxa de transmissão de dados são as características mais importantes do dispositivo. Os resultados da análise conjunta indicaram um claro trade-off entre a duração da bateria e as três outras características. Além disso, esta pesquisa demonstrou que a pesquisa de aceitação de tecnologia se beneficia consideravelmente de uma abordagem interdisciplinar e multi-método. Além disso, implementar as preferências dos usuários nos estágios iniciais do processo de desenvolvimento de produtos oferece várias vantagens em relação à eficácia, bem como aos aspectos econômicos do desenvolvimento.
Destaques.
► Implementação de requisitos do usuário no desenvolvimento de processadores de telefonia celular. ► Os resultados apresentam trade-offs claros na tomada de decisão dos usuários. ► Refletindo a diversidade de usuários na avaliação de recursos do celular.
Escolha uma opção para localizar / acessar este artigo:
Verifique se você tem acesso através de suas credenciais de login ou de sua instituição.

Como: Concluindo uma análise de compromisso.
Existem muitas abordagens para concluir uma análise formal de trade-offs. Este post irá resumir dois.
Decisões importantes incluem múltiplos fatores, às vezes competitivos. Um trade-off é desistir de uma coisa em troca de outra. Quase todas as decisões complexas exigem que você aceite menos de uma coisa para obter mais de outra coisa.
Ferramenta de trade-off de Ben Franklin.
A ferramenta de trade-off da Ben Franklin fornece uma maneira simples e intuitiva de pesar trade-offs. Crie duas colunas verticais, uma com a etiqueta & # 8220; Pros & # 8221; e um & ldquo; Cons & # 8221; Brainstorm as duas listas. Em seguida, emparelhe um item ou itens de cada lista com um item ou itens de igual peso da outra lista. Essas combinações semelhantes de prós e contras se anulam mutuamente. No gráfico da amostra, os profissionais superam os contras na troca & # 8220; álgebra. & # 8221; Não há necessidade de uma ferramenta mais sofisticada para tomar a decisão. A metodologia poderia ser ensinada a uma criança pequena.
Visualizando negociações em uma matriz de decisão.
A beleza de uma matriz de decisão é que você pode gerenciar facilmente a análise de compromisso, pois é possível ver onde estão as compensações.
Um post anterior de três partes descreveu como completar uma análise multicritério. A parte 3 ilustrou como construir uma matriz de decisão usando o exemplo do processo de seleção da faculdade.
A matriz acima exibe os resultados finais da avaliação de três faculdades em relação a um conjunto de critérios ponderados. As células com a borda vermelha representam a maior pontuação em cada critério. O benefício total de & # 8220; & # 8221; é a soma das pontuações ponderadas. Como você pode ver, a matriz ajuda a esclarecer as escolhas específicas da decisão por critério individual.
Esses resultados podem levar uma família a decidir selecionar Siracusa porque ela tem a maior pontuação de Benefício Total e a pontuação mais alta em três critérios: Distância, Clubes e Alimentação. No entanto, os trade-offs também são claros. Delaware é superior em dois critérios: Vida Social e Instalações. Templo, em um: Major. O quadro de decisão cria clareza: ao selecionar Siracusa, a família obtém o maior Benefício Total, mas desiste de Instalações superiores, Vida Social e Maior.
O desafio de qualquer decisão complexa é como esclarecer, gerenciar e avaliar as compensações. A ferramenta de trade-off e a matriz de decisão de Ben Franklin completam a tarefa de maneiras diferentes. Como você gerencia negócios em sua tomada de decisão?
Compartilhe este post:
Como o que você está lendo? Inscreva-se agora!
Contate-Nos.
BLOG: ASSINAR HOJE!
Blog: posts recentes.
Marcel Remy, 94 anos, vai inspirar você.
Como o NYS Ed Department distorce o desempenho escolar.
Caminhada de dia no Parque Nacional Torres del Paine.
Que mudanças estão chegando ao sistema de responsabilização escolar de Nova York?
Decisão é a virtude da vontade.
Blog: todas as postagens.
Tweets recentes.
@ realDonaldTrump está se recusando a implementar novas sanções bipartidárias do Kremlin, vitais para proteger nossa democracia. Ao fazer isso, ele escolheu os interesses de Putin sobre os nossos. A subserviência de Trump a Moscou é real e um sério problema de segurança nacional. twitter / eschor / status /…
Então, para recapitular: Hoje à noite, a administração Trump decidiu deixar futuras eleições abertas a mais assistência russa aos candidatos ao Partido Republicano, enquanto demitir e insultar as autoridades do FBI que tentaram proteger as eleições contra a Rússia twitter / eschor / status /…
Empresas farmacêuticas submergiram WV em opiáceos: uma cidade de 3.000 tem 21 milhões de comprimidos arstechnica / tech-policy / 2 & hellip; por @BethMarieMole.
Surpreendente a falta de transparência em torno dos bilhões de REDC. Tão maduro por abuso. twitter / sarbetter / stat…
Que mudanças estão chegando ao sistema de responsabilização escolar de Nova York? prismdecision / changes-com & hellip; via @prismdecision.
@sarbetter @NYSEDNews @spong_learns @NYSchoolSupts @nyschoolboards @NYRuralEscolas prismdecision / nysed-disto & hellip; Uma rápida olhada naquilo que acredito serem as falhas fundamentais no legado sistema de responsabilização que podem distorcer o desempenho escolar de maneiras absurdas e com resultados perversos.
O sistema de prestação de contas do Departamento de Educação de Nova York distorce o desempenho escolar de maneiras absurdas e com resultados perversos. prismdecision / nysed-disto & hellip;
@sarbetter Você é bem-vindo, @sarbetter. Tentando ajudar as pessoas a entender as mudanças. Essa “variação de um tema” não apenas sustenta mas provavelmente amplifica os problemas inerentes ao sistema legado que ele cria. @NYSEDNews @spong_learns @NYSchoolSupts @nyschoolboards @NYRuralSchools.

Análise de Trade-off: Criação e Exploração do Tradespace do Sistema.
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ões baseado nas melhores práticas de teoria de decisão e análise de custos alinhadas com a ISO / IEC 15288, o Manual de Engenharia de Sistemas e o Corpo de Conhecimento em Engenharia de Sistemas. Ele fornece uma estrutura sólida de análise de compromisso para gerar o espaço de negociação e avaliar o valor e o risco para apoiar a tomada de decisões do sistema ao longo do ciclo de vida. Análise de trade-off e técnicas de análise de risco são examinadas. Os autores apresentam uma estrutura de trade-off e análise de risco de valor integrado baseada 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 probabilidade Ilustra como realizar uma análise de compromisso 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 a prática de projetistas de sistemas, engenheiros de sistemas, gerentes de projeto e gerentes de engenharia.
Gregory S. Parnell, PhD, é professor pesquisador no Departamento de Engenharia Industrial da Universidade de Arkansas. Ele também é diretor sênior da Innovative Decisions, Inc., uma empresa de análise de risco e análise e atuou como presidente do conselho. 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.
Solicitar permissão para reutilizar o conteúdo deste site.
Lista de colaboradores xix.
Sobre os autores xxi.
Sobre o site do Companion xlv.
1 Introdução à Análise de Trade-off 1.
Gregory S. Parnell Mateus Cilli Azad M. Madni e Garry Roedler.
1.1 Introdução 2.
1.2 Trade-off Analyses Throughout the Life Cycle 3.
1.3 Trade-off Analysis to Identify System Value 3.
1.4 Trade-off Analysis to Identify System Uncertainties and Risks 6.
1.5 Trade-off Analyses can Integrate Value and Risk Analysis 6.
1.6 Trade-off Analysis in the Systems Engineering Decision Management Process 8.
1.7 Trade-off Analysis Mistakes of Omission and Commission 9.
1.8 Overview of the Book 20.
1.9 Key Terms 24.
1.10 Exercises 25.
2 A Conceptual Framework and Mathematical Foundation for Trade-Off Analysis 29.
Gregory S. Parnell Azad M. Madni and Robert F. Bordley.
2.1 Introduction 29.
2.2 Trade-Off Analysis Terms 30.
2.3 Influence Diagram of the Tradespace 31.
2.4 Tradespace Exploration 46.
2.6 Key Words 47.
2.7 Exercises 48.
3 Quantifying Uncertainty 51.
Robert F. Bordley.
3.1 Sources of Uncertainty in Systems Engineering 51.
3.2 The Rules of Probability and Human Intuition 52.
3.3 Probability Distributions 56.
3.4 Estimating Probabilities 66.
3.5 Modeling Using Probability 72.
3.7 Key Terms 81.
3.8 Exercises 83.
4 ANALYZING RESOURCES 91.
Edward A. Pohl Simon R. Goerger and Kirk Michealson.
4.1 Introduction 91.
4.2 Resources 92.
4.3 Cost Analysis 99.
4.4 Affordability Analysis 135.
4.5 Key Terms 147.
4.6 Excercises 149.
5 Understanding Decision Management 155.
Matthew Cilli and Gregory S. Parnell.
5.1 Introduction 155.
5.2 Decision Process Context 156.
5.3 Decision Process Activities 157.
5.5 Key Terms 199.
5.6 Exercises 200.
6 Identifying Opportunities 203.
Donna H. Rhodes and Simon R. Goerger.
6.1 Introduction 203.
6.2 Knowledge 205.
6.3 Decision Traps 207.
6.4 Techniques 210.
6.6 Illustrative Examples 223.
6.7 Key Terms 228.
6.8 Exercises 230.
7 Identifying Objectives and Value Measures 233.
Gregory S. Parnell and William D. Miller.
7.1 Introduction 233.
7.2 Value-Focused Thinking 234.
7.3 Shareholder and Stakeholder Value 236.
7.4 Challenges in Identifying Objectives 238.
7.5 Identifying the Decision Objectives 239.
7.6 The Financial or Cost Objective 241.
7.7 Developing Value Measures 243.
7.8 Structuring Multiple Objectives 243.
7.9 Illustrative Examples 248.
7.10 Summary 250.
7.11 Key Terms 252.
7.12 Exercises 253.
8 DEVELOPING AND EVALUATING ALTERNATIVES 257.
C. Robert Kenley Clifford Whitcomb and Gregory S. Parnell.
8.1 Introduction 257.
8.2 Overview of Decision-making Creativity and Teams 258.
8.3 Alternative Development Techniques 263.
8.4 Assessment of Alternative Development Techniques 275.
8.5 Alternative Evaluation Techniques 276.
8.6 Assessment of Alternative Evaluation Techniques 290.
8.7 Key Terms 290.
8.8 Exercises 290.
9 An Integrated Model for Trade-Off Analysis 297.
Alexander D. MacCalman Gregory S. Parnell and Sam Savage.
9.1 Introduction 297.
9.2 Conceptual Design Example 298.
9.3 Integrated Approach Influence Diagram 300.
9.4 Other Types of Trade-Off Analysis 322.
9.5 Simulation Tools 322.
9.7 Key Terms 330.
9.8 Exercises 331.
10 EXPLORING CONCEPT TRADE-OFFS 337.
Azad M. Madni and Adam M. Ross.
10.1 Introduction 337.
10.2 Defining the Concept Space and System Concept of Operations 345.
10.3 Exploring the Concept Space 346.
10.4 Trade-off Analysis Frameworks 348.
10.5 Tradespace and System Design Life Cycle 349.
10.6 From Point Trade-offs to Tradespace Exploration 351.
10.7 Value-based Multiattribute Tradespace Analysis 351.
10.8 Illustrative Example 359.
10.9 Conclusions 369.
10.10 Key Terms 371.
10.11 Exercises 372.
11 Architecture Evaluation Framework 377.
11.1 Introduction 377.
11.2 Key Considerations in Evaluating Architectures 385.
11.3 Architecture Evaluation Elements 389.
11.4 Steps in an Architecture Evaluation Process 396.
11.5 Example Evaluation Taxonomy 398.
11.6 Summary 400.
11.7 Key Terms 400.
11.8 Exercises 402.
12 Exploring the Design Space 405.
Clifford Whitcomb and Paul Beery.
12.1 Introduction 405.
12.2 Example 1: Liftboat 406.
12.3 Example 2: Cruise Ship Design 411.
12.4 Example 3: NATO Naval Surface Combatant Ship 417.
12.5 Key Terms 431.
12.6 Exercises 433.
13 SUSTAINMENT RELATED MODELS AND TRADE STUDIES 437.
John E. MacCarthy and Andres Vargas.
13.1 Introduction 437.
13.2 Availability Modeling and Trade Studies 439.
13.3 Sustainment Life Cycle Cost Modeling and Trade Studies14 454.
13.4 Optimization in Availability Trade Studies 464.
13.5 Monte Carlo Modeling 471.
13.6 Chapter Summary 475.
13.7 Key Terms 476.
13.8 Exercises 478.
14 Performing Programmatic Trade-Off Analyses 483.
Gina Guillaume-Joseph and John E. MacCarthy.
14.1 Introduction 483.
14.2 System Acceptance Decisions and Trade Studies 485.
14.3 Product Cancelation Decision Trade Study 512.

No comments:

Post a Comment