ZENQ项目实训指导手册.docx

ZENQ项目实训指导手册.docx

《ZENQ项目实训指导手册.docx》由会员分享，可在线阅读，更多相关《ZENQ项目实训指导手册.docx（14页珍藏版）》请在冰点文库上搜索。

ZENQ项目实训指导手册

ZENQ项目实训

指

导

手

册

版本

V1.1

最后修订时间

2008-11-29

目录

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人

测试经理

编写项目的单元测试代码、设计测试用例、安装程序制作、安装说明书

1人

需求分析师

对业务逻辑建模，明确项目需求

软件工程师

按需求进行模块设计、单元编码、模块测试

测试工程师

按照测试用例编写好的软件进行功能测试，记录测试的BUG

配置管理员

负责整个项目的文档版本管理、代码备份，为组员分配源代码管理帐号。

1人

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

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

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

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

立项阶段需要完成的工作任务：

1、角色定义

任务描述：

根据参与项目的人员特长，为小组成员定义角色，确定项目经理、测试经理等；

参与人员：

全体成员参与；

验收标准：

完成配置管理计划文档，并经过全体成员认可；

2、建立工作环境

任务描述：

创建源代码管理服务器，根据源代码管理要求建立相关目录；为项目成员分配登录帐号，并测试源代码服务器。

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

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

参与人员：

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

验收标准：

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

3、项目进度计划

任务描述：

根据项目难易程度、项目时间要求，估算项目进度。

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

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

参与人员：

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

验收标准：

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

4、任务跟踪表

任务描述：

通过完成项目计划，确定每个人的任务。

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

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

参与人员：

项目经理负责完成。

验收标准：

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

2.2.2需求分析

任务描述：

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

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

需求分析的基本任务

1.问题识别

（1）功能需求：

明确所开发的软件必须具备什么样的功能。

（2）性能需求：

明确待开发的软件的技术性能指标。

   （3）环境需求：

明确软件运行时所需要的软、硬件的要求。

   （4）用户界面需求：

明确人机交互方式、输入输出数据格式。

2.分析与综合，导出软件的逻辑模型

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

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

3.编写文档

一般可以采用UML对需求分析进行建模。

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

参与人员：

需求分析工程师；

验收标准：

完成需求分析说明书，并签入服务器；

2.2.3概要设计

在软件需求分析阶段，已经搞清楚了软件“做什么”的问题，并把这些需求通过规格说明书描述了出来，这也是目标系统的逻辑模型。

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

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

概要设计的基本任务：

1、概要设计

任务描述：

概要设计明确系统采用的技术手段、开发语言，模块划分。

参与人员：

项目经理、软件工程师。

验收标准：

完成概要设计说明书。

2、界面设计

任务描述：

良好的人机界面是一个软件成功的重要因素之一。

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

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

参与人员：

软件工程师。

验收标准：

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

3、数据库设计

任务描述：

如果系统需要使用数据库存储数据，需要进行数据库设计。

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

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

参与人员：

软件工程师。

验收标准：

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

2.2.4开发阶段

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

开发阶段的基本任务：

1、代码编写

任务描述：

根据设计文档，进行单元编码。

编码可能包括两个方面：

编程语言代码、数据库存储过程代码。

参与人员：

软件工程师。

验收标准：

单元编码。

2、单元测试

任务描述：

根据详细设计，编写单元测试代码。

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

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

参与人员：

软件工程师。

验收标准：

完成单元测试代码。

2.2.5测试阶段

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

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

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

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

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

测试阶段的主要任务：

1、编写测试用例

任务描述：

根据需求分析、系统设计，由针对性的设计测试系统数据、操作流程，用于验证系统。

参与人员：

测试经理。

验收标准：

完成测试说明书、数据库测试数据。

2、测试跟踪记录

任务描述：

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

并跟踪错误的解决情况。

参与人员：

测试工程师。

验收标准：

建立测试跟踪记录文件。

2.2.6发布阶段

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

测试阶段的主要任务:

1、编写安装程序

