ソフトウェア

ソフトウェアドキュメンテーション

ソフトウェアドキュメンテーションとは、コンピュータのソフトウェアに付随する文書、またはそのような文書を作成することを意味する。類似の用語としてソースコードドキュメンテーションがある。
プログラム仕様 仕様書とは異なる。仕様書は設計/実装のために事前に作成される文書だが、ここでいうドキュメンテーションは開発中あるいは既に完成したソフトウェアに付随する文書である。
ドキュメンテーションはソフトウェア開発の重要な部分を占めているが、見過ごされることが多い。ドキュメンテーションは以下のように分類される:
アーキテクチャ/設計 - ソフトウェアの概要。外部環境との関係、設計原則などが記述される文書。
技術 - コード、アルゴリズム、インタフェース、Application Programming Interface APIなどの文書。

『フリー百科事典ウィキペディア日本語版』 2009/01/01/24/09、URL: http://ja.wikipedia.org/

ソフトウェアテスト

ホワイトボックステストとは、プログラム (コンピュータ) プログラムの構造に着目したソフトウェアテストのことである。着目する構造には命令や分岐などがあり、注目した構造に対してどれだけの割合の部分を実行できたかをコード網羅率 網羅率で表す。
1: int abs(int x){
2: if(x<0){
3: x=-x;
5: return x;
命令網羅基準を用いてテストを行う場合は、すべての命令を実行すればよい。上記のabs関数では、x -1 を用いてテストすれば命令網羅基準に従ってテストできたことになるかも。
分岐網羅基準を用いてテストを行う場合は、すべての分岐において、すべての分岐の方向を実行すればよい。上記のabs関数では、x=-1、x=0を用いてそれぞれテストすれば、分岐網羅基準にしたがってテストできたことになる。

『フリー百科事典ウィキペディア日本語版』 2009/01/01/21/09、URL: http://ja.wikipedia.org/

ソフトウェアコンポーネント

ソフトウェアコンポーネント（Software Componentry）は、ソフトウェア工学の一分野である。ソフトウェアオブジェクト、ソフトウェアアーキテクチャ、ソフトウェアフレームワーク、デザインパターン (ソフトウェア) デザインパターンなどに基づいた分野であり、オブジェクト指向プログラミングおよび設計の理論を活用している。ソフトウェアコンポーネントとは、ハードウェアの電子部品（electronic component）からの発想であり、モジュールの互換性と信頼性を重視していることを意味する。
ソフトウェアコンポーネントは、事前に定義されたサービスを提供するシステム構成要素であり、コンポーネント間で通信することができる。Clemens Szyperski と David Messerschmitt は、ソフトウェアコンポーネントが備えるべき5つの基準を以下のように定義した:

『フリー百科事典ウィキペディア日本語版』 2009/01/01/15/09、URL: http://ja.wikipedia.org/

ソフトウェアエージェント

ソフトウェアエージェント（Software Agent）とは、ユーザーや他のソフトウェアとの仲介(Agency)的関係語源はラテン語の ”agere”（～の代行をする協定）から。において動作するソフトウェアを説明する計算機科学上の抽象概念であり、論理的モデルである。そのような代行的行動は行動の適切さの判断や時期の判断の権限を暗示している。すなわち、エージェントの動作はタスクとして厳密に管理されないが、自分自身が勝手に起動することはない。
関連する派生概念として、知的エージェント（人工知能的要素である学習や推論を取り入れたもの）、自律エージェント（目的を達成するための方法を自律的に更新できるもの）、マルチエージェントシステム（単体では目的を達成できず、互いに通信する分散エージェント群）、モバイルエージェント（ネットワーク上で自身を実行するプロセッサを乗り換えていくことができるエージェント）などがある。

『フリー百科事典ウィキペディア日本語版』 2009/01/01/08/09、URL: http://ja.wikipedia.org/

ソフトウェアアーキテクチャ

ソフトウェアアーキテクチャ（Software Architecture）は、ソフトウェアコンポーネント、それらの外部特性、またそれらの相互関係から構成される。また、この用語はシステムのソフトウェアアーキテクチャの文書化を意味することもある。ソフトウェアアーキテクチャの文書は開発依頼主とのコミュニケーションを容易にするもので、概要レベルの設計に関する早期の決定を促し、プロジェクト間でのコンポーネントとパターンの設計を再利用することを可能にする
”IEEE 1471 ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software-Intensive Systems”（ソフトウェアシステムのアーキテクチャ記述のための指針）は、ソフトウェアアーキテクチャの領域での世界初の標準であり、最近 ISO によって ”IEEE 1471 ISO/IEC DIS 25961” として採用された。

『フリー百科事典ウィキペディア日本語版』 2009/01/01/07/09、URL: http://ja.wikipedia.org/

ソフトウェア開発

マーケティングとの関わりは要求分析 ソフトウェア要求分析としても知られているWon Kim: “On Assuring Software Quality and Curbing Software Development Cost”, in Journal of Object Technology, vol. 5, no. 6, July-August 2006, pp. 35-42 http://www.jot.fm/issues/issue_2006_07/column5。ソフトウェア開発はクライアントが必要とするもの以上の機能を開発しようとしたり、逆に妥協しようとしたりする。そのため、ソフトウェア開発は通常の工学/技術とは関連付けられていなかった各種プロセス（市場調査、人材登用、リスクマネジメント、知的財産権、予算、危機管理など）まで取り込もうとする場合がある。その場合、ソフトウェア開発は Business Development と呼ばれる領域ともオーバーラップすることになる。
Alan M. Davis は著書 ”"Great Software Debates"” の章 ”"Requirements"” の節 ”"The Missing Piece of Software Development"” で次のように述べている:

『フリー百科事典ウィキペディア日本語版』 2008/12/12/31/08、URL: http://ja.wikipedia.org/

ソフトウェア危機

ソフトウェア危機（Software Crisis）とは、ソフトウェア工学がまだ十分に確立していなかった頃、よく使われた言葉である。この言葉は、コンピュータの急激な高性能化によってコンピュータ上のシステムが扱う問題が益々複雑化することによる影響を表したものである。基本的にソフトウェア危機は、正しく、可読性が高く、形式的検証 検証可能なコンピュータプログラムを書くことの困難さから発した考え方である。ソフトウェア危機の根本は、複雑性と予測と変化である。
相反する要求は常にソフトウェアの開発過程を妨げてきた。例えば、ユーザーは多大な機能を要求するが、顧客はソフトウェアに支払う対価と開発期間をなるべく最小にしたがることが多い。

『フリー百科事典ウィキペディア日本語版』 2008/11/11/13/08、URL: http://ja.wikipedia.org/

ソフトウェアファクトリー

標準化されたコンポーネント、特殊化されたスキルセット、並行プロセス、予測可能でスケーラブルな一貫した品質といった製造業的基盤にならって、ソフトウェア開発のレベルを高度化することがソフトウェアファクトリーの目的である。自動車製造の工業化によって生産性が向上して低価格で高品質の製品ができるようになったように、ソフトウェア開発工程の工業化でも同様の利点が期待されている。ソフトウェアファクトリーはソフトウェア開発工数を削減する手法として注目されている。概念的には、ソフトウェアファクトリーは、ドメインごとに事前に作られた標準機能を探し出す方法論である。
ソフトウェアファクトリーは Software Manufacturing（ソフトウェア製造）プロセスとそれを支える生産性ツールから構成される。

『フリー百科事典ウィキペディア日本語版』 2008/11/11/03/08、URL: http://ja.wikipedia.org/

ソフトウェア保守

ソフトウェア保守またはソフトウェアメンテナンス（Software maintenance）とは、ソフトウェア工学において既存のソフトウェアを改良・最適化していくと共にバグを修正していくプロセスを意味する。ソフトウェア保守はソフトウェア製品ライフサイクルにおける主要なプロセスの一部であり、ソフトウェアデプロイメント ソフトウェアの実際の現場への投入後に行われる。ソフトウェア保守工程では、実際の使用で発見された問題点やバグを修正すると共に、そのソフトウェアのユーザビリティや可用性を改善するための機能追加も行う。
ソフトウェア保守プロセスは、日本工業規格 JIS規格　日本工業規格 JIS X 0160（ソフトウェア・ライフサイクル・プロセス）で規定されたプロセスで、日本工業規格 JIS X 0161:2008（ソフトウェアライフサイクルプロセス－保守）で詳細が規定されている。

『フリー百科事典ウィキペディア日本語版』 2008/09/09/29/08、URL: http://ja.wikipedia.org/

ソフトウェア開発工程

ソフトウェア開発工程（Software Development Process）とは、ソフトウェア製品の開発の構造を意味する。ソフトウェアライフサイクル、ソフトウェア開発プロセス、ソフトウェアプロセスもほぼ同義語である。開発工程にはいくつかのモデルがあり、開発工程内の各種タスク・活動のための手法を提案している。
ソフトウェア開発組織の巨大化とともに開発工程に関する方法論が提案されるようになってきた。アメリカでは軍需での契約を獲得する条件としてプロセスモデルに基づいた評価が行われるため、それが方法論の発達を促したとも言える。ISO 12207 はプロジェクトのライフサイクルを選択・実装・監視する手法に関する標準規格である。
能力成熟度モデル統合 能力成熟度モデル(CMM) は主要なモデルの1つである。独自のアセスメントにより組織が自身で定義したプロセスにどれだけ忠実に従っているかを測る。このとき、そのプロセスの品質そのものやソフトウェア製品の品質は関与しない。CMM は徐々に拡張され能力成熟度モデル統合(CMMI) となった。ISO 9000 は形式的に構成されたプロセスとその文書に関する標準規格である。

『フリー百科事典ウィキペディア日本語版』 2008/09/09/15/08、URL: http://ja.wikipedia.org/