本サイトはプロモーション(広告)が含まれています。

【応用情報技術者】ソフトウェア開発管理技術の用語メモ

【応用情報技術者】ソフトウェア開発管理技術の用語メモ

CMMI

CMMI(Capability Maturity Model Integration)は、ソフトウェア開発やプロセス改善のためのベストプラクティスとガイドラインを提供する枠組みで、特にソフトウェア業界で広く使用されています。CMMIは、組織がプロセス成熟度を向上させ、プロジェクトの品質、効率性、予測可能性を高めるのに役立つモデルです。以下はCMMIの主要な特徴とコンセプトです

  • ソフトウェア開発組織及びプロジェクトのプロセスの成熟度を評価するためのモデルである。
  • ソフトウェアプロセスの標準化と最適化を推進し,製品やサービスの開発,調達及び保守活動において,組織のもつプロセスを改善するためのガイドラインを提供するもの
  • 製品やサービスについて,組織が開発と保守やプロセスを改善するのを助ける。

IDE

集成開発環境(Integrated Development Environment、IDE)は、ソフトウェア開発者がソフトウェアアプリケーションを開発、テスト、デバッグするための統合ツールセットです。IDEは、開発プロセスを効率化し、プログラミング言語やフレームワークに特化した機能を提供します。

  • エディタ,コンパイラ,リンカ,デバッガなどが一体となったツール

KPT手法

KPT手法は、プロジェクトやチームの改善を促進するためのシンプルなフィードバックツールです。KPTは、”Keep, Problem, Try” の略で、以下の3つの要素から成り立っています:

  1. Keep(キープ): これは、プロジェクトやチームで良く機能していることや、成功していることを指します。キープすることは、成功体験を認識し、継続するために重要です。

  2. Problem(プロブレム): これは、プロジェクトやチームに存在する課題や問題点を指します。プロブレムを明確にし、解決策を見つけるためのステップとして役立ちます。

  3. Try(トライ): これは、プロジェクトやチームが改善しようとする具体的なアクションや取り組みを指します。トライは、問題を解決し、キープ要素を強化するための提案です。

KPT手法は、プロジェクトの進行やチームの状態を定期的に評価し、反復的な改善をサポートするのに役立ちます。通常、定期的なミーティングやワークショップでKPTセッションが実施され、チームメンバーや関係者が意見を共有し、改善の方向性を議論します。

SOA(Service Oriented Architecture)

Service-Oriented Architecture(SOA、サービス指向アーキテクチャ)は、ソフトウェアアーキテクチャの設計原則で、ビジネスプロセスや機能を独立したサービスとしてモデル化し、これらのサービスを組み合わせてシステムを構築する方法論です。SOAは、企業や組織が効率的で柔軟なソフトウェアシステムを開発し、運用するためのアプローチとして広く採用されています。

  • 業務機能を提供するサービスを組み合わせることによって,システムを構築する考え方である。

イテレーション

イテレーション(Iteration)は、ソフトウェア開発やプロジェクト管理のコンテクストで使用される重要な概念の一つです。イテレーションは、プロジェクトの一部を一定期間内に反復的に繰り返すプロセスを指します。このアプローチは、アジャイル開発方法論などで広く採用されています

  • ソフトウェアに存在する顧客の要求との不一致を短いサイクルで解消したり,要求の変化に柔軟に対応したりする。

クロス開発

クロス開発(Cross-Development)は、ソフトウェア開発の一形態であり、通常は異なるプラットフォームや環境で動作するソフトウェアを開発するプロセスを指します。クロス開発は、特に組み込みシステムやモバイルアプリケーションの開発、クライアント-サーバーアプリケーション、マルチプラットフォーム対応のソフトウェアなど、異なる環境で動作するソフトウェアを開発する場合に一般的です。

  • ソフトウェアを実行する機器とはCPUのアーキテクチャが異なる機器で開発を行うこと

サーバプロビジョニングツール

サーバプロビジョニングツールは、サーバーの自動化と設定管理を行うためのソフトウェアツールやフレームワークです。これらのツールは、サーバーの展開、構成、および管理プロセスを効率化し、一貫性を保ち、リソースの効果的な利用を支援します。

  • システム構成をあらかじめ記述しておくことによって,サーバを自動的に構成する。

状態遷移図

状態遷移図(State Transition Diagram)は、情報技術(IT)分野で使用されるモデリングツールの一つで、システムやソフトウェアコンポーネントの状態と、それらの状態間の遷移を視覚的に表現するために使われます。状態遷移図は、システムやアプリケーションが特定の条件やイベントに応じて状態を変更する方法を理解しやすくするのに役立ちます。