任务描述：

为应用程序编写安装程序，方便用户使用。

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

参与人员：

测试经理。

验收标准：

安装测试。

2、帮助

任务描述：

根据应用程序类型制作系统帮助文件。

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

参与人员：

测试工程师。

验收标准：

完成帮助文档。

2.3迭代开发

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

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

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

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

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

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

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

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

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

因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：

需求工作流、分析和设计工作流、实现工作流、测试工作流。

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

与传统的瀑布模型相比较，迭代过程具有以下优点：

1、降低了在一个增量上的开支风险。

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

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

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

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

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

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

因此，迭代过程这种模式使适应需求的变化会更容易些。

3配置管理

3.1概述

软件配置管理（SCM，SoftConfigureManagement）的目的是在整个项目的软件生存周期内，建立和维护软件项目产品的完整性。

软件配置管理包括在给定时间点上及时地标识软件的配置，系统地控制对配置的更改，并在整个软件生存周期中维护配置的完整性和可跟踪性。

置于软件配置管理之下的工作产品包括交付给客户的软件产品（如软件需求文档和代码），以及与这些软件产品一同标识的或为产生这些软件产品所要求的产品项（如编译程序）。

软件配置管理包括了多项相关活动，包括版本控制、建立软件配置库系统、配置项变化的控制、软件基线记录报告等等。

在实训项目中我们只要求进行开发过程中的版本控制。

在一个项目的开发过程中，一定是涉及到多人合作，共同完成设计、编码、测试等工作。

为了避免项目组的不同成员在开发过程中，因为代码、文档不一致，影响开发进度；在开发过程中必须要使用一种版本管理工具。

版本管理工具记录了所有库中代码和文档的开发历程，可以保证产品的可追溯性，为调试代码、清除缺陷提供很大的帮助。

同时，版本管理支持并行开发和维护，为协同开发打下了基础。

3.2版本控制工具

目前流行的源代码主要有MicrosoftSourceSafe、CVS、SVN、RationalClearCase等。

根据不同的项目，选择不同的源代码管理工具。

1、MicrosoftSourceSafe

SourceSafe微软公司生产的源代码管理工具，能够与VisualStudio很好的集成。

在Windows组成的局域网内使用，配置管理非常方便。

一般来讲，使用VisualStudio作为主要的开发工具时使用SourceSafe作为项目的源代管理工具。

2、CVS/SVN

CVS/SVN都是开源项目经常使用的源代码管理工具。

它的优点是能够使用HTTP协议，可以摆脱局域网的限制。

但是配置、管理相对复杂。

CVS可以与Eclispe、NetBeans等开发工具比较好的集成。

如果使用JAVA开发项目时，建议使用CVS或者SVN作为开发工具。

3.3项目目录结构

在项目开发过程中，会创建很多的代码、文档、图片等文件。

为了更好的管理这些文件，专门定义项目开发时的目录结构，便于文件分门别类进行存放。

当项目开发时，一般需要定义项目开发代号，这里假设项目代号是。

目录结构如图1所示：

图2

1、项目管理

项目管理目录存放关于项目进度规划、任务安排、项目成员工作日志。

2、需求分析

此目录存放项目需求文档以及需求相关的资料、分析产生的中间文档等。

3、概要设计

此目录存放项目的概要设计文档，以及使用UML设计文档、数据库设计文档等。

4、详细设计

存放详细设计文档及相关资料

5、源代码

存放开发过程的源代码，包括创建数据的脚本文件、安装程序源代码、帮助文件等开发过程产生的文件。

6、测试

项目开发过程中需要进行测试，准备测试数据。

将测试过程的记录、测试文档、自动化测试脚本放在此文件中。

7、发布

将项目的安装程序、帮助手册其他辅助发布的文档放在此目录中。

8、开发资料【非必须】

开发过程中经常用到的技术文档、参考资料

9、公共组件【非必须】

存放本项目中使用到的一些公共组件。

避免出现大家使用的组件版本不一致的情况。

附件：

文档参考手册