このウェブサイトは販売用です！ srat-app.com は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、srat-app.comが全てとなります。あなたがお探しの内容が見つかることを願っています！
srat-app.com - このウェブサイトは販売用です！ - srat app リソースおよび情報
このウェブサイトは販売用です！ srat-app.com は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、srat-app.comが全てとなります。あなたがお探しの内容が見つかることを願っています！
ASTER テストツールガイド改訂WG（Test Tool Guide Working Group）
特定非営利活動法人 ソフトウェアテスト技術振興協会（以下、NPO法人ASTERと表記する）では、「テストツールまるわかりガイド」Version 2.0.0を、2020年9月末日に公開しました。 2012年、NPO法人ASTER テストツールWGにて、「テストツールまるわかりガイド（入門編）」Version 1.0.0（以下、Version 1.0.0と表記する）が公開されました。この公開から年月が経過したことを受け、読者が最新の情報を入手できるよう、改訂を行い、公開するものです。 「テストツールまるわかりガイド」Version 2.0.0では、プロプライエタリのテストツール（企業が販売しているツールなど）の情報の刷新を行いました。 プロプライエタリのテストツールについては、企業間の垣根を越えて多様なツールを知っていただくために、国内のテストツールベンダ／販社各社に協力を呼びかけ、国内で入手
テスト管理の自動化
表1に示した通り、ソフトウエアテスト実施時にテスト管理者が管理すべき項目は広範囲にわたります。テスト管理者はこれらの管理作業（進捗状況の確認や品質の分析など）に専念すべきですが、実際にはそのための情報収集などの雑多な作業に追われて時間が足りなくなり、十分な管理ができないことがしばしば起こります。テスト管理ツールを導入すれば、これらの管理作業を確実に、かつ効率良く行うことができます。 以下では、表1のテスト結果管理/テスト結果レポートツールで行うテスト結果管理作業のうち「進捗管理」と「品質管理」の自動化を、要件管理ツールで行うテスト分析作業のうち「要件管理」の自動化を取り上げます。 進捗管理の自動化 テストに限らず、システム開発では計画したスケジュール通りに作業が進んでいるかどうかを確認する進捗管理を行います。ここではテストプロセスの中から、テスト実行の進捗管理に絞って話を進めます。 一般的
第89回 PMOとして品質にどう向き合うか？（後編）
前回は、品質管理の勘所として次の4点を挙げ、最初のポンインについて考察しました。（1）品質指標の妥当性と目標値の意味づけ、（2）設計品質と開発品質、（3）プロセス品質とプロダクト品質、（4）非機能要件に関する品質の確保――。今回は残りの（2）～（4）のポイントを見ていくことにしましょう。 後藤 年成 マネジメントソリューションズ 取締役 PMP 私はプロジェクトの現場で「良いシステムを開発するために、テスト期間を長めにとって、たくさんテストを実施しましょう」という言葉を何度か耳にしたことがあります。「品質を上げるには、テストでたくさんのバグを出せばよい」と信じている方もいらっしゃいます。 確かに、アジャイル開発のように「設計～テスト」を繰り返し実施することで品質を実用レベルに高めていく開発手法もあります。しかし、ウォーターフォール型の一般的な開発手法においては、上流工程（要件定義や基本設計
実践！テスト自動化の勘所
システム開発において、安定稼働を支えるシステム品質の鍵を握るソフトウエアテスト。システムの大規模化や複雑化、デバイスの多様化などによってその作業負担は増える一方だ。手作業に頼ったテストが、結果としてシステムの品質低下や開発工期の増大を招く。ソフトウエアテストの専門家が、ツールを用いたテスト自動化のポイントを解説する。 テスト自動化とツールの導入
暮らしに役立つQC七つ道具(6) ―― 特性要因図：「原因」を「整理」する
この連載では，ソフトウェア開発の品質管理（QC：Quality Control）において使われている七つの技法「QC七つ道具」について解説している．今回は，「抽象化‐具体化」することによってある特性の要因を整理するのに役立つ「特性要因図」を取り上げる．特性要因図は，特性と要因の関係をフィッシュ・ボーンにたとえ，要因を収束し，原因を整理していくのに役立つ．（編集部） ●七つ道具その6：特性要因図 今回取り上げるQC七つ道具は，「特性要因図」です．特性要因図とは，特性と要因との関係を整理した図です．その形状からフィッシュ・ボーン・チャート（魚の骨図）とも呼ばれます．また，この図法を考案した石川馨（かおる）博士注1にちなんでIshikawa Diagramと呼ばれたりもします． 特性：現象や結果など原因を見つけようとする「対象」要因：特性に対して影響を与える「要素」もしくは「原因」 QC七つ道具
チームの生産性向上を重視するアジャイル開発の精神―米IBM チーフソフトウェアエコノミスト ウォーカー・ロイス氏
― まず、ロイスさんのこれまでの経歴をお聞きしたいのですが、ずっとソフトウェア開発の世界に携わっているのでしょうか？ そうですね、およそ35年間この世界に関わってきています。もともと大学では物理学を専攻していたのですが、その後コンピュータサイエンスを学び、さらにコミュニケーションの教育も受けました。入社後は、プログラマーを皮切りにシステムエンジニア、プロジェクトマネージャー、ヴァイスプレジデントなどを経験して、現在の役職に至っています。 ― 今のチーフソフトウェアエコノミストという役職には、どういったミッションが求められているのですか？ 私に求められているのは、いかにしてソフトウェアプロジェクトの測定方法を改善できるかについての指標を示すことです。これはすなわち、「どのような形で技術的な成果をビジネス上の価値に結び付けられるか」について考え、その実現を目指していくということになります。 そ
「FindBugs」「Jenkins」をサポートし、不具合検出の幅が大きく広がった静的解析ツール「Coverity Static Analysis 5.5」
2011年10月4日、コベリティは、C/C++やJava、C#のソースコード解析ツールの新バージョン「Coverity Static Analysis 5.5」を発表しました。発見が難しく、誤動作の原因となるバグを効率よく検出できる同ツールの新バージョンでは、前バージョンに比べてコード解析速度が向上し、より広範囲な開発環境に対応できるよう強化が施されました。Coverity Static Analysisの特長や新機能から、ソースコード静的解析のメリットについて考えてみましょう。 テストケースの用意は不要。ビルド時に不具合を発見 「Coverity Static Analysis」は、C/C++やJava、C#の各言語で記述されたソースコードに含まれるバグを検出できるソフトウェア開発支援ツールです。大規模・複雑化するソフトウェア開発において、ソースコードの不具合は、出荷遅延や修正対応による
現場の秘訣：実施段階
今回は、実施段階における、現場の具体的な秘訣を見ていこう。 実施段階における秘訣 段取りやチェックリスト、Excelで効率化 実施段階では、効率を高めることがポイントとなる。ここでは、進捗に影響を与えるリスクを早めにつぶす、スキル差による生産性のブレをなくす、単純作業を自動化する、迅速な修正を促す、問題の把握を早くする──といった現場の秘訣がある。 テストの中で「反復」を繰り返す 「危険な機能は先にテストするのが鉄則」。プライスウォーターハウスクーパースの高橋昭憲氏（シニアマネージャー）はこう考える。システム運用・保守を手掛ける高橋氏らは、頻発する変更・追加要求に対応して素早くテストするには段取りが重要という。 ここでいう段取りとは、テストの進め方を指す。危険な個所を前倒しでテストしておけば、もしバグがあっても手戻りが小さくて済み、テスト全体の効率は高まる。これを実現するのが「反復型テスト
品質とは何か
品質という言葉の意味 測定との関係と視点 品質の種類 基本的な考え方 ソフトウェア品質特性 機能性品質特性の品質副特性 信頼性品質特性の品質副特性 使用性品質特性の品質副特性 効率性品質特性の品質副特性 保守性品質特性の品質副特性 移植性品質特性の品質副特性 利用時の品質とは 俯瞰 まとめ 品質という言葉の意味 「品質」という言葉は、我々の世界ではよく使いますが、 品質とは何でしょう。 品質が良い／悪い、と言ったり、 品質を上げる、と言ったりしますが、 これがどんなものなのか、明確に認識しているでしょうか。 いろいろな人の話を聞いていると、 意外と認識が一致していません。 人によっては、検証の結果を見て言います。 「このモジュールは品質が悪いね」と。 人によっては、プロジェクト開始前に言います。 「前回のような品質問題は起こさないようにしよう」と。 人によっては、常に使います。 「品質を測
デブサミ2011レポート ソースコード品質、大丈夫ですか？ ～静的検証のススメ～
機能するコーディングルールの策定でバグ作り込みを防止 何故、ソースコードにバグを作り込むのか。日立ソリューションズの田邊照雄氏が要因として挙げたのは、言語に認められている自由度と、言語仕様の理解不足の問題だ。一つの実装に様々なロジックが考えられ、一つのロジックに対し色々な書き方ができる。また文法など言語仕様を一通り学んでいても、コンパイラの処理系定義の動作等まで理解しているエンジニアは多くない。 そこでコーディングルールを策定し、開発を標準化する試みが行われている。田邊氏が紹介したルール作成のポイントはまず、既存のものをベースにすることだ。たとえばESCR「組込みソフトウェア向けコーディング作法ガイド」が有用だ。また、身近なプロジェクトで作成されたものも参考にするのもいい。ただし、ルール数は必要最小限にする。またルールの目的、ルールからの逸脱時のリスクを明確にしておくことだ。 静的検証ツー
第3回 設計段階で性能を見積もろう
Webアプリケーションの画面を設計するとき、皆さんは性能について意識していますか。機能面の要望を取り込むことに集中するあまり、性能は二の次になっていないでしょうか。 あとになって性能が問題になるプログラムは、設計時に過ちを犯していることが少なくありません。そのような性能トラブルは、チューニングで簡単に解決しないことが多いものです。設計時に性能リスクを明らかにして早めの対策を打っておけば、致命的な性能トラブルの多くを防げます。 今回は設計段階で性能リスクを早期に発見するための性能見積もり手法について紹介します。設計段階で性能を作り込む手法には、多様なものがありますが、今回解説するのはその前段階として必要になるものです。どの機能に対して、工数をかけて性能を作り込むべきかを明らかするのが狙いです。 性能を見積もるメリットは二つ 設計段階では動作するプログラムが存在しないので、性能評価においては、
第2回 「応答一律3秒」という性能要件はやめよう
今回は、性能要件を具体化するポイントを紹介します。皆さんは、性能要件に何を定めればよいと思いますか。 システムの性能要件で、「Webアプリケーションの画面レスポンス時間は3秒以内であること」「バッチアプリケーションは毎日午前0～午前5時の間に終了すること」としか定義していないプロジェクトを見かけます。この場合、以下のような問題が潜んでいます。 （1）全機能の処理時間を同じレスポンス時間に収めなければならない 全機能に対して同じレスポンス時間を目標とするのは現実的ではありません。なぜなら、機能によって求められるレスポンス時間と処理の複雑度は異なるからです。 例えばコールセンターのシステムで、「（a）電話オペレーターが操作する画面」と「（b）管理者がマスターデータをメンテナンスする画面」があるとします。レスポンスの悪化が直ちにビジネス機会の損失につながる（a）の方が、求められるレスポンス時間は
第1回 性能品質は開発工程全体で作り込もう
性能要件の実現は重要だと認識しながら、「結局、性能は構築し終わるまで分からない」といったスタンスでプロジェクトに臨んでいないでしょうか。最初に性能要件を定義したあとは特に何もせず、カットオーバー直前にわずかな性能テストとチューニングを行うだけというケースを、筆者はよく見かけています。 そのようなスタンスでシステムを開発しても、性能要件をしっかりと実現できる可能性は高くありません。カットオーバー直前にその場しのぎの対策をするか、巨額の追加コストをかけてハードウエア増強に走る、といった状況に追い込まれがちです。 ITシステムの性能品質は本来、ライフサイクル全体を通して作り込むものです（図1）。設計、実装、テストの工程を通じて、システムの性能要件達成に取り組み、検証していく必要があります。 本連載では「システムの性能を確保するために何をすべきか」というテーマで、性能をマネジメントするための考え方
ソフトウェア品質特性 - Software Quality.com
ソフトウェアは「目に見えないモノ」ですので、その評価は現時点でも非常に難しい課題の一つです。 見えないからこそ、ソフトウェア品質の評価は重要となります。 その難題に一つの光明を見いだしたのが皆さんもご存じのISO/IEC9126(JIS X 0129) ソフトウェア品質特性（Ｑｕａｌｉｔｙ Characteristics） です。 （正式名称は「Information technology software product evaluation:Quality characteristics and guidlines for their use」） この規格は1991年（JISは1994年）に発行され、多くの人が存在（名前だけ？）を知っているのですが、その難解さ故利用されることは少ないようにも思います。 そこで、Software Quality.comではこのソフトウェア品質特性をある程
GQM - Wikipedia
GQM (じーきゅーえむ; Goal, Question, Metric)は、メリーランド大学のビクター・バシリ教授によって開発された、ソフトウェア工学における計測の枠組みおよびモデル化手法である [1] 。 ソフトウェア工学におけるあらゆる計測は、無目的にメトリクスやデータを集めるのではなく、何のために測定するのか、前提となるモデルは何か、結果をどう解釈するかなどを明確にした上で実施されるべきである。 GQM 法はこれらを定義する枠組みとして代表的なものの一つであり、測定モデルを以下の3つの層で定義する。 ゴール層 (G、概念レベル) 測定を行う目的の定義。測定の対象、理由、観点、およびコンテキストを定めるものである。 クエスチョン層 (Q、運用レベル) 目的の達成のために評価すべき質問の定義。ゴールが達成されたか否かを判断する具体的な基準となるものである。 メトリクス層 (M、定量レベ
第8章：プロジェクト品質マネジメント(その2)
ここでは、プロジェクト品質マネジメントをまとめます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ keywords ・シックスシグマ ・トータルクオリティマネジメント(TQM) ・品質計画 ・フローチャート ・特性要因図 ・品質保証 ・品質管理 ・コントロールチャート(管理図) ・上方管理限界と下方管理限界 ・中心線、平均 ・7の法則(ルールオブセブン)とアサイナブルコーズ シックスシグマ 経営指南本で有名なキーワードだけれども、純粋に品質管理の用語。google先生に訊いてみるとそれこそ山のように出てくるけれど、本当に重要なのは次のとおり。 シグマ(記号だとσ)とは標準偏差、すなわちバラツキの度合いのこと。数値が高ければ高いほど、精度が高いことを意味する。例えば、3シグマの精度は99.73％で、1000個の製品のうち、不良品は27個程度混入すると予想される。数値を記憶。
頑張るだけのレビューはもう限界
上流で品質を作り込むことを狙い，設計レビューを強化する現場が増えている。しかし，長時間に及ぶレビューは現場の負荷を高め，メンバーを疲弊させる。それだけの労力を投じても，重大な設計ミスが必ずしも減らないのが現実だ。3人のITエンジニアが座談会でその実態を語った。（聞き手は中山 秀夫＝日経SYSTEMS） 情報システムの信頼性に対する要求が厳しくなるなか，品質管理を強化し「設計ミス」をなくそうとする動きがあるようです。みなさんの現場では，いかがでしょうか？ Aさん：私は製造業のシステム部門に勤めています。設計の品質向上は，大きな課題になっていますね。テストでバグをつぶすのではなくて，もっと上流できっちり品質を作り込んでいこうという方針です。最近はレビューの強化に取り組んでいます。レビューの回数を増やしたのに加えて，設計レビューで有識者を必ず入れるルールになりました。 有識者は具体的にはどんな人
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
“品質重視”にさらに磨きをかける日本型プロジェクト管理のあり方