CSI01软件设计和编码过程.docx

CSI01软件设计和编码过程.docx

《CSI01软件设计和编码过程.docx》由会员分享，可在线阅读，更多相关《CSI01软件设计和编码过程.docx（19页珍藏版）》请在冰豆网上搜索。

CSI01软件设计和编码过程

项目管理体系文件

软件设计和编码过程

编撰人：

TMO

审核人：

批准人：

批准日期：

2010-9-1

保密级别：

机密

文档版本：

0.0.1

北京中软国际信息技术有限公司

版本历史

日期

版本

说明

作者

目录

1.引言3

1.1.目的3

1.2.适用范围3

1.3.术语和缩略语3

1.4.相关文件3

2.角色和职责4

3.入口准则4

4.输入4

5.流程图5

6.主要活动5

6.1.软件设计6

6.1.1.概要设计6

6.1.2.详细设计13

6.1.3.设计变更15

6.2.编码实现16

6.2.1.开发集成环境准备16

6.2.2.代码编写16

6.2.3.单元测试17

6.2.4.代码评审17

6.2.5.编码变更18

6.3.构件集成18

7.出口准则19

8.输出19

9.引用过程20

1.引言

1.1.目的

软件设计和编码的目的在于设计和实现关于需求的解决方案。

保证《需求规格说明书》中的各项要求在设计时都能够得到满足；对项目的编码实现进行质量控制，保证编码实现活动按计划顺利完成并与设计相一致。

1.2.适用范围

适用于公司合同开发类软件项目、产品研发类项目的系统设计和编码过程。

1.3.术语和缩略语

表1术语和缩略语

术语、缩略语

解释

PD

项目总监

TD

技术总监

PM

项目经理

构件

构件是相对完整业务功能的应用，具有可复用性，一个构件有明确的物理边界，例如：

在基于ResourceOne的架构中，一个构件具体包装为一个受管理的WAR包。

模块

是独立的功能部分，实现一个相对独立的软件功能，是构成软件系统结构的基本元素。

体系结构

体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理。

即软件体系结构=（构件，连接件，环境，原理）。

1.4.相关文件

无

2.角色和职责

表2角色和职责

角色

职责

PM

1）组织和参与设计评审，批准设计结果；

2）协调项目组内各角色之间的协同合作关系。

责任设计师

1）进行系统整体架构的分析和设计；

2）编写《概要设计说明书》；

3）参与详细设计的评审。

工程师（高、中级）

1）进行详细设计，编写《详细设计说明书》；

高级工程师

1）组织并执行代码走查。

工程师

1）编写代码并进行单元测试。

开发技术专家

1）配合高级工程师组织和监督执行代码走查。

PD

1）参加概要设计评审。

TD

1）指导并监督设计工作；

2）评审并核准概要设计。

3.入口准则

1）《需求规格说明书》已通过评审

4.输入

1）《项目计划》

2）《需求规格说明书》

3）《用户需求调研报告》

5.流程图

图1软件设计和编码过程流程图

6.主要活动

系统设计和编码过程主要包括概要设计、详细设计和编码实现。

TD应进行设计的监督工作，总体把控项目的设计，并指导PM和设计师完成设计及修正设计过程的问题。

6.1.软件设计

6.1.1.概要设计

主要由责任设计师负责，其主要依据是《需求规格说明书》。

TD应对概要设计进行监督。

概要设计主要包括体系结构设计、构件设计、接口设计和数据结构设计。

6.1.1.1.解决方案选择

系统设计时可能会涉及到多种解决方案的选择，如：

1）系统架构；

2）系统技术路线；

3）软件架构与设计模式；

4）采用的工具；

5）构件的开发或复用等。

在进行解决方案选择时，应尽可能选择复用公司已有解决方案。

基于J2EE架构的应用系统应选择基于公司ResourceOne平台进行设计开发。

当出现多种候选方案，难以通过简单的方法判断出方案的优劣时，应按照《决策分析和决定过程》进行决策，并形成《决策分析报告》。

6.1.1.2.确定设计约束

在开始设计之前，PM、设计师应确定影响系统设计的约束因素：

