シェア
んー、寒暖差が大きくなってそれでいて空気が乾燥する季節。 一番苦手かも知れません。 ・…
顛末書（てんまつしょ）とはトラブルの一部始終…ことの顛末を報告するための文書のことを言い…
これは、JSTQB（Japan Software Testing Qualifications Board）の定める 「テストの７原則…
昨今、ＵＩ／ＵＸと言う言葉などがもてはやされて久しいものですが、ＵＸはともかくＵＩなどは…
「ＩＴ業界」と一般に呼称される私たちの業界は、正式には「情報サービス産業」と言って、サー…
はい、先日の続きです。 4.対策方法の特定ここは「3.問題原因の特定」で特定できた原因がとて…
ちょっと長すぎてへばってきたので、複数に分割したいと思います。 ソフトウェア開発においては「モノづくり」を実際にしている設計や実装の作業において品質を証明することはできません。品質を意識した設計や実装はできても、それ自体を証明することはそこではできません。 あくまで レビュー（設計工程のテスト） テスト によって、作りこんだ作業や成果物の品質を検証し、保証します。裏を返せばレビューやテストをまともに実施していないプロジェクトというのは、何も品質を保証しないまま先に
問題解決において自ら解決できない場合、他者、他部署に依頼することもあると思います。私は基…
『エンジニアは往々に決断をすることが"弱い"』 と世間ではよく言われています。 特にＢ２Ｂ…
何をするにしても「計画」と言うのは、最後に期待する結果を思い描いているからこそできること…
プライベート…と言うか、自分に非がある時は結構「さっさと謝ってしまおう」派の私ですが、問…
意外と理解されている方は少ないと思うのですが、本来、ソフトウェア開発業、システム開発業は…
「手戻り」と言う表現を使う業界と使わない業界があるかも知れませんので、簡単に説明しますと…
ソフトウェア品質において、各工程ごとのプロセスや中間成果物の品質を見るのはとても大切なことです。けれども、それらは目標のための手段であって、それ自体が目標ではありません。 ソフトウェア品質の最終目標は、「定義通りの機能を、ユーザーに利用してもらうこと」です。つまり、最後の最後まで品質状態が維持できて、初めてその存在意義が認められるというものです。 どんなに途中の経過が順調でも、最後がダメならやはりダメなのです。かと言って結果主義と言うわけではありません。わざわざ途中経過の
