8th Workshop on Critical Software (WOCS) 18-19 January 2011 検出漏れのない割込み干渉検出システムの開発 (株)豊田中央研究所 安全・情報システム研究部 稲森 豊 アイシン精機(株) ソフトウェアセンター 山田信幸 8th Workshop on Critical Software (WOCS) 18-19 January 2011 概要 テストでは発見困難な不具合要因である割込み干渉について Cソースコード作成段階で自動検出するシステムを開発した 目次 1. 割込み干渉とは 2. システム開発の目的 3. 割込み干渉検出手法の概要 4. 割込み干渉検出手法の詳細 5. システム開発と評価 6. おわりに 検出漏れのない割込み干渉検出システムの開発 車載ソフトウェアにおける割込み処理 3/28 サスペンション制御 ブレーキ制御 エン
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
出典は列挙するだけでなく、脚注などを用いてどの記述の情報源であるかを明記してください。記事の信頼性向上にご協力をお願いいたします。(2019年8月) ソフトウェア品質(ソフトウェアひんしつ、英: Software quality)は、ソフトウェアの品質を指し、プログラマの観点からはソースコードの品質、エンドユーザーの観点からはアプリケーションソフトウェアの品質を意味する。 ソフトウェア品質の定義は様々である。ジェラルド・ワインバーグは著書 Quality Software Management: Systems Thinking v. 1 で「品質とは誰かにとっての価値である」と書いている。この定義は品質が本来主観的なものであることを強調している。同じソフトウェアであっても人によって品質の感じ方は全く異なる。この定義の利点は、ソフトウェア開発チームに「このソフトウェアは誰のために作っている
モノ作りの品質というと、どうしても製造現場にフォーカスしたもの(品質管理)が多いけど、この本は開発現場での品質(品質工学)を取り上げている。品質工学を毛嫌いする人は少なくなく、知名度や普及度は今ひとつのような感じがする。でも、この本に難しい理屈は無く、品質工学の基本的な考え方やその必要性が平易な言葉で説明されており、初心者でも容易に読み進められるはずだ。 TQM活動は、生産分野から始まり経営分野へと広がりを見せているが、技術開発分野への展開はまだ不十分である。それは、技術そのものに対する理解がボトルネックになっているからである。品質工学は、そのボトルネックを克服し、品質を根本から改善するためのツールの一つである。どのような視点から技術を理解すべきか、製品をどう設計すべきかを追求する方法である。 実績データを活用して信頼性を予測する信頼性工学とは異なり、品質工学は、実績データが存在しない場合
終了した開発プロジェクトの問題分析を行っている。「バグの源流をたどれ」の如く、なぜなぜ分析で問題の根本原因を探り、抜本対策案をまとめるのが目的だ。さすがに限られた時間内で全障害を検証するのは不可能なので、優先度の高い問題のみをピックアップしてから分析を行う。Tracのチケットに記載された情報を元に、仕様書の記載ミスなら変更前後の仕様書を見比べ、コーディングミスなら該当するコミット状況を確認し、テスト漏れならテスト手順書の記載を検証するといった感じだ。 開発対象も開発者も異なるプロジェクトを見ているけれど、いずれの開発でも共通の傾向があるので面白い。 障害は偏在する 全ての障害が一様に分布するのではなく、特定の機能、開発者、モジュール等に著しく偏って発生することが多い。パレートの法則ほどではないけれど、その偏り方は目に見えてはっきりと分かる程だ。 類似の障害は繰り返し発生する 一つのプロジェ
エンジニア質問箱は、開設以来、多数の方々にご利用いただいてまいりましたが 2022年6月30日をもちまして、サービスを終了いたしました。 今までご愛顧いただきましたお客様には深く御礼申し上げますとともに この度のご案内となりましたことを心よりお詫び申し上げます。 ■ 対象サイト:エンジニア質問箱 (https://www.qabox.jp/) ■ サービス終了日時:2022年6月30日(木) 18:00 ご登録いただいたメールアドレス、ご質問・ご回答情報、獲得された称号等については サービス終了作業に伴う必要な期間を経過したのち、適切に消去させていただきます。 弊社ではサービス向上のため今後も鋭意努力してまいりますので 変わらぬご愛顧賜りますようお願い申し上げます。 本件に関する問合せにつきましては、問合せフォームよりお問い合わせください。
Welcome to the 2023 Common Weakness Enumeration (CWE™) Top 25 Most Dangerous Software Weaknesses list (CWE™ Top 25). This list demonstrates the currently most common and impactful software weaknesses. Often easy to find and exploit, these can lead to exploitable vulnerabilities that allow adversaries to completely take over a system, steal data, or prevent applications from working. CWEs are becom
PDCA PDCA とみんな言いますが、僕はこれずっと何かおかしいと思っているのです。 ウィキペディアによれば PDCA とは、 Plan(計画):従来の実績や将来の予測などをもとにして業務計画を作成するDo(実施・実行):計画に沿って業務を行うCheck(点検・評価):業務の実施が計画に沿っているかどうかを確認するAct(処置・改善):実施が計画に沿っていない部分を調べて処置をするであって、これをサイクリックに繰り返すとのこと。 これの何がおかしいと感じるかというと、最後の Act のところです。 まず計画を立てて、それを実行してみて、その結果を評価する。ここまではいい。 けれど、その次に評価の結果を見て改善処置をする Act というフェーズが、他の Plan Do Check と並列になっているのはおかしい。 もしこれがサイクルではなくて、ウォーターフォールとしてはじまりと終わりがはっ
「ソフトウェア品質のホンネ」連載中! SQiPポータルサイトでは、SQiP委員のソフトウェア品質へのその想いをコラム的に綴る 「ソフトウェア品質のホンネ」のコーナーを好評連載中です。 肩肘張らずに気軽にお読みいただける内容を掲載していきますので、お仕事の合間などに是非ご覧ください! ※本コーナーに対するご意見、ご感想がありましたら、sqip@juse.or.jpまでお寄せください。 2.ソフトウェア品質保証の変遷(Fの例) 1)品質保証部署の設置 わたしが勤務していた会社(F)の中にソフトウェア製品の検査(検査部という組織名称であったので品質保証とせずそのまま「検査」を用います)を担当する部署が設置されたのは1968年と聞いています。この時代は、品質保証というよりもテストノウハウやデータの取得を目指していたと聞いています。ハードウェア装置の検査方法、文献などを頼りにソフトウェア検査の
テストを軸としたソフトウェア品質の改善 を軸 ウ 品質 改善 ソフトウェアテストシンポジウム新潟 2011 2011/2/18(金) 電気通信大学 大学院 情報理工学研究科 総合情報学専攻 経営情報学コース © NISHI, Yasuharu 総合情報学専攻 経営情報学コ ス 西 康晴 自己紹介 自己紹介 • 身分 トウ 学 研究者 – ソフトウェア工学の研究者 » 電気通信大学 電気通信学部 システム工学科 » ちょっと「生臭い」研究/ソフトウェアテストやプロセス改善など – 先日までソフトウェアのよろず品質コンサルタント • 専門分野 – ソフトウェアテスト/プロジェクトマネジメント /QA/ソフトウェア品質/TQM全般/教育 共訳書 • 共訳書 – 実践ソフトウェア・エンジニアリング/日科技連出版 – 基本から学ぶソフトウェアテスト/日経BP – ソフトウェアテスト293の鉄則/日経
1 © NISHI, Yasuharu テストの改善、テストによる改善 ソフトウェアテストシンポジウム(JaSST)2009東海 2009/10/16(金) 電気通信大学 電気通信学部 システム工学科 西 康晴 © NISHI, Yasuharu 2 自己紹介 • 身分 – ソフトウェア工学の研究者 » 電気通信大学 電気通信学部 システム工学科 » ちょっと「生臭い」研究/ソフトウェアテストやプロセス改善など – 先日までソフトウェアのよろず品質コンサルタント • 専門分野 – ソフトウェアテスト/プロジェクトマネジメント /QA/ソフトウェア品質/TQM全般/教育 • 共訳書 – 実践ソフトウェア・エンジニアリング/日科技連出版 – 基本から学ぶソフトウェアテスト/日経BP – ソフトウェアテスト293の鉄則/日経BP – 基本から学ぶテストプロセス管理/日経BP • もろもろ – T
今いる社員を収益を生む考え方と行動に変える「考動知図」:改善を積上げる土台:現場の「こうしたほうが、いいのに」をみんなで積上げて「強み」へ PDCA cycle (plan-do-check-act cycle 第二次世界大戦後、品質管理を構築した ウォルター・シューハート(Walter A. Shewhart)、 エドワーズ・デミング(W. Edwards Deming)らが提唱した。 このため、シューハート・サイクル(Shewhart Cycle) またはデミング・ホイール(Deming Wheel)とも呼ばれる。 PDCAサイクルという名称は、 サイクルを構成する次の4段階の頭文字をつなげたものである。 事業活動における生産管理や品質管理などの 管理業務を円滑に進める手法の一つ。 Plan(計画)→ Do(実行)→ Check(評価)→ Act(改善)の 4段階
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く