スポンサーサイト

 --------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

スポンサーサイト の続きを読む


カテゴリ :スポンサー広告 トラックバック(-) コメント(-)

今日のブックマーク ~性能品質~

 2008-03-07
参考記事

@ITより 保存版 性能品質の作り方

今までなんとなくで行ってた性能品質
「動けばいいや」を目標に完成したシステムで
思った以上に性能が出なくて、
もう手を打てません状態にならない為のヒントが、
工程ごとに解り易く説明されています。

自分なりに気付かされた事は、、

要件として、、
■モニタリングできる仕組みを要件定義の段階で考慮しておく
 超簡単に言うと、想定閾値でのレスポンスタイムとそれを計る為の手段(ログ等)
■性能の有効期間も考慮する
 例えば有効期間を5年として、1年目のデータが1万件、2年目が2万件と
 増えていった時に有効期間である5年後のデータ量でも性能要件を
 満たしているかという事


要件が出揃った所で、実際のアーキテクチャ構築に入ります。

これは色々なパターンがあるので適時考える必要があるのですが、
(SEの一番の腕の見せ所かもしれません)
まぁ、この処理は重そうなのでバッチにしようとかここはSQL一発でとか
そういう所をよく考えてねって事です。

さらにプログラミングにはいって、
無駄なループや不要な条件分岐、メモリ食いすぎ見たいな点をチェックしつつ、


テストに突入、
単体テストで思ってる性能がでないと、
当然のごとくそれ以後では性能は確保できないので
ますは単体レベルで整えていきます。


そしてめでたく完成!!

と思う前に、

運用レベルので性能監視と診断レベルを決定
このあたりは最初の要件定義の品質が効いてきます
実際の運用ルールまで要件定義の段階から頭に入ってないと
保守の名目でとんでもない事になってしまいます。。

上流工程恐ろしや、頼むから変なモノ作り逃げしないでね。


よろしければポチっとお願いします。(変な所には飛びません(^^))

今日のブックマーク ~性能品質~ の続きを読む


≪ トップページへこのページの先頭へ  ≫
halken800 Twitter
最近の記事
カテゴリー
タグリスト
最近のコメント
最近のトラックバック
広告



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。