Requirements & Systems Portal with Altium 365

Connect design data and requirements in Altium 365's Requirements & Systems Portal for faster design with fewer errors

Filter
見つかりました
Sort by
役割
ソフトウェア
コンテンツタイプ
適用
フィルターをクリア
電子開発のための要件管理ツール エレクトロニクス開発に最適な要件管理ツールの選び方 1 min Blog システムエンジニア/アーキテクト 電気技術者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 電気技術者 電気技術者 スプレッドシート、メール、Word文書は、多くの電子開発チームにとって依然として要件管理ツールの主流です。それらは使い慣れており、柔軟で、使いやすいです。しかし、プロジェクトがより複雑になるにつれて、その場しのぎの要件管理はリスクとなります。 断片化した文書はメールやSlackのスレッドに閉じ込められ、チームメンバーやその他の関係者間での誤解を招きます。要件は進化しますが、下流のエンジニアが常に追いついているわけではありません。変更が発生したとき、その影響を追跡したり、完全に検証されたかどうかを把握する簡単な方法はありません。 その結果、プロジェクトの遅延、ボードの再設計、コンプライアンスの問題が発生します。 再作業の最大50%が要件の失敗に起因しており、失敗するプロジェクトの70%が要件の不備によって引き起こされます。解決策は単により良い文書ではなく、ハードウェア要件を扱うためのより良いシステムとツールです。 この記事では、電子開発のための要件管理ツールを評価する方法、避けるべき落とし穴、そして現代の協力的な電子設計チームにとって最も重要な機能について説明します。 なぜほとんどの要件管理プロセスが不十分なのか 表面上は、スプレッドシートやカンバンボードは要件管理に適した方法のように思えます。これらは情報を論理的で整理された方法で収集・表示するために設計されています。データはカテゴリ分けされ、フィルタリングされ、構造化されます。これらのツールは汎用性があり、異なるプロジェクトのニーズに合わせて形を変えることができるほど柔軟です。 しかし、非専門的なツールの一般的で高水準な性質が問題の一部です。これらは現代の電子機器開発の複雑さを扱うために設計されておらず、エンジニアやシステムアーキテクトが設計の反復とともに進化する数百または数千の要件を追跡するために必要な機能が欠けています。 最大の課題は可視性です。要件がタスク管理ツール、共有ドライブ、内部ウィキ、チャットスレッドに散らばっている場合、それらが最新の変更を反映しているか、またはテストケースが変更された要件をまだカバーしているかどうかを知る方法がありません。エンジニアは時間を無駄に二重チェックや相互参照に費やします。または、何も変わっていないと仮定することが、それよりも悪いです。 第二の問題はトレーサビリティです。専門の要件管理ツールがなければ、要件を設計要素や検証ステップにリンクすることは困難です。プロジェクトが終盤に近づくか監査の時になると、チームはなぜ、どこで決定が行われたのか、それがテストされたか、そしてそのテストが現在の設計の状態に対してまだ関連があるのかを再構築するために慌てます。 最終的に、これらの方法はスケールしません。チームが成長し、同時に複数のプロジェクトを手がけるにつれて、オーバーヘッドは指数関数的に増加します。スケールで切断された要件を管理する結果は、より多くの作業、より多くのやり直し、そしてより多くの無駄なお金です。 選んではいけないもの:要件管理ツールの一般的な落とし穴 要件管理用に市販されているすべてのツールがハードウェア開発に適しているわけではありません。多くは細かい点で失敗しますが、それでも電子設計のワークフローにとっては重大な影響を及ぼします。特に、チームがどんな構造化されたシステムでもアドホックな要件管理より良いと仮定する場合はなおさらです。 チームにとっての解決策を選ぶ際に避けるべき「機能」をいくつか探ってみましょう。 要件トレーサビリティ機能がない 一部のツールは、要件を静的なチェックリストのように扱います。それらは、要件を互いや回路図、テストケース、設計成果物にリンクする能力に欠けています。要件の収集には役立つかもしれませんが、それが終わると、本当に重要なコンテキストを欠いた構造化されたデータを持つことになります。 汎用タスクマネージャー ソフトウェア向けに構築されたプロジェクト管理プラットフォームは、自らをRMソリューションとして宣伝することがよくあります。しかし、要件をチケットとして割り当てることは、検証計画、ライフサイクル管理、またはECAD統合を効果的にサポートしません。要件データは収集され、レビューのために利用可能になりますが、プロセスの規律をツールの外で強制しなければなりません。 過剰設計されたレガシーRMプラットフォーム 一部のエンタープライズRMツールは、膨大な数の機能を備えていますが、現代の電子開発プロジェクトが求める使いやすさ、柔軟性、速度に欠けています。適切な手に渡れば、これらは優れたツールですが、専用の管理者、カスタムスクリプト、そしてチームを速く立ち上げるための数ヶ月のオンボーディングがしばしば必要です。これらは、迅速に動こうとするエンジニアリングチームには不向きです。 記事を読む
アジャイル設計のためのコラボレーション 小規模チーム、大きな影響:Altium 365 RSPがアジャイル設計のためのコラボレーションを効率化 1 min Newsletters PCB設計者 システムエンジニア/アーキテクト PCB設計者 PCB設計者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 今日の電子機器開発チームは、完璧な嵐のような課題に直面しています。システムはより複雑かつ学際的になりつつあり、市場の要求は急速に変化しています。アジャイル開発アプローチを使用する小規模ハードウェアチームにとって、これは特に大きな課題を生み出します: 限られたリソースで成長する複雑さを管理しながら効果的に対応し続ける。 ハードウェア開発におけるアジャイル導入の影響は明らかです。 マッキンゼーの研究によると、 アジャイル方法を成功裏に実装したハードウェア開発チームは、市場投入までの時間を30%速めることができます。しかし 50%以上のチームが依然として要件を基本的なスプレッドシートやドキュメントで追跡しており、現代のニーズと伝統的なツールとの間に乖離が生じています。 ハードウェアがアジャイルに出会う時:複雑なロマンス ハードウェア開発とアジャイル方法論との関係は常にスムーズだったわけではありません。ソフトウェアチームが数十年にわたってアジャイル実践を受け入れている一方で、ハードウェアチームはしばしばこれらのアプローチを懐疑的に見ています。このためらいは理由がないわけではありません - ハードウェア開発には物理的なコンポーネント、規制要件、製造の制約が関わっており、これらは常に純粋なアジャイル方法とは一致しません。 「 コラボレーティブな要件管理システムでサイロを打破する」で以前に探求したように、従来の製品開発はしばしばリレーレースのように見え、各チームが次のチームにバトンを渡していきます。この線形のアプローチは論理的に見えるかもしれませんが、小規模チームが負担できないコミュニケーションのギャップや遅延したフィードバックをしばしば引き起こします。 小規模チーム、大きな責任 小規模のハードウェアチームにとって、課題は倍増します。エンジニアはしばしば複数の役割を担い – ある日はシステムアーキテクト、次の日は検証スペシャリストです。この役割の流動性は小規模チームに固有のものですが、組織と追跡可能性を維持するためには堅牢なシステムが求められます。単一のエンジニアが要件変更を行う場合、その変更がシステム全体に及ぼす影響を理解する必要があるかもしれません。 複雑さはチームのサイズとともに減少するわけではありません。小規模チームは、大規模組織と同じ課題に直面します:規制要件の管理、製品バリアントの取り扱い、分散したチームメンバー間の明確なコミュニケーションの維持。違いは、これらの要求を管理するためのリソースが少ないことにあります – 効率と自動化を望ましいものから必須へと押し上げます。 すでに持っているアジャイルの利点 記事を読む