软件开发管理过程文档格式.docx

软件开发管理过程文档格式.docx

《软件开发管理过程文档格式.docx》由会员分享，可在线阅读，更多相关《软件开发管理过程文档格式.docx（23页珍藏版）》请在冰豆网上搜索。

4.5产品发布16

5.过程支持17

5.1配置管理17

5.2产品和过程质量保证17

5.3测量与分析17

5.4决策分析和决定18

1.序言

2.组织的标准过程

2.1建立并完善一套适合公司实际情况的开发管理体系

标准过程是整个软件开发团队需要遵循的规范和章程，它规定了各个过程的该如何做，该做成什么样子，各个过程的输入输出。

如果标准过程不够完善，势必导致整个软件开发团队的混乱，团队成员将无法知道怎么开发，开发到什么程度算合格。

我们从A公司“需求”相关的标准过程中提取出部分来举例说明：

从上面的流程图中，我们不难发现，它清楚的定义了整个需求分析要经历如下过程，需求开发（需求获取、需求分析、需求定义）、需求管理（…）

有以下输入输出，需求开发中，需求获取时需要输入《项目立项公告》，输出《用户需求说明书》…

当然A公司在“需求”相关的标准过程中，对该过程活动以及产品进行了适当并且无二义性的描述。

有了标准过程的约束和指导，我们便能清楚的知道这个过程该如何做，该做成什么样子，当然软件开发管理其他的过程也是如此，下面我会对此一一描述。

所以我们急需制定出标准过程，并且对标准过程进行评审，最终得到一套适合我们公司的标准过程来约束软件开发管理过程。

2.2持续改进并完善组织的标准过程

建立了标准过程在实施中必然会遇到问题，这时需要根据企业的实际情况不断地做出改进。

为此在有条件的情况下，我们需要成立一个专门的小组对标准过程进行持续改进并的工作（EPG）。

这样可以使得我们的标准过程越来越适合我们公司的发展需要。

3.项目管理

其中项目策划、项目监督和控制以及风险管理我结合实际具体描述。

3.1立项

立项的过程如下图所示

个人认为公司的所有产品都需要进行立项，并且需要对项目进行分析、评审确保项目的可行性。

这样既可以在相关的人员中达成共识，同时明确相关成员的职责。

3.2集成项目管理

集成项目管理主要是结合项目实际情况对标准体系按照组织的裁剪指南进行裁剪，经过评审，最终形成项目的已定义过程来管理项目。

主要流程如下图所示：

集成项目管理简单地说来就是根据规范删减标准过程来适应项目，满足项目的要求，这样做可以使得标准过程变得更为灵活，同时具备更强的适应能力。

当然集成项目管理中还牵涉一个问题，就是项目的生命周期的选择，而生命周期的选择需要根据项目的特性来进行选择，例如需求非常明确的项目可以选择瀑布型，需求不太明确并且不断地有需求增减的项目可以选择增量型，要求非常苛刻的可以选择“V”字型（SPICE中的比较推荐的模型，如果前装项目可以用此模型来开发），等等。

3.3项目策划

3.3.1计划

项目策划这里并不仅仅局限于项目进度计划，还包括项目的规模、工作量、质量、成本、资源、风险等计划。

项目实施前，应合理地分解项目工作任务，对项目的规模、工作量、质量、进度、成本、资源、风险等进行适当的估计和策划，编制形成项目的总体计划与支持计划，同时在项目的实施过程中根据项目的进展与偏差情况调整项目总体计划与支持计划。

软件的规模是通过代码行数来表现，需要项目相关成员根据项目所要完成的任务（各自所要实现的软件需求），以及以前项目的经验，来进行估计；

工作量可以结合软件规模和我们团队目前的人均月代码行，按照各个过程的分布比例，分别进行估算；

软件开发团队的成本主要和每个人的工作量挂钩，以及部分设备，或者培训等其他方面资金的投入；

产品的质量可以结合规模、难易程度、产品发布前后代码BUG率以及行业内的水平进行，按照各个过程的分布比例分别进行估计；

根据项目的需求对所需的资源进行估计，包括人力、物力、财力等；

在整个开发过程中需不断的识别风险，对风险进行处理，制定风险管理计划。

以上这些计划而且需要在实施前就需要估计和策划好，以便在实施时和估计值进行比较，从而能及时做出处理，以确保项目在受控中顺利实施。

项目的策划过程如下图所示：

