● システム開発 設計
この部分はSEという肩書きを持つ人がするフェーズです。私の場合は一人ですから先の「用件定義」から最後までやりますが。
用件定義から得られた情報を元にインフラ、ハード、開発言語、データベースなどを確定します。開発そのもの以外に必要な予算を提示します。
次に画面数、各画面のインターフェイスなどを確定します。こちらは顧客の相談で決めます。
この段階で工数がだいたい読めます、確定した工数表、見積もりを出します。用件定義の途中で概算の工数、見積もりは口頭なとで提示しています。
社内で利用されているデータの項目を確認します。それをデータベースのカラムに配置します。システム上必要なカラムを追加します。
画面、全体のフローを資料で清書して顧客企業に手渡し、確認を取ります。設計内容で顧客企業が操作する画面を確認してもらいます。
初期に基本的な設計を済ませて、約1週間ごとの開発部分を設計して進捗し、顧客企業に関係した説系内容は資料化して顧客企業に提示して開発内容に誤り、漏れが無いかを確認します。これは用件定義の再定義のようなものです。
データベースはシステムのキモの部分に当たりますので確定した仕様は「テーブル定義書」として顧客にも資料として納品とます。これは弊社以外の業者が以後を着手して際に仕様の把握を効率的にするためです。
基本的な設計は実開発前に済ませますが、詳細な設計はコーディングしながら行っています。
弊社の設計の基本スタンスは、
・初期2回から3回の用件定義と基本設計
・1週間単位での進捗確認、開発資料の提示
・PHP、PostgreSQLでの開発
・MVCパラダテムの使用
・ブラウザを用いたイタンーフェィス
設計の段階で用件定義の矛盾が出てくる場合があります、この場合は再確認して再定義を行います。その場合は設計のやり直しが発生します。もし、実開発に入っていると、コードの追加、修整も発生します。
顧客の業務分野を把握することがおそらく最も難しく、それが一番初めにする作業であり、これを突破しないと前に進めないというものです。
顧客側も開発者に対して要求をまとめ上げることも非常に時間がかかる作業と思われます。
たとえ数人の担当者がいてもシステムに必要な要求を全て事前に把握することは大変な作業と思います。初期の打ち合わせで要求をある程度まとめ上げていないとまず着手するのが難しいと思います。
たまに、初回に企業を訪問しても担当者の方が何も話さず、こちらからの話を待っているだけの時があります。こちらが推測できればお伺いしますが、そこから外れたものは確定できません。
用件定義が90%は確定して欲しいと思っているのですが。
腕時計のご紹介
クリスチャンボヌール
クロスフォー
|
■システムちょっと用語
●単体テスト
設計した最小単位でテストを行う。１つのプログラムや１つの画面単位。単体テストを徹底的に行いバグを潰しておくことで、その後の工程をスムーズに進めることができる。
●タイムシュアリング・システム
１台のコンピュータを複数のユーザが同時に使用するために作られたシステム。ＣＵＰの処理時間を短い単位で区切る事により、複数のユーザーの処理を効率良く準じ処理していく。
●ダウンサイジング
コンピュータを大型から小型なものへと入れ替えていくこと。コスト削減に有効的。小型機の性能が休息に向上して処理能力が高まったため、急速に取り入れられた。
●タスク
コンピュータが処理をする、ＣＰＵ内部における仕事の最小単位。OSから見た処理の実行単位。また、ユーザから見たひとまとまりの「仕事」を漠然と指す語として用いられている。
●帳票設計
システムで出力される各種帳票の設計。出力項目の配置は見易さ、わかり易さを最優先に考え、また、無駄な帳票出力は極力避けるようにし、ペーパレス化も図るようにする。
●テスト
プログラムやシステム全体が、設計した通りの動きをするかのチェックを行う。ノーマルパターンやイレギュラーなパターンすべてのパターンのデータを使用してテストを行う。
|
|
|
