ARCHIVE  ENTRY  COMMENT  TRACKBACK  CATEGORY  RECOMMEND  LINK  PROFILE  OTHERS
<< April 2011 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >>
2016.02.05 Friday

スポンサーサイト

一定期間更新がないため広告を表示しています

2011.04.23 Saturday

jdbcの性能

仕事でjdbcの処理速度を検証しました。

■ある検索処理について
・改善前
取得レコード数:4451(ほんとは9001だけど、途中でメモリエラー)
取得カラム数:278
フェッチ処理時間:24.51sec
1レコードあたり平均フェッチ処理時間:5.50msec

select * を使って、不要カラムも取得しているので、必要なカラムだけをselectするように改善。

・改善後
取得レコード数:9001
取得カラム数:7
フェッチ処理時間:10.12sec
1レコードあたり平均フェッチ処理時間:1.12msec

改善後が圧倒的に早い。
jdbcは遅いっていうけど、無駄なselectはよくない。
2011.04.23 Saturday

なぜハマる?新ゲームビジネスの秘密

ITホワイトボックス
 「なぜハマる?新ゲームビジネスの秘密」
です。

グリーとかモバゲーとかの話ですね。
会員数も利益もすごいんだそうです。

・バイラルループ(Viral Loop)
ウィルスに感染したかのようにユーザが広まること。
グリーの会員数は現在、2383万人。7年前の1万人からここまで伸びている。
携帯電話さえあればできてしまうこと。
無料でできてしまうこと。
気軽にできること。
友達を紹介することで仮想通貨が手に入ること。
そういう仕組みで増えている。

収益モデルはフリーミニアム。
全体の2割の人から収益の8割を上げてるんだそう。


SDK(Software Development Kit)
ソーシャルゲーム用のソフトウェア開発キット。
ライブラリ群とかエミュレータ、デバッガとか。。
そういえば、javaもSDKっていうよね。


・アジャイル開発
短い期間の開発を繰り返すソフトウェア開発手法。
ソーシャルゲームはバージョンアップでゲームがバージョンアップしていき、期間限定セール、イベントなど、ユーザを飽きさせないための工夫をしている。


個人的にはゲームとは思えないので、全くやらないけれど、ビジネスとしてはすごい。
スマートフォンの躍進で、ますます発達することでしょう。
手軽なゲームが人気になると、逆にコンシューマーゲームの採算がとれなくなり、ゲーム業界は衰退してしまわないだろうか。
ゼビウスの遠藤雅信が出ていた。
いまは、ゲーム会社の社長らしいです。
2011.04.12 Tuesday

SIMロック解除で何が変わるのか?

ITホワイトボックスより
「SIMロック解除で何が変わるのか?」

携帯電話のSIMカードとロック解除について。

・SIMカード
Subscriber Identity Module Card(契約者識別モジュール)
携帯電話1台に1枚挿して利用する。
携帯電話番号、メールアドレス、どの国の通信事業者を利用しているなどの情報を記録。
ヨーロッパで誕生した規格。

・SIMロック
日本の携帯電話の端末は、その通信事業者のSIMカードしか利用できないようロックがかかっている。
しかし、総務省がユーザの利用の選択肢を増やすという観点で2010年、ガイドラインを発表。
2011年4月以降に発売する携帯電話端末はロックを解除される。
ユーザは、携帯電話端末と通信事業者を自由に選択することが可能となり、サービスの競争から、コスト安になることも期待できる。

・LTE(Long Term Evolution)
新しい携帯電話の通信規格。FTTHくらいの通信速度がある。
ただ速くなるだけでなく、次世代通信規格として、LTEで統一される予定であり、そうなると、SIMカードを日本のすべての携帯電話端末で利用できることとなる。(現在は、SIMロックが解除されても、携帯電話端末の通信規格が異なると利用できない)

第3世代携帯電話
W-CDMA:ntt docomo, softbank
CDMA2000:au

第3.9世代携帯電話
LTE:ntt docomo(Xi 2010年12月24日より開始), softbank(2013年予定), au(2012年予定)

携帯電話は、ものすごい勢いでパソコンに近づいていってる。
2011.04.10 Sunday

