製品・サービス 会社情報 事業紹介 採用案内 関連会社 トップページ
事業紹介
システム設計
ソフトウェアの研究・開発
総合テスト
個別対応・製品メンテナンス
Join Us
新しい領域に向かって止まらずに変化を追求し続ける我々は、大志を抱いている貴方の加入を待っております。
採用エントリー >>
ソフトウェア開発
    ASE上海のソフトウェア開発プロセスは下記に示します。
ソフト開発フロー図
1.PJ計画の作成
    PJを確定したら、PJ管理をスムーズに進めるには一連の計画を立てる必要がある。計画関連の作業は以下に示す。
        1) 責任決定
        2) リソース利用計画
        3) 研修計画
        4) 規模見込と工数見積
        5) スケジュール作成
        6) リスク管理計画
        7) 計画レビュー
2.要件定義書の分析
    要件定義書は顧客が提供し、顧客の要望を概要的に纏めた文書のことである。この文書を踏まえて顧客の要望を読みこなすべきである。理解時にNotesやEmailなどを利用して顧客に交流し、正確に要求仕様を把握する。大略説明を詳細化、充実化、且つ正確化のことを果たして最終確定書に反映する。
3.確定書の作成
    「要件定義書の分析」が終わったら、確定書を作成し始める。このプロセスでは設計みたいな作業を行う。設計のよりどころとしては「要件定義書の分析」で獲得した顧客の需要と結論で、確定書にはこれらの需要を分析した結論を記載するとともに、結論を基づいた詳細設計の内容も含める。(詳細は「システム設計」に記載)
4.CheckListの作成
    CheckListは、開発担当者がコーディング後の単体テストに使用されるものである。弊社はブラックボックス的な手段で単体テストを行う。CheckListを作成時、確定書を踏まえてモジュール機能が確実に実現しているかどうかを評価ポイントにすることを注意すべきである。
5.コーディング
    現在のPJではC++,VB,.Netを含めて多種の開発ツールと言語を使用している。開発者各自はコーティング規約に遵守しなければならない。これは開発正規化、及び今後メンテナンスにおいて重大な意義がある。
6.TestCaseの作成
    テストケースは評価担当者が作成され、評価のベースとなるもの。評価はバラックボックス的な手段を行われるため、評価者は確定書に基づき、機能が漏れなく正しく実現されているかどうかを検証する。
7.単体テスト
    単体テストは開発者が作成したCheckListに従い、モジュール毎にテストを行う。
    テストケースを実行したことより、出力した結果が期待値の通りになっていない場合、二つの解釈しかありえない。それはモジュールの不具合、でなければテストケースそのものが間違っている。このような迷惑を極力回避する為、テストケースを実行する前、テストケースをレビュー・チェックする必要がある。また、開発担当者が自分の作成したモジュールをテストするわけには行かなく、メンバーと交換してテストすること。ただし、デバッグは本人で行うこと。
    一つ注意すべきことは、単体テストの目安としてモジュールが正常の動作できることを証明するわけでなく、モジュールにバグのあることを証明するわけだ。
8.ソースチェック
    開発者はコーディングの同時、ソースチェックを行う必要がある。バグを早ければ早いほど発見できれば、修正にかかるコストが低い、影響範囲も少ない。
    ソースチェックとは、単位毎にコードを読むことでコーディング規約の遵守や不具合の発見などを含めて一連チェックの集合である。
    メリットとしては、1.不具合のところを正確に把握でき、デバッグコストの軽減ができる。2.このプロセスで同様なバグを複数個所に見つけることができ、一括に修正できる。
    普通、開発作業ではソースチェックにより30%~70%のロジックミスとコーディングミスを発見できる。ただし、このチェックは上位設計階層に潜んでいるバグを見つけることが難しい。例えば、要件定義書を分析ときに、誤解によるバグ等。
    一般的には、チェックリストを使用してよくあるバグを見つける。よくあるバグは以下に示す。
        1) データ引用エラー
        2) データ宣言エラー
        3) 演算エラー
        4) 比較エラー
        5) 制御フローにおけるエラー
        6) インタフェースにおけるエラー
        7) IOエラー
        8) その他のエラー
    ソースチェックは新規開発APで大きな役割を果たしている。一方、機能修正のAPに対しても同じ、更なる大きな役割を果たしている。経験によると、機能修正は新規作成よりバグが発生しやすい。それで回帰テストを行うほか、機能変更のAPではソースチェックの必要もある。
9.総合テスト
    単体テストを完了した、評価工程が始まる。完璧な単体テストを行ったでも、すべてのバグを漏れなく発見したとはいえない。それで総合テストを行うにより高度な評価を実行する。総合テストは以下の内容を含める(詳細は「総合テスト」に記載):
        1) 機能テスト
        2) システム テスト
        3) 受入テスト
        4) インストール テスト
10.正式リリース
    顧客に完成品をリリースする。
11.最終文書の作成
    時には顧客が総括的な文書を作成するのを要求する場合もあるが、このような文書は一般的に仕様書と呼ぶ。
12.運用説明
    上記は汎用開発の場合に適用する。実際作業のときにユーザーの要望に応じて適合に調整する場合もある。
中文 ご利用条件 情報セキュリティ サイトマップ 採用エントリー
Copyright (c) AMANO Software Engineering (Shanghai) Co., Ltd. All Rights Reserved.
沪ICP备06007265号

沪公网安备 31011502004515号