IEEE Computer Society
Member Benefit – IEEE DataPort Your IEEE Computer Society membership includes a free subscription to IEEE DataPort. A convenient way to store and manage research data, and access 5,000+ datasets. Member Benefit – IEEE DataPort Your IEEE Computer Society membership includes a free subscription to IEEE DataPort. A convenient way to store and manage research data, and access 5,000+ datasets. IEEE P26
アーキテクチャ設計に品質特性を使おう - arclamp
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報
つれづれなる技術屋日記: ソフトウェアにおける「故障モード」
このサイトではWindowsやPMBOKなど、登録商標および商標を記載省略しています。以前の記事閲覧で、カレンダー経由「ページが見つかりません」になったら、”バックナンバー”経由で辿ってください。 Facebookで知り合いの書き込みにコメントしたら、どうもソフトウェアにおける「故障モード」って整理されてない／一般的なものが存在しないようだと判明。探せば見つかるのかもしれないが、広まっているものがないように思えた。 ちなみに、CiNiiで「ソフトウェア FMEA」で検索すると19件、「ソフトウェア 故障モード」で検索すると7件ヒットした。未公開などの中に良い情報があるかもしれないが、読める論文だと、故障モードが詳細すぎる気がする。（今回ブログに書いたのは、それも理由。） またCiNiiで「FMEA」で検索すると249件、「ソフトウェア 故障モード」で検索すると119件ヒット。 と言うことで
QuaSTom 高品質ソフトウェア技術交流会 – QuaSTomは、ソフトウェアと品質を楽しく真面目に語り合う場です。
QuaSTomは、ソフトウェアと品質を楽しく真面目に語り合う場です。 MENU メニューを飛ばす お知らせ 2023年度総会を実施しました 2022年度第2回例会「知っているようで知らない今時のアジャイル開発」レポート 2022年度第2回例会案内「知っているようで知らない今時のアジャイル開発」 QuaSTom設立30周年記念 2021年度第6回例会 開催案内 2021年度第3回例会レポート 会員BLOG フリック派？キーボード派？ 還暦のCOBOLと私 業界特有の「固有名詞」問題 仕事と恋煩い システム開発の春夏秋冬 IoTとは？ 枯れた枯れない技術 理論は役に立つ？ Skype de QuaSTom！ “ゆる～く” の魅力 2023年度例会 開催日 カテゴリ テーマ 講師 2023年5月30日 講演 & ワーク & ディスカッション ODC分析 入門 森 龍二 氏 2023年7月24日
ソフトウェアアーキテクチャ その4 - アーキテクチャ決定要因と品質特性 [arch]
Software Architecture in Practice (Sei Series in Software En ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必... アーキテクトのバイブルとされる本．SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている． タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている． こちらがその和訳本． 一般的に，要件は - 技術制約 (Technical Constraint) - ビジネス制約 (Business Constraint) - 機能要件 (Functional Requirement) - 品質特性 (Quality Attribut
![ソフトウェアアーキテクチャ その4 - アーキテクチャ決定要因と品質特性 [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d39783b1c594c934484b79a62718fe607d18ed4/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FALY8t1tueREyYc3hLfKNQTV15uHOW3fltPRnYLKPpRv4QFYjDMgvN47J1vkDLWLe-9WFU8hsS6r8z_gxLTOmlIQ--TGJL-JgrgLtu9bWzKZDd6UStsRqr_wz5TrBVGEhp1JJmAip6Q%3Dw1200-h630-p-k-no-nu)
トラブル事象分析手法４Ｍ５Ｅの紹介
核燃料使用施設の皆様へ このたび、（財）原子力安全技術センターでは、文部科学省の委託事業として、核燃料使用施設で発生したトラブル等を対象とした要因分析手法として４Ｍ５Ｅ分析手法を策定し、そのマニュアルを作成しました。自主保安のより一層の充実のため、お役立ていただけますようお願い致します。 〈４Ｍ５Ｅ分析手法の概要〉 事故･トラブルには、人的な過誤(ヒューマンエラー)が係わることが多く、発生した事象を分析し、ヒューマンエラーを含めそこに潜む要因を抜けのないように明らかにし、同種の要因を含む事象が再び起こらないよう適切な対策を講じることが大切です。 ４Ｍ５Ｅ分析手法は、様々な産業分野で用いられている４Ｍ４Ｅ分析手法を改良したもので、作業現場のひとりひとりがヒヤリハットのような軽微な事象を含めたトラブル事象に遭遇したとき、自らが分析して多様な側面からの要因と適切な対策が導き出せるように
定量的なソフトウェア品質管理（pdf)
日科技連とSQiPの取り組み 1980年、日科技連では、日本におけるソフトウェア製品の品質向上と効果的開発の方法論の確立を目指して、「ソフトウェア生産管理研究委員会」（SPC, Software Production Control）を設置しました。 以来、「TQMとソフトウェア工学の結婚」を標榜し、日本的品質管理をソフトウェア生産に適用するための調査・研究・普及を行ってまいりました。 2007年に、この活動が「ソフトウェア品質に関する活動」であると分かりやすくすることと、ソフトウェア技術職という専門的職業の矜持を大事にしたいという思いから、SQiP(Software Quality Profession)に改称しました。 1980年の設立当初は、メインフレーマーで培われたソフトウェア品質技術・施策を議論する場でしたが、現在はソフトウェア産業に関わるすべての方々が議論できる場になっています
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MOT＆MBAの基礎知識－i Library
重大欠陥検出に集中するためのレビューポイントの導出方法の提案
「史上最悪のソフトウェアバグ」ワースト10を紹介｜WIRED.jp
https://www.jasst.jp/archives/jasst08e/pdf/D4-3.pdf
-
ソフトウェアバグ発生時の真因分析手法の策定