计划其实与我们公司的“凡是工作，必有计划”方针是一致的，在接下来的一些过程的介绍时，大家不难发现几乎什么过程都有计划，有些甚至是计划的计划。

3.3.2计划变更

在项目前期我们对项目的各个方面进行了计划、估计，随着项目的进展，以及外部的因素等影响，或多或少的会产生一定的偏差。

当偏差大于标准体系规定的阀值时，需要对计划进行变更，及时地纠正项目计划的偏差，确保项目工作在合理的计划安排中进行。

具体流程如下：

当然偏差值也仍然在受控范围内，可以不用变更计划，但这个时候需要制定措施来控制项目的偏差，如果偏差值在合理范围内，可以不用制定措施。

同样计划的变更也不仅仅是指进度方面的，可以是质量、工作量、成本等等。

3.4项目监督和控制

项目监督和控制的目的是通过周期性地跟踪项目计划的各种性能参数如工作产品的规模、工作量、成本、进度、风险等，不断地了解项目的进展情况，以便当项目实际进展状况显著偏离项目计划时能够及时采取纠正措施。

最终目的都是为了使项目按时、按预算交付合格的产品。

跟踪的方式有三种：

周跟踪、里程碑跟踪、不定期跟踪。

周跟踪的主要内容：

✧任务跟踪：

对进度和工作量进行跟踪。

✧资源及承诺等跟踪：

对软硬件资源、人力资源、培训资源，项目内外部的承诺、数据管理、共利益者介入情况等进行跟踪。

✧风险跟踪：

没有设置里程碑的项目，在周跟踪时跟踪风险缓解措施的解决情况，识别新的风险。

进行风险管理。

✧问题解决跟踪：

对问题解决情况进行跟踪。

里程碑跟踪的主要内容：

跟踪任务完成情况，包括工作量和进度。

✧费用跟踪：

跟踪项目费用执行情况，包括人力资源成本和直接费用。

✧规模跟踪：

跟踪工作成果及其规模。

跟踪风险缓解措施的解决情况，并对风险进行重新评估，确保新的风险变化能被及时识别。

✧资源、承诺、共利益者介入、问题解决等跟踪。

不定期跟踪的主要内容：

✧关键任务跟踪：

对特别重要的任务不定期的进行跟踪，以便及时制定措施。

✧关键对策的跟踪：

对于关键问题解决方案实施效果进行跟踪。

跟踪方式可以但不局限于如下方式：

✧进行周跟踪（工作量、进度、资源、承诺、问题）

✧编写项目周报

✧召开项目例会

✧对项目成员工作的检查与监督

✧里程碑会议、评审

该过程的主要流程如下：

每次跟踪完成时，需要将跟踪的结果对比更新至原先的计划中。

例如不断的更新进度、质量、风险等计划，这样才能及时地跟估计值进行比较，识别出问题时也能相应地进行对策。

3.5风险管理

风险管理（RiskManagement,RSKM）的目的在于识别潜在的问题，以便策划处理风险的活动（识别、分析评估和缓解）和在必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现项目目标。

风险管理主要有四个活动：

✧风险识别：

确定对项目的进度、成本和质量造成不利影响的风险的来源，风险产生的条件，描述其风险特征和造成结果描述。

风险识别不是一次就可以完成的事，应当在项目生命周期内定期进行。

✧风险评估：

运用风险参数（风险概率、风险影响、风险值等）对每个风险进行评价和分类，并确定其相对优先顺序。

✧风险缓解：

针对风险评估的结果，针对那些对项目来说最重要的风险拟订风险缓解措施的过程。

✧风险监控：

涉及整个项目管理过程中定期监督每个风险的状态，并在适当时候实施风险缓解措施。

该活动的输出包括应对风险的缓解措施以及更新的风险管理报告。

风险管理的主要流程如下：

风险和问题是有区别的，风险是项目过程中有可能遇到但还没有发生的潜在问题，当潜在问题发生时，便已经不再是风险，需要当作项目的问题来进行对策。

3.6供方协定管理

通过对供方与采购活动实行控制，确保适质、适价、适时、适量地满足采购要求，并实现产品的采购。

主要流程如下：

例如我们的导航产品，地图数据的供方有四维、高德以及凯立德等，我们需要根据客户的需求进行采购和管理。

3.7结项管理

结项管理（ProjectClosingManagement,PCM）的目的是在项目工作结束后，对项目工作情况、经验教训进行总结；

依据项目的目标和计划对项目完成情况和目标实现情况进行综合评价。