1）需求约束。

设计师应从需求文档《需求规格说明书》中提取需求约束，例如：

（1）本系统应当遵循的标准或规范；

（2）软件、硬件环境（包括运行环境和开发环境）的约束；

（3）接口/协议的约束；

（4）用户界面的约束；

（5）软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。

2）隐含约束。

有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能的在此处说明。

例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。

6.1.1.3.确定系统设计策略

PM、设计师根据软件的需求和公司相关要求，确定设计策略。

如：

1）扩展策略：

说明为了方便本系统在将来扩展功能，现在采取什么措施；

2）复用策略：

说明本系统在当前及将来的复用策略，应尽量考虑构件化的要求，优先考虑应用已有的软件构件；

3）折中策略：

说明当两个目标难以同时优化时如何折中。

6.1.1.4.体系结构设计

设计师负责进行体系结构设计，其步骤如下：

1）设计与目标系统交互的外部实体（其他系统、设备和人）和交互的特性，及目标系统运行的环境。

通常用体系结构环境图对软件与外部实体交互的方式进行建模。

与目标系统交互的系统可以表示为：

上级系统、下级系统、同级系统和参与者；

2）设计目标系统内部的结构模型；

3）把1）、2）中的内容精化成构件。

构件分业务构件和基础设施构件，业务构件来源于业务领域，基础设施构件与业务领域没有业务联系，是为业务构件提供运行支持的。

设计师在对构件进行划分时应依据以下原则：

●功能相对独立原则；

●低耦合、高内聚原则；

●可独立交付原则；

●构件之间无缝组装、复用原则。

体系结构设计的主要输出为软件体系结构图，图中包括数据架构和程序结构。

设计师应对软件体系结构图中的各部分进行详细说明。

6.1.1.5.构件设计

构件设计需要对体系结构中的构件进行细化。

6.1.1.5.1.模块切分

设计师根据构件所包含的业务需求，进行模块切分，形成模块列表并确定模块与需求的对应关系。

1）模块的切分应考虑如下基本原则

●模块进行切分时要大小适中，具有清晰的模块结构。

一般情况下要求切分的模块功能相对独立和完整。

●明确模块间合理的依赖关系。

在设计阶段明确合理的模块依赖关系，有利于项目计划更合理的安排。

●尽可能消除重复的工作，建立公用模块，以减少冗余。

2）模块切分成果

模块列表：

模块列表

构件

名称

模块

编号

模块

名称

对应需求

功能编号

所对应

需求功能

实现

优先级

6.1.1.5.2.构件接口设计

构件是相对独立的，构件间的交互是通过接口完成。

设计师需要明确构件间的依赖关系、构件与外部系统（第三方的系统）的依赖关系，形成构件接口说明。

构件接口列表

构件名称

接口编号

接口名称

接口类型

说明

构件1

内部

外部

…

具体接口设计，应完成如下工作：

1）接口属性设计

接口编号

接口名称

接口说明

数据来源

调用者

输入

输出

处理流程

2）处理流程图

3）类设计，可使用多表

类名称

分类

描述

使用到的其他类

属性及方法描述

使用/交互

其他

6.1.1.5.3.构件复用评估

设计师应组织对构件进行复用评估：

1）确定是复用已有构件，还是需要自主开发或购买；

2）对自主开发的构件判断是否适合公司内复用。

评估时需要考虑的事项包括：

业务方面：

可行性、产品成本、经验、投资回报、成熟度及其他因素；

技术方面：

安全、交互标准、数据访问、数据存储、系统服务、开发工具、操作系统等。

6.1.1.6.模块设计

模块设计通常需要反复迭代，对于每个模块需要详细描述如下内容：

1）模块功能

定义模块的主要功能；

2）处理流程

用图表（例如流程图等）辅以必要的说明来表示本模块的逻辑流程，并对流程图进行描述；

3）输入

给出对每一个输入参数的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。

4）输出

给出对每一个输出参数的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式，输出介质、对输出图形及符号的说明、；

5）主要算法

包括计算公式与说明、某些设定的或必然的逻辑关系。

