このブログを検索

2010年12月8日水曜日

Testing should be part of the development process from specification to maintenance

Testing should be part of the development process from specification to maintenance
One mark of a good product specification and/or software specification is that every requirement is testable and everything that should be tested should be listed as a requirement. In fact, the first draft of the test plan can and should be written alongside the specification. (The first draft of the user manual can and should be written at this time as well. It is a crucial part of the testing.)

2010年11月21日日曜日

機能設計と詳細設計 vs 意匠設計と構造設計

ITを利用した業務システムは建物によく例えれるが、
その構築手法も建物の構築手法からヒントを得るどころは多い。
システムの多様化や複雑化につれ、ますます機能設計と
詳細設計(=プログラム設計)の分業は必要になってくると思われる。

 建築構造って?

2010年11月1日月曜日

peopleware

業務システムはsoftware、hardware、そしてpeoplewareで成り立つ。
peoplewareとはシステムを利用する組織とユーザのことである。

業務システムがうまく機能するためには、それを構成する各部分が協調していなければならない。

softwareやhardwareは、人が正しい判断を下すために必要な情報を入手するためのツールであり、人間の代わりに判断をしてくれるものではない。


実世界のビジネス環境は常に変化している。

一番柔軟に変化に対応できる部分はpeoplewareであり、peoplewareが持っている柔軟性を最大限に引き出すには、softwareとhardwareがpeoplewareに対する縛りを最小限にする必要がある。

そのためには、softwareやhardwareはなるべく機能がシンプルで代替可能な部品で構成することが重要である。

また、複雑なデータ構造(複雑なリレーション、複雑な状態遷移)や複雑な処理ロジックは避けるべきである。

2010年10月28日木曜日

機関車、自動車、飛行機 & メインフレーム、PC、クラウド

機関車1820年代 >>> 高速電鉄1980年代
自動車1900年代 >>> 電気自動車2010年代
飛行機1930年代 >>> ジャンボ機1970年代
メインフレーム1960年代 >>> ???20?0年代
PC1990年代 >>> ???20?0年代
クラウド2010年代 >>> ???20?0年代

2010年10月20日水曜日

Work, Worship and Wisdom

Without flowers you cannot have fruits.
The maturation of the flowers into the unripe fruits and then into the ripe fruits,
is the path of self-realization.

The flowering stage is the path of service.
When it progresses to the unripe fruits it is the path of devotion.
When the fruits become ripe and full of the sweet nectar of wisdom,
then it becomes the path of self-knowledge. At that point, the flowers of good works and service
have transformed themselves  through love and devotion into the sweet fruits of wisdom.

Therefore, good works lead naturally to worship and detachment, and on to wisdom.
On the spiritual path, it is not enough to just worship; you must also engage in good works.
But your works become worship when you steep every deed with love for the Lord and offer all your works to him.

As long as you are in this world, you must be engaged in work.
Work is very important for human beings.
It is through your work and activities that you learn to harmonize thoughts, words and deeds.
For great souls, thoughts, words and deeds are always one.
At first you will yearn for the fruits of your work.
In the beginning, when there is still a great deal of desire,
you will not be able to perform your work without a desire to enjoy the fruits.
Later, however, you will become totally selfless and unconcerned with the fruits of your work.
In that way, gradually, your work becomes converted into worship and, in time,
you will be doing everything only for the love of God.

Truth is one, but the sages call it by many names.
The divinity is one, but many names are used to speak of this one absolute reality.
From the one come the many.
When a child is born it is called a baby.
As it grows up it becomes a youth.
After twenty years it becomes an adult and later a parent.
Later still in life, it becomes a grandparent.
But these are all one and the same entity.
Similarly, the ultimate reality is always one and the same.
When you realize this unity and remain firmly established in the one divinity
underlying all the changing names and forms, you will have achieved something that is truly worthwhile.

Sri Sathya Sai Baba

2010年10月13日水曜日

「ライト、ついてますか」読後感

ユーザはシステムが提供する機能がほしいのであって、システムを構成するハードウェアやソフトウェアがほしいのではない。
もし、ユーザがほしい機能を提供できるシステムがすでにあるのであれば、ユーザはわざわざ大金を費やして自らシステムを構築したりしない。

しかし・・・

Gerald M. Weinberg 曰く
「ちょっとみたところと違って人々は、くれといったものを出してやるまでは何がほしかったか知らぬものである。」

