对日软件开发作业流程.doc

对日软件开发步骤日本软件项目开发进度控制很严格，项目极少出现延期，一旦延期，伴随而来就是大宗罚款，所以，日本软件项目很重视按期交付。在日本软件项目进度控制中起关键作用就是软件阶段定义。日本软件项目阶段分项目提案、要件定义、概要设计、具体设计、编写代码、单体测试、结合测试、系统测试、编写手顺等。项目提案指项目可行性分析、项目立项，是用户需求正式提出阶段，本阶段出具项目提案书。要件定义指业务需求具体确定和系统需求具体确定，系统需求关键包含软件安全性，运行速度，网络环境，运行环境，平台，架构等方面要求，和技术选择调查，本阶段出具业务要件定义书和系统要件定义书。概要设计指功效设计，系统架构设计，界面设计和数据库设计，其中界面设计和数据库设计包含内容最多，要求最具体，本阶段出具概要设计定义书、数据库设计定义书和界面设计定义书。具体设计关键指编码前类设计，类中方法属性设计，类之间调用关系设计，本阶段出具具体设计定义书。编写代码指各模块责任人编写相关代码，在编码之前还要编写单体测试式样书，本阶段出具程序源码和单体测试式样书。单体测试指由各模块编码人员完成各自模块单体测试工作，单体测试完成要求各模块独立运行时缺点均消除，本阶段出具单体测试票。结合测试指各模块单体测试完成后，各模块同时运行时，模块之间运行情况测试，包含业务流，负载，运行速度，稳定性，一致性等内容，本阶段出具结合测试票。系统测试指系统各模块统一运行缺点均消除后，模拟用户环境运行测试过程，本阶段要尽可能模拟用户实际平台，用户数量，硬件环境，软件环境，网络情况，用户数据进行系统测试，本阶段出具系统测试票。编写手顺指编写用户手册，本阶段出具安装手顺、使用手顺和维护手顺。对日开发基础步骤中包含了以上11个阶段，每个阶段为一个里程碑，每个里程碑在安排计划时全部要求了明确完成期限，这些阶段性里程碑是项目进度关键点。每个阶段完成后必需进行阶段Review，这种阶段Review起到了阶段验收和总结作用。阶段Review是日本项目阶段控制关键。只采取阶段Review方法进行验收也有其不足之处，全部验收工作全部放在阶段完成再进行，阶段中错误后续连续放大无法得到控制。而且通常情况下，阶段Review时问题会比较多，Review后修改时间比较长，修改次数也较多，造成很大程度反复工作。再有，标准对日软件开发过程中，阶段内任务安排和验收比较；无序，很多问题会被有意推迟到Review时处理。要件定义决定了系统全部功效，说本阶段产出结果物左右了整个系统成败也不为过。输入输出1.用户业务需求1.要件定义书2.网络结构定义书要件定义输入是用户想要系统化业务需求。系统开发是为了用户企业业务更灵活及高效。而要件定义目标就是明确用户想要系统化业务逻辑。进行要件定义所需含有能力当进行上面所说要件定义时，需要有以下能力。1. 了解用户企业商业模型必需要充足了解用户是怎样进行商业活动。要明白为何须需系统化，为何要建立这么商业模型，要搜集各方面需求，不能有遗漏。因为到后期，当发觉需求分析不充足时将造成整个开发系统全部无用。另外，假如做了过多分析，只要将不用功效放弃掉就能够，对进度影响很小。当然，对不需要功效开发投入金钱成本，用户是不需要支付，全部由开发方负责。2. 和用户谈判能力和人谈判能力是指待人能力，协调能力。对方是给钱用户，不能用严厉语言激怒对方。对于无法了解需求要努力在当初就了解了，对于用户所要求不合理需求要能协调好。这个不像其它能力能够经过培训或以往经验来填补，关键取决于个人性格，是相当关键能力。3. 进行要件定义同时，要能想象到下一步怎样据此进行外部设计需要有逻辑思维能力，用最近话说就是logical thinking。用户单方面表示自己需求，在当场立即明白那些功效是能实现，哪些是不能实现是很关键。举个极端例子，开发考勤管理系统。明明没有统计天天上班下班时间，却要用图表显示每个月工作时间，这么需求显然是无法实现。这种情况下，要么提出开发一个新功效统计天天上班下班时间，要么和用户讨论是否真需要算出每个月工作时间这个功效。外部设计之前，要件定义阶段，发觉需求不合理能力是很关键。要件定義開始条件1. 側要求事項整理事。2. 開発案件受注、契約締結事。汉字：1. 用户整理要求事项。2. 发包并签署合约。要件定義目标1. 業務化要求作業要求定義。结果物要求定義書。2. 要求実現、化要件作業要件定義。结果物要件定義書。3. 要件定義、化範囲明確、開発工数費用見積為行。汉字：1. 整理用户要求作业为要求定义。结果物是要求定义书。2. 整理系统要件作业为要件定义。结果物为要件定义书。3. 要件定义目标是为了明确系统范围，预估系统开发所需工数及费用。要件定義担当1. 要求定義、要件定義中心行。2. 側関係部門担当者集、化委員会発足、要求事項導出、要件定義行。3. 開発者情報関専門知識提供、要件定義作業支援。汉字：1. 要求定义及要件定义应该以用户为中心。2. 用户应召集相关部门责任人，成立系统委员会，导出并整理要求事项，进行要件定义。3. 开发人员提供信息系统相关专业知识，支援用户要件定义作业。要件定義方法1. 化事明確定義、開発者漏伝。2. 自業務定義。、誰、何、何為記述。3. 業務上何問題挙。問題対解決記述。4. 解決方法、業務止、運用変、化等、面体制面、関係者影響等、側面検討、決定。5. 問題解決方法中化、開発者情報専門家立場助言。汉字：1. 用户须明确定义系统要求，并要无一遗漏传达给开发人员。2. 用户须定义自己业务。逐一统计谁、在哪里、做什么、怎样做、为何做。3. 列举业务方面存在问题。统计每一问题怎样处理。4. 处理方案有“终止业务”、“外包”、“变更应用”、“系统化”等多个，须从成本、体制、对利害关系人影响等多个层面研究后决定。5. 相关处理方法之一“系统化”，开发人员须以信息系统教授立场提出谏言。要件定義基資料1. 中長期事業計画書。2. 業務内部資料（業務/業務定義書/業務等）。3. 業務課題一覧。4. 現行、現行各種資料（出力帳票/操作/設計書/仕様書等）。5. 。6. 用紙。7. 打合議事録。汉字：1. 中长久事业计划书。2. 业务内部资料（业务指南/业务定义书/业务流等）。3. 业务课题一览。4. 如有现行系统，则需提供现行系统多种资料（出力帳票/操作指南/設計書/仕様書等）。5. 听取页。6. 调查问卷。7. 会议统计。要件種類業務面業務?布署?拠点?効率面機能?操作性?品質?性能?運用面?保守性?拡張性?安全性?運用?運用体制?要件定義確認1. 課題何。2. 課題何時続。3. 課題何時解決。4. 課題解決効果見込。5. 課題主布署誰担当。6. 課題解決。7. 何故、解決方法取。8. 課題何原因起。9. 課題放置影響。10. 課題解決方法、化選。汉字：1. 课题是什么。2. 课题连续到什么时候。3. 课题在什么时间前必需处理。4. 课题处理后会有怎样效果。5. 课题关键是由哪个部门谁负责。6. 课题准备怎样处理。7. 为何采取这种处理措施。8. 课题是基于什么原因发生。9. 课题不做处理话会有怎样影响。10. 课题作为处理措施，没有选择系统化会怎样。要件定義書項目1. 項番2. 部門3. 部門担当者4. 業務名5. 課題6. 課題分類(経営戦略、情報戦略、業務上問題等)7. 対応方法8. 対応方法分類(業務変更、業務廃止、変更、新規化等)9. 実現可能性10. 優先度11. 実施期限12. 備考要件定義書作成時注意点1. 一項目一要件書。複数要件書。2. 表現統一。汉字：1. 一个要件自成一项。2. 统一采取“”这种表示形式。要件定義変更管理1. 必文書事。2. 変更理由背景明確事。3. 関係者合意取事。4. 她要件整合性取事。5. 工数費用見積、周知事。6. 技術裏付取事。7. 優先度実現時期確認事。8. 効果試算事。9. 変更履歴残事。汉字：1. 采取书面管理。2. 明确变更理由和背景。3. 和利害关系人达成一致。4. 和其它要件没有矛盾。5. 预估工数和費用并让组员周知。6. 保留技术证据。7. 确定优先级和实现期间。8. 试算效果。9. 保留变更履历。结果物1. 業務定義書2. 現行業務3. 新業務4. 要求事項一覧5. 課題一覧6. 議事録7. 要件定義書終了条件1. 要件定義書関、側開発側合意取事。汉字：1. 相关要件定义书，用户和开发人员要达成一致。設計開始条件1. 要件定義終了、要件確定事。汉字：1. 要件定义结束，要件已经确定。概要定義1. 目标（期待効果）記述。2. 範囲（対象業務?対象布署?実現機能）記述。3. 前提条件（事?事?実現程度）記述。4. 概要（機能概要?運用処理概要）記述。汉字：1. 描述系统目标（期待效果）。2. 描述系统范围（对象业务?対象布署?实现机能）。3. 描述系统前提条件（能做事?不能做事?实现程度）。4. 描述系统概要（機能概要?運用処理概要）。方法設計1. （?PC?機種?CPU?）構成図作成。2. （回線?回線速度）構成図作成。3. （名?）構成図作成。汉字：1. 作成硬件（服务器?PC?打印机?机型?CPU?内存?硬盘）组成图。2. 作成网络（回线?调制解调器?路由器?集线器?桥接器?转发器?回线速度）组成图。3. 作成软件（软件名称?版本号）组成图。结果物1. 概要定義書2. 構成図（構成?構成?構成）汉字：1. 系统概要定义书2. 系统组成图（硬件组成?软件组成?网络组成）終了条件1. 结果物完成事。2. 结果物承認得事。汉字：1. 结果物完成。2. 结果物得到用户认可