对于函数，要着重说明。

6）数据结构

依据6.1.2.8章节，建立数据表结构、索引等，并进行优化设计，形成数据库设计说明书；

7）类设计

面向对象软件开发中，模块一般与包对应的，模块设计的工作是对模块中类的关联关系及类主要方法的设计，要求建立类图、及类关系图；

8）模块的界面设计，详见6.1.2.6章节。

6.1.1.7.界面总体设计

通过界面原型设计，可以更有效的表达用户需求，减少工程师开发工作中对需求的错误理解，提供开发的效率。

6.1.1.7.1.定义界面原型规则

1）界面设计人员与用户交流，了解用户的工作习惯和他们对界面的看法。

2）收集或创作基本的界面资源如：

图像、图标以及通用的组件。

3）设计师结合公司对设计的相关要求，确定用户界面设计规则：

（1）优秀界面的特征或通用的设计原则；

（2）软件主界面、子界面（主窗口、主页面）的设计规则；

（3）标准控件的使用规则；

（4）美学设计规则。

6.1.1.7.2.界面设计

用户界面设计一般要经历“原型创作—>原型评估－>细化”等步骤，通常迭代进行。

1）原型创作

设计人员先徒手画出界面原型，或者用Visio等工具绘制界面的视图；

再用软件开发工具实现可以运行的原型。

2）原型评估

设计人员邀请用户和同行们评估界面的原型，汇集意见，及时改进。

3）细化

设计人员细化界面原型，例如美工处理，添加细节等。

工程师在本阶段不必关心界面原型的代码质量，因为界面原型可能不断地被修改甚至被抛弃。

6.1.1.8.编写概要设计说明书

设计师组织编写《概要设计说明书》（模板详见：

“04.设计和开发\CSI_05_概要设计说明书.doc”），主要内容应包括：

1）软件系统概述；

2）系统体系结构；

3）系统运行的软硬件环境；

4）构件设计，包括功能模块划分、构件接口设计等；

5）模块设计，模块功能说明、角色和权限、处理流程、操作界面等；

6）接口设计，包括软件的外部接口等；

7）部署设计；

8）系统出错处理。

6.1.1.9.数据库设计

6.1.1.9.1.定义数据库设计规则

设计师依据软件需求、设计规则及系统概要设计，确定软件的数据库设计规则，主要包括：

1）数据库命名规则；

2）数据库库表结构设计规则；

3）优化规则。

6.1.1.9.2.数据库设计

1）数据库设计准备

设计师应准备数据库设计相关的设计工具和资料。

2）数据库设计

设计师进行表结构设计，建立数据库实体关系模型。

一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。

3）数据库优化

分析并优化数据库的效率，尽可能地“提高处理速度”并且“降低数据库占用的空间”。

分析效率的瓶颈，找出优化对象（目标），并确定优先级。

当优化对象（目标）之间存在对抗时，给出折衷方案。

给出优化的具体措施，例如优化数据库环境参数，对表格进行反规范化处理等。

6.1.1.9.3.编写数据库设计说明书

设计师组织编写《数据库设计说明书》（模板详见：

“04.设计和开发\CSI_06_数据库设计说明书.doc”），主要内容应包括：

1）数据库设计约定；

2）数据库模型图；

3）表；

4）视图；

5）存储过程；

6）触发器。

6.1.1.10.概要设计评审

概要设计评审的输入包括概要设计说明书和数据库设计说明书。

概要设计的评审，执行《评审过程》，根据《评审检查单》模板形成《概要设计说明书评审检查单》及《数据库设计说明书评审检查单》。

概要设计主要评审要素包括：

1）适当性：

考察该体系结构是否适合于软件需求，是否可在预定计划内实现。

2）系统的综合能力：

例如可扩展性，可维护性，可复用性，安全性等。

3）正确性、完整性、一致性。

6.1.2.详细设计

详细设计可以和概要设计并行进行，但应考虑并行设计不应因概要设计的修改而导致较大的详细设计返工。

详细设计主要有高、中级工程师完成，PM、设计师须参与评审。

TD应监督详细设计的评审。

