ZENQ项目实训指导手册

ZENQ项目实训指导手册目录1 概述 (3)2 开发过程管理 (3)2.1 概述 (3)2.2 软件开发基本流程 (4)2.2.1 立项阶段 (4)2.2.2 需求分析 (7)2.2.3 概要设计 (8)2.2.4 开发阶段 (9)2.2.5 测试阶段 (10)2.2.6 发布阶段 (11)2.3 迭代开发 (12)3 配置管理 (13)3.1 概述 (13)3.2 版本控制工具 (13)3.3 项目目录结构 (14)1概述本手册的目的是为了明确在实训项目开发时每个环节的步骤，需要完成的工作，以及需要完成文档的模板等提出规范。

没有规矩不成方圆，标准是企业走向成功的利器，在项目的开发过程中，必须按照本指南的要求，开展项目。

在开发过程管理章节中，向读者介绍了从立项阶段、需求分析、概要设计、开发阶段、测试阶段到发布阶段软件开发的基本流程。

这些规范是对现有企业开发方法精炼的积累和总结，也是学员在培训过程中所需要遵循的规范。

在配置管理章节中，介绍企业中实际使用的项目版本控制工具的使用，以及配置管理的方法。

并通过项目目录结构来展示将进入产品基线库的项目成果，从而引导学员整个项目交付时需要有那些成果及其应该以怎样的方式进行归档。

最后给出项目的开发模版，以指导学员以规范的方式编写文档，并通过模版引导学员对模版中需要填充的内容进行思考，从而引导学员进行项目开发、设计、编码和测试工作。

2开发过程管理2.1 概述业界有非常的开发方法，来保证开发进度，开发的质量。

比如RUP、CMM-I、MSF、XP开发等。

各种开发过程都有它的优势和特点，并适合在各种规模和类型不同的企业中进行使用。

但目前流行的开发过程都有一个特点，就是迭代开发，这是由软件项目的特点决定的。

在现实项目中，往往很难一次性得到项目的需求，项目需求获取的渐进性，使项目设计、开发也需要随后跟进，整个项目采用迭代开发模式可以有效节约开发成本。

在项目开发中，将任务分解为多个阶段，每个阶段能完成可以运行的版本，是我们项目中采用的方式。

实训中简化这个过程，一般以一周为单位作为一个基本时间。

每周能推出一个可以运行的版本。

这样能够及时纠正项目中的问题，指导学员在正确的模式下迭代开发完成项目。

2.2 软件开发基本流程开发过程按照一下过程进行迭代开发。

每个阶段需要编写相关的文档、完成指定的任务。

由于需求在需求分析阶段很难一次性将需求调研清楚，这是由业务需求本身具有其不确定造成的。

但项目却不能在需求完全确定后再考虑分析和设计，这样在时间与人力的分配上造成了浪费。

在项目中所采用的通用的方式是，首先选取核心的业务进行分析，先固定下来进行分析设计，能有效确保核心业务的完善。

而后，需求调研人员对后续需求进行补充，这时候分析设计人员能够同步与需求分析人员进行工作，大大提高了工作效率。

所以迭代开发是并发完成项目所必需的软件开发模式。

2.2.1 立项阶段在立项阶段，完成团队的组建。

为项目成员分配任务，根据项目目标、时间规划项目进度。

在此阶段，需要建立团队的工作区，建立源代码管理环境。

在此时要分配项目中的角色，明确每个人的职责。

至少需要以下角色：在实际项目中不同的人员可以兼任不同的角色，但是有些情况是不能兼任的。

一般来说，软件工程师不能兼任测试工程师。

在实训过程中，由于人员限制，软件工程师也担任测试工程的角色。

在这种情况下，软件工程师负责测试的模块不能使自己编写的模块。

立项阶段需要完成的工作任务：1、角色定义任务描述：根据参与项目的人员特长，为小组成员定义角色，确定项目经理、测试经理等；参与人员：全体成员参与；验收标准：完成配置管理计划文档，并经过全体成员认可；2、建立工作环境任务描述：创建源代码管理服务器，根据源代码管理要求建立相关目录；为项目成员分配登录帐号，并测试源代码服务器。

每个成员测试自己的帐号，工作环境是否正常使用。

建立过程可以参考第三章《配置管理》。

参与人员：本任务负责人为配置管理员，所有团队成员参与。

验收标准：完成配置管理计划文档，并经过全体成员确认。

3、项目进度计划任务描述：根据项目难易程度、项目时间要求，估算项目进度。

并为项目成员进行工作安排。

项目计划可以根据情况，进行一定的变更。

参与人员：项目经理负责完成，与项目成员确认工作安排。

验收标准：使用Project 完成项目进度计划，并将文档签入服务器。

4、任务跟踪表任务描述：通过完成项目计划，确定每个人的任务。

根据模板建立任务跟踪表，通过此表格跟踪每个人的任务完成情况。

任务跟踪表可以根据项目计划的编号，对任务进行终止、暂停等。

参与人员：项目经理负责完成。

验收标准：根据项目跟踪模板建立项目跟踪记录表，并将文档签入服务器。

