プロジェクトライフサイクルの5つの段階

1.プロジェクトの開始フェーズ

（1）プロジェクトの実現可能性分析

成功した製品は、次の3つの側面から観察および評価する必要があります。

製品の設計：商業的行動
- 製品設計の前に、市場調査と評価を行う必要があり、製品の適時性、市場の需要、および技術的な実現可能性を考慮する必要があります。
- 製品設計が完了したら、詳細な製品仕様（技術レベル、人的資源、開発コスト、製品コスト）を書き留めます。
- 途中で製品仕様を変更しないようにしてください。
- すべては、エンドユーザーのニーズまたは経験に左右されます。
管理プロジェクト：管理行動
- プロジェクトマネージャーは、指定された制限時間内に許容可能な品質の製品開発を完了するためのタスクを明確に理解する必要があります。この前提の下で、プロジェクトマネージャーは、人員およびその他の関連リソースを測定し、実行する必要があることのみを実行し、それに応じて行動できる必要があります。
開発システム：技術的行動
- 完璧を追求するのではなく、規定の制限時間と限られたリソース内でニーズを満たす「十分に優れた」製品を設計および開発する必要があるだけです。
- 設計作業は正確かつ完全に文書化されている必要があります。進歩のために、設計をスキップしてプログラムを直接作成することはできません。

デマンドマネージャーの決定->デマンド分析とレビュー->プロジェクト規模の見積もり->プロジェクトリスク分析->予備的なプロジェクト実行計画とレビュー

（2）プロジェクト承認書

プロジェクトの目的と管理の方向性を明確に述べる

PMを明確に承認する

プロジェクトに関連する情報

（3）必要な制約を明確にする

製品仕様の確認（コスト/パフォーマンス/品質/ ...需要）

製品の制限を確認する

プロジェクトに参加する会社とユニットを最初に確認します

開発モードの確認（S / W開発ライフサイクル）

ウォーターフォールモデル

プロトタイプモデル（初期要件は明確ではありません）

スパイラルモデル（ウォーターフォール+プロトタイプの複数の反復）

。。。。

2.プロジェクト計画段階

初期計画：このプロジェクトは受け入れられるべきですか？

計画はありません、それはハングする必要があります！プロジェクトを決定する前に、非常に注意深い分析を行っている必要があります。
不可能なミッションを完了してください！なぜなら、顧客が提供するプロジェクトは確かに単純すぎないからです。

（1）範囲/時間/コスト/品質計画

（2）リソース/コミュニケーション計画

（3）リスクプラン

（4）構成計画

（1）スコープ管理

妥協の芸術：進歩対仕様

品質とエネルギーバランスの原則は、顧客がスケジュールを繰り返し圧縮する場合、仕様を減らすことしかできません。顧客が仕様を繰り返し変更する場合、スケジュールを遅らせることしかできません。

プロジェクトが開始されるとき、最初にプロジェクトの範囲（何をすべきか、何をすべきでないか）を管理するために時間を費やすことです。正しい範囲が定義されている場合にのみ、後で行われるスケジュール、コスト、および人員計画は意味があります。

プロジェクト管理ツール-作業内訳構造、WBS、および変更管理

WBS
- 他のプロジェクト計画の最も重要な基礎である作業の内訳
- 分解基準：
- 「機能構成」で分類
- 「プロジェクトライフサイクル」別の内訳
- 「システムアーキテクチャ」に従って分解する
- WBSの最小分解単位（ワークパッケージ）は非常に具体的で、少なくとも1週間または40時間のワークロードに分割する必要があります。
- 表現方法（樹形図＋リスト）
変更管理
- すべての変更はCCB（変更管理委員会、つまり変更に関与する利害関係者が意思決定に参加する会議）によって承認され、新しい計画を作成する必要があります。仕様を非公開で変更するという顧客の要求を受け入れることは固く禁じられています。

（2）プロジェクトの進捗状況（時間/スケジュール）管理

