ソフトウェア工学とプログラム仕様

ショートカット: 違い、類似点、ジャカード類似性係数、参考文献。

ソフトウェア工学とプログラム仕様の違い

ソフトウェア工学 vs. プログラム仕様

フトウェア工学（ソフトウェアこうがく、Software engineering）は、コンピュータのプログラム、およびその作成行為であるプログラミングを対象とした工学である。. プログラム仕様（プログラムしよう、Program specification）は、プログラムに求められることを定義したものである。プログラムの設計図や開発者から見たユーザーマニュアルの元となる文書のような「非形式的」な形態の場合と、数学的に厳密に動作を定義する「形式的」な形態の場合がある。実際、最もよい仕様は既存のアプリケーションを理解して改善するために書かれたものであることが多いが、重要なソフトウェアは開発前に注意深く仕様を記述する必要がある。仕様は特に常に安定性が求められる外部インタフェースでは重要である。.

プログラム (コンピュータ)

ンピュータプログラム（英：computer programs）とは、コンピュータに対する命令（処理）を記述したものである。コンピュータが機能を実現するためには、CPUで実行するプログラムの命令が必要である。 コンピュータが、高度な処理を人間の手によらず遂行できているように見える場合でも、コンピュータは設計者の意図であるプログラムに従い、忠実に処理を行っている。実際には、外部からの割り込み、ノイズなどにより、設計者の意図しない動作をすることがある。また設計者が、外部からの割り込みの種類を網羅的に確認していない場合もある。.

ソフトウェア工学とプログラム (コンピュータ) · プログラム (コンピュータ)とプログラム仕様 · 続きを見る »

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

ウォーターフォール・モデルは、ソフトウェア工学では非常に古くからある、もっともポピュラーな開発モデル。.

ウォーターフォール・モデルとソフトウェア工学 · ウォーターフォール・モデルとプログラム仕様 · 続きを見る »

エクストリーム・プログラミング

トリーム・プログラミング、XP（extreme programming）は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。1999年に書籍『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』によって発表された。 XPは、軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、同種の開発手法のなかで代表的なものである。柔軟性の高い開発手法であるが、古典的には開発が進むにつれ変更コストは大きくなると言うことを前提に開発手法が構築されているのに対して、自動テストを導入するなど様々な対策をすることにより開発が進んでも変更コストが大きくならないような工夫を持ち込むことにより、変更に対する柔軟性を実現している。この変更コストが増大しないという前提が破綻すると、この手法も破綻する。 XPは比較的少人数の開発にもっとも適用しやすく、5つの価値と19の具体的なプラクティス（実践）が定義されている。XPはドキュメントよりもソースコードを、組織的開発の歯車となることよりも、個人の責任と勇気を重んじる人間中心の開発プロセスであるとしている。.

エクストリーム・プログラミングとソフトウェア工学 · エクストリーム・プログラミングとプログラム仕様 · 続きを見る »

ソースコード

青で示されているのが有効なコードである。 ソースコード（source code）とは、コンピュータプログラミング言語で書かれた、コンピュータプログラムである文字列（テキストないしテキストファイル）のことである。.

ソフトウェア工学とソースコード · ソースコードとプログラム仕様 · 続きを見る »

ソフトウェア

フトウェア（software）は、コンピューター分野でハードウェア（物理的な機械）と対比される用語で、何らかの処理を行うコンピュータ・プログラムや、更には関連する文書などを指す。ソフトウェアは、一般的にはワープロソフトなど特定の作業や業務を目的としたアプリケーションソフトウェア（応用ソフトウェア、アプリ）と、ハードウェアの管理や基本的な処理をアプリケーションソフトウェアやユーザーに提供するオペレーティングシステム (OS) などのシステムソフトウェアに分類される。.

ソフトウェアとソフトウェア工学 · ソフトウェアとプログラム仕様 · 続きを見る »

ソフトウェアテスト