利害関係の渦の中で開発される大規模な業務システムともなると、よほど明確なゴールと強力(協力)なリーダシップがない限り、システム開発は失敗しないほうがおかしい。システム開発の成功、失敗をどのように定義するかは別の話になる。

2010年9月5日日曜日

ソフトウェアの仕様書は料理のレシピに似ている

ソフトウェアの仕様書は料理のレシピに似ている

ちなみに、この話を書いていて思ったのだが、プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ 端のエンジニアの書いたコードをレビューするのは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。も ちろん、レストランに行く側の立場になってみれば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレスト ランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。 --中島聡

2010年8月25日水曜日

業務システムの仕様書を書くのに適した言語

業務システムの画面表示仕様やデータ処理仕様には業務用語が沢山使われる。
これらの業務用語は、業務データ(もの)を表すものもあれば業務処理(事)を表すものもある。
五万とある業務用語をすべて明確に定義しない限り、仕様書に曖昧さはつきものである。
形式言語(例えば、Z言語)を用いれば曖昧さはなくせるかも知れないが、特別な訓練を受けない限り、仕様書の記述と理解は極めて困難になる。

なので、業務システムの仕様を記述する言語には、自然言語の分かりやすさと形式言語の厳密さとのバランスが必要である。最近欧米でPython言語がポピュラになっているのも、英語を使う人から見ればPythonはJavaよりバランスが取れているからだと思う。ただし、Pythonは変数や関数をAlphabetでしか記述できないので、日本の業務システム開発現場では、Java言語の方が向いていると思う。

2010年8月24日火曜日

要求、仕様、設計、実装

要求:
抽象的に、分かり易く表現する。
コスト、納期のトレードオフの中で取捨選択する。

仕様:
厳密に表現し、測定可能でなければならない。
コスト、納期のトレードオフの中で決める。

設計(仕組み):
シンプルに、保守しやすい構造(構成)にする。
コスト、納期のトレードオフの中で改良を続ける。

実装(コード):
簡潔に、分かり易くコードを記述する。
時間が許す限り磨きをかける。
また、コメントにはコードの必要性を裏付ける”事情”を必ず書いておく。
コードを見ればわかるような内容をコメントに書く必要はない。

2010年8月19日木曜日

システム開発が決まったら

システム開発が決まったら
まずは、データ仕様について分析する。
管理対象となる業務データのかたまり(エンティティ)を識別し、
必要な属性と識別子(データの粒度)を洗い出す。

業務プロセスを加味する。
承認ステータス、手配ステータスと言ったステータス項目が増える。

データの追跡可能性やセキュリティと言ったことを加味する。
赤黒区分、履歴番号、論理削除フラグと言った項目や最終更新者、最終更新時刻と言った項目が増える。

外部システムとのデータ連携を加味する。
外部システムとのデータ整合性を保証するための外部データのキー項目が増える。

ここまで分析できたら、以下を設計する。
  •  コード体系
  •  データベース
  •  システム構成(HW、MW、NW)
  •  アプリのアーキテクチャ
  •  個別機能

機能概要
  •  機能が必要な理由
  •  画面モックアップ
  •  ボタンなど押された時実行される処理について
  •  想定される使い方
画面表示仕様
  •   レイアウト(セクション、タブ、フレームなど)
  •   表示項目(表示するデータ項目)
  •   表示フォーマット(日付、時刻、数値、電話番号、郵便番号など)
  •   表示ステータス(表示・非表示、活性・非活性)
  •   見栄え(フォント、色など)
画面操作仕様
  •   コントロールの種類(テキスト、プールダウン、ラジオボタンなど)
  •   Javascriptによる動き
画面遷移仕様
  •   Actionと遷移先
  •   子画面表示
  •   戻る
データ処理仕様(Input,Process,Output)
  •   トランザクション
  •   制御フロー
  •   データ加工

データ処理仕様について

データ処理仕様は、実装言語に依存させない。ただし、抽象度は実装コードとほぼ同じレベル。
フローチャートを使うのは編集や維持が不便なので、やはりテキストベースの言語が必要。
顧客にも処理仕様が理解できるように自然言語に近い表現が望ましい。
なので、現時点では日本語でプログラミングできるJAVA言語がデータ処理仕様の記述に最適だと思う。
JAVAでデータ処理仕様を記述すると以下のメリットが得られる。
1.厳密な表現と自然言語に近い表現が両立できる。
2.高機能な編集ツールが利用できるので、ドキュメント間の整合性維持が楽になる。