時間は、一方向で、繰り返し不可能で、かけがえのないものであるという点で、他のリソースとは異なります。
「スケジュール計画」の計画：
- WBSからすべての最小アクティブユニット（ツリー図の葉）を取得します
- タスク間の関係（期間、注文関係）を確認します
- FS（Finish to Start）：タスクAが終了した後、タスクBを開始できます。
- FF（終了から終了）：タスクAが終了した後、タスクBを終了できます。
- SF（開始から終了）：タスクAが終了した後、タスクBを終了できます。
- SS（開始から開始）：タスクAの開始後、タスクBを開始できます。
- 進捗管理チャート（ガントチャート+ネットワークチャート）
- ガントチャートは、各タスクの開始時刻と終了時刻を示し、「進行状況の追跡」を実行するためにも使用できます。
- ネットワーク図は、クリティカルパスCPM（グラフで最も長い時間のパス）を見つけ、クリティカルパスのみを短縮するために使用されるタスクのシーケンス（ノードはタスクを表し、矢印はタスクの順序を示し、矢印の横の数字は必要な時間を表します）を示します。タスクに必要な時間は、プロジェクト全体のサイクルを短縮する可能性があります。
予約を管理する
- プロジェクト全体の時間を確保します（通常、プロジェクトサイクル全体の10〜15％）。必要がない限り、使用しないでください。
- パーキンソンの法則によれば、従業員にいくら時間を与えても、彼は常に彼に割り当てられた時間を使い果たす傾向があります。
知っておくべき原則
- スケジュールは変更ではなくコンプライアンスのためのものです。遅延が発生した場合、PMとスーパーバイザーは、スケジュールを修正するのではなく、積極的に問題の解決を試み、スケジュールに追いつくようにする必要があります。
- スケジュールを立てるときは、ラフからディテールまでさまざまなユニットの意見を調整して統合し、密室で作業することを忘れないでください。
- 進捗状況とコストは反比例します。
- WBSの分解は、プロジェクトのスケジュールに直接影響します
- 実行期間中は、プロジェクトの計画と実際の進捗にずれがないかを常に確認し、時間内に追跡して対処する必要があります。

（3）プロジェクトコスト（コスト）管理

ソフトウェアシステムのプロジェクトコストの見積もりは決して正確ではなく、精度を向上させるために経験または業界のコンセンサスにのみ依存することができます。
プロジェクトは商業活動であり、収益性のない製品を開発しない方がよいでしょう。すべてがコストのために妥協されなければなりません。
コストの主な原因：
- 管理費
- ハードウェア/構造設計コスト
- 製造および材料費
- ソフトウェア開発コスト（コードライン、機能ポイント、人月...）
- COCOMOモデルのコスト見積もり
コスト見積もりエラーの原因：
- 基本データが不十分で、プロジェクトにはまだ多くの不確実な要素があります
- プロジェクトのコストは需要に敏感です
- 経験の浅い、または不十分なコスト見積もり手法
- 署名の前後で一貫性がない
WBSが作成され、作業がより詳細に分割された後でのみ、推定は実際の状況に最も近くなります。しかし、引用する前にWBSを終了するまで、実際の作業を行うことはしばしば不可能です。「マンマンス神話：ソフトウェアプロジェクト管理の方法」をお勧めします。組み込みソフトウェアプロジェクトでは、人件費が総費用の最も重要な部分です。
稼得価値管理

主にプロジェクトのコストと進捗状況の監視に使用されます。これまでに行われた作業をプロジェクト計画の推定値と比較して、プロジェクトが完了してからの距離の推定値を提供します。PMはプロジェクトのコストを取得できます。リソースの数。

（4）プロジェクトの品質（品質）管理

基本的な考え方
- 品質はチェックではなく計画されます。予防は治療よりも重要です。「品質計画」は計画段階で作成し、プレーンテキストで発表する必要があります。詳細なルールを策定する前に、ベースラインを太い線で設定できます。
- プロジェクトの品質は、すべての開発者の作業品質の産物です。
- 品質管理は1回限りのアクティビティではありませんが、プロジェクトのライフサイクル全体を通じて実行されます。
- 品質レベルは相対的であり、顧客の需要と価格によって異なります。
- 品質管理は精神であり、ISO9000またはCMMを介して高品質の製品を製造することはできません。
- 品質管理システム：ISO9000またはCMMI
QA（品質保証）

