ソフトウェアエンジニアリングの概要(ソフトウェア危機、ソフトウェアエンジニアリング、ソフトウェアライフサイクル、ソフトウェアプロセス)

  • ソフトウェアエンジニアリングの概要(1)
  • 指向の構造化された方法論(2-8)
  • オブジェクト指向の方法論(9-12)

1.ソフトウェアの概念

ソフトウェアはプログラムと同じではありません。
ソフトウェアとは何ですか?

プログラム+データ構造+ドキュメント

ソフトウェアは、コンピュータプログラム、使用されるデータ、および関連ドキュメントのコレクションです。実際、ソフトウェアは、人々の特定のニーズを満たすために開発および使用される人々の集まりです。したがって、ソフトウェアは、プログラム、データ、ドキュメント、および人で構成されます。

プログラム:操作中に必要な機能とパフォーマンスを提供できる命令セット。プログラムコンピュータで認識、理解、処理できるプログラミング言語で記述された一連の文。
データ構造:プログラムを正しく実行できるようにするデータ構造。
ドキュメント:プログラム開発のプロセスとメソッドの使用を説明するドキュメント。ドキュメントは、ソフトウェア開発活動と段階的な結果を記録し、ソフトウェアを理解するために必要な説明資料です。

2.ソフトウェアの危機

1.
ソフトウェア危機の概念ソフトウェア危機:ソフトウェアの開発および保守中に発生する一連の深刻な問題を指します。
2.ソフトウェア危機のパフォーマンス

  • ソフトウェア開発のコストとスケジュールの見積もりは非常に不正確です
  • ユーザーは「完成した」ソフトウェアに満足せず、それを受け入れることさえ拒否します
  • 信頼できないソフトウェア品質
  • ソフトウェアの保守性が悪い
  • ソフトウェアには通常、適切なドキュメントがありません
  • コンピュータシステムの総コストに占めるソフトウェアコストの割合は年々増加しています
  • ソフトウェア開発のスピードと生産率が上がり、ハードウェア開発のスピードに追いつかない

3.ソフトウェア危機の典型的な例

デンバー国際空港の
IBM360シリーズ、
ARIANE 5ロケット、
パトリオットミサイル
2008原子炉のオペレーティングシステム

4.ソフトウェア危機の根本原因

  • 大規模で複雑性が高い
  • ソフトウェアは論理的な製品であり、その本質と特徴は完全には理解されていません。
  • 質の高い人材の不足(技術および管理)
  • ソフトウェアの開発、管理、保守をガイドするための効果的で体系的な原則、原則、方法、およびツールの欠如

ソフトウェア危機の理由:
①ソフトウェアの特性。ソフトウェアの特性には、知識、社会性、複雑さ、不可視性、ハードウェア、規模の拡大などがあります。これらの特性により、ソフトウェアの開発、使用、保守に隠れた危険が残り、ソフトウェアの危機につながる可能性があります。
②開発、使用、保守の方法は科学的ではありません。たとえば、需要分析が実施されていない、4つが開発されていない、ツールが後方にある、品質保証がないなどです。

3.ソフトウェアエンジニアリング

1.ソフトウェアエンジニアリングの定義
1.ソフトウェアエンジニアリングは、実際のマシンで効果的に実行できる信頼性の高いソフトウェアを経済的に取得するために確立および使用される健全なエンジニアリング原則です。
2.ソフトウェアの開発、運用、保守のプロセスに、体系的で標準化された測定可能なアプローチを適用します。それはソフトウェアにエンジニアリングを適用することです。

2.ソフトウェアエンジニアリングの
本質的な特徴基本的な特徴:
ソフトウェアエンジニアリングは大規模なプログラムの構築に焦点を当てています;
②ソフトウェアエンジニアリングの中心的な主題は複雑さを制御
することです;
③ソフトウェアは頻繁に変更されます; ソフトウェア開発の効率は非常に重要です;
⑤調和のとれた協力は開発ですソフトウェアの
秘訣; ⑥ソフトウェアはユーザーを効果的にサポートする必要があります;
✓ソフトウェアエンジニアリングの分野では、ある文化的背景を持つ人々は通常、別の文化的背景を持つ人々のために製品を作成します。

