法人向けプロフェッショナルソリューション

インテグレーション

ERP、SCM、CRM、企業経営の付加価値を高める様々なシステムが台頭する今日、
企業戦略、企業経営の発展に対するコンサルティング、
課題解決のためのソリューションを提供します。

最近の本流であるWebシステムの構築では

  • オープンシステムを採用することでのTCO削減
  • リッチクライアントを活用した高機能GUI
  • OOP(オブジェクト指向プログラミング)による柔軟な拡張が、
    差別化を図る有効なファクターとなります。

これらのテクノロジーを用いたシステム構築を、

  • プロトタイピングによる完成イメージの提供
  • 機会損失を低減するためスパイラル、
    XP(Extreme Programming)による短工期のシステム開発を駆使し、
    お客様と一体となってシステム構築を行います。

システム構築の流れ

step1
要件定義
お客様から業務のシステム化の相談を受けると、まず「お客様が困っていることは何か」「お客様の悩みは何か」ということを聞き、システムエンジニアの視点 で「システム構築を通してどのように実現すればお客様の課題が解決できるか」「そのシステムは実現可能なのか」と言う事を具体的に検討していきます。この時点でお客様はまだ曖昧なイメージしかもっていないため、システム実現のために何が必要かと言う事を話し合いながら、お客様の業務を構造化して整理し、お客様と私たちのイメージを合わせていきます。
step2
設計
要件定義の段階でどのようなシステムを作るかが決まったら、設計に入ります。設計は大きく「基本設計(外部設計)」と「詳細設計(内部設計)」の2つに分 かれます。基本設計では、実際お客様が使用する状態を想定し、どういう機能・項目が必要か、デザインをどのようにするかなどを、お客様と話し合いながら検討します。詳細設計では、基本設計を基にプログラムを作成するためのより詳細な仕様書を作成します。
step3
制作
設計の段階で作成された仕様書を基にして、プログラムを作成します。この工程は、多くのメンバーを必要とするので、経験豊富な弊社パートナーとも連携することもあります。オフショアの優秀なプログラミング技術を持ったメンバーへの依頼も最近は増えてきています。
step4
テスト
いろいろな視点でテストをして、要望通り設計した物が作られているかを確認していきます。
3段階のテストで品質を保証していきます。
単体テスト:詳細設計書通り動いているかどうか、内部のプログラムがきちんと動いているかを確認します。
結合テスト:基本設計書通り動いているか、機能として外から見たときに正しく動いているかを確認します。
システムテスト:要件定義書どおり動いているのかをお客様目線で確認する
step5
本番
テストを終えると、いよいよ本番化します。
step6
運用、保守
システムはお客様の業務の変更に対応していくことが求められます。システムが正常に動き続けるために日々整備しておくとともに、お客様のビジネスの変化に合わせてシステムの改修などを行ってお客様の業務を滞りなく進めることをサポートしていきます。
システムの改修は小規模なものから大規模なものまであります。大規模な改修になるとまた要件定義からプロジェクトチームを作って進めていきます。

構築の種類

お客様の業種、業態、規模、スケジュールなどを総合的に判断し、適切な開発手法、手順で開発を行います。
1.プロトタイプ型

プロトタイプ型

[メリット]
試作品を早期に開発することにより、ユーザの要件漏れや開発側との齟齬が減少する。

[デメリット]
プロトタイプの開発に時間が掛かり、全体工数が肥大化する傾向がある。

2.スパイラル型

スパイラル型型

[メリット]

  • 機能の一部を早期にユーザに確認できるため、ユーザの要件漏れなどのリスクを軽減できる。
  • 一定の技術者数で開発を進めるため、各技術者に技術や業務知識が蓄積され、品質や生産性の向上が図れる。
  • 技術者の確保が比較的しやすくなる。
  • [デメリット]

  • 大規模システム開発の場合、最初の開発単位の見積もりが難しく、見積もり誤差により、開発作業に遅れが出ることがある。
  • 各工程で、手戻りが発生し、場合によっては、ウォーターフォール型より工期や工数が多くかかる場合がある。
  • 複数の開発が並行で進むため、管理が難しくなる。

開発標準化

これまで説明してきた開発プロセスモデルのような「開発プロセス」の標準化や、成果物とするドキュメント(設計書やテスト仕様書など)の標準化、コーディング規約などのことを言います。開発プロセスやドキュメント、コーディングを今までのシステム開発の経験、積み上げた技術から 最適と思われる形で標準化することにより、開発を効率良く進め、開発期間を短縮し、開発コストを削減、また、品質を向上させる目的があります。

開発手順のモデルとなるような開発プロセスが考えられてきたのと同様に、成果物である設計書やテスト仕様書などのドキュメントの標準化やコー ディングの仕方を詳細に定義した規約などがあります。通常は、各開発プロジェクトによって、ドキュメント規約やコーディング規約が定義され、各開発者に遵守するよう通達されます。また、大手SIerには、社内標準と言われる開発プロセス、ドキュメント規約、コーディング規約があり、各プロジェクトは、それ を遵守する形で、開発を進めていきます。

ドキュメント規約には、成果物の定義(何を成果物とするか)や各フォーマットや記述のルール(フォントタイプ・フォントサイズ・項番・記述内 容)などが定義されています。また、コーディング規約には、プログラムや変数名のルールである命名規約や、コーディングのルールなどが詳細に定義されてい ます。これらの規約によって、統一されたドキュメントやプログラムのソースとなり、メンテナンス性や品質の向上に繋がっていきます。

お問い合わせ


各種インテグレーションのお問い合わせはこちらから

各種お問い合わせ

ソリューション・サービスのご相談・お問い合わせ
法人のお客様専用のお問い合わせ窓口
お問い合わせフォームへ
  • 営業時間外のメールでのお問い合わせは、返答までお時間がかかる場合がございますので、あらかじめご了承ください。
  • インターネットからのお問い合わせはすべて拝見させていただきますが、内容によっては返答できかねることがございますのであらかじめご了承ください。
  • お客様からの製品の開発や企画に関するご提案等は、承っておりませんので何とぞご了承ください。
  • 個人情報に関するポリシーは、こちらをご覧ください。
  • 新規お取引に関する申請は、お申し込みページをご利用ください。
Copyright© Appaloosa UniBirth All Rights Reserved.