プロセスの正確さに焦点を当てることは、管理機能です。QAの主な目的は、確立されたスケジュールと予算の下で、製品が期待される品質レベルと信頼性の目標を確実に達成できるようにすることです。QAのツールは監査であり、計画の策定、モジュールの設計、コードのレビュー、テスト計画、製造プロセス、および材料の準備計画からすべての段階で監査する必要があります。計画段階の成果は、品質計画を策定し、プロジェクトで採用されている品質基準を明確にし、基準の要件を満たす方法を決定することです。特に：
- 特定のマイルストーンを完了しました
- 変更のリクエスト
- プロジェクトが次の段階に入るとき
QC（品質管理）

プロセスのバグの発見と追跡に焦点を当てることは、検査機能です。QCは、プロジェクトの結果が品質基準に準拠しているかどうかを判断すると同時に、不一致（バグ）の理由を見つけ、それらが適切に解決されているかどうかを追跡する必要があります（各バグの処理プロセスを記録する必要があります）。計画段階の作業成果物は、テスト計画を作成することです。

（5）プロジェクト人的資源（人的資源）管理

人員の適切な編成と管理は、ソフトウェアプロジェクトに影響を与える決定的な要因です。
MSには明確なルールがあります-プロジェクトチームのメンバーは10人以下です。
組織構造：
- 機能的な組織（組織とプロジェクトの利益が対立する可能性があります）
- プロジェクト組織（リソースが重複している、会社の戦略を実行できない）
- マトリックス編成（機能マネージャーまたは部門マネージャーとプロジェクトマネージャー間の競合）
- 強力なマトリックス編成
チーム管理
- 実際に存在するプロジェクトチームを作成する
- 報酬メカニズムを確立する
- 良好な対人関係を確立する
- 作業許可システムを設定する
- 動機理論：自分の才能を自分のベストに合わせる

（6）プロジェクトコミュニケーション（コミュニケーション）管理

管理エラーの70％はコミュニケーション不足が原因であり、PMの時間の80％以上がコミュニケーションに費やされています。
コミュニケーション計画：
- コミュニケーションのニーズ：誰が、いつ、どのようなニーズが必要ですか？
- コミュニケーションコンテンツ：コミュニケーションフォーマット、コンテンツ、詳細レベルなど。
- 通信方法：明確な通信方法と通信チャネル（会議、バグ管理ソフトウェア、作業レポート）
- コミュニケーションの責任：誰がメッセージを送信し、誰がメッセージを受信するか
- コミュニケーションの手配：重要なコミュニケーションイベントのスケジュールをプロジェクト計画に含める必要があります。（例：レビュー会議）
通信チャネルの計算：プロジェクトにN人がいる場合、N（N-1）/ 2の通信チャネルを確立する必要があります。これは、高い通信コストに相当します。

（7）プロジェクトリスク（リスク）管理

Risk三要素：
- イベントです
- 発生確率
- プロジェクトに一定の影響を与える
リスク管理は最も見過ごされ、管理が最も困難です
リスク管理プロセス（繰り返し）：
- リスクの特定：リスクを一覧表示します
- プロジェクトの可視性が不足している
- 新技術の魅力
- テクノロジーの互換性のリスク
- パフォーマンスリスク：設計フェーズの実装の強度を高め、プロトタイプ（プロトタイプ）を作成するなど。
- オンラインで急ぐリスク
- 使いやすさの問題
- 材料不足、部品価格の高騰
- 契約リスク：契約内容を法務で詳細に確認する
- 需要変更リスク：変更処理プロセスについて事前に書面で合意する
- コミュニケーションリスクの低さ：プロジェクトコミュニケーション計画の策定と発表
- 高レベルのサポートリスクの欠如
- スケジュールのリスク：スケジュールを調整できない場合は、できるだけ多くのリソースと予算を取得するか、段階的に製品を提供するようにしてください。
- 品質リスク：プロジェクトの品質戦略を慎重に策定し、品質管理チームを設立します。
- チームメンバーの能力リスク：事前にメンバーをトレーニングまたは変更します。
- チームワークのリスク：明確な目標と公正なパフォーマンスシステム。
- 人事異動リスク：コアタスクは実行のために複数の人に割り当てられます。
- リスクのあるメーカーを支援する：協力する前にレビューと承認の手順を策定します。
- リスクアセスメント
- 定性分析
  - 確率/重大度マトリックスのリスト
  - プロジェクトの弱点をある程度理解している
