前回は、品質管理の勘所として次の4点を挙げ、最初のポンインについて考察しました。（1）品質指標の妥当性と目標値の意味づけ、（2）設計品質と開発品質、（3）プロセス品質とプロダクト品質、（4）非機能要件に関する品質の確保――。今回は残りの（2）～（4）のポイントを見ていくことにしましょう。 後藤 年成 マネジメントソリューションズ 取締役 PMP 私はプロジェクトの現場で「良いシステムを開発するために、テスト期間を長めにとって、たくさんテストを実施しましょう」という言葉を何度か耳にしたことがあります。「品質を上げるには、テストでたくさんのバグを出せばよい」と信じている方もいらっしゃいます。 確かに、アジャイル開発のように「設計～テスト」を繰り返し実施することで品質を実用レベルに高めていく開発手法もあります。しかし、ウォーターフォール型の一般的な開発手法においては、上流工程（要件定義や基本設計
システムインテグレーションにとどまらず運用のエキスパート（専門家）をもシステムに統合する──。垂直統合型システムの後発であるIBMがPureSystemsに込めた秘策は、これだ。運用負荷の増大に悩むユーザー企業のニーズに応え、ライバルに対抗するべく「現段階のベストを追求するだけでなく企業システムの次の10年を見据えて開発した」（日本IBMの橋本孝之会長）のである。 システム管理ソフトからのアラートを通じて異常の兆候を見抜き（インシデント管理）、原因を特定して適切な解決策を選び（問題管理）、システムリソースの追加など障害対策を実施する（変更管理）。システムの維持管理で最も重要なこれらのプロセスを、PureSystemsでは、非機能要件などを定義した「パターン」を組み込んだ運用管理ソフトによって遂行する。IBMが提唱してきたオートノミック・コンピューティング（自律型コンピューティング）のコンセ
性能や信頼性、保守性といった非機能要求は情報システムの高度化・大規模化が進むに伴って、その重要性が改めてクローズアップされている。あいまいにしたままシステム開発を進めるのはあまりにもリスクが大きいからだ。 こうしたなか「システム基盤の発注者要求を見える化する非機能要求グレード検討会」はこの5月に非機能要求グレードを公開した（図1）。検討会はNTT データ、富士通、NEC、日立製作所、三菱電機インフォメーションシステムズ、OKIの6社が2008年4月に共同で発足させた。 非機能要求グレードの目的は、「早期に」「誤解なく」「漏らさずに」非機能要求を発注者が受注者と共同で定義して、かつ、合意できるようにすること。これまでの非機能要求定義の難しさを克服するため、非機能要求で決めるべき項目を定め、その具体例を段階的に「見える化」することで、発注者が非機能要求を決めやすくしている。 「機能以外」だから
Webアプリケーションの画面を設計するとき、皆さんは性能について意識していますか。機能面の要望を取り込むことに集中するあまり、性能は二の次になっていないでしょうか。 あとになって性能が問題になるプログラムは、設計時に過ちを犯していることが少なくありません。そのような性能トラブルは、チューニングで簡単に解決しないことが多いものです。設計時に性能リスクを明らかにして早めの対策を打っておけば、致命的な性能トラブルの多くを防げます。 今回は設計段階で性能リスクを早期に発見するための性能見積もり手法について紹介します。設計段階で性能を作り込む手法には、多様なものがありますが、今回解説するのはその前段階として必要になるものです。どの機能に対して、工数をかけて性能を作り込むべきかを明らかするのが狙いです。 性能を見積もるメリットは二つ 設計段階では動作するプログラムが存在しないので、性能評価においては、
今回は、性能要件を具体化するポイントを紹介します。皆さんは、性能要件に何を定めればよいと思いますか。 システムの性能要件で、「Webアプリケーションの画面レスポンス時間は3秒以内であること」「バッチアプリケーションは毎日午前0～午前5時の間に終了すること」としか定義していないプロジェクトを見かけます。この場合、以下のような問題が潜んでいます。 （1）全機能の処理時間を同じレスポンス時間に収めなければならない 全機能に対して同じレスポンス時間を目標とするのは現実的ではありません。なぜなら、機能によって求められるレスポンス時間と処理の複雑度は異なるからです。 例えばコールセンターのシステムで、「（a）電話オペレーターが操作する画面」と「（b）管理者がマスターデータをメンテナンスする画面」があるとします。レスポンスの悪化が直ちにビジネス機会の損失につながる（a）の方が、求められるレスポンス時間は
性能要件の実現は重要だと認識しながら、「結局、性能は構築し終わるまで分からない」といったスタンスでプロジェクトに臨んでいないでしょうか。最初に性能要件を定義したあとは特に何もせず、カットオーバー直前にわずかな性能テストとチューニングを行うだけというケースを、筆者はよく見かけています。 そのようなスタンスでシステムを開発しても、性能要件をしっかりと実現できる可能性は高くありません。カットオーバー直前にその場しのぎの対策をするか、巨額の追加コストをかけてハードウエア増強に走る、といった状況に追い込まれがちです。 ITシステムの性能品質は本来、ライフサイクル全体を通して作り込むものです（図1）。設計、実装、テストの工程を通じて、システムの性能要件達成に取り組み、検証していく必要があります。 本連載では「システムの性能を確保するために何をすべきか」というテーマで、性能をマネジメントするための考え方
一定期間において、そのうちシステムがどの程度の割合で正常稼働しているかを示す数値。文献によっては、可用性と呼ばれることもある。 稼働率は、システムの平均故障時間（MTTF：Mean Time To Failure）と平均修復時間（MTTR：Mean Time To Repair）を用いて算出する。具体的には、MTTFは、システムが故障などによって停止するまでの平均時間を示すもので、たとえば、平均して6カ月に1回の割合でシステムが停止する可能性があるとすれば、このシステムのMTTFは6カ月ということになる。逆の見方をすれば、MTTFはシステムの平均連続稼働時間と考えることもできる。 一方のMTTRは、停止状態になったシステムを稼働状態に復旧するまでにかかる時間で、たとえば平均30分で復旧できるとすれば、MTTRは30分になる。 これらMTTFとMTTRの値を使用して、稼働率は以下の式から算出
セキュリティ要件の導き出し方 Webシステムは，攻撃を受けやすい特性を持っています。その理由の一つは，HTTP（HyperText Transfer Protocol）というシンプルなプロトコルを使うことにあります。テキスト形式のプロトコルなので，クライアントとサーバーが送受信するメッセージ内容を盗み見される危険があります。不正にリクエスト（要求）メッセージを書き換えられるかもしれません。公開されたプロトコルを使用するので，インターネット上に公開するWebシステムでは，多数のリクエスト・メッセージを同時に送り込んで回線やサーバーを混雑させる「サービス妨害（DoS）」と呼ぶ攻撃を受ける恐れもあります。イントラネットのWebシステムでも，社員がデータベースから無断で情報を抜き出したり，自分の都合のよいようにデータを書き換えたりする危険があります。 こうした特性をよく認識してWebシステムを設計
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
