―106―Fig. 2 Development Method (As is)Fig. 3 Development Method (To be)Fig. 1 Work Sharing Patterns in Software Development ②ソフトウェアサプライヤーへの委託パターン：OEMがソフトウェア開発をサプライヤーに委託するパターンである。サプライヤーはソフトウェアの開発，テスト，保守などを担当する。メリットとしては，OEM内部の開発コストやリソースの削減が可能であり，外部の専門知識や技術を活用できる。2.3 現状の開発プロセスの課題 自動車ソフトウェア開発における現状の問題として，手戻りの発生による開発効率の低下がある。特に，ソフトウェア要求定義に関連する手戻りが多いことが社内調査で判明している。ソフトウェア要求の正確性や一貫性は，ソフトウェア開発全体の品質に大きな影響を与えている。要求定義の不備や不明瞭さが後の開発段階で判明し，手戻りや修正が発生することはよくある問題である。3.1 次世代の開発手法 従来の開発手法では要求，要件を自然言語による文章の仕様書に記載しており，内容の確認を人手によるレビューで行ってきた。このような従来の開発では仕様書の記載内容に曖昧さや間違いが混入しやすいため，Fig. 2に示すとおりソフトウェア実装後にテストで要求と異なる動きが発覚し，元の要求の間違いに気づき大きな手戻りとなることがある。3. 目指す開発の姿機能や性能要件を洗い出す。非機能要件も加味しシステムのアーキテクチャやモジュールの設計を行い，要件に基づいたシステム仕様書を作成する。 下流活動では，上流活動で作成されたシステム仕様書で定義されたソフトウェア要求に基づいて，ソフトウェアの詳細設計が行われ，分割したモジュールやコンポーネントの詳細な設計を行い，実装するソースコードを開発する。 テスト・結合活動では，おおよそ単体テスト，結合テスト，システムテストの3つのレベルでソフトウェア及びシステムの検証が実施される。 単体テストでは，下流活動で作成された各モジュールやコンポーネントに対して，個々のモジュールが正しく動作し，要件を満たしていることを確認する。結合テストでは，単体テストが完了したモジュールやコンポーネントを結合し，システム全体の動作，モジュール間の相互作用やインターフェースの正常性を確認する。システムテストでは，システムが要件を満たしており，ユーザーの期待に沿った動作をすることを確認する。実際の環境でのテストやユーザビリティテストを実施し，システムが要求された機能を適切に提供することを確認する。2.2 ソフトウェア開発のワークシェアパターン プロジェクトや対象システムによってOEMとサプライヤーでの作業分担は異なる。以下に一般的なワークシェアパターンを示す（Fig. 1参照）。 ①インハウス開発パターン：OEMが自社内の開発チームをもち，ソフトウェア開発を自社で行うパターンである。OEMはソフトウェアの設計，開発，テスト，保守などの全てのプロセスを自社内で管理する。メリットとしては，直接的なコントロールが可能であり，セキュリティや知的財産の保護が容易である。 そこで次世代の開発手法としてFig. 3に示すとおり，各工程ごとに検証を実施した後に，次工程を行うことで手戻りを少なくできると考える。また，要求や要件を曖昧さがない形式的に記述することで機械的にモデル化及びコード生成することでき，人手による間違いの混入を防ぐことができる。先行してエンジン制御開発では，ソフトウェア設計の工程において形式的なモデルによるソフトウェア開発を行っており，品質改善や効率化で大きな成果を上げている（2）。
元のページ ../index.html#114