レスポンスタイム（応答時間）
・オンラインシステムの性能指標
ターンアラウンドタイム
・バッチシステムの性能指標
スループット
・処理能力は、データ量や命令数を利用
2025年7月29日火曜日
システムの性能評価指標
・オンラインシステムの性能指標
・バッチシステムの性能指標
・処理能力は、データ量や命令数を利用
クロニクル Win11+EclipseでHelloworld
windows11です。
1.Pleiades Eclipseをダウンロード
2023版 Ultimateをダウンロード
2.ダウンロードしたものを実行
ダウンロードしたファイルを実行して、
c:¥pledias
へ展開する。
3.Eclipse起動
c:¥pledias¥2023¥eclipse¥eclipse.exe
を起動。
4. 確認
Eclipseで、[ファイル]-[新規]-[Javaプロジェクト]で、プロジェクト名は適当で作成
パッケージエクスプローラーで、当該プロジェクトを選択して出てくるメニューから
[クラス]を選択。
名前は適当。「どのメソッド・スタブを作りますか？」で、
mainを作るように指定する。
作成されたスタブのmainへ、
System.out.println(“Hello world”);
を追加。
実行するとコンソールに
Hello world
が出力されます。
動いているようです。
2025年7月28日月曜日
システムの信頼性指標
MTBF(Mean Time Between Failures)
・システムが障害から復旧して、次の故障が発生するまでの時間（連続稼働している時間）
MTTR(Mean Time Between Repair)
・故障が発生してから復旧するまでの平均時間
稼働率
・稼働率 ＝ MTBF／（MTBF＋MTTR）
2025年7月27日日曜日
2025年7月24日木曜日
ガベレージコレクターの方式
1. 参照カウンタ方式
・オブジェクトを参照している数をカウントして
参照数が、ゼロになると、メモリから解放する。
・孤立した循環参照があると参照数がゼロとならず
メモリリークが発生する。
2.マーク&スィーブ方式
グローバルオブジェクトから到達不可能なオブジェクトを
メモリから解放する。
2025年7月23日水曜日
2025年7月10日木曜日
Testing of mobile applications. A review of industry practices
公開されている
Testing of mobile applications. A review of industry practices
のキモ部分を読んで勉強してみたいと思います。
概要
目的
モバイルアプリケーションのテストに関してのリサーチである。
方法とツールについて、実際の企業での利用を調べる。
方法
リテラル・レビューとリサーチである。
はじめに
ソフトウェアのテストは、期待される結果と実際の結果を
比較するもの。ソフトウェアのテストには、セキュリティ、
信頼性、正確性などが含まれる。
この論文は、モバイルアプリケーションのテストに関するもの。
モバイルアプリケーションには、ネイティブなものと、
Webアプリケーションを含む。
次のようなリサーチ・クエスチョンを調べる。
・モバイルアプリケーションのテストの方法
・モバイルアプリケーションのテストにおける困難さ
・困難への企業への対応
伝統的なソフトウェアのテストとモバイルアプリケーションのテスト
の違いは、次である。
(1) モバイルアプリケーションでは、開発者は、OSの違い
ディスプレイサイズの違い、パフォーマンス、バッテリーなど
を考慮しなければならない。
(2) スマートフォンは、キーボード、音声など、
様々な入力方法をサポートしている。
アプリケーションもそれを考慮しなければ、ならない。
(3) モバイルサービスは、3G、4G、Wi-Fiなど様々な通信環境を
サポートしている。モバイルアプリケーションは、これを考慮しなければ
ならない。
(4) モバイルデバイスは、多様で、それぞれテストが必要となる。
これには、シミュレータが用いられることが多い。
また、次のような制約がある。
リソースの制約、センサーなどのデバイス、新しいGUIなど。
また、中断時のテスト、インストールのテストなども必要である。
モバイルのソフトウェアのテストに関する問題は、
デバイスの多様性に関するものが多い。スクリーンサイズ、解像度、
メモリサイズ、色々なネットワーク環境のサポートなどである。
RELATED WORK
テストの分類を以下に示す。
・ホワイトボックステスト
プログラムのソースコードに基づいてテストする。
・ブラックボックテスト
内部の構造は考慮せずにテストする。データが正しく処理されるか、
など。
・ユーザビリティテスト
ユーザのエクスペリエンスに関して、欠陥や改善点を見つける
・Quality of Service テスト(QoSテスト)
パフォーマンス、信頼性、可用性などを確認する。
モバイルアプリケーションに関しては、ネットワークの影響が大きい。
モバイルアプリケーションでも、ユニットテスト、結合テスト、システムテスト
が行われることが多い。
2025年7月1日火曜日
論文 A guide to Lean Software Development Transformation
「A guide to Lean Software Development Transformation」のキモ部分です。
間違っていたら、ごめんなさい。
1.概要
アジャイルをスケールアップする方法として、リーン開発が提唱されている。
この論文の目的は、アジャイルをリーン開発へ変更することについて
（１）そのメリット（２）変更点（３）変更を測定するメトリクス
を明らかにすること。
その方法として、 Systematic Literature Review(SLR)を利用した。
結果、主なメリットとしては、次があった
（１）時間の削減 （２）フローの改善 （３）継続的な改善（４）欠陥のFIX率の改善
主な変更点としては、次があった
（１）マインドセットを変えること （２）無駄の削減のコンセプトの理解 （３）スケールのフレキシビリティ
利用されるメトリクスとしては、（１）リードタイム が最も使われていた
１．はじめに
リーンソフトウェア開発は、開発プロセスを最適化するために、ムダを削減するものである。
この論文の目的は、アジャイルからリーンへの変更に関して、そのメリット、変更点、利用されるメトリクスを明らかにすること。
２．SLR
Systematic Literature Reviewは、文献をシステマティックな方法でまとめるもの。
A.Needs for an SLR
アジャイルからリーンへの変更に関しての研究は、ウォーターフォールから、アジャイルへの変更に関しての研究に比較して、少ない。
B.リサーチクエスチョン
RQ1 アジャイルにリーンの原則を組み込むことで、どんなメリットがあるか
RQ2 アジャイルにリーンの原則を組み込むことで、どんな変更があるか
RQ3 アジャイルにリーンへ変更することに関して測定するメトリクスは
C.Search strategy & Study selection
省略
D. Study quality assessment criteria
対象の１８の論文に関して、目的に合っているかを確認するために、次の調査を行った。
c1. アジャイルが変更前の状態か
c2.実際に、リーンソフトウェア開発のプラクティスを採用したか
c3.変更のメトリクスがあるか
3.SLA Result
A.benefit (RQ1)
レポートされているbenefitを分析した
(1)リードタイムの短縮
もっとも多く報告されているbenefitであった
(2)フローの改善
(3)継続的な改善
B.challenges(RQ2)
アジャイルから、リーンへの変更には、いろいろなことが必要となる。プロセスの可視化、持続性のマネジメント、チーム間のコミュニケーションが、よく見られるものである。
テストプロセスの変更もよく重要な変更と言われる。それは、ソフトウェアの欠陥に関して、真の原因を見つけるものである。
アジャイルからりーんへの変更のキモとして、ムダの最小化と品質の改善がある。
C.メトリクス(RQ3)
(1)リードタイム
(2)欠陥数
単位時間当たりの欠陥など
(3)欠陥の修正時間
(4)Velocity
Velocityは、タスクの完了に必要と予測した時間を、実際にかかった時間で、割ったものである。
(5)Line of code
(6)イテレーション事のストーリー数
(7)リリースの頻度
4.結論
概要と同じ
登録:
コメント (Atom)