フトウェアテスト（）は、コンピュータのプログラムから仕様にない振舞または欠陥（バグ）を見つけ出す作業のことである。ソフトウェアテストで見つかったプログラム中の欠陥を修正する作業をデバッグという。ソフトウェアテストに成功するとは、テストで欠陥が発見されるか、規定した試験項目にすべて合格するか、規定した品質目標に到達することである。目標とした品質には、規定した試験項目にすべて合格することもある。例えば、OS, プログラミング言語では、仕様を満たしているかどうかの適合試験を規定している。ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。ソフトウェアに仕様にない振舞がないことを保証する作業を証明といい、証明用のシステム、証明しやすい言語も多数存在している。本項では動的なソフトウェアテストを中心に扱う。.

ソフトウェアテストとソフトウェア工学 · ソフトウェアテストとプログラム仕様 · 続きを見る »

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

フトウェアドキュメンテーションとは、コンピュータのソフトウェアに付随する文書、またはそのような文書を作成することを意味する。類似の用語としてソースコードドキュメンテーションがある。 仕様書を含むか、含まないかは立場により異なる。仕様書は設計/実装のために事前または事後に作成する文書である。ドキュメンテーションは開発中あるいは既に完成したソフトウェアに付随する文書を指す訳ではない。ソフトウェアに関する文書には作成する順番があるとは限らない。図からソフトウェアを生成する場合もあれば、ソフトウェアから図を生成する場合もある。ソフトウェアから仕様を生成する場合もあれば、仕様からソフトウェアを生成する場合もある。.

ソフトウェアドキュメンテーションとソフトウェア工学 · ソフトウェアドキュメンテーションとプログラム仕様 · 続きを見る »

ソフトウェア開発

フトウェア開発（ソフトウェアかいはつ、Software Development）とは、ユーザーのニーズやマーケティング上の目標をソフトウェア製品に変換する作業である。ソフトウェア開発には、ソフトウェア工学の研究的側面とソフトウェア製品を開発するマーケティング的側面が含まれていると言われることがある。ソフトウェア製品のマーケティング活動そのものは、必ずしも新商品開発とは結びつかない。顧客の期待を満足させるべく開発されたソフトウェア製品の成功/失敗の責任が工学的側面にあるのかマーケティング的側面にあるのかを判別するのは、多くの場合困難である。そのため、ソフトウェア開発全体として工学的側面とマーケティング的側面を共に理解し、それらの協調を促進することが重要である。工学とマーケティングの両方の側面をまとめ、バランスをとるのは、プロジェクトマネージャなどと呼ばれる立場の人である。 マーケティングとの関わりはソフトウェア要求分析としても知られている。ソフトウェア開発はクライアントが必要とするもの以上の機能を開発しようとしたり、逆に妥協しようとしたりする。そのため、ソフトウェア開発は通常の工学/技術とは関連付けられていなかった各種プロセス（市場調査、人材登用、リスクマネジメント、知的財産権、予算、危機管理など）まで取り込もうとする場合がある。その場合、ソフトウェア開発は Business Development と呼ばれる領域ともオーバーラップすることになる。 Alan M. Davis は著書 "Great Software Debates" の章 "Requirements" の節 "The Missing Piece of Software Development" で次のように述べている.

ソフトウェア工学とソフトウェア開発 · ソフトウェア開発とプログラム仕様 · 続きを見る »

要求分析

要求分析（ようきゅうぶんせき、Requirements Analysis）とは、システム工学やソフトウェア工学において新たなシステムやシステム更新に際しての調査/定義に関わる工程を指す。要求分析はシステム設計工程でも重要な部分であり、アナリストやシステムエンジニア/ソフトウェア開発者が顧客の必要性や要求を特定する工程である。顧客の要求が特定されたら、システム設計者がその解決策を設計することになる。.

ソフトウェア工学と要求分析 · プログラム仕様と要求分析 · 続きを見る »

数学

数学（すうがく、μαθηματικά, mathematica, math）は、量（数）、構造、空間、変化について研究する学問である。数学の範囲と定義については、数学者や哲学者の間で様々な見解がある。.

ソフトウェア工学と数学 · プログラム仕様と数学 · 続きを見る »