新機種 続々! スマートフォンの違いとは?

 ITホワイトボックスいつの間にか再開してました。

第1回「新機種 続々! スマートフォンの違いとは?」
いま話題のスマートフォンについてです。

・オープンソースOS
android OSはオープンソースである。
オープンソースは自由に改造が可能であるが、改造したコードを公開しなければならない。
androidのOSの非コア部(付加機能)についての改造はコードの公開義務はない。
→開発企業にとってのメリットといえる。

・サンドボックスモデル
アプリケーションはアプリケーション境界を持ち、その範囲内でのみの実行権限を持つ。
GPS、個人情報、写真など。。
それらの機能を連携して使用する場合は、ユーザが許可をする。
→許可を悪用した利用したウィルスが存在する。

・ポストPC
androidが家電に組み込まれることにより、それぞれが従来のPCの役割を果たすという意味。
それにより、ネットワークを利用した家電の連携が将来、可能となる。

スマートフォンを語るときに、ほぼandroidの話題になってしまうあたり、いかにgoogleがスゴイかってことですね。
androidワクワクします。
会社でも取り入れていきたいという意向もあるし、個人でも興味があるので、勉強します。
2011.04.03 Sunday

【ファンクションポイント法】13.まとめ

ファンクションポイントの計算方法は以上です。

仕事を受注するのに必要かなと思っていたんですが、まず、基本設計が出来ていないとコレ、適用できませんね。。
で、基本設計をしたあとに見積もりをしているかというと、そんなプロジェクトはみたことがない。。
ステップカウントで、規模は出しますけど、それくらいかなあ。
それも、だいたい、品質の分析に使っていると思います。

仕事を受注するときの見積もりはというと、各工程にかかる人月を難易度づけして、求めてました。
では、この難易度の根拠はどこから算出したのか?
分からないので、聞いてみたいと思います。
会社の実績だったり、IPAの実績だったり、いろいろあると思いますが、まあ、見積もりはそれぞれであり、根拠を明確にすればいいのかなと感じました。
基準があれば、私もやれると思います。

テキストはまだ演習編へ続きます。
引き続き学びます。
2011.04.03 Sunday

【ファンクションポイント法】12.調整済みファンクションポイントの計算

未調整FP値とVAFから調整済みFP値を求める。
3つの計測タイプがある。

1.新規開発FP計測における計算法
新規開発におけるソフトウェアの規模。
システムアプリケーションと移行アプリケーションが対象。

DEP = (UFP + CFP) * VAF

DEP:新規開発FP計測のFP値
UFP:未調整FP値
CFP:データ移行機能のFP値
VAF:調整係数


2.機能拡張FP計測における計算法
機能拡張におけるソフトウェアの規模。
追加、変更、削除アプリケーションと移行アプリケーションが対象。

EFP = {(ADD + CHGA + CFP) * VAFA} + (DEL * VAFB)

EFP:機能拡張FP計測のFP値
ADD:追加導入される機能のFP値
CHGA:変更される機能のFP値
DEL:削除される機能のFP値
CFP:データ移行機能のFP値
VAFA:機能拡張FP計測後の調整係数
VAFB:機能拡張FP計測前の調整係数

3.アプリケーションFP計測における計算法
アプリケーション全体の規模。
初期と更新で2通りの計算方法を用いる。

・初期アプリケーションFP計測の計算
AFP = ADD * VAF

AFP:アプリケーションFP計測のFP値
ADD:未調整FP値
VAF:調整係数

・更新アプリケーションFP計測の計算
AFP = {(UFPB + ADD + CHGA) - (CHGB + DEL)} * VAFA

AFP:アプリケーションFP計測のFP値
UFPB:機能拡張FP計測前の未調整FP値
ADD:追加導入される機能のFP値
CHGA:変更される機能のFP値
DEL:削除される機能のFP値
CFP:データ移行機能のFP値
VAFA:機能拡張FP計測後の調整係数
2011.04.03 Sunday

【ファンクションポイント法】11.調整係数の計算

未調整FP値を補正する調整係数を求める。
→VAF(Value Adjustment Factor)

