筆者について

Alexsander Tamari

Alexsanderは、テクニカル マーケティング エンジニアとしてAltiumに入社し、多年にわたるエンジニアリングの専門知識をチームにもたらしてくれています。エレクトロニクス設計への情熱と実践的なビジネスの経験は、Altiumのマーケティング チームに彼ならではの視点を提供してくれます。Alexsanderは、世界の上位20校であるカリフォルニア大学サンディエゴ校を卒業し、電気工学の学士号を取得しています。

最新の記事

電子開発のための要件管理ツール エレクトロニクス開発に最適な要件管理ツールの選び方 1 min Blog システムエンジニア/アーキテクト 電気技術者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 電気技術者 電気技術者 スプレッドシート、メール、Word文書は、多くの電子開発チームにとって依然として要件管理ツールの主流です。それらは使い慣れており、柔軟で、使いやすいです。しかし、プロジェクトがより複雑になるにつれて、その場しのぎの要件管理はリスクとなります。 断片化した文書はメールやSlackのスレッドに閉じ込められ、チームメンバーやその他の関係者間での誤解を招きます。要件は進化しますが、下流のエンジニアが常に追いついているわけではありません。変更が発生したとき、その影響を追跡したり、完全に検証されたかどうかを把握する簡単な方法はありません。 その結果、プロジェクトの遅延、ボードの再設計、コンプライアンスの問題が発生します。 再作業の最大50%が要件の失敗に起因しており、失敗するプロジェクトの70%が要件の不備によって引き起こされます。解決策は単により良い文書ではなく、ハードウェア要件を扱うためのより良いシステムとツールです。 この記事では、電子開発のための要件管理ツールを評価する方法、避けるべき落とし穴、そして現代の協力的な電子設計チームにとって最も重要な機能について説明します。 なぜほとんどの要件管理プロセスが不十分なのか 表面上は、スプレッドシートやカンバンボードは要件管理に適した方法のように思えます。これらは情報を論理的で整理された方法で収集・表示するために設計されています。データはカテゴリ分けされ、フィルタリングされ、構造化されます。これらのツールは汎用性があり、異なるプロジェクトのニーズに合わせて形を変えることができるほど柔軟です。 しかし、非専門的なツールの一般的で高水準な性質が問題の一部です。これらは現代の電子機器開発の複雑さを扱うために設計されておらず、エンジニアやシステムアーキテクトが設計の反復とともに進化する数百または数千の要件を追跡するために必要な機能が欠けています。 最大の課題は可視性です。要件がタスク管理ツール、共有ドライブ、内部ウィキ、チャットスレッドに散らばっている場合、それらが最新の変更を反映しているか、またはテストケースが変更された要件をまだカバーしているかどうかを知る方法がありません。エンジニアは時間を無駄に二重チェックや相互参照に費やします。または、何も変わっていないと仮定することが、それよりも悪いです。 第二の問題はトレーサビリティです。専門の要件管理ツールがなければ、要件を設計要素や検証ステップにリンクすることは困難です。プロジェクトが終盤に近づくか監査の時になると、チームはなぜ、どこで決定が行われたのか、それがテストされたか、そしてそのテストが現在の設計の状態に対してまだ関連があるのかを再構築するために慌てます。 最終的に、これらの方法はスケールしません。チームが成長し、同時に複数のプロジェクトを手がけるにつれて、オーバーヘッドは指数関数的に増加します。スケールで切断された要件を管理する結果は、より多くの作業、より多くのやり直し、そしてより多くの無駄なお金です。 選んではいけないもの:要件管理ツールの一般的な落とし穴 要件管理用に市販されているすべてのツールがハードウェア開発に適しているわけではありません。多くは細かい点で失敗しますが、それでも電子設計のワークフローにとっては重大な影響を及ぼします。特に、チームがどんな構造化されたシステムでもアドホックな要件管理より良いと仮定する場合はなおさらです。 チームにとっての解決策を選ぶ際に避けるべき「機能」をいくつか探ってみましょう。 要件トレーサビリティ機能がない 一部のツールは、要件を静的なチェックリストのように扱います。それらは、要件を互いや回路図、テストケース、設計成果物にリンクする能力に欠けています。要件の収集には役立つかもしれませんが、それが終わると、本当に重要なコンテキストを欠いた構造化されたデータを持つことになります。 汎用タスクマネージャー ソフトウェア向けに構築されたプロジェクト管理プラットフォームは、自らをRMソリューションとして宣伝することがよくあります。しかし、要件をチケットとして割り当てることは、検証計画、ライフサイクル管理、またはECAD統合を効果的にサポートしません。要件データは収集され、レビューのために利用可能になりますが、プロセスの規律をツールの外で強制しなければなりません。 過剰設計されたレガシーRMプラットフォーム 一部のエンタープライズRMツールは、膨大な数の機能を備えていますが、現代の電子開発プロジェクトが求める使いやすさ、柔軟性、速度に欠けています。適切な手に渡れば、これらは優れたツールですが、専用の管理者、カスタムスクリプト、そしてチームを速く立ち上げるための数ヶ月のオンボーディングがしばしば必要です。これらは、迅速に動こうとするエンジニアリングチームには不向きです。 記事を読む
要件管理とは何か 要件管理とは何か? 1 min Blog 電気技術者 システムエンジニア/アーキテクト 電気技術者 電気技術者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 要件管理は、開発ライフサイクルを通じて要件を収集、優先順位付け、検証、およびテストするための構造化されたプロセスです。これにより、電子開発企業は製品要件を実装し、成功裏に協力し、コストのかかるエラーを削減することができます。 成功した製品は、明確に定義された一連の要件を満たしています。製品がシンプルであっても、要件は設計者によって知られており、 PCB設計レビューの間に意識的にチェックされます。より複雑なプロジェクトや大規模な範囲の場合、要件はしばしばSOWやより大きな製品文書で指定され、これらはレビュープロセスの一部となります。 複雑さは電子製品開発の常であり、要件管理は製品がビジネス、機能、安全、ユーザーエクスペリエンス、およびコンプライアンスの目標を満たすことを保証します。 要件とは何か? 要件は プロジェクト関係者によって定義された特定のニーズや機能です。例えば、電子製品には特定の電流容量をサポートできるPCB設計が必要かもしれません。その要件は、適切なコンポーネントの必要性、適切な熱管理、および業界標準への準拠といった二次要件を生じさせます。 要件収集は、期待される機能、性能、およびユーザーエクスペリエンスを概説する高レベルの要件から始まります。初期の要件は、クライアント、製品マネージャー、ビジネスアナリスト、またはシステムエンジニアによって提案されることがあります。開発チームは、プライマリ要件をより詳細なセカンダリ要件に分解し、プロジェクトの目標を達成するための機能と制約を指定します。その結果、要件を構造化された形式に整理し、ステークホルダーがそれらの関係と依存関係を理解できるようにする階層が生まれます。 プロジェクトの各要件は、回路図および/またはPCBレイアウト内の特定のオブジェクト、実行される特定のタスク、関連する文書および/または機能ブロック、およびコンプライアンスのために考慮される予想される条件を参照する必要があります。要件を単純なチェックリストとして考慮することは、しばしばナビゲートが難しい大規模な要件文書よりも扱いやすいです。 良い要件とは何か? 要件が有用であるためには、特定の基準を満たす必要があります。最も重要なことは、それがあいまいでないことです。不正確な要件は、誤解、期待の不一致、および時間の無駄を引き起こします。 その他の重要な特性には以下が含まれます: 必要性: それは製品およびビジネスの目標に貢献しますか? 達成可能性: それはプロジェクトの範囲と能力内で実装できますか? テスタブル:成功した実装を測定するための明確で具体的な基準はありますか? 電子製品開発のための要件管理 要件管理は協力的なプロセスです。要件の収集と管理は、プロジェクトに関わるマネージャー、電子設計者、電気エンジニア、機械エンジニア、およびその他のステークホルダーからの入力に依存しています。 また、協力を促進するプロセスでもあります。明確でよく理解され、合意された要件の包括的なセットは、さまざまな場所にいる能力が異なるチームが同じ目標に向かって作業することを可能にします。 記事を読む
要件トレーサビリティマトリックスとは何か 要件トレーサビリティマトリックスとは何ですか? 1 min Blog 電気技術者 システムエンジニア/アーキテクト 技術マネージャー 電気技術者 電気技術者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 技術マネージャー 技術マネージャー 要件トレーサビリティマトリックス(RTM)は、電子製品開発において要件とその実装を追跡するために使用される文書です。RTMは、要件とそれに関連するすべての情報を記録した大きな表で、設計文書、回路図、テストなどが含まれます。 これらは、エンジニアやデザイナーがプロジェクトの関係者と協力し、プロジェクトの成果がその目的と一致することを確認するのに役立ちます。 要件トレーサビリティとは何か? 要件トレーサビリティは、プロジェクトの要件、成果物、および製品開発プロセスを通じての検証およびバリデーションテスト間の関係を追跡する能力です。 要件トレーサビリティは、前方、後方、または双方向のいずれかであることができます。 前方トレーサビリティは、各要件が対応する設計、実装、およびテストフェーズにリンクされていることを保証します。 後方トレーサビリティは、チームが最終製品をテストおよび設計フェーズを通じて元の要件にまで遡って追跡できるようにします。これは、納品されたシステムが初期の目標および目的と一致していることを検証するために不可欠です。 双方向トレーサビリティは、前方および後方トレーサビリティの両方を組み合わせ、プロジェクトライフサイクル全体を通じて要件を管理するための包括的なフレームワークを作成します。 要件トレーサビリティは、電子開発チームが次のことを支援します: 正しい製品を構築していることを確認する。 要件データを追跡し、すべての要件が満たされていることを検証するためのテストを含む。 機能、安全性、および規制遵守の要件充足の証明を提供する。 RTMは概念からテストまでの要件を追跡する 電子機器会社が医療機器用の新しいプリント回路基板(PCB)を設計していると想像してください。規制により、PCBは電磁干渉(EMI)に耐性がある必要があります。 要件: PCBは、標準IEC 60601-1-2で概説されたEMI要件を満たす必要があります。 トレーサビリティ: 設計チームは、PCBレイアウトでこの要件をどのように達成するかを示す必要があります。 彼らは、特定の設計技術、コンポーネント、またはシールディング方法を使用するかもしれません。これらはすべて文書化され、要件にリンクされます。 記事を読む
Altium 365 Jira 統合機能の深掘り 効率を最大化する:Altium 365 Jira インテグレーション機能の詳細な解説 1 min Blog プロジェクトリーダー(マネージャー) プロジェクトリーダー(マネージャー) プロジェクトリーダー(マネージャー) 電子設計の急速に進化する世界では、プロジェクトを軌道に乗せておくことが複雑で時間を要する作業になりがちです。これにより、プロジェクト管理と設計ツールの統合が、チーム全体の効率と正確性を維持するために不可欠となります。 Altium 365 Jira Integrationは、両プラットフォーム間でシームレスな双方向同期を提供し、 タスク管理を合理化し、プロジェクトの可視性を向上させます。この統合の主要機能に深く潜ることで、プロジェクト追跡と意思決定をどのように強化し、最終的に時間とコストの節約につながるかを強調します。 Altium 365 Jira Integrationを際立たせる機能 詳細に入る前に、この統合が本当にユニークなものである理由を強調しましょう: デザイン中心の統合: 一般的なプロジェクト管理の統合とは異なり、Altium 365 Jira Integrationは電子設計ワークフローに特化して調整されています。PCB固有の概念を理解しており、設計要素とプロジェクトタスク間のシームレスなリンクを可能にします。 双方向のビジュアルコンテキスト: 当社の統合は、ビジュアルデザインのスニペットをJiraチケットに自動的に添付できる点でユニークです。これにより、非技術的なステークホルダーに即座にコンテキストを提供し、設計とプロジェクト管理の間のギャップを埋めます。 シームレスなワークフロー: Altium 記事を読む