项目结束有两种状况：

一是正常结束，二是异常结束。

结项管理不仅针对正常结束的项目，对于异常结束的项目也必须进行项目的经验总结和综合评价，积累经验教训使整个组织受益。

4.软件工程

4.1需求开发与管理

软件需求工程包括了需求开发和需求管理两个部分，需求开发的目的是通过调查与分析，获取用户需求并定义软件需求。

需求开发的主要活动包括：

需求获取，需求分析和需求定义。

需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。

需求管理的主要活动包括：

需求确认，需求变更和需求跟踪控制。

主要流程在2.1章节中已经介绍过了。

用户需求和软件需求是两个不同层面上的概念，前者是建立客户和项目组的联系，后者是建立项目组内部的联系。

用户的需求往往比较简单，我们可以通过访谈、讨论会或者展示DEMO等方式来和客户达成共识，确保项目组实现的产品就是客户想要的。

获取用户需求后，我们需要对需求进行分析和定义，生成软件需求。

下面我们以A公司的产品来举例。

如上图所示，车厂客户给A公司的FeatureList关于地图操作方面的要求。

如上图所示，A公司将客户的需求形象化，制作成操作规格书和用户确认，很容易和用户达成共识，同时也便于项目组内部的分析和评审活动的开展。

如上图所示，A公司根据确认后的用户需求进行分析，产生需求跟踪矩阵（RTM）和软件需求规格书，以便在后期的软件开发工程中作对应、维护以及变更工作。

（由于RTM文件比较大，我仅截取部分来说明）

这个可以使得整个需求开发和管理过程条理清晰，客户和项目组都没有二义性，减少不必要的麻烦。

4.2系统设计编码

系统设计编码的目的在于开发、设计和实现关于需求的解决方案。

软件需求规格书以及RTM中的各项要求在设计时都能够得到满足；

对项目的编码实现进行质量控制，保证编码实现活动按计划顺利完成并与设计相一致。

该过程的主要流程如下：

4.2.1系统设计

系统设计主要包括概要设计和详细设计。

概要设计是建立整个软件的体系结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义等。

包括：

Ø

总体架构设计

上图所示为匹配模块的总体设计中描述道路匹配过程的设计。

接口设计

上图所示为匹配模块的接口设计，从图中我们可以看到，在接口设计时与需求建立了一个对应关系，以便进行需求的管理、维护以及验证。

界面总体设计

数据结构设计

系统部署等

详细设计根据确定的设计方法，选择适当工具进行详细设计，以获得关于处理逻辑、数据结构和数据定义的更加详尽的描述，最终产生软件工程师可用的模块说明。

可以包含：

描述

功能

参数说明

性能（可选）

用户界面

流程逻辑

算法等（可选）

上图所示为匹配模块的详细设计，从上图中可以看出详细设计的细致程度，详细设计等于写了一份伪代码，这样做可以对接下来的编码工作进行指导和规范。

很多程序员不愿意进行设计工作，认为设计是多余的，会降低整体产品开发的效率。

其实不然，良好的设计，往往便于自己以及他人了解以及维护将要开发的产品，对自己的工作给出清晰并且比较有针对性的指导，同时也便于以后的维护工作，提高整体的工作效率。

因为理解设计往往比理解代码要容易的多，设计的同时更容易暴露问题，也更容易解决问题，我们应该让更多的问题暴露在设计阶段。

设计的同时也需要建立于需求的对应关系，同样编码也需要和设计进行对应（其实每个过程都应该是可以溯源的），以便进行因需求变更引起的设计方面的修改，乃至于直接找到具体是哪些代码需要进行修改。

4.2.2系统实现

系统实现主要包括编码、单元测试以及代码走查部分。

上图所示为匹配模块的代码，其中注释和条理都是比较清楚的，便于后期工作的展开（检查以及维护等）。

绝大部分程序员不太喜欢写注释，其实写注释有很多显而易见的好处，1、便于自己理清思路，使得代码整体条理清晰；

2、便于代码检查和修改；

3、便于后期自己或者他人的维护；

4、通过注释可以和设计进行对应，便于软件产品开发的整体的溯源等。

此外整个软件团队编码应遵循统一的规范，使得最终的代码质量、风格等基本达到一致，增加整体的可读性和易维护性等。

最后还有单元测试和代码走查这两个活动，这两个活动往往是大多数公司做的不好的，与员工的责任心和惰性有一定的关系，编码完成的系统各模块可以针对项目中的重要模块、算法复杂的相关模块进行单元测试。

