EBU6304 ソフトウェア エンジニアリングのナレッジ ポイントの概要_7 オープン ソース ソフトウェア、ソフトウェア開発ツール

オープンソースソフトウェア

無料で、使用に関する法的制限もありません。

アジャイル開発も必要ですが、開発手法が少し異なり、結局のところ興味のあるモデルではありません。個人間の密接な個人的なやり取りを重視しており、開発者は自分自身の顧客でもあるため、多くの人がテストを行い、修正された小規模バージョンがすぐにリリースされます。通常は小さなモジュールが多数あり、世界中の全員が別々に開発します。

世界中の人々が電子的に通信しています。

全体のコーディネーターは通常ボランティアです。

商用ソフトウェアと OSS は大聖堂とバザールのようなもので、大聖堂には全体的な建設目標が必要であり、全員が協力する必要があります。バザールは都市管理者のような総合コーディネーターによって運営されるかもしれませんが、それでも全員がより個人的なものです。

貴社が自社でプロジェクトを開発する場合、当然開発とその後のメンテナンスに多大な人的・資金的リソースが必要になりますが、クローズドソースソフトウェアを選択した場合、サプライヤー(独占技術)に拘束され、当社がその費用を支払わなければなりません。追加料金がかかります。オープンソース ソフトウェアを使用すると、支払い手数料やサプライヤーの閉鎖について心配する必要はありませんが、オープンソース ソフトウェアをただ使用することはできないため、著作権の問題に注意してください。

ほとんどのオープンソース ソフトウェアでは、コア機能と新機能を少数の人々が開発しており、そのほとんどが欠陥を修正しています。ほとんどの場合、開発者は新しいフォークを開発するのではなく、既存のフォークを維持することを好みます。

オープンソース ソフトウェアにも管理構造があり、通常、最初にプロジェクトを提案した人がソフトウェアに関する最終決定権を持ち、個人ではなく一部の営利企業によって管理されます (これにより、より高い品質が保証されます)。たとえば、Android オープンソース ソフトウェアは Google によって管理されており、提出されたフォークとパッチは次のバージョン更新の内容を最終決定する権利を有します。

  • 貢献者: OSS に貢献する人。
  • 開発者: ソフトウェア プラットフォーム上でアプリケーションを開発する人。
  • 検証者: 変更要求が正しいかどうかをテストする人。
  • 承認者: これらの変更を大きなバージョンにマージするかどうかを決定する人であり、検証者は面接審査をレビューする必要があります。
  • プロジェクト リーダー: 個々のプロジェクトのエンジニアリングを監督します。

ソフトウェアの自由

  • プログラムをフリーランする

  • このプログラムがどのように動作するかを研究し、希望通りに計算できるようにプログラムを変更します (もちろん、ソース コードにアクセスできることが前提です)。

  • ソフトウェアのコピーを配布するためのコピーの無料再配布

  • 修正したバージョンのコピーを他の人に無料で配布します。

著作権

プロデューサーのみがコピーを作成し、それに基づいて新しい作品を作成する権利を持っていますが、他の人が作品のコピーを作成し、それを翻案することを許可することができます。プロデューサーは、これらの権限を課金によって他の人に与えたり、適応範囲を制限したりすることができます。これはプロデューサーに課せられた義務であり、何らかの報酬を得るのが通常であるためです。

コピーレフト

ただし、OSS の著作権声明では、フリー ソフトウェア ライセンスであるコピーレフトが使用されており、他者がコピーおよび翻案する権利を制限するものではなく、他者にそうする権限を与えています。ライセンスの内容には、ソースコードが利用可能である旨の記載と、翻案許可の範囲が含まれます。

投票

投票権を持つ人は最大でも 1 票を有することができ、投票権を持たない人は投票することができず、投票権を持ち、投票することを選択した人は投票を妨げられません。彼らは完全な選択肢を十分に持つ必要があります。選択; 投票結果は正しく数えられる必要があり、他人が改ざんすることはできません; 投票の総数は正しく追加され、改ざんすることはできません; ほとんどの場合、投票者の選択を知ることはできません。

電子投票にはデータの改ざんや偽造が容易に行われるなどのリスクがあります。

ソフトウェア開発ツール

ソフトウェアの職人技とクリーンなコード

書式設定やコメントなど、コードの清潔さに注意してください。

「ノー」と言う

常に上司や顧客のニーズに盲目的に同意する必要はありません。プログラマーはコードに精通しており、上司が起こり得る間違いを回避できるよう支援する必要があります。

間違いから学ぶ

Microsoft のベスト プラクティス

リビジョン管理システム

バージョン管理。

roll-back: バージョンのロールバック。

チェックアウト: 開発者はコードをプルダウンします。

チェックイン: 開発者は自分のリビジョンを送信します。

衝突: 2 人の人の提出物が衝突しました。

merge: メインブランチにマージします。

デイリービルド

1 日 1 回コードをビルドし、ソース コードをコンパイルしてリンクし、いくつかのテストを行って、翌日全員が最新バージョンを使用できることを確認します。

継続的インテグレーション

開発者は、1 日 1 回チェックインすることも推奨しています。

ビルド検証テスト

アサーションと単体テスト。

バグデータベース

以前のバグ記録、解決策、重大度、優先度、その他の情報を記録します。

戦争チームとバグトリアージ

リリース前に、運用チームはシステムが「リリースするのに十分な」ものであることを確認しました。正常に動作しているか、残っているバグの重大度などを確認します。

コードレビューとコーディングガイドライン

チームはお互いのコードを徹底的にレビューします。

グローバリゼーションとローカリゼーション

さまざまな言語およびスクリプトに対する差分処理。

ドキュメントジェネレーター

ドキュメントの生成。

おすすめ

転載: blog.csdn.net/jtwqwq/article/details/131073844