システム開発技術

システム開発のプロセス

企画プロセス

システム構想の立案
システム化計画の立案

要件定義プロセス

システムが実現する仕組みに関する要件
利害関係の識別
顧客に沿ったニーズ要件の抽出、定義、確率

システム開発プロセス

1.システム要件定義プロセス
顧客の要件を元に、どのようなシステムを実現するのかを決定する。(ITコンサル)
2.システム方式設計プロセス
決定したシステム要件を満たすために、サブシステムごとに、ハード・ソフトウェアを選定。
3.ソフトウェア要件定義プロセス
業務モデル，論理データモデルを作成して，システムを構成するソフトウェアに求められる機能，能力，
インタフェースなどを決定し，ソフトウェア適格性確認要件を定める。

サブシステムの機能仕様とそのインタフェースの設計：サブシステムとはシステムの一部のこと。インタフェースとは境界面のことで各サブシステムの連結部分を指す。
業務モデルとデータモデルの設計：UMLを用いて、業務フローやサブシステム間、データモデルを整理する。
セキュリティの設計：情報セキュリティ方針、セキュリティ要件、セキュリティ実現方式を決定する。
保守性の考慮：運用開始後の新機能の追加及び既存機能の変更に必要な工数を抑えるために設計する。

4.ソフトウェア(ハードウェア)方式設計プロセス
要件定義で決定したソフトウェアの機能要件や非機能要件、制約条件、外部とのやり取りなどを最上位レベルで決定する。

ハードウェア方式設計：信頼性や性能要件に基づいて、冗長化、フォールトトレラント設計、サーバの機能配分、信頼性配分などを検討し、構成を決定する。
ソフトウェア方式設計：システムの供給者が自社で全て開発するか，ソフトウェアパッケージなどを利用するかなどの方針，使用するミドルウェアの選択などを検討し，ソフトウェア構成を決定する。
データベース方式設計：データベースについて最上位レベルの決定。システムで使用するデータベースの種類，信頼性を考慮し冗長化したレプリケーションなどを検討し，決定する。

5.ソフトウェア(ハードウェア)詳細設計プロセス
方式設計の結果を受けて、各部品（コンポーネント）とモジュールレベルにまで分割して細かな内容の決定を行う。

ハードウェア詳細設計：テーブル1つ1つの定義、データベースの設定の記述（データベース詳細設計）ネットワークのプロトコル、通信速度等の設計（ネットワーク詳細設計）ロードバランサ等その他ハードウェアの詳細設計。
ソフトウェア詳細設計：各モジュールをコーディング・テストするためにソフトウェアユニット（独立して実行できる単位（クラス））まで詳細化する各プログラムの処理内容の記述（シーケンス図）。

保守プロセス

ソフトウェア要件定義・設計のアプローチ

プロセス中心アプローチ：システムに必要な機能を洗い出して定義し、その実行に必要なデータを導く設計法。DFD(データフローダイアグラム)を用いる。
データ中心アプローチ：業務処理中に現れるデータ構造に着目する。データベース設計を先に行う。
オブジェクト指向アプローチ：対象業務の手続きとデータを一体化したオブジェクトとして分析・設計する手法。モジュールの独立性を高める。

オブジェクト指向の概念

データとメソッドをカプセル化して定義するプログラム方式。

クラス：オブジェクトの振る舞いをプログラムにしたもの。
インスタンス：クラスから生成した実体。
継承(インヘリタンス)：スーパークラス(上位クラス)のもつ性質をサブクラス(下位クラス)に引き継ぐこと。
抽象クラス：変数・メソッド名のみ定義し、処理の詳細を書かない上位クラスのこと。
ポリモーフィズム：継承したクラス間で同じ名前のメソッドを定義して実行時にどの処理が実行されるか結びつける方法(動的結合)。

モジュールの独立性

他のモジュールに与える影響度の強さ。
強度：強いほどモジュール内の機能間で関連性がない評価をする。

暗号的強度：機能を定義できてない。他人が理解しにくい。
論理的強度：論理的に関連のある複数の機能で構成される。
時間的強度：特定の時間帯に実行されるという観点で機能をまとめたもの。
手順的強度：一連の手順で実行することで、一つの機能を達成するモジュール。
連絡的強度：手順的強度＋データの受け渡し。
情報的強度：同一のデータ構造を扱う複数の機能の入ったモジュールを一つにまとめたもの。
機能的強度：モジュールが単一の機能だけを提供しているもの。

結合度：モジュール同士の関連の強さで、データをどのようにやりとりするのかを定義する。

