logo

ソフトウェア 改善活動

開発活動の実態(ソフトウェアの問題、開発の進め方、現状の作業成果物の状態、開発者のスキル状態)の把握; 改善をする上で優先度が高い課題(”弱み”)の特定 改善実施. 12 特集文 12(680) 1.ま え が ソフトウェア 改善活動 き 当社のJIT改善活動のDNAとも言える基本的な考え方 は,ムダのない筋肉質の会社にするための活動で,製造現. カバレッジ率の値を取るために使われる 3. バグを全部見つけるのは無理だと心得ろ 2. 組み合わせテストで見つかるバグの数は、10%以下 1. アシスト、統合システム運用管理ソフトウェア「JP1」の販売活動において「JP1 Partner Award」を受賞 ツイート 国内トップクラスのシェアを誇る統合システム運用管理ソフトウェア「 JP1 」の開発元である株式会社 日立製作所が、年12月10日に「JP1パートナー.

1 イントロダクション 5. 活動事例や報告・提言内容を紹介するとともに、 ・「経営に貢献できているのだろうか?. データを保存する 2. 探索的テストとは、ソフトウェアの理解とテスト設計とテスト実行を同時に行うテスト 2. 数字の書き間違い 3. 組込み系ソフトウェア開発 現場におけるプロセス改善 年7月3日 ~品質向上、生産性向上を図る 現場の改善施策と今後の課題~ 改善活動事例発表 セイコーエプソン株式会社 ビジネス機器事業推進部 川瀬真. コード行数 6.

ソフトウェアプロセス改善活動を実践 ⇒社内の改善活動の具体事例やプロセスモデルの両面から、改善活動をご支援 2.幅広いソフトウェアエンジニアリングの実績. もともとはソフトウェアプロセス改善(SPI:software process improvement)プログラムにおける改善活動の計画・実行を支援するためのモデルで. 計算を行う 1.

ソフトウェアで弱いところを見つけたら、そこに重点を置き、その部分を十分にテストする 3. 品質が悪いとは: バグによって本来の機能が制限され、そのソフトウェアに期待される機能を顧客に提供できないこと. See full list on qiita. ユーザーがよく使いそうなデータ 2. ソフトウェアは4つの仕事しかせず、その4つの振る舞いをテストすればよい 1. 基本的には品質の悪い一部のコンポーネントが全体の品質の足を引っ張る 2. プログラムのある部分でエラーがまだ存在している確率は、すでにその部分で見つかったエラーの数に比例する 3.

JaSST&39;17 Tokyoの招待講演で講師の奈良さんが「QAの役割はQMSを回すこと2」と説明されていたのがシンプルかつ深みがあり筆者は好きです。 QMSを回すとはプロセス警察(エビデンスを要求したりプロセス通りに実行しているかを監視する)のことではなく、価値を最大化し価値を損ねるものを最小化するためにソフトウェア開発の全工程に対してよりよく回るようにしたりうまく回っていないところにテコ入れすることといったほうがしっくりくると思います。. See full list on mamezou. どの成果物を評価すればよいかがわからない・・・評価対象の問題。 2. バグの修正にかかる時間 4. ふだんシステム開発・保守・運用組織の中でプロセス改善活動を推進されている方、ソフトウェア開発業務を改善したいと考えている技術者、リーダー、マネージャーの方に広くご参加いただきたく存じます。 ソフトウェアプロセス改善とは 実際の顧客がもっとも使うと思われるオペレーションをした際のMTBF (Mean Time Between Failure) 4. 余分な境界 異なる処理が行われる一番近い二地点のテストをすること。 データを入力する機能がある場合、必ず「良いデータ」と「悪いデータ」を入力する。 1. 改善の進め方の要点 改善は、現場で行うこと. その多さの要因は、組み合わせテストがテストケースの増大を起こしている 3.

