組込みソフトウェアテスト対策_7 システム開発プロセスとプロジェクト管理

システム開発プロセスとプロジェクト管理

開発モデル

開発プロセスを段階に分割します。

ウォーターフォールモデル: SDLC。欠点は、最初に要件を明確にする必要があることですが、開発サイクルを変更しないことが難しいことです。

そこで改善してください:

プロトタイプ: デモ。

ラピッド プロトタイピング モデル: モデルを放棄する ユーザーのニーズが得られたら、プロトタイプを破棄できます。

進化モデル：プロトタイプをベースに、ユーザーのニーズに合わせて改良を加えました。しかし問題は、ユーザーが干渉しすぎてユーザーがプロジェクトを支配してしまった場合、プロジェクトの時間をコントロールすることが困難になることです。

そこで、プロトタイプとウォーターフォールモデルを組み合わせて、スパイラルモデルとインクリメンタルモデルが誕生しました。

スパイラルモデル：大規模プロジェクトやリスクの高いプロジェクトに適しています。デモから始めて、最終的には実用的な製品を手に入れることができるかもしれません。

増分モデル: 各リリースは運用可能な製品です。

V モデル: いくつかの検証とテストを追加しました。ソフトウェアには高い品質が求められますが、コーディング後にしかテストできないのがデメリットです。

ファウンテン モデル: オブジェクト指向。

画像クレジット:ファウンテンモデルとは何ですか? _ウィズダム成都ブログ-CSDN ブログ

RAD：現在よく使われているコンポーネントモデルとウォーターフォールモデルをベースにした高速モデル。

コンポーネントアセンブリモデル:

コンポーネントライブラリにより移植などの開発効率が大幅に向上します。

アジャイル手法モデル: アジャイルマニフェストに準拠することはアジャイル手法です。

一般原則として、小規模バージョンは迅速に配信されます。

典型的なアジャイル手法:

• 極端なプログラミング。

すべてを適用する必要はなく、具体的なプロジェクトに応じて分析する必要があります。

• クリスタルメソッドシリーズ: クリスタル、鍛錬を減らしても成功することができます。

• オープンソース openUp: 開発者は地理的に広く分散しており、トラブルシューティングは高度に並行して行われます。誰でもメンテナにパッチを送信すると、メンテナはそのパッチをソース コード リポジトリにマージします。

• スクラムスクラム方法: 繰り返し続けます。30 日などの一定期間の反復はスプリントと呼ばれ、要件を達成するために優先順位に従って複数の反復が実行されます。

• FDD 関数駆動型開発手法、短期イテレーション段階、プログラミングは一般にチーフプログラマ (プロジェクト調整) とクラスプログラマ (ソースコード作成) に分かれます。

• asd 適応型ソフトウェア開発手法。推測、協力、学習の 3 つの段階に分かれています。

• dsdm ビジネスを核とした動的システム開発手法、ビジネス中心のフレームワーク開発手法。

プロジェクト管理

専門家の判断: 専門家は経験に基づいて判断します。

3 点見積もり: 最良の場合、何人が必要ですか? 最悪のシナリオ？一般的な状況はどうですか？重量に基づいて計算されます。

ファンクション ポイントの見積もり: プロジェクトのいくつかのファンクション ポイントに基づいて見積もります。

時間管理

PERTチャート

破線は時間を必要としないアクティビティです。

最も早い開始時刻が最初から繰り上げられます。Eアクティビティなど。早ければ3ノード目、つまり4日目(ABの最大値)から始まり、早ければ7日目に終了します。

25号が一番早く完成しました。

最新の作業時間がこのノードから反転されます。

A：トータルタイム差は0です

B：2

子：2

……

クリティカル パス: 合計時間差 = 0 のパス。1-2-3-4-6-7-9、このクリティカル パス上のイベントを遅延させることはできません。遅延はプロジェクト プロセス全体に影響します。

PERT 図の関係は非常に明確です。

ガントチャート

ガント チャートの時間の流れ、簡単なリソース計画。しかし、関係の表現は良くありません。

例：

最長パス ABCEFJ の場合、最短時間は 18 日です。

BC と BD は同じ人によって開発され、最初に BC、次に BD、BD が 3 日後、または最初に BD、次に BC、BC が 2 日後に開発され、合計期間は +2 になります。

当初は 02578 が最長の 55 日でした。

変更後は 0268 に相当し、8+23+25=56 日となります。

最短期間: ABDIJL 20 日。

GH のパス: 17 日間、つまり GH リラックス時間は 20 ～ 17 日です。

ソフトウェア構成管理

開発ライブラリはテスト後、管理ライブラリに追加して変更することができ、変更後はテストして元に戻すことができます。

チェックポイント: 指定した時間間隔でプロジェクトを確認し、実績と計画との差異を確認し、修正します。

マイルストーン: 段階的な作業の兆候。

ベースライン: 正式なレビュー後の重要なマイルストーン。それは簡単に変えることはできません。

• 機能ベースライン: システム設計仕様。
• 割り当てベースライン SRS: 要件仕様。
• 製品ベースライン: ソフトウェア製品のすべての構成項目の仕様 (包括的)。

レビューを送信してレビューに合格したら、変更を申請し、コードをプルダウンして動作状態にチェックアウトして変更を開始します。

リスク分類

三次元測定機認証