特殊
内容結合：他モジュールの内部を直接参照している結合。
グローバル
共通結合：複数のモジュールが複数の大域的な構造体のデータをグローバル変数化などをして共有する。
外部結合：複数のモジュールが単一のグローバルデータを共有する。
パラメータ
制御結合：引数に応じて中の処理を変えるデータ(フラグ等)を渡す。
スタンプ結合：構造体を持つデータ(インスタンス等)を引数として渡す。
データ結合：構造を持たない単一のデータ(文字列、数値等)を引数として渡す。

UML

統一モデリング言語。オブジェクト指向開発に一貫して用いるモデリング手法。

クラス図：システムを構成するクラスとプロパティ、メソッドを記載する。
オブジェクト図：インスタンスの関係を表す図。
ユースケース図：ユーザーの要求に対するシステムの振る舞いを表現する図。
コミュニケーション図：オブジェクト間のメッセージのやりとりを表す図。
シーケンス図：機能毎にクラス間でのデータのやりとりを時系列で表した図。
コンポーネント図：ソフトウェアコンポーネントの繋がりを表現する。
ステートマシーン図：オブジェクト状態がどのように変換するのかを表した図。
アクティビティ図：処理の手順をフローチャートで表す。

ソフトウェア構築(テストの流れ)

単体テスト

モジュールごとにプログラムを実行して入力に対する出力をみて正しくプログラミングされているのかを確認。

ホワイトボックステスト：プログラムの中を見てプログラムの制御構造(ロジック)に基づいてテストケースを設計する。
命令網羅：プログラム上の命令を少なくとも一回実行する。
判定条件網羅：判定条件のうち真と偽を少なくとも一回は判定する。
条件網羅：判定条件中の全ての条件で、一回は正と負の判定があるようにする。
判定条件/条件網羅：判定条件網羅と条件網羅の両方を満たすようにする。
複数条件網羅：判定条件の取りうるすべての組み合わせを網羅する。
ブラックボックステスト：プログラムの中身を意識せずにテスト対象の機能仕様を元に入力に対する正しい出力が得られるか確認する。
同値分割：入力条件の仕様を元に、入力領域のうち正常処理となる「有効同値クラス」と、異常処理となる「無効同値クラス」に分けて、各同値クラスの代表値をテストケースとする。
限界値分割：同値クラスの境界付近をテストケースとする。

結合テスト

モジュール(ソフトウェア)を結合して一つのサブシステムとして分割の適切さ、モジュール(ソフトウェア)間のデータの受け渡しが正しくできているのかを確認。

トップダウンテスト：上位のモジュールから下位のモジュールに向けて結合を進めるテスト。
スタブ：下位モジュール未作成時に、仮の下位モジュールを利用すること。
ボトムアップテスト：下位のモジュールから上位のモジュールに向けて結合を進めるテスト。
ドライバ：上位モジュール未作成時に、仮の上位モジュールを利用すること。

適格性確認テスト

ソフトウェア(システム)が要件定義で設定された機能やセキュリティが実現されているのかを検証する。

機能テスト：要件定義で規定したユーザの求める機能を満たしているかどうか検証する。
性能テスト：処理速度、ターンアラウンドタイム、レスポンスタイム、スループットなどの性能を検証する。
負荷テスト：システムに量的な負荷をかけて、耐えられるかどうかを検証する。
例外テスト：システムが定めたエラー処理、例外処理を行うか検証する。
災害対策テスト：災害発生時を想定して、システムがバックアップサーバに移行することができるか検証する。

その他

ユーザビリティテスト：利用者にシステムを実際に触ってもらい、使いやすさに問題がないか確認するテスト。
レグレッション(回帰)テスト：プログラムの一部を回収したことによって、他の部分で新たなバグの発生やシステム性能の低下等がないか確認するためのテスト。
ベンチマークテスト：プログラムを走らせてその実行時間を測定することで、他のコンピュータと性能を比較するテスト。
運用テスト：システムの運用部門が業務の流れに沿ってシステムのテストを行い、実際の稼働状況において不具合が発生しないかを検証するテスト。
静的解析ツール：ソースコードを解析して、コーディング規約の違反やバグがないかを検出する。
テストデータジェネレータ：テストデータを自動生成するツール。
カバレッジ分析ツール：テストプログラム実行時にどれだけの部分が実行されているのかを分析する。
プロファイラ：モジュールの呼出し回数や実行時間，実行文の実行回数などの，プログラム実行時の動作特性に関するデータを計測する。

ソフトウェアの品質

機能適合性：ソフトウェアの機能がどれだけユーザの要求するニーズにマッチしているのかという特性。
性能効率性：限られた資源でどれだけ高速に処理でき、資源の無駄遣いが少ないか。
互換性：複数の製品が影響なく共存できる、データを問題なく相互利用できるか。
使用性：利用者にとってソフトウェアが使いやすいか。
信頼性：製品をトラブルなく利用できるか、またトラブルがあっても容易に回避できるか。
セキュリティ：製品の情報、データを保護できているか。
保守性：製品の修正がしやすいか。
移植性：製品をある環境から別の環境へ移すことができやすいか。