3.
ソフトウェアエンジニアリングにおける役割ソフトウェアエンジニアリングにおける役割には、プロジェクトマネージャー、製品マネージャー、分析デザイナー、プログラマー、テスター、実装、保守、トレーナー、および販売が含まれます。
4.ソフトウェアエンジニアリングの基本原則

  • 段階的なライフサイクル計画による厳格な管理
  • ステージレビューを主張する
  • 厳格な製品管理を実装する
  • 最新のプログラミング技術を使用する
  • 結果は明確にレビュー可能である必要があります
  • 開発チームは小規模で熟練している必要があります
  • ソフトウェアエンジニアリングの実践を継続的に改善する必要性を認める

4.ソフトウェアエンジニアリング手法

ソフトウェアのライフサイクル全体で使用される一連の技術的手法は、通常、方法論と呼ばれます。

ソフトウェアエンジニアリング手法の3つの要素:

方法-ソフトウェア開発のタスクを完了するための技術的な方法です。
ツール-メソッドを適用するために提供される自動または半自動のソフトウェアエンジニアリング環境です。
プロセス-高品質のソフトウェアを入手するために完了する必要がある一連のタスクのフレームワークであり、各タスクを完了するための作業ステップを指定します。

ソフトウェアエンジニアリング方法論:
1。従来の方法論
ライフサイクル方法論
構造化パラダイム

2.オブジェクト指向の方法論

オブジェクト:データとデータの操作を統合する統合ソフトウェアコンポーネント。
すべてのオブジェクトをクラスに分割します。
親クラスとサブクラスは階層システムを形成します。
オブジェクトは、メッセージを送信することによってのみ相互に通信できます。

オブジェクト指向の方法論は、データと動作を等しく重要と見なします。これは、データをメインラインとし、データとデータの操作を緊密に統合する方法です。

5、ソフトウェアライフサイクル

ソフトウェアライフサイクルモデルフェーズ

(1)問題の定義;
(2)実現可能性の調査;
(3)需要分析;
(4)全体的な設計;
(5)詳細な設計;
(6)コーディングとユニットテスト;
(7)包括的なテスト;
(8)ソフトウェアのメンテナンス。

6、ソフトウェアプロセス

1.一般的なソフトウェアプロセスモデル
(1)ウォーターフォールモデル;
(2)プロトタイプモデル;
(3)インクリメンタルモデル;
(4)スパイラルモデル;
(5)ファウンテンモデル;
(6)アジャイルモデル;
(7)統合プロセスモデル。

プログレッシブ開発モデル:迅速なプロトタイピング、インクリメンタル、スパイラル

2.ウォーターフォールモデル(不可逆)
シーケンスと依存関係
実装の遅延
品質保証
3.迅速なプロトタイピングモデル
によって迅速に確立できるコンピューター上で実行できるプログラム実行できる機能は、多くの場合、最終的なソフトウェア製品の機能です。サブセット。
4.インクリメンタルモデル(インクリメンタルモデル)
は、ソフトウェア製品を一連のインクリメンタルコンポーネントとして使用して、設計、コーディング、統合、およびテストを行います。各コンポーネントは複数の相互作用するモジュールで構成され、特定の機能を実行できます。
5.スパイラルモデル

ウォーターフォールモデル+迅速なプロトタイピング+リスク分析

リスクを最小限に抑えるために、プロトタイプやその他の方法を使用してください。このモデルを理解する簡単な方法は、各段階の前にリスク分析プロセスを追加する迅速なプロトタイプモデルと考えることです。

6.噴水モデル

  • 反復:各開発アクティビティは多くの場合、作業を何度も繰り返し、関連する機能は各反復で進化したシステムに追加されます。

  • ギャップなし:開発活動間に明確な境界はありません。
    7、合理的な統一プロセス

