BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

          學習與感受

          Posted on 2008-10-29 10:00 dybjsun 閱讀(230) 評論(0)  編輯  收藏 所屬分類: 工程管理

          日語剛學,有很多問題,請指正。
          ?

          1.? 設計書の作成について

             1 つの設計書は1つのレビューできる成果物です。不同の使用者向け、設計書に該當の內容を明記すべきであります。

          ?????? SD の方面

             SD 階段の設計書は構成設計書です。書く時に、以下の観點を注意されます。

          ????? この設計書の使用者は MK1 の擔當者と MK3 の擔當者です。この設計書によって、ソースは作成することができます。しかも他の問題を考慮する必要がありません。 MK3 の擔當者はこの設計書よりテスト設計書を作成することができます。

          ????? この設計書の詳しい程度、品質の要求の高低と時間に係ります。最低の要求は、すべてのクラスとメソッドにインタフェースやパラメータをはっきり書きなければならなくて、簡単な処理フローを書きます。しかも言語は曖昧な意味があることができません。

          ????? この設計書を書く時、きっと先にクラスとメソッドの一覧を作成して、且つ根拠を書き出します。また、 FD の設計書のすべての機能を全部含ます。

          ????? 設計書を書く時、條理があって、入力から出力まで 1 つのステップずつを説明します。一足飛びのロジックがあることができません。

          ????? 言語は分かり易くなって、多義性があることができません。且つレビューし易いために多くの細い點を注意します。

          ?

          ?????? BD の方面。これらは近日 FJ 殿の BD 設計書から習いました。間違いの場所を指摘してください。

          ????? BD 階段の設計書は基本設計書です。ユーザ(例えば:本製品の使用者)の立場からこの設計書を作成します。ユーザのすべての需要に対応して、説明を行います。

          ????? システムのソフトウェア、ハードウェアの規模性と複雑性に対して、設計書に対応することがあるかどうか。

          ????? システムの拡張性、設計書に対応することがあるかどうか。

          ????? 使用された技術の複雑性と難しくに対して、製品の高い品質のために、設計書に対応することがあるかどうか。

          ????? 性能とセキュリティなど方面、設計書に対応することがあるかどうか。

          ????? この製品はどれくらいの時間を使うことができます。設計書に対応することがあるかどうか。

          ????? ユーザの需要が曖昧の場合、設計書に対応することがあるかどうか。そして増えるまたは減らす作業量、複雑性などに対して、考えることがあるかどうか。

          ????? 言語は分かり易くなって、多義性があることができません。設計書を書く時、どのようにレビューし易いと考えます。

          ?

          ?????? FD の方面。

          ????? FD 階段の設計書は機能設計書です。主に基本設計書を対応して、コンピュータの上でどのように実現します。

          ????? 基本設計書と構成設計書の間すべての設計は機能設計書の內容だと思います。この設計書は開発者の根拠です。內容必ずは合理的と正しいです。

          ????? 言語は分かり易くなって、多義性があることができません。且つレビューし易いために多くの細い點を注意します。

          ?

          2.? レビューについて

          ????? 設計書では、プロジェクトと會社の規約によって、 Excel 版文書または Word 版文書があります。 Excel 版の文書は分かり易くて、しかしレビューに役立ちません。 Word 版の文書はレビューに役立って、しかし分かることは苦労しています。

          ????? 設計書の難しい程度と會社のデータによって、予定するバッグ數を確定します。

          ????? 設計書を書き終わった後に、自己レビューして、向かうしレビューすることが必要です。

          ????? レビュー前に、本回のレビュー観點を明確します。

          ????? レビューの時に、擔當者は設計書を読むんで、レビュー者は問題を指摘します。問題のタイプによって、分類します。

          ????? レビュー終わったから、レビュー結果報告書と結果分析報告を作成します。指摘されたバッグ、バッグの原因、予定するバッグ數によって、分析して、見解を提出します。また、もう一回レビューが必要かどうかとレビュー観點を確定します。合計するバッグ數は予定するバッグ數より大きくまたは少なく場合、管理者はこの問題を重視する必要があります。

          ????? レビュー結果報告書と結果分析報告によって、管理者は設計書の品質と擔當者の問題を見ます。

          ?

          3.? プロジェクト管理について。

          ????? オフショアので、プロジェクト內容は明確にしなければなりません。明確しない作業があることができません。

          ????? プロジェクトの開発の中で、 2 つの表を保守する必要があります。問題一覧表と作業一覧表です。

          ????? それぞれのデータを取得します。例えば:新規開発 1k ステップ當たり各階段の指標、レビューのバッグ數等。

          ????? MK2 MK3 CT ST それぞれのテスト観點を明確しました。テストされる內容はソース、構成設計書、機能設計書、基本設計書です。

          ????? 線票で進捗情報を表示します。

          ????? プロジェクト會議に問題を記録して、次の會議にすべての問題を確認します。

          ?

          ?

          主站蜘蛛池模板: 固镇县| 安岳县| 嘉禾县| 义马市| 子长县| 衡水市| 蒙山县| 当阳市| 昌邑市| 汉川市| 图片| 镇远县| 洪江市| 沛县| 巴青县| 商都县| 和政县| 都江堰市| 通山县| 浦东新区| 阳新县| 卓资县| 亳州市| 环江| 遂溪县| 林芝县| 麻栗坡县| 行唐县| 宜兰县| 无锡市| 新巴尔虎左旗| 三明市| 呼和浩特市| 张家港市| 东海县| 大同县| 偏关县| 通州市| 海城市| 金塔县| 井冈山市|