シェア
みなさんは議事録をレビューするとなった場合、具体的にはどのような観点で、どのようなポイン…
ソフトウェア開発における品質分析の手法は色々あれど、それらは確かに評価するために用いる……
はい、先日の続きです。 4.対策方法の特定ここは「3.問題原因の特定」で特定できた原因がとて…
ちょっと長すぎてへばってきたので、複数に分割したいと思います。 ソフトウェア開発において…
要件定義とはお客さまがシステムを使って実現したいことを明確にすることです。決して「何を作…
ソフトウェアやシステムのリプレース(再構築)や改造の引き合いを受けることがあります。そん…
「何かをするときは必ず仮説や試算をすべし」 というのは、いくつになっても、どんな業界でも、どんなシチュエーションでも大抵必要です。必要ないのは、反射神経が求められるようなシーンだけ。 じゃあ、実際普段何気なく行っている作業1つ取って試算してみるとどうでしょう。たとえば、 要員構成:5名(リーダ1名) 開発期間:1年(総期間) 開発規模:機能 = 70画面/30帳票 規模 = 250kstep 作業対象:基本設計~システムテスト完了まで 発生工程:結合テスト 不
少々気になる記事を見つけたので、私なりの見解を書き残しておきたいと思います。 こうした現…
は、おそらく原因を深く掘り下げて考えることが苦手な人です。 たとえば、「料理が塩辛かった…
細かいことを言い出すと原因は無限に出てきますが、マクロな視点で分類するなら、次の3点に絞…
"非機能"と言うと、とかく機能やプログラムの「性能」面ばかり気にしてしまいますが、実際には…
システムや機器は故障しないに越したことはありません。 しかし、故障そのものの発生をなくす…
ソフトウェア開発の世界では、よくいわれる格言に、 「上流工程のバグは、下流工程で増幅す…
レビュアーとは、「レビューをする人(Reviewer)」のことです。「レビューアー」と言うか、「レビューワー」と言うか、あるいは「レビュワー」と言うのか、その辺は好きにしてください。たぶん中身は一緒です。 レビューとは、直訳するならば「評論・再調査」を意味する言葉になります。とりわけIT現場では多用されていますが、特にIT業界というだけでなく、ビジネスの現場ではどこでも使用されます。批評・再評価する対象が異なるだけでしかありません。ですから、どこにいたとしても、 「レビ