このウェブサイトは販売用です! srat-app.com は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、srat-app.comが全てとなります。あなたがお探しの内容が見つかることを願っています!
このウェブサイトは販売用です! srat-app.com は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、srat-app.comが全てとなります。あなたがお探しの内容が見つかることを願っています!
特定非営利活動法人 ソフトウェアテスト技術振興協会(以下、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のテスト結果管理/テスト結果レポートツールで行うテスト結果管理作業のうち「進捗管理」と「品質管理」の自動化を、要件管理ツールで行うテスト分析作業のうち「要件管理」の自動化を取り上げます。 進捗管理の自動化 テストに限らず、システム開発では計画したスケジュール通りに作業が進んでいるかどうかを確認する進捗管理を行います。ここではテストプロセスの中から、テスト実行の進捗管理に絞って話を進めます。 一般的
― まず、ロイスさんのこれまでの経歴をお聞きしたいのですが、ずっとソフトウェア開発の世界に携わっているのでしょうか? そうですね、およそ35年間この世界に関わってきています。もともと大学では物理学を専攻していたのですが、その後コンピュータサイエンスを学び、さらにコミュニケーションの教育も受けました。入社後は、プログラマーを皮切りにシステムエンジニア、プロジェクトマネージャー、ヴァイスプレジデントなどを経験して、現在の役職に至っています。 ― 今のチーフソフトウェアエコノミストという役職には、どういったミッションが求められているのですか? 私に求められているのは、いかにしてソフトウェアプロジェクトの測定方法を改善できるかについての指標を示すことです。これはすなわち、「どのような形で技術的な成果をビジネス上の価値に結び付けられるか」について考え、その実現を目指していくということになります。 そ
今回は、実施段階における、現場の具体的な秘訣を見ていこう。 実施段階における秘訣 段取りやチェックリスト、Excelで効率化 実施段階では、効率を高めることがポイントとなる。ここでは、進捗に影響を与えるリスクを早めにつぶす、スキル差による生産性のブレをなくす、単純作業を自動化する、迅速な修正を促す、問題の把握を早くする──といった現場の秘訣がある。 テストの中で「反復」を繰り返す 「危険な機能は先にテストするのが鉄則」。プライスウォーターハウスクーパースの高橋昭憲氏(シニアマネージャー)はこう考える。システム運用・保守を手掛ける高橋氏らは、頻発する変更・追加要求に対応して素早くテストするには段取りが重要という。 ここでいう段取りとは、テストの進め方を指す。危険な個所を前倒しでテストしておけば、もしバグがあっても手戻りが小さくて済み、テスト全体の効率は高まる。これを実現するのが「反復型テスト
品質という言葉の意味 測定との関係と視点 品質の種類 基本的な考え方 ソフトウェア品質特性 機能性品質特性の品質副特性 信頼性品質特性の品質副特性 使用性品質特性の品質副特性 効率性品質特性の品質副特性 保守性品質特性の品質副特性 移植性品質特性の品質副特性 利用時の品質とは 俯瞰 まとめ 品質という言葉の意味 「品質」という言葉は、我々の世界ではよく使いますが、 品質とは何でしょう。 品質が良い/悪い、と言ったり、 品質を上げる、と言ったりしますが、 これがどんなものなのか、明確に認識しているでしょうか。 いろいろな人の話を聞いていると、 意外と認識が一致していません。 人によっては、検証の結果を見て言います。 「このモジュールは品質が悪いね」と。 人によっては、プロジェクト開始前に言います。 「前回のような品質問題は起こさないようにしよう」と。 人によっては、常に使います。 「品質を測
機能するコーディングルールの策定でバグ作り込みを防止 何故、ソースコードにバグを作り込むのか。日立ソリューションズの田邊照雄氏が要因として挙げたのは、言語に認められている自由度と、言語仕様の理解不足の問題だ。一つの実装に様々なロジックが考えられ、一つのロジックに対し色々な書き方ができる。また文法など言語仕様を一通り学んでいても、コンパイラの処理系定義の動作等まで理解しているエンジニアは多くない。 そこでコーディングルールを策定し、開発を標準化する試みが行われている。田邊氏が紹介したルール作成のポイントはまず、既存のものをベースにすることだ。たとえばESCR「組込みソフトウェア向けコーディング作法ガイド」が有用だ。また、身近なプロジェクトで作成されたものも参考にするのもいい。ただし、ルール数は必要最小限にする。またルールの目的、ルールからの逸脱時のリスクを明確にしておくことだ。 静的検証ツー
Webアプリケーションの画面を設計するとき、皆さんは性能について意識していますか。機能面の要望を取り込むことに集中するあまり、性能は二の次になっていないでしょうか。 あとになって性能が問題になるプログラムは、設計時に過ちを犯していることが少なくありません。そのような性能トラブルは、チューニングで簡単に解決しないことが多いものです。設計時に性能リスクを明らかにして早めの対策を打っておけば、致命的な性能トラブルの多くを防げます。 今回は設計段階で性能リスクを早期に発見するための性能見積もり手法について紹介します。設計段階で性能を作り込む手法には、多様なものがありますが、今回解説するのはその前段階として必要になるものです。どの機能に対して、工数をかけて性能を作り込むべきかを明らかするのが狙いです。 性能を見積もるメリットは二つ 設計段階では動作するプログラムが存在しないので、性能評価においては、
今回は、性能要件を具体化するポイントを紹介します。皆さんは、性能要件に何を定めればよいと思いますか。 システムの性能要件で、「Webアプリケーションの画面レスポンス時間は3秒以内であること」「バッチアプリケーションは毎日午前0~午前5時の間に終了すること」としか定義していないプロジェクトを見かけます。この場合、以下のような問題が潜んでいます。 (1)全機能の処理時間を同じレスポンス時間に収めなければならない 全機能に対して同じレスポンス時間を目標とするのは現実的ではありません。なぜなら、機能によって求められるレスポンス時間と処理の複雑度は異なるからです。 例えばコールセンターのシステムで、「(a)電話オペレーターが操作する画面」と「(b)管理者がマスターデータをメンテナンスする画面」があるとします。レスポンスの悪化が直ちにビジネス機会の損失につながる(a)の方が、求められるレスポンス時間は
性能要件の実現は重要だと認識しながら、「結局、性能は構築し終わるまで分からない」といったスタンスでプロジェクトに臨んでいないでしょうか。最初に性能要件を定義したあとは特に何もせず、カットオーバー直前にわずかな性能テストとチューニングを行うだけというケースを、筆者はよく見かけています。 そのようなスタンスでシステムを開発しても、性能要件をしっかりと実現できる可能性は高くありません。カットオーバー直前にその場しのぎの対策をするか、巨額の追加コストをかけてハードウエア増強に走る、といった状況に追い込まれがちです。 ITシステムの性能品質は本来、ライフサイクル全体を通して作り込むものです(図1)。設計、実装、テストの工程を通じて、システムの性能要件達成に取り組み、検証していく必要があります。 本連載では「システムの性能を確保するために何をすべきか」というテーマで、性能をマネジメントするための考え方
ソフトウェアは「目に見えないモノ」ですので、その評価は現時点でも非常に難しい課題の一つです。 見えないからこそ、ソフトウェア品質の評価は重要となります。 その難題に一つの光明を見いだしたのが皆さんもご存じのISO/IEC9126(JIS X 0129) ソフトウェア品質特性(Quality Characteristics) です。 (正式名称は「Information technology software product evaluation:Quality characteristics and guidlines for their use」) この規格は1991年(JISは1994年)に発行され、多くの人が存在(名前だけ?)を知っているのですが、その難解さ故利用されることは少ないようにも思います。 そこで、Software Quality.comではこのソフトウェア品質特性をある程
GQM (じーきゅーえむ; Goal, Question, Metric)は、メリーランド大学のビクター・バシリ教授によって開発された、ソフトウェア工学における計測の枠組みおよびモデル化手法である [1] 。 ソフトウェア工学におけるあらゆる計測は、無目的にメトリクスやデータを集めるのではなく、何のために測定するのか、前提となるモデルは何か、結果をどう解釈するかなどを明確にした上で実施されるべきである。 GQM 法はこれらを定義する枠組みとして代表的なものの一つであり、測定モデルを以下の3つの層で定義する。 ゴール層 (G、概念レベル) 測定を行う目的の定義。測定の対象、理由、観点、およびコンテキストを定めるものである。 クエスチョン層 (Q、運用レベル) 目的の達成のために評価すべき質問の定義。ゴールが達成されたか否かを判断する具体的な基準となるものである。 メトリクス層 (M、定量レベ
上流で品質を作り込むことを狙い,設計レビューを強化する現場が増えている。しかし,長時間に及ぶレビューは現場の負荷を高め,メンバーを疲弊させる。それだけの労力を投じても,重大な設計ミスが必ずしも減らないのが現実だ。3人のITエンジニアが座談会でその実態を語った。(聞き手は中山 秀夫=日経SYSTEMS) 情報システムの信頼性に対する要求が厳しくなるなか,品質管理を強化し「設計ミス」をなくそうとする動きがあるようです。みなさんの現場では,いかがでしょうか? Aさん:私は製造業のシステム部門に勤めています。設計の品質向上は,大きな課題になっていますね。テストでバグをつぶすのではなくて,もっと上流できっちり品質を作り込んでいこうという方針です。最近はレビューの強化に取り組んでいます。レビューの回数を増やしたのに加えて,設計レビューで有識者を必ず入れるルールになりました。 有識者は具体的にはどんな人
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く