既存システムやプログラムへの影響を洗い出したら，変更個所をドキュメントにまとめていく。決まったフォーマットは無いが，「変更個所に漏れがないか一覧できる」ことが目標である。ソフトウエア開発プロセスのコンサルタントである，システムクリエイツの清水吉男氏が考案した手法で，改造計画のまとめ方のコツを見ていこう。 清水氏は改造作業に対して，「何を変更するのか（What）」「その変更はどこにあるのか（Where）」「どのように変更するのか（How）」を表現する三つのドキュメントを作成することを勧めている（図1）。まず，変更要求や変更仕様を洗い出し「変更要求仕様書」にまとめる。ロジックの変更点だけでなく，メモリーの使用量が増えるといった，改造による変化を漏らさず書き出す。「改造にはソースコードを変えない“変更”もあり得る。変更要求仕様書には，そういったものも表現しておく」（清水氏）。 図1●システムクリ

これまでの連載では、ソフトウェア要求管理の基本を理解していただくことを目標にして、RUPにおける要求管理の成果物とワークフローを取り上げ、要求管理の基本を解説してきました。今回はいよいよ最終回です。本連載の締めくくりとして要求管理ツールについてお話ししたいと思います。 ［注］ 要求管理ツールを説明するに当たって、要求タイプ、要求属性、トレーサビリティといった用語が出てきますので、もしこれらの言葉がぴんと来ない場合は、まずは、過去の連載を読み返してから、今回の記事をお読みになられると分かりやすいと思います。 要求管理ツールとは？ 一般的に、要求管理（requirement management）ツールというと、開発チーム内で一元的に要求を登録、編集でき、その際に、変更履歴や変更理由を記録することができるツールを指しています。また、それらの基本的機能に加えて、要求ごとに、優先度・リスク・担当者

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠

この連載では，ITエンジニアにとって必須のスキルと言ってよいPMの基礎知識と情報システム開発への適用方法を，事例を織り交ぜながら解説していく。 第1回　PM実践体系--重要性増すPM,そのシステム開発での実践体系を知る 第2回　プロジェクト計画--システム開発プロジェクトの「計画」を作成する 第3回　品質管理計画--プロジェクト全体を通じた品質基準や方針を策定する 第4回　見積もりとコスト計画--開発負荷を見積もり，プロジェクトのコスト計画を策定する 第5回　マスター・スケジュール　プロジェクト全体を見通す，実行性のあるスケジュールを作る 第6回　組織・要員計画--プロジェクトを効率的に推進できる組織・要員計画を作る 第7回　問題管理と変更管理--プロジェクトで生じた問題と仕様変更をコントロールする 第8回　ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り

先週，プロジェクト・マネジメントをテーマにした日経コンピュータ主催のセミナーに出かけた。この分野における専門家3人の講演をうかがい，いろいろと勉強になった。セミナーを聞き終えて興味深かったのは，講演者3人が3人とも，「システム開発プロジェクトが泥沼にはまり込む過程」を同じような表現で語っていた点だ。3人がそれぞれの経験に基づいて，「負のループ」「悪魔のサイクル」「悪魔のスパイラル」と呼んでいた。 これらの呼び方が示そうとしているのは，初めはプロジェクトに生じた小さな「遅れ」や「問題」だったとしても，悪魔のスパイラルを通じて徐々に深刻化していくという悪循環の存在である。このような指摘に「そうそう」とうなずいたり，「あぁ，確かにそうかもしれない」と気付いたり，あるいは「えっ？」と驚いたりと，読者の方々はさまざまな印象を受けていると思う。この機会に自分が関与するプロジェクトの状況について，点検し

Let's say you must test something that involves a lot of different variables. Configuration testing is like that: different printers, different print options, different documents. Who knows what … [Read more...] about Allpairs Sometimes you need to test a text field or document with different kinds of stressful inputs. But, it can be a pain to prepare the text data. PerlClip is a tool that helps y

The page you're looking for has moved, been replaced, or is currently unavailable to view. If you previously bookmarked a page and have now reached this message, check to make sure the link was not shortened, or go to our home page to find the page from there. We've been upgrading this site. If you selected a link on our site and reached this message, use the Back button to return to the previous

ソフトウエアの改造がトラブルの温床になっている。改造案件が増える一方で，改造ならではの方法論が未熟だからだ。プログラマやSE，プロジェクト・マネージャが一丸となって「改造力」を高めるノウハウを解説する。 第1回　ソフトウエア改造力が足りない：変更ミスがトラブルの温床に 第2回　ソフトウエア改造力が足りない：工数膨らませる影響調査と確認テスト 第3回　対応すべき案件を選ぶ：要望を集め，工数を概算する 第4回　対応すべき案件を選ぶ：費用対効果で優先順位を判断する 第5回　改造の影響を調べる：詳細な工数とソースコードの変更箇所を洗い出す 第6回　改造の影響を調べる：ドキュメントをまとめ作業計画をレビューする 第7回　テスト範囲を最適に決める：過去のテスト項目集めて漏れを減らす 第8回　テスト範囲を最適に決める：シナリオや環境整備でテストを効率化する 第9回　テスト範囲を最適に決める：本番リリース

テスト管理ツールには三つの機能がある。1番目は，リポジトリによるテスト情報の一元管理機能。リポジトリで「要件」「テストケース」「テストスクリプト」「不具合情報」などを一元管理する。2番目は，自動テストの実行管理機能。自動テストツールを連携させて，自動テストの実行を管理する。テスト結果はリポジトリに登録される。3番目は，集計/分析機能。リポジトリに蓄積した各種データを様々な角度から集計/分析し，画面や帳票に出力する。 こうしたテスト管理ツールを選定し，うまく活かすにはどうすれば，いいかを解説する。 ＜目次＞ 第1回 テスト管理ツール：表計算ソフトの限界超える 第2回 テスト管理ツール：要件とのひも付けがカギ 第3回 テスト管理ツール：管理者支援型か開発者支援型か 第4回 テスト管理ツール：テスト手順に工夫が必要 「プロダクト賢者の選択」過去の連載-----------------------

IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.