ブラウザよりも高速アクセス！
57 関係: 反復型開発、実体関連モデル、実装、形式仕様記述、形式手法、ペトリネット、モデル (自然科学)、モデル駆動型アーキテクチャ、モデル駆動工学、ユーザーエクスペリエンス、ラショナル統一プロセス、リファクタリング (プログラミング)、トップダウン設計とボトムアップ設計、プロトタイピング、プログラミングパラダイム、プログラム仕様、プロジェクト、プロジェクトマネジメント、プロセスモデル、テスト駆動開発、アビオニクス、アジャイルソフトウェア開発、インターフェース、ウォーターフォール・モデル、エクストリーム・プログラミング、オートマトン、シックス・シグマ、システム工学、システム開発ライフサイクル、スパイラルモデル、ソフトウェア、ソフトウェア保守、ソフトウェアプロトタイピング、ソフトウェアテスト、ソフトウェアデプロイメント、ソフトウェアフレームワーク、ソフトウェアドキュメンテーション、ソフトウェアアーキテクチャ、ソフトウェアクリーンルーム、ソフトウェア開発、ソフトウェア開発方法論、ソフトウェア構成管理、共通フレーム、B-Method、統計学、要求分析、要求管理、能力成熟度モデル統合、ISO 9000、ISO/IEC 12207、...、ISO/IEC 15504、Object Constraint Language、Rapid Application Development、Vモデル、VDM、Z言語、有限オートマトン。 インデックスを展開 (7 もっと) »
反復型開発
反復型開発（はんぷくがたかいはつ、Iterative and Incremental Development）とは、より古典的なウォーターフォール・モデルの弱点を克服すべく開発されたソフトウェア開発工程の手法である。反復型開発の中でもRADとDSDMは、よく知られたフレームワークである。反復型開発は、エクストリーム・プログラミングや他のアジャイルソフトウェア開発フレームワークの基本的要素でもある。.
新しい！!: ソフトウェア開発工程と反復型開発 · 続きを見る »
実体関連モデル
チェンの記法を使った実体関連図の例 実体関連モデル（じったいかんれんモデル、Entity-relationship Model, ERM）は、概念的データモデルの高レベルな記述を可能とするモデルの一種である。また、実体関連モデルによって具体的なシステムのデータモデルを図で表現したものを実体関連図（Entity-relationship Diagram, ERD）あるいはER図と呼ぶ。本項ではピーター・チェンの1975年の論文で提唱された技法を中心に解説する for entity–relationship modeling.
新しい！!: ソフトウェア開発工程と実体関連モデル · 続きを見る »
実装
実装（じっそう、implementation）とは、何らかの機能（や仕様）を実現するための（具体的な）装備や方法のこと。.
新しい！!: ソフトウェア開発工程と実装 · 続きを見る »
形式仕様記述
形式仕様記述（けいしきしようきじゅつ、formal specification）とは形式手法のひとつで、何らのシステムなどについて、その性質などの仕様を形式的に記述する手法や、そういった手法による仕様の記述である。 形式的な仕様を与えることにより、対象システムが仕様に照らして正しいかどうかを形式的に判定することが可能となる(形式的検証)。また、仕様策定の工程で仕様の不整合を検出することが可能となり、実装工程のような開発の後半での仕様不備発覚、それに伴う手戻り(多大なコストを要する場合が多い)を防ぐという利点がある。他の使われ方として、仕様から設計、設計から実装へと段階的に検証可能なステップを踏んで詳細化し、開発工程で不具合を作りこむのを防ぐ。 設計（や実装）の「正当性」はそれ自身だけで確認できないという点が重要である。正当性は与えられた仕様に照らして初めて検証可能であり、形式仕様記述が解決すべき問題を正しく記述できるかどうかは別の問題である。これもまた困難な問題であり、非形式的な実際の問題を抽象化された形式的仕様記述で正しく記述する問題に帰着する。そして、そのような抽象化は形式的証明が不可能である。しかし、仕様が表現することを期待されている特性に関わる定理を証明することによって仕様記述を検証することは可能である。もし検証結果が正しければ、それらの定理は仕様記述者の仕様記述および根底にある問題領域との関係への理解を深める。検証結果が正しくない場合、その仕様は元となっている問題領域を正しく反映しているとは言えないので、仕様記述者はさらに理解を深めて仕様記述を改訂することになるだろう。.
新しい！!: ソフトウェア開発工程と形式仕様記述 · 続きを見る »
形式手法
Z言語を使った形式仕様記述の例 形式手法（けいしきしゅほう、formal methods）は、ソフトウェア工学における数学を基盤としたソフトウェアおよびハードウェアシステムの仕様記述、開発、検証の技術である。ソフトウェアおよびハードウェア設計への形式手法の適用は、他の工学分野と同様、適切な数学的解析を行うことで設計の信頼性と頑健性が向上するという予想によって動機付けられている。 形式手法は理論計算機科学の様々な成果を基盤として応用したものであり、数理論理学、形式言語、オートマタ理論、プログラム意味論、型システム、代数的データ型などを活用して、ソフトウェアおよびハードウェアの仕様記述とその検証を行う。.
新しい！!: ソフトウェア開発工程と形式手法 · 続きを見る »
ペトリネット
ペトリネット ペトリネット（Petri net）とは、カール・アダム・ペトリが1962年に発表した離散分散システムを数学的に表現する手法である。モデリング言語としては分散システムを注釈付の有向2部グラフとして視覚的に表現する。.
新しい！!: ソフトウェア開発工程とペトリネット · 続きを見る »
モデル (自然科学)
自然科学におけるモデルは、理論を説明するための簡単な具体的なもの。特に幾何学的な図形を用いた概念や物体。.
新しい！!: ソフトウェア開発工程とモデル (自然科学) · 続きを見る »
モデル駆動型アーキテクチャ
モデル駆動型アーキテクチャ（モデルくどうがたアーキテクチャ、Model-Driven Architecture、MDA）とは、Object Management Group (OMG) が2001年に公式に発表したソフトウェア設計手法である。MDA はソフトウェアシステムにおけるモデル駆動工学サポートを意図したものである。.
新しい！!: ソフトウェア開発工程とモデル駆動型アーキテクチャ · 続きを見る »
モデル駆動工学
モデル駆動工学（モデルくどうこうがく、Model-Driven Engineering、MDE）とは、アルゴリズム的な概念よりも、ドメインモデルの作成と利用を中心とするソフトウェア開発方法論の一種である。ドメインモデルとは、特定の適応領域についての知識や活動を抽象化して表現したものである。 モデル駆動工学(以下、MDE)は、工学的ライフサイクルを通して、モデルをシステム的に利用する工学手法を意味する。また、MDEの適用範囲は、ソフトウェア、システム、データ工学などである。MDEでは、モデルを第一に考える。.
新しい！!: ソフトウェア開発工程とモデル駆動工学 · 続きを見る »
ユーザーエクスペリエンス
ユーザーエクスペリエンス（）とは、人工物（製品、システム、サービスなど）の利用を通じてユーザーが得る経験である。しばしば「UX」と略される。「ユーザー経験」「ユーザー体験」などと訳される。 よいユーザーエクスペリエンスを達成するために、ユーザビリティ工学、インタラクションデザイン、ユーザー中心設計 (UCD) あるいは人間中心設計 (HCD) などが実践される。.
新しい！!: ソフトウェア開発工程とユーザーエクスペリエンス · 続きを見る »
ラショナル統一プロセス
ラショナル統一プロセス (Rational Unified Process; RUP) とは、IBM社ラショナルブランドのオブジェクト指向型ソフトウェア開発プロセス、およびその製品のことを指す。RUPでは、以下の6つのベストプラクティスが定められている。.
新しい！!: ソフトウェア開発工程とラショナル統一プロセス · 続きを見る »
リファクタリング (プログラミング)
リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。また、いくつかのリファクタリング手法の総称としても使われる。ただし、十分に確立された技術とはいえず、また「リファクタリング」という言葉に厳密な定義があるわけではない。.
新しい！!: ソフトウェア開発工程とリファクタリング (プログラミング) · 続きを見る »
トップダウン設計とボトムアップ設計
トップダウン設計とボトムアップ設計（トップダウンせっけいとボトムアップせっけい）とは、設計戦略である。トップダウンとボトムアップは、情報や知識の順序付け戦略であり、様々な分野で使われる用語である。この記事では、主にソフトウェア工学での用法について解説する。.
新しい！!: ソフトウェア開発工程とトップダウン設計とボトムアップ設計 · 続きを見る »
プロトタイピング
プロトタイピング（Prototyping）とは、実働するモデル（プロトタイプ）を早期に製作する手法およびその過程を意味する。その目的は、設計を様々な観点から検証する、機能やアイデアを形にすることでユーザーから早めにフィードバックを得るなど、様々である。プロトタイピングはシステム設計工程の一部として組み込まれることも多く、それによってプロジェクトのリスクと費用を低減させると考えられている。反復型開発では1つ以上のプロトタイプが作られ、欠陥や問題が徐々に解決されていく。プロトタイプの改善が十分なされ、機能/堅牢性/製造の容易さといった設計目標に達したとき、製品としての製造が可能となる。.
新しい！!: ソフトウェア開発工程とプロトタイピング · 続きを見る »
プログラミングパラダイム
プログラミングパラダイム (programming paradigm)とは、プログラミングにおけるパラダイムである。.
新しい！!: ソフトウェア開発工程とプログラミングパラダイム · 続きを見る »
プログラム仕様
プログラム仕様（プログラムしよう、Program specification）は、プログラムに求められることを定義したものである。プログラムの設計図や開発者から見たユーザーマニュアルの元となる文書のような「非形式的」な形態の場合と、数学的に厳密に動作を定義する「形式的」な形態の場合がある。実際、最もよい仕様は既存のアプリケーションを理解して改善するために書かれたものであることが多いが、重要なソフトウェアは開発前に注意深く仕様を記述する必要がある。仕様は特に常に安定性が求められる外部インタフェースでは重要である。.
新しい！!: ソフトウェア開発工程とプログラム仕様 · 続きを見る »
プロジェクト
プロジェクト（）は、何らかの目標を達成するための計画を指す。小さな目標の達成のためのものではなく、大きな目標を集団で実行するものを指すことがある。その計画の実現のための個々のタスク（仕事）の実行までを含めて指すこともある。 既存の組織の枠をはずし、各組織から臨時に人を集めて実行する集団をプロジェクトと呼ぶこともある。これらは、英語でも同様である。ソフトウェアの設計では、統合設計環境における設計単位をプロジェクトと呼ぶ。.
新しい！!: ソフトウェア開発工程とプロジェクト · 続きを見る »
プロジェクトマネジメント
プロジェクトマネジメント（プロジェクト管理、）とはプロジェクトを成功裏に完了させることを目指して行われる活動のことである。これにはプロジェクトを構成する各活動の計画立案、日程表の作成、および進捗管理が含まれる。 システム開発を成功させるためには、プロジェクトを適切に管理することが求められる。.
新しい！!: ソフトウェア開発工程とプロジェクトマネジメント · 続きを見る »
プロセスモデル
プロセスモデル（process model）とは、何らかのプロセス（過程、工程）の模型(モデル)である。 化学工学はプロセス産業と呼ぶように、プロセスモデルが処理モデルである。 ビジネスプロセスモデルとは、企業の仕事の仕方のモデルである。 コンピュータでは、処理方法がプロセスモデルである。並列処理の方式などがある。 ソフトウェアプロセスは、ソフトウェアを設計し、利用し、廃棄する流れの一つの視点を提供するものであり、人の作業とコンピュータの処理を含む。 コレット・ローランドはプロセスモデルを次のように定義しているC.
新しい！!: ソフトウェア開発工程とプロセスモデル · 続きを見る »
テスト駆動開発
テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。近年はビヘイビア駆動開発へと発展を遂げている。.
新しい！!: ソフトウェア開発工程とテスト駆動開発 · 続きを見る »
アビオニクス
アビオニクス（Avionics, エイヴィオニクス）とは、航空機に搭載され飛行のために使用される電子機器のこと。.
新しい！!: ソフトウェア開発工程とアビオニクス · 続きを見る »
アジャイルソフトウェア開発
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) などがある。 非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している。.
新しい！!: ソフトウェア開発工程とアジャイルソフトウェア開発 · 続きを見る »
インターフェース
インターフェース (interface) はインタフェイス、インターフェイスとも書き、英語で界面や接触面、中間面などといった意味を持ち、転じてコンピュータと周辺機器の接続部分を表すようになった。さらに、ユーザーインターフェースなどのように、人間と自動機械との間の複雑な操作をする手順・規則との意味にも使われる。.
新しい！!: ソフトウェア開発工程とインターフェース · 続きを見る »
ウォーターフォール・モデル
ウォーターフォール・モデルは、ソフトウェア工学では非常に古くからある、もっともポピュラーな開発モデル。.
新しい！!: ソフトウェア開発工程とウォーターフォール・モデル · 続きを見る »
エクストリーム・プログラミング
トリーム・プログラミング、XP（extreme programming）は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。1999年に書籍『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』によって発表された。 XPは、軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、同種の開発手法のなかで代表的なものである。柔軟性の高い開発手法であるが、古典的には開発が進むにつれ変更コストは大きくなると言うことを前提に開発手法が構築されているのに対して、自動テストを導入するなど様々な対策をすることにより開発が進んでも変更コストが大きくならないような工夫を持ち込むことにより、変更に対する柔軟性を実現している。この変更コストが増大しないという前提が破綻すると、この手法も破綻する。 XPは比較的少人数の開発にもっとも適用しやすく、5つの価値と19の具体的なプラクティス（実践）が定義されている。XPはドキュメントよりもソースコードを、組織的開発の歯車となることよりも、個人の責任と勇気を重んじる人間中心の開発プロセスであるとしている。.
新しい！!: ソフトウェア開発工程とエクストリーム・プログラミング · 続きを見る »
オートマトン
ートマトン (単数形: automaton, 複数形: オートマタ（automata ）) とは、自動人形などとも呼ばれる「オートマタ」と同じ語であるが、計算理論において、計算モデルに関して有限オートマトンなどの総称として使われる。また特に「オートマトン理論」と呼ばれる分野では、計算機械のうち計算可能性の点でチューリングマシンよりも制限されているものを特に指して言うこともある。.
新しい！!: ソフトウェア開発工程とオートマトン · 続きを見る »
シックス・シグマ
ックス・シグマ（Six Sigma, Lean Six Sigma）とは、1980年代に米モトローラが開発した品質管理手法、または経営手法である。その適用範囲は、主に製造業が中心であるが、製造業の製造部門に留まらず、営業部門、企画部門などの間接部門への適用、更にはサービス業などの非製造業への適用も多い。統計分析手法、品質管理手法を体系的に用いて製品製造工程などの各種プロセスの分析を行い、原因の特定やそれへの対策を行って、不良率の引き下げや顧客満足度の向上などをしていく。.
新しい！!: ソフトウェア開発工程とシックス・シグマ · 続きを見る »
システム工学
テム工学（システムこうがく、systems engineering）とは、システムの設計、制御、および効率などを研究する学問（工学）である。ここでの「システム」の定義としては、システムの記事（システム#JIS Z 8115）などを参照のこと。工学として応用される実社会の具体例としては、工業プラントやロボットから、コンピュータを用いたシミュレーションゲームや人工補助脳（ロボットスーツに搭載されるもの）、会社組織や行政機関に至るまで、きわめて広範囲に及ぶ。システム工学は、個々の要素からシステムを合成するということと、複雑なシステムを解析するという、大きく分けて2つの目的がある。なおシステム科学も参照のこと。.
新しい！!: ソフトウェア開発工程とシステム工学 · 続きを見る »
システム開発ライフサイクル
テム開発ライフサイクル（英: Systems Development Life Cycle、SDLC）とは、システム開発、特にコンピュータシステム開発のモデルまたは方法論である。なお、SDLCは Software Development Life Cycle の略とされることもあるし、SLC と略されることもある。SOAの発展と共に、コンピュータシステムは複雑化し、複数のソフトウェアベンダーが提供するシステム群を相互に連結するようになってきた。これを管理するため、ウォーターフォール・モデル、スパイラルモデル、反復型開発、ソフトウェアプロトタイピングなど、様々なシステム開発ライフサイクル (SDLC) モデルが考案されてきた。 中でもウォーターフォール・モデルは最も古く、SDLCそのものと見なされてきた。各工程の出力が次の工程の入力になる形で連なっている。この流れは基本的に同じような形だが、工程数は個々のモデルによって異なり、4つから7つのものがある。決定的に正しいモデルは存在しないが、各工程にはおおよそ以下のような特徴がある。; プロジェクト計画立案、実現可能性調査、プロジェクト開始; 要求仕様収集とシステム分析; システム設計; 構築; テスト; インストール、実装、配備; 保守、運用 最近では、厳密なウォーターフォール・モデルをシステム開発に適用する例は少なくなりつつあり、様々なSDLCの方法論が考案され適用されている。SDLCの考え方は古いという者もいるが、用語としては今もよく使われている。.
新しい！!: ソフトウェア開発工程とシステム開発ライフサイクル · 続きを見る »
スパイラルモデル
パイラルモデル（Spiral Model）とは、トップダウン設計とボトムアップ設計の長所を生かしたソフトウェア開発工程のモデルであり、設計とプロトタイピングを繰り返して開発していく手法である。.
新しい！!: ソフトウェア開発工程とスパイラルモデル · 続きを見る »
ソフトウェア
フトウェア（software）は、コンピューター分野でハードウェア（物理的な機械）と対比される用語で、何らかの処理を行うコンピュータ・プログラムや、更には関連する文書などを指す。ソフトウェアは、一般的にはワープロソフトなど特定の作業や業務を目的としたアプリケーションソフトウェア（応用ソフトウェア、アプリ）と、ハードウェアの管理や基本的な処理をアプリケーションソフトウェアやユーザーに提供するオペレーティングシステム (OS) などのシステムソフトウェアに分類される。.
新しい！!: ソフトウェア開発工程とソフトウェア · 続きを見る »
ソフトウェア保守
フトウェア保守またはソフトウェアメンテナンス (software maintenance) とは、ソフトウェア工学において既存のソフトウェアを改良・最適化していくと共にバグを修正していくプロセスを意味する。ソフトウェア保守はソフトウェア製品ライフサイクルにおける主要なプロセスの一部であり、ソフトウェアの実際の現場への投入後に行われる。ソフトウェア保守工程では、実際の使用で発見された問題点やバグを修正すると共に、そのソフトウェアのユーザビリティや可用性を改善するための機能追加も行う。.
新しい！!: ソフトウェア開発工程とソフトウェア保守 · 続きを見る »
ソフトウェアプロトタイピング
フトウェアプロトタイピング（英: Software Prototyping）とは、将来完成する予定のソフトウェアの不完全なモデル（プロトタイプ）を作成することおよびその過程を意味する。プロトタイプは完成品についてのイメージをユーザーに抱かせ、顧客がそのプログラムを評価することができる。これにはいくつかの利点がある。設計者や実装者はプロジェクトの初期段階でユーザーからフィードバックを得ることができる。顧客や契約者はそのソフトウェアがソフトウェア仕様に適合しているかどうかを比較検討できる。また、ソフトウェア開発者はプロジェクトの工数を正確に見積もることが可能となり、要求されている期限などが（人員や開発設備などに照らして）妥当かどうかを検討できる。プロトタイピングをどの程度完璧にすべきかやその製作技法に関しては、1970年代初期から議論を呼んでいるTodd Grimm: The Human Condition: A Justification for Rapid Prototyping.
新しい！!: ソフトウェア開発工程とソフトウェアプロトタイピング · 続きを見る »
ソフトウェアテスト
フトウェアテスト（）は、コンピュータのプログラムから仕様にない振舞または欠陥（バグ）を見つけ出す作業のことである。ソフトウェアテストで見つかったプログラム中の欠陥を修正する作業をデバッグという。ソフトウェアテストに成功するとは、テストで欠陥が発見されるか、規定した試験項目にすべて合格するか、規定した品質目標に到達することである。目標とした品質には、規定した試験項目にすべて合格することもある。例えば、OS, プログラミング言語では、仕様を満たしているかどうかの適合試験を規定している。ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。ソフトウェアに仕様にない振舞がないことを保証する作業を証明といい、証明用のシステム、証明しやすい言語も多数存在している。本項では動的なソフトウェアテストを中心に扱う。.
新しい！!: ソフトウェア開発工程とソフトウェアテスト · 続きを見る »
ソフトウェアデプロイメント
フトウェアデプロイメント（英: Software deployment）とは、ソフトウェアシステムを利用可能にする活動全般を指す用語である。デプロイメント（Deployment）とは「展開、配備、配置」などの意。 一般にデプロイメントは相互に関連したいくつかの活動から構成される。それらの活動は、ソフトウェア開発者の側で行われるものもあれば、顧客側で行われるものも、あるいは両者が共同で行うものもある。ソフトウェアは非常に様々なものがあり、ソフトウェアデプロイメントのプロセスやプロシージャを正確に定義することは難しい。従って、ソフトウェアデプロイメントは、個々の事情や要求に応じてカスタマイズされる「汎用プロセス」と理解されるべきである。ソフトウェアデプロイメントに含まれる個々の活動については以下で解説する。 また、アプリケーションサーバにおいて、各種アプリケーションモジュールを実際に使用される環境に配備することをアプリケーションデプロイメントと呼ぶ。.
新しい！!: ソフトウェア開発工程とソフトウェアデプロイメント · 続きを見る »
ソフトウェアフレームワーク
フトウェアフレームワーク（英: software framework）とは、プログラミングにおいて、一般的な機能をもつ共通コードをユーザーが選択的に上書きしたり特化させたりすることで、ある特定の機能をもたせようとする抽象概念のことである。単にフレームワークとも呼ばれる。 ソフトウェアフレームワークは、はっきり定義されたAPIを持ち、具体的な実装を再利用可能な形で隠蔽しているという点でライブラリとよく似ている。しかし、ライブラリでは呼び出し側がプログラム全体の制御構造を指定できないが、フレームワークでは可能である。この制御の反転がソフトウェアフレームワークの特徴である。.
新しい！!: ソフトウェア開発工程とソフトウェアフレームワーク · 続きを見る »
ソフトウェアドキュメンテーション
フトウェアドキュメンテーションとは、コンピュータのソフトウェアに付随する文書、またはそのような文書を作成することを意味する。類似の用語としてソースコードドキュメンテーションがある。 仕様書を含むか、含まないかは立場により異なる。仕様書は設計/実装のために事前または事後に作成する文書である。ドキュメンテーションは開発中あるいは既に完成したソフトウェアに付随する文書を指す訳ではない。ソフトウェアに関する文書には作成する順番があるとは限らない。図からソフトウェアを生成する場合もあれば、ソフトウェアから図を生成する場合もある。ソフトウェアから仕様を生成する場合もあれば、仕様からソフトウェアを生成する場合もある。.
新しい！!: ソフトウェア開発工程とソフトウェアドキュメンテーション · 続きを見る »
ソフトウェアアーキテクチャ
フトウェアアーキテクチャ（Software Architecture）は、ソフトウェアコンポーネント、それらの外部特性、またそれらの相互関係から構成される。また、この用語はシステムのソフトウェアアーキテクチャの文書化を意味することもある。ソフトウェアアーキテクチャの文書は開発依頼主とのコミュニケーションを容易にするもので、概要レベルの設計に関する早期の決定を促し、プロジェクト間でのコンポーネントとパターンの設計を再利用することを可能にする。.
新しい！!: ソフトウェア開発工程とソフトウェアアーキテクチャ · 続きを見る »
ソフトウェアクリーンルーム
フトウェアクリーンルーム（Cleanroom Software Engineering）とは、検証可能な信頼性を保ったソフトウェア開発工程のモデルの1つである。クリーンルーム手法はIBMにてハーラン・ミルズらが開発した。クリーンルーム手法の主眼はバグ除去よりもバグ予測にある。この名称は集積回路の製造工程で使われるクリーンルームが語源であり、欠陥を防ぐという目的の類似性から使われている。著作権や特許の侵害を防ぐクリーンルーム設計の開発とは関係しない。 クリーンルーム手法は1980年代末ごろから使われ始めた。1990年代初めには実証プロジェクトが軍関係で行われた。最近では、CSPで表現された仕様による自動検証機能をクリーンルーム手法に組み合わせる試みがなされている。.
新しい！!: ソフトウェア開発工程とソフトウェアクリーンルーム · 続きを見る »
ソフトウェア開発
フトウェア開発（ソフトウェアかいはつ、Software Development）とは、ユーザーのニーズやマーケティング上の目標をソフトウェア製品に変換する作業である。ソフトウェア開発には、ソフトウェア工学の研究的側面とソフトウェア製品を開発するマーケティング的側面が含まれていると言われることがある。ソフトウェア製品のマーケティング活動そのものは、必ずしも新商品開発とは結びつかない。顧客の期待を満足させるべく開発されたソフトウェア製品の成功/失敗の責任が工学的側面にあるのかマーケティング的側面にあるのかを判別するのは、多くの場合困難である。そのため、ソフトウェア開発全体として工学的側面とマーケティング的側面を共に理解し、それらの協調を促進することが重要である。工学とマーケティングの両方の側面をまとめ、バランスをとるのは、プロジェクトマネージャなどと呼ばれる立場の人である。 マーケティングとの関わりはソフトウェア要求分析としても知られている。ソフトウェア開発はクライアントが必要とするもの以上の機能を開発しようとしたり、逆に妥協しようとしたりする。そのため、ソフトウェア開発は通常の工学/技術とは関連付けられていなかった各種プロセス（市場調査、人材登用、リスクマネジメント、知的財産権、予算、危機管理など）まで取り込もうとする場合がある。その場合、ソフトウェア開発は Business Development と呼ばれる領域ともオーバーラップすることになる。 Alan M. Davis は著書 "Great Software Debates" の章 "Requirements" の節 "The Missing Piece of Software Development" で次のように述べている.
新しい！!: ソフトウェア開発工程とソフトウェア開発 · 続きを見る »
ソフトウェア開発方法論
フトウェア開発方法論またはシステム開発方法論は、ソフトウェア工学におけるフレームワークであり、情報システムの開発工程を構造化し、計画し、制御するのに使われる。SDM（software development methodology または system development methodology）と略記される。.
新しい！!: ソフトウェア開発工程とソフトウェア開発方法論 · 続きを見る »
ソフトウェア構成管理
フトウェア構成管理（ソフトウェアこうせいかんり、software configuration management、SCM）とはソフトウェア開発プロジェクトをその成果物を通して制御・管理する方法論である。ソースコードや文書などの成果物の変更履歴を管理し、製品のバージョンやリビジョンに個々の成果物のどのバージョンが対応しているかを識別し、任意のバージョンの製品を再現可能とする。 バージョン管理システムは SCM のためのツールであるが、バージョン管理システムそのものを SCM と呼ぶこともある。しかし、一般にソフトウェア構成管理はバージョン管理とは等価ではなく、バージョン管理を制御するマネジメント的要素が含まれる。.
新しい！!: ソフトウェア開発工程とソフトウェア構成管理 · 続きを見る »
共通フレーム
共通フレーム（きょうつうフレーム、SLCP-JCF）は、情報処理推進機構が発行している、ソフトウェアライフサイクルにおける用語や作業内容などを規定したガイドライン。.
新しい！!: ソフトウェア開発工程と共通フレーム · 続きを見る »
B-Method
B-Methodとは、AMN（Abstract Machine Notation）という仕様記述言語（兼プログラミング言語）を中心とした形式手法に基づいたソフトウェア開発手法である。B-Method で使用する形式手法やそのツール群は単に B と呼ぶ。.
新しい！!: ソフトウェア開発工程とB-Method · 続きを見る »
統計学
統計学（とうけいがく、statistics、Statistik）とは、統計に関する研究を行う学問である。 統計学は、経験的に得られたバラツキのあるデータから、応用数学の手法を用いて数値上の性質や規則性あるいは不規則性を見いだす。統計的手法は、実験計画、データの要約や解釈を行う上での根拠を提供する学問であり、幅広い分野で応用されている。 現在では、医学（疫学、EBM）、薬学、経済学、社会学、心理学、言語学など、自然科学・社会科学・人文科学の実証分析を伴う分野について、必須の学問となっている。また、統計学は哲学の一分科である科学哲学においても重要な一つのトピックになっている。.
新しい！!: ソフトウェア開発工程と統計学 · 続きを見る »
要求分析
要求分析（ようきゅうぶんせき、Requirements Analysis）とは、システム工学やソフトウェア工学において新たなシステムやシステム更新に際しての調査/定義に関わる工程を指す。要求分析はシステム設計工程でも重要な部分であり、アナリストやシステムエンジニア/ソフトウェア開発者が顧客の必要性や要求を特定する工程である。顧客の要求が特定されたら、システム設計者がその解決策を設計することになる。.
新しい！!: ソフトウェア開発工程と要求分析 · 続きを見る »
要求管理
要求管理（ようきゅうかんり、Requirements management）は、プロジェクトの要求を管理し、それら要求とプロジェクトの計画および成果物との不整合を特定することを目的とする。要求管理には変更管理と要求トレーサビリティが含まれる。.
新しい！!: ソフトウェア開発工程と要求管理 · 続きを見る »
能力成熟度モデル統合
能力成熟度モデル統合 (のうりょくせいじゅくどモデルとうごう、) は、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものである 。 CMMIは、もともとは能力成熟度モデル (CMM; Capability Maturity Model) として開発された。.
新しい！!: ソフトウェア開発工程と能力成熟度モデル統合 · 続きを見る »
ISO 9000
ISO 9000シリーズないし、ISO 9000ファミリーとは、国際標準化機構 (ISO) による品質マネジメントシステムに関する規格の総称で、その中核をなす規格はISO 9001である。もともと、現在のISO 9001の前身となる規格が事業所の性格に応じてISO 9001、ISO 9002、ISO 9003に分かれていたことや、現在でも関連の規格が9000番台である物が中心になっているので、まとめてISO 9000シリーズと呼ばれる。認証の対象となる規格はISO 9001である。.
新しい！!: ソフトウェア開発工程とISO 9000 · 続きを見る »
ISO/IEC 12207
ISO/IEC 12207 (Systems and software engineering — Software life cycle processes) とは、ソフトウェアのライフサイクル全般についての標準である。国際標準化機構 (ISO) と国際電気標準会議 (IEC) の合同技術委員会 (JTC 1) が1995年に策定した。ソフトウェアの開発や保守に関わる活動全般の標準を定義することを目的としている。翻訳が、日本工業規格 JIS X 0160（ソフトウェアライフサイクルプロセス）になっている。 ISO/IEC 12207 ではソフトウェアのライフサイクルを定義しており、システム上のサービスの入手や構成に関わる活動やプロセスも含まれる。各プロセスには必ずその出力となるものが定義されている。実際には 23種類のプロセス、95種類の活動、325種類のタスク、224種類の出力（成果物）が定義されている。 この標準の主な目的は、ソフトウェアの開発や保守に関わる様々なステークホルダー（購入者、提供者、開発者、保守者、操作者、管理者、技術者）に共通の構造を提供し、相互のコミュニケーションを円滑にすることである。そのような共通の言語はうまく定義されたプロセスで確立される。標準自体の構造は柔軟でモジュール性があり、必要な人が必要な部分だけを採用することができるようになっている。この標準の2つの基本原則は、モジュール性と信頼性である。モジュール性とは、定義されたプロセス間の結合度が最小で凝集度が最大となっていることを意味する。信頼性とは、各プロセスの信頼性を確立し、標準を応用したプロジェクトに多くの人々が法的に参加できるものにすることである。 プロセス、活動、タスクはソフトウェアプロジェクトに適用可能である。プロセスは3種類に分類されている。;基本プロセス: 購入プロセス（発注プロセス）、提供プロセス、開発プロセス、運用プロセス、保守プロセス;サポートプロセス: 文書化プロセス、構成プロセス、品質保証プロセス、検証プロセス、評価プロセス、ジョイントレビュープロセス、報告プロセス、問題解決プロセス;組織プロセス: 管理プロセス、基盤プロセス、改善プロセス、訓練プ.
新しい！!: ソフトウェア開発工程とISO/IEC 12207 · 続きを見る »
ISO/IEC 15504
ISO/IEC 15504は、ソフトウェア開発を中心とした工程の評価の枠組みであり、国際標準化機構(ISO)と国際電気標準会議(IEC)の合同技術委員会が策定した。原案作成に寄与したプロジェクト名にちなんでSPICE(Software Process Improvement and Capability dEtermination)という愛称で関係者が呼んでいることがある。.
新しい！!: ソフトウェア開発工程とISO/IEC 15504 · 続きを見る »
Object Constraint Language
Object Constraint Language（OCL）は、統一モデリング言語 (UML) モデルに適用する規則を記述するための宣言型言語である。IBMが開発し、UML標準の一部となった。初期のOCLは、単なるUMLの形式仕様記述言語としての拡張であったが、その後 UMLだけでなく Object Management Group (OMG) の Meta-Object Facility (MOF) のメタモデル全般を扱うようになった。Object Constraint Language (OCL) は Meta-Object Facility などのモデルやメタモデルについて、図表の形式では表現できない制約やクエリを表現することができる正確なテキスト言語である。OCL は OMG のモデル変換に関する推奨標準 QVT 仕様の一部となっている。他の多くのモデル変換言語（ATLなど）も OCL に基づいて構築されている。.
新しい！!: ソフトウェア開発工程とObject Constraint Language · 続きを見る »
Rapid Application Development
Rapid Application Development（ラピッド・アプリケーション・デベロップメント、RAD）とは、ソフトウェアの開発を容易にする仕組みの1つである。ユーザーを含む少人数のチームで開発を進め、プロトタイプを作ってそれを評価するというサイクルを繰り返すことで、完成品に近づけていく。.
新しい！!: ソフトウェア開発工程とRapid Application Development · 続きを見る »
Vモデル
Vモデル（V-Model）とは、IT製品開発の手法の一種。ドイツ政府と軍関係のプロジェクトで標準として採用されている。また、一般に利用可能であるため、様々な企業でも使われている。プロジェクトマネジメント手法としては、PRINCE2に匹敵する。また、システム開発やソフトウェア開発の手法としても使われている。.
新しい！!: ソフトウェア開発工程とVモデル · 続きを見る »
VDM
VDM（Vienna Development Method）は、IBMのウィーン研究所で1960年代から70年代にかけて開発された形式手法。 その仕様記述言語VDM-SLは1996年にISO標準（ISO_IEC_13817-1）となっている。VDM-SLをオブジェクト指向拡張したVDM++も、欧州連合ESPRIT計画のAFRODITEプロジェクトで開発された。.
新しい！!: ソフトウェア開発工程とVDM · 続きを見る »
Z言語
Z言語 (ぜっどげんご) は、Z記法 (ぜっどきほう) ともいい、形式仕様記述言語であり、コンピュータシステムの記述とモデリングを行うために使われる。 ZはZF集合論から名前をとって命名された。 Zは次のことに焦点を当てている。.
新しい！!: ソフトウェア開発工程とZ言語 · 続きを見る »
有限オートマトン
有限オートマトン（finite automaton)または有限状態機械（finite state machine, FSM）とは、有限個の状態と遷移と動作の組み合わせからなる数学的に抽象化された「ふるまいのモデル」である。デジタル回路やプログラムの設計で使われることがあり、ある一連の状態をとったときどのように論理が流れるかを調べることができる。有限個の「状態」のうち1つの状態をとる。ある時点では1つの状態しかとらず、それをその時点の「現在状態」と呼ぶ。何らかのイベントや条件によってある状態から別の状態へと移行し、それを「遷移」と呼ぶ。それぞれの現在状態から遷移しうる状態と、遷移のきっかけとなる条件を列挙することで定義される。 有限オートマトンは様々な問題に応用でき、半導体設計の自動化、通信プロトコル設計、構文解析などの工学面での応用がある。生物学や人工知能研究では状態機械（群）を使って神経系をモデル化し、言語学では自然言語の文法をモデル化したりする。.
新しい！!: ソフトウェア開発工程と有限オートマトン · 続きを見る »