プロセス制御などの事象駆動(イベントドリブン)による処理の仕様を表現する方法として,適切なもの

スクラム開発

スクラム(Scrum)は、アジャイルソフトウェア開発のためのプロジェクト管理フレームワークの一つであり、ソフトウェア開発プロセスを効果的に管理し、高品質のソフトウェアを迅速に提供するために設計されています。スクラムは、プロジェクトを複数の小さなイテレーション(スプリントと呼ばれる)に分割し、柔軟性を持って変更を受け入れつつ、継続的に価値を提供します。

  • プロダクトオーナなどの役割,スプリントレビューなどのイベント,プロダクトバックログなどの作成物,及びルールから成るソフトウェア開発のフレームワークである。

スクラムマスター

「スクラムマスター」(Scrum Master)は、アジャイルソフトウェア開発フレームワークであるスクラムのプロジェクト管理における役割の一つです。スクラムマスターは、スクラムプロセスを導入し、スクラムチームがスクラムの原則とルールに従って効果的に働くことをサポートする役割を果たします。

  • スクラムの理論とプラクティスを全員が理解するように支援する。

スプリントプランニング(Sprint Planning)

スプリントプランニング(Sprint Planning)は、スクラム開発フレームワークの一部であり、スクラムチームが次のスプリントに取り組むための計画を立てる重要なイベントです。

スプリントレトロスペクティブ

スプリントレトロスペクティブ(Sprint Retrospective)は、スクラム開発フレームワークの一部であり、スクラムチームが直前のスプリントの実施とプロセスについて学び、改善の機会を見つけるために行う定期的なイベントです。スプリントレトロスペクティブは、スプリントが終了し、新しいスプリントが始まる前に実施されます。

スプリントレビュー(Sprint Review)

スプリントレビュー(Sprint Review)は、スクラム開発フレームワークの一部であり、スクラムチームが直前のスプリントで達成した成果物をステークホルダーや関係者に対してプレゼンテーションし、フィードバックを受けるための定期的な会議です。スプリントレビューはスプリントが終了した後に行われ、通常はスプリント期間の最終日に予定されます。

ソフトウェア方式設計プロセス

ソフトウェア方式設計プロセスは、ソフトウェア開発においてソフトウェアのアーキテクチャや構造を計画し、設計するための手順やステップの一連です。ソフトウェア方式設計は、要求事項をもとにしてソフトウェアの設計を行い、実装の前段階として非常に重要なステップです。

〔タスク〕

  • ソフトウェア品目の外部インタフェース,及びソフトウェアコンポーネント間のインタフェースについて最上位レベルの設計を行う。
  • データベースについて最上位レベルの設計を行う。
  • ソフトウェア結合のために暫定的なテスト要求事項及びスケジュールを定義する。

デイリースクラム

「デイリースクラム」(Daily Scrum)は、スクラム開発フレームワークの一部であり、スクラムチームがプロジェクトの進捗状況を毎日評価し、協力してプロジェクト目標を達成するための短い日常のミーティングです。通常、デイリースクラムは毎日同じ場所と同じ時間に行われ、スプリント中に継続的に実施されます。このミーティングは、15分以内に行われることが一般的で、短くて効果的なコミュニケーションの場です。

テスト駆動開発

テスト駆動開発(Test-Driven Development、TDD)は、ソフトウェア開発のプラクティスの一つで、ソフトウェアの品質向上と効率的な開発を目指す手法

  • プログラムを書く前にテストケースを記述する。

デュアルライセンス

デュアルライセンス(Dual Licensing)は、ソフトウェアや他の知的財産に対して複数のライセンスオプションを提供するライセンスモデルです。これは、特にオープンソースソフトウェア(OSS)コミュニティや商用ソフトウェア開発者によって使用されることが多いアプローチです。デュアルライセンスの基本的なアイデアは、ソフトウェアユーザーが2つ以上のライセンスオプションから選択し、その選択に応じてソフトウェアを利用できるようにすることです。

  • 複数のライセンスが設定されているので,利用者はそのうちの一つのライセンスを選択して同意する。

特許のサブライセンス

特許のサブライセンスは、特許権の所有者(特許権の発行者)が、特許権を第三者に許可し、その第三者が特許権を利用できるようにする契約のことを指します。サブライセンス契約は、特許権の所有者とサブライセンス受領者との間で合意され、特許の利用、開発、販売、または他の活動に関する条件と規制を定めるものです。

  • 特許の実施権の許諾を受けた者が,更に第三者に当該特許の実施権を許諾すること

バーンダウンチャート(Burn Down Chart)

