FrontPage > SoftwareEnginialing1 (Now)
はじめに †
大学2年生秋学期のソフトウェア1のメモ
Lesson1 2009/10/01 "ソフトウェア開発の現状について" †
休みました!
Lesson2 2009/10/07 "商用ソフトウェアと、オープンソース" †
Open Source Software - OOS †
OOS とはなにか †
OOS の定義 †
- 再配布の自由
- ソースコードを含む
- 派生ソフトウェアの容認
- 作者のソースコードの完全性 - 誰が作ったのか明確にすること
- 個人、グループ、利用する分野の差別の禁止
- ライセンスについて - 分配、
なぜ OOP なのか †
リチャードストールマンが創設
「自由なソフトウェア」という意味
著作権は放棄しない
- 自由なソフトウェア
- コピー、研究、変更、配布に対して制限がつけられないソフトウェアのこと
- Copyleft
- フリーソフトウェアが自由であり続けるための概念
「配布する人にソースコードを自由に習得変更再配布する権利を提供せずにプログラムの再配布をしては逝けない」
いったんフリーソフトウェアとして公開したソフトウェアを、フリーソフトウェアでなくすことは難しい
誰かがそのソフトウェアを更新し続ける限り、そのソフトウエアは成長を続ける
- Public Domain
- 他人の権利を侵害しない限り、自由に利用できる
著作権を誰も持っていないもの
OSSと商用ソフトウェアの違い †
- OSS
- 全て公開、再配布、派生物の作成、開発者は全世界
- 商用ソフトウェア
- コード非公開、コンパイル後販売、プログラム解析禁止、サポート有り、独自のライセンス
- 伽藍とバザール
- OOSと商用ソフトウェアの開発手法を比較した論文
- 伽藍方式
- 大聖堂を作るがごとく、厳かで大掛かりであること
- バザール方式
- 特定の思想やしきたりに縛られることなう、自由で活発な開発が行われる様子を示す
ソフトウェアライセンス †
ソフトウェアを使用するために交わす契約
開発者の特許権などを保護する
代表的なソフトウェアライセンス †
- GPL
- The GNU General Public License
ソフトウェアを実行、解析、再配布、改変する許可を与える
派生物に対しても、この規約を保持させる
- MPL
- Mozilla Public License
派生物もMPLである必要がある
他のライセンスと選択的に成立させることが可能
- BSD
- Berkeley Software Distribution
派生物に、「著作権表示」「ライセンス条文」「無保証」の3つのドキュメントに含まれていれば良い
Creative Commons †
デジタルコンテンツを流通させるための様々な法的問題を回避するためのプロジェクト
以下の4項目について権利を主張する
- 表示
- 非営利
- 改変禁止
- 継承
ライセンスの互換性 †
ライセンスが同時に使うことができること
ライセンスに互換性がなければ、同時に使うことができない
- 複数ライセンスの選択
- 単一のライセンスではなく、使う人がその内のどれかを選択できるようにするもの
代表例:Perl, Ruby, Firefox
Lesson3 「ソフトウェア開発のプ †
ロセスモデルとコストモデル」[#q69e77ab]
ソフトウェアのライフサイクル †
- 開発計画
- 設計
- 開発
- 運用
- 保守
- 破棄
ソフトウェアプロセスの各工程 †
- 要求分析:要求定義
- 設計:システム設計、プログラム設計
- 実装:コーディング、プログラミング
- テスト:単体テスト、結合テスト、システムテスト、受入テスト
- 運用
- 保守
ライフサイクルモデル †
ウォーターフォール型 †
工程が上から下へ流れるモデル
各工程の区切りを明確にする
前の工程に戻ることをできるだけなくす
[問題点]現実にそぐわない状況が多い
設計とテストを対応させたモデル
- 要求分析 ⇔ 受入テスト(実際の運用と同じ状態)
- システム設計 ⇔ システムテスト(モジュールを組み合わせて)
- プログラム設計 ⇔ 単体テスト(1ファイル当たり)
- コーディング
スパイラルモデル †
全体を一気に作り上げようとしない
1+1+1+....+1=全体
[問題点]システム開発全体のリスクを管理しにくい
コストモデル †
ソフトウェアを開発するのにどれくらいのコストを要するのか見積もる
Halstead Model †
原始プログラムの命令数からプログラミングに要する作業量を求める
FP法 †
機能を単位として複雑度などからポイントを計算する
- 外部入力数
- 外部出力数
- 外部照会数
- 論理内部ファイル数
- 外部インタフェース
COCOMO(COnstructive COst MOdel) †
プログラマの作業量とコストの関係を統計的に計算する
ソフトウェアの予想されるコード行数に補正係数をかけ、コストを算出
- 基本COCOMO
ソフトウェアサイズ(E)=b*K*L*O*C^c
人月 †
1人が1ヶ月に行える作業量を表す単位
ソフトウェアプロセスの評価 †
組織に対して5段階のプロセス成熟度レベルのどこに当たるのか評価する
CMM, CMMI †
- レベル1「初期」
- レベル2「管理された」
- レベル3「定義された」
- レベル4「定量的に管理された」
- レベル5「最適化」
Lesson4 「ソフトウェアプロセスの各工程について<要求仕様・分析>」 †
※課題がでたみたいです→仕様書を作ってみよう
要求分析 †
「なにを」作るのか、「なぜ」作るのかを明確にする
要求の明確化 †
ソフトウェアのユーザが何を意図し、何を要求するのか明確化する
- 現行システム分析
- 問題点分析、ニーズ分析
具体的な問題点やニーズを列挙する
とことんまで具体化するのは難しい
- 要求の種類
- 機能要求
- ソフトウェアがなすべきこと
- 非機能要求
- 機能としては求められないが、ソフトウェアの品質として求められるもの
保守性、効率性など。主に開発者側に対するもの
要求の記述 †
分析の結果を、仕様記述モデル、もしくは仕様記述言語によって、仕様を記述する
要求仕様 †
「HOW」は書かず、「WHAT」を書く
- 要求を厳密に定義し、記述したもの
- 要求分析工程で仕様として表すもの
- 要求仕様は、動的なオブジェクトである
- よい要求仕様の条件
- 利用者
- 書くべきもの
- 概要
- シナリオ対象者
- 前提条件
- 入出力形式
- 異常値に対する応答
- その他
仕様のモデル化 †
UMLなどを用います
ユースケースモデル †
「WHO」「HOW」を記述
- 登場人物
- ユースケース:WHAT
- サブジェクト:HOW
- アクタ:WHO
- 関係:WHO with
- 注意点
- アクターは責務を表す
- 詳細を書きすぎない
- 昨日要求を表す
- 粒度に気をつける
開発の最初にすべきこ †
- 開発を本当に進めるか否かを決める
- 効果、利益、、コスト、スケジュール、社会などによる制約(資源、組織、市場、制度)
- 要求分析(何を作るのか、求められる性能の分析)
Lesson5 「ソフトウェアプロセスの各工程について<設計>」 †
Lesson6「ソフトウェアプロセスの各工程について<コーディング>」 †
Lesson7「ソフトウェアプロセスの各工程について<テスト>」 †
Lesson8 「ソフトウェアプロセスの各工程について<運用・保守>」 †
※課題がでたみたいです→興味をもった工程
Lesson 9「データの図式化」 †
DFD : Deta Flow Diagram †
- データの流れとその変換を記述する
- 構造化設計で用いられる
利点 †
- 直感的にわかりやすい
欠点 †
- UMLに採用されていない
登場人物 †
- プロセス
- データフロー
- データストア(データペベース)
- 外部実体(ターミネータ、情報源、情報出口)
プロセスへの入出力 †
- 入出力同士の論理的な関係は記述しない
フローチャート †
制御の流れを表す
登場人物 †
利点 †
誰でも理解できる
欠点 †
複雑な処理を表せない
アクティビティ図 †
フローチャートであるが、並列動作の記述が可能
登場人物 †
- 開始
- 終了
- 動作状態
- 分岐
- 並行分岐
- 並行合流
- 見張り
シーケンス図 †
登場人物 †
- アクター
- 時間
- オブジェクト(オブジェクト名:クラス名)
- 活性区間
- 生存線
- メッセージ
クラス図 †
クラス名、クラスが持つ造成と操作を表すための構造図
登場人物 †
- クラス名、変数、メソッド
- 汎化
- 集約
- コンポジション
- 関係
- 誘導可能性(矢印の元のオブジェクトが決まれば、矢印の先のオブジェクトが導ける)
- 多重度(クラスから作られたオブジェクトが、いくつあるのか定義)
- インタフェース
UML図を描くフリーのソフトは、アスター
CASEツール
参考資料 †
- 青空文庫
- Lesson2で紹介があった著作権が切れた文庫集
- Criative Commons Japan
- Lesson2で紹介があった、CCの日本ポータル。おしゃれ。
参考文献 †
- ソフトウェア工学の基礎 - 玉井哲雄 2008.08.02 岩波書店:?
- 本講義の教科書