レガシーソフトウェア改善ガイド輪読会 「レガシーソフトウェア改善ガイドの輪読会」を通してチームメンバーの認識を揃える. ソフトウェア開発組織の成熟とは ソフトウェアプロセス管理の歴史は、1986年までさかのぼることができる。米国の国防総省(DOD:Department of Defense)が、調達における供給者の能力向上とその評価に利用するために、カーネギーメロン大学のソフトウェア工学研究所(SEI:Software Engineering Institute. こうして眺めてみるとSQAの活動は多岐にわたることがわかります。 なお、プロダクトやプロジェクト、SQAの規模、成熟度、優先することなどは各社各様で、優先度をつけてやることを絞ったりここに挙げていないこともやったりなど活動内容や活動方法は現場ごとにさまざまと思います。ここに書かれていることが必ずしも皆さんの環境に当てはまるとは限りませんが何かの参考になれば幸いです。. 対して、小集団での改善活動によって対策を行ったので、ここにその内容を紹介する。なお、本稿は、年1月18日に東京都・千代 田区で開催された、第8回クリティカルソフトウェアワークショップ(wocs)の一般講演をもとにしたものである。.

>と>=の間違い 2. 各機能のテスト及びバグの記録 2. 弱いエリアを見つける 2. 出力を処理する 1. 業務改善に限らず, 組織の中で何らかの活動を過去に行い, うまくいかなかった経験を持っている組織には, 「 ⁠どうせ, またうまくいかないだろう」 と最初から冷ややかに見ている人がいるものです。そのタイプも様々です。. 本ページは、講座「k-001:改善活動の基礎講座~カイゼンの基本編~」の講座ナビゲーションページです。本講座では、「改善活動の考え方と進め方」や、コミュニケーションを取る上で必須のフレームワークである「5w2h」、社会人にとって基本中の基本である「pdcaサイクル」等のカイゼンの. 最近ではソフトウェアに限らず業務プロセス全般を扱い、Engineering Process Group(EPG)と呼ぶケースもある。 主任務は 組織プロセスの可視化(定義) と運用支援および改善であり、不具合や開発効率の分析をもとにプロセスの強み弱みを評価して改善活動を.

ステートメントカバレッジでは、コード内の命令文 (ステートメント) をすくなくとも一回は実行する 2. 電子政府の構築などでも注目を集めているソフトウェア開発のプロセス改善モデルのcmm。電子政府構築でさらに注目を集めるプロセス改善だが、いま、cmm以上に注目を集めそうなのが、国際標準化されたiso/iec ソフトウェア 改善活動 tr 15504に準拠したppaというソフトウェア開発のプロセス改善モデルだ。. 機能をリストアップする 2. 次に、品質改善のために品質評価がなぜ重要なのかを考察していきます。 「改善」や「リファクタリング」というキーワードが飛び交う現場では、どうしてもその実践に注目が集まります。皆さんも「開発者個人の気になっている箇所だけをスポット的に修正する」、「変更してみたものの何がどの程度良くなったかがわからない」といった経験はありませんか。 このように、問題の分析や改善の評価が手薄なままで、改善活動はうまくいくでしょうか。 まず、品質の観点でどのような問題があるかを把握しないまま手をいれても、変更後にどのように品質が改善されたかがわかりません。 さらに、品質上の問題ではない箇所を変更するといった無駄な作業が発生する可能性もあります。 問題の分析や改善の評価を怠ると、残念ながら改善活動としては失敗するリスクが高くなります。 では、失敗しないために必要なことは何でしょうか。身近な例から探っていくために、体の改善であるダイエットの場合にどのような手順で進めるかを考えてみましょう。 最初に今の体重や食生活などを確認するはずです。そして、今の状態をベースに目標を立てて、その実現に向けたアクションプランを考えることでしょう。仮に今の状態を把握しないまま進めたとして、いざ体重計に乗っても「どれだけ痩せたか」という成果がわかりません。 ソフトウェアの改善も同じように、まず品質を評価して、今の品質がどうなっているかを知ることが大切です。そうすることで問題点を的確に把握することができます。正しい問題認識に基づいた改善施策を立てれば、品質上の問題ではない箇所を変更するような無駄な作業の発生を防ぐことができます。 そして改善後にも品質を評価し、改善前後の評価結果を比べることで「どれだけ改善したか」という成果を知ることができます。成果を正しく把握できれば、実施した改善がどの程度効果的なものであったかがわかり、次の改善活動の計画立案や施策検討に役立てることができます。 改善前後の品質評価を組み入れた品質改善のプロセスをまとめると以下の図のようになります。 図 1 品質評価を盛り込んだソフトウェア品質改善のプロセス. 2 ソフトウェア 改善活動 プロセス改善のタイプ アセスメントモデル プロセス改善モデル 5. テストケースの数と、テストの自動化率 3. マルチプロセスやマルチスレッド間でデータを共有している よって、組み合わせテストに関する問題はテストで見つけるのではなく、アーキテクチャを工夫して出ないようにすべし。.

大事なのは、バグのない製品を出すこと ソフトウェア 改善活動 2. プログラムが許す最大のデータ 1. テスト担当者以外のバグの発見数 2. 非常に小さなデータ 3. ビルドにかかる時間 5. 非常に大きなデータ 4. プログラムが許す最小のデータ 3.

品質改善に取り組めば、生産性もアップ ~ソフトウェア開発技術適用事例の データ分析から見えてきたこと~ 1 独立行政法人情報処理推進機構 技術本部ソフトウェア高信頼化センター 年5月12日 ソフトウェアグループ・連携委員 春山 浩行. 入力ダイアログボックスがあれば、境界値テストを行い、単機能のデータ入力に対するバグを見つける 2. ソフトウェア 改善活動 ビルドのメトリックス 5. ls研: ソフトウェアプロセス改善のためのCMM導入指針 年度 研究成果報告書 (内レベル2が1社、レベル3が3社)におもむき、CMM導入から今日までのプロセス改善活動に関する 調査を実施した。本論文中の数値は主にこの調査によるものである。. See full list on ogis-ri. • 研究者として: ソフトウェア工学の研究(~) –文科省e-society基盤の総合開発、経産省 先進的ソフトウェア開発で ソフトウェア工学の産学連携の研究に従事 –300社超との相談、18社と機密保持契約ベースの産学連携 日経SYSTEMS, ソフトウェア 改善活動 ThinkIT等での連載記事.

2 テストプロセス改善 ソフトウェアプロセス改善モデル テスト改善モデル 参考書籍 ソフトウェア 改善活動 5. 「品質が良い」というのは以下の2つにブレークダウンできます。 1. そのタコなもジュルを見つけて品質改善をすると、あっと驚くような品質のソフトウェアになる 3. ソフトウェアプロセスとは、「ソフトウェアを開発・保守するための手順(プロセス)」のことです。 本ブログでは、ソフトウェアプロセスに関連する事柄について説明します。中には私の独自の見解も含まれます。.

ソフトウェア開発プロセス改善活動 7 特 集 当社におけるソフトウェアプロセス改善活動の目的は, ソフトウェア開発におけるqcdを向上させ,ソフトウェアで 製品の収益を支えることと,改善活動を常態とする組織文化 の確立にある。. ビルドで見つかった問題 5. 複数の入力ダイアログボックスがあれば、ディシジョンテーブルテストを行う 3. 入力を処理する 1. モジュールで見つかるバグの数 5. テスト担当者が忙しい原因は、テストケースの多さ 2. 「品質」でググるとわかるようにいろいろな人がいろいろな定義をしていてSQuBOK Guide(ソフトウェア品質知識体系ガイド)ではアリストテレスまでさかのぼってさまざまな品質の定義を紹介しています。ソフトウェアエンジニアでSQuBOKを読んだことのない方は読まれることをお勧めします。 品質には多面性があり唯一の正解というものはないのですが筆者はワインバーグの「品質とは誰かにとっての価値である1」というのが好きです。 お金を出して商品を買ってくれたユーザや無料版を無料で使用しているユーザと比べると「誰か」というのはとっても広いですね。でも商品を買う前のまだユーザになっていない段階でレビューを見て良さそうだとかイマイチっぽいとか、品質、つまるところ対価を払って得られる価値が購入するという行為の判断材料の一つになっていることは誰しも経験があるかと思います。そして、何に価値を感じるかは人それぞれでもあります。. ソースコードのメトリックス 3.

制御パステスト法は、プログラムがどのような振る舞いをして、どのように制御され実行されていくかをテストする 2. KLOCs: どのくらいソースコードの行数が増加しているか 3. 探索的タスクを実行する 2. どんな入力も正しく処理するためには -同値分割法-. ダイアログボックスの遷移があれば、状態遷移テストを行う 4. 20%のバグの発見は、モジュールごとのバグの発見数を調べれば、どこにバグがたくさんあるかはすぐわかる 5.

ソフトウェア開発が大規模化・複雑化・短期化へと変化するに伴い、あるべきテストの考え方・テストの方法も変化しています。 より良い製品を開発するために、新しいテストの考え方や手法を取り入れていくことが必要となります。 そのためのお手伝いを、豆蔵はご提供いたします。. 品質保証はQA、Quality Assuranceとも呼ばれます。保証を意味する英語としてはassuranceのほかにwarranteeやguaranteeもありますが以下のassuranceの解説を読んでなるほどこれが品質保証、QAかと納得しました。 ソフトウェアには製造工程がないため筆者は以下のようにアレンジしています。 ここで「全ての工程」とあるように品質保証は全工程、全員参加の取り組みであり品質保証の担当者だけで行うものではありません。. 同値分割とは、入力領域を「同値クラス」という部分集合に分割し、その部分集合に入る入力値を等値とみなす作業 2. 問題は、無効同値の数が多くなること 3. ソフトウェアプロセス改善(spi活動)とは? •⽬標 –システム・ソフトウェア開発のqcd(品質、コスト、納期)の向上 •⼿段 –開発プロセスを変更 •問題の質 –何が問題なのかわかっていない問題(広い問題).

ISO/IEC9126-1では、以下のように6つの品質特性と27の品質副特性でソフトウェアの品質を定義しています。 表 1 ISO/IEC9126-1で定義されているソフトウェア品質モデル 「ソフトウェアの品質」というと「機能性」や「信頼性」といった、いわば「製品利用者視点の品質」をイメージする方が多いのではないでしょうか。ISO/IEC9126-1では、「製品利用者視点の品質」だけでなく「保守性」や「移植性」といった、いわば「開発者視点の品質」も含んでいる点が特徴的です。 かつてのように小規模なソフトウェアを少人数で開発することが主流だったときには、「開発者視点の品質」をそれほど意識する必要はなかったのかもしれません。そのため、「ソフトウェア品質=製品利用者視点の品質」という認識でも問題はなかったでしょう。しかし、既存ソフトウェア成果物の活用が一般的になり「開発者視点の品質」の重要性が高まってきている昨今では、品質特性を網羅的に正しく評価することが求められます。. ソフトウェア品質改善には、例えば以下のような活動があげられます。 バグ分析 バグがどういった原因で発生したのかを分析し、どこで混入されてしまったか、どのモジュールで発生しているのかなどを見つけ出します。. 信頼性成長曲線 4. グローバル変数を使っている 2. 品質評価には、改善活動を有益なものにするメリットがありますが、現場で一般的に実施されているとは言い難い状況です。 これは品質評価を実施する上で以下の2つのハードルがあるからだと筆者は考えています。 1.

Maturity Model® Integration )〔注1〕 をモデルとしたプロセス改善が行われており、 そのプロセスの元、ソフトウェア開発が行われている。また、CMMI®の導入により、 独立したグループによる客観的な品質保証活動の必要性が認知されてきている。. 価値を損ねるものがない、少ない ソフトウェアの品質が良いというとバグゼロやバグが少ないことを思い浮かべるかもしれませんが価値があること、優れていることも大事です。. 本ページは、講座「k-001:改善活動の基礎講座~カイゼンの基本編~ 第2章:改善活動の考え方と進め方」の学習ページです。第2章では、改善活動の2つのアプローチである日常改善・目標設定型改善の違いやサイクル、改善活動を行なう上での心得等について解説をしています。. 3 テストプロセスの改善 推奨プロセス プロセス改善ロードマップ プ.