システムに関するGSCという14項目の特徴を評価し、0-5の評価点(DI:Degree Of Influence)をつけ、その合計(TDI:Total Degree Of Influence)からVAFを求める。

VAF = (TDI * 0.01) + 0.65

1.Data Communications(データ通信)
アプリケーションの通信度合い

0:バッチ処理のみ、またはスタンドアロン
1:バッチ処理だが、リモートでのデータ入力またはリモートでの印刷
2:バッチ処理だが、リモートのデータ入力およびリモートでの印刷両方
3:オンラインでデータ収集するか、バッチ処理のためのTP(遠隔操作)フロントエンド
4:フロントエンド以上の通信機能を持つが、1種類のTP通信プロトコルのみサポート
5:フロントエンド以上の通信機能を持つが、複数種類のTP通信プロトコルをサポート


2.Distributed Data Processing(分散処理)
アプリケーション構成要素間でのデータ転送の度合い

0:システム構成要素間でのデータ転送、データ処理機能に関与しない
1:PCの表計算やDBMSなどの構成要素でエンドユーザーコンピューティング(EUC)向けのデータを準備
2:エンドユーザーコンピューティング(EUC)のためではなく、データが転送のために準備され、システムのほかの構成要素に転送、処理される
3:一方向のみのオンラインでの分散処理とデータ転送あり
4:双方向でのオンラインでの分散処理とデータ転送あり
5:データ処理がシステムの最適な構成要素上で動的に実行


3.Performance(性能)
レスポンスタイム、スループットに対する要求おける開発影響の度合い

0:性能に対する特別な要求はない
1:性能条件と設計について要求が明言され、レビュー実施されるも、対応要求なし
2:レスポンスタイムまたはスループットがピーク時に厳しい状況だが、CPU使用率に対する設計上の特別な配慮は不要。処理の期限は翌営業日
3:レスポンスタイムまたはスループットが全業務時間中厳しい状況となるが、CPU使用に対する設計上の特別な配慮は不要。インターフェースをとっているシステムによって、処理の期限に制限あり
4:3に加え、ユーザーの指定した性能要件が厳しいため、設計段階で性能分析が必要
5:4に加え、ユーザーの指定した性能要件を満たすため、設計、開発、導入の段階で性能分析ツールを使用する必要がある


4.Heavily Used Configuration(高負荷構成)
コンピュータの資源制約における開発影響の度合い

0:運用上の制約は明示されておらず、暗黙的にもない
1:運用上の制約はあるが、通常よりも厳しくなく、特別の配慮は不要
2:セキュリティまたはタイミング上の配慮が必要
3:アプリケーションの特定部分に対して、特別なプロセッサ要件がある
4:指定された運用上の制約によって、セントラルプロセッサまたは専用プロセッサに関して特別の制約が必要
5:4に加えて、システムの分散構成要素に関してアプリケーションに特別な制約が必要


5.Transaction Rate(トランザクション量)
トランザクション量における開発影響の度合い

0:トランザクションのピーク期間はないと予測
1:トランザクションのピーク期間は、毎月、四半期、季節ごと、年に一回程度に予想
2:毎週トランザクションのピークがあると予想
3:毎日トランザクションのピークがあると予想
4:アプリケーションに対するユーザー要求、サービス契約の面でユーザーから高いトランザクション処理率が要求されるため、設計段階で性能分析作業が必要
5:4に加えて、設計、開発、導入の段階で性能分析ツールを使用する必要がある


6.Online Data Entry(オンライン入力)
データがインタラクティブに入力される度合い

0:すべてのトランザクションがバッチモードで処理
1:トランザクションの1〜7%がオンライン画面経由で入力
2:トランザクションの8〜15%がオンライン画面経由で入力
3:トランザクションの16〜23%がオンライン画面経由で入力
4:トランザクションの24〜30%がオンライン画面経由で入力
5:トランザクションの30%以上がオンライン画面経由で入力


7.End-User Efficiency(エンドユーザ効率)
ユーザの使いやすさやヒューマンファクターへの配慮の度合い

