newpiaoyun的专栏

无论学习什么技术，都需要了解该技术的本质。若是靠死记硬背该技术提供的方法或者语法，终归是知其然而不知其所以然，当发现错误时，你根本不知道是什么原因导致的。我在使用Git时，就处于这种知其然而不知其所以然的状态。现在，再来补补课。Git有三个工作区域，分别为：工作目录（Working Directory）、暂存区（Stage或Index）以及资源库（Repository或Git Direct

機能設計書のドキュメント体系   これまでに、表紙、目次／概要、I/O関連図、画面／帳票レイアウト、項目説明書について説明してきました。今回は残りのドキュメントについて説明し、詳細設計フェーズのドキュメント編を完了します。詳細設計フェーズのアウトプットの1つである「機能設計書」を構成するドキュメント構成は、表1のとおりです。ドキュメント

常駐・派遣型ビジネスから脱却するには   ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。   その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者

請負で仕事をするために必要な2つの作業   システム開発の仕事では、仕様の追加や変更は日常茶飯事です。「これで仕様凍結！と宣言して、仕様変更を受け付けなければ良い」などとこちらの勝手を言う人もいますが、事はそう簡単にはいきません（安易な変更を抑制する効果はありますが…）。現実的にはその仕様のままじゃ動かなかったりするので、ある程度の追加・変更はあるものと覚悟しておく必要があ

基本設計のドキュメント構成と作成手順   第1回で「業務フロー」、第2回で「機能一覧表とI/O関連図」について説明しました。今回は残りのアウトプットを取り上げて、基本設計フェーズのドキュメント標準を完了させることにします。「DUNGEON」の標準で定義されている基本設計工程のアウトプットは、表1の通りです。工程ドキ

機能設計書のドキュメント体系   設計ドキュメント標準「DUNGEON」で定義されている設計工程のアウトプットは表1の通りです。「DUNGEON」では、基本設計書で骨組みを定義し、詳細設計書で肉付けを行います。つまり、基本設計書で作成したドキュメントはそのまま（必要に応じて修正も加えて）利用され、さらに詳細機能を表すためのドキュメントを追加して「詳細設計書」となります。

テストのプロセス   ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます（図1）。図1：テストの4つのプロセス   テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など

設計＆テストのＶ字モデル   一般にウォーターフォール型開発におけるテストは、図1のようなV字モデルで表されます。DUNGEONは、このV字モデルにのっとった設計＆テスト体系を採っています。   つまり、次のように要求分析と総合テスト、基本設計と結合テスト、詳細設計と単体テストを対比させ、各テストでは対応する設計書の内容を満たすことを確認するのです。

ソフトウェアライフサイクルプロセス（SLCP）とDUNGEON   「DUNGEON」はソフトウェア開発の各工程において必要とするドキュメント標準を決めて、その具体的なテンプレートを用意したものです。概念的なアプローチとはまったく逆に、アウトプット側から開発プロセスを標準化するという実践的な考え方を重視しています。   これまで7回にわたって、基本設計から詳細設計、