プロセス改善の事例 SECセミナー等での発表 タイトル 発表者 設計からはじめる見逃しバグの防止 (株)日立ハイテクノロジーズ 飯泉紀子氏 年2月13日 secセミナー 派生開発による品質および開発効率の向上 東京エレクトロンソフトウェアテクノロ. コードカバレッジ 2. 改善活動から生まれました。 TimeTracker NXは、ソフトウェア開発、ハード設計、営業、Web制作などの知識労働・デスクワーク業務における工数管理・プロジェクト管理のためのツールです。. コンポーネントごとのバグの発見数 (バグが多すぎないか、もしくは少なすぎないか) 2. ソフトウェアの信頼性メトリックス 4.

社で行われている改善事例を収集し分析することにより、改善活動に役立つソフトウェアプロセ ス改善(SPI)推進上のノウハウをまとめた「SPI 虎の巻」(付録A として抜粋を収録)を作成する。 これは実際の改善活動で利用されることを想定しているため、現場. ホワイトボックステストとは、プログラムの論理構造が正しいかを解析するテスト 2. 境界がない (条件文書き忘れ) 4. バグの住む場所を探す -境界値分析法-. 近年、プラットフォームの高度化、セキュリティ対策の強化、ハードウェアの高性能化により、組込み製品に求められる機能はますます高度で複雑なものになっています。その一方で、開発期間の短期化、多機種開発が要求されてきています。 また、近年、自動車、金融、交通インフラなどさまざまな分野でソフトウェアに起因するシステムのトラブルが起こっており、改めてソフトウェアの品質改善に注目が高まってきています。. クライテリアを決める (表形式) 1.