详细设计主要是完成具体模块的细化工作，要在逻辑上正确地实现每个模块的功能。

6.1.2.1.模块细化设计

6.1.2.1.1.类设计

根据概要设计确定的类及类的主要方法，建立类实体。

类的实现应依据相关编码规范的要求，应注意以下要点：

1）将数据设计为私有。

不要破坏封装性。

数据的表示形式很可能会改变，但他们的使用方式却不会经常发生变化。

当数据保持私有时，他们的表示形式的变化不会对类的使用者产生影响，即使出现bug也易于检测。

2）要对数据初始化。

最好不要依赖于系统的默认值，而是应该显式地初始化所有的数据，具体的初始化方式可以是提供默认值，也可以是在所有构造器中设置默认值。

3）不要在类中使用过多的基本数据类型。

就是说，用其他的类代替多个相关的基本数据类型的使用。

这样会使类更加易于理解且易于修改。

4）使用标准格式进行类的定义。

采用下面的顺序书写类的内容：

公有访问特性部分；

私有访问特性部分；

在每一部分中，应该按照下列顺序列出：

实例方法；

静态方法；

实例域；

静态域。

5）将职责过多的类进行分解。

6）类名和方法名要能够体现其的职责。

6.1.2.2.编写详细设计说明书

《详细设计说明书》（模板详见：

“04.设计和开发\CSI_07_详细设计说明书.doc”）的编写，主要以模块设计为主：

1）模块功能；

2）处理流程；

3）输入；

4）输出；

5）主要算法；

6）类实现；

7）界面设计。

6.1.2.3.详细设计说明书评审

详细设计根据设计需要确定是否进行评审。

详细设计进行评审，执行《评审过程》，评审过程中应根据《评审检查单》模板形成《详细设计说明书评审检查单》。

新业务的设计、涉及3个及以上业务流程的设计、复杂算法和数据结构的设计、见习设计师设计的结果必须进行评审。

详细设计主要评审要素包括：

1）与概要设计的一致性；

2）正确性、完整性；

3）处理流程及界面设计的合理性。

6.1.3.设计变更

设计的变更应严格遵照《变更管理规程》执行。

一般以下情况会引起设计变更：

1）需求发生变化；

2）实现过程中发现设计的缺陷。

6.2.编码实现

6.2.1.开发集成环境准备

代码开发前项目经理指定人员对开发、集成环境进行规范并完成环境搭建。

开发、集成环境搭建应考虑的内容有：

1）配置管理库；

2）开发服务器环境（应用服务器、数据库服务器、网络等）；

3）客户端、开发工具及版本；

4）编码涉及的复用构件及版本；

5）代码目录结构；

6）编码规范等。

开发、集成环境使用要求：

1）项目组开发工具应统一；基于R1的应使用R1开发平台;

2）开发的代码及相关资料应及时与配置管理库进行同步；

3）构件的集成须在集成环境中进行。

6.2.2.代码编写

工程师根据《概要设计说明书》、《数据库设计说明书》、《详细设计说明书》、《代码编写规范》进行编码实现。

代码编写应考虑以下两个方面：

编程方法：

常见方法有结构化编程、面向对象编程、重用已有代码等。

此外代码编写根据所使用的开发语言不同，应该遵循相应的编码规范。

编程实现顺序：

在编程过程中应根据《项目进度计划》确定的各功能单元的编程顺序来进行编码，已确保各功能持续集成。

代码实现的主要过程：

1）工程师应首先复核详细设计说明，保证影响编码的问题得到识别和解决；

2）工程师根据项目进度计划、设计文档的要求，使用规定的开发工具和环境，按照相关编码规范的要求编写代码，并通过对软件单元的调试、修改，使之符合软件设计文档的要求；

3）建议工程师在开始编码时应每日写开发日志；

4）代码编写、修改过程中，工程师要进行每日同步和每日提交；

5）接口的实现。

6.2.3.单元测试

单元测试目的是为保证编写的每个代码单元片段功能实现满足设计要求，提高提交的代码质量，主要由工程师完成。

单元测试主要过程：

