需求分析：根据任务书开展项目的需求分析，并由任务承担人完成《项目需求分析规格说明书》
初步设计：按照任务分配及项目进度要求，根据《项目需求分析规格说明书》，任务承担人完成《项目初步设计规格说明书》。
详细设计：按照任务分配及项目进度要求，由任务承担人对项目进行详细设计
代码编写：至少应完成项目开发计划和需求分析中要求的功能，可以适当增加
测试：对实现部分的软件功能或者模块进行测试，并完成《项目测试报告》
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
一：编写目的
本文档的编写旨在探寻规范的软件开发流程、加快软件开发速度、提高软件开发质量、降低项目综合成本。
IT界有一句格言："You can do it right; you can do it fast; you can do it *****. Pick two." 而我们要做的就是：提供优质服务、项目周期短、成本低廉
二：总体说明
项目从用户需求说明书的提出，到系统的第一个完整版本的交付使用经历了若干或复杂或简单的过程，但不管项目大小如何一般需要经历以下几个步骤：
1． 需求分析。
2． 撰写需求规格说明书
3． 总体设计
4． 详细设计
5． 编码实现
6． 测试、试运行、上线
7． 验收
8． 日常维护
9． （下一个版本的循环开发）
在以上各步骤中尤其重要的是系统分析和撰写需求规格说明书。当定义好《需求规格说明书》后需要用户签字确认，以此作为项目验收的依据，在中大型项目中尤其重要。
失败的项目原因很多但以下几点比较普遍：
（1）商务运作中为了拉住“单子”对客户的众多纷繁复杂的要求一味的妥协让步满口答应。项目开发计划、时间表等完全依照客户意见，不以具体项目的客观事实为依据，不做认真细致严格的项目复杂度、项目工作量的评估。
（2） 不做细致的用户需求分析导致项目后期的需求变更较大不能按期完成项目。
三：项目开发经历的各阶段
在项目开发的各阶段时间比例方面，中小项目一般控制在
1： 40% 设计
2： 40% 编码
3： 20% 总体设计/试运行
3．1 需求分析阶段
研究客户需求，从中找出需求中模糊不清的地方，反复讨论确认。在不断的确认中，包括需求的总体认知、需求边界定义、目前技术条件下的可实现需求、用户界面等。通过项目组内讨论、与客户（直接客户、间接客户）讨论等方式不断清晰客户真正的需求，从而撰写〈〈需求规格说明书〉〉，在取的客户认可后签字，以此做为项目开发的第一个里程碑。在项目验收时以此作为验收的主要依据
在系统分析阶段与客户的沟通方式可以通过（1）项目静态图、项目静态界面DEMO（2） 系统用例图（例如：rose软件的用例图） 等方式与客户沟通。
本阶段要完成的工作有：
1．撰写项目需求分析报告
本报告主要目的是项目分析人员提出需求的疑难不清问题，为与客户有效、准确沟通准备必要的材料。
2．画用例图
描述系统各个不同用户类型与本系统及其他系统等的交互过程。
3．建立项目静态界面DEMO
使得用户在项目初期就可以看到项目上线实施后的使用界面和使用方法等
4． 做必要的技术预研等。
3．2撰写需求规格说明书
需求规格说明书的撰写主要目的是把客户天马行空、纷繁复杂、凭想象等的理想需求中变成在一定时间段、一定技术条件下可实现的需求。不然项目会很难满足客户的理想需求，永远被客户的理想需求所限制，陷入一种非常被动的状态。
3．3总体设计
在完成项目需求规格说明书后，就进入项目总体设计的阶段。
在总体设计阶段需要完成的文档有：
1． 《项目总体设计---概要设计说明书》、
2． 《数据库设计报告》
3． 《项目总体开发时间表》
在此阶段应该建立项目的正式开发环境、项目测试环境、建立项目基本开发框架且导入项目管理配置工具中（例如：CVS、VSS等）等
在项目的以上阶段完成后，建议进行项目总体设计和总体开发准备情况的评审工作。在公司、集团专家组评审通过后本阶段结束，这算做项目的第二个里程碑。
在进行下一阶段前，目前项目组可以对SCCB（软件变更控制委员会）提交的资料有：
1：《需求规格说明书》
2：《项目总体设计概要说明书》
3：《项目界面设计说明书》（及界面DEMO）
4：《项目数据库设计说明书》等
5：《项目总体开发时间表》
3．4详细设计
在项目完成总体设计和搭建完毕开发环境后，就可以进行项目的详细设计。
在项目中建议详细设计由项目编写“后台”程序的资深人员编写。主要完成每个负责的业务模块从界面到业务实现到数据库连接操作的主要步骤和数据库的实现SQL。最好在条件允许的情况下编写模块单元测试程序，在整个模块编码阶段完成后进行程序单元测试工作。（“测试驱动”的开发理念）
详细设计目的是在不编写代码和少量代码的情况下，完成项目模块的模拟编程实现。
在详细设计阶段可以对项目某模块做准确的工作量统计，依此为依据整个项目比较准确的工作量就可以被统计出来。
3．5编码实现
（略）
3．6测试、试运行、上线
1 概述
目的与概述
本文档为XX公司的开发规范文档，给开发团队提供开发标准和规范。
整体说明
在开发规范中包含了两个部分，第一部分是项目开发流程规范，主要阐述在项目开发过程中的各个阶段的规范。第二部分为Coding开发规范，Coding开发规范阐述了在一个框架中的各个层的开发规范
（注：在第一版中不包含对工作流开发的规范制定）
覆盖范围
阅读对象
1. 项目管理人员
2. 系统设计人员
3. 系统开发人员
参考资料
略
2 项目开发流程规范
2.1 业务需求调研阶段
l 调研的目标
系统层面： 客户的系统运行环境
业务层面：了解客户需要什么样的系统，具体了解业务目的，业务逻辑，业务数据，客户的操作习惯，页面风格习惯等。
l 调研的准备工作：
行业知识的准备：
了解客户的行业背景，行业领域的业务术语，含义。结合客户行业背景，了解客户的业务知识。
业务专家需求：
在行业领域的复杂度不高的情况下，业务分析人员直接收集并学习行业知识就可以了，但行业知识的准备工作还是要做的
在行业领域业务复杂度高的情况下，需要业务专家对客户的业务的进行整理。
l 调研的流程：
第一步 ，项目启动阶段 了解客户的IT环境。
第二步， 讨论并具体确定客户系统的范围，并获得客户业务功能点的原始的单据。在这个过程中准备一个本和一只笔记录讨论的业务信息
第三步， 整理业务信息，和原始表单，抽取出有效业务信息，并对于不明确的业务信息进行整理和归类，并制作成问卷形式进一步调研。
第四步， 发放调研问卷，再次进行业务调研（直接转到三）
第五步，卷写调研问卷，并内部评审
第六步，调研问卷客户评审并确认。
l 调研阶段的交付项（可配置项）
软件需求说明书
软件需求说明书的目录：
1 客户行业背景
2 客户系统的意义
3 客户系统运行的环境
4 业务功能点描述（业务目的，业务逻辑，业务数据，优先级别，使用频率等）
5 客户的操作习惯，页面风格习惯。
2.2 概要设计阶段
概要设计阶段主要分两个步骤： 1 框架设计 2 业务模块概要设计 ,下面分别对两个步骤进行描述：
2.2.1框架设计 （注：这边的框架设计是按照传统的开发方式进行阐述，基于平台的开发方式待补）
l 框架设计的目标：
根据客户需求，设计系统的后台架构，前台界面框架，数据模型。在设计之前要考虑客户的业务特点，性能要求，已有的IT环境，同时还要考虑将来业务的增长，保证系统一定得可扩展性。
l 框架设计包含的内容：
后台框架： 各层的职能划分，技术实现的方式，层之间的交互规则，异常处理规则，目录定义规则
界面框架：操作主界面定义
页面整体风格的定义，页面流转关系等
数据模型： 系统基础数据（组织人员结构，权限设置，字典参数设置） 业务数据
l 框架设计阶段交付项：
文档 ：系统架构
界面框架
数据模型
注：三份文档可以融合在一份文档之中。
2.2.2业务模块概要设计
系统设计人员根据业务分析人员的业务需求文档，进行概要设计。在概要设计过程中主要关注三个关键点
1） 业务模块的页面显示内容：信息显示的内容，显示的方式；交互接口的定义，等
举例：查询人员信息模块
操作说明，查询条件，显示字段，排序和显示方式。
2）业务逻辑描述
对业务逻辑进行详细的描述。
3）业务数据项
业务模块涉及到数据的描述。
具体的描述包含
数据项名称 ，显示方式，是否必填，输入方式，相关逻辑
l 概要设计阶段的交付项
概要设计文档
2.3 业务需求理解阶段
1
2
2.1
2.3.1系统设计人员理解需求
在系统设计人员理解需求之前，业务分析人员必须提供相关模块的客户需求文档。 系统设计人员阅读并理解客户需求文档。
l 理解需求文档的交付结果（可配置项）
业务需求对于客户来讲，目的是什么，解决什么问题，有什么意义？
具体业务的执行逻辑是什么？
在业务流转过程中的业务数据有哪些？
l 需求理解时间要求：
简单的需求，理解时间为2-3 小时
复杂需求：理解需求时间4-8小时
l 复杂的业务需求需要需求分析人员确认。
复杂的业务需求按照涉及到的业务的复杂度来决定的。
2.4 详细设计阶段
详细设计阶段分两个步骤
l 第一步骤，系统设计人员根据业务需求的理解,详细设计业务模块，并出详细设计文档
l 第二步骤，核心设计人员对系统设计人员的详细设计文档进行技术评审。
2.2
2.4.1系统设计人员详细设计阶段
系统设计人员根据业务需求，详细设计模块。
l 详细设计阶段的交付结果（可配置项）
详细设计文档：
业务接口定义
数据库的数据项定义
Web页面和Js接口定义等
注：对于复杂的模块可以在详细设计文档中可以包含了UML类图，和时序图 ，从而进一步描述设计的内容
l 详细设计时间要求：
简单的业务需求：2-4小时
复杂的业务需求4-12小时
l 详细设计文档的书写原则：
系统设计人员在文档中能描述清楚业务模块的详细设计，不拘泥于格式。
2.4.2 技术评审阶段
l 技术评审流程：
1）系统设计人员在技术评审之前，将自己的详细设计文档分发给技术评审的与会人员。
2）在技术评审过程中，系统设计人员首先讲述详细设计文档
3）评审人员对详细设计中各个环节进行询问和确认，提出修改方案。
4）最后项目技术负责人确认调整后的设计方案。
l 技术阶段的交付结果（可配置项）
业务确定的详细设计文档。
注：此文档是交付确认的标准之一。
2.5 Coding阶段
系统开发人员根据业务的项目详细设计文档，进行实际Coding过程。
在Coding过程中的注意事项
1） 在Coding过程中严格按照Coding开发规范来执行。
2）在Coding过程中，发现详细设计文档中的严重缺陷，则需要和项目设计人员确认，如非常复杂，则需重新技术评审。
3）在详细设计发生改变时，需要及时更新详细设计文档。
2.6 业务模块确认交付阶段
项目技术负责人和业务分析人员共同对业务模块进行验收。
验收步骤：
1）业务分析人员确认功能模块实现功能和客户需求一致
2）技术负责人对功能模块进行技术上的确认。
3）测试人员的测试报告
注：第三步主要看公司的具体的情况和业务复杂度，
第三步完成流程如下：
1）准备测试阶段 测试人员根据业务需求，设定一个业务环境，写成测试脚本，
2）测试阶段 根据测试环境和业务需求 进行测试
3）根据测试的结果，出测试报告。
2.7 系统集成测试
根据客户业务需求，测试人员设定一个测试环境，编写测试脚本，在测试服务器上部署好系统。按照测试用例进行业务功能上测试。
测试人员准备工作清单：
测试用例
测试脚本
当前实现模块
硬件设备：
等同条件的客户运行环境
系统集成测试阶段交付项（可配置项）：
系统集成测试报告
系统集成测试报告格式
功能点 测试人 测试脚本 测试结果 异常原因
2.8 系统打包部署
客服安装人员将系统打包成一个安装文件，供在客户的系统环境中部署系统
系统集成测试阶段交付项（可配置项）：
系统安装文件