- 定量分析：定性分析の結果に基づく数学的処理と表現
- リスクランキングを一覧表示します（確率X重大度）
- リスク計画（治療）
- リスクを回避する：リスクの原因となる計画の使用を積極的に断念または拒否し、代替案を探します
- リスクの移転：リスクをアウトソーシング会社に移転する
- ロスコントロール：リスクが発生したときの危害の程度を軽減する
- リスクを取る：発生の可能性が低い、または影響が少ないリスクに対処しないことを選択できます
- リスク管理

（8）プロジェクトの調達/契約管理

ソフトウェアのアウトソーシング：実際には、自社開発への純投資よりも15％から20％多い
アウトソーシングプロジェクトの管理は、自己開発よりも複雑です。
- 技術的な難しさ
- 通信の複雑さ
- アウトソーシングコスト
アウトソーシングプロジェクトに関する注意：
- 通信の問題
- 詳細な計画を立てる
- 遅延を避ける
- 明確な受け入れ基準（ソフトウェア仕様とAPI ...）

（9）プロジェクト構成（構成）管理

開発プロセス全体を実行します。目的は、製品の整合性とトレーサビリティを確立および維持することです。
ソフトウェア開発プロジェクトの成熟したバージョン制御プロセスに対応
ソフトウェア構成管理-単にプロジェクト資産管理、開発プロセスで製品を識別、追跡、および制御するプロセスを意味します。これには次のものが含まれます。
- 製品仕様と設計仕様を含む、プロジェクトの全体像。
- プロジェクトの当初の計画と、プロジェクトの運用中に行われたすべての変更。
- 設計段階での主要なターニングポイントと、プロジェクト運用中の主要な技術的ブレークスルー。
- ソフトウェア開発中にどのような問題に遭遇し、その解決策は何でしたか？対応するプログラムコードは何ですか？
- 重要なソフトウェアバージョンまたはプロジェクトマイルストーンの重要性、およびそのイベントでのプロジェクトステータスのスナップショット
- ハードウェアの設計および製造段階での問題の履歴が解決策です。

3.プロジェクトの実行/制御段階

ソフトウェアエンジニアリングとプロジェクト管理はどのように連携しますか？

ソフトウェアエンジニアリングには、次の3つの循環プロセスが含まれます。

開発プロセスの定義：ソフトウェア要件、ソフトウェア開発プロセス、ソフトウェア構成管理SCMを含む
ソフトウェア開発：ソフトウェア設計、ソフトウェア構築、テスト、保守、更新を含む
ソフトウェア品質保証：ソフトウェア品質

プロジェクト管理プロセスは、次の3つの循環プロセスで構成されます。

プロジェクト計画
プロジェクトの実施
プロジェクトの監視

（1）製品仕様設計

製品仕様書を作成した後、お客様は最後に確認して再度署名する必要があります。今後のすべての設計作業では、これをテンプレートとして使用する必要があります。顧客が新しい要件を「仕様」に変えたいと思ったら、レビューに合格した正式な文書を変更する必要があり、これは品質管理システムによって承認される必要があります。

一般的に、製品仕様には次の側面が含まれます。

ハードウェア仕様の概要
製品の設計コンセプト、制限、および適用範囲
ユーザー機能マニュアル
運用フローチャート
ユーザーインターフェースとアートワーク
性能規制
特別な考慮事項

（2）ハードウェア設計

ハードウェア設計段階の作業は次のとおりです。外観と構造の設計に加えて、ファームウェアエンジニアは可能な限り参加する必要があります。

CPUの選択
メインチップの選択
回路設計
レイアウト
部品および材料の管理
製品形状設計
構造設計
型開き前の模型製作

この段階で出力されるファイルは次のとおりです。

ハードウェア設計仕様
GOOD表
3D外観
構造図
回路図
レイアウト図

（3）システム設計

プロジェクトの規模やハードウェア環境に応じて、適切な設計方法を選択してください。CPU周波数が数十Mで、メモリが小さい場合は、構造化されたメソッド設計を選択し、開発用にC言語を選択することをお勧めします。プロジェクトが大きく、CPU周波数が数百Mで、ストレージリソースが豊富な場合は、オブジェクト指向の方法が選択され、言語はC ++またはJavaになります。

（4）テストプランの設計