アイデア:
1。システムアーキテクチャに焦点を当てる
2.ユースケース主導型
3.反復開発

RUPを使用すると、ツールの購入コストと学習コストが莫大になります
。RUPソフトウェア開発ライフサイクルは、2次元のライフサイクルモデルであり、横軸は時間を表し、縦軸はコアワークフローを表します。

4つの段階:
初期段階、
本質段階、
建設段階、
引き渡し段階

8.アジャイルプロセスとエクストリームプログラミング
アジャイルプロセスはアジャイルプロセスです(軽量方式)

アジャイル方式が採用されている状況に適してい
ます不確実な要件と不安定(揮発性、つまり今日の要件は明日必要ないことを意味します)
責任感と意欲のある開発者、
ユーザーはコミュニケーションが容易で、参加できます

エクストリームプログラミングは、アジャイルメソッドの中で最も有名なものです。

9.マイクロソフトプロセス

  • 計画段階

市場調査と調査を実施し、会社の戦略を組み合わせて長期的な製品目標を形成します。

  • 設計段階

製品の長期的な目標に従って、ソフトウェアの機能仕様と全体的な設計を完了し、製品開発の主な進捗状況を判断します。

  • 開発段階

    開発タスク全体はいくつかの段階的な段階に分割され、M1、M2、Mnなどの内部マイルストーンに設定され、段階的な作業結果が各マイルストーンで送信されます。

  • 安定期

包括的な内部および外部テストを実行し、最終的にリリース可能なRTMバージョンを作成します。

  • リリース段階

製品の品質がリリース基準を満たしていることを確認した後、製品および関連ニュースをリリースします。

7つ目は、RUPとアジャイルプロセスの長所と短所です。

(1)RUP
RUPの利点:①RUP
は、反復、需要主導型、構造化プロセス開発などの優れたソフトウェアエンジニアリング原則に基づいています。
②RUPにはいくつかの方法があります。たとえば、反復ごとに動作するプロトタイプが生成され、各段階の最後にプロジェクトを続行するかどうかが決定されます。これらの方法により、開発プロセスを非常に直感的に管理できます。
③合理的な会社は、このhtmlベースのソフトウェアプロジェクトを組織の実際のニーズに合わせてカットできるように、RUPを開発しており、今後も開発を続けます。
RUPのデメリット:①RUP
には開発プロセスのみが含まれます。ソフトウェアプロセスを完全に網羅しているわけではありません。図1から、メンテナンスと技術サポートの2つの重要な段階が失われていることがわかります。
②RUPは組織内でのマルチプロジェクト開発をサポートしていないため、組織内での大規模な再利用に失敗します。
③RUPは開発者のサポートが不足しています。ソフトウェアプロセスのあらゆる側面を自動化できますか?Rationalは、合理的なヘルプデスクや合理的な永続性モデリング4があるかどうかなど、選択できるすべてのツールを提供します。RUPには、測定管理、再利用管理、人事管理、およびテストに欠陥があります。
(2)アジャイルプロセスアジャイルプロセス
のメリット:
①個人やインタラクションはプロセスやツール
よりも優れている②実行可能なソフトウェアは包括的なドキュメントよりも優れている
③顧客の協力は契約交渉よりも優れている
④変更への対応は計画に従うよりも優れている
。アジャイルプロセスのデメリット:
アジャイルフォーカス人事コミュニケーションは文書化の重要性を無視します。プロジェクトの人員フローが大きすぎると、メンテナンスが非常に困難になります。特別なプロジェクトに初心者が増えると、年配の従業員はより疲れます。

8.まとめ

ソフトウェアは、プログラム、データ、および関連ドキュメントのコレクションです。
ソフトウェア危機の根本的な原因の1つは、体系的な方法とツールガイダンスの欠如です。
ソフトウェアエンジニアリング:方法、ツール、およびプロセス。
ソフトウェアエンジニアリングの基本原則
ソフトウェアライフサイクル
ソフトウェアプロセスモデル

おすすめ

転載: blog.csdn.net/weixin_44366125/article/details/105875914
おすすめ