バーンダウンチャート(Burn Down Chart)は、アジャイルプロジェクト管理やスクラム開発において使用されるプロジェクトの進捗を視覚的に追跡するためのツールです。バーンダウンチャートは、プロジェクトの残りの作業量やストーリーポイントを時間とともにグラフ化し、プロジェクトの進捗状況を可視化します。

バーンダウンチャートの特徴と使い方について以下に説明します:

  1. 横軸(X軸): バーンダウンチャートの横軸には時間が表示されます。通常はスプリントの日数や週数が表示され、プロジェクトの期間に応じて選択されます。

  2. 縦軸(Y軸): バーンダウンチャートの縦軸には作業量やストーリーポイントが表示されます。これはプロジェクトの進捗を示す指標です

プロダクトオーナ

「プロダクトオーナー」(Product Owner)は、アジャイルソフトウェア開発フレームワーク(例:スクラム)において、プロジェクトの成功をリードし、プロダクトのビジョンを実現するための重要な役割の一つです。プロダクトオーナーは、プロダクトについての最終的な権限を持ち、開発チームとステークホルダーとの橋渡しを担当します。

 

ペアプログラミング

ペアプログラミング(Pair Programming)は、ソフトウェア開発のプラクティスの一つで、2人のプログラマーが1つのコンピューターで協力してコードを共同で開発する方法です。通常、1人は「ドライバ」としてコードを実際に書き、もう1人は「ナビゲータ」としてコードを評価し、提案を出し、エラーを検出します。

  • 品質の向上や知識の共有を図るために,2人のプログラマがペアとなり,その場で相談したりレビューしたりしながら,一つのプログラムの開発を行う。

ベロシティ

「ベロシティ」(Velocity)は、アジャイルソフトウェア開発のコンテキストで使用されるメトリック(指標)の一つです。ベロシティは、スクラムやカンバンなどのアジャイルフレームワークで、開発チームの作業能力やプロジェクトの進捗を追跡するために使用されます。

アジャイル開発の手法の一つであるスクラムにおいて,決められた期間におけるスクラムチームの生産量を相対的に表現するとき,尺度として用いるもの

マッシュアップ

マッシュアップ(Mashup)は、異なるデータソースやウェブサービスから取得した情報や機能を組み合わせ、新しいアプリケーションやウェブページを作成する技術や手法のことを指します。マッシュアップは、ウェブ開発、データ統合、情報共有などのさまざまな分野で使用されています。

  • 公開されている複数のサービスを利用して,新たなサービスを提供する。

要求事項評価の基準

要求事項評価の基準は、ソフトウェアプロジェクトや製品の要求事項が適切かどうかを評価するための指標や基準です。これらの基準は、要求事項がプロジェクトの目標や顧客のニーズを満たすかどうかを判断するために使用されます。

  • 取得ニーズとの一貫性

リファクタリング(Refactoring)

リファクタリング(Refactoring)は、ソフトウェア開発のプロセスで、既存のコードを再構築し、保守性、可読性、拡張性を向上させるための手法です。リファクタリングは、ソフトウェアの品質を向上させ、バグを減らし、開発速度を向上させるのに役立ちます

アジャイル開発のプラクティスのうち,回帰テストを行うことを前提とするもの

  • 外部から見た動作を変えずにプログラムをより良く作り直すこと

リーンソフトウェア開発

リーンソフトウェア開発(Lean Software Development)は、製造業のリーン思想に基づいてソフトウェア開発プロセスを改善するためのアジャイル開発の手法の一つです。リーンソフトウェア開発の主要な目標は、無駄を削減し、価値を最大化することです。

(1)~(7)に示した七つの原則を適用して,アジャイル開発プラクティスを実践する考え方。

  • ムダをなくす
  • 品質を作り込む
  • 知識を作り出す
  • 決定を遅らせる
  • 早く提供する
  • 人を尊重する
  • 全体を最適化する

レトロスペクティブ

レトロスペクティブ(Retrospective)は、ソフトウェア開発プロセスやプロジェクトの一部として行われる定期的な反省と改善のプラクティスです。主にアジャイル開発方法論(たとえば、スクラムやカンバン)で使用され、プロジェクトチームが過去の作業やプロセスについて学び、改善点を特定するために行います。レトロスペクティブは、プロジェクトの品質、効率性、コラボレーション、チームのモラルなどを向上させるのに役立ちます。

  • “イテレーション”の各回の最後

リバースエンジニアリング

リバースエンジニアリング(Reverse Engineering)は、既存の製品、ソフトウェア、またはシステムを分析し、その構造、設計、または動作を理解しようとするプロセスです。

  • ソースプログラムを解析してプログラム仕様書を作る。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

PAGE TOP