重要度の高いバグの発見数 3. メトリックスデータを使用する場合、次の2点に気をつける 2. コードの複雑度: McCabeのルール 4. テストという作業は、アウトプットが非常に見えにくい 2. 追加、削除、変更されたコードの行数 3.

それでおしまい! 1. あるいは実践の手助けをする活動を通じて、 よりよいソフトウェア品質改善方法を見いだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 報告用の文書や測定よりも正しく動くソフトウェアを、. ソフトウェア 改善活動 これをソフトウェア開発における品質管理活動に当てはめてみると、「品質改善活動」と「品質安定活動」の2本柱になります。 一般的な製造業の製品に比べて、ソフトウェアの品質は個人のスキルに依存する部分が大きいという特徴があります。. 長いデータ (abcdefghijklmn.

プログラムの振舞をテストする -制御パステスト法-. • 現場担当者の共感が得られ、ソフトウェアの改善要望が高まった Step2:活動内容と結果 ターゲット製品選定 部分機能の開発 (4ヶ月) 部分機能の開発 (4ヶ月) ターゲット製品の 従来手法での開発 (5ヶ月). 横軸: Pass基準 / Fail基準 1.

プログラムで境界と呼ばれる場所には常にバグが潜んでいるので、境界値近くは詳しくテストする必要がある 以下の4つのバグタイプを頭に入れながらテストを書く。 1. スケジュールのメトリックス 6. ビルドが失敗した原因 6. 組み込みソフトウェア開発の現場では、ソフトウェアの大規模/複雑化、短納期化が進んでいます。 多くの現場では、過酷な状況の中で、いかにソフトウェア品質を改善していくかが課題となっています。 改善活動を進めていく上で「どのように成果物を改変するか」という改善の中身が重要なことは言うまでもありません。加えて、筆者は改善前後に実施する「品質評価」も同様に重要だと考えています。 本稿では、「ソフトウェア品質」の定義を紹介した上で、「品質評価」の重要性と、数多くの成果物の中で何を評価すれば良いのか、という点について考察していきます。. SEA - Software Process Improvement Network の略称で、 SEA-SPIN はソフトウェア技術者協会(SEA)の分科会活動の一つです。 ソフトウェアプロセス改善(SPI)活動の普及促進に関心がある技術者と管理者が 集まり、SPIの実践についての情報交換と意見交換などを行なってい. 1 プロセス改善の紹介 5. 決するために,企業では様々な取組みを実施している.ソフトウェア品質を確保する 取組としては,設計ドキュメント様式の充実,設計プロセスの定義,検証と妥当性確 認の取り組みなど様々な改善活動を実施している.その中で,ピアレビューは,仕.

縦軸: 機能性 / 安定性 2. ソフトウェア 改善活動 テストを実行しながら、どこか他の部分に問題がないかを考え、そこをテストする 2. ストレステストを行った際のMTTF 5. どのように評価すればよいかがわからない・・・評価方法の問題。 本稿では、1つ目のハードルについて考察していきます。 品質を評価するにあたり、ソフトウェア開発に関する全ての成果物を評価対象とすることは、工数の関係上、現実的ではありません。従って、評価対象とする成果物を絞り込む必要があります。 どのような成果物が評価対象として望ましいでしょうか。まず、継続的に評価することを考えれば、どのようなプロジェクトであっても必ず製作される成果物であることが望まれます。さらに、できるだけ定量的に評価できる成果物であることが望まれます。 このような条件に最もフィットする成果物は、ソースコードではないでしょうか。 ソースコードはソフトウェア開発で必ず製作される成果物であると同時に、実際に製品に搭載される唯一の成果物です。また、有効なメトリクスが世の中に多数提案されていますので、他の成果物よりも定量的な評価がしやすいと考えられます。 以上から筆者は、まず、ソースコードを対象に品質評価をすることが、現場で実施できる効果的かつ現実的なソフトウェア品質評価の形態だと考えています。 次回は、2つ目のハードルであるソースコードの品質評価方法についてご紹介する予定です。. 報告や改善の提言などを実施しています。 本発表では、品質保証部門が経営に貢献すべく実施している. バグのメトリックス 1. 2 テストプロセス改善への取り組み テストプロセス改善は組織的な取り組みが必要である。そこ で、品質を改善するために当社がおこなっている品質改善活動 (iQi活動:INTEC Quality Improvement Initiative)のなか で取り組むことにした。. 価値がある、優れている 2.

テストのメトリックス 2. ソフトウェア 改善活動 なるべく誤差がなく、人間の恣意に左右されないものを選ぶ 2. SPI Japanはソフトウェア開発プロセス改善活動で得られた技術や知見を総集し、その普及と技術力向上の場を提供するために開催いたします。JASPICが主催する最大のイベントです。 なお、年から年はSEPG Japanとして開催していました。. 時間軸でのバグの発見数 1.


Phone:(743) 758-7949 x 8582

Email: info@fzca.nmk-agro.ru