レビュー

品質を高めるために、ソフトウェアに潜む問題を発見するためのミーティング形式の活動。

共同レビュー：プロトタイプとして作成したソフトウェアを顧客とレビューする。
デザインレビュー：設計工程で行う。
コードレビュー：ソースコードにバグがないのかを確認する。
ピアレビュー：チームメンバのうち、様々なスキルや知識を持つ技術者メンバで構成して確認する。
インスペクション：責任のあるプロジェクトメンバー以外の第三者が参加して、評価基準に基づいて仕様書やソースコードなどの成果物に潜在的な不具合や問題点がないかを検証する。
モデレータ：インスペクションの結果を公式に記録・分析する人。
ウォークスルー：コードや設計書の作成者と複数の関係者で問題の早期発見を目的として行うレビュー。
ラウンドロビン：レビューのための作業と役割を参加メンバに均等に配分し、参加メンバが持ち回りでレビュー責任者を務めるレビュー技法。
パスアラウンド：成果物を複数のレビュアに配布又は回覧してレビューを依頼して、コメントをもらう。

ソフトウェア開発管理技術

開発プロセス・手法

ウォータフォールモデル：上流から下流工程に向けて一つ一つ工程を終えて次の工程に進むモデル。
プロトタイプモデル：試作品（プロトタイプ）を作成してレビューをしてもらって評価して、変更点を修正して再度プロトタイプを作成、評価を繰り返すモデル。
スパイラルモデル：「目的、代替案、制約の決定」「代替案とリスクの評価」「開発と検証」「計画」を繰り返すプロセスモデル。反復ごとにリスク分析をして、リスクを最小限に抑える。
RAD：開発支援ツールを活用して、従来の開発手法よりも少人数で早期に開発を行う。
タイムボックス：制限を過ぎても要件の固まらない要求は開発しない。

アジャイル

短い期間（数日、数週間）の開発サイクルを反復(イテレーションという)して開発する。
最終段階までの詳細な計画は立てず、1サイクル分の簡単な計画を立てる。
開発サイクルごとに、成果物をリリースする。

ペルソナ：製品開発時に利用者として想定する仮想的なユーザのこと。

バーンダウンチャート

アジャイルの残作業を可視化するためのチャート。

XP(Extream Programming)

アジャイルの代表的な開発手法で5つの価値と19のプラクティスからなる。

5つの価値
コミュニケーション：クライアント、チームメンバーとのコミュニケーションを重視する。
シンプル：過度な実装をせずに、単純な実装をシンプルに行う。
フィードバック：クライアント、ユーザから定期的にフィードバックをもらって、必要な機能を考えて実装をする。
勇気：上記3つの価値を実現するための勇気や変化を受け入れる勇気。
尊重：関係する互いのチーム、開発チームと運用チーム等の意見、立場を尊重すること。
共同のプラクティス
反復：開発期間は1週間～2週間を何度も繰り返します。「設計→開発→テスト→リリース」を反復します。
共通の用語：用語集を作成してチーム全体で使用する用語を統一して概念の不一致をなくす。
オープンな作業空間：会話しやすく、作業に打ち込める雰囲気を作る。
回顧：過去のフィードバックを迅速に反映させるように心がけ、そのための環境を整える。
開発のプラクティス
テスト主導型の開発：実装を行うよりも先に、テストを作成して、そのテストのパスを通すことを目標に実装する。
ペア・プログラミング：実装は2人1組で行う。
リファクタリング：完成済みのコードを、随時、改善する。
集団的な所有権：誰が作ったコードでも全員が断りなく修正できる。
継続的インテグレーション：作成したコードはすぐに結合テストをして、改善点がないか確認する。
YAGNI(“You Aren’t Going to Need It”.)：現在必要となる機能に絞って実装する。
管理者のプラクティス
責任の受け入れ：責任を特定の人に押し付けず、開発チームがプロジェクトを実施できるように責任を受け入れる。
援護：チームの活動が円滑に進むように支援して、障害を取り除くこと。
四半期ごとの見直し：プロジェクトの進捗状況を顧客とともに四半期ごとのレビューして、必要に応じて見直す。
ミラー：いまどういう状態かチームがわかるようにする。
持続可能なベース：知的な作業は週40時間がベストで、XPは集中力を高めることを重視しているため、それ以上の労働を強いずに心身共に健全な状態に保つようにする。
顧客のプラクティス
ストーリーの作成：求める機能のコンセプトを短い文章で記したストーリーカードを作成する。
リリース計画：どのストーリーをどのイテレーションの対象とするか、チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。
受け入れテスト：イテレーションごとに顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。
頻繁なリリース：実行できるソフトウェアを2-3週間から2-3カ月の短いスパンで作成してリリースする。

