Hide
Don't miss an update, subscribe
Don't miss an update, subscribe

ニュースレター

PCB設計と業界情報に関する過去のニュースレターをご覧ください。

Filter
見つかりました
Sort by
役割
ソフトウェア
フィルターをクリア
要件管理 スプレッドシートのやりくりにストップ!Altium 365 RSPで要件を管理しよう 1 min Newsletters PCB設計者 電気技術者 購買・調達マネージャー PCB設計者 PCB設計者 電気技術者 電気技術者 購買・調達マネージャー 購買・調達マネージャー 電子設計の複雑さは、従来の 要件管理の方法を上回っています。私たちが見てきたところによると、開発チームの30から50パーセントがまだ要件をスプレッドシートや基本的なテキストドキュメントで追跡しており、他の人々は設計に直接メモを追加したり、Jiraのようなタスク管理ツールを使用したりしています。 この断片化されたアプローチ–要件が複数のシステムやチームにまたがって散在している–は、製品がより洗練されるにつれて、顕著なリスクを生み出します。エンジニアはスプレッドシート、ドキュメント、設計ファイル間を切り替えながら、要件を正確に追跡することに苦労しています。 散在する要件の隠れたコスト 要件が複数の場所に存在すると、問題は倍増します。エンジニアは現在の仕様を探すのに数時間を費やすと報告しており、プロジェクトマネージャーはバージョン管理を維持するのに苦労しています。設計チームはしばしば古い情報で進めてしまい、避けられたはずのやり直しを余儀なくされます。 影響は時間の無駄にとどまりません。適切な要件追跡がなければ、設計上の欠陥が開発の遅い段階で表面化し、大幅な遅延を引き起こします。規制された産業では、散在する要件はコンプライアンスの検証をほぼ不可能にします。異なる要件ソースから作業しているハードウェアとソフトウェアのチームも、互換性のないソリューションを構築してしまうことがあります。監査中に、要件の実装を証明することは、さまざまなシステムからのドキュメントを組み合わせることを含む、時間を要する挑戦となります。 要件管理の新しいアプローチ 要件&システムポータル(RSP)は、Altium 365内で要件を扱う異なる方法を表しています。AltiumがValispaceの技術を取得したことに基づき、RSPは要件管理をAltiumの電子開発エコシステムに直接統合します。 「要件は通常、プロジェクトを開始するところです。何をしたいか、どのように何かを構築するか、プロジェクトに何が必要かを記述します」と、Altiumのシステムエンジニアリング製品担当副社長であるLouise Lindbladは最新の ポッドキャストで説明しています。「そのパズルのピースは、Altium 365やAltiumの製品では多少欠けていました。そのため、要件フェーズを詳細設計に接続するためにValispaceが導入されました。」 要件を設計に接続する RSPは、包括的な要件管理機能を備えており、単なる要件リストをはるかに超えています。RSPは、 Altium 365のWebインターフェースと Altium Designerの両方を通じて要件をアクセス可能にします。エンジニアは作業中に要件にアクセスでき、 要件と特定の設計要素との間に直接リンクを作成することができます。一方、関係者は設計内で各要件がどこに実装されているかを迅速に特定できます。この接続により、要件が実装から切り離されるという一般的な問題が解消されます。 記事を読む
アジャイル設計のためのコラボレーション 小規模チーム、大きな影響:Altium 365 RSPがアジャイル設計のためのコラボレーションを効率化 1 min Newsletters PCB設計者 システムエンジニア/アーキテクト PCB設計者 PCB設計者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 今日の電子機器開発チームは、完璧な嵐のような課題に直面しています。システムはより複雑かつ学際的になりつつあり、市場の要求は急速に変化しています。アジャイル開発アプローチを使用する小規模ハードウェアチームにとって、これは特に大きな課題を生み出します: 限られたリソースで成長する複雑さを管理しながら効果的に対応し続ける。 ハードウェア開発におけるアジャイル導入の影響は明らかです。 マッキンゼーの研究によると、 アジャイル方法を成功裏に実装したハードウェア開発チームは、市場投入までの時間を30%速めることができます。しかし 50%以上のチームが依然として要件を基本的なスプレッドシートやドキュメントで追跡しており、現代のニーズと伝統的なツールとの間に乖離が生じています。 ハードウェアがアジャイルに出会う時:複雑なロマンス ハードウェア開発とアジャイル方法論との関係は常にスムーズだったわけではありません。ソフトウェアチームが数十年にわたってアジャイル実践を受け入れている一方で、ハードウェアチームはしばしばこれらのアプローチを懐疑的に見ています。このためらいは理由がないわけではありません - ハードウェア開発には物理的なコンポーネント、規制要件、製造の制約が関わっており、これらは常に純粋なアジャイル方法とは一致しません。 「 コラボレーティブな要件管理システムでサイロを打破する」で以前に探求したように、従来の製品開発はしばしばリレーレースのように見え、各チームが次のチームにバトンを渡していきます。この線形のアプローチは論理的に見えるかもしれませんが、小規模チームが負担できないコミュニケーションのギャップや遅延したフィードバックをしばしば引き起こします。 小規模チーム、大きな責任 小規模のハードウェアチームにとって、課題は倍増します。エンジニアはしばしば複数の役割を担い – ある日はシステムアーキテクト、次の日は検証スペシャリストです。この役割の流動性は小規模チームに固有のものですが、組織と追跡可能性を維持するためには堅牢なシステムが求められます。単一のエンジニアが要件変更を行う場合、その変更がシステム全体に及ぼす影響を理解する必要があるかもしれません。 複雑さはチームのサイズとともに減少するわけではありません。小規模チームは、大規模組織と同じ課題に直面します:規制要件の管理、製品バリアントの取り扱い、分散したチームメンバー間の明確なコミュニケーションの維持。違いは、これらの要求を管理するためのリソースが少ないことにあります – 効率と自動化を望ましいものから必須へと押し上げます。 すでに持っているアジャイルの利点 記事を読む