sho1884

テスト設計や、USDM及び機能と品質を統合した要求系統図法など、ソフトウェア品質コンサ…

sho1884

テスト設計や、USDM及び機能と品質を統合した要求系統図法など、ソフトウェア品質コンサルに従事。 https://www.facebook.com/profile.php?id=100005139097129 　　 https://qiita.com/sho1884

ソフトウェアテスト設計の品質を検算する方法（その②）

問題の在り処その①の稿で示したのと同様、プログラマが間違えそうなところと、テスト設計者が見落としそうなところは重なっている可能性が高いことを問題であると考えています。 ソフトウェアテスト設計の品質を合理的な範囲で検算可能な場合があるので、本稿でもその方法の一つを示します。 前稿とは異なり、ここで示すものはソフトウェアテスト設計の範囲の中で、異なる二つの設計技法で設計されたものの間での検算になります。 こう説明すると、「結局設計にわざわざ２度手間をかけるということですね？」

sho1884

    • ソフトウェアテスト設計の品質を検算する方法（その①）

      問題の在り処少し考えればすぐに気付くことですが、プログラマが間違えそうなところと、テスト設計者が見落としそうなところは重なっている可能性が高いでしょう。 複雑で厄介な問題となる部分は両者にとって変わりなく共通となるはずですから、これは当たり前ということになってしまいます。これは実に困ったことです。 ソフトウェアテスト設計の品質を合理的な範囲で検算可能な場合があるので、本稿ではその方法の一つを示します。 松尾谷[1]が示した［簿記の歴史に学ぶ］検算による品質向上 松尾谷[

      sho1884

      • 要求体系化のための『機能・品質要求系統図法』の勧め

        全体の整合性やバランスの取れた品質、トレーサビリティのためにシステムや製品の開発において、個々の要求毎に対する品質だけではなく、要求の全体集合に対して、その整合性やバランスの取れた品質、またトレーサビリティ確保が重視されるようになってきています。要求集合を体系化する一貫した方法論へのニーズが高まっている、と言えると思います。 ここではその体系化にお勧めの方法として、機能・品質要求系統図法を紹介します。(SysMLの要求図を使用した表現で示していますが、SysMLを使う必要は

        sho1884

        • ロジックとアーキテクチャの境界を設計する（その１）　～設計者やプログラマにお勧めする原因結果グラフ技法～

          UMLやSysMLと同等の位置づけで原因結果グラフ活用をお勧めする理由 原因結果グラフ技法は、ソフトウェアテストの国際規格ISO/IEC/IEEE 29119の中にも示され、ソフトウェアテストのテスト設計技法として知られているものです。しかし、ここでは特に開発設計者やプログラマの皆さまに役立てて頂くことを念頭に置いて、この技法を数回に分けて紹介しています。 原因結果グラフ技法がテスト技法としてよく知れ渡るに至っているのは、デシジョンテーブルが自動生成できるとか、テスト数を減

          sho1884

        ソフトウェアテスト設計の品質を検算する方法（その②）

        sho1884

        • ソフトウェアテスト設計の品質を検算する方法（その①）

          sho1884

        • 要求体系化のための『機能・品質要求系統図法』の勧め

          sho1884

        • ロジックとアーキテクチャの境界を設計する（その１）　～設計者やプログラマにお勧めする原因結果グラフ技法～

          sho1884

          ブールグラフでロジックを整理してデシジョンテーブルと条件式を自動生成する　～ 設計者やプログラマにお勧めする原因結果グラフ技法 ～

          設計者やプログラマにお勧めしようと考えた理由原因結果グラフ技法は、ソフトウェアテストの国際規格ISO/IEC/IEEE 29119の中にも示され、ソフトウェアテストのテスト設計技法として知られているものです。しかし、この技法やツールを使い込んで思うことは、まずは開発設計のために使う方がずっと有益だし、合理的だということです。 また、私は多数のコンサルの現場でこの技法を紹介してきているのですが、少し実装にまで踏み込まなければならないためか、テスト技術者には浮かない顔を見せる人

          sho1884

          ブールグラフでロジックを整理してデシジョンテーブルと条件式を自動生成する　～ 設計者やプログラマにお勧めする原因結果グラフ技法 ～

          sho1884

          マネジメントシステムにソフトウェアの派生開発手法を適用して国際規格改訂に対応する

          本記事は、以下のカンファレンスおよびシンポジウムで発表した内容を、口頭説明が無くてもわかるように「読み物」として編み直したものです。 ・ 派生開発カンファレンス2018 https://affordd.jp/conference2018_program.shtml ・ JaSST'18 Tokyo http://jasst.jp/symposium/jasst18tokyo/report.html その際、次の方針で臨みました。 ・実践のための内容に絞り

          sho1884

          マネジメントシステムにソフトウェアの派生開発手法を適用して国際規格改訂に対応する

          sho1884

          「要求」の「根拠」として何を示すべきなのか？

          確かにそれも「根拠」と言えるけど、今欲しい情報はそれじゃないんだ！要求工学、要求開発、要求管理、ビジネス・アナリシス、等々、こういった領域の国際標準や様々なフレームワークなどの中で、「要求」と伴にその「根拠(あるいは理由)」を示す(引き出す、書き残す、管理する)ことの重要性やメリットが謳われています。 5W1Hのフレームワークで言えば、HowやWhatだけではなく、Whyを示すことの重要性が語られていることに相当すると思います。 実際、様々な場面で根拠情報は活用されることが

          sho1884

          「要求」の「根拠」として何を示すべきなのか？

          sho1884