スクラム

アジャイル開発の代表で、「チームで開発すること」を主眼において、チームのコミュニケーションを重視します。

プロダクトオーナー：作成するプロダクトの責任者。スケジュール、予算管理を行う。
スクラムマスタ：スクラムを円滑に実行させるための責任者。スクラムを成功に導くための調整と支援を行う。実際の開発は行わない。
開発チーム：実際に開発を行うメンバ。チームに上限関係なく、一丸となって開発をする。
スプリントプランニング：スプリントで実施する作業内容の決定、工数の見積もり、メンバへの作業の割り当て。
デイリースクラム：毎朝、短い時間(5-15分)チームの状況を共有する。
スプリントレビュー：・プロダクトオーナが成果物の確認をする。
スプリントレトロスペクティブ：スプリントを振り返り問題点・解決策を洗い出す。

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

既存のソフトウェアのファイルやソースコードと言った下流工程の成果物を解析して、設計・仕様などの上流工程の情報を導き出す手法。

マッシュアップ

複数のコンテンツを取り込み、組み合わせて利用するサービス。

コンカレントエンジニアリング(CE)

製品開発にかかる作業を同時並行に実施して、全体の作業期間を短縮する手法。

CMMI(能力成熟度モデル統合)

組織における開発プロセスの成熟度を5段階に分けたもの。

レベル1(初期レベル)
何も管理されていない。ごく一部の人材に依存している。
プロセスが場当たり的。
レベル2(反復できるレベル)
類似するソフトウェアの開発を、繰り返し実施できる状態。
安定したプロセスが存在するが、定義や管理がされていない。
レベル3(定義されたレベル)
定義され、標準化されたプロセスが組織全体に確立されている。
レベル4(管理されたレベル)
プロセスと成果物を定量的に計測・評価できる状態。
レベル5(最適化されたレベル)
組織が自発的に継続してプロセスの改善を行える状態。
定量的なフィードバックを元に継続的に改善、最適化されている。

知的財産権運用管理

著作権(死後70年)

音楽，映画，コンピュータプログラムなど，知的創作物に付属する権利。
著作者の許可なく、著作物を勝手に利用することはできない。
プログラム言語、規約(コーディング規約等),アルゴリズムは保護の対象とならない。

著作権の帰属

個人が作成したプログラム→個人に帰属
法人で働く、従業員が作成したプログラム→原則として法人。ただし、特約があればそれに従う
請負契約で発注されたプログラム→原則として発注先に帰属。ただし、特約があればそれに従う
派遣契約によって作成されたプログラム→原則として発注元（派遣先）に帰属する
共同で開発したプログラム→原則として共同開発者の両方に帰属する

著作権の侵害と侵害でない場合

海賊版のプログラムを知りながらそのプログラムを利用する。
バックアップ目的での複製、利用するために必要なバグの修正は著作権侵害にあたらない。
正当に入手したソフトを逆コンパイルしてリバースエンジニアリングするのは原則著作権侵害ではない。

特許権(20年)

特許を受けた発明を権利者が一定期間独占的に実施することができる権利。
発明の内容を記載した書類を願書とともに特許庁に提出し、審査官の審査を受けて特許査定を受ける必要がある。

特許法

「発明の保護及び利益を図る」ことによって、産業の発達に寄与することを目的とした法律。

特許出願、審査請求を行い、審査を経て登録されると権利が発生する（先願主義）
ただし、別の事業者が先に特許技術を独自で開発していた場合には、使用権を認める（先使用権）
特許を取得するには技術の公開が必要なので、あえて特許を取得しない場合もある（セキュリティ技術など）
事業でなく、個人的な使用であるなら特許権者から実施許諾を受けなくても利用できる。
特許の実施許諾を受けたものが、第3者に特許の実施許諾することをサブライセンスと言う。通常、実施許諾時にサブライセンス権について明記しない場合は、サブライセンス権は付与されない。

構成管理・変更管理

構成状況の記録：ソフトウェア構成品目について、状況や履歴を管理し、変更回数・最新のバージョン・移行状況などを文書に記録。
構成品目の完全性保証：ソフトウェアの機能的、物理的な完全性を保証する（正確であり最新の情報であること）。
リリース管理及び出荷：ソフトウェア構成品目の完全性が保証された後は，ソフトウェアや関連文書の新しい版の出荷などの手続を行うこと(バージョン管理)，ソフトウェアのコードや文書はソフトウェアの寿命のある間保守する。