ページ
- お問い合わせ
- サイトマップ
- ソフトのプロダクト品質を良くするには
- ソフトの品質を保証するテストにはテストの種類とテスト計画とテスト管理とテスト報告書が重要
- ソフトの開発を委託する時の注意点
- ソフトの開発技術には何が要る
- ソフトの開発組織には何が必要
- ソフト品質以外の雑談部屋
- ソフト開発プロセスは開発実務プロセスと開発管理プロセスに分けて品質を改善する
- ソフト開発委託先の開発能力はソフト開発監査で見切る
- バグと不具合は別々の管理が必要
- バグの巣 にはバグが集まって住み着く
- プライバシーポリシー
- リリース判定は４つのリリース判定基準と４つのリリース判定の仕組みで実施する
- 他社製ソフトを使う時の注意点
- 神戸のグータラ親父の横顔は
- 組み込みソフトの品質保証に必要な複数の活動と重点ポイント
カテゴリー
- リリース判定
- 概要・リリース判定はテスト品質/残存バグ/プロダクト品質/プロセス品質の４つの基準で判断する
- 概要・リリース判定はリリースの種類/判定責任者/判定方法/ワークシートの４つの仕組みで実施する
- リリース判定基準・テストの量はテスト密度で測る
- リリース判定基準・テストの量はテスト実施率も確認する
- リリース判定基準・テストの種類まずは異常系と準正常系
- リリース判定基準・テストの種類２つ目は安定性と堅牢性
- リリース判定基準・テストの種類３つ目はRAS機能
- リリース判定基準・テストの種類４つ目はバージョンアップ機能
- リリース判定基準・テストの種類５つ目は過去不具合の確認
- リリース判定基準・テストの実施状況は進捗確認から
- リリース判定基準・テストの実施状況はバグの検出状況も見る
- リリース判定基準・バグは顕在バグと潜在バグに分けて考える
- リリース判定基準・潜在バグは何件残っているかを推定する
- リリース判定基準・残存バグ０は必須条件じゃない
- リリース判定基準・信頼度成長曲線はまあまあ使える
- リリース判定基準・残存バグはサービス提供への影響で判断する
- リリース判定基準・残存バグから電話申告の件数を推定する
- リリース判定基準・残存バグから電話申告の件数を推定する（その２）
- リリース判定基準・残存バグから電話申告の件数を推定する（その３）
- リリース判定基準・プロダクト品質はまずは設計品質を確認する
- リリース判定基準・プロダクト品質はコード品質も確認する
- リリース判定基準・プロセス品質は開発実務と開発管理に分けて考える
- リリース判定基準・開発管理プロセスはまず開発計画を見る
- リリース判定基準・開発管理プロセスは設計と実装とテスト計画を見る
- リリース判定基準・懸案やリスクの管理とベースライン管理も見る
- リリース判定基準・保守の体制と契約は明確になっているか
- リリース判定基準・ゲートプロセスの実施状況
- リリース判定の仕組み・ソフトのリリースには社外向けと社内向けがある
- リリース判定の仕組み・リリース判定の対象は社外向けのソフト
- リリース判定の仕組み・リリース判定は品保部長か開発部長か社長が行う
- リリース判定の仕組み・リリース判定は公式レビューで行うのが最良
- リリース判定の仕組み・リリース判定は２部署会議や個別判断でも可能
- リリース判定の仕組み・リリース判定の結果はチェックリストで記録を残す
- リリース判定その他・特別採用によるソフトのリリースもあり得る
- リリース判定その他・特別採用はテストの状況と潜在バグと残存バグで判定する
- リリース判定その他・テストとバグの悩ましい関係
- リリース判定その他・ソフトの品質はプロダクト品質が大切
- リリース判定は４つのリリース判定基準と４つのリリース判定の仕組みで実施する
- テスト品質
- 概要・テスト品質を良くするにはテストの目的に合うテストの種類を選ぶ事から
- 概要・テスト品質を良くするにはテスト計画書に目的と体制と管理と環境とトラッキングを書く
- 概要・テスト品質を良くするにはテスト報告書にテスト結果とテスト評価を書く
- 概要・組み込みソフトのテスト品質を良くするのに重要なテスト項目のいろいろ
- テストの種類・単体テストと結合テストとシステムテスト
- テストの種類・準正常系と異常系と正常系
- テストの種類・通信プロトコル処理での準正常系テスト
- テストの種類・状態遷移での準正常系テスト
- テストの種類・ハードウエア制御での準正常系テスト
- テストの種類・RAS の機能テスト
- テストの種類・セキュリティテスト
- テストの種類・The Art of Software Testing のシステムテストカテゴリ
- テストの種類・機能/大容量データ/高負荷/利用性/セキュリティ/性能/記憶領域
- テストの種類・構成/互換性/インストール/信頼性
- テストの種類・異常回復性/保守性/ドキュメント/手順書
- テストの種類：テストはデバックのためそれとも品質保証のため？
- テスト計画・計画書はテストの方針を最初に書く
- テスト計画・テスト目標（その１）納期とコストとプロダクト品質
- テスト計画・テスト目標（その２）プロセス品質と作業品質とテスト管理
- テスト計画・テストの分担と体制（その１）設計と実施と記録と再現
- テスト計画・テストの分担と体制（その２）不具合の一次切り分けとデバッグ
- テスト計画・テスト管理のメトリクス（その１）：日程と成果物の進捗管理
- テスト計画・テスト管理のメトリクス（その２）：テスト結果の管理
- テスト計画・テスト環境と環境の準備
- テスト計画・不具合やバグは分類の仕方と記録する項目を決めて置く
- テスト計画・不具合やバグの管理には不具合やバグの状態の定義が重要
- テスト計画・不具合やバグは優先度をつけてトラッキングする
- テスト報告書・発見したバグは分布が判るように分析する
- テスト報告書・信頼度成長曲線による潜在バグの推定
- テスト報告書・テストの評価はまずテスト内容の評価から
- テスト報告書・テスト計画の評価にはテスト日程についての評価も書く
- テスト報告書・テスト計画の評価にはテスト効率についての評価も書く
- システムテストの必須項目（１）・メモリリークテスト
- システムテストの必須項目（２）・メモリ以外の動的資源リークテスト
- システムテストの必須項目（３）・タイマやカウンタのロールオーバーテスト
- システムテストの必須項目（４）・複数機能の同時実行テスト
- システムテストの必須項目（５）・起動時テストには準正常系と異常系を加える
- システムテストの必須項目（６）・フラッシュメモリやHDDなどの二次記憶装置の劣化テスト
- システムテストの必須項目（７）・高負荷エージングテスト
- システムテストの必須項目（８）・品質の悪い通信路でのエージングテスト
- テスト品質を良くするにはテストの種類とテスト計画とテスト管理とテスト報告書が重要
- ソフト開発監査
- ソフト開発監査の目的その１：委託先の選定のために開発能力を判定するための監査
- ソフト開発監査の目的その２：開発委託先のソフト開発能力を改善するための監査
- ソフト開発監査の目的その３：バグ修正版ソフトの品質を確認するための監査
- ソフト開発監査では開発プロセスの良否をまず判断する
- ソフト開発監査では開発技術の中でも重要なテスト技術の良否を最初に判定する
- ソフト開発監査では開発要件の把握力の良否を３番目に判定する
- ソフト開発監査ではソフトの設計・実装力の良否を４番目に判定する（前半）
- ソフト開発監査ではソフトの設計・実装力の良否を４番目に判定する（後半）
- ソフト開発監査の方法（１）監査はプロセスの監査と技術力の監査
- ソフト開発監査の方法（２）プロセス監査の手順はIS9001と同じで準備と当日とフォローアップ
- ソフト開発監査の方法（３）プロセス監査の確認項目はCMMIの重要なアクティビティを主体に
- ソフト開発監査の方法（４）ISO9001とCMMIでプロセスを監査し開発技術力は別に確認します
- ソフト開発監査の事前準備（１）監査計画の説明
- ソフト開発監査の事前準備（２）資料入手と組織の把握
- ソフト開発監査の事前準備（３）チェックリストの事前記入
- ソフト開発監査の監査当日（１）ソフト監査も３現主義が大切
- ソフト開発監査の監査当日（２）オープニング会議
- ソフト開発監査の監査当日（３）組織の概要と規模の把握（前半）
- ソフト開発監査の監査当日（４）組織の概要と規模の把握（後半）
- ソフト開発監査の監査当日（５）ソフト開発に必要な機能と担当部署（前半）
- ソフト開発監査の監査当日（６）ソフト開発に必要な機能と担当部署（後半）
- ソフト開発監査の監査当日（７）開発プロセスのチェックのポイント
- ソフト開発監査の監査当日（８）要件管理のチェックのポイント
- ソフト開発監査の監査当日（９）テスト技術のチェックのポイント
- ソフト開発監査の監査当日（１０）設計と実装技術のチェックのポイント
- ソフト開発監査の監査当日（１１）監査報告書の作成（前半）
- ソフト開発監査の監査当日（１２）監査報告書の作成（後半）
- ソフト開発監査の監査当日（１３）クロージング会議とフォローアップ
- ソフト開発監査チェックリスト（１）要件管理プロセス
- ソフト開発監査チェックリスト（２）計画管理プロセス
- ソフト開発監査チェックリスト（３）トラッキングプロセス
- ソフト開発監査チェックリスト（４）品質保証プロセス（前半）
- ソフト開発監査チェックリスト（５）品質保証プロセス（後半）
- ソフト開発監査チェックリスト（６）構成管理プロセス
- ソフト開発監査チェックリスト（７）外注管理プロセス
- ソフト開発監査チェックリスト（８）要件管理技術（全般）
- ソフト開発監査チェックリスト（９）信頼性/可用性要件管理技術
- ソフト開発監査チェックリスト（１０）保守性要件管理技術
- ソフト開発監査チェックリスト（１１）セキュリティ要件管理技術
- ソフト開発監査チェックリスト（１２）検収条件管理技術
- ソフト開発監査チェックリスト（１３）開発管理技術（全般
- ソフト開発監査チェックリスト（１４）テスト管理技術（前半）
- ソフト開発監査チェックリスト（１５）テスト管理技術（後半）
- ソフト開発監査チェックリスト（１６）テスト技術
- ソフト開発監査チェックリスト（１７）設計/実装技術（概要）
- ソフト開発監査チェックリスト（１８）購入ソフト使用技術
- ソフト開発監査チェックリスト（１９）OSS/フリーソフト使用技術
- ソフト開発監査チェックリスト（２０）内作ソフト設計/実装技術(前半)
- ソフト開発監査チェックリスト（２１）内作ソフト設計/実装技術(後半)
- 開発委託先の能力はソフト開発監査で見切る
- バグの巣
- その他
- 信頼度成長曲線（バグ曲線）は３つの視点でソフトの品質を判断する
- ソフトウエアの開発で、開発管理ってなぜ必要なのでしょう？
- ソフトの品質向上はプロダクト品質とプロセス品質に分けて対策を進める
- リスクは将来起きる問題で懸案は既に起きている問題です、分けて管理しましょう
- ソフトの品質は一品物だから判り難い
- 正常系と異常系と準正常系
- ソフトの開発やテストの進捗管理を定量的に行う具体例２つ
- 排他制御の仕組みと効果・共有データには排他制御を掛けましょう
- 銀の弾丸なんて無い No Silver Bullet
- 情報の価値
- 座右の銘は持ってますか
- インフォーマルコミュニケーション
- マスクは洗って再利用もOK?
- ソフト品質以外の雑談部屋
- プロセス品質