マガジンのカバー画像

ソフトウェア品質

159
ソフトウェア開発、システム開発について、全工程を対象に保証すべき品質のあり方について、あまり世の中では見かけない点について、メモっています。自身の備忘録も兼ねており、統一感はない…
運営しているクリエイター

#IT産業

[品質評価基準] 議事録

みなさんは議事録をレビューするとなった場合、具体的にはどのような観点で、どのようなポイン…

500

テスト時の間違った品質分析

ソフトウェア開発における品質分析の手法は色々あれど、それらは確かに評価するために用いる……

障害管理はこれで完璧(2/2)

はい、先日の続きです。 4.対策方法の特定ここは「3.問題原因の特定」で特定できた原因がとて…

1,000

障害管理はこれで完璧(1/2)

ちょっと長すぎてへばってきたので、複数に分割したいと思います。 ソフトウェア開発において…

1,000

決まらないくせに変わりやすいのが要件

要件定義とはお客さまがシステムを使って実現したいことを明確にすることです。決して「何を作…

なぜ出来損ないのシステムを使わなければならないのか

ソフトウェアやシステムのリプレース(再構築)や改造の引き合いを受けることがあります。そん…

類似見直しに要するコストはいくら?

「何かをするときは必ず仮説や試算をすべし」 というのは、いくつになっても、どんな業界でも、どんなシチュエーションでも大抵必要です。必要ないのは、反射神経が求められるようなシーンだけ。 じゃあ、実際普段何気なく行っている作業1つ取って試算してみるとどうでしょう。たとえば、 要員構成:5名(リーダ1名) 開発期間:1年(総期間) 開発規模:機能 = 70画面/30帳票      規模 = 250kstep 作業対象:基本設計~システムテスト完了まで 発生工程:結合テスト 不

「現行通り」は惑わせる言葉

少々気になる記事を見つけたので、私なりの見解を書き残しておきたいと思います。 こうした現…

「表面的な原因を取り除くことを対策とする」という人

は、おそらく原因を深く掘り下げて考えることが苦手な人です。 たとえば、「料理が塩辛かった…

なぜ不良を検知するためのテストフェーズで、不良が見つけられないのか

細かいことを言い出すと原因は無限に出てきますが、マクロな視点で分類するなら、次の3点に絞…

効率性はアーキテクチャの設計で作りこまれる

"非機能"と言うと、とかく機能やプログラムの「性能」面ばかり気にしてしまいますが、実際には…

機器やシステムの信頼性の評価式

システムや機器は故障しないに越したことはありません。 しかし、故障そのものの発生をなくす…

500

上流工程ほどいいかげんな品質管理

ソフトウェア開発の世界では、よくいわれる格言に、  「上流工程のバグは、下流工程で増幅す…

500

レビュアーの心得

レビュアーとは、「レビューをする人(Reviewer)」のことです。「レビューアー」と言うか、「レビューワー」と言うか、あるいは「レビュワー」と言うのか、その辺は好きにしてください。たぶん中身は一緒です。 レビューとは、直訳するならば「評論・再調査」を意味する言葉になります。とりわけIT現場では多用されていますが、特にIT業界というだけでなく、ビジネスの現場ではどこでも使用されます。批評・再評価する対象が異なるだけでしかありません。ですから、どこにいたとしても、  「レビ

¥500