認定の一種。これを経由するプログラムが優先される場合があります。ソフトウェア開発とソフトウェアテストの実習。

18 の主要ドメイン:

試験ではどの審査員がどのレベルにあるかが問われます。

要件エンジニアリング

要件分析は非常に重要で、それがうまく行われないとプロジェクト全体が崩壊してしまう場合もあります。

要件開発：要件取得、要件分析、要件定義（srs仕様）、要件検証。

要件管理: 上記の部分が決定された後、実際の要件は要件ベースライン アプリケーションを通じて変更できます。変更管理、バージョン管理、要件追跡、要件ステータス追跡が含まれます。

要件は、ソフトウェア要件、機能、制御、動作、パフォーマンス、設計制約などの観点からシステムに対するユーザーの期待 (システムが解決する必要がある問題は何か) に分類されます。

• ユーザーのニーズ: ユーザーの視点。
• ビジネス要件: 全体像。
• システム要件: コンピューター化。機能要件（実現したい機能）、非機能要件（性能など）、設計上の制約（データベース、ユーザーはmysqlが必要、またはos、ユーザーはlinuxが必要など）を含みます。

上から下へ、抽象的なグローバルから具体的な詳細まで。

3 は最も抽象的で、2 は機能的に最も具体的です。

A。

構造化分析

データ辞書: ユーザーや開発者が理解しやすいデータの説明。たとえば、データベース内の dbname 項目にはデータベースの名前が格納され、encoding にはそのエンコード方法が格納されます。または、発券プラットフォームでのユーザー入力を標準化し、目的地は北京、河北、広州などのみ選択できます。 ..

データ フロー図:

最上位レベルは、システムと外部エンティティの関係を表します。以下の図は、トップレベルの図の詳細です。

円はデータ処理、矢印は流れ方向のあるデータ、2 本の線はデータの保存、外部エンティティは外部データのソースである四角形のエンティティです。

状態動作図:

開始点、終了点 (丸で囲んだ部分)、ボックスは状態、線はイベントです。

データ フロー グラフと比較すると、これは動的動作であり、データ フロー グラフは静的です。

ER 図、mysql の古い知り合い:

エンティティとプロパティはワイヤーで接続されます。

強いエンティティと弱いエンティティの概念:

研修会社のデータベース設計の
ビジネス要件は次のとおりです。

各学生は学期ごとに 1 つのコースのみを受講できます。

つまり、同社には多くのコースがあります。「各学生はセッションごとに 1 つのコースのみを受講できる」という要件のみを分析したところ、学生とコースという 2 つのエンティティが関係していることがわかりました。したがって、データベースを次のように設計するのは当然のことと考えるかもしれません。

コースは複数の学生が選択できますが、学生が選択できるコースは 1 つだけです。問題が見つかりましたか? ビジネス要件は、学生が 1 つのコースしか受講できないことを意味するのではなく、学生が 1 学期に 1 つのコースしか受講できないことを意味します。このようにデータベースを設計することは、人々のお金を切り取ることになります。したがって、「セッションごと」という概念を考慮する必要があります。

問題ないようですが、データベースの設計がそんなに簡単であるはずがありません。私たちは各コースをレコードとして捉えているため、コース名、価格、紹介などのコース情報については、コースを開くたびにデータベースに一連のレコードを保存する必要があるため、データベースの冗長性が高くなります（また、つまり、データベースの第 2 正規形も満たしません)。したがって、データベースを次のように設計する必要があります。

見えますか？ここでの「記録」は弱いエンティティであり、その主キーは授業に参加する学生の行動を表す「学期主キー＋学生主キー」であり、抽象化が弱いエンティティとなる。学期テーブルの主キーと学生テーブルの主キーを使用するのはなぜですか? 1 人の学生、1 学期には 1 つのコースしか受講できないため、主キーはレコードの各行を一意に識別するという原則に従って、この方法で選択する必要があります。カリキュラム テーブルの主キーはレコード テーブルの外部キーとなり、カリキュラム テーブルとレコード テーブルの間には 1 対多の関係が存在します。

この例では、学生とコースはビジネス要件の説明において明白なエンティティであり、「期間」もより明白なエンティティと見なすことができますが、動詞「参加」はデータベースでは「出席記録」、つまりレコード エンティティになります。 。
———————————————
著作権に関する声明: この記事は CSDN ブロガー「Qiao Qing」のオリジナル記事であり、CC 4.0 BY-SA 著作権契約に従っており、オリジナルのソースリンクを添付してください。この記事は声明を転載するためのものです。
元のリンク: https://blog.csdn.net/qq_41112170/article/details/103328927

オブジェクト指向のニーズ分析: テストが少なくなります。

集計: たとえば、車のタイヤが壊れても、車は大丈夫です。

UML 図:

構造化されたデザイン

構造化分析に基づいています。

情報の隠蔽: カプセル化。

モジュールの独立性: 各モジュールはできる限り 1 つのことだけを行います。

呼び出しの深さ: ネストレベル。

ファンインとファンアウト: 他のモジュールがこのモジュールをより頻繁に呼び出し、このモジュールが他のモジュールを呼び出す頻度が低くなります。

モジュール構造設計

システムを、相互にインターフェースを持つモジュールに分割します。

モジュールは、IO、処理機能、内部データ、プログラム コードを含むシステムの基本単位です。

○○デザイン

ソフトウェアとハ​​ードウェアの共同設計