・以下の機能をカウント
メニュー、オンラインヘルプ、オンラインドキュメント、カーソル移動の自動化、スクロール、オンライントランザクションによる遠隔印刷、ファンクションキーの事前割当、オンライントランザクションからのバッチジョブ起動、画面上のデータのカーソルによる選択、反転表示、ハイライト表示、カラーアンダーライン表示およびその他の表示機能の多用、オンライントランザクションのユーザードキュメンテーションのハードコピー、マウスインターフェース、ポップアップウィンドウ、必要最小限の画面による業務機能の実現、二ヶ国語サポート(4項目としてカウント)、多言語サポート(6項目としてカウント)

0:機能のいずれも実現していない
1:機能の1〜3項目を実現
2:機能の4〜5項目を実現
3:機能の6項目以上を実現。しかし操作効率についてユーザーからの要求は特にない
4:機能の6項目以上を実現。さらに操作効率に対するユーザー要求が厳しいため、ヒューマンファクターに対する設計作業が必要である
5:4に加えて専用のツールおよび処理を用いて目的が達成されたことを証明する必要がある


8.Onlne Update(オンライン更新)
ILFがオンラインで更新される度合い

0:オンライン更新はない
1:1〜3のILFをオンラインで更新。更新量は少なく、回復は容易
2:4以上のILFをオンラインで更新。更新量は少なく、回復は容易
3:主要なILFをオンラインで更新
4:3に加え、データ損失保護が必須、特別な設計、プログラムあり
5:4に加え、更新量が多く、回復処理の費用面の考慮がなされている。オペレータの介在が最小となるような高度に自動化された回復手順が必要


9.Complex Processing(複雑な処理)
処理ロジック複雑さにおける開発影響の度合い

・以下の要素をカウント
 きめ細かい制御、または特有のセキュリティ処理
 広範な論理的処理
 広範な演算処理
 再処理が必要となる不完全トランザクションが原因での多くの例外処理
 多様の入出力機能を扱う複雑な処理

0:要素のいずれにも該当せず
1:要素のいずれか1項目に該当
2:要素のいずれか2項目に該当
3:要素のいずれか3項目に該当
4:要素のいずれか4項目に該当
5:要素の5項目すべてに該当


10.Reusability(再利用可能性)
アプリケーションを他アプリケーションでも利用可能とする場合の特別な配慮の度合い

0:再利用できるコードはない
1:再利用できるコードがアプリケーション内で使用されている
2:アプリケーションの10%未満で複数のユーザーのニーズを考慮
3:アプリケーションの10%以上で複数のユーザーのニーズを考慮
4:アプリケーションは再利用し易くするために特別なパッケージ化および文書化がされている。またアプリケーションはソースコードレベルでユーザーによりカスタマイズされる
5:アプリケーションは再利用し易くするために特別なパッケージ化および文書化がされていて、アプリケーションのカスタマイズはユーザーのパラメータ維持管理で可能


11.Installation Ease(インストール容易性)
前環境からの移行難易度における開発影響の度合い

0:導入に対してユーザーの特別な指定、特別な設置作業も不要
1:導入に対してユーザーの特別な指定はないが、特別なセットアップが必要
2:移行および導入にユーザー指定があり、移行および導入ガイドを提供するとともにテストされている。プロジェクトに対する移行の影響は重大ではない
3:移行および導入にユーザー指定があり、移行および導入ガイドを提供するとともにテストされている。プロジェクトに対する移行の影響は重大である
4:2に加えて、自動移行および自動導入ツールを提供するとともにテストされている
5:3に加えて、自動移行および自動導入ツールを提供するとともにテストされている


12.Operational Ease(運用性)
起動、バックアップ、復旧などの運用における開発留意の度合い

0:通常のバックアップ手続き以外、ユーザーからの運用上の指定は特にない
1〜4:アプリケーションに適用される項目を以下から選択。各項目1度数としてカウント。1.効率的な始動、バックアップ、回復処理が提供されているが、オペレータの介入も必要。2.効率的な始動、バックアップ、回復処理が提供されており、オペレータの介入が不要(2度数としてカウント)。3.アプリケーションは、テープマウントの必要性が最小限になるようにしている。4.アプリケーションは用紙操作の必要性が最小限になるようにしている。
5:アプリケーションは無人操作となるように設計されている。無人操作とは、アプリケーションの始動、シャットダウン以外はオペレーターがシステムを操作する必要がないことを意味する。自動エラー回復機能付アプリケーション。


