web-dev-qa-db-ja.com

ALMシステム、ERP、および組み込み製品はどうですか?

私たちは、バグトラッカー、ドキュメントシステム、プロジェクト管理などを含む、新しいアプリケーションライフサイクル管理(ALM)システムの取得に取り組んでいます。

懸念されるのは、非常に複雑な組み込みシステムを扱っており、さまざまなサービス(プロジェクト管理、問題/タスクの追跡、文書化など)を可能な限り最適に統合したいということです。ソフトウェアだけならJIRAのようなものを買うだけですが、ソフトウェア、ファームウェア(大きな問題はありません)、ハードウェアを同じシステムで管理したいと思っているので少し疑問があります。

私はこれらの点に関するアドバイスを探しています:

  • 組み込み製品で「バグ」を管理するのはどうですか?ソフトウェアでは、影響を受けるモジュールのバージョンがあります。組み込み製品では、さまざまなソフトウェアが動作し、さまざまなファームウェアが動作し、場合によっては異なるハードウェアが動作します。ハードウェア部品を、ソフトウェアを対象としたシステムのソフトウェアモジュールであるかのように単純に考えるのは実際には良いことですか?バグ追跡インターフェースに多くのカスタムフィールドが追加され、その結果、体系的な使用が促進されないと私は信じがちです。
  • 一部の人は、ハードウェアインベントリを残りの部分に統合するレベルに統合をプッシュしたいと考えています。これは、ALM(JIRAを考えてください)のプロジェクトは、サブコンポーネントに基づいてハードウェアコンポーネントを予約する必要があることを意味します。また、たとえば、問題のALMは、部品プロバイダーを管理し、一般的な発注書の作成、送信、および管理を容易にする機能を提供できる必要があることも意味します。

その時点で、組み込みプロジェクト管理プロセスのすべてを1つの管理システムに統合できるのか、それとも1)バグ/タスク追跡(おそらくソフトウェアとハ​​ードウェア)とプロジェクト管理との間に線を引く必要があるのか​​疑問に思います。 2)高レベルのプロジェクト管理、在庫追跡、販売/購入注文など。最終的に望まれるのは、統合されたJIRAとERPにほかなりません。または、既存のERPで適切なALMを実行すること、またはALMシステムで適切なERPをすでに実行することは可能ですか?

私の個人的な意見は、私が今知っていることから、問題とプロジェクト管理(ALM +ドキュメント+ ...)をERPから分割することです。それに関する問題は、ERPとALMのプロジェクト管理(ソフトウェア、ファームウェア、ハードウェアなどに使用される)の両方にプロジェクトに関するドキュメントがあることです。これで面白いのは、タイムシート(ERP)や問題(ALMのバグトラッカー)など、最初は非常に無関係に見えるものもあるかもしれませんが、最終的には、非常に興味深い、欲しかった、または知る必要があるかもしれませんバグまたはプロジェクト全体(バグ、問題、機能、その他のタスク)に費やされた時間。これにより、ERP/ALMの完全な統合に向けたポイントが得られます。

この時点で、あなたは私の質問の感触を得るはずです。有益なご意見をいただければ幸いです。ありがとう!

4
Joanis

私は、カスタムハードウェア、ファームウェア、ソフトウェアなど、地震記録用の組み込みデバイスを開発している会社で働いていました。

RedMine(私たちが使用したもの)やJIRA(あなたが提案するように)のような従来の問題追跡システムだけがすでに完全に機能していることが判明しました。

私はJIRAに精通していませんが、RedMineではプロジェクトの「領域」を定義できるため、プロジェクト全体をハードウェア、ファームウェア、ソフトウェアの3つの大きな部分に分割します。 RedMineを使用すると、「オンザフライ」で領域を変更できます。これは、バグに気づき、その原因がわからない場合に特に便利です。一般的なバグとして投稿するだけで、ファームウェアまたはハードウェアエンジニアを担当する開発者ができます。適切なセクションに割り当てます。

2