1）工程师编写关键业务模块的测试代码，并执行进行测试；

2）PM可以组织工程师之间互相进行交换测试；

3）测试中如发现问题应及时通知该代码编写者进行修改；

4）高级工程师应在代码走查过程中对单元测试的代码及执行结果进行审查，并依据需求验证编码质量。

单元测试需要关注以下几个方面：

1）源代码编译：

测试代码是否通过编译。

2）SQL脚本：

测试数据库脚本、存储过程运行是否正常。

3）模块接口：

对被测模块，信息是否能正确地流入和流出。

4）局部数据结构：

在模块的工作过程中，其内部的数据能否保持其完整性。

5）覆盖条件到模块的运行是否满足设计的逻辑要求。

6）出错处理—检查模块的错误处理是否有效。

7）建议引用测试工具自动执行单元测试。

6.2.4.代码评审

1）高级工程师根据项目计划，组织代码评审；

2）代码评审前应确定《代码评审检查单》，以确定走查依据和原则；

3）评审过程中发现问题应记录到《项目问题跟踪表》，并及时通知代码编写人员修改；

4）高级工程师须对《项目问题跟踪表》中的问题进行跟踪，直至问题解决。

除根据PM制定的项目计划进行代码评审外，高级工程师也可以根据项目的需要，灵活组织代码评审，评审的方式也可以根据需要变动，一般如下情况应考虑展开评审：

（1）新员工编写的代码；

（2）关键业务或系统核心代码；

（3）问题较多的代码；

（4）新增模块的代码等。

5）基于ResourceOne的项目应在ResourceOneStudio中进行代码走查。

6.2.5.编码变更

编码阶段基线建立以后，编码的变更应严格遵照《变更管理规程》执行。

一般以下情况会引起代码变更：

1）设计发生变化；

2）测试基线建立后发现的缺陷。

6.3.构件集成

构件集成是一个持续集成的过程，参与集成人员主要包括：

责任设计师、工程师、项目CM人员。

1）PM负责构件集成策划，责任设计师组织构件集成；

2）工程师与项目CM负责搭建集成环境，项目开发环境可以是集成环境；

3）责任设计师检查集成就绪

对要提交进行集成的构件，须满足集成就绪的准则后，方可进行集成。

对于不同构件，集成就绪准则可能不同。

一般，应考虑以下方面：

●构件功能开发完成，并通过了单元测试和代码检查；

●对构件接口的进行测试，并通过。

具体准则，可以在《集成就绪检查单》（模板详见：

“04.设计和开发\CSI_08_集成就绪检查单.doc”）中定义，并由工程师应进行验证，责任设计师应对其进行确认。

4）实施集成

根据设计中确定的构件依赖关系，确定集成顺序；

确定集成方式，如：

自底向上、自顶到下、由内向外、由外向内；

工程师负责构件集成的联调工作，并及时处理集成过程中发现的问题；

系统内部构件集成后，根据需要在进行外围的第三方构件、客户环境构件的集成。

5）集成验证

集成完毕后，需进行集成验证工作，须满足集成结束的准则后，方确认集成完成。

一般需关注：

●集成环境的相关情况；

●各构建间接口的调用是否正常工作，是否达到预期业务效果。

集成验证工作结束后，项目CM应根据配置管理的要求进行配置管理。

7.出口准则

1）设计文档评审通过

2）代码通过单元测试和代码评审

8.输出

1）《决策分析报告》

2）《概要设计说明书》

3）《概要设计说明书评审检查单》

4）《数据库设计说明书》

5）《数据库设计说明书评审检查单》

6）《概要设计评审报告》

7）《详细设计说明书》

8）《详细设计说明书评审检查单》

9）《详细设计评审报告》

10）《代码评审检查单》

11）源代码

12）部署包

9.引用过程

1）《决策分析和决定过程》（详见：

“16.决策分析\CSI_01_决策分析与解决过程.doc”）

2）《评审过程》（详见：

“13.评审\CSI_01_评审过程.doc”）

3）《变更管理规程》（详见：

“11.配置管理\CSI_03_变更管理规程.doc”）