13.Multiple Sites(複数サイト)
アプリケーションの利用度合い

0:複数サイトへの導入の要求はない
1:複数サイトへの必要性を考慮し、アプリケーションは同一のハードウェア、ソフトウェア環境だけで運用するように設計されている。
2:複数サイトへの必要性を考慮し、アプリケーションは類似のハードウェア、ソフトウェア環境だけで運用するように設計されている。
3:複数サイトへの必要性を考慮し、アプリケーションは異なるハードウェア、ソフトウェア環境だけで運用するように設計されている。
4:複数サイトでアプリケーションを使用するためのドキュメントとサポート計画が提供され、テストされている。アプリケーションの状態は1と2の記述の通り。
5:複数サイトでアプリケーションを使用するためのドキュメントとサポート計画が提供され、テストされている。アプリケーションの状態は3の記述の通り。


14.Facilitate Change(変更容易性)
アプリケーション変更を容易さの度合い

・以下の特性をカウント
 簡単な要求(eg-1つのILF)を処理するための柔軟な照会、レポート機能を提供
 平均的な要求(eg-複数のILF)を処理するための柔軟な照会、レポート機能を提供
 複雑な要求(eg-複数のILFに対する複数のロジック)を処理するための柔軟な照会、レポート機能を提供
 オンライン対話型処理によりユーザーが保守できるように、制御データが保持されるが、反映されるのは翌営業日
 オンライン対話型処理によりユーザーが保守できるように、制御データが保持され、直ちに反映される

0:特性のいずれにも該当しない
1:特性のいずれか1項目に該当
2:特性のいずれか2項目に該当
3:特性のいずれか3項目に該当
4:特性のいずれか4項目に該当
5:特性のいずれか5項目に該当

2011.04.03 Sunday

【ファンクションポイント法】10.未調整ファンクションポイントの計算

ファイル、アプリケーションで求めたFP値を合計し、それを未調整FP値とする。
2011.04.03 Sunday

【ファンクションポイント法】9.トランザクショナルファンクションの計測

アプリケーション境界ごとの要素処理の計測する。
要素処理の単位で、どれだけの情報をやりとりするかを値化。

1.アプリケーションに存在する要素処理を抽出
要素処理は「アプリケーション境界の決定」で抽出済み
【ファンクションポイント法】7.計測範囲の決定、アプリケーション境界の決定


2.要素処理をEI、EO、EQのいずれかに区別
要素処理を以下のいずれかに決定する。
・EI(外部入力)
→データ入力を受け付ける。

・EO(外部出力)
→データを加工し、出力する。

・EQ(外部照会)
→データを加工しないで出力する。


3.要素処理のデータエレメントタイプとファイルタイプリファレンスを数える
・DET(Data Element Type)
→要素処理がアプリケーション境界をまたいで使用し、かつユーザが認識できる繰り返しのないデータのフィールド数。
 ボタンなどのトリガーも1と計上する。
 ユーザが認識できるフィールドであるが、キー値も1と計上する。

・FTR(File Type Reference)
→要素処理が参照、更新などでアクセスするファイル数。

を計測し、要素処理の複雑度を求める。


4.要素処理の複雑度を求める
以下の表から要素処理の複雑度を求める。
・EIの複雑度の求め方

1 - 4DET5 - 15DET16以上DET
0 - 1 FTRLowLowAverage
2FTRLowAverageHigh
3以上FTRAverageHighHigh

・EO、EQの複雑度の求め方

1 - 5DET6 - 19DET20以上DET
0 - 1 FTRLowLowAverage
2 - 3FTRLowAverageHigh
4以上FTRAverageHighHigh


5.複雑度から要素処理のFP値を求める
以下の表から要素処理のFP値を求める。
・FP値の求め方

LowAverageHigh
EI346
EO457
EQ346
Powered by
30days Album
PR