ソフトウェア品質の12の属性
システム開発において「品質の向上」という標語がしばしば掲げられますが、 「品質の属性」については無頓着なケースが多いのではないでしょうか。 ひとくちに品質といっても多様な属性があります。 顧客と品質の話で揉めたことはありませんか？ 品質には多様な属性があり、単一の軸で良しあしを決められないという側面があります。 そのため、単に「品質」と言ってしまうと認識に齟齬が生じるのです。 Karl E. Wiegers氏が著書 「ソフトウェア要求」 で挙げた、すべてのプロジェクトが検討すべき12の属性は以下のとおりです。 可用性availability 動作可能時間の指標。システム故障までの平均時間MTTF(Mean Time To Failure)を 平均修復時間MTTR(Mean Time To Repair)とMTTFの合計で割った値。稼働率とも呼ばれる。 効率性efficiency 同じ処理性
痛い目に合わないとわからない - masayang's diary
酔狂人の異説: ウォーターフォール型開発は最初から破綻している? そもそも、洗い出せていないリスクや問題点が存在しないって、どうして言えるんだろうか。存在しないことの証明は、「悪魔の証明」って言われるほどで、事実上不可能なのに。存在しないことの証明ができるなら、プログラムにバグの無いことの証明もできるだろう。最初から不可能なことをできると考える時点で、既にウォーターフォールは破綻しているということ。 そのとおり！ でもね... 洗い出せていないリスクや問題点を吸収できるだけの「ゲタ」を履かす事で、破綻する確率を下げる事ができる。 その「ゲタ」は例えば下記の通り： おびただしい量の成果物を記述するための労力分を余裕をみて請求する。 プロジェクト後半で発覚する問題点を押さえ込むための労力分を余裕をみて請求する。 それらのゲタを見越した顧客の値引き要求に対するさらなるゲタ。 その値引き要求に対す
ウォーターフォール型開発は最初から破綻している? - 酔狂人の異説(新館)
ウォーターフォール大好き人間達にいつも言われたことは 「リスクと問題点は全て洗い出して解決しなきゃいかんのです。 随時解決するなんてリスクはとれませんよ」 よくよく思えばやり始めていきなりわかるほうが対策が打てる分有利だよなとしみじみ思った。 そもそも、洗い出せていないリスクや問題点が存在しないって、どうして言えるんだろうか。存在しないことの証明は、「悪魔の証明」って言われるほどで、事実上不可能なのに。存在しないことの証明ができるなら、プログラムにバグの無いことの証明もできるだろう。最初から不可能なことをできると考える時点で、既にウォーターフォールは破綻しているということ。
ドメインモデリングよりもユーザーインターフェースを (arclamp.jp アークランプ)
S/N Ratioで紹介されていた「ソフトウェアアーキテクトが知っておくべき10のこと」が、いい感じです。佐藤さんの紹介をそのままに。 人がプラットフォーム (People are the platform) すべてのソリューションは時代遅れ (All solutions are obsolete) データは永遠だ (Data is forever) 柔軟性が複雑性を生む (Flexibility breeds complexity) 期待通り動くものはない (Nothing works as expected) ドキュメントは普遍的なソースコード (Documentation is the universal source code) ビジネスを知るべし (Know the business) ビジョンを維持せよ (Maintain the vision) ソフトウェアアーキテクトもコー
設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージＩＤのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版２」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく３つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
株式会社マジカジャパンの羽生章洋が書いてるブログ:大雑把でもいい - livedoor Blog（ブログ）
システム化・IT化で失敗しがちなのは、これまで全くといっていいほど何も管理してこなかったのに、せっかく多額の予算を割くのだからといきなりものすごく詳細に精密に物事を管理しようとして運用が回らなくなるというケースです。 そういうとこれまた極端な話が出てきて、言わば0/1のような感じで「だったらやるだけ無駄だ」という風になってしまい現状追認で終わってしまうということも見受けられます。ですが現状のままであるということは問題はそのままなのが当然なので、それが自然に勝手に解決して欲しいと思っても、そこにはちょっと無理があるように思うのです。 いきなり精緻にやらなくてもいい。まずは大雑把でいい。出来る範囲だけでいい。始めることに意義があると考えて、実際にやることが重要だと思うのです。そして成果が出てくると、段々とやる気も高まってきます。 何も最初から無用に目標を高く設定する必要などないのです。本当に目
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
それはYAGNIか? それとも思考停止か?
インハウス開発とか | 眠る開発屋blog