ソフトウェアテストの基準もあります。IEEE829は、テスト計画の規定と注意事項を詳細に説明していますが、実際の状況では、基準のアイデアと精神はプロジェクトの特性に応じて継承されるべきです。テストを行う前に、より複雑な機能、新機能、顧客の特別な要件、または仕様に記載されているあいまいな領域の理解に焦点を当て、テストケースと計画を設計する必要があります。

（5）リスク評価

最も一般的なリスクは次のとおりです。

進行中の遅延
需要のインフレ
離職
仕様の崩壊
業績不振
テクノロジーギャップ
文化の違い
ソフトウェアとハードウェアの統合
製造上の問題

リスク特定プロセス：

リスク特定フローチャート

リスクに対処する4つの方法：

避ける：危険な部分には触れないでください
抑制：リスクが具体化したときにリスクを軽減するために十分な時間とお金を準備します
緩和策：リスクが具体化する前に特定の対策を講じる
脱出：何もせず、神の祝福を祈る

（6）コーディングする前に設計文書を書く

プロジェクトの開始から、プロジェクトのすべてのファイルを保存および管理するためのサーバーを準備する必要があります。すべてのプロジェクトメンバーは、必要なファイルまたはレコードを簡単に取得できます。

記録する必要のあるファイルは次のとおりです。

製品仕様
スケジュール
ハードウェア設計関連文書（CPU PIN構成図、概略図、レイアウト図など）
技術文書-チップデータシート、サードパーティソフトウェアライブラリAPIなど。
システムアーキテクチャ設計仕様（各モジュールのAPIを含む）
テスト計画
テストレポートとバグシート
品質文書
重要な会議の議事録
重要なメールのバックアップ
記録されるその他の文書

（7）デザインレビュー

デザインレビューの原則：

デザインレビューは進歩的でなければなりません。そして、設計の全プロセスを実行します
デザインのクライアントをデザインレビューに参加するように招待します
デザインが大きいほど、参加するためにすべてのプロジェクト担当者を呼び出す必要があります。

（8）実施段階

すべての設計ドキュメントがレビューに合格したら、実装段階に入ることができます。これには次のものが含まれます。

プログラムの開発とデバッグ
ハードウェア（電子機器、構造）の開発
ソフトウェアとハードウェアのテスト
同じ品質の実行
工場試作

プロジェクトの各段階は、PDCA（Plan、Do、Chick、Act）に従って循環させる必要があります。プログラムのコンパイル中に設計上の問題が発見された場合は、自分で変更しないでください。実装を続行する前に、一時的に実装を停止し、対策を見つけ、影響範囲を確認し、関連ユニットの設計レビューに合格する必要があります。これが「設計変更」プロセスです

同じ組み込み開発の結果は、最終的には商品化されるため、工場との取引は避けられません。

ソフトウェアエンジニアが工場に届けなければならないアイテムは次のとおりです。
- 書き込み用のバイナリファイル
- 生産ラインの自動テストプログラムとマニュアル
- 環境試験専用の試験手順
ハードウェアおよび電子エンジニアが工場に提供しなければならないアイテムは次のとおりです。
- 電子回路
- 電気工学仕様
- 特別仕様試験説明書（これまで工場で製造されていなかった機能）
構造エンジニアが工場に届けなければならないアイテムは次のとおりです。
- 組み合わせ図（すべてのパーツを1つずつ展開）
- 特殊部品の外形図
- 特殊加工組み合わせ図

4.プロジェクトの終了段階

（1）外部契約の締結

（2）内部プロジェクトの終了

プロジェクトデータアーカイブ

技術データアーカイブ

経験を記録し、会社のプロジェクト資産を蓄積する

緊密な会議、人員解散

プロジェクトの実行中に、プロセスを開発し、自動化されたツールを使用してプロジェクト開発の追跡（プログラム、ファイル、バグ管理、問題管理、変更管理などを含む）を記録し、定期的にバックアップします。

プロジェクト終了プロセスの実施の開始時間と終了時間を明確に規定し、できれば1週間以内にし、プロジェクトメンバーの部門長および現在のプロジェクトマネージャーと連絡を取り、調整し、これらの同僚に一定期間内にプロジェクトを支援するよう依頼します。

組み込みプロジェクト管理への一般的なアプローチ