３.開発方針
1)システムの信頼性を最も重視する。例えごく簡単な修正の場合でも、該当プログラム分だけでも、最低１回はテストする。
2)納期通りの完成、見積り通りの完成を第一にする。納期が守られねば、過剰サ−ビス分も一 切評価されない。
3)ユ−ザ要求纏めは必ず承認を受け、記録を残す。
4)ユ−ザ側のテストの検証や承認作業、開発者からの完成物品の納品手続きを明確に取り決め、完了日をはっきりさせる。納品システムの控えは同一バ−ジョンで、必ずバックアップとして保管する。
5)各種ハ−ド、ソフトの新技術や未使用のコマンドを導入する場合は、全面的に採用する前に、必ず少数デ−タでテストする。データベース言語ソフトなどパソコン用汎用ソフトの多くは例えば、カタログに記載されている機能仕様であっても色々な条件化での十分なテストはなされていない。
少数デ−タテストによって思いがけない現象を知る事がよくあり、ワンクッション置く事は、推進上予想外の着実感を得られる。
|
テスト手順では、各ソフト、ハ−ドを分解し、各部分間の関係を、出来れば１：１になるまで分解、列挙し、１：１のインタフェイスがうまくいくかをチェックする。特に開発元が異なっている部分同志はカタログと異なり、テストはされていないと見なす事。（ex. コネクタ−とケ−ブルと輸入ソフトと日本語処理と使用デ−タベ−スとパソコンインタ−フェイス間等)
又、使用ソフト、機器導入の準備作業、トラブル対応、ハードやソフトの開発元間との保守分担等を見積もっておく。
(1)操作性、レスポンスタイム等で予想通りの効果が上がるか。
(2)システムダウン等の問題点が出てこないか
6）あくまでパソコンとしての限界が存在することを踏まえデータ量や、データサイズ、処理内容は、
メーカーの標準例を越えないようにする。例外的な使用法を試みた場合はハード、ソフト共メーカーテストは充分でなく結果は保証されないというリスクを伴う。なるべく既存の実証済み標準パターンに合わせて設計、プログラミングする。
7）小型機ではハード、ソフト及びユーザー使用環境等の信頼性面から不測の事態が発生し易くバックアップ対策が不可欠になる。
| |