2.2.2 需求分析任务描述：需求分析是开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应的形式功能规约（需求规格说明）的过程。

需求分析虽处于软件开发过程的初期阶段,但它对于整个软件开发过程以及软件产品质量是至关重要的。

需求分析的基本任务1.问题识别(1) 功能需求：明确所开发的软件必须具备什么样的功能。

(2) 性能需求：明确待开发的软件的技术性能指标。

(3) 环境需求：明确软件运行时所需要的软、硬件的要求。

(4) 用户界面需求：明确人机交互方式、输入输出数据格式。

2. 分析与综合，导出软件的逻辑模型分析人员对获取的需求，进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。

用图文结合的形式，建立起新系统的逻辑模型。

3. 编写文档一般可以采用UML 对需求分析进行建模。

可以根据需求分析，适当调整项目计划。

参与人员：需求分析工程师；验收标准：完成需求分析说明书，并签入服务器；2.2.3 概要设计在软件需求分析阶段，已经搞清楚了软件“做什么”的问题，并把这些需求通过规格说明书描述了出来，这也是目标系统的逻辑模型。

进入了设计阶段，要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，即着手实现软件的需求，并将设计的结果反映在“设计规格说明书”文档中，所以软件设计是一个把软件需求转换为软件表示的过程，最初这种表示只是描述了软件的总的体系结构，称为软件概要设计。

概要设计要明确系统的模块划分，软件系统的架构，数据库设计等。

概要设计的基本任务：1、概要设计任务描述：概要设计明确系统采用的技术手段、开发语言，模块划分。

参与人员：项目经理、软件工程师。

验收标准：完成概要设计说明书。

2、界面设计任务描述：良好的人机界面是一个软件成功的重要因素之一。

在软件设计之初就应当考虑到界面设计。

界面设计应当考虑色彩搭配、易用性。

参与人员：软件工程师。

验收标准：包括在概要设计说明书中，或则编写单独的界面设计说明书。

3、数据库设计任务描述：如果系统需要使用数据库存储数据，需要进行数据库设计。

数据库设计一般使用专门的数据库设计软件，推荐使用 Sybase PowerDesign 。

完成数据库设计以后，编写数据库设计说明书。

参与人员：软件工程师。

验收标准：在概要设计说明书中编写数据库设计章节，或者单独编写数据库设计说明书。

2.2.4 开发阶段开发阶段的主要任务是根据设计，对系统进行构建。

开发阶段的基本任务：1、代码编写任务描述：根据设计文档，进行单元编码。

编码可能包括两个方面：编程语言代码、数据库存储过程代码。

参与人员：软件工程师。

验收标准：单元编码。

2、单元测试任务描述：根据详细设计，编写单元测试代码。

编写单元测试的目的是为了快速对模块的正确性进行验证。

一般使用 JUnit、NUnit等工具进行单元测试。

参与人员：软件工程师。

验收标准：完成单元测试代码。

2.2.5 测试阶段软件测试是程序的一种执行过程，目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。

它是软件生命周期中一项非常重要且非常复杂的工作，对软件可靠性保证具有极其重要的意义。

在目前形式化方法和程序正确性证明技术还无望成为实用性方法的情况下，软件测试在将来相当一段时间内仍然是软件可靠性保证的有效方法。

软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成软件开发项目。

测试阶段的工作可以在开发阶段同步进行。

测试阶段的主要任务：1、编写测试用例任务描述：根据需求分析、系统设计，由针对性的设计测试系统数据、操作流程，用于验证系统。

参与人员：测试经理。

验收标准：完成测试说明书、数据库测试数据。

2、测试跟踪记录任务描述：根据测试用例、单元测试，将出现错误的结果记录在测试跟踪表。

并跟踪错误的解决情况。

参与人员：测试工程师。

验收标准：建立测试跟踪记录文件。

2.2.6 发布阶段当程序通过各项测试，已经没有明显影响程序执行、功能性错误时进行。

测试阶段的主要任务:1、编写安装程序任务描述：为应用程序编写安装程序，方便用户使用。

注意安装测试也需要经过测试。

参与人员：测试经理。

验收标准：安装测试。

2、帮助任务描述：根据应用程序类型制作系统帮助文件。

如果是 WEB 应用程序应包含在程序中。

参与人员：测试工程师。

验收标准：完成帮助文档。

2.3 迭代开发项目中的每个阶段可以进一步分解为迭代。

一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。

传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期。

这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。

一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。

这叫做一个迭代生命周期。

在工作流中的每一次顺序的通过称为一次迭代。

软件生命周期是迭代的连续，通过它，软件是增量的开发。

一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。

因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。

其本身就像一个小型的瀑布项目。

与传统的瀑布模型相比较，迭代过程具有以下优点：1、降低了在一个增量上的开支风险。

如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。

2、降低了产品无法按照既定进度进入市场的风险。

通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。

3、加快了整个开发工作的进度。

因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

4、由于用户的需求并不能在一开始就做出完全的界定，它们通常是在后续阶段中不断细化`的。