由模块开发人员进行，有条件的可以由其它开发人员进行互换测试。

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

源代码编译-----测试代码是否通过编译。

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

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

边界条件-----在边界上模块是否能正常工作。

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

出错处理-----检查模块的错误处理设施是否有效。

单元测试过程能发现的问题，往往在集成测试中难以发现，特别是一些边界问题。

因为集成测试对有些看不见的过程很难覆盖全面，但是随着使用数量、次数或者时间增多等因素这些问题将会逐渐地暴露出来，如果没有很好的解决，最终这些问题将被用户发现，可能导致很严重的问题，所以应该重视此过程的作用。

4.3测试

测试作为质量控制的一种有效手段，运行测试用例找出软件中潜在的各种缺陷，通过协助开发人员修正缺陷来提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患和降低质量成本。

通过测试管理为产品与过程改进提供可靠的数据分析，起到缺陷预防的作用。

缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的质量。

细分为：

1）从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发现的缺陷都能够被解决；

2）收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；

可以通过缺陷趋势图来确定测试过程是否结束；

3）在已收集到的缺陷数据的基础上进行统计分析。

总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。

缺陷管理流程如下：

4.4评审

根据评审的内容特点，评审活动可分为管理类评审和技术类评审，适用范围如下：

管理类评审：

与管理相关的评审活动，如立项评审、项目计划评审、里程碑评审、结项评审等。

管理评审方式包括：

会议、审批两种；

技术类评审：

与技术相关的评审活动，如需求评审、概要设计评审、详细设计评审、代码走查、测试用例评审等。

技术评审一般采用同行评审方式，主要包括：

技术评审会议、个人复查两种。

我们团队目前评审做得比较薄弱，有些过程几乎没有评审。

即使有评审，评审时发现的问题也比较少，对评审发现的问题也缺乏跟踪解决。

如果采用会议评审方式，首先在评审前应由评审发起人将待评审的材料发给相关成员，评审后需要生产会议纪要和评审报告，以便对评审时发现的问题进行跟踪。

4.5产品发布

软件产品的发布包括产品发布与产品对外发行两个步骤。

产品发布是从受控库获取发布产品配置项，进行产品版本标识，将需要发布的产品和文档放置在产品库规定目录下，并经过发布审批实施发布的活动。

产品对外发行是指将产品正确版本提供给客户的过程。

过程如下：

5.过程支持

过程支持主要包括：

配置管理、产品和过程质量保证、测量与分析以及决策分析和决定。

5.1配置管理

配置管理的目的是协调软件开发，使得混乱减少到最少，从而提高开发效率。

主要流程如下：

5.2产品和过程质量保证

通过质量保证活动，确保过程与产品满足过程、规程及相应的要求，确保问题得到关注与解决，使工作人员和管理者能够客观地了解过程与相关的工作产品。

质量保证不仅仅局限在保证产品的质量，还需要保证整个开发产品的过程，所以质量保证工程师需要同事检查产品的质量以及产品开发的过程。

5.3测量与分析

测量和分析（MeasurementandAnalysis,MA）的目的在于开发和维持度量能力，以便支持对管理信息的需要。

通过测量和分析，对组织产品和服务提供各环节的指标进行监控，客观了解组织各部门的过程和产品的实施情况；

识别组织的薄弱环节，为组织过程改进和产品改进提供定量信息；

并为公司管理决策提供定量信息。

策划测量和分析，使测量目标和测量行为与信息需要和目标取得一致；

实施测量和分析活动，收集分析测量数据，提供结果。

测量和分析这个过程简单地来说，就是不断地收集过程中的一些数据，例如开发人员的人均月代码行数（生产率）、发布前后缺陷密度、问题及时关闭率等等，不断地和组织指标以及和历史项目进行对比，发现现存的问题，也能客观地对组织和项目做出评价，发现改进的方向。

数据是最客观和最具说服力的依据。

这就像提高某产品性能一样，我们一般都以提高性能前后的一些方面的数据来进行对比分析的。

5.4决策分析和决定

决策分析和决定（DecisionAnalysisandResolution，DAR）的目的在于运用结构化方法对组织内与项目有关的关键决策行为提供有效的方法。

当出现如下情况时需要用到决策分析:

●存在多项目立项决策时

●项目管理的风险管理中，高级别的风险存在多个缓解措施进行选择时

●系统设计和编码过程中系统